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.
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.
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
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
Comentarios
Publicar un comentario