intro-pentest-web-ethical-hacking-linuxmaine.pdf

Introduction of the pentest for web apps

1. Introduction aux
pentest de sites web
(ethical hacker)
Association LinuX Maine
https://linuxmaine.org/
Session du 17/05/2025
Thierry GAYET

2. ●Cette presentation et a usage educatif ou
documentaire uniquement. N’utilisez pas ces
connaissances pour un usage pour des usages
reprehensibles ou malveillants !

3. Messagerie securise
https://www.tixeo.com/

4. PLAN
●
- Définition des tests d'intrusion
●
- Qui a besoin de tests d'intrusion ?
●
- Points de vue sur les tests d'intrusion
●
- Phases des tests d'intrusion
●
- Reconnaissance et collecte d'informations
●
- Dénombrement et analyse du réseau
●
- Tests et exploitation des vulnérabilités

5. I. INTRODUCTION

6. Definition des tests
d’intrusions ?
Un test d'intrusion, ou pentest, est un test
évaluant la solidité de tous les contrôles de
sécurité du système informatique. Les tests
d'intrusion évaluent les contrôles procéduraux
et opérationnels, ainsi que les contrôles
technologiques.

7. Qui a besoin de pentest ?
- Banques/institutions financières, organismes gouvernementaux, fournisseurs
en ligne ou toute organisation traitant et stockant des informations privées.
- Developpeurs de sites web.
- La plupart des certifications exigent ou recommandent la réalisation régulière
de tests d'intrusion afin de garantir la sécurité du système.
- La section 11.3 de la norme de sécurité des données PCI exige que les
organisations effectuent des tests d'application et d'intrusion au moins une fois
par an.
- La section 8 des mesures de protection administratives de la règle de
sécurité HIPAA exige des audits des processus de sécurité, des analyses
périodiques des vulnérabilités et des tests d'intrusion.

8. Points de vue sur
les tests de pénétration
Externe vs. Interne : les tests de pénétration
peuvent être effectués du point de vue d'un
attaquant externe ou d'un employé
malveillant.
Ouvert vs. Secret :les tests de pénétration
peuvent être effectués à l'insu ou non du
service informatique de l'entreprise testée.

9. Phases des tests de pénétration
1)Reconnaissance et collecte d'informations
2)Recensement et analyse du réseau ou scanning
3)Tests et exploitation des vulnérabilités, Obtention
d’accès/Exploitation
4)Maintien de l'accès
5)Couverture des traces
6)Rapport

10. 1. Reconnaissance et collecte
d'informations
Objectif : Découvrir un maximum d’informations sur une cible
(individu ou organisation) sans avoir à la contacter.
Méthodes :
●
Découverte d’informations sur l’organisation via WHOIS
●
Analyse des sous domaines
●
Recherche Google
●
Navigation sur le site web

11. Au cours de la phase de reconnaissance, un attaquant tente de
rassembler le plus d'informations possible sur une cible avant de
lancer son attaque. La plage cible de reconnaissance peut inclure
des employés, des réseaux, des systèmes et même des tiers.
Parfois, les informations disponibles en ligne sur une cible
peuvent révéler des points d’entrée faibles, en fonction de ce que
l’attaquant trouve. Un attaquant peut utiliser deux techniques de
reconnaissance différentes : la reconnaissance passive et la
reconnaissance active.
La reconnaissance passive impliquerait de récupérer des
informations sans interagir directement avec la cible. Par
exemple, la recherche dans les archives publiques (piratage
Google), le trashing (la plongée dans une benne à ordures), les
communiqués de presse et les offres d'emploi.
En revanche, la reconnaissance active implique une interaction
directe avec la cible. Par exemple, contacter un employé et poser
des questions sur l'entreprise ou utiliser des techniques d'analyse
de réseau non intrusives.

12. 2. Énumération et analyse du
réseau (scanning)
Objectif : Découvrir les réseaux existants appartenant à une cible, ainsi que les hôtes
et services actifs exécutés sur ces hôtes.
Le scanning, ou analyse, correspond à la phase de préattaque, lorsque l’attaquant
analyse le réseau de l’entreprise. Il s’agit d’approfondir la recherche sur les systèmes
détectés en recherchant des données et des services utiles. L'analyse comprend
l'utilisation d'outils tels que des scanners de ports, des outils ping, des scanners de
vulnérabilités et des mappeurs de réseau. Fondamentalement, on cherche des
vulnérabilités qui pourraient être exploitées afin d’accéder au système. Une
organisation peut avoir une détection d'intrusion en place sur son réseau, il est donc
important d'apprendre et d’utiliser des techniques d'évasion pour éviter toute alerte.
Méthodes :
●Programmes d’analyse identifiant les hôtes actifs, les ports ouverts, les services et
autres informations (Nmap, autoscan)
●Requêtes DNS
●Analyse des itinéraires (traceroute)

13. 3. Tests et exploitation des
vulnérabilités
Objectif : Rechercher les vulnérabilités connues des hôtes et déterminer si elles sont
exploitables, ainsi qu’évaluer leur gravité potentielle.
Méthodes :
●Analyse des vulnérabilités à distance (Nessus, OpenVAS)
●Tests d’exploitation actifs
●Vérification des connexions et attaque par force brute
●Exploitation des vulnérabilités (Metasploit, Core Impact)
●Découverte des failles 0day et des exploits (fuzzing, analyse de programme)
●Techniques post-exploitation pour évaluer la gravité (niveaux d’autorisation, portes
dérobées, rootkits, etc.)

14. À ce stade, l’attaquant réussi à accéder à un système ou à
une application, et continue de sa tentative d’extirpation du
plus d'informations possibles (un compte administrateur afin
d'élever les privilèges).
Un hacker pourrait avoir accès à un système ou à une
application par le biais d'une faille du mot de passe, d'un
piratage de session, d'une ingénierie sociale, , etc.
Les systèmes du réseau pourraient être compromis.
Toutefois, un attaquant pourrait néanmoins endommager un
système sans privilèges d’administrateur, car certains outils
peuvent s’exécuter sans en avoir besoin.

15. 4. Maintien de l'accès
Le maintien de l'accès fait référence à la phase dans laquelle un
attaquant tente de conserver un contrôle complet du système. Cela
pourrait être fait en installant des rootkits, des chevaux de Troie, en
créant un compte administrateur ou en utilisant d'autres outils de porte
dérobée.
Quelle que soit la voie choisie par l’attaquant, celle-ci serait en mesure
de télécharger et de manipuler des fichiers à tout moment. Le système
étant en ligne, la plupart de ces opérations sont effectuées à distance. Il
serait très difficile pour un administrateur système ou un utilisateur
normal de détecter ces outils car ils sont connus pour fonctionner en
mode furtif.
L’attaquant pourrait également ajouter le système compromis à un
réseau de robots afin d’avoir encore plus de contrôle sur le système Ce
dernier pourrait ensuite être utilisé pour des attaques sur une autre cible.

16. 5. Couverture des traces
La phase finale de l'attaquant est de couvrir ses traces. Il est important que l'attaquant
manipule ou supprime tous les historiques. Ainsi, il évite toute détection et, surtout, toute
poursuite. Par exemple, certains outils peuvent être utilisés pour effacer les historiques du
système et de ses applications, sinon, le hacker peut choisir de le faire manuellement.
Un attaquant s'assurera que les chevaux de Troie et les rootkits restent masqués et
cachent des données à l'aide de techniques de sténographie afin d'éviter la détection par
un logiciel antivirus. L'espionnage des adresses IP est une autre technique d'évasion
utilisée par un attaquant pour envoyer une équipe de sécurité dans la mauvaise direction.
Bien entendu, la dernière chose que tout attaquant souhaite est de se faire prendre et de
perdre le contrôle du système.
En tant que hacker éthique, il est important de connaître et suivre les mêmes étapes que
celles utilisées par un hacker malveillant pour jouer un rôle important dans la défense
contre les cyberattaques.

17. 6. Rapports
Objectif : Organiser et documenter les informations
recueillies lors des phases de reconnaissance,
d’analyse du réseau et de test de vulnérabilité d’un test
d’intrusion.
Méthodes :
●
Outils de documentation (Dradis)
●
Organiser les informations par hôtes, services,
dangers et risques identifiés, et recommander des
solutions.

18. Comment devenir un
testeur de pénétration
- Se tenir au courant des dernières avancées en matière de sécurité
informatique : lire des newsletters et des rapports de sécurité est un excellent
moyen.
- Maîtriser C/C++ et un langage de script tel que PYTHON, GO, RUST, C++
- Certifications Microsoft, Cisco et Novell
- Certifications en tests d'intrusion
- Hacker éthique certifié (CEH)
- Testeur d'intrusion certifié GIAC (GPEN)

19. Ethical hacking
●Le hacking éthique, ou piratage éthique, en sécurité informatique
, décrit l'activité de hacking lorsqu'elle n'est pas malveillante.
●Les mêmes pratiques (tel que le piratage, l'exploitation de faille,
le contournement des limitations) peuvent être utilisées par des
white hats (français : chapeaux blancs) avec un objectif
bienveillant (analyse, information, protection…) ou des black hat
s (français : chapeaux noirs) avec un objectif malveillant
(destruction, prise de contrôle, vol...).
●Par exemple, il est plus éthique de pratiquer une divulgation resp
onsable et d'agir dans un cadre légal : mission de test d'intrusion
ou bug bounty (chasse aux bugs).

20. boites blanche / grise / noire

21. boites blanche / grise / noire
Les tests en « boîte blanche » (white box)
●
Les tests en « boîte blanche » consistent à examiner le fonctionnement d’une application et sa
structure interne, ses processus, plutôt que ses fonctionnalités. Sont ici testés l’ensemble des
composants internes du logiciel ou de l’application, par l’intermédiaire du code source, principale
base de travail du testeur.
●
Pour réaliser un test en « boîte blanche », ce dernier doit donc avoir des compétences de
programmation, afin de comprendre le code qu’il étudie. Il doit également avoir une vue globale du
fonctionnement de l’application, des éléments qui la composent, et naturellement de son code
source. Contrairement aux tests en « boîte noire », le testeur ici a un profil développeur, et non pas
utilisateur.
●
En effectuant un test en « boîte blanche », on voit en effet quelle ligne de code est appelée pour
chaque fonctionnalité. Cela permet de tester le flux de données ainsi que la gestion des exceptions et
des erreurs. On s’intéresse également à la dépendance des ressources, ainsi qu’à la logique interne
et justesse du code. C’est pourquoi ces tests sont surtout utiles pendant le développement d’une
application, même s’ils peuvent être effectués durant de nombreuses phases de la vie d’un projet. La
méthode en « boîte blanche » peut être appliquée pour les tests unitaires (majoritairement), les tests
d’intégration et les tests système.
●
La méthode en « boîte blanche » utilise des scénarios de test, créés par le testeur selon ce qu’il a
appris du code source de l’environnement. L’objectif est qu’en testant l’ensemble de ces scénarios,
toutes les lignes de code soient vérifiées. Ce qui est regardé, c’est le processus effectué par
l’application après une entrée (input) pour obtenir un résultat. On ne fait que vérifier si le code produit
les résultats espérés.

23. boites blanche / grise / noire
Les tests en « boîte noire » (black box)
●
Les tests en « boite noire » consistent à examiner uniquement les fonctionnalités d’une
application, c’est-à-dire si elle fait ce qu’elle est censée faire, peu importe comment elle le fait. Sa
structure et son fonctionnement interne ne sont pas étudiés. Le testeur doit donc savoir quel est le
rôle du système et de ses fonctionnalités, mais ignore ses mécanismes internes. Il a un profil
uniquement « utilisateur ».
●
Ainsi, cette méthode sert à vérifier, après la finalisation d’un projet, si un logiciel ou une application
fonctionne bien et sert efficacement ses utilisateurs. En général, les testeurs sont à la recherche
de fonctions incorrectes ou manquantes, d’erreurs d’interface, de performance, d’initialisation et de
fin de programme, ou bien encore d’erreurs dans les structures de données ou d’accès aux bases
de données externes.
●
Pour cela, ils préparent des scénarios calqués sur les différents chemins utilisateur possibles sur
le système testé. Toutes les fonctionnalités doivent être prises en compte, pour qu’une fois tous les
tests effectués, elles aient toutes été éprouvées. Les tests consistent à suivre un scenario, et à
vérifier pour chaque fonctionnalité que les entrées (inputs) valides sont acceptées, que celles non
valides sont refusées, et bien entendu, qu’à chaque fois, le résultat (sortie ou output) attendu est
bien obtenu. C’est ce que l’on appelle la méthode « trial and error » (essais et erreurs).
●

24. boites blanche / grise / noire

25. boites blanche / grise / noire
Les tests en « boîte grise » (grey box)
●
Les tests en « boîte grise » compilent ces deux précédentes approches : ils éprouvent
à la fois les fonctionnalités et le fonctionnement d’un système. C’est-à-dire qu’un
testeur va par exemple donner une entrée (input) à un système, vérifier que la sortie
obtenue est celle attendue, et vérifier par quel processus ce résultat a été obtenu.
●
Dans ce type de tests, le testeur connaît le rôle du système et de ses fonctionnalités,
et a également une connaissance, bien que relativement limitée, de ses mécanismes
internes (en particulier la structure des données internes et les algorithmes utilisés).
Attention cependant, il n’a pas accès au code source !
●
Ces tests peuvent difficilement être effectués pendant la phase de développement du
projet, car elle implique des tests sur les fonctionnalités du programme : celui-ci doit
déjà être dans un état proche de final pour que ces tests puissent être pertinents. En
effet, pendant les tests en « boîte grise », ce sont surtout des techniques de « boîte
noire » qui sont utilisées, puisque le code n’est pas accessible. Cependant, les
scénarios sont orientés pour jouer sur les processus sous-jacents, et ainsi les tester
également.
●

27. Les equipes de couleurs
en cybersec

29. Equipes en cybersec
Equipe rouge (Red Team)
??????
●
Mission : Attaquer / offensive
●
Simule des attaques réelles pour tester la résistance des
systèmes (tests d’intrusion, exploitation de vulnérabilités).
●
Rôle offensif : agit comme un hacker malveillant.
●
Objectif : découvrir les failles de sécurité avant qu’un vrai
attaquant ne le fasse.

30. Equipes en cybersec
Equipe verte (Green Team)
??????
●Mission : Automatiser / intégrer
●Travaille sur l'automatisation de la sécurité, CI/CD sécurisé,
infrastructure-as-code.
●Parfois fusionnée avec les DevOps/SecOps.
●Fait le lien entre Blue Team et les développeurs.

31. Equipes en cybersec
Equipe bleu (Blue Team)
??????
●
Mission : Défendre
●
Responsable de la sécurité opérationnelle, surveillance,
détection, et réponse aux incidents.
●
Rôle défensif : protège les systèmes contre les attaques.
●
Utilise des outils comme les SIEM, EDR/XDR/, firewalls,
etc.

32. Equipes en cybersec
Equipe blanche (White Team)
⚪
●Mission : Superviser
●Observateurs ou arbitres dans les simulations Red vs Blue (ex :
exercices de type "capture the flag" ou cyber range).
●Garantit que les règles sont respectées, documente, évalue les
performances.

33. Equipes en cybersec
Equipe jaune (Yellow Team)
??????
●Mission : Développement sécurisé
●Composée de développeurs ou ingénieurs logiciels sensibilisés
à la sécurité.
●Collabore avec la Blue Team pour intégrer la sécurité dès la
conception (DevSecOps).

34. Equipes en cybersec
Purple Team
??????
●
Mission : Coopérer
●
Fusion des Red et Blue Teams : collaboration active entre attaque et
défense.
●
But : améliorer la sécurité en combinant les points de vue offensif et
défensif.
●
Facilite le partage de connaissances et la mise à jour des défenses.

35. Equipes en cybersec
Black Team (plus rare, parfois utilisée dans des contextes
⚫
militaires ou industriels)
●Mission : Exploitation, opérations secrètes
●Très offensif, souvent dans un cadre légal restreint
(cyberguerre, opérations clandestines).
●Parfois synonyme de “Red Team extrême”.

38. Les chapeaux de couleur

39. Les chapeaux de couleur
Les chapeau blancs :
●
Les chapeaux blancs, parfois également appelés « pirates informatiques éthiques » ou « bons
pirates informatiques », sont l'antithèse des chapeaux noirs. Ils exploitent des systèmes ou des
réseaux informatiques pour détecter leurs failles de sécurité et formuler des recommandations
pour les améliorer.
●
Les chapeaux blancs utilisent leurs compétences pour découvrir les failles de sécurité et aider
à protéger les organisations contre les pirates informatiques dangereux. Il peut s'agir
d'employés rémunérés ou d'entrepreneurs travaillant pour des entreprises en tant que
spécialistes de la sécurité qui tentent de trouver des failles dans la sécurité.
●
Les chapeaux blancs expliquent partiellement pourquoi les grandes entreprises enregistrent
généralement moins d'interruptions de service et éprouvent moins de problèmes avec leurs
sites Web. La majorité des pirates savent qu'il sera plus difficile d'entrer dans des systèmes
gérés par de grandes entreprises que dans ceux exploités par les petites entreprises, qui ne
disposent probablement pas des ressources adaptées pour examiner chaque fuite de sécurité
possible.
●
Un sous-ensemble de pirates informatiques éthiques inclut les testeurs de pénétration ou
« pentesters », qui se concentrent particulièrement sur
●
a recherche de vulnérabilités et l'évaluation des risques au sein des systèmes.

40. Les chapeaux de couleur
Les chapeaux gris
● Les chapeaux gris se trouvent à mi-chemin entre les chapeaux noirs et les chapeaux blancs. Les pratiques des chapeaux gris
sont un mélange de celles des chapeaux noirs et des chapeaux blancs. Les chapeaux gris recherchent souvent les failles d'un
système sans l'autorisation ni la connaissance du propriétaire. S'ils constatent des problèmes, ils les signalent au propriétaire, en
demandant parfois une petite rémunération pour résoudre le problème.
● Certains chapeaux gris aiment croire qu'ils rendent service aux entreprises en piratant leurs sites Web et en envahissant leurs
réseaux sans autorisation. Toutefois, les propriétaires d'entreprises apprécient rarement les intrusions non autorisées dans leur
infrastructure d'informations commerciales.
● Bien souvent, la véritable intention d'un chapeau gris est de montrer ses compétences et de se faire de la publicité (ou obtenir
une reconnaissance) pour ce qu'il considère comme une contribution à la cybersécurité.
● Les chapeaux gris peuvent parfois violer les lois ou les normes éthiques habituelles, mais ils n'ont pas l'intention malveillante
typique d'un chapeau noir.
● Lorsqu'un chapeau blanc découvre une vulnérabilité, il ne l'exploite qu'avec une autorisation et n'en parle pas aux autres avant
qu'elle ne soit corrigée. En revanche, le chapeau noir l'exploitera illégalement ou indiquera à d'autres comment le faire. Le
chapeau gris ne l'exploitera pas illégalement et ne dira pas aux autres comment le faire.
● De nombreux chapeaux gris estiment qu'Internet n'est pas sécurisé pour les entreprises et considèrent que leur mission est de
rendre cet espace plus sûr pour les individus et les organisations. Ils remplissent celle-ci en piratant des sites Web et des
réseaux, ainsi qu'en provoquant le chaos pour montrer au monde qu'ils ont raison. Les chapeaux gris affirment souvent qu'ils ne
cherchent pas à faire du tort avec leurs incursions. Parfois, ils sont simplement curieux de pirater un système de renom, sans
tenir compte de la protection de la vie privée et de nombreuses autres lois.
● Dans la plupart des cas, les chapeaux gris fournissent de précieux renseignements aux entreprises. Néanmoins, la communauté
des chapeaux blancs (et une grande partie du cybermonde) ne considère pas leurs méthodes comme éthiques. Les activités des
chapeaux gris sont illégales, car les pirates informatiques n'ont pas reçu l'autorisation d'une organisation pour tenter d'infiltrer ses
systèmes.

41. Les chapeaux de couleur
Les chapeaux noirs :
●
Les chapeaux noirs sont des criminels qui s'introduisent dans des réseaux informatiques avec des intentions
malveillantes. Ils peuvent également publier des logiciels malveillants qui détruisent des fichiers, prennent des
ordinateurs en otage ou volent des mots de passe, des numéros de carte de crédit et d'autres informations
personnelles.
●
Les chapeaux noirs sont motivés par des raisons intéressées, comme le gain financier, la vengeance ou
simplement le désir de semer le chaos. Il peut arriver que leur motivation soit idéologique, en ciblant des
personnes avec lesquelles ils sont en profond désaccord.
●
Les chapeaux noirs commencent souvent comme des « pirates adolescents » novices qui utilisent des outils de
piratage achetés dans le but d'exploiter les failles de sécurité. Certains sont formés au piratage par des patrons
désireux de gagner de l'argent rapidement. Les principaux chapeaux noirs sont généralement des pirates
informatiques qualifiés qui travaillent pour des organisations criminelles complexes qui fournissent parfois des
outils de collaboration à leurs employés et proposent des contrats de service aux clients, tout comme le font les
entreprises légitimes. Les kits de logiciels malveillants vendus sur le Web caché comprennent parfois des
garanties ainsi qu'un service clientèle.
●
Les chapeaux noirs se spécialisent souvent, par exemple dans le phishing ou la gestion d'outils d'accès à
distance. Un grand nombre d'entre eux décrochent leur « emploi » par le biais de forums et d'autres relations sur
le Web caché. Certains conçoivent et vendent eux-mêmes des logiciels malveillants, mais d'autres préfèrent
travailler par l'intermédiaire de franchises ou de contrats de location, là encore, comme dans le monde
professionnel légitime.
●
Le piratage est devenu un outil de collecte de renseignements à part entière pour les gouvernements, mais les
chapeaux noirs travaillent plus souvent seuls ou avec des organisations criminelles pour gagner facilement de
l'arge

42. II. DETAIL : blue team,
ethical hacking

47. Analyse d’un site web

63. ETAPES EN DETAIL
1)Reconnaissance et collecte d'informations
2)Recensement et analyse du réseau ou scanning
3)Tests et exploitation des vulnérabilités, Obtention
d’accès/Exploitation
4)Maintien de l'accès
5)Couverture des traces
6)Rapport

64. 1. Reconnaissance Passive
(pas d'interaction directe

65. Examples
●whois linuxmaine.org
●dig linuxmaine.org any
●nslookup -type=ns linuxmaine.org

66. $ whatweb linuxmaine.org
http://linuxmaine.org [301 Moved Permanently] Country[FRANCE]
[FR], HTTPServer[nginx], IP[89.88.198.101],
RedirectLocation[https://linuxmaine.org/], Title[301 Moved
Permanently], nginx
https://linuxmaine.org/ [200 OK] Country[FRANCE][FR],
Email[[email protected]], HTML5, HTTPServer[nginx],
IP[89.88.198.101], JQuery, MetaGenerator[SPIP 4.3.5 avec Escal
5.2.9], SPIP[4.3.5][https://linuxmaine.org/local/config.txt],
Script[text/javascript], Strict-Transport-Security[max-
age=63072000; includeSubDomains; preload], Title[Le Mans
1998 - 2025], UncommonHeaders[x-sso-wat,composed-by,x-spip-
cache,content-security-policy,x-content-type-options,x-download-
options,x-permitted-cross-domain-policies,permissions-policy], X-
Frame-Options[SAMEORIGIN], X-XSS-Protection[1;
mode=block], nginx

67. $ host -t ns linuxmaine.org
linuxmaine.org name server dns12.ovh.net.
linuxmaine.org name server ns12.ovh.net.

68. $ dig linuxmaine.org MX
; <<>> DiG 9.20.8-6-Debian <<>> linuxmaine.org MX
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 21892
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 512
;; QUESTION SECTION:
;linuxmaine.org.
IN MX
;; ANSWER SECTION:
linuxmaine.org.
21600 IN MX
1 mx4.mail.ovh.net.
linuxmaine.org.
21600 IN MX
10 mx3.mail.ovh.net.
;; Query time: 23 msec
;; SERVER: 192.168.86.1#53(192.168.86.1) (UDP)
;; WHEN: Thu May 15 19:55:36 CEST 2025
;; MSG SIZE rcvd: 95

70. Whois / DNSWhois / DNS
Whois / DNSWhois / DNS
●whois : Informations sur le propriétaire du domaine.
●dig, host, nslookup : Requêtes DNS (serveurs NS, MX, etc.).
●ViewDNS.info : Interface web pour plusieurs requêtes DNS.
●SecurityTrails, DNSdumpster : Cartographie DNS passive.

71. WHOIS →

72. Recherche sur les moteurs (OSINT)
Recherche sur les moteurs (OSINT)
●
Google Dorking : Requêtes avancées Google.
●
Shodan : Scanne Internet pour des services exposés.
●
Censys.io : Similaire à Shodan, avec plus de granularité.
●
Hunter.io : Trouver des adresses e-mail liées à un domaine.
●
theHarvester : Collecte d’adresses e-mails, sous-domaines, hôtes,
etc.

73. $ theHarvester -d linuxmaine.org -b all
acteurjeunessequartierssud.linuxmaine.org
acteurjeunessequartierssud.linuxmaine.org:2001:41d0:1:1b00:213:186:33:17
acteurjeunessequartierssud.linuxmaine.org:213.186.33.17
centresocialdesquartierssud.linuxmaine.org
centresocialdesquartierssud.linuxmaine.org:213.186.33.17
cloud.linuxmaine.org
galette.linuxmaine.org
galette.linuxmaine.org:89.88.198.101
galette2.linuxmaine.org
garradin.linuxmaine.org
garradin.linuxmaine.org:213.186.33.17
gestion.linuxmaine.org
git.linuxmaine.org
git.linuxmaine.org:89.88.198.101
grr.linuxmaine.org
grr.linuxmaine.org:213.186.33.17
lists.linuxmaine.org
lists.linuxmaine.org:local.linuxmaine.org
Dd lists.linuxmaine.org:local.linuxmaine.org.
local.linuxmaine.org
local.linuxmaine.org:89.88.198.101
local.linuxmaine.org:local.linuxmaine.org
local.linuxmaine.org:local.linuxmaine.org.
nextcloud.linuxmaine.org:89.88.198.101
pad.linuxmaine.org
polecoluche72.linuxmaine.org
polecoluche72.linuxmaine.org:213.186.33.17
pve.linuxmaine.org
pve.linuxmaine.org:89.88.198.101
rc.linuxmaine.org
rc.linuxmaine.org:89.88.198.101
spip4.linuxmaine.org
spip4.linuxmaine.org:89.88.198.101
test.linuxmaine.org
test.linuxmaine.org:89.88.198.101
visio.linuxmaine.org
wg.linuxmaine.org
wg.linuxmaine.org:89.88.198.101
wiki.linuxmaine.org

74. Réseaux sociaux et bases de données publiques
Réseaux sociaux et bases de données publiques
●
SpiderFoot : OSINT automatisé.
●
Maltego : Cartographie relationnelle de personnes, domaines,
serveurs, etc.
●
Recon-ng : Framework modulaire d’OSINT.
●
Amass : Cartographie passive de sous-domaines (utilise
plusieurs sources).

76. 2. Reconnaissance Active
(interactions contrôlées

77. Scan de ports / services
Scan de ports / services
●Nmap : Découverte d’hôtes, ports, services, versions.
●Masscan : Scanning très rapide de ports.
●ZMap : Scan à large échelle.

78. Enumération DNS et sous-domaines
Enumération DNS et sous-domaines
●Sublist3r : Recherche de sous-domaines.
●Amass : (mode actif) découverte étendue de sous-domaines.
●dnsenum, dnsrecon : Outils d’énumération DNS.

79. $ sublist3r -d linuxmaine.org
[-] Total Unique Subdomains Found: 22
www.linuxmaine.org
acteurjeunessequartierssud.linuxmaine.org
alcasar.linuxmaine.org
centresocialdesquartierssud.linuxmaine.org
cloud.linuxmaine.org
galette.linuxmaine.org
galette2.linuxmaine.org
garradin.linuxmaine.org
gestion.linuxmaine.org
git.linuxmaine.org
grr.linuxmaine.org
local.linuxmaine.org
nextcloud.linuxmaine.org
pad.linuxmaine.org
polecoluche72.linuxmaine.org
pve.linuxmaine.org
rc.linuxmaine.org
spip4.linuxmaine.org
test.linuxmaine.org
visio.linuxmaine.org
wg.linuxmaine.org
wiki.linuxmaine.org

80. $ dnsrecon -d linuxmaine.org -t brt
[*] No dictionary file has been specified.
[*] Using the dictionary file: /usr/share/dnsrecon/dnsrecon/data/namelist.txt (provided by tool)
[*] brt: Performing host and subdomain brute force against linuxmaine.org...
[+] CNAME ftp2.linuxmaine.org anonymous.ftp.ovh.net
[+] A anonymous.ftp.ovh.net 213.186.33.14
[+] CNAME ftp.linuxmaine.org linuxmaine.org
[+] A linuxmaine.org 89.88.198.101
[+] A local.linuxmaine.org 89.88.198.101
[+] AAAA local.linuxmaine.org 2001:861:4d02:cbb0:ecb8:5a86:200:106
[+] CNAME mail.linuxmaine.org ns0.ovh.net
[+] A ns0.ovh.net 193.70.18.144
[+] CNAME pop3.linuxmaine.org ns0.ovh.net
[+] A ns0.ovh.net 193.70.18.144
[+] A rc.linuxmaine.org 89.88.198.101
[+] CNAME smtp.linuxmaine.org ns0.ovh.net
[+] A ns0.ovh.net 193.70.18.144
[+] A vpn.linuxmaine.org 89.88.198.101
[+] A www.linuxmaine.org 89.88.198.101
[+] 15 Records Found

81. $ dnsenum linuxmaine.org
Host's addresses:
__________________
linuxmaine.org. 19811 IN A 89.88.198.101
Name Servers:
______________
ns12.ovh.net. 3081 IN A 213.251.128.131
dns12.ovh.net. 887 IN A 213.251.188.131
Mail (MX) Servers:
___________________
mx3.mail.ovh.net. 60 IN A 91.121.53.175
mx4.mail.ovh.net. 20 IN A 178.32.124.207
Brute forcing with /usr/share/dnsenum/dns.txt:
_______________________________________________
ftp.linuxmaine.org. 21600 IN CNAME linuxmaine.org.
linuxmaine.org. 21600 IN A 89.88.198.101
mail.linuxmaine.org. 21600 IN CNAME ns0.ovh.net.
ns0.ovh.net. 270 IN A 193.70.18.144
smtp.linuxmaine.org. 21600 IN CNAME ns0.ovh.net.
ns0.ovh.net. 300 IN A 193.70.18.144
vpn.linuxmaine.org. 21600 IN A 89.88.198.101
www.linuxmaine.org. 21600 IN A 89.88.198.101

82. $ amass enum -passive -v -d linuxmaine.org
linuxmaine.org (FQDN) --> ns_record --> dns12.ovh.net (FQDN)
linuxmaine.org (FQDN) --> ns_record --> ns12.ovh.net (FQDN)
linuxmaine.org (FQDN) --> mx_record --> mx4.mail.ovh.net (FQDN)
linuxmaine.org (FQDN) --> mx_record --> mx3.mail.ovh.net (FQDN)
wg.linuxmaine.org (FQDN) --> a_record --> 89.88.198.101 (IPAddress)
wg.linuxmaine.org (FQDN) --> aaaa_record --> 2001:861:4d02:cbb0:e1e9:9725:1:101
(IPAddress)
89.80.0.0/12 (Netblock) --> contains --> 89.88.198.101 (IPAddress)
2001:860::/29 (Netblock) --> contains --> 2001:861:4d02:cbb0:e1e9:9725:1:101
(IPAddress)
5410 (ASN) --> managed_by --> BOUYGTEL-ISP (RIROrganization)
5410 (ASN) --> announces --> 89.80.0.0/12 (Netblock)
5410 (ASN) --> announces --> 2001:860::/29 (Netblock)
local.linuxmaine.org (FQDN) --> a_record --> 89.88.198.101 (IPAddress)
local.linuxmaine.org (FQDN) --> aaaa_record --> 2001:861:4d02:cbb0:ecb8:5a86:200:106
(IPAddress)
pve.linuxmaine.org (FQDN) --> a_record --> 89.88.198.101 (IPAddress)
2001:860::/29 (Netblock) --> contains --> 2001:861:4d02:cbb0:ecb8:5a86:200:106
(IPAddress)
www.linuxmaine.org (FQDN) --> a_record --> 89.88.198.101 (IPAddress)
acteurjeunessequartierssud.linuxmaine.org (FQDN) --> aaaa_record -->
2001:41d0:1:1b00:213:186:33:17 (IPAddress)
2001:41d0::/33 (Netblock) --> contains --> 2001:41d0:1:1b00:213:186:33:17 (IPAddress)
16276 (ASN) --> managed_by --> OVH (RIROrganization)
16276 (ASN) --> announces --> 2001:41d0::/33 (Netblock)
galette.linuxmaine.org (FQDN) --> a_record --> 89.88.198.101 (IPAddress)
visio.linuxmaine.org (FQDN) --> a_record --> 89.88.198.101 (IPAddress)
dns12.ovh.net (FQDN) --> a_record --> 213.251.188.131 (IPAddress)
dns12.ovh.net (FQDN) --> aaaa_record --> 2001:41d0:1:4a83::1 (IPAddress)
mx4.mail.ovh.net (FQDN) --> a_record --> 178.32.124.207 (IPAddress)
rc.linuxmaine.org (FQDN) --> a_record --> 89.88.198.101 (IPAddress)
2001:41d0::/33 (Netblock) --> contains --> 2001:41d0:1:4a83::1 (IPAddress)
213.251.128.0/18 (Netblock) --> contains --> 213.251.188.131 (IPAddress)
178.32.0.0/15 (Netblock) --> contains --> 178.32.124.207 (IPAddress)
16276 (ASN) --> announces --> 213.251.128.0/18 (Netblock)
16276 (ASN) --> announces --> 178.32.0.0/15 (Netblock)
spip4.linuxmaine.org (FQDN) --> a_record --> 89.88.198.101 (IPAddress)
nextcloud.linuxmaine.org (FQDN) --> a_record --> 89.88.198.101 (IPAddress)
linuxmaine.org (FQDN) --> a_record --> 89.88.198.101 (IPAddress)
centresocialdesquartierssud.linuxmaine.org (FQDN) --> a_record --> 213.186.33.17
(IPAddress)
213.186.32.0/19 (Netblock) --> contains --> 213.186.33.17 (IPAddress)
16276 (ASN) --> announces --> 213.186.32.0/19 (Netblock)
galette2.linuxmaine.org (FQDN) --> a_record --> 89.88.198.101 (IPAddress)
pad.linuxmaine.org (FQDN) --> a_record --> 89.88.198.101 (IPAddress)
git.linuxmaine.org (FQDN) --> a_record --> 89.88.198.101 (IPAddress)
ns12.ovh.net (FQDN) --> a_record --> 213.251.128.131 (IPAddress)
ns12.ovh.net (FQDN) --> aaaa_record --> 2001:41d0:1:1983::1 (IPAddress)
2001:41d0::/33 (Netblock) --> contains --> 2001:41d0:1:1983::1 (IPAddress)
213.251.128.0/18 (Netblock) --> contains --> 213.251.128.131 (IPAddress)
mx3.mail.ovh.net (FQDN) --> a_record --> 91.121.53.175 (IPAddress)
91.121.0.0/16 (Netblock) --> contains --> 91.121.53.175 (IPAddress)
16276 (ASN) --> announces --> 91.121.0.0/16 (Netblock)

83. $ amass enum -brute -d linuxmaine.org
linuxmaine.org (FQDN) --> ns_record --> dns12.ovh.net (FQDN)
linuxmaine.org (FQDN) --> ns_record --> ns12.ovh.net (FQDN)
linuxmaine.org (FQDN) --> mx_record --> mx4.mail.ovh.net (FQDN)
linuxmaine.org (FQDN) --> mx_record --> mx3.mail.ovh.net (FQDN)
linuxmaine.org (FQDN) --> a_record --> 89.88.198.101 (IPAddress)
rc.linuxmaine.org (FQDN) --> a_record --> 89.88.198.101 (IPAddress)
spip4.linuxmaine.org (FQDN) --> a_record --> 89.88.198.101 (IPAddress)
pad.linuxmaine.org (FQDN) --> a_record --> 89.88.198.101 (IPAddress)
ftp2.linuxmaine.org (FQDN) --> cname_record --> anonymous.ftp.ovh.net (FQDN)
mail.linuxmaine.org (FQDN) --> cname_record --> ns0.ovh.net (FQDN)
smtp.linuxmaine.org (FQDN) --> cname_record --> ns0.ovh.net (FQDN)
89.80.0.0/12 (Netblock) --> contains --> 89.88.198.101 (IPAddress)
5410 (ASN) --> managed_by --> BOUYGTEL-ISP (RIROrganization)
5410 (ASN) --> announces --> 89.80.0.0/12 (Netblock)
www.linuxmaine.org (FQDN) --> a_record --> 89.88.198.101 (IPAddress)
galette2.linuxmaine.org (FQDN) --> a_record --> 89.88.198.101 (IPAddress)
anonymous.ftp.ovh.net (FQDN) --> a_record --> 213.186.33.14 (IPAddress)
213.186.32.0/19 (Netblock) --> contains --> 213.186.33.14 (IPAddress)
16276 (ASN) --> managed_by --> OVH (RIROrganization)
16276 (ASN) --> announces --> 213.186.32.0/19 (Netblock)
mx3.mail.ovh.net (FQDN) --> a_record --> 91.121.53.175 (IPAddress)
galette.linuxmaine.org (FQDN) --> a_record --> 89.88.198.101 (IPAddress)
centresocialdesquartierssud.linuxmaine.org (FQDN) --> a_record --> 213.186.33.17 (IPAddress)
git.linuxmaine.org (FQDN) --> a_record --> 89.88.198.101 (IPAddress)
213.186.32.0/19 (Netblock) --> contains --> 213.186.33.17 (IPAddress)
91.121.0.0/16 (Netblock) --> contains --> 91.121.53.175 (IPAddress)
16276 (ASN) --> announces --> 91.121.0.0/16 (Netblock)

84. $ git clone https://github.com/1N3/Sn1per.git
$ cd Sn1per/

$ sudo ./install.sh
$ sudo sniper -t linuxmaine.org -m recon

85. $ spiderfoot -s linuxmaine.org -u passive -o csv
-q
$ spiderfoot -s linuxmaine.org -u passive -o csv
-q > linuxmaine-osint.csv

86. $ metagoofil -d linuxmaine.org -t pdf,doc,xls,ppt -l 100 -o ./output -f result.html
[*] Searching for 100 .pdf files and waiting 30.0 seconds between searches
[*] Results: 0 .pdf files found
[*] Searching for 100 .doc files and waiting 30.0 seconds between searches
[*] Results: 0 .doc files found
[*] Searching for 100 .xls files and waiting 30.0 seconds between searches
[*] Results: 0 .xls files found
[*] Searching for 100 .ppt files and waiting 30.0 seconds between searches
[*] Results: 0 .ppt files found
[+] Done!
-d : domaine
??????
-t : types de fichiers
??????
-l : nombre de fichiers max
??????
-o : dossier de sortie
??????
-f : nom du fichier HTML généré
??????

87. Bannières et technologies
Bannières et technologies
●WhatWeb, Wappalyzer, BuiltWith : Identifier les technologies
utilisées sur un site.
●Netcat, Telnet, Nmap --script : Lecture de bannières de
services.

88. $ nmap -sS -sV -T4 linuxmaine.org
Starting Nmap 7.95 ( https://nmap.org ) at 2025-05-14 19:24 CEST
Nmap scan report for linuxmaine.org (89.88.198.101)
Host is up (0.016s latency).
rDNS record for 89.88.198.101: bol62-h05-89-88-198-101.dsl.sta.abo.bbox.fr
Not shown: 997 filtered tcp ports (no-response)
PORT STATE SERVICE VERSION
21/tcp open ssh OpenSSH 8.4p1 Debian 5+deb11u1 (protocol 2.0)
80/tcp open http nginx
443/tcp open ssl/http nginx
Service Info: OS: Linux; CPE: cpe:/o:linux:linux_kernel
Service detection performed. Please report any incorrect results at https://nmap.org/submit/
.
Nmap done: 1 IP address (1 host up) scanned in 17.44 seconds

89. TCP $ nmap -sS -sV linuxmaine.org
Starting Nmap 7.95 ( https://nmap.org ) at 2025-05-15 19:44 CEST
Nmap scan report for linuxmaine.org (89.88.198.101)
Host is up (0.017s latency).
rDNS record for 89.88.198.101: bol62-h05-89-88-198-101.dsl.sta.abo.bbox.fr
Not shown: 997 filtered tcp ports (no-response)
PORT STATE SERVICE VERSION
21/tcp open ssh OpenSSH 8.4p1 Debian 5+deb11u1 (protocol 2.0)
80/tcp open http nginx
443/tcp open ssl/http nginx
Service Info: OS: Linux; CPE: cpe:/o:linux:linux_kernel
Service detection performed. Please report any incorrect results at https://nmap.org/submit/ .
Nmap done: 1 IP address (1 host up) scanned in 17.47 seconds

91. Nmap Results

92. 3. Tests et exploitation des vulnérabilités, Obtention
d’accès/Exploitation

93. Outils d’exploitation

96. Packet Storm Security
●URL : https://packetstormsecurity.com
●Archive massive de vulnérabilités, exploits, whitepapers, tools,
etc.
●Plus diversifié qu'Exploit-DB (avec des scripts, outils, etc.).

97. Exploit Database (Exploit-DB)
●URL : https://www.exploit-db.com
●Maintenu par Offensive Security.
●Contient des exploits publics (code + description) et des PoC.
●Très utilisé dans le cadre de tests de vulnérabilité et avec
searchsploit.

98. NVD / CVE Details
●NVD : https://nvd.nist.gov
●CVE Details : https://www.cvedetails.com
●Données sur les vulnérabilités CVE (Common Vulnerabilities
and Exposures).
●Pas toujours des exploits prêts à l’emploi, mais très utile pour
connaître les vulnérabilités publiées.

99. GitHub
●Beaucoup de PoC et d’outils d’exploitation y sont publiés.
●Exemples :
●https://github.com/nomi-sec/PoC-in-GitHub (index de PoCs
récents)
●Recherche avec CVE-XXXX-YYYY ou exploit dans GitHub.

100. 0day.today (anciennement 1337day)
●URL : https://0day.today
●Base de données d’exploits publics, mais aussi de 0-day
payants.
●Usage éthique : prudence requise, accès partiellement
restreint.

101. Metasploit Framework
●URL : https://github.com/rapid7/metasploit-framework
●Contient des centaines d'exploits, payloads, scanners.
●Peut être couplé avec msfconsole, msfvenom.

102. Vulners
●URL : https://vulners.com
●Moteur de recherche d’exploits, bulletins de sécurité, PoCs, etc.
●API pratique pour intégration dans des outils d'audit.

103. CXSecurity
●URL : https://cxsecurity.com
●Anciens et nouveaux exploits, avec base classée par type de
vulnérabilité.

104. VirusShare
●URL : https://virusshare.com
●Une énorme collection de malwares (samples binaires).
●Nécessite un compte (gratuit mais avec validation manuelle).
●Chaque échantillon est identifié par son hash MD5/SHA256.

105. MalwareBazaar (par abuse.ch)
●URL : https://bazaar.abuse.ch
●Fournit des échantillons de malwares récents.
●Recherche par hash, signature YARA, tag (ex : "ransomware").
●API disponible.
●Beaucoup utilisé par les chercheurs en Threat Intelligence.

106. MalShare
●URL : https://malshare.com
●Plateforme communautaire d'échange de malwares.
●Requiert une inscription.
●API REST simple pour rechercher et télécharger.

107. Any.Run (Interactive Sandbox)
●URL : https://any.run
●Sandbox interactif pour analyser des malwares en temps réel.
●Peut fournir des échantillons selon les cas.
●Analyses visuelles + réseau + comportement.

108. Hybrid Analysis (par Falcon CrowdStrike)
●URL : https://www.hybrid-analysis.com
●Sandbox avancée pour malwares.
●Téléchargement possible d’échantillons (après inscription).
●Classement par type, nom de menace, etc.

109. VX-Underground
●URL : https://vx-underground.org
●La plus grosse collection publique de malwares, APTs,
ransomwares, leaks de groupes.
●Fournit aussi des documents de leaks de groupes APT et des
codes sources de malwares célèbres.
●Pas en accès libre direct (souvent via Discord ou demande).

110. Zoo (TheZoo)
●URL GitHub : https://github.com/ytisf/theZoo
●Base de malwares bien organisée (samples + source pour
certains).
●Pour usage éducatif / recherche uniquement.

111. VirusTotal
●URL : https://www.virustotal.com
●Analyse de fichiers et URLs par dizaines d’antivirus.
●Possibilité d’extraire des échantillons en étant enregistré
comme chercheur.
●API puissante.

112. VirusTotal (Mobile Apps)
●
URL : https://www.virustotal.com
●
Accepte l’analyse de fichiers .apk (Android) et .ipa (iOS).
●
Retourne les détections de nombreux antivirus + comportements.
●
API disponible pour rechercher et soumettre des applis mobiles.
●
Tu peux chercher des hashs, noms de paquets (package names), etc.

113. AndroZoo
●URL : https://androzoo.uni.lu
●Maintenu par l’Université du Luxembourg.
●Contient plusieurs millions d’APK Android, légitimes et
malveillants.
●Recherche par SHA256, package name, certificate, catégorie.
●Usage académique (accès sur demande).

114. Koodous
●URL : https://koodous.com
●Plateforme collaborative d’analyse d’apps Android.
●Téléchargement de .apk + évaluation communautaire.
●API publique (avec jeton gratuit).
●Dispose d’un moteur YARA pour détecter les comportements
suspects.

115. APKMirror / APKPure (non-malveillant, mais utile pour
comparaison)
●Pas des bases de malwares, mais utiles pour comparer des
versions infectées/propres d’applis.
●https://www.apkmirror.com
●https://apkpure.com

116. AppMon / MobSF (sandbox pour analyse)
●AppMon : Surveillance dynamique d'applications Android
(recherche académique).
●MobSF (Mobile Security Framework) : sandbox et framework
d’analyse statique/dynamique Android et iOS.
●https://github.com/MobSF/Mobile-Security-Framework-MobSF

117. iOS-specific malware (rares)
●
Très peu de malwares iOS publics, car le système est fermé.
●
Les samples iOS sont principalement disponibles dans :
●
VirusTotal
●
VX-Underground
●
APT reports (ex : Kaspersky, FireEye, Mandiant)
●
On trouve surtout des malwares jailbreakés ou utilisés dans des
attaques APT (comme Pegasus, LightSpy, etc.).

118. OWASP ZAP
(open source, très complet pour les tests dynamiques)

119. INSTALLATION
Telecharge l’installer :
https://www.zaproxy.org/download/
$ cd ~/Download/
$ chmod a+x ZAP_2_16_1_unix.sh
$ sudo ./ZAP_2_16_1_unix.sh
[sudo] password for tgayet:
Starting Installer ...

120. Méthode GUI (mode graphique)
⚙️
Lancer ZAP (zap.sh sur Linux ou depuis le menu Windows/macOS).
Aller dans "Quick Start" → "Automated Scan".
Entrer l’URL cible (ex: http://testphp.vulnweb.com) → Lancer.
ZAP explore le site (spider) puis exécute des attaques (XSS, SQLi...).

121. ligne de commande (mode headless)
./zap.sh -daemon -port 8090 -config api.key=your_api_key
Tu peux alors piloter ZAP via son API REST : http://localhost:8090/ via API ou script Python avec python-owasp-zap-v2.4
.

122. Burpsuite
(Version professionnelle)

123. Burp Suite (proxy et scanner interactif)
Méthode standard
??????
Démarre Burp.
Va dans "Proxy" > "Options" : vérifie le port (souvent 8080).
Configure ton navigateur pour utiliser le proxy 127.0.0.1:8080.
Navigue sur le site cible dans ton navigateur.
Toutes les requêtes sont interceptées → tu peux les réinjecter
dans le scanner (onglet "Scanner" si Pro).
Analyse passive (Community Edition)
??????
Active le proxy.
Utilise "Target" > "Site Map" pour voir les pages collectées.
Clique droit sur une page > "Do passive scan".

124. Installation de la version pro.
$ wget -qO-
https://raw.githubusercontent.com/xiv3r/Burp
suite-Professional/main/install.sh | sudo bash
Burp Suite est une suite d’outils développée en Java par la
société PortSwigger Ltd. Il existe trois versions de Burpsuite : la
version community (free), la version professional et la version
enterprise (les deux dernières sont payantes et assez chères).

125. Execution
$ burpsuite (version communautaire gratuite)
$ which burpsuitepro (version pro)
/usr/bin/burpsuitepro

126. Client / Serveur

127. Exemple de requetes

128. Architecture burpsuite (proxy)

129. Architecture burpsuite (proxy)

130. On peut choisir entre un projet existant
(uniquement en version pro) ou un projet
temporaire. Puis appuyez sur NEXT

131. Pas besoin de charger un fichier de config,
appuyez sur START BURP

132. Burpsuite se charge …

133. Nous arrivons ici sur le dashboard.
Sur la barre du dessus vous avez les différents outils disponibles :
proxy, le repeater, le spider, l’intruder et le decoder.

134. 2 possibilites de configuration :
- utilisation d’un navigateur web externe en configurant burpsuite comme proxy
- utilisation du navigateur web interne base sur chromium et deja preconfigure
Cliquer sur open browser

135. Pour parametrer burpsuite pour pouvoir intercepter la navigation provenant de
notre navigateur web comme firefox (via l’utilisation de l’extension foxy standard) :
https://docs.bluekeys.org/guide/cyber-securite/outils/burpsuite-introduction

136. Une page web interne doit s’ouvrir… ou
l’on peut personnaliser l’URL

137. La page don’t on a tape l’url doit s’ouvrir …
mai la burpsuite n’a pas encore effectue d’interception
car elle n’est pas encore active !

138. A activer ici et ensuite on peut recharger la page ...

139. On voir apparaitre les HTTP
REQUEST mais la pour le
moment le navigateur interne a
envoye la requete au proxy
burpsuite (et pas encore au
serveur web car intercept est a
ON)
Pour la liberer de burp, on doit
cliquer sur le bouton forward

140. A chaque HTTP REQUEST on aura le detail et on
pourra aussi modifier pour voir le comportement du
serveur.
Apres chaque modification, il faudra appuyer sur le
bonton FORWARD.

141. On peut changer d’onglet de INTERCEPT a HTTP
HISTORY. Cela liste toutes les requetes passees et
recuperees par l’intercepteur BURPSuite (qu’il soit
a ON ou bien a OFF).

142. On peut donc consulter les HTTP REQUEST
(navigateur web →proxy → serveur web) mais
aussi les HTTP RESPONSE (serveur web → proxy
→ navigateur web).

144. On peut modifier la requete.
Une fois la requete modifie, on peut l’envoyer en
appuyant sur SEND.

147. https://www.youtube.com/watch?v=MH3F6qqcgyw
https://www.youtube.com/watch?v=rQRhHhhGTjM
https://www.kali.org/tools/burpsuite/
https://github.com/xiv3r/Burpsuite-Professional
Liens et ressources
https://github.com/fagun18/ChatGPT-with-BurpSuite

148. nikto

149. Installation
sudo apt install nikto
ou
$ git clone https://github.com/sullo/nikto.git
$ cd nikto
$ perl nikto.pl -h

150. Exemple de scan
nikto -h http://www.linuxmaine.org
nikto -h http://www.linuxmaine.org -p 8080 -ssl
nikto -h http://www.linuxmaine.org -output
result.txt

151. WPScan (WordPress uniquement)

152. Installation
$ sudo gem install wpscan

153. Exemple de scan
$ docker run --rm -it wpscanteam/wpscan --url
http://www.linuxmaine.org
$ wpscan --url http://example.com --api-token
YOUR_TOKEN
Nb : Obtiens un token gratuit sur https://wpscan.com

154. JoomScan (Joomla uniquement)

155. Installation
$ git clone https://github.com/OWASP/JoomScan.git
$ cd JoomScan
$ chmod +x joomscan.pl

156. Exemple de scan
$ ./joomscan.pl -u http://www.linuxmaine.org

157. III. AUTRES ANNEXES
TECHNIQUES