SOC Prime Bias: Critique

12 Jan 2026 12:59 UTC

BlueDelta (APT28) Hameçonnage de Crédentiels via Hébergement Gratuit & Ngrok

Author Photo
Ruslan Mikhalov Chief of Threat Research at SOC Prime linkedin icon Suivre
BlueDelta (APT28) Hameçonnage de Crédentiels via Hébergement Gratuit & Ngrok
shield icon

Detection stack

  • AIDR
  • Alert
  • ETL
  • Query

Résumé

BlueDelta, un groupe affilié au GRU également connu sous les noms de APT28/Fancy Bear, a mené plusieurs campagnes de collecte de données d’identification entre février et septembre 2025. Les campagnes utilisaient des services d’hébergement et de tunneling gratuits pour héberger des pages de connexion Outlook, Google et Sophos VPN contrefaites et exfiltrer les informations d’identification capturées. Les appâts comprenaient des documents PDF légitimes et un langage spécifique à la région pour accroître la crédibilité. L’opération ciblait des entités du secteur de l’énergie, de la recherche nucléaire, du gouvernement et du milieu académique en Turquie, en Macédoine du Nord et en Ouzbékistan.

Enquête

Insikt Group de Recorded Future a collecté plus d’une douzaine de pages de phishing hébergées sur des services tels que Webhook.site, InfinityFree, Byet Internet Services et ngrok. Le JavaScript sur les pages capturait les noms d’utilisateur, les mots de passe et les identifiants des victimes, envoyait des signaux aux webhooks contrôlés par les attaquants, puis redirigeait les victimes vers des portails authentiques. Plusieurs variantes réutilisaient du code et modifiaient les noms de variables pour simplifier le déploiement. L’infrastructure était de courte durée et utilisait des raccourcisseurs de lien comme ShortURL.at.

Atténuation

Bloquez les domaines connus d’hébergement gratuit et de tunneling, surveillez le trafic sortant vers les services de webhook, et appliquez l’authentification multifacteur sur tous les comptes accessibles depuis l’extérieur. Éduquez les utilisateurs sur les pages de phishing qui imitent OWA, Google et les portails VPN, en particulier lorsque des appâts PDF sont attachés. Implémentez un filtrage réseau pour les URL malveillantes connues et appliquez des contrôles de sécurité des e-mails pour détecter les liens PDF suspects.

Réponse

Alertez les analystes SOC lorsque des POST HTTP vers des points de terminaison de webhooks connus sont observés et lorsque des pages de collecte de données d’identification sont chargées. Mettez en quarantaine la page malveillante, isolez les comptes utilisateurs affectés, forcez une réinitialisation des mots de passe et examinez les journaux pour détecter des mouvements latéraux. Effectuez une chasse aux menaces pour d’autres pages utilisant la même infrastructure et mettez à jour les listes de blocage en conséquence.

Flux d’attaque

Exécution de la simulation

Prérequis : Le contrôle préalable de télémétrie et de base doit avoir réussi.

Justification : Cette section détaille l’exécution précise de la technique de l’adversaire (TTP) conçue pour déclencher la règle de détection. Les commandes et le récit DOIVENT refléter directement les TTP identifiés et viser à générer exactement la télémétrie attendue par la logique de détection. Des exemples abstraits ou non liés entraîneront un mauvais diagnostic.

  • Narrative et commandes de l’attaque :

    1. Livraison initiale de phishing : Un attaquant envoie un e-mail de phishing contenant une URL courte qui redirige vers le site malveillant webhook.site page.
    2. Interaction de la victime : La victime clique sur le lien; le navigateur suit la redirection et envoie une requête HTTP GET demande vers https://webhook.site/e8ae3bbd-ab02-46b7-b84c-f5f4baa5d7c7.
    3. Page de capture des informations d’identification : La page héberge un JavaScript qui vole les informations d’identification saisies et les envoie en POST à la même URL de webhook, mais le proxy n’enregistre que la requête GET initiale, ce qui est suffisant pour déclencher la règle.
    4. Pour le test, nous émulons la victime en utilisant Invoke-WebRequest de PowerShell pour demander exactement l’URL malveillante, reproduisant la même entrée de journal proxy.
  • Script de test de régression :

    # -------------------------------------------------
    # Simulation d'accès au site Webhook de BlueDelta (TC-20260109-9X3BZ)
    # -------------------------------------------------
    $maliciousUrls = @(
        "https://webhook.site/e8ae3bbd-ab02-46b7-b84c-f5f4baa5d7c7",
        "https://webhook.site/3791f8c0-1308-4c5b-9c82-0dc416aeb9c4"
    )
    
    foreach ($url in $maliciousUrls) {
        try {
            Write-Host "Demande d'URL malveillante : $url"
            Invoke-WebRequest -Uri $url -UseBasicParsing -Method GET -TimeoutSec 10 | Out-Null
            Write-Host "✅ Demande envoyée."
        } catch {
            Write-Warning "La demande à $url a échoué : $_"
        }
    }
  • Commandes de nettoyage :

    # Vider le cache du proxy (le cas échéant) pour éviter les entrées résiduelles
    net stop "Squid Service"
    net start "Squid Service"
    
    # Supprimer tous les fichiers temporaires créés par le script (aucun dans ce cas)
    Write-Host "Nettoyage terminé."