.jpeg){kind=logo}
Les attaquants ont tendance à définir leurs propres règles plutôt que de modifier celles déjà mises en place par l'utilisateur. L'équipe MDR de Vectra a mené des recherches à ce sujet dans les environnements de ses clients. Voici ce qui ressort de l'analyse globale des décisions quotidiennes de nos analystes, ainsi que ce qu'un SOC peut en tirer.
En tant qu'équipe MDR, nous effectuons chaque jour un tri des détections provenant de nombreux environnements clients. L'une d'entre elles, notre détection « Règle de boîte de réception suspecte Microsoft 365 », signale les règles de boîte de réception qui méritent un examen plus approfondi. La plupart de ces détections se résolvent de deux manières : soit un analyste les classe comme inoffensives, soit il les transmet au client pour validation. Prises individuellement, il s’agit d’interventions de routine. Mais considérées dans leur ensemble, issues d’environnements clients de toutes les régions et de tous les secteurs d’activité, et étayées par les confirmations des clients lorsque les cas sont transmis, elles se sont avérées receler une information précieuse : une vision précise et partagée de la manière dont les attaquants utilisent réellement les règles de boîte de réception.
Pourquoi les règles de boîte mail méritent qu'on s'y intéresse
Les règles de la boîte de réception constituent une fonctionnalité courante visant à améliorer la productivité : elles permettent de transférer, déplacer, marquer ou supprimer automatiquement des e-mails.
Cette fonctionnalité est particulièrement prisée par les attaquants après une Usurpation de compte, car elle leur permet de contrôler une boîte mail en toute discrétion, sans malware processus sur aucun endpoint. Deux types d'abus prédominent : le transfert de courriers vers une adresse externe (exfiltration, MITRE ATT&CK .003) et le déplacement ou la suppression des courriers entrants afin de dissimuler les notifications de sécurité et les réponses (évasion, MITRE ATT&CK .008).
Pourquoi ne pas se contenter d'étudier les attaques ?
Une question légitime : si l’on souhaite comprendre les attaquants, pourquoi ne pas se contenter d’étudier les attaques confirmées ? L’étude isolée des attaques permet de voir ce que font les attaquants, mais pas à quelle fréquence cette même action apparaît dans le cadre d’une utilisation normale et inoffensive ; or, c’est précisément ce contraste qui rend un comportement digne d’intérêt. Une règle qui supprime les e-mails entrants peut sembler alarmante au milieu d’une multitude d’attaques ; ce n’est qu’en la comparant à l’activité quotidienne que l’on se rend compte qu’elle est véritablement rare, et qu’elle constitue donc un signal. Comprendre ce qui est normal afin de reconnaître ce qui ne l’est pas est un principe bien connu en matière de détection. Nous l’avons appliqué à une autre forme de « normalité » : les décisions quotidiennes que prennent les analystes concernant une détection. Cette majorité bénigne n’est pas un fatras à écarter. Chaque clôture bénigne est un jugement sur ce qui ne constitue pas une attaque, et considérés dans leur ensemble, ces jugements constituent un savoir que l’étude des attaques seules ne permettrait pas d’acquérir.
Le profil qui se dégage de nos données
Dans l'ensemble, les analystes classent chaque comportement entre « courant » et « mérite une attention particulière ». Le déplacement des e-mails vers un dossier est l'action la plus courante observée chez les attaquants à l'aide d'une règle, suivie par le transfert et la suppression ; cependant, il s'avère que la fréquence d'un comportement ne permet pas de déterminer dans quelle mesure il doit vous inquiéter. Voici ce qui a retenu notre attention.
Ils créent ; ils ne réécrivent pas. Dans toutes les attaques que nous avons confirmées, les règles malveillantes sont celles de l’attaquant lui-même : elles sont créées puis modifiées, souvent en une seule fois, plutôt que d’être des règles existantes du client réutilisées. Le schéma est systématique : les attaquants apportent leurs propres règles. C’est dans le déplacement de courriers vers un dossier que l’on peut le plus clairement observer cette routine : la modification d’une règle de déplacement vers un dossier existant depuis longtemps, dans les cas où les analystes ont pu constater précisément les effets de cette modification, ne justifie presque jamais une escalade. Les tâches de maintenance quotidiennes et la nouvelle configuration mise en place par un attaquant n’ont absolument rien en commun.
La suppression est un événement rare et marquant. Très peu de règles de boîte de réception suppriment les e-mails entrants, mais lorsqu’un analyste en repère une, elle fait l’objet d’une escalade bien plus souvent que la norme habituelle, et nos cas confirmés montrent que cet instinct est justifié. La suppression visant à faire disparaître des réponses et des notifications de sécurité est une manœuvre de dissimulation, et elle se comporte comme telle dans les données. Alors que la modification d’une ancienne règle de déplacement vers un dossier est du bruit, la suppression est un signal.
Le transfert se situe dans une zone grise. Il occupe une position intermédiaire : ni rare ni courant, mais avec une part non négligeable de cas confirmés comme malveillants. Les choses ne se séparent pas toujours clairement, et c'est précisément dans le domaine du transfert qu'il faut redoubler de vigilance, plutôt que de relâcher la pression. Le fait de le dire en toute honnêteté fait partie du propos.
Comment les pirates se trahissent. Deux indices sont revenus régulièrement dans nos cas confirmés. Les règles créées par les pirates portent de manière disproportionnée des noms étranges et minimalistes : une seule lettre, un ou deux points isolés, le genre de nom « jetable » qu’une personne normale ne choisirait pas. Et lorsque les pirates déplacent des e-mails, ils ont tendance à utiliser les dossiers par défaut plutôt que des dossiers personnalisés. Aucun de ces indices n’est une preuve en soi, mais ensemble, ils permettent de préciser le tableau.
Ce qu'un SOC peut faire avec cela
Un profil de ce type peut être exploité de deux façons à la fois : pour atténuer les alertes de routine et pour mettre en évidence les éléments réellement suspects. Le fonctionnement du système de notation de la Vectra AI permet de le faire en toute sécurité : chaque détection est associée à un niveau de gravité basé sur la règle qui l’a déclenchée, et ce niveau de gravité est pris en compte, avec d’autres facteurs, dans un score unique au niveau du compte qui reflète l’ensemble de l’activité sur ce compte. Ainsi, la gravité attribuée à un schéma routinier peut être réduite sans créer d’angle mort : un compte présentant également une connexion inhabituelle, ou tout autre signal indépendant, reste en tête de liste. La routine passe inaperçue ; la combinaison véritablement suspecte reste mise en avant.
Il est essentiel de noter que rien de tout cela n'est automatique. Une tendance qui semble récurrente dans notre historique n'est qu'une hypothèse ; nous validons donc chaque élément du profil par rapport à nos propres cas d'attaques confirmés avant qu'il ne serve de base à quoi que ce soit, et toute modification du système de notation de la détection ferait l'objet d'un examen de sécurité, et ne serait pas directement mise en production.
Ce que cela améliore
L’intérêt d’un profil comme celui-ci ne réside pas dans le profil lui-même, mais dans ce qu’il permet d’apporter à la détection et au service qui l’entoure. Les intuitions qui, autrefois, n’existaient que dans l’esprit d’un analyste expérimenté deviennent explicites et réutilisables, ce qui évite d’avoir à redécouvrir le même jugement au cas par cas. Les comportements routiniers peuvent être mis en sourdine tandis que les combinaisons véritablement suspectes restent mises en avant, ce qui signifie moins de temps perdu en fausses alertes et davantage d’attention portée à ce qui le mérite réellement. Et le travail quotidien de triage cesse d’être un coût qui s’enfonce dans une pile de tâches en attente pour devenir une boucle de rétroaction, chaque modèle validé rendant le cycle de détection suivant un peu plus précis. Il en résulte un service qui se fait plus discret là où il le doit et plus vigilant là où il le faut, et qui parvient de mieux en mieux à distinguer les deux au fur et à mesure de son fonctionnement.
Le profil spécifique est utile, mais la méthode qui le sous-tend est encore plus importante. Chaque SOC s'appuie sur un historique de décisions prises par les analystes, qui renferme discrètement des connaissances durement acquises sur le comportement des attaquants, et dont la quasi-totalité n'est pas consignée par écrit. Considérer cet historique comme une source d'informations, plutôt que comme un simple arriéré, transforme le tri quotidien en une boucle de rétroaction qui affine les détections et permet aux analystes de gagner du temps.
Vectra AI
Le profil de règle de boîte mail décrit ici n'est qu'un exemple parmi d'autres de la manière dont Vectra AI améliore Vectra AI la détection comportementale. Chaque détection s'appuie sur des recherches continues en matière de sécurité, des observations concrètes des attaquants et les retours d'expérience de notre équipe MDR. Cette combinaison d'IA, d'analyse comportementale et d'expertise humaine permet aux équipes de sécurité de consacrer moins de temps à examiner les fausses alertes et davantage à réagir aux menaces qui comptent vraiment.
Découvrez comment la Vectra AI utilise la détection comportementale basée sur l'IA pour bloquer les attaques hybrides ciblant les identités, cloud, les solutions SaaS, les terminaux et les réseaux.