Analysez vos partages de fichiers Active Directory avec Snaffler pour protéger vos données

I. Présentation

Dans cet article, nous allons explorer la problématique du stockage d'informations sensibles dans les partages de fichiers d'un système d'information et des conséquences que la mauvaise gestion des permissions et les négligences humaines peuvent avoir. Je vous partagerai mon retour d'expérience à ce sujet et notamment pourquoi il s'agit d'un incontournable dans le mode opératoire d'un attaquant lors d'une cyberattaque.

Nous allons également apprendre à utiliser l'outil Snaffler, qui peut être utilisé par la blue team (équipe de défense du SI) afin d'avoir une démarche proactive sur ce sujet et complémentaire vis-à-vis des autres bonnes pratiques de sécurité que nous allons évoquer.

Snaffler est un outil qui permet d'automatiser la recherche d'informations sensibles dans tous les partages de fichiers des systèmes du domaine. Cela grâce à de la découverte automatique de partage ainsi que des règles pré-conçues et personnalisables.

II. Partage réseau et informations sensibles

Les diverses missions que j'ai accomplies en tant qu'auditeur en cybersécurité et pentester m'ont conduit à la conclusion suivante : il est presque impossible de garantir qu'une donnée sensible n'est pas accessible à un utilisateur non légitime dans les partages réseau.

La recherche de fichiers contenant des mots de passe ou des données techniques sensibles est toujours une opération fructueuse via un compte authentifié sur le domaine.

La multitude de groupes, sites géographiques, permissions, ACL, partages, dossiers et sous-dossiers multipliée par la négligence, les mauvaises pratiques humaines et l'historique du SI font que dès qu'un attaquant compromet un compte utilisateur sur un domaine, il parvient à obtenir des identifiants grâce à une recherche d'information dans les partages de fichier. Ces identifiants peuvent être stockés dans :

• des fichiers bureautiques;
• des fichiers textes;
• des coffres-fort de mots de passe;
• des fichiers de configuration;
• le code source d'une application web;
• des disques dur de machines virtuelles;
• des archives contenant un ou plusieurs des items précédents;
• etc.

Le stockage d'informations sensibles dans les partages réseau des serveurs d'une entreprise est plutôt commun. C'est exactement le but de ces services : stocker les informations critiques de l'entreprise sur ses propres serveurs, au sein de son propre système d'information.

Cependant, c'est la gestion des permissions d'accès à ces informations qui pose majoritairement un problème. Une fois que l'attaquant obtient un compte valide du domaine, il peut alors profiter des droits de cet utilisateur, les groupes métiers auquel il appartient donneront de fait accès aux données relatives à son contexte métier.

Ça, c'est dans le meilleur des cas. Dans la réalité, le fait de disposer de n'importe quel compte utilisateur valide sur le domaine permet de profiter des droits permissions aux groupes "Tout le monde" et "Utilisateurs authentifiés". Ce sont les droits accordés à ces groupes sur les partages de fichiers qui sont généralement beaucoup trop permissifs. Et pour cause, lorsque l'on souhaite partager un dossier, celui-ci intègre par défaut une ACL de lecture sur le groupe "Tout le monde" (qui comprend "Utilisateurs authentifiés"), qu'il faut manuellement supprimer :

Pour rappel, Le groupe "Authenticated Users/Utilisateurs authentifiés" englobe tous les utilisateurs dont l'authentification a été vérifiée lors de leur connexion. Cela inclut à la fois les comptes d'utilisateurs locaux et ceux provenant de domaines de confiance. Le groupe "Tout le monde" inclut tous les membres du groupe "Utilisateurs authentifiés" ainsi que le compte intégré Invité, et divers comptes de sécurité intégrés (SERVICE, LOCAL_SERVICE, etc.).

Il faut aussi intégrer le fait que plus l'attaquant compromettra de compte utilisateur, plus il profitera des nouveaux privilèges obtenus pour accéder à de nouveaux partages et dossiers réseau en fonction des groupes d'appartenances des groupes compromis.

Par négligence, facilité ou ignorance des conséquences, il est très fréquent que la plupart des partages de fichiers soient accessibles aux membres du groupe "Utilisateurs authentifiés" du domaine, c'est-à-dire tous les utilisateurs.

Également, il faut connaitre et noter la différence entre les permissions appliquées les partages réseau et les permissions NTFS (appliquées sur les dossiers et sous-dossiers de ces partages). Ces permissions NTFS permettent de gérer les permissions des différents dossiers à l'intérieur d'un partage de fichier, en autorisant ou interdisant l'accès à des dossiers spécifiques. Dans les faits, cela permet donc de définir de façon granulaire qui a accès à quel dossier, mais cela rajoute de la complexité de gestion qui peut mener à des erreurs, des oublis, etc.

Pour mieux comprendre la différence entre permissions NTFS et permissions des partages, je vous invite à consulter notre article à ce sujet : Serveur de fichiers – Les permissions NTFS et de partage, résumé dans la vidéo ci-dessous :

Il est à noter que par "informations sensibles", la première idée qui vient en tête est bien sûr le mot de passe d'un compte privilégié du domaine. Dans un contexte d'entreprise, il peut s'agit également de données métiers (secrets industriels), d'informations financières et bancaires, mais aussi d'informations personnelles (RGPD) concernant les clients ou les salariés de l'entreprise. Nous verrons par la suite que ce détail à une importance pour la red team (attaquant), mais aussi pour la blue team (défenseur) qui souhaite avoir une démarche proactive et rechercher elle-même l'exposition excessive de données dans les partages réseaux.

Lors d'une cyberattaque, pour accomplir cette tâche de manière complète, la red team doit opérer de la façon suivante :

1. Énumérer les hôtes du domaine.
2. Énumérer les services de partage de fichiers présents sur ces hôtes.
3. Énumérer les partages exposés et les permissions d'accès avec l'utilisateur courant.
4. Parcourir chaque dossier et chaque fichier accessible à la recherche d'informations sensibles.

Vous l'imaginez bien, cette tâche est fastidieuse et ne peut être menée à bien dans un délai raisonnable. C'est pourquoi des outils ont été créés pour l'automatiser de façon efficace. De plus, ces opérations sont fréquentes dans le mode opératoire des attaquants et disposent de leur propre TTP dans le framework MITRE ATT&CK, preuve qu'il s'agit d'un sujet à prendre au sérieux :

• T1135 - Network Share Discovery
• T1083 - File and Directory Discovery

Prenez notamment le temps de jeter un œil à la section "Procedure Examples" du TTP T1083. Cette section liste les cas avérés et documentés de cyberattaque ayant exploité ce TTP. Ici, près de 350 cas sont répertoriés.

III. Gestion des droits sur les partages réseaux : les bonnes pratiques standard

La gestion des permissions sur les partages réseau est une tâche à la base simple, qui devient très complexe dans un contexte réel d'entreprise. Il faut à la fois permettre la collaboration entre les utilisateurs, s'assurer que le principe de moindre privilège est respecté et garder un œil sur le respect des bonnes pratiques et directives données.

Le principe de moindre privilège est un concept fondamental en cybersécurité. Il consiste à n'accorder à un utilisateur, un processus ou un objet uniquement les privilèges nécessaires à l'accomplissement de ses tâches, et ce, sans accorder de droits superflus.

Ce principe vise à limiter les risques en réduisant la surface d'attaque potentielle. Il est souvent mis en avant lors de la gestion des droits d'accès pour souligner l'importance de mettre en place un modèle de privilèges granulaire, afin de minimiser les risques d'exploitation par des attaquants.

Les mesures "traditionnelles" de sécurité à prendre concernant la gestion des permissions d'accès aux partages de fichiers sont les suivantes :

• S'assurer que les partages de fichiers ne sont pas accessibles en mode anonyme : cela peut paraitre étonnant, mais c'est beaucoup plus fréquent qu'on ne le croit d'après mes expériences.
• Définir un modèle de droit clair et efficace, adapté au contexte de sécurité de l'entreprise. Pour trouver un modèle "standard" de sécurité, vous pouvez notamment consulter cet article sur la méthode AGDLP : AGDLP – Bien gérer les permissions de son serveur de fichiers.
• S'assurer d'avoir une équipe formée sur le sujet : la gestion des droits sur les partages de fichiers peut avoir quelques secrets. Il faut s'assurer que notre équipe est techniquement formée, mais qu'elle connait aussi les bonnes pratiques internes de l'entreprise afin de savoir s'il y est légitime que tel groupe accède à telle information. On peut citer la directive n°1 du guide d'hygiène de l'ANSSI : Former les équipes opérationnelles à la sécurité des systèmes d’information.
• Sensibiliser et former les utilisateurs concernant la manipulation, le stockage et la partage d'informations sensibles au quotidien, au sein d'une équipe ou avec des utilisateurs externes : On peut citer la directive n°2 du guide d'hygiène de l'ANSSI : Sensibiliser les utilisateurs aux bonnes pratiques élémentaires de sécurité informatique.
• Archiver les données qui ne sont plus utilisées afin de réduire la surface d'attaque. Il est évident que si une donnée n'est plus exposée, elle ne pourra être compromise.

Même avec toutes ces bonnes pratiques, qu'est-ce qui empêcherai un utilisateur de stocker le mot de passe du compte X (ex-Twitter) de l'entreprise dans un fichier texte sur le partage "\\SRV-FICHIER\Communs\Communication", pour l'échanger plus facilement avec ses deux collègues du pôle communication ?

IV. Démarche proactive de recherche d'informations sensibles dans les partages

A. Snaffler : automatiser la recherche d'informations sensibles

En complément des mesures et bonnes pratiques listées dans la section précédente, la blue team peut souhaiter avoir une démarche proactive et utiliser elle-même les outils et méthodes des attaquants. Cela dans le but de vérifier que les mesures de sécurité sont efficaces et bien implémentées au travers des vérifications régulières. C'est ici que Snaffler entre en jeu.

Snaffler est un exécutable plutôt simple d'utilisation au regard de la charge de travail qu'il permet d'économiser. Comme indiqué précédemment, dans son utilisation standard, celui-ci va

1. Se connecter à l'Active Directory et lister les objets "Ordinateur".
2. Se connecter à chaque ordinateur afin de lister les partages de fichiers exposés.
3. Vérifier les droits de lecture sur chacun des partages, dossiers et sous-dossiers avec l'utilisateur courant.
4. Lister les fichiers et sélectionner les plus intéressants.
5. Lire le contenu de chacun des fichiers accessibles dans ces partages en fonction des règles de recherche configurées.

À chaque étape de ce processus sont appliquées des règles de matching afin de déterminer si le partage, répertoire ou fichier est intéressant ou doit être mis de côté. Ce processus peut être schématisé de la façon suivante :

B. Utiliser Snaffler au sein d'un domaine Active Directory

Soyez vigilant à utiliser cet outil que si vous y êtes autorisé. Pour rappel : Code pénal : Chapitre III : Des atteintes aux systèmes de traitement automatisé de données

Maintenant que nous avons introduit le sujet, passons à l'action. Il faut bien sûr commencer par télécharger l'exécutable depuis son dépôt Github : Github - Snaffler.

Attention, il faut également savoir que le binaire "Snaffler.exe" peut être détecté comme malveillant par certains EPP et EDR, le binaire étant autant utilisé par les défenseurs que par les attaquants, il est normal que des solutions de sécurité le catégorisent ainsi :

D'après cette analyse VirusTotal réalisée sur la dernière version de Snaffler, 43 des 73 produits de sécurité utilisés considèrent le binaire comme malveillant. Il faudra donc certainement passer par une mise en liste blanche du binaire.

Snaffler est open-source, vous pouvez donc étudier son code source avant exécution sur votre système d'information.

Le plus simple pour avoir une vue rapide de ses capacités et de l'exécuter depuis un poste du domaine avec un utilisateur "non privilégié" du domaine.

Cependant, les choix de l'utilisateur et de la position sur le réseau du système utilisé ont ici leur importance et doivent refléter la situation de l'attaquant tel que souhaité dans votre simulation. S'agit-il d'un compte RH, stagiaire ou d'un membre de l'équipe IT ? L'attaquant effectue-t-il sa recherche depuis le réseau Wifi invité, le poste utilisateur de l'accueil ?, etc. À ce titre, plusieurs itérations du même test peuvent être effectuées, en modifiant le compte utilisateur utilisé ou la position réseau du système émettant la recherche. Vous pourrez alors comparer les résultats obtenus.

Depuis un poste intégré au domaine et un compte utilisateur valide sur le domaine, j'utilise Snaffler de la façon suivante :

.\Snaffler.exe -s -v Data

L'option "-s" est utilisée ici pour rediriger la sortie vers le terminal et l'option "-v Data" est utilisée pour définir le niveau de verbosité. "Data" signifie ici que nous n'aurons que des informations à propos des données trouvées, aucune information de debug.

Pas d'authentification, pas de spécification de cible (même si cela est possible via les options). Snaffler va utiliser la session actuelle de l'utilisateur ainsi que les informations du domaine pour se connecter à l'Active Directory et commencer son énumération.

En fonction de votre système d'information, Snaffler peut s'exécuter pendant assez longtemps (j'ai déjà vu des cas où l'analyse prenait plusieurs heures). Cependant, vous devriez avoir des premiers résultats assez rapidement. Ceux-ci s'affichent au fil de l'eau.

Voici un exemple de résultat (cliquez sur l'image pour zoomer) :

A noter que pour une utilisation en live, cette première commande suffit. On peut toutefois stocker la sortie de Snaffler dans un fichier texte, ce qui est notamment intéressant lorsque la sortie produite est volumineuse :

snaffler.exe -s -v Data -o snaffler.log

Snaffler va alors écrire ses résultats dans un fichier dédié, qui pourra être parcouru après coup.

C. Comprendre les résultats de Snaffler

Comme vous pouvez le voir dans la capture ci-dessus, Snaffler peut être assez verbeux dans sa sortie. Lorsque l'on connait la structure de cet affichage, les choses deviennent cependant beaucoup plus simples. Dans un premier temps, on peut voir que Snaffler se connecte à tous les objets Ordinateurs retournés par sa requête LDAP (l'AD et un poste utilisateur dans mon cas) et liste les partages réseau disponibles (Cliquez sur l'image pour zoomer) :

À noter que j'effectue ma démonstration ici avec l'Administrateur du domaine, qui a donc accès à tous les répertoires partagés du domaine. En fonction de votre objectif (trouver absolument une donnée, où qu'elle soit, ou voir à quoi à accès tel profil utilisateur depuis telle position réseau), votre résultat pourra nettement différer.

Suite à cela, Snaffler commence à journaliser des informations à propos des fichiers qu'il trouve intéressant, ainsi que des extraits de ces fichiers (Cliquez sur l'image pour zoomer) :

Chaque ligne commence par le nom de l'utilisateur utilisé pour l'énumération ("[IT-CONNECT\Administrateur@AD01]" :

• La première ligne nous indique qu'une règle de détection a trouvé un fichier intéressant (d'après son nom) : "confCons.xml". Les connaisseurs reconnaitront le nom d'un fichier de configuration de l'outil "mRemoteNG", utilisé pour stocker les connexions (nom, login, mot de passe) des connexions RDP, SSH, etc.
• La seconde ligne est le résultat d'une règle de parsing du contenu d'un fichier et nous donne un extrait d'une donnée de ce même fichier de configuration. C'est souvent le plus intéressant et facile d'accès, car il s'agit de fichier "texte", facile à parser pour Snaffler. Mais, il ne faut pas forcément s'arrêter là.
• La troisième ligne est à nouveau une règle de matching sur un nom de fichier. Snaffler a découvert un fichier de dump mémoire (".DMP"). Le chemin et nom complet du fichier (en violet) nous indique qu'il s'agit d'un dump mémoire du processus LSASS, notamment connu pour y stocker les identifiants et sessions des utilisateurs connectés. La structure du fichier n'étant pas du simple texte, Snaffler nous indique simplement sa présence et c'est à nous d'aller plus loin si l'on juge cela intéressant.

Pour mieux comprendre encore, voici la structure de chaque ligne de sortie Snaffler (cliquez sur l'image pour zoomer) :

La couleur a notamment une importance, elle détermine le niveau de certitude et d'intérêt que Snaffler a sur la présence d'une information recherchée :

• Black : certitude que l'information ou le fichier découvert est sensible
• Red : a de grande chance d'être ou de contenir une information sensible
• Yellow et Green : peut présenter un intérêt, mais une investigation plus poussée est nécessaire

Ces niveaux de catégorisation sont inscrits dans les différentes règles de Snaffler. La découverte d'un champ "password=" dans un fichier sera Red alors que la découverte d'un script PowerShell sera Green. À ce titre, il est possible de filtrer la sortie de Snaffler pour n'afficher, par exemple, que les résultats Red ou Black :

.\Snaffler.exe -s -v Data -b 3

L'option "-b 3" entraine une journalisation de la catégorie Black uniquement (la plus élevée). Je vous recommande cependant de journaliser au moins à partir du niveau Red, qui sont en général pertinents. Pour cela, utilisez l'option "-b 2".

D. Réaliser une recherche locale de données via Snaffler

Nous avons pour le moment utilisé Snaffler dans son mode "par défaut", dans lequel il va lui-même chercher une liste d'hôtes auprès de l'Active Directory. Il est aussi possible de réaliser une exécution uniquement locale de Snaffler, ciblant le système du fichier de l'hôte sur lequel il est déposé, sans communication réseau et avec des chances de détection réduite pour un attaquant :

.\Snaffler.exe -s -v Data -i C:\

Via l'option "-i", on ordonne à Snaffler de ne pas faire de récupération d'hôte et de se fier à notre liste à la place. Cette option peut aussi être utilisée pour spécifier un partage précis sur un système de notre choix :

.\Snaffler.exe -s -v Data -i \\AD01.it-connect.tech\Partage_IT

Enfin, si l'on souhaite que Snaffler effectue une découverte des partages, mais pas des hôtes, on peut lui fournir une liste d'hôte à énumérer avec l'option "-n" :

.\Snaffler.exe -s -v Data -n AD01.it-connect.tech,DESKTOP-VAU6BQO.it-connect.tech

Ces deux dernières options sont intéressantes pour une analyse ciblée sur un serveur ou un partage donné.

V. Utilisation et configuration personnalisée de Snaffler

A. Comprendre le fonctionnement des règles Snaffler

Pour mieux comprendre le fonctionnement de Snaffler, il faut savoir que celui-ci effectue une recherche et catégorisation progressive des fichiers et informations en fonctions des règles fournies. D'abord, il va rechercher les fichiers dans tous les partages, dossiers et sous-dossiers sur lequel il dispose de droits de lecture. Un premier tri est effectué sur ces fichiers :

• En fonction de leurs tailles (pour des raisons de performance)
• En fonction de leurs extensions (.kdbx, .id_rsa, .ppk, etc.)
• En fonction des noms de fichier (web.config)
• En fonction d'un mot présent dans le nom du fichier ("Mes mots de passe 2024.xlsx")

En fonction de ces critères ou d'une combinaison d'entre eux, Snaffler appliquera une décision :

1. Discard : Exclure le fichier de l'analyse (trop gros, fichiers généralement pas intéressants ou difficiles à parser).
2. Keep : Journaliser le fichier (terminal/fichier de log).
3. Relay : passer le fichier à une ou plusieurs règles en vue d'y chercher une donnée spécifique (en fonction du format/type de fichier). Par exemple, si une règle recherchant les extensions ".ps1" trouve un fichier, elle passera ce fichier à un ensemble de règles permettant d'y chercher les mots "password", "net user", etc. grâce à des expressions régulières.

Les règles sont écrites au format TOML et sont assez complexes au premier abord. Il faut notamment bien comprendre le fonctionnement et les capacités de Snaffler pour les mieux les appréhender. Préférez donc utiliser l'outil dans un premier temps avant de vouloir concevoir vos propres règles.

Les règles par défaut de Snaffler, intégrées dans l'exécutable, sont généralement suffisantes pour avoir des résultats pertinents lors d'une première analyse.

Pour dégrossir le sujet et mieux comprendre Snaffler, étudions la règle suivante :

[[ClassifierRules]]
EnumerationScope = "FileEnumeration"
RuleName = "RelayPsByExtension"
MatchAction = "Relay"
RelayTargets = ["KeepPsCredentials",
"KeepCmdCredentials",
"KeepAwsKeysInCode",
"KeepInlinePrivateKey",
"KeepPassOrKeyInCode", "KeepSlackTokensInCode",
"KeepSqlAccountCreation",
"KeepDbConnStringPw"]
Description = "Files with these extensions will be searched for PowerShell related strings."
MatchLocation = "FileExtension"
WordListType = "Exact"
MatchLength = 0
WordList = ["\.psd1",
"\.psm1",
"\.ps1"]
Triage = "Green"

Les noms des différents attributs sont assez explicites et nous avons déjà aperçu des "EnumerationScope" précédemment dans l'article :

• ShareEnumeration : règles portant sur les partages, permettant notamment d'exclure de l'analyse certains partages peu intéressant ("\\PRINT$" "\\IPC$").
• DirectoryEnumeration : règles portant sur les noms des répertoires, permettant également d'en exclure certains.
• FileEnumeration : règles portant sur les noms et extensions des fichiers, permettant d'inclure ou exclure certains d'entre eux de l'analyse, de journaliser les fichiers intéressants et de passer aux règles suivantes les fichiers à parser.
• ContentsEnumeration : règles de parsage de fichier, qui permettent de détecter des patterns précis dans des fichiers ("password=", "client_secret", etc.)
• PostMatch : Règles spécifiques d'exclusion pour exclure certains faux positifs classiques.

Notre règle ci-dessus va donc rechercher les fichiers ayant des extensions précises ("MatchLocation = FileExtension"), comme ".psd1", ".psm1" ou ".ps1". En cas de match, elle va relayer ("MatchAction = Relay") le fichier cible aux règles présentes dans la liste "RelayTargets". Voici, en exemple, l'une des règles cible en question :

[[ClassifierRules]]
EnumerationScope = "ContentsEnumeration"
RuleName = "KeepPsCredentials"
MatchAction = "Snaffle"
Description = "Files with contents matching these regexen are very interesting."
MatchLocation = "FileContentAsString"
WordListType = "Regex"
MatchLength = 0
WordList = [ "-SecureString",
"-AsPlainText",
"\[Net.NetworkCredential\]::new\("]
Triage = "Red"

Cette règle va rechercher dans le contenu du fichier ("MatchLocation = FileContentAsString") les mots "-SecureString", "-AsPlainText", "\[Net.NetworkCredential\]::new\(" et journaliser "MatchAction = Snaffle" en cas de match. Lorsqu'un script PowerShell contient l'instruction "-AsPlainText" ou qu'il fait référence à une SecureString, c'est généralement le signe qu'il y a un mot de passe intégré dans le script.

Les règles par défaut de Snaffler sont mises à jour occasionnellement en fonction des apports de la communauté (voir l'historique des pull requests Github), vous pouvez notamment consulter le contenu des règles sur le Github également : Github - Snaffler/SnafflerRules. N'hésitez pas à les consulter en parallèle de vos premières utilisations pour comprendre précisément comment ces règles sont structurées.

B. Créer une règle Snaffler personnalisée

Ces deux exemples devraient vous fournir les bases nécessaires à la modification des règles existantes et la création de vos propres règles. Nous allons voir dans cette section comment ajouter une règle de recherche dans le contenu des fichiers PowerShell. Dans un premier temps, il est nécessaire de générer une base de fichier de configuration à l'aide de l'option "-z" :

Snaffler.exe -z

Cette option va générer un fichier "default.toml" dans votre répertoire courant, qu'il faudra ensuite spécifier lors du lancement de Snaffler (c'est ce fichier qui contient la limite de taille de fichier au-delà de laquelle Snaffler ne s'intéressera pas à un fichier).

À titre d'exemple, imaginons que nous venons de mettre en place un SI de sauvegarde cloisonné de notre SI principal et totalement décorrélé de notre domaine. Dans la démarche d'un attaquant ayant compromis notre domaine et souhaitant atteindre les sauvegardes avant de déployer son ransomware, celui-ci peut chercher dans notre documentation, scripts et mails la trace d'un éventuel SI de sauvegarde.

Nous ne souhaitons donc pas qu'un attaquant ayant compromis un compte d'un membre du SI puisse découvrir de script contenant le nom de notre serveur de sauvegarde ("SRV-BACKUP01") et par conséquent l'existence de notre SI de sauvegarde. Je vais dans un premier temps ajouter la règle suivante :

[[ClassifierRules]]
EnumerationScope = "ContentsEnumeration"
RuleName = "CUSTOM-KeepPsBackupServer"
MatchAction = "Snaffle"
Description = "File containning our backup server name, should be deleted ASAP."
MatchLocation = "FileContentAsString"
WordListType = "Regex"
MatchLength = 0
WordList = [ "SRV-BACKUP01"]
Triage = "Red"

Celle-ci va rechercher le terme "SRV-BACKUP01" dans tous les fichiers qui lui seront relayés. Ensuite, nous allons reprendre la structure de la règle "RelayPsByExtension" vu précédemment, ajouter quelques extensions et préciser ma nouvelle règle dans la liste des "RelayTargets" :

[[ClassifierRules]]
EnumerationScope = "FileEnumeration"
RuleName = "RelayScriptExtension"
MatchAction = "Relay"
RelayTargets = ["CUSTOM-KeepPsBackupServer"]
Description = "Files with these extensions will be searched for script related strings."
MatchLocation = "FileExtension"
WordListType = "Exact"
MatchLength = 0
WordList = ["\\.psd1",
"\\.psm1",
"\\.ps1",
"\\.bat",
"\\.cmd",
"\\.vbs"]
Triage = "Green"

Si j'exécute Snaffler en spécifiant ma nouvelle configuration, une analyse avec uniquement mes deux règles sera effectuée :

Snaffler.exe -s -v Data -z .\default.toml

Voici un résultat possible :

Ma nouvelle règle "CUSTOM-KeepPsBackupServer" a effectivement permis de trouver un script contenant le nom de mon serveur de sauvegarde, il ne s'agit pas d'une information sensible au regard des règles par défaut de Snaffler, mais dans mon contexte, cette information a intérêt à être remontée.

Attention, cette action va exécuter une analyse avec uniquement vos règles. Celles par défaut ne seront plus utilisées. Si vous souhaitez ajouter vos règles de façon durable dans l'analyse en plus de celles par défaut, il faut ajouter des fichiers ".toml" contenant vos règles dans le dossier "Snaffler/SnaffRules/DefaultRules", puis recompiler le binaire, qui contiendra alors l'ensemble des règles.

VI. Conclusion

Nous avons étudié dans cet article la problématique du stockage des informations sensibles dans les partages de fichiers et de la difficulté de gestion des droits et permissions dans le temps sur ces éléments. Snaffler est à mon sens un outil très intéressant pour compléter les mesures de sécurité habituelles sur ces sujets, puisqu'il permet de faire une analyse complète et concrète des informations visibles par un utilisateur sur les partages.

Il s'agit d'un outil très utilisé dans les phases de recherche, notamment lors des opérations de simulations d'attaques (tests d'intrusion). Dans des opérations réelles, l'attaquant ne va pas utiliser Snaffler car celui-ci est trop bruyant (un même compte utilisateur qui s'authentifie sur toutes les machines du domaine pour lister les partages), mais l'opération restera la même : voir quelles informations sont accessibles par un utilisateur compromis, et trouver des données techniques ou métier.

Enfin, il faut savoir qu'une version "étendue" de Snaffler existe ("UltraSnaffler"), elle permet de chercher des données dans des fichiers plus complexes comme des fichiers ".docx", ".xlsx". Ces possibilités ne sont pas proposées par défaut, car elle nécessite l'inclusion de librairies qui multiplie par 1200% le poids du binaire. Cela reste néanmoins une piste intéressante pour une utilisation et investigation avancée.

N'hésitez pas à donner votre avis dans les commentaires ou sur notre Discord !