5.3 · Detección de amenazas de identidad y correo

Panorama#

El perímetro de red dejó de ser la línea de defensa hace años; la identidad ocupó su lugar. Cuando las aplicaciones viven en la nube, el trabajo es remoto y el acceso depende de credenciales y tokens, la pregunta que importa ya no es «¿el paquete entró a la red?» sino «¿quién dice ser este usuario y se está comportando como él?». Y la puerta de entrada a esa identidad es, abrumadoramente, el correo: según el informe X-Force de IBM, el 41% de los accesos iniciales empiezan con un phishing, porque para el atacante recolectar direcciones con el OSINT de identidad (2.2) y enviar un señuelo cuesta muy poco y explota la vulnerabilidad más constante, la del usuario. Este capítulo es el espejo defensivo de ese OSINT —donde 2.2 mostraba cómo el atacante construye el conocimiento de una identidad, aquí se detecta cómo la usa— y de la explotación de Kerberos (4.2), su forma más avanzada dentro del dominio.

Un principio rector, tomado de la práctica de respuesta a incidentes, gobierna todo el capítulo: una autenticación exitosa no implica legitimidad. Un login correcto, un MFA aprobado, un token válido —cada uno puede ser el atacante usando una identidad legítima que robó o cuyo consentimiento engañó—. Por eso la detección de amenazas de identidad no se hace sobre el evento aislado («hubo un acceso exitoso, todo bien») sino sobre el comportamiento en contexto: quién, desde dónde, con qué dispositivo, a qué velocidad, haciendo qué a continuación. Es la aplicación directa de la pirámide del dolor de 5.1 a la identidad: la IP de un login cambia con un clic, pero el patrón «autenticación exitosa + dispositivo nuevo + viaje imposible + regla de buzón que oculta facturas» es una TTP que el atacante no puede evitar sin renunciar al objetivo.

El recorrido va de afuera hacia adentro, siguiendo la cadena de identidad: primero el correo entrante (el señuelo y el análisis de sus cabeceras), luego la autenticación (el léxico de Event IDs del login), después los ataques modernos a la identidad en la nube (que ni roban la contraseña ni burlan técnicamente el MFA) y finalmente el abuso de identidad en el dominio (Kerberos visto desde el SIEM). La telemetría de todos ellos es la que 5.2 definió.

flowchart LR
  MAIL["Correo entrante\n(phishing · BEC ·\nadjunto/enlace)"] --> AUTH["Autenticación\n(login: 4624/4625 ·\nSPF/DKIM/DMARC)"]
  AUTH --> CLOUD["Identidad en la nube\n(OAuth consent · AiTM ·\nrobo de token)"]
  AUTH --> DOM["Identidad en el dominio\n(Kerberos: 4769 RC4 ·\nspraying · lateral)"]
  CLOUD -->|"regla de buzón · Graph API"| FRAUD["Fraude / BEC ·\npersistencia"]
  DOM -->|"5140/5145 · 4728/4732"| ESC["Escalada · lateral\n→ 5.6"]
  classDef n fill:#1e293b,stroke:#475569,color:#e2e8f0;
  class MAIL,AUTH,CLOUD,DOM,FRAUD,ESC n;

El correo como vector de acceso inicial#

El análisis de un correo sospechoso empieza por clasificar la amenaza. Las familias son cuatro: el phishing masivo e indiscriminado; el spear phishing dirigido y personalizado (que eleva drásticamente la tasa de éxito); el whaling, spear phishing enfocado en ejecutivos de alto valor —las «ballenas», el CEO o el CFO—; y el BEC (Business Email Compromise), el fraude que suplanta o compromete la identidad de un empleado de confianza para desviar pagos. La carga se entrega de dos formas: un adjunto armado —weaponized document—, que segmenta en documentos de Office con macros VBA (los más prevalentes por el uso corporativo), PDF con JavaScript o exploits del renderizador, archivos comprimidos que ofuscan el binario, imágenes ISO que eluden los filtros de tipo, y formularios HTML locales que imitan portales; o un enlace que lleva a un sitio de robo de credenciales o a la descarga de la carga secundaria.

Contra las pasarelas de correo —Secure Email Gateways, que detonan el adjunto en un sandbox antes de entregarlo— el atacante despliega evasiones específicas: inyectar un sleep que supere el timeout del sandbox (el malware «duerme» tres minutos y no hace nada mientras lo observan), entregar el adjunto cifrado con la contraseña en el cuerpo del correo (el sandbox no puede abrirlo automáticamente pero la víctima sí), y alojar las URL en nubes confiables (web.app, OneDrive) que las listas de reputación no bloquean. Por eso el análisis del SOC es un flujo determinista que nunca se detiene en un solo indicador: triangular la reputación de la IP del servidor SMTP (con listas como MxToolbox), validar el dominio contra los registros MX autorizados para descartar suplantación, aislar el contenido, y —cuando hace falta— detonarlo en un sandbox interactivo (ANY.RUN para adjuntos, urlscan.io para enlaces) para capturar el comportamiento real. En un caso típico, un VISA PAYMENT (1).xls protegido con contraseña detona en excel.exe, escribe un UkMes.bat, lanza cmd.exe y termina en un powershell.exe con un argumento Base64 kilométrico —la misma cadena padre-hijo anómala que 5.2 enseña a cazar en el 4688—, revelando en el camino las conexiones HTTP a los servidores de descarga y los flags de descubrimiento del entorno.

Análisis de cabeceras: desenmascarar la suplantación#

Cuando el señuelo suplanta un remitente confiable, la prueba está en las cabeceras, y leerlas exige entender el flujo del correo: el cliente (MUA) entrega al servidor de sumisión (MSA), que transfiere por relés (MTA) hasta el servidor de recepción (MX) del destinatario, que lo deposita vía el agente de entrega (MDA). El detalle forense clave es que cada salto estampa su propia cabecera Received arriba de las anteriores, de modo que el encabezado se lee de abajo hacia arriba: el bloque Received más bajo revela la IP y el hostname del servidor que originó la transmisión —el dato para triangular la infraestructura del atacante contra la inteligencia de amenazas—.

Sobre esa base se leen las discrepancias que delatan la suplantación. La primera es entre el From (visible, que el atacante manipula) y el Return-Path —también Envelope-From, la dirección oculta a la que van los rebotes—: si no coinciden, hay señal de spoofing. La segunda, y la firma clásica del BEC, es un Reply-To divergente: el correo parece venir del proveedor legítimo, pero la respuesta de la víctima se desvía a un dominio externo o lookalike controlado por el atacante. Y la validación criptográfica la dan tres protocolos que conviene leer juntos en la cabecera Authentication-Results:

• SPF (Sender Policy Framework): el dominio publica en su DNS un registro TXT con las IP autorizadas a enviar en su nombre (v=spf1 ip4:... -all); el receptor compara la IP emisora y marca spf=pass o spf=fail.
• DKIM (DomainKeys Identified Mail): el emisor firma criptográficamente cabeceras y cuerpo; el receptor recupera la clave pública del DNS usando el selector (s=) y verifica que nada se alteró en tránsito. La ausencia del bloque DKIM-Signature en un correo que dice venir de una marca grande es en sí misma una señal.
• DMARC (Domain-based Message Authentication, Reporting and Conformance): unifica SPF y DKIM exigiendo alineación con el dominio del From visible, y dicta al receptor qué hacer ante el fallo —p=reject (descartar), p=quarantine (a spam) o p=none (solo reportar)—.

El contraste es nítido en la práctica: un correo legítimo de Yahoo a Gmail muestra spf=pass + dkim=pass + dmarc=pass bajo p=REJECT; un spoof de FedEx muestra el Received más bajo inyectado desde una IP ajena (mailserver.footballticketnet.com), un spf=fail confirmado al consultar los MX reales de fedex.com en MxToolbox, y la ausencia total de DKIM-Signature —tres pruebas concluyentes de la falsificación—.

Rastreo de la autenticación: el léxico forense del login#

Casi toda acción en Windows está atada a una cuenta, de modo que el primer rastro de un adversario es la actividad de login. El evento central es el 4624 (inicio de sesión exitoso), que solo cobra sentido leído junto a su campo Logon Type: tipo 2 (teclado local), 3 (red o SMB), 10 (RDP), 11 (credenciales cacheadas). Un 4624 tipo 10 desde una IP interna inesperada es un movimiento lateral por RDP; un tipo 3 hacia recursos administrativos es lateral por SMB —el terreno de 5.6—. Cuando el 4624 va seguido de inmediato por un 4672 («privilegios especiales asignados»), la sesión arrancó con derechos administrativos. Y vinculando el Logon ID entre el 4624 y su cierre (4634 logoff de red, 4647 logoff interactivo) se mide la ventana exacta en que la cuenta estuvo activa —tres minutos, en el caso de la cuenta pbeesly del dataset APT29—, lo que acota el intervalo donde buscar el resto de las acciones.

Los fallos dicen tanto como los éxitos. El 4625 (login fallido) trae un Status/Sub Status hexadecimal que revela la semántica del error, y la distinción es táctica: 0xC0000064 significa usuario inexistente (el atacante adivina identidades a ciegas), mientras que 0xC000006A significa contraseña incorrecta sobre un usuario que sí existe (tiene una lista válida de usuarios). Muchos 0xC000006A sobre muchas cuentas con una sola contraseña común es la firma del password spraying —probar una contraseña frecuente contra todo el directorio para no disparar el bloqueo por cuenta, el 4740—. La validación de credenciales, además, la registra el sistema que autentica, no la estación: en el controlador de dominio, un fallo NTLM genera el 4776 y un fallo de pre-autenticación Kerberos el 4771 (con Failure Code 0x6 = usuario inexistente, 0x18 = contraseña incorrecta). Finalmente, la persistencia por identidad se lee en los eventos de gestión de cuentas: la creación (4720) no dice los permisos, así que hay que cruzarla con el 4728/4732 (adición a un grupo global/local) para ver si la cuenta apócrifa fue elevada a «Domain Admins». Este es el diccionario de eventos que la defensa de Active Directory (4.9) aplicó a la cadena de ataque del dominio; aquí se describe su mecánica de login como base de todo lo que sigue.

La identidad en la nube: cuando el MFA no alcanza#

Los ataques de identidad más incómodos de 2026 comparten un rasgo: ni roban la contraseña ni burlan técnicamente el MFA —lo rodean—. Tres patrones, tomados de cadenas de incidente reales, lo ilustran, y los tres desembocan en la misma maniobra de persistencia: una regla de buzón que oculta la correspondencia financiera.

El primero es el abuso de consentimiento OAuth (OAuth consent abuse). El señuelo no pide la contraseña: lleva a un flujo de autorización legítimo de Microsoft donde el usuario, engañado, aprueba que una aplicación maliciosa acceda a sus datos (permisos Mail.Read, Files.Read.All, offline_access). El atacante obtiene así un token de aplicación persistente sin tocar la credencial ni el MFA —que el propio usuario aprobó—. Desde ese token opera de forma no interactiva vía Microsoft Graph API, desde una IP inusual, buscando en el buzón términos como «factura» o «pago». Como el acceso «parece» venir de una app autorizada, pasa desapercibido salvo que se vigile la reputación del editor de la app, los permisos delegados que solicita y los patrones de consentimiento anómalos (T1528, Steal Application Access Token).

El segundo es el AiTM (Adversary-in-the-Middle). El señuelo enruta el flujo de login a través de un proxy del atacante; el usuario completa el MFA de forma aparentemente normal, pero como el tráfico está intermediado, el atacante captura el token de sesión —la cookie criptográfica post-aprobación— y lo reproduce (replay) desde su propio dispositivo e IP, derrotando al MFA porque presenta la evidencia ya validada. Con ese token lee el buzón buscando instrucciones de VPN, entra a la red interna, hace descubrimiento de AD y prepara ransomware. La señal no está en el MFA (que fue «exitoso») sino en las discrepancias: impossible travel (la misma sesión desde dos geografías incompatibles en el tiempo), device/UA mismatch (dispositivo o user-agent distinto del habitual) y la reutilización del token desde una red anómala (T1550.004, Web Session Cookie). Es el primo en la nube del pass-the-cookie que la web moderna (3.5) describió.

El tercero es el BEC clásico (Business Email Compromise): con credenciales comprometidas —a menudo de un stealer log o un combo-list, como mostró 2.6— el atacante entra al buzón de finanzas, busca hilos de facturación, crea reglas de buzón que ocultan los correos con «invoice»/«payment» y reenvían al exterior, suplanta a un proveedor histórico con un dominio lookalike, y en un hilo real solicita un «cambio urgente de datos bancarios» para desviar los fondos. Borra sus rastros con un HardDelete (borrado irreversible del servidor) y delega permisos para persistir (T1078.004 + T1114.003).

El abuso de identidad en el dominio: Kerberos desde el SIEM#

Dentro del dominio, la forma más avanzada de abuso de identidad es la explotación de Kerberos, y su detección es el espejo azul directo de la explotación ofensiva (4.2). La cadena típica parte de un foothold interno (4624 desde una estación unida al dominio o una VPN anómala), hace descubrimiento con consultas LDAP inusuales, e identifica cuentas de servicio con SPN (Service Principal Name) —los objetivos del Kerberoasting—. Al solicitar masivamente tickets de servicio (TGS) para esas cuentas, fuerza al controlador de dominio a cifrarlos, y la firma de detección es un pico de eventos 4769 que piden explícitamente cifrado RC4 (0x17) en lugar del AES moderno (0x12): un downgrade attack deliberado, porque RC4 es más fácil de romper fuera de línea. Descifrada la contraseña de la cuenta de servicio, el atacante la usa —4624 desde una estación irregular, la anomalía que delata una cuenta de servicio que normalmente no inicia sesión interactiva—, accede a servidores por SMB (5140/5145), enumera grupos privilegiados y, en el intento final de escalada, modifica grupos críticos (4728/4732/4756, adición a «Domain Admins»). La detección no depende de un evento sino de correlacionar la cadena: SPN discovery → 4769 RC4 → uso irregular de la cuenta → modificación de grupos. La defensa de AD (4.9) desarrolló a fondo esta correlación y su hardening (RC4→AES, cuentas de servicio con contraseñas largas o gMSA, rotación); aquí queda enmarcada como el eslabón «dominio» de la cadena de identidad.

Cierre: la cadena de identidad y el comportamiento sobre el evento#

Los siete casos de este capítulo —el adjunto armado, la cabecera falsificada, el spraying, el consentimiento OAuth, el token robado por AiTM, el fraude BEC y el Kerberoasting— dibujan una sola lección, la que enuncian los propios playbooks: el SOC detecta el incidente cuando múltiples comportamientos se correlacionan en una historia de ataque completa, no cuando salta una alerta aislada. Ninguna de estas amenazas se ve en un evento único; todas se ven en la secuencia: correo entregado → clic → MFA aprobado → login desde IP nueva → búsqueda de facturas → regla de buzón → intento de exfiltración. Por eso la lógica de detección de los playbooks es una máquina de estados —«SI se observa foothold Y el comportamiento siguiente coincide con discovery Y más tarde alcanza lateral movement Y hay impacto de negocio posible, ENTONCES dispara alerta de severidad crítica»—, exactamente el tipo de regla que la ingeniería de detección de 5.1 construye sobre comportamiento (alto en la pirámide del dolor) y no sobre el artefacto atómico que caduca.

La cara de hardening cierra el círculo con el OSINT de identidad (2.2): donde allí el atacante perfilaba la identidad de afuera, aquí la organización reduce su superficie —MFA resistente al phishing (FIDO2/passkeys, que no se dejan interceptar por AiTM porque la clave está atada al origen), restricción del consentimiento OAuth a aplicaciones verificadas, alertas sobre reglas de reenvío externo y delegación de buzón, SPF/DKIM/DMARC en p=reject para que nadie suplante el propio dominio, y en el dominio RC4→AES con cuentas de servicio endurecidas—. Cuando el incidente se confirma, la contención de identidad es específica y se desarrolla en 5.4: revocar los tokens y las sesiones (no basta con resetear la contraseña, porque el token OAuth o la cookie de AiTM la sobreviven), cortar la VPN, y limpiar las reglas de buzón y delegaciones que dejó el atacante. La identidad es el perímetro; su telemetría, correlacionada en el tiempo, es cómo se defiende.

Referencias#

• blue-dfir/effective-threat-investigation/cap-01 — Investigating Email Threats: las familias de amenaza (phishing/spear/whaling/BEC), los adjuntos armados y la evasión de sandbox, el flujo de triaje determinista y la detonación en ANY.RUN/urlscan.
• blue-dfir/effective-threat-investigation/cap-02 — Email Flow and Header Analysis: el flujo MUA→MTA→MX, la lectura de Received de abajo hacia arriba, From/Return-Path/Reply-To, y el mecanismo y lectura de SPF/DKIM/DMARC.
• blue-dfir/effective-threat-investigation/cap-04 — Tracking Accounts Login and Management: 4624 y Logon Type, 4672, Logon ID/4634/4647, 4625 con Sub Status (brute-force vs spraying), 4776/4771, y 4720/4728/4732/4740.
• blue-dfir/incident-playbook/cap-01 — Identity-Based Attack (OAuth consent abuse): el token de aplicación sin contraseña, el acceso no interactivo por Graph API y la regla de buzón como preludio de BEC (T1528/T1550.001).
• blue-dfir/incident-playbook/cap-02 — AiTM Phishing: el proxy que roba el token de sesión, el replay que derrota al MFA, y las señales de impossible travel y device/UA mismatch (T1557/T1550.004).
• blue-dfir/incident-playbook/cap-06 — BEC: reglas de buzón que ocultan, reenvío externo, dominio lookalike, cambio de datos bancarios y HardDelete (T1078.004/T1114.003).
• blue-dfir/incident-playbook/cap-09 — Abuso de Kerberos: la cadena SPN discovery → 4769 RC4 (0x17) → uso irregular de la cuenta de servicio → modificación de grupos (4728/4732/4756) (T1558.003).
• MITRE ATT&CK — T1566.002, T1621, T1528, T1550.004 y T1558.003, las técnicas de la cadena de identidad de este capítulo.