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
- Informations sur les menaces fournies par les entreprises de sécurité
- Quelles sont les vulnérabilités ?
- Quelles sont les versions d’Exchange concernées ?
- Quelle est l’ampleur des attaques ?
- Comment appliquer un correctif
- Identifier les serveurs vulnérables
- Comment identifier et enquêter sur les compromissions
- Vidéo : Soyez rapidement à la page avec John Hammond de Huntress
Vue d’ensemble
Vous trouverez ci-dessous des résumés et des fils à suivre pour vous mettre au diapason :
- HAFNIUM cible les serveurs Exchange avec des exploits zero-day (Microsoft)
- Comprend les détails de l’attaque, des informations spécifiques sur les CVE, des recommandations sur les mesures de mitigation et une liste d’indicateurs de compromission (IoC)
- Alerte CISA : Atténuer les vulnérabilités du serveur Microsoft Exchange
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.
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.
- 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 :
Confirmation du rapport de @briankrebs selon lequel le groupe chinois Hafnium a exploité les failles de Microsoft Exchange pour pirater des dizaines de milliers de réseaux. Un chercheur parle de 30 000 serveurs rien qu’aux États-Unis et de centaines de milliers dans le monde. “La Chine vient de s’emparer du monde” https://t.co/C1FkmBVLNI
– Andy Greenberg (@a_greenberg) 6 mars 2021
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.
La CISA demande instamment à TOUTES les entreprises de TOUS les secteurs de suivre des conseils pour remédier à l’exploitation nationale et internationale généralisée des vulnérabilités du produit Microsoft Exchange Server ; voir la page Web récemment publiée par la CISA pour plus de détails. https://t.co/VwYqAKKUt6. #Cyber #InfoSec
– US-CERT (@USCERT_gov) 9 mars 2021
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.
La télémétrie d’ESET montre que (au moins) CVE-2021-26855 est activement exploité dans la nature par plusieurs groupes de cyber-espionnage. Parmi eux, nous avons identifié #LuckyMouse, #Tick, #Calypso et quelques autres groupes non encore classés. 2/5
– ESET research (@ESETresearch) 2 mars 2021
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.
Source : Examen de l’exploitation des échanges et des leçons à en tirer pour les défenseurs par Joe Slowik
Comment patcher
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 :
- Exchange Server 2010 (la mise à jour nécessite une SP 3 ou une RU SP 3 – il s’agit d’une mise à jour Defense in Depth)
- Exchange Server 2013 (la mise à jour nécessite l’UC 23)
- Exchange Server 2016 (la mise à jour nécessite l’UC 19 ou l’UC 18)
- Exchange Server 2019 (la mise à jour nécessite l’UC 8 ou l’UC 7)
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).
Beaucoup de confusion à ce sujet – la vulnérabilité d’Exchange s’applique à toutes les versions.
Vous n’êtes protégé que si vous utilisez la dernière mise à jour cumulative (CU) ET que vous installez la nouvelle mise à jour de sécurité (SU). https://t. co/i9QPBJaOZA
– Kevin Beaumont (@GossiTheDog) 3 mars 2021
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
Microsoft a mis en place un nouvel outil de mitigation en un clic pour aider les clients qui ne disposent pas d’équipes informatiques ou de sécurité dédiées à l’application des mises à jour de sécurité Exchange
1⃣ Applique l’atténuation CVE-2021-26855
2⃣ Exécute une analyse MSERT
3⃣ Inverser les modifications apportées par les menaces identifiées pic.twitter.com/UEhNQC8NEM
– Tanmay Ganacharya (@tanmayg) 15 mars 2021
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.
J’ai créé un script nmap rapide et pratique qui peut être utilisé pour trouver des serveurs potentiellement vulnérables dans vos environnements.
J’encourage vivement les entreprises à évaluer leur empreinte Exchange sur site (on-premise), en particulier si elles sont tournées vers l’internet. https://t.co/8MCOrhIjQ5
– Kevin Beaumont (@GossiTheDog) 2 mars 2021
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é.
Nous avons ajouté la détection des récentes vulnérabilités de Microsoft Exchange. Si vous avez configuré Shodan Monitor (https://t.co/pVAnB0gecF), vous recevrez automatiquement une notification . pic.twitter.com/Sbi2VVAFKh
– Shodan (@shodanhq) 4 mars 2021
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.
Microsoft Defender a inclus des mises à jour de renseignements de sécurité dans la dernière version de l’outil Microsoft Support Emergency Response Tool (MSERT) afin de détecter et de remédier aux dernières menaces connues pour abuser des vulnérabilités d’Exchange Server divulguées le 2 mars 2021.
– Tanmay Ganacharya (@tanmayg) 6 mars 2021
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 :
- Hachures et chemins d’accès de Microsoft
- IoCs de Volexity
- Inventaire des shells web ASPX de China Chopper de Huntress
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.
