Compromission système : qualifier et endiguer un incident

📑

Tout d’abord, après avoir confirmé la compromission d’un système, il s’agit d’évaluer la gravité de l’incident, son périmètre, son impact, et sa criticité.

Qualifier la compromission d’un système

Prérequis pour qualifier la compromission d’un système

Pour qualifier la compromission d’un système, les personnes impliquées doivent pouvoir accéder à l’administration, aux outils de monitoring du système d’information, et aux équipements de sécurité. Elles doivent aussi avoir connaissance des priorités métier de l’organisation ainsi que de la liste des contacts d’urgence. Une aide externe peut être nécessaire pour qualifier l’incident.

En outre, l'organisation victime doit ouvrir une main courante et veiller à la stocker hors du système d’information compromis, sur un support externe, un fichier partagé en Cloud, au format papier... et y reporter les actions menées pour répondre à l’incident. La main courante doit notamment inclure :

La date et l’heure de l’action ou de l’événement,
Le nom de la personne ou du service qui a détecté ou informé de l’événement,
La description détaillée de l’action ou de l’événement.

Elle vise notamment à consigner l'historique du traitement de l’incident, suivre les étapes de la remédiation et en évaluer l'efficacité, et elle doit également inclure les actions de connexion sur les machines compromises.

Mais pour commencer, comment qualifier la compromission d’un système ? Et ensuite, comment évaluer le périmètre de l’incident, son impact et sa criticité ?

Evaluer la compromission d’un système

Cette étape permet d’identifier le système concerné par l’incident, quelles parties du système d’information sont touchées, anticiper les perturbations sur l’activité de l’organisation, et se mettre en ordre de marche pour prendre les mesures adéquates en vue de résoudre l’incident.

Il s’agit également de définir la ou les parties du système d’information compromises, si des ressources sont touchées, si des risques existent pour d’autres systèmes connectés, et si l’activité de l’organisation peut être perturbée.

Compromission système : évaluer l’incident

Identifier le système concerné

Le système peut être identifié par son adresse IP, et il faut vérifier si le sous-réseau IP concerné fait partie des adresses utilisées sur le système d’information, ou encore si le signalement pointe une machine susceptible d’en masquer d’autres (routeur, proxy, serveur DNS, pare-feu ou NAT).

Le système peut aussi être identifié par le nom de machine, ou à partir des informations collectées par un SOC ou un EDR qui auront déclenché une alerte le cas échéant.

Recueillir les informations élémentaires de configuration système

Toutes les informations relatives à la configuration du système sont aussi essentielles pour identifier le système : OS et version, système de synchronisation horaire éventuel, applications métier installées sur le système, présence d’applications potentiellement vulnérables...

Confirmer la validité du signalement de compromission d’un système

Pour éviter de perdre du temps en démarches liées à un signalement qui serait erroné, certains points méritent une vérification complémentaire, notamment la cohérence temporelle. Il convient ainsi de confirmer si l’architecture et la configuration du système au moment du signalement correspondent aux informations recueillies dans le cadre du signalement, la cohérence de l’horodatage, le fait que le système était bien en production au moment du signalement...

Confirmer la compromission du système

Afin de confirmer l’incident, les informations provenant des journaux et des logs sont utiles pour rechercher des événements ou confronter les informations du signalement avec :

celles du pare-feu, du CDN ou des serveurs mandataires si le signalement est un flux réseau
les données de l’EDR ou de l’antivirus si le signalement est un comportement illégitime
les traces relatives aux flux
les éventuelles modifications de services exposés par le système
l'utilisation illégitime de comptes utilisateurs
les journaux d’infrastructure Cloud...

Evaluer le périmètre de la compromission système

Une fois la compromission d’un système confirmée, le périmètre de l’incident peut être évalué en identifiant la fonction et la connectivité de la ou des machine(s) compromise(s) : poste de travail, serveur, VM, hyperviseur, connexion avec Internet... Cette phase permet aussi de définir plus précisément la partie du système d’information atteinte, voire si des ressources d’administration sont concernées.

Evaluer l’impact et l’urgence à résoudre l’incident

La prise de contrôle sur une machine peut avoir des conséquences pour des activités ou des services critiques, et pour l’activité métier. Elle peut entraîner des risques pour l’image de l’organisation, des données voire des personnes, et avoir un impact sur le plan réglementaire. Ces facteurs permettent aussi de définir le degré d’urgence à réagir.

Selon les risques d’évolution, les risques pour l’activité de l’organisation et pour les dispositifs de sécurité dans leur ensemble, l’incident peut être qualifié d’anomalie courante, incident mineur ou majeur, voire crise cyber. La suite des actions consiste à endiguer la compromission système.

Endiguer une compromission système

Le conseil d’expert

Dans le cadre des actions d’endiguement d’un compromission système, les connexions locales, RDP et SSH, ou toute session interactive avec la machine compromise sont à éviter, qui plus est avec un compte privilégié !

Si les actions à distance sont impossibles, mieux vaut envisager :

Des actions via un EDR ou un logiciel de gestion à distance n’ouvrant pas de système (type RMM) ;

Une connexion locale via une console physique, hors bande ou d’hyperviseur avec un compte administrateur uniquement local au système concerné ;

En dernier recours, une connexion par le réseau qui ne met pas en danger le mot de passe des administrateurs (PowerShell Remoting, Windows Remote Shell, ou RDP en mode Restricted Admin).

Toutes ces actions de connexion doivent être consignées dans la main courante.

Limiter l’extension de la compromission

Figer la situation

Si l'indisponibilité de la machine infectée ne pose pas de problème pour le reste du système d’information et l’activité de l’organisation, cette machine doit être mise à l’arrêt avec notification explicite sur le fait qu’elle a besoin d'être maintenue éteinte ou en pause. Elle peut aussi être déconnectée du réseau via l’EDR ou physiquement.

Dans le cas où la machine compromise ne peut pas être rendue indisponible, elle doit a minima être isolée du réseau interne, pour éviter le rebond de l’attaque vers le reste du système d’information.

Les équipes métier ont besoin d’être prévenues de l’impact potentiel des opérations en cours.

Réinitialiser les identifiants utilisateurs suspectés d’être compromis

Tous les comptes utilisateurs et administrateurs du domaine suspectés doivent être désactivés.

Les comptes homonymes sur les autres machines et ceux utilisés sur les machines infectées ainsi que les comptes Cloud doivent être réinitialisés, et les sessions de compte révoquées. A noter : si un second facteur est utilisé depuis ou vers la machine compromise, il faut veiller à le suspendre pendant la durée de l’investigation.

Enfin, si le serveur compromis contenait des clés SSH privées, alors, il faut supprimer les clés publiques ailleurs sur le parc.

Réinitialiser les secrets liés à la machine infectée

Si la machine infectée contenait des certificats, il convient de les révoquer et de vérifier la révocation.

Si elle contenait des token d’API, il est nécessaire de révoquer les jetons et éventuellement d’en déployer de nouveaux sur d’autres instances partageant la même clé.

Si la machine est inscrite dans un Active Directory, il est nécessaire de désactiver le compte machine.

Préserver les actifs essentiels de l’organisation

Les sauvegardes doivent impérativement être sécurisées en cas d’incident, à la fois pour rétablir les services du système d’information et aussi pour contribuer aux investigations. L’accès doit être validé, et si un risque de compromission existe, l’accès doit être limité.

Préserver les traces en cas de compromission système

La préservation des traces peut concerner :

Une machine virtuelle, auquel cas il faut réaliser un instantané de la machine en pause incluant l’export de la mémoire s’il est disponible ;
Une machine physique, auquel cas un prélèvement forensique peut être réalisé à l’aide d’un EDR, un agent forensique, le service d’administration, ou un outil de prélèvement.

Les traces provenant des journaux d’équipements sont aussi nécessaires : pare-feu, passerelle VPN, proxy, CDN, EDR, antivirus, AD... et la période de rétention des données et la verbosité les plus importantes possibles seront des atouts pour les analystes.

A ce stade de l’endiguement, les actions de l’attaquant ne peuvent pas encore être identifiées précisément. Seule une analyse approfondie va permettre de comprendre ces éléments, et elle peut nécessiter l’intervention de ressources externes (InterCERT France mentionne les contacts adéquats dans ses fiches réflexe).

Approfondissez l'analyse des incidents
et découvrez tout ce que notre EDR peut faire pour vous aider :