LOLBins 2026 : détecter le living-off-the-land avec Sigma (ligne de commande, pas nom de binaire)

Un audit post-incident sur une intrusion ransomware récente montre presque toujours la même signature : aucun malware exotique, aucun binaire inconnu, seulement des outils Microsoft signés, présents nativement sur chaque poste Windows, détournés de leur usage prévu. MSBuild qui compile un fragment de code arrivé par mail. Regsvr32 qui va chercher un scriptlet sur un serveur distant. Rundll32 qui charge une DLL posée dans un dossier temporaire. C'est la technique connue sous les identifiants T1218 (System Binary Proxy Execution) et T1036 (Masquerading), et elle est aujourd'hui présente dans la quasi-totalité des chaînes d'intrusion observées avant chiffrement.

La difficulté n'est pas de savoir que ces binaires existent : elle est de les détecter sans bloquer, ni même alerter à tort, sur les usages légitimes. MSBuild tourne sur tous les postes de développement. Regsvr32 est appelé par des installeurs métier. Rundll32 est invoqué en permanence par Windows lui-même. Une règle qui déclenche sur le simple nom de ces binaires génère une tempête de faux positifs et finit désactivée en quelques jours, ce qui est pire que l'absence de règle.

Pourquoi la ligne de commande, jamais le nom du binaire

Le principe qui structure tout ce qui suit : ces exécutables sont signés Microsoft, présents par défaut, et légitimes dans l'immense majorité des contextes. Les cibler par leur Image seul revient à vouloir détecter un cambriolage en surveillant qui possède un tournevis. Ce qui distingue l'usage légitime de l'abus, c'est le contexte : les arguments passés en ligne de commande, le processus qui a lancé l'exécution, et parfois le répertoire de travail.

Un développeur qui compile son projet lance MSBuild avec un chemin vers un .csproj situé dans un répertoire de build classique, depuis un terminal ou un IDE. Un attaquant qui exécute du code inline via MSBuild passe un fichier .xml ou .csproj situé hors de tout chemin de build reconnu, et surtout, le processus parent n'est presque jamais un terminal : c'est souvent Outlook, Word, ou l'explorateur Windows, suite à l'ouverture d'une pièce jointe ou d'un raccourci.

MSBuild.exe : l'exécution .NET inline sans dropper de binaire

MSBuild accepte des tâches inline définies directement dans un fichier de projet XML. Cette fonctionnalité légitime (compiler du code au sein d'une tâche de build) devient une technique d'exécution quand l'attaquant embarque du C# arbitraire dans un fichier qui n'a jamais vocation à être un projet de build réel.

title: Exécution MSBuild suspecte depuis un parent inhabituel
id: 8f2c1a4e-3b7d-4e91-9a2f-6d5c8b1e0f3a
status: experimental
description: >
  Détecte MSBuild.exe lancé par un processus parent atypique (client mail,
  navigateur, explorateur) avec une cible hors des chemins de build connus.
logsource:
  category: process_creation
  product: windows
detection:
  selection_image:
    Image|endswith: '\MSBuild.exe'
  selection_parent_suspect:
    ParentImage|endswith:
      - '\OUTLOOK.EXE'
      - '\WINWORD.EXE'
      - '\EXCEL.EXE'
      - '\explorer.exe'
      - '\wscript.exe'
      - '\powershell.exe'
  filter_build_path:
    CommandLine|contains:
      - '\obj\'
      - '\bin\Debug\'
      - '\bin\Release\'
      - 'Program Files\dotnet\'
  condition: selection_image and selection_parent_suspect and not filter_build_path
falsepositives:
  - Scripts de build orchestrés depuis un outil d'automatisation non listé
  - CI/CD interne lançant MSBuild via un wrapper PowerShell légitime
level: high

Le filtre sur les chemins de build (filter_build_path) est ce qui sépare cette règle d'une simple alerte sur le nom du parent : sans lui, chaque intégration continue déclencherait l'alerte.

Regsvr32 et rundll32 : proxy execution classique, toujours efficace

regsvr32.exe avec l'option /i:http (ou /i:https) va chercher un scriptlet distant et l'exécute sans jamais écrire de fichier exécutable sur le disque. rundll32.exe charge une DLL passée en argument, et l'abus le plus fréquent consiste à pointer vers une DLL déposée dans %TEMP% ou %APPDATA%, deux répertoires qu'aucun composant Windows légitime n'utilise comme source de bibliothèques.

title: Regsvr32 proxy execution via scriptlet distant
id: 4d6e9f21-7a3c-4b58-9e0d-1f2a3b4c5d6e
status: experimental
logsource:
  category: process_creation
  product: windows
detection:
  selection:
    Image|endswith: '\regsvr32.exe'
    CommandLine|contains:
      - '/i:http'
      - 'scrobj.dll'
  condition: selection
falsepositives:
  - Déploiement logiciel interne utilisant un scriptlet signé et hébergé en interne
level: high
---
title: Rundll32 chargeant une DLL depuis un répertoire utilisateur
id: 1a2b3c4d-5e6f-4708-9a0b-1c2d3e4f5a6b
status: experimental
logsource:
  category: process_creation
  product: windows
detection:
  selection_image:
    Image|endswith: '\rundll32.exe'
  selection_path:
    CommandLine|contains:
      - '\AppData\Local\Temp\'
      - '\AppData\Roaming\'
      - '\Users\Public\'
  condition: selection_image and selection_path
falsepositives:
  - Applications tierces packagées qui installent leurs DLL dans le profil utilisateur
level: medium

Le signal fort : suppression des shadow copies avant chiffrement

Contrairement aux deux techniques précédentes, la suppression des sauvegardes locales n'est presque jamais légitime en dehors d'une opération de maintenance planifiée et documentée. Voir vssadmin delete shadows, wmic shadowcopy delete ou wbadmin delete catalog sur un poste utilisateur ou un serveur applicatif hors fenêtre de maintenance est un signal d'imminence de chiffrement, à traiter comme une alerte critique, pas comme un indicateur parmi d'autres.

title: Suppression des shadow copies, signal pré-ransomware
id: 9c8b7a6d-5e4f-4321-8a9b-0c1d2e3f4a5b
status: stable
logsource:
  category: process_creation
  product: windows
detection:
  selection_vssadmin:
    Image|endswith: '\vssadmin.exe'
    CommandLine|contains:
      - 'delete shadows'
      - 'resize shadowstorage'
  selection_wmic:
    Image|endswith: '\WMIC.exe'
    CommandLine|contains: 'shadowcopy delete'
  selection_wbadmin:
    Image|endswith: '\wbadmin.exe'
    CommandLine|contains:
      - 'delete catalog'
      - 'delete backup'
  condition: 1 of selection_*
falsepositives:
  - Script de maintenance planifiée sur compte de service identifié
level: critical

Ici, l'exclusion se fait par compte de service et fenêtre horaire documentée, jamais par désactivation de la règle. C'est la nuance qui distingue une équipe qui maîtrise ses faux positifs d'une équipe qui a simplement éteint la détection.

Anti-FP : baseliner, exclure, ne jamais désactiver

La tentation face à un faux positif récurrent est de couper la règle. C'est l'erreur qui rouvre l'angle mort. La bonne discipline est en trois temps :

1. Baseliner les usages admin légitimes : scripts de sauvegarde planifiés, orchestration CI/CD, déploiements logiciels internes. Chaque cas doit être identifié nommément, pas supposé.
2. Exclure par chemin ou par compte, jamais par désactivation globale : un filtre sur le compte de service de la sauvegarde ou sur le chemin du script de build légitime referme le faux positif sans rouvrir la fenêtre d'attaque.
3. Documenter l'exclusion avec sa justification et sa date, pour qu'elle soit revue plutôt qu'oubliée quand l'environnement change.

Le moteur : ce qu'il faut activer avant que la règle serve à quelque chose

Ces règles reposent sur Sysmon Event ID 1 (Process Creation) et exploitent trois champs : CommandLine, ParentImage, CurrentDirectory. Sans configuration adéquate, ces champs sont vides ou absents et la règle ne détecte rien, silencieusement.

# Vérifier que l'audit de création de processus est actif
auditpol /get /subcategory:"Process Creation"
 
# Vérifier que la ligne de commande est bien incluse dans les logs (registre)
reg query "HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System\Audit" /v ProcessCreationIncludeCmdLine_Enabled

Deux prérequis non négociables : l'audit "Process Creation" doit être actif dans la stratégie de groupe, et l'option "Include command line in process creation events" doit être activée. Sans cela, Sysmon reçoit bien l'événement mais le champ CommandLine reste vide, et toutes les règles ci-dessus deviennent muettes sans jamais remonter d'erreur visible.

Avant / après : la même intrusion, deux résultats

Avant (règle sur le nom du binaire seul) :

detection:
  selection:
    Image|endswith: '\regsvr32.exe'
  condition: selection

Cette règle déclenche à chaque appel de regsvr32, y compris ceux issus d'installeurs logiciels légitimes plusieurs fois par jour sur un parc de quelques centaines de postes. Résultat : des dizaines d'alertes quotidiennes, aucune priorisée, et la règle désactivée en moins d'une semaine par l'équipe qui ne peut plus les traiter.

Après (CommandLine + contexte) : la règle présentée plus haut, limitée à /i:http et scrobj.dll, ne déclenche que sur le schéma de proxy execution réel. Sur un corpus de test de plusieurs semaines de logs d'un parc de production, elle ne produit aucune alerte sur les usages admin recensés, et détecte correctement l'appel distant lors d'un test de simulation d'intrusion.

En résumé

La détection du living-off-the-land ne se joue pas sur la liste des binaires à surveiller (elle est publique, connue, et surveillée par tous), mais sur la discipline à détecter le contexte d'exécution : ligne de commande complète, processus parent, chemin de la cible. C'est ce travail de baseline et d'exclusion documentée, pas la désactivation, qui permet de garder ces règles actives sur la durée sans épuiser l'équipe qui les exploite.

C'est exactement la discipline appliquée dans le feed Sigma ThreatClaw : chaque règle LOLBins est construite sur CommandLine et ParentImage, testée sur un corpus d'usages admin légitimes avant publication, et livrée avec ses conditions d'exclusion documentées plutôt qu'un simple nom de binaire à bannir.