Le poste de travail utilisateur est le point le plus vulnérable de l’infrastructure en termes de sécurité de l’information. Les utilisateurs peuvent recevoir une lettre sur leur courrier électronique professionnel qui semble provenir d'une source sûre, mais avec un lien vers un site infecté. Peut-être que quelqu'un téléchargera un utilitaire utile pour travailler depuis un emplacement inconnu. Oui, vous pouvez proposer des dizaines de cas où des logiciels malveillants peuvent infiltrer les ressources internes de l’entreprise par l’intermédiaire des utilisateurs. Par conséquent, les postes de travail nécessitent une attention accrue, et dans cet article nous vous indiquerons où et quels événements prendre pour surveiller les attaques.
Pour détecter une attaque le plus tôt possible, WIndows dispose de trois sources d'événements utiles : 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é
Il s'agit de l'emplacement de stockage principal des journaux de sécurité du système. Cela inclut les événements de connexion/déconnexion des utilisateurs, l'accès aux objets, les modifications de stratégie et d'autres activités liées à la sécurité. Bien sûr, si la politique appropriée est configurée.
Énumération des utilisateurs et des groupes (événements 4798 et 4799). Au tout début d’une attaque, les logiciels malveillants effectuent souvent des recherches dans les comptes d’utilisateurs locaux et les groupes locaux sur un poste de travail pour trouver les informations d’identification nécessaires à leurs opérations louches. Ces événements aideront à détecter le code malveillant avant qu'il ne se propage et, à l'aide des données collectées, se propage à d'autres systèmes.
Création d'un compte local et modifications des groupes locaux (événements 4720, 4722-4726, 4738, 4740, 4767, 4780, 4781, 4794, 5376 et 5377). L'attaque peut également commencer, par exemple, par l'ajout d'un nouvel utilisateur au groupe des administrateurs locaux.
Tentatives de connexion avec un compte local (événement 4624). Les utilisateurs respectables se connectent avec un compte de domaine, et l'identification d'une connexion sous un compte local peut signifier le début d'une attaque. L'événement 4624 inclut également les connexions sous un compte de domaine. Ainsi, lors du traitement des événements, vous devez filtrer les événements pour lesquels le domaine est différent du nom du poste de travail.
Une tentative de connexion avec le compte spécifié (événement 4648). Cela se produit lorsque le processus s'exécute en mode « Exécuter en tant que ». Cela ne devrait pas se produire pendant le fonctionnement normal des systèmes, de tels événements doivent donc être contrôlés.
Verrouillage/déverrouillage du poste de travail (événements 4800-4803). La catégorie des événements suspects comprend toutes les actions survenues sur un poste de travail verrouillé.
Modifications de la configuration du pare-feu (événements 4944 à 4958). Évidemment, lors de l'installation d'un nouveau logiciel, les paramètres de configuration du pare-feu peuvent changer, ce qui entraînera des faux positifs. Dans la plupart des cas, il n’est pas nécessaire de contrôler ces changements, mais cela ne fera certainement pas de mal d’en être informé.
Connexion d'appareils Plug'n'play (événement 6416 et uniquement pour WIndows 10). Il est important de garder un œil sur ce point si les utilisateurs ne connectent généralement pas de nouveaux appareils au poste de travail, mais qu’ils le font soudainement.
Windows comprend 9 catégories d'audit et 50 sous-catégories pour un réglage fin. L'ensemble minimum de sous-catégories qui doivent être activées dans les paramètres :
Connexion / déconnexion
- Se connecter;
- Se déconnecter;
- Verrouillage du compte ;
- Autres événements de connexion/déconnexion.
Gestion de compte
- Gestion des comptes utilisateurs ;
- Gestion du groupe de sécurité.
Changement de politique
- Changement de politique de vérification ;
- Modification de la politique d'authentification ;
- Modification de la 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. Habituellement, vous devez l'installer séparément.
Ces mêmes événements peuvent, en principe, être retrouvés dans le journal de sécurité (en activant la politique d'audit souhaitée), mais Sysmon fournit plus de détails. Quels événements peuvent être extraits de Sysmon ?
Création de processus (ID d'événement 1). Le journal des événements de sécurité du système peut également vous indiquer quand un fichier *.exe a démarré et même afficher son nom et son chemin de lancement. Mais contrairement à Sysmon, il ne pourra pas afficher le hachage de l'application. Un logiciel malveillant peut même être qualifié d’inoffensif notepad.exe, mais c’est le hachage qui le mettra en lumière.
Connexions réseau (ID d'événement 3). De toute évidence, il existe de nombreuses connexions réseau et il est impossible de toutes les suivre. Mais il est important de considérer que Sysmon, contrairement à Security Log, peut lier une connexion réseau aux champs ProcessID et ProcessGUID et afficher le port et les adresses IP de la source et de la destination.
Modifications dans le registre système (ID d'événement 12-14). Le moyen le plus simple de vous ajouter à l'exécution automatique est de vous inscrire dans le registre. Le journal de sécurité peut le faire, mais Sysmon indique qui a effectué les modifications, quand, d'où, l'ID du processus et la valeur de clé précédente.
Création de fichier (ID d'événement 11). Sysmon, contrairement à Security Log, affichera non seulement l'emplacement du fichier, mais également son nom. Il est clair que vous ne pouvez pas tout suivre, mais vous pouvez auditer certains répertoires.
Et maintenant, ce qui ne figure pas dans les politiques du journal de sécurité, mais dans Sysmon :
Modification de l'heure de création du fichier (ID d'événement 2). Certains logiciels malveillants peuvent usurper la date de création d'un fichier pour le masquer des rapports sur les fichiers récemment créés.
Chargement des pilotes et des bibliothèques dynamiques (ID d'événement 6-7). Surveillance du chargement des DLL et des pilotes de périphériques en mémoire, vérification de la signature numérique et de sa validité.
Créez un thread dans un processus en cours d'exécution (ID d'événement 8). Un type d’attaque qui doit également être surveillé.
Événements RawAccessRead (ID d’événement 9). Opérations de lecture de disque en utilisant « . ». Dans la grande majorité des cas, une telle activité doit être considérée comme anormale.
Créez un flux de fichiers nommé (ID d'événement 15). Un événement est enregistré lorsqu'un flux de fichiers nommé est créé et émet des événements avec un hachage du contenu du fichier.
Création d'un canal nommé et d'une connexion (ID d'événement 17-18). Suivi du code malveillant qui communique avec d'autres composants via le canal nommé.
Activité WMI (ID d’événement 19). Enregistrement des événements générés lors de l'accès au système via le protocole WMI.
Pour protéger Sysmon lui-même, vous devez surveiller les événements avec l'ID 4 (arrêt et démarrage de Sysmon) et l'ID 16 (modifications de configuration Sysmon).
Journaux Power Shell
Power Shell est un outil puissant pour gérer l'infrastructure Windows, il y a donc de fortes chances qu'un attaquant le choisisse. Il existe deux sources que vous pouvez utiliser pour obtenir des données d'événements Power Shell : le journal Windows PowerShell et le journal Microsoft-WindowsPowerShell/Operational.
Journal Windows PowerShell
Fournisseur de données chargé (ID d'événement 600). Les fournisseurs PowerShell sont des programmes qui fournissent une source de données que PowerShell peut afficher et gérer. Par exemple, les fournisseurs intégrés peuvent être des variables d'environnement Windows ou le registre système. L’émergence de nouveaux fournisseurs doit être surveillée afin de détecter à temps les activités malveillantes. Par exemple, si vous voyez WSMan apparaître parmi les fournisseurs, cela signifie qu'une session PowerShell à distance a été démarrée.
Microsoft-WindowsPowerShell/Journal opérationnel (ou MicrosoftWindows-PowerShellCore/Opérationnel dans PowerShell 6)
Journalisation du module (ID d’événement 4103). Les événements stockent des informations sur chaque commande exécutée et les paramètres avec lesquels elle a été appelée.
Journalisation du blocage des scripts (ID d'événement 4104). La journalisation du blocage de script affiche chaque bloc de code PowerShell exécuté. Même si un attaquant tente de masquer la commande, ce type d'événement affichera la commande PowerShell réellement exécutée. Ce type d'événement peut également enregistrer certains appels d'API de bas niveau effectués. Ces événements sont généralement enregistrés comme verbeux, mais si une commande ou un script suspect est utilisé dans un bloc de code, il sera enregistré avec un niveau de gravité d'avertissement.
Veuillez noter qu'une fois l'outil configuré pour collecter et analyser ces événements, un temps de débogage supplémentaire sera nécessaire pour réduire le nombre de faux positifs.
Dites-nous dans les commentaires quels journaux vous collectez pour les audits de sécurité des informations et quels outils vous utilisez pour cela. L’un de nos domaines d’intérêt concerne les solutions d’audit des événements de sécurité de l’information. Pour résoudre le problème de la collecte et de l'analyse des journaux, nous pouvons suggérer d'examiner de plus près , qui peut compresser les données stockées avec un rapport de 20 : 1, et une instance installée de celui-ci est capable de traiter jusqu'à 60000 10000 événements par seconde à partir de XNUMX XNUMX sources.
Source: habr.com