Analyser les journaux d’événements de sécurité avec PowerShell et signaler les tentatives de force brute

À mesure que les entreprises renforcent leur sécurité face aux attaques par force brute, les traces de ces tentatives passent souvent inaperçues, jusqu’à ce qu’un identifiant soit compromis ou qu’un compte soit verrouillé.

Les administrateurs informatiques peuvent utiliser PowerShell pour récupérer et analyser les journaux d’événements de sécurité afin de renforcer les défenses de leur entreprise. Ce guide détaille étape par étape la détection des attaques par force brute et la mise sur liste noire avec PowerShell.

Configurer les journaux d’événements de sécurité avec PowerShell

Avant de commencer, assurez-vous de réunir les prérequis suivants :

📌 Prérequis :

• Un accès administrateur aux systèmes locaux ou distants
• PowerShell 5.1+
• L’audit de sécurité Windows activé via une GPO
• Un accès au Registre Windows pour marquer l’état de détection
• Une plateforme RMM (NinjaOne, par exemple) pour déployer les scripts et les alertes
• Facultatif : le transfert d’événements vers un SIEM ou une journalisation centralisée

Étape 1 : activer l’audit des échecs de connexion via une stratégie de groupe

La première étape consiste à vérifier que l’audit est actif sur tous les terminaux. Vous pouvez l’activer via une stratégie de groupe. Une fois l’audit activé, les tentatives de connexion réussies comme les échecs sont enregistrés avec des ID d’événement tels que 4625 (échec de connexion) et 4624 (connexion réussie).

Pour activer l’audit des échecs de connexion :

1. Appuyez sur Win + R, saisissez gpmc.msc et appuyez sur Entrée pour ouvrir la console de gestion des stratégies de groupe.
2. Rendez-vous dans Configuration ordinateur > Stratégies > Paramètres Windows > Paramètres de sécurité > Configuration avancée de la stratégie d’audit > Stratégies d’audit > Ouverture/Fermeture de session.
3. Modifiez le paramètre Auditer l’ouverture de session sur Succès et Échec.

⚠️ Important : des paramètres d’audit de connexion incorrects peuvent provoquer des problèmes. Pour en savoir plus, consultez la section Points de vigilance.

Étape 2 : analyser les échecs de connexion avec PowerShell

1. Ouvrez PowerShell en tant qu’administrateur.
2. Utilisez les commandes suivantes :
   • Analyser l’ID d’événement 4625 sur les 24 dernières heures :

$events = Get-WinEvent -FilterHashtable @{
LogName = 'Security'
Id = 4625
StartTime = (Get-Date).AddHours(-24)
} | Select-Object TimeCreated, Message

Remarque : si aucun événement correspondant n’est trouvé, la commande renvoie un résultat vide.

• • Extraire les sources et les noms d’utilisateur des échecs de connexion :

$failedLogons = $events | ForEach-Object {

if ($_.Message -match "(?s)Account For Which Logon Failed:.*Account Name:\s+(\S+).*Source Network Address:\s+(\S+)") {

[PSCustomObject]@{

Time = $_.TimeCreated

Username = $matches[1]

SourceIP = $matches[2]

}

}

}

• • Exporter au format CSV :

$failedLogons | Export-Csv "C:\Reports\FailedLogons.csv" -NoTypeInformation

Étape 3 : repérer les schémas de force brute à partir de seuils

Dès lors que vous savez analyser les journaux d’événements, vous pouvez détecter des schémas récurrents et appliquer des seuils de force brute pour renforcer votre sécurité. Pour le mettre en place avec PowerShell, utilisez les commandes suivantes :

Regrouper et compter par IP source ou par nom d’utilisateur :

$grouped = $failedLogons | Group-Object SourceIP | Where-Object { $_.Count -ge 10 }
$grouped | ForEach-Object {
Write-Output "Potential brute-force from $($_.Name) with $($_.Count) attempts"
}

Ce script analyse les échecs de connexion sur un seul ordinateur, les regroupe par IP source et signale toute adresse IP totalisant au moins 10 tentatives infructueuses comme une possible attaque par force brute.

Remarque : le seuil défini dans cette ligne est ajustable. Vous pouvez modifier le nombre qui suit Count -ge pour définir le nombre d’échecs déclenchant une alerte de force brute.

💡 Astuce : vous pouvez également regrouper par nom d’utilisateur pour détecter les attaques par force brute ciblant un compte précis :

$groupedUsers = $failedLogons | Group-Object Username | Where-Object { $_.Count -ge 10 }

Les seuils s’ajustent selon votre tolérance au risque (par exemple, 5 tentatives ou plus en 10 minutes).

Étape 4 : écrire la détection dans le Registre et dans des journaux accessibles depuis CMD (invite de commande)

L’étape 4 consiste à relier les événements analysés au RMM et à des journaux accessibles depuis CMD (invite de commande) pour gagner en visibilité et faciliter la remédiation. Les clés suivantes vous permettent de déclencher des alertes dans NinjaOne ou de couper automatiquement l’accès réseau :

Marquage dans le Registre pour le RMM ou une inspection manuelle :

New-Item -Path "HKLM:\SOFTWARE\Org\SecurityAlerts" -Force
Set-ItemProperty -Path "HKLM:\SOFTWARE\Org\SecurityAlerts" -Name "LastBruteForceDetected" -Value (Get-Date).ToString("u")
Set-ItemProperty -Path "HKLM:\SOFTWARE\Org\SecurityAlerts" -Name "OffendingIP" -Value $grouped[0].Name

Vérification de l’état de détection depuis CMD (invite de commande) :

reg query HKLM\SOFTWARE\Org\SecurityAlerts

⚠️ Points de vigilance

Étapes suivantes : blocage d’IP ou alertes

Le blocage d’adresses IP, les alertes et les autres actions de mitigation interviennent généralement après l’analyse de vos journaux d’événements de sécurité. Cette section présente les actions possibles avec PowerShell en cas de multiples échecs de connexion ou de détection d’une attaque par force brute.

Écrire l’événement dans le journal d’événements :

Write-EventLog -LogName Application -Source "BruteForceDetector" -EventId 1010 -EntryType Warning -Message "Brute-force detected from $($grouped[0].Name)"
Remarque : si la source de l’événement n’existe pas, vous pouvez la créer une seule fois (en tant qu’administrateur) avec :

New-EventLog -LogName Application -Source ‘BruteForceDetector’

De plus, les administrateurs informatiques peuvent choisir de bloquer l’adresse IP localement (si la source est externe) :

New-NetFirewallRule -DisplayName "Block Brute IP" -Direction Inbound -RemoteAddress $grouped[0].Name -Action Block

💡 Remarque : documentez chaque blocage d’IP et chaque politique de nettoyage dans votre RMM afin d’assurer la cohérence sur l’ensemble de vos appareils.

Autres points à prendre en compte pour la détection des attaques par force brute et la mise sur liste noire avec PowerShell

Attaques locales et attaques RDP

Les journaux d’une tentative de force brute n’ont pas la même allure selon l’origine de l’attaque. Les tentatives via Remote Desktop Protocol (RDP) affichent généralement une adresse IP externe sous Source Network Address, alors qu’une attaque locale n’indique que 127.0.0.1. Le type d’ouverture de session (Logon type) peut apporter un contexte supplémentaire.

Contrôleurs de domaine

Dans les environnements Active Directory (AD), les échecs de connexion sont généralement consignés sur les contrôleurs de domaine (DC), et pas uniquement sur le poste de travail depuis lequel la connexion a été tentée. Il est recommandé d’exécuter les scripts PowerShell de façon centralisée ou via le transfert d’événements.

Faux positifs

Tous les échecs de connexion répétés ne proviennent pas d’attaques par force brute. Des comptes de service ou des outils de synchronisation peuvent occasionnellement générer des échecs de connexion. Pour rester efficace, excluez les comptes connus et sûrs de vos règles de détection (il suffit d’ajouter une liste blanche dans votre script pour que ces comptes soient ignorés automatiquement)

Intégrations SIEM

Pour les entreprises équipées d’un système SIEM (Security Information and Event Management), intégrer les données de détection de force brute améliore nettement la visibilité. Si vous en avez la possibilité, transmettez les données à un collecteur de journaux central afin de détecter les attaques dans l’ensemble de votre environnement.

Résolution des problèmes courants

Les règles de pare-feu ne s’appliquent pas

Si votre script tente de bloquer une adresse IP malveillante avec une règle de pare-feu PowerShell sans résultat, le problème peut venir des profils de pare-feu ou des autorisations du script. Les pare-feu Windows disposent de profils distincts (Domaine, Privé, Public) et la règle doit s’appliquer au bon profil. De plus, les stratégies d’exécution PowerShell ou des privilèges insuffisants peuvent empêcher la commande de s’exécuter. Exécutez toujours le script avec des droits d’administrateur et vérifiez que le pare-feu du système est actif et correctement configuré.

Les entrées de Registre ne se mettent pas à jour

Écrire les résultats de détection dans le Registre exige des autorisations adéquates, en particulier lorsque l’on cible HKLM:\SOFTWARE. Si un utilisateur standard exécute le script, les écritures dans le Registre échouent silencieusement ou renvoient une erreur d’accès. Pour éviter cela, assurez-vous que le script s’exécute dans le contexte Administrateur ou SYSTEM, ce que vous pouvez imposer lors d’un déploiement via des outils comme NinjaOne. Il est également judicieux de vérifier que la clé de Registre existe et qu’elle n’est pas verrouillée par une stratégie de groupe ou par un logiciel de sécurité des terminaux.

Renforcer la détection des attaques par force brute avec les services NinjaOne

Avec NinjaOne, les administrateurs informatiques et les MSP peuvent mettre en place une détection des attaques par force brute à grande échelle et intégrer la réponse aux incidents grâce à ces possibilités :

• déployer des scripts de détection PowerShell sur l’ensemble des appareils ou par groupe de clients ;
• surveiller des valeurs de Registre ou des fichiers de sortie pour signaler une détection ;
• déclencher des workflows de remédiation automatisés (alertes, blocage d’IP, notifications aux utilisateurs) ;
• générer des rapports multiclients présentant les tentatives de force brute et les IP sources ;
• alerter en cas de détections répétées ou de comptes ciblés.

Récupérer le journal d’événements de sécurité avec PowerShell

Analyser les journaux d’événements de sécurité avec PowerShell pour y repérer les tentatives de force brute offre aux MSP une méthode puissante et évolutive pour détecter les attaques sur les identifiants et y répondre. Ce guide propose aux administrateurs informatiques une marche à suivre détaillée ainsi qu’une aide à la résolution des problèmes les plus fréquents.

Sujets connexes :

• Comment lire les journaux d’événements Windows : arrêt et redémarrage
• Comment effacer l’historique de protection de Sécurité Windows dans Windows 11
• Comprendre les journaux Linux : vue d’ensemble et exemples
• Qu’est-ce qu’une attaque par force brute ?
• Détecter et prévenir les attaques par force brute avec PowerShell