Activity) Writing Sigma Rules

Dans cette activité, vous allez examiner certaines Sigma règles et rédiger les vôtres en modifiant une règle prédéfinie. Le but de cette activité est de vous familiariser avec un format de détection indépendant du fournisseur qui peut être appliqué aux principaux fournisseurs de SIEM, mais également de développer votre capacité à réfléchir de manière logique aux détections.

Tout d'abord, vous devez accéder à Sigma HQ/Sigma">Télécharger le fichier ZIP principal depuis le Sigma Github :

Une fois que vous avez le fichier .ZIP, nous devons en extraire le contenu. Pour faciliter les choses, créez un dossier sur votre bureau appelé « BTL1 -SIGMA », déplacez le fichier ZIP téléchargé vers ce dossier, puis extrayez-le.

Ouvrez le dossier « règles ». Un certain nombre de sous-dossiers contenant certaines règles de base s'affichent :

Accédez maintenant au « dossier réseau » puis ouvrez « net_dns_c2_detection.yml » dans Sublime Text 2 (ou l'éditeur de texte de votre choix) :

Avant de commencer à personnaliser cette règle en fonction de nos propres besoins, récapitulons exactement ce que fait cette règle et comment elle est formatée. Prenez note des différentes lignes expliquées ci-dessous, car vous allez bientôt modifier certaines d'entre elles !

1. title est une valeur descriptive personnalisée qui est utilisée pour fournir une très brève

explication de ce que la règle recherche.

2. id est utilisé comme identifiant unique pour cette règle.

3. status est une valeur descriptive personnalisée utilisée pour expliquer l'état de la règle.

Certains exemples peuvent inclure « incomplet », « expérimental » ou « production ».

4. la description est une valeur descriptive personnalisée utilisée pour fournir une explication

plus détaillée de ce que la règle essaie de détecter et de quelle manière.

5. Voir ci-dessus.

6. author est une valeur personnalisée utilisée pour contenir le ou les auteurs de cette règle

SIGMA.

7. date est une valeur personnalisée utilisée pour contenir la date à laquelle la règle a été créée

pour la première fois.

8. modified est une valeur personnalisée utilisée pour contenir la date à laquelle la règle a été

modifiée pour la dernière fois par un auteur.

9. les références sont une liste personnalisée qui contient des URL qui aident à expliquer ce que

la règle essaie de détecter

10. voir ci-dessus (9)

11. voir ci-dessus (9)

12. logsource est utilisé pour expliquer quels journaux sont requis dans le SIEM pour que la règle

fonctionne

13. la catégorie logsource est dns, ce qui montre que l'équipe de sécurité devra extraire les

journaux DNS dans son SIEM pour que la règle fonctionne

14. La détection explique la logique qui sous-tend la règle, y compris les conditions qui,

lorsqu'elles sont remplies, peuvent générer une alerte.

15. La sélection indique que quelque chose doit être sélectionné dans les journaux DNS. Dans ce

cas, il s'agit du domaine parent (ou du domaine racine, tel que Google.com).

16. parent_domain indique le champ de journal qui doit être sélectionné. Le symbole astérisque

* représente un « caractère générique », ce qui signifie que n'importe quelle valeur peut être utilisée. Cela signifie que N'IMPORTE QUEL domaine doit être sélectionné.

17. la condition indique la logique de détection réelle. Pour cette règle, il récupérera toutes les

valeurs parent_domain et comptera le nombre de requêtes adressées à ce domaine. Si le nombre est supérieur à 1 000 (> 1 000 signifie supérieur à 1 000), il émettra une alerte.

18. les faux positifs sont une liste personnalisée qui indique comment les faux positifs peuvent se

produire.

19. faux positifs 2 — L'auteur explique qu'un logiciel légitime qui utilise le DNS pour transférer

des données générerait une alerte, même s'il ne s'agit pas d'une activité malveillante.

20. level est une valeur descriptive personnalisée qui, dans cette règle, semble indiquer le degré

d'urgence de cette alerte.

21. les tags sont une liste personnalisée qui inclut différentes techniques MITRE ATT&CK qui

peuvent être détectées à l'aide de cette règle.

Nous savons donc que cette règle est utilisée pour détecter un éventuel tunneling DNS à des fins de communication de commande et de contrôle en recherchant un grand nombre de requêtes adressées

à des domaines, et qu'elle émet une alerte lorsque 1001 demandes ou plus ont été observées en consultant les journaux DNS.

C'est maintenant à vous d'apporter des modifications qui nous permettront de détecter certaines activités spécifiques. Lisez le briefing de renseignement ci-dessous et essayez d'apporter des modifications à ce fichier de règles existant afin de refléter les informations fournies.

Séance d'information

Nous avons récemment observé un nouveau type de logiciel malveillant, baptisé « TRANSPORTER », qui utilise le tunnel DNS pour fournir un canal de commande et de contrôle sur Internet, permettant à un attaquant d'envoyer des commandes à des systèmes infectés. Le trafic DNS étant extrêmement courant dans les environnements, ce trafic s'intègre et ne semble pas immédiatement suspect. Les paquets DNS contiennent de nombreux champs et en-têtes dans lesquels les données peuvent être masquées.

Au moment de la rédaction de cet article, nous n'avons observé qu'un seul nom de domaine utilisé pour envoyer et recevoir du trafic C2, que nous avons inclus ci-dessous. En discutant avec une victime, nous avons constaté que son SIEM n'avait pas détecté cette activité car il ne surveillait pas le nombre excessif de requêtes DNS adressées aux domaines.

Nom de domaine : redhunt.net Nombre moyen de requêtes : 500 MITRE ATT&CK Techniques utilisées : T1071.004 (Application Layer Protocol : DNS)

Astuces

• Vous pouvez supprimer les lignes « id » et « modified » de la règle existante car elles ne sont pas obligatoires.
• Utilisez les lignes « titre » et « description » pour inclure les informations issues du briefing d'information ci-dessus.
• Si l'on considère le nombre moyen de requêtes, nous devons alerter si ce nombre est inférieur à ce chiffre pour détecter toute infection dont le trafic est inférieur à cette moyenne.