T1010

Application Window Discovery

Discovery Last updated:

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.

What is T1010 Application Window Discovery?

Application Window Discovery (T1010) maps to the Discovery tactic — the adversary is trying to figure out your environment in MITRE ATT&CK.

This page provides production-ready detection logic for Application Window Discovery, covering the data sources and telemetry it touches: Process: Process Creation, Command: Command Execution, Microsoft Defender for Endpoint. The queries below are rated medium severity at medium confidence, and ship for 7 SIEM platforms — KQL, SPL, Elastic, QRadar, Sumo, YARA-L, LogScale.

MITRE ATT&CK

Tactic
Discovery
Technique
T1010 Application Window Discovery
Canonical reference
https://attack.mitre.org/techniques/T1010/
Microsoft Sentinel / Defender
kusto 
let WindowAPIFunctions = dynamic([
    "GetForegroundWindow", "EnumWindows", "FindWindow", "GetWindowText",
    "GetActiveWindow", "EnumChildWindows", "GetWindowLong", "GetWindowRect",
    "FindWindowEx", "GetWindowInfo"
]);
// Vector 1: Script interpreters referencing window enumeration API functions
let ScriptInterpreterEnum = DeviceProcessEvents
| where Timestamp > ago(24h)
| where FileName in~ ("powershell.exe", "pwsh.exe", "wscript.exe", "cscript.exe", "mshta.exe", "python.exe", "python3.exe", "ruby.exe", "perl.exe")
| where ProcessCommandLine has_any (WindowAPIFunctions)
    or (ProcessCommandLine has_any ("Add-Type", "DllImport") and ProcessCommandLine has "user32" and ProcessCommandLine has_any ("window", "Window", "hwnd", "hWnd"))
    or (ProcessCommandLine has "Shell.Application" and ProcessCommandLine has_any ("Windows()", ".Windows "))
| extend DetectionVector = case(
    ProcessCommandLine has_any ("Add-Type", "DllImport") and ProcessCommandLine has "user32", "PowerShell P/Invoke Window API",
    ProcessCommandLine has "Shell.Application", "COM Shell Window Enumeration",
    "Script Window Enumeration API"
);
// Vector 2: Automation tools spawned from unexpected parents (not UI or development environments)
let AutomationToolEnum = DeviceProcessEvents
| where Timestamp > ago(24h)
| where FileName in~ ("autoit3.exe", "autohotkey.exe", "ahk2exe.exe", "autoit3_x64.exe")
| where InitiatingProcessFileName !in~ ("explorer.exe", "devenv.exe", "code.exe", "notepad++.exe", "sublime_text.exe", "atom.exe", "cursor.exe")
| extend DetectionVector = "Automation Tool Window Enumeration (Unusual Parent)";
// Vector 3: Known third-party window enumeration utilities
let KnownToolEnum = DeviceProcessEvents
| where Timestamp > ago(24h)
| where FileName in~ ("winlister.exe", "wintitles.exe", "windowdetective.exe", "spyxx.exe", "spyxx_amd64.exe", "winspector.exe")
| extend DetectionVector = "Known Window Enumeration Utility";
union ScriptInterpreterEnum, AutomationToolEnum, KnownToolEnum
| project Timestamp, DeviceName, AccountName, FileName, ProcessCommandLine,
         InitiatingProcessFileName, InitiatingProcessCommandLine, DetectionVector
| sort by Timestamp desc

Detects application window discovery activity via three vectors: (1) script interpreters (PowerShell, WScript, Python) referencing Windows API functions such as EnumWindows, GetForegroundWindow, GetWindowText, or using PowerShell P/Invoke patterns loading user32.dll window APIs; (2) automation tools (AutoHotkey, AutoIt) spawned from non-development parent processes, which are commonly leveraged by malware families like Grandoreiro for window-based security tool detection; (3) known third-party window enumeration utilities (WinLister, Window Detective, Spy++). Detection confidence is medium — script-based patterns are reliably visible in command-line telemetry, but native compiled malware performing in-process API calls will not be caught without image load or process access telemetry.

medium severity medium confidence

Data Sources

Process: Process Creation Command: Command Execution Microsoft Defender for Endpoint

Required Tables

DeviceProcessEvents

False Positives

  • Legitimate AutoHotkey or AutoIt scripts used by IT support staff for desktop automation and helpdesk tooling
  • Screen recording, remote desktop, and accessibility software (e.g., NVDA, JAWS, TeamViewer) that enumerates windows for UI interaction
  • Developer tooling such as UI testing frameworks (Selenium WebDriver for Windows, WinAppDriver, TestComplete) that programmatically enumerate windows
  • Python automation scripts for legitimate RPA (Robotic Process Automation) deployments using pywin32 or pywinauto
  • PowerShell DSC configurations or inventory scripts that query Shell.Application window state

Sigma rule & cross-platform mapping

The detection logic for Application Window Discovery (T1010) above is provided in a vendor-neutral form so you can deploy it on any SIEM. The same logic is shipped here as native KQL (Microsoft Sentinel / Defender), SPL (Splunk), Elastic (Elastic Security (EQL)), QRadar (IBM QRadar (AQL)), Sumo (Sumo Logic CSE), YARA-L (Google Chronicle / SecOps), LogScale (CrowdStrike LogScale (CQL)) queries. In Sigma terms, this detection targets the following logsource: 

logsource:
  category: process_creation
  product: windows

Browse the community-maintained Sigma rules for this technique:

SigmaHQ rules for T1010 Sigma rules on detection.fyi

Platform-specific guides for T1010

Detect in Microsoft Sentinel (KQL) Detect in Splunk (SPL) Detect in Elastic Security (Elastic) Detect in IBM QRadar (QRadar) Detect in Sumo Logic CSE (Sumo) Detect in Google Chronicle (YARA-L) Detect in CrowdStrike LogScale (LogScale)
Last updated: 2026-04-13 Research depth: deep
References (8)

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.

  1. Test 1PowerShell 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.

  2. Test 2PowerShell 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.

  3. Test 3PowerShell 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.

  4. Test 4VBScript 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.

Response Playbook

Triage

  1. 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.
  2. 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.
  3. 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).
  4. 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.
  5. 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.
  6. 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

  1. If the enumerating process is unknown or unsigned: terminate the process via EDR remote response and quarantine the originating file for analysis.
  2. 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.
  3. 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.
  4. 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.
  5. 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

  1. 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
  2. Sysmon Event ID 1 (Process Create) — command line arguments, parent process, user context, and process hash for the enumerating process
  3. 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
  4. Sysmon Event ID 11 (File Create) — if the process wrote window title output to disk (common in keylogger+window-context malware like DarkWatchman)
  5. 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
  6. Prefetch files (C:\Windows\Prefetch\) — execution timestamps for autoit3.exe, autohotkey.exe, winlister.exe, or any suspicious executable
  7. PowerShell command history ($env:APPDATA\Microsoft\Windows\PowerShell\PSReadLine\ConsoleHost_history.txt) — if an interactive session was used
  8. 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

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.

Hunting — KQL
kql 
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 desc
Hunting — SPL
spl 
index=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 - Count

Correlate 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.

Hunting — KQL
kql 
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 desc
Hunting — SPL
spl 
index=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 - EnumEvents

Hunt 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.

Hunting — KQL
kql 
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 desc
Hunting — SPL
spl 
index=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 - Count

Atomic Red Team Tests

Test 1 PowerShell P/Invoke Window Enumeration via GetForegroundWindow
windows

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 
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.

Test 2 PowerShell COM Shell.Application Window Enumeration
windows

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 
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.

Test 3 PowerShell Full Window Enumeration via EnumWindows Callback
windows

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 
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.

Test 4 VBScript COM Window Enumeration via Shell.Application
windows

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

powershell 
cscript.exe //nologo //e:vbscript "%TEMP%\df00tech_wintenum.vbs"

Cleanup

powershell 
del /f /q "%TEMP%\df00tech_wintenum.vbs" 2>nul

Expected 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.

Related Detections

Tactic Hub

TA0007Discovery

Related Techniques

T1056.001KeyloggingT1113Screen CaptureT1518.001Security Software DiscoveryT1106Native APIT1059.001PowerShellT1059.005Visual BasicT1059.007JavaScriptT1497.001System ChecksT1057Process DiscoveryT1005Data from Local System

Same Tactic: Discovery

Popular Detections