15 requêtes Splunk (SPL) pour détecter les attaques courantes

On trouve en ligne des centaines de requêtes Splunk de détection, presque toutes en anglais et rarement expliquées. Nous avons choisi les quinze que nous utilisons le plus souvent pour repérer les attaques qu'on rencontre réellement dans les entreprises françaises : force brute, prise de contrôle de comptes, persistance, vol d'identifiants dans Active Directory et préparation d'un ransomware.

Pour chaque requête, nous indiquons la technique MITRE ATT&CK correspondante, ce qu'elle détecte, et comment l'ajuster pour éviter les fausses alertes.

Avant de commencer : les journaux nécessaires

Une requête ne trouve que ce qui a été collecté. Ces exemples supposent trois choses. Les journaux Windows (Sécurité et Système) sont collectés avec le Splunk Add-on for Microsoft Windows. Sysmon est installé sur les postes et les serveurs, avec une configuration reconnue comme sysmon-modular ou celle de SwiftOnSecurity. Et les stratégies d'audit Windows sont activées pour les événements utilisés, en particulier l'audit des tickets de service Kerberos et l'accès au service d'annuaire sur les contrôleurs de domaine.

Dans nos exemples, les journaux Windows sont dans l'index wineventlog et Sysmon dans l'index sysmon : remplacez-les par vos propres noms d'index. Nous utilisons les noms de champs du format XML (TargetUserName, IpAddress, LogonType), qui est le format par défaut des versions récentes de l'add-on. Si vous collectez au format texte classique, les champs s'appellent par exemple Account_Name ou Source_Network_Address.

Comptes et connexions

1. Force brute sur un compte (T1110.001)
Beaucoup d'échecs de connexion sur un même compte depuis une même adresse, en peu de temps. Le seuil de 10 échecs en 5 minutes convient à la plupart des PME ; relevez-le si un logiciel métier se trompe régulièrement de mot de passe.

index=wineventlog EventCode=4625
| bin _time span=5m
| stats count AS echecs BY _time, TargetUserName, IpAddress, host
| where echecs >= 10
| sort - echecs

2. Pulvérisation de mots de passe (T1110.003)
L'attaquant essaie un ou deux mots de passe courants sur un grand nombre de comptes, pour passer sous les seuils de verrouillage. On cherche donc une même source qui échoue sur beaucoup de comptes différents.

index=wineventlog EventCode=4625
| bin _time span=10m
| stats dc(TargetUserName) AS comptes_vises values(TargetUserName) AS comptes BY _time, IpAddress
| where comptes_vises >= 10

3. Connexion réussie après une série d'échecs (T1110)
C'est la suite logique des deux précédentes, et la plus importante : l'attaquant a trouvé le mot de passe. Toute alerte de ce type mérite une vérification immédiate auprès de l'utilisateur.

index=wineventlog (EventCode=4625 OR EventCode=4624)
| bin _time span=15m
| stats count(eval(EventCode=4625)) AS echecs count(eval(EventCode=4624)) AS succes BY _time, TargetUserName, IpAddress
| where echecs >= 10 AND succes >= 1

4. Connexion bureau à distance depuis Internet (T1021.001, T1133)
Une session RDP (type de connexion 10) ouverte depuis une adresse publique. Dans une PME, un RDP exposé directement sur Internet est l'une des premières portes d'entrée des ransomwares. Si cette requête renvoie quelque chose, la question n'est pas seulement « qui s'est connecté ? », mais aussi « pourquoi ce port est-il ouvert ? ».

index=wineventlog EventCode=4624 LogonType=10
| where NOT (cidrmatch("10.0.0.0/8", IpAddress) OR cidrmatch("172.16.0.0/12", IpAddress) OR cidrmatch("192.168.0.0/16", IpAddress) OR IpAddress="127.0.0.1" OR IpAddress="-")
| iplocation IpAddress
| table _time, host, TargetUserName, IpAddress, Country, City

Persistance et privilèges

5. Ajout d'un membre à un groupe d'administrateurs (T1098)
Un attaquant qui a pris pied dans le réseau cherche presque toujours à s'ajouter, ou à ajouter un compte qu'il contrôle, dans un groupe privilégié. Pensez à indiquer les noms français et anglais des groupes : ils dépendent de la langue d'installation de vos serveurs.

index=wineventlog EventCode IN (4728, 4732, 4756)
TargetUserName IN ("Admins du domaine", "Domain Admins", "Administrateurs", "Administrators", "Administrateurs de l'entreprise", "Enterprise Admins")
| table _time, host, SubjectUserName, MemberName, TargetUserName

6. Création d'un compte utilisateur (T1136)
Dans une PME, les créations de comptes sont rares et passent par une ou deux personnes. Cette requête liste toutes les créations avec leur auteur ; ajoutez un filtre sur les heures de bureau si vous voulez n'être alerté que pour les créations inhabituelles.

index=wineventlog EventCode=4720
| eval heure=tonumber(strftime(_time, "%H"))
| eval hors_horaires=if(heure < 7 OR heure >= 20, "oui", "non")
| table _time, host, SubjectUserName, TargetUserName, hors_horaires

7. Installation d'un nouveau service suspect (T1543.003)
Les attaquants et beaucoup d'outils de déplacement latéral, comme PsExec, installent un service pour exécuter leur code. Cette requête ne garde que les services lancés depuis des emplacements inhabituels ou via un interpréteur de commandes.

index=wineventlog EventCode=7045
(ImagePath="*Temp*" OR ImagePath="*AppData*" OR ImagePath="*ProgramData*" OR ImagePath="*Users*" OR ImagePath="*powershell*" OR ImagePath="*cmd.exe*")
| table _time, host, ServiceName, ImagePath, AccountName

8. Tâche planifiée qui lance un script (T1053.005)
Une tâche planifiée créée pour lancer PowerShell, un script ou un fichier téléchargé est un mécanisme de persistance très courant. L'événement 4698 nécessite l'audit des « autres événements d'objet » dans la stratégie d'audit avancée.

index=wineventlog EventCode=4698
(TaskContent="*powershell*" OR TaskContent="*cmd.exe*" OR TaskContent="*wscript*" OR TaskContent="*mshta*" OR TaskContent="*http*")
| table _time, host, SubjectUserName, TaskName

9. Effacement des journaux d'événements (T1070.001)
Effacer le journal de sécurité, c'est effacer ses traces. Cet événement n'a pratiquement aucune raison légitime de se produire en production : il mérite une alerte à chaque occurrence.

index=wineventlog (EventCode=1102 OR (EventCode=104 source="*System*"))
| table _time, host, EventCode, SubjectUserName

Exécution de code malveillant

10. PowerShell avec une commande encodée (T1059.001, T1027)
Les attaquants encodent souvent leurs commandes PowerShell en Base64 pour les rendre illisibles. Certains outils d'administration légitimes le font aussi : identifiez-les dans les résultats et excluez-les par leur processus parent.

index=sysmon EventCode=1 (Image="*\\powershell.exe" OR Image="*\\pwsh.exe")
(CommandLine="* -enc*" OR CommandLine="* -e *" OR CommandLine="*-EncodedCommand*" OR CommandLine="*FromBase64String*")
| table _time, host, User, ParentImage, CommandLine

11. Word, Excel ou Outlook qui lance un interpréteur de commandes (T1566.001, T1204.002)
C'est la signature classique d'une pièce jointe piégée : un document Office qui, une fois ouvert, lance PowerShell, cmd ou un script. En usage normal, ces applications n'ont presque jamais de raison de le faire.

index=sysmon EventCode=1
ParentImage IN ("*\\winword.exe", "*\\excel.exe", "*\\powerpnt.exe", "*\\outlook.exe")
Image IN ("*\\cmd.exe", "*\\powershell.exe", "*\\pwsh.exe", "*\\wscript.exe", "*\\cscript.exe", "*\\mshta.exe", "*\\rundll32.exe", "*\\regsvr32.exe")
| table _time, host, User, ParentImage, Image, CommandLine

Vol d'identifiants et Active Directory

12. Accès à la mémoire de LSASS (T1003.001)
Le processus LSASS garde en mémoire les identifiants des utilisateurs connectés. Des outils comme Mimikatz le lisent pour les récupérer. Cette détection suppose que votre configuration Sysmon journalise les accès au processus lsass.exe, ce que ne font pas toutes les configurations. Excluez ensuite votre antivirus ou votre EDR, qui y accède légitimement.

index=sysmon EventCode=10 TargetImage="*\\lsass.exe"
GrantedAccess IN ("0x1010", "0x1410", "0x1438", "0x143a", "0x1fffff")
NOT SourceImage IN ("*\\MsMpEng.exe", "*\\csrss.exe", "*\\wininit.exe")
| stats count BY host, SourceImage, GrantedAccess

13. Kerberoasting (T1558.003)
L'attaquant demande des tickets Kerberos pour des comptes de service, puis tente de casser leur mot de passe hors ligne. On repère un même compte qui demande en peu de temps des tickets chiffrés en RC4 (type 0x17) pour plusieurs services. Si votre domaine n'utilise plus du tout RC4, une seule demande de ce type est déjà suspecte.

index=wineventlog EventCode=4769 TicketEncryptionType=0x17
ServiceName!="*$" ServiceName!="krbtgt"
| bin _time span=1h
| stats dc(ServiceName) AS nb_services values(ServiceName) AS services BY _time, TargetUserName, IpAddress
| where nb_services >= 3

14. DCSync : un compte qui se fait passer pour un contrôleur de domaine (T1003.006)
Avec l'attaque DCSync, un attaquant qui a obtenu certains droits demande au contrôleur de domaine de lui envoyer les empreintes de mots de passe de tous les comptes, comme le ferait un autre contrôleur lors d'une réplication. Seuls les contrôleurs de domaine, dont les comptes machine se terminent par $, devraient faire ces demandes. Il faut avoir activé l'audit de l'accès au service d'annuaire, avec une liste de contrôle d'audit sur la racine du domaine.

index=wineventlog EventCode=4662
(Properties="*1131f6aa-9c07-11d1-f79f-00c04fc2dcd2*" OR Properties="*1131f6ad-9c07-11d1-f79f-00c04fc2dcd2*" OR Properties="*89e95b76-444d-4c62-991a-0facbeda640c*")
SubjectUserName!="*$"
| table _time, host, SubjectUserName, SubjectDomainName

Préparation d'un ransomware

15. Suppression des clichés instantanés et des sauvegardes (T1490)
Juste avant de chiffrer les fichiers, la plupart des ransomwares suppriment les clichés instantanés Windows et désactivent la récupération du système, pour empêcher la restauration. C'est l'une des détections les plus fiables qui existent : si elle se déclenche, il faut agir dans les minutes qui suivent. Notre article sur les premières heures d'une attaque par ransomware détaille la marche à suivre.

index=sysmon EventCode=1
((Image="*\\vssadmin.exe" CommandLine="*delete*shadows*")
 OR (Image="*\\wmic.exe" CommandLine="*shadowcopy*delete*")
 OR (Image="*\\bcdedit.exe" CommandLine="*recoveryenabled*no*")
 OR (Image="*\\wbadmin.exe" CommandLine="*delete*catalog*")
 OR (CommandLine="*Win32_ShadowCopy*" CommandLine="*Delete*"))
| table _time, host, User, ParentImage, Image, CommandLine

Transformer ces requêtes en alertes

Une fois une requête testée, enregistrez-la comme alerte avec « Enregistrer sous » puis « Alerte ». Programmez-la toutes les 15 minutes sur les 15 dernières minutes, et activez la limitation (throttling) sur les champs clés, par exemple le compte et la machine, pour ne pas recevoir la même alerte cinquante fois. Les détections 9, 11, 14 et 15 peuvent déclencher une notification immédiate ; les autres sont plutôt à regrouper dans un rapport quotidien tant que vous n'avez pas fini de les ajuster.

Si vous utilisez Splunk Enterprise Security, la plupart de ces détections existent déjà sous une forme plus complète dans le contenu de sécurité fourni par Splunk, basé sur les modèles de données CIM et la commande tstats, beaucoup plus rapide sur de gros volumes. Nos versions restent utiles pour comprendre la logique de chaque détection et pour les environnements sans Enterprise Security.

Questions fréquentes

Ces requêtes fonctionnent-elles avec Splunk Free ?
Vous pouvez les lancer manuellement dans Splunk Free pour vous entraîner, mais la version gratuite ne permet pas de les transformer en alertes, et elle est limitée à 500 Mo de données par jour. Pour une surveillance réelle, il faut une licence payante.

Pourquoi mes requêtes ne renvoient-elles aucun résultat ?
Dans la grande majorité des cas, l'événement n'est pas collecté : stratégie d'audit Windows non activée, Sysmon absent ou mal configuré, ou nom d'index différent. Vérifiez d'abord que l'événement existe avec une recherche simple comme index=* EventCode=4769, puis ajoutez les filtres.

Peut-on faire les mêmes détections avec Wazuh ?
Oui. Wazuh intègre déjà des règles pour la plupart de ces techniques, et les autres peuvent être ajoutées sous forme de règles personnalisées. Notre comparatif Splunk ou Wazuh : quel SIEM pour une PME ? explique quand choisir l'un ou l'autre.

Quelle est la différence entre ces requêtes et MITRE ATT&CK ?
MITRE ATT&CK est un référentiel qui classe les techniques utilisées par les attaquants. Relier chaque requête à une technique permet de savoir quelles parties du référentiel vous couvrez déjà, et lesquelles restent sans détection.

Écrire des détections est une chose, les surveiller jour et nuit en est une autre. Si vous n'avez pas d'équipe pour ça, notre service MDR 24/7 s'en charge. Et pour tester ce que vos détections voient vraiment, rien ne vaut un test d'intrusion suivi d'une revue des alertes déclenchées.