À travers plusieurs guides, l'ANSSI s'attaque à un sujet très intéressant, mais pas évident : la remédiation après une cyberattaque. Pour le moment, il ne s'agit pas de la version définitive puisque l'agence française lance un appel à commentaires !
Lorsque l'on subit une attaque informatique, il y a forcément un avant et un après, et dans la phase de réponse à incident, il y a plusieurs activités dont la remédiation dans le but d'assainir et de reconstruire le ou les systèmes impactés par la cyberattaque. À cela s'ajoutent la gestion de crise et les différentes investigations, indispensables pour comprendre ce qu'il s'est réellement passé.
Le premier guide à lire s'intitule "Les clés de décision" et il donne quelques conseils pour bien gérer cette crise, ce moment où la tension est à son maximum, en prenant les bonnes décisions. Il s'agit d'un document plus synthétique. L'ANSSI aborde trois scénarios possibles comme plan de remédiation, notamment un premier scénario où l'on va chercher à restaurer le système le plus rapidement possible et un troisième scénario où l'on va investir dès la phase de remédiation pour sécuriser son système.
Pour aller plus loin et approfondir le sujet, l'ANSSI a mis en ligne un guide sur le pilotage de la phase de remédiation, qui aborde le sujet dans le détail en commençant par les grands principes de la remédiation en 3 grandes étapes selon le principe "E3R" :
Endiguement de l'attaquant
Éviction de l'intrus du cœur du SI
Éradication des emprises de l'adversaire
À cela s'ajoute un troisième guide dédié à l'Active Directory et la remédiation du tier-0. Lorsqu'il y a une compromission du tier-0, cela implique que l'attaquant a pris le contrôle du domaine Active Directory. Que faire dans ce cas ? C'est ce que détaille l'ANSSI dans ce guide dédié.
Ce travail de l'ANSSI devrait être apprécié par de nombreuses personnes, à commencer par les équipes de sécurité et les RSSI. Tous les guides sont accessibles à cette adresse. Sachez que vous disposez jusqu'au 22 juin 2023 pour effectuer des retours à l'ANSSI.
Dans ce tutoriel, nous allons apprendre à configurer une autorité de certification ADCS pour délivrer des certificats dans le but de sécuriser les connexions RDP sur les serveurs Windows Server. Ainsi, la connexion RDP vers un serveur intégré à l'Active Directory sera sécurisée avec le certificat et l'authentification Kerberos.
Cette configuration implique la création d'un modèle de certificat dans ADCS. Les serveurs autorisés pourront demander un certificat de ce type pour la sécurisation des connexions RDP. Pour gérer quels sont les serveurs qui ont accès ou non à ce modèle de certificat, un groupe de sécurité Active Directory sera utilisé. Toutefois, nous pourrions tout à fait l'ouvrir à tous les ordinateurs du domaine.
Pour cette démo, les serveurs suivants sont utilisés :
SRV-ADDS-01
Contrôleur de domaine
Windows Server 2022
SRV-ADCS
Autorité de certification (ADCS)
Windows Server 2022
SRV-APPS
Serveur applicatif (pour tester la connexion RDP avec certificat)
Windows Server 2022
Ce tutoriel n'aborde pas l'installation de l'autorité de certification Active Directory (ADCS). Si besoin, suivez cet article :
Tout d'abord, nous devons créer un modèle de certificat pour les connexions RDP. Ouvrez l'autorité de certification, effectuez un clic droit sur "Modèles de certificats" et cliquez sur "Gérer".
Ici, vous devez dupliquer le modèle de certificat nommé "Ordinateur" via un clic droit puis "Dupliquer le modèle".
Ce nouveau modèle doit être configuré. Dans l'onglet "Général", vous devez donner un nom complet pour ce modèle. En ce qui me concerne, ce sera "Accès RDP - Certificat". Vous pourrez constater que le nom du modèle reprend le nom complet, mais sans les espaces (ce sera important pour la suite). Cochez également l'option "Publier le certificat dans Active Directory".
Passez à l'onglet "Extensions" (1). Ici, vous devez sélectionner "Stratégies d'application" (2), cliquer sur "Modifier" (3) puis sur "Ajouter" (4) dans la nouvelle fenêtre qui apparaît.
La fenêtre "Ajouter une stratégie d'application" apparaît. Cliquez sur "Nouveau". Il est nécessaire de créer une nouvelle stratégie en indiquant l'identificateur d'objet "1.3.6.1.4.1.311.54.1.2" correspondant à "Remote Desktop Authentication". Un nom doit aussi être attribué à cette stratégie. Ce qui donne :
Validez. La stratégie "Certificat RDP" est visible. Vous devez sélectionner "Authentification du client" et "Authentification du serveur" pour les supprimer via le bouton prévu à cet effet. Cliquez sur "OK".
Seule notre stratégie est assignée à ce modèle.
Passez à l'onglet "Sécurité". Vous devez donner les autorisations "Inscrire" et "Inscription automatique" en plus de la lecture aux machines qui doivent pouvoir demander ce type de certificat. Dans cet exemple, j'utilise le groupe "GG-RDP-Cert" : seules les machines membres de ce groupe auront cette autorisation. Côté Active Directory, ce groupe contient notamment mon serveur "SRV-APPS". Cliquez sur "OK".
Le modèle est prêt. Il ne reste plus qu'à l'ajouter à la liste des certificats que notre CA est capable de délivrer. Effectuez un clic droit sur "Modèles de certificats", puis sous "Nouveau" choisissez "Modèle de certificat à délivrer". Le modèle "Accès RDP - Certificat" doit apparaître dans la liste comme ceci :
La configuration côté ADCS est terminée !
III. Créer la GPO pour demander les certificats RDP
Dès à présent, une stratégie de groupe doit être configurée pour indiquer aux serveurs quel est le nom du modèle de certificat à solliciter auprès de l'ADCS. Puis, on va aussi configurer le RDP pour qu'il utilise le certificat.
Créez une nouvelle stratégie de groupe et éditez-la. Par exemple, la GPO "Sécurité - Certificat RDP".
Parcourez les paramètres comme ceci :
Configuration ordinateur > Stratégies > Modèles d'administration > Composants Windows > Services Bureau à distance > Hôte de la session Bureau à distance > Sécurité
Ici, configurez un premier paramètre nommé "Modèle de certificat d'authentification serveur". Passez ce paramètre sur l'état "Activé" et indiquez le nom du modèle de certificat : pensez à bien mettre le nom du modèle de certificat (sans espace). Validez.
Ensuite, configurez aussi le paramètre "Nécessite l'utilisation d'une couche de sécurité spécifique pour les connexions distantes (RDP)". Vous devez l'activer et choisir "SSL" comme couche de sécurité, ce qui permettra d'utiliser TLS 1.0 (il n'y a pas d'autres versions disponibles). Validez.
La GPO est prête. Il ne reste plus qu'à l'associer à l'unité d'organisation qui contient les machines cibles.
IV. Tester la connexion RDP
Les serveurs ciblent doivent récupérer la stratégie de groupe puis effectuer une demande de certification auprès de notre CA. Pour le moment, le certificat n'est pas délivré sur le serveur SRV-APPS donc si l'on clique sur le cadenas dans la bandeau de la connexion RDP, on peut lire : "L'identité de l'ordinateur distant a été vérifiée en utilisant Kerberos".
Une fois que le certificat sera en place, il sera visible dans le magasin de certificats local du serveur, mais aussi dans la liste des certificats délivrés de l'autorité de certification. Sur l'image ci-dessous, on constate bien la présence d'un certificat pour "SRV-APPS".
En effectuant une nouvelle connexion RDP sur ce serveur, cette fois-ci, le certificat a joué en rôle dans la vérification de l'identité du serveur. On peut lire le message : "L'identité de l'ordinateur distant a été vérifiée en utilisant un certificat de serveur et Kerberos". La configuration fonctionne !
Il est à noter que si on établit une connexion sur ce même serveur, mais à partir d'une machine qui n'est pas dans le domaine Active Directory, l'avertissement de certificat est présent. Ceci s'explique par le fait que la machine n'approuve pas le certificat racine de notre autorité de certificat. C'est normal, car ce certificat est distribué automatiquement aux machines intégrées au domaine.
V. Conclusion
Nous venons de voir comment apporter une couche de sécurité supplémentaire aux connexions RDP à destination des serveurs Windows Server grâce à ce certificat !
Un nouveau rapport met en lumière les activités malveillantes sur Discord, notamment autour des abonnements Discord Nitro qui représente une véritable opportunité pour les cybercriminels.
Pour rappel, Discord est un service en ligne très populaire pour échanger par chat ou par audio et il existe de nombreuses communautés sur des thématiques diverses et variées. Même si à ses débuts il était utilisé surtout par les gamers, ce n'est plus du tout le cas depuis plusieurs années. D'ailleurs, il y a le serveur Discord de la communauté IT-Connect ! Discord compte plus de 300 millions d'utilisateurs actifs. Forcément, s'il y autant d'utilisateurs sur cette plateforme, cela va attirer les cybercriminels.
Justement, un chercheur en sécurité de chez CyberArk Labs a fait la découverte d'un nouveau malware nommé Vare qui présente la particularité d'être distribué par l'intermédiaire de Discord. Il est associé à un groupe de pirates nommé Kurdistan 4455 basé au sud de la Turquie.
Discord Nitro, l'élément déclencheur
D'après ce chercheur, c'est depuis qu'il y a l'offre payante Discord Nitro qu'il y a des malwares sur Discord. Pourquoi ? Et bien, parce qu'en échange d'un abonnement payé mensuellement, l'utilisateur accède à des fonctions supplémentaires comme le chargement de fichiers plus lourds ou une qualité plus élevée pour le streaming.
De ce fait, il y a des utilisateurs qui essaient d'obtenir des clés d'activation Discord Nitro de manière gratuite et qui se font piéger. Certains d'entre eux s'essaient aussi au brute force ou au social engineering pour mettre la main sur les avantages Discord Nitro gratuitement. C'est pour cette raison qu'avec un malware, les pirates peuvent piéger les utilisateurs et leur voler des informations, notamment les coordonnées de cartes bancaires dans le but d'acheter des clés Discord Nitro : "Ces clés peuvent être échangées pour obtenir Discord Nitro, et des acteurs malveillants les vendent à des fins lucratives.", précise l'étude CyberArk.
Le malware Vare
Dans le cas présent, le malware Vare utilisé par les pirates informatiques est codé en Python puis converti en exécutable avec pyInstaller. Il agit uniquement sur Discord, que ce soit pour stocker les données exfiltrées ou pour trouver de nouvelles cibles.
Une fois la machine infectée, le malware Vare va être capable de voler des informations notamment dans Discord : jetons d'authentification, informations de paiement, statut du Nitro, ainsi que le numéro de téléphone associé au compte. Cela ne s'arrête pas là, car il va aussi se servir dans les navigateurs pour voler les mots de passe enregistrés et récupérer des informations sur la machine en elle-même (CPU, RAM, clés WiFi enregistrées, etc.). Ces fonctions correspondent à celles que l'on retrouve dans le malware Empyrean.
Cette recherche est intéressante, car elle montre que ce n'est pas simplement une guerre entre les cybercriminels d'un côté et les utilisateurs de l'autre. En effet, ici le groupe de cybercriminels Kurdistan 4455 va chercher à piéger d'autres personnes malveillantes : ce qui prouve que personne n'est à l'abri et que ce n'est pas qu'une question de positionnement !
Le rapport complet de CyberArk est disponible à cette adresse.
Dans ce tutoriel, nous allons apprendre à configurer un serveur DHCP de façon à pouvoir faire du boot PXE à la fois en mode BIOS et en mode UEFI, sur le même réseau. Un serveur WDS sous Windows Server 2022 sera utilisé pour tester le bon fonctionnement.
Lorsque l'on effectue un boot PXE sur une machine en mode BIOS (ou Legacy), il faut configurer les options DHCP 66 et 67. Dans le même temps, quand on utilise le mode UEFI (avec ou sans Secure Boot), il faut configurer les options DHCP 60, 66 et 67, mais avec une valeur différente pour l'option 67 qui est commune aux deux modes.
Si l'on a besoin de déployer les deux types de machines et que l'on utilise le même réseau local pour le déploiement (ce qui est généralement le cas), on se retrouve dans l'obligation d'ajuster la configuration de l'étendue DHCP en fonction de la configuration de la machine à déployer (BIOS ou UEFI). Même si l'UEFI devient le mode par défaut et se généralise, la problématique existe toujours. Pour répondre à cette problématique et gérer les deux modes en même temps, nous allons pouvoir créer des stratégies DHCP. C'est ce que nous allons voir.
Mode
Option 60
Option 66
Option 67
BIOS
-
Adresse IP du WDS
boot\x64\wdsnbp.com
UEFI
PXEClient
Adresse IP du WDS
boot\x64\wdsmgfw.efi
En ce qui concerne l'environnement utilisé pour cette démo :
Un serveur virtuel WDS
Nom de machine : SRV-WDS
Adresse IP : 192.168.14.11
Intégré au domaine Active Directory (facultatif)
Un serveur virtuel contrôleur de domaine et DHCP
Nom de machine : SRV-ADDS-01
Adresse IP : 192.168.14.10
Nom de domaine : it-connect.local
Une machine virtuelle vierge pour tester le boot PXE
Si vous avez besoin d'aide pour mettre en place le serveur WDS, suivez la vidéo complète puisqu'elle intègre cette partie.
II. VMware Workstation : basculer du mode BIOS au mode UEFI
Le firmware d'une machine virtuelle VMware Workstation Pro peut être configuré en mode "BIOS ou "UEFI". Avec Windows 10, on peut utiliser l'un de ces deux modes, tandis qu'avec Windows 11, il faut utiliser impérativement le mode UEFI pour respecter le prérequis de la puce TPM (vTPM).
Pour basculer d'un mode à l'autre, voici la marche à suivre. Accédez aux paramètres de la machine virtuelle, cliquez sur l'onglet "Options", choisissez "Advanced" dans la liste et sur la droite ajustez le paramètre "Firmware type".
Si vous souhaitez vous exercer sur une machine virtuelle, comme je le fais dans cette démonstration, conservez le mode "BIOS" pour le moment.
III. WDS : boot PXE en mode BIOS
Avant de gérer les deux modes, voyons comment utiliser le mode BIOS seul. Pour cela, nous allons configurer l'étendue "Deploiement" déjà présente sur le serveur DHCP et qui distribue des adresses IP sur le réseau "192.168.14.0/24".
Commencez par ouvrir la console DHCP, sélectionnez l'étendue DHCP utilisée pour le déploiement et effectuez un clic droit sur "Options d'étendue" pour cliquer sur "Configurer les options".
Dans l'onglet "Général", activez les options 066 et 067 en cochant la case située sur la gauche. Renseignez les deux options de cette façon :
Option 66 : l'adresse IP du serveur PXE, ici c'est le serveur WDS
Option 67 : le nom du fichier de démarrage, indiquez la valeur générique "boot\x64\wdsnbp.com".
Validez, vous devez obtenir ceci :
C'est suffisant pour faire du boot PXE en mode BIOS !
Pour tester, rien de plus simple : on démarre une machine virtuelle en "boot réseau" et si elle est bien sur le même segment réseau que les serveurs, elle va obtenir une adresse IP et se connecter au serveur WDS. Sur l'exemple ci-dessous, on voit bien qu'elle a pu obtenir une adresse IP et qu'il faut appuyer sur F12 pour démarrer sur le réseau.
C'est tout bon pour le mode BIOS.
IV. WDS : Boot PXE en mode UEFI (et BIOS)
Pour configurer le DHCP avec les options spécifiques au mode UEFI, le principe est le même avec des options et valeurs différentes.
Maintenant, nous allons voir comment configurer le serveur DHCP pour qu'il gère les deux modes : UEFI et BIOS.
Je vous propose de réaliser cette configuration en PowerShell. Voici les étapes à réaliser :
Activer la prise en charge de l'option 60 dans le serveur DHCP
Déclarer des classes de fournisseurs pour différencier les machines BIOS et UEFI
Créer une stratégie pour gérer les machines en mode BIOS
Créer une stratégie pour gérer les machines en mode UEFI
A. DHCP : ajouter la prise en charge de l'option 60
Dans la liste des options DHCP, l'option 60 n'est pas disponible dans la liste. À l'aide de PowerShell (ou de netsh), nous allons pouvoir remédier à cela.
Sur le serveur DHCP, en l'occurrence SRV-ADDS-01 dans mon exemple, ouvrez une console PowerShell en tant qu'administrateur et exécutez cette commande :
Après avoir actualisé la console DHCP, on peut voir que cette option est accessible :
Passons à la suite.
B. DHCP : déclarer les classes de fournisseurs
Pour la suite, je vous recommande d'utiliser PowerShell ISE ou Visual Studio Code pour écrire les commandes au fur et à mesure.
Commençons par définir trois variables que l'on va appeler tout au long de la procédure :
# Nom d'hôte du serveur DHCP
$DhcpServerName = "SRV-ADDS-01"
# Adresse IP du serveur WDS (PXE)
$PxeServerIp = "192.168.14.11"
# Adresse réseau de l'étendue DHCP ciblée
$Scope = "192.168.14.0"
Puis, grâce aux commandes ci-dessous, nous allons définir trois classes de fournisseurs DHCP correspondantes à des architectures différentes. Par exemple, la valeur "PXEClient:Arch:00007" correspond à du boot PXE pour l'UEFI en x64.
Une nouvelle fois, cette configuration est visible dans la console DHCP. Ici, il faut accéder à la partie "Stratégies" de l'étendue DHCP ciblée. Voici le résultat :
Si l'on regarde les options de notre étendue DHCP, on peut voir qu'il y a beaucoup de valeurs. Effectivement, nous avons plusieurs fois les mêmes options, mais avec des valeurs différentes, et la bonne valeur sera appliquée en fonction de la machine qui initie la connexion.
Le serveur DHCP est correctement configuré !
D. Tester le boot PXE en UEFI
Pour tester cette configuration, il convient de basculer la machine virtuelle en mode UEFI (avec le Secure Boot actif tant qu'à faire) et de tester un boot sur le réseau. Si le serveur DHCP est correctement configuré, la machine virtuelle doit parvenir à contacter le PXE et il suffira d'appuyer sur Entrée pour initier le boot réseau et charger l'image de démarrage.
V. Conclusion
Nous venons de voir comment configurer un serveur DHCP pour prendre en charge le boot PXE en mode BIOS et en mode UEFI. Dans cet exemple, le serveur PXE est représenté par un serveur WDS mais il pourrait s'agir d'une autre solution.
Si vos serveurs sont dans un réseau différent des machines à déployer (VLANs différents, par exemple), vous devez déclarer l'adresse IP du serveur DHCP et du serveur WDS dans les options de relais DHCP de votre passerelle (routeur/pare-feu).
L'entreprise suisse Proton vient de lancer en version bêta son propre gestionnaire de mots de passe : Proton Pass. Il est l'heure de faire le point sur cette nouveauté !
Au fil des années, Proton continue d'étoffer son catalogue de services alors qu'initialement il s'agissait seulement d'un service de messagerie en ligne. Pas n'importe quel service, car il s'agit d'une solution de messagerie basée sur du chiffrement de bout en bout : la sécurité et la confidentialité sont au cœur des préoccupations chez Proton. Au-delà des e-mails, Proton propose un service de gestion de calendriers, de stockage en ligne ou encore de navigation sécurisée avec le service Proton VPN.
Désormais, le gestionnaire de mots de passe Proton Pass vient s'ajouter au catalogue de service de l'entreprise suisse ! Un marché sur lequel la concurrence est forte. On peut citer quelques solutions très connues comme Bitwarden, LastPass, 1Password ou encore KeePass dans un style un peu différent. D'ailleurs, Proton n'hésite pas à évoquer le dernier incident de sécurité qui a touché LastPass.
Pour cette première version, Proton a inclus des fonctions inévitables dans un gestionnaire de mots de passe :
Remplissage automatique des formulaires de connexion (le nom d'utilisateur et le mot de passe) y compris lorsqu'il y a le MFA
Tout dépend du type de second facteur, et cela ne plaira pas forcément à tout le monde, car on met tous ses œufs dans le même panier comme on dit...
Enregistrement automatique des identifiants dans votre coffre-fort de mots de passe s'il s'agit de nouvelles informations
Génération de mots de passe à la demande (mots de passe robustes, bien sûr)
Au-delà de stocker le nom d'utilisateur et le mot de passe, Proton Pass intègre une zone de saisie supplémentaire dans chaque entrée pour permettre l'ajout de notes. Fonction utile pour conserver les codes de récupération correspondants à un site spécifique, par exemple.
À l'instar de Proton Mail et des autres services, Proton Pass bénéficie du chiffrement de bout en bout : "Proton Pass ne se contente pas de chiffrer le champ du mot de passe, mais applique un chiffrement de bout en bout à tous les champs, y compris les noms d'utilisateur, les adresses web et toutes les données contenues dans la section des notes chiffrées."
Pour le moment, Proton Pass est accessible en version bêta, que ce soit en mode web (extensions pour Chrome et Brave pour le moment) ou à partir d'applications mobiles pour iOS et Android. Une version gratuite est accessible à tout le monde. Le modèle de sécurité de Proton Pass est décrit sur cette page.
