Una operación internacional interrumpió el 31 de agosto de 2026 la infraestructura de Sality, una botnet activa desde 2003. CrowdStrike aisló más de 15.000 equipos infectados de los canales del operador mediante una operación de sinkhole entre pares, mientras autoridades de Estados Unidos, Bulgaria, Hungría y Rumania actuaron contra dominios vinculados con la red.
El resultado es relevante, pero no equivale a desinfectar las organizaciones afectadas. La manipulación de las listas P2P impide que los bots reciban nuevas instrucciones y cargas del operador; el malware que ya reside en los endpoints permanece activo hasta que cada propietario lo detecte y lo elimine. Esa diferencia convierte una victoria contra infraestructura criminal en una tarea inmediata para empresas, proveedores de Internet y equipos nacionales de respuesta.
El Departamento de Justicia de Estados Unidos anunció la acción el 1 de septiembre junto con FBI, DCIS, CrowdStrike y Shadowserver, con apoyo de Europol, Eurojust y las autoridades europeas participantes. Shadowserver trabaja con proveedores y CSIRT para identificar infecciones, notificar a las víctimas y facilitar la remediación. No se publicó una lista de organizaciones afectadas ni evidencia de una campaña dirigida específicamente a España o Colombia.
Qué logró la operación contra Sality
CrowdStrike ejecutó una toma de control lógica de las redes P2P v3 y v4. Esas redes compartían base de código y operador, pero usaban protocolos y claves diferentes. En vez de depender de un servidor central, los equipos infectados mantenían listas de pares alcanzables y distribuían entre sí instrucciones para descargar o transferir cargas maliciosas.
La operación debilitó primero a los superpares que sostenían esa comunicación. Mediante manipulación del protocolo invalidó entradas legítimas e insertó direcciones de sinkhole controladas por los defensores. Cuando los bots detrás de firewalls o NAT realizan su mantenimiento periódico, reciben listas modificadas, pierden contacto con la red del operador y comienzan a comunicarse con la infraestructura defensiva.
En paralelo, autoridades y socios retiraron dominios y URL que alojaban cargas activas. El Departamento de Justicia, FBI y DCIS incautaron dominios en Estados Unidos; Bulgaria, Hungría y Rumania actuaron sobre otros alojados en Europa. El operador perdió así el canal para enviar tareas nuevas y los bots dejaron de descargar los archivos que aún indicaban sus paquetes de URL.
Interrumpir la botnet no limpia el endpoint
| La operación sí hace | La operación no hace | Acción de la organización |
|---|---|---|
| Aísla los pares del control criminal. | No elimina Sality de archivos y memoria. | Detectar, adquirir evidencia y erradicar en cada equipo. |
| Bloquea nuevas instrucciones y cargas conocidas. | No revoca credenciales robadas antes de la acción. | Revisar abuso y rotar secretos por alcance. |
| Convierte el tráfico al sinkhole en señal de infección. | No identifica automáticamente todos los sistemas relacionados. | Correlacionar red, endpoint, shares y medios removibles. |
| Facilita notificación mediante Shadowserver y CSIRT. | No sustituye el análisis del impacto empresarial. | Determinar datos, cuentas y movimientos laterales afectados. |
Confundir esos dos niveles crea una falsa sensación de cierre. Un endpoint puede dejar de recibir órdenes y seguir conteniendo ejecutables infectados, mecanismos de persistencia o cargas instaladas previamente. También puede conservar credenciales capturadas, configuraciones alteradas y rutas hacia carpetas compartidas que vuelvan a propagar archivos cuando otro equipo los ejecute.
La frase operativa correcta es “canal criminal interrumpido, infección pendiente de remediación”. Dirección debería pedir dos evidencias distintas: que la infraestructura externa ya no controla la máquina y que la organización eliminó el malware, comprobó su alcance y cerró el mecanismo de propagación.
Por qué Sality sobrevivió más de dos décadas
Sality apareció por primera vez en 2003 como malware que infecta archivos. Su evolución hacia una arquitectura P2P eliminó el punto único de fallo: cada equipo comprometido podía aprender de otros pares y transportar instrucciones. Derribar un dominio o servidor no bastaba, porque la red continuaba reorganizándose sin una autoridad central visible.
El segundo factor fue su comportamiento polimórfico. Sality se adjunta a ejecutables y modifica su representación para dificultar firmas simples. Se propagó mediante shares de red, unidades removibles y archivos intercambiados. Esa mecánica permite que una infección reaparezca desde un binario olvidado, una carpeta de software heredado o un dispositivo que vuelve a conectarse después de la limpieza inicial.
La longevidad también expone una debilidad empresarial: activos antiguos que funcionan, pero dejaron de recibir inventario, telemetría o mantenimiento. Equipos de laboratorio, cajas, estaciones de producción, quioscos y PC de proveedores pueden mantenerse años fuera del ciclo de renovación. Un Análisis de Vulnerabilidades debe incluir software obsoleto, rutas de propagación y controles compensatorios, no limitarse a enumerar CVE recientes.
Una plataforma para cargas, fraude y DDoS
La capacidad base de Sality era desplegar otros componentes. A lo largo de su historia distribuyó malware para robo de credenciales, spam, proxies, explotación de red y ataques distribuidos de denegación de servicio. Eso convierte cada bot en una puerta reutilizable: el efecto depende de la carga que el operador decida entregar en una etapa concreta.
Durante los últimos ocho años, la carga principal fue EggJagger, una herramienta de clipjacking. Monitorea el portapapeles y sustituye direcciones de billeteras de criptomonedas por otras controladas por el operador. La víctima copia una dirección legítima, pero puede pegar una diferente en la transacción. CrowdStrike estima al menos 12,1 millones de rublos, aproximadamente 150.000 dólares, robados mediante esa técnica; el cálculo no incluye otros ingresos de la botnet.
La investigación también describe campañas ocasionales de DDoS. Por tanto, una infección no puede clasificarse solo como “minería” o “fraude de criptomonedas”. La organización debe determinar qué cargas estuvieron presentes, qué cuentas se usaron y qué conexiones ocurrieron durante su propia ventana. La historia pública de la familia orienta la búsqueda, pero no reemplaza la evidencia local.
La nueva señal de detección más directa
CrowdStrike publicó una dirección “faro” para la operación: tráfico UDP con destino a 188.166.101[.]148 indica una infección de Sality que requiere remediación. Los equipos deben buscarla en DNS cuando corresponda, firewalls, NetFlow, proxy, EDR y telemetría del endpoint. No se debe intentar visitar la dirección desde un navegador ni añadirla a una lista de allowlist; su valor es retrospectivo y de correlación.
La fuente también ofrece URL desactivadas y reglas YARA para buscar en memoria las claves públicas RSA incrustadas en las variantes v3 y v4. Un match debe activar adquisición y contención, no un borrado automático sin contexto. Antes de reiniciar o eliminar archivos conviene registrar procesos, conexiones, módulos, usuarios, tareas, binarios y hash para comprender qué más ejecutó el equipo.
No observar el faro tampoco demuestra limpieza. La máquina puede estar apagada, desconectada, filtrada o contener un artefacto que todavía no ejecutó su ciclo de comunicación. La búsqueda debe combinar IOC, comportamiento de infección de archivos, telemetría histórica y alcance de shares.
Cómo organizar una cacería sin destruir evidencia
- Buscar el faro. Consultar registros históricos y actuales por tráfico UDP al sinkhole, conservando hora, origen, usuario y segmento.
- Confirmar en el endpoint. Aplicar las reglas YARA publicadas, revisar procesos y examinar ejecutables sin abrirlos en equipos de producción.
- Delimitar propagación. Identificar shares, unidades removibles, paquetes y estaciones que intercambiaron archivos con el sistema confirmado.
- Preservar una muestra. Capturar memoria, triage, archivos y registros suficientes antes de reimagen o limpieza, bajo cadena de custodia proporcional.
- Buscar cargas secundarias. Revisar robo de credenciales, proxy, spam, DDoS, clipjacking y cualquier persistencia instalada.
- Validar la erradicación. Reescanear endpoints y repositorios de software, controlar reconexiones y vigilar que no reaparezca la señal.
Un Análisis Forense Digital permite conservar una imagen explicable del incidente antes de reemplazar los equipos. Esa evidencia es necesaria para decidir si basta con reimagen, si deben revocarse identidades y si otras estaciones recibieron archivos contaminados.
La remediación no termina con una reimagen
Si Sality o una carga secundaria capturó credenciales, el secreto puede seguir en manos del actor aunque el canal P2P haya caído. Después de cerrar persistencia y asegurar dispositivos confiables, deben rotarse contraseñas, tokens, llaves y sesiones expuestas. Hacerlo desde el mismo endpoint infectado puede entregar las nuevas credenciales.
También conviene revisar acciones posteriores: inicios de sesión, reglas de correo, acceso remoto, nuevas cuentas, movimientos de datos y cambios en servicios. La ausencia de ransomware no implica ausencia de impacto. Un proxy instalado puede haber ocultado actividad de terceros; una cuenta robada puede usarse en otro servicio semanas después.
La recuperación exige una referencia limpia. Inventario de software aprobado, fuentes verificadas, repositorios internos controlados y medios removibles limitados reducen la reinfección. Si una aplicación heredada solo existe como ejecutable compartido sin origen ni firma, la organización debe tratarla como un riesgo de cadena de suministro interna.
Qué significa para España y Colombia
La acción tuvo participación europea, pero las fuentes no publican un desglose de infecciones por España o Colombia. Sality es una botnet global y CrowdStrike había documentado históricamente actividad de una de sus variantes en Venezuela. Esa referencia regional no confirma presencia en Colombia; sí justifica que proveedores, CSIRT y organizaciones latinoamericanas consulten su propia telemetría.
En España, las empresas pueden recibir notificaciones de proveedores o equipos de respuesta a partir de los datos del sinkhole. El aviso debe tratarse como evidencia técnica útil, no como spam ni como prueba de que el problema ya fue resuelto externamente. Hay que confirmar el activo, preservar registros y compartir un cierre verificable con quien notificó.
En Colombia, organizaciones con estaciones antiguas, software compartido, plantas, comercios o redes distribuidas deberían priorizar la búsqueda. Un Security GAP Assessment puede identificar dónde faltan inventario, registros, aislamiento o procedimientos de remediación y convertir la alerta puntual en una mejora sostenible.
Cambios que deben permanecer después de la alerta
La primera mejora es controlar la ejecución. Políticas de allowlisting, firmas, reputación y bloqueo de ubicaciones escribibles reducen la capacidad de un archivo infectado para propagarse. Deben probarse con las aplicaciones reales del negocio para evitar excepciones permanentes que anulen el control.
La segunda es segmentar shares y estaciones heredadas. No todos los usuarios necesitan escribir o ejecutar en todas las carpetas. Las unidades removibles requieren reglas, registro y un canal seguro para casos legítimos. La tercera es conservar suficiente telemetría de red y endpoint para responder meses después, porque una amenaza de larga duración rara vez cabe en siete días de logs.
Finalmente, la organización debe ensayar quién recibe una notificación externa, quién adquiere evidencia, quién autoriza la desconexión y quién declara limpio el entorno. Un CISO as a Service puede alinear esas decisiones con continuidad, proveedores y dirección, especialmente cuando no existe un equipo interno dedicado.
Límites y preguntas abiertas
La operación interrumpió el control del operador sobre las redes observadas, pero ninguna intervención garantiza que el responsable no intente reconstruir infraestructura o distribuir otra variante. Reuters informó que el operador no ha sido identificado públicamente. La vigilancia debe continuar, sin presentar la interrupción como eliminación definitiva del actor.
La cifra de más de 15.000 corresponde a máquinas infectadas que podían recibir cargas a través de la botnet según CrowdStrike; no equivale a 15.000 empresas. Un mismo entorno puede contener varios equipos y una organización puede no aparecer en la visibilidad pública. Los cálculos de criptomonedas son estimaciones del proveedor y se limitan a EggJagger.
Convierta la interrupción global en una limpieza comprobable
Insylux puede buscar la señal publicada, delimitar endpoints y shares afectados, preservar evidencia, identificar cargas secundarias y validar que la recuperación no deje credenciales o ejecutables contaminados.
Solicite una cacería prioritaria de Sality con el Equipo Insylux.
Fuentes y alcance
- Departamento de Justicia de Estados Unidos, operación internacional contra Sality, 1 de septiembre de 2026.
- CrowdStrike, detalle técnico del sinkhole, IOC y remediación, 1 de septiembre de 2026.
- Reuters, corroboración y contexto de la operación, 1 de septiembre de 2026.
Fuentes consultadas el 1 de septiembre de 2026. Los detalles técnicos e indicadores proceden de CrowdStrike; la coordinación jurídica, del Departamento de Justicia. Las acciones de remediación y la lectura para España y Colombia son análisis del Equipo Insylux.
