Les adresses e-mails de plusieurs cadres de Microsoft ont été piratées par le groupe de pirates Midnight Blizzard sponsorisé par l'État russe. Que s'est-il passé ? Faisons le point.
Vendredi 19 janvier 2024, Microsoft a mis en ligne un nouveau rapport pour annoncer que le groupe Midnight Blizzard, également connu sous le nom de Nobelium et Cozy Bear, était parvenu à accéder aux boites aux lettres de messagerie de plusieurs cadres. Ce groupe de pirates informatiques est sponsorisé par l'État russe, notamment dans le cadre des actions du Service de renseignement extérieur de la Russie (SVR) et il a été associé à plusieurs cyberattaques ces dernières années (l'attaque liée à SolarWinds est probablement le meilleur exemple).
Microsoft a détecté l'attaque le 12 janvier 2024, et pourtant, cela faisait plusieurs mois que les pirates étaient sur le coup. En effet, à la fin du mois de novembre 2023, les cybercriminels sont parvenus à compromettre un compte permettant d'accéder à un tenant de test utilisé par Microsoft. Pour cela, les pirates ont utilisé une méthode bien connue : le password spraying. De ce fait, la firme de Redmond insiste sur le fait que les cybercriminels n'ont pas exploité de vulnérabilités dans le cadre de cette attaque. À l'inverse, ceci montre que ce compte ne respectait pas les bonnes pratiques en matière de sécurité : pourquoi l'authentification multifacteurs n'était pas activée sur ce compte ? Bonne question.
Ensuite, grâce à cet accès, les pirates ont pu accéder aux comptes de messagerie de plusieurs employés de Microsoft, correspondants à "des membres de notre équipe de direction et des employés de nos fonctions de cybersécurité, juridiques et autres", précise l'entreprise américaine. Le document précise également que les cybercriminels ont profité de ces accès pour exfiltrer certains e-mails et des pièces jointes. Les employés concernés par cet incident de sécurité vont être notifiés.
Microsoft continue de mener son enquête, mais pour le moment, "rien ne prouve que le cybercriminel ait eu accès aux environnements des clients, aux systèmes de production, au code source ou aux systèmes d'intelligence artificielle." - Affaire à suivre...
Microsoft a annoncé officiellement que les derniers Mac, équipés d'une puce Apple M3, peuvent faire tourner Windows 11 en s'appuyant sur de la virtualisation. Voici ce qu'il faut savoir.
Si vous souhaitez utiliser Windows 11 sur un Mac, vous devez passer par de la virtualisation et la prise en charge n'est pas aussi évidente qu'avec les Mac avec un processeur Intel, car les puces fabriquées par Apple s'appuient sur une architecture ARM. La solution consiste à s'appuyer sur un hyperviseur, en l'occurrence via une application bien connue : Parallels Desktop.
À ce sujet, Microsoft a mis en ligne un nouveau document de support au sein duquel nous pouvons lire : "Parallels Desktop version 18 et 19 sont des solutions autorisées pour exécuter les versions Arm de Windows 11 Pro et Windows 11 Enterprise dans un environnement virtuel sur sa plateforme sur les ordinateurs Apple M1, M2 et M3."
Source : parallels.com
Ainsi, Windows 11 s'exécute dans une machine virtuelle, ce qui reste différent et plus contraignant que l'utilitaire Boot Camp d'Apple. En effet, sur les Mac équipés d'un processeur Intel, il est possible d'utiliser Boot Camp pour installer Windows en parallèle de macOS. La prise en charge est limitée puisque certaines fonctionnalités, notamment celles basées sur la virtualisation imbriquée (nested virtualization), ne sont pas supportées (Hyper-V, Windows Subsystem for Linux, Windows Subsystem for Android et Windows Sandbox).
Il est important de préciser qu'il est déjà possible depuis un bon moment d'installer Windows 11 sur Mac grâce à Parallels Desktop et les utilisateurs n'ont pas attendu le feu vert de Microsoft pour le faire. Toutefois, le fait que ce soit annoncé officiellement assure une prise en charge de la part de Microsoft, ce qui est intéressant.
Par ailleurs, Microsoft explique que vous pouvez utiliser Windows 11 sur Mac grâce à son service de Cloud PC baptisé "Windows 365". Dans ce cas, il s'agit d'un ordinateur virtuel hébergé dans le Cloud Azure de Microsoft et qui est dédié à l'utilisateur, en l'échange du paiement d'un abonnement mensuel.
Dans ce tutoriel, nous allons apprendre à gérer le compte administrateur local des appareils Windows avec une stratégie Microsoft Intune. Nous allons voir comment forcer l'activation du compte Administrateur (Builtin), mais aussi comment renommer le compte Administrateur.
Grâce à cette stratégie, tous les appareils Windows dans le périmètre de la stratégie auront un compte administrateur local activé et qui aura le même nom. Nous allons cibler le compte Administrateur "Builtin", c'est-à-dire celui intégré et associé au SID 500 sur l'ensemble des installations de Windows. Ceci peut s'avérer utile pour uniformiser la configuration de vos machines, notamment si vous envisagez de déployer Windows LAPS dans un second temps.
Notre objectif va être d'activer et de renommer le compte "Administrateur" en "adm_itconnect" sur les appareils Windows 10 et Windows 11 de l'entreprise.
Cliquez sur "Appareils" dans le menu latéral, puis sur "Profils de configuration" afin de créer une nouvelle stratégie.
Un panneau latéral apparaît sur la droite, choisissez "Windows 10 et ultérieur" comme plateforme puis choisissez "Catalogue des paramètres".
Commencez par donner un nom à ce profil de configuration, par exemple "Activer et renommer le compte Administrateur local".
Passez à la seconde étape et ajoutez un paramètre.
Un panneau latéral apparaît sur la droite... Recherchez "Options de sécurité des stratégies locales" dans la liste. Cliquez dessus.
Ensuite, vous devez sélectionner deux paramètres :
Comptes Activer l'état du compte d'administrateur
Comptes Renommer le compte administrateur
Ceci va permettre de configurer les deux paramètres. Vous devez indiquer le nouveau nom que vous souhaitez attribuer au compte Administrateur, et activer le second paramètre pour forcer l'activation de ce compte sur les machines Windows.
Poursuivez jusqu'à l'étape "Affectations". Dans cet exemple, la stratégie sera affectée à tous les appareils, mais vous pouvez sélectionner un groupe.
Poursuivez jusqu'à la fin... Vérifiez la configuration et cliquez sur "Créer". Revenez en arrière si besoin.
La stratégie va être créée et les appareils concernés vont pouvoir appliquer la configuration.
III. Tester sur un appareil Windows
Sur un appareil Windows 11 où la stratégie s'est correctement appliquée, nous pouvons voir que le compte "Administrateur" a changé de nom ! Désormais, il s'appelle "adm_itconnect", conformément avec notre stratégie.
Nous pouvons également le vérifier avec PowerShell :
Get-LocalUser | Format-Table Name,Sid
La stratégie Intune fonctionne parfaitement !
IV. Conclusion
Grâce à cette stratégie très simple à mettre en place, vous pouvez gérer l'état du compte Administrateur local (nous pourrions également le désactiver !) et changer son nom !
Troy Hunt, le créateur du célèbre site "Have I Been Pwned", a ajouté à sa plateforme un nouveau fichier baptisé "Naz.API" comportant 100 millions de mots de passe et 71 millions d'adresses e-mails ! Ce fichier a été mis en ligne par un pirate informatique sur un forum spécialisé. Voici ce que l'on sait.
À la lecture de cette introduction, il y a deux questions que l'on peut se poser, et c'est tout à fait légitime, d'où proviennent ces données ? Suis-je concerné ? Tout d'abord, il faut savoir que cet énorme fichier a été constitué à partir de données volées par les malwares de type "infostealer" (voleur d'informations) mais aussi à partir de listes destinées à effectuer du credential stuffing. En fait, il s'agit de collections d'identifiants et de mots de passe ayant été récupérés via une précédente fuite de données (sur un service en ligne, par exemple). Une partie des données contenues dans la base Naz.API serait issue du site illicit[.]services, qui n'est plus en ligne.
Comme l'explique Troy Hunt dans un article, chaque ligne de la base Naz.API se compose de plusieurs informations : une URL de connexion, un identifiant et un mot de passe associé à cet identifiant. Voici à quoi ressemble cette base :
Source : troyhunt.com
Sur cette base, Troy Hunt s'est amusé à effectuer quelques vérifications, notamment pour vérifier la légitimité des données contenues dans ce fichier Naz.API. D'après lui, il s'agit de "données fiables" car les associations entre les services et les e-mails sont correctes : ce qui est déjà un bon point de départ, mais si le mot de passe, quant à lui, peut avoir changé.
Il est important de préciser que ce fichier contient des informations inédites : environ 35% des adresses e-mails sont répertoriées pour la première fois dans un fichier de ce type. Contrairement à d'autres bases similaires, celle-ci n'est pas une vulgaire compilation de précédentes fuites de données. À ce sujet, Troy Hunt précise : "Il ne s’agit pas là d’une liste de contenu recyclé avec un emballage inédit, mais d’un volume important de nouvelles données. "
Cette nouvelle fuite de données est l'occasion de rappeler l'importance d'utiliser un mot de passe unique par service tout en assurant la gestion des identifiants avec un gestionnaire de mots de passe, et en activant l'authentification multifacteurs à chaque fois que c'est possible.
Pour savoir si votre adresse e-mail est présente dans cette fuite de données, ou dans une autre base répertoriée sur le site Have I Been Pwned, rendez-vous justement sur ce site :
Sur ce même site, vous pouvez aussi utiliser l'outil Pwned Passwords, sur cette page, pour effectuer une vérification précise sur un mot de passe. Toutefois, ceci vous oblige à communiquer le mot de passe en question.
Dans ce tutoriel, nous allons partir à la découverte du protocole mDNS qui est pris en charge par Windows, Linux, et macOS afin d'effectuer de la résolution de noms dans certaines conditions ! Nous verrons également quels sont les risques associés au protocole mDNS et comment nous pouvons le désactiver !
Cet article fait suite à celui publié au sujet des protocoles LLMNR et NetBIOS (NBT-NS) que vous pouvez consulter en utilisant le lien suivant :
Au même titre que le protocole LLMNR, le protocole mDNS pour Multicast DNS (ou multicast Domain Name System) a pour objectif de permettre la résolution des noms de machines sur les réseaux locaux. Il fonctionne sur le même principe que le DNS, sans avoir besoin d'un serveur DNS pour fonctionner, c'est pour cette raison qu'il émet des paquets en multicast sur le réseau (pour sonder les machines connectées au réseau local).
Comme avec le protocole LLMNR, Windows va émettre une requête mDNS sur le réseau local à partir du moment où il ne parvient pas à résoudre un nom à partir de son fichier hosts, de son cache DNS et qu'il n'obtient pas de réponse de la part du serveur DNS déclaré dans l'interface réseau active. Ceci en fait un protocole relativement bavard puisqu'il est susceptible d'envoyer de nombreux paquets sur le réseau.
En principe, le protocole mDNS doit être implémenté de manière à fonctionner uniquement pour les noms en ".local", c'est pour cette raison que les requêtes émises via le protocole mDNS concerneront toujours "le nom à résoudre + l'extension .local". Enfin, sachez que le protocole mDNS est activé par défaut sur Windows (jusqu'à sur les dernières versions de Windows 10 et Windows 11) et sur certaines distributions Linux.
Remarque : le protocole mDNS s'appuie sur l'UDP et le port 5353, contrairement au DNS qui travaille sur le port 53.
III. Quels sont les risques associés au protocole mDNS ?
Avec le protocole mDNS, les risques sont les mêmes qu'avec le protocole LLMNR puisqu'il est vulnérable à plusieurs attaques, notamment celles de type poisoning et man-in-the-middle (MiTM).
Comme je l'avais expliqué dans mon précédent article, cela signifie qu'une machine émettrice d'une requête mDNS peut être empoisonnée par la machine contrôlée par un attaquant (notamment via l'outil Responder). Autrement dit, la machine de l'attaquant va répondre à la requête mDNS émise sur le réseau afin de retourner une fausse information. Dans ce cas, le client mDNS va tenter une authentification auprès du serveur contrôlé par l'attaquant, ce qui va permettre de récupérer des identifiants (hash Net-NTLM, identifiants HTTP, etc.).
Ainsi, nous pourrions effectuer la même attaque sur une machine à partir du moment où le protocole mDNS est activé. Avec l'outil Responder, que nous avons mis en pratique pour l'empoisonnement LLMNR, ceci est clairement visible :
[*] [MDNS] Poisoned answer sent to 192.168.14.11 for name srv-fichiers.local
[*] [MDNS] Poisoned answer sent to 192.168.14.11 for name srv-fichiers.local
Dans le même temps, à partir du PC de l'attaquant, si l'on effectue une capture du trafic avec Wireshark, nous pouvons voir arriver deux requêtes mDNS, une en IPv4 et une en IPv6. Nous pouvons voir également une troisième requête correspondante à la réponse à la requête mDNS, générée par l'outil Responder pour empoisonner le client Windows.
IV. Windows : comment désactiver le protocole mDNS par GPO ?
Pour désactiver le protocole mDNS sur les machines Windows d'un environnement Active Directory, nous allons créer une stratégie de groupe (GPO) qui va créer une valeur dans le Registre Windows des machines. Sur une machine locale, vous pouvez également créer manuellement cette valeur dans le Registre Windows.
Commencez par ouvrir la console de gestion des stratégies de groupe afin de créer une nouvelle GPO. Par exemple, la GPO "Sécurité - Désactiver mDNS". Éditez cette GPO et accédez à cet emplacement :
1 - Accédez à : Configuration ordinateur > Préférences > Paramètres Windows > Registre
2 - Effectuez un clic droit, puis sous "Nouveau" choisissez "Élément Registre".
Une fenêtre s'affiche à l'écran.
Nous allons devoir configurer la valeur de Registrer à déployer sur les machines Windows. Voici la configuration à effectuer :
Action : Mettre à jour (même si cette valeur n'existe pas par défaut)
Ruche : HKEY_LOCAL_MACHINE
Chemin d'accès de la clé : SYSTEM\CurrentControlSet\Services\Dnscache\Parameters
Nom de valeur : EnableMDNS
Type de valeur : REG_DWORD
Données de valeur : 0
Ce qui donne ceci :
La valeur "0" sert à désactiver le protocole mDNS sur Windows !
Voilà, la GPO est prête ! Il ne reste plus qu'à tester sur une machine après avoir effectué un "gpupdate /force" et un reboot sur une machine affectée par la stratégie de groupe.
V. Conclusion
Si vous désactivez les protocoles LLMNR, NBT-NS et mDNS sur les machines de votre infrastructure, vous ne devriez plus capturer de trames associées à ces différents protocoles à partir d'un outil tel que Wireshark ! En effet, si la résolution DNS échoue, elle échoue, point. En plus de réduire la surface d'attaque de vos machines, vous allez aussi générer moins de trafic réseau, car ces protocoles sont bavards !
Comme d'habitude, effectuez des tests avant de déployer massivement ce type de changements...
