Evil-WinRM

Définition

Evil-WinRM est un shell interactif open source, écrit en Ruby, qui exploite le protocole WinRM (Windows Remote Management) pour obtenir un accès distant en ligne de commande sur une machine Windows. Développé par l'équipe Hackplayers, il s'est imposé comme l'outil de référence des phases de post-exploitation lors des audits d'environnements Active Directory : une fois des identifiants valides obtenus, il transforme un service d'administration légitime en canal de contrôle complet.

Contrairement à un implant malveillant déposé sur le disque, Evil-WinRM n'installe rien sur la cible. Il utilise un service natif activé par défaut sur les serveurs Windows depuis 2012, ce qui en fait un parfait exemple de technique Living off the Land — l'attaquant se fond dans le trafic d'administration normal.

Fonctionnement technique

WinRM est l'implémentation Microsoft du standard WS-Management, un protocole SOAP encapsulé dans HTTP. Il écoute sur deux ports :

• 5985/tcp — WinRM sur HTTP (chiffrement applicatif via NTLM/Kerberos, mais pas TLS)
• 5986/tcp — WinRM sur HTTPS, avec certificat X.509

L'accès n'est pas réservé aux administrateurs : tout compte membre du groupe local Remote Management Users peut ouvrir une session. C'est précisément ce détail que les auditeurs recherchent, car ce groupe est souvent peuplé de comptes de service ou d'équipes d'exploitation aux privilèges mal maîtrisés.

Côté serveur, chaque connexion déclenche la création d'un processus wsmprovhost.exe, hôte du runspace PowerShell distant. Ce processus est l'artefact de détection le plus fiable : toute commande lancée par l'attaquant apparaît comme un enfant de wsmprovhost.exe.

Exemples concrets d'utilisation

Connexion classique avec mot de passe en clair :

• evil-winrm -i 10.10.10.5 -u svc_backup -p 'P@ssw0rd!'

Authentification par Pass-the-Hash, sans jamais connaître le mot de passe — le hash NTLM extrait de la mémoire LSASS suffit :

• evil-winrm -i 10.10.10.5 -u administrateur -H 5e884898da280471...

Session Kerberos (Pass-the-Ticket) après import d'un ticket dans le cache :

• evil-winrm -i dc01.corp.local -r CORP.LOCAL

Une fois le shell obtenu, Evil-WinRM fournit des commandes intégrées qui dépassent largement PowerShell Remoting standard :

• upload / download — transfert de fichiers bidirectionnel intégré au canal WinRM
• services — énumération des services et de leurs permissions, pour repérer une escalade de privilèges
• Invoke-Binary — exécution d'un binaire .NET directement en mémoire, sans écriture disque
• Dll-Loader et Donut-Loader — chargement réflexif de DLL et de shellcode
• Bypass-4MSI — neutralisation en mémoire de l'interface AMSI pour faire passer des scripts détectés

Le paramètre -s /chemin/scripts permet de monter un répertoire local de scripts PowerShell (PowerView, PowerUp, Invoke-Mimikatz) chargeables à la volée dans la session distante.

Liens avec les autres concepts cyber

Evil-WinRM n'est jamais un point de départ : c'est un maillon dans une chaîne d'attaque Active Directory.

• Amont — les identifiants proviennent typiquement d'un Kerberoasting, d'un AS-REP Roasting, d'un dump NTDS.dit, d'un relais NTLM ou d'une extraction LSASS.
• Cartographie — BloodHound expose l'arête CanPSRemote, qui identifie précisément quels comptes peuvent atteindre quelles machines via WinRM.
• Alternatives — NetExec (ex-CrackMapExec) avec le protocole winrm, Impacket (wmiexec.py, psexec.py), ou Enter-PSSession natif.
• Aval — mouvement latéral, escalade vers Domain Admin, persistance, exfiltration.
• Cadre MITRE ATT&CK — technique T1021.006 « Remote Services: Windows Remote Management ».

Détection et bonnes pratiques défensives

Côté détection, plusieurs signaux sont à corréler dans le SIEM :

• Journal Microsoft-Windows-WinRM/Operational : événements 91 (création de session) et 168
• Journal Sécurité : 4624 avec type d'ouverture 3 et processus winrm
• Script Block Logging PowerShell : événements 4103 et 4104, révélant le code réellement exécuté
• Toute génération de processus enfant inhabituel par wsmprovhost.exe
• Connexions entrantes sur 5985 depuis des postes bureautiques — un poste utilisateur n'a aucune raison d'administrer un serveur

Côté durcissement, les mesures prioritaires sont :

• Désactiver WinRM sur les machines qui n'en ont pas l'usage, et n'autoriser que 5986 (HTTPS) ailleurs
• Auditer et purger le groupe Remote Management Users
• Déployer JEA (Just Enough Administration) pour restreindre les cmdlets accessibles en session distante
• Filtrer les flux WinRM par pare-feu selon un modèle de tiering : seuls les postes d'administration sécurisés (PAW) atteignent les serveurs et contrôleurs de domaine
• Activer LSA Protection, Credential Guard et le compte Protected Users pour couper l'approvisionnement en hashes réutilisables
• Généraliser LAPS afin d'éliminer les mots de passe administrateur local identiques sur tout le parc

Evil-WinRM illustre une réalité structurante de la sécurité Windows : le problème n'est pas l'outil, mais la surface d'administration ouverte et les identifiants réutilisables qu'il exploite. Réduire l'un et l'autre neutralise la technique bien plus efficacement qu'une signature antivirus.