El SMS que no debí abrir: Cómo destripé a Darcula desde Latinoamérica

Un SMS, un abogado preocupado, y las ganas de recordar mis días en el SOC. Así terminé extrayendo las claves de cifrado de una de las…

Un SMS, un abogado preocupado, y las ganas de recordar mis días en el SOC. Así terminé extrayendo las claves de cifrado de una de las operaciones de phishing más sofisticadas del mundo.

Por Pois0n84 · Investigador de Seguridad · Fundador de Academia SPG· Marzo 2026

AVISO LEGAL: El presente artículo tiene finalidad exclusivamente educativa e informativa. La investigación fue realizada de conformidad con la legislación dominicana vigente, incluyendo la Ley número 53–07, sobre Crímenes y Delitos de Alta Tecnología. Se prohíbe expresamente la utilización de los conocimientos aquí expuestos para la comisión de actos ilícitos.

⚠️ Disclaimer:

La presente investigación fue conducida en estricto apego a los principios de divulgación responsable (responsible disclosure) reconocidos internacionalmente (ISO/IEC 29147:2018). En ningún momento se accedió sin autorización a sistemas de terceros ni se explotó vulnerabilidad alguna. El análisis se limitó exclusivamente a: (i) la inspección de código JavaScript entregado públicamente por el servidor al navegador del investigador; (ii) la captura de tráfico generado por el propio dispositivo del investigador; y (iii) el análisis offline de los archivos obtenidos en (i). Los datos de tarjeta son de sesiones de prueba con información completamente ficticia.

El SMS que no debí abrir (pero lo abrí)

La semana pasada estaba grabando contenido para mi academia cuando de repente, bzzz, me llega un SMS con una supuesta multa pendiente.

Supe que era estafa al segundo. Literal. El sistema de mi país no es tan avanzado como para mandarte un SMS con un link de cobro. Si el gobierno dominicano te quiere cobrar una multa, te enteras cuando vas a renovar la licencia, no por mensaje de texto.

Pero me detuve un momento. Miré el enlace. Miré la pantalla. Y pensé: “¿Y si intento entrar a la infraestructura criminal?”

Lo primero que hice fue lo que cualquier persona responsable haría: llamé a mi abogado. Su respuesta fue un “no” rotundo.

Según las leyes dominicanas, meterme con infraestructura ajena, aunque sea criminal, me podía traer problemas. Así que dije bueno, ya quedó. Se acabó la aventura antes de empezar.

Pero luego lo pensé mejor.

Investigar no es vulnerar. La infraestructura no está alojada en mi país. No voy a modificar nada, no voy a acceder a ningún panel, no voy a explotar ninguna vulnerabilidad. Solo voy a mirar lo que el propio sitio me envía a mi navegador. Eso es análisis de tráfico propio. Eso es legítimo.Entonces recordé mis días oscuros en un SOC.

Documenté por escrito el alcance exacto de la investigación antes de proceder: el análisis se circunscribiría exclusivamente a la inspección pasiva de los recursos que el servidor entregara voluntariamente a mi navegador, sin acceder a paneles administrativos, sin explotar vulnerabilidades, y sin interactuar con el sistema de forma distinta a como lo haría cualquier usuario legítimo. Bajo este marco, la actividad es jurídicamente equiparable a abrir una página web pública.

Los días del SOC (y por qué nunca volví)

Cuando era más joven trabajé en un SOC. Y si nunca has trabajado en uno, déjame comentarte cómo es: la fatiga de alertas, las noches largas, los falsos positivos que te hacen cuestionar tu carrera, y un sin número de cosas más que me hicieron jurar que nunca volvería a uno.

Pero no todo fue malo.

Durante esos años aprendí a investigar de verdad. Hice análisis de seguridad de alto impacto, perseguí amenazas que otros ignoraban, y fui de los primeros Threat Hunters del país. Esas habilidades no se olvidan. Se oxidan un poco, sí. Pero no se olvidan. Así que miré el SMS otra vez y dije: “Vamos a la obra.”

En la República Dominicana, DIGESETT son las siglas de la Dirección General de Seguridad de Tránsito y Transporte Terrestre. Es la institución policial responsable de regular el tránsito, fiscalizar el transporte, hacer cumplir las leyes de movilidad y prevenir accidentes en las calles y autopistas del país.

Primer round: La PC no sirve

Copié la URL y la abrí en mi PC.

No funcionó. Me redirigió a la página real del gobierno. Ok, está validando por User-Agent, básico.

Abrí Burp Suite, le inyecté un User-Agent de móvil, y… nada. Me mandó directo a un challenge de Cloudflare.

¿Cloudflare? ¿Protegiendo infraestructura de phishing?

Y aquí me pregunté: ¿llevo mucho tiempo fuera de un SOC? Porque la verdad, sí. Pero en mi defensa, que un servicio como Cloudflare esté sirviendo de escudo a una operación criminal no es exactamente lo primero que uno espera encontrar.

El tema es que no solo tenía que pasar Cloudflare y su control de bots. Después de eso, el propio script del kit de phishing tenía sus propias validaciones: verificación de red celular, detección de proxies, fingerprinting del navegador… mil y una capas de protección.

A este punto ya sabía que no me estaba enfrentando al típico phishing hecho en mi país, ya saben, esos con el logo pixelado y el “Estimado usario” con falta de ortografía. Esto era algo más elaborado. Casi una obra de arte del mal. Cada detalle estaba cuidado, cada vector de análisis estaba bloqueado.

¿Estaba oxidado? Tal vez un poco. ¿Me estaba costando? Sí. Pero eso solo hacía que quisiera seguir más.

Chrome Remote Debugging

Hice lo que hago cuando algo se pone difícil: armé un mapa mental.

El problema era claro: necesitaba abrir el phishing en un dispositivo que no fuera directamente mi teléfono personal, o más bien, necesitaba abrirlo en el teléfono pero poder ver los archivos, inspeccionar el tráfico, y analizar el código desde mi PC. La otra opción era bypassear Cloudflare directamente, pero mi abogado me recomendó que fuera por la primera. La segunda… digamos que no es difícil, pero quedémonos con la recomendación legal.

Entonces, conversando con un colega, encontré algo que me sacó una sonrisa: Chrome Remote Debugging.

El concepto es sencillo: conectas un teléfono Android por USB a tu PC, habilitas la depuración USB, y desde chrome://inspect en tu computadora puedes ver y controlar todo lo que pasa en el Chrome del teléfono. DevTools completas. Consola, Network, Sources, entre otros.

Y lo mejor: el sitio web no detecta nada, porque no hay proxy, no hay automatización, no hay WebDriver. Es un navegador legítimo en un teléfono legítimo en una red celular legítima. Solo que yo estoy mirando todo desde mi PC, listo, estaba dentro.

Conecté un Samsung de laboratorio con una SIM prepagada. Navegué a la URL del phishing usando datos móviles. La página cargó perfectamente en el teléfono. Y en mi PC, en chrome://inspect, apareció la pestaña activa con el dominio multas.gobpgt.one. Hice clic en inspect, y ahí empezó la verdadera investigación.

El tráfico cifrado

Antes de meterme con el código, tengo que contarles algo. Mientras configuraba todo, decidí probar suerte con Burp Suite otra vez. Y pasó algo curioso: al quitar el proxy de Burp y volver a activarlo, los controles de Cloudflare me dejaron pasar. No sé si fue un error de configuración del kit o simplemente tuve suerte, pero de repente podía ver el tráfico.

El problema es que ver no es lo mismo que entender.

Cada request que la página hacía al servidor estaba completamente cifrado. El body de las peticiones era un string Base64 largo sin ningún sentido aparente. Los responses, igual. Podía ver que había comunicación, podía ver los endpoints, pero el contenido era una pared de caracteres ilegibles.

La primera barrera estaba clara: todo el protocolo entre la víctima y el servidor tenía una capa de cifrado adicional por encima de HTTPS. No bastaba con interceptar el tráfico, había que descifrarlo, y para descifrarlo, necesitaba las llaves.

Buscando las llaves del castillo

Con las DevTools abiertas, lo primero fue buscar las funciones de cifrado. Usé la búsqueda global en la pestaña Sources y busqué “cryptoJS”.

Aparecieron dos archivos JavaScript del dominio con referencias a CryptoJS:

• DgZYu39z.js con 12 coincidencias
• IB9GIkLJ.js con 5 coincidencias

Un tercero de Cloudflare Insights que no tenía nada que ver.

Descargué ambos archivos para analizarlos offline con más calma. Ahora tenía el código fuente del kit de phishing en mi máquina.

El código ofuscado

Volví a los archivos JavaScript que había descargado. Abrí el primero y lo que vi fue algo así:

var a5_0x431bf7=a5_0x4460;(function(_0x7e8cfd,_0x3a754f){var _0xae0235=a5_0x4460...

Basura ilegible. Todo el código estaba pasado por un ofuscador: nombres de variables aleatorios, strings codificados en un array, índices hexadecimales en lugar de texto normal.

Pero yo sabía algo. En este tipo de escenarios, los atacantes hacen algo que parece inteligente pero en el fondo es bastante estúpido: guardan las claves de cifrado en el cliente. ¿Por qué? Porque a ellos no les importa la seguridad de la víctima. El cifrado no está ahí para proteger a nadie. Está ahí para dificultarnos el trabajo forense a nosotros, los que analizamos estas cosas. Pero si el navegador de la víctima puede descifrar los mensajes, las llaves tienen que estar en algún lugar del JavaScript. Es inevitable.

Hice lo básico: el código tenía todos los textos del programa metidos en una lista revuelta, un traductor interno que convertía códigos en texto real, y un paso extra que desordenaba todo al inicio para dificultar la lectura. Identifiqué las piezas pero cuando intenté reconstruir el decodificador completo, me di cuenta de que necesitaba un par de ojos extra. Contacté a un colega con más experiencia en reversing de JavaScript ofuscado y entre los dos logramos armarlo.

Extrajimos las tres piezas, las ejecutamos, y los fragmentos de la clave empezaron a aparecer:

Índice 0x3d1 → 'fc7fee****'
Texto plano en el código → 'cb9b****d9'
Índice 0x389 → '7ed9****ea'
Texto plano en el código → '**'

Concatenando todo obtuvimos la primera llave: la que cifra todas las peticiones HTTP entre la víctima y el servidor.

Pero no era la única. Seguimos buscando y encontramos dos más: una para las comunicaciones en tiempo real por Socket.IO, y otra para los datos que el kit guarda en el navegador de la víctima.

Tres llaves. Las tres hardcodeadas en el JavaScript. Las mismas para todas las víctimas, todas las sesiones, todas las IPs. Mientras el operador no actualice su copia del software, estas llaves descifran absolutamente todo.

Esto lo había visto antes…

A este punto tenía las llaves, tenía tráfico capturado, y podía descifrar las comunicaciones. Pero algo me hacía ruido. La estructura del código, el nivel de sofisticación, la forma en que todo estaba armado… esto no era un proyecto de un tipo solo en su cuarto.

Entonces me vino un recuerdo.

Hace unos meses había visto pasar una investigación sobre una operación de phishing a gran escala. En su momento no le presté mucha atención, la vi por encima, leí el título y seguí con mi vida. Pero ahora, con el código del kit abierto en mi pantalla.

Volví a buscar ese artículo. Era de la firma noruega de ciberseguridad mnemonic. Y cuando lo releí, empecé a atar cabos.

El cifrado Rabbit con CryptoJS. La estructura de Socket.IO con rooms hasheados en MD5. Los labels en chino dentro del código. Todo coincidía. Lo que yo tenía en mis manos era una instancia activa de la misma plataforma que ellos habían documentado.

Los hashes de los rooms lo confirmaban:

MD5("admin") = 21232f297a57a5a743894a0e4a801fc3
MD5("sync-data") = 824d02e7cf6ec64a44710b06ef8cfa0e

Los mismos valores que aparecían en su investigación. Misma plataforma, diferente campaña, diferente región.

Estaba frente a Darcula. Y su herramienta, Magic Cat.

Una operación global de phishing-as-a-service con cientos de miles de víctimas, un sistema de licencias tipo software empresarial, y ahora apuntando directamente a Latinoamérica.

Descifrando el tráfico

Ahora venía la parte divertida. Tenía las llaves, entendía el protocolo, y tenía 18 requests capturados en Burp con los bodies cifrados.

El protocolo funciona así:

Para las peticiones HTTP, el kit toma los datos, los cifra con Rabbit usando la llave que extrajimos, y el resultado es un string Base64 que al decodificar empieza con “Salted__” (formato estándar de OpenSSL). El Content-Type que usan es ‘text/trpc-crypt’, un tipo completamente inventado por ellos.

Para Socket.IO la cosa es más compleja: los mensajes se cifran con Rabbit, luego se comprimen con LZString, y se envuelven con delimitadores “|”. Por eso cuando miraba los mensajes en la pestaña Messages de las DevTools veía caracteres Unicode ilegibles en vez de Base64. No era cifrado, era compresión sobre cifrado.

Los endpoints de la API aparecen como hashes en la URL, tipo /api/f43ea7dd51b7e98b, pero por dentro son rutas normales como /api/user/initClient.

Exporté los 18 requests de Burp como XML y construí un procesador automático que parsea el XML, extrae los bodies cifrados, y aplica el descifrado con la llave, Lo que apareció en pantalla me dejó con la boca abierta.

Lo que Darcula no quería que viéramos

Cada request descifrado revelaba la API interna completa de Magic Cat:

/api/user/initClient para registrar una nueva víctima. A mi sesión de prueba le asignó el ID 339,058. Eso da una idea de la escala de esta operación.

/api/user/savePageDatas para enviar los datos robados en tiempo real, campo por campo, con labels en chino: 首页 (página inicio), 填卡 (llenar tarjeta), 验证码 (código de verificación).

/api/user/binLookup que automáticamente consulta los primeros 6 dígitos de la tarjeta para identificar el banco emisor, tipo de tarjeta y país. En tiempo real. Sin que la víctima se entere.

Y /api/user/actionGuard, que es el hallazgo más importante de toda la investigación.

El actionGuard es un sistema de control remoto en tiempo real. Cuando la víctima ingresa su tarjeta, el kit envía TODA la información al operador y le presenta un menú de opciones en chino:

• 验证: redirigir a la víctima a una página de verificación y pedirle un código OTP
• 跳转完成: redirigir a “completado” si ya tienen lo que necesitan
• 拒绝卡号: rechazar la tarjeta y pedir otra

El operador está ahí, en vivo, decidiendo qué hacer con cada víctima. Si la tarjeta parece válida, pide el OTP. Si no sirve, la rechaza. No es automatizado. Es una persona al otro lado controlando todo como si fuera un videojuego.

Y entre las opciones de verificación encontré algo que me confirmó que esta campaña fue diseñada específicamente para nuestra región: una opción etiquetada como “[CENSURADO]网银”, que significa “Banca online [CENSURADO]”. Tienen templates personalizados para bancos específicos de Latinoamérica.

Por razones de confidencialidad, los nombres específicos han sido comunicados directamente a las instituciones afectadas y a las autoridades regulatorias competentes. Esta información no se publica en este artículo.

El campo “page” en la respuesta del servidor decía “多米尼加etc”, que en chino significa “Dominicana etc”. Esta instancia de Darcula fue configurada para atacar mi país. Eso ya lo hizo personal.

Los IOCs

Del análisis se extraen los siguientes indicadores de compromiso:

Dominio: multas.gobpgt.one

Plataforma: Magic Cat (Darcula PhaaS)

Cifrado: CryptoJS Rabbit

Transporte: Socket.IO v5 con compresión LZString

Anti-análisis: FingerprintJS, filtrado de User-Agent, bloqueo de IP

Campaña: República Dominicana, tema de multas gubernamentales

Lo que aprendí (y lo que deberías saber)

Si trabajas en seguridad: Chrome Remote Debugging es tu mejor arma cuando los kits de phishing te bloquean todo lo demás. Las llaves de cifrado client-side siempre van a estar expuestas porque el navegador las necesita para funcionar. Y por favor, captura el tráfico primero y analiza después. No cometas mi error de intentar hacerlo en vivo.

Si no trabajas en seguridad: lo que encontré detrás de ese SMS no es un tipo con un HTML copiado de YouTube. Es crimen organizado operando como una startup de tecnología, con licencias, soporte técnico, y un operador humano controlando todo en tiempo real. Cuando te llegue un SMS con un enlace y sentido de urgencia, no lo abras. Verifica directo con la institución. Del otro lado hay alguien con un dashboard abierto esperando tu clic.

Divulgación responsable

Esta investigación fue conducida bajo los principios de divulgación responsable conforme al estándar ISO/IEC 29147:2018. Con anterioridad a esta publicación se realizaron las siguientes notificaciones formales: (i) reporte ante la Fiscalía Especializada en Crímenes y Delitos de Alta Tecnología del Ministerio Público de la República Dominicana; (ii) notificación al INDOTEL; (iii) reporte a Cloudflare Trust & Safety mediante su formulario oficial de abuso; (iv) comunicación directa a las instituciones bancarias identificadas como objetivo de la campaña. Los IOCs completos han sido compartidos con las autoridades. Las claves criptográficas identificadas no se publican y fueron comunicadas por canal privado a los organismos competentes. El dominio malicioso fue reportado a los registradores correspondientes.

Una última cosa

Este análisis forma parte de los contenidos educativos de Academia SPG, donde formamos profesionales de seguridad que operan con rigor técnico y marcos legales sólidos. Si tu organización enfrenta amenazas similares o deseas desarrollar capacidades de inteligencia de amenazas bajo un marco de divulgación responsable, puedes conocer más en nuestros canales oficiales.

Herramientas utilizadas

• Chrome Remote Debugging (chrome://inspect)
• Burp Suite Professional
• Node.js (para desobfuscación)
• CryptoJS (para descifrado offline)
• Android con SIM prepagada