Un atacante con ejecución en un solo endpoint todavía no tiene nada que valga la pena robar: necesita una credencial que sirva en otra máquina, y para conseguirla tiene que tocar el sitio donde Windows las guarda en memoria. Ese paso, robar una credencial y reutilizarla en otro equipo, es el que separa un incidente contenido en un puesto de un compromiso de dominio, y también el que más señales deja si se sabe dónde mirar. El problema para quien escribe la regla es que casi todas esas señales las genera también el uso legítimo del sistema: un antivirus abre lsass.exe igual que Mimikatz, un administrador usa PsExec igual que un atacante, y una tarea programada presenta credenciales explícitas igual que un script de copia de seguridad.
Este módulo se queda deliberadamente en la detección: qué evento activar, qué campo mirar y qué regla escribir cuando alguien intenta llevarse una credencial o saltar de una máquina a otra. El bastionado que reduce la superficie real de este tipo de ataque (Protected Users, LAPS, gMSA, delegación restringida, AD CS) pertenece al curso de Defensa de Active Directory, y la reconstrucción forense completa de un movimiento lateral ya confirmado, con línea temporal y alcance, es del curso de DFIR.
Qué aprenderás
- Qué mide el campo
GrantedAccessdel evento 10 de Sysmon y por qué una regla de acceso a LSASS se escribe sobre esa máscara y no sobre el nombre del proceso. - Qué procesos legítimos generan ruido al abrir
lsass.exe, con un ejemplo real documentado por Microsoft. - Qué eventos deja en el Visor de eventos la regla de reducción de superficie de ataque contra el robo de credenciales de LSASS, y por qué su modo auditoría es una fuente de detección aunque no bloquee nada.
- Qué combinación de tipos de inicio de sesión (3, 9 y 10) dibuja un salto lateral en el 4624, y qué campos de red son los que realmente aportan.
- Por qué el 4648 (uso de credenciales explícitas) es de las señales más infravaloradas en un SOC.
- Qué eventos Kerberos genera un TGT y un ticket de servicio, qué tipo de cifrado delata una degradación deliberada, y cómo se ve una petición masiva de tickets.
- Qué huella dejan PsExec, WMI y WinRM en named pipes, servicios y procesos remotos, y por qué esa huella siempre tiene ruido de fondo legítimo.
- Cómo se detecta el volcado del registro (SAM, SECURITY, SYSTEM) y el acceso a esas mismas colmenas a través de una copia de sombra.
- Por qué, con una cuenta de servicio, la línea base pesa más que cualquier firma.
Acceso a la memoria de LSASS: el evento 10 de Sysmon
El proceso lsass.exe (Local Security Authority Subsystem Service) guarda en memoria los materiales de autenticación de las sesiones activas: hashes NTLM, claves de Kerberos y, en ciertas condiciones, contraseñas en claro. Leer esa memoria es la vía directa de T1003.001, LSASS Memory, la sub-técnica de T1003, OS Credential Dumping, y es también el gesto que herramientas como Mimikatz, Procdump o el propio Administrador de tareas comparten cuando se les pide un volcado de proceso.
Sysmon documenta el evento 10 así, en la página oficial de Sysinternals: «the process accessed event reports when a process opens another process, an operation that’s often followed by information queries or reading and writing the address space of the target process», y añade que habilitarlo «can generate significant amounts of logging if there are diagnostic utilities active that repeatedly open processes to query their state, so it generally should only be done so with filters that remove expected accesses» (Sysmon – Sysinternals, Microsoft Learn, publicada el 17 de junio de 2026). Esa segunda frase es la que explica por qué nadie despliega el evento 10 sin filtro: cualquier apertura de proceso lo dispara, y en un endpoint corriente hay decenas por minuto.
Por qué GrantedAccess y no el nombre del proceso
El evento incluye, entre otros, los campos SourceImage, TargetImage, GrantedAccess y CallTrace (según la referencia de campos de Ultimate Windows Security para este evento, que documenta el esquema con más detalle del que publica la página general de Sysmon). GrantedAccess es la máscara de acceso, en hexadecimal, que el sistema operativo concedió realmente a quien abrió el proceso; es un valor que depende de qué permisos pidió el llamador (leer memoria, escribirla, crear un hilo remoto) y no de qué nombre lleve su ejecutable. Ahí está la razón de fondo para no escribir la regla como «avisa si algo que no sea antivirus.exe abre lsass.exe»: ese filtro lo rompe cualquiera que copie mimikatz.exe a svchost.exe o que cargue el mismo código desde PowerShell reflejado en memoria. La máscara de acceso, en cambio, la fija la API que se llama (típicamente MiniDumpWriteDump o las funciones de lectura de memoria de proceso), y eso cambia mucho menos.
La regla pública que mejor ilustra esto es la de SigmaHQ para credential dumping vía LSASS, mantenida por Samir Bousseaden y Michael Haag y modificada el 29 de junio de 2026 según su cabecera:
title: Potential Credential Dumping Activity Via LSASS
id: 5ef9853e-4d0e-4a70-846f-a9ca37d876da
status: test
description: |
Detects process access requests to the LSASS process with specific call trace calls and access masks.
This behaviour is expressed by many credential dumping tools such as Mimikatz, NanoDump, Invoke-Mimikatz, Procdump and even the Taskmgr dumping feature.
author: Samir Bousseaden, Michael Haag
date: 2019-04-03
modified: 2026-06-29
tags:
- attack.credential-access
- attack.t1003.001
logsource:
category: process_access
product: windows
detection:
selection:
TargetImage|endswith: 'lsass.exe'
GrantedAccess|contains:
- '0x1038'
- '0x1438'
- '0x143a'
- '0x1fffff' # Too many false positives
# - '0x01000' # Too many false positives
# - '0x1010' # Too many false positives
# - '0x1400' # Too many false positives
# - '0x1410' # Too many false positives
# - '0x40' # Too many false positives
CallTrace|contains:
- 'dbgcore.dll'
- 'dbghelp.dll'
- 'kernel32.dll'
- 'kernelbase.dll'
- 'ntdll.dll'
condition: selection and not 1 of filter_main_* and not 1 of filter_optional_*
falsepositives:
- Unknown
level: medium(Regla completa y filtros de exclusión en el repositorio de SigmaHQ, licencia DRL 1.1, atribución a Samir Bousseaden y Michael Haag.)
Fíjate en los comentarios: 0x1010, 0x1400, 0x1410 y 0x40 están dentro de la lista pero comentados, con la nota «too many false positives» puesta por los propios autores de la regla. Eso es información operativa real, no solo sintaxis: esas máscaras las piden con frecuencia procesos que solo quieren consultar el estado de lsass.exe (PROCESS_QUERY_INFORMATION, lectura básica de memoria), y los mantenedores de la regla decidieron que el coste de revisar esas alertas superaba el valor de la detección. La regla activa se queda con las máscaras que, junto con conceder lectura de memoria, coinciden con el rastro de llamadas (CallTrace) de las bibliotecas que usa la API de volcado de procesos de Windows: eso es lo que separa «algo consultó el proceso» de «algo se comportó como una herramienta de volcado».
Quién más toca LSASS
La propia documentación de Microsoft sobre la regla de reducción de superficie de ataque equivalente (que se ve en la siguiente sección) da un ejemplo concreto de ruido legítimo: «Google Chrome updates unnecessarily access LSASS, because passwords are stored in LSASS on the device» (ASR rules reference, Microsoft Learn, 2 de julio de 2026). A eso hay que sumar el propio Sysmon o cualquier otro sensor EDR (que necesita leer lsass.exe para su propia telemetría), utilidades de diagnóstico como Process Explorer, y agentes de sincronización de contraseñas tipo Azure AD Connect. Ninguno de ellos aparece en la lista de exclusión por nombre en la regla anterior porque la regla no filtra por nombre: los deja fuera la combinación de máscara y rastro de llamadas, que en su caso no coincide con el patrón de volcado.
Telemetría de las reglas ASR de Microsoft Defender
Las reglas de reducción de superficie de ataque (Attack Surface Reduction, ASR) de Microsoft Defender Antivirus se pueden desplegar en tres modos: bloqueo, auditoría y advertencia. La que interesa aquí es «Block credential stealing from the Windows local security authority subsystem», con GUID 9e6c4e1f-7d60-472f-ba1a-a39ef669e4b2 según la referencia oficial de reglas, que «helps prevent credential stealing by locking down the Local Security Authority Subsystem Service (LSASS)» y no admite modo advertencia (ASR rules reference, Microsoft Learn).
La misma página avisa de algo que conviene tomarse en serio antes de desplegarla en bloqueo: «this ASR rule produces a large volume of audit events, almost all of which are safe to ignore when the rule is enabled in Block mode». Es la contrapartida de vigilar un punto tan transitado: cualquier proceso que enumere procesos del sistema y pida permisos amplios sobre todos ellos (hay software de gestión y de seguridad que lo hace por diseño) va a generar un evento de auditoría contra esta regla sin que haya nada raro detrás.
Dónde caen los eventos y qué IDs buscar
Los eventos de las reglas ASR, incluida esta, se escriben en el canal Microsoft-Windows-Windows Defender/Operational. La documentación oficial de Microsoft para leerlos en el Visor de eventos da esta tabla:
| Event ID | Qué significa |
|---|---|
| 1121 | La regla disparó en modo bloqueo |
| 1122 | La regla disparó en modo auditoría |
| 1129 | El usuario descartó el bloqueo en modo advertencia |
| 5007 | Cambió la configuración de la regla |
(Fuente: Attack surface reduction events in Windows Event Viewer, Microsoft Learn, 2 de julio de 2026.)
El 1122 es la razón por la que el modo auditoría vale como fuente de detección aunque no impida nada: un SOC que todavía no puede permitirse desplegar esta regla en bloqueo en todo el parque (porque rompería alguna aplicación de línea de negocio, por ejemplo) puede seguir activando la auditoría en todas partes y alertar sobre el 1122 en los activos de nivel más alto mientras dura la fase de ajuste. Es telemetría gratis de un motor que ya corre en el endpoint, complementaria a Sysmon: la regla ASR ve el intento a nivel de Defender Antivirus, con su propio catálogo de procesos de confianza, mientras que el evento 10 de Sysmon ve la llamada al nivel del sistema operativo.
Para revisar rápido si hay eventos de esta regla en un equipo de laboratorio:
wevtutil qe "Microsoft-Windows-Windows Defender/Operational" /q:"*[System[(EventID=1121 or EventID=1122)]]" /f:text /c:20 > C:soc-labasr-lsass.txtInicios de sesión: los logon types que dibujan un salto lateral
El 4624 y sus tipos de inicio de sesión ya se han visto con el resto de la política de auditoría avanzada. Aquí interesa un subconjunto muy concreto: los tres tipos que, combinados en secuencia, son la firma más habitual de un movimiento lateral. Según la tabla oficial de logon types de Microsoft:
| Logon Type | Nombre | Descripción oficial |
|---|---|---|
| 3 | Network | «A user or computer logged on to this computer from the network.» |
| 9 | NewCredentials | «A caller cloned its current token and specified new credentials for outbound connections. The new logon session has the same local identity, but uses different credentials for other network connections.» |
| 10 | RemoteInteractive | «A user logged on to this computer remotely using Terminal Services or Remote Desktop.» |
(4624(S) An account was successfully logged on, Microsoft Learn, árbol archivado, ms.date 7 de septiembre de 2021.)
El tipo 3 es el que más aparece en un salto lateral clásico: PsExec, WMI y el acceso a recursos administrativos por SMB autentican así en la máquina destino, así que una cuenta que genera 4624 tipo 3 en varios hosts distintos en una ventana corta de tiempo dibuja exactamente el patrón «saltar de equipo en equipo». El tipo 10 hace lo mismo para RDP. El tipo 9 es el más particular de los tres: su descripción oficial dice literalmente que la nueva sesión «has the same local identity, but uses different credentials for other network connections», que es justo el mecanismo detrás de runas /netonly y del sekurlsa::pth de Mimikatz para T1550.002, Pass the Hash: el proceso que arranca localmente sigue siendo, a efectos de sesión, quien lo lanzó, pero cualquier conexión saliente de ese proceso usa el hash robado. El repositorio EVTX-ATTACK-SAMPLES, ya presentado en el módulo de laboratorio, tiene un fichero dedicado justo a eso, LM_4624_mimikatz_sekurlsa_pth_source_machine.evtx, en su carpeta Lateral Movement: el 4624 tipo 9 que queda registrado en la máquina origen cuando se ejecuta ese ataque, no en la máquina destino.
De los campos del evento, los dos que de verdad aportan para reconstruir un salto son la dirección de red de origen (Source Network Address, vacía o local en un tipo 9 porque la conexión sale después) y el proceso de logon. Ese campo, según la referencia de campos que mantiene Ultimate Windows Security para este evento, vale «Kerberos» cuando la autenticación fue Kerberos y «NtLmSsp» cuando fue NTLM; combinado con el campo Authentication Package (que la documentación oficial de Microsoft sí confirma con los valores «NTLM», «Kerberos» y «Negotiate»), dice con qué protocolo llegó la sesión, lo que importa por ejemplo para saber si un salto usó tickets Kerberos legítimos o un hash NTLM reutilizado.
Uso de credenciales explícitas: el 4648
El 4648 se genera, según la documentación oficial, «when a process attempts an account logon by explicitly specifying that account’s credentials», algo habitual en tareas programadas, en runas y en scripts de automatización (4648(S) A logon was attempted using explicit credentials, Microsoft Learn, archivado, ms.date 7 de septiembre de 2021). Trae dos identidades separadas, el Subject (quién lanzó la petición) y la Account Whose Credentials Were Used (la cuenta prestada), más el Target Server Name y la información de red del destino.
Está infravalorado porque, a diferencia del 4624, se genera en la máquina de origen antes de que salga ningún tráfico, con lo que aparece un paso antes que cualquier otra señal de red. Una cuenta de administrador de dominio cuyo Subject sea un usuario estándar, o cuyo Target Server Name apunte a un servidor con el que esa cuenta nunca ha hablado, es una desviación que el 4648 detecta sola, sin necesidad de correlacionar todavía nada más. El hilo de correlación es el Logon GUID, que enlaza este evento con el 4624 de la máquina destino y, si el salto siguió por Kerberos, con el 4769 que quedó en el controlador de dominio.
wevtutil qe Security /q:"*[System[(EventID=4648)]]" /f:text /c:20 > C:soc-labcredenciales-explicitas.txtKerberos desde el punto de vista del SOC
Un controlador de dominio genera dos eventos por cada paso de la autenticación Kerberos que interesa a un SOC, y los dos se generan solo ahí, nunca en el endpoint: el 4768 cuando el KDC emite un Ticket Granting Ticket (TGT), y el 4769 cuando emite un ticket de servicio (TGS) a partir de ese TGT. Los dos comparten un campo que merece vigilancia constante, Ticket Encryption Type, con esta tabla de valores documentada por Microsoft:
| Valor | Algoritmo | Nota oficial |
|---|---|---|
| 0x1 | DES-CBC-CRC | Deshabilitado por defecto desde Windows 7 / Server 2008 R2 |
| 0x3 | DES-CBC-MD5 | Deshabilitado por defecto desde Windows 7 / Server 2008 R2 |
| 0x11 | AES128-CTS-HMAC-SHA1-96 | Soportado desde Windows Server 2008 / Vista |
| 0x12 | AES256-CTS-HMAC-SHA1-96 | Soportado desde Windows Server 2008 / Vista |
| 0x17 | RC4-HMAC | Suite por defecto antes de Windows Server 2008 / Vista |
| 0x18 | RC4-HMAC-EXP | Suite por defecto antes de Windows Server 2008 / Vista |
(Fuentes: evento 4769 y Detect and Remediate RC4 Usage in Kerberos, Microsoft Learn, esta última actualizada el 6 de febrero de 2026.)
Esa segunda página cambia el peso de esta señal justo este año: desde la actualización de noviembre de 2022 (respuesta a CVE-2022-37966), Windows ya no usa RC4 por defecto cuando una cuenta no tiene un tipo de cifrado explícito, sino AES-SHA1, y la propia página advierte de que Microsoft «plans to disable RC4 use as the default assumed supported encryption type for Active Directory domain controllers by the end of the second quarter of 2026». Eso quiere decir que, en un dominio ya migrado, ver 0x17 en un 4769 pesa cada vez más como anomalía y cada vez menos como ruido de compatibilidad heredada, porque cada vez hace falta más esfuerzo deliberado (o una cuenta realmente vieja sin rotar) para que aparezca.
Kerberoasting: cuando la degradación de cifrado es la técnica
T1558.003, Kerberoasting abusa exactamente de esto: cualquier cuenta autenticada puede pedir un ticket de servicio para cualquier SPN, y si consigue que ese ticket venga cifrado en RC4 en vez de AES, se lleva un objetivo mucho más barato de romper por fuerza bruta fuera de línea. La regla pública más citada para esta técnica es la de Florian Roth en SigmaHQ:
title: Suspicious Kerberos RC4 Ticket Encryption
id: 496a0e47-0a33-4dca-b009-9e6ca3591f39
status: test
description: Detects service ticket requests using RC4 encryption type
author: Florian Roth (Nextron Systems)
date: 2017-02-06
modified: 2022-06-19
tags:
- attack.credential-access
- attack.t1558.003
logsource:
product: windows
service: security
detection:
selection:
EventID: 4769
TicketOptions: '0x40810000'
TicketEncryptionType: '0x17'
reduction:
ServiceName|endswith: '$'
condition: selection and not reduction
falsepositives:
- Service accounts used on legacy systems (e.g. NetApp)
- Windows Domains with DFL 2003 and legacy systems
level: medium(Repositorio de SigmaHQ, licencia DRL 1.1, atribución a Florian Roth, Nextron Systems.)
La exclusión ServiceName|endswith: '$' descarta las cuentas de equipo (que terminan en $ y con frecuencia siguen usando RC4 por compatibilidad), quedándose con cuentas de usuario y de servicio, que son las que de verdad interesan en un ataque de Kerberoasting.
Una sola petición con RC4 puede ser ruido; una ráfaga de peticiones de tickets de servicio distintos en poco tiempo desde la misma cuenta es harina de otro costal, porque nadie necesita legítimamente decenas de SPN distintos en un par de minutos. Splunk lo aborda con un enfoque estadístico en vez de un umbral fijo, en su detección «Unusual Number of Kerberos Service Tickets Requested» (colección security_content, licencia Apache-2.0, autoría de Mauricio Velazco y Dean Luxton):
`wineventlog_security` EventCode=4769 ServiceName!="*$" TicketEncryptionType=0x17
| bucket span=2m _time
| stats dc(ServiceName) AS unique_services values(ServiceName) as requested_services values(user_category) as user_category values(src_category) as src_category values(dest) as dest BY _time, user, src
| eventstats avg(unique_services) as comp_avg , stdev(unique_services) as comp_std BY user, src
| eval upperBound=(comp_avg+comp_std*3)
| eval isOutlier=if(unique_services > 2 and unique_services >= upperBound, 1, 0)
| search isOutlier=1
| `unusual_number_of_kerberos_service_tickets_requested_filter`(Splunk Security Content, licencia Apache-2.0.)
Lo interesante de esta búsqueda no es el SPL en sí, sino la idea que codifica: en lugar de decidir a priori «más de N peticiones en M minutos es sospechoso», calcula la media y la desviación típica de servicios distintos pedidos por cada combinación de usuario y origen, y marca como atípico lo que se sale de esa media más tres desviaciones. Es la misma lógica de línea base que aparece más abajo para las cuentas de servicio, aplicada aquí a Kerberos.
Ejecución remota: named pipes, servicios, WMI y WinRM
Una vez que la credencial robada se reutiliza, hace falta ejecutar algo en la máquina destino, y cada herramienta habitual para eso deja su propio rastro.
Named pipes: los eventos 17 y 18 de Sysmon
Sysmon documenta el evento 17 (PipeEvent, Pipe Created) como el que «generates when a named pipe is created» y el 18 (Pipe Connected) como el que «logs when a named pipe connection is made between a client and a server» (Sysmon – Sysinternals, Microsoft Learn). PsExec y sus clones usan una tubería con nombre por defecto para comunicar el cliente con el servicio que instalan en remoto; SigmaHQ tiene una regla que se apoya justo en ese patrón, de Nasreddine Bencherchali:
title: PsExec Tool Execution From Suspicious Locations - PipeName
id: 41504465-5e3a-4a5b-a5b4-2a0baadd4463
status: test
description: Detects PsExec default pipe creation where the image executed is located in a suspicious location. Which could indicate that the tool is being used in an attack
author: Nasreddine Bencherchali (Nextron Systems)
date: 2022-08-04
modified: 2023-09-20
tags:
- attack.execution
- attack.t1569.002
logsource:
category: pipe_created
product: windows
detection:
selection:
PipeName: 'PSEXESVC'
Image|contains:
- ':UsersPublic'
- ':WindowsTemp'
- 'AppDataLocalTemp'
- 'Desktop'
- 'Downloads'
condition: selection
falsepositives:
- Rare legitimate use of psexec from the locations mentioned above. This will require initial tuning based on your environment.
level: medium(Repositorio de SigmaHQ, licencia DRL 1.1, atribución a Nasreddine Bencherchali, Nextron Systems.)
El nombre de la tubería por sí solo, PSEXESVC, no basta como regla: el PsExec legítimo de Sysinternals la genera igual. Combinarlo con dónde vive el ejecutable que la creó (carpetas de usuario, temporales, descargas) es lo que sube la confianza de que es un uso ofensivo y no el PsExec que ya tiene instalado el equipo de infraestructura.
Otras herramientas de post-explotación (Cobalt Strike entre ellas) generan tuberías con nombres que siguen los patrones de sus perfiles maleables. La regla de SigmaHQ para eso, de Florian Roth y Christian Burkard, tiene esta forma (lista de patrones abreviada; la regla completa incluye más prefijos y sus propios filtros):
title: CobaltStrike Named Pipe Patterns
id: 85adeb13-4fc9-4e68-8a4a-c7cb2c336eb7
status: test
description: Detects the creation of a named pipe with a pattern found in CobaltStrike malleable C2 profiles
author: Florian Roth (Nextron Systems), Christian Burkard (Nextron Systems)
date: 2021-07-30
modified: 2024-01-26
logsource:
product: windows
category: pipe_created
detection:
selection_malleable_profile_generic:
- PipeName|startswith:
- 'msrpc_'
- 'mypipe-f'
- 'mypipe-h'
- 'ntsvcs'
- 'scerpc'
- 'spoolss'
- 'win_svc'
- 'wkssvc'
filter_main_generic:
PipeName:
- 'wkssvc'
- 'spoolss'
- 'scerpc'
- 'ntsvcs'
condition: 1 of selection_malleable_profile_* and not 1 of filter_main_*
falsepositives:
- Chrome instances using the exact same pipe name "mojo.xxx"
- Some applications may just coincidentally use the pipe names which contain the same prefix as the ones used by CobaltStrike, e.g. "f4c3"
level: high(Repositorio de SigmaHQ, licencia DRL 1.1, atribución a Florian Roth y Christian Burkard, Nextron Systems.)
Fíjate en que el propio filtro excluye wkssvc, spoolss, scerpc y ntsvcs: son tuberías RPC que Windows crea de forma constante para servicios legítimos (la cola de impresión, el servicio de estación de trabajo) y que también coinciden con prefijos usados por Cobalt Strike. Es el mismo problema que las máscaras de LSASS: la superficie de coincidencia entre lo ofensivo y lo nativo del sistema operativo es real, y la regla tiene que descontarla explícitamente en vez de confiar en que no exista.
Servicios creados en remoto
PsExec instala, en la máquina destino, un servicio llamado por defecto PSEXESVC, lo que genera el 7045 en el registro System («A new service was installed in the system», ya visto como categoría de evento en el módulo de auditoría avanzada). SigmaHQ tiene una regla específica para ese nombre de servicio por defecto, de Thomas Patzke:
title: PsExec Service Installation
id: 42c575ea-e41e-41f1-b248-8093c3e82a28
status: test
description: Detects PsExec service installation and execution events
author: Thomas Patzke
date: 2017-06-12
modified: 2023-08-04
tags:
- attack.execution
- attack.t1569.002
logsource:
product: windows
service: system
detection:
selection_eid:
Provider_Name: 'Service Control Manager'
EventID: 7045
selection_service:
- ServiceName: 'PSEXESVC'
- ImagePath|endswith: 'PSEXESVC.exe'
condition: all of selection_*
falsepositives:
- Unknown
level: medium(Repositorio de SigmaHQ, licencia DRL 1.1, atribución a Thomas Patzke.)
Herramientas equivalentes que no pasan por el servicio de control de Windows dejan otra huella. El psexec.py de Impacket, por ejemplo, no crea el servicio PSEXESVC sino uno con nombre aleatorio, y usa un recurso compartido IPC$ con tuberías llamadas RemCom_stdin, RemCom_stdout y RemCom_stderr para mover la entrada y salida del comando. Con la subcategoría «Object Access > Audit Detailed File Share» activada (ya cubierta como parte de la auditoría avanzada), eso queda en el 5145:
title: Impacket PsExec Execution
id: 32d56ea1-417f-44ff-822b-882873f5f43b
status: test
description: Detects execution of Impacket's psexec.py.
author: Bhabesh Raj
date: 2020-12-14
modified: 2022-09-22
tags:
- attack.lateral-movement
- attack.t1021.002
logsource:
product: windows
service: security
detection:
selection1:
EventID: 5145
ShareName: '\\*\IPC$'
RelativeTargetName|contains:
- 'RemCom_stdin'
- 'RemCom_stdout'
- 'RemCom_stderr'
condition: selection1
falsepositives:
- Unknown
level: high(Repositorio de SigmaHQ, licencia DRL 1.1, atribución a Bhabesh Raj.)
WMI y WinRM
T1047, Windows Management Instrumentation, y T1021.006, Windows Remote Management, son los otros dos caminos habituales de ejecución remota, y los dos tienen un problema de documentación oficial: Microsoft no publica una tabla de referencia de los IDs de sus registros operativos como sí hace con la auditoría de seguridad o con las reglas ASR. Lo que sigue viene de fuentes de la comunidad, no de una página oficial de Microsoft, y conviene marcarlo así.
Según el blog de Carlos Perez (investigador de seguridad conocido por sus herramientas de post-explotación en PowerShell), el registro Microsoft-Windows-WMI-Activity/Operational incluye el evento 5857 cuando se carga un proveedor WMI (con el proceso y la ruta de la DLL que lo aloja), el 5860 cuando se registra un consumidor de eventos temporal y el 5861 cuando se crea o modifica uno permanente («Basics of Tracking WMI Activity», darkoperator.com, 14 de octubre de 2017). Para ejecución remota vía WMI (por ejemplo wmic /node: o el wmiexec.py de Impacket) el 5857 es el que más interesa, porque documenta que se cargó un proveedor en un host que normalmente no ejecuta consultas WMI remotas contra sí mismo. Lo más fiable en la práctica, en cualquier caso, sigue siendo el proceso hijo: WmiPrvSE.exe arrancando un intérprete de comandos o PowerShell es la señal que un Sysmon Event ID 1 con buen filtrado de padre-hijo va a capturar siempre, tenga o no activado el registro WMI-Activity.
Para WinRM, varias fuentes de la comunidad (entre ellas un análisis técnico de In.security sobre detección de movimiento lateral vía WinRM con KQL) coinciden en que el registro Microsoft-Windows-WinRM/Operational escribe el evento 91 en la máquina destino cuando llega una sesión entrante («when a WinRM connection is received EventID 91 is recorded», In.security, 3 de mayo de 2021); tampoco esto sale de una página de referencia de Microsoft, así que trátalo como observación consistente de varios investigadores y no como documentación oficial. Lo que sí es constante y sí conviene vigilar directamente es el proceso wsmprovhost.exe, que aloja la sesión remota en el destino: cualquier proceso hijo suyo es, por definición, algo que llegó por PowerShell remoto. El repositorio EVTX-ATTACK-SAMPLES tiene grabaciones reales de ambos patrones en su carpeta Lateral Movement, entre ellas LM_winrm_exec_sysmon_1_winrshost.evtx y LM_PowershellRemoting_sysmon_1_wsmprovhost.evtx.
Volcado de credenciales del registro y acceso a copias de seguridad
Las colmenas SAM, SECURITY y SYSTEM del registro guardan, entre otras cosas, los hashes de las cuentas locales y las claves con las que se cifran los secretos de LSA. T1003.002, Security Account Manager, las vuelca con el propio reg.exe del sistema, algo que el test de Atomic Red Team para esta técnica reproduce con tres líneas:
reg save HKLMsam %temp%sam
reg save HKLMsystem %temp%system
reg save HKLMsecurity %temp%security(Test «Registry dump of SAM, creds, and secrets», GUID 5c2571d0-1572-416d-9676-812e64ca9f44, Atomic Red Team, T1003.002, licencia MIT.)
La regla pública que detecta esto en la línea de comandos, de un grupo de autores encabezado por Teymur Kheirkhabarov, no se limita a buscar el texto exacto: comprueba variantes con caracteres unicode que se parecen visualmente a las letras normales (una técnica de evasión real, ya documentada en herramientas ofensivas, que intenta esquivar reglas que solo buscan la cadena literal):
title: Dumping of Sensitive Hives Via Reg.EXE
id: fd877b94-9bb5-4191-bb25-d79cbd93c167
status: test
description: Detects the usage of "reg.exe" in order to dump sensitive registry hives. This includes SAM, SYSTEM and SECURITY hives.
author: Teymur Kheirkhabarov, Endgame, JHasenbusch, Daniil Yugoslavskiy, oscd.community, frack113
date: 2019-10-22
modified: 2023-12-13
tags:
- attack.credential-access
- attack.t1003.002
logsource:
category: process_creation
product: windows
detection:
selection_img:
- Image|endswith: 'reg.exe'
- OriginalFileName: 'reg.exe'
selection_cli_flag:
CommandLine|contains:
- ' save '
- ' export '
selection_cli_hklm:
CommandLine|contains:
- 'hklm'
- 'hkey_local_machine'
selection_cli_hive:
CommandLine|contains:
- 'system'
- 'sam'
- 'security'
condition: all of selection_*
falsepositives:
- Dumping hives for legitimate purpouse i.e. backup or forensic investigation
level: high(Regla completa, con todas las variantes unicode, en el repositorio de SigmaHQ, licencia DRL 1.1.)
Su propia lista de falsos positivos ya lo dice: una copia de seguridad legítima de esas mismas colmenas dispara la misma regla, así que en un entorno con backup por script hay que esperar ese ruido y decidir cómo descontarlo (por cuenta que lo ejecuta, por ruta de destino del volcado, o por ambas).
El otro camino hacia las mismas colmenas, sin tocar reg.exe para nada, es leerlas directamente desde una copia de sombra creada con vssadmin. La regla de SigmaHQ para ese patrón, de Max Altgelt y Tobias Michalski, busca la combinación del dispositivo de la copia de sombra con el nombre de la colmena:
title: Sensitive File Access Via Volume Shadow Copy Backup
id: f57f8d16-1f39-4dcb-a604-6c73d9b54b3d
status: test
description: |
Detects a command that accesses the VolumeShadowCopy in order to extract sensitive files such as the Security or SAM registry hives or the AD database (ntds.dit)
author: Max Altgelt (Nextron Systems), Tobias Michalski (Nextron Systems)
date: 2021-08-09
modified: 2024-01-18
logsource:
category: process_creation
product: windows
detection:
selection_1:
CommandLine|contains: '\\?\GLOBALROOT\Device\HarddiskVolumeShadowCopy'
selection_2:
CommandLine|contains:
- '\NTDS.dit'
- '\SYSTEM'
- '\SECURITY'
condition: all of selection_*
falsepositives:
- Unlikely
level: high(Repositorio de SigmaHQ, licencia DRL 1.1, atribución a Max Altgelt y Tobias Michalski, Nextron Systems.) Esa misma ruta cubre también el volcado de NTDS.dit en un controlador de dominio, pero esa parte del ataque, con el propio Active Directory como origen de la credencial robada, ya es terreno del curso de Defensa de Active Directory.
Cuentas de servicio fuera de su línea base
Todo lo anterior asume una firma reconocible: un nombre de pipe, una máscara de acceso, un tipo de cifrado. Las cuentas de servicio rompen ese supuesto, porque su comportamiento normal ya se parece mucho al de un atacante moviéndose lateralmente: autentican en varias máquinas, a menudo con privilegios amplios, y con frecuencia fuera del horario de oficina porque corren tareas nocturnas. Ninguna de las reglas anteriores las distingue bien de un uso malicioso de esas mismas credenciales, porque la diferencia no está en el evento sino en si ese evento encaja con lo que esa cuenta concreta hace siempre.
Ahí la firma cede el paso a la línea base: qué máquinas toca normalmente esa cuenta, a qué horas, con qué tipo de logon y desde qué origen. La misma lógica estadística de la búsqueda de Splunk para Kerberoasting (media más varias desviaciones típicas, por cuenta y por origen, en vez de un umbral fijo para todas) es la que se aplica aquí, extendida a 4624 y 4768: no «esta cuenta se autenticó a las 3 de la madrugada» en abstracto, sino «esta cuenta se autenticó a las 3 de la madrugada, algo que no había hecho ni una vez en las últimas ocho semanas». Construir y mantener esa línea base por cuenta cae ya del lado de la ingeniería de datos del SIEM más que de la escritura de una regla suelta, pero es la pieza que le falta a todo lo demás en este módulo para cubrir el caso de la cuenta de servicio.
Tabla resumen
| Técnica | Fuente de telemetría | Evento | Campo determinante | Ruido esperable |
|---|---|---|---|---|
| T1003.001, LSASS Memory | Sysmon | Event ID 10 | GrantedAccess + CallTrace |
Alto sin filtrar por máscara |
| T1003.001 (capa Defender) | ASR en auditoría o bloqueo | 1121 / 1122 | RuleId 9e6c4e1f-... |
Alto; Microsoft avisa de que casi todo es descartable en bloqueo |
| T1003.002, SAM | Sysmon / auditoría de procesos | Event ID 1 (Sysmon) o 4688 | CommandLine con reg save |
Bajo, salvo scripts de backup |
| Acceso vía copia de sombra | Sysmon / auditoría de procesos | Event ID 1 (Sysmon) o 4688 | CommandLine con ruta GLOBALROOT...ShadowCopy |
Bajo |
| T1550.002, Pass the Hash | Seguridad de Windows | 4624 tipo 9 seguido de 4624 tipo 3 en otro host | LogonType + Source Network Address |
Medio |
| T1021.002, PsExec / SMB | Sysmon + System | 17/18 y 7045 | PipeName PSEXESVC, ServiceName |
Bajo-medio (PsExec legítimo existe) |
| T1021.002, Impacket psexec.py | Seguridad de Windows | 5145 | RelativeTargetName con RemCom_std* |
Bajo |
| T1047, WMI | WMI-Activity/Operational + Sysmon | 5857/5860/5861 + Event ID 1 | Proceso hijo de WmiPrvSE.exe |
Medio-alto |
| T1021.006, WinRM | WinRM/Operational + Sysmon | 91 (comunidad) + Event ID 1 | Proceso hijo de wsmprovhost.exe |
Medio |
| T1558.003, Kerberoasting | Seguridad de Windows | 4769 | TicketEncryptionType 0x17 |
Medio en dominios con equipos legacy |
| Cuenta de servicio anómala | Seguridad de Windows | 4624 / 4768 | Hora u origen fuera de línea base | Depende por completo de la línea base construida |
Ejercicio: reconstruir la cadena con telemetría ya grabada
El objetivo es ordenar, sin ejecutar nada ofensivo tú mismo, la secuencia de eventos que delata un robo de credenciales seguido de un salto lateral, usando tres ficheros reales del repositorio EVTX-ATTACK-SAMPLES (licencia GPL-3.0, mantenido por Samir Bousseaden), ya presentado en el módulo de laboratorio.
- Descarga estos tres ficheros a tu VM Windows:
sysmon_10_lsass_mimikatz_sekurlsa_logonpasswords.evtxde la carpetaCredential Access, yLM_4624_mimikatz_sekurlsa_pth_source_machine.evtxjunto conLM_WMI_4624_4688_TargetHost.evtxde la carpetaLateral Movement. - Ábrelos uno a uno con el Visor de eventos (
eventvwr.msc, Acción > Abrir registro guardado), tal como hiciste en el módulo de laboratorio, y anota de cada uno: cuántos eventos contiene, de qué IDs, y a qué host corresponde según el nombre del fichero. - Para el primero, localiza el evento 10 de Sysmon con
TargetImageterminado enlsass.exey apunta el valor deGrantedAccessy las bibliotecas que aparecen enCallTrace. Compáralo con la lista de máscaras activas de la regla de LSASS memdump de este módulo. - Para el segundo, busca el 4624 y anota su
LogonType. Este fichero documenta, según su propio nombre, el artefacto que dejasekurlsa::pthen la máquina de origen: contrasta lo que encuentres con la descripción oficial del tipo 9 citada en este módulo. - Para el tercero, localiza el 4624 y el 4688 más próximos en el tiempo entre sí y anota su
LogonTypey el proceso que aparece en el 4688. Es la telemetría de la máquina destino tras el salto. - Con los tres ficheros abiertos, ordena por marca de tiempo los tres eventos que anotaste y escribe, en una frase por evento, qué demuestra cada uno por separado y qué demuestran juntos en secuencia.
Exporta cada fichero a texto con wevtutil qe si prefieres trabajar con grep o con tu editor en vez del Visor de eventos:
wevtutil qe "<ruta>sysmon_10_lsass_mimikatz_sekurlsa_logonpasswords.evtx" /lf:true /f:text > C:soc-labcred-access.txt
wevtutil qe "<ruta>LM_4624_mimikatz_sekurlsa_pth_source_machine.evtx" /lf:true /f:text > C:soc-laborigen.txt
wevtutil qe "<ruta>LM_WMI_4624_4688_TargetHost.evtx" /lf:true /f:text > C:soc-labdestino.txtVerifica en tu propio entorno los valores exactos que aparecen en cada evento (PID, SID, marcas de tiempo, dirección IP): no hay una salida universal, dependen de cómo se grabó cada fichero.
Preguntas frecuentes
¿Por qué no basta con bloquear o alertar por el nombre del ejecutable que abre lsass.exe?
Porque el nombre lo controla quien ataca: copiar o renombrar un binario, o cargar el mismo código desde PowerShell reflejado en memoria, rompe cualquier regla que dependa del nombre de imagen. La máscara de acceso (GrantedAccess) y el rastro de bibliotecas cargadas (CallTrace) dependen de qué API se llamó, algo mucho más difícil de disfrazar sin perder la funcionalidad que el atacante necesita.
¿Hace falta desplegar la regla ASR de LSASS en modo bloqueo para que sirva como detección?
No. El modo auditoría genera el mismo evento 1122 que generaría el bloqueo en el 1121, sin interrumpir nada, así que un SOC puede alertar sobre esos eventos mientras la organización todavía está validando que el bloqueo no rompe procesos legítimos. Microsoft documenta que la fase de auditoría es un paso normal antes de pasar a bloqueo, no un modo permanente de segunda categoría.
¿Por qué el Logon Type 9 es tan revelador en un ataque de pass-the-hash?
Porque su propia definición oficial describe el mecanismo del ataque casi palabra por palabra: la sesión local sigue siendo la misma, pero las conexiones salientes usan credenciales distintas. Verlo en un 4624 con un proceso poco habitual como Subject, seguido poco después de un 4624 tipo 3 en otra máquina con la cuenta prestada, es de las combinaciones más específicas de todo este módulo.
¿Cómo se diferencia un salto legítimo de administración remota de un movimiento lateral real?
Con este conjunto de eventos aislado, casi nunca de forma perfecta: PsExec, WMI y WinRM los usan a diario los propios equipos de sistemas. Lo que cambia el veredicto es el contexto que no está en el evento individual: si la cuenta, el origen, la hora o el destino encajan con lo que esa cuenta hace siempre (la línea base de la última sección) o no.
¿Sigue mereciendo la pena vigilar RC4 en Kerberos si Microsoft lo está retirando por defecto?
Sí, y cada vez más. Cuanto menos frecuente se vuelve RC4 por la propia migración de Microsoft hacia AES por defecto, más peso tiene como anomalía cada ticket que sigue apareciendo cifrado con él, porque hace falta una razón concreta (una cuenta muy vieja sin rotar, o alguien forzándolo a propósito) para que siga ocurriendo.
¿Y si mi organización no tiene Sysmon desplegado, solo la auditoría nativa de Windows?
Pierdes el evento 10 (acceso a procesos) y los eventos 17/18 (named pipes), que no tienen equivalente directo en el registro de seguridad nativo. Te quedan, aun así, el 4624, el 4648, el 4768/4769, el 5145 y el 7045, que entre todos siguen cubriendo buena parte de las señales de este módulo (logon types, credenciales explícitas, Kerberos y servicios remotos), aunque con menos detalle en la parte de ejecución.