Qu'est-ce que l'on peut tirer des journaux d'une station de travail fonctionnant sous Windows

La station de travail d’un utilisateur est le maillon le plus vulnérable de l'infrastructure en matière de sécurité de l'information. Les utilisateurs peuvent recevoir dans leur messagerie professionnelle un email prétendument provenant d'une source sécurisée, mais contenant un lien vers un site infecté. Il est possible que quelqu'un télécharge un outil utile pour le travail depuis une source inconnue. On peut imaginer des dizaines de scénarios dans lesquels des logiciels malveillants peuvent infiltrer les ressources internes de l'entreprise via les utilisateurs. Par conséquent, les stations de travail nécessitent une attention particulière, et dans cet article, nous allons expliquer quelles sources d'événements et quels événements surveiller pour détecter les attaques.

Pour détecter une attaque à un stade précoce, il existe trois sources d'événements utiles dans le système d'exploitation Windows : le journal des événements de sécurité, le journal de surveillance du système et les journaux Power Shell.

Journal des événements de sécurité (Security Log)

C'est l'endroit principal où sont stockés les journaux de sécurité système. Les événements de connexion/déconnexion des utilisateurs, d'accès aux objets, de modifications de politiques et d'autres activités liées à la sécurité y sont consignés. Bien entendu, cela n'est possible que si une politique appropriée est configurée.

Tentatives de récupération des utilisateurs et groupes (événements 4798 et 4799). Les logiciels malveillants, au début d'une attaque, explorent souvent les comptes utilisateurs locaux et les groupes locaux sur la station de travail pour trouver des identifiants à des fins malveillantes. Ces événements peuvent aider à détecter le code malveillant avant qu'il ne se propage à d'autres systèmes en utilisant les données collectées.

Création de compte utilisateur local et modifications dans les groupes locaux (événements 4720, 4722–4726, 4738, 4740, 4767, 4780, 4781, 4794, 5376 et 5377). Une attaque peut également commencer, par exemple, par l'ajout d'un nouvel utilisateur au groupe des administrateurs locaux.

Tentatives de connexion avec un compte utilisateur local (événement 4624). Les utilisateurs respectueux entrent avec un compte de domaine, et la détection d'une connexion via un compte local peut indiquer le début d'une attaque. L'événement 4624 inclut également les connexions avec des comptes de domaine, donc lors de l'analyse des événements, il est nécessaire de filtrer ceux où le domaine diffère du nom de la station de travail.

Tentative de connexion avec un compte donné (événement 4648). Cela se produit lorsque le processus est exécuté en mode « Exécuter en tant que » (run as). En mode de fonctionnement normal du système, cela ne devrait pas arriver, donc de tels événements doivent être surveillés.

Verrouillage/Déverrouillage de la station de travail (événements 4800-4803). On peut considérer comme suspects toutes les actions qui se sont produites sur une station de travail verrouillée.

Changements de configuration du pare-feu (événements 4944-4958). Il est évident qu'à l'installation d'un nouveau logiciel, les paramètres de configuration du pare-feu peuvent changer, ce qui entraînera de fausses alertes. Dans la plupart des cas, il n'est pas nécessaire de surveiller de tels changements, mais il est toujours bon d'être au courant.

Connexion de dispositifs Plug’n’Play (événement 6416 et uniquement pour Windows 10). Il est important de suivre cela si les utilisateurs ne connectent généralement pas de nouveaux dispositifs à la station de travail, et soudain, ils en ont branché un.

Windows comprend 9 catégories d'audit et 50 sous-catégories pour un paramétrage précis. Le jeu minimal de sous-catégories à activer dans les paramètres est le suivant :

Connexion/Déconnexion

• Connexion ;
• Déconnexion ;
• Verrouillage de compte ;
• Autres événements de connexion/déconnexion.

Gestion des comptes

• Gestion des comptes utilisateurs ;
• Gestion des groupes de sécurité.

Changement de politique

• Changement de politique d'audit ;
• Changement de politique d'authentification ;
• Changement de politique d'autorisation.

Moniteur système (Sysmon)

Sysmon est un utilitaire intégré à Windows qui peut enregistrer des événements dans le journal système. Il doit généralement être installé séparément.

Ces événements peuvent en principe être trouvés dans le journal de sécurité (en activant la politique d'audit requise), mais Sysmon offre plus de détails. Quels événements peuvent être récupérés à partir de Sysmon ?

Création de processus (ID d'événement 1). Le journal système des événements de sécurité peut également indiquer quand un fichier *.exe a été lancé et même montrer son nom et son chemin d'exécution. Mais contrairement à Sysmon, il ne peut pas afficher le hachage de l'application. Un logiciel malveillant peut être nommé même innocemment notepad.exe, mais c'est précisément le hachage qui le démasquera.

Connexions réseau (ID d'événement 3). Il est évident qu'il y a beaucoup de connexions réseau, et il est impossible de toutes les surveiller. Mais il est important de prendre en compte que Sysmon, contrairement au Security Log, peut lier une connexion réseau aux champs ProcessID et ProcessGUID, montrant le port et adresses IP la source et le destinataire.

Modifications dans le registre système (ID d'événement 12-14). La manière la plus simple d'ajouter vous-même au démarrage automatique est de vous inscrire dans le registre. Le Journal de sécurité sait le faire, mais Sysmon montre qui a effectué les modifications, quand, d'où, l'ID du processus et la valeur précédente de la clé.

Création de fichier (ID de l'événement 11). Sysmon, contrairement au Journal de sécurité, montrera non seulement l'emplacement du fichier, mais aussi son nom. Il est clair qu'on ne peut pas tout surveiller, mais on peut auditer certains répertoires.

Et maintenant, ce qui n'est pas dans les politiques du Journal de sécurité, mais qui l'est dans Sysmon :

Modification de l'heure de création du fichier (ID de l'événement 2). Certains logiciels malveillants peuvent modifier la date de création du fichier pour le cacher des rapports sur les fichiers récemment créés.

Chargement de pilotes et de bibliothèques dynamiques (ID des événements 6-7). Suivi du chargement en mémoire de DLL et de pilotes de périphériques, vérification de la signature numérique et de sa validité.

Création d'un thread dans un processus en cours d'exécution (ID de l'événement 8). Un type d'attaque qu'il faut également surveiller.

Événements RawAccessRead (ID de l'événement 9). Opérations de lecture depuis le disque utilisant '`.`'. Dans la grande majorité des cas, cette activité doit être considérée comme anormale.

Création d'un flux de fichier nommé (ID de l'événement 15). L'événement est enregistré lorsqu'un flux de fichier nommé est créé, générant des événements avec le hachage du contenu du fichier.

Création de named pipe et connexions (ID des événements 17-18). Suivi du code malveillant qui communique avec d'autres composants via named pipe.

Activité WMI (ID de l'événement 19). Enregistrement des événements générés lors d'un accès au système via le protocole WMI.

Pour protéger Sysmon lui-même, il faut suivre les événements avec ID 4 (arrêt et démarrage de Sysmon) et ID 16 (modification de la configuration de Sysmon).

Journaux PowerShell

PowerShell est un puissant outil de gestion de l'infrastructure Windows, donc il y a de fortes chances que l'attaquant choisisse celui-ci. Pour obtenir des données sur les événements PowerShell, on peut utiliser deux sources : le journal Windows PowerShell et le journal Microsoft-WindowsPowerShell / Operational.

Journal Windows PowerShell

Fournisseur de données chargé (ID de l'événement 600). Les fournisseurs PowerShell sont des programmes qui servent de source de données pour PowerShell afin de les visualiser et de les gérer. Par exemple, les fournisseurs intégrés peuvent inclure les variables d'environnement Windows ou le registre système. Il est important de suivre l'apparition de nouveaux fournisseurs pour détecter rapidement une activité malveillante. Par exemple, si vous voyez que WSMan est apparu parmi les fournisseurs, cela signifie qu'une session PowerShell à distance a été initiée.

Journal opérationnel Microsoft-WindowsPowerShell (ou MicrosoftWindows-PowerShellCore pour PowerShell 6)

Journalisation des modules (ID d'événement 4103). Les événements contiennent des informations sur chaque commande exécutée et les paramètres avec lesquels elle a été appelée.

Journalisation des blocs de scripts (ID d'événement 4104). La journalisation des blocs de scripts montre chaque bloc de code PowerShell exécuté. Même si un attaquant essaie de dissimuler la commande, ce type d'événement affichera la commande PowerShell effectivement exécutée. De plus, certains appels API de bas niveau exécutés peuvent être enregistrés dans ce type d'événement, qui sont généralement notés comme Verbose, mais si une commande ou un script suspect est utilisé dans le bloc de code, il sera enregistré avec une sévérité Warning.

Veuillez noter qu'après avoir configuré l'outil de collecte et d'analyse de ces événements, un temps supplémentaire sera nécessaire pour déboguer afin de réduire le nombre de faux positifs.

Partagez dans les commentaires quels journaux vous collectez pour l'audit de la sécurité de l'information et quels outils vous utilisez à cet effet. L'une de nos spécialités est les solutions pour l'audit des événements de sécurité de l'information. Pour la collecte et l'analyse des journaux, nous pouvons vous suggérer d'examiner Quest InTrust, qui peut compresser les données stockées avec un ratio de 20:1, et une instance installée est capable de traiter jusqu'à 60 000 événements par seconde à partir de 10 000 sources.

Source : habr.com