ransomware SafePay: aviso AA26-293A para red team

El 20 de octubre de 2026, la CISA, el FBI, el USSS y socios de Alemania y del Reino Unido publicaron el aviso conjunto AA26-293A sobre el ransomware SafePay. Ransomware SafePay es la operación y la variante descritas en ese aviso de la serie #StopRansomware, con actividad observada desde agosto de 2024 y al menos 600 víctimas en varios sectores de infraestructura crítica.

El texto oficial aporta TTP, indicadores y mitigaciones observados en investigaciones que llegan hasta agosto de 2026. La nota de prensa de la CISA, fechada el 21 de octubre de 2026, refuerza el mismo cuadro y resume acciones prácticas para reducir impacto, inclusive en el eje SafePay VPN phishing CVE que abre la cadena.

Para un equipo de red team al servicio de la defensa, el valor del aviso no está en repetir el ataque contra terceros. Está en traducir la cadena en hipótesis comprobables, solo en entorno propio o con autorización formal por escrito, y en amarrar cada fase a señales de detección y a controles que el blue team pueda medir.

Qué afirma el AA26-293A y quién firma el aviso

El AA26-293A afirma que actores del ransomware SafePay operan con intensidad desde agosto de 2024 contra empresas e infraestructura crítica en las Américas, Europa y Australia, y que el grupo estuvo entre los más activos en 2026, con al menos 600 víctimas distintas.

Las agencias autoras son el FBI, la CISA, el United States Secret Service, el Landeskriminalamt Rheinland-Pfalz (Alemania), la National Crime Agency del Reino Unido y la North West Regional Organised Crime Unit del Reino Unido. El aviso AA26-293A en CISA fija la publicación el 20 de octubre de 2026, y la nota de prensa de la CISA, liberada el 21 de octubre de 2026, habla de cerca de 600 víctimas y cita al subdirector asistente Brett Leatherman, de la FBI Cyber Division, con la formulación “más de 600 víctimas”.

El producto SafePay ransomware CISA describe un patrón familiar para quien opera emulación de adversario. Hay obtención de acceso, creación o toma de cuentas, uso de herramientas legítimas para moverse, desactivación de protecciones, cifrado de archivos y nota de rescate que pide pago en criptomoneda. El público objetivo declarado incluye gobierno federal civil de EE. UU., SLTT, infraestructura crítica y operadores de OT, además de analistas defensivos y gestores de vulnerabilidades.

En la práctica, lo que exijo de un ejercicio posterior al aviso es alinear el alcance a lo que las agencias documentaron, y no al rumor de foro. Si el número de víctimas o la geografía cambian en una actualización futura, la base de comparación sigue siendo el texto del AA26-293A y la fecha de la consulta, no la memoria colectiva del equipo.

ransomware SafePay: cómo ocurre el acceso inicial según el aviso

Según el aviso, el ransomware SafePay obtiene acceso inicial por exposición de credenciales, fuerza bruta de contraseña, abuso de VPN y explotación de sistemas orientados a internet, inclusive con perfiles de cuenta obtenidos por phishing y tráfico asociado a IP del proveedor VPN Mullvad.

En el mapeo MITRE ATT&CK Enterprise versión 20 usado por el AA26-293A, eso aparece bajo acceso inicial (TA0001), con fuerza bruta (T1110) y explotación de aplicación pública (T1190). Para dispositivos de borde, el aviso lista CVE-2020-3259 y CVE-2023-20269. Para sistemas expuestos con scripts automatizados, lista CVE-2023-27532, CVE-2024-40711 y CVE-2024-40766. La CISA, en el propio AA26-293A, prioriza la remediación de vulnerabilidades del catálogo KEV en sistemas internet-facing, sin nombrar fabricante en el tramo de CVE.

El análisis de respuesta de AttackIQ al AA26-293A refuerza el mismo bloque de CVE y el papel de credenciales y phishing en la puerta de entrada. El guía de parches de Brandefense sobre el aviso asocia los dos primeros a productos Cisco ASA/FTD, los dos siguientes a Veeam Backup & Replication y el último a SonicWall SonicOS, siempre con base en boletines de proveedor, porque el AA26-293A StopRansomware no nombra el producto junto a cada CVE. Eso importa para red team defensivo porque la hipótesis de ejercicio empieza en el borde y en la identidad, no en el payload de cifrado.

El error que más cuesta caro aquí es tratar VPN y firewall como ya autenticados y, por tanto, confiables. Cuando la cuenta local o el perfil phished elude MFA, o cuando la CVE de borde sigue abierta, el resto de la cadena del ransomware SafePay deja de ser hipotético y se convierte en cronograma de incidente.

Qué TTP mapea el aviso a MITRE ATT&CK

El AA26-293A mapea la actividad del ransomware SafePay a tácticas y técnicas de MITRE ATT&CK Enterprise versión 20, y solo esos ID, como figuran en el aviso, deben guiar la emulación autorizada y las reglas de detección.

Después del acceso, el texto describe persistencia por manipulación de cuentas existentes (T1098) o creación de cuentas (T1136), ejecución con binarios legítimos (T1218), PsExec en shares administrativos (T1021.002), WinRM (T1021.006) y PowerShell o shell (T1059.001, T1059.003). Herramientas nombradas en el aviso incluyen ShareFinder.ps1 y SharpShares.exe para cazar shares. En la recolección y salida, cita archivado con utilidades (T1560.001), exfiltración por protocolo alternativo (T1048) y por servicio web como OneDrive (T1567), con uso observado de 7-Zip, FileZilla, RClone, WinRAR y WinSCP. La síntesis SafeBreach publicada en Security Boulevard confirma, a partir de la tabla ATT&CK del aviso, la inhibición de recuperación (T1490) y el cifrado para impacto (T1486).

AttackIQ, al resumir el mismo AA26-293A, también registra bypass de UAC, impersonación de token, RDP, Mimikatz, artefactos de DCSync, ScreenConnect, AnyDesk y TeamViewer en usos abusivos, además de cifrado híbrido ChaCha20 con RSA, extensión .SafePay, nota de rescate con chat TOR, llamadas telefónicas de presión y amenaza de publicación en el sitio de filtración. La nota de prensa de la CISA describe el mismo ciclo de robo, cifrado y coerción, inclusive contacto directo por teléfono en algunos casos.

Mucha gente cree que basta bloquear el binario del ransomware, y casi siempre se equivoca, porque el AA26-293A muestra largos tramos de LOTL antes del cifrado. Si la telemetría solo mira el encryptor, la ventana de contención del ransomware SafePay ya pasó.

Cómo emular la cadena en ejercicio autorizado

Emular la cadena del ransomware SafePay, en el sentido útil a la defensa, significa validar hipótesis de acceso, movimiento, sabotaje de respaldo y coerción de datos en laboratorio o producción aislada, siempre con autorización formal por escrito, sin explotar objetivos de terceros y sin reproducir exploit funcional.

El objetivo del ejercicio no es probar que el red team entra. Es probar si la organización detecta y contiene cada fase listada en el AA26-293A. Por eso la emulación queda en nivel conceptual y de comportamiento, con herramientas aprobadas, cuentas de prueba y criterios de éxito definidos por el blue team antes del kickoff.

1. Fijar el alcance escrito con sistemas, horarios, datos sintéticos y criterios de aborto, citando explícitamente el AA26-293A como modelo de amenaza y prohibiendo cualquier explotación de CVE con payload armable fuera del laboratorio controlado.
2. Validar la superficie de identidad y VPN con cuentas de prueba, MFA obligatorio y revisión de autenticación local que eluda el segundo factor, midiendo alertas de fuerza bruta y login anómalo sin escanear la internet de terceros.
3. Emular movimiento lateral solo con utilidades ya autorizadas en el entorno de ejercicio, generando artefactos comparables a PsExec, WinRM y RDP descritos en el aviso, y pidiendo al SOC que clasifique lo que se vio o no.
4. Simular descubrimiento de shares y preparación de archivo con datos ficticios, sin exfiltrar dato real de cliente, y comprobar si hay alerta por compactación masiva y uso de clientes de sync.
5. Probar la hipótesis de inhibición de recuperación en copias descartables, nunca en backup de producción, y medir si el equipo de continuidad percibe pérdida de sombra o reset de NAS de laboratorio a tiempo de activar el plan.
6. Cerrar con tabletop de la SafePay doble extorsión, cubriendo decisión de comunicación, evidencia forense y restauración, sin negociar con actor real y sin usar enlaces TOR de nota de rescate como material operativo.

La limitación es clara. Incluso un ejercicio bien diseñado no garantiza que un incidente real del ransomware SafePay será contenido, porque la telemetría, la latencia humana y la configuración de producción difieren del laboratorio. Aun así, sin ese ensayo la defensa solo descubre el hueco cuando la nota .SafePay ya está en el escritorio.

Si montara la campaña mañana, empezaría por la identidad y por el borde KEV, y solo después tocaría emulación de exfiltración sintética. Cifrar demasiado pronto en el ejercicio enseña poco y asusta mucho, sin mejorar la madurez de detección.

Qué detectar en cada fase de la cadena

La defensa debe instrumentar cada fase del ransomware SafePay con hipótesis explícitas de alerta, porque el aviso describe una campaña larga en LOTL, no un único ejecutable obvio.

En el acceso inicial, busque picos de autenticación fallida en VPN, inicios de sesión con perfil recién phished, origen asociado a VPN comercial citada en el aviso e intentos contra dispositivos de borde aún sin corregir. En la ejecución y persistencia, correlacione creación de cuenta privilegiada, cambio masivo de contraseña de usuarios válidos y uso raro de PsExec, WinRM o software de acceso remoto instalado fuera de la ventana de cambio. En el descubrimiento, trate ShareFinder.ps1 y SharpShares.exe, o comportamientos equivalentes de barrido de share en AD, como caza de activo para exfiltración. En la recolección, observe compactación con 7-Zip, WinRAR o RClone en volúmenes de negocio, seguida de transferencia por FileZilla, WinSCP u OneDrive. En el impacto, priorice parada del servicio de Volume Shadow Copy, reset de NAS de backup y aparición de la extensión .SafePay, además de notas de rescate en el escritorio o en la raíz.

Ninguna de esas señales, aislada, prueba el ransomware SafePay. En conjunto, y alineadas a los IOC STIX del AA26-293A, elevan la confianza lo bastante para aislar cuenta y segmento. El costo oculto es el falso positivo en administración legítima. Por eso el ejercicio autorizado necesita calibrar allowlist y contexto de cambio, si no el SOC aprende a ignorar la alerta correcta.

En la práctica, lo que veo con más frecuencia es telemetría rica en la estación y pobre en la VPN y en el backup. Contra el perfil del AA26-293A, esa asimetría deja a la organización ciega justo donde el actor decide si la recuperación todavía existe.

Por qué la destrucción de respaldos y la doble extorsión cambian la respuesta

Porque el aviso describe actores que exfiltran antes de cifrar, sabotean Volume Shadow Copy y NAS de backup, y además presionan por teléfono y por amenaza de publicación, lo que hace que “solo restaurar” sea insuficiente si la copia en línea fue destruida o si la filtración ya salió.

El AA26-293A registra que el grupo interrumpe el Volume Shadow Copy Service y restablece de fábrica NAS con datos de backup, clasificado como inhibición de recuperación (T1490). Después cifra con ChaCha20 y RSA, exige pago en criptomoneda y, si no hay pago, publica en el sitio de filtración ligado en la nota. La nota de prensa de la CISA confirma el patrón de robo más cifrado y, en algunos casos, llamadas directas a las víctimas. Ese es el núcleo de la SafePay doble extorsión descrito por las agencias.

Para la respuesta a incidente, eso cambia el orden del trabajo. Además de contener el cifrado, hace falta preservar evidencia de exfiltración, estimar qué salió y decidir comunicación con base jurídica y contractual, sin asumir que pagar restaura reputación. Pagar tampoco es garantía de descifrado limpio ni de eliminación de la copia robada, y síntesis técnicas del aviso dejan claro que datos cifrados con la variante .SafePay no se recuperan sin la clave del actor.

El camino que priorizo con la mayoría de los equipos es probar restauración desde copia offline e inmutable antes del incidente, y entrenar el tabletop de filtración como evento separado de la restauración técnica. Cuando el backup solo existe en el mismo segmento que el actor ya administró, la coerción encuentra a la organización sin plan B.

Mitigaciones priorizadas MFA, VPN, KEV y respaldos inmutables

Las mitigaciones SafePay ransomware que el aviso y la nota de la CISA ponen al frente son actualización continua, MFA, parche prioritario de KEV en sistemas internet-facing, respaldos offline probados y segmentación, porque esas medidas cortan las puertas de entrada y el impacto usados para cobrar.

El AA26-293A pide remediación prioritaria de KEV, Zero Trust, restricción de herramientas y privilegios administrativos, y políticas de ICAM con MFA. La nota del 21 de octubre de 2026 repite MFA, parche de vulnerabilidades conocidas explotadas, respaldos offline con prueba de restauración y segmentación. Dos CVE citadas en el aviso ya tenían entrada pública en el catálogo KEV de la CISA en 2024, lo que refuerza la urgencia histórica del borde y del backup expuesto. El 17 de octubre de 2024 la CISA añadió el CVE-2024-40711 al KEV, y el 9 de septiembre de 2024 incluyó el CVE-2024-40766 en el mismo catálogo. El boletín KB4649 de Veeam, publicado el 4 de septiembre de 2024 y actualizado después, describe el CVE-2024-40711 como RCE no autenticado con CVSS v3.1 9.8 y corrección a partir de la build 12.2.0.334.

Esas acciones reducen probabilidad e impacto, pero no eliminan riesgo residual. MFA mal implementado aún falla si hay cuenta local sin segundo factor. Parche atrasado en appliance deja T1190 abierto. Backup inmutable sin prueba de restore se vuelve ficción en la crisis. Segmentación sin control de cuenta privilegiada se atraviesa con RDP y WinRM legítimos abusados.

Cuando reviso planes después de un #StopRansomware, pido evidencia de restore reciente e inventario KEV del borde antes de cualquier discusión sobre herramienta nueva de EDR. Sin esos dos pilares, el resto del playbook del ransomware SafePay se convierte en teatro de diapositivas.

Qué aún no se sabe tras el AA26-293A

Aún no se sabe, solo con el texto público del AA26-293A, la lista completa y estable de todas las víctimas, el valor medio pedido en cada caso, ni si cada CVE listada aparece en todas las intrusiones, porque el aviso agrega observaciones de investigaciones y no publica un censo auditable caso por caso.

Tampoco se puede tratar IOC STIX como cobertura eterna. Los indicadores envejecen, la infraestructura del actor rota y aparecen TTP migratorias después de la fecha de corte. El aviso menciona investigaciones hasta agosto de 2026, y la publicación es del 20 de octubre de 2026, de modo que cualquier campaña posterior exige nueva consulta en las fuentes oficiales. Divergencias leves de redacción entre “al menos 600”, “cerca de 600” y “más de 600” ya aparecen entre el aviso, la nota y la cobertura de Reuters republicada en medios como Yahoo News, lo que recomienda citar la frase exacta de la página usada.

Para red team y threat intel, la brecha útil es otra. El AA26-293A no sustituye telemetría local, ni autoriza barrido ofensivo de la internet ajena en nombre de la investigación. Lo que falta en su red solo se descubre con inventario, hunting y ejercicio autorizado, no con extrapolación del PDF.

Trato esa incertidumbre como parte del trabajo, no como excusa para la inmovilidad. Se usa lo que el aviso afirma con fecha, se marca lo que es hipótesis interna y se actualiza el modelo cuando la CISA o el FBI publiquen corrección.

Preguntas frecuentes sobre ransomware SafePay

Antes de cerrar, estas preguntas reúnen dudas que suelen surgir cuando un SOC o un equipo de red team abre el AA26-293A por primera vez y necesita transformar el texto en acción medible sin salir del alcance ético. Las respuestas siguientes se mantienen en el nivel del aviso y de la defensa, sin instrucción armable, y sirven tanto para priorizar parches como para diseñar ejercicio autorizado con criterio de éxito claro para el blue team.

¿El AA26-293A atribuye SafePay a qué tipo de operación?

El AA26-293A trata el ransomware SafePay como grupo y variante de ransomware observados desde agosto de 2024, con cifrado, nota de rescate en criptomoneda y presión adicional por filtración y teléfono. Las agencias no presentan el texto como atribución geopolítica estatal. Para planificación defensiva, lo que importa es el comportamiento documentado, las CVE, los TTP ATT&CK y las mitigaciones, todos con fecha de publicación el 20 de octubre de 2026 en el aviso y refuerzo el 21 de octubre de 2026 en la nota de la CISA.

¿Necesito explotar las CVE listadas para entrenar al equipo?

No. Entrenar explotación funcional de esas CVE contra sistemas de terceros es ilegal y queda fuera del alcance ético de este tipo de artículo y de ejercicio responsable. El camino alineado al aviso es parche prioritario, inventario de borde, revisión de MFA en VPN y emulación conductual solo en entorno propio o con autorización escrita. Detectar fallo de autenticación, uso anómalo de LOLBins y sabotaje de backup entrega más valor operativo que reproducir PoC.

¿Bastan los respaldos en la nube contra este grupo?

No bastan si el actor ya tiene cuenta privilegiada y puede borrar, cifrar o restablecer el repositorio alcanzable por la red comprometida. El AA26-293A describe interrupción de Volume Shadow Copy y reset de NAS de backup, lo que alcanza copias en línea accesibles. La mitigación citada por las agencias incluye respaldos offline y pruebas regulares de restauración. Sin inmutabilidad y sin prueba de restore, la nube sola no resuelve la coerción de la doble extorsión.

¿Cómo debe usar el red team el ATT&CK del aviso?

Debe usar solo las técnicas que el AA26-293A lista, como matriz de hipótesis para detección y para escenarios autorizados, en la versión Enterprise 20 referida en el texto. Cada técnica se convierte en pregunta al SOC sobre log, alerta y tiempo de respuesta. Técnicas de fuentes no oficiales o de relatos aislados entran como hipótesis separada, con etiqueta de confianza menor, hasta que exista fuente primaria. Eso evita inflar el ejercicio con ruido y mantiene trazabilidad al documento de las agencias.

¿Qué hacer en las primeras 72 horas después de leer el aviso?

En las primeras 72 horas, priorice inventario de las cinco CVE del aviso en el borde y en backup expuesto, confirme MFA sin bypass local en VPN, valide si hay copia offline comprobable y cargue los IOC STIX del AA26-293A en el pipeline de detección con proceso de expiración. En paralelo, marque en el calendario un ejercicio autorizado corto enfocado en identidad, movimiento LOTL e inhibición de recuperación. Esa secuencia no elimina el riesgo del ransomware SafePay, aunque reduce la superficie que el propio aviso señala como más explotada.

Conclusión

El AA26-293A coloca el ransomware SafePay en el centro de la prioridad defensiva de octubre de 2026 con números, fechas, CVE y TTP suficientes para actuar sin esperar el próximo incidente de la industria. Para la mayoría de las organizaciones, el primer paso útil es cerrar borde KEV y MFA de VPN, y probar restore offline, porque es ahí donde el aviso muestra que la campaña gana impulso.

La respuesta cambia cuando usted ya tiene evidencia de compromiso previo o de exfiltración. En ese caso el orden pasa a contención forense, estimación de lo que salió y comunicación controlada, todavía con la misma disciplina de no improvisar explotación ofensiva. El ejercicio autorizado existe para hallar el fallo de detección antes del actor real, no para coleccionar capturas de cifrado.

Si su equipo solo puede hacer una cosa esta semana, elija la combinación inventario de las CVE del aviso más prueba de restauración desde una copia que el ransomware SafePay no alcance por la red corporativa. El resto del programa de emulación y hunting gana base sólida después de que esos dos controles existan de verdad.

Este material tiene carácter informativo y educativo sobre el aviso AA26-293A y sobre emulación defensiva del ransomware SafePay. No sustituye evaluación profesional de seguridad, jurídica o de respuesta a incidente. Cualquier prueba técnica debe ocurrir solo en entornos propios o con autorización formal por escrito del titular del sistema, sin explotación de objetivos de terceros y sin uso de exploit, payload o procedimiento armable.