NovaCookies : Le phishing comme service qui dévaste la sécurité Microsoft 365

Le paysage de la cybersécurité B2B subit une mutation alarmante avec l'émergence de kits de phishing sophistiqués vendus sur le marché noir. Parmi eux, NovaCookies se distingue en offrant une capacité d'interception de sessions Microsoft 365 pour une modique somme mensuelle, contournant ainsi les défenses traditionnelles basées sur les mots de passe.

En bref

• Interception de session (AitM) : NovaCookies ne vole pas seulement les identifiants, il capture les jetons d'authentification (cookies) actifs, permettant un accès direct sans ré-authentification.
• Modèle SaaS criminel : Le kit est loué pour 320 $/mois, démocratisant l'accès à des techniques autrefois réservées aux groupes étatiques ou aux APTs.
• Contournement du MFA : En réutilisant la session existante de la victime, l'attaquant évite la friction de la vérification multifacteur.
• Cible principale : Les environnements Microsoft 365 (Exchange Online, Teams, SharePoint) où les jetons de session sont persistants.
• Défi pour les DSI : La détection basée sur la géolocalisation ou l'IP seule devient insuffisante face à un accès légitime "volé".

Le mécanisme d'attaque : Au-delà du simple vol de mot de passe

Traditionnellement, un kit de phishing (comme Evilginx ou ses variantes) force l'utilisateur à saisir ses identifiants dans une fausse page de connexion. L'attaquant peut alors capturer le mot de passe. Cependant, avec la généralisation du Multi-Factor Authentication (MFA), le mot de passe seul est insuffisant pour accéder au compte.

NovaCookies opère selon le modèle Adversary-in-the-Middle (AitM). Le processus est le suivant :

1. Redirection : La victime reçoit un e-mail de phishing (souvent un faux rappel de facture, de sécurité ou de collègue).
2. Proxy transparent : L'utilisateur est redirigé vers un serveur contrôlé par l'attaquant. Ce serveur se place entre l'utilisateur et le vrai portail Microsoft (login.microsoftonline.com).
3. Interception des jetons : Lorsque l'utilisateur s'authentifie (en saisissant son mot de passe et en validant son MFA), le serveur proxy capture non seulement les identifiants, mais surtout les cookies de session (comme XSRF-TOKEN, FPC, ou les jetons OAuth spécifiques à l'application).
4. Réutilisation immédiate : L'attaquant utilise ces cookies pour ouvrir sa propre session. Pour Microsoft 365, cette session est considérée comme "déjà authentifiée". Le MFA n'est pas requis car la preuve d'identité a déjà été fournie par la victime via le proxy.

La différence cruciale avec un simple vol de mot de passe est que l'attaquant n'a pas besoin de résoudre le défi MFA. Il hérite de la confiance accordée par le navigateur de la victime.

Pourquoi 320 $/mois est une menace systémique

Le prix de 320 $ mensuels pour un kit complet d'interception de session est un signal d'alarme majeur pour les consultants IT et les CISOs. Voici pourquoi ce modèle économique est dangereux :

1. La baisse de la barrière à l'entrée

Auparavant, la construction d'un infrastructure AitM robuste (certificats TLS valides, proxy haute performance, rotation d'IP) exigeait des compétences en développement web, en réseau et en cryptographie. Aujourd'hui, un script kiddie ou un groupe de ransomware junior peut louer cette capacité. Cela transforme le phishing avancé en un "outil de productivité" criminel.

2. L'automatisation des campagnes

Pour ce prix, NovaCookies fournit généralement :

• Un tableau de bord centralisé pour surveiller les captures.
• Des templates de phishing prêts à l'emploi.
• Une infrastructure d'envoi d'e-mails (ou des instructions pour l'intégrer à des outils d'envoi en masse).
• La gestion des certificats SSL pour éviter les avertissements navigateur.

3. La durabilité des accès

Les mots de passe sont souvent changés après une violation. Les sessions, elles, peuvent durer des heures ou des jours selon la configuration. Si l'attaquant capture le cookie de session, il peut continuer à accéder aux données même si la victime change son mot de passe, tant que la session n'est pas révoquée côté serveur.

Détection et analyse forensique : Ce que les logs disent (et ne disent pas)

En tant que consultants, nous devons savoir comment identifier ces attaques dans les journaux. La difficulté réside dans le fait que l'accès semble légitime.

Signaux d'alerte dans Microsoft 365 (AuditLogs)

L'analyse des journaux d'audit Unified (via PowerShell ou le portail Microsoft 365 Compliance) permet de repérer des anomalies :

1. Divergence IP/Session :

   • L'utilisateur se connecte depuis son IP habituelle (ex: 192.168.1.50).
   • Quelques minutes plus tard, une activité est détectée depuis une IP différente (ex: un VPS en Roumanie), mais le CorrelationId ou les détails de la session indiquent qu'il s'agit de la même session initiale.
   • Note : Dans un cas AitM classique, l'attaquant utilise les cookies de la victime. Si le kit est bien conçu, il peut mimer les headers du navigateur. Cependant, les métadonnées de la session (User-Agent, Timezone) peuvent révéler une incohérence.

2. Accès à des ressources inhabituelles :

   • Un utilisateur du marketing qui accède soudainement aux boîtes mail de l'administrateur système ou aux fichiers financiers via SharePoint/OneDrive.
   • Recherche massive de mots-clés sensibles (salaires, clients, M&A) dans Exchange Online.

3. Échecs de connexion précédés de succès :

   • Souvent, l'attaquant tente de valider ses identifiants capturés. Si le MFA bloque, on verra des erreurs InvalidCredential ou MfaRequired. Si l'attaque est un vol de session pur, on n'a pas d'échec de mot de passe, mais un accès direct.

Exemple de commande PowerShell pour l'audit

Voici un script PowerShell pour extraire les événements de connexion suspects sur les 30 derniers jours :

# Connectez-vous à Microsoft Graph ou Exchange Online
Connect-ExchangeOnline -UserPrincipalName "admin@domain.com"

# Récupérer les événements d'audit de connexion
Get-UnifiedAuditLog -Operations "UserLogin", "AccessedSharedMailbox" -Start (Get-Date).AddDays(-30) -ResultSize 5000 | 
Select-Object CreationTime, UserPrincipal, ClientIP, Operation, Result, Details | 
Sort-Object CreationTime -Descending | 
Format-Table -AutoSize

# Filtrer spécifiquement les accès où l'IP change rapidement pour le même utilisateur
# (Indice potentiel d'interception de session ou de relais)
$logs = Get-UnifiedAuditLog -Operations "UserLogin" -Start (Get-Date).AddDays(-7) -ResultSize 5000
$logs | Group-Object UserPrincipal | ForEach-Object {
    $userLogs = $_.Group
    if ($userLogs.Count -gt 1) {
        $ips = $userLogs | Select-Object -ExpandProperty ClientIP -Unique
        if ($ips.Count -gt 1) {
            Write-Host "ALERTE: Multi-IP pour $($_.Name) : $($ips -join ', ')" -ForegroundColor Yellow
        }
    }
}

Stratégies de mitigation pour les consultants IT

Face à une menace qui contourne le MFA par le vol de session, les défenses périmétriques classiques ne suffisent plus. Voici les actions concrètes à proposer à vos clients.

1. Implémenter la Conditional Access "Strict" (Microsoft Entra ID)

C'est la défense la plus efficace contre le vol de session. La Conditional Access peut exiger une ré-authentification continue ou restreindre l'accès basé sur la confiance du signal.

• Exiger la ré-authentification : Configurer une politique qui force la ré-authentification si l'accès est fait depuis un appareil non managé ou une IP inconnue, même si une session est active.
• Signal de confiance (Trust Signals) : Utiliser les signaux de Microsoft (App Identity, Browser Identity) pour valider que l'accès provient bien de l'application légitime et non d'un proxy.
• Session Lifetime : Réduire la durée de vie des jetons de session. Par défaut, les cookies de session Microsoft peuvent durer longtemps. Une politique de Conditional Access peut forcer la ré-authentification toutes les 2 heures, par exemple.

2. Adopter les certificats pour appareils (Device-Based Authentication)

Le vol de session cible les identifiants utilisateur. Si vous basculez sur une authentification basée sur l'appareil (via des certificats TPM), l'attaquant doit posséder physiquement le matériel de l'utilisateur.

• Déployer Intune pour gérer les certificats.
• Configurer l'authentification Windows Hello pour Business.
• Exiger l'attestation de l'appareil (Intune Attestation) dans Conditional Access.

3. Détection par l'analyse du trafic réseau (Zscaler, Palo Alto, Fortinet)

Les kits comme NovaCookies doivent utiliser des certificats TLS. Bien qu'ils soient souvent valides (issus de Let's Encrypt ou d'autres CAs publics), le comportement du trafic peut être suspect.

• Inspection TLS : Activez l'inspection TLS sur les proxys web pour les flux sortants vers les domaines de phishing connus ou les domaines génériques utilisés par les kits.
• Détection d'anomalies de comportement : Surveiller les requêtes HTTP anormales (ex: un navigateur qui envoie des requêtes API Exchange avec un User-Agent incohérent avec le système d'exploitation détecté).

4. Éducation des utilisateurs : Reconnaître le AitM

Les utilisateurs doivent être formés à identifier les signes d'un proxy AitM :

• Barre d'adresse : Même avec un certificat valide, le domaine affiché dans la barre d'adresse est souvent différent de login.microsoftonline.com (ex: secure-login-microsoft.com).
• Vérification de la page : Demander aux utilisateurs de vérifier le domaine exact avant de saisir leurs identifiants.
• Alertes de sécurité : Microsoft envoie des e-mails d'alerte de connexion suspecte. Former les utilisateurs à répondre immédiatement à ces e-mails en changeant de mot de passe et en révoquant les sessions.

Bonnes pratiques pour consultants IT

1. Audit des politiques Conditional Access : Vérifiez que vous n'avez pas de politique "Allow" trop large qui ignore les signaux de risque. Utilisez le mode "Report" pour tester les nouvelles règles avant de les activer.
2. Révocation proactive des sessions : Mettez en place une procédure d'urgence pour révoquer toutes les sessions d'un utilisateur en cas de suspicion d'attaque.

   # Révoquer toutes les sessions d'un utilisateur spécifique
   Revoke-UserSession -UserPrincipalName "victim@domain.com"
   

3. Intégration SIEM : Assurez-vous que vos alertes Microsoft 365 sont envoyées à votre SIEM (Splunk, Sentinel, etc.) avec un seuil d'alerte bas pour les anomalies de connexion.
4. Tests de pénétration AitM : Demandez à votre équipe de sécurité (ou à un tiers) de simuler une attaque AitM pour tester la capacité de détection de votre infrastructure. Ne testez jamais en production sans accord écrit.
5. Documentation des incidents : En cas d'attaque, documentez la chaîne de compromission. Identifiez quel utilisateur a été ciblé, quel kit a été utilisé (si possible, via les headers HTTP capturés) et quelles données ont été exfiltrées.

Points cles

• NovaCookies n'est pas un cas isolé : C'est un exemple de la tendance "Cybercrime as a Service". D'autres kits (Evilginx, ScamLink) existent et évoluent constamment.
• Le MFA ne suffit plus : Il doit être combiné avec des politiques de Conditional Access strictes et une authentification basée sur l'appareil.
• La détection est complexe : L'attaque ressemble à un accès légitime. La vigilance sur les anomalies de comportement (IP, User-Agent, horaire) est cruciale.
• L'action est immédiate : Si vous suspectez un vol de session, révoquez les sessions, changez les mots de passe, et enquêtez sur les accès aux ressources sensibles.
• L'éducation continue : Les utilisateurs sont la première ligne de défense, mais aussi la cible principale. La formation doit être technique et contextuelle.

En conclusion, l'arrivée de kits comme NovaCookies sur le marché noir à des prix accessibles signifie que chaque entreprise Microsoft 365 est potentiellement une cible. Les consultants IT doivent repenser leurs stratégies de sécurité en intégrant la protection contre le vol de session comme une priorité absolue, au-delà de la simple gestion des mots de passe et du MFA. La résilience face à ces attaques repose sur une approche en couches : authentification forte, détection comportementale, et réaction rapide.

Source : Dark Reading