CiberWiki - Cambios recientes [es]

BEACON

2026-10-13T16:44:35Z

← Revisión anterior		Revisión del 16:44 13 oct 2026
Línea 128:		Línea 128:
	=== Origen y Motivación ===		=== Origen y Motivación ===
	BEACON fue desarrollado por Raphael Mudge y su empresa Strategic Cyber LLC (posteriormente adquirida por HelpSystems, hoy Fortra) como el payload central del framework Cobalt Strike, lanzado en 2012 como software comercial de simulación de adversarios para equipos de red teaming . Originalmente, Mudge creó un agente llamado Raven para el Collegiate Cyber Defense Competition de 2012, con el objetivo de mantener acceso silencioso a hosts comprometidos. Raven evolucionó hasta convertirse en BEACON, incorporando capacidades de comunicación DNS, carga reflexiva y ejecución asíncrona de comandos . El propósito legítimo era permitir a los equipos de seguridad emular las tácticas de atacantes avanzados en entornos controlados. Sin embargo, versiones crackeadas y copias no autorizadas del software comenzaron a circular en foros clandestinos. Según Proofpoint, Cobalt Strike apareció en el 5.3% de todas las campañas de malware rastreadas en 2023, y Google TAG identificó 34 versiones crackeadas diferentes circulando en la naturaleza . Antes de la Operación Morpheus (junio 2024), se estimaba que el 75% de los despliegues de Cobalt Strike eran sin licencia . La motivación detrás de su uso malicioso es diversa: grupos de ransomware lo emplean como plataforma de acceso inicial y post-explotación por su eficacia; APTs patrocinados por estados (APT29, APT32, APT40, APT41, Lazarus Group) lo utilizan para operaciones de ciberespionaje prolongado ; y cibercriminales financieramente motivados lo aprovechan para robo de datos y despliegue de ransomware. Su diseño modular, su capacidad de evasión mediante Malleable C2 y su naturaleza fileless lo convierten en una herramienta extremadamente peligrosa y versátil, cuyo uso malicioso sigue siendo un desafío crítico para la seguridad global a pesar de los esfuerzos de las autoridades por limitar su proliferación.		BEACON fue desarrollado por Raphael Mudge y su empresa Strategic Cyber LLC (posteriormente adquirida por HelpSystems, hoy Fortra) como el payload central del framework Cobalt Strike, lanzado en 2012 como software comercial de simulación de adversarios para equipos de red teaming . Originalmente, Mudge creó un agente llamado Raven para el Collegiate Cyber Defense Competition de 2012, con el objetivo de mantener acceso silencioso a hosts comprometidos. Raven evolucionó hasta convertirse en BEACON, incorporando capacidades de comunicación DNS, carga reflexiva y ejecución asíncrona de comandos . El propósito legítimo era permitir a los equipos de seguridad emular las tácticas de atacantes avanzados en entornos controlados. Sin embargo, versiones crackeadas y copias no autorizadas del software comenzaron a circular en foros clandestinos. Según Proofpoint, Cobalt Strike apareció en el 5.3% de todas las campañas de malware rastreadas en 2023, y Google TAG identificó 34 versiones crackeadas diferentes circulando en la naturaleza . Antes de la Operación Morpheus (junio 2024), se estimaba que el 75% de los despliegues de Cobalt Strike eran sin licencia . La motivación detrás de su uso malicioso es diversa: grupos de ransomware lo emplean como plataforma de acceso inicial y post-explotación por su eficacia; APTs patrocinados por estados (APT29, APT32, APT40, APT41, Lazarus Group) lo utilizan para operaciones de ciberespionaje prolongado ; y cibercriminales financieramente motivados lo aprovechan para robo de datos y despliegue de ransomware. Su diseño modular, su capacidad de evasión mediante Malleable C2 y su naturaleza fileless lo convierten en una herramienta extremadamente peligrosa y versátil, cuyo uso malicioso sigue siendo un desafío crítico para la seguridad global a pesar de los esfuerzos de las autoridades por limitar su proliferación.

			* [[Mitigaciones Backdoor\|Relación de acciones para mitigar el riesgo de esta actividad maliciosa.]]

			[[Category:Familias de malware\|Familias de malware]]

BEACON

2026-10-13T16:44:25Z

descripcion de BEACON

Página nueva

BEACON es el payload central (implante) del framework comercial de simulación de adversarios Cobalt Strike, diseñado originalmente para equipos de red team y pruebas de penetración autorizadas, pero que ha sido armamentizado masivamente por operadores de ransomware, APTs patrocinados por estados y cibercriminales financieramente motivados, convirtiéndolo en uno de los implantes post-compromiso más observados en intrusiones avanzadas a nivel mundial .

=== Funcionamiento Técnico Detallado ===
BEACON es un implante modular residente en memoria (memory-resident) que opera como agente ligero dentro del sistema comprometido, comunicándose periódicamente con el servidor de mando y control (C2) del atacante. Su arquitectura se articula en torno a varios componentes clave:

Arquitectura y tipos de beacon:

Cobalt Strike utiliza una arquitectura cliente-servidor donde el Team Server (aplicación Java, puerto 50050 por defecto) gestiona los beacons y recibe conexiones de los operadores. BEACON soporta múltiples protocolos de comunicación diseñados para diferentes escenarios tácticos :
{| class="wikitable"
!Tipo
!Protocolo
!Puerto
!Uso
|-
|HTTP
|HTTP
|80
|C2 vía web, se mezcla con tráfico legítimo
|-
|HTTPS
|HTTPS
|443
|C2 cifrado, más sigiloso
|-
|DNS
|DNS
|53
|C2 vía consultas DNS, lento pero difícil de bloquear
|-
|SMB
|Named Pipes
|445
|Beacon interno, no sale a Internet
|-
|TCP
|TCP raw
|Configurable
|Comunicación directa entre beacons
|}
Comportamiento de beaconing (latido):

BEACON no mantiene una conexión constante. En su lugar, despierta a intervalos regulares (60 segundos por defecto) para contactar al C2, enviar datos y recibir comandos. Para evadir detección basada en patrones temporales, aplica jitter (variación aleatoria): un jitter del 20% significa que el intervalo real varía entre 48 y 72 segundos. Un análisis forense de red documentó intervalos de beaconing con una desviación estándar de 169.2 segundos y un ratio de jitter del 35.4%, consistente con valores configurados típicos de Cobalt Strike .

Malleable C2 Profiles (evasión de tráfico):

La característica más potente de BEACON para evasión es la posibilidad de personalizar completamente su tráfico HTTP/HTTPS mediante ''Malleable C2 Profiles''. Estos perfiles definen URIs, cabeceras, User-Agent, codificación del payload y certificados TLS, permitiendo que el tráfico C2 imite aplicaciones legítimas como Microsoft Teams, APIs REST o servicios de CDN. Un analista que revise logs de proxy vería lo que parece ser tráfico normal hacia <code>teams.microsoft.com</code>, cuando en realidad son check-ins del beacon . Esto complica enormemente la detección por herramientas de seguridad de red tradicionales .

Carga reflexiva y operación fileless:

BEACON se carga en memoria mediante Reflective Loading (carga reflexiva), una técnica que permite ejecutar código PE sin tocar el disco ni usar el cargador estándar de Windows. Esto lo hace invisible para antivirus basados en escaneo de archivos. El beacon típicamente se inyecta en procesos legítimos como <code>rundll32.exe</code> o <code>svchost.exe</code> para camuflarse . En una campaña documentada contra organismos públicos brasileños, el atacante implantó el beacon de Cobalt Strike enmascarado como un binario legítimo del sistema en la ruta <code>C:\Windows\debug\svchost.exe</code>, un indicador de alta confianza de mascaramiento (T1036.005), pues el <code>svchost.exe</code> legítimo nunca opera desde ese directorio .

Cifrado de comunicaciones:

El tráfico C2 de BEACON está cifrado con AES-CBC y autenticado con HMAC-SHA-256, según análisis de reverse engineering de muestras reales . Esto garantiza la integridad y confidencialidad de las comunicaciones, dificultando la inspección del contenido por parte de defensas perimetrales.

SMB Beacon y movimiento lateral:

El SMB Beacon es una pieza clave para el movimiento lateral: permite controlar máquinas internas sin que estas generen tráfico saliente a Internet. El flujo es: un beacon HTTP/HTTPS en una máquina con acceso a Internet actúa como puente, y los SMB Beacons en máquinas internas se comunican con él vía named pipes (típicamente <code>\\.\pipe\msagent_xx</code>), que a su vez reenvía los datos al Team Server . Esto permite comprometer segmentos de red aislados sin que las máquinas internas tengan conectividad directa al exterior.

Capacidades de post-explotación:

BEACON incorpora un amplio arsenal de comandos que cubren todo el ciclo de ataque MITRE ATT&CK :
{| class="wikitable"
!Comando
!Función
!Técnica MITRE
|-
|<code>execute-assembly</code>
|Ejecutar .NET assembly en memoria
|T1059
|-
|<code>inject</code>
|Inyectar beacon en otro proceso
|T1055.001
|-
|<code>mimikatz</code>
|Ejecutar Mimikatz en memoria
|T1003.001
|-
|<code>hashdump</code>
|Dump de hashes SAM
|T1003.002
|-
|<code>jump psexec</code>
|Movimiento lateral vía PsExec
|T1021.002
|-
|<code>jump winrm</code>
|Movimiento lateral vía WinRM
|T1021.006
|-
|<code>portscan</code>
|Escaneo de puertos
|—
|-
|<code>screenshot</code>
|Captura de pantalla
|—
|-
|<code>keylog</code>
|Registro de pulsaciones de teclado
|—
|}

=== Impacto y Consecuencias ===
El impacto de una infección por BEACON es crítico, ya que otorga al atacante una plataforma completa de post-explotación dentro de la red comprometida .

a) Control encubierto y persistente:

BEACON permite al atacante mantener acceso interactivo silencioso durante semanas o meses. Sus funciones de <code>sleep</code> y <code>jitter</code> le permiten permanecer dormido la mayor parte del tiempo, despertando solo para contactar al C2 y ejecutar comandos, lo que dificulta su detección por herramientas que buscan actividad constante . Un informe de CTIR Gov brasileño documentó una campaña activa tipo "hands-on-keyboard" contra órganos públicos donde el atacante utilizaba técnicas avanzadas de enmascaramiento de procesos para mantener acceso prolongado .

b) Robo de datos y credenciales:

A través de comandos como <code>mimikatz</code>, <code>hashdump</code> y <code>keylog</code>, BEACON permite la exfiltración de credenciales corporativas, hashes de contraseñas, tickets Kerberos y datos sensibles . Esto facilita ataques posteriores como fraude, suplantación de identidad y escalada de privilegios.

c) Movimiento lateral y propagación:

El SMB Beacon permite controlar máquinas internas sin que estas generen tráfico saliente a Internet. En la campaña brasileña, el framework Cobalt Strike utilizó SMB Beacons para propagarse internamente a través de la porta TCP 445, frecuentemente creando servicios remotos temporales para ejecución de código . Esto permite comprometer segmentos de red aislados que de otro modo serían inalcanzables.

d) Puerta de entrada para ransomware:

BEACON es utilizado frecuentemente como vector de entrada por grupos de ransomware como LockBit y Conti . Una vez que el atacante tiene acceso persistente vía BEACON, puede desplegar herramientas de reconocimiento, robar credenciales, moverse lateralmente y finalmente ejecutar el ransomware destructivo. El perfil de invasión documentado en Brasil es compatible con grupos de Ransomware-as-a-Service (RaaS) como RansomHub, conocido por mapear redes extensivamente antes de la detonación final .

e) Impacto operativo y financiero:

La presencia prolongada y no detectada de BEACON conduce a respuesta a incidentes costosa, tiempo de inactividad y posibles pérdidas financieras . Su prevalencia en intrusiones avanzadas lo convierte en un indicador sólido de un compromiso serio que requiere respuesta a incidentes de nivel avanzado.

=== Origen y Motivación ===
BEACON fue desarrollado por Raphael Mudge y su empresa Strategic Cyber LLC (posteriormente adquirida por HelpSystems, hoy Fortra) como el payload central del framework Cobalt Strike, lanzado en 2012 como software comercial de simulación de adversarios para equipos de red teaming . Originalmente, Mudge creó un agente llamado Raven para el Collegiate Cyber Defense Competition de 2012, con el objetivo de mantener acceso silencioso a hosts comprometidos. Raven evolucionó hasta convertirse en BEACON, incorporando capacidades de comunicación DNS, carga reflexiva y ejecución asíncrona de comandos . El propósito legítimo era permitir a los equipos de seguridad emular las tácticas de atacantes avanzados en entornos controlados. Sin embargo, versiones crackeadas y copias no autorizadas del software comenzaron a circular en foros clandestinos. Según Proofpoint, Cobalt Strike apareció en el 5.3% de todas las campañas de malware rastreadas en 2023, y Google TAG identificó 34 versiones crackeadas diferentes circulando en la naturaleza . Antes de la Operación Morpheus (junio 2024), se estimaba que el 75% de los despliegues de Cobalt Strike eran sin licencia . La motivación detrás de su uso malicioso es diversa: grupos de ransomware lo emplean como plataforma de acceso inicial y post-explotación por su eficacia; APTs patrocinados por estados (APT29, APT32, APT40, APT41, Lazarus Group) lo utilizan para operaciones de ciberespionaje prolongado ; y cibercriminales financieramente motivados lo aprovechan para robo de datos y despliegue de ransomware. Su diseño modular, su capacidad de evasión mediante Malleable C2 y su naturaleza fileless lo convierten en una herramienta extremadamente peligrosa y versátil, cuyo uso malicioso sigue siendo un desafío crítico para la seguridad global a pesar de los esfuerzos de las autoridades por limitar su proliferación.

CNBackdoor

2026-10-13T16:42:39Z

← Revisión anterior		Revisión del 16:42 13 oct 2026
Línea 32:		Línea 32:
	== Origen y motivación ==		== Origen y motivación ==
	La superposición del código fuente de CNBackdoor (YiBackdoor) con IcedID y Latrodectus indica que sus desarrolladores probablemente son los mismos que crearon estas dos conocidas familias de malware. IcedID apareció originalmente como un troyano bancario y posteriormente fue reutilizado como herramienta de acceso inicial para ransomware; Latrodectus se considera su sucesor. La arquitectura modular de CNBackdoor, sus avanzadas técnicas anti-análisis y su filosofía de diseño de "primero persistir, luego expandir" apuntan a un actor de amenazas experimentado y con recursos considerables, cuya motivación presenta una naturaleza dual: por un lado, el beneficio económico o el espionaje comercial mediante el robo de datos; por otro, servir como eslabón previo en la cadena de ataque de ransomware, allanando el camino para ataques destructivos de mayor nivel. El limitado alcance de despliegue actual podría reflejar que la herramienta aún se encuentra en fase de prueba o despliegue temprano, pero su base de código y su potencial de pluginización implican que, una vez madure, podría escalar rápidamente a ataques a gran escala.		La superposición del código fuente de CNBackdoor (YiBackdoor) con IcedID y Latrodectus indica que sus desarrolladores probablemente son los mismos que crearon estas dos conocidas familias de malware. IcedID apareció originalmente como un troyano bancario y posteriormente fue reutilizado como herramienta de acceso inicial para ransomware; Latrodectus se considera su sucesor. La arquitectura modular de CNBackdoor, sus avanzadas técnicas anti-análisis y su filosofía de diseño de "primero persistir, luego expandir" apuntan a un actor de amenazas experimentado y con recursos considerables, cuya motivación presenta una naturaleza dual: por un lado, el beneficio económico o el espionaje comercial mediante el robo de datos; por otro, servir como eslabón previo en la cadena de ataque de ransomware, allanando el camino para ataques destructivos de mayor nivel. El limitado alcance de despliegue actual podría reflejar que la herramienta aún se encuentra en fase de prueba o despliegue temprano, pero su base de código y su potencial de pluginización implican que, una vez madure, podría escalar rápidamente a ataques a gran escala.

			* [[Mitigaciones Backdoor\|Relación de acciones para mitigar el riesgo de esta actividad maliciosa.]]

			[[Category:Familias de malware\|Familias de malware]]

CNBackdoor

2026-10-13T16:42:26Z

Descripcion de CNBackdoor

Página nueva

CNBackdoor (también conocido como YiBackdoor) es un backdoor modular para Windows cuyo diseño central no es la destrucción inmediata, sino la persistencia sigilosa a largo plazo y la supresión de defensas, sirviendo como canal de acceso inicial para un posterior despliegue de ransomware o robo de datos. Fue descubierto por primera vez en junio de 2025 por Zscaler ThreatLabz, y su código presenta una superposición significativa con IcedID y Latrodectus, lo que sugiere que sus desarrolladores poseen una amplia experiencia en ingeniería de malware.
----

== Funcionamiento técnico detallado ==
La cadena de ejecución de CNBackdoor sigue una lógica táctica de "primero cegar, luego acechar", y su implementación técnica abarca los siguientes componentes clave:

Supresión de defensas y establecimiento de persistencia:

La característica central de CNBackdoor es que, antes de establecer persistencia, ejecuta comandos PowerShell cuidadosamente construidos para desactivar programáticamente Microsoft Defender y otros controles de seguridad locales, añadiendo su propia ruta y la de payloads posteriores a la lista de exclusiones mediante <code>Add-MpPreference -ExclusionPath</code>, "cegando" así las defensas del endpoint sin activar alertas tradicionales. En cuanto a la persistencia, el malware copia su DLL a un directorio de nombre aleatorio y la registra en la clave Run del registro de Windows mediante <code>regsvr32.exe</code> para lograr el autoarranque. El nombre del valor en el registro se deriva de un algoritmo pseudoaleatorio basado en el Bot ID y el generador congruencial lineal (LCG) de Microsoft, lo que dificulta la detección estática. Tras la instalación, el dropper original se autodestruye para obstaculizar el análisis forense.

Inyección de procesos y ejecución encubierta:

CNBackdoor inyecta su funcionalidad principal en el proceso legítimo del sistema <code>svchost.exe</code> para pasar desapercibido. Una característica destacada de su técnica de inyección es que parchea a nivel de ensamblador la función API de Windows <code>RtlExitUserProcess</code>: cuando esta función es invocada (es decir, cuando el proceso está a punto de terminar), el flujo de ejecución es redirigido al punto de entrada del backdoor, secuestrando así la secuencia de terminación del proceso y manteniendo el código vivo dentro del proceso objetivo.

Comunicación C2 modular:

El backdoor extrae la dirección del servidor C2 desde una configuración cifrada incrustada y establece comunicación mediante protocolos HTTP/HTTPS. Su tráfico de red emplea un mecanismo de clave dinámica: la derivación de la clave de cifrado y el IV depende del día actual de la semana como desplazamiento para calcular la dirección de inicio, asegurando que la clave cambie cada día e invalidando la detección de red basada en firmas estáticas. Los datos enviados se codifican en Base64 y se adjuntan a una cabecera HTTP personalizada <code>X-tag</code>.

Expansión funcional mediante plugins:

CNBackdoor tiene funcionalidad limitada por defecto, pero soporta plugins cifrados codificados en Base64 para expandir sus capacidades. Los comandos C2 ya soportados incluyen: <code>systeminfo</code> (recopilación de versión de Windows, lista de procesos, configuración de red, relaciones de confianza de dominio, etc.), <code>screen</code> (captura de escritorio), <code>CMD</code>/<code>PWS</code> (ejecución de comandos vía cmd.exe o PowerShell), y <code>plugin</code>/<code>task</code> (interacción con plugins existentes o inicialización de nuevos plugins).

Capacidades anti-análisis:

El malware detecta entornos virtualizados (VMware, Xen, KVM, VirtualBox, Hyper-V, Parallels) mediante la instrucción <code>CPUID</code>, y utiliza la instrucción <code>rdtsc</code> para realizar detección temporal e identificar sandboxes. Las cadenas se descifran en tiempo de ejecución mediante XOR, y las funciones API de Windows se resuelven dinámicamente recorriendo la lista de módulos y calculando hashes ROR, lo que incrementa aún más la dificultad del análisis estático.
----

== Impacto y consecuencias ==
La amenaza de CNBackdoor posee un carácter sigiloso y prolongado, y su impacto trasciende con creces una simple intrusión puntual en un endpoint. Al desactivar prioritariamente las herramientas de seguridad en la fase inicial, es capaz de mantener un acceso no detectado durante largos periodos mientras el sistema defensivo permanece "ciego". Este acceso persistente otorga al atacante una ventana temporal amplia para ejecutar robo silencioso de datos, recolección de credenciales y movimiento lateral en la red, lo que puede derivar en la exfiltración continua y prolongada de propiedad intelectual, secretos corporativos y datos de clientes, en lugar de una única fuga masiva. Como herramienta utilizada en conjunto con el ransomware KansasGroup, la función de CNBackdoor es proporcionar al operador capacidades de reconocimiento del entorno y consolidación del punto de apoyo antes de que el ransomware cifre los archivos, haciendo que el ataque destructivo posterior sea más preciso y letal. Esto significa que una infección por CNBackdoor puede abrir simultáneamente dos vías de daño: el robo de datos inmediato y el posible despliegue de ransomware.
----

== Origen y motivación ==
La superposición del código fuente de CNBackdoor (YiBackdoor) con IcedID y Latrodectus indica que sus desarrolladores probablemente son los mismos que crearon estas dos conocidas familias de malware. IcedID apareció originalmente como un troyano bancario y posteriormente fue reutilizado como herramienta de acceso inicial para ransomware; Latrodectus se considera su sucesor. La arquitectura modular de CNBackdoor, sus avanzadas técnicas anti-análisis y su filosofía de diseño de "primero persistir, luego expandir" apuntan a un actor de amenazas experimentado y con recursos considerables, cuya motivación presenta una naturaleza dual: por un lado, el beneficio económico o el espionaje comercial mediante el robo de datos; por otro, servir como eslabón previo en la cadena de ataque de ransomware, allanando el camino para ataques destructivos de mayor nivel. El limitado alcance de despliegue actual podría reflejar que la herramienta aún se encuentra en fase de prueba o despliegue temprano, pero su base de código y su potencial de pluginización implican que, una vez madure, podría escalar rápidamente a ataques a gran escala.

RegPhantom

2026-10-13T16:38:06Z

← Revisión anterior		Revisión del 16:38 13 oct 2026
Línea 58:		Línea 58:
	== Origen y Motivación ==		== Origen y Motivación ==
	RegPhantom tiene su origen en un actor de amenazas vinculado a China, según indican los análisis de múltiples firmas de seguridad (Nextron Systems, SOC Prime, IBM X-Force). La evidencia de atribución incluye: muestras firmadas con certificados de empresas chinas respetadas, una línea de tiempo de desarrollo continuo (muestras recolectadas entre junio y agosto de 2025), y características de código compartidas que indican un toolkit en evolución activa. La motivación principal no es financiera, sino estratégica y de ciberespionaje avanzado: RegPhantom está diseñado como una herramienta de post-explotación de élite, destinada a operaciones de intrusión de alto valor donde el objetivo es mantener control absoluto y silencioso sobre sistemas Windows críticos durante periodos prolongados, sin ser detectado por las defensas convencionales. Su diseño obsesivo por la invisibilidad forense —bloqueo de registro, borrado de memoria, carga reflexiva— refleja una madurez operativa y recursos significativos, típicos de actores APT patrocinados por estados con intereses en inteligencia estratégica y sabotaje silencioso.		RegPhantom tiene su origen en un actor de amenazas vinculado a China, según indican los análisis de múltiples firmas de seguridad (Nextron Systems, SOC Prime, IBM X-Force). La evidencia de atribución incluye: muestras firmadas con certificados de empresas chinas respetadas, una línea de tiempo de desarrollo continuo (muestras recolectadas entre junio y agosto de 2025), y características de código compartidas que indican un toolkit en evolución activa. La motivación principal no es financiera, sino estratégica y de ciberespionaje avanzado: RegPhantom está diseñado como una herramienta de post-explotación de élite, destinada a operaciones de intrusión de alto valor donde el objetivo es mantener control absoluto y silencioso sobre sistemas Windows críticos durante periodos prolongados, sin ser detectado por las defensas convencionales. Su diseño obsesivo por la invisibilidad forense —bloqueo de registro, borrado de memoria, carga reflexiva— refleja una madurez operativa y recursos significativos, típicos de actores APT patrocinados por estados con intereses en inteligencia estratégica y sabotaje silencioso.

			* [[Mitigaciones Backdoor\|Relación de acciones para mitigar el riesgo de esta actividad maliciosa.]]

			[[Category:Familias de malware\|Familias de malware]]

RegPhantom

2026-10-13T16:37:54Z

Descripcion de RegPhantom

Página nueva

RegPhantom es un rootkit de kernel de Windows con capacidades de backdoor, diseñado para permitir que procesos de usuario con bajos privilegios ejecuten código arbitrario directamente en el espacio del kernel, utilizando el registro de Windows como canal de comunicación encubierto. Su nivel de amenaza es crítico: no solo otorga al atacante el máximo nivel de privilegios en el sistema operativo, sino que está diseñado específicamente para no dejar rastro forense —sin archivos persistentes, sin entradas de registro visibles y con borrado de memoria post-ejecución—, lo que lo convierte en una de las herramientas de post-explotación más sigilosas documentadas hasta la fecha.
----

== Funcionamiento Técnico Detallado ==
RegPhantom opera como un driver firmado (.sys) que se carga en el sistema aprovechando la confianza que Windows otorga a los controladores con certificados válidos, lo que le permite eludir el Driver Signature Enforcement (DSE) sin necesidad de exploits. Su arquitectura se articula en varias fases claramente diferenciadas:

1. Registro de callbacks y establecimiento del canal encubierto:

En su rutina <code>DriverEntry</code>, el driver registra dos callbacks de kernel: <code>CmRegisterCallback</code> para interceptar operaciones del registro, y <code>PsSetCreateThreadNotifyRoutine</code> como mecanismo secundario de vigilancia. Al registrarse en <code>DriverEntry</code>, el comportamiento es indistinguible del de un driver legítimo, evitando sospechas.

2. Intercepción de comandos vía registro (canal de 56 bytes):

El driver intercepta todas las operaciones de escritura al registro a nivel de sistema mediante <code>CmRegisterCallback</code>. Filtra específicamente escrituras del tipo <code>REG_BINARY</code> con un tamaño exacto de 56 bytes (0x38). Cualquier clave del registro puede servir como canal de comando—la ruta es agnóstica. Cuando detecta una escritura coincidente, copia los 56 bytes, los descifra con XOR y bloquea la escritura original devolviendo <code>STATUS_ACCESS_DENIED</code>, garantizando que no quede ningún artefacto en el registro.

3. Carga reflexiva y ejecución en kernel:

Tras descifrar el comando, el driver carga reflexivamente un payload PE (Portable Executable) en la memoria del kernel, sin utilizar el cargador estándar de módulos. Esto significa que el código malicioso no aparece en la lista de drivers cargados (<code>PsLoadedModuleList</code>), volviéndose invisible para herramientas como <code>lm</code> en WinDbg o cualquier enumeración estándar de módulos del kernel.

4. Evasión forense y borrado de evidencia:

El diseño de RegPhantom está obsesivamente orientado a eliminar rastros:

* Comandos cifrados con XOR: Previene detección por firmas en el tráfico de datos.
* Re-cifrado post-procesamiento: No deja texto plano en memoria.
* Punteros de hooks codificados en XOR: Ofusca la memoria para dificultar el análisis forense.
* Borrado de memoria post-ejecución: Una vez ejecutado el payload PE, borra la región de memoria donde residía.
* Bloqueo de escrituras al registro: Elimina artefactos forenses al impedir que la escritura original se materialice.

5. Ofuscación anti-análisis:

El driver implementa ofuscación de flujo de control (CFG) con predicados opacos y llamadas indirectas a APIs, lo que impide que desensambladores y decompiladores resuelvan los destinos de las llamadas, haciendo las referencias cruzadas poco fiables en todo el binario. La baja variedad de predicados opacos, sin embargo, hace que la ofuscación sea vulnerable a simplificación basada en patrones.
----

== Impacto y Consecuencias ==
El impacto de una infección por RegPhantom es crítico y potencialmente irreversible para la integridad de un sistema Windows:

a) Compromiso total del kernel y escalada de privilegios absoluta:

RegPhantom permite que cualquier proceso de usuario sin privilegios escriba una secuencia de 56 bytes en el registro y obtenga ejecución de código arbitrario en modo kernel (Ring 0). Esto equivale a control absoluto del sistema operativo: desde el kernel, un atacante puede deshabilitar cualquier control de seguridad, leer memoria de cualquier proceso (incluyendo LSASS para robar credenciales), modificar estructuras de datos del sistema y persistir de forma prácticamente indetectable.

b) Destrucción de la cadena de evidencia forense:

Como advierte un analista, una vez que el kernel no es confiable, "ya no estás investigando al atacante, sino investigando lo que el atacante decidió dejarte ver". RegPhantom está diseñado para que no queden artefactos: no hay archivos en disco, no hay entradas de registro persistentes, no hay módulos en la lista de drivers, y la memoria del payload se borra. Esto significa que las herramientas forenses estándar (Sysmon, volcados de memoria, análisis de registro, enumeración de módulos) pueden devolver resultados limpios aunque el sistema esté comprometido, creando una falsa sensación de seguridad que es en sí misma un riesgo operativo grave.

c) Evasión de controles de seguridad y confianza en la cadena de suministro:

Al estar firmado con certificados válidos (algunos emitidos a empresas chinas), RegPhantom elude el DSE y puede cargarse en sistemas con políticas de seguridad por defecto. Esto demuestra que la firma digital ya no garantiza la integridad de un driver, erosionando la confianza en un control fundamental de Windows.

d) Riesgo en entornos de Active Directory:

En una red corporativa con Active Directory, un controlador de dominio comprometido con RegPhantom puede "mentir" a los analistas de seguridad. Un informe forense puede concluir "no hay signos de manipulación del DC", cuando en realidad el DC está comprometido a nivel de kernel y ocultando activamente la actividad maliciosa. Esto convierte a RegPhantom en una amenaza de movimiento lateral y persistencia a nivel de dominio extremadamente peligrosa.

e) Dificultad de detección y mitigación:

La detección efectiva no puede depender de artefactos de usuario (registro, archivos, procesos). Debe centrarse en el binario del driver mismo y sus patrones de código únicos. Las mitigaciones incluyen: bloqueo de drivers no confiables, monitoreo de uso sospechoso de <code>CmRegisterCallback</code>, reglas YARA específicas para las secuencias de bytes del driver, y captura de volcados completos de memoria del kernel para análisis forense profundo. La respuesta a incidentes requiere aislar el endpoint, eliminar el driver malicioso y revocar los certificados de firma abusados.
----

== Origen y Motivación ==
RegPhantom tiene su origen en un actor de amenazas vinculado a China, según indican los análisis de múltiples firmas de seguridad (Nextron Systems, SOC Prime, IBM X-Force). La evidencia de atribución incluye: muestras firmadas con certificados de empresas chinas respetadas, una línea de tiempo de desarrollo continuo (muestras recolectadas entre junio y agosto de 2025), y características de código compartidas que indican un toolkit en evolución activa. La motivación principal no es financiera, sino estratégica y de ciberespionaje avanzado: RegPhantom está diseñado como una herramienta de post-explotación de élite, destinada a operaciones de intrusión de alto valor donde el objetivo es mantener control absoluto y silencioso sobre sistemas Windows críticos durante periodos prolongados, sin ser detectado por las defensas convencionales. Su diseño obsesivo por la invisibilidad forense —bloqueo de registro, borrado de memoria, carga reflexiva— refleja una madurez operativa y recursos significativos, típicos de actores APT patrocinados por estados con intereses en inteligencia estratégica y sabotaje silencioso.

SSHDoor

2026-10-13T16:32:13Z

← Revisión anterior		Revisión del 16:32 13 oct 2026
Línea 55:		Línea 55:

	== Origen y Motivación ==		== Origen y Motivación ==
	SSHDoor tiene su origen en actores de amenazas vinculados al ciberespionaje ruso, específicamente atribuido a APT28 (Charming Kitten) según los feeds de inteligencia más recientes . Fue documentado por primera vez por ESET en enero de 2013, en el contexto de una campaña más amplia que también incluía el módulo malicioso para Apache Linux/Chapro.A . La motivación principal de SSHDoor no es económica ni oportunista, sino estratégica y de inteligencia: su diseño está optimizado para mantener acceso silencioso y prolongado a servidores Linux de alto valor, recolectar credenciales de administradores y usuarios privilegiados, y servir como plataforma de acceso persistente para operaciones de espionaje continuado . El uso de nombres de dominio que imitan servicios legítimos (como <code>openssh.info</code> y <code>linuxrepository.org</code>) demuestra una planificación cuidadosa para evitar sospechas de los administradores y prolongar la vida útil de la infección . La evolución de la familia hacia variantes con inyección PAM y rootkits indica que sus operadores siguen invirtiendo en investigación y desarrollo para mejorar la evasión y adaptarse a entornos defensivos más maduros .		SSHDoor tiene su origen en actores de amenazas vinculados al ciberespionaje ruso, específicamente atribuido a APT28 (Charming Kitten) según los feeds de inteligencia más recientes . Fue documentado por primera vez por ESET en enero de 2013, en el contexto de una campaña más amplia que también incluía el módulo malicioso para Apache Linux/Chapro.A . La motivación principal de SSHDoor no es económica ni oportunista, sino estratégica y de inteligencia: su diseño está optimizado para mantener acceso silencioso y prolongado a servidores Linux de alto valor, recolectar credenciales de administradores y usuarios privilegiados, y servir como plataforma de acceso persistente para operaciones de espionaje continuado . El uso de nombres de dominio que imitan servicios legítimos (como <code>openssh.info</code> y <code>linuxrepository.org</code>) demuestra una planificación cuidadosa para evitar sospechas de los administradores y prolongar la vida útil de la infección . La evolución de la familia hacia variantes con inyección PAM y rootkits indica que sus operadores siguen invirtiendo en investigación y desarrollo para mejorar la evasión y adaptarse a entornos defensivos más maduros.

			* [[Mitigaciones Backdoor\|Relación de acciones para mitigar el riesgo de esta actividad maliciosa.]]

			[[Category:Familias de malware\|Familias de malware]]

SSHDoor

2026-10-13T16:31:57Z

Descripcion de SSHDoor

Página nueva

SSHDoor es un troyano/backdoor para Linux cuyo nombre técnico completo es Linux/SSHDoor.A (también conocido como SSHdKit), diseñado para comprometer servidores que ejecutan el protocolo SSH (Secure Shell) . Su función principal es robar credenciales de inicio de sesión (usuarios y contraseñas) y garantizar al atacante un acceso remoto persistente y encubierto, incluso si las contraseñas legítimas cambian. A diferencia de un malware genérico, SSHDoor se implanta directamente en el binario del demonio SSH, camuflándose como el servicio legítimo del sistema.

== Funcionamiento Técnico Detallado ==
SSHDoor opera mediante la sustitución o inyección del binario <code>sshd</code> legítimo en el servidor comprometido . Una vez que el administrador o el sistema inicia el servicio SSH, el demonio troyanizado se ejecuta con la misma apariencia y funcionalidad visible que el original, pero con comportamientos maliciosos ocultos.

1. Robo de credenciales:

Cada vez que un usuario intenta autenticarse exitosamente vía SSH, el backdoor intercepta el nombre de usuario y la contraseña antes de que sean procesados por el sistema de autenticación legítimo . Los datos capturados se cifran usando una clave RSA de 1024 bits incrustada en el binario, se codifican en Base64 y se envían a un servidor remoto mediante peticiones HTTP POST . Las cadenas relacionadas con el comportamiento malicioso están ofuscadas con codificación XOR (utilizando la constante <code>0x23</code>) para dificultar el análisis estático y la detección por búsqueda de cadenas sospechosas .

2. Persistencia mediante doble mecanismo:

SSHDoor garantiza el acceso del atacante incluso si el administrador legítimo cambia su contraseña. Lo logra de dos formas :

* Contraseña hardcodeada: El binario contiene una contraseña fija incrustada en el código. Cualquier usuario que la introduzca recibe acceso inmediato al sistema, sin importar las credenciales configuradas en el servidor.
* Clave SSH incrustada: El malware también incorpora una clave pública SSH (formato <code>ssh-rsa</code>) cuyo par privado posee el atacante. Al autenticarse con esa clave privada correspondiente, el acceso se concede automáticamente.

3. Recolección de datos del sistema:

Al iniciarse, el backdoor envía al servidor de recolección la IP, el puerto en el que el servicio está escuchando y el nombre del host de la máquina comprometida, permitiendo al atacante mapear su infraestructura de víctimas .

4. Variantes modernas (SSHdKit):

Las versiones más recientes de la familia, detectadas en 2025 y 2026, han evolucionado hacia técnicas más sigilosas. Algunas variantes utilizan inyección de módulos PAM (Pluggable Authentication Modules) mediante archivos <code>.so</code> personalizados en lugar de modificar directamente el binario <code>sshd</code> . Este enfoque evita alterar archivos del sistema como <code>pam_unix.so</code>, lo que le permite pasar verificaciones de herramientas como Lynis, chkrootkit y rkhunter, y no deja rastro en <code>authorized_keys</code> . Otras variantes monitorean en puertos altos como 60001 y abren reverse shells, además de desplegar componentes de rootkit que ocultan su presencia de comandos como <code>ps</code> y <code>netstat</code> .

== Impacto y Consecuencias ==
El impacto de una infección por SSHDoor es crítico para cualquier infraestructura Linux expuesta, especialmente servidores de producción, bases de datos y sistemas de administración remota.

a) Compromiso total del servidor:

El robo de credenciales de SSH otorga al atacante acceso con privilegios de administrador a la máquina comprometida. Desde allí puede ejecutar comandos arbitrarios, instalar más malware, modificar configuraciones, acceder a bases de datos y, en última instancia, controlar completamente el servidor .

b) Persistencia garantizada:

El doble mecanismo de persistencia (contraseña hardcodeada + clave SSH incrustada) significa que cambiar la contraseña del usuario afectado no expulsa al atacante. Incluso una auditoría de seguridad convencional puede no detectar la puerta trasera si solo se revisan las cuentas de usuario y las claves autorizadas .

c) Movimiento lateral y escalada de privilegios:

Las credenciales robadas de un servidor suelen ser reutilizadas para acceder a otros sistemas de la red corporativa, facilitando el movimiento lateral. Si el servidor comprometido tiene acceso a recursos compartidos, bases de datos o sistemas internos, el atacante puede extender su control rápidamente .

d) Dificultad de detección:

SSHDoor se ejecuta como un proceso llamado <code>sshd</code>, con la misma ruta esperada (<code>/usr/sbin/sshd</code> en condiciones normales). Esto hace que herramientas de monitoreo estándar como <code>ps aux | grep sshd</code> no detecten anomalías evidentes . Las variantes que usan inyección PAM o rootkits ocultan aún más su presencia, evadiendo controles de integridad de archivos y auditorías de seguridad comunes .

e) Exfiltración silenciosa y prolongada:

La comunicación con el servidor de recolección se realiza mediante HTTP POST cifrado, lo que permite al atacante recibir credenciales continuamente sin activar alertas de tráfico anómalo, siempre que el firewall corporativo permita salida HTTP . Esto facilita operaciones de espionaje prolongado sin detección.

f) Riesgo reputacional, regulatorio y de cumplimiento:

Un servidor comprometido con acceso SSH persistente puede ser utilizado para alojar y distribuir malware (como se documentó con la asociación a Linux/Chapro.A) , lo que expone a la organización a sanciones regulatorias, pérdida de confianza de clientes y daños legales si el servidor se utiliza para atacar a terceros.

g) Atribución a grupos APT:

En 2026, feeds de amenazas han asociado SSHDoor a APT28 (Charming Kitten), un actor de origen ruso vinculado a operaciones de ciberespionaje contra gobiernos y organizaciones estratégicas . Esto eleva la gravedad del incidente de un simple troyano a una operación de inteligencia patrocinada por un estado, con implicaciones geopolíticas y de seguridad nacional.

== Origen y Motivación ==
SSHDoor tiene su origen en actores de amenazas vinculados al ciberespionaje ruso, específicamente atribuido a APT28 (Charming Kitten) según los feeds de inteligencia más recientes . Fue documentado por primera vez por ESET en enero de 2013, en el contexto de una campaña más amplia que también incluía el módulo malicioso para Apache Linux/Chapro.A . La motivación principal de SSHDoor no es económica ni oportunista, sino estratégica y de inteligencia: su diseño está optimizado para mantener acceso silencioso y prolongado a servidores Linux de alto valor, recolectar credenciales de administradores y usuarios privilegiados, y servir como plataforma de acceso persistente para operaciones de espionaje continuado . El uso de nombres de dominio que imitan servicios legítimos (como <code>openssh.info</code> y <code>linuxrepository.org</code>) demuestra una planificación cuidadosa para evitar sospechas de los administradores y prolongar la vida útil de la infección . La evolución de la familia hacia variantes con inyección PAM y rootkits indica que sus operadores siguen invirtiendo en investigación y desarrollo para mejorar la evasión y adaptarse a entornos defensivos más maduros .

VBREVSHELL

2026-10-13T16:30:01Z

← Revisión anterior		Revisión del 16:30 13 oct 2026
Línea 17:		Línea 17:
	== Origen y Motivación ==		== Origen y Motivación ==
	VBREVSHELL tiene su origen en APT42, un grupo de amenazas persistentes avanzadas de origen iraní que ha estado activo desde al menos 2015 y cuya actividad se ha observado hasta febrero de 2024. La motivación principal de este actor es el ciberespionaje con fines geopolíticos, dirigido a la recolección de inteligencia sobre objetivos gubernamentales, militares, académicos y de derechos humanos, tanto dentro como fuera de Irán. VBREVSHELL no es un malware de motivación financiera ni de cibercrimen oportunista; es una herramienta de acceso remoto diseñada para ser desplegada en operaciones de intrusión persistentes, donde el objetivo es mantener el acceso silencioso durante el mayor tiempo posible para extraer información estratégica. El hecho de que su diseño evite deliberadamente la ejecución si detecta ESET Security sugiere una adaptación cuidadosa a entornos específicos, característica típica de actores APT con recursos y planificación a largo plazo.		VBREVSHELL tiene su origen en APT42, un grupo de amenazas persistentes avanzadas de origen iraní que ha estado activo desde al menos 2015 y cuya actividad se ha observado hasta febrero de 2024. La motivación principal de este actor es el ciberespionaje con fines geopolíticos, dirigido a la recolección de inteligencia sobre objetivos gubernamentales, militares, académicos y de derechos humanos, tanto dentro como fuera de Irán. VBREVSHELL no es un malware de motivación financiera ni de cibercrimen oportunista; es una herramienta de acceso remoto diseñada para ser desplegada en operaciones de intrusión persistentes, donde el objetivo es mantener el acceso silencioso durante el mayor tiempo posible para extraer información estratégica. El hecho de que su diseño evite deliberadamente la ejecución si detecta ESET Security sugiere una adaptación cuidadosa a entornos específicos, característica típica de actores APT con recursos y planificación a largo plazo.

			* [[Mitigaciones Backdoor\|Relación de acciones para mitigar el riesgo de esta actividad maliciosa.]]

			[[Category:Familias de malware\|Familias de malware]]

VBREVSHELL

2026-10-13T16:29:50Z

Descripcion de VBREVSHELL

Página nueva

VBREVSHELL es un backdoor implementado como una macro VBA que establece una reverse shell apoyándose exclusivamente en llamadas a la API de Windows. Fue documentado por Mandiant y su actividad se ha vinculado principalmente al grupo APT42, un actor de amenazas de origen iraní que lo ha utilizado en operaciones de ciberespionaje, aunque también se ha observado su uso por parte de otros actores como el grupo Tonto Team en campañas dirigidas a universidades surcoreanas.

== Funcionamiento Técnico Detallado ==
VBREVSHELL opera como un componente dentro de una cadena de infección multi-etapa y su diseño prioriza la ejecución sin depender de binarios tradicionales en disco. El vector de entrada más documentado involucra archivos CHM (Compiled HTML Help) maliciosos, que al ser abiertos ejecutan código JavaScript o VBScript que descarga y lanza una DLL maliciosa. Esta DLL realiza verificaciones anti-sandbox —como comprobar si el número de archivos en la carpeta <code>%TEMP%</code> es inferior a 18, señal de un entorno virtual— y, si pasa los controles, crea y ejecuta un archivo VBE (Visual Basic Encoded) en <code>%TEMP%</code>.

Ese archivo VBE es precisamente ReVBShell, el componente central de la amenaza. A diferencia de otros backdoors que cargan dependencias externas, ReVBShell ejecuta sus operaciones apoyándose únicamente en llamadas a la API de Windows desde el propio intérprete de VBScript. Para lograr la persistencia, el malware registra su ejecución en la clave <code>SOFTWARE\Microsoft\Windows\CurrentVersion\Run</code> del registro de Windows.

Una vez activo, ReVBShell intenta conectarse a un servidor de mando y control (C2) preconfigurado. Si establece la conexión, el atacante obtiene una shell remota con capacidades que incluyen: obtención de información del sistema operativo mediante consultas WMI (<code>SELECT * FROM Win32_OperatingSystem</code>), recolección de datos de adaptadores de red y direcciones MAC (<code>SELECT * FROM Win32_NetworkAdapterConfiguration WHERE MACAddress > <nowiki>''</nowiki></code>), enumeración de procesos activos (<code>SELECT * FROM Win32_Process</code>), así como funciones de descarga y ejecución de archivos y una funcionalidad tipo <code>WGET</code> para traer contenido externo. La infraestructura C2 documentada para VBREVSHELL utiliza predominantemente el puerto 8082 en múltiples direcciones IP.

== Impacto y Consecuencias ==
El impacto de VBREVSHELL es alto dentro del contexto de una intrusión activa, ya que otorga al atacante una shell interactiva con control total sobre el sistema comprometido. A través de esta shell, un operador malicioso puede ejecutar comandos arbitrarios, descargar herramientas adicionales (keyloggers, ransomware, stealers), exfiltrar información sensible y utilizar el host como punto de pivote para movimiento lateral dentro de la red corporativa.

Una de las consecuencias más críticas es su capacidad de evasión. VBREVSHELL incluye lógica que verifica la presencia de productos de seguridad específicos como ESET Security; si detecta su instalación, simplemente no ejecuta ninguna acción maliciosa, permaneciendo inerte. Esto le permite sobrevivir en sistemas protegidos por determinadas soluciones sin activar alertas, lo que dificulta la detección temprana. Adicionalmente, al operar desde un archivo VBE en <code>%TEMP%</code> y depender solo de APIs nativas de Windows, el malware no requiere archivos ejecutables adicionales, lo que complica su identificación mediante análisis de disco tradicionales.

Desde la perspectiva de atribución y respuesta, la presencia de VBREVSHELL en un entorno comprometido es un indicador sólido de actividad APT, específicamente de APT42 (también conocido como TA428 o APT31). Su uso se ha documentado en campañas de ciberespionaje contra objetivos gubernamentales, académicos y de infraestructura crítica, lo que eleva la gravedad del incidente y exige protocolos de respuesta a incidentes de nivel avanzado.

== Origen y Motivación ==
VBREVSHELL tiene su origen en APT42, un grupo de amenazas persistentes avanzadas de origen iraní que ha estado activo desde al menos 2015 y cuya actividad se ha observado hasta febrero de 2024. La motivación principal de este actor es el ciberespionaje con fines geopolíticos, dirigido a la recolección de inteligencia sobre objetivos gubernamentales, militares, académicos y de derechos humanos, tanto dentro como fuera de Irán. VBREVSHELL no es un malware de motivación financiera ni de cibercrimen oportunista; es una herramienta de acceso remoto diseñada para ser desplegada en operaciones de intrusión persistentes, donde el objetivo es mantener el acceso silencioso durante el mayor tiempo posible para extraer información estratégica. El hecho de que su diseño evite deliberadamente la ejecución si detecta ESET Security sugiere una adaptación cuidadosa a entornos específicos, característica típica de actores APT con recursos y planificación a largo plazo.

XRed

2026-10-13T16:28:32Z

← Revisión anterior		Revisión del 16:28 13 oct 2026
Línea 76:		Línea 76:
	== Origen y motivación ==		== Origen y motivación ==
	XRed tiene su origen en un desarrollador individual con motivación principalmente económica, aunque su uso se ha diversificado hacia campañas de cibercrimen organizado e incluso actores patrocinados por estados. Diversas evidencias lingüísticas en el código —comentarios, cadenas y nombres de variables en turco— apuntan a que su creador es un hablante nativo de ese idioma, lo que sugiere un origen en el ecosistema del cibercrimen turco, conocido por producir herramientas de acceso remoto (RAT) y stealers de bajo costo. A diferencia de un APT puro, la motivación inicial fue financiera: venta del malware en foros clandestinos, servicios de alquiler del backdoor (MaaS, Malware-as-a-Service) y fraude directo. Sin embargo, la modularidad del framework y su bajo costo de adquisición lo han convertido en una herramienta atractiva también para grupos de espionaje y sabotaje, lo que amplifica su peligro y lo posiciona como una amenaza híbrida entre el crimen común y las operaciones APT patrocinadas por estados.		XRed tiene su origen en un desarrollador individual con motivación principalmente económica, aunque su uso se ha diversificado hacia campañas de cibercrimen organizado e incluso actores patrocinados por estados. Diversas evidencias lingüísticas en el código —comentarios, cadenas y nombres de variables en turco— apuntan a que su creador es un hablante nativo de ese idioma, lo que sugiere un origen en el ecosistema del cibercrimen turco, conocido por producir herramientas de acceso remoto (RAT) y stealers de bajo costo. A diferencia de un APT puro, la motivación inicial fue financiera: venta del malware en foros clandestinos, servicios de alquiler del backdoor (MaaS, Malware-as-a-Service) y fraude directo. Sin embargo, la modularidad del framework y su bajo costo de adquisición lo han convertido en una herramienta atractiva también para grupos de espionaje y sabotaje, lo que amplifica su peligro y lo posiciona como una amenaza híbrida entre el crimen común y las operaciones APT patrocinadas por estados.

			* [[Mitigaciones Backdoor\|Relación de acciones para mitigar el riesgo de esta actividad maliciosa.]]

			[[Category:Familias de malware\|Familias de malware]]

XRed

2026-10-13T16:28:18Z

Descripcion de XRed

Página nueva

XRed, también conocido como el gusano Synaptics, es un troyano de puerta trasera (backdoor) modular combinado con capacidades de gusano, escrito principalmente en Delphi, que ha estado activo de forma continua desde al menos 2019. Su característica más distintiva es que se disfraza completamente del controlador legítimo de Synaptics —nombre y rutas de un componente de hardware real— para pasar desapercibido tanto para el usuario como para las soluciones de seguridad. Su nivel de amenaza se clasifica como alto: no solo posee capacidades completas de control remoto y robo de datos, sino que además se propaga de forma autónoma mediante USB y macros de Office, y su calidad de desarrollo indica que no es una obra amateur, sino una herramienta madura que probablemente se comercializa en el ecosistema del cibercrimen como servicio (Cybercrime-as-a-Service, CaaS).
----

== Funcionamiento técnico detallado ==
La cadena de infección de XRed está cuidadosamente diseñada y presenta una arquitectura de múltiples etapas, múltiples procesos y múltiples rutas de persistencia, orientada a evadir defensas en profundidad.

=== Vectores de entrada y camuflaje de ejecución ===
Los principales métodos de distribución de XRed incluyen: controladores de hardware troyanizados (especialmente los que acompañan a adaptadores USB-C), canales de distribución de software comprometidos (como el caso de mayo de 2025, cuando se confirmó que el fabricante de impresoras ProColored distribuyó paquetes de instalación infectados con XRed), y correos de phishing. En una campaña activa detectada en octubre de 2025, los atacantes se hicieron pasar por el Ministerio de Hacienda de India, enviando correos sobre supuestas infracciones fiscales. El vector era un archivo VBS ("Tax Penalty Notice.vbs") que descargaba un ejecutable desde <code><nowiki>https://googlevip</nowiki>[.]shop/216.250.104.166ClientSetup[.]exe</code> y lo ejecutaba silenciosamente mediante PowerShell tras un retraso de 8 a 15 segundos para evadir entornos sandbox.

=== Instalación y persistencia ===
Una vez ejecutado, XRed se copia a sí mismo en <code>C:\ProgramData\Synaptics\</code>, disfrazado como <code>Synaptics.exe</code>. Para garantizar la persistencia tras reinicios, crea una clave en el registro de Windows:

text
HKCU\Software\Microsoft\Windows\CurrentVersion\Run
Nombre: "Synaptics Pointing Device Driver"
Adicionalmente, verifica la existencia de un mutex llamado <code>Synaptics2X</code> para asegurarse de que solo se ejecute una instancia en el sistema, evitando duplicaciones que podrían delatar su presencia.

=== Recolección y exfiltración inicial ===
Tras la instalación, XRed recopila información del sistema: nombre de usuario, dirección MAC, nombre del equipo, versión del sistema operativo y otros identificadores. Estos datos son enviados mediante SMTP a direcciones de correo hardcodeadas (como <code>xredline1@gmail.com</code>) controladas por el atacante. Esta técnica de exfiltración vía correo electrónico es inusual y permite al atacante recibir los datos sin necesidad de un servidor C2 tradicional.

=== Comunicación con el centro de mando y control (C2) ===
El canal de C2 se establece a través del dominio <code>xred.mooo.com</code>, cuya resolución dinámica se gestiona mediante la API de <code>freedns.afraid.org</code>. Esto permite al atacante cambiar la IP del servidor sin modificar el binario, dificultando el bloqueo por parte de defensas perimetrales.

=== Capacidades de control remoto ===
El backdoor acepta múltiples comandos desde el C2, entre ellos:

* Ejecución de comandos en la línea de comandos (CMD)
* Captura de pantalla del escritorio
* Listado y navegación de directorios
* Descarga, carga y eliminación de archivos
* Registro de pulsaciones de teclado (keylogger) mediante hooks de teclado
* Control del ratón y del sistema en general

=== Propagación tipo gusano ===
XRed se propaga por dos vías principales:

* USB: crea un archivo <code>autorun.inf</code> en unidades extraíbles para ejecutarse automáticamente al conectarlas.
* Excel: infecta archivos <code>.xlsm</code> inyectando macros VBA maliciosas, y modifica el registro para deshabilitar las advertencias de seguridad de macros en Office.

=== Variantes recientes ===
Las versiones más nuevas incorporan técnicas de evasión más avanzadas: liberación multi-etapa del payload, carga de componentes maliciosos mediante <code>svchost.exe</code>, y el uso de servicios del sistema para lograr persistencia redundante. En 2025, XRed fue detectado distribuyéndose a través del instalador de software de impresoras ProColored, lo que demuestra que el actor detrás del malware sigue activamente comprometiendo cadenas de suministro legítimas.
----

== Impacto y consecuencias ==
El impacto de XRed es multidimensional y de alta severidad, tanto a nivel individual como organizacional:

a) Compromiso total del endpoint:

Al funcionar como un backdoor con control remoto completo, XRed otorga al atacante la capacidad de operar la máquina comprometida como si estuviera sentado frente a ella: ejecutar programas, robar archivos, espiar la pantalla y capturar todo lo que el usuario teclea.

b) Robo de credenciales y datos sensibles:

El keylogger integrado y la capacidad de acceder a archivos permiten la exfiltración de credenciales corporativas, correos, documentos confidenciales y datos financieros. Esto facilita ataques posteriores como fraude, suplantación de identidad y movimiento lateral en la red.

c) Propagación interna y multiplataforma:

Su capacidad de infectar unidades USB y archivos de Excel convierte a XRed en un riesgo de propagación horizontal dentro de organizaciones, especialmente en entornos donde se comparten archivos por medios extraíbles o por correo. Un solo empleado infectado puede comprometer toda una red.

d) Evasión de controles tradicionales:

Al disfrazarse de un proceso legítimo de Synaptics y usar nombres y rutas plausibles (<code>C:\ProgramData\Synaptics\</code>), XRed evade muchas soluciones antivirus basadas en firmas y dificulta la detección por parte del usuario o del administrador.

e) Dificultad de erradicación:

Su persistencia en registro, su capacidad de reinstalarse vía USB y su C2 dinámico hacen que la simple eliminación del binario no sea suficiente. Se requiere análisis forense completo para garantizar la desinfección.

f) Riesgo reputacional y regulatorio:

Una infección por XRed en una organización puede derivar en incumplimientos normativos (protección de datos, PCI-DSS, ISO 27001), sanciones regulatorias y daño reputacional significativo si se confirma la fuga de información sensible.

g) Actividad reciente (2025):

En octubre de 2025, Mimecast identificó una campaña de XRed que suplantaba al Ministerio de Hacienda de India con correos sobre supuestas infracciones fiscales. Los objetivos eran principalmente filiales indias de empresas con sede en Reino Unido o Estados Unidos, lo que evidencia que XRed sigue siendo utilizado en campañas activas de ciberespionaje y cibercrimen.
----

== Origen y motivación ==
XRed tiene su origen en un desarrollador individual con motivación principalmente económica, aunque su uso se ha diversificado hacia campañas de cibercrimen organizado e incluso actores patrocinados por estados. Diversas evidencias lingüísticas en el código —comentarios, cadenas y nombres de variables en turco— apuntan a que su creador es un hablante nativo de ese idioma, lo que sugiere un origen en el ecosistema del cibercrimen turco, conocido por producir herramientas de acceso remoto (RAT) y stealers de bajo costo. A diferencia de un APT puro, la motivación inicial fue financiera: venta del malware en foros clandestinos, servicios de alquiler del backdoor (MaaS, Malware-as-a-Service) y fraude directo. Sin embargo, la modularidad del framework y su bajo costo de adquisición lo han convertido en una herramienta atractiva también para grupos de espionaje y sabotaje, lo que amplifica su peligro y lo posiciona como una amenaza híbrida entre el crimen común y las operaciones APT patrocinadas por estados.

XShellGhost

2026-10-13T16:25:52Z

← Revisión anterior		Revisión del 16:25 13 oct 2026
Línea 61:		Línea 61:
	== Origen y motivación ==		== Origen y motivación ==
	XShellGhost / ShadowPad tiene su origen en un actor de amenazas persistente avanzado (APT) vinculado a operaciones de ciberespionaje, atribuido por múltiples firmas de seguridad (Kaspersky, ESET, Symantec) al ecosistema Winnti / APT41, un grupo con presuntos vínculos con intereses estatales chinos. La motivación principal no era económica, sino estratégica y de inteligencia: obtener acceso silencioso y persistente a infraestructuras críticas, robar propiedad intelectual, credenciales corporativas y posicionarse dentro de redes gubernamentales y empresariales de alto valor. A diferencia de un ransomware (motivación financiera), ShadowPad estaba diseñado para pasar desapercibido durante largos periodos, recolectar información y servir como plataforma de acceso continua. El uso de la cadena de suministro como vector refleja una planificación sofisticada y recursos considerables, característicos de actores APT patrocinados por estados.		XShellGhost / ShadowPad tiene su origen en un actor de amenazas persistente avanzado (APT) vinculado a operaciones de ciberespionaje, atribuido por múltiples firmas de seguridad (Kaspersky, ESET, Symantec) al ecosistema Winnti / APT41, un grupo con presuntos vínculos con intereses estatales chinos. La motivación principal no era económica, sino estratégica y de inteligencia: obtener acceso silencioso y persistente a infraestructuras críticas, robar propiedad intelectual, credenciales corporativas y posicionarse dentro de redes gubernamentales y empresariales de alto valor. A diferencia de un ransomware (motivación financiera), ShadowPad estaba diseñado para pasar desapercibido durante largos periodos, recolectar información y servir como plataforma de acceso continua. El uso de la cadena de suministro como vector refleja una planificación sofisticada y recursos considerables, característicos de actores APT patrocinados por estados.

			* [[Mitigaciones Backdoor\|Relación de acciones para mitigar el riesgo de esta actividad maliciosa.]]

			[[Category:Familias de malware\|Familias de malware]]

XShellGhost

2026-10-13T16:25:24Z

Descripcion de XShellGhost

Página nueva

XShellGhost (nombre técnico asociado a ShadowPad) es un caso emblemático de ataque a la cadena de suministro (Supply Chain Attack). En julio de 2017, la empresa NetSarang —fabricante de las populares herramientas de administración remota Xshell, Xmanager y Xftp— publicó versiones de sus productos que contenían un backdoor inyectado directamente en el módulo <code>nssock2.dll</code>. Dado que el binario conservaba la firma digital legítima de NetSarang, muchas soluciones antivirus no lo detectaron por confiar en el certificado, lo que permitió que el código malicioso se distribuyera masivamente a administradores de sistemas, ingenieros de red y personal de TI en todo el mundo. Kaspersky lo clasificó como Backdoor.Win32.ShadowPad.a y lo vinculó a un actor de amenazas avanzado (presuntamente relacionado con el grupo APT41 / Winnti), lo que elevó la gravedad del incidente a nivel de ciberespionaje.
----

== Funcionamiento técnico detallado ==
El backdoor XShellGhost fue diseñado bajo un modelo modular, sigiloso y multicapa, orientado a la persistencia prolongada y a la evasión de detección. Su funcionamiento se articula en varias fases:

1. Activación y comunicación inicial (fase DNS):

Al ejecutarse Xshell, el binario legítimo cargaba <code>nssock2.dll</code>, el cual verificaba mediante consultas DNS de tipo TXT si debía activarse. Utilizaba un Domain Generation Algorithm (DGA) que generaba un nuevo dominio C2 cada mes, con un patrón predecible para el atacante. Las respuestas TXT contenían la clave de descifrado del siguiente ''stage''. Este mecanismo permitía que el backdoor permaneciera en estado "dormido" sin tráfico HTTP sospechoso, y solo se activara cuando el atacante respondía desde el dominio correspondiente.

2. Framework modular en memoria (Root + Plugins):

Una vez activado, el backdoor descifraba y ejecutaba en memoria un shellcode Root que servía como orquestador. Este Root contenía submódulos con funciones específicas:

* <code>Install</code>: ajustaba privilegios, creaba mutex para evitar múltiples instancias y, si era necesario, se inyectaba en un proceso legítimo (<code>svchost.exe</code> o similar) para operar fileless.
* <code>Config</code>: leía y escribía la configuración persistente del malware.
* <code>Plugins</code>: cargaba dinámicamente plugins adicionales (keylogger, exfiltrador, RAT, etc.) según las órdenes del C2.
* <code>Online</code> / <code>DNS</code>: gestionaban los canales de comunicación con el servidor de mando y control.

3. Persistencia en el registro de Windows (VFS oculto):

El backdoor creaba un sistema de archivos virtual (VFS) cifrado dentro del Registro de Windows, lo que le permitía almacenar plugins, configuraciones y datos robados sin dejar rastros en disco. Esta técnica es especialmente difícil de detectar porque los archivos nunca existen como archivos reales en el sistema de ficheros.

4. Comunicación cifrada y comandos:

Los comandos desde el C2 viajaban cifrados (usualmente AES + RSA) dentro de registros DNS o, en fases posteriores, mediante HTTP/HTTPS camuflado. Esto permitía ejecutar órdenes como descarga de archivos, ejecución de comandos, captura de pantalla, robo de credenciales, y movimiento lateral dentro de la red.

5. Evasión y anti-análisis:

El malware verificaba la presencia de entornos virtuales o sandbox, retardaba su ejecución mediante ''sleep loops'' y usaba llamadas nativas de Windows para dificultar el análisis dinámico. Además, al estar firmado digitalmente, pasaba por controles de integridad y listas blancas corporativas.
----

== Impacto y consecuencias ==
El impacto de XShellGhost fue crítico y de alcance global, por varias razones:

a) Compromiso de infraestructura crítica:

Xshell es una herramienta usada masivamente por administradores de sistemas para gestionar servidores Linux/Unix, routers, switches y dispositivos de red. Un backdoor en esta herramienta equivale a entregar las llaves de la infraestructura a un atacante. Cualquier organización que hubiera actualizado Xshell entre el 18 de julio y el 4 de agosto de 2017 quedó potencialmente expuesta.

b) Naturaleza de ciberespionaje:

El grupo detrás de ShadowPad está vinculado a campañas de espionaje estatal y robo de propiedad intelectual (APT41/Winnti, con presunta relación con intereses chinos). Los objetivos típicos incluían gobiernos, bancos, empresas tecnológicas y operadores de telecomunicaciones en Asia, Europa y América.

c) Erosión de la confianza en la cadena de suministro:

El caso demostró que la firma digital ya no garantiza inocuidad. Un atacante con acceso al entorno de compilación de un fabricante puede firmar malware con un certificado legítimo, burlando la mayoría de controles tradicionales (antivirus, EDR basados en firma, políticas de whitelisting).

d) Riesgo de movimiento lateral y exfiltración silenciosa:

Dado que el backdoor operaba en memoria, sobrevivía reinicios y se comunicaba de forma cifrada, las organizaciones afectadas podían ser comprometidas durante meses o años sin detección, permitiendo robo de credenciales, propiedad intelectual y datos sensibles.

e) Consecuencias regulatorias y reputacionales:

NetSarang tuvo que retirar las versiones comprometidas, emitir parches urgentes, notificar a clientes y enfrentar escrutinio público. Afectó también la reputación del ecosistema de software legítimo y forzó a muchas empresas a revisar sus procesos de verificación de proveedores (SBOM, análisis de integridad, verificación de hashes).

f) Legado técnico:

ShadowPad se convirtió en un framework reutilizable que ha sido observado en múltiples campañas posteriores (2018–2024), evolucionando hacia variantes más complejas. Su diseño influyó en el desarrollo de otras familias APT como PlugX, Winnti y Passcv.
----

== Origen y motivación ==
XShellGhost / ShadowPad tiene su origen en un actor de amenazas persistente avanzado (APT) vinculado a operaciones de ciberespionaje, atribuido por múltiples firmas de seguridad (Kaspersky, ESET, Symantec) al ecosistema Winnti / APT41, un grupo con presuntos vínculos con intereses estatales chinos. La motivación principal no era económica, sino estratégica y de inteligencia: obtener acceso silencioso y persistente a infraestructuras críticas, robar propiedad intelectual, credenciales corporativas y posicionarse dentro de redes gubernamentales y empresariales de alto valor. A diferencia de un ransomware (motivación financiera), ShadowPad estaba diseñado para pasar desapercibido durante largos periodos, recolectar información y servir como plataforma de acceso continua. El uso de la cadena de suministro como vector refleja una planificación sofisticada y recursos considerables, característicos de actores APT patrocinados por estados.

Campaña GhostAction (Flujos de trabajo maliciosos de GitHub Actions para robo de credenciales)

2026-10-12T15:53:40Z

← Revisión anterior		Revisión del 15:53 12 oct 2026
Línea 456:		Línea 456:
	== Etiquetas / Categorías ==		== Etiquetas / Categorías ==
	<code>ghostaction</code> <code>github-actions</code> <code>supply-chain-attack</code> <code>cadena-de-suministro</code> <code>robo-de-credenciales</code> <code>credential-theft</code> <code>ci-cd</code> <code>secretos</code> <code>github</code> <code>pat</code> <code>token-de-acceso-personal</code> <code>aws</code> <code>azure</code> <code>google-cloud</code> <code>firebase</code> <code>openai</code> <code>anthropic</code> <code>openrouter</code> <code>slack</code> <code>discord</code> <code>telegram</code> <code>sendgrid</code> <code>pypi</code> <code>npm</code> <code>dockerhub</code> <code>ghcr</code> <code>crates-io</code> <code>xmrig</code> <code>criptomineria</code> <code>monero</code> <code>kuafuai</code> <code>devopsgpt</code> <code>pyxel</code> <code>athenadriver</code> <code>uber</code> <code>henrywoo</code> <code>kitao</code> <code>xxyangyoulin</code> <code>security-audit</code> <code>github-actions-security</code> <code>security-check</code> <code>git-history</code> <code>exfiltracion</code> <code>http-simple</code> <code>193-32-204-199</code> <code>stepsecurity</code> <code>socket</code> <code>gitguardian</code> <code>octubre-2026</code>		<code>ghostaction</code> <code>github-actions</code> <code>supply-chain-attack</code> <code>cadena-de-suministro</code> <code>robo-de-credenciales</code> <code>credential-theft</code> <code>ci-cd</code> <code>secretos</code> <code>github</code> <code>pat</code> <code>token-de-acceso-personal</code> <code>aws</code> <code>azure</code> <code>google-cloud</code> <code>firebase</code> <code>openai</code> <code>anthropic</code> <code>openrouter</code> <code>slack</code> <code>discord</code> <code>telegram</code> <code>sendgrid</code> <code>pypi</code> <code>npm</code> <code>dockerhub</code> <code>ghcr</code> <code>crates-io</code> <code>xmrig</code> <code>criptomineria</code> <code>monero</code> <code>kuafuai</code> <code>devopsgpt</code> <code>pyxel</code> <code>athenadriver</code> <code>uber</code> <code>henrywoo</code> <code>kitao</code> <code>xxyangyoulin</code> <code>security-audit</code> <code>github-actions-security</code> <code>security-check</code> <code>git-history</code> <code>exfiltracion</code> <code>http-simple</code> <code>193-32-204-199</code> <code>stepsecurity</code> <code>socket</code> <code>gitguardian</code> <code>octubre-2026</code>

			[[Categoría:CAMPAÑAS\|CAMPAÑAS]]

Campaña GhostAction (Flujos de trabajo maliciosos de GitHub Actions para robo de credenciales)

2026-10-12T15:53:15Z

Descripcion de Campaña GhostAction (Flujos de trabajo maliciosos de GitHub Actions para robo de credenciales)

Página nueva

GhostAction es una campaña masiva de ataque a la cadena de suministro dirigida a repositorios de GitHub, cuyo objetivo es el robo de credenciales de CI/CD, secretos de GitHub Actions y credenciales de nube, IA y SaaS. La campaña fue identificada por primera vez en septiembre de 2025 por GitGuardian, y ha resurgido en múltiples oleadas a lo largo de 2026, incluyendo una nueva ola significativa el 8 de octubre de 2026.

El modus operandi de GhostAction consiste en comprometer cuentas de mantenedores de código abierto de alto perfil para inyectar un flujo de trabajo malicioso (workflow) en cientos o miles de repositorios. El flujo de trabajo, disfrazado como una "auditoría de seguridad" (<code>security-audit.yml</code>, <code>github_actions_security.yml</code> o <code>security-check.yml</code>), se ejecuta automáticamente en cada <code>push</code> y exfiltra datos confidenciales a un servidor controlado por el atacante mediante HTTP simple (sin cifrar) a una dirección IP codificada.

La campaña se ha atribuido a un actor de amenazas no identificado, y se caracteriza por su persistencia, automatización y escala masiva. A fecha de octubre de 2026, se ha identificado más de 500 cuentas de GitHub que han implementado el flujo de trabajo malicioso en decenas de miles de repositorios desde el 7 de octubre de 2026.
----

== Nombres Alternativos / Alias ==

* GhostAction (Nombre principal de la campaña)
* Campaña de robo de credenciales de GitHub Actions (Por el vector)
* Ataque a la cadena de suministro de GitHub (Por el tipo de ataque)
* Security Audit Workflow Malware (Por el disfraz)
* Mini Shai-Hulud (Familia de malware relacionada)

----

== Fecha de Detección / Actividad ==

* Primera Detección: Septiembre de 2025 (GitGuardian)
* Oleadas Posteriores:
** Septiembre de 2025: 817 repositorios, 327 usuarios, 3,325 secretos exfiltrados.
** Octubre–Diciembre 2025, Marzo 2026: ~75 repositorios (endpoint <code>170.39.218.2</code>).
** Noviembre 2025, Marzo–Abril 2026: ~250 repositorios (endpoint <code>*.oast.fun</code> / Interactsh).
** Agosto–Septiembre 2026: 772 repositorios, 373 usuarios/organizaciones, 2,577 secretos objetivo.
** 8 de octubre de 2026: 346 repositorios en dos ventanas automatizadas (27 de <code>kitao</code>, 318 de <code>henrywoo</code> + <code>uber/athenadriver</code>).
* Estado: Activo. La campaña continúa evolucionando y expandiéndose. A fecha de octubre de 2026, se han identificado más de 500 cuentas comprometidas y decenas de miles de repositorios afectados.

----

== Actor de Amenaza (Atribución) ==

* Nombre del Actor: No atribuido a un grupo específico. La campaña se rastrea como GhostAction.
* Tipo de Actor: Ciberdelincuente organizado, especializado en ataques a la cadena de suministro de software y robo de credenciales.
* Sofisticación: Alta. El actor demuestra:
** Capacidad de comprometer cuentas de mantenedores de alto perfil (ej. <code>kitao</code>, <code>henrywoo</code>, <code>xxyangyoulin</code>).
** Automatización masiva: 346 repositorios comprometidos en dos ventanas de minutos.
** Uso de técnicas de reconocimiento para identificar secretos específicos en cada repositorio.
** Capacidad de evadir la detección mediante el uso de nombres de flujo de trabajo legítimos y mensajes de commit inocuos.
** Adaptación continua: la campaña ha evolucionado desde 2025, cambiando endpoints de exfiltración y expandiendo los objetivos a credenciales de nube e IA.
** Posible experimentación con mineros de criptomonedas (XMRig) en algunos repositorios comprometidos.

----

== Resumen Ejecutivo ==
GhostAction es una campaña de ataque a la cadena de suministro que compromete cuentas de mantenedores de GitHub para inyectar flujos de trabajo maliciosos en repositorios. Estos flujos de trabajo, disfrazados como "auditorías de seguridad", se ejecutan automáticamente en cada <code>push</code> y exfiltran datos confidenciales a un servidor controlado por el atacante.

La campaña fue identificada por primera vez en septiembre de 2025 por GitGuardian, afectando a 817 repositorios de 327 usuarios y exfiltrado 3,325 secretos, incluidos tokens de PyPI, npm y DockerHub. Desde entonces, la campaña ha continuado con múltiples oleadas, expandiéndose significativamente en 2026.

La ola más reciente, detectada el 8 de octubre de 2026, involucró dos cuentas de mantenedores comprometidas:

* Takashi Kitao (autor del motor de juegos <code>pyxel</code>, con 18,400 estrellas): 27 repositorios comprometidos entre las 13:20 y 13:44 UTC.
* Henry Wu (<code>henrywoo</code>, autor original de <code>athenadriver</code> de Uber): 318 repositorios comprometidos en una ventana de 16 minutos (21:10–21:26 UTC), incluyendo <code>uber/athenadriver</code>.

Según Socket, a fecha de 9 de octubre de 2026, se han identificado más de 500 cuentas de GitHub que han implementado el flujo de trabajo malicioso en decenas de miles de repositorios desde el 7 de octubre de 2026.

El flujo de trabajo malicioso se activa en <code>workflow_dispatch</code> y en un <code>push</code> sin filtrar (cualquier rama, cualquier etiqueta), se extrae con <code>fetch-depth: 0</code> y ejecuta un único paso de "Auditoría" que realiza cuatro acciones:

# Agrega los secretos con nombre del repositorio encontrados durante el reconocimiento.
# Analiza el árbol de trabajo en busca de 13 patrones de credenciales asociados con claves de AWS, servicios de IA, servicios de control de versiones y claves de API de SaaS y nube.
# Revisa todo el historial de Git para encontrar los mismos 13 patrones y obtener credenciales que podrían haber sido confirmadas inadvertidamente en el repositorio y posteriormente eliminadas.
# Empareja los ID de claves de acceso de AWS con sus claves de acceso secretas correspondientes.

Los datos capturados se envían a una dirección IP codificada (<code>193.32.204[.]199</code>) a través de HTTP simple. La campaña también ha utilizado endpoints como <code>bold-dhawan.45-139-104-115.plesk.page</code>, <code>carte-avantage.com</code>, <code>170.39.218.2</code> y <code>*.oast.fun</code> (Interactsh).

En al menos un caso detectado el 30 de agosto de 2026, los ciberdelincuentes modificaron el repositorio <code>kuafuai/DevOpsGPT</code> para insertar un minero de criptomonedas XMRig en la imagen Docker del proyecto.

La campaña nunca se detuvo realmente. Los datos de GitGuardian muestran que los flujos de trabajo inyectados en oleadas anteriores nunca fueron eliminados en muchos casos; el atacante simplemente los modificó para apuntar a nuevos endpoints. La limpieza es incompleta: solo 124 repositorios (16%) fueron limpiados efectivamente en el historial público observado hasta el 5 de octubre de 2026.
----

== Vectores de Ataque / Métodos de Distribución ==

# Compromiso de cuenta de mantenedor: El atacante obtiene credenciales de GitHub de un mantenedor, muy probablemente un token de acceso personal (PAT) filtrado a partir de registros de robo de información (infostealer logs) o volcados de credenciales que circulan entre múltiples actores.
# Reconocimiento: Los archivos de flujo de trabajo del repositorio se analizan en busca de referencias a <code>$<nowiki>{{ secrets.NAME }}</nowiki></code>. Los nombres exactos de los secretos encontrados se plantillan en el payload antes de ser commiteado.
# Inyección: Se inyecta un flujo de trabajo que simula ser una auditoría de seguridad en la rama principal, utilizando la identidad de la víctima. El commit se realiza directamente a la rama por defecto, sin PR ni revisión.
# Ejecución automática: El flujo de trabajo se activa en <code>workflow_dispatch</code> y en un <code>push</code> sin filtrar (cualquier rama, cualquier etiqueta). Se extrae con <code>fetch-depth: 0</code> para obtener todas las ramas y etiquetas.
# Exfiltración: El flujo de trabajo ejecuta un paso de "Auditoría" que:
#* Agrega los secretos con nombre del repositorio.
#* Analiza el árbol de trabajo en busca de 13 patrones de credenciales.
#* Revisa todo el historial de Git (<code>git log -p --all</code>) para encontrar los mismos 13 patrones.
#* Empareja los ID de claves de acceso de AWS con sus claves secretas mediante la captura de contexto (±2 líneas).
#* Envía todos los datos a un endpoint controlado por el atacante mediante <code>curl</code> sobre HTTP simple.
# Expansión: Las credenciales robadas pueden utilizarse para comprometer más repositorios y cuentas, expandiendo la campaña.
# Monetización: Las credenciales robadas (claves de AWS, tokens de PyPI/npm/DockerHub, claves de API de IA, etc.) pueden venderse o utilizarse para publicar paquetes maliciosos, minar criptomonedas o acceder a infraestructura en la nube.

----

== Técnicas, Tácticas y Procedimientos (TTPs) - MITRE ATT&CK ==
{| class="wikitable"
!Táctica (MITRE ATT&CK)
!Técnica / Subtécnica
!Descripción / Implementación
|-
|Initial Access (TA0001)
|Valid Accounts: Cloud Accounts (T1078.004)
|Uso de credenciales de GitHub comprometidas (PAT filtrado).
|-
|Initial Access (TA0001)
|Supply Chain Compromise: Software Supply Chain (T1195.002)
|Inyección de flujo de trabajo malicioso en repositorios de GitHub.
|-
|Execution (TA0002)
|Command and Scripting Interpreter: Unix Shell (T1059.004)
|Ejecución de comandos shell en el runner de GitHub Actions.
|-
|Persistence (TA0003)
|Account Manipulation (T1098)
|Modificación de flujos de trabajo existentes para mantener la persistencia.
|-
|Defense Evasion (TA0005)
|Masquerading: Match Legitimate Name or Location (T1036.005)
|Uso de nombres de flujo de trabajo legítimos ("Security Audit", "Github Actions Security").
|-
|Defense Evasion (TA0005)
|Obfuscated Files or Information (T1027)
|Uso de nombres de secretos plantillados y mensajes de commit inocuos.
|-
|Credential Access (TA0006)
|Credentials from Password Stores (T1555)
|Robo de secretos de GitHub Actions y credenciales de nube/IA/SaaS.
|-
|Credential Access (TA0006)
|Unsecured Credentials: Credentials In Files (T1552.001)
|Búsqueda de credenciales en el árbol de trabajo y el historial de Git.
|-
|Discovery (TA0007)
|Software Discovery (T1518)
|Reconocimiento de secretos referenciados en flujos de trabajo existentes.
|-
|Collection (TA0009)
|Data from Information Repositories (T1213)
|Recopilación de secretos y credenciales de repositorios de GitHub.
|-
|Exfiltration (TA0010)
|Exfiltration Over C2 Channel (T1041)
|Exfiltración de datos a través de HTTP simple a una IP codificada.
|-
|Impact (TA0040)
|Resource Hijacking (T1496)
|Inserción de mineros de criptomonedas (XMRig) en algunos repositorios.
|}
----

== Flujo de Ataque (Cyber Kill Chain - GhostAction) ==

# Reconocimiento: El atacante identifica repositorios de GitHub con secretos referenciados en sus flujos de trabajo. Escanea los archivos de flujo de trabajo en busca de <code>$<nowiki>{{ secrets.NAME }}</nowiki></code>.
# Armamento: El atacante genera un flujo de trabajo malicioso plantillado con los nombres exactos de los secretos encontrados. El payload incluye lógica para:
#* Exfiltrar secretos con nombre.
#* Buscar 13 patrones de credenciales en el árbol de trabajo y el historial de Git.
#* Emparejar claves de AWS con sus secretos.
# Entrega: El atacante compromete una cuenta de mantenedor (mediante PAT filtrado) y commitea el flujo de trabajo malicioso directamente a la rama por defecto del repositorio, utilizando la identidad de la víctima.
# Explotación: El flujo de trabajo se ejecuta automáticamente en el próximo <code>push</code> (incluyendo el propio commit de inyección) o mediante <code>workflow_dispatch</code>.
# Instalación: El flujo de trabajo malicioso queda instalado en el repositorio y se ejecuta en cada <code>push</code> a cualquier rama o etiqueta.
# Comando y Control (C2): El flujo de trabajo envía los datos exfiltrados a un endpoint controlado por el atacante (<code>193.32.204[.]199</code>, puertos 80 y 3000) mediante <code>curl</code> sobre HTTP simple. No se realiza consulta DNS, lo que evita defensas basadas en dominios.
# Acción sobre Objetivos:
#* Robo de secretos de GitHub Actions: Tokens de PyPI, npm, DockerHub, claves de AWS, claves de API de IA, etc.
#* Barrido del historial de Git: Credenciales que fueron commiteadas y posteriormente eliminadas.
#* Emparejamiento de claves AWS: Captura de contexto alrededor de los ID de claves de acceso para reconstruir pares de claves completos.
#* Telemetría de campaña: Los marcadores <code>?c=monami</code> y <code>?c=new</code> permiten al operador clasificar los datos por rendimiento.
#* Minería de criptomonedas: En al menos un caso (<code>kuafuai/DevOpsGPT</code>), se insertó un minero XMRig en la imagen Docker.

----

== Infraestructura Utilizada ==
{| class="wikitable"
!Tipo
!Indicador / Característica
!Propósito
|-
|Endpoint C2 (2026)
|<code>193.32.204[.]199</code> (puertos 80, 3000)
|Exfiltración de datos.
|-
|Endpoint C2 (2025)
|<code>bold-dhawan.45-139-104-115.plesk.page</code>, <code>carte-avantage.com</code>, <code>objective-hopper.45-139-104-115.plesk.page</code>
|Exfiltración de datos (oleada 2025).
|-
|Endpoint C2 (2025-2026)
|<code>170.39.218.2</code>
|Exfiltración de datos (oleadas intermedias).
|-
|Endpoint C2 (2025-2026)
|<code>*.oast.fun</code> (Interactsh)
|Exfiltración de datos (oleadas intermedias).
|-
|Marcadores de URL
|<code>/?c=monami</code>, <code>/?c=new</code>, <code>?inj=<id></code>
|Telemetría de campaña.
|-
|Marcadores de cuerpo POST
|<code>REPO=</code>, <code>AKIA_CTX_START</code>, <code>AKIA_CTX_END</code>
|Identificadores únicos del payload.
|-
|Nombres de flujo de trabajo
|<code>security-audit.yml</code>, <code>github_actions_security.yml</code>, <code>security-check.yml</code>
|Disfraz de auditoría de seguridad.
|-
|Nombres de trabajo/paso
|"Security Audit" / job <code>audit</code>; "Github Actions Security" / job <code>send-secrets</code>; paso "Prepare Cache Busting"
|Capa de disfraz.
|-
|Mensajes de commit
|"Add security audit workflow", "Update security audit workflow", "Add/Update Github Actions Security workflow", "Add security check workflow", "Trigger security scan"
|Firmas de commits inyectados y re-disparados.
|-
|Cuentas comprometidas
|<code>henrywoo</code>, <code>kitao</code>, <code>xxyangyoulin</code>, <code>Grommash9</code>
|Cuentas víctimas utilizadas para la inyección.
|-
|Minero de criptomonedas
|XMRig 6.21.0 (en <code>kuafuai/DevOpsGPT</code>)
|Minería de Monero.
|-
|Pool de minería
|<code>pool.supportxmr.com:3333</code>
|Pool de minería.
|-
|Monedero Monero
|<code>832eKef1fNRTQdiJeJzsvkMMsogMp22FR2FLX1oaV5BxGfoMcJvkcbFgWgNRyNfsE19D9pdM1zdU7D9kRLdJbM5rU1vjfcL</code>
|Monedero del atacante.
|}
----

== Objetivos y Sectores Afectados ==

* Objetivo Principal: Repositorios de GitHub, especialmente aquellos con secretos de CI/CD configurados y credenciales commiteadas en el código o el historial de Git.
* Sectores Afectados: General. Cualquier organización o desarrollador individual que utilice GitHub Actions y tenga secretos configurados.
* Repositorios Notables Afectados:
** <code>uber/athenadriver</code> (Uber)
** <code>kitao/pyxel</code> (18,420 estrellas)
** <code>henrywoo/pyllama</code> (2,777 estrellas)
** <code>henrywoo/chatllama</code> (1,200 estrellas)
** <code>kuafuai/DevOpsGPT</code> (~6,000 estrellas)
** <code>howie6879/liuli</code>
** <code>monkeyx-net/PortMaster-Build-Templates</code>
** <code>RSOLV-dev/rsolv-action</code>
** <code>typecho-fans/plugins</code>
* Plataformas Afectadas: GitHub (repositorios públicos y privados, forks).
* Número de Repositorios Afectados: Decenas de miles (más de 500 cuentas comprometidas desde octubre de 2026).
* Número de Secretos Objetivo: 2,577 secretos en la oleada de agosto-septiembre de 2026; 3,325 secretos en la oleada de septiembre de 2025.
* Distribución Geográfica: Global.

----

== Impacto y Riesgo ==

* Nivel de Riesgo: Crítico para organizaciones que utilizan GitHub Actions y tienen secretos configurados o credenciales commiteadas en el historial de Git.
* Impacto Potencial:
** Robo de Credenciales de CI/CD: Tokens de PyPI, npm, DockerHub, GHCR, claves de AWS, credenciales de Azure, Google Cloud, Firebase, etc.
** Publicación de Paquetes Maliciosos: Las credenciales de publicación robadas (PyPI, npm, crates.io) podrían utilizarse para publicar versiones maliciosas de paquetes legítimos, afectando a miles de usuarios downstream.
** Acceso a Infraestructura en la Nube: Las claves de AWS, Azure y GCP robadas podrían otorgar acceso a recursos en la nube, datos confidenciales y capacidad de escalada de privilegios.
** Acceso a Servicios de IA: Las claves de API de Anthropic, OpenAI y OpenRouter robadas podrían utilizarse para reventa de inferencia, generación de spam, desinformación o acceso a datos confidenciales.
** Compromiso de Comunicaciones: Los tokens de Slack, Discord y Telegram robados podrían otorgar acceso a comunicaciones internas.
** Minería de Criptomonedas: Inserción de mineros XMRig en imágenes Docker, consumiendo recursos computacionales y aumentando costos.
** Expansión de la Cadena de Suministro: Las credenciales robadas pueden utilizarse para comprometer más repositorios y cuentas, expandiendo la campaña.
** Riesgo Legal y Reputacional: La publicación de paquetes maliciosos o el compromiso de datos de clientes puede tener consecuencias legales y reputacionales graves.

----

== Recomendaciones de Mitigación ==

=== Acciones Inmediatas si un Flujo de Trabajo Afectado Apareció en su Repositorio ===

# Rotar todo lo que el barrido del historial pudo alcanzar:
#* Todos los secretos de Actions.
#* Cada credencial jamás commiteada a cualquier rama: claves de AWS, claves de proveedores de IA, tokens de GitHub/GitLab, Slack, SendGrid, Google/Firebase.
#* La eliminación del árbol actual es irrelevante; <code>git log -p --all</code> vio el historial.
# Encontrar y revocar la credencial de GitHub comprometida:
#* El PAT o la sesión que permitió la inyección.
#* Rotar los secretos del repositorio es insuficiente mientras la ruta de inyección permanezca abierta.
# Eliminar el flujo de trabajo malicioso de todas las ramas:
#* No solo de la rama por defecto; se activa en <code>push</code> a cualquier rama y barre todas las referencias.
# Auditar las ejecuciones de flujos de trabajo desde el 31 de agosto de 2026:
#* Buscar los indicadores mencionados.
#* Tratar cualquier ejecución completada de "Security Audit" / "Github Actions Security" como una exfiltración confirmada: el guard siempre es verdadero y cada ejecución hace beacon.
# No publicar releases hasta limpiar:
#* Si los secretos de publicación (PyPI, npm, crates.io, registros de contenedores) estaban configurados, asumir que el atacante puede publicar como usted.
# Revisar los forks:
#* Los forks de repositorios infectados llevan el flujo de trabajo; habilitar Actions en ellos lo ejecuta contra el contexto de su cuenta.

=== Acciones Generales ===

# Habilitar el escaneo de secretos de GitHub con protección de push.
# Requerir aprobación para ejecuciones de flujos de trabajo de colaboradores externos.
# Revisar los registros de auditoría de la organización para la ventana de push y buscar adiciones de archivos de flujo de trabajo en todos los repositorios a los que la cuenta podía escribir.
# Buscar conexiones a <code>193.32.204[.]199</code> en registros de egreso, incluyendo desde rangos de runners auto-alojados, y bloquearla.
# Implementar políticas de flujo de trabajo y repositorio que restrinjan la ejecución de flujos de trabajo no aprobados.
# Monitorear los registros de Transparencia de Certificados (CT) para detectar emisiones inesperadas.
# Publicar registros CAA restrictivos para limitar la emisión de certificados a CAs autorizadas.
# Considerar el uso de herramientas como StepSecurity Harden-Runner para visibilidad de red y procesos durante ejecuciones de CI/CD, y para bloquear conexiones a destinos maliciosos.

----

== Herramientas de Detección ==

* Búsqueda de código en GitHub:
** <code>"AKIA_CTX_START" path:.github/workflows</code>
** <code>"c=monami"</code>
** <code>"193.32.204.199" path:.github/workflows</code>
** <code>org:your-org "AKIA_CTX_START"</code>
** <code>org:your-org "c=monami"</code>
** <code>org:your-org "193.32.204.199"</code>
* Patrones de registro de auditoría:
** Commits de identidades de mantenedores añadiendo los archivos de flujo de trabajo directamente a ramas por defecto, omitiendo pull requests.
** Eventos <code>workflow_dispatch</code> en flujos de trabajo de "auditoría" recién creados.
** Commits rápidos no firmados en muchos repositorios en minutos.
* Análisis de tráfico de red:
** Conexiones a <code>193.32.204[.]199</code> (puertos 80, 3000).
** Conexiones a <code>45.139.104.115</code>, <code>170.39.218.2</code>, <code>*.oast.fun</code>.
* Monitoreo de procesos:
** Detección de mineros XMRig en ejecución.
** Conexiones a <code>pool.supportxmr.com:3333</code>.
* StepSecurity Harden-Runner:
** Visibilidad de red y procesos durante ejecuciones de CI/CD.
** Bloqueo de conexiones a la lista de bloqueo global de StepSecurity.
** Política de <code>allowed-endpoints</code> para bloquear cualquier destino fuera de la lista de permitidos.

----

== Indicadores de Compromiso (IOCs) ==

=== Direcciones IP C2 ===
{| class="wikitable"
!IP
!Puertos
!Período
!Significado
|-
|<code>193.32.204[.]199</code>
|80, 3000
|Desde sept. 2026
|Endpoint de exfiltración actual.
|-
|<code>45.139.104.115</code>
| -
|Sept. 2025
|Endpoint de exfiltración anterior.
|-
|<code>170.39.218.2</code>
| -
|Oct.–Dic. 2025, Mar. 2026
|Endpoint de exfiltración anterior.
|-
|<code>*.oast.fun</code>
| -
|Nov. 2025, Mar.–Abr. 2026
|Endpoint de exfiltración anterior (Interactsh).
|}

=== Marcadores de URL y Cuerpo POST ===
{| class="wikitable"
!Tipo
!Valor
!Significado
|-
|Marcador de URL
|<code>/?c=monami</code>
|El repositorio tenía secretos con nombre.
|-
|Marcador de URL
|<code>/?c=new</code>
|Solo barrido de historial.
|-
|Marcador de URL
|<code>?inj=<id></code>
|Identificador único de inyección.
|-
|Marcador de cuerpo
|<code>REPO=</code>
|Identificador del repositorio.
|-
|Marcador de cuerpo
|<code>AKIA_CTX_START</code>
|Inicio del contexto de clave AWS.
|-
|Marcador de cuerpo
|<code>AKIA_CTX_END</code>
|Fin del contexto de clave AWS.
|}

=== Archivos de Flujo de Trabajo Maliciosos ===

* <code>.github/workflows/security-audit.yml</code>
* <code>.github/workflows/github_actions_security.yml</code>
* <code>.github/workflows/security-check.yml</code>

=== Nombres de Flujo de Trabajo / Trabajo / Paso ===

* "Security Audit" / job <code>audit</code>
* "Github Actions Security" / job <code>send-secrets</code>
* Paso "Prepare Cache Busting"

=== Mensajes de Commit ===

* "Add security audit workflow"
* "Update security audit workflow"
* "Add Github Actions Security workflow"
* "Update Github Actions Security workflow"
* "Add security check workflow"
* "Trigger security scan"

=== Cuentas Comprometidas ===

* <code>henrywoo</code> (Henry Wu)
* <code>kitao</code> (Takashi Kitao)
* <code>xxyangyoulin</code>
* <code>Grommash9</code> (ya no accesible)

=== Otros IOCs ===
{| class="wikitable"
!Tipo
!Valor
|-
|Minero
|XMRig 6.21.0
|-
|Pool de minería
|<code>pool.supportxmr.com:3333</code>
|-
|Monedero Monero
|<code>832eKef1fNRTQdiJeJzsvkMMsogMp22FR2FLX1oaV5BxGfoMcJvkcbFgWgNRyNfsE19D9pdM1zdU7D9kRLdJbM5rU1vjfcL</code>
|-
|Repositorio con minero
|<code>kuafuai/DevOpsGPT</code>
|-
|Commit del minero
|<code>fix(subtask) 修改OpenAI版本</code> (30 de agosto de 2026, 00:30 UTC)
|}
----

== Referencias y Fuentes ==

* Lakshmanan, R. (2026, 9 de octubre). ''Flujos de trabajo de GitHub Actions para robar credenciales se han infiltrado en decenas de miles de repositorios''. The Hacker News.
* Prabhu, R. (2026, 9 de octubre). ''GhostAction Returns: Malicious "Security Audit" Workflows Now Mine Credentials from Entire Git Histories''. StepSecurity.
* Socket Research Team. (2026, 9 de octubre). ''New GhostAction Wave Hits Hundreds of Repos, Expanding Beyond CI/CD Secrets to Cloud Credentials''. Socket.
* Ferry, G., & Valadon, G. (2026, 7 de octubre). ''The campaign that never stopped: tracking GhostAction from 2025 to 2026''. GitGuardian.
* Lakshmanan, R. (2025, 8 de septiembre). ''⚡ Weekly Recap: Drift Breach Chaos, Zero-Days Active, Patch Warnings, Smarter Threats & More''. The Hacker News.
* MITRE ATT&CK Framework. Enterprise Matrix. (Para mapeo de TTPs).

----

== Historial de Revisiones ==
{| class="wikitable"
!Fecha
!Versión
!Autor
!Cambios Realizados
|-
|2026-10-12
|1.0
|Fernando Vargas Hincapié
|Creación inicial de la entrada basada en los informes de The Hacker News, StepSecurity, Socket y GitGuardian sobre la campaña GhostAction.
|}
----

== Etiquetas / Categorías ==
<code>ghostaction</code> <code>github-actions</code> <code>supply-chain-attack</code> <code>cadena-de-suministro</code> <code>robo-de-credenciales</code> <code>credential-theft</code> <code>ci-cd</code> <code>secretos</code> <code>github</code> <code>pat</code> <code>token-de-acceso-personal</code> <code>aws</code> <code>azure</code> <code>google-cloud</code> <code>firebase</code> <code>openai</code> <code>anthropic</code> <code>openrouter</code> <code>slack</code> <code>discord</code> <code>telegram</code> <code>sendgrid</code> <code>pypi</code> <code>npm</code> <code>dockerhub</code> <code>ghcr</code> <code>crates-io</code> <code>xmrig</code> <code>criptomineria</code> <code>monero</code> <code>kuafuai</code> <code>devopsgpt</code> <code>pyxel</code> <code>athenadriver</code> <code>uber</code> <code>henrywoo</code> <code>kitao</code> <code>xxyangyoulin</code> <code>security-audit</code> <code>github-actions-security</code> <code>security-check</code> <code>git-history</code> <code>exfiltracion</code> <code>http-simple</code> <code>193-32-204-199</code> <code>stepsecurity</code> <code>socket</code> <code>gitguardian</code> <code>octubre-2026</code>