🔒
🚨 Alerta de ransomware activo

¿Qué es el ransomware ".sorry" que cifra servidores cPanel y cómo detectarlo?

Censys detectó 7.135 servidores cPanel con artefactos del ransomware "Sorry" visibles desde Internet. El cifrador escrito en Go explota CVE-2026-41940 para obtener acceso root y cifrar todo el servidor.

🗓 8 Mayo 2026⏱ 9 min lectura🔴 Afectación activa confirmada
7.135
Servidores cPanel con ransomware confirmado — Censys, 4 May 2026
8.859
Equipos con archivos .sorry visibles en directorios abiertos
Go
Lenguaje de programación del cifrador — difícil de detectar por antivirus tradicionales
Tox
Protocolo de mensajería cifrada usado para las instrucciones de rescate

¿Qué es el ransomware "Sorry"?

El ransomware "Sorry" es un cifrador Linux escrito en Go diseñado específicamente para infraestructura de servidor. A diferencia del ransomware tradicional que ataca equipos de escritorio mediante archivos adjuntos o correos de suplantación, "Sorry" fue desarrollado para explotar vulnerabilidades de servidor — y CVE-2026-41940 le proporcionó el vector de entrada perfecto.

Una vez que obtiene acceso root al servidor cPanel mediante el exploit CRLF, el ransomware actúa de forma metódica: cifra todos los archivos del servidor, modifica las extensiones a .sorry, y deja una nota de rescate con instrucciones de contacto a través de Tox, un protocolo de mensajería cifrada que preserva el anonimato del atacante.

Por qué Go es un problema para los equipos de defensa

Los ejecutables compilados en Go son archivos autónomos que incluyen todas sus dependencias. No requieren bibliotecas externas instaladas en el sistema. Son más difíciles de analizar que el código malicioso en lenguajes más comunes, y muchos sistemas de detección tradicionales no cuentan con firmas actualizadas para identificarlos.

Cómo opera el ataque — de CVE-2026-41940 al cifrado del servidor

Fase 1 — Acceso inicial

Exploit CVE-2026-41940

El atacante usa el exploit CRLF para obtener acceso root a WHM sin credenciales. El proceso tarda segundos y puede automatizarse para atacar miles de servidores en paralelo.

Fase 2 — Reconocimiento

Mapeo del servidor

Con acceso root, el programa malicioso recorre todos los directorios, cuentas de alojamiento y archivos del servidor. Identifica los datos más valiosos para maximizar el impacto del cifrado.

Fase 3 — Cifrado masivo

Encriptación y extensión .sorry

El cifrador Go encripta todos los archivos accesibles — incluidas las copias de respaldo si están en el mismo servidor — y agrega la extensión .sorry. Los sitios web quedan completamente inaccesibles.

Fase 4 — Nota de rescate

Instrucciones vía Tox

El ransomware deja archivos de nota de rescate en el servidor con instrucciones para contactar a los atacantes a través de Tox. El monto del rescate varía según el perfil del servidor comprometido.

Campaña paralela

Botnet Mirai — segunda amenaza

Una campaña paralela usa CVE-2026-41940 para instalar variantes de la botnet Mirai (nuclear.x86), crear cuentas de administrador ocultas, desactivar el registro de seguridad, y utilizar el servidor como nodo de ataques de denegación de servicio y minería de criptomonedas.

Cómo detectar si tu servidor fue afectado

Detección de artefactos de ransomware .sorry
# Buscar archivos con extensión .sorry en todo el servidor
find / -name "*.sorry" -type f 2>/dev/null | head -30
# Si este comando devuelve resultados, el servidor fue cifrado

# Buscar notas de rescate típicas
find / -name "README*" -newer /var/cpanel/version 2>/dev/null
find / -name "HOW_TO_DECRYPT*" -newer /var/cpanel/version 2>/dev/null

# Verificar procesos sospechosos en ejecución
ps aux | grep -v "cpanel\|apache\|mysql\|sshd\|root" | head -20

# Comprobar conexiones de red activas a direcciones IP externas inusuales
ss -tulnp | grep ESTAB | awk '{print $5}' | sort | uniq

Si encontraste archivos .sorry — pasos inmediatos

No pagues el rescate antes de agotar las alternativas

El pago del rescate no garantiza la recuperación de los datos. En muchos casos, los atacantes no entregan la clave de descifrado, o entregan una incompleta. El primer paso debe ser siempre verificar si tienes copias de respaldo externas al servidor comprometido.

  • !Desconecta el servidor de la red de inmediato para evitar que el problema se propague a otros sistemas.
  • !Verifica si tienes copias de respaldo externas al servidor comprometido — anteriores al 23 de febrero de 2026.
  • 2Documenta el incidente con capturas del estado del servidor antes de cualquier acción: es necesario para seguros, denuncias y análisis forense.
  • 3Contacta a tu proveedor de alojamiento y, si manejas datos de clientes, a un abogado especializado en protección de datos.
  • 4Si tienes copias de respaldo limpias: aprovisiona un servidor nuevo, aplica el parche CVE-2026-41940, y restaura desde la copia de respaldo.
  • iEn Chile, Perú y otros países de la región, una brecha de datos personales puede generar obligaciones legales de notificación. Consulta con un especialista antes de actuar.