SOC Investigation Workbook Series - Volume 5

Investigating Malware Alerts Like a SOC Analyst

Un libro de trabajo de campo para trabajar una alerta de malware de EDR desde el primer triage hasta el cierre del ticket. Escrito por un gerente de ingeniería de ciberseguridad que revisa estás investigaciones por trabajo.

Dentro: cómo leer una detonación, la pregunta de blocked vs ran que lo decide todo, ejemplos reales de alertas de EDR, un flujo de trabajo de investigación paso a paso, un paquete de queries listo para ejecutar, ejercicios de escenario, un recorrido completo y páginas de notas del analista para completar.

Jbird | jbirdcyber.gumroad.com

---

¿Qué hay en este libro de trabajo?

• Sección 1: Descripción general del ataque - Qué significa una alerta de malware de EDR
• Sección 2: La alerta llega - Ejemplo de alerta, veredicto e indicadores
• Sección 3: El flujo de trabajo de la investigación - Blocked or Ran?
• Sección 4: Recopilación de evidencia - Hashes, Sandbox, Árbol de procesos
• Sección 5: Tomando la decisión - True Positive, FP, o PUA
• Sección 6: Recorrido completo de la investigación - Un stealer en la naturaleza
• Sección 7: Notas del analista - Tus páginas de investigación para completar
• Sección 8: Referencia rápida - La versión de una sola página
• Bonus: Cómo aparecen las alertas de malware en tu entrevista

CÓMO USAR ESTE LIBRO DE TRABAJO: 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 malware. La alerta de malware es la alerta de mayor volumen que la mayoría de los SOC manejan, y la que los analistas más suelen cerrar mal en ambas direcciones: tratando un archivo de prueba en cuarentena como un incendio de cinco alarmas, o pasando por alto una infección real porque el EDR dijo remediated. La estructura aquí te mantiene fuera de ambos problemas.

Una palabra antes de empezar

Me siento del lado de la contratación para roles de SOC e ingeniería. Las alertas de malware son donde descubro si un candidato entiende lo que su EDR realmente hizo. Detected no significa contenido, y quarantined no significa necesariamente limpio. Los analistas que pueden leer una alerta y decirme precisamente qué se ejecutó, qué se bloqueó y qué aún necesita ser revisado son los que no se queman por la alerta que dijo handled pero no lo estaba. Esa habilidad de lectura es todo el trabajo aquí.

Para quién es esto

• Aspirantes y analistas junior de SOC que viven en la cola de malware y quieren dejar de adivinar qué hizo el EDR.
• Personal de help desk y sysadmins pivotando hacía la seguridad, que ya lidian con máquinas infectadas y quieren la parte de la investigación.
• Estudiantes de ciberseguridad e internos que conocen las categorías de malware pero nunca han leído un reporte de detonación real.
• Cualquier persona con una entrevista de SOC en el calendario. La sección bonus al final está construida para ti.

Los ejemplos se inclinan hacía Microsoft Defender for Endpoint porque es donde la mayoría de ustedes trabajarán estás alertas, y el razonamiento se transfiere a CrowdStrike, SentinelOne o cualquier EDR.

---

Sección 1 - Descripción general del ataque

Lo que una alerta de malware de EDR realmente te dice

Buenas tardes, amigos. Cuando tu EDR dispara una alerta de malware, te está diciendo que vio algo que cree que es malicioso en un endpoint. Lo que NO te está diciendo automáticamente es la única cosa que más necesitas saber: ¿ese algo realmente se ejecutó, o el EDR lo detuvo primero?

Todo sobre cómo trabajas la alerta fluye de esa distinción única, y es la distinción que los analistas nuevos omiten más rápido.

• Una detection es una observación.
• Un block es una acción.

Una alerta puede significar que el archivo fue puesto en cuarentena antes de que se ejecutara (bueno, baja urgencia), o puede significar que el EDR notó un comportamiento malicioso de un proceso que ya estaba ejecutándose (malo, el host está comprometido y ahora estás en incident response). Misma cola de alertas, investigaciones radicalmente diferentes.

Leer los campos de verdict y action correctamente es el paso uno, siempre.

Las categorías de malware que realmente verás

No necesitas la profundidad de un analista de malware, pero necesitas saber qué busca cada familia, porque la categoría te dice qué revisar después:

• Infostealer. Recolecta contraseñas guardadas, cookies del navegador, tokens de sesión, wallets de cripto y los envía rápido. Las familias Lumma, RedLine y Vidar dominan. Si un stealer se ejecutó, tu incidente no es realmente sobre el archivo, es sobre cada credencial y sesión que estaba en esa máquina. Este es el puente directo de regreso a los Volúmenes 1 y 2.
• Loader / dropper. Un pequeño primer paso cuyo único trabajo es descargar y ejecutar un segundo paso más grande. El archivo que capturaste es la puerta, no la amenaza. Tienes que encontrar qué cargó.
• Remote access trojan (RAT). Da al atacante control de manos en el teclado del host: acceso a archivos, ejecución de comandos, captura de pantalla. Un RAT en ejecución significa que un humano puede estar activo en la máquina.
• Ransomware. Encripta archivos para extorsión, generalmente la etapa final después del acceso, robo y propagación. El Volumen 10 cubre esto de extremo a extremo; aquí solo necesitas reconocer las señales tempranas.
• Coin miner. Roba capacidad de cómputo para minar criptomonedas. Severidad más baja, pero su presencia significa que algo entró, así que nunca lo limpies y sigas adelante sin preguntar cómo llegó.
• PUA / PUP. Potentially unwanted applications: adware, barras de herramientas empaquetadas, limpiadores agresivos. A menudo son detecciones reales de algo verdaderamente molesto pero no un ataque. Saber que está categoría existe evita que declares una brecha por una extensión de navegador.

Cómo llega el malware al endpoint

• Archivos adjuntos y enlaces de Phishing. El documento con macros del Volumen 4, una factura falsa, un zip protegido con contraseña. Sigue siendo la ruta de entrega número uno.
• Software falso y cracks. Aplicaciones piratas, instaladores falsos, malvertising que sirve una descarga trojanizada cuando un usuario busca software legítimo.
• Actualizaciones falsas y CAPTCHAs falsos. El cebo que engaña a un usuario para que ejecute el malware por sí mismo, a menudo pegando un comando (el patrón ClickFix que conecta con el Volumen 4).
• Medios removibles y cadena de suministro. Drops de USB y actualizaciones de software legítimo comprometidas. Más raras, pero de alto impacto cuando aterrizan.

NOTA DEL GERENTE DE CONTRATACIÓN: La única pregunta que uso para separar a los analistas de malware fuertes de los débiles es simple: ¿se ejecutó o fue bloqueado, y cómo lo sabes? Un candidato que lee los campos de action y verdict, revisa el árbol de procesos para la ejecución y solo entonces asigna urgencia, está pensando correctamente. Un candidato que entra en pánico con la palabra trojan o se relaja con la palabra quarantined sin verificar lo que se ejecutó, va a terminar mal, y también lo hará la organización que lo contrate. Esa habilidad de lectura es todo el trabajo aquí.

Dónde se sitúa esto en MITRE ATT&CK

Fase que observas	Technique ID	Cómo llegó
Phishing, User Execution, Malvertising	T1566, T1204, T1583.008	Ruta de entrega inicial
El archivo malicioso ejecutándose	T1106, T1204.002	Native API / Malicious File execution
Loader extrayendo un segundo stage	T1105	Ingress Tool Transfer
Infostealer en acción	T1555, T1539	Credentials from Password Stores, Steal Web Session Cookie
Manteniéndose residente	T1547, T1053	Boot or Logon Autostart, Scheduled Task
Llamando a casa	T1071	Application Layer Protocol (C2)

Forma real de la alerta

Un patrón que he trabajado personalmente: un usuario buscó una herramienta gratuita de PDF, hizo clic en un resultado de malvertising y ejecutó un instalador que era un stealer.

El EDR alertó con quarantined en el campo de action, lo que el primer analista leyó como caso cerrado. Pero el verdict y el árbol de procesos contaron una historia diferente: el proceso del stealer se había ejecutado y corrido durante noventa segundos antes de que el EDR lo matara y pusiera en cuarentena, y en esa ventana ya había leído los stores de credenciales del navegador y hecho una conexión de salida.

Quarantined el archivo, sí. Detuvo el robo, no. El incidente real era el reset de contraseñas y sesiones para ese usuario, que el cierre apresurado habría omitido por completo. Blocked versus ran, y el espacio entre ellos, es todo el juego.

---

Sección 2 - La alerta llega

Lo que realmente ves en la cola

A continuación se muestra una alerta representativa en el formato que produce Microsoft Defender for Endpoint. La cosmética del proveedor varía, los campos no.

ALERT: 'Lumma' malware was detected
Severity: High
Category: Malware
Device: SALES-LT-0144
User: r.patel
Detection: Trojan:Win32/LummaStealer.A
Detection source: Antivirus
Detection method: Behavior
File: SetupPdf.exe
SHA256: 9f2c...e71a
Path: C:\Users\r.patel\Downloads\SetupPdf.exe
Action: Quarantined
Remediation status: Remediated
Process: SetupPdf.exe PID 7720 (executed)
Parent: chrome.exe

Los cuatro campos que deciden tu investigación

Antes que nada, lee estos cuatro campos en este orden. Te dicen casi todo sobre qué tan urgente es esto:

• Action - lo que hizo el EDR. Blocked o Prevented (detenido antes de la ejecución, menor urgencia) vs Quarantined o Remediated DESPUÉS de que el proceso ya corrió (el archivo se movió, pero puede haber cumplido su función primero). Quarantined no significa que nunca se ejecutó.
• Detection method - cómo lo detectó. Un match de firma o hash en un archivo en reposo a menudo significa que fue capturado al escribir, antes de la ejecución. Una detección de Behavior o EDR suele significar que la cosa estaba haciendo algo, lo que significa que estaba ejecutándose.
• Process and execution state - ¿hay un PID y el timeline muestra que el proceso realmente se ejecutó, generó hijos o tocó la red? Un archivo sentado en Downloads que fue puesto en cuarentena al descargar es muy diferente de un proceso que corrió durante noventa segundos.
• Parent process - la lección del Volumen 4 aplica: chrome.exe como padre apunta a una descarga web o malvertising, una app de Office apunta a phishing, explorer apunta a un usuario haciendo doble clic. El linaje te dice la ruta de entrega.

Leyendo esta alerta específica

Está es la trampa de la Sección 1. El campo de action dice Quarantined y Remediated, lo que parece tranquilizador. Pero:

• La línea de proceso dice executed con un PID
• El método de detección es Behavior (lo capturó haciendo algo, no sentado quieto)
• La familia es un stealer

El EDR puso el archivo en cuarentena, pero solo después de que corrió lo suficiente para ser detectado por comportamiento. Eso significa que debes asumir el robo de credenciales y sesiones hasta que el timeline demuestre lo contrario. El campo de action tranquilizador es exactamente lo que hace que está alerta se cierre mal.

PATRÓN A MEMORIZAR: Quarantined te dice dónde está el archivo ahora. No te dice si se ejecutó primero. Una detección de comportamiento que puso en cuarentena un proceso de stealer ejecutado significa que el archivo se fue Y las credenciales probablemente fueron robadas. Siempre reconcilia el campo de action contra el estado de ejecución antes de asignar la urgencia.

La misma alerta en una tienda de CrowdStrike

Consola diferente, mismas preguntas. CrowdStrike presenta la detección con un pattern disposition y un árbol de procesos frente a ti:

Detection: LummaStealer via Falcon
Severity: High
Tactic: Credential Access
Technique: T1555
Pattern disposition: ...   (prevented vs detected matters)
SHA256: 9f2c...e71a
Filename: SetupPdf.exe
Process tree: chrome.exe > SetupPdf.exe > (children)
Action taken: Process killed / Quarantine on write

Sea cual sea la consola, estás respondiendo las mismas tres preguntas: ¿se ejecutó, qué hizo mientras se ejecutó y qué detuvo realmente el EDR? Los nombres de los campos cambian, la investigación no.

---

Sección 3 - El flujo de trabajo de la investigación

Cinco fases, en orden. La pregunta definitoria de este volumen se encuentra justo al frente: ¿fue bloqueado, o se ejecutó? Tu camino completo se bifurca según la respuesta.

Fase 1 - Triage y la pregunta de Blocked-or-Ran (primeros 10 minutos)

• Lee la acción y el estado de ejecución juntos. ¿Bloqueado antes de la ejecución y ningún proceso corrió? Esto es probablemente un cleanup de baja urgencia: confirma, documenta y revisa cómo llegó. ¿Proceso ejecutado, independientemente de la acción de cuarentena? Estás en incident response, procede como si hubiera cumplido su función.
• Identifica la familia de malware y su objetivo. Stealer, loader, RAT, ransomware, miner, PUA. La familia te dice qué revisar después: un stealer significa credenciales, un loader significa encontrar el segundo stage, un RAT significa asumir un humano activo.
• Haz el hash del archivo y enri quécelo. Toma el SHA256 a tu threat intel y a un servicio de reputación multi-motor. Un hash conocido como malo colapsa la pregunta de “qué es” instantáneamente.
• Lee el linaje. El proceso padre te dice la ruta de entrega y si fue ejecución por el usuario, entregado por navegador o provocado por phishing.

Fase 2 - Validación (¿amenaza real, FP, o PUA?)

• Confirma que la detección no es un falso positivo. Herramientas internas, software de seguridad, binarios de red team y scripts de admin se marcan. Un hash con reputación limpia en todas partes excepto en tu EDR, en una ruta que coincide con software interno conocido, apunta hacía un FP.
• Distingue PUA de malware. El adware y la basura empaquetada son detecciones reales pero no ataques. La reputación, el comportamiento del archivo y el campo de categoría suelen resolverlo. No declares una brecha por una barra de herramientas. Y no ignores un stealer porque comparte la cola con las barras de herramientas.
• Para cualquier cosa que se ejecutó, detona el hash en un sandbox o extrae un reporte existente. La detonación te dice las capacidades: qué lee, escribe, deja caer y conecta. No estás haciendo ingeniería inversa, estás leyendo el resumen de comportamiento.
• Confirma el contexto del usuario fuera de banda: ¿descargó y ejecutó una herramienta de PDF? Las estafas de soporte técnico y los cebos ClickFix hacen que los usuarios ejecuten malware por sí mismos, y el relato del usuario sobre lo que pasó a menudo te entrega la ruta de entrega.

DETONA EL HASH, NO EL ARCHIVO VIVO: Envía el SHA256 a tu sandbox o busca un reporte existente. No ejecutes la muestra en tu propia máquina ni en la del usuario para ver qué hace, del mismo modo que no ejecutaste el PowerShell en el Volumen 4. El sandbox existe precisamente para que puedas leer el comportamiento sin convertirte en la próxima víctima.

Fase 3 - Scoping (el archivo nunca es la historia completa)

• Construye el árbol de procesos. ¿Qué generó el malware y qué generó el malware antes de que el EDR lo detuviera? Los hijos que corrieron son parte del incidente incluso si el padre fue puesto en cuarentena.
• Para un stealer: asume el robo de credenciales y sesiones. Cada contraseña guardada en el navegador, cada cookie de sesión, cada token en esa máquina está potencialmente perdido. Este es tu traspaso a la respuesta de identidad en los Volúmenes 1 y 2: reset y revocación.
• Para un loader: encuentra el segundo stage. ¿Qué descargó y ejecutó? Obtén la URL y el payload en tu sandbox y trata las capacidades del segundo stage como presentes en el host.
• Revisa la persistencia. Tareas programadas, run keys, servicios, entradas de carpeta de inicio, y cuentas nuevas creadas alrededor del tiempo de detección. Un archivo en cuarentena que ya instaló persistencia deja la puerta abierta después de que el archivo desaparezca.
• Caza el hash y los indicadores en toda la flota. Busca en cada endpoint el mismo SHA256, los dominios C2 y la URL de entrega. Una máquina es un incidente. Varias son una campaña, y las otras pueden no haber alertado.
• Revisa la red. ¿El host hizo beaconing o exfiltración antes de la contención? Las conexiones de salida desde el proceso del malware son tanto evidencia de scoping como indicadores para bloquear.

Fase 4 - Escalación

Escala cuando el malware se ejecutó, cuando es un stealer o RAT o precursor de ransomware, cuando se ejecutó un segundo stage, cuando se estableció persistencia, o cuando el scoping muestra más de un host.

Entrega a IR un paquete, no un número de ticket: la familia y su objetivo, el hash con reputación, el resumen de comportamiento del sandbox, el árbol de procesos, el timeline del host de lo que corrió y lo que tocó, las credenciales o sesiones expuestas, y las acciones que ya tomaste con marcas de tiempo. La Sección 7 produce exactamente ese paquete.

Indica claramente si el EDR realmente remedió o simplemente puso en cuarentena después de la ejecución, porque esa única frase le dice al siguiente respondedor si esto es limpieza o IR activo.

Fase 5 - Consideraciones de Contención

• Aísla el host si se confirma la ejecución, especialmente para un RAT o cualquier cosa con beaconing. Un clic en la mayoría de las plataformas de EDR, preservando la conexión de investigación.
• Preserva antes de limpiar: árbol de procesos, artefactos dejados caer, memoria si es soportada, y la muestra para Análisis, antes de que la remediación borre todo.
• Confía en la remediación del EDR, pero verifícala. Confirma que la cuarentena se mantuvo, el proceso está muerto, la persistencia se fue y ningún hijo sobrevivió. Remediated es una afirmación que verificas, no un hecho que aceptas.
• Para un stealer: resetea las contraseñas del usuario y revoca todas las sesiones, tratando cada secreto en el host como comprometido. Este es el paso más comúnmente omitido y el más dañino de saltarse.
• Bloquea los indicadores (hash, dominios C2 e IPs, URL de entrega) en EDR, proxy y firewall, luego húntalos en toda la flota.
• Reimagea cuando un RAT o un compromiso profundo hagan que el estado limpio sea impronunciable. Para un archivo limpiamente bloqueado que nunca se ejecutó, reimagear es excesivo; documenta por qué y sigue adelante.

LAS DOS MANERAS DE CERRAR ESTO MAL: Reaccionar de más (aislar y reimagear una máquina por un PUA en cuarentena que nunca se ejecutó) quema confianza y tiempo. Reaccionar de menos (cerrar un stealer detectado por comportamiento porque la acción dijo quarantined, sin resetear las credenciales) deja el robo real sin resolver. La calibración es la habilidad, y proviene de la pregunta de Blocked-or-Ran.

---

El Paquete de Queries - Búsquedas que hacen el trabajo

Escritos en KQL para Microsoft Defender for Endpoint advanced hunting, porque es ahí donde la mayoría de ustedes trabajarán estás alertas. La lógica se traduce a cualquier lenguaje de caza de cualquier EDR: mismas preguntas, diferente sintaxis.

1. Confirmar ejecución y extraer la actividad del archivo

DeviceProcessEvents
| where Timestamp > ago(7d)
| where SHA256 == "9f2c...e71a"
       or FileName =~ "SetupPdf.exe"
| project Timestamp, DeviceName, AccountName,
          InitiatingProcessFileName, FileName, ProcessId, ProcessCommandLine
| sort by Timestamp asc

2. Construir el árbol de procesos alrededor de la detección

DeviceProcessEvents
| where DeviceName == "SALES-LT-0144"
| where Timestamp between (datetime(2026-06-10 16:00) .. datetime(2026-06-10 17:00))
| project Timestamp, InitiatingProcessFileName,
          InitiatingProcessId, FileName, ProcessId, ProcessCommandLine
| sort by Timestamp asc

3. ¿Tocó el stealer los stores de credenciales o la red?

union DeviceFileEvents, DeviceNetworkEvents
| where Timestamp > ago(7d)
| where InitiatingProcessFileName =~ "SetupPdf.exe"
| project Timestamp, DeviceName, ActionType, FolderPath,
          RemoteUrl, RemoteIP, RemotePort
| sort by Timestamp asc

4. Cazar el hash y los indicadores en toda la flota

DeviceFileEvents
| where Timestamp > ago(30d)
| where SHA256 == "9f2c...e71a"
| summarize FirstSeen=min(Timestamp), LastSeen=max(Timestamp),
            Devices=make_set(DeviceName) by SHA256
| extend HostCount = array_length(Devices)

5. Revisar si se creó persistencia cerca de la detección

DeviceRegistryEvents
| where Timestamp between (datetime(2026-06-10 16:00) .. datetime(2026-06-10 17:30))
| where DeviceName == "SALES-LT-0144"
| where RegistryKey has_any ("CurrentVersion\\Run", "RunOnce","Services")
| project Timestamp, RegistryKey, RegistryValueName,
          RegistryValueData, InitiatingProcessFileName

Del uno al cinco confirman la ejecución, construyen el linaje, revelan lo que el malware realmente hizo, miden la propagación y capturan la persistencia que el EDR pudo haber dejado atrás. Esa es una investigación de malware defendible en cinco queries.

---

Sección 4 - Recopilación de evidencia

Dónde vive la evidencia

Source	Qué te da	Typical platform
EDR alert detail	Acción, detection method, verdict, execution state, los cuatro campos clave	Defender, CrowdStrike, SentinelOne
Process events	Si se ejecutó, el árbol de procesos completo, las líneas de comandos	EDR process telemetry
File events	Qué leyó, escribió o dejó caer el malware, los stores de credenciales importan	EDR file telemetry
Network events	La descarga, la llamada C2, cualquier exfiltración antes de la contención	EDR network telemetry, proxy, firewall
Registry / autoruns	Persistencia: run keys, servicios, tareas programadas, entradas de inicio	EDR registry telemetry, autoruns
Sandbox / TI	Resumen de comportamiento y reputación del hash, sin ejecutar la muestra tú mismo	Detonation sandbox, multi-engine reputation, TI platform
The user	Cómo llegó: descarga, adjunto, comando pegado, USB	Contacto fuera de banda

El Hash y el Sandbox - Leyendo una detonación

El SHA256 es la pieza de evidencia más portable en una investigación de malware. Te identifica el archivo exacto en todas partes. Aquí te muestro cómo convertir un hash en un veredicto sin ejecutar la muestra:

• Reputación primero. Envía el hash a un servicio de reputación multi-motor y a tu plataforma de TI. Muchos motores marcándolo como una familia conocida es una confirmación fuerte. Cero detecciones en un archivo que tu EDR capturó por comportamiento puede significar una muestra totalmente nueva, o un falso positivo, así que no te detengas en el conteo.
• Lee el resumen de comportamiento del sandbox, no el ensamblaje. Un reporte de detonación te dice en lenguaje claro qué hace el archivo: archivos escritos, procesos generados, claves de registro establecidas, dominios contactados, stores de credenciales accedidos. Ese resumen es tu lista de capacidades. No necesitas hacer ingeniería inversa, estás leyendo el resumen de comportamiento.
• Mapea el comportamiento a tu scoping. Si el reporte muestra acceso a credenciales de navegador, tu scoping debe incluir un reset de credenciales. Si muestra una descarga, tienes un segundo stage que encontrar. El reporte de la detonación te entrega tu lista de tareas.
• Ten en cuenta la evasión del sandbox. Algunos malwares detectan sandboxes y se quedan callados, por lo que un reporte limpio en un archivo que tu EDR marcó por comportamiento no lo libera, así que confía en lo que realmente pasó en el host.

Severidad de un vistazo por categoría

Category	Qué quiere	Tu must-do si se ejecutó
Infostealer	Passwords, cookies, tokens, wallets	Reset de credenciales, revocar todas las sesiones, tratar todos los secretos del host como comprometidos
Loader	Pull and run a second stage	Encontrar el segundo stage, tratar sus capacidades como presentes
RAT	Hands on keyboard control	Aislar ahora, asumir un humano estaba activo, cazar sus acciones
Ransomware	Encrypt for extortion	Aislar, escalar duro, ver Volumen 10
Coin miner	Steal compute	Limpiar, pero encontrar cómo entró, es un síntoma
PUA / PUP	Adware, bundled junk	Eliminar, documentar, no llamarlo un ataque

El Hash es tu hilo conductor

Un SHA256 une la alerta, la búsqueda de reputación, el reporte del sandbox, la caza en toda la flota y la lista de bloqueo. Captúralo primero, defénsalo cualquier URL a su alrededor y llévalo a través de cada paso. Cuando IR pregunte “¿qué era?”, el hash es la respuesta que les permite retomar el trabajo instantáneamente.

Preguntas que impulsan la búsqueda de evidencia

• ¿Se ejecutó, o fue bloqueado antes de la ejecución, y cómo lo sé?
• ¿Qué familia es y cuál es su objetivo?
• ¿Qué dicen la reputación del hash y el reporte del sandbox sobre lo que hace?
• ¿Cuál es el proceso padre y cómo llegó el archivo?
• Si se ejecutó: ¿qué credenciales, sesiones o datos fueron expuestos en esa ventana?
• ¿Dejó caer o descargó un segundo stage, y qué hace ese?
• ¿Estableció persistencia que sobreviva a la eliminación del archivo?
• ¿Dónde más en la flota aparecen este hash o estos indicadores?

Artefactos a capturar sobre la marcha

• El SHA256 (y otros hashes), más la ruta del archivo y el nombre.
• La acción, el método de detección y el estado de ejecución de la alerta, registrados explícitamente.
• El árbol de procesos con padres, hijos, PIDs y marcas de tiempo.
• El resumen de comportamiento del sandbox y la reputación multi-motor.
• Indicadores: dominios C2 e IPs (defensados), URL de entrega, hash del segundo stage.
• Artefactos de persistencia y credenciales expuestas, capturadas antes de la limpieza.

---

Sección 5 - Tomando la decisión

Cada alerta de malware termina en uno de tres veredictos. El veredicto impulsa respuestas radicalmente diferentes, por lo que acertar es la calibración de la que trata este volumen.

Veredicto 1 - True Positive (malware real)

• El hash se enriquece como una familia maliciosa conocida, o el sandbox muestra un comportamiento claramente malicioso.
• El linaje encaja con una ruta de entrega real: descarga de malvertising, adjunto de phishing, comando pegado.
• Si se ejecutó, el scoping muestra consecuencias reales: acceso a credenciales, un segundo stage, persistencia o C2.
• La respuesta escala según la categoría y la respuesta de blocked-or-ran, desde el reset de credenciales hasta aislar y reimagear.

Veredicto 2 - False Positive

• El hash tiene una reputación limpia en todas partes excepto en tu EDR, y la ruta coincide con software interno o de proveedor conocido.
• El archivo marcado es una herramienta de administración, un producto de seguridad o un binario de red team que alguien puede avalar.
• El comportamiento, cuando se detona, es benigno y coincide con las acciones esperadas de la herramienta legítima.
• Documenta el FP y, si es posible, solicita una supresión o permiso para que la misma herramienta deje de avisar al SOC.

Veredicto 3 - PUA / No deseado pero no un ataque

• La categoría es PUA o PUP: adware, barras de herramientas, optimizadores agresivos.
• La reputación y el comportamiento muestran molestia, no robo ni control: anuncios, redirecciones, empaquetado, no acceso a credenciales ni C2.
• Detección real de algo real, pero es un cleanup y una conversación con el usuario, no un incidente.
• Elimínalo, anota cómo llegó (a menudo empaquetado en un instalador), y resiste la urgencia de escalarlo como malware.

Comparación de señales

Signal	True positive	False positive	PUA
Reputation	Widely flagged as a family	Clean except your EDR	Flagged as PUA/adware
Path / source	Downloads, temp, malvertising	Known internal/vendor path	Bundled installer
Behavior	Theft, loading, C2	Benign, matches the tool	Ads, redirects, bundling
Response	Scale to category and run state	Document, suppress	Remove, note, move on

NINGUNA SEÑAL ÚNICA DECIDE: Una reputación limpia no libera una detección por comportamiento (puede ser una muestra totalmente nueva), y un nombre de familia aterrador no prueba por sí solo la ejecución. Reconcilia la reputación, el comportamiento, el linaje y el estado de ejecución juntos. El veredicto es un conjunto, y los errores más costosos provienen de confiar en un solo campo.

Ejercicio - Tres alertas, tú tomas la decisión

Lee cada escenario, decide tu veredicto y si se ejecutó, luego verifica la respuesta. Estos son compuestos de investigaciones reales y mapean directamente a las preguntas de escenario en las entrevistas.

Escenario A

Alerta en la estación de trabajo de un admin: una hacktool marcada como HackTool:Win32/Mimikatz, ruta C:\Tools\security-testing\, el proceso padre es la propia sesión de PowerShell del admin, no hay ejecución más allá del admin ejecutándola deliberadamente, y el SHA256 coincide con el lanzamiento público bien conocido de Mimikatz. El admin está en el red team interno y tiene un compromiso documentado está semana.

Veredicto: False Positive (herramientas autorizadas). Mimikatz es una herramienta real para volcar credenciales, así que el EDR no está equivocado en que es peligrosa. Pero el uso autorizado del red team, en un compromiso documentado, por la persona correcta, en una ruta de herramientas conocida, es actividad sancionada, no un incidente. Confirma el compromiso con el líder del red team fuera de banda, documéntalo y suprime para ese host específico. La habilidad es verificar la autorización en lugar de ignorar una hacktool o tratar las pruebas sancionadas como una brecha.

Escenario B

Alerta en una laptop de finanzas: Trojan:Win32/Vidar, acción Quarantined y Remediated, pero la línea de proceso muestra que se ejecutó durante dos minutos con chrome.exe como padre, el usuario confirma que buscó una plantilla de factura gratuita y ejecutó un instalador, y el reporte del sandbox para el hash muestra acceso al store de credenciales de Chrome y una conexión de salida a un dominio C2 conocido de un stealer.

Veredicto: True Positive, stealer que se ejecutó. El tranquilizador Quarantined y Remediated es la trampa. Se ejecutó durante dos minutos, es un stealer, y el sandbox confirma la capacidad de robo de credenciales. El archivo se fue, pero las credenciales no. Aísla, resetea las contraseñas del usuario y revoca todas las sesiones inmediatamente, caza el hash y el C2 en toda la flota, revisa la persistencia y escala. Cerrar esto basándose solo en el campo de action dejaría el robo real activo, que es el error más común en las alertas de malware.

Escenario C

Alerta en una PC de marketing: PUA:Win32/DriverUpdater, marcada como una aplicación potencialmente no deseada, empaquetada dentro de un convertidor de video gratuito que el usuario instaló la semana pasada. Sin acceso a credenciales, sin C2, sin segundo stage en el reporte del sandbox. El comportamiento es molestar al usuario para que compre una licencia y mostrar anuncios. Reputación en otros motores: PUA, no malware.

Veredicto: PUA, cleanup no incidente. Detección real de una molestia real, pero es adware empaquetado en software gratuito, no un ataque. Elimínalo, dile al usuario cómo llegó (instaladores empaquetados) y considera si tu política de software debería bloquear está clase. Escalar esto como malware quema tiempo de IR y credibilidad. La habilidad es llamarlo con precisión: no es nada, pero tampoco es una brecha.

---

Sección 6 - Recorrido completo de la investigación

Trabajemos la alerta de la Sección 2 de principio a fin, exactamente como esperaría que un analista sólido la ejecute. Los tiempos son el tiempo de investigación transcurrido.

00:00 a 00:10 - Triage y la pregunta de Blocked-or-Ran

Los cuatro campos, leídos en orden:

• Action: Quarantined y Remediated, lo que parece cerrado.
• Detection method: Behavior, lo que significa que fue capturado haciendo algo, no sentado quieto.
• Process: SetupPdf.exe con un PID, ejecutado, padre chrome.exe.
• Family: LummaStealer, un infostealer.

Al juntarlos: esto se ejecutó antes de ser puesto en cuarentena, y es un ladrón de credenciales. El campo de action tranquilizador es anulado por el estado de ejecución. Este es un incidente, no un cleanup.

El hash 9f2c...e71a se envía a reputación y al sandbox inmediatamente mientras continúa el triage.

00:10 a 00:20 - Validación

• Reputación: ampliamente marcado como Lumma en todos los motores.
• Reporte del sandbox sobre el hash: lee los stores de credenciales de Chrome y Edge, lee bases de datos de cookies, escribe un archivo temporal y se conecta a un dominio C2 de stealer nombrado por el sandbox.
• Usuario contactado fuera de banda: r.patel buscó una herramienta gratuita de PDF, hizo clic en un resultado que era un anuncio y ejecutó el instalador. Eso es entrega por malvertising, ejecución por el usuario.

Veredicto bloqueado: true positive, stealer, ejecutado durante aproximadamente noventa segundos según el timeline. La investigación es ahora una carrera para contener el robo.

00:20 a 00:45 - Scoping

• Query uno y dos: el proceso se ejecutó, generó un hijo que escribió el archivo temporal, y el EDR lo mató y puso en cuarentena en la marca de los noventa segundos.
• Query tres: en esa ventana el proceso accedió a las rutas de stores de credenciales de Chrome y Edge y hizo una conexión de salida al C2 que el sandbox nombró. Así que las contraseñas y cookies guardadas y al menos una conexión salieron del host: asume que las contraseñas guardadas y los tokens de sesión activos para r.patel fueron robados.
• Query cinco: no se crearon claves de registro de persistencia, consistente con un stealer de tipo “smash and grab”.
• Query cuatro: el hash aparece en una otra máquina, un colega que descargó el mismo instalador una hora antes pero, según su alerta, fue bloqueado en la escritura antes de la ejecución.

Dos hosts, un robo confirmado, uno bloqueado limpio. Todo exportado.

00:45 a 01:05 - Escalación y Contención

Escalado a IR e identidad con el paquete: familia y objetivo, hash y reputación, resumen de comportamiento del sandbox, árbol de procesos, el timeline de noventa segundos con acceso a credenciales y la conexión C2, y el alcance de dos hosts.

Contención, con aprobación:

• SALES-LT-0144 aislado en 00:47
• Se verificó que la cuarentena del EDR se mantuvo y los procesos se confirmaron muertos
• El paso crítico, ejecutado en paralelo por el respondedor de identidad: reset de contraseña de r.patel y revocación de TODAS las sesiones y tokens de actualización, cada credencial guardada en el navegador tratada como comprometida y puesta en cola para rotación
• El dominio C2 y el hash bloqueados en proxy, firewall y EDR
• El host del colega se verificó como un bloque limpio (archivo en cuarentena en la escritura, sin ejecución, sin acceso a credenciales) y cerrado como tal
• SALES-LT-0144 se pone en cola para reimage y una limpieza de credenciales de navegador, ya que un stealer que tocó los stores de credenciales deja incertidumbre

Causa raíz y cierre

Cadena: el usuario buscó software gratuito, hizo clic en un resultado de malvertising, ejecutó un instalador trojanizado que era el Lumma stealer, el cual leyó las credenciales del navegador y las exfiltró antes de que la detección por comportamiento del EDR lo matara en noventa segundos.

La nota de cierre documenta la cadena, el hallazgo explícito de blocked-or-ran para ambos hosts, la exposición de credenciales y el reset, y dos recomendaciones sistémicas: una política de contenido web para frenar las descargas de malvertising, y un recordatorio de que es exactamente por esto que la revocación de sesiones en los Volúmenes 1 y 2 importa, porque los tokens robados son inútiles una vez revocados.

La detección funcionó; la victoria fue leer más allá del campo de action para ver el robo debajo.

LO QUE HIZO BUENA Está INVESTIGACIÓN: El analista leyó el campo de action contra el estado de ejecución en lugar de confiar en Quarantined, identificó el objetivo de la familia y pivotó directamente a la respuesta de credenciales, verificó la remediación del EDR en lugar de asumirla, separó el bloque limpio del robo real y preservó antes de reimagear. Cada uno de esos hábitos son preguntas que hago en las entrevistas.

El único hábito que salvó este caso

Dos analistas podrían haber abierto está misma alerta. Uno lee Quarantined y Remediated, ve el estado verde y la cierra en treinta segundos. El otro lee la misma palabra, nota que el proceso se ejecutó y la familia es un stealer, y resetea las contraseñas del usuario antes de que los tokens robados sean usados.

Misma alerta, mismo EDR, mismos datos. La única diferencia es si el analista reconcilió el campo de action contra el estado de ejecución, lo cual toma unos dos minutos y es todo el valor que este libro de trabajo intenta construir en ti.

Detected no significa contenido. Quarantined no significa limpio. Leer el espacio entre lo que el EDR observó y lo que realmente detuvo es la habilidad central del analista de malware, y es la diferencia entre un ticket cerrado y un incidente cerrado.

---

Sección 7 - Notas del analista

Imprímelas o recréalas en tu herramienta de tickets. Complétalas durante tu próxima investigación real de malware. La estructura a continuación es el paquete de escalación de la Sección 3, fase 4.

Checklist de Triage (ejecuta antes que cualquier otra cosa)

• Acción del campo leída: bloqueado antes de la ejecución vs puesto en cuarentena después de correr
• Estado de ejecución confirmado: ¿corrió realmente un proceso? (PID, árbol)
• Método de detección anotado: firma/archivo en reposo vs comportamiento/EDR
• Familia de malware y su objetivo identificados
• SHA256 capturado y enviado a reputación + sandbox
• Proceso padre y ruta de entrega identificados
• FP / PUA descartados vía reputación, ruta y comportamiento
• Resumen de comportamiento del sandbox leído (capacidades, no ensamblaje)
• Si se ejecutó: evaluación de exposición de credenciales / sesiones / datos
• Segundo stage o descarga identificado y analizado
• Persistencia revisada: run keys, tareas, servicios, cuentas
• Hash e indicadores cazados en toda la flota
• Evidencia preservada antes de cualquier limpieza o reimage

CONSEJO DE CAMPO: El error más común es cerrar basándose solo en el campo de action. Escribe la respuesta de blocked-or-ran explícitamente en el ticket en el momento en que la definas, porque cada decisión posterior (reimage, reset de credenciales, escalación) depende de ello. Los revisores lo comprueban.

Qué contiene un paquete de escalación completo

• La familia, su objetivo y el hallazgo explícito de blocked-or-ran para cada host.
• El hash con reputación y el resumen de comportamiento del sandbox.
• El árbol de procesos con padres, hijos, PIDs y marcas de tiempo.
• El timeline del host de lo que corrió y lo que tocó, incluyendo acceso a credenciales y C2.
• Credenciales o sesiones expuestas, y hallazgos de persistencia.
• Indicadores listos para bloquear, y acciones ya tomadas con marcas de tiempo.

Investigación 1

Campo	Valor
Encabezado de investigación	Alert ID: ____________ Fecha/hora de apertura: ____________
Device	____________
User	____________
Family	____________
Ran?	Y / N
SHA256 / path / parent process

Hallazgos

Campo	Valor
Árbol de procesos y timeline del incidente (UTC)
Indicadores (hash / C2 / URL, defensados) y secretos expuestos
Causa raíz
Acciones tomadas	Con marcas de tiempo, incluyendo resets de credenciales
Recomendaciones y feedback de detección

Investigación 2

Campo	Valor
Encabezado de investigación	Alert ID: ____________ Fecha/hora de apertura: ____________
Device	____________
User	____________
Family	____________
Ran?	Y / N
SHA256 / path / parent process

Hallazgos

Campo	Valor
Árbol de procesos y timeline del incidente (UTC)
Indicadores (hash / C2 / URL, defensados) y secretos expuestos
Causa raíz
Acciones tomadas	Con marcas de tiempo, incluyendo resets de credenciales
Recomendaciones y feedback de detección

Glosario - Términos que encontrarás en el turno

Término	Definición
Detection vs prevention	Una detection es una observación de que algo sucedió. Una prevention o block detuvo el evento antes de que corriera. El espacio entre ellos es donde viven los incidentes omitidos.
Quarantine	Mover un archivo malicioso a una ubicación aislada. Te dice dónde está el archivo ahora, no si se ejecutó primero.
Remediation	La afirmación de limpieza del EDR: archivo en cuarentena, proceso muerto. Verifícalo en lugar de aceptarlo.
Infostealer	Malware que recolecta contraseñas, cookies, tokens y wallets y los exfiltra rápido. Lumma, RedLine, Vidar son familias comunes.
Loader / dropper	Un pequeño primer paso cuyo trabajo es descargar y ejecutar un segundo stage más grande. El archivo que capturaste es la puerta.
RAT	Remote access trojan. Da al atacante control de manos en el teclado del host.
PUA / PUP	Potentially unwanted application or program: adware, barras de herramientas, optimizadores agresivos. Detección real, no un ataque.
SHA256	La huella criptográfica de un archivo. El identificador portable que une toda la investigación.
Detonation / sandbox	Ejecutar una muestra en un entorno de análisis aislado para observar el comportamiento sin infectar nada de lo que te importa.
Reputation	Veredictos agregados sobre un hash en múltiples motores. Confirmación fuerte cuando está ampliamente marcado como una familia, inconcluyente cuando está limpio en una detección por comportamiento.
Sandbox evasion	El malware se queda callado cuando detecta un entorno de análisis, por lo que un reporte limpio no libera un archivo marcado por comportamiento.
Second stage	El payload que un loader descarga y ejecuta. A menudo es la amenaza real, escondida detrás de un primer archivo pequeño.
Persistence	Mecanismos que sobreviven al reinicio y a la eliminación del archivo: run keys, tareas programadas, servicios, entradas de inicio.
C2	Command and control: la infraestructura a la que el malware llama a casa. Una llamada de salida es tanto evidencia de que se ejecutó como un indicador para bloquear.

---

Sección 8 - Referencia rápida

La versión de una sola página. Mantén esto abierto en tu turno.

Primeros diez minutos

• Lee cuatro campos en orden: action, detection method, execution state, parent process.
• Responde la pregunta que lo decide todo: ¿fue bloqueado antes de la ejecución, o se ejecutó?
• Identifica la familia y su objetivo: stealer, loader, RAT, ransomware, miner, PUA.
• Haz el hash, envía el SHA256 a reputación y al sandbox. Nunca ejecutes la muestra tú mismo.

Decidiendo

• True positive: mala reputación o comportamiento, ruta de entrega real, consecuencias reales si se ejecutó.
• False positive: reputación limpia, ruta y fuente interna/de proveedor conocidas, comportamiento benigno, alguien puede avalarlo.
• PUA: adware o basura empaquetada, molestia no robo, cleanup no incidente.
• Reputación limpia no libera una detección por comportamiento. Nombres aterradores no prueban la ejecución. Apila las señales.

Si se ejecutó

• Stealer: resetea credenciales y revoca TODAS las sesiones. Trata cada secreto del host como comprometido.
• Loader: encuentra y analiza el segundo stage, trata sus capacidades como presentes.
• RAT: aísla ahora, asume un humano activo, caza sus acciones.
• Siempre: construye el árbol de procesos, revisa la persistencia, caza el hash en toda la flota, verifica la remediación del EDR.

Calibración

• No reimagees un PUA en cuarentena que nunca se ejecutó. No cierres un stealer detectado por comportamiento en el campo de action sin resetear las credenciales.
• Preserva antes de limpiar. Bloquea indicadores en todas partes. Documenta el hallazgo de blocked-or-ran explícitamente.

SIEMPRE: Detected no significa contenido. Quarantined no significa limpio. Reconcilia el campo de action contra el estado de ejecución antes de decidir cualquier cosa. La lectura de los cuatro campos son dos minutos que deciden las siguientes dos horas.

---

Bonus - Cómo aparece esto en tu entrevista

Yo realizo entrevistas técnicas para roles de analista e ingeniería, y las alertas de malware son donde pongo a prueba la calibración: ¿puede un candidato leer lo que el EDR realmente hizo y responder proporcionalmente? 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 libro de trabajo dicha en voz alta.

Preguntas de la entrevista

Pregunta 1: Una alerta de malware dice “Quarantined and Remediated”. ¿Ya terminaste?

No, y el porqué es toda la pregunta: quarantined te dice dónde está el archivo, no si se ejecutó primero. Los candidatos fuertes preguntarán inmediatamente por el estado de ejecución y el método de detección, y notarán que un proceso detectado por comportamiento corrió antes de ser puesto en cuarentena. Los candidatos que digan “sí, el EDR lo manejó” acaban de describir el error de malware más común que existe.

Pregunta 2: ¿Cómo distingues un falso positivo de una detección real?

Reputación en múltiples motores, la ruta y fuente del archivo, el comportamiento del sandbox y si alguien puede avalarlo como una herramienta conocida. La respuesta madura añade que una reputación limpia no libera una detección por comportamiento, porque podría ser una muestra totalmente nueva. Ese matiz es lo que separa a los analistas cuidadosos de los que solo marcan casillas.

Pregunta 3: El malware es un infostealer conocido y se ejecutó. ¿Cuál es tu prioridad?

Credenciales y sesiones, inmediatamente: resetea la contraseña del usuario, revoca todas las sesiones y tokens, trata cada secreto guardado en el host como comprometido. Los candidatos fuertes vinculan explícitamente esto con la revocación de sesiones y dicen que el archivo puesto en cuarentena es casi irrelevante una vez que un stealer se ha ejecutado. Está es la pregunta donde todo el volumen se conecta.

Pregunta 4: ¿Ejecutarías la muestra para ver qué hace?

Nunca en una máquina de producción o del usuario. Envías el hash a un sandbox o lees un reporte de detonación existente. Los candidatos que nombran el sandbox como la ruta segura, y que tratan la ejecución de la muestra viva como obviamente incorrecta, tienen los instintos adecuados. Es la misma disciplina que no ejecutar el PowerShell para leerlo.

Pregunta 5: ¿Cuándo aislas o reimageas en lugar de solo limpiar?

Aísla cuando se ejecutó y especialmente para un RAT o malware con beaconing. Reimagea cuando el estado limpio no puede ser probado, como un RAT o un compromiso profundo. Limpia y documenta cuando un archivo fue limpiamente bloqueado antes de la ejecución o es PUA. La respuesta ganadora muestra calibración: haciendo coincidir la respuesta con la respuesta de blocked-or-ran y la categoría, no sobre-reaccionando ni sub-reaccionando.

Ese es el libro de trabajo, amigos. Lee los cuatro campos, responde blocked o ran, y deja que el objetivo del malware dirija tu respuesta. Si logras esa calibración, la cola de malware dejará de ser una moneda al aire entre el pánico y la complacencia. Otros volúmenes en está serie cubren las otras alertas con las que vivirás en tu turno.

Jbird, jbirdcyber.gumroad.com