ADLOG-007: Sysmon Deployment Indicator
- Platform
- Active Directory
- Category
- AD Logging & EDR Posture
- Severity
- Medium
- Zero Trust pillar
- Visibility & Analytics (weight 1)
- Golden fixtures
- 1
- Branch coverage
- Observed: fixtures prove the verdicts they exercise
- Provenance
- baseline
What it checks
The check performs a SYSVOL and GPO heuristic sweep looking for indirect evidence of a Sysmon deployment pipeline. It enumerates all GPOs in the domain and inspects each for: (1) a startup or computer scriptini that references Sysmon.exe, Sysmon64.exe, or a -i install switch (typically under \\<domain>\SYSVOL\<domain>\Policies\{GUID}\Machine\Scripts\Startup\scripts.ini and the backing .ps1, .cmd, or .bat files); (2) a Files or Registry preference under Computer Configuration\Preferences that copies a Sysmon binary or sets HKLM\SYSTEM\CurrentControlSet\Services\SysmonDrv or Sysmon64 values; (3) a Scheduled Tasks preference that invokes Sysmon; and (4) a Software Installation MSI assignment that matches a known Sysmon MSI wrapper. The check also reads the WEF (Windows Event Forwarding) subscription configuration from registry where reachable to see whether Microsoft-Windows-Sysmon/Operational is in any forwarded channel set. When no indirect evidence is found, the check WARNs rather than FAILs, because Sysmon is commonly deployed via SCCM, Intune, Tanium, or other configuration-management platforms that leave no GPO footprint. The operator is asked to validate against a sampled host with Get-CimInstance Win32_Service -Filter "Name='Sysmon64' OR Name='Sysmon'" or by reading the Microsoft-Windows-Sysmon/Operational log directly.
Why it matters
Native Windows auditing has well-known gaps that attackers rely on. Process creation events (4688) carry the command line only when Include command line in process creation events is enabled, do not include the image SHA256, and do not record parent process command line. Native logging records no per-process network connections at all (the closest equivalent is Windows Filtering Platform events 5156/5157, which are noisy and not attributed cleanly). DLL load events do not exist in the Security log. Registry auditing requires SACLs on every key of interest and produces low-fidelity 4657 events. Sysmon fills every one of these gaps: Event ID 1 for process creation with hash and parent context, Event ID 3 for network connections per process, Event ID 7 for image loads, Event ID 10 for process access (credential dumping primitive), Event ID 11 for file creation, Event ID 12/13/14 for registry, Event ID 17/18 for named pipes, Event ID 19/20/21 for WMI subscription, Event ID 22 for DNS queries, and Event ID 25 for process tampering. Without Sysmon (or an EDR that exposes equivalent kernel telemetry), the SOC is structurally blind to LSASS handle opens, process hollowing, named pipe lateral movement, and most living-off-the-land binaries. An attacker who lands on an unmonitored host can stage tooling, dump credentials, and pivot without generating actionable evidence. The presence of Sysmon is a baseline maturity signal; its absence on workstations and member servers is one of the highest-leverage gaps a defender can close.
Attack path
Sysmon is not a vulnerability and is not directly exploited. The attack path is the absence of telemetry that Sysmon would provide, which enables techniques to proceed undetected. A representative adversary sequence on an un-Sysmoned host: Step 1: Initial access. The attacker executes a payload via phishing macro, ISO+LNK, or HTML smuggling. Native 4688 records the parent process and image path but no hash and no parent command line. The SOC sees winword.exe launching powershell.exe but cannot reconstruct the powershell.exe command line without an additional source. Sysmon Event 1 would record the full command line, image SHA256, parent command line, integrity level, and the user logon GUID. Step 2: Credential access. The attacker opens a handle to LSASS to read memory (Mimikatz, nanodump, comsvcs.dll MiniDump). Native logging produces no event for OpenProcess against LSASS unless object access auditing is enabled on the System ACL of the LSASS process token, which it is not by default. Sysmon Event 10 with rule GrantedAccess 0x1010, 0x1410, or 0x1438 against lsass.exe is the canonical detection. Step 3: Lateral movement. The attacker uses SMB named pipes for PsExec or Impacket-style execution. Native logging records 4624 type 3 logons and 5145 share access events. Sysmon Event 17/18 records the actual pipe name and the process that created or connected to it, which differentiates PsExec from SMBExec from wmiexec. Step 4: Persistence. The attacker installs a WMI event subscription (ActiveScriptEventConsumer or CommandLineEventConsumer). Native logging is silent. Sysmon Event 19/20/21 records the subscription creation with full filter and consumer text. Step 5: Defense evasion. On a host where Sysmon is deployed, the attacker may attempt to disable the service or unload the driver via fltMC unload SysmonDrv or sc stop. This corresponds to T1562.001. ADLOG-007 only catches the deployment indicator; companion checks (and the EDR) should catch the unload.
How Guerrilla assesses it
Guerrilla enumerates GPOs via the GroupPolicy module (Get-GPO -All) and downloads the SYSVOL contents for each. For every GPO it parses Machine\Scripts\scripts.ini and grep-scans the referenced script files for the literal strings Sysmon.exe, Sysmon64.exe, SysmonDrv, sysmon -i, sysmon -accepteula, and known config repository URLs (raw.githubusercontent.com/SwiftOnSecurity, github.com/olafhartong/sysmon-modular). It parses Preferences XML for Files (sysmon*.exe in copy operations), Registry (HKLM\SYSTEM\CurrentControlSet\Services\SysmonDrv or Sysmon64), and Scheduled Tasks (action invokes a Sysmon binary). It also reads SoftwareInstallation.xml for MSI packages whose ProductName contains Sysmon. If any signal is found, the check returns INFO with the GPO name and the matching artifact path. If no signal is found, the check returns WARN with text instructing the operator to validate at the host layer: Get-CimInstance -ClassName Win32_Service -Filter "Name='Sysmon64' OR Name='Sysmon'" -ComputerName <sample host>, or Get-WinEvent -LogName Microsoft-Windows-Sysmon/Operational -MaxEvents 1. The WARN level is intentional because the absence of a GPO signal does not prove the absence of Sysmon (config-management platforms are common and leave no GPO trace).
Recommended value
Sysmon is installed on workstations and servers via a deployment GPO or configuration-management push, with a configuration tuned to the environment (SwiftOnSecurity, Olaf Hartong, or vendor-provided baselines).
Remediation
Deploy Sysmon (https://download.sysinternals.com/files/Sysmon.zip) via GPO startup script or your config-management platform. Use a community baseline as starting point (SwiftOnSecurity/sysmon-config or Olaf Hartong/sysmon-modular). Verify deployment via Get-CimInstance Win32_Service -Filter "Name='Sysmon64'" against a representative host set, or query the WEF collector for 'Microsoft-Windows-Sysmon/Operational' events.
Fixture-proven verdicts
Every verdict below is proven by a golden fixture in the module's gating test suite. This table derives from the last green run; it cannot be edited by hand.
| Scenario | Expected verdict |
|---|---|
| always-warn | WARN |
Framework mappings
- NIST SP 800-53
- AU-2, SI-4
- CIS AD Benchmark
- 9.4.2
- MITRE ATT&CK
- T1562.001