Elastic pour les analystes sécurité. Partie 1: Recherche de chaînes.

Objectif :

Avec Elastic qui accroît sa présence dans le domaine de la cybersécurité grâce à la rapidité et à l’évolutivité de sa solution, nous nous attendons à accueillir davantage de nouveaux utilisateurs Elastic. Ces utilisateurs aborderont Elastic avec une intuition construite à partir de leur expérience avec d’autres plateformes et SIEMs. Souvent, cette intuition sera directement remise en question après quelques recherches dans Elastic. Le but de cette série est de permettre aux analystes de sécurité de se familiariser avec l’unicité d’Elastic. Ce post fournit aux lecteurs un guide pour construire des recherches appropriées sur les données de type chaîne dans Elastic.Comprendre incorrectement comment les Texte et les Mots-clés analysés et non analysés peuvent affecter la recherche de données basées sur des chaînes peut entraîner des résultats trompeurs. En lisant cet article, vous serez mieux équipé pour effectuer des recherches sur des chaînes qui correspondent à vos intentions analytiques.

Aperçu :

1. Avant de commencer
2. Quel type de données utilisez-vous ?
3. Résumé des différences
4. Différence 1 : Tokenisation et termes
5. Différence 2 : Sensibilité à la casse
6. Différence 3 : Correspondance des symboles

Avant de commencer :

Lucene

Ce billet utilise Lucene. KQL ne prend pas encore en charge les expressions régulières et nous en avons besoin.

Termes : Types de données, Mappings et Analyseurs :

Lorsqu’on discute de la façon dont les données sont stockées dans les index d’Elastic, il faut être familier avec les termes Mappings, Types de données et Analyseurs.

• Type de données – Le « type », « type de données » ou « type de données » sous lequel une valeur est stockée/indexée. Exemples de types de données : Chaîne, Booléen, Entier et IP. Les chaînes sont stockées/indexées en tant que «Texte » ou «Mots-clés » type de données.
• Mapping – C’est le paramètre qui assigne (mappe) chaque champ à un type de données. Accessible via l’API get mapping. Lorsque vous « récupérez le mapping », le type de données est renvoyé pour le champ auquel il est mappé.
• Analyseur – avant que les données de type chaîne ne soient stockées/indexées, la valeur est prétraitée pour optimiser le stockage et la recherche. Les analyseurs aident à rendre la recherche contre des chaînes rapide.

Comment les chaînes sont stockées :

Il existe deux principaux types de données pour les chaînes : Mots-clés and Texte.

1. Mots-clés – les chaînes de type Mots-clés sont stockées avec leur valeur brute. Aucun analyseur n’est appliqué.
2. Texte – les chaînes de type Texte sont analysées. L’analyseur par défaut et le plus courant est l’ analyseur standard (texte). Dans cet article, lorsque nous parlons du type de données «Texte », nous faisons référence au type de données avec l’analyseur standard. Il existe d’autres analyseurs, et des analyseurs personnalisés sont possibles. Texte datatype with the standard analyzer. There are other analyzers, and custom analyzers are possible.

Quel type de données utilisez-vous ?

Il est fort probable que votre instance Elastic utilise à la fois les types de données Texte and Mots-clés pour les chaînes. Cependant, l’Elastic Common Schema (ECS) et Winlogbeat utilisent principalement le type de données Mots-clés .

Même si vous utilisez ECS, les administrateurs peuvent personnaliser les mappings ! Pour savoir avec certitude comment un champ est mappé, vous devez interroger votre instance Elastic. Pour ce faire, vous pouvez utiliser l’API ​get field mapping​ ou l’API ​​get mapping​. Il est bon de se tenir informé des derniers mappings pour les champs que vous interrogez régulièrement ou sur lesquels vous avez construit du contenu. Les mappings peuvent changer tandis que les noms de champs peuvent rester les mêmes. En d’autres termes, le champ « Mots-clés » d’aujourd’hui pourrait être un champ « Texte » demain.

Les différences notables entre Mots-clés and Texte sont détaillées dans la section ci-dessous. De plus, chaque différence qui affectera les résultats de recherche sera explorée dans sa propre section.

Résumé des différences

Nous ne nous attendons pas à ce que vous examiniez cette section et que vous compreniez immédiatement pourquoi les types correspondent lorsqu’ils le font. Chacune des différences est développée dans sa propre section. Chacun des exemples dans les tableaux est également placé dans un tableau au sein de la section qui explique le comportement.

Différences

Le tableau suivant fournit un aperçu des principales différences dans les types de données.

Différences de comportement

Le tableau suivant fournit des exemples réels de la façon dont les types affectent le comportement de recherche.

_

Différence 1 : Analyseur, Tokenisation et Termes

Différence

Pourquoi…?

The Texte Le type de données / analyseur standard utilise la tokenisation qui divise une chaîne en morceaux (tokens). Ces tokens sont basés sur les limites des mots (par exemple : un espace), la ponctuation et plus.

À titre d’exemple, si nous tokenisons la chaîne suivante avec l’analyseur standard :« rechercher des choses avec Elastic est simple »Les termes résultants seraient :« rechercher » | « des » | « choses » | « avec » | « elastic » | « est » | « simple »Tenez compte du fait que tout a été tokenisé sur des espaces (limites des mots), est maintenant en minuscule, et que le « s » a été retiré du mot choses.

La tokenisation permet de faire correspondre des termes individuels sans utiliser de contient ou de jokers. Par exemple, si nous effectuons une recherche pour « Elastic » the Texte une chaîne de type de données contenant « rechercher des choses avec Elastic est simple » correspondrait. C’est différent des autres SIEMs qui dépendent largement des jokers ou de la logique ‘contient’.

Cependant, la tokenisation se brise sur les jokers entre les termes. Par exemple, « *recherche*Elastic* » ne correspondrait pas à la chaîne analysée standard « rechercher avec Elastic est simple ».Remarque : Vous pouvez y remédier avec la proximité, mais l’ordre n’est pas maintenu. Par exemple, « recherche Elastic »~1 correspondrait à « rechercher avec Elastic » et « Elastic avec rechercher ».

 Souvent, en sécurité, nous avons besoin de correspondance exacte et de la possibilité d’utiliser des jokers entre les termes. C’est une des raisons pour lesquelles le Mots-clés type de données est devenu le type de données par défaut dans ECS. Ce que vous perdez en vitesse, vous le gagnez en possibilité d’effectuer des recherches plus précises.

Exemples

_

Différence 2 : Sensibilité à la casse

Différence

Pourquoi…?

Les problèmes de sensibilité à la casse sont l’une des principales causes de confusion dans le comportement d’Elastic en tant qu’analyste de sécurité. C’est particulièrement vrai pour les Mots-clés types de données (bonjour la foule ECS). Un seul caractère hors de la casse dans un journal peut empêcher une requête mal construite de correspondre aux champs Mots-clés . Lorsque qu’un attaquant contrôle certaines parties des données qui entrent dans Keywords (pensez aux événements Windows 4688 & 4104), vous devriez utiliser des expressions régulières pour assurer une insensibilité à la casse !De plus, Elastic ne vous avertira pas si un document a été à peine manqué à cause d’un seul caractère mal orthographié. Ainsi, les résultats manquants ou trop nombreux sont une cause majeure de confusion pour un analyste de sécurité.

Voici un exemple de base de correspondance contre « PoWeRsHeLl ». Remarquez comment il ne suffit que d’un seul caractère incorrect pour que la requête ne correspond pas.

Pour un exemple réel dans Kibana. Dans l’image ci-dessous, le champ de type « process.args » est interrogé pour la chaîne « windows ». Pour un analyste non averti, cela peut sembler suffisant… 42 résultats ont été renvoyés. Eh bien, s’ils espéraient obtenir n’importe quel document contenant « windows », ils auraient tort. Comme la recherche est sensible à la casse, « Windows » ne correspondra pas. Mots-clés type field “process.args” is queried for the string “windows”. To an unsuspecting analyst this may seem good enough… 42 results were returned. Well if they were hoping to obtain any document containing “windows” they would be wrong. As the search is case sensitive, therefore “Windows” would not match.

Résultats limités à partir d’une recherche sensible à la casse

Dans la requête ci-dessous, l’utilisation d’une expression régulière pour rechercher « windows » renvoie respectivement 567 résultats qui étaient auparavant « manquants » !

Résultats maximum

Espérons qu’il est maintenant clair que si nous recherchons en utilisant le type de Mots-clés type et que nous n’utilisons pas d’expression régulière, alors nous manquerons les variations de « powershell » au-delà d’une correspondance exacte. Soyez averti contre l’utilisation de KQL (qui ne supporte pas les regex) pour correspondre aux données que l’attaquant contrôle.Remarque : Il existe des cas où vous souhaiterez des correspondances sensibles à la casse dans les champs du mot-clé tels que pour base64.Vous pouvez rendre n’importe quelle requête insensible à la casse en utilisant des ensembles de caractères regex. Voici des exemples :

Exemples

_

Différence 3 : Correspondance des symboles

Différence

Pourquoi ?

Tous les symboles sont conservés par le type Mots-clés puisque l’ensemble du champ est conservé exactement tel que les données sont saisies (voir note). Cependant, pour l’analyseur standard une règle générale à suivre est que les symboles ne seront pas conservés. Cela est dû au fait que l’analyseur est fait pour la correspondance de mots entiers et que les symboles ne sont pas des mots. En d’autres termes, les symboles ne sont (pour la plupart) pas stockés dans l’analyseur standard. Donc, Si vous avez l’intention de correspondre à des symboles, il est préférable d’utiliser le Mots-clés type de données. Si vous n’avez qu’un champ texte et que vous devez correspondre à un groupe de symboles, vous n’avez pas de chance. Cependant, il existe des contextes où les symboles seront conservés dans l’analyseur standard. Par exemple, les points seront conservés dans des termes comme « cmd.exe ». Les auteurs estiment que la façon la plus simple de comprendre quand les symboles seront conservés dans l’analyseur standard est de simplement tester des données via l’API analyze.

Exemples

_

Conclusion

Elastic est un outil puissant. Cependant, il peut également être trompeur. J’espère que nous vous avons armé d’un peu plus de connaissances et de la puissance pour chercher en toute confiance contre des données basées sur des chaînes.

Si vous avez l’impression d’avoir besoin d’aide pour rédiger du contenu pour Elastic, le Threat Detection Marketplace de SOC Prime regorge de contenu de détection qui fonctionne avec notre configuration Elastic suggérée.

Publications futures

Restez à l’écoute pour d’autres articles de blog explorant les fondamentaux et les non-fondamentaux de l’utilisation d’Elastic en tant qu’analyste de sécurité.

Ressources supplémentaires pour la recherche :

Cette série se concentre sur les points de douleur courants pour les analystes sans approfondir le sujet de la syntaxe. Elastic fournit une documentation détaillée sur leur syntaxe Lucene. De plus, il y a plusieurs fiches de triche de qualité dans la communauté : notamment celle de McAndre and Florian Roth et Thomas Patzke.

Meta :

Publié – Mars 2020

Dernière mise à jour – 12 Mars

Auteurs – Adam Swan (@acalarch) avec l’aide de Nate Guagenti (@neu5ron)

Version d’Elastic utilisée : 7.5.2

Logs utilisés dans les exemples : https://github.com/sbousseaden/EVTX-ATTACK-SAMPLES