Sality, interrumpida tras 23 años la botnet P2P utilizada para robar criptomonedas

Una operación internacional aísla la red criminal

Una operación internacional ha interrumpido la infraestructura de Sality, una botnet peer-to-peer observada por primera vez en 2003 y que se mantuvo operativa durante 23 años. Con el tiempo, la red distribuyó information stealers, servicios proxy, herramientas para ataques DDoS y otros componentes maliciosos.

En la campaña participaron CrowdStrike, las fuerzas de seguridad de Estados Unidos, Bulgaria, Hungría y Rumanía, y la Shadowserver Foundation. Esta última está colaborando con proveedores de Internet y CSIRT para identificar los sistemas que todavía siguen comprometidos y coordinar las tareas de limpieza.

La intervención combinó dos acciones. CrowdStrike manipuló el protocolo P2P para separar los bots de los nodos controlados por el operador, mientras que las autoridades retiraron o desactivaron las URL que alojaban los payloads distribuidos por la red.

Según CrowdStrike, el responsable de Sality ya no podría comunicarse con las máquinas infectadas. Los sistemas que todavía están comprometidos estarían enviando ahora su tráfico periódico a sinkholes controlados por la empresa.

Por tanto, la botnet ha sido neutralizada desde el punto de vista operativo, pero no ha sido eliminada automáticamente de los endpoints. El malware aún puede estar presente en los dispositivos.

Por qué Sality resistió durante tanto tiempo

La longevidad de Sality dependía sobre todo de su arquitectura distribuida. En lugar de recurrir a un único servidor de mando y control, la botnet utilizaba una red P2P a través de la cual los nodos recibían actualizaciones, instrucciones y código nuevo.

La ausencia de una infraestructura central dificultaba una operación tradicional de incautación. Desactivar un único servidor no habría sido suficiente: los dispositivos infectados podrían haber seguido comunicándose a través de otros peers.

La columna vertebral de la red estaba formada por máquinas comprometidas que desempeñaban el papel de super peers. Cada bot mantenía una lista de estos nodos y comprobaba periódicamente si seguían siendo accesibles.

El protocolo utilizaba un sistema operativo de reputación. Un super peer que continuaba respondiendo ganaba fiabilidad, mientras que un nodo inaccesible perdía reputación progresivamente hasta ser eliminado de la lista. De este modo, Sality podía actualizar automáticamente su topología y conservar rutas de comunicación operativas.

La propagación también contribuía a su persistencia. Sality actuaba como file infector, insertando su código en los ejecutables almacenados en discos y soportes extraíbles. Por tanto, un archivo modificado y transferido a otro equipo podía extender la infección más allá del sistema original.

Esta característica también complica la limpieza. No basta con detener el proceso malicioso o eliminar un único archivo: es necesario localizar los ejecutables modificados y comprobar los soportes que podrían haber transportado el malware.

El punto débil oculto en el protocolo P2P

La misma arquitectura que protegió a Sality durante más de dos décadas contenía una debilidad estructural. El protocolo confiaba en los peers sin aplicar mecanismos de autenticación ni controles fiables sobre su identidad.

CrowdStrike aprovechó esta confianza para intervenir directamente en las listas utilizadas por los bots. La operación eliminó progresivamente las referencias a los super peers de la infraestructura criminal y las sustituyó por nodos destinados al sinkholing.

Un sinkhole es un sistema controlado por los defensores que recibe el tráfico que antes se dirigía a la infraestructura maliciosa. No desinfecta el equipo, pero impide o limita el contacto con el operador y permite observar las comunicaciones residuales.

En el caso de Sality, la manipulación de las listas aisló gradualmente las máquinas comprometidas. Cuando los bots actualizaron su visión de la red, los nodos controlados por los defensores ocuparon el lugar de los super peers utilizados por el operador.

La intervención sobre las URL completó la operación. Al retirar los recursos desde los que Sality descargaba los payloads, las autoridades impidieron que los dispositivos ya infectados recibieran nuevos componentes a través de esos canales.

No se trata de una vulnerabilidad de software clasificada públicamente. No se ha indicado ningún identificador CVE, ni hay constancia de productos o versiones específicas que deban actualizarse mediante un parche. El defecto aprovechado para interrumpir la botnet estaba relacionado con el modelo de confianza del protocolo P2P utilizado por esta.

EggJagger y el robo mediante el portapapeles

Durante los últimos ocho años, Sality se habría utilizado principalmente para distribuir EggJagger, una herramienta de clipjacking asociada al robo de criptomonedas.

Esta técnica ataca el contenido copiado en el portapapeles del sistema operativo. Durante una transacción, un usuario puede copiar la dirección del monedero del destinatario para pegarla en la aplicación o el sitio web utilizado para realizar la transferencia.

El malware intercepta ese valor y lo sustituye por una dirección controlada por el atacante. Si la víctima no compara cuidadosamente la cadena pegada con la original, la transacción se autoriza hacia el monedero equivocado.

Una vez confirmada la transferencia en la blockchain, recuperar los fondos puede resultar extremadamente difícil. EggJagger habría sustraído al menos 150.000 dólares en Bitcoin y Ethereum. Se trata de una estimación mínima que podría no reflejar todos los beneficios obtenidos mediante la campaña.

Sin embargo, el impacto de Sality no se limita a las criptomonedas. La botnet respaldó actividades de espionaje de información, distribución de proxies abusivos y ataques DDoS, ofreciendo al operador una plataforma adaptable a distintos objetivos delictivos.

Interrumpir la botnet no significa eliminar el malware

El aislamiento de la red reduce la capacidad del operador para impartir órdenes y distribuir nuevos payloads. Sin embargo, no elimina Sality de los ordenadores ya comprometidos ni restaura los ejecutables modificados por el file infector.

Por ello, las organizaciones deberían revisar los endpoints potencialmente expuestos, prestando especial atención a los sistemas más antiguos, los archivos ejecutables transferidos entre dispositivos y los soportes extraíbles utilizados en varios equipos. Estos últimos pueden conservar copias infectadas y reintroducir el malware después de una limpieza incompleta.

También conviene comprobar si existen anomalías en las aplicaciones destinadas a gestionar criptomonedas. Las direcciones de los monederos deben compararse antes de autorizar cada transacción, especialmente cuando se hayan introducido mediante copiar y pegar.

No se han publicado nombres de archivos, hashes, dominios, direcciones IP ni otras cadenas que puedan utilizarse directamente como indicadores de compromiso. Tampoco se conocen firmas operativas o procedimientos universales para eliminar la infección.

Cuando los datos de los sinkholes estén disponibles para los defensores, el tráfico dirigido a estos sistemas podrá ayudar a identificar endpoints que todavía estén activos. La comunicación con un sinkhole constituye una posible señal de infección residual, no una prueba de que el equipo ya haya sido limpiado.

La limpieza requiere la colaboración de ISP, CSIRT y proveedores de seguridad

La Shadowserver Foundation está colaborando con ISP y CSIRT para asociar las conexiones observadas con los sistemas afectados y avisar a usuarios y organizaciones. Quien reciba una notificación debería tratarla como un indicio concreto de compromiso e iniciar un análisis del endpoint.

Ante la ausencia de herramientas y firmas de eliminación publicadas, la remediación debe coordinarse con el proveedor correspondiente, el CSIRT competente o un proveedor de seguridad. El análisis debería incluir los ejecutables, los soportes extraíbles y los demás dispositivos que hayan intercambiado archivos con la máquina infectada.

Puede ser necesario sustituir los archivos modificados por copias íntegras o restaurar completamente el sistema. La decisión dependerá del alcance de la infección, que un file infector puede hacer difícil de delimitar con certeza.

La operación ha arrebatado al autor de Sality el control de la red y ha bloqueado los canales conocidos para distribuir payloads. La siguiente fase es menos visible, pero decisiva: localizar las máquinas que todavía están infectadas y eliminar el código que ha permanecido operativo tras 23 años de propagación.