Snaffler

# Snaffler 

[![ko-fi](https://www.ko-fi.com/img/githubbutton_sm.svg)](https://ko-fi.com/T6T31VEVJ)

![Une définition de dictionnaire de "snaffle".](https://assets.kitploit.com/production/public/readmes/5041/6bffcc4a7687e6617af40adbde0bdf04bc1be3ef93f68fb091b40fab56021879.png)

## À quoi ça sert ? 

Snaffler est un outil pour les **pentesters** et les **red teamers** afin de vous aider à trouver de délicieuses aiguilles de bonbons (surtout des creds, mais c'est flexible) dans un tas de meules de foin horribles et ennuyeuses (un environnement massif Windows/AD).

Il pourrait également être utile pour d'autres personnes faisant d'autres choses, mais il n'est explicitement PAS destiné à être un outil d'« audit ».

## Je ne veux pas lire tout ça !!!

Pfff, d'accord. Mais nous ne sommes pas responsables des résultats. Nous avons écrit tout ce qui précède pour vous, mais ce n'est pas grave. Nous ne sommes pas en colère, juste déçus.

`snaffler.exe -s -o snaffler.log`

## Qu'est-ce que ça fait ?

*En gros* - il récupère une liste d'ordinateurs Windows depuis Active Directory, puis déploie ses appendices snaffly vers eux tous pour déterminer lesquels ont des partages de fichiers, et si vous pouvez les lire.

Ensuite, ENCORE PLUS d'appendices snaffly énumèrent tous les fichiers dans ces partages et utilisent l'**I**NTELLIGENCE **A**RTIFACTUELLE **A**PPRISE pour **M**ACHINES pour déterminer lesquels un petit hacker crasseux comme vous pourrait vouloir.

En fait, il ne fait rien de ML, car le faire correctement nécessiterait des données d'entraînement, et cela nécessiterait un temps énorme que nous n'avons pas. Au lieu de cela, comme tous les bons projets « ML », il utilise simplement une tonne de `if` et de regex.

## À quoi ça ressemble ?

Comme ça !

<p align="center">
  <img src="https://assets.kitploit.com/production/public/readmes/5041/8acb1dc4ee910b6f2adf281a4f55572aca3731c4ead5774df7864758a976451a.png">
</p>

## Comment l'utiliser ?

Si vous « exécutez littéralement l'EXE sur une machine jointe au domaine dans le contexte d'un utilisateur de domaine » (comme les gens ont été invités à le faire avec Grouper2, immédiatement avant de le lancer avec tous les commutateurs verbeux/de débogage activés, ce qui leur a craché plusieurs centaines de mégaoctets de traces de pile), il ne fera essentiellement rien. C'est notre idée d'une blague<sup>TM</sup> pour les personnes qui ne lisent pas les fichiers README, parce que nous sommes des monstres.

CEPENDANT... si vous ajoutez les incantations correctes, cela activera le susmentionné L.A.I.M. et les chemins de fichiers où des bonbons peuvent être trouvés tomberont.

Les incantations clés sont : 

`-o`   Permet de sortir les résultats dans un fichier. Vous voulez probablement ceci si vous n'utilisez pas `-s`. p.ex. `-o C:\users\thing\snaffler.log`

`-s`   Permet de sortir les résultats sur la sortie standard dès qu'ils sont trouvés. Vous voulez probablement ceci si vous n'utilisez pas `-o`.

`-v`   Contrôle le niveau de verbosité, les options sont Trace (le plus bavard), Degub (moins bavard, moins de gubs), Info (encore moins bavard, par défaut) et Data (résultats uniquement). p.ex `-v debug` 

`-m`   Active et attribue un répertoire de sortie pour que snaffler prenne automatiquement une copie (ou Snaffle... si vous voulez) de tous les fichiers trouvés qu'il aime.

`-l`   Taille maximale des fichiers (en octets) à Snaffler. Par défaut 10000000, ce qui fait *environ* 10 Mo.

`-i`   Désactive la découverte des ordinateurs et des partages, nécessite un chemin vers un répertoire dans lequel effectuer la découverte de fichiers.

`-n`   Désactive la découverte d'ordinateurs, prend une liste d'hôtes séparés par des virgules ou un fichier d'entrée pour faire la découverte des partages et fichiers. Note : si vous fournissez un fichier, l'entrée doit être un chemin, par exemple C:\targets.txt ou .\targets.txt.

`-y`   Formate la sortie en TSV.

`-b`   Saute les règles LAIM qui trouvent des choses moins intéressantes, ajustez avec un nombre entre 0 et 3.

`-f`   Limite Snaffler à la recherche de partages de fichiers via DFS (Distributed File System) - cela devrait être beaucoup plus discret que par défaut tout en couvrant les plus gros partages de fichiers dans de nombreuses organisations.

`-a`   Saute l'énumération des fichiers, donne juste une liste des partages listables sur les hôtes cibles.

`-u`   Fait en sorte que Snaffler tire une liste de noms de comptes depuis l'AD, choisisse ceux qui semblent les plus intéressants, puis les utilise dans une règle de recherche.

`-d`   Domaine dans lequel chercher des ordinateurs pour chercher des partages pour chercher des fichiers. Facile.

`-c`   Contrôleur de domaine à interroger pour la liste des ordinateurs du domaine.

`-r`   Taille maximale du fichier (en octets) à rechercher pour des chaînes intéressantes. Par défaut 500k.

`-j`   Nombre d'octets de contexte de chaque côté des chaînes trouvées dans les fichiers à afficher, p.ex. `-j 200`

`-z`   Chemin vers un fichier de configuration qui définit tout ce qui précède, et bien plus encore ! Voir ci-dessous pour plus de détails. Passez `-z generate` pour générer un exemple de fichier de configuration appelé `.\default.toml`.

`-t` Type de journal que vous souhaitez produire. Les options actuellement supportées sont plain et JSON. Par défaut plain.

`-x` Nombre maximum de threads à utiliser. Ne le mettez pas en dessous de 4 ou ça va casser.

`-p` Chemin vers un répertoire rempli de règles au format .toml. Snaffler chargera tous ces fichiers à la place de l'ensemble de règles par défaut.

## Que signifie tout ce résultat de journal ?

Espérons que cet exemple annoté vous aidera :

<p align="center">
  <img src="https://assets.kitploit.com/production/public/readmes/5041/d840a80c5ba879a8a0aa90af454212220a9705142d166fe5964697c372764b55.png">
</p>

Cette entrée de journal doit être lue approximativement de gauche à droite comme suit :

* vers 7h37
* Snaffler a trouvé un fichier qu'il pense digne d'intérêt
* il l'a noté « Rouge », le deuxième niveau le plus intéressant
* il a correspondu à une règle nommée « KeepConfigRegexRed »
* vous pouvez le lire, mais pas le modifier
* l'expression régulière exacte qui a été trouvée est ce truc dans la boîte rouge
* il fait 208 ko
* il a été modifié pour la dernière fois le 10 janvier 2020 à quatre heures moins le quart de l'après-midi.
* le fichier se trouve au chemin en violet

... et le reste de la ligne (en gris) est un petit extrait de contexte du fichier où la correspondance a été trouvée.

Dans ce cas, nous avons trouvé des valeurs validationKey et decryptionKey d'ASP.NET, ce qui pourrait nous permettre de RCE l'application web via des bidouilles de désérialisation. Hourra !

Note : après que cette capture d'écran a été réalisée, Sh3r4 a ajouté un truc pour préfixer chaque ligne avec l'utilisateur et l'hôte actuels. Je ne veux pas refaire la capture d'écran cependant.

## Comment décide-t-il quels fichiers sont bons et lesquels sont ennuyeux ?

### La réponse « tellement simple que c'est presque un mensonge » :

Chaque méthode magique de recherche de fichiers L.A.I.M. fait des choses comme :

* Recherche par correspondance exacte d'extension de fichier, ce qui signifie que tout fichier avec une extension qui correspond à la liste de mots pertinente sera retourné. Cela est destiné aux **extensions de fichier** qui contiendront presque toujours des bonbons, p.ex. `.kdbx`, `.vmdk`, `.ppk`, etc.

* Recherche par correspondance exacte (insensible à la casse) du nom de fichier. Cela est destiné aux **noms de fichier** qui contiendront presque toujours des bonbons, p.ex. `id_rsa`, `shadow`, `NTDS.DIT`, etc.

* Recherche par correspondance exacte d'extension de fichier (encore une autre liste de mots) SUIVIE par le 'grep' du contenu de tous les fichiers correspondants pour certains mots clés (encore une autre liste de mots). Cela est destiné aux extensions de fichier qui **parfois** contiennent des bonbons mais où vous savez qu'il y aura probablement beaucoup de déchets à trier. Par exemple, `web.config` contiendra parfois des identifiants de base de données, mais contiendra aussi souvent des trucs de configuration IIS ennuyeux et aucun mot de passe. Cela trouvera (par exemple) tout ce qui se termine par `.config`, puis cherchera dedans des chaînes incluant mais sans s'y limiter : `connectionString`, `password`, `PRIVATE KEY`, etc.

* Recherche par correspondance partielle du nom de fichier (oh mon dieu encore des listes de mots). C'est principalement destiné à trouver `Jeff's Password File 2019 (Copy).docx` ou `Privileged Access Management System Design - As-Built.docx` ou autre, en faisant correspondre tout fichier dont le nom contient les sous-chaînes `passw`, `handover`, `secret`, `secure`, `as-built`, etc.

* Il y a aussi des listes de saut pour ignorer tous les fichiers avec certaines extensions, ou tout fichier dont le chemin contient une chaîne donnée.

### La vraie réponse :

Snaffler utilise un système de « classificateurs », chacun examinant des partages, dossiers, fichiers ou contenus de fichiers, en passant certains éléments en aval au classificateur suivant, et en rejetant d'autres. Chaque classificateur utilise un ensemble de règles pour décider quoi faire des éléments qu'il classifie.

Ces règles peuvent être très simples, p.ex. « si l'extension d'un fichier est `.kdbx`, signale-le moi », ou « si un chemin contient `windows\sxs` alors arrête de regarder les sous-répertoires et fichiers dans ce chemin ».

Les règles peuvent aussi utiliser des expressions régulières, ce qui permet une recherche de motifs relativement sophistiquée. C'est particulièrement utile lors de l'examen du contenu des fichiers, bien qu'il faille faire attention pour éviter des regex qui pénalisent significativement les performances. Dans les grands environnements, ces règles peuvent être vérifiées littéralement des millions de fois, donc des problèmes de performance mineurs peuvent être amplifiés considérablement.

La vraie puissance réside dans la capacité de Snaffler à enchaîner plusieurs règles ensemble, et même à créer des chaînes ramifiées. Cela nous permet d'utiliser des règles « peu coûteuses » comme vérifier les noms et extensions de fichiers pour décider quand utiliser des règles « coûteuses » comme exécuter des regex sur le contenu des fichiers, analyser les certificats pour voir s'ils contiennent des clés privées, etc. C'est ce qui permet à Snaffler d'atteindre une inspection assez profonde des fichiers là où c'est nécessaire, tout en étant étonnamment rapide pour un outil écrit dans un langage de haut niveau comme C#.

Par exemple, un ensemble de règles très simple pourrait contenir :
* une règle pour jeter tous les fichiers avec des extensions associées aux fichiers image
* une règle pour trouver tous les fichiers avec l'extension `.dmp` et les snaffler
* une chaîne de règles où :
  * la première règle cherche les fichiers avec l'extension `.ps1`, et envoie tous les fichiers correspondants à la fois à la deuxième et à la troisième règle.
  * la deuxième règle regarde à l'intérieur des fichiers en utilisant des regex conçus pour trouver des identifiants codés en dur dans du code PowerShell.
  * la troisième règle regarde à l'intérieur des fichiers en utilisant des regex conçus pour trouver des identifiants codés en dur dans des commandes `cmd.exe`, comme on pourrait en trouver dans des fichiers `.bat` ou `.cmd`, car ceux-ci sont aussi couramment utilisés dans des scripts PowerShell.

Cette approche nous permet également de maintenir un ensemble de règles relativement gérable et lisible, et facilite aussi grandement la personnalisation des valeurs par défaut ou le développement de vos propres ensembles de règles par l'utilisateur final (vous).

### Je ne veux pas écrire de règles, ça a l'air dur et ennuyeux.

Tu as raison, ça l'était.

Snaffler est livré avec un ensemble de règles par défaut intégré dans l'`.exe`. Vous pouvez les voir dans `./Snaffler/SnaffRules/DefaultRules`.

### Je suis un puissant titan de la monotonie, un maître du banal, je souhaite écrire mon propre ensemble de règles.

Pas de problème, espèce d'énorme original. Vous avez 2 options.

1. Modifiez ou remplacez les règles dans le répertoire `DefaultRules`, puis construisez un nouveau Snaffler. Les fichiers `.toml` de ce répertoire seront intégrés dans l'`.exe` en tant que ressources, et chargés à l'exécution chaque fois que vous ne spécifiez pas d'autres règles à utiliser.
2. Créez un répertoire et mettez-y un tas de vos propres fichiers de règles, puis exécutez Snaffler avec `-p .\path\to\rules`. Snaffler analysera tous les fichiers `.toml` de ce répertoire et utilisera l'ensemble de règles résultant. Cela fonctionnera aussi si vous les avez tous dans un seul gros fichier `.toml`.

Voici quelques exemples annotés qui, espérons-le, aideront à mieux expliquer les choses. Si cela semble très difficile, vous pouvez simplement utiliser nos règles et elles vous trouveront probablement de bonnes choses.

Ceci est un exemple de règle qui fera ignorer à Snaffler tous les fichiers et sous-répertoires en dessous d'un répertoire portant un certain nom.```toml
[[ClassifierRules]]
EnumerationScope = "DirectoryEnumeration" # This defines which phase of the discovery process we're going to apply the rule. 
                                          # In this case, we're looking at directories. 
                                          # Valid values include ShareEnumeration, DirectoryEnumeration, FileEnumeration, ContentsEnumeration
RuleName = "DiscardLargeFalsePosDirs" # This can be whatever you want. We've been following a rough naming scheme, but you can call it "Stinky" if you want. ¯\_(ツ)_/¯
MatchAction = "Discard"# What to do with things that match the rule. In this case, we want to discard anything that matches this rule.
                        # Valid options include: Snaffle (keep), Discard, Relay (example of this below), and CheckForKeys (example below)
Description = "File paths that will be skipped entirely." # Not used in the code, just a place for notes really.
MatchLocation = "FilePath" # What part of the file/dir/share to look at to check for a match. In this case we're looking at the whole path.
                           # Valid options include: ShareName, FilePath, FileName, FileExtension, FileContentAsString, FileContentAsBytes,
                           # although obviously not all of these will apply in all EnumerationScopes.
WordListType = "Contains" # What matching logic to apply, valid options are: Exact, Contains, EndsWith, StartsWith, or Regex.
                          # Under the hood these all get turned into regexen one way or another.
MatchLength = 0
WordList = [ 
  # A list of strings or regex patterns to use to match. If using regex patterns, WordListType must be Regex.
	"\\\\puppet\\\\share\\\\doc",
	"\\\\lib\\\\ruby",
	"\\\\lib\\\\site-packages",
	"\\\\usr\\\\share\\\\doc",
	"node_modules",
	"vendor\\\\bundle",
	"vendor\\\\cache",
	"\\\\doc\\\\openssl",
	"Anaconda3\\\\Lib\\\\test",
	"WindowsPowerShell\\\\Modules",
	"Python27\\\\Lib"
]
Triage = "Green" # If we find a match, what severity rating should we give it. Valid values are Black, Red, Yellow, Green. This value is ignored for Discard MatchActions.
```
Cette règle, en revanche, examinera les extensions de fichiers et ignorera immédiatement celles que nous n'aimons pas.

Dans ce cas, je jette principalement les polices, images, CSS, etc.```toml
[[ClassifierRules]]
EnumerationScope = "FileEnumeration" # We're looking at the actual files, not the shares or dirs or whatever.
RuleName = "DiscardExtExact" # just a name
MatchAction = "Discard" # We're discarding these
MatchLocation = "FileExtension" # This time we're only looking at the file extension part of the file's name.
WordListType = "Exact" # and we only want exact matches. 
WordList = [".bmp", ".eps", ".gif", ".ico", ".jfi", ".jfif", ".jif", ".jpe", ".jpeg", ".jpg", ".png", ".psd", ".svg", ".tif", ".tiff", ".webp", ".xcf", ".ttf", ".otf", ".lock", ".css", ".less"] # list of file extensions.
```
Voici un exemple d'une règle très simple pour les choses que nous aimons et que nous voulons conserver.```toml
[[ClassifierRules]]
EnumerationScope = "FileEnumeration" # Still looking at files
RuleName = "KeepExtExactBlack" # Just a name
MatchAction = "Snaffle" # This time we are 'snaffling' these. This usually just means send it to the output, 
                       # but if you turn on the appropriate option it will also grab a copy.
MatchLocation = "FileExtension" # We're looking at file extensions again
WordListType = "Exact" # With Exact Matches
WordList = [".kdbx", ".kdb", ".ppk", ".vmdk", ".vhdx", ".ova", ".ovf", ".psafe3", ".cscfg", ".kwallet", ".tblk", ".ovpn", ".mdf", ".sdf", ".sqldump"] # and a bunch of fun file extensions.
Triage = "Black" # these are all big wins if we find them, so we're giving them the most severe rating.
```
Celui-ci est fondamentalement le même, mais nous examinons le nom complet du fichier. Simple!```toml
[[ClassifierRules]]
EnumerationScope = "FileEnumeration"
RuleName = "KeepFilenameExactBlack"
MatchAction = "Snaffle"
MatchLocation = "FileName"
WordListType = "Exact"
WordList = ["id_rsa", "id_dsa", "NTDS.DIT", "shadow", "pwd.db", "passwd"]
Triage = "Black"
```
Celui-ci est assez ingénieux, jetez-y un œil...```toml
[[ClassifierRules]]
EnumerationScope = "FileEnumeration" # we're looking for files...
RuleName = "KeepCertContainsPrivKeyRed" 
MatchLocation = "FileExtension" # specifically, ones with certain file extensions...
WordListType = "Exact"
WordList = [".der", ".pfx"] # specifically these ones...
MatchAction = "CheckForKeys" # and any that we find, we're going to parse them as x509 certs, and see if the file includes a private key!
Triage = "Red" # cert files aren't very sexy, and you'll get huge numbers of them in most wintel environments, but this check gives us a way better SNR!
```
OK, c'est là que les choses puissantes arrivent. Nous avons une paire de règles enchaînées ici.

Les fichiers dont les extensions correspondent à la première règle seront envoyés à la seconde règle, qui va "grep" (c'est-à-dire String.Contains()) leur contenu pour des éléments d'une liste de mots spécifique.

Vous pouvez les enchaîner autant que vous le souhaitez, même si je suppose que vous commencerez à rencontrer des problèmes de performances si vous devenez trop "inception" avec cela.```toml
[[ClassifierRules]]
EnumerationScope = "FileEnumeration" # this one looks at files...
RuleName = "ConfigGrepExtExact"
MatchLocation = "FileExtension" # specifically the extensions...
WordListType = "Exact"
WordList = [".yaml", ".xml", ".json", ".config", ".ini", ".inf", ".cnf", ".conf"] # these ones.
MatchAction = "Relay" # Then any files that match are handed downstream...
RelayTargets = ["KeepConfigGrepContainsRed"] # To the rule with this RuleName! This can also be an array of RuleNames if you want to get real wild and start writing branching rulesets.

[[ClassifierRules]]
RuleName = "KeepConfigGrepContainsRed" # Anyway, this is the target rule. Following a naming convention really helps to make sure you're using the right targets.
EnumerationScope = "ContentsEnumeration" # this one looks at file content!
MatchAction = "Snaffle" # it keeps files that match
MatchLocation = "FileContentAsString" # it's looking at the contents as a string (rather than a byte array)
WordListType = "Contains" # it's using simple matching
WordList = ["password=", " connectionString=\"", "sqlConnectionString=\"", "validationKey=", "decryptionKey=", "NVRAM config last updated"]
Triage = "Red"
```
Espérons que cela donne une idée. Je recommande de prendre certaines des règles par défaut et de les modifier jusqu'à ce que vous ayez une bonne maîtrise.

## WTF est un "UltraSnaffler" ???

Beaucoup de gens voulaient la possibilité de regarder à l'intérieur de formats de fichiers qui n'étaient pas seulement du texte brut, comme les documents Word, les PDF, les `.eml`, etc. Malheureusement, la bibliothèque la plus simple pour implémenter cette fonctionnalité a fait exploser la taille finale du fichier `Snaffler.exe` d'environ 1200 %, ce qui était embêtant pour un tas de techniques populaires d'exécution en mémoire qui avaient des limites supérieures sur la taille de fichier avec laquelle elles pouvaient être utilisées.

La solution était UltraSnaffler, qui est simplement un deuxième fichier `.sln` qui active la bibliothèque requise et le code correspondant. Compilez `UltraSnaffler.sln`, obtenez UltraSnaffler.

AVERTISSEMENT : Les règles par défaut de Snaffler n'incluent aucune qui examine les documents Office ou les PDF, car nous avons trouvé très difficile d'en écrire qui ne prendraient pas des *années* pour terminer une exécution dans un environnement d'entreprise typique. *Sachez que regarder à l'intérieur de ces documents est beaucoup plus lent que de regarder à l'intérieur des bons vieux fichiers texte, et un environnement typique contiendra une montagne absolue de documents Office et de PDF de faible valeur.*

## Comment fonctionne le truc du fichier de configuration ?

C'est en fait vraiment sympa à mon avis.

Si vous ajoutez `-z generate` à la fin d'une ligne de commande de Snaffler, Snaffler sérialisera l'objet de configuration (incluant tous les aspects de la configuration définis par vos arguments) dans un fichier de configuration `.toml`, que vous pouvez ensuite éditer manuellement assez facilement (ou pas) et réutiliser à votre guise.

Par exemple, si vous faites :

`Snaffler.exe -s -o C:\mydir\snaffler.log -v trace -i \\host.lol.domain\share -p C:\users\someguy\myrules -z generate`

Snaffler analysera tous vos très nombreux arguments, les transformera en un objet de configuration, sérialisera cet objet de configuration dans le fichier de configuration `.toml` suivant :```toml
PathTargets = ["\\\\host.lol.domain\\share"]
ComputerTargetsLdapFilter = "(objectClass=computer)"
ScanSysvol = true
ScanNetlogon = true
ScanFoundShares = true
InterestLevel = 0
DfsOnly = false
DfsShareDiscovery = false
DfsNamespacePaths = []
CurrentUser = "l0sslab\\l0ss"
RuleDir = "C:\\users\\someguy\\myrules"
MaxThreads = 60
ShareThreads = 20
TreeThreads = 20
FileThreads = 20
MaxFileQueue = 200000
MaxTreeQueue = 0
MaxShareQueue = 0
LogToFile = true
LogFilePath = "C:\\mydir\\snaffler.log"
LogType = "Plain"
LogTSV = false
Separator = 32
LogToConsole = true
LogLevelString = "trace"
ShareFinderEnabled = false
LogDeniedShares = false
DomainUserRules = false
DomainUserMinLen = 6
DomainUserNameFormats = ["sAMAccountName"]
DomainUserMatchStrings = ["sql", "svc", "service", "backup", "ccm", "scom", "opsmgr", "adm", "adcs", "MSOL", "adsync", "thycotic", "secretserver", "cyberark", "configmgr"]
DomainUsersWordlistRules = ["KeepConfigRegexRed"]
MaxSizeToGrep = 1000000
Snaffle = false
MaxSizeToSnaffle = 10000000
MatchContextBytes = 200
```
Vous remarquerez qu'il y a beaucoup d'éléments ici pour lesquels vous n'avez passé aucun argument. Ces valeurs sont les éléments de configuration par défaut, dont certains ne peuvent être modifiés facilement que dans la source ou via un fichier de configuration, généralement parce que cela ne semblait pas valoir la peine d'ajouter un argument pour eux.

## C'est nul, avez-vous prévu de le rendre moins nul ?

Non ça ne l'est pas, c'est toi qui es nul.

Et oui, nous avons des plans.

Nous allons aussi : 
 - Ajouter l'analyse des fichiers d'archive, idéalement en les traitant comme un répertoire supplémentaire à parcourir à la recherche de bons plans.
 - Continuer à affiner les règles et les expressions régulières. **Plus de mots pour les listes de mots ! `string[]`s pour le trône `string` !**

![Une blague stupide sur les listes de mots.](https://assets.kitploit.com/production/public/readmes/5041/ac1d2a65e3759820b6eaaf47c893ec06661ce5db74c26d60eb424fabfe29a11f.png)

## De qui avez-vous volé du code ?

Les parties liées à l'énumération des partages ont été chapardées (tu vois le jeu de mots ?) de SharpShares, écrit par l'extrêmement utile Dwight Hohnstein. (https://github.com/djhohnstein/SharpShares/)
Le profil GitHub de Dwight est comme ce superbe rayon du fond dans une quincaillerie où se trouvent tout un tas d'outils qui te font dire « oh purée j'ai hâte d'avoir une excuse pour essayer celui-ci pour de vrai... » et tu devrais vraiment y jeter un œil.

Bien qu'aucun code n'ait été copié (surtout parce que c'est du Ruby lol), nous avons volé un tas d'idées sympas de `plunder2` (http://joshstone.us/plunder2/)

Les listes de mots ont également été organisées à partir de celles trouvées dans d'autres outils similaires comme trufflehog, shhgit, gitrobber et graudit.

## Est-ce que c'est OPSEC safe ? (Quoi que ça puisse bien vouloir dire)

Pfft, non. C'est super bruyant.

Écoute, disons les choses ainsi… Si c'est le genre d'environnement où tu te sentirais à l'aise de lancer BloodHound en mode par défaut, alors euh, ouais mon pote… C'est vraiment furtif.

## Je croyais que tu utilisais ce truc sur des missions red team ?

*soupir* 

OK, je vais te donner la vraie réponse.

En mode par défaut, Snaffler ressemble beaucoup à SharpHound, à bien des égards. Il envoie pas mal de requêtes LDAP vers l'AD, puis il essaie de parler SMB à chaque machine Windows du domaine. Ce genre de comportement est quasiment garanti de te faire pincer dans une organisation qui a un peu son affaire en ordre.

CEPENDANT…

Les options plus ciblées de Snaffler (en particulier `-i`) sont *beaucoup* moins susceptibles de déclencher des détections.

Je suis particulièrement fan de lancer `Snaffler.exe -s -i C:\` sur un serveur ou une station de travail fraîchement compromise, et je n'ai jamais vu ce comportement être détecté.

Pour l'instant.

## Comment puis-je aider ou obtenir de l'aide ?

Si tu veux discuter via Slack, tu peux nous envoyer un message (@l0ss ou @Sh3r4) sur le Slack de BloodHound, accessible à https://bloodhoundgang.herokuapp.com/, ou discuter avec un groupe de contributeurs dans le canal #snaffler.

Tu peux aussi nous contacter sur Twitter – @mikeloss et @sh3r4_hax

Sinon, ouvre un ticket ; on essaiera.