rançongiciel SafePay: avis AA26-293A pour red team

Le 20 octobre 2026, la CISA, le FBI, le USSS et des partenaires allemands et britanniques ont publié l'avis conjoint AA26-293A sur le rançongiciel SafePay. Le rançongiciel SafePay désigne l'opération et la variante décrites dans cet avis de la série #StopRansomware, avec une activité observée depuis août 2024 et au moins 600 victimes dans plusieurs secteurs d'infrastructures critiques.

Le texte officiel présente des TTP, des indicateurs et des mitigations issus d'enquêtes allant jusqu'à août 2026. Le communiqué de presse de la CISA, daté du 21 octobre 2026, confirme le même cadre et résume des actions concrètes pour limiter l'impact, y compris sur l'axe SafePay VPN phishing CVE qui ouvre souvent la chaîne.

Pour une équipe de red team au service de la défense, la valeur de l'avis ne consiste pas à rejouer l'attaque contre des tiers. Elle consiste à transformer la chaîne en hypothèses testables, uniquement en environnement propre ou avec une autorisation écrite formelle, puis à relier chaque phase à des signaux de détection et à des contrôles que le blue team peut mesurer.

Que affirme l'AA26-293A et qui signe l'avis

L'AA26-293A affirme que les acteurs du rançongiciel SafePay opèrent avec intensité depuis août 2024 contre des entreprises et des infrastructures critiques aux Amériques, en Europe et en Australie, et que le groupe figurait parmi les plus actifs en 2026, avec au moins 600 victimes distinctes.

Les agences auteures sont le FBI, la CISA, le United States Secret Service, le Landeskriminalamt Rheinland-Pfalz (Allemagne), la National Crime Agency du Royaume-Uni et la North West Regional Organised Crime Unit du Royaume-Uni. L'avis AA26-293A sur le site de la CISA fixe la publication au 20 octobre 2026, et le communiqué de presse de la CISA, diffusé le 21 octobre 2026, parle d'environ 600 victimes et cite l'assistant director Brett Leatherman, de la FBI Cyber Division, avec la formulation « plus de 600 victimes ».

Le produit SafePay rançongiciel CISA décrit un schéma familier à qui conduit une émulation d'adversaire. On y trouve l'obtention d'accès, la création ou la prise de comptes, l'usage d'outils légitimes pour se déplacer, la désactivation de protections, le chiffrement de fichiers et une note de rançon exigeant un paiement en cryptomonnaie. Le public cible déclaré inclut le gouvernement fédéral civil des États-Unis, les entités SLTT, les infrastructures critiques et les opérateurs d'OT, ainsi que les analystes défensifs et les responsables de la gestion des vulnérabilités.

Dans la pratique, ce que j'exige d'un exercice post-avis, c'est d'aligner le périmètre sur ce que les agences ont documenté, et non sur la rumeur d'un forum. Si le nombre de victimes ou la géographie évoluent dans une mise à jour future, la base de comparaison reste le texte de l'AA26-293A et la date de consultation, pas la mémoire collective de l'équipe.

rançongiciel SafePay: comment l'accès initial se produit selon l'avis

Selon l'avis, le rançongiciel SafePay obtient l'accès initial par exposition de credentials, force brute de mots de passe, abus de VPN et exploitation de systèmes exposés à Internet, y compris avec des profils de compte obtenus par phishing et un trafic associé à des IP du fournisseur VPN Mullvad.

Dans le mapping MITRE ATT&CK Enterprise version 20 utilisé par l'AA26-293A, cela apparaît sous l'accès initial (TA0001), avec la force brute (T1110) et l'exploitation d'application publique (T1190). Pour les équipements de bordure, l'avis liste CVE-2020-3259 et CVE-2023-20269. Pour les systèmes exposés avec scripts automatisés, il liste CVE-2023-27532, CVE-2024-40711 et CVE-2024-40766. La CISA, dans l'AA26-293A lui-même, priorise la remédiation des vulnérabilités du catalogue KEV sur les systèmes internet-facing, sans nommer le fabricant dans le passage des CVE.

L'analyse de réponse d'AttackIQ à l'AA26-293A confirme le même bloc de CVE et le rôle des credentials et du phishing à l'entrée. Le guide de correctifs Brandefense sur l'avis associe les deux premiers à des produits Cisco ASA/FTD, les deux suivants à Veeam Backup & Replication et le dernier à SonicWall SonicOS, toujours à partir des bulletins éditeur, car l'AA26-293A StopRansomware ne nomme pas le produit à côté de chaque CVE. Cela compte pour le red team défensif, car l'hypothèse d'exercice commence à la bordure et à l'identité, pas au payload de chiffrement.

L'erreur qui coûte le plus cher ici, c'est de traiter le VPN et le pare-feu comme déjà authentifiés et donc fiables. Quand le compte local ou le profil phishé contourne le MFA, ou quand la CVE de bordure reste ouverte, le reste de la chaîne du rançongiciel SafePay cesse d'être hypothétique et devient un calendrier d'incident.

Quels TTP l'avis cartographie vers MITRE ATT&CK

L'AA26-293A cartographie l'activité du rançongiciel SafePay vers des tactiques et techniques de MITRE ATT&CK Enterprise version 20, et seuls ces identifiants, tels qu'ils figurent dans l'avis, doivent guider l'émulation autorisée et les règles de détection.

Après l'accès, le texte décrit la persistance par manipulation de comptes existants (T1098) ou création de comptes (T1136), l'exécution avec des binaires légitimes (T1218), PsExec sur des partages administratifs (T1021.002), WinRM (T1021.006) et PowerShell ou shell (T1059.001, T1059.003). Les outils nommés dans l'avis incluent ShareFinder.ps1 et SharpShares.exe pour chasser les partages. Sur la collecte et la sortie, il cite l'archivage avec utilitaires (T1560.001), l'exfiltration par protocole alternatif (T1048) et par service web comme OneDrive (T1567), avec un usage observé de 7-Zip, FileZilla, RClone, WinRAR et WinSCP. La synthèse SafeBreach publiée sur Security Boulevard confirme, à partir du tableau ATT&CK de l'avis, l'inhibition de la récupération (T1490) et le chiffrement pour l'impact (T1486).

AttackIQ, en résumant le même AA26-293A, enregistre aussi le contournement d'UAC, l'usurpation de jeton, le RDP, Mimikatz, des artefacts de DCSync, ScreenConnect, AnyDesk et TeamViewer dans des usages abusifs, ainsi qu'un chiffrement hybride ChaCha20 avec RSA, l'extension .SafePay, une note de rançon avec chat TOR, des appels téléphoniques de pression et la menace de publication sur le site de fuite. Le communiqué de la CISA décrit le même cycle de vol, de chiffrement et de coercition, y compris un contact téléphonique direct dans certains cas.

Beaucoup pensent qu'il suffit de bloquer le binaire du rançongiciel, et ils se trompent presque toujours, car l'AA26-293A montre de longs segments LOTL avant le chiffrement. Si la télémétrie ne regarde que l'encryptor, la fenêtre de confinement du rançongiciel SafePay est déjà passée.

Comment émuler la chaîne en exercice autorisé

Émuler la chaîne du rançongiciel SafePay, au sens utile à la défense, signifie valider des hypothèses d'accès, de mouvement, de sabotage de sauvegarde et de coercition de données en laboratoire ou en production isolée, toujours avec une autorisation écrite formelle, sans exploiter des cibles tierces et sans reproduire d'exploit fonctionnel.

L'objectif de l'exercice n'est pas de prouver que le red team entre. C'est de prouver si l'organisation détecte et contient chaque phase listée dans l'AA26-293A. L'émulation reste donc au niveau conceptuel et comportemental, avec des outils approuvés, des comptes de test et des critères de succès définis par le blue team avant le kickoff.

1. Fixer le périmètre écrit avec systèmes, créneaux, données synthétiques et critères d'abort, en citant explicitement l'AA26-293A comme modèle de menace et en interdisant toute exploitation de CVE avec payload armable hors laboratoire contrôlé.
2. Valider la surface d'identité et de VPN avec des comptes de test, un MFA obligatoire et une revue de l'authentification locale qui contourne le second facteur, en mesurant les alertes de force brute et de connexion anormale sans scanner l'Internet de tiers.
3. Émuler le mouvement latéral uniquement avec des utilitaires déjà autorisés dans l'environnement d'exercice, en générant des artefacts comparables à PsExec, WinRM et RDP décrits dans l'avis, puis en demandant au SOC de classer ce qui a été vu ou non.
4. Simuler la découverte de partages et la préparation d'archives avec des données fictives, sans exfiltrer de donnée réelle client, et vérifier s'il existe une alerte pour compression massive et usage de clients de sync.
5. Tester l'hypothèse d'inhibition de récupération sur des copies jetables, jamais sur une sauvegarde de production, et mesurer si l'équipe de continuité perçoit à temps la perte d'ombre ou le reset d'un NAS de laboratoire pour déclencher le plan.
6. Clôturer par un tabletop de la SafePay double extorsion, couvrant la décision de communication, la preuve forensique et la restauration, sans négocier avec un acteur réel et sans traiter les liens TOR d'une note de rançon comme matériel opérationnel.

La limite est claire. Même un exercice bien conçu ne garantit pas qu'un incident réel du rançongiciel SafePay sera contenu, car la télémétrie, la latence humaine et la configuration de production diffèrent du lab. Sans cet essai, la défense ne découvre le trou que lorsque la note .SafePay est déjà sur le bureau.

Si je montais la campagne demain, je commencerais par l'identité et la bordure KEV, et je ne toucherais l'émulation d'exfiltration synthétique qu'ensuite. Chiffrer trop tôt dans l'exercice enseigne peu et effraie beaucoup, sans améliorer la maturité de détection.

Que détecter à chaque phase de la chaîne

La défense doit instrumenter chaque phase du rançongiciel SafePay avec des hypothèses d'alerte explicites, car l'avis décrit une campagne longue en LOTL, et non un seul exécutable évident.

À l'accès initial, cherchez les pics d'authentification échouée sur VPN, les connexions avec un profil récemment phishé, une origine associée au VPN commercial cité dans l'avis et des tentatives contre des équipements de bordure encore non corrigés. En exécution et persistance, corrélez la création de compte privilégié, le changement massif de mots de passe d'utilisateurs valides et l'usage rare de PsExec, WinRM ou logiciels d'accès distant installés hors fenêtre de changement. En découverte, traitez ShareFinder.ps1 et SharpShares.exe, ou des comportements équivalents de scan de partages dans l'AD, comme une chasse d'actifs pour exfiltration. En collecte, observez la compression avec 7-Zip, WinRAR ou RClone sur des volumes métier, suivie d'un transfert via FileZilla, WinSCP ou OneDrive. À l'impact, priorisez l'arrêt du service Volume Shadow Copy, le reset d'un NAS de sauvegarde et l'apparition de l'extension .SafePay, ainsi que les notes de rançon sur le bureau ou à la racine.

Aucun de ces signaux, isolé, ne prouve le rançongiciel SafePay. Ensemble, et alignés sur les IOC STIX de l'AA26-293A, ils élèvent assez la confiance pour isoler compte et segment. Le coût caché reste le faux positif en administration légitime. C'est pourquoi l'exercice autorisé doit calibrer allowlist et contexte de changement, sinon le SOC apprend à ignorer la bonne alerte.

En pratique, ce que je vois le plus souvent, c'est une télémétrie riche sur le poste et pauvre sur le VPN et la sauvegarde. Face au profil de l'AA26-293A, cette asymétrie aveugle l'organisation exactement là où l'acteur décide si la récupération existe encore.

Pourquoi la destruction des sauvegardes et la double extorsion changent la réponse

Parce que l'avis décrit des acteurs qui exfiltrent avant de chiffrer, sabotent Volume Shadow Copy et les NAS de sauvegarde, puis font pression par téléphone et par menace de publication, le simple « restaurer » devient insuffisant si la copie en ligne a été détruite ou si la fuite est déjà sortie.

L'AA26-293A indique que le groupe interrompt le Volume Shadow Copy Service et remet à l'usine des NAS contenant des données de sauvegarde, classé comme inhibition de la récupération (T1490). Ensuite il chiffre avec ChaCha20 et RSA, exige un paiement en cryptomonnaie et, sans paiement, publie sur le site de fuite lié dans la note. Le communiqué de la CISA confirme le schéma vol plus chiffrement et, dans certains cas, des appels directs aux victimes. C'est le noyau de la SafePay double extorsion décrit par les agences.

Pour la réponse à incident, cela change l'ordre du travail. Au-delà de contenir le chiffrement, il faut préserver la preuve d'exfiltration, estimer ce qui est sorti et décider la communication sur une base juridique et contractuelle, sans supposer que payer restaure la réputation. Payer n'est pas non plus une garantie de déchiffrement propre ni de suppression de la copie volée, et les synthèses techniques de l'avis rappellent que les données chiffrées avec la variante .SafePay ne se récupèrent pas sans la clé de l'acteur.

Le chemin que je priorise avec la plupart des équipes, c'est de prouver la restauration depuis une copie hors ligne et immuable avant l'incident, puis d'entraîner le tabletop de fuite comme événement distinct de la restauration technique. Quand la sauvegarde n'existe que dans le même segment que l'acteur a déjà administré, la coercition trouve l'organisation sans plan B.

Mitigations prioritaires MFA, VPN, KEV et sauvegardes immuables

Les mitigations SafePay rançongiciel que l'avis et le communiqué de la CISA placent en tête sont la mise à jour continue, le MFA, le patch prioritaire KEV sur les systèmes internet-facing, les sauvegardes hors ligne testées et la segmentation, car ces mesures coupent les portes d'entrée et l'impact utilisés pour facturer.

L'AA26-293A demande une remédiation prioritaire du KEV, du Zero Trust, une restriction des outils et privilèges administratifs, et des politiques ICAM avec MFA. Le communiqué du 21 octobre 2026 répète MFA, correctifs des vulnérabilités connues exploitées, sauvegardes hors ligne avec test de restauration et segmentation. Deux CVE citées dans l'avis avaient déjà une entrée publique dans le catalogue KEV de la CISA en 2024, ce qui renforce l'urgence historique de la bordure et de la sauvegarde exposée. Le 17 octobre 2024, la CISA a ajouté le CVE-2024-40711 au catalogue KEV, et le 9 septembre 2024 elle a inclus le CVE-2024-40766 dans le même catalogue. Le bulletin KB4649 de Veeam, publié le 4 septembre 2024 et mis à jour ensuite, décrit le CVE-2024-40711 comme une RCE non authentifiée avec un CVSS v3.1 de 9.8 et une correction à partir du build 12.2.0.334.

Ces actions réduisent la probabilité et l'impact, mais elles n'éliminent pas le risque résiduel. Un MFA mal mis en œuvre échoue encore s'il existe un compte local sans second facteur. Un patch retardé sur un appliance laisse T1190 ouvert. Une sauvegarde immuable sans test de restore devient fiction en crise. Une segmentation sans contrôle du compte privilégié est traversée par du RDP et du WinRM légitimes abusés.

Quand je revois des plans après un #StopRansomware, je demande d'abord la preuve d'un restore récent et l'inventaire KEV de la bordure, avant toute discussion sur un nouvel outil EDR. Sans ces deux piliers, le reste du playbook du rançongiciel SafePay devient du théâtre de slides.

Ce que l'on ne sait pas encore après l'AA26-293A

On ne sait pas encore, avec le seul texte public de l'AA26-293A, la liste complète et stable de toutes les victimes, le montant moyen demandé dans chaque cas, ni si chaque CVE listée apparaît dans toutes les intrusions, car l'avis agrège des observations d'enquêtes et ne publie pas un recensement auditable dossier par dossier.

On ne peut pas non plus traiter les IOC STIX comme une couverture éternelle. Les indicateurs vieillissent, l'infrastructure de l'acteur tourne et des TTP migratoires apparaissent après la date de coupure. L'avis mentionne des enquêtes jusqu'à août 2026, et la publication est du 20 octobre 2026, donc toute campagne postérieure exige une nouvelle vérification dans les sources officielles. De légères divergences de rédaction entre « au moins 600 », « environ 600 » et « plus de 600 » apparaissent déjà entre l'avis, le communiqué et la couverture Reuters reprise par des médias comme Yahoo News, ce qui recommande de citer la phrase exacte de la page utilisée.

Pour le red team et le threat intel, la lacune utile est ailleurs. L'AA26-293A ne remplace pas la télémétrie locale, et il n'autorise pas non plus un scan offensif de l'Internet d'autrui au nom de la recherche. Ce qui manque dans votre réseau ne se découvre que par inventaire, hunting et exercice autorisé, pas par extrapolation du PDF.

Je traite cette incertitude comme une part du métier, et non comme une excuse à l'immobilité. On utilise ce que l'avis affirme avec date, on marque ce qui reste une hypothèse interne, et on met à jour le modèle quand la CISA ou le FBI publient une correction.

Questions fréquentes sur le rançongiciel SafePay

Avant de conclure, ces questions regroupent les doutes qui surgissent souvent lorsqu'un SOC ou une équipe de red team ouvre l'AA26-293A pour la première fois et doit transformer le texte en action mesurable sans sortir du périmètre éthique. Les réponses ci-dessous restent au niveau de l'avis et de la défense, sans instruction armable, et servent autant à prioriser le patch qu'à concevoir un exercice autorisé avec un critère de succès clair pour le blue team.

L'AA26-293A rattache SafePay à quel type d'opération?

L'AA26-293A traite le rançongiciel SafePay comme un groupe et une variante de rançongiciel observés depuis août 2024, avec chiffrement, note de rançon en cryptomonnaie et pression supplémentaire par fuite et téléphone. Les agences ne présentent pas le texte comme une attribution géopolitique étatique. Pour la planification défensive, ce qui compte, c'est le comportement documenté, les CVE, les TTP ATT&CK et les mitigations, le tout avec date de publication au 20 octobre 2026 dans l'avis et renforcement le 21 octobre 2026 dans le communiqué de la CISA.

Faut-il exploiter les CVE listées pour former l'équipe?

Non. Former à l'exploitation fonctionnelle de ces CVE contre des systèmes de tiers est illégal et hors du périmètre éthique de ce type d'article et d'un exercice responsable. La voie alignée sur l'avis passe par le patch prioritaire, l'inventaire de bordure, la revue du MFA sur VPN et une émulation comportementale uniquement en environnement propre ou avec autorisation écrite. Détecter l'échec d'authentification, l'usage anormal de LOLBins et le sabotage de sauvegarde apporte plus de valeur opérationnelle que la reproduction d'un PoC.

Les sauvegardes cloud suffisent-elles contre ce groupe?

Elles ne suffisent pas si l'acteur dispose déjà d'un compte privilégié et peut effacer, chiffrer ou réinitialiser le dépôt atteignable depuis le réseau compromis. L'AA26-293A décrit l'interruption de Volume Shadow Copy et le reset de NAS de sauvegarde, ce qui touche les copies en ligne accessibles. La mitigation citée par les agences inclut des sauvegardes hors ligne et des tests réguliers de restauration. Sans immuabilité et sans preuve de restore, le cloud seul ne résout pas la coercition de la double extorsion.

Comment le red team doit-il utiliser l'ATT&CK de l'avis?

Il doit utiliser uniquement les techniques que l'AA26-293A liste, comme matrice d'hypothèses pour la détection et pour des scénarios autorisés, dans la version Enterprise 20 citée dans le texte. Chaque technique devient une question au SOC sur le journal, l'alerte et le délai de réponse. Les techniques issues de sources non officielles ou de récits isolés entrent comme hypothèse séparée, avec une étiquette de confiance plus faible, jusqu'à disposer d'une source primaire. Cela évite de gonfler l'exercice avec du bruit et conserve la traçabilité vers le document des agences.

Que faire dans les 72 premières heures après lecture de l'avis?

Dans les 72 premières heures, priorisez l'inventaire des cinq CVE de l'avis sur la bordure et la sauvegarde exposée, confirmez un MFA sans contournement local sur VPN, validez qu'il existe une copie hors ligne testable et chargez les IOC STIX de l'AA26-293A dans le pipeline de détection avec un processus d'expiration. En parallèle, placez au calendrier un exercice autorisé court centré sur l'identité, le mouvement LOTL et l'inhibition de récupération. Cette séquence n'élimine pas le risque du rançongiciel SafePay, mais elle réduit la surface que l'avis lui-même désigne comme la plus exploitée.

Conclusion

L'AA26-293A place le rançongiciel SafePay au centre de la priorité défensive d'octobre 2026, avec des chiffres, des dates, des CVE et des TTP suffisants pour agir sans attendre le prochain incident du secteur. Pour la plupart des organisations, le premier pas utile consiste à fermer la bordure KEV et le MFA VPN, puis à prouver un restore hors ligne, car c'est là que l'avis montre la campagne prendre de l'élan.

La réponse change lorsque vous avez déjà une preuve d'accès préalable ou d'exfiltration. Dans ce cas l'ordre devient confinement forensique, estimation de ce qui est sorti et communication contrôlée, toujours avec la même discipline de ne pas improviser d'exploitation offensive. L'exercice autorisé existe pour trouver la faille de détection avant l'acteur réel, pas pour collectionner des captures d'écran de chiffrement.

Si votre équipe ne peut faire qu'une seule chose cette semaine, choisissez la combinaison inventaire des CVE de l'avis plus test de restauration depuis une copie que le rançongiciel SafePay n'atteint pas par le réseau d'entreprise. Le reste du programme d'émulation et de hunting gagne une base solide une fois que ces deux contrôles existent vraiment.

Ce contenu a un caractère informatif et éducatif sur l'avis AA26-293A et sur l'émulation défensive du rançongiciel SafePay. Il ne remplace pas une évaluation professionnelle de sécurité, un avis juridique ou une réponse à incident. Tout test technique doit se dérouler uniquement dans des environnements propres ou avec une autorisation écrite formelle du titulaire du système, sans exploitation de cibles tierces et sans usage d'exploit, de payload ou de procédure armable.