L'ETW du noyau est le meilleur ETW

Préambule

Une caractéristique essentielle des logiciels sécurisés par conception est la génération de journaux d'audit lorsque des opérations privilégiées sont effectuées. Ces journaux d'audit natifs peuvent contenir des détails sur l'état interne du logiciel, ce qui n'est pas pratique pour les fournisseurs de sécurité tiers qui les ajoutent après coup.

La plupart des composants Windows génèrent des journaux à l'aide de Event Tracing for Windows (ETW). Ces événements révèlent certains des mécanismes internes de Windows, et il existe des scénarios dans lesquels les produits de sécurité des points d'accès bénéficient d'un abonnement à ces événements. En matière de sécurité, cependant, tous les fournisseurs d'ETW ne sont pas égaux.

La première considération est généralement la fiabilité du fournisseur d'événements lui-même - en particulier, l'endroit où l'enregistrement a lieu. S'agit-il d'un processus client qui est trivialement vulnérable aux manipulations de l'ETW? Ou bien est-ce un peu plus sûr dans le cadre d'un processus de serveur RPC ? Idéalement, les données télémétriques proviendront du noyau. Compte tenu de la limite de sécurité entre l'utilisateur et le noyau, cela permet d'obtenir des garanties anti-fraude plus solides pour la télémétrie au sein du processus. C'est l'approche recommandée par Microsoft. Comme Elastic Endpoint, Microsoft Defender for Endpoint utilise également l'ETW du noyau plutôt que les crochets fragiles du mode utilisateur ntdll.

Par exemple, un adversaire peut être en mesure d'éviter facilement un crochet en mode utilisateur sur ntdll!NtProtectVirtualMemory, mais il est beaucoup plus difficile de contourner un événement PROTECTVM ETW du noyau. Ou, du moins, il devrait l'être.

Le journal des événements de sécurité n'est en fait qu'un stockage permanent des événements provenant du fournisseur ETW Microsoft-Windows-Security-Auditing. Il est surprenant de constater que l' événement de sécurité 4688 concernant la création de processus n'est pas un événement du noyau. Le noyau transmet les données au service de l'autorité de sécurité locale (lsass.exe), émettant un événement ETW que le journal des événements peut consommer. Les données peuvent donc être altérées à partir de ce processus de serveur. Comparez cela à l'événement ProcessStart du fournisseur Microsoft-Windows-Kernel-Process, qui est enregistré directement par le noyau et dont l'interférence nécessite des privilèges au niveau du noyau.

La deuxième considération est la fiabilité des informations enregistrées. Vous pouvez faire confiance à la source de l'événement, mais que se passe-t-il si elle se contente d'enregistrer aveuglément des données fournies par le client qui sont extrinsèques à l'événement enregistré ?

Dans cet article, nous nous concentrerons sur les événements de l'ETW du noyau. Ce sont généralement les plus importants sur le plan de la sécurité, car ils sont difficiles à contourner et concernent souvent des actions privilégiées effectuées pour le compte d'un thread client.

Lorsque Microsoft a introduit le système Kernel Patch Protection, les fournisseurs de solutions de sécurité ont été considérablement limités dans leur capacité à surveiller le noyau. Compte tenu du nombre limité de points d'extension du noyau fournis par Microsoft, ils ont été de plus en plus contraints de s'appuyer sur des événements ETW asynchrones pour obtenir une visibilité a posteriori des actions du noyau effectuées pour le compte de logiciels malveillants.

Compte tenu de cette dépendance, la documentation publique sur les sources de télémétrie du noyau Windows est malheureusement assez rare.

Événements de l'ETW du noyau

Il existe actuellement quatre types de fournisseurs d'ETW que nous devons prendre en considération.

Tout d'abord, il existe des variantes anciennes et modernes du terme "fournisseur d'événements" :

• fournisseurs d'événements hérités(basés sur le mof)
• fournisseurs d'événements modernes(basés sur des manifestes)

Il existe également des variantes anciennes et modernes du terme "fournisseur de services de traçage" :

• les fournisseurs de traces de l'ancien préprocesseur de traces logicielles Windows(WPP)
• fournisseurs modernes de traces TraceLogging

La distinction entre "événement" et "trace" est essentiellement sémantique. Les fournisseurs d'événements sont généralement enregistrés à l'avance auprès du système d'exploitation, et vous pouvez consulter les métadonnées de télémétrie disponibles. Elles sont généralement utilisées par les administrateurs système à des fins de dépannage et sont souvent semi-documentées. Mais lorsque quelque chose va vraiment, vraiment mal, il y a des fournisseurs de services de traçage (cachés). Elles ne sont généralement utilisées que par les auteurs du logiciel original pour un dépannage avancé et ne sont pas documentées.

Dans la pratique, chacun utilise un fichier de format légèrement différent pour décrire et enregistrer ses événements, ce qui introduit des différences mineures dans la manière dont les événements sont enregistrés et, plus important encore, dans la manière dont les événements potentiels peuvent être énumérés.

Fournisseurs d'événements du noyau moderne

Les fournisseurs d'ETW des noyaux modernes ne sont pas strictement documentés. Cependant, les détails des événements enregistrés peuvent être interrogés à partir du système d'exploitation via l'API Trace Data Helper. L'outil PerfView de Microsoft utilise ces API pour reconstruire le manifeste d'enregistrement du fournisseur, et EtwExplorer de Pavel Yosifovich intègre ensuite ces manifestes dans une interface graphique simple. Vous pouvez utiliser ces fichiers de valeurs séparées par des tabulations pour les manifestes enregistrés des versions successives de Windows. Une seule ligne par événement est très utile pour la recherche, bien que d'autres aient depuis publié les manifestes XML bruts.

Il ne s'agit cependant pas de tous les événements Windows ETW possibles. Il s'agit uniquement de ceux qui sont enregistrés par défaut dans le système d'exploitation. Par exemple, les événements ETW pour de nombreux rôles de serveur ne sont pas enregistrés tant que cette fonctionnalité n'est pas activée.

Fournisseurs d'événements du noyau hérité

Les anciens événements du noyau sont documentés par Microsoft. En grande partie.

Les fournisseurs traditionnels existent également au sein du système d'exploitation sous la forme de classes WMI EventTrace. Les fournisseurs sont les classes racines, les groupes sont les enfants et les événements sont les petits-enfants.

Pour rechercher les événements hérités de la même manière que les événements modernes, ces classes ont été analysées et le MOF original (en grande partie) reconstruit. Ce support MOF a été ajouté à EtwExplorer, et des résumés de valeurs séparées par des tabulations des événements hérités de ces classes ont été analysés et le MOF original (en grande partie) reconstruit. Ce support MOF a été ajouté à EtwExplorer et des résumés de valeurs séparées par des onglets des événements hérités ont été publiés.

Le MOF de Windows Kernel Trace entièrement reconstruit se trouve ici (ou sous forme de tableau ici).

Sur les 340 événements patrimoniaux enregistrés, seuls 116 ont été documentés. En règle générale, chaque événement hérité doit être activé au moyen d'un drapeau spécifique, mais ces drapeaux n'ont pas été documentés non plus. Il y avait un indice dans la documentation sur les événements de trace du gestionnaire d'objets du noyau. Il mentionne PERF_OB_HANDLE, une constante qui n'est pas définie dans les en-têtes du dernier SDK. Heureusement, Geoff Chappell et le Windows 10 1511 WDK sont venus à la rescousse. Ces informations ont été utilisées pour ajouter à la bibliothèque KrabsETW de Microsoft la prise en charge des drapeaux de trace du noyau PERFINFO_GROUPMASK. Il s'est également avéré que la documentation sur le suivi des objets était erronée. Cette constante non publique ne peut être utilisée qu'avec une extension d'API non documentée. Heureusement, les projets publics de Microsoft tels que PerfView fournissent souvent des exemples d'utilisation d'API non documentées.

Avec les manifestes et les MOFs publiés sur GitHub, la plupart des événements du noyau peuvent maintenant être trouvés avec cette requête.

Il est intéressant de noter que Microsoft obscurcit souvent les noms des événements liés à la sécurité, de sorte que la recherche d'événements avec un préfixe générique tel que task_ donne des résultats intéressants.

Parfois, le mot-clé fait allusion à l'objectif de l'événement. Par exemple, task_014 dans Microsoft-Windows-Kernel-General est activé avec le mot-clé KERNEL_GENERAL_SECURITY_ACCESSCHECK.

Et heureusement, les paramètres sont presque toujours bien nommés. Nous pouvons supposer que task_05 dans Microsoft-Windows-Kernel-Audit-API-Calls est lié à OpenProcess puisqu'il enregistre des champs nommés TargetProcessId et DesiredAccess.

Une autre requête utile consiste à rechercher des événements comportant un champ explicite ProcessStartKey. Les événements ETW peuvent être configurés pour inclure ce champ pour le processus d'enregistrement, et tout événement qui inclut cette information pour un autre processus est souvent pertinent pour la sécurité.

Si vous avez une API spécifique à l'esprit, vous pouvez demander son nom ou ses paramètres. Par exemple, si vous souhaitez connaître les événements "Named Pipe", vous pouvez utiliser la requête suivante.

Dans ce cas, Microsoft-Windows-SEC appartient aux pilotes de sécurité Microsoft intégrés que Microsoft Defender for Endpoint (MDE) utilise. Ce fournisseur n'est officiellement disponible que pour MDE, mais Sebastian Feldmann et Philipp Schmied ont démontré comment démarrer une session à l'aide d'un AutoLogger et s'abonner aux événements de cette session. Ceci n'est actuellement utile que pour les utilisateurs de MDE, car sinon, le pilote n'est pas configuré pour émettre des événements.

Mais qu'en est-il des fournisseurs de services de traçage ?

Fournisseurs de services de traçage du noyau moderne

Les métadonnées de TraceLogging sont stockées sous la forme d'un blob opaque dans le binaire de journalisation. Heureusement, ce format a été inversé par Matt Graeber. Nous pouvons utiliser le script de Matt pour extraire toutes les métadonnées de TraceLogging pour ntoskrnl.exe. Vous trouverez ici un exemple de vidage des métadonnées de Windows 11 TraceLogging.

Malheureusement, la structure des métadonnées ne permet pas à elle seule de conserver la corrélation entre les fournisseurs et les événements. Il existe des noms de fournisseurs intéressants, tels que Microsoft.Windows.Kernel.Security et AttackSurfaceMonitor, mais notre fichier de métadonnées ne permet pas encore de déterminer clairement quels événements appartiennent à ces fournisseurs.

Fournisseurs de traces du noyau hérité

Les métadonnées WPP sont stockées dans des fichiers de symboles (PDB). Microsoft inclut ces informations dans les symboles publics pour certains pilotes, mais pas tous. Le noyau lui-même, cependant, ne produit pas d'événements WPP. Au lieu de cela, il est possible de passer des drapeaux non documentés au fournisseur d'événements Windows Kernel Trace pour activer les événements "trace" hérités qui ne sont généralement accessibles qu'aux développeurs du noyau Microsoft.

Étapes suivantes

Nous disposons maintenant de métadonnées d'événements du noyau pour chacun des quatre types de fournisseurs d'ETW, mais la liste des événements ETW n'est qu'un point de départ. Connaître le fournisseur et le mot-clé de l'événement peut ne pas suffire à générer les événements que nous attendons. Parfois, une clé de registre de configuration supplémentaire ou un appel à l'API est nécessaire. Le plus souvent, cependant, nous avons simplement besoin de comprendre les conditions exactes dans lesquelles l'événement est enregistré.

Il est essentiel de savoir exactement où et quoi est enregistré pour bien comprendre votre télémétrie et ses limites. Et, grâce aux décompilateurs facilement disponibles, nous avons la possibilité de procéder à une inversion juste suffisante. Dans IDA, nous appelons cela "appuyer sur F5". Ghidra est l'alternative open-source et prend en charge les scripts ... avec Java.

Pour l'ETW du noyau, nous sommes particulièrement intéressés par les appels EtwWrite qui sont accessibles à partir des appels système. Nous souhaitons disposer d'un maximum d'informations sur les paramètres du site d'appel, y compris les informations sur les symboles publics qui y sont associés. Cela signifie que nous devions parcourir le graphe des appels, mais aussi tenter de résoudre les valeurs possibles pour des paramètres particuliers.

Les paramètres nécessaires étaient le RegHandle et le EventDescriptor. Le premier est un identifiant opaque pour le fournisseur, et le second fournit des informations spécifiques à l'événement, telles que l'identifiant de l'événement et les mots-clés associés. Un mot-clé ETW est un identifiant utilisé pour activer un ensemble d'événements.

Mieux encore, ces descripteurs d'événements étaient généralement stockés dans une constante globale avec un symbole public.

Nous disposions de suffisamment de métadonnées sur les événements, mais il nous fallait encore résoudre le problème de l'identifiant opaque du fournisseur, attribué au moment de l'exécution, en le ramenant aux métadonnées sur le fournisseur. Pour ce faire, nous avons également besoin des appels EtwRegister.

Le modèle typique des fournisseurs d'événements modernes du noyau consistait à stocker le GUID constant du fournisseur et la poignée d'exécution dans des globales avec des symboles publics.

Les appels à EtwRegister, EtwEwrite et EtwUnregister, tous dans la même fonction, sont un autre modèle rencontré. Dans ce cas, nous avons tiré parti de la localité pour trouver le GUID du fournisseur de l'événement.

Les fournisseurs modernes de TraceLogging n'avaient cependant pas de symboles publics associés à chaque fournisseur pour donner une idée de l'objectif de chacun d'entre eux. Cependant, Matt Graeber a inversé le format des métadonnées de TraceLogging et a documenté le fait que le nom du fournisseur est stocké avec un décalage fixe par rapport au GUID du fournisseur. Il est encore mieux d'avoir le nom exact du fournisseur que le symbole public que nous avons récupéré pour les événements modernes.

Il ne reste donc plus que les fournisseurs traditionnels. Ils ne semblaient pas avoir de symboles publics ni de métadonnées. Certaines constantes sont transmises à une fonction non documentée nommée EtwTraceKernelEvent qui englobe l'éventuel appel à l'écriture de l'ETW.

Ces constantes sont présentes dans les en-têtes du WDK Windows 10 1511 (et dans les en-têtes du System Informer ), de sorte que nous pouvons étiqueter ces événements avec les noms des constantes.

Ce script a été récemment mis à jour pour Ghidra 11, avec une meilleure prise en charge des événements TraceLogging et Legacy. Vous pouvez maintenant le trouver sur GitHub ici - https://github.com/jdu2600/API-To-ETW

Vous trouverez ici un exemple de sortie pour le noyau Windows 11 .

Les événements précédemment anonymes de Microsoft-Windows-Kernel-Audit-API-Calls sont rapidement démasqués par ce script.

Symbole et fonction contenant les événements Microsoft-Windows-Kernel-Audit-API-Calls

Grâce au chemin d'appel et aux informations sur les paramètres récupérés par le script, nous pouvons également constater que l'événement SECURITY_ACCESSCHECK mentionné précédemment est associé à l'API du noyau SeAccessCheck, mais qu'il n'est enregistré que dans une fonction nommée SeLogAccessFailure. L'enregistrement des seules conditions d'échec est très fréquent dans le cas des événements ETW. Pour le dépannage, le cas d'utilisation original de l'ETW, ce sont généralement les plus utiles et la mise en œuvre dans la plupart des composants le reflète. Malheureusement, en matière de sécurité, c'est souvent l'inverse qui se produit. Les journaux des opérations réussies sont généralement plus utiles pour détecter les activités malveillantes. La valeur de certains de ces événements est donc souvent faible.

La pratique moderne Secure by Design consiste à enregistrer les succès et les échecs des activités liées à la sécurité et Microsoft continue d'ajouter de nouveaux événements ETW liés à la sécurité. Par exemple, la version préliminaire de Windows 11 24H2 inclut de nouveaux événements ETW intéressants dans le fournisseur Microsoft-Windows-Threat-Intelligence. Il est à espérer que ces éléments seront documentés à l'intention des vendeurs de produits de sécurité avant sa publication.

L'exécution de ce script de décompilation sur des pilotes Windows et des DLL de service intéressants est laissée à l'appréciation du lecteur.