Événement Windows 4625 : lire une connexion échouée

Ce qu'est le 4625

L'ID d'événement 4625 — « Échec de l'ouverture de session d'un compte » — est écrit dans le journal de sécurité Windows à chaque tentative d'authentification rejetée, quelle qu'en soit la raison : mot de passe erroné, compte inexistant, compte désactivé, connexion hors des heures autorisées. Son pendant en cas de succès est le 4624.

C'est l'événement le plus utile sur un serveur Windows exposé à internet, parce que c'est là qu'une attaque brute-force devient visible avant de réussir. Tout ce que fait une défense au niveau du pare-feu commence par la lecture de ce flux.

Si vous ne voyez aucun événement 4625 sur un serveur que vous savez exposé, c'est l'audit qui est désactivé, pas le serveur qui est calme. Vérifiez et activez :

auditpol /get /subcategory:"Logon"
auditpol /set /subcategory:"Logon" /success:enable /failure:enable

Les champs qui comptent

Un enregistrement 4625 est verbeux et l'essentiel n'est que du bruit. Cinq champs portent l'information :

• Nom du compte (sous « Compte pour lequel l'ouverture de session a échoué ») — le nom d'utilisateur essayé. Lors d'une vraie attaque, c'est un défilé de noms qui n'ont jamais existé sur votre machine.
• Adresse réseau source — l'IP d'où venait la tentative. C'est le champ sur lequel vous agissez. Il est vide pour les ouvertures de session locales sur console.
• Type de connexion — la manière dont la connexion a été tentée. 10 est RemoteInteractive (RDP), 3 est Réseau (SMB, ou RDP derrière certaines passerelles), 2 une console physique, 5 un service, 4 une tâche planifiée.
• Raison de l'échec et Statut / Sous-statut — le code hexadécimal expliquant ce qui n'allait pas. C'est là que se trouve la distinction utile.
• Nom de la station de travail — le nom d'hôte fourni par le client. Les outils d'attaque envoient souvent n'importe quoi, une chaîne aléatoire, ou laissent le champ vide, ce qui est en soi un signal.

Les codes de statut, décodés

Le champ à lire est le Sous-statut ; le Statut de premier niveau contient généralement le générique 0xC000006D. Apprenez ces cinq-là et vous classerez presque tout 4625 d'un coup d'œil :

• 0xC0000064 — le nom de compte n'existe pas. Presque toujours une attaque : vos propres utilisateurs connaissent leur identifiant.
• 0xC000006A — le compte existe mais le mot de passe était erroné. Soit un vrai utilisateur qui se trompe, soit un bot qui a deviné un identifiant valide.
• 0xC0000234 — le compte est verrouillé. Si vous en voyez des séries, votre stratégie de verrouillage est utilisée contre vous.
• 0xC0000072 — le compte est désactivé. Souvent un compte dormant qu'un attaquant a trouvé et continue d'essayer.
• 0xC000006F / 0xC0000070 — connexion hors des heures autorisées, ou depuis une station non autorisée. Rare, et à investiguer plutôt qu'à ignorer.

Distinguer une attaque d'une faute de frappe

Trois signaux les séparent, et il vous les faut tous les trois avant d'agir automatiquement.

Rythme et persistance. Une personne fait deux ou trois tentatives en une minute puis, soit elle entre, soit elle vous appelle. Un bot maintient un rythme constant pendant des heures, toute la nuit, sans pause et sans jamais appeler personne.

Diversité des comptes. Une personne essaie un compte : le sien. Un bot déroule une liste — administrator, admin, user, test, sql, backup, scan — et la plupart de ces comptes n'existent pas sur votre machine, ce qui donne précisément la signature 0xC0000064 ci-dessus.

Source. Vos collaborateurs se connectent depuis une poignée d'adresses connues. Les attaques arrivent de plages d'hébergement, depuis une adresse différente toutes les quelques centaines de tentatives, souvent depuis plusieurs pays dans la même heure.

Ceci regroupe les échecs des dernières 24 heures par adresse source et par compte, pour voir les trois signaux d'un coup :

Get-WinEvent -FilterHashtable @{LogName='Security'; Id=4625; StartTime=(Get-Date).AddDays(-1)} |
  ForEach-Object {
    $d = ([xml]$_.ToXml()).Event.EventData.Data
    [pscustomobject]@{
      IP      = ($d | Where-Object Name -eq 'IpAddress')['#text']
      Account = ($d | Where-Object Name -eq 'TargetUserName')['#text']
      Status  = ($d | Where-Object Name -eq 'SubStatus')['#text']
    }
  } |
  Group-Object IP |
  Sort-Object Count -Descending |
  Select-Object -First 15 Count, Name,
    @{n='Accounts'; e={ ($_.Group.Account | Select-Object -Unique) -join ', ' }}

De la lecture des événements à leur blocage

Lire les 4625 à la main est un diagnostic, pas une défense — au moment où vous lancez la requête, l'attaque dure depuis une semaine. Ce qui change quelque chose, c'est de le faire en continu et de traduire un seuil en règle de pare-feu.

La version naïve s'abonne au journal de sécurité, compte les échecs par source et appelle New-NetFirewallRule quand une source franchit la limite. Ça marche, puis ça rencontre les problèmes que rencontre tout script de ce genre : le jeu de règles grossit jusqu'aux milliers et le pare-feu se traîne, le journal tourne sous charge et des événements sont perdus, le script meurt silencieusement après un redémarrage, et une mauvaise correspondance coupe l'administrateur du seul accès.

RDP Protector exécute cette boucle en tant que service, avec une règle de pare-feu consolidée au lieu de milliers, une liste blanche toujours prioritaire sur un blocage, et une décision prise localement — elle tient donc quand le réseau ne tient pas. Il lit le même flux d'événements que celui montré ci-dessus ; rien ne vous est caché.