Opérations de sécurité

Les secrets d’un analyste en sécurité : comment lancer une chasse aux menaces ?

Découvrez les bases pour lancer une chasse aux menaces grâce aux conseils et astuces d'analystes en sécurité expérimentés.

En matière de détection et de réponse aux menaces, un nombre croissant d’entreprises se tournent vers des services MDR (Managed Detection and Response). En fait, “51 % utilisent un fournisseur de services MDR pour les aider à intégrer les données de télémétrie dans le cadre de leurs opérations de détection et de réponse aux menaces” selon ESG Research.

Les services MDR, tels que Sophos MTR (Managed Threat Response), présentent de nombreux avantages par rapport à un unique programme interne d’opérations de sécurité. Le plus grand avantage de tous est souvent l’expérience. L’objectif de cette série d’articles est de vous aider à exploiter cette expérience afin que vous puissiez apprendre certains secrets de nos opérateurs de sécurité, à commencer par la chasse aux menaces.

Les analystes en sécurité sont constamment à la recherche de menaces et de tout élément suspect susceptible de nécessiter des actions complémentaires. Cependant, toutes les chasses aux menaces ne sont pas identiques. Chez Sophos, nous les classons en deux grandes catégories :

  • Chasses aux menaces avec indices (lead-driven)
  • Chasses aux menaces sans indices (leadless)

Que la chasse soit menée avec ou sans indices, toute menace détectée doit faire l’objet d’un triage, être traitée et neutralisée par l’équipe de sécurité.

Chasses aux menaces avec indices (lead-driven)

Les analystes en sécurité doivent surveiller leurs actifs sur une base 24/7/365 afin de détecter tout comportement malveillant et suspect. Au niveau de notre organisation, toute détection nécessitant une investigation plus approfondie est examinée par un véritable analyste, expert en menaces, qui pourra utiliser le contexte propre à l’entreprise concernée ainsi qu’un raisonnement humain à n’importe quelle situation. Il observera le comportement, prendra en compte le contexte de l’entreprise précédemment défini, établira une hypothèse et agira ensuite en fonction de cette dernière. L’hypothèse peut être par exemple de s’engager activement au niveau de l’incident potentiel ou de faire un travail d’investigation supplémentaire afin de renforcer les connaissances sur le problème en question.

Ensuite, pour boucler la boucle, l’analyste attendra afin de pouvoir évaluer quels sont les résultats issus de cette hypothèse et de ces tests. Si une investigation plus approfondie est nécessaire, il pourra alors répéter ce cycle jusqu’à ce qu’une décision soit prise. Si l’événement s’est transformé en un incident actif, l’analyste basculera alors en mode ‘réponse complète’ afin de lutter activement contre cette menace.

Les analystes en sécurité expérimentés utilisent souvent un framework pour guider leurs investigations. Par exemple, l’équipe Sophos MTR utilise une méthodologie d’investigation connue sous le nom de boucle OODA (OODA loop). Cette méthode leur permet de s’engager dans le cycle présenté ci-dessus afin de s’assurer que tous les résultats sont testés et prouvés :

chasse aux menaces

La boucle OODA est un concept militaire qui permet à notre équipe de passer par un cycle de raisonnement afin de bien comprendre l’événement et le comportement environnant. Elle pourra ensuite s’appuyer sur ces connaissances et passer par une prise de décision et l’intuition humaines pour conclure si une activité malveillante est bien présente au sein d’un environnement client. L’analyste pourra alors agir à l’issue de cette investigation.

Illustrons, à présent, ce que nous venons vous présenter avec un exemple concret. Précisons que le client ci-dessous possédait environ 800 appareils et était surveillé par Sophos MTR.

Le déclencheur

La seule indication que quelque chose n’allait pas sur le système impacté était une exécution apparemment inoffensive de ProcDump (un outil tout à fait légitime utilisé par les administrateurs pour capturer l’espace mémoire d’une application, généralement pour résoudre des problèmes spécifiques) ; cependant, dans ce cas précis, le signal que Sophos Endpoint avait fait remonter indiquait que ProcDump tentait de vider la mémoire de lsass.exe.

LSASS désigne le Local Security Authority Subsystem dans Microsoft Windows et est responsable de l’application de la politique de sécurité et de la gestion des connexions aux systèmes Windows. En écrivant sa mémoire sur le disque, les identifiants et les mots de passe des utilisateurs pouvaient alors être récupérés.

La protection endpoint Sophos Intercept X a bloqué cette tentative en tant qu’événement de type “vol d’identifiants”. Cependant, cette alerte était un signal suffisamment fort pour justifier une chasse aux menaces complète à partir d’indices. Ainsi, un cas a été créé automatiquement par le système MTR et assigné aux analystes MTR, experts en menaces, afin qu’ils puissent passer à l’action.

La chasse

Après l’événement initial de type “vol d’identifiants”, l’analyste MTR a suivi l’arborescence des processus à partir de ProcDump pour essayer d’identifier tout indicateur supplémentaire. À partir de là, il a pu identifier que l’attaquant avait tenté également d’utiliser Meterpreter pour élever ses privilèges utilisateur. L’attaquant avait également laissé une trace au niveau du trafic Command and Control (C2) qui communiquait avec une adresse IP externe inconnue mais identique à celle déjà observée par l’analyste concernant des outils de reconnaissance et de persistance tels que Cobalt Strike.

À ce stade, il était clair qu’un adversaire actif était présent sur le réseau et l’analyste MTR a transmis cet événement au client, conformément au mode de réponse MTR que ce dernier avait choisi, afin de continuer la chasse aux côtés de l’équipe MTR.

Vous pouvez obtenir plus d’informations sur cette étude de cas en parcourant l’article suivant : Sophos MTR : un adversaire actif pris en flagrant délit.

Chasses aux menaces sans indices (leadless)

Alors que les chasses à partir d’indices nécessitent l’un de nos capteurs pour détecter ou générer un “signal” digne d’intérêt ; une chasse aux menaces sans indices est beaucoup plus naturelle. Bien que nous puissions toujours utiliser nos algorithmes d’intelligence artificielle pour traiter la grande quantité de données que nous ingérons, les chasses aux menaces sans indices sont presque toujours dirigées, dès le départ, par un véritable analyste, expert en menaces.

Plutôt que de nous fier à ce signal initial systématique pour nous avertir qu’un élément doit faire l’objet d’une investigation, nous exécutons de manière proactive des requêtes au niveau des domaines d’un client ou de plusieurs clients. Ces opérations peut être déployées pour plusieurs raisons (liste non exhaustive) :

  • Un client Sophos dans le même secteur vertical a été ciblé d’une manière particulière, et nous voulons faire les vérifications qui s’imposent pour nous assurer que les mêmes acteurs malveillants ne tentent pas d’attaquer l’un de nos autres clients MTR Advanced.
  • Les SophosLabs ont informé l’équipe MTR d’une attaque importante ciblant des clients, soit dans le même secteur, soit avec des caractéristiques similaires, ciblant un ou plusieurs clients MTR Advanced.
  • Un événement important s’est produit dans le paysage de la sécurité et nous voulons savoir si l’un de nos clients a été affecté. Dans le paysage actuel où les menaces zero-day sont de plus en plus avancées et répandues, ce type d’évènement n’est malheureusement que trop courant.

Pour en savoir plus sur le service Sophos MTR, vous pouvez visiter sur notre site Web ou bien parcourir nos études de cas et nos recherches.

Billet inspiré de Secrets of a security analyst: Starting a threat hunt, sur le Blog Sophos.

Qu’en pensez-vous ? Laissez un commentaire.

Your email address will not be published. Required fields are marked *