Aviso ético y legal: las técnicas de análisis forense y las herramientas descritas en este módulo (wevtutil, EvtxECmd, Chainsaw, Hayabusa, DeepBlueCLI, PsExec, WMI, WinRM) deben usarse exclusivamente en sistemas y máquinas virtuales de laboratorio propias o con autorización expresa por escrito del propietario. Simular movimiento lateral o analizar logs de producción sin permiso puede constituir un delito de acceso ilícito a sistemas informáticos (art. 197 bis y ss. del Código Penal español) y una infracción grave de las políticas de tu organización. Este contenido tiene fines exclusivamente educativos dentro de un entorno de laboratorio controlado (por ejemplo, un dominio Active Directory desechable en VMware/VirtualBox).
Qué aprenderás
Este módulo profundiza en la segunda gran fuente de evidencia en un incidente sobre Windows: los registros de seguridad relacionados con autenticación. Al terminar serás capaz de:
- Reconstruir la cadena completa de un inicio de sesión a partir del Event ID 4624 y clasificar correctamente el Logon Type (interactivo, red, RDP, servicio, batch, etc.), que es el dato que más se ignora y el que más cambia la interpretación del incidente.
- Diferenciar un fallo de autenticación por contraseña incorrecta de uno por cuenta bloqueada, caducada o deshabilitada usando el SubStatus del 4625.
- Leer los eventos Kerberos (4768, 4769, 4771) para detectar peticiones de TGT/TGS anómalas, Kerberoasting y golden/silver tickets.
- Correlacionar 4688 (creación de proceso) con línea de comandos para reconstruir qué ejecutó un atacante tras autenticarse.
- Reconocer la huella forense específica de cada técnica de movimiento lateral: PsExec, WMI, WinRM/PowerShell Remoting, RDP, pass-the-hash y pass-the-ticket.
- Detectar la creación y modificación de cuentas privilegiadas (4720, 4728, 4732, 4738) como indicador de persistencia.
- Extraer y triar EVTX a escala con
wevtutil, EvtxECmd, Chainsaw, Hayabusa y DeepBlueCLI.
1. El ciclo de vida de un logon: 4624, 4625, 4634, 4647
Todo el análisis de autenticación en Windows gira en torno al canal Security del Visor de eventos, generado por el subsistema LSASS y auditado mediante las directivas Audit Logon y Audit Logoff (categoría Logon/Logoff dentro de Advanced Audit Policy Configuration). El evento estrella es el 4624 (An account was successfully logged on), pero su utilidad depende por completo de un campo que muchos analistas pasan por alto: el Logon Type.
| Event ID | Nombre | Logon Type | Significado forense |
|---|---|---|---|
| 4624 | Logon exitoso | 2 – Interactive | Inicio de sesión local, teclado y pantalla físicos o consola directa de la VM. |
| 4624 | Logon exitoso | 3 – Network | Acceso a recurso compartido (SMB/\hostshare), autenticación contra un servicio remoto. Es el tipo más común en movimiento lateral con PsExec, WMI y ataques pass-the-hash. |
| 4624 | Logon exitoso | 4 – Batch | Ejecución de una tarea programada (Scheduled Task) con credenciales almacenadas. |
| 4624 | Logon exitoso | 5 – Service | Arranque de un servicio de Windows con una cuenta de servicio. Clave para detectar PsExec y servicios maliciosos persistentes. |
| 4624 | Logon exitoso | 7 – Unlock | Desbloqueo de una sesión de escritorio previamente bloqueada. |
| 4624 | Logon exitoso | 8 – NetworkCleartext | Autenticación de red con la contraseña viajando en claro hacia LSASS (típico de IIS con Basic Auth). Alta prioridad si aparece sin justificación. |
| 4624 | Logon exitoso | 9 – NewCredentials | Uso de runas /netonly: la sesión local no cambia, pero las credenciales nuevas se usan para conexiones salientes. Frecuente en post-explotación con Cobalt Strike/Mimikatz. |
| 4624 | Logon exitoso | 10 – RemoteInteractive | Conexión RDP (Escritorio remoto) o Terminal Services. Núcleo de la detección de RDP lateral. |
| 4624 | Logon exitoso | 11 – CachedInteractive | Logon interactivo usando credenciales cacheadas cuando no hay controlador de dominio disponible (portátiles fuera de red corporativa). |
| 4625 | Logon fallido | (igual clasificación que 4624) | Intento de autenticación rechazado. El SubStatus indica la causa exacta (ver tabla siguiente). |
| 4634 | Logoff | — | Cierre de sesión estándar; hay que emparejarlo con el 4624 correspondiente por Logon ID para calcular duración de sesión. |
| 4647 | Logoff iniciado por el usuario | — | Cierre de sesión explícito (el usuario pulsa «Cerrar sesión»), a diferencia del 4634 que puede ser forzado por el sistema. |
| 4648 | Logon con credenciales explícitas | — | Se usó runas o una conexión especificando usuario/contraseña distintos de la sesión actual. Aparece en el equipo origen, antes de que en el destino se genere el 4624 Type 3 o 10. |
| 4672 | Asignación de privilegios especiales | — | Se concede al token de la sesión un privilegio administrativo (SeDebugPrivilege, SeBackupPrivilege…). Se dispara junto al 4624 cuando la cuenta es administradora; su ausencia tras un 4624 de una cuenta que debería ser admin es también un indicador. |
El Logon ID (Target Logon ID, campo hexadecimal) es la clave de correlación más importante de todo el módulo: es único por sesión y permite unir el 4624 inicial con todos los 4688 (procesos), 4672 (privilegios) y el 4634/4647 (cierre) que ocurren dentro de esa misma sesión. Sin dominar el Logon ID no se puede reconstruir una línea temporal fiable.
1.1 Los campos que importan de verdad en un 4624
- Subject vs Target: Subject es quién inició la petición (a menudo SYSTEM o ANONYMOUS en logons de red); Target es la cuenta que efectivamente inicia sesión. En movimiento lateral, el Subject casi siempre es NULL/ANONYMOUS y solo el Target aporta información.
- Logon Process y Authentication Package:
NtLmSspindica NTLM (más sospechoso en redes con Kerberos habilitado);Kerberoses lo esperable en un dominio sano. - Workstation Name e Source Network Address: origen de la conexión. Un Source Network Address interno inesperado (un servidor de bajo privilegio autenticándose contra un controlador de dominio) es una señal fuerte de lateral movement.
- Key Length: 0 en logons NTLM que no usan cifrado de clave completa suele acompañar a pass-the-hash.
1.2 SubStatus del 4625: por qué falló el logon
| SubStatus | Significado |
|---|---|
| 0xC000006A | Nombre de usuario correcto, contraseña incorrecta. El indicador clásico de fuerza bruta/password spraying cuando se repite con múltiples SamAccountName. |
| 0xC0000064 | El nombre de usuario no existe. Útil para detectar enumeración de cuentas. |
| 0xC0000234 | Cuenta bloqueada (account lockout) — consecuencia de fuerza bruta previa. |
| 0xC0000072 | Cuenta deshabilitada. |
| 0xC0000193 | Cuenta caducada. |
| 0xC0000071 | Contraseña caducada. |
| 0xC0000224 | Se requiere cambio de contraseña en el próximo logon. |
| 0xC0000133 | Desincronización de reloj entre cliente y KDC (relevante en fallos Kerberos, no NTLM). |
Un patrón de 0xC000006A repetido contra decenas de SamAccountName distintos desde el mismo origen en una ventana corta es la firma de un password spraying; el mismo SubStatus contra un único usuario cientos de veces es fuerza bruta dirigida.
2. Kerberos en los logs: 4768, 4769, 4771
En un dominio Active Directory, la mayoría de los logons interactivos y de red usan Kerberos, no NTLM. Los eventos Kerberos se registran en el controlador de dominio, no en la máquina destino, por lo que su ausencia en el DC durante una ventana de movimiento lateral sospechoso es en sí misma informativa (indicaría NTLM, más propio de pass-the-hash).
| Event ID | Nombre | Uso en IR |
|---|---|---|
| 4768 | TGT solicitado (AS-REQ / Authentication Service) | El cliente pide su Ticket Granting Ticket inicial. Un 4768 con Certificate Information vacío y Pre-Authentication Type 2 (contraseña) es lo normal. Múltiples 4768 para la misma cuenta desde IPs distintas en pocos minutos sugiere credenciales comprometidas usadas desde varios puntos. |
| 4769 | TGS solicitado (Service Ticket Request) | El cliente ya tiene TGT y pide acceso a un servicio concreto (SPN). Es el evento clave para detectar Kerberoasting: múltiples 4769 con Ticket Encryption Type 0x17 (RC4) para SPNs de cuentas de servicio, solicitados en ráfaga por un mismo usuario que normalmente no accede a esos servicios. |
| 4771 | Fallo de pre-autenticación Kerberos | Equivalente Kerberos del 4625. El campo Failure Code 0x18 indica contraseña incorrecta (fuerza bruta); 0x6 indica usuario desconocido; 0x25 indica reloj desincronizado. |
Dos anomalías Kerberos que todo analista de FOR500/FOR508 debe saber leer:
- Golden Ticket: un 4768/4769 con un tiempo de vida del ticket (Ticket Options) anormalmente largo, o cuentas cuyo RID no corresponde a ningún objeto real de AD, o ausencia total del 4768 previo esperado (el ticket se forjó offline con el hash krbtgt y nunca hubo petición de AS-REQ legítima).
- Silver Ticket: aparece un 4624 Type 3 con Kerberos válido para acceder a un servicio, pero no existe el 4769 correspondiente en el controlador de dominio — porque el ticket de servicio se forjó con el hash de la cuenta de servicio sin pasar por el KDC. Esta ausencia de correlación 4769→4624 es la huella principal.
3. Creación de procesos: el 4688 como pegamento de la línea temporal
El Event ID 4688 (A new process has been created) requiere habilitar Audit Process Creation y, para que sea realmente útil, la directiva Include command line in process creation events (GPO: Administrative Templates → System → Audit Process Creation), que añade el campo Process Command Line. Sin esta línea de comandos, el 4688 solo dice qué ejecutable corrió, no con qué parámetros — y en el 90% de los incidentes lo decisivo está en los parámetros.
Campos clave del 4688:
- New Process Name y Creator Process Name: permiten reconstruir el árbol de procesos (¿quién es el padre de
powershell.exe? Si eswmiprvse.exeoservices.exe, es indicativo de ejecución remota). - Process Command Line: aquí aparecen los comandos ofuscados, flags
-encde PowerShell, rutas UNC aADMIN$, nombres de servicios temporales de PsExec, etc. - Token Elevation Type: indica si el proceso corrió con un token completo (TokenElevationTypeFull) propio de una sesión administrativa ya elevada, coherente con un 4672 previo.
La correlación de oro es: 4624 (Logon ID X) → 4672 (mismo Logon ID, privilegios especiales) → 4688 (mismo Logon ID, proceso hijo del logon). Si ves un 4688 con línea de comandos sospechosa pero no puedes encontrar su Logon ID en un 4624 reciente, el proceso puede venir de una sesión ya cerrada, de una tarea programada (Logon Type 4) o de una técnica que evita el logon estándar (inyección, WMI sin nueva sesión visible).
4. Movimiento lateral: técnica por técnica
Cada herramienta de movimiento lateral deja una combinación de artefactos característica. Memorizar esta tabla es, junto con los Logon Types, el contenido más rentable de todo el módulo.
| Técnica | Artefactos / Event IDs clave | Detalle |
|---|---|---|
| PsExec (Sysinternals) | 4624 Type 3 (SMB a ADMIN$) → 7045 (nuevo servicio) → 4697 (instalación de servicio, si se audita) → 4688 (PSEXESVC.exe) → 4624 Type 3 adicional para el pipe con nombre \pipepsexecsvc |
PsExec copia el binario PSEXESVC.exe vía SMB a \hostADMIN$, crea un servicio temporal (visible en 7045 con Service Name = PSEXESVC por defecto, aunque puede renombrarse con -r), lo arranca (Logon Type 5) y se comunica por una named pipe. El artefacto más citado en cursos SANS es precisamente el 7045 con nombre de servicio efímero e Image Path apuntando a una ruta temporal en %SystemRoot%. |
| WMI (wmic / Invoke-WmiMethod / Impacket wmiexec) | 4624 Type 3 → proceso hijo de WmiPrvSE.exe en 4688 → eventos ETW de WMI-Activity (Microsoft-Windows-WMI-Activity/Operational, ID 5857-5861) |
No crea servicio ni copia binario a disco (fileless en muchos casos), lo que la hace más sigilosa que PsExec. El indicador principal es un proceso inusual (cmd.exe, powershell.exe) cuyo Creator Process Name es WmiPrvSE.exe combinado con un logon de red inmediatamente anterior sin sesión interactiva. |
| WinRM / PowerShell Remoting (Enter-PSSession, Invoke-Command) | 4624 Type 3 (puertos 5985/5986) → Microsoft-Windows-PowerShell/Operational 4103 (ejecución de pipeline) y 4104 (Script Block Logging) → 4688 de wsmprovhost.exe |
El tráfico va sobre WS-Management (HTTP 5985 / HTTPS 5986). El proceso host wsmprovhost.exe como padre de comandos es la firma de PSRemoting. El 4104 con contenido de script completo es la evidencia más valiosa si el nivel de Script Block Logging captura bloques marcados como sospechosos. |
| RDP (Remote Desktop / Terminal Services) | 4624 Type 10 en el destino → logs Microsoft-Windows-TerminalServices-RemoteConnectionManager/Operational (ID 1149, conexión de red aceptada) y Microsoft-Windows-TerminalServices-LocalSessionManager/Operational (ID 21 inicio de sesión, ID 24 desconexión, ID 25 reconexión) |
El 1149 registra el intento de conexión RDP con IP origen antes de que se complete la autenticación, por lo que aparece incluso si el logon falla después. El ID 21/24/25 del LocalSessionManager permite reconstruir la duración exacta de la sesión gráfica remota. |
| Pass-the-Hash | 4624 Type 3 con Authentication Package = NtLmSsp, Key Length = 0, sin 4768/4769 Kerberos correspondiente en el DC | El atacante nunca conoce la contraseña en texto claro, solo el hash NTLM, así que el logon siempre usa NTLM y nunca Kerberos, aunque el entorno lo soporte. Es un patrón anómalo cuando el resto del tráfico de la organización es mayoritariamente Kerberos. |
| Pass-the-Ticket | 4624 Type 3 o 10 con Kerberos válido, pero el 4769 previo en el DC no coincide en tiempo, IP origen o número de veces esperado; tickets reutilizados en máquinas distintas en ventanas de tiempo imposibles para un usuario humano | Se exporta un ticket Kerberos legítimo (con Mimikatz sekurlsa::tickets o Rubeus) y se inyecta en otra sesión/máquina. La anomalía se detecta por incoherencia entre el origen físico esperado del usuario y el origen real de las peticiones TGS, o por el mismo Logon ID/ticket apareciendo en hosts distintos casi simultáneamente. |
5. Persistencia sobre cuentas: 4720, 4728, 4732, 4738
Tras moverse lateralmente, el atacante a menudo crea o modifica cuentas para asegurar el acceso futuro sin depender de la vulnerabilidad inicial.
| Event ID | Nombre | Relevancia |
|---|---|---|
| 4720 | Cuenta de usuario creada | Nueva cuenta local o de dominio. Revisar quién la creó (Subject) y si el nombre imita convenciones legítimas (cuentas de servicio falsas, nombres con typosquatting de IT). |
| 4728 | Miembro añadido a grupo global habilitado para seguridad | Escalado a grupos como Domain Admins. Correlacionar con el Subject para saber quién ejecutó el cambio y si su sesión venía de un 4624 sospechoso. |
| 4732 | Miembro añadido a grupo local habilitado para seguridad | Añadir una cuenta al grupo local Administradores de una máquina concreta — persistencia local típica tras PsExec/WMI. |
| 4738 | Cuenta de usuario modificada | Cambios de atributos (habilitar cuenta deshabilitada, quitar expiración, cambiar SID History). Buscar el patrón «cuenta legacy deshabilitada que de repente se modifica y se usa». |
6. Extracción y triaje de EVTX a escala
En un incidente real no se revisan eventos uno a uno desde el Visor de eventos: se exportan y se procesan con herramientas de línea de comandos. A continuación, el flujo de trabajo estándar en un FOR500/FOR508.
6.1 wevtutil — extracción nativa sin instalar nada
# Exportar el canal Security completo a un archivo EVTX en otra ubicación
wevtutil epl Security C:IRSecurity_export.evtx
# Consultar en vivo solo los logons interactivos y RDP exitosos (Type 2 y 10)
wevtutil qe Security /q:"*[System[(EventID=4624)] and EventData[Data[@Name='LogonType']='10' or Data[@Name='LogonType']='2']]" /f:text /c:50
# Filtrar únicamente eventos de movimiento lateral relevantes (4624, 4625, 4648, 4672, 4688) en una ventana concreta
wevtutil qe Security /q:"*[System[(EventID=4624 or EventID=4625 or EventID=4648 or EventID=4672 or EventID=4688) and TimeCreated[@SystemTime>='2026-06-28T00:00:00' and @SystemTime<='2026-06-30T23:59:59']]]" /f:text
# Ver los eventos de creación de servicios (7045) que suele dejar PsExec
wevtutil qe System /q:"*[System[(EventID=7045)]]" /f:text /c:20
6.2 EvtxECmd (Eric Zimmerman) — conversión a CSV/JSON para análisis masivo
# Convertir un EVTX a CSV con todos los mapas de campos conocidos (incluye Logon Type ya traducido)
EvtxECmd.exe -f Security.evtx --csv C:IRout --csvf security_parsed.csv
# Procesar un directorio completo de EVTX exportados de varios hosts
EvtxECmd.exe -d C:IRevtx_collected --csv C:IRout --csvf all_hosts.csv
# Generar además una línea temporal en formato JSON para importar en Timeline Explorer
EvtxECmd.exe -f Security.evtx --json C:IRout
El CSV de EvtxECmd resuelve automáticamente el Logon Type numérico a su nombre (Network, RemoteInteractive, etc.), lo que agiliza muchísimo el pivotaje en Timeline Explorer o Excel con tablas dinámicas por LogonType + TargetUserName + IpAddress.
6.3 Chainsaw — hunting dirigido por reglas Sigma
# Búsqueda genérica de eventos de logon interesantes con detección de reglas integradas
chainsaw hunt C:IRevtx_collected --sigma C:sigmarules --mapping C:chainsawmappingssigma-event-logs-all.yml -o C:IRchainsaw_results.csv
# Caza específica de movimiento lateral (PsExec, WMI, RDP) usando las reglas "lateral_movement" de Sigma
chainsaw hunt C:IRevtx_collected --sigma C:sigmaruleswindowslateral_movement -o C:IRlateral_hits.csv --csv
# Búsqueda de texto libre por línea de comandos sospechosa dentro de todos los EVTX
chainsaw search "psexec" -i C:IRevtx_collected --ignore-case
# Extraer solo los eventos de logon fallidos agrupados por IP de origen
chainsaw hunt C:IRevtx_collected --sigma C:sigmaruleswindowsbuiltinsecuritywin_security_susp_failed_logons_explicit_credentials.yml
6.4 Hayabusa — detección rápida orientada a Windows Event Log con reglas propias
# Análisis completo de un directorio de EVTX con salida de resultados por severidad
hayabusa.exe csv-timeline -d C:IRevtx_collected -o C:IRhayabusa_timeline.csv
# Filtrar solo alertas de nivel alto/crítico relacionadas con movimiento lateral y logons anómalos
hayabusa.exe csv-timeline -d C:IRevtx_collected -m high -o C:IRhayabusa_high.csv
# Generar un resumen de métricas (qué Event IDs y qué reglas se han disparado más)
hayabusa.exe metrics -d C:IRevtx_collected -o C:IRhayabusa_metrics.csv
6.5 DeepBlueCLI — módulo PowerShell centrado en el Security log
# Analizar el log Security en vivo del sistema local
.DeepBlue.ps1 -log security
# Analizar un EVTX exportado, mostrando específicamente anomalías de logon y creación de cuentas
.DeepBlue.ps1 -file C:IRSecurity_export.evtx
# Analizar el log de PowerShell operacional (útil para correlacionar 4103/4104 tras WinRM)
.DeepBlue.ps1 -log powershell
DeepBlueCLI está pensado para ejecutarse directamente en Windows sin dependencias externas, y su valor añadido es que ya trae heurísticas para detectar contraseñas largas/sospechosas en línea de comandos, uso de certutil para descargar payloads y patrones de fuerza bruta por volumen de 4625.
7. Laboratorio: detectar un PsExec simulado en la VM del curso
Objetivo: en tu máquina virtual Windows Server del laboratorio (con Advanced Audit Policy activada para Logon/Logoff, Account Management y Process Creation, e idealmente Sysmon instalado), vas a simular un movimiento lateral con PsExec desde una segunda VM atacante y detectarlo únicamente a partir de los EVTX.
- Preparación: confirma en la VM víctima que
auditpol /get /category:"Logon/Logoff","Account Management","Detailed Tracking"muestra Success and Failure en las subcategorías relevantes. Verifica también que la GPO Include command line in process creation events está habilitada (gpresult /ro revisando el registro enHKLMSOFTWAREMicrosoftWindowsCurrentVersionPoliciesSystemAuditProcessCreationIncludeCmdLine_Enabled). - Ataque simulado: desde la VM atacante, con credenciales de administrador de dominio de laboratorio, ejecuta
PsExec.exe \VICTIMA -u LABadmin -p ******** cmd.exe /c whoami /all. - Recolección: en la VM víctima, exporta Security y System con
wevtutil epl Security C:IRSecurity.evtxywevtutil epl System C:IRSystem.evtx. - Triaje con EvtxECmd: convierte ambos EVTX a CSV y busca, en orden cronológico: un 4624 Type 3 desde la IP de la VM atacante, seguido de un 7045 en System.evtx con un Service Name de aspecto aleatorio o igual a
PSEXESVC, seguido de un 4688 cuyo New Process Name seacmd.exey cuyo Creator Process Name seaPSEXESVC.exe. - Verificación con Chainsaw: ejecuta
chainsaw hunt C:IR --sigma C:sigmaruleswindowslateral_movement -o C:IRresultado.csvy confirma que al menos una regla de la familia «PsExec Service Installation» o «Suspicious Service Installation» se ha disparado. - Entregable del laboratorio: documenta el Logon ID del 4624 inicial y demuestra, uniendo por ese Logon ID, la cadena completa 4624 → 7045 → 4688 → 4634/4647 de cierre, junto con la línea de comandos ejecutada (
whoami /all) extraída del 4688.
8. Errores comunes al analizar autenticación
- Ignorar el Logon Type: tratar todos los 4624 como «un usuario inició sesión» sin distinguir Type 2 de Type 3 o Type 10 lleva a falsos negativos graves (un Type 3 masivo hacia decenas de hosts en minutos es lateral movement, no actividad normal de usuario) y a falsos positivos (un Type 5 de servicio no es una persona conectándose).
- No correlacionar 4624 con 4672: si no cruzas ambos eventos por Logon ID, no sabrás si la sesión obtuvo privilegios especiales, perdiendo la señal de que un atacante escaló durante esa misma sesión.
- Analizar el Security log de la máquina destino sin revisar el controlador de dominio: los eventos Kerberos (4768/4769/4771) solo existen en el DC. Sin esa correlación cruzada, un Pass-the-Ticket o un Golden Ticket pasan desapercibidos.
- No habilitar la línea de comandos en 4688: sin esta GPO, el 4688 solo confirma qué se ejecutó, no con qué parámetros — perdiendo justo la evidencia más incriminatoria en la mayoría de los casos.
- Confundir 4634 con 4647 y asumir que su ausencia significa que la sesión sigue abierta: un logoff puede no registrarse limpiamente si el proceso termina abruptamente (crash, corte de red), así que la ausencia de cierre no es prueba concluyente de sesión activa.
- Buscar solo el Event ID de PsExec y olvidar WMI/WinRM: cada herramienta de movimiento lateral tiene una firma distinta; construir la detección solo sobre 7045 deja ciego al analista frente a wmiexec o Invoke-Command.
9. Ejercicio
Se te entrega un export de Security.evtx de un host Windows Server que formaba parte de un dominio. Un usuario del equipo de operaciones reporta que el servidor de ficheros «se comportó raro» durante la noche. En el EVTX encuentras:
- 23:14:02 — 4625, TargetUserName=svc-backup, SubStatus=0xC000006A, IpAddress=10.10.5.44 (repetido 6 veces entre 23:14 y 23:15)
- 23:15:10 — 4624, LogonType=3, TargetUserName=svc-backup, AuthenticationPackage=NtLmSsp, IpAddress=10.10.5.44, Logon ID=0x3A9F21
- 23:15:11 — 4672, Logon ID=0x3A9F21, privilegios: SeDebugPrivilege, SeBackupPrivilege
- 23:15:14 — (System.evtx) 7045, Service Name=NqRstV, Image Path=%SystemRoot%NqRstV.exe
- 23:15:15 — 4688, New Process Name=NqRstV.exe, Creator Process Name=services.exe, Logon ID=0x3A9F21
- 23:15:16 — 4688, New Process Name=cmd.exe, Command Line=»cmd.exe /c whoami & net user hacker P@ssw0rd123! /add», Creator Process Name=NqRstV.exe
- 23:15:17 — 4720, New Account=hacker, Subject=SYSTEM
- 23:15:18 — 4732, Member Added, Group=Administradores, New Account=hacker
Preguntas: (1) ¿Qué SubStatus del 4625 indica que se trató de fuerza bruta contra una única cuenta, y por qué esa cuenta concreta (svc-backup) es un objetivo lógico para un atacante? (2) Clasifica la técnica de movimiento lateral empleada y justifica tu respuesta con al menos tres artefactos de la lista. (3) ¿Por qué el uso de NTLM en lugar de Kerberos, visible en AuthenticationPackage=NtLmSsp, es en sí mismo un indicador adicional en un dominio donde Kerberos está disponible? (4) Redacta, con estos datos, la línea temporal de persistencia final que dejó el atacante.
Preguntas frecuentes
¿Por qué el Event ID 4624 Type 3 aparece tantas veces en un servidor de ficheros aunque no haya ningún ataque?
Porque el Logon Type 3 (Network) es el que se genera de forma legítima cada vez que un usuario o un servicio accede a un recurso compartido SMB, imprime en una impresora de red o consulta un recurso vía RPC. En un servidor de ficheros esto ocurre miles de veces al día. La clave no es la presencia del Type 3, sino el volumen anómalo, el origen inesperado (una IP o cuenta que nunca antes había accedido) o su combinación inmediata con un 7045 o un 4688 sospechoso.
¿Se puede confiar en el campo IpAddress del 4624 si el atacante usa un proxy o pivota por varios saltos?
El IpAddress solo refleja el salto inmediatamente anterior, es decir, la IP de la máquina que estableció la conexión SMB/RDP/WinRM directamente contra el host auditado. Si el atacante pivota (por ejemplo, RDP a un host intermedio y desde ahí PsExec a un tercero), tendrás que reconstruir la cadena host por host, correlacionando el 4624 de salida en el host intermedio (visible como 4648 o como conexión saliente en el firewall/Sysmon Event ID 3) con el 4624 de entrada en el host final.
¿Qué diferencia hay entre auditar «Logon Events» y «Account Logon Events» en la política de auditoría clásica?
Es una confusión histórica de Windows: Logon/Logoff (categoría «Logon Events») registra los inicios y cierres de sesión en el propio equipo donde ocurre el acceso (los 4624/4625/4634 que hemos visto). Account Logon (a veces llamada «Account Logon Events») registra la validación de credenciales, que en un dominio ocurre en el controlador de dominio vía Kerberos (4768/4769/4771) o, en logons locales/legacy, vía NTLM. Para una investigación completa necesitas ambas categorías activas, tanto en los hosts finales como en los controladores de dominio.
¿Por qué Sysmon no sustituye a los Security Event Logs de Windows en este módulo?
Sysmon aporta detalle adicional excelente (Event ID 1 con hash del proceso, Event ID 3 de conexiones de red salientes, Event ID 8 de creación remota de hilos), pero no genera los eventos de autenticación nativos: el 4624, el 4625, el 4768 y el 4769 son generados exclusivamente por LSASS/Netlogon y auditados por la política nativa de Windows, no por Sysmon. En un caso real, Sysmon complementa —no reemplaza— la lectura del canal Security.
¿Es fiable el nombre del servicio en el 7045 para identificar siempre PsExec?
No de forma aislada. Herramientas como PsExec, y también sus imitaciones (Impacket psexec.py, CrackMapExec, Metasploit psexec) permiten renombrar el servicio y el ejecutable, así que basarse solo en el literal PSEXESVC genera falsos negativos frente a atacantes que cambian el nombre. Por eso el análisis robusto combina el 7045 con el patrón completo: Image Path apuntando a una carpeta temporal o poco habitual, el 4688 hijo del servicio recién creado y el 4624 Type 3/5 inmediatamente anteriores desde un origen de red.
«Logon type 3 – Network: A user or computer logged on to this computer from the network. […] This is the type of logon that occurs when accessing shared folders or printers, or via most types of logons to IIS.» — Microsoft Learn, «4624(S): An account was successfully logged on»