Exercice Red Team - Chapitre 3

Remarque importante avant de commencer : les différentes phases ne sont pas entièrement détaillées, les informations fournies ici permettent d'illustrer le contexte et de fournir une meilleure compréhension du récit, certains détails sont manquants - nous nous en excusons.

Cet article est le troisième chapitre d'une série d'articles qui ont été publiés sur ictexpertsluxembourg.lu, coin technique

Scénario 2 : Ajout d'un dispositif Raspberry

Comme indiqué dans le scénario précédent, nous avons équipé plusieurs appareils Raspberry d'un modem 4G, ce qui nous permet de contrôler à distance l'appareil sans avoir besoin d'être à proximité pour le faire fonctionner.

Lors de la reconnaissance précédente, nous avons identifié des salles de formation dans un bureau au rez-de-chaussée (voir le chapitre 2 de cette série de blogs). Comme nous avions remarqué que plusieurs systèmes étaient connectés dans ces salles, nous avons profité de l'occasion pour brancher un de ces dispositifs Raspberry afin d'obtenir un autre accès au réseau ciblé.

Ce scénario avait été retenu suite à notre reconnaissance physique initiale, l'objectif étant d'obtenir un accès au réseau.

Un Raspberry est un petit hardware à faible coût et à faible consommation basé sur un processeur ARM qui peut être facilement étendu avec des composants électroniques et qui peut exécuter des systèmes d'exploitation basés sur Linux. Toutes ces propriétés en font un très bon candidat pour la construction d'implants de réseau personnalisés susceptibles d'être utilisés dans différentes situations où l'accès physique à un réseau intéressant est obtenu.

Pour répondre à ces besoins, nous avons conçu une installation Raspberry personnalisée avec les objectifs suivants en tête :

• Pouvoir accéder à distance au dispositif Raspberry, même lorsqu'il est branché sur des réseaux isolés ou sur des systèmes à lame d'air. Pour ce faire, nous utilisons un modem 4G avec une connexion VPN à nos systèmes de commande et de contrôle ;
• Être totalement passif par défaut et ne pas générer de trafic indésirable pour éviter d'être détecté ou bloqué par les contrôles d'accès au niveau du réseau avant de pouvoir obtenir des informations utiles ;
• Prise en charge d'une configuration réseau multiple afin de s'adapter aux cas d'utilisation potentiels (branché dans des salles de serveurs, sur des réseaux locaux VoIP mixtes, sur des réseaux avec contrôles d'accès) et flexibilité suffisante pour profiter des erreurs potentielles de configuration des commutateurs ;
• Prise en charge d'installations physiques de type « man in the middle » permettant d'usurper l'appareil d'une victime, car cela permettrait de contourner des installations plus complexes avec filtrage IP ou contrôle d'accès au réseau (NAC/802.1x) sans affecter la connectivité de l'appareil de la victime.

Le dispositif Raspberry étant petit, il peut également être déguisé en un périphérique réseau générique en créant un boîtier personnalisé.

Par paresse et parce que nous voulions lui donner l'apparence d'un appareil électronique brut, nous avons choisi de profiter du look de la carte électronique Raspberry 4G qui a été ajoutée à l'appareil Raspberry et de la garder ouverte, avec une antenne à bande.

Comme cela peut éveiller les soupçons, le fait de coller une note indiquant « ! toujours garder cet appareil sous tension ! » sur la face avant de l'appareil cachera légèrement les composants électroniques bruts et provoquera un effet paradoxal qui rendra la présence d'un tel appareil plus légitime (du fait de son apparence fragile).

Après avoir accédé à l'une des salles de formation, la première action a été d'allumer le dispositif Raspberry et d'essayer de le brancher à un patch réseau libre :

Aucun trafic n'ayant été observé sur la prise réseau et le temps étant limité, nous avons choisi de le connecter dans une position de type « man in the middle », c'est-à-dire physiquement entre un ordinateur portable présent dans la salle de formation et sa prise réseau, tout en cachant le dispositif Raspberry dans la trappe.

Attaques passives du réseau

À partir de là, le trafic réseau a pu être observé et l'utilisation du contrôle d'accès au réseau (NAC) a été rapidement identifiée sur la base de l'authentification par radius 802.1X (utilisant le protocole EAP).

Le NAC étant actif sur le commutateur, il est possible que la génération de trafic sans authentification appropriée déclenche une alerte ou même la fermeture du port du commutateur. Comme le dispositif Raspberry était déjà en place, contrôlé à distance et connecté à un réseau fonctionnel, la meilleure chose à faire dans ce scénario était de surveiller passivement le trafic réseau de la victime pendant plusieurs jours au lieu de générer du trafic réseau et de risquer de se faire prendre (de plus, nous disposions déjà d'un autre accès fonctionnel au réseau cible à ce moment-là).

Le dispositif Raspberry utilise deux interfaces réseau configurées comme un pont (comme un commutateur), permettant de laisser passer de manière transparente le trafic de couche 2. La seule restriction est causée par le noyau Linux qui bloque les adresses réservées IEEE 802.1d qui sont utilisées pour le NAC 802.1x. Pour ce faire, il est nécessaire de configurer un masque afin de laisser passer les adresses MAC IEEE 802.1d multicast [1], plus précisément l'adresse MAC EAP 01-80-C2-00-00-03 :

Grâce à cette configuration, le système victime a pu s'authentifier correctement sur le réseau. [1]

Recherche de cibles

Bien sûr, un renifleur de paquets a été lancé dès que l'appareil a été branché. Après moins d'un jour d'attente, une première analyse du trafic réseau a été effectuée directement sur l'appareil à l'aide de scripts basés sur l'outil tshark (nous voulons effectuer l'analyse localement sans avoir à télécharger tous les PCAP d'un réseau 4G - surtout lorsque le signal est mauvais).

• L'exécution des statistiques IP de tshark a permis de découvrir les adresses IP des systèmes internes couramment utilisées et certaines plages de réseau :
  
• Recherche de trafic multicast révélant plusieurs noms d'hôtes, notamment des clients ou des serveurs Windows diffusant sur le même réseau que la victime :
  

Recherche de mots de passe

La découverte d'informations d'identification exploitables à ce stade serait très utile pour les autres scénarios d'attaque. Cela peut être réalisé en utilisant des commandes tshark plus avancées ou en utilisant des outils dédiés :

• La recherche de mots de passe en texte clair ou de mots de passe HTTP peut être intéressante :
  
• De même, certains mots de passe pourraient être divulgués dans des formulaires HTML soumis en clair (via HTTP).
• Si aucun mot de passe en texte clair ne peut être trouvé, les handshakes d'authentification NetNTLM peuvent être récupérés et permettraient d'essayer de craquer les mots de passe, si ceux-ci sont suffisamment faibles. La commande suivante permet de récupérer tous ces handshakes en json avec suffisamment d'informations pour tenter de craquer les mots de passe utilisés pour « signer » ces handshakes, et supporte la plupart des protocoles réseau utilisés pour l'authentification NetNTLM :
  

La première observation, après une journée de reniflage du réseau, est que la victime effectue un handshake NTLM à chaque fois qu'elle visite un site Web. En effet, le proxy web exige une authentification pour chaque page, et l'authentification du proxy est effectuée pendant la demande de tunnellisation HTTP CONNECT, cette demande se produisant en texte clair et divulguant le handshake NetNTLM.

Cela a permis de récupérer les handshakes d'authentification de plusieurs connexions résumées ci-dessous :

La logique derrière ces utilisateurs est intéressante car apparemment, le même identifiant 73 est utilisé soit pour un utilisateur non privilégié (commençant par usr) soit pour un utilisateur privilégié (commençant par adm). Cette pratique est courante dans les environnements informatiques pour éviter que les utilisateurs privilégiés n'accèdent aux courriers électroniques ou aux ressources habituelles de l'entreprise.

Les handshakes d'authentification de ces comptes ont été extraits afin d'être craqués avec des dictionnaires de mots de passe connus ou ayant fait l'objet de fuites, sans succès.
Dans un deuxième temps, une session de craquage plus intelligente a été lancée sur la base de modèles de mots de passe ; le test de modèles simples n'a pas été concluant, même en faisant tourner notre plateforme GPU pendant plusieurs jours, jusqu'à ce que nous découvrions certains modèles de mots de passe utilisés par les employés.

Recherche de fichiers

Les partages de fichiers Windows sont très utilisés dans la plupart des entreprises, soit pour des raisons informatiques, soit pour l'échange ou l'archivage de fichiers d'entreprise.

Depuis une vingtaine d'années, les entreprises de sécurité informatique recommandent de ne pas utiliser les protocoles en texte clair, car ils permettent à tout qui est capable d'intercepter le trafic réseau d'accéder facilement à certaines informations. C'est cependant rarement le cas pour le protocole de partage de fichiers de Windows pour lequel les communications sont rarement cryptées, une excellente opportunité dans la situation actuelle.

Tout d'abord, cela a permis de découvrir un grand nombre de fichiers liés aux stratégies de groupe de Windows, car ces fichiers sont échangés régulièrement avec le contrôleur de domaine. Il s'agissait notamment de fichiers contenant des mots de passe tels que les politiques de création d'utilisateurs :

Ce mot de passe a pu être décodé et était lié à un fournisseur informatique. Potentiellement, ce mot de passe pouvait être utilisé ailleurs dans le réseau ou sur d'autres réseaux gérés par le même fournisseur informatique.

Il était basé sur un modèle qui pouvait également être utilisé pour craquer d'autres mots de passe :

Bien entendu, d'autres fichiers ont été obtenus à ce stade, notamment des documents confidentiels et des extraits de données financières (fichiers Excel...) qui étaient utilisés par le compte de bureau de la victime, et qui ont pu être exfiltrés directement depuis le réseau 4G, sans que nous puissions être détectés.

Persévérance

Suite à cette découverte, nous avons décidé de continuer à renifler le trafic pendant une semaine complète, alors que d'autres scénarios d'attaque étaient en cours.

Plusieurs jours après l'analyse initiale, l'ensemble du profil Windows de l'utilisateur a été synchronisé, car l'utilisateur était configuré pour utiliser un profil distant. Là encore, cela a entraîné la fuite de nombreux fichiers de configuration utilisés par les applications Windows, y compris les profils Firefox.

Les noms de fichiers suivants ont pu être observés pendant la synchronisation des profils Windows, montrant la synchronisation de deux profils Firefox :

Le fichier logins.json contient les informations d'identification cryptées à l'aide d'une clé stockée dans key4.db et, éventuellement, d'une phrase de passe principale ; cependant, une des limites de Firefox est qu'il ne demande pas automatiquement la création de cette phrase de passe.

Le fichier key4.db est une base de données SQLite et sa récupération a été difficile car de nombreux paquets ont été perdus en raison de problèmes de performance du dispositif raspberry pi, en particulier lorsque l'ensemble du profil utilisateur distant était synchronisé (nous suggérons aux lecteurs intéressés de vérifier la taille du tampon lorsqu'ils exécutent tcpdump et de surveiller les paquets perdus en envoyant régulièrement le signal SIGUSR1 à tcpdump).

Néanmoins, il a été possible de reconstruire un des fichiers SQLite key4.db avec seulement 3 des 4 chunks en remplaçant le chunk manquant par des octets nuls. Ce profil ne contenait qu'un seul compte web alors que le second contenait des dizaines de comptes :

À ce stade, il n'y a aucune garantie que ce compte web utilise le même mot de passe que le compte de domaine de l'utilisateur, mais d'après notre expérience, c'est souvent le cas, soit à cause de l'utilisation de la délégation d'authentification du domaine (le site web authentifie les utilisateurs en se connectant au LDAP de l'Active Directory), soit parce que les utilisateurs réutilisent leurs mots de passe sur plusieurs services de l'entreprise (parfois même sur des services web extérieurs à l'entreprise).

Recraquage de mots de passe

Grâce aux mots de passe recueillis, des modèles de mots de passe intéressants ont pu être dérivés pour essayer de craquer à nouveau les handshakes d'authentification obtenus.

Les mots de passe suivent souvent le même modèle, dès lors que les utilisateurs ont tendance à générer un mot de passe uniquement pour correspondre à la politique de mot de passe, dans notre cas :

• Un nom commençant par une majuscule
• Un caractère spécial facultatif
• Une date
• Un caractère spécial facultatif

La session de craquage de mots de passe suivante montre que de tels mots de passe peuvent être récupérés en moins d'une minute avec un bon matériel et un bon dictionnaire de noms :

L'utilisation du craquage de mots de passe dans ce cas a réussi, mais n'a servi à rien puisque les mots de passe obtenus auraient pu de toutes façons être ajoutés directement à un dictionnaire. C'est une mauvaise habitude d'utiliser la puissance pure plutôt que les neurones humains.

À ce stade, et sans générer de trafic sur le réseau, nous avons obtenu deux mots de passe, et prouvé que l'un d'entre eux est valide pour un compte utilisateur apparemment privilégié sur le domaine Windows.

Cela a également montré que les habitudes de réutilisation des mots de passe peuvent briser les paradigmes des domaines de sécurité, car la fuite du mot de passe d'un domaine à faible risque suffit à un assaillant pour accéder à un domaine à plus haut risque.

Attaques actives du réseau

Jusqu'à présent, seules des activités passives ont été réalisées sur le dispositif Raspberry PI, pour s'assurer qu'elles ne puissent pas être découvertes. La poursuite du processus d'intrusion nécessite toutefois d'obtenir un accès au réseau.

L'accès au réseau nécessite cependant de découvrir une adresse IP valide et de contourner le NAC. Ceci est possible en usurpant les adresses réseau de l'ordinateur portable de la salle de formation, car notre système Raspberry est connecté entre cet ordinateur portable et le réseau.

L'usurpation aveugle d'adresses réseau peut souvent entraîner une interruption du réseau pour l'ordinateur portable de la victime. Pour éviter de nous faire remarquer à cause des interruptions de réseau, nous avons suivi une stratégie définie dans un article de DEFCON- 19 en 2011.

Cette stratégie consiste à :

• Utiliser un pont et configurer correctement le noyau Linux pour laisser passer les paquets EAP (ce qui a été présenté précédemment) ;
• Usurper le MAC de la victime en utilisant une règle POSTROUTING avec EBTables ;
• Usurper l'IP de la victime en utilisant une traduction d'adresse IPTables Source NAT ;
• Enregistrer de force l'adresse MAC du routeur dans les tables ARP, et créer manuellement une route pour la plage d'IP du réseau local approprié (parce que nous usurpons l'adresse IP de la victime, le système Linux ne sait pas réellement qu'il peut router le trafic vers la plage d'IP de la victime locale et il ne connaît pas la passerelle locale).
• Finalement, ajouter des routes pour acheminer le trafic vers d'autres réseaux de l'entreprise (ne pas créer aveuglément une route par défaut, car cela peut casser l'accès à notre serveur de commande et de contrôle qui utilise la route par défaut du modem 4G).

Des scripts ont été écrits pour chacune de ces étapes afin de garder un contrôle précis de la configuration de l'usurpation. Cependant, le plus difficile est souvent de découvrir d'abord l'environnement réseau et surtout :

• L'adresse IP et MAC de la victime
• L'adresse IP et MAC du routeur
• La plage IP du réseau de la victime
• Les adresses potentielles de serveurs DNS en service

La méthode la plus simple pour les découvrir consiste à dresser une liste de mapping IP/MAC des hôtes qui ont été observés dans le trafic réseau et à effectuer une analyse basée sur les faits suivants :

1. Le trafic le plus fréquent se déroule souvent entre l'adresse IP de l'ordinateur portable de la victime et l'adresse MAC du routeur
2. Les adresses MAC sont différentes pour chaque système du réseau local, ce qui permet d'identifier la taille du réseau local
3. Tous les paquets vers les IP des autres réseaux utilisent l'adresse MAC du routeur

La configuration finale pour l'usurpation était la suivante :

L'examen de ces variables a permis d'exécuter les différents scripts d'usurpation. Cette configuration a été validée pour fonctionner correctement (y compris les DNS) en essayant d'obtenir le fichier proxy.pac du dispositif Raspberry (qui permet également de découvrir les usages web courants de l'entreprise) :

À partir de là, il était possible d'accéder au réseau de l'entreprise à l'aide du dispositif Raspberry, tout en usurpant les adresses MAC et IP de la victime.

À ce stade, nous avons pu commencer à utiliser les informations d'identification de l'utilisateur identifié précédemment, mais nous avons décidé d'utiliser les informations d'identification obtenues lors du Scénario 4.

Pendant la clôture de la mission, l'ordinateur portable de la salle de formation a été considéré comme compromis par la Blue Team car des connexions utilisant un administrateur de forêt ont été observées à partir de cet ordinateur portable. Cet ordinateur portable a donc été retiré du réseau.

Cependant, l'intervention de la Blue Team n'a pas permis de trouver le dispositif Raspberry, ce qui signifie que nous pouvions toujours accéder à distance au dispositif, mais que nous avions perdu l'accès au réseau puisqu'aucune victime ne pouvait effectuer l'authentification NAC pour nous.

Nous avons donc décidé d'attendre que la victime ou un autre ordinateur portable soit connecté au câble réseau, mais nous avons rapidement atteint la fin de la mission de la Red Team. Nous avons fini par révéler que l'ordinateur portable de la salle de formation n'avait pas été compromis, mais qu'un dispositif Raspberry avait été utilisé pour accéder directement au réseau.

Scénario 3 : Phishing ciblé (simulé)

Comme indiqué dans le précédent chapitre, les campagnes de phishing ont été exclues de cet exercice, tel que défini dans la partie pré-engagement.

Toutefois, étant donné que ce vecteur d'attaque représente un point d'entrée important qui est activement exploité dans le monde réel, la Red Team de POST a recommandé de simuler, au minimum, une campagne exécutée avec succès afin d'évaluer l'ensemble de la chaîne et de couvrir le risque de la meilleure façon possible et d'apporter une valeur ajoutée supplémentaire à cet exercice en testant :

• l'efficacité du filtrage des passerelles de messagerie ;
• la possibilité pour un assaillant d'exécuter du code sur un poste de travail standard (durcissement) ;
• les limites de la solution AV/EDR ;
• la possibilité pour le code malveillant exécuté de se connecter à Internet par le biais des politiques de passerelle Web (proxy) ;
• le système d'alerte et en cas d'alerte, les réactions et processus en place - la réponse à l'incident ;
• l'exposition au risque pour le CLIENT d'être compromis par ce vecteur d'attaque.

Comme décrit dans le chapitre 2, nous avions déjà créé une étape PowerShell personnalisée moins charge utile inversée HTTPS pour contourner le Sophos AV et AMSI. Nous l'avons combinée avec un HTA pour pouvoir la livrer et avons envoyé un e-mail contenant le lien malveillant vers notre site Web à notre victime.

La victime ciblée a cliqué sur le lien, qui a ouvert notre site Web à l'aide du navigateur Web Microsoft Edge. Sur la base d'un script d'empreinte JS de base, la victime est redirigée, à l'aide d'Edge ou d'IE, vers notre page HTML qui délivre le script .HTA à exécuter. Comme nous pouvons le voir sur la capture d'écran des journaux du serveur Web ci-dessous, la victime a visité la page, a ouvert le HTA, qui a été exécuté lorsque la charge utile PowerShell a été téléchargée. Ensuite, nous pouvons voir la demande sur « /cs/jsquery », ce qui signifie que notre charge utile PowerShell a été exécutée avec succès et qu'elle se connecte à notre serveur C&C :

Figure 1 Dropper et charge utile exécutés avec succès

Notre shell à distance est à présent ouvert sur la machine de la victime :

À partir de là, nous pouvons commencer la phase de post-exploitation, en découvrant et en énumérant le réseau.

Nous avons d'abord commencé à énumérer les informations du domaine, telles que les utilisateurs, les ordinateurs et les groupes, afin d'identifier les serveurs intéressants et les utilisateurs administrateurs de domaine ou d'entreprise à cibler. Ensuite, nous avons cherché des dossiers et des fichiers intéressants sur l'hôte auquel nous étions connectés, afin de récolter des fichiers qui pourraient contenir des mots de passe, notamment des bases de données de navigateurs. Disposant d'une session d'un utilisateur du domaine, nous pouvions facilement accéder aux ressources du réseau.

Nous avons rapidement identifié qu'il y avait très peu d'utilisateurs administrateurs de domaine, et seulement un compte administrateur d'entreprise. Nous avons également trouvé plusieurs fichiers KeePass qui nous laissent penser que cette société utilisait KeePass comme logiciel principal de gestion des mots de passe. Si l'utilisateur emploie le mot de passe principal de KeePass au lieu d'utiliser un fichier clé pour protéger les fichiers de la base de données KeePass, le mot de passe principal peut être stocké dans les fichiers de configuration de KeePass.

Nous avons donc utilisé les scripts d'agression harmj0y de Cobalt Strike pour récolter les informations du mot de passe principal. Par conséquent, nous avons pu trouver le mot de passe de la base de données KeePass de l'utilisateur en texte clair :

Dans ce fichier de la base de données KeePass, le compte administrateur du logiciel « Password Manager Pro » (PMP) a pu être trouvé. Après avoir configuré le tunnel de chaussettes de Cobalt Strike, nous avons pu y accéder en tant qu'administrateur, et accéder aux mots de passe de l'administrateur de tous les serveurs, y compris celui du contrôleur de domaine ainsi que le mot de passe de l'utilisateur administrateur de l'entreprise.

Nous avons alors pu nous connecter avec succès au contrôleur de domaine en utilisant le compte admin de l'entreprise, et accéder à toutes les données stockées sur les serveurs de fichiers... game over !

Trophée : Obtenir des privilèges « Enterprise Admin » au sein du réseau d'entreprise : mission accomplie !

Scénario 4 : Intrusion physique au siège (salle des serveurs)

Le dernier trophée consistait à s'introduire dans le centre de données. Notre crainte d'apprendre que le DC de notre client aurait pu être un Tier 3 ou Tier 4 a été rapidement dissipée lorsque nous avons trouvé un article en ligne expliquant que celui-ci avait récemment été déplacé au siège de notre client.

Forts de ces informations, nous nous sommes rendus dans les locaux de notre client afin d'essayer d'identifier son emplacement dans le bâtiment. Nous nous concentrons sur les étages inférieurs car très souvent les locaux techniques se trouvent à ces niveaux, pour des raisons techniques (température plus basse au sous-sol, facilité de déplacement des racks dans les étages inférieurs, gain de place pour les bureaux à l'étage supérieur...). Qui plus est, nous avions déjà visité les étages supérieurs lors de la récupération du précédent trophée, ceux-ci semblaient uniquement occupés par des bureaux, et les locaux techniques ne nous semblaient pas assez grands pour pouvoir accueillir un centre de données.

Lors de notre visite, nous avons identifié plusieurs locaux techniques aux différents sous-sols. Par rapport à la configuration du bâtiment, nous n'avions identifié que trois locaux techniques suffisamment grands pour accueillir un centre de données.

Après quelques phases de reconnaissance, nous nous sommes rendus sur place avec un simple outil de porte claquée. Par expérience, nous savons que dans la majorité des cas, pour une question de commodité, la sortie d'un local technique ne nécessite pas l'utilisation d'une carte d'accès.

Figure 2 – Ouverture d'une porte claquée par le bas

Lors de nos séances de reconnaissance, parmi les trois locaux techniques que nous avions repérés, l'un d'eux semblait plus surveillé que les autres avec une caméra qui pointait directement sur la porte.

Toutefois, afin de mettre notre théorie en pratique, nous l'avons testée sur l'un des sites techniques les moins surveillés. Après quelques secondes, nous avons réussi à ouvrir la porte nous permettant d'accéder à cette pièce et avons ainsi validé notre POC.

Après cette validation, nous sommes retournés dans le local technique que nous avions initialement ciblé pour vérifier si notre intuition était juste quant à l'emplacement du DC. Nous sommes donc revenus à cette porte et avons à nouveau essayé de l'ouvrir avec notre outil, cette fois sous la surveillance d'une caméra qui pointait directement sur la porte.

Après quelques secondes, nous avons réussi à ouvrir la porte.

Une fois la première porte franchie, nous sommes arrivés dans un couloir menant à une autre porte. Le bruit de la ventilation provenant de cette deuxième porte et le registre à côté contenant les noms, les dates et les heures des visites semblaient indiquer que nous étions au bon endroit. Nous avons répété la procédure d'ouverture de la porte à l'aide de notre outil afin d'essayer d'accéder au DC. Une fois de plus, après quelques instants, nous avons pu ouvrir la porte et arriver directement dans la salle des serveurs.

Une fois dans la salle, le trophée était obtenu. Cependant, une dernière pièce semblait intéressante, car tous les câbles des différentes baies y aboutissaient. Cette fois encore, nous avons ouvert cette porte avec le même outil et avons réussi à accéder au centre névralgique du client.

Figure 6 – Centre de données

Nous avons décidé de brancher un dispositif Raspberry dans cette salle de serveurs, nous n'avons eu aucune difficulté à ouvrir le rack car de nombreuses clés étaient disponibles. Les serrures des racks sont standard si elles ne sont pas changées individuellement, une seule clé peut les ouvrir toutes.

Figure 7 – Tiroir à clé ouvert

Il est important de noter que cet appareil a été branché pour valider le trophée, mais qu'aucune interaction n'a été effecutée avec lui, d'abord en raison de la sensibilité de l'équipement sur lequel il était branché, mais aussi parce que tous les trophées avaient déjà été validés au préalable.

Trophée : « Accéder au centre de données et brancher un dispositif malveillant dans la salle des serveurs » : mission accomplie !

Conclusion :

En conclusion, alors que les clients pensent souvent que le siège, le centre de données et la salle des serveurs sont sécurisés parce qu'ils sont situés à l'intérieur de bâtiments, protégés par des caméras et des cartes d'accès, nous avons cependant réussi à atteindre 3 des 4 trophées énumérés ci-dessous :

• Trophée 1 : Objectif lié à la sécurité informatique [TERMINÉ]
  • Obtenir des privilèges « Enterprise Admin » au sein du réseau d'entreprise ;
• Trophée 3 : Scénario complet : [TERMINÉ]
  • Identifier les membres du Conseil d'administration ;
  • Identifier l'emplacement de leur bureau ;
  • Entrer dans le bureau ;
  • Accéder à et/ou exfiltrer un document confidentiel ;
• Trophée 4 : Scénario complet [TERMINÉ]
  • Entrer dans le centre de données principal ;
  • Entrer dans la zone des racks de serveurs ;
  • Déposer un dispositif malveillant pour éprouver les capacités de persistance et accéder aux données de l'infrastructure sans être détecté.