Guide des règles YARA : Apprendre à utiliser cet outil de recherche de logiciels malveillants

Les règles YARA permettent de classer et d’identifier des échantillons de malwares en créant des descriptions de familles de malwares basées sur des modèles textuels ou binaires.

Dans cet article, j’aborderai les sujets suivants :

• Fonctionnement des règles YARA
• Cas d’utilisation YARA
• Éléments YARA à connaître
• Écriture des règles YARA

Fonctionnement des règles YARA

Les règles YARA sont comme une portion de langage de programmation : elles définissent un certain nombre de variables qui contiennent des modèles trouvés dans un échantillon de malware. Si certaines ou toutes les conditions sont remplies, suivant la règle, cette dernière peut être utilisée pour identifier efficacement un malware.

En analysant un malware, les chercheurs en sécurité reconnaîtront des modèles et des chaînes uniques au sein du malware qui leur permettront d’identifier le groupe de menace et la famille de malwares à laquelle l’échantillon est associé. En créant une règle YARA à partir de plusieurs échantillons provenant de la même famille de malwares, il est possible d’identifier un groupe d’échantillons issus de la même campagne ou du même hacker.

Lors de l’étude d’un malware, un analyste peut créer une règle YARA pour un nouvel échantillon en cours d’investigation. Cette règle peut ensuite être utilisée pour rechercher des échantillons similaires dans sa propre base de données ou dans des référentiels en ligne tels que VirusTotal.

Si l’analyste de logiciels malveillants travaille pour une organisation ayant déployé un système de prévention d’intrusion (IPS) ou une autre plateforme prise en charge par YARA et dédiée à la protection contre les malwares, les règles YARA peuvent servir d’outil de réponse aux incidents pour détecter les binaires malveillants au sein de l’organisation.

CAS D’UTILISATION

YARA est devenu très populaire auprès de la communauté InfoSec, car cet outil peut être mis en œuvre dans plusieurs cas d’utilisation :

• Identifier et classer les malwares.
• Trouver de nouveaux échantillons sur la base de modèles spécifiques à une famille donnée.
• Les techniciens de réponse aux incidents peuvent déployer des règles YARA pour identifier des échantillons ainsi que les appareils compromis.
• Le déploiement proactif de règles YARA personnalisées peut renforcer les défenses d’une organisation.

Éléments YARA à connaître

Pour élaborer une règle YARA utile et personnalisée, vous devez connaître les différents éléments qui peuvent être utilisés.

Métadonnée

Les métadonnées n’affectent pas ce que la règle YARA va rechercher, mais elles fournissent des informations utiles sur la règle elle-même.

• Auteur – Nom, adresse électronique, nom d’utilisateur Twitter.
• Date – Date de création de la règle.
• Version – Numéro de version de la règle YARA pour le suivi des modifications.
• Référence – Lien vers un article sur l’échantillon ou de téléchargement de l’échantillon, utilisé pour fournir des informations pertinentes sur l’échantillon de malware que la règle est conçue pour détecter.
• Description – Bref aperçu de l’objectif de la règle et du malware qu’elle vise à détecter.
• Hachage – Liste d’échantillons de hachages qui ont été utilisés pour créer la règle YARA.

Chaînes

On trouve souvent des chaînes uniques et intéressantes au sein d’un échantillon de malware, idéales pour élaborer une règle YARA. Pour définir une chaîne dans une règle, la chaîne elle-même doit être déclarée comme une variable.

• $a=”string from malware sample”

En plus de déclarer une chaîne, nous pouvons également ajouter des modificateurs après la chaîne déclarée pour affiner la recherche.

• $a=”malwarestring” fullword – Ce modificateur établira une correspondance avec un terme exact. Par exemple, « www.malwarestring.com » renverrait à une correspondance, mais pas « www.abcmalwarestring.com ».
• $a=”malwarestring” wide – Ce modificateur établira une correspondance avec des chaînes Unicode séparées par des octets nuls, par exemple « w.w.w…m.a.l.w.a.r.e.s.t.r.i.n.g…c.o.m. ».
• $a=”malwarestring” wide ascii – Ce modificateur permettra à la règle d’établir une correspondance avec des caractères Unicode et ASCII.
• $a=”MalwareString” nocase – La règle établira une correspondance avec la chaîne, quelle que soit la casse.

Dans l’image ci-dessous, j’ai utilisé HxD, un éditeur hexadécimal ; on peut voir ici certaines chaînes dans l’outil.

J’ai mis en surbrillance la chaîne ASCII « \photo.png » ainsi que la représentation hexadécimale correspondante. Avec ces informations, vous pouvez déclarer une chaîne hexadécimale dans une règle YARA.

• $a={5C 70 68 6F 74 6F 2E 70 6E 67} – Notez l’utilisation d’accolades au lieu de guillemets.
• $a={5C 70 68 6F ? ?? ?F 2E 70 6E 67} – Les points d’interrogation peuvent être utilisés comme caractères de remplacement si vous avez détecté une légère variation d’un modèle hexadécimal dans plusieurs échantillons.
• $a={5C [2-10] 6F 74 6F 2E 70 6E 67} – Dans cet exemple, j’ai indiqué que la chaîne peut commencer par la valeur « 5C » mais qu’il peut y avoir 2 à 10 octets aléatoires avant la reprise du modèle de correspondance.
• $a={5C (01 02 | 03 04) 6F 2E 70 6E 67} – Dans cet exemple, j’ai indiqué que les valeurs hexadécimales de cet emplacement pouvaient être « 01 02 » ou « 03 04 ».

Chaînes et identificateurs uniques qui conviennent très bien pour les règles YARA :

• Mutex – Trouvés uniquement dans les familles de malwares, les Mutex sont utilisés par les malwares pour vérifier si un appareil a déjà été compromis, en recherchant leur présence.
• Agents utilisateurs rares et inhabituels – Identifiés lorsque le malware communique avec son infrastructure C2.
• Clés de registre – Souvent créées par les malwares comme mécanisme de persistance.
• Chemins d’accès PDB – PDB signifie Program Database ; une PDB contient des informations de débogage sur un fichier. Il est peu probable que vous ayez une PDB pour un malware, mais le chemin d’accès PDB peut souvent être trouvé et utilisé dans une règle YARA, par exemple c:\users\user\desktop\vc+ 6\6,2,20\scrollerctrl_demo\scrollertest\release\scrollertest.pdb.
• Chaînes de configuration chiffrées – Les malwares chiffrent souvent leur configuration, qui contient des indicateurs de compromission (IOC) utiles tels que les adresses IP et les domaines. Si vous avez les compétences nécessaires en rétro-ingénierie pour identifier ces données chiffrées, elles peuvent être utilisées dans une règle YARA.

Conditions

La section Chaînes définit les critères de recherche qui seront utilisés pour une règle YARA ; la section Conditions définit les critères de déclenchement d’une règle pour une correspondance réussie. Plusieurs conditions peuvent être utilisées que vous trouverez ci-après.

• uint16(0) == 0x5A4D – La vérification de l’en-tête d’un fichier est une excellente condition à inclure dans vos règles YARA. Cette condition stipule que le fichier doit être un exécutable Windows, car les valeurs hexadécimales 4D 5A sont toujours situées au début d’un en-tête de fichier exécutable. Ceci est inversé dans YARA en raison du boutisme.
• uint32(0)==0x464c457f) ou (uint32(0) == 0xfeedfacf) ou (uint32(0) == 0xcffaedfe) ou (uint32(0) == 0xfeedface) ou (uint32(0) == 0xcefaedfe) – Utilisé pour identifier les binaires Linux en vérifiant l’en-tête du fichier.
• (#a == 6) – Le nombre de chaînes est égal à 6.
• (#a > 6) – Le nombre de chaînes est supérieur à 6.

Il existe plusieurs façons de spécifier la condition relative à la taille du fichier.

• (filesize>512)
• (filesize<5000000)
• (filesize<5MB)

Une fois que les chaînes ont été déclarées dans une règle, vous pouvez personnaliser le nombre de correspondances devant être déclenchées pour que la règle renvoie ce qu’elle considère être une condition remplie.

• 2 parmi ($a,$b,$c)
• 3 d’entre elles
• 4 parmi ($a*)
• toutes
• n’importe laquelle
• $a et pas $b

Si possible, essayez d’utiliser 2 ou 3 groupes de conditions pour éviter de générer des faux positifs et pour créer une règle fiable.

Importations

Les importations sont un excellent moyen de mettre en œuvre des conditions supplémentaires dans vos règles YARA. Dans cet article, je vais évoquer quelques exemples d’utilisation de l’importation au format PE (exécutable portable).

Bibliothèque PE :

L’ajout de la syntaxe « import pe » au début d’une règle YARA vous permettra d’utiliser la fonctionnalité PE de YARA, ce qui est utile si vous ne parvenez pas à identifier de chaînes uniques.

Les exportations sont d’excellents ajouts à une règle YARA ; il s’agit de fonctions créées par l’auteur du malware, alors assurez-vous d’utiliser leur nom spécifique. Dans l’image ci-dessous, j’ai identifié certaines exportations utilisées par une DLL qui a été déposée par un malware Formbook.

• pe.exports(“Botanist”, “Chechako”, “Originator”, “Repressions”)

Dans l’image ci-dessous, j’ai identifié une DLL intéressante utilisée pour la connectivité HTTP, winhttp.dll :

Nous pouvons également constater que cette bibliothèque importe un certain nombre d’API intéressantes qui pourraient être incluses dans une règle.

• pe.imports(“winhttp.dll”, “WinHttpConnect”)
• pe.machine == pe.MACHINE_AMD64 – Utilisé pour vérifier le type de machine.

Un imphash est le hachage de la table des adresses d’importation (IAT) du malware, que nous avons identifié dans l’image précédente à l’aide de PEStudio. La même IAT est souvent utilisée dans une famille de malwares, c’est pourquoi son utilisation dans une règle YARA devrait détecter des échantillons similaires.

• pe.imphash() == “0E18F33408BE6E4CB217F0266066C51C”

Pour qu’un horodatage de fichiers soit utilisé dans une règle YARA, il doit être converti au format Unix ; dans l’image ci-dessous, j’ai identifié l’heure de compilation du malware.

L’utilisation de la syntaxe « // » permet d’effectuer des commentaires dans la règle. Je peux ajouter un commentaire indiquant l’heure Unix.

• pe.timestamp == 1616850469 // Tue Dec 08 17:58:56 2020

La section Version de PEStudio montre que cet échantillon de Lokibot possède des identifiants de version uniques. En utilisant la fonction pe.version_info, nous pouvons spécifier les propriétés de version à utiliser, comme le champ « CompanyName ».

• pe.version_info[“CompanyName”] contient AmAZon.cOm.
• pe.language(0x0804) // China – Les langues identifiées peuvent être utilisées en spécifiant le code de langue Microsoft.

Dans l’image ci-dessous, j’ai identifié plusieurs sections du malware qui ne figurent pas souvent dans d’autres exécutables Windows que j’ai analysés. Grâce à ces informations, je peux spécifier des noms de section précis et leur numéro de section associé.

Notez que les sections sont indexées à zéro. La première section serait donc « 0 », la seconde serait « 1 », etc. Ainsi, dans l’exemple ci-dessous, j’ai utilisé la section intitulée « BSS », qui est la section numéro deux.

• pe.sections[2].name == “BSS”

Comment écrire des règles YARA

L’image ci-dessous est un exemple de règle YARA que j’ai créé à partir d’un échantillon du malware Redline :

Début de la règle

La règle YARA commence par la syntaxe « rule » suivie du nom de la règle. Il est ensuite ajouté une accolade « { » pour signifier le contenu de la règle YARA.

Juste au-dessus, j’ai importé la fonctionnalité PE en utilisant l’instruction « import pe » ; cette fonctionnalité est utilisée dans la section Conditions de la règle.

Métadonnée

Dans l’exemple de règle, j’ai inclus l’auteur, le type de fichier du malware, la date d’écriture de la règle, la version de la règle, une référence à l’endroit où j’ai obtenu l’échantillon, ainsi qu’un hachage du malware. Cela donne des informations contextuelles à toute autre personne susceptible d’utiliser la règle, ou peut même être utile à l’auteur lorsqu’il réexamine la règle ultérieurement.

Déclaration des chaînes

Ensuite, j’ai spécifié certaines chaînes trouvées dans l’échantillon du logiciel malveillant. Elles sont déclarées comme des variables dans la règle et peuvent être utilisées pour rechercher des fichiers au contenu similaire.

Les chaînes que j’ai utilisées ont été identifiées à l’aide de PEStudio et sont un mélange intéressant d’API Windows et de chaînes qui, selon moi, seront uniques à cette famille de malwares.

Conditions

La section Conditions est l’endroit où la règle YARA déclare quelles conditions doivent être remplies pour que la règle déclenche une correspondance. La première règle que j’ai stipulée est que l’en-tête du fichier doit être un exécutable Windows. Cela se fait en spécifiant les valeurs hexadécimales trouvées dans l’en-tête d’un exécutable Windows. Dans l’image ci-dessous, vous pouvez voir comment ces valeurs ont été identifiées à l’aide d’un éditeur hexadécimal.

La version de fichier dans le malware m’a également semblé être quelque chose d’unique au malware, c’est pourquoi je l’ai incluse dans la règle – “Versium Research 5 Installation”.

J’ai également indiqué que trois importations doivent être présentes, signalées comme suspectes par PEStudio.

Avec le temps et l’expérience, vous serez en mesure de repérer les sections suspectes dans des échantillons. Quelques exemples de sections courantes que vous verrez sont « .data », « .reloc », et « .rsrc ». Dans cet échantillon, j’ai trouvé quelques sections qui ne correspondent pas à ce modèle, donc ma règle YARA recherche les sections nommées « CODE » et « BSS ».

Les autres conditions stipulées comme devant être remplies sont que la première chaîne déclarée comme « $a1 » doit être présente, OU trois des chaînes « $b » ou l’une des chaînes « $c ». La dernière condition est que la taille du fichier doit être inférieure à 50 000 octets.

Cette règle peut maintenant être utilisée pour commencer à rechercher d’autres échantillons Redline.

Quelques réflexions pour conclure :

Vous avez maintenant les connaissances nécessaires pour commencer à élaborer vos propres règles YARA en vue de rechercher de nouveaux échantillons à analyser, ou de mettre en œuvre des détections proactives au sein de votre organisation.

Si vous cherchez à améliorer la posture de sécurité de votre organisation, consultez Varonis Edge : Détection de périmètre et Plateforme de sécurité des données.