Analyse de la campagne Blinder Tunnel : Tactiques, techniques et infrastructure
Detection stack
- AIDR
- Alert
- ETL
- Query
Résumé
Un acteur menaçant aligné sur l’État iranien mène la campagne Blinder Tunnel contre des organisations d’infrastructures critiques au Moyen-Orient. Les attaquants s’appuient sur l’ingénierie sociale, se faisant passer pour les aéroports de Dubaï pour distribuer des projets Visual Studio armés. Ces projets abusent des outils de développement de confiance pour déployer des logiciels malveillants personnalisés, y compris ShelbyLoader V2 et des utilitaires de tunneling Blackwood, tout en utilisant une infrastructure de commande et de contrôle basée sur GitHub.
Enquête
Les chercheurs de l’unité 42 ont suivi l’activité depuis la préparation de l’infrastructure à la fin de 2025 jusqu’au ciblage actif observé en 2026. L’enquête a révélé une chaîne d’infection en plusieurs étapes impliquant le détournement d’AppDomainManager et le chargement latéral de DLL. L’analyse des logiciels malveillants a également révélé l’utilisation des API GitHub pour la communication C2 et des résolveurs dead-drop, ainsi qu’une nomenclature et un marquage thématiques inspirés de Peaky Blinders.
Atténuation
Les organisations doivent renforcer les environnements de développement et surveiller l’exécution suspecte d’utilitaires de confiance tels que msbuild.exe. La mise en place de contrôles stricts de chargement de DLL et la détection de DLL inattendues ou non standard dans les répertoires système peuvent réduire l’exposition aux attaques. Les équipes de sécurité devraient également déployer une protection avancée des points de terminaison capable de détecter l’exécution en mémoire et les activités non autorisées de PowerShell.
Réponse
Lorsqu’une activité suspecte est détectée, les organisations doivent isoler les points de terminaison affectés et initier une réinitialisation des identifiants. Les équipes de sécurité devraient examiner la télémétrie de détection et de réponse des points de terminaison (EDR) pour un comportement de processus anormal, en particulier les signes de détournement de processus légitimes. Les enquêteurs devraient également examiner les connexions non autorisées aux services cloud publics tels que GitHub pour des motifs de trafic inhabituel ou non standard.
Flux d’Attaque
Détections
Points de persistance possibles [ASEPs – Software/NTUSER Hive] (via registry_event)
Exécution de processus système à partir de chemins atypiques (via process_creation)
Téléchargement possible de fichiers GitHub initié par un processus inhabituel (via network_connection)
Commande et contrôle suspicieux par demande DNS de domaine de premier niveau inhabituel (TLD) (via dns)
IOC (HashSha256) pour détecter : Analyse de la campagne Blinder Tunnel
IOC (SourceIP) pour détecter : Analyse de la campagne Blinder Tunnel
IOC (DestinationIP) pour détecter : Analyse de la campagne Blinder Tunnel
Activité suspecte provenant du domaine de phishing cloud.g-drive.cam [Google Cloud Platform]
Détection de processus renommés menant au détournement d’AppDomainManager [Création de processus Windows]
Détection du projet Visual Studio malveillant Blinder Tunnel [Événement de fichier Windows]
Exécution de simulation
-
Narration des attaques & Commandes : L’adversaire initie une campagne de phishing. Une victime reçoit un email semblant être un document partagé de Google Cloud. Lorsque la victime clique sur le lien, son navigateur effectue une requête GET vers
https://cloud.g-drive.cam/login/auth. Cette requête est capturée par le proxy d’entreprise, qui devrait déclencher la règle de détection basée sur la présence du domaine malveillant dans l’URL. -
Script de test de régression :
# Script de simulation pour déclencher la règle de détection en demandant le domaine de phishing. # Cela simule un utilisateur cliquant sur un lien dans un email de phishing. $PhishingUrl = "https://cloud.g-drive.cam/auth/login?user=victim" Write-Host "Simulation de connexion au domaine de phishing : $PhishingUrl" try { # Nous utilisons -ErrorAction SilentlyContinue car le domaine n'existe pas réellement, # mais la requête DNS et la tentative de connexion généreront le journal du proxy. Invoke-WebRequest -Uri $PhishingUrl -Method Get -UseBasicParsing -ErrorAction SilentlyContinue Write-Host "Tentative de connexion terminée. Vérifiez le SIEM pour les journaux du proxy." } catch { Write-Host "Échec de la connexion comme prévu (domaine probablement inexistant), mais une télémétrie devrait être générée." } -
Commandes de nettoyage :
# Aucun changement permanent n'est apporté au système. # Pour vider le cache Web local si nécessaire : Clear-History Write-Host "Nettoyage de simulation terminé. Aucun artefact laissé sur l'hôte."