Detect Application Window Discovery in Splunk
Adversaries may attempt to get a listing of open application windows. Window listings convey information about how the system is used and help adversaries identify potential data sources and security tooling to evade. Malware families including Attor, njRAT, DarkWatchman, Grandoreiro, InvisiMole, and Lazarus Group tooling use this technique to obtain window titles and correlate them with keylogger output, identify running security products by window name, locate cryptocurrency wallets, and determine sandbox environments. Adversaries typically implement this via native Windows API functions (EnumWindows, GetForegroundWindow, FindWindow, GetWindowText from user32.dll), scripting languages using P/Invoke or COM automation, or automation tools such as AutoHotkey and AutoIt. On Linux and macOS, adversaries may use xdotool, wmctrl, or Quartz/Cocoa APIs to achieve equivalent capability.
MITRE ATT&CK
- Tactic
- Discovery
- Technique
- T1010 Application Window Discovery
- Canonical reference
- https://attack.mitre.org/techniques/T1010/
SPL Detection Query
index=wineventlog sourcetype="XmlWinEventLog:Microsoft-Windows-Sysmon/Operational" EventCode=1
| eval CommandLineLower=lower(CommandLine)
| eval ImageLower=lower(Image)
| eval ParentImageLower=lower(ParentImage)
| eval ScriptWindowAPIEnum=if(
match(ImageLower, "(powershell|pwsh|wscript|cscript|mshta|python[23]?|ruby|perl)\.exe") AND
match(CommandLineLower, "(getforegroundwindow|enumwindows|findwindow|getwindowtext|getactivewindow|enumchildwindows|getwindowlong|findwindowex)"),
1, 0)
| eval PInvokePattern=if(
match(ImageLower, "(powershell|pwsh)\.exe") AND
match(CommandLineLower, "(add-type|dllimport)") AND
match(CommandLineLower, "user32") AND
match(CommandLineLower, "(window|hwnd)"),
1, 0)
| eval COMShellEnum=if(
match(ImageLower, "(powershell|pwsh|wscript|cscript|mshta)\.exe") AND
match(CommandLineLower, "shell\.application") AND
match(CommandLineLower, "windows\(\)"),
1, 0)
| eval AutomationToolEnum=if(
match(ImageLower, "(autoit3|autohotkey|ahk2exe)(_x64)?\.exe") AND
NOT match(ParentImageLower, "(explorer|devenv|code|notepad\+\+|sublime_text|atom)\.exe"),
1, 0)
| eval KnownWinEnumTool=if(
match(ImageLower, "(winlister|wintitles|windowdetective|spyxx(_amd64)?|winspector)\.exe"),
1, 0)
| eval TotalScore=ScriptWindowAPIEnum + PInvokePattern + COMShellEnum + AutomationToolEnum + KnownWinEnumTool
| where TotalScore > 0
| eval DetectionVector=case(
KnownWinEnumTool=1, "Known Window Enumeration Utility",
AutomationToolEnum=1, "Automation Tool Window Enumeration (Unusual Parent)",
PInvokePattern=1, "PowerShell P/Invoke Window API",
COMShellEnum=1, "COM Shell Window Enumeration",
ScriptWindowAPIEnum=1, "Script Window Enumeration API",
1=1, "Unknown"
)
| table _time, host, User, Image, CommandLine, ParentImage, ParentCommandLine, DetectionVector, TotalScore
| sort - _timeDetects application window discovery via Sysmon Event ID 1 (Process Creation). Evaluates command lines from scripting engines and automation tools against known window enumeration patterns including Win32 API function names (EnumWindows, GetForegroundWindow, GetWindowText), PowerShell P/Invoke signatures loading user32.dll for window operations, COM Shell.Application window enumeration, and AutoHotkey/AutoIt spawned from non-development parent processes. A composite score is computed to prioritize alerts with multiple corroborating indicators.
Data Sources
Required Sourcetypes
False Positives & Tuning
- Legitimate AutoHotkey or AutoIt scripts used by IT support staff for desktop automation and helpdesk tooling
- Screen recording, remote desktop, and accessibility software (NVDA, JAWS, TeamViewer) that enumerates windows for UI interaction
- Developer tooling such as UI testing frameworks (WinAppDriver, TestComplete, Ranorex) that programmatically enumerate windows
- Python RPA automation using pywin32 or pywinauto libraries in approved business automation workflows
- PowerShell scripts querying Shell.Application window state for IT inventory or configuration management
Other platforms for T1010
Testing Methodology
Validate this detection against 4 adversary techniques from Atomic Red Team. Each test below lists the behaviour to exercise and the telemetry you should expect to see. Executable commands and cleanup steps are available with Pro.
- Test 1 PowerShell P/Invoke Window Enumeration via GetForegroundWindow
Expected signal: Sysmon Event ID 1: Process Create with Image=powershell.exe, CommandLine containing 'Add-Type', 'DllImport', 'user32.dll', 'GetForegroundWindow', and 'GetWindowText'. PowerShell ScriptBlock Log Event ID 4104 in Microsoft-Windows-PowerShell/Operational will capture the full deobfuscated Add-Type code block including the user32.dll import declarations.
- Test 2 PowerShell COM Shell.Application Window Enumeration
Expected signal: Sysmon Event ID 1: Process Create with Image=powershell.exe, CommandLine containing 'Shell.Application' and 'Windows()'. PowerShell ScriptBlock Log Event ID 4104 with the full COM enumeration code. No network connection events expected as this is a local enumeration call.
- Test 3 PowerShell Full Window Enumeration via EnumWindows Callback
Expected signal: Sysmon Event ID 1: Process Create with Image=powershell.exe, CommandLine containing 'Add-Type', 'EnumWindows', 'GetWindowText', 'IsWindowVisible', and 'user32.dll'. PowerShell ScriptBlock Log Event ID 4104 with the full multi-line Add-Type type definition including all three DllImport declarations and the callback delegate pattern.
- Test 4 VBScript COM Window Enumeration via Shell.Application
Expected signal: File creation event (Sysmon Event ID 11) for %TEMP%\df00tech_wintenum.vbs. Sysmon Event ID 1: Process Create with Image=cscript.exe, CommandLine containing '//e:vbscript' and the .vbs filename. The VBScript content (Shell.Application COM enumeration) will be visible in script file artifacts but not the cscript command line itself — emphasizing the need for script content logging where available.
References (8)
- https://attack.mitre.org/techniques/T1010/
- https://web.archive.org/web/20220629230035/https://www.prevailion.com/darkwatchman-new-fileless-techniques/
- https://www.welivesecurity.com/2020/04/28/grandoreiro-how-engorged-can-exe-get/
- https://securelist.com/nettraveler-is-running-red-star-apt-attacks-compromise-high-profile-victims/35936/
- https://github.com/redcanaryco/atomic-red-team/blob/master/atomics/T1010/T1010.md
- https://learn.microsoft.com/en-us/windows/win32/api/winuser/nf-winuser-enumwindows
- https://learn.microsoft.com/en-us/windows/win32/api/winuser/nf-winuser-getforegroundwindow
- https://www.autohotkey.com/docs/v2/lib/WinGetTitle.htm
Response Playbook
Triage
- Identify the process performing enumeration — is it a known scripting engine (PowerShell, Python, AutoHotkey), a compiled unknown binary, or a recognized third-party tool? Unknown compiled binaries warrant immediate escalation.
- Examine the parent process chain — was the script/tool spawned by a browser, email client, Office application, or other phishing vector? Parent process of explorer.exe or mshta.exe is highly suspicious for initial access scenarios.
- Determine what windows were being targeted — review the full command line or, for PowerShell, ScriptBlock logs (Event ID 4104) to understand if the enumeration was looking for specific keywords (security product names, 'Wireshark', 'Process Monitor', 'Sandbox', cryptocurrency wallet names).
- Check for keylogger correlation — T1010 is frequently paired with keylogging (T1056.001). Search within ±30 minutes for the same process writing to disk or making unusual network connections that could indicate combined keylog+window-context exfiltration.
- Assess the user context — does the account that launched the process match the logged-on user? Service accounts or SYSTEM running window enumeration scripts are anomalous.
- Check if the process subsequently accessed screen capture APIs or spawned screenshot utilities — T1113 (Screen Capture) is the most common follow-on to T1010, with malware like Attor and njRAT recording window titles alongside screenshots.
Containment
- If the enumerating process is unknown or unsigned: terminate the process via EDR remote response and quarantine the originating file for analysis.
- If the process is confirmed malicious and has made outbound connections: isolate the endpoint from the network immediately using EDR isolation, then preserve disk image before any further action.
- If the process was spawned from an Office document or browser: disable macro execution or quarantine the originating document/download, and scan all recently opened files from that user.
- If the tool was deployed via a lateral movement vector (psexec, WMI, scheduled task): identify and contain all potentially affected hosts using the same parent process pattern, and reset any credentials that may have been exposed.
- Block the enumerating binary's hash at the EDR level and add the originating URL/email attachment to blocklists at proxy and email gateway.
Evidence Collection
- PowerShell ScriptBlock Logs (Event ID 4104 from Microsoft-Windows-PowerShell/Operational) — captures full deobfuscated script content including any window enumeration API calls and results output
- Sysmon Event ID 1 (Process Create) — command line arguments, parent process, user context, and process hash for the enumerating process
- Sysmon Event ID 3 (Network Connection) — any outbound connections made by the enumerating process within the same session, which may indicate window titles being exfiltrated to C2
- Sysmon Event ID 11 (File Create) — if the process wrote window title output to disk (common in keylogger+window-context malware like DarkWatchman)
- Memory dump of the enumerating process — native compiled malware using EnumWindows callback will have API call evidence in process memory even if command line is clean
- Prefetch files (C:\Windows\Prefetch\) — execution timestamps for autoit3.exe, autohotkey.exe, winlister.exe, or any suspicious executable
- PowerShell command history ($env:APPDATA\Microsoft\Windows\PowerShell\PSReadLine\ConsoleHost_history.txt) — if an interactive session was used
- Browser or email client artifacts — if the enumerating process was spawned from a document-based phishing payload, recover the original lure document
Escalation Criteria
- !The enumerating process searched for security product window names (Wireshark, Process Monitor, x64dbg, Fiddler, Sandbox, VMware, VirtualBox) — this indicates active evasion or sandbox detection behavior consistent with professional malware
- !The enumerating process searched for cryptocurrency wallet window names (Electrum, Exodus, MetaMask, Ledger Live) — this matches DarkGate and banking trojan TTPs for financial theft
- !Window enumeration was followed within 60 seconds by screen capture activity (magicaltux.dll, PrintWindow API, BitBlt calls, or known screenshot tool execution)
- !The process is unsigned or has an untrusted certificate chain, executed from a temp, AppData, or Downloads directory
- !Window titles were captured and sent over the network — correlate Sysmon Event ID 3 with connections to non-corporate IPs immediately after enumeration
- !Multiple endpoints in the environment show the same window enumeration pattern within a short timeframe, suggesting automated lateral movement or a worm-like spread
Investigation Guide
Related Techniques
Forensic Artifacts
- >
Prefetch: C:\Windows\Prefetch\AUTOIT3.EXE-*.pf, AUTOHOTKEY.EXE-*.pf — execution timestamps and loaded DLL list revealing user32.dll access - >
Prefetch: C:\Windows\Prefetch\WINLISTER.EXE-*.pf, WINDOWDETECTIVE.EXE-*.pf — NirSoft/third-party tool execution evidence - >
PowerShell ScriptBlock Log: Event ID 4104 in Microsoft-Windows-PowerShell/Operational — full deobfuscated window enumeration script content - >
PowerShell History: $env:APPDATA\Microsoft\Windows\PowerShell\PSReadLine\ConsoleHost_history.txt — interactive session commands - >
AutoHotkey Script Files: .ahk files in temp directories, AppData, or startup folders containing WinGetTitle, WinGetClass, or WinList calls - >
AutoIt Script Files: .au3 or compiled .exe files; decompile with exe2aut or myaut2exe for window enumeration logic - >
Process Memory: Heap allocations containing window title strings — accessible via memory dump analysis (strings on process memory or Volatility windows plugin) - >
File System: Any text/log files written to disk by the enumerating process containing window title output — common in keylogger modules - >
Network Captures: Window title data encoded in C2 traffic — check for Base64-encoded strings matching window title patterns in DNS queries or HTTP POST bodies
Tuning Guidance
Begin by baselining legitimate automation tool usage in your environment. AutoHotkey and AutoIt have widespread legitimate use in IT support, helpdesk tooling, and accessibility software — build an allowlist of known script hashes and parent process combinations before alerting broadly. For PowerShell P/Invoke detections, exclude known DevOps automation accounts and SCCM/Intune service accounts that may use window API calls in deployment scripts. For the Shell.Application COM vector, note that some monitoring agents query window state for application availability checks. The most reliable signal is context: window enumeration from a process spawned by a browser, email client, Office macro, or an unexpected parent (mshta.exe, wscript.exe, cmd.exe from a temp path) should always be escalated. Consider implementing a correlation rule that fires when T1010 indicators co-occur within 10 minutes with T1113 (screen capture) or T1056 (keylogging) on the same endpoint — this pattern is definitively malicious and seen in Attor, DarkWatchman, and njRAT deployments. On endpoints where AutoHotkey/AutoIt is not an approved business application, consider blocking these binaries via application control policies rather than relying on detection.
Hunting Queries
Hunt for recurring window enumeration activity across the environment to identify persistent malware or automated tooling. Aggregating by account and interpreter reveals compromised accounts or widespread deployment of enumeration scripts. Multiple devices affected by the same account is a strong indicator of lateral movement with an enumeration capability.
DeviceProcessEvents
| where Timestamp > ago(7d)
| where FileName in~ ("powershell.exe", "pwsh.exe", "wscript.exe", "cscript.exe", "python.exe", "python3.exe", "autoit3.exe", "autohotkey.exe")
| where ProcessCommandLine has_any ("GetForegroundWindow", "EnumWindows", "FindWindow", "GetWindowText", "GetActiveWindow", "Shell.Application", "WinGetTitle", "WinList")
| summarize Count=count(), Devices=dcount(DeviceName), FirstSeen=min(Timestamp), LastSeen=max(Timestamp), SampleCommandLine=take_any(ProcessCommandLine) by AccountName, FileName
| where Count > 1
| sort by Count descindex=wineventlog sourcetype="XmlWinEventLog:Microsoft-Windows-Sysmon/Operational" EventCode=1
(Image="*\\powershell.exe" OR Image="*\\pwsh.exe" OR Image="*\\wscript.exe" OR Image="*\\cscript.exe" OR Image="*\\python.exe" OR Image="*\\autoit3.exe" OR Image="*\\autohotkey.exe")
(CommandLine="*GetForegroundWindow*" OR CommandLine="*EnumWindows*" OR CommandLine="*FindWindow*" OR CommandLine="*GetWindowText*" OR CommandLine="*Shell.Application*" OR CommandLine="*WinGetTitle*")
| stats count as Count, dc(host) as Devices, earliest(_time) as FirstSeen, latest(_time) as LastSeen, values(CommandLine) as CommandLines by User, Image
| where Count > 1
| sort - CountCorrelate window enumeration activity with outbound network connections from the same process. Malware that enumerates windows (keylogger+context) and exfiltrates to C2 will show both signals within the same process ID. This query hunts for the exfiltration phase following window discovery, which is the primary threat scenario for families like DarkWatchman, Attor, and njRAT.
let WindowEnumProcesses = DeviceProcessEvents
| where Timestamp > ago(7d)
| where ProcessCommandLine has_any ("GetForegroundWindow", "EnumWindows", "GetWindowText", "GetActiveWindow")
or FileName in~ ("autoit3.exe", "autohotkey.exe", "winlister.exe")
| distinct DeviceName, AccountName, ProcessId, Timestamp;
WindowEnumProcesses
| join kind=inner (
DeviceNetworkEvents
| where Timestamp > ago(7d)
| where RemoteIPType == "Public"
| project DeviceName, NetworkTimestamp=Timestamp, RemoteIP, RemotePort, InitiatingProcessId
) on DeviceName, $left.ProcessId == $right.InitiatingProcessId
| where NetworkTimestamp between (Timestamp .. (Timestamp + 5m))
| project Timestamp, NetworkTimestamp, DeviceName, AccountName, RemoteIP, RemotePort
| sort by Timestamp descindex=wineventlog sourcetype="XmlWinEventLog:Microsoft-Windows-Sysmon/Operational"
| eval is_enum=if(EventCode=1 AND (match(CommandLine, "(?i)(GetForegroundWindow|EnumWindows|GetWindowText|GetActiveWindow)") OR match(Image, "(?i)(autoit3|autohotkey|winlister)\.exe")), 1, 0)
| eval is_net=if(EventCode=3 AND NOT match(DestinationIp, "^(10\.|172\.(1[6-9]|2[0-9]|3[01])\.|192\.168\.|127\.)"), 1, 0)
| stats sum(is_enum) as EnumEvents, sum(is_net) as NetEvents, values(DestinationIp) as ExtIPs, values(CommandLine) as CmdLines by host, ProcessId
| where EnumEvents > 0 AND NetEvents > 0
| sort - EnumEventsHunt for AutoHotkey or AutoIt execution from unexpected parent processes. Legitimate automation tools are typically launched interactively from explorer.exe or from development environments. When spawned by cmd.exe, wscript.exe, powershell.exe, or document-opened applications, it strongly suggests malware leveraging these tools for stealthy window enumeration without requiring native API knowledge.
DeviceProcessEvents
| where Timestamp > ago(7d)
| where FileName in~ ("autoit3.exe", "autohotkey.exe", "ahk2exe.exe")
| summarize Count=count(), UniqueScripts=dcount(ProcessCommandLine), Devices=dcount(DeviceName),
FirstSeen=min(Timestamp), LastSeen=max(Timestamp), SampleCmd=take_any(ProcessCommandLine)
by AccountName, InitiatingProcessFileName
| where InitiatingProcessFileName !in~ ("explorer.exe", "devenv.exe", "code.exe", "notepad++.exe", "sublime_text.exe")
| sort by Count descindex=wineventlog sourcetype="XmlWinEventLog:Microsoft-Windows-Sysmon/Operational" EventCode=1
(Image="*\\autoit3.exe" OR Image="*\\autohotkey.exe" OR Image="*\\ahk2exe.exe")
NOT (ParentImage="*\\explorer.exe" OR ParentImage="*\\devenv.exe" OR ParentImage="*\\code.exe" OR ParentImage="*\\notepad++.exe" OR ParentImage="*\\sublime_text.exe")
| stats count as Count, dc(CommandLine) as UniqueScripts, dc(host) as Devices, earliest(_time) as FirstSeen, latest(_time) as LastSeen, values(ParentImage) as ParentImages by User, Image
| sort - CountAtomic Red Team Tests
Uses PowerShell Add-Type to define a P/Invoke wrapper for user32.dll's GetForegroundWindow and GetWindowText functions, then retrieves the title of the currently active window. This simulates the technique used by PowerShell-based RATs and post-exploitation frameworks that use reflection or P/Invoke to enumerate windows without spawning additional processes.
Command
powershell.exe -NoProfile -Command "Add-Type -TypeDefinition 'using System; using System.Runtime.InteropServices; public class WinEnum { [DllImport(\"user32.dll\")] public static extern IntPtr GetForegroundWindow(); [DllImport(\"user32.dll\", CharSet=CharSet.Auto)] public static extern int GetWindowText(IntPtr hWnd, System.Text.StringBuilder s, int n); }'; $hwnd = [WinEnum]::GetForegroundWindow(); $sb = New-Object System.Text.StringBuilder 256; [WinEnum]::GetWindowText($hwnd, $sb, 256); Write-Output ('Active window: ' + $sb.ToString())"Expected Telemetry
Sysmon Event ID 1: Process Create with Image=powershell.exe, CommandLine containing 'Add-Type', 'DllImport', 'user32.dll', 'GetForegroundWindow', and 'GetWindowText'. PowerShell ScriptBlock Log Event ID 4104 in Microsoft-Windows-PowerShell/Operational will capture the full deobfuscated Add-Type code block including the user32.dll import declarations.
Expected Detection
KQL: DetectionVector='PowerShell P/Invoke Window API' — matches on Add-Type + DllImport + user32 + window/hwnd patterns. SPL: PInvokePattern=1, TotalScore >= 1.
Uses the COM Shell.Application object via PowerShell to enumerate all open Internet Explorer / Explorer windows, listing their location names and URLs. This approach requires no native API calls and operates entirely through COM automation, mimicking techniques used by DarkWatchman and similar fileless malware that leverage COM for reconnaissance.
Command
powershell.exe -NoProfile -Command "(New-Object -ComObject Shell.Application).Windows() | ForEach-Object { Write-Output ('Window: ' + $_.LocationName + ' | ' + $_.LocationURL) }"Expected Telemetry
Sysmon Event ID 1: Process Create with Image=powershell.exe, CommandLine containing 'Shell.Application' and 'Windows()'. PowerShell ScriptBlock Log Event ID 4104 with the full COM enumeration code. No network connection events expected as this is a local enumeration call.
Expected Detection
KQL: DetectionVector='COM Shell Window Enumeration' — matches on Shell.Application + Windows() pattern in PowerShell command line. SPL: COMShellEnum=1, TotalScore >= 1.
Defines a complete EnumWindows P/Invoke wrapper in PowerShell that iterates all visible top-level windows and collects their titles into a list. This is the PowerShell equivalent of the malicious window enumeration performed by njRAT, Attor, and InvisiMole — gathering a complete snapshot of open applications for exfiltration to C2 or local correlation with keylogger output.
Command
powershell.exe -NoProfile -Command "Add-Type @'
using System; using System.Runtime.InteropServices; using System.Text; using System.Collections.Generic;
public class AllWindows {
public delegate bool EnumWinProc(IntPtr hWnd, IntPtr lParam);
[DllImport(\"user32.dll\")] public static extern bool EnumWindows(EnumWinProc cb, IntPtr lp);
[DllImport(\"user32.dll\", CharSet=CharSet.Auto)] public static extern int GetWindowText(IntPtr h, StringBuilder s, int n);
[DllImport(\"user32.dll\")] public static extern bool IsWindowVisible(IntPtr h);
public static List<string> GetTitles() {
var t = new List<string>();
EnumWindows((h, l) => { if (IsWindowVisible(h)) { var sb = new StringBuilder(256); GetWindowText(h, sb, 256); if (sb.Length > 0) t.Add(sb.ToString()); } return true; }, IntPtr.Zero);
return t;
}
}
'@; [AllWindows]::GetTitles() | Select-Object -First 30 | ForEach-Object { Write-Output $_ }Expected Telemetry
Sysmon Event ID 1: Process Create with Image=powershell.exe, CommandLine containing 'Add-Type', 'EnumWindows', 'GetWindowText', 'IsWindowVisible', and 'user32.dll'. PowerShell ScriptBlock Log Event ID 4104 with the full multi-line Add-Type type definition including all three DllImport declarations and the callback delegate pattern.
Expected Detection
KQL: DetectionVector='PowerShell P/Invoke Window API' — matches on Add-Type + DllImport + user32 + Window/hwnd patterns including EnumWindows reference. SPL: ScriptWindowAPIEnum=1 (EnumWindows match) AND PInvokePattern=1, TotalScore >= 2. Multiple corroborating indicators increase alert confidence.
Uses cscript.exe with inline VBScript to enumerate open Shell windows using the Shell.Application COM object. This technique is used by commodity RATs and macro-based malware to enumerate windows without relying on compiled PE binaries. The output mimics the window title collection performed by NetTraveler and similar espionage malware.
Command
cscript.exe //nologo //e:vbscript "%TEMP%\df00tech_wintenum.vbs"Cleanup
del /f /q "%TEMP%\df00tech_wintenum.vbs" 2>nulExpected Telemetry
File creation event (Sysmon Event ID 11) for %TEMP%\df00tech_wintenum.vbs. Sysmon Event ID 1: Process Create with Image=cscript.exe, CommandLine containing '//e:vbscript' and the .vbs filename. The VBScript content (Shell.Application COM enumeration) will be visible in script file artifacts but not the cscript command line itself — emphasizing the need for script content logging where available.
Expected Detection
SPL: ScriptWindowAPIEnum or COMShellEnum matches may not fire on cscript.exe command line alone if the API calls are in the .vbs file content rather than command line arguments. This test highlights the detection gap for file-based VBScript — hunting queries over Sysmon EventCode=1 with cscript.exe + .vbs in temp paths is the compensating control. Consider file content scanning (Sysmon Event ID 11 + file read) as a supplementary detection layer.