Les correctifs seuls ne suffisent pas : comment définir et analyser sa fenêtre d’exposition ?

Cybersécurité

Suite aux récentes vulnérabilités sérieuses, au niveau de Microsoft Exchange, qui ont été exploitées sur le terrain par Hafnium, DearCry et un nombre croissant d’autres groupes malveillants, il est essentiel de comprendre que les correctifs seuls ne suffisent pas.

correctifs

Les correctifs vous protègent pour le futur. Ils traitent des failles qu’un adversaire aurait pu utiliser pour pénétrer au sein de votre réseau. Mais ces correctifs, dans la plupart des cas, ne font rien pour contrecarrer un adversaire qui aurait déjà utilisé cette faille, abusant ainsi d’une vulnérabilité non corrigée.

Attention, l’installation de correctifs est une action fondamentale pour mitiger le risque d’une vulnérabilité logicielle, mais lorsque cette dernière est connue du grand public ou a été exploitée sur le terrain avant la publication d’un correctif, il est essentiel de traquer les menaces et d’analyser l’activité du système au niveau de l’ensemble de votre fenêtre d’exposition.

Fenêtre d’exposition

correctifs

Lorsqu’une vulnérabilité logicielle est divulguée publiquement, une fenêtre d’exposition s’ouvre. La fenêtre est le temps entre deux événements cruciaux : la première observation de l’utilisation de la vulnérabilité et le moment où vous avez installé un correctif disponible ou mitigé la menace.

Une fenêtre d’exposition vous permet de définir temporellement (étape appelée également timeboxing) le moment où une activité adverse a pu se produire et de vous lancer dans une traque des menaces au niveau de ce lapse de temps.

Votre fenêtre d’exposition locale est le temps entre le premier indicateur d’attaque (IOA) ou indicateur de compromission (IOC) identifié au sein de votre réseau ou à sa périphérie, et le moment où vous avez installé le correctif correspondant à la vulnérabilité. S’il n’existe pas d’IOC ou d’IOA dans votre réseau, la date de la divulgation publique de la vulnérabilité peut être utilisée.

Pour beaucoup, les web shells sont apparus sur leurs serveurs Exchange à partir du 27 février 2021, au moment où Hafnium et d’autres ont commencé à exploiter en masse les vulnérabilités.

Votre fenêtre d’exposition globale commence avec le premier abus connu sur le terrain ou la divulgation publique de la vulnérabilité, selon bien sûr l’évènement qui a lieu en premier, et se termine lorsque vous avez installé le correctif concerné.

Les rapports publiés en matière de renseignement montrent qu’à plusieurs reprises la fenêtre d’exposition globale s’est ouverte, avec de nombreuses équipes de sécurité qui ont identifié une exploitation réussie en janvier 2021, mais des commentaires anecdotiques sur les réseaux sociaux suggèrent que l’exploitation a pu avoir lieu dès novembre 2020.

Pour ProxyLogon/Hafnium, votre niveau d’exposition local et global ressemblera au schéma ci-dessous :

correctifs

Timeboxing et traque au sein de votre fenêtre d’exposition

Les correctifs nous fournissent l’un des horodatages nécessaires pour le timeboxing d’une fenêtre d’exposition, à savoir l’heure à laquelle la fenêtre s’est fermée, mais nous devons également identifier quand cette fenêtre s’est ouverte.

Nous savons que la fenêtre d’exposition globale s’est ouverte entre novembre 2020 et janvier 2021. Cependant, l’identification de l’ouverture de la fenêtre d’exposition locale nécessite que les IOC ou les IOA soient recherchés afin d’identifier si une vulnérabilité a été utilisée et, le cas échéant, extraire les horodatages à partir des observations faites afin de faciliter le timeboxing et la traque des menaces ultérieures au niveau des activités adverses.

Les conseils récents de Microsoft à l’intention des défenseurs fournissent une description détaillée pour identifier si vous avez été compromis par les récentes vulnérabilités de Microsoft Exchange.

À partir de ces conseils, on peut extrapoler deux risques majeurs liés à ces vulnérabilités: l’accès non autorisé aux emails et le déploiement de web shells.

Accès non autorisé aux emails

Vous devez d’abord examiner la sortie de Test-ProxyLogon.ps1 et rechercher la présence de Cve-2021-26855.csv car cet élément indiquera une exploitation réussie de la vulnérabilité Request Forgery côté serveur.

Si le .csv contient des références, dans la colonne AnchorMailbox, à /ews/exchange.asmx? alors cela indique qu’un attaquant a pu exfiltré des emails. Pour investiguer, vous devrez consulter les logs Exchange situés dans <Exchange install path>\V15\Logging\EWS.

Déploiement de web shells

En utilisant les outils mis à disposition par Microsoft dans leurs conseils aux défenseurs, ou si vous utilisez Sophos Intercept X EDR, tirez parti de nos conseils et requêtes, pour identifier la présence de web shells déployés par un adversaire.

Si des web shells sont présents, vous devez examiner la potentielle activité de commande pour révéler les actions entreprises par l’adversaire.

Les web shells permettent à un adversaire d’envoyer à distance des commandes à votre serveur et d’orchestrer le reste de son attaque. S’ils en ont déployé un avec succès à l’intérieur de votre réseau, il pourrait être utilisé pour n’importe quel type d’activité. Ainsi, nous devons découvrir ce qu’un adversaire a fait avec ce shell et comprendre quel est impact de celui-ci.

Activité adverse

Utilisez la technologie EDR, telle que Sophos Intercept X EDR, pour effectuer des recherches dans vos fenêtres d’exposition afin d’identifier les activités adverses. Une solution EDR nous fournit un historique des enregistrements de la télémétrie du système, comme les exécutions de commandes et l’activité de processus, que nous pouvons rechercher rétrospectivement.

Tout d’abord, votre fenêtre d’exposition locale doit être examinée car il s’agit de la période durant laquelle le risque a été le plus élevé. Une fois cet examen terminé et après vous être assuré de pouvoir vous reposer en toute confiance sur vos résultats, votre fenêtre d’exposition globale doit être examinée à son tour.

Au niveau de chaque fenêtre, examinez toute activité pouvant révéler un comportement anormal, un accès aux fichiers, un mouvement latéral, une élévation de privilèges, une exfiltration, l’intégration de code additionnel, des modifications de configuration, etc.

Le scénario le plus courant observé par Sophos MTR (Managed Threat Response) est celui où le processus parent est w3wp.exe ou umworkerprocess.exe avec une activité malveillante provenant de ces processus.

Nous avons également vu beaucoup de compilation à la volée d’assemblys C#.NET à l’aide de csc.exe, et avec celui-ci, vous pouvez rechercher dans le répertoire suivant les DLL suspectes :

C:\Windows\Microsoft.NET\Framework64\v4.0.30319\Temporary ASP.NET Files\root\%

correctifs

Il est important de noter que si le comportement ci-dessus a été observé dans plusieurs réseaux différents par Sophos MTR, la nature des vulnérabilités indique qu’il existe une possibilité pour que différents scénarios se produisent. Nous vous recommandons vivement d’utiliser le timeboxing de vos fenêtres d’exposition pour examiner toute l’activité du système, en particulier à un moment proche du déploiement du web whell par l’adversaire, mais aussi après la mise en œuvre de ce dernier.

Framework d’Investigation Sophos

Rester concentré pendant une investigation n’est pas une tâche facile. L’analyse des données et le suivi des pistes peuvent vous conduire dans de nombreux et différents recoins. Ne pas dévier de son objectif nécessite une approche méthodique.

Dans Sophos MTR, nous utilisons notre propre framework d’investigation que nous appelons Threat Detection and Response (ou TDR en abrégé). Nous avons déjà écrit sur ce framework et les outils qu’il contient vous aideront à la fois lors d’une investigation mais aussi lors de la préparation du prochain potentiel incident.

Ayez conscience de vos capacités et de vos limites

Mener des investigations à la suite d’incidents majeurs comme Hafnium/ProxyLogon demande du temps et de l’expertise. Pour de nombreuses entreprises, être certain qu’il n’y a pas d’activité adverse au sein de leur réseau est tout simplement hors des capacités actuelles de leurs équipes.

Si vous pensez être confronté à une menace active qui a exploité les vulnérabilités de Microsoft Exchange, en particulier si vous avez pu identifier la présence de web shells, Sophos Rapid Response est là pour vous aider et vous assurer que les adversaires seront expulsés de votre réseau.

Si vous n’êtes pas confronté à une menace active mais souhaitez qu’une équipe d’experts surveille votre réseau 24h/24 et 7j/7, identifiant, investiguant et répondant aux menaces qui ont échappé à vos défenses, Sophos Managed Threat Response est là pour vous aider.

Enfin, si vous faites partie des entreprises chanceuses qui n’ont pas été victimes de l’exploitation de serveurs Microsoft Exchange vulnérables et que votre investigation n’a révélé aucun signe de web shells ou d’activité adverse, prenez le temps de passer en revue vos capacités de détection et de réponse aux menaces avant la prochaine attaque.

Les incidents majeurs tels que ProxyLogon sont de formidables opportunités pour apprendre et ainsi en comprenant le vecteur de menace et le comportement adverse observés après l’exploitation, vous pourrez ajouter des capacités de détection et de réponse inestimables pour accélérer les investigations à venir et prévenir les menaces futures.

Billet inspiré de Patching alone is not enough: Investigate your exposure windows, sur le Blog Sophos.

Leave a Reply

Your email address will not be published.