Informe de Inteligencia de Amenazas

Tema: Ransomware White Lock (.fbin)
Ventana analizada: 29/09/2025 – 01/12/2025

1. BLUF (Resumen ejecutivo)

Qué es White Lock

White Lock es una familia de crypto-ransomware relativamente nueva, activa desde fines de septiembre de 2025, que cifra datos en sistemas Windows, agrega la extensión .fbin y deja la nota de rescate c0ntact.txt.

Está operada por el mismo grupo detrás de la operación de extorsión de datos dAn0n, reaparecido ahora con capacidad de cifrado y un modelo de extorsión directa (rescate de 4 BTC y un plazo aproximado de 4 días).

Evaluación rápida de riesgo:

• Riesgo para empresas Windows medianas/grandes: Alto
• Modelo de amenaza: cifrado + exfiltración, extorsión sin “leak site” público (negociación vía chat en Tor).
• Madurez técnica: media-alta (anti-AV, borrado de shadow copies, ofuscación, uso de servicios Windows).

2. Identidad y contexto

2.1. Línea temporal

• Primera observación confirmada: finales de septiembre de 2025; primeras muestras con timestamp de compilación del 29/09/2025 en repositorios de malware públicos.
• Estado actual (01/12/2025): campaña en fase temprana pero con tooling estable (mismo esquema .fbin + c0ntact.txt + demanda de 4 BTC).

2.2. Relación con dAn0n

Análisis de investigadores de seguridad vincula White Lock con el grupo de extorsión dAn0n por:

• Reutilización de infraestructura: dominios dan0n[.]com y whitelock[.]xyz sobre las mismas IPs y subred para correo.
• Misma operación de extorsión (plantilla de emails, uso de Tor, estilo de negociación) y continuidad operativa declarada.

En 2024, dAn0n se centró en exfiltración y doxeo sin cifrado; en 2025 reaparecen como White Lock con cifrado completo, manteniendo el foco en víctimas corporativas.

2.3. Colisión de nombres

Hay referencias antiguas (2016) a una familia llamada WHITELOCK, pero no hay evidencia pública de continuidad técnica con el White Lock actual; sólo comparten el nombre.

3. Superficie de ataque y victimología

3.1. Tecnología objetivo

• Sistema operativo: Windows (entornos corporativos).
• Criptografía:
  • Cifrado de archivos con algoritmos simétricos (AES).
  • Protección de claves mediante criptografía asimétrica (RSA), en un esquema híbrido clásico.

3.2. Perfil de víctimas y sectores

Por ahora no se conoce un leak site de White Lock con listado sistemático de víctimas, pero:

• La nota de rescate asume capacidad financiera alta (4 BTC por incidente, monto típico de organizaciones con ingresos significativos).
• Evaluaciones externas apuntan a que el foco son entornos enterprise, con interés en organizaciones con:
  • Datos sensibles de clientes.
  • Procesos críticos (ERPs, logística, servicios profesionales, etc.).

Traducción: no apuntan a usuarios hogareños; buscan redes con Active Directory, file servers, bases de datos y capacidad real de pagar.

4. Modelo de extorsión

4.1. Nota de rescate y condiciones

La nota c0ntact.txt incluye:

• Mensaje que indica:
  • Compromiso total de la red.
  • Cifrado y robo de información sensible.
• Demandas:
  • Rescate fijo: 4 BTC.
  • Plazo base: 4 días para pagar.
• Escalado de amenazas en caso de no pago:

Notificación a clientes sobre el incidente.

Venta de datos a competidores.

Publicación/venta en la dark web.

Divulgación abierta en Internet.

Además, desaconsejan explícitamente contactar a fuerzas de seguridad o usar herramientas de recuperación de terceros, bajo amenaza de borrado definitivo de llaves y datos.

4.2. Canal de negociación

• Uso obligado de Tor Browser.
• URL .onion dedicada, con acceso a un portal de negociación donde se ingresa un Client ID incluido en la nota de rescate.
• No existe (por ahora) un portal público de “leaks”; todo se canaliza vía chat privado víctima-atacante.

Modelo: extorsión directa con posible doble extorsión, pero sin exposición pública de víctimas como mecanismo principal de presión.

5. Ciclo de ataque & TTPs (MITRE ATT&CK)

Basado en informes técnicos y análisis de muestras, se observan los siguientes TTPs principales:

Ejecución

• T1129 – Shared Modules
  Uso de módulos compartidos / DLLs para ejecutar el payload en entornos Windows.

Persistencia / Elevación de privilegios

• T1543.003 – Create or Modify System Process: Windows Service
  Creación o modificación de servicios de Windows para persistir y ejecutar con privilegios elevados.
• T1134 – Access Token Manipulation
  Manipulación de tokens de acceso para elevar privilegios o suplantar cuentas.

Evasión de defensas

• T1027.002 – Obfuscated Files or Information: Software Packing
• T1027.005 – Indicator Removal from Tools
• T1027.009 – Embedded Payloads
• T1140 – Deobfuscate/Decode Files or Information

En la práctica: binarios empaquetados/ofuscados, payload incrustado y rutinas para limpiar rastros y complicar análisis estático y dinámico.

Descubrimiento

• T1010 – Application Window Discovery
• T1012 – Query Registry
• T1016 – System Network Configuration Discovery
• T1057 – Process Discovery
• T1082 – System Information Discovery
• T1083 – File and Directory Discovery
• T1518 – Software Discovery

Objetivo: mapear sistema, procesos, software y red antes de cifrar o exfiltrar.

Comando y Control

• T1071 – Application Layer Protocol
  Comunicación sobre protocolos de capa de aplicación (HTTP/HTTPS) y/o encapsulado sobre Tor.
• T1090 – Proxy
  Uso de nodos intermedios / proxys para ocultar el origen real.
• T1571 – Non-Standard Port
  Empleo de puertos no estándar para dificultar firmas simples basadas en puertos.

Impacto

• T1486 – Data Encrypted for Impact
  Cifrado de datos con extensión .fbin.
• T1489 – Service Stop
  Detención de servicios, incluyendo antivirus, backup y bases de datos, para maximizar impacto del cifrado.
• T1529 – System Shutdown/Reboot
  Reinicio o apagado controlado del sistema tras el cifrado para consolidar el impacto.

Adicionalmente se observan patrones de terminación de procesos de seguridad y borrado de copias de sombra antes de iniciar el cifrado masivo.

6. Artefactos técnicos

6.1. Indicadores estáticos

Archivos y extensiones

• Extensión de archivos cifrados: *.fbin
  • Ejemplos: 1.jpg.fbin, 2.png.fbin
• Nota de rescate:
  • c0ntact.txt en múltiples carpetas de usuario y compartidas.
• Fondo de pantalla:
  • Archivo ba.bmp utilizado como wallpaper con mensaje de rescate.

Hashes de muestras (SHA-256, cifrador)
(resumen truncado para lectura; usar valores completos en detecciones)

• 7e5ec68f...dd537a68
• 960bfbed...bb379996c
• a501583b...edcc49c29
• db15fb3f...9e1ccfb7

Detecciones AV reportadas (ejemplos)

• Avast: Win64:MalwareX-gen [Ransom]
• ESET: A Variant Of Win64/Filecoder.ADE
• Kaspersky: Trojan-Ransom.Win64.Agent.ean
• Microsoft: Trojan:Win32/Egairtigado!rfn

6.2. Infraestructura y C2

Indicadores asociados a la operación dAn0n / White Lock:

• Dominios:
  • dan0n.com
  • whitelock.xyz
• URLs en Tor (negociación / C2):
  • 2c7nd54guzi6xhjyqrj5kdkrq2ngm2u3e6oy4nfhn3wm3r54ul2utiqd.onion
  • l3e4ct2egnlfz4ymexwn66jlz55vrnnn72ub4u3xqdjcp7xel5hpbzqd.onion
• IPs observadas en registros históricos:
  • 192.64.119.130
  • 192.64.119.136
  • 91.195.240.19

(Todos los IoC deben tratarse como punto de partida; validar siempre con fuentes actualizadas antes de bloquear en producción.)

7. Proyecciones de amenaza

Proyección 1 – Crecimiento sobre entornos con backups débiles

• Se espera que White Lock aumente la actividad contra organizaciones con copias de seguridad poco maduras (sin copias offline o inmutables).
• Probabilidad: alta.
• Razonamiento: el modelo de rescate elevado exige víctimas con baja resiliencia frente a ransomware.

Proyección 2 – Evolución hacia RaaS limitado

• Posible apertura a un esquema de afiliados controlado, reutilizando la marca White Lock y la infraestructura heredada de dAn0n.
• Probabilidad: media.
• Razonamiento: patrón general del ecosistema y experiencia previa del grupo en extorsión de datos.

Proyección 3 – Aparición de imitadores

• Es probable que aparezcan samples de otras familias que reutilicen el nombre “White Lock” o .fbin sin relación directa.
• Probabilidad: media.
• Razonamiento: precedentes de homónimos y “clones” de marcas de ransomware conocidas.

8. Detección y hunting (SOC / Blue Team)

8.1. Telemetría en endpoints (EDR / AV)

Buscar combinaciones de:

Patrón de archivos:

• Aparición masiva de *.fbin en un intervalo corto de tiempo.
• Creación de c0ntact.txt en múltiples directorios.

Borrado de copias de sombra / servicios:

• Ejecución de comandos para borrar shadow copies (vssadmin, wmic shadowcopy, llamadas API equivalentes).
• Detención de servicios de antivirus, backup y bases de datos inmediatamente antes del cifrado.

Cambios de wallpaper y registro:

• Escrituras en claves de configuración de fondo de pantalla asociadas a la creación de ba.bmp.

Comportamiento anti-análisis:

• Diferencias de comportamiento en entornos sandbox frente a hosts “reales” (inactividad en VM de análisis vs cifrado en entornos de producción).

8.2. Detección en red

• Tráfico saliente hacia:
  • Dominios dan0n.com y whitelock.xyz.
  • IPs asociadas a la infraestructura del grupo.
  • URLs .onion, si se dispone de visibilidad sobre tráfico Tor.
• Aumento repentino de tráfico hacia servicios de anonimato o proxys no autorizados.

8.3. Casos de uso / reglas sugeridas

Use Case 1 – Ransomware genérico con huella White Lock

• Disparar alerta crítica si un proceso:

Mata procesos de antivirus o backup,

Borra shadow copies,

Crea archivos con extensión .fbin de forma masiva,

Crea c0ntact.txt en múltiples directorios.

Use Case 2 – Cambios de wallpaper + cifrado

• Correlación entre:
  • Cambios en claves de wallpaper,
  • Ejecución de binario desconocido desde rutas temporales,
  • Creación de c0ntact.txt y .fbin en el mismo host.

Use Case 3 – Egress sospechoso

• Alerta cuando un servidor crítico contacte por primera vez a dominios/IPs asociados a dAn0n/White Lock o inicie conexiones hacia Tor sin justificación.

9. Contención y respuesta (IR)

9.1. Acciones inmediatas (0–4 h)

Aislar sistemas afectados (desconectar de red, sin apagarlos salvo necesidad).

Bloquear IoC conocidos en firewall, EDR y proxies (dominios, IPs, hashes).

Preservar evidencia:

• Imagen de disco de al menos un host afectado.
• Volcado de memoria si es posible.
• Exportar logs de SIEM, EDR, proxy, gateway de correo y VPN.

9.2. Análisis inicial

• Identificar paciente cero y vector probable (phishing, RDP expuesto, software pirata, credenciales comprometidas, etc.).
• Verificar:
  • Indicios de exfiltración (picos de tráfico, conexiones externas inusuales, logs de DLP).
  • Compromiso de Active Directory y cuentas privilegiadas.

9.3. Recuperación

• Política recomendada por defecto: no pagar el rescate dado que no hay garantías de recuperación y se financia más actividad criminal.
• Restaurar desde backups offline/inmutables previamente verificados.
• Reforzar:
  • Rotación de todas las credenciales privilegiadas.
  • MFA fuerte en accesos remotos.
  • Segmentación de redes antes de volver a producción.

10. Recomendaciones estratégicas

Prioridad 1 – Prevención técnica

• Endurecer acceso remoto:
  • MFA obligatorio en VPN/RDP.
  • Listas de permitidos por IP para accesos administrativos donde sea posible.
  • Uso de bastion hosts en lugar de exponer servidores directamente.
• Fortalecer backups:
  • Estrategia 3-2-1 con al menos una copia offline o inmutable.
  • Pruebas regulares de restauración.
• Endpoints:
  • EDR capaz de bloquear procesos que intenten borrar shadow copies y matar servicios críticos.

Prioridad 2 – Detección & respuesta

• Definir playbooks específicos de “ransomware sin decryptor público”.
• Integrar IoC de White Lock en:
  • Reglas de correlación del SIEM.
  • Listas de bloqueo de EDR/NDR/FW.

Prioridad 3 – Gobierno y negocio

• Revisar y documentar:
  • Política corporativa sobre pago de rescates.
  • Flujos de comunicación a reguladores, clientes y socios en caso de filtración de datos.
  • Coberturas de seguros cibernéticos, si corresponden.

11. Conclusión

White Lock combina la experiencia previa de dAn0n en extorsión de alto impacto con un cifrador moderno y un modelo de negociación discreto, sin portal público de filtraciones pero con un esquema de amenaza escalonada muy agresivo.

Para cualquier entorno Windows-centrico con backups flojos y exposición a phishing/RDP, este actor representa una amenaza seria. Blindar backups, acceso remoto y detección temprana de patrones de cifrado es clave para que un incidente con White Lock quede en “daño controlado” y no en un desastre operativo, legal y reputacional.