Actions PRE/POST

Chaque fichier scanné peut être traité par des actions PRE et/ou POST :

• Pré-décodage : Fonctions invoquées AVANT l'exécution de la correspondance, comme le décodage base64 ou le remplacement de chaînes.
• Post-décodage : Fonctions invoquées APRÈS l'exécution de la correspondance, comme le désamorçage d'URL.

L'idée derrière les fonctions PreDecodeActions était d'utiliser des expressions régulières pour identifier une chaîne ou un motif correspondant, d'acquérir son contenu brut, d'effectuer des étapes de décodage/nettoyage définies et de renvoyer le résultat final au moteur d'analyse pour un nouveau scannage/traitement. Un exemple très simple de cela est le décodage Base64. Afin de vérifier toute logique de détection contre un shell web encodé en base64, nous devons d'abord supprimer toute couche de base64. Pour ce faire, nous pourrions utiliser la PreDecodeAction suivante :

En regardant le bloc ci-dessus, nous avons d'abord le nom de la fonction, l'expression régulière utilisée pour la correspondance, l'expression régulière de capture de données (parfois vous pouvez vouloir ajuster ce qui est capturé par rapport à ce qui correspond) et PreDecodeActions. Dans ce cas, AVANT que la fonction cm.DecodeBase64 soit appliquée au texte correspondant, le système va d'abord supprimer les éléments suivants " et '. PostDecodeActions fonctionne à l'inverse, où la sortie est vérifiée APRÈS le décodage. En utilisant ce modèle, nous pouvons créer plusieurs décodeurs personnalisés avec des fonctions PRE/POST et de décodage infinies pour répondre à la plupart des besoins d'analyse de shells web.

Détections

Une détection est une expression régulière accompagnée d'un nom et d'une description. L'idée derrière ce modèle était de rendre les détections modulaires et évolutives et de garder le contexte avec la détection réelle. Les détections partagent le même format que les attributs, à la différence que les attributs ne peuvent pas générer une détection, ils ne peuvent qu'ajouter du contexte à une détection existante. Regardons l'exemple de bloc de logique de détection ci-dessous :

En se basant sur l'expression régulière, nous pouvons voir qu'elle cherche un fichier exécutable Windows embarqué en fonction des octets magiques d'en-tête 4D 5A. Si trouvé, cela entraînerait une détection et un rapport JSON serait généré pour le fichier. Actuellement, les détections sont appliquées en fonction de l'extension du fichier ou de manière générique pour tous les types de fichiers. Par exemple, les routines de décodage pour PHP sont définies sous cm.GlobalMap.Function_Php et les balises pour les attributs sont définies sous cm.GlobalMap.Tags_Php. Les fonctions cm.GlobalMap.Function_Generics et les balises sous cm.GlobalMap.Tags_Generics s'appliquent à TOUTES les extensions de shells web en tant que fourre-tout.

Attributs

L'étiquetage d'attributs est un nouveau concept que j'ai créé qui ajoute du "contexte" à une détection existante de shell web. Les attributs seuls ne peuvent pas actuellement générer une détection par eux-mêmes. Dans un moteur de scan traditionnel, un scanner alerterait uniquement si un shell web était détecté mais fournirait peu ou pas de contexte supplémentaire sur les capacités (attributs) potentielles du shell web. Les balises d'attributs fonctionnent de la même manière que la logique de détection, mais elles n'apparaissent qu'après qu'une détection a été identifiée et ne peuvent pas générer de détections par elles-mêmes. Regardons l'exemple de logique ci-dessous :

Nous voyons que dans la structure Tags_Php, nous avons créé une nouvelle balise PHP. Lorsqu'une correspondance est trouvée lors du scan, le drapeau Attribute est vérifié et s'il est défini sur True, le shell web détecté aura la balise PHP_Database_Operations ajoutée à son rapport JSON, avec la fréquence et le bloc de texte correspondant, comme montré dans l'exemple de sortie ci-dessous :

Ces balises aident non seulement à définir ce qu'un shell web peut faire, mais elles aident également les équipes telles que les consultants RI effectuant des interventions en direct à avoir un point de pivot pour savoir où chercher potentiellement ensuite.

Prérequis

Aucun ! Téléchargez simplement le binaire pour votre système d'exploitation, fournissez le répertoire que vous souhaitez scanner (les autres arguments sont facultatifs) et laissez-le faire.

Exécution du binaire

Exécuter wsa sans arguments affiche les options suivantes :

Le seul argument requis est dir. Vous pouvez modifier les autres valeurs par défaut du programme si vous le souhaitez.

La sortie de l'analyseur sera écrite dans la console (sortie standard). Exemple ci-dessous (Pour de meilleurs résultats, redirigez la sortie standard vers un fichier json et examinez/retraitez hors ligne) :

Une fois l'analyseur terminé, il affichera les métriques globales du scan sur STDOUT, comme montré dans l'exemple ci-dessous :

{"scanned":311,"matches":122,"noMatches":189,"directory":"/webshell-master/php","scanDuration":1.4757737378333333,"systemInfo":{"hostname":"Beast","envVars":[""],"username":"beastmode","userID":"501","realName":"The Beast","userHomeDir":"/Users/beastmode"}}