Cómo cazamos persistencia sin IOC en un Active Directory comprometido.

El SIEM no había emitido una sola alerta en cuarenta y ocho horas. Ningún hash conocido. Ninguna IP en listas. Ningún proceso fuera de baseline. Lo único que teníamos era una intuición: la quietud. Cuando un atacante consigue persistencia bien hecha, lo último que hace es hacer ruido. Y eso —no hacer ruido— también deja huella, si sabes dónde mirar.

Esta es la crónica abreviada de una caza. Tres consultas, dos horas, un caso cerrado. La detalle como recordatorio de algo que repetimos en cada sesión interna: las cosas más graves no llegan con IOC.

El punto de partida: una hipótesis, no una alerta

El cliente tenía un EDR maduro, SIEM con dos años de tuning y un equipo blue team competente. La pregunta que les planteamos fue muy concreta:

«Si un atacante hubiera conseguido Domain Admin hace una semana y quisiera persistir sin levantar alertas, ¿qué haría primero?»

La respuesta, en ATT&CK, está en pocas técnicas. Las más cómodas para un actor que quiere quedarse: T1053.005 (Scheduled Task), T1136.002 (Create Account · Domain), T1098.001 (manipulación de privilegios sobre cuentas existentes) y T1547.001 (Run Keys, ya menos elegante). Las cuatro tienen una característica en común: generan logs perfectamente válidos cuando los ejecuta una cuenta privilegiada. No son IOC. Son comportamiento legítimo.

De ahí salió la hipótesis: existen tareas programadas creadas en los últimos 14 días por una cuenta administradora, que persisten en uno o varios DCs y no corresponden a ningún cambio operacional documentado.

Consulta 1 — Tareas creadas, normalizadas por baseline

El evento que importa aquí es 4698 (A scheduled task was created). Está en todos los DCs si hay auditoría avanzada. La consulta básica, en pseudo-KQL, es trivial:

SecurityEvent
| where EventID == 4698
| where TimeGenerated > ago(14d)
| extend taskName = tostring(parse_xml(EventData).TaskName)
| extend createdBy = SubjectUserName
| project TimeGenerated, Computer, taskName, createdBy

El primer resultado fue ruido: 312 tareas. Lo siguiente fue restar el baseline conocido — tareas que llevan meses, tareas que crean herramientas de gestión legítima (SCCM, Splunk forwarder, antivirus) y tareas creadas dentro de ventanas de cambio aprobadas.

Tras ese filtrado quedaron once tareas que nadie pudo justificar. Once. En 14 días. En una organización de 8.000 endpoints.

Consulta 2 — Quién las creó y desde dónde

De las once, ocho compartían un patrón: las había creado la misma cuenta de servicio (svc-backup-helper), pero la sesión de la que salió la creación no era la que esa cuenta usaba históricamente. Cruzamos eventos 4624 (logon) con 4698 y vimos lo que esperábamos: la cuenta había sido autenticada desde una estación de trabajo de finanzas, no desde el servidor de backup donde vive su trabajo real.

Eso, en sí mismo, no es un IOC. Es una anomalía contextual. Pero cuando una cuenta de servicio empieza a comportarse como un humano, casi siempre es porque alguien le robó las credenciales y la está usando como pivote.

Consulta 3 — Qué hacían las tareas

Los TaskName estaban camuflados como rutinas de mantenimiento (WindowsUpdateHelper-7, SCCM-Cache-Cleanup-EU, etc). El payload, sin embargo, era llamativo cuando se desempaquetaba el XML:

<Actions>
  <Exec>
    <Command>C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe</Command>
    <Arguments>-NoP -W Hidden -Enc JABjAGwAaQB...</Arguments>
  </Exec>
</Actions>

Decodificado, el blob era un beaconing loader que se conectaba a un dominio recién registrado, descargaba un segundo stage y lo ejecutaba en memoria. Periodicidad: cada seis horas. Disparador: OnLogon sobre cualquier sesión interactiva del DC.

Habíamos encontrado la persistencia. Sin un solo hash conocido. Sin una IP en listas. Solo combinando tres preguntas que el SIEM no se había hecho.

Por qué esto funciona y por qué tu EDR no lo vio

El EDR del cliente sí registraba 4698, pero la regla por defecto solo se disparaba si la línea de comandos contenía cadenas sospechosas (Invoke-Expression, DownloadString, etc). El atacante había usado -Enc con base64 y un dominio recién registrado, así que no había firma, ni listas, ni heurística que lo enganchara en el momento de la creación. La detección por comportamiento sí lo habría visto eventualmente — al ejecutar el beacon — pero entre crearlo y ejecutarlo pasaron cinco horas. Cinco horas en las que un blue team que dependa solo de alertas estaba ciego.

El threat hunting cierra ese hueco preguntándole a la telemetría algo que la regla automática no le pregunta. Y lo importante: la consulta es genérica, reutilizable, y se convierte en regla nueva. Esa caza terminó dejando tres detecciones nuevas en el SIEM y una limpieza completa del entorno en el mismo día.

Cómo replicarlo en tu entorno

Si quieres correr la misma cacería esta semana, los tres bloques mínimos son:

1. Auditoría avanzada activada en todos los DCs (Object Access · Audit Other Object Access Events y Detailed Tracking · Audit Process Creation). Sin esto no hay 4698 consistente.
2. Baseline de tareas conocidas. Una lista actualizada de qué tareas son legítimas y qué cuentas las gestionan. Si no la tienes, empieza por exportar todas las tareas con schtasks /query /v /fo csv en cada DC, y guarda el snapshot.
3. Pivote por cuenta: cualquier cuenta de servicio que de pronto se autentique desde una IP, host o segmento atípico es candidata. No esperes a que rompa algo.