L’année 2021 a été marquée par la publication de nombreuses vulnérabilités. On peut citer entre autres les vulnérabilités liées au service Microsoft Exchange qui a connu à lui seul la publication de huit CVE réparties sur la période de Mars à Août 2021. Ces dernières portaient les noms de ProxyLogon (CVE-2021-26855, CVE-2021-26858, CVE-2021-26857, et CVE-2021-27065) et Proxy Shell (CVE-2021-34473, CV-2021-34523, CVE-2021-31207). Ces vulnérabilités permettent la prise de contrôle et l’exécution de codes arbitraires sur n’importe quel serveur Exchange exposé sur Internet, qui plus est : sans authentification.  Via l’architecture des serveurs Exchange, ces failles donnent la possibilité d’élever ses privilèges au niveau d’administrateur de domaine (niveau le plus élevé d’autorisation dans le domaine). Ces vulnérabilités ont été massivement exploitées par différents groupes d’attaquants aux motivations diverses : financières via le vol de données et le déploiement de Ransomware ou étatiques. Par ailleurs, cela constitue également une porte d’entrée formidable pour des attaquants du fait l’exposition quasi obligatoire de ces environnements et la défaillance des processus de gestion des vulnérabilités d’autre part. Dans le cas de ProxyLogon par exemple, Microsoft a publié un correctif le 2 Mars 2021. Dans notre SOC « at-Defense », nous avons constaté des attaques sur nos clients dès le 3 Mars 2021 alors qu’il n’existait pas encore de code d’exploitation officiellement publié. Cette observation démontre bien la complexité du processus de gestion des vulnérabilités et de leur suivi qui doivent être effectués en « temps réel » pour prévenir ces attaques dans des fenêtres de temps extrêmement courtes. Et oui : les attaquants n’attendent pas les réunions d’appréciation de risques et les Change Advisory Board pour lancer leurs méfaits ! Cette période a été extrêmement chargée pour nos équipes. Outre la charge de travail induite sur notre service de monitoring des menaces (MSS « At-Defense »), nous étions également contactés par des entreprises qui n’étaient pas sous notre surveillance. Déclenchant ainsi des opérations de réponses à incident en urgence absolue et des investigations post-mortem (aka forensique). Et cela, plusieurs semaines après la publication des failles ; les clients se rendant compte de la compromission en générale par la présence d’un ransomware. Sur l’ensemble des investigations effectuées, nous avons noté un nombre important d’attaquants avec des motivations diverses et variées qui se promenaient allègrement sur le parc des clients en prenant le contrôle du domaine, exfiltrant des données et une fois « terminé » déployaient un ransomware pour augmenter leur profit.

Microsoft a quelque peu semé le trouble … Après une communication bien fournie sur la faille de mars, un grand nombre d’entreprises, ont pris conscience de l’urgence, et ont pu se préparer afin d’éviter le pire. Cependant, celle-ci a laissé passer la faille publiée en août (presque identique en termes d’impact) comme quasiment « inaperçue », laissant de nombreuses entreprises vulnérables pendant une large fenêtre de temps. Lors de nos travaux de réponses aux incidents, nous demandions quand le patch Exchange avait été appliqué. La réponse était systématiquement : mars 2021. Ces mêmes entreprises étaient donc bien exposées à la nouvelle faille parue en août.

Notre équipe a eu l’opportunité de travailler avec des entreprises concernées par l’affaire des « Pandora papers » – 11.9 millions de documents fuités et communiqués à l’International Consortium of Investigative Journalists (ICIJ). Des investigations forensiques effectuées pour ces mêmes clients dans le cadre d’attaque par ransomware sur la période d’octobre, nous ont permis de constater que ces clients étaient également impactés par les failles Exchange. De même, nos équipes ont pu retrouver des traces d’exploitations et de vols de données avérées en août 2021 sur au moins trois clients. Dans ces conditions, dès lors que le consortium de journaliste (ICIJ) disposait des informations dès le mois de septembre le lien de la fuite de données à travers l’exploitation de cette faille ne peut être complètement écarté…

La réponse aux incidents est un métier qui demande des compétences d’analyses évoluées, tant sur les aspects offensifs que défensifs, ainsi qu’un maintien continu des connaissances des schémas d’attaque et de défense. Les « Incident Responders » interviennent après une constatation d’incident ou un doute. Ils assistent le client souvent pendant plusieurs jours dans la remédiation correcte de son incident tout en fournissant un rapport et des conseils sur les implémentations à effectuer pour se prémunir de ces attaques. Ce travail de fourmis démarre d’une machine compromise pour retrouver le « patient zéro », la méthode d’intrusion initiale, les mouvements internes qu’il y a pu avoir entre les machines, les persistances laissées par l’attaquant, les outils utilisés par l’attaquant, le niveau de privilèges et d’accès dont disposaient les attaquants, les données exfiltrées etc.

Chez e-Xpert Solutions, nous privilégions systématiquement un contrôle à quatre yeux, impliquant deux analystes. La communication interne avec le board de direction ou conseil d’administration est un autre élément sensible dans lequel le spécialiste forensique contribue en apportant de précieux conseils tant sur la bonne démarche de retour en production que sur la communication avec les tiers (clients externes, partenaires, NCSC, organes de police, etc.)

Sans cette investigation avancée, repartir en production à partir d’une simple sauvegarde est le chemin assuré vers un nouvel incident dans les jours qui suivent. À ce jour, nous n’avons jamais eu à revenir chez un client après une réponse aux incidents.

Dans la panique, et sans doute par méconnaissances, nous observons régulièrement des entreprises qui s’adressent à des éditeurs de solutions (tels que des vendeurs d’antivirus) de sécurité pour leurs réponses aux incidents. L’approche d’un éditeur diffère de manière significative de celle des analystes et consistera en général en un traitement symptômatique plutôt que d’identifier la « root cause » de l’attaque. Vulgairement dit, ils appliqueront un sparadrap sur la blessure plutôt que d’en soigner la cause, en déployant un produit « miracle », qui au passage, détruit régulièrement les preuves primordiales à une investigation policière ou permettant simplement de remonter à la source de l’attaque.

Un SOC peut-il aider les entreprises à se prémunir de ces problèmes ?

Un Security Operations Center (ou SOC) tient un rôle fondamental : il a la charge de prévenir, détecter et répondre aux incidents de sécurité. Si votre SOC effectue son travail correctement, la partie analyse forensique approfondie (analyse disque, mémoire, etc) ne devrait jamais avoir lieu puisque la menace sera détectée suffisamment tôt et, ainsi, le risque prévenu.

Très concrètement le SOC repose sur plusieurs principes simples :

• Être à jour sur les menaces
• Collecter des informations venant de tous vos équipements liés à la sécurité
• Normaliser ces informations pour être capable de croiser des données entre elles
• Enrichir ces évènements collectés avec des informations de contexte (informations sur les utilisateurs, les systèmes, réputation d’IP, de domaines, infos géographiques etc.)
• Centraliser ces informations (dans une solution appelée SIEM)
• Corréler ces informations avec des indices de compromission connus (IOC) et appliquer des modèles de détection de menaces
• Générer des alertes qui seront revus par les analystes
• Répondre aux incidents
• Fournir des rapports au management

Dans le cadre de nos activités, nous sommes aussi amenés à auditer d’autres SOC. Là encore, nous régulièrement les mêmes lacunes : sources de données manquantes, scope de collecte trop restreint, ou à l’inverse trop volumineuse et sans intérêt pour la corrélation et entrainant des coûts importants pour le client sans gain réel en terme de sécurité. Parfois les modèles de détection sont désuets et ne prennent pas en compte les indicateurs de compromission fournis par les organismes gouvernementaux pourtant facilement exploitables et gratuitement dans un nombre de cas. Ces lacunes se traduisent dans tous les cas en une capacité limitée à détecter des attaques même basiques.

Le conseil que nous pourrions donner est de choisir son prestataire sur des critères tangibles et mesurables dans son propre environnement. L’accompagnement par un conseil spécialisé du domaine peut être judicieux et permettra de mitiger l’ascendant psychologique de certains éditeurs ou autres « acteurs incontournables » du secteur. Concrètement, on demandera des évidences démontrant concrètement comment la technologie utilisée permet des détections avancées (analyses statistique, fréquence, anomalies, mouvements latéraux, etc) ? Quels sont les temps de réponse définis ? Le déploiement de la solution couvre-t-il l’ensemble de l’infrastructure du endpoint aux équipements réseau ? Y a-t-il des possibilités d’optimiser les coûts, notamment en filtrant du volume inutile à corréler en termes de sécurité ? Les exemples de reporting présentés sont-ils suffisamment clairs et utiles au-delà de l’esthétique graphique ou du nombre de pages ?  Le service dispose-t-il d’une certification garantissant des processus formels et établis telle que ISO  27001? Après avoir sélectionné un prestataire-candidat convaincant, le test ultime demeurera un « Proof Of Value » en couplant la solution proposée avec à un test d’intrusion effectué par un prestataire différent basé sur le framework MITRE ATT&CK. Cet exercice doit aboutir à des alarmes quasiment immédiates côté SOC. Dans le cas contraire : passer votre chemin.

Chez e-Xpert Solutions, nous mettons en œuvre l’ensemble des bonnes pratiques en termes de détection permettant de détecter des attaques connues mais également inconnues. En effet, sans disposer d’indicateurs ou de règles supplémentaires notre service était capable de détecter les attaques évoquées précédemment dès leur arrivée (avant le 2 mars). La technique utilisée est finalement assez simple : nous surveillons les exécutions de commandes ayant comme parent le service IIS (utilisé par MS Exchange). Si un des processus « fils » ne correspond pas à un modèle d’exécution vu sur les deux mois précédents, cela devient une anomalie. Cette approche nous a permis de détecter aisément les tentatives d’exploitations de ces vulnérabilités pour des clients non patchés. Nous surveillons également les vulnérabilités dites sensibles (exploitables publiquement sur des produits connus sans authentification) et prévenons nos clients sous forme de bulletin d’information important en avance de phase.

Comment se préparer à de telles attaques ?

Comme dans bien des domaines, l’anticipation est un enjeu majeur. Dans le cadre de nos activités de réponses aux incidents (clients non-SOC), nous constatons 9 fois sur 10 les mêmes lacunes liées à l’architecture du réseau ou aux systèmes :

Manque de suivi des patchs. Il convient de mettre en place une surveillance accrue des vulnérabilités et d’établir un processus de changements rapides (< 24h pour les vulnérabilités critiques sur les systèmes exposés)
Des réseaux dits « plats » ou chaque machine peut accéder à n’importe quelle autre machine sans couche « d’isolation », au niveau du réseau, entre les zones critiques. Un serveur Web compromis peut donc servir de rebond pour attaquer les autres machines du réseau.
Pas de filtrage des flux sortants vers Internet. Un attaquant peut aisément créer un canal de communication vers son environnement pour faciliter la prise de contrôle ou l’exfiltration de données.
Des problèmes au niveau de la sécurité liée aux authentifications notamment avec des mots de passe d’Administrateur local identique entre toutes les machines. On observe souvent ce cas quand le processus de déploiement de nouvelle machine est basé sur une « Gold Image ». Une solution gratuite est la mise en place de la technologie LAPS de Microsoft permettant de remédier efficacement à ce problème.
Des problèmes de sécurité au niveau Active Directory. Une solution simple consiste à utiliser l’outil PingCastle (gratuit) pour avoir un diagnostic rapide des problèmes de sécurité afin de pouvoir y remédier.
Absence de technologie de sécurité endpoint de type Endpoint Detection & Response (EDR). Celles-ci vont effectivement au-delà des capacités offertes par un antivirus classique. Il permet notamment de remonter des anomalies à un SOC qui pourra ainsi les analyser et les corréler.
Pas de centralisation des logs. Ce problème est malheureusement récurrent et met à risque l’ensemble de l’entreprise. Si une technologie de centralisation est mise en place en amont, l’intervention sera rapide, en moins d’une heure. Si ce n’est pas le cas, nous avons eu à faire des investigations pouvant durer 4 jours/nuits, avec des analyses lourdes et approfondies au niveau disque et mémoire.
Pas de service de Security Operations Center permettant de gérer, corréler les éléments remontés afin de détecter des menaces ou des anomalies.
Et bien sûr… la sensibilisation des utilisateurs aux risques de sécurité qui devrait être effectuée à minima une fois par an et surtout évaluée via des campagnes de phishing par exemple.

Ces éléments ne sont aujourd’hui plus des « Nice to have » mais bien des « Must have » pour faire face aux menaces qui ciblent les entreprises de petites ou de grandes tailles. Les attaquants ne faisant pas la différence.