Guide de mitigation des vulnérabilités zero-day de Microsoft Exchange : Ce qu’il faut savoir et ce qu’il faut faire maintenant

  • Dernière mise à jour
  • Dernière mise à jour juillet

Bannière d'alerte de sécurité MSP

Mise à jour le 16 mars 2021. 

Le mardi 2 mars, Microsoft a annoncé qu’elle avait détecté une série de quatre exploits de vulnérabilité de type “zero-day” ou “0-day” activement utilisés pour attaquer des versions d’Exchange Server sur site. Des correctifs sont disponibles et il est vivement conseillé aux entreprises d’identifier, de mettre à jour et de vérifier les systèmes vulnérables le plus rapidement possible.

Nous avons créé cet article pour rassembler des ressources et des informations connexes et nous le mettrons à jour régulièrement.

Contenu

 

Vue d’ensemble

Vous trouverez ci-dessous des résumés et des fils à suivre pour vous mettre au diapason :

 

Informations sur les menaces fournies par les entreprises de sécurité

Huntress
Exploitation massive des serveurs Exchange sur site (fil de discussion sur r/msp)

Fil de réponse rapide de Huntress destiné spécifiquement aux MSP, comprenant des informations sur les menaces et des conclusions tirées de l’examen de leur propre base de partenaires. Huntress est activement mise à jour au fur et à mesure que de nouvelles informations sont disponibles.

Huntress a également organisé un séminaire en ligne le 4 mars à 13h ET et a présenté un résumé de ses recherches et de ses observations jusqu’à présent. Regarder à la demande ici.

Volexité
Opération Exchange Marauder : Exploitation active de multiples vulnérabilités de jour zéro dans Microsoft Exchange

L’un des premiers à avoir identifié (le 6 janvier !) et rapporté cette activité. Ce billet fournit plus de détails sur la manière dont les vulnérabilités sont effectivement exploitées ainsi qu’une courte liste de TTP (tactics, techniques, and procedures) observées après l’exploitation. Il fournit également des IoC supplémentaires.

FireEye
Détection et réponse à l’exploitation des vulnérabilités Zero-Day de Microsoft Exchange

Elle confirme également l’observation des abus en janvier et contient une autre analyse technique intéressante des attaques. Contient des conseils supplémentaires pour enquêter sur les compromissions potentielles (voir ci-dessous).

Canari rouge
Exploitation du serveur Microsoft Exchange : Comment détecter, atténuer et rester calme ?

Fournit une ventilation de l’activité de menace post-exploitation que Red Canary a identifiée, ainsi que des opportunités de détection pratiques et des conseils de remédiation.

CrowdStrike
Falcon Complete bloque les exploits de type “Zero-Day” de Microsoft Exchange Server

Si vous pouvez passer outre le titre et l’angle de vente, ce billet fournit des détails techniques supplémentaires, des IoC, et un bon récapitulatif de la découverte et de la chasse aux menaces.

 

Quelles sont les vulnérabilités ?

Microsoft a identifié quatre vulnérabilités activement exploitées, mais la mise à jour de sécurité hors bande de l’entreprise traite également trois vulnérabilités supplémentaires d’exécution de code à distance (RCE) qui n’ont pas été associées aux attaques actives.

Accès initial

CVE-2021-26855 

CVSSv3 : 9,1

Une vulnérabilité de type SSRF (server-side request forgery) dans Exchange qui permet à des attaquants distants d’envoyer des requêtes HTTP arbitraires et de s’authentifier en tant que serveur Exchange.

Selon la société de sécurité Volexity :

Cette vulnérabilité est exploitable à distance et ne nécessite pas d’authentification d’aucune sorte, ni de connaissances particulières ou d’accès à un environnement cible. L’attaquant n’a besoin que de connaître le serveur exécutant Exchange et le compte à partir duquel il veut extraire le courrier électronique.

L’exploitation réussie de cette vulnérabilité donne à un attaquant la possibilité d’exploiter les trois autres vulnérabilités ci-dessous.

Post-authentication remote code execution (RCE)

CVE-2021-26857

CVSSv3 : 7,8

Selon Tenable, la faille réside dans le Exchange Unified Messaging Service, qui permet la fonctionnalité de messagerie vocale en plus d’autres fonctions. Elle permet d’exécuter du code en tant que SYSTEM sur le serveur Exchange, mais nécessite l’autorisation de l’administrateur ou une autre vulnérabilité pour être exploitée.

CVE-2021-26858

CVSSv3 : 7,8

Si les attaquants sont en mesure de s’authentifier auprès du serveur Exchange (soit en exploitant CVE-2021-26855, soit en compromettant les informations d’identification d’un administrateur légitime), ils peuvent utiliser cette vulnérabilité pour écrire un fichier dans n’importe quel chemin d’accès sur le serveur.

CVE-2021-27065

CVSSv3 : 7,8

Idem.

 

Remarques sur l’activité post-exploitation

Comme l’ont signalé FireEye, Volexity et d’autres, des attaquants ont abusé de ces vulnérabilités pour lancer des shells web, y compris des variantes de China Chopper. Ils permettent aux attaquants de préparer le terrain et d’effectuer toute une série d’activités de post-exploitation.

Les TTP observées sont les suivantes

  • Vol d’informations d’identification à l’aide de ProcDump (outil Windows Sysinternals légitime) pour vider la mémoire du processus LSASS
  • Exfiltration de données, y compris Carnets d’adresses hors ligne d’Exchange
  • Exporter des données de boîte e-mail via les Snap-ins Exchange PowerShell
  • Établissement d’un accès à distance via PowerCat et d’autres cadres d’attaque

Pour plus d’informations sur les menaces post-exploitation, voir les recherches de Red Canary.

 

“Vulnérabilités non liées “Bonus

Outre ces vulnérabilités de type “zero-day”, Microsoft a également corrigé les failles RCE suivantes, qui n’ont aucun lien entre elles :

  • CVE-2021-26412 (CVSSv3 : 9.1)
  • CVE-2021-26854 (CVSSv3 : 6.6)
  • CVE-2021-27078 (CVSSv3 : 9.1)

 

Quelles sont les versions d’Exchange concernées ?

Comme Huntress l’a dit succinctement lors de leur webinaire: tous.

quelles sont les versions d'exchange vulnérables

  • Exchange Server 2010
  • Exchange Server 2013
  • Exchange Server 2016
  • Exchange Server 2019

Remarque : Microsoft a confirmé qu’Exchange Online n’est PAS affecté.

Quelle est l’ampleur des attaques ?

Bien que Microsoft ait initialement décrit les attaques comme étant “limitées et ciblées”, les conclusions ultérieures d’autres fournisseurs et chercheurs indiquent que l’activité a été beaucoup plus répandue et indiscriminée.

Mise à jour : On estime qu’au moins 30 000 entreprises américaines ont été compromises

Le vendredi 5 mars, Brian Krebs a rapporté que de multiples sources estimaient que des centaines de milliers d’entreprises avaient été compromises dans le monde entier, dont 30 000 rien qu’aux États-Unis.

Le journaliste de Wired, Andy Greenberg, l’a confirmé par la suite :

L’équipe américaine de préparation aux urgences informatiques (US-CERT) a qualifié l’exploitation de généralisée et a insisté sur le fait que toutes les entreprises, quel que soit leur secteur d’activité , devaient suivre des conseils pour atténuer les effets de l’exploitation.

 

Parmi les entreprises compromises figurent des administrations locales et un large éventail de PME

Selon John Hammond, chercheur principal chez Huntress, les victimes compromises qu’ils ont identifiées comprennent de petits hôtels, un fabricant de crèmes glacées, un fabricant d’appareils électroménagers, plusieurs communautés de personnes âgées et d’autres entreprises “moins que sexy” du marché intermédiaire. Huntress a également observé de nombreuses victimes du gouvernement de la ville et du comté, des fournisseurs de soins de santé, des banques/institutions financières et plusieurs fournisseurs d’électricité résidentiels.

Sur les quelque 2 000 serveurs Exchange examinés, près de 200 ont été compromis par des charges utiles de type web shell.

De nombreux groupes d’acteurs de la menace exploitent activement les vulnérabilités

Alors que Microsoft a attribué la campagne qu’elle a observée avec une grande confiance à l’acteur de menace HAFNIUM, basé en Chine, ESET a rapporté avoir vu d’autres groupes se mêler à l’affaire.

 

 

Mise à jour : ESET a publié une nouvelle étude indiquant qu’ au moins 10 groupes APT exploitent activement ces vulnérabilités.

Les premières attaques ont été identifiées le 6 janvier 2021

Brian Krebs a établi une chronologie de haut niveau qui indique que Microsoft a été informée de l’une des vulnérabilités le 5 janvier. Un jour plus tard, la société de sécurité Volexity a identifié des attaques dans la nature.

  • 5 janvier : DEVCOR informe Microsoft de ses conclusions.
  • 6 janvier : Volexity repère des attaques utilisant des vulnérabilités inconnues dans Exchange.
  • 8 janvier : DEVCOR signale que Microsoft a reproduit les problèmes et vérifié ses conclusions.
  • 11 janvier : DEVCOR s’empare de proxylogon.com, un domaine désormais utilisé pour expliquer son processus de découverte des vulnérabilités.
  • 27 janvier : Dubex alerte Microsoft au sujet d’attaques sur une nouvelle faille d’Exchange.
  • 29 janvier : Trend Micro publie un billet de blog sur les shells web “Chopper” diffusés via des failles d’Exchange.
  • 2 février : Volexity avertit Microsoft d’attaques actives sur des vulnérabilités Exchange précédemment inconnues.
  • 8 février : Microsoft indique à Dubex qu’elle a “escaladé” son rapport en interne.
  • 18 février : Microsoft confirme à DEVCOR la date du 9 mars (demain) pour la publication des mises à jour de sécurité pour les failles d’Exchange. Il s’agit du deuxième mardi du mois. le “Patch Tuesday“, lorsque Microsoft publie des mises à jour de sécurité mensuelles (et oui, cela signifie qu’il faut revenir ici demain pour le toujours captivant PatchTuesday roundup).
  • 26-27 février : L’exploitation ciblée se transforme progressivement en un balayage de masse global ; les attaquants commencent à remonter rapidement les serveurs vulnérables.
  • 2 mars : Une semaine plus tôt que prévu, Microsoft publie des mises à jour pour combler 4 failles de type “zero-day”.
  • 3 mars : Des dizaines de milliers de serveurs Exchange ont été compromis dans le monde entier, et des milliers d’autres serveurs sont fraîchement piratés chaque heure.
  • 5 mars : KrebsOnSecurity annonce qu’au moins 30 000 entreprises aux États-Unis – et des centaines de milliers dans le monde – ont installé des portes dérobées.
  • 5 mars : Wired.com confirme le nombre de victimes annoncé. La Maison Blanche exprime son inquiétude quant à l’ampleur de l’attaque. L‘ancien responsable de la CISA Chris Krebs tweets le nombre réel de victimes est “très inférieur” à ce qui a été rapporté publiquement.
  • 6 mars : CISA déclare à avoir connaissance d’une “exploitation nationale et internationale généralisée des failles de Microsoft Exchange Server”
  • Du 7 mars à aujourd’hui : Les experts en sécurité poursuivent leurs efforts pour informer les victimes, coordonner les mesures correctives et rester vigilants quant à la “phase 2” de cette attaque (exploitation plus poussée des serveurs déjà compromis).

Chronologie créée par Brian Krebs

 

Mise à jour : De nouvelles recherches indiquent que l’exploitation pourrait s’étendre jusqu’en novembre 2020.

mise à jour du calendrier d'exploitation des échanges

Source : Examen de l’exploitation des échanges et des leçons à en tirer pour les défenseurs par Joe Slowik

 

Comment patcher

Options de mise à jour de Microsoft Exchange

Graphique de Microsoft illustrant les trois voies d’application des mises à jour d’Exchange

 

Des mises à jour de sécurité corrigeant ces vulnérabilités sont disponibles pour les versions spécifiques suivantes d’Exchange :

Remarque : Si vous les installez manuellement, vous devez le faire en tant qu’administrateur. Sinon, il s’agit d’un problème connu. Comme le souligne Kevin Beaumont, chercheur en sécurité chez Microsoft, il y a eu une certaine confusion quant à la nécessité d’avoir des serveurs exécutant l’une des deux dernières mises à jour cumulatives (CU).

Microsoft apporte ici plus de clarté :

Ces correctifs ne peuvent être installés que sur les serveurs qui utilisent les versions spécifiques énumérées précédemment, qui sont considérées comme étant à jour. Si vos serveurs utilisent une mise à jour cumulative ou un rollup Exchange Server plus ancien, vous devrez installer une RU/CU actuellement prise en charge avant de pouvoir installer les mises à jour de sécurité.

Besoin d’aide pour trouver la bonne CU à installer ?

Michel de Rooij est un héros et possède des liens de téléchargement pour les mises à jour cumulatives répertoriées par . Les versions d’échange comprennent également les numéros de construction et les dates de publication.

Mise à jour : Vous utilisez une CU qui n’est plus prise en charge et vous ne pouvez pas obtenir les dernières mises à jour ?

Microsoft a commencé à fournir des mises à jour de sécurité (SU) qui peuvent être appliquées à certains anciens CU non pris en charge. Ces mises à jour ne contiennent que des correctifs pour les CVE zero-day et ne sont disponibles que par l’intermédiaire du centre de téléchargement de Microsoft (et non de Microsoft Update). Vous trouverez plus de détails et les instructions d’installation ici.

Remarque : Microsoft insiste sur le fait que ces SU sont, , “uniquement destinées à servir de mesure temporaire pour vous aider à protéger les machines vulnérables dès à présent”. Vous devez toujours mettre à jour vers le dernier CU pris en charge, puis appliquer les SU applicables”

** Si vous ne pouvez pas appliquer de correctif immédiatement, faites-le à titre de mesure de mitigation temporaire

Pour les entreprises qui ne sont pas en mesure d’appliquer les correctifs, Microsoft a fourni la recommandation suivante en guise de mitigation :

Mettre en œuvre une règle de réécriture IIS et désactiver les services de messagerie unifiée (UM), Exchange Control Panel (ECP) VDir et Offline Address Book (OAB) VDir

  • Ces mesures de mitigation ont un impact connu sur la fonctionnalité décrite ci-dessous en détail.
  • Ces mesures de mitigation sont efficaces contre les attaques que nous avons observées jusqu’à présent dans la nature, mais elles ne garantissent pas une atténuation complète de toutes les possibilités d’exploitation de ces vulnérabilités.
  • Cela ne permettra pas d’expulser un adversaire qui a déjà compromis un serveur.
  • Cette solution ne doit être utilisée que temporairement, jusqu’à ce que les serveurs Exchange puissent être entièrement corrigés.

Détails et scripts PowerShell fournis par Microsoft ici.

** Remarque : Ni les correctifs ni ces mesures de mitigation ne permettront de résoudre les problèmes de compromission **

Comme le souligne Microsoft, il ne s’agit pas d’une mesure corrective si vos serveurs Exchange ont déjà été compromis. Pour vous aider à le déterminer, voir ci-dessous.

** Mise à jour : Microsoft lance un “outil de mitigation en un clic” conçu pour les entreprises qui ne disposent pas d’équipes informatiques ou de sécurité internes

Les détails de l’outil peuvent être consultés via Microsoft ici.

Identifier les serveurs vulnérables

En raison du volume d’analyses et d’exploitations actives, ainsi que du risque encouru, Huntress et d’autres fournisseurs de services de sécurité conseillent de faire confiance mais de vérifier. Les correctifs doivent être validés et les MSP doivent analyser activement les réseaux de leurs clients pour s’assurer qu’il n’y a pas de serveur surprise qui a été oublié. Il suffit d’un seul.

Kevin Beaumont a développé un script Nmap simple que vous pouvez utiliser ici.

 

 

Remarque : Si vous avez utilisé le script ci-dessus pour analyser des environnements avec Exchange 2013 avant le 7 mars, vous devriez analyser à nouveau. 

Les chercheurs de Rapid7 ont identifié une faille dans le script qui l’amenait à signaler des faux négatifs pour les serveurs Exchange 2013, en particulier.

Le script a depuis été mis à jour et le problème résolu.

Si vous êtes un client payant de Shodan Monitor, vous pouvez même recevoir automatiquement une notification si un serveur vulnérable est détecté.

 

Identifier et enquêter sur les compromissions

Mise à jour : Microsoft a mis à jour son outil Microsoft Support Emergency Response Tool (MSERT) pour détecter et supprimer les logiciels malveillants associés à la compromission.

C’est une excellente nouvelle, car cela permet de protéger les entreprises dont les serveurs ne sont pas équipés de Defender for Endpoint.

Microsoft a également mis en évidence diverses possibilités de détection et a créé un script que vous pouvez utiliser pour analyser les fichiers journaux d’Exchange à cette fin.

Vous pouvez également trouver des listes d’IoC ici :

En plus de fournir des IoC, FireEye recommande également de vérifier les éléments suivants pour détecter d’éventuelles preuves de compromission :

  • Processus enfants de C: WindowsSystem32inetsrvw3wp.exe sur les serveurs Exchange, en particulier cmd.exe.
  • Fichiers écrits sur le système par w3wp.exe ou UMWorkerProcess.exe.
  • Fichiers ASPX appartenant à l’utilisateur SYSTEM 
  • Nouveaux fichiers ASPX compilés de manière inattendue dans le répertoire Temporary ASP.NET Files 
  • Requêtes de reconnaissance et de test de vulnérabilité adressées aux ressources suivantes à partir d’une adresse IP externe :
    • /rpc/ directory
    • /ecp/DDI/DDIService.svc/SetObject
    • Ressources inexistantes
    • Avec des User-Agents HTTP (ou agent-utilisateur) suspects ou usurpés
  • Requêtes Exchange PowerShell SnapIn inattendues ou suspectes pour exporter des boîte e-mail

** Si vous soupçonnez qu’un serveur a été compromis **

  • Lancez votre plan de réponse aux incidents / contactez un fournisseur de réponse aux incidents (n’hésitez pas à demander l’aide d’experts si vous n’avez pas d’expérience en interne en matière de réponse aux incidents)
  • Isoler le serveur
  • FireEye recommande de conserver les artefacts suivants en vue d’une analyse médico-légale
    • Au moins 14 jours de journaux web HTTP provenant des répertoires inetpubLogsLogFiles (y compris les journaux de tous les sous-répertoires)
    • Le contenu du serveur Web Exchange (qui se trouve également dans le dossier inetpub )
    • Au moins 14 jours de journaux du panneau de contrôle Exchange (ECP), situés dans Program FilesMicrosoftExchange Serverv15LoggingECPServer
    • Journaux d’événements de Microsoft Windows
  • Rétablir le système d’échange avant le premier incident connu(les rapports actuels indiquent le 5 janvier)
  • Application de correctifs ou de mesures de mitigation provisoires
  • Procéder à un audit complet pour vérifier les éléments suivants :
    • Nouveaux utilisateurs et utilisateurs privilégiés (utilisez votre RMM et PowerShell)
    • Dates de changement de mot de passe
    • Redirection des boîtes e-mail
    • Transfert/redirection dans les dossiers de la boîte de réception
  • Modifier les mots de passe du domaine
  • Rester vigilant et se tenir au courant des nouvelles menaces

 

Vidéo : Soyez rapidement à la page avec John Hammond de Huntress

J’ai eu l’occasion de m’entretenir avec John au sujet des recherches menées par son équipe, de découvrir ce qui l’a surpris et d’obtenir ses recommandations sur la manière dont les fournisseurs de services de gestion devraient réagir.

Transcription

Jonathan: Bonjour à tous. J’ai avec moi John Hammond de Huntress. Et bien sûr, le sujet dont nous parlons est Microsoft Exchange et les vulnérabilités de type “zero day” qui sont activement exploitées. La semaine a été mouvementée. John, tu es sous l’emprise de l’adrénaline à ce stade. Vous êtes debout depuis des jours. Vous avez lancé un fil de discussion sur Reddit et vous vous en occupez depuis le début, en l’actualisant constamment avec les éléments que vous avez trouvés. Comment allez-vous ? Comment vous vous en sortez ?

John : Merci Jonathan. Je m’en sors bien. Nous sommes en quelque sorte à bout de souffle. Je plaisantais avec vous tout à l’heure. J’ai ma boisson énergétique ici. Je ne fais que me tenir au courant. Mais nous restons occupés. Nous essayons de mettre à jour les indicateurs de compromis. Nous essayons de lancer un webinaire qui sera diffusé en direct cet après-midi à 13 heures (heure de l’Est). Nous essayons donc d’éduquer la communauté et de la sensibiliser.

Jonathan: Oui, c’est vrai. Absolument. Je vais inclure un lien vers ce fil de discussion Reddit parce que vous avez fait un travail remarquable en incluant ce que vous avez dit des IOC et aussi des mises à jour de ce que vous avez trouvé de votre côté et vous avez vraiment appelé des partenaires à 2 heures du matin pour les aider à comprendre ces choses et nous avons vu beaucoup de questions circuler et à ce stade, je pense qu’il est sûr de dire que beaucoup de gens ont pris des mesures initiales. Il existe des outils que les gens ont partagés autour de l’analyse pour découvrir les serveurs vulnérables. Microsoft a mis en place des correctifs, mais de nombreuses questions restent en suspens. Bon, si j’ai trouvé les IOC, que dois-je faire maintenant ? Avez-vous des suggestions à faire sur ce que vous avez vu tout d’abord avec ces IOC, et ensuite sur les mesures de mitigation ?

John : Oui, c’est vrai. L’évidence immédiate est donc le patch. Une fois que vous avez fait cela, si vous pouviez valider votre patch, ce serait l’étape suivante. Kevin Beaumont a mis au point un excellent moteur de script Nmap, un utilitaire que vous pouvez utiliser avec Nmap pour valider en externe et s’assurer que vous n’êtes plus vulnérable et, après cela, effectuer votre réponse de restauration typique nécessaire. Restaurez votre serveur Exchange si vous le pouvez, avant le premier incident connu. Examinez votre domaine. Utilisateurs et ordinateurs, assurez-vous qu’il n’y a pas de changements ou de modifications, de nouveaux administrateurs dans les groupes Exchange. C’est essentiel. Et changez tous les mots de passe de vos domaines. Nous disons cela tout le temps, mais il faut le faire. Rincer et répéter, débusquer les choses, puis surveiller ces IOC, se tenir au courant des informations sur les menaces. Et si vous voyez quelque chose de nouveau, si vous voyez, oh, j’ai un webshell différent qui utilise un argument différent où je vois une adresse IP différente communiquée. Oui, nous sommes conscients que ce n’est pas bien, mais s’il vous plaît, dites-le à la communauté. Dites-le au reste d’entre nous pour que nous puissions continuer la chasse, car c’est notre raison d’être.

Jonathan: Vous avez beaucoup contribué à la communauté en prenant l’initiative et en partageant beaucoup d’informations. Y a-t-il quelque chose de nouveau à cet égard en termes de CIO ou de nouvelles activités maintenant que le chat est sorti du sac ?

John : Absolument. Nous avons donc lutté contre cela autant que nous le pouvions, n’est-ce pas ? Lorsque nous partageons cette information, il est agréable et merveilleux de voir que d’autres personnes font confiance à Huntress. Ainsi, de nouveaux partenaires et de nouvelles personnes apprennent à connaître notre tableau de bord. Notre inventaire de serveurs Exchange augmente. Au cours de la journée écoulée, nous avons constaté l’ajout d’un millier de nouveaux serveurs Exchange, ce qui porte notre nombre à environ 3 000, et le nombre de compromissions augmente également. Aujourd’hui, nous en sommes à environ 300 et nous nous demandons quelles sont les versions existantes Combien ont apporté des correctifs ? Je pense que nous en avons environ 900 sur un total de 3 000, mais il est incroyable de voir les statistiques. Les données sont incroyables, mais elles montrent que cette menace existe toujours. Les hôtes infectés le sont toujours. Les attaquants scannent l’Internet et cela n’est pas encore terminé.

John : À cet égard, revenons rapidement à l’annonce de Microsoft. Ils soulignent que c’était du moins le cas lorsqu’ils ont annoncé une exploitation ciblée limitée. Ils voyaient et, bien sûr, maintenant, vos résultats indiquent que c’est peut-être un peu plus large. Je veux dire que vous voyez une variété de victimes ici, il semble qu’il s’agisse d’une sorte de discrimination. Peut-être pas tout de suite, mais au moins à ce stade.

John : Je suis plutôt d’accord. À vrai dire, cette mention de Microsoft signifie qu’il s’agit d’attaques limitées et ciblées. En vérité, nous ne sommes pas d’accord. Nous observons ce phénomène à une échelle un peu plus large, dans toute la gamme, n’est-ce pas ? Il s’agit de tous les secteurs : les marchands de glaces, les petits hôtels, le magasin au coin de la rue, les administrations, les entreprises municipales et régionales, les institutions financières et bancaires, les prestataires de soins de santé et même les fournisseurs d’électricité. D’après ce que nous avons vu, ce phénomène s’est répandu partout. Et cela a causé une tonne de douleur évidemment avec les clients et ensuite avec les MSP. Je veux dire par là que la semaine a été frénétique pour beaucoup de gens, même pour les MSP qui ont migré la majorité de leurs clients et qui ont encore une poignée de serveurs.

Jonathan: Une autre question se pose : l’activité post-exploitation. Que voulaient-ils faire ? De nombreuses questions se posent à ce sujet, car des personnes ont trouvé des webshells. Y a-t-il d’autres activités ? Nous avons vu Microsoft faire référence à d’autres outils d’attaque, dont Procdump, et quelques cadres d’exploitation ont été abandonnés dans certains cas. Avez-vous vu ces choses et avez-vous d’autres indications de l’activité future que vous pouvez partager ?

John : Nous n’avons pas été en mesure de nous pencher sur l’exploitation du poste ou sur ce que les attaquants ont fait par la suite. Nous nous concentrons et nous zoomons sur le fait que c’est mauvais. Nous savons que c’est mauvais. Nous devons le faire sortir de là, mais aussi de l’autre côté des renseignements sur les menaces au sein de la communauté. Nous voyons ces instances Procdump ou il essaiera de récupérer des informations d’identification ou des hachages dans la mémoire. Nous voyons l’utilité de net.exe, l’outil de ligne de commande de Windows, un binaire vivant pour ajouter et supprimer des administrateurs, ou des outils Powersploit ou Powercat pour obtenir des connexions dans les deux sens. Nous observons des shells inversés par le biais de PowerShell. Il y a certainement eu plus que cela, mais nous ne savons pas exactement ce qu’il en est. Quelle est la prochaine étape ? Ils ont le contrôle du commandement. Ils ont un accès à distance RCE avec ce webshell. Cela signifie-t-il qu’il y aura des ransomwares ? Cela signifie-t-il l’exfiltration de données ? Cela signifie-t-il l’extraction de crypto-monnaies ? Nous ne sommes pas encore tout à fait sûrs, mais nous continuons à nous battre.

Jonathan: John, merci beaucoup de nous avoir rejoints. Vous allez passer en revue une grande partie de ce que vous avez trouvé et de manière beaucoup plus détaillée aujourd’hui à 13h00 (heure française) lors de votre webinaire. Nous mettrons en place un lien pour que les gens puissent l’enregistrer. Merci beaucoup d’avoir pris le temps et merci beaucoup à vous et à tout le monde chez Huntress pour ce que vous faites. Nous l’apprécions énormément.

John : Merci beaucoup Jonathan.

Pour aller plus loin

Pour les MSP, choisir le bon RMM est essentiel à la réussite de leur entreprise. La promesse principale d’un RMM est d’offrir l’automatisation, l’efficacité et l’évolutivité afin que l’entreprise MSP puisse croître de manière rentable. NinjaOne a été classé n°1 des RMM pendant plus de trois années consécutives en raison de sa capacité à fournir une plateforme rapide, facile à utiliser et performante pour les entreprises MSP de toutes tailles.
Pour en savoir plus sur NinjaOne, participez à une visite guidée en direct ou commencez votre essai gratuit de la plateforme NinjaOne.
Essai Gratuit
  • Categories RMM

Vous pourriez aussi aimer

Complete Guide: How to Install a CAB File in Windows blog banner image

Guide complet : comment installer un fichier CAB sous Windows

rMM

MSP : Utiliser le RMM pour acquérir un avantage concurrentiel

Comment désactiver les clés USB sur Windows 10 et 11

Comment désactiver les clés USB sur Windows 11 et Windows 10

What Is Full Stack Development blog image

Acquérir la prévisibilité de la surveillance et gestion à distance (RMM)

Un groupe de personnes résolvant différents défis opérationnels informatiques

6 défis opérationnels informatiques courants et leurs solutions

comment redémarrer un ordinateur distant avec windows

Comment redémarrer un ordinateur distant avec Windows

Prêt à simplifier les aspects les plus complexes de l'informatique et de la sécurité ?
Démarrer un essai gratuit
Demandez une démo
×

Voir NinjaOne en action !

En soumettant ce formulaire, j'accepte la politique de confidentialité de NinjaOne.

Termes et conditions NinjaOne

En cliquant sur le bouton “J’accepte” ci-dessous, vous indiquez que vous acceptez les termes juridiques suivants ainsi que nos conditions d’utilisation:

  • Droits de propriété: NinjaOne possède et continuera de posséder tous les droits, titres et intérêts relatifs au script (y compris les droits d’auteur). NinjaOne vous accorde une licence limitée pour l’utilisation du script conformément à ces conditions légales.
  • Limitation de l’utilisation: Les scripts ne peuvent être utilisés qu’à des fins personnelles ou professionnelles internes légitimes et ne peuvent être partagés avec d’autres entités.
  • Interdiction de publication: Vous n’êtes en aucun cas autorisé à publier le script dans une bibliothèque de scripts appartenant à, ou sous le contrôle d’un autre fournisseur de logiciels.
  • Clause de non-responsabilité: Le texte est fourni “tel quel” et “tel que disponible”, sans garantie d’aucune sorte. NinjaOne ne promet ni ne garantit que le script sera exempt de défauts ou qu’il répondra à vos besoins ou attentes particulières.
  • Acceptation des risques: L’utilisation du script est sous votre propre responsabilité. Vous reconnaissez qu’il existe certains risques inhérents à l’utilisation du script, et vous comprenez et assumez chacun de ces risques.
  • Renonciation et exonération de responsabilité: Vous ne tiendrez pas NinjaOne pour responsable des conséquences négatives ou involontaires résultant de votre utilisation du script, et vous renoncez à tout droit ou recours légal ou équitable que vous pourriez avoir contre NinjaOne en rapport avec votre utilisation du script.
  • EULA: Si vous êtes un client de NinjaOne, votre utilisation du script est soumise au contrat de licence d’utilisateur final qui vous est applicable (End User License Agreement (EULA)).
J'accepte