Le poste de travail utilisateur est l'infrastructure la plus vulnérable en termes de sécurité de l'information. Les utilisateurs peuvent recevoir une lettre de leur courrier électronique qui semble provenir d'une source sûre, mais avec un lien vers le site infecté. Peut-être que quelqu'un va télécharger un utilitaire utile pour travailler à partir d'un endroit inconnu. Oui, vous pouvez trouver plus d'une douzaine de cas, comment les utilisateurs de logiciels malveillants peuvent s'infiltrer dans les ressources internes de l'entreprise. Par conséquent, les postes de travail nécessitent une attention accrue et, dans l'article, nous vous indiquerons où et quels événements prendre pour suivre les attaques.
Il existe trois sources d'événements utiles pour détecter une attaque à un stade précoce dans Windows: un journal des événements de sécurité, un journal de surveillance du système et des journaux Power Shell.
Journal de sécurité
Il s'agit de l'emplacement de stockage principal pour les journaux de sécurité du système. Cela inclut les événements de connexion / déconnexion des utilisateurs, l'accès aux objets, les changements de politiques et d'autres activités liées à la sécurité. Bien sûr, si la stratégie appropriée est configurée.
Dénombrement des utilisateurs et des groupes (événements 4798 et 4799). Un logiciel malveillant au tout début d'une attaque passe souvent par des comptes d'utilisateurs locaux et des groupes locaux sur un poste de travail pour trouver des informations d'identification pour ses affaires sombres. Ces événements aideront à détecter le code malveillant avant qu'il ne progresse et, en utilisant les données collectées, se propageront à d'autres systèmes.
Création d'un compte local et modification des groupes locaux (événements 4720, 4722–4726, 4738, 4740, 4767, 4780, 4781, 4794, 5376 et 5377). Une attaque peut également commencer, par exemple, en ajoutant un nouvel utilisateur à un groupe d'administrateurs locaux.
Tente de se connecter avec un compte local (événement 4624). Les bons utilisateurs se connectent avec un compte de domaine et l'identification d'une entrée sous un compte local peut indiquer le début d'une attaque. L'événement 4624 inclut également des connexions sous un compte de domaine. Par conséquent, lors du traitement des événements, vous devez filtrer les événements dans lesquels le domaine est différent du nom du poste de travail.
Tentative de connexion avec un compte donné (événement 4648). Cela se produit lorsque le processus s'exécute en mode «Exécuter en tant que». Dans le fonctionnement normal des systèmes, cela ne devrait pas être, par conséquent, de tels événements devraient être contrôlés.
Verrouillage / déverrouillage du poste de travail (événements 4800-4803). Les événements suspects incluent toutes les actions qui se sont produites sur un poste de travail verrouillé.
Modifications de la configuration du pare-feu (événements 4944-4958). De toute évidence, 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 de tels changements, mais il ne sera pas superflu de les connaître.
Connexion de périphériques Plug'n'play (événement 6416 et uniquement pour WIndows 10). Il est important de surveiller cela, si les utilisateurs ne connectent généralement pas de nouveaux appareils à la station de travail, puis tout d'un coup, ils l'ont connecté.
Windows comprend 9 catégories d'audit et 50 sous-catégories pour un réglage fin. L'ensemble minimal de sous-catégories qui doit être inclus dans les paramètres:
Ouverture / fermeture de session- Ouverture de session;
- Déconnexion;
- Verrouillage du compte;
- Autres événements d'ouverture / fermeture de session.
Gestion de compte- Gestion des comptes d'utilisateurs;
- Gestion des groupes de sécurité.
Changement de politique- Modification de la politique d'audit
- Changement de politique d'authentification;
- Modification de la politique d'autorisation.
Moniteur système (Sysmon)
Sysmon est un utilitaire intégré dans Windows qui peut écrire des événements dans le journal système. Il est généralement nécessaire de l'installer séparément.
Les mêmes événements peuvent en principe être trouvés dans le journal de sécurité (en incluant la politique d'audit souhaitée), mais Sysmon fournit plus de détails. Quels événements peuvent être retirés de Sysmon?
Création d'un processus (ID d'événement 1). Le journal des événements système des événements de sécurité peut également indiquer quand certains * .exe ont démarré et même afficher son nom et son chemin de démarrage. Mais contrairement à Sysmon, il ne pourra pas montrer le hachage de l'application. Un logiciel malveillant peut même être appelé notepad.exe inoffensif, mais c'est le hachage qui le mettra dans l'eau claire.
Connexions réseau (ID d'événement 3). De toute évidence, il existe de nombreuses connexions réseau et vous ne pouvez pas suivre tout le monde. Mais il est important de considérer que Sysmon, contrairement au journal de sécurité, peut lier une connexion réseau aux champs ProcessID et ProcessGUID, affiche le port et les adresses IP de la source et du récepteur.
Modifications dans le registre (ID d'événement 12-14). Le moyen le plus simple de vous ajouter au démarrage est de vous inscrire dans le registre. Le journal de sécurité peut le faire, mais Sysmon indique qui a effectué les modifications, quand, où, l'ID de processus et la valeur de clé précédente.
Création de fichier (ID d'événement 11). Sysmon, contrairement au journal de sécurité, affichera non seulement l'emplacement du fichier, mais aussi son nom. Il est clair que vous ne pouvez pas tout suivre, mais vous pouvez également auditer certains répertoires.
Et maintenant, ce que les politiques du journal de sécurité n'ont pas, mais sont dans Sysmon:
Modifier l'heure de création du fichier (ID d'événement 2). Certains logiciels malveillants peuvent remplacer la date de création du fichier pour le masquer des rapports contenant des fichiers récemment créés.
Téléchargez les pilotes et les bibliothèques dynamiques (ID d'événement 6-7). Suivi 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éation d'un thread dans un processus en cours (ID d'événement 8). Un type d'attaque que vous devez également surveiller.
Événements RawAccessRead (ID d'événement 9). Lire les opérations à partir du disque en utilisant «\\. \». Dans la grande majorité des cas, une telle activité doit être considérée comme anormale.
Création d'un flux de fichiers nommé (ID d'événement 15). Un événement est enregistré lorsqu'un flux de fichiers nommé est généré et génère 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 un 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 suivre les événements avec l'ID 4 (arrêter et démarrer Sysmon) et l'ID 16 (modifier la configuration Sysmon).
Magazines Power Shell
Power Shell est un outil puissant pour gérer l'infrastructure Windows, il y a donc de fortes chances que l'attaquant le choisisse. Vous pouvez utiliser deux sources pour obtenir des informations sur les é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 servent de source de données à PowerShell pour les afficher et les gérer. Par exemple, les fournisseurs intégrés peuvent être des variables d'environnement Windows ou le registre. L'émergence de nouveaux fournisseurs doit être surveillée afin d'identifier à temps les activités malveillantes. Par exemple, si vous voyez WSMan apparaître parmi les fournisseurs, une session PowerShell distante 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 verrouillage de script (ID d'événement 4104). La journalisation du verrouillage de script montre 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. Même dans ce type d'événement, certains appels d'API de bas niveau peuvent être enregistrés, ces événements sont généralement écrits comme verbeux, mais si une commande ou un script suspect est utilisé dans un bloc de code, il sera enregistré comme avertissement avec criticité.
Veuillez noter qu'après avoir configuré l'outil de collecte et d'analyse de 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 l'audit de sécurité des informations et quels outils vous utilisez pour cela. L'un de nos domaines 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 offrir un examen plus approfondi de
Quest InTrust , qui peut compresser les données stockées avec un rapport de 20: 1, et une instance installée est capable de traiter jusqu'à 60000 événements par seconde à partir de 10000 sources.