Les configurations de registre conçues pour être utilisées pour le dépannage et le développement sont désormais un moyen de persistance cachée en raison du manque de visibilité des outils de sécurité tels que Autoruns. Ici, nous mettons en évidence trois façons clés dont les modules Tanium, y compris Trace et Detect, peuvent être utilisés pour déterminer rapidement l’existence de ce mécanisme de persistance relativement inconnu.
(Image : Bruno Glätsch / Pixabay)
Que faites-vous lorsqu’une nouvelle méthode de persistance est signalée du jour au lendemain sur Twitter ? Une idée : utilisez Tanium pour examiner rapidement toute activité actuelle et configurer une alerte rapide lorsqu’elle se produit. Le tout avant le petit-déjeuner.
Le 10 avril, Oddvar Moe (@oddvarmoe) a consulté Twitter pour partager son article de blog, Persistance Using Globalflags in Image File Execution Options – Masqué de autoruns.exe, qui discute d’un mécanisme de persistance via une configuration de registre qui exécute silencieusement un processus après la fin d’un autre processus « surveillé ». Cette méthode n’est actuellement pas incluse dans les emplacements de persistance répertoriés par les exécutions automatiques Sysinternals de Microsoft.
L’utilisation de Global Flags donne aux développeurs un moyen de lancer un processus après la fin d’un autre processus. Cela représente actuellement un angle mort, car Autoruns n’énumère pas ces configurations. Elles sont définies soit via l’utilisation de gflag.exe, un utilitaire trouvé dans les outils de développeurs de Microsoft, soit peuvent être effectuées avec des modifications apportées au registre par un compte administrateur.
À moins qu’une machine ne soit utilisée pour le dépannage ou pour le travail de développement, l’existence de ces configurations de registre est hautement suspecte et doit faire l’objet d’une enquête. Cela sera fait ci-dessous, et sert d’exemple de scénario démontrant à quelle vitesse vous pouvez prendre les détails nouvellement divulgués et évaluer votre propre environnement.
Ici, nous soulignons comment les modules Tanium, y compris Trace et Signals, peuvent être utilisés pour déterminer rapidement l’existence de ce mécanisme de persistance relativement inconnu de trois manières clés :
- En examinant l’état actuel des paramètres du registre ;
- En examinant l’historique des modifications du registre avec Trace ; et
- En établissant des alertes en temps réel pour les modifications apportées à ces paramètres de registre à l’avenir.
À propos du problème
Le billet de blog de Moe met en évidence trois modifications de registre qui établissent un déclencheur d’exécution qui lance un processus chaque fois qu’un processus surveillé se termine. De plus, lorsque le processus surveillé se termine, le second processus est lancé silencieusement. En d’autres termes, s’il existe une interface graphique, elle se lance en arrière-plan. Les attaquants peuvent utiliser cette fonctionnalité comme moyen de maintenir la persistance ; faire exécuter leur code après la fin d’un processus de leur choix jusqu’à ce que les clés de registre soient supprimées.
Les détails de cette fonctionnalité Windows sont documentés par Microsoftici.
Pour les tests, le script ci-dessous effectue les modifications du registre qui entraînent l’exécution d’evil.exe à tout moment où le fichier notepad.exe se termine.
reg add "HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Image File Execution Options\notepad.exe" /v GlobalFlag /t REG_DWORD /d 512 reg add "HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\SilentProcessExit\notepad.exe" /v ReportingMode /t REG_DWORD /d 1 reg add "HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\SilentProcessExit\notepad.exe" /v MonitorProcess /d "C :\temp\evil.exe"
Activité actuelle
La recherche de signes de cette technique déjà utilisée dans l’ensemble de l’entreprise est possible via Tanium.
Il peut y avoir des utilisations légitimes de cette technique dans certains environnements, il convient donc d’effectuer un examen minutieux pour déterminer si les configurations existantes sont malveillantes ou bénignes. Un point de départ est la recherche de la ruche de registre SilentProcessExit. Dans la plupart des environnements, il doit s’agir d’une clé vide ou inexistante. Trois sensors seront utilisés pour cette enquête :
- Sous-clés de registre - Affiche tous les processus qui déclenchent l’exécution lors de leur résiliation. La figure 1, ci-dessous, montre « notepad.exe » comme seule sous-clé sous SilentProcessExit.
- Noms de valeur de clé de registre - Affiche les sous-clés existantes. La figure 1 montre MonitorProcess et ReportingMode comme les deux entrées de Nom de valeur du registre.
- Données de valeur de registre - Ces données montrent le processus configuré pour se lancer lorsque le processus surveillé se termine. La figure 1 montre les données pour les deux entrées.
Figure 1 : Exemple d’entrée utilisée pour les tests dans cet article.
Dans la Figure 2, ci-dessous, le sensor Tanium Registry Key Subkeys affiche l’entrée de sous-clé notepad.exe sous la clé SilentProcessExit.
Figure 2 : Recherche de SilentProcessExit à l’aide du capteur de sous-clés de clé de registre.
Sensor : sous-clés de registreSous-clés de registre[HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\SilentProcessExit] de toutes les machines
Pour toutes les sous-clés renvoyées par le sensor de sous-clés de clé de registre, les enquêteurs doivent copier la valeur KeyPath et l’utiliser comme paramètre dans le sensor de noms de valeurs de clé de registre pour vérifier qu’une entrée MonitorProcess existe (voir Figure 3). Si une entrée MonitorProcess existe, l’entrée ReportingMode doit également être présente.
Figure 3 : sensor de nom de valeur de clé de registre utilisé pour découvrir les sous-clés.
Sensor : Noms de valeur de clé de registreNoms de valeur de clé de registre[HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\SilentProcessExit\notepad.exe] de toutes les machines
Pour déterminer le processus à exécuter pour une entrée MonitorProcess donnée, la valeur KeyPath de la sortie des sous-clés de clé de registre et le nom de valeur de la sortie du sensor des noms de valeur de clé de registre doivent être fournis comme paramètres au sensor des données de valeur de registre (voir Figure 4).
Figure 4 : Sortie du sensor de données de valeur du registre.
Sensor : données de valeur du registreDonnées de valeur du registre[HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\SilentProcessExit\notepad.exe,MonitorProcess] de toutes les machines
En utilisant le KeyPath et le nom de valeur de la sortie du sensor comme paramètres du sensor de données de valeur du registre, nous voyons la saisie de données pour ce MonitorProcess, y compris le chemin vers l’emplacement où le processus est stocké sur le disque dans la Figure 4.
Nous voyons également dans la Figure 4 un exemple de masquage d’un processus binaire dans un flux de données alternatif (ADS). ADS est une fonctionnalité du système de fichiers NTFS, que les attaquants peuvent utiliser pour intégrer des fichiers binaires afin qu’ils ne soient pas vus dans l’Explorateur Windows ou dans les listes de répertoires normales via cmd.exe et PowerShell.exe. Notez le « : » présent dans le nom binaire du processus.
Notre exécutable masqué est intégré dans le dossier ou l’entrée de répertoire NTFS, C :\Windows et a été nommé « cmd.exe ».
Activités passées
Avec les sensors Tanium, il est possible de rechercher ces emplacements de registre spécifiques sur des centaines de milliers d’endpoints en quelques secondes.
Mais que se passe-t-il si les entrées du registre ont été supprimées après l’activité initiale ? Ils ne s’afficheront pas avec les sensors « état actuel » indiqués ci-dessus. Pour rechercher des données historiques dans l’ensemble de l’entreprise, nous examinerons le registre à l’aide des données Tanium Trace.
Nous commençons par inspecter la clé du registre SilentProcessExit pour voir si des événements SetRegistryKey ont été enregistrés (voir Figure 5).
Figure 5 : Sortie du sensor des clés de valeurs du registre de traces.
Sensor : clés ou valeurs de registre de traceObtenir des clés ou valeurs de registre de trace[illimité, 1523639748493|1523643347493, 0, 0, 10, 0, HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\SilentProcessExit, , SetValueKey, , , ] de toutes les machines
La colonne « clé » contient une entrée pour l’exécutable qui, lorsqu’elle est résiliée, entraînera le lancement de l’exécutable MonitorProcess. Les données de la colonne de clé étendue sont : HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\SilentProcessExit\notepad.exe
Étant donné que Trace n’enregistre pas les données de valeur, nous savons à ce stade qu’un processus a été configuré pour déclencher un autre processus, mais pas là où ce processus est situé. Cependant, nous pouvons ouvrir une connexion en temps réel via Trace et y jeter un coup d’œil.
Alerte
En plus de rechercher l’état actuel et les données historiques de l’entreprise, un signal Tanium Detect peut fournir des alertes en temps réel lorsque ces clés de registre sont configurées de la manière décrite ci-dessus.
group(Registry.key_path contient '\\SilentProcessExit\\' ET Registry.value_name contient 'MonitorProcess')
Avec ce signal déployé, chaque fois qu’un processus établit une persistance sous la clé SilentProcessExit en créant une entrée MonitorProcess, une alerte en temps réel se déclenchera dans l’interface Tanium Detect et ces alertes peuvent être transmises au SIEM ou aux systèmes de notification.
Comme pour toute alerte Tanium Detect, vous pouvez sélectionner l’alerte et basculer vers une connexion Trace Live pour enquêter plus en détail sur l’activité (voir Figure 6). Ici, nous voyons l’activité du processus en détail. Dans ce cas, notre processus malveillant est à nouveau intégré en tant qu’ADS, mais cette fois dans une entrée de répertoire C :\System.
Figure 6 : Alerte de signaux et option pour établir une connexion en temps réel avec Trace.
Ensuite, nous voyons l’arborescence de processus dans Trace (voir Figure 7). Il convient de noter que le processus parent du processus malveillant est WerFault.exe, le service de génération de rapports d’erreurs Windows. Notez également que le processus malveillant se lance dans le même contexte de compte d’utilisateur et non en tant que SYSTEM.
Figure 7 : Visualisation du processus dans Trace.
Le hachage du processus est surligné en rouge, indiquant que le service Tanium Reputation a classé ce fichier comme malveillant.
Maintenant, nous pouvons prendre les détails du hachage et du fichier et passer à Tanium Protect pour bloquer l’exécution future de ce processus. Nous pouvons également nettoyer le registre et tuer tous les processus existants à l’aide d’actions Tanium standard.
Exemples de signaux
Ci-dessous, nous pouvons voir les alertes Tanium Detect Signal correspondant à diverses façons d’activer ce mécanisme de persistance (voir Figures 8-13).
Figure 8 : Alerte de signal lors de l’ajout de l’entrée MonitorProcess via le fichier batch.
Figure 9 : Alerte de signal lors de l’ajout de l’entrée GlobalFlag avec un fichier batch.
Figure 10 : Alerte de signal pour ajouter manuellement l’entrée MonitorProcess à l’aide de l’interface graphique Regedit.exe.
Figure 11 : Alerte de signal lors de l’utilisation de PowerShell pour modifier le registre.
Figure 12 : Fichier de registre avec modifications de configuration.
Figure 13 : la fusion du fichier de registre à partir de la Figure 12 a généré cette alerte.
Une autre note. Une alerte IOC affichera l’ADS dans la vue détaillée, y compris l’enrichissement en couleur de hachage, comme illustré dans la Figure 14.
Figure 14 : Un résultat d’analyse IOC pour le binaire basé sur le hachage.
Résumé
Le processus décrit dans cet article montre comment Tanium peut rapidement déterminer l’existence d’un mécanisme de persistance relativement inconnu en examinant l’état actuel des paramètres de registre, en examinant l’historique des modifications de registre avec Trace, et enfin en établissant des alertes en temps réel pour les modifications apportées à ces paramètres de registre à l’avenir. Si vous souhaitez en savoir plus, rejoignez-moi dans la Communauté d’utilisateurs Tanium et discutons-en.
Vous souhaitez voir Tanium en action ? Planifiez une démo individuelle ou participez à notre webinaire hebdomadaire. Discutez avec nos experts Tanium lors de nos prochains événements.
À propos de l’auteur : Scott Langendorf est directeur de l’équipe EDR Tanium. Il a rejoint Tanium à l’automne 2015 après avoir été directeur principal dans une société d’ingénierie mondiale attaquée par des groupes nationaux. Fort de huit ans d’expérience en cybersécurité, Scott a rejoint Tanium pour aider à faire progresser les produits de sécurité, reconnaissant l’importance d’une visibilité rapide des endpoints, d’alertes et d’agilité des données pour les équipes de défense et de recherche. Il a également travaillé chez la NASA sur le système d’alimentation électrique de la station spatiale et en tant que responsable informatique dans le secteur de l’énergie lorsque APT1 venait d’être découvert.
