Analyse du Ransomware Benzona : IOCs, Possibilités de Décryptage et Stratégies de Défense
Équipe de Sécurité Cyberlord Profil de l'auteur

En novembre 2025, une nouvelle souche de ransomware sophistiquée connue sous le nom de Benzona a émergé, se faisant rapidement un nom en ciblant des organisations à travers l'Europe, l'Asie et l'Afrique de l'Ouest. Opérant sur un modèle de Ransomware-as-a-Service (RaaS), Benzona emploie des tactiques agressives de double extorsion, menaçant de divulguer des données sensibles si ses exigences ne sont pas satisfaites.
Cette analyse technique décompose la chaîne d'attaque Benzona, les Indicateurs de Compromission (IOCs) et les stratégies de défense actionnables pour les professionnels de la sécurité.

La Chaîne d'Attaque Benzona
Benzona suit un cycle de vie d'attaque structuré conçu pour maximiser l'impact et entraver la récupération.
1. Accès Initial & Exécution
Les attaquants obtiennent généralement l'accès via des campagnes de phishing, des identifiants compromis ou en exploitant des vulnérabilités non corrigées dans des applications publiques. Une fois à l'intérieur, le ransomware utilise :
- Injection de Processus (T1055) : Injection de code malveillant dans des processus légitimes pour échapper à la détection.
- Interpréteurs de Script (T1059) : Utilisation de PowerShell pour exécuter des commandes et désactiver les contrôles de sécurité.
2. Évasion & Persistance
Pour maintenir l'accès et éviter la détection antivirus, Benzona :
- Désactive la Récupération : Il exécute des commandes pour supprimer les Copies d'Ombre de Volume (
vssadmin.exe Delete Shadows /All /Quiet) et supprimer les points de restauration Windows. - Termine les Processus : Il tue les logiciels de sécurité et les processus de virtualisation pour empêcher l'analyse et s'assurer que les fichiers ne sont pas verrouillés pendant le cryptage.
- Modifie le Registre : Il altère les clés de registre pour assurer la persistance après les redémarrages.
3. Cryptage & Exfiltration (Double Extorsion)
Benzona utilise des algorithmes cryptographiques forts pour verrouiller les fichiers des victimes.
- Extension de Fichier : Les fichiers cryptés sont ajoutés avec l'extension
.benzona(par exemple,rapport_financier.pdf.benzona). - Vol de Données : Avant le cryptage, le malware exfiltre des données sensibles vers un serveur de commande et contrôle (C2). Ces données volées sont le levier pour la deuxième étape de l'extorsion.
4. La Note de Rançon
Une fois le cryptage terminé, une note de rançon intitulée RECOVERY_INFO.txt est déposée dans les répertoires affectés. La note contient généralement :
- Un avertissement que les fichiers sont cryptés et que les données ont été volées.
- Une menace de publier les données si la rançon n'est pas payée dans les 72 heures.
- Des instructions pour télécharger le navigateur Tor et visiter un portail de chat
.onionspécifique pour la négociation.
Indicateurs de Compromission (IOCs)
Les équipes de sécurité doivent scanner les indicateurs suivants pour détecter l'activité Benzona.
Indicateurs de Fichiers
- Extension :
.benzona - Note de Rançon :
RECOVERY_INFO.txt
Indicateurs Réseau
- Portail de Chat Tor :
http://rwsu75mtgj5oiz3alkfpnxnopcbiqed6wllyoffpuruuu6my6imjzuqd.onion/ - Site de Fuite :
http://benzona6x5ggng3hx52h4mak5sgx5vukrdlrrd3of54g2uppqog2joyd.onion
Hashes de Fichiers (SHA-256)
09f7432834ce15e701aa7fcc84a9c2441c1c7e0a9cb66a6211845be73d2597cc1c895eeb1d6ab9e5268759558c765b93f4c183557cb2c457857b91532ac61982
Stratégies de Défense & Atténuation
Il n'y a actuellement aucun décrypteur gratuit disponible pour le ransomware Benzona. La prévention et la réponse rapide sont vos seules défenses.
- Sauvegardes Immuables : Assurez-vous d'avoir des sauvegardes hors ligne et immuables. Benzona cible et supprime les sauvegardes en ligne et les copies d'ombre.
- Gestion des correctifs : Priorisez la correction des systèmes exposés à Internet pour empêcher l'accès initial.
- Segmentation du Réseau : Limitez le mouvement latéral en segmentant les réseaux critiques.
- Détection et Réponse aux Endpoints (EDR) : Déployez des solutions EDR configurées pour bloquer l'injection de processus et les modifications de fichiers en masse.
- Formation des Utilisateurs : Menez des simulations de phishing pour éduquer les employés sur la reconnaissance des e-mails malveillants.
De la détection à l'isolement : les 24 premières heures
Dans une PME, la mise en œuvre ne tient rarement en une seule personne : il faut au minimum deux manuels. La séquence suivante suppose que l'EDR a signalé des fichiers renommés en .benzona :
- Minute 0 – Contraindre la propagation : débrancher le réseau des postes suspects et déconnecter les partages SMB exposés. Ne pas éteindre les machines : la mémoire contient parfois le binaire, des clés de session ou des traces d'exfiltration.
- Première heure – Couper les accès : révoquer les sessions VPN et les comptes à privilèges, fermer l'accès à distance depuis une machine propre, pas cryptée.
- Heures 2 à 6 – Deux files en parallèle : une file forensique (images disque, journaux, note de rançon) et une file de pilotage (assureur cyber, conseil juridique, CERT ou CIRCL correspondant). Les deux files ne suivent ni les mêmes objectifs ni les mêmes contraintes.
- Heures 6 à 12 – Valider les sauvegardes : vérifier l'empreinte du support hors ligne, tester une restauration sur un poste de contrôle, noter les horodatages de dernière copie par système.
- Heure 24 – Décision actée : au plus tard un jour après l'alerte, une décision documentée et signée. Reporter indéfiniment transforme un incident en crise.
Restaurer ou négocier ? Les critères à poser à plat
Le choix entre restauration et paiement (ou un hybride des deux) ne doit pas être émotionnel. Trois questions le structurent :
- L'ampleur et l'intégrité des sauvegardes. Si les sauvegardes immuables couvrent l'ensemble des systèmes critiques avec un RPO acceptable, la restauration est privilégiée. Sinon, il faut chiffrer ce que le complément coûterait en reconstruction manuelle (heures d'équipe, reconstitution de base, perte d'historique de messagerie).
- La cause racine est-elle fermée ? Restaurer sur un parc encore compromis garantit la récurrence. Si le vecteur initial (compte volé, vulnérabilité, serveur exposé) n'est pas neutralisé, la restauration doit attendre.
- La durée des deux scenarii. Une restauration sérieuse d'un parc de 30 à 50 postes prend rarement moins de deux à cinq jours ouvrés, une fois la cause racine fermée. Toute voie alternative doit être notée noir sur blanc — en gardant à l'esprit qu'aucun décrypteur gratuit n'existe pour Benzona et qu'aucun prestataire ne peut garantir la récupération des clés.
Une remise des clés ne ferme jamais le dossier : les données exfiltrées restent hors de contrôle, ce qui maintient l'obligation d'apprécier l'incident au regard du RGPD, même après le déchiffrement.
Pièges fréquents de la restauration
Les retours d'expérience d'incident convergent vers un petit ensemble d'erreurs :
- Restaurer sur un hôte réinfecté. Sans vérifier la cause racine ni reformater les disques système, la nouvelle exécution du chiffrement survient parfois en quelques heures.
- Ignorer les tâches planifiées et les comptes de service. Les sauvegardes d'un serveur de fichiers peuvent être intactes alors qu'une tâche planifiée exécutée sous un compte de service compromis relance la chaîne d'attaque indépendamment de l'authentification humaine.
- Oublier la messagerie et l'authentification. Les boîtes aux lettres et les jetons de session (cookies d'entreprise, inscriptions TOTP provisionnées) font partie du périmètre compromis mais sortent du champ des sauvegardes classiques.
- Remonter un annuaire LDAP ou un SGBD sans valider les comptes à privilèges. La restauration technique est réussie ; la réinfection par rejeu d'un objet ordinateur ou d'un mot de passe sorti d'un instantané découle du manque de réinitialisation.
- Purger les preuves pendant la reconstruction. Reformater les machines d'origine avant qu'une analyse forensique n'archive les disques rend l'analyse post-mortem impossible et complique la déclaration auprès de l'assureur ou du régulateur.
Checklist de préservation des preuves
Avant toute remise au propre, les éléments suivants doivent être consignés, datés et stockés hors du domaine compromis :
- Copies de la note de rançon
RECOVERY_INFO.txtaccompagnées des attributs et horodatages de création du fichier. - Exemplaires du binaire si disponibles (
.exe,.dll), avec empreinte SHA-256 à comparer aux indicateurs listés plus haut. - Journaux : pare-feu, contrôleur de domaine, VPN, EDR et journal d'événements Windows — au minimum les 15 jours précédant l'alerte, la fenêtre d'exfiltration pouvant remonter plus loin.
- Image forensique des postes les plus touchés, acquise avec un outil dédié si possible, avec une trace de chaîne de conservation (qui, quand, quel support).
- Le journal des décisions : horodatage de chaque action de confinement, de chaque contact externe et de chaque décision de restitution.
Les empreintes SHA-256 publiées plus haut ne couvrent que des échantillons précis de Benzona : une empreinte absente n'établit pas l'absence de compromission, et une correspondance de hash peut provenir d'une réutilisation de la même charge utile dans une autre campagne.
Conclusion
Benzona représente l'évolution continue des menaces RaaS fin 2025. Son utilisation de la double extorsion et des techniques anti-récupération en fait un adversaire redoutable. Les organisations doivent passer d'une posture réactive à une mentalité proactive "supposez la brèche", en se concentrant sur la résilience et la récupération rapide.
Si vous avez été touché par Benzona, ne payez pas la rançon immédiatement. Contactez une équipe professionnelle de réponse aux incidents pour évaluer vos options.
Aperçu
Décisions clés, risques et actions de mise en oeuvre pour ce sujet.