Est-il possible de se défendre complètement contre les cyberattaques? Vous pouvez probablement, si vous vous entourez de tous les moyens de protection existants et embaucher une énorme équipe d'experts pour gérer les processus. Cependant, il est clair qu'en réalité cela est impossible: le budget pour la sécurité de l'information n'est pas infini, et des incidents vont néanmoins se produire. Et comme ils se produiront, alors vous devez vous y préparer!
Dans cet article, nous allons partager des scénarios typiques pour enquêter sur les incidents de logiciels malveillants, nous dire ce qu'il faut rechercher dans les journaux et donner des recommandations techniques sur la façon de configurer les outils de protection des informations pour augmenter les chances de réussite d'une enquête.
Le processus classique de
réponse à un incident lié à un logiciel malveillant implique des étapes telles que la détection, le confinement, la récupération, etc., cependant, toutes vos capacités, en fait, sont déterminées au stade de la préparation. Par exemple, le taux de détection des infections dépend directement de la façon dont l'audit est configuré dans l'entreprise.
Cycle de réponse classique aux incidents SANS
De manière générale, les actions des analystes au cours de l'enquête sont les suivantes:
- Génération de versions expliquant les causes de l'incident (par exemple, «le logiciel malveillant a été installé sur l'hôte parce que l'utilisateur l'a lancé à partir d'un e-mail de phishing» ou «l'incident est une fausse alarme car l'utilisateur a visité un site légitime situé sur le même hébergement que le serveur de gestion) malware »).
- Priorisation des versions par degré de probabilité. La probabilité est calculée (mais plutôt prétendue) sur la base des statistiques des incidents passés, de la criticité de l'incident ou du système, et également sur la base de l'expérience personnelle.
- Etude de chaque version, recherche de faits prouvant ou infirmant.
Bien sûr, il est inutile de tester toutes les hypothèses possibles - du moins parce que le temps est limité. Par conséquent, nous examinerons ici les versions les plus probables et les scénarios typiques pour enquêter sur les incidents de logiciels malveillants.
Scénario 1
Vous pensez qu'un système non critique a été compromis par des logiciels malveillants. En raison de la nature non critique du système, un peu de temps a été alloué pour la vérification.
La première chose que font la plupart des ingénieurs d'intervention est d'exécuter une vérification antivirus. Cependant, comme nous le savons, un antivirus n'est pas si difficile à contourner. Par conséquent, il vaut la peine de générer et d'élaborer la version hautement probable suivante: les logiciels malveillants sont un fichier ou service exécutable distinct.
Dans le cadre du développement de cette version, il y a trois étapes simples à suivre:
- Filtrer le journal de sécurité par événement 4688 - nous obtenons donc une liste de tous les processus qui ont démarré.
- Filtrez le journal système par événement 7045 - afin d'obtenir une liste des installations de tous les services.
- Identifiez les nouveaux processus et services qui n'étaient pas auparavant dans le système. Copiez ces modules et analysez-les pour détecter les codes malveillants (scannez avec plusieurs antivirus, vérifiez la validité de la signature numérique, décompilez le code, etc.).
Lister tous les processus et services en cours d'exécution dans l' explorateur du journal des événements
En théorie, c'est un processus assez trivial. Cependant, dans la pratique, il y a un certain nombre d'écueils auxquels il faut se préparer.
Tout d'abord, la configuration d'audit standard de Windows n'enregistre pas les faits du lancement du processus (événement 4688), elle doit donc être activée à l'avance dans la stratégie de groupe de domaine. S'il arrivait que cet audit n'ait pas été inclus à l'avance, vous pouvez essayer d'obtenir une liste de fichiers exécutables à partir d'autres artefacts Windows, par exemple, à partir du registre
Amcache . Vous pouvez
extraire des données de ce fichier de registre à l'aide de l'utilitaire
AmcaheParser .
Un exemple d'extraction des faits de démarrage de processus depuis Amcache.hve
Cependant, cette méthode n'est pas très fiable, car elle ne fournit pas d'informations précises sur le moment exact et le nombre de démarrages du processus.
Deuxièmement, les preuves du lancement de processus tels que
cmd.exe, powershell.exe, wscript.exe et d'autres interpréteurs seront peu utiles sans informations sur la ligne de commande avec laquelle les processus ont été démarrés, car il contient le chemin d'accès à un fichier de script potentiellement malveillant.
Exécution de l'interpréteur de script sans information sur le script lancé
Une autre caractéristique de Windows est que l'audit de ligne de commande du processus lancé est effectué en configurant séparément la stratégie de groupe de domaine:
Configuration ordinateur -> Stratégies -> Modèles d'administration -> Système -> Création de processus d'audit -> Inclure la ligne de commande dans les événements de création de processus . Dans le même temps, le Windows 7/2008, plutôt populaire, n'enregistre pas la ligne de commande sans la
mise à jour
KB3004375 installée , alors mettez-la à l'avance.
S'il se trouve que vous n'avez rien configuré à l'avance ou que vous avez oublié la mise à jour, vous pouvez essayer de trouver l'emplacement du script dans les fichiers
Prefetch (un
utilitaire pour vous aider ). Ils contiennent des informations sur tous les fichiers (principalement des DLL) chargés dans le processus au cours des 10 premières secondes de vie. Et le script contenu dans les arguments de la ligne de commande de l'interpréteur y sera certainement présent.
Exemple de recherche d'un argument de ligne de commande «perdu» dans Prefetch
Mais cette méthode n'est pas du tout fiable - la prochaine fois que vous lancerez le processus, le cache Prefetch sera écrasé.
Préparation à l'enquête:
- Inclure un audit avancé de la création et de l'achèvement des processus.
- Activez la journalisation des arguments de la ligne de commande du processus.
- Installez la mise à jour KB3004375 sur Windows 7 / Server 2008.
Scénario 2
Un accès au serveur de gestion des logiciels malveillants a été enregistré sur le routeur de périmètre. L'adresse IP du serveur malveillant a été obtenue à partir d'un abonnement au service de renseignement sur les menaces à sécurité moyenne.
Dans l'
un de nos articles précédents, nous avons dit que les analystes de TI péchaient en ajoutant aux listes d'indicateurs de compromis des adresses IP des serveurs qui hébergent des centres de contrôle de logiciels malveillants et des sites Web légitimes en même temps. Si vous venez de commencer à formuler des processus de réponse, dans les premières étapes, il est préférable d'abandonner l'utilisation de ces indicateurs, car chaque tentative d'un utilisateur d'entrer sur un site Web légitime ressemblera à un incident à part entière.
L'une des options pour répondre à de telles alarmes peut être réduite à la vérification du processus qui a établi la connexion - s'il s'agit d'un navigateur Internet, en l'absence d'autres faits indiquant un compromis, l'incident peut être considéré comme une fausse alarme.
Il existe de nombreuses façons de savoir quel processus a initié la connexion: vous pouvez exécuter
netstat et voir les sockets en cours ou collecter un vidage de la mémoire, puis définir la
volatilité sur celui-ci, qui peut également afficher les connexions déjà terminées. Mais tout cela est long, non évolutif et surtout - pas fiable. Il est beaucoup plus fiable d'obtenir toutes les informations nécessaires à partir du journal de sécurité Windows.
Corrélation de l'événement «accès à une adresse IP malveillante» dans le système HPE Arcsight SIEM et du processus correspondant dans le journal de sécurité Windows
Préparation de l'enquête
Pour résoudre ce scénario sur une machine utilisateur, vous devez activer la journalisation de toutes les connexions réseau au journal de sécurité. Cela peut être fait sur la base des événements d'
audit de
la plate -
forme de filtrage et de l'
audit de perte de paquets .
Dans le même temps, le magazine peut rapidement se boucher, augmentez donc sa taille à 2-3 Go. D'après notre expérience, sur un hôte utilisateur régulier, ce montant est suffisant pendant environ 3 jours pour enregistrer toutes les sockets, et cette période est assez suffisante pour une enquête réussie.
Sur les serveurs très chargés, tels que les contrôleurs de domaine, les serveurs Web, etc., vous ne devriez pas le faire, le journal débordera beaucoup plus rapidement.
Scénario 3
Votre système de détection d'anomalies NG / ML / Anti-APT signale que 30 hôtes recherchent les mêmes comptes.
Lorsqu'ils pénètrent dans un nouveau réseau, les attaquants tentent généralement de savoir quels services y sont présents et quels comptes sont utilisés - cela aide beaucoup dans le processus de déplacement ultérieur le long de l'infrastructure. En particulier, ces informations peuvent être obtenues à partir d'Active Directory lui-même à l'aide de la commande
net user / domain .
Si l'intelligence potentielle est effectuée à partir d'un hôte, elle peut être étudiée, notamment en utilisant les journaux des processus en cours d'exécution. Cependant, s'il existe de nombreux hôtes et que les attaques sont du même type (survenues en même temps ou si le même ensemble d'entités a été demandé à AD), il est tout d'abord logique d'exclure un faux positif typique. Pour ce faire, créez et vérifiez les versions suivantes:
- L'intelligence est fixée sur 30 hôtes pour les mêmes objets AD parce que l'utilisateur légitime net , l'administrateur, a lancé la commande net .
- L'intelligence est fixée sur 30 hôtes pour les mêmes objets AD, car elle a créé le même logiciel légitime.
L'analyse statistique des journaux aidera à trouver ces points nodaux (un utilisateur ou un processus commun). Nous avons démontré cette méthode dans un article précédent appliquée aux
journaux du serveur DNS . Cependant, de telles méthodes d'enquête efficaces ne peuvent pas être utilisées si le stockage des données n'a pas été organisé à l'avance.
Préparation de l'enquête
Il est nécessaire d'organiser le stockage à long terme d'au moins les données suivantes à partir des journaux des services réseau communs:
- Contrôleurs de domaine - entrées, sorties de comptes et émission de tickets Kerberos (catégorie Connexion au compte dans les paramètres d'audit avancés).
- Proxies - adresses, ports source et serveur externe, ainsi que l'URL complète.
- Serveurs DNS - requêtes DNS réussies et infructueuses et leur source dans le réseau.
- Routeurs de périmètre - Construits et démontés pour toutes les connexions TCP / UDP, ainsi que les connexions qui tentent d'enfreindre les règles d'accès logique: par exemple, tente d'envoyer directement une requête DNS vers l'extérieur, en contournant le serveur DNS d'entreprise.
Scénario 4
Votre domaine a été compromis et vous craignez qu'un attaquant ne prenne pied dans l'infrastructure à l'aide de la technique DCShadow.
Supposons qu'une chose terrible se soit produite: vous constatez que le compte d'administrateur de domaine a été compromis.
La réponse à un tel incident comprend une très grande couche de travail, y compris une analyse de toutes les actions commises à partir de ce compte. Une partie de cette enquête peut être effectuée en utilisant uniquement les journaux du contrôleur de domaine. Par exemple, vous pouvez étudier les événements associés à l'émission de tickets Kerberos pour comprendre d'où ils sont sortis sous ce compte. Ou vous pouvez analyser les événements associés à la modification des objets AD critiques pour vérifier si la composition des groupes hautement privilégiés (les mêmes administrateurs de domaine) a changé. Naturellement, tout cela nécessite un audit préconfiguré.
Cependant, il existe un problème selon lequel un attaquant disposant de droits d'administrateur de domaine peut modifier des objets AD à l'aide de la technique DCShadow, qui est basée sur le mécanisme de réplication entre les contrôleurs de domaine.
Son essence est que l'attaquant lui-même semble être un contrôleur de domaine, apporte des modifications à AD, puis réplique (synchronise) ces modifications avec des contrôleurs légitimes, contournant ainsi l'audit des modifications d'objet configurées sur eux. Le résultat d'une telle attaque peut être l'ajout d'un utilisateur à un groupe d'administrateurs de domaine ou des liaisons plus délicates en modifiant l'attribut
Historique SID ou en modifiant l'objet ACL
AdminSDHolder .
Afin de vérifier la version concernant la présence de modifications non validées dans AD, vous devez étudier les journaux de réplication des contrôleurs: si des adresses IP autres que les contrôleurs de domaine ont été impliquées dans la réplication, vous pouvez dire en toute confiance que l'attaque a réussi.
Suppression d'un contrôleur de domaine inconnu de la réplication ADPréparation à l'enquête:- Pour enquêter sur les actions commises par un compte compromis, vous devez inclure à l'avance:
- Audit des entrées et sorties du compte et émission de tickets Kerberos (catégorie Connexion au compte dans les paramètres d'audit avancés).
- Audit des modifications apportées aux comptes et aux groupes (catégorie Gestion des comptes ).
- Pour rechercher les versions liées à d'éventuelles attaques DCShadow:
- Activez l'audit détaillé de la réplication du service d'annuaire .
- Organisez le stockage à long terme des événements 4928/4929, dans lequel la source d'événements n'est pas un contrôleur de domaine légitime (attribut DCShadow).
Conclusion
Dans cet article, nous avons parlé de certains scénarios typiques pour enquêter sur les incidents de sécurité des informations et des mesures pour leur préparation préventive. Si vous êtes intéressé par ce sujet et que vous êtes prêt à aller plus loin, je vous recommande de faire attention à
ce document , qui décrit dans quels événements Windows vous pouvez trouver des traces de l'utilisation de techniques de piratage populaires.
Je voudrais terminer par une citation d'une étude récente d'une entreprise de cybersécurité:
«Pour la plupart, les directeurs russes de la sécurité de l'information ont tendance à donner des réponses pessimistes [aux questions de recherche]. Ainsi, la moitié (48%) pensent que le budget ne changera en rien, et 15% pensent que le financement sera réduit. »
Pour moi personnellement, c'est un signal que le budget restant de la nouvelle année est mieux dépensé non pas pour acheter des SZI à la mode comme les détecteurs d'apprentissage automatique, un autre IDS de nouvelle génération, etc., mais pour affiner ces SZI qui existent déjà. Et le meilleur SZI est des journaux Windows correctement configurés. À mon humble avis.