ADLOG-003: Registro de módulos de PowerShell habilitado
- Plataforma
- Active Directory
- Categoría
- AD Logging & EDR Posture
- Severidad
- Medium
- Pilar de Zero Trust
- Visibility & Analytics (peso 1)
- Fixtures de referencia
- 3
- Cobertura de ramas
- Observada: los fixtures prueban los veredictos que ejercitan
- Procedencia
- baseline
Qué comprueba
El evento 4103 (registro de módulos de PowerShell) registra las invocaciones de cmdlets y parámetros de cualquier módulo configurado para el registro. Combínalo con el registro de bloques de script y tendrás una pila de telemetría de alta confianza para cualquier ataque basado en PowerShell. El parámetro lo entrega una plantilla administrativa en HKLM\SOFTWARE\Policies\Microsoft\Windows\PowerShell\ModuleLogging.
Por qué importa
PowerShell is the default execution surface for Windows administration and the default offensive surface for everything from initial access to lateral movement. Empire, PowerSploit, PowerView, Nishang, Invoke-Mimikatz, Rubeus wrappers, Bloodhound collectors, and the majority of public red-team tradecraft are PowerShell modules or are loaded as in-memory script blocks by a PowerShell host. Without Module Logging, the defender sees a process-create event for powershell.exe or pwsh.exe with a command line that is frequently obfuscated, base64-encoded, or simply -EncodedCommand <blob>, and nothing else. The actual cmdlets, parameters, and pipeline data are invisible. Module Logging is the control that translates that opaque process into a per-cmdlet record: Invoke-WebRequest with the URL, Get-ADUser with the LDAP filter, Add-ADGroupMember with the principal, New-PSSession with the target host, Invoke-Command with the script block, Set-ItemProperty with the registry path and value. For DFIR, this is the difference between "PowerShell was used during the incident" and a reconstructable timeline. Three abuse patterns demonstrate the gap. First, credential theft via Get-Credential, Export-Clixml, and ConvertFrom-SecureString: without 4103, the defender cannot see the file path the credential was written to. Second, AD enumeration via the ActiveDirectory module: Get-ADUser -Filter * -Properties * pulls every user attribute including msDS-KeyCredentialLink and userPassword in 30 seconds, and without Module Logging the defender sees only ldap_search counters on the DC, not which attributes were requested by which host. Third, defensive evasion: Set-MpPreference -DisableRealtimeMonitoring $true and Remove-Item on the Windows Defender exclusion list show up in 4103 with the parameter values, but show up nowhere else outside of Defender-specific telemetry. Module Logging also costs little: the event volume is high but compressible, and the Microsoft-Windows-PowerShell/Operational channel can be sized to gigabytes or forwarded via Windows Event Forwarding to a central collector with sub-minute latency. The control is recommended by Microsoft, CISA, NSA, and the CIS PowerShell benchmark, and is one leg of the "PowerShell logging triad" alongside Script Block Logging (4104) and Transcription. ADLOG-003 fails closed when any of the three is missing.
Ruta de ataque
1. Reconnaissance under the radar: with Module Logging disabled, an attacker who has landed a PowerShell foothold (phishing payload, supply-chain implant, web shell) runs Import-Module ActiveDirectory; Get-ADUser -Filter * -Properties memberOf,servicePrincipalName,userAccountControl. The DC logs the LDAP search counters, but no 4103 event records the cmdlet or its parameters on the attacker host. The defender sees a PowerShell process with a short command line and nothing else. 2. Credential harvest: Invoke-Mimikatz, Out-Minidump, or a custom Get-LsassDump wrapper runs as an in-memory script block. Without Module Logging, the parameter bindings (target process, output path) are invisible. With Script Block Logging alone the defender sees the script text, but if the attacker uses AMSI bypasses or splits the payload across pipelines, even 4104 is incomplete; 4103 captures the actual cmdlet invocations after AMSI is bypassed because logging is at the pipeline binding stage. 3. Lateral movement: New-PSSession -ComputerName DC01 -Credential $cred; Invoke-Command -Session $s -ScriptBlock { ... } executes remotely. Without 4103, the source host shows only a TCP connection to DC01 on 5985 or 5986 and a WinRM client log entry; the script block executed on DC01 is not recoverable without DC-side logging that is itself dependent on Module Logging being enabled on DC01. 4. Persistence and defense evasion: New-ScheduledTaskAction, Register-ScheduledTask, Set-Service, New-Service, Add-MpPreference -ExclusionPath, and Set-MpPreference -DisableRealtimeMonitoring all complete silently. The Defender event log records the exclusion change only if Defender-specific logging is on, and the scheduled task XML lives in C:\Windows\System32\Tasks but the cmdlet that wrote it is unknown. 5. Cleanup: Clear-EventLog -LogName Security; wevtutil cl Microsoft-Windows-PowerShell/Operational. With Module Logging disabled there is no 4103 event for the Clear-EventLog cmdlet itself; with it enabled and a centrally forwarded channel, the clear is recorded upstream before the local log dies. 6. Long-term tradecraft: a sophisticated actor enumerates the ModuleLogging registry key on every host they land on. If the value is 0 or unset, they proceed in PowerShell. If it is 1, they switch to a non-PowerShell loader (C# via Add-Type executed before logging activates, or a native binary) to avoid the 4103 trail. ADLOG-003 closes the easy path and forces the attacker into harder-to-stage tradecraft, which is the entire purpose of PowerShell logging.
Cómo lo evalúa Guerrilla
Guerrilla evaluates Module Logging at the registry, GPO, and channel layers. Registry layer: Get-ItemProperty -Path "HKLM:\SOFTWARE\Policies\Microsoft\Windows\PowerShell\ModuleLogging" -Name EnableModuleLogging and Get-Item -Path "HKLM:\SOFTWARE\Policies\Microsoft\Windows\PowerShell\ModuleLogging\ModuleNames" with .Property enumeration to read the module list. The 32-bit Wow6432Node mirror is read for drift detection. GPO layer: Get-GPO -All piped through Get-GPRegistryValue -Key "HKLM\SOFTWARE\Policies\Microsoft\Windows\PowerShell\ModuleLogging" identifies which GPOs author the value and at which scope they are linked, which lets the check distinguish a domain-wide enforced policy from a one-off OU exception or a hand-edited local registry. The full Get-GPOReport -ReportType Xml output is parsed for the matching <RegistrySettings> blocks under the Computer Configuration node, so the check can record the source GPO display name and DN. Channel layer: Get-WinEvent -ListLog Microsoft-Windows-PowerShell/Operational reads MaximumSizeInBytes, LogMode (Circular vs AutoBackup vs Retain), and IsEnabled, and Get-WinEvent -FilterHashtable @{ LogName="Microsoft-Windows-PowerShell/Operational"; Id=4103; StartTime=(Get-Date).AddDays(-1) } -MaxEvents 1 confirms 4103 events are actually arriving (a common failure mode is the policy is set but the channel itself has been disabled or its ACL has been rewritten to deny SYSTEM write). Domain-wide assessment: where the check is run against a forest, it iterates all domain controllers, all member servers tagged Tier 0 (Get-ADComputer -SearchBase OU=Tier0,... or by group membership), and a sample of workstations, then reports per-host status and the percentage of in-scope hosts with the control fully enabled. Output rows include HostName, EnableModuleLogging (0/1/Unset), ModuleNames (array), GpoSource, LinkScope, OperationalChannelEnabled, OperationalChannelSizeMB, LogMode, Last4103EventAge, ScriptBlockLoggingEnabled (cross-reference), TranscriptionEnabled (cross-reference), and a Notes field that enumerates failure reasons.
Valor recomendado
La directiva de grupo 'Activar el registro de módulos' está habilitada con al menos la lista de nombres de módulo '*'. Registro: EnableModuleLogging = 1.
Remediación
Configuración del equipo > Directivas > Plantillas administrativas > Componentes de Windows > Windows PowerShell > 'Activar el registro de módulos' = Habilitado. Añade '*' a la lista de nombres de módulo (registra todos los módulos) o específicamente Microsoft.PowerShell.* más los módulos que tu entorno utiliza para la administración.
Veredictos probados con fixtures
Cada veredicto de esta tabla está probado por un fixture de referencia en la suite de pruebas que valida el módulo. La tabla se deriva de la última ejecución en verde; no puede editarse a mano.
| Escenario | Veredicto esperado |
|---|---|
| clean | PASS |
| known-bad | WARN |
| throttled | Not Assessed |
Mapeos a marcos de referencia
- NIST SP 800-53
- AU-2, SI-4
- CIS AD Benchmark
- 9.2.2
- MITRE ATT&CK
- T1059.001