ADLOG-002: Registro de bloques de script de PowerShell habilitado
- Plataforma
- Active Directory
- Categoría
- AD Logging & EDR Posture
- Severidad
- High
- Pilar de Zero Trust
- Visibility & Analytics (peso 2)
- Fixtures de referencia
- 3
- Cobertura de ramas
- Observada: los fixtures prueban los veredictos que ejercitan
- Procedencia
- baseline
Qué comprueba
El evento 4104 (registro de bloques de script de PowerShell) es el evento de Windows más útil para investigar intrusiones modernas: captura el código PowerShell que realmente se ejecuta tras la desofuscación, incluido el código pasado mediante -EncodedCommand. Sin él, un investigador que analiza el despliegue de ransomware basado en PowerShell está a ciegas. El parámetro lo entrega una plantilla administrativa en HKLM\SOFTWARE\Policies\Microsoft\Windows\PowerShell\ScriptBlockLogging\EnableScriptBlockLogging.
Por qué importa
Event 4104 is what turns an opaque PowerShell process tree into readable evidence. When a payload is delivered as powershell.exe -nop -w hidden -enc <base64>, the only artifact visible to Sysmon event 1 or Security event 4688 is the encoded blob. Event 4104 logs the decoded script block, including every dot-sourced or downloaded fragment, after PowerShell has expanded it for execution. This is the layer at which Cobalt Strike beacons, Empire stagers, AD enumeration scripts, and ransomware deployment payloads become legible. When script block logging is off, three classes of attacker activity become invisible: 1. In-memory execution. IEX (New-Object Net.WebClient).DownloadString(...) never touches disk. Without 4104 there is no record of what was actually run. 2. Encoded commands. -EncodedCommand is the most common LOLBin pattern. Process creation events show the base64 but not the post-decode behavior. 3. AMSI-bypass and obfuscation chains. Tools like Invoke-Obfuscation produce commands that look benign in 4688 and reveal their true behavior only at the script block layer. DFIR teams treat 4104 as a baseline requirement. The DFIR Report, Mandiant M-Trends, and CISA advisories on Conti, BlackBasta, ALPHV, and Volt Typhoon all reference 4104 as the primary or sole source of post-compromise PowerShell evidence. A domain in which 4104 is disabled on endpoints (or only enabled on DCs) is a domain in which post-incident scoping is largely impossible.
Ruta de ataque
1. Initial access: the operator lands on an endpoint via phishing, exposed RDP, or a compromised service account. 2. Discovery: PowerView, ADRecon, SharpHound (PowerShell wrapper), or Get-DomainComputer is launched in-process. With 4104 disabled, only powershell.exe with no arguments (or with an -enc blob) is recorded; the attacker query (Get-DomainUser -SPN, Get-NetGroupMember "Domain Admins") is not. 3. Defense evasion: the operator confirms logging posture by querying HKLM:\SOFTWARE\Policies\Microsoft\Windows\PowerShell\ScriptBlockLogging\EnableScriptBlockLogging. If absent, no further action is needed; if present, the operator may attempt to terminate the EventLog service (T1562.002) or roll the log via Limit-EventLog -LogName Microsoft-Windows-PowerShell/Operational -MaximumSize 1024KB before staging follow-on activity. 4. Credential access: Invoke-Mimikatz, Out-Minidump, or Rubeus is loaded reflectively via IEX. With 4104 disabled these scripts execute and exit leaving no scriptblock artifact. 5. Lateral movement: Invoke-Command, Enter-PSSession, or WMI-based PowerShell invocation runs the next stage on remote hosts. WSMan/4104 on the target would normally capture the inbound script; if the target also lacks the policy, the lateral movement is invisible. 6. Impact: ransomware deployment scripts (Invoke-WebRequest pulling the loader, foreach loop over Get-ADComputer to disable AV and schedule the binary) execute with no scriptblock trail. Post-incident, the IR team can confirm files encrypted, but cannot reconstruct what the attacker ran, what was collected, or what other hosts were touched.
Cómo lo evalúa Guerrilla
Guerrilla queries the in-scope computer set via the parent cmdlet and, for each reachable host, reads the policy-applied registry values through the Remote Registry provider (or via WinRM Invoke-Command where Remote Registry is disabled). For each target the check evaluates: - HKLM\SOFTWARE\Policies\Microsoft\Windows\PowerShell\ScriptBlockLogging\EnableScriptBlockLogging (Windows PowerShell 5.1) - HKLM\SOFTWARE\Policies\Microsoft\PowerShellCore\ScriptBlockLogging\EnableScriptBlockLogging (PowerShell 7+) - Get-WinEvent -ListLog Microsoft-Windows-PowerShell/Operational to confirm MaximumSizeInBytes is sized for the host workload (recommended >= 1 GB on servers, >= 256 MB on workstations) and LogMode is Circular or AutoBackup with archival A host returns Pass only when the Windows PowerShell key is set to 1 and (if PowerShell 7 is installed) the PowerShellCore key is also set to 1. Findings include the hostname, OS version, both registry values observed, the channel size, and whether the policy is coming from a linked GPO (Resultant Set of Policy is consulted via Get-GPResultantSetOfPolicy where credentials permit). The check does not require AMSI, Sysmon, or any third-party agent: it relies only on the native registry and event log surface.
Valor recomendado
La directiva de grupo 'Activar el registro de bloques de script de PowerShell' está habilitada en el nivel de dominio o de la OU de controladores de dominio. Registro: EnableScriptBlockLogging = 1.
Remediación
Configuración del equipo > Directivas > Plantillas administrativas > Componentes de Windows > Windows PowerShell > 'Activar el registro de bloques de script de PowerShell' = Habilitado. Verifica tras gpupdate: Get-ItemProperty 'HKLM:\SOFTWARE\Policies\Microsoft\Windows\PowerShell\ScriptBlockLogging'. Asegúrate de que la capacidad del registro de eventos de 'Microsoft-Windows-PowerShell/Operational' esté dimensionada para el volumen (los 15 MB predeterminados rotarán en cuestión de horas bajo carga).
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 | FAIL |
| throttled | Not Assessed |
Mapeos a marcos de referencia
- NIST SP 800-53
- AU-2, SI-4
- CIS AD Benchmark
- 9.2.1
- MITRE ATT&CK
- T1059.001, T1562.002