.. | ||
buckets | ||
drupal | ||
electron-desktop-apps | ||
php-tricks-esp | ||
tomcat | ||
xss-to-rce-electron-desktop-apps | ||
403-and-401-bypasses.md | ||
aem-adobe-experience-cloud.md | ||
angular.md | ||
apache.md | ||
artifactory-hacking-guide.md | ||
bolt-cms.md | ||
cgi.md | ||
code-review-tools.md | ||
dotnetnuke-dnn.md | ||
drupal.md | ||
flask.md | ||
git.md | ||
golang.md | ||
grafana.md | ||
graphql.md | ||
gwt-google-web-toolkit.md | ||
h2-java-sql-database.md | ||
iis-internet-information-services.md | ||
imagemagick-security.md | ||
jboss.md | ||
jira.md | ||
joomla.md | ||
jsp.md | ||
laravel.md | ||
moodle.md | ||
nextjs.md | ||
nginx.md | ||
nodejs-express.md | ||
prestashop.md | ||
put-method-webdav.md | ||
python.md | ||
README.md | ||
rocket-chat.md | ||
special-http-headers.md | ||
spring-actuators.md | ||
symphony.md | ||
tomcat.md | ||
uncovering-cloudflare.md | ||
vmware-esx-vcenter....md | ||
waf-bypass.md | ||
web-api-pentesting.md | ||
werkzeug.md | ||
wordpress.md |
80,443 - Méthodologie de Pentesting Web
{% hint style="success" %}
Apprenez et pratiquez le Hacking AWS :HackTricks Training AWS Red Team Expert (ARTE)
Apprenez et pratiquez le Hacking GCP : HackTricks Training GCP Red Team Expert (GRTE)
Soutenir HackTricks
- Consultez les plans d'abonnement!
- Rejoignez le 💬 groupe Discord ou le groupe telegram ou suivez-nous sur Twitter 🐦 @hacktricks_live.
- Partagez des astuces de hacking en soumettant des PRs aux HackTricks et HackTricks Cloud dépôts github.
Si vous êtes intéressé par une carrière en hacking et par le fait de hacker l'inhackable - nous recrutons ! (polonais courant écrit et parlé requis).
{% embed url="https://www.stmcyber.com/careers" %}
Informations de base
Le service web est le service le plus commun et étendu et de nombreux types différents de vulnérabilités existent.
Port par défaut : 80 (HTTP), 443(HTTPS)
PORT STATE SERVICE
80/tcp open http
443/tcp open ssl/https
nc -v domain.com 80 # GET / HTTP/1.0
openssl s_client -connect domain.com:443 # GET / HTTP/1.0
Web API Guidance
{% content-ref url="web-api-pentesting.md" %} web-api-pentesting.md {% endcontent-ref %}
Méthodologie résumé
Dans cette méthodologie, nous allons supposer que vous allez attaquer un domaine (ou sous-domaine) et seulement cela. Donc, vous devriez appliquer cette méthodologie à chaque domaine, sous-domaine ou IP découvert avec un serveur web indéterminé dans le périmètre.
- Commencez par identifier les technologies utilisées par le serveur web. Recherchez des astuces à garder à l'esprit pendant le reste du test si vous pouvez identifier avec succès la technologie.
- Y a-t-il une vulnérabilité connue de la version de la technologie ?
- Utilisez-vous une technologie bien connue ? Une astuce utile pour extraire plus d'informations ?
- Y a-t-il un scanner spécialisé à exécuter (comme wpscan) ?
- Lancez des scanners à usage général. Vous ne savez jamais s'ils vont trouver quelque chose ou s'ils vont trouver des informations intéressantes.
- Commencez par les vérifications initiales : robots, sitemap, erreur 404 et scan SSL/TLS (si HTTPS).
- Commencez à spider la page web : Il est temps de trouver tous les fichiers, dossiers et paramètres utilisés. Vérifiez également les découvertes spéciales.
- Notez qu'à chaque fois qu'un nouveau répertoire est découvert lors du brute-forcing ou du spidering, il doit être spideré.
- Brute-Forcing de répertoire : Essayez de brute forcer tous les dossiers découverts à la recherche de nouveaux fichiers et répertoires.
- Notez qu'à chaque fois qu'un nouveau répertoire est découvert lors du brute-forcing ou du spidering, il doit être brute-forcé.
- Vérification des sauvegardes : Testez si vous pouvez trouver des sauvegardes de fichiers découverts en ajoutant des extensions de sauvegarde courantes.
- Paramètres de Brute-Force : Essayez de trouver des paramètres cachés.
- Une fois que vous avez identifié tous les endpoints possibles acceptant l'entrée utilisateur, vérifiez tous les types de vulnérabilités y afférant.
- Suivez cette liste de contrôle
Version du serveur (Vulnérable ?)
Identifier
Vérifiez s'il existe des vulnérabilités connues pour la version du serveur qui fonctionne.
Les en-têtes HTTP et les cookies de la réponse pourraient être très utiles pour identifier les technologies et/ou la version utilisée. Un scan Nmap peut identifier la version du serveur, mais il pourrait également être utile d'utiliser les outils whatweb, webtech ou https://builtwith.com/:
whatweb -a 1 <URL> #Stealthy
whatweb -a 3 <URL> #Aggresive
webtech -u <URL>
webanalyze -host https://google.com -crawl 2
Search for vulnerabilités de l'application web version
Vérifiez si un WAF est présent
- https://github.com/EnableSecurity/wafw00f
- https://github.com/Ekultek/WhatWaf.git
- https://nmap.org/nsedoc/scripts/http-waf-detect.html
Astuces technologiques web
Quelques astuces pour trouver des vulnérabilités dans différentes technologies bien connues utilisées :
- AEM - Adobe Experience Cloud
- Apache
- Artifactory
- Buckets
- CGI
- Drupal
- Flask
- Git
- Golang
- GraphQL
- H2 - base de données SQL Java
- Astuces IIS
- JBOSS
- Jenkins
- Jira
- Joomla
- JSP
- Laravel
- Moodle
- Nginx
- PHP (php a beaucoup d'astuces intéressantes qui pourraient être exploitées)
- Python
- Spring Actuators
- Symphony
- Tomcat
- VMWare
- Web API Pentesting
- WebDav
- Werkzeug
- Wordpress
- Electron Desktop (XSS à RCE)
Tenez compte du fait que le même domaine peut utiliser différentes technologies sur différents ports, dossiers et sous-domaines.
Si l'application web utilise une tech/platform bien connue listée précédemment ou toute autre, n'oubliez pas de chercher sur Internet de nouvelles astuces (et faites-le moi savoir !).
Revue de code source
Si le code source de l'application est disponible sur github, en plus de réaliser par vous-même un test en boîte blanche de l'application, il y a certaines informations qui pourraient être utiles pour le test en boîte noire actuel :
- Y a-t-il un Change-log ou Readme ou Version fichier ou quoi que ce soit avec des informations de version accessibles via le web ?
- Comment et où sont sauvegardées les identifiants ? Y a-t-il un fichier (accessible ?) avec des identifiants (noms d'utilisateur ou mots de passe) ?
- Les mots de passe sont-ils en texte clair, chiffrés ou quel algorithme de hachage est utilisé ?
- Utilise-t-il une clé maîtresse pour chiffrer quelque chose ? Quel algorithme est utilisé ?
- Pouvez-vous accéder à l'un de ces fichiers en exploitant une vulnérabilité ?
- Y a-t-il des informations intéressantes dans le github (problèmes résolus et non résolus) ? Ou dans l'historique des commits (peut-être un mot de passe introduit dans un ancien commit) ?
{% content-ref url="code-review-tools.md" %} code-review-tools.md {% endcontent-ref %}
Scanners automatiques
Scanners automatiques à usage général
nikto -h <URL>
whatweb -a 4 <URL>
wapiti -u <URL>
W3af
zaproxy #You can use an API
nuclei -ut && nuclei -target <URL>
# https://github.com/ignis-sec/puff (client side vulns fuzzer)
node puff.js -w ./wordlist-examples/xss.txt -u "http://www.xssgame.com/f/m4KKGHi2rVUN/?query=FUZZ"
Scanners CMS
Si un CMS est utilisé, n'oubliez pas de lancer un scanner, peut-être que quelque chose de juteux sera trouvé :
Clusterd: JBoss, ColdFusion, WebLogic, Tomcat, Railo, Axis2, Glassfish
CMSScan: WordPress, Drupal, Joomla, vBulletin sites pour des problèmes de sécurité. (GUI)
VulnX: Joomla, Wordpress, Drupal, PrestaShop, Opencart
CMSMap: (W)ordpress, (J)oomla, (D)rupal ou (M)oodle
droopscan: Drupal, Joomla, Moodle, Silverstripe, Wordpress
cmsmap [-f W] -F -d <URL>
wpscan --force update -e --url <URL>
joomscan --ec -u <URL>
joomlavs.rb #https://github.com/rastating/joomlavs
À ce stade, vous devriez déjà avoir des informations sur le serveur web utilisé par le client (si des données sont fournies) et quelques astuces à garder à l'esprit pendant le test. Si vous avez de la chance, vous avez même trouvé un CMS et exécuté un scanner.
Découverte d'application web étape par étape
À partir de ce point, nous allons commencer à interagir avec l'application web.
Vérifications initiales
Pages par défaut avec des informations intéressantes :
- /robots.txt
- /sitemap.xml
- /crossdomain.xml
- /clientaccesspolicy.xml
- /.well-known/
- Vérifiez également les commentaires dans les pages principales et secondaires.
Forcer des erreurs
Les serveurs web peuvent se comporter de manière inattendue lorsque des données étranges leur sont envoyées. Cela peut ouvrir des vulnérabilités ou divulguer des informations sensibles.
- Accédez à des pages factices comme /whatever_fake.php (.aspx, .html, etc.)
- Ajoutez "[]", "]]" et "[[" dans les valeurs de cookie et les valeurs de paramètre pour créer des erreurs
- Générez une erreur en donnant une entrée comme
/~randomthing/%s
à la fin de l'URL - Essayez différents verbes HTTP comme PATCH, DEBUG ou incorrects comme FAKE
Vérifiez si vous pouvez télécharger des fichiers (verbe PUT, WebDav)
Si vous constatez que WebDav est activé mais que vous n'avez pas suffisamment de permissions pour télécharger des fichiers dans le dossier racine, essayez de :
- Brute Forcer les identifiants
- Télécharger des fichiers via WebDav dans le reste des dossiers trouvés à l'intérieur de la page web. Vous pourriez avoir des permissions pour télécharger des fichiers dans d'autres dossiers.
Vulnérabilités SSL/TLS
- Si l'application n'oblige pas l'utilisateur à utiliser HTTPS à un moment donné, alors elle est vulnérable au MitM
- Si l'application envoie des données sensibles (mots de passe) en utilisant HTTP. Alors c'est une vulnérabilité élevée.
Utilisez testssl.sh pour vérifier les vulnérabilités (dans les programmes de Bug Bounty, ces types de vulnérabilités ne seront probablement pas acceptés) et utilisez a2sv pour re-vérifier les vulnérabilités :
./testssl.sh [--htmlfile] 10.10.10.10:443
#Use the --htmlfile to save the output inside an htmlfile also
# You can also use other tools, by testssl.sh at this momment is the best one (I think)
sslscan <host:port>
sslyze --regular <ip:port>
Information sur les vulnérabilités SSL/TLS :
- https://www.gracefulsecurity.com/tls-ssl-vulnerabilities/
- https://www.acunetix.com/blog/articles/tls-vulnerabilities-attacks-final-part/
Spidering
Lancez une sorte de spider à l'intérieur du web. L'objectif du spider est de trouver autant de chemins que possible à partir de l'application testée. Par conséquent, le crawling web et les sources externes doivent être utilisés pour trouver autant de chemins valides que possible.
- gospider (go) : Spider HTML, LinkFinder dans les fichiers JS et sources externes (Archive.org, CommonCrawl.org, VirusTotal.com, AlienVault.com).
- hakrawler (go) : Spider HML, avec LinkFinder pour les fichiers JS et Archive.org comme source externe.
- dirhunt (python) : Spider HTML, indique également les "fichiers juteux".
- evine (go) : Spider HTML CLI interactif. Il recherche également dans Archive.org.
- meg (go) : Cet outil n'est pas un spider mais peut être utile. Vous pouvez simplement indiquer un fichier avec des hôtes et un fichier avec des chemins, et meg récupérera chaque chemin sur chaque hôte et enregistrera la réponse.
- urlgrab (go) : Spider HTML avec des capacités de rendu JS. Cependant, il semble qu'il ne soit pas maintenu, la version précompilée est ancienne et le code actuel ne compile pas.
- gau (go) : Spider HTML qui utilise des fournisseurs externes (wayback, otx, commoncrawl).
- ParamSpider : Ce script trouvera des URL avec des paramètres et les listera.
- galer (go) : Spider HTML avec des capacités de rendu JS.
- LinkFinder (python) : Spider HTML, avec des capacités de beautification JS capable de rechercher de nouveaux chemins dans les fichiers JS. Il pourrait également être intéressant de jeter un œil à JSScanner, qui est un wrapper de LinkFinder.
- goLinkFinder (go) : Pour extraire des points de terminaison à la fois dans le code source HTML et dans les fichiers JavaScript intégrés. Utile pour les chasseurs de bugs, les équipes rouges, les ninjas de la sécurité informatique.
- JSParser (python2.7) : Un script python 2.7 utilisant Tornado et JSBeautifier pour analyser les URL relatives à partir des fichiers JavaScript. Utile pour découvrir facilement les requêtes AJAX. Semble ne pas être maintenu.
- relative-url-extractor (ruby) : Étant donné un fichier (HTML), il extraira les URL en utilisant une expression régulière astucieuse pour trouver et extraire les URL relatives à partir de fichiers laids (minifiés).
- JSFScan (bash, plusieurs outils) : Rassembler des informations intéressantes à partir de fichiers JS en utilisant plusieurs outils.
- subjs (go) : Trouver des fichiers JS.
- page-fetch (go) : Charger une page dans un navigateur sans tête et imprimer toutes les URL chargées pour charger la page.
- Feroxbuster (rust) : Outil de découverte de contenu mélangeant plusieurs options des outils précédents.
- Javascript Parsing : Une extension Burp pour trouver des chemins et des paramètres dans les fichiers JS.
- Sourcemapper : Un outil qui, étant donné l'URL .js.map, vous obtiendra le code JS beautifié.
- xnLinkFinder : Cet outil est utilisé pour découvrir des points de terminaison pour une cible donnée.
- waymore: Découvrir des liens à partir de la machine Wayback (téléchargeant également les réponses dans le Wayback et cherchant plus de liens).
- HTTPLoot (go) : Explorer (même en remplissant des formulaires) et trouver des informations sensibles en utilisant des regex spécifiques.
- SpiderSuite : Spider Suite est un crawler/spider web GUI multi-fonction avancé conçu pour les professionnels de la cybersécurité.
- jsluice (go) : C'est un package Go et outil en ligne de commande pour extraire des URL, des chemins, des secrets et d'autres données intéressantes à partir du code source JavaScript.
- ParaForge : ParaForge est une simple extension Burp Suite pour extraire les paramètres et les points de terminaison de la requête afin de créer une liste de mots personnalisée pour le fuzzing et l'énumération.
- katana (go) : Outil génial pour cela.
- Crawley (go) : Imprime chaque lien qu'il est capable de trouver.
Brute Force des répertoires et fichiers
Commencez le brute-forcing à partir du dossier racine et assurez-vous de brute-forcer tous les répertoires trouvés en utilisant cette méthode et tous les répertoires découverts par le Spidering (vous pouvez faire ce brute-forcing récursivement et en ajoutant au début de la liste de mots utilisée les noms des répertoires trouvés).
Outils :
- Dirb / Dirbuster - Inclus dans Kali, ancien (et lent) mais fonctionnel. Permet les certificats auto-signés et la recherche récursive. Trop lent par rapport aux autres options.
- Dirsearch (python): Il ne permet pas les certificats auto-signés mais permet la recherche récursive.
- Gobuster (go) : Il permet les certificats auto-signés, il n'a pas de recherche récursive.
- Feroxbuster - Rapide, prend en charge la recherche récursive.
- wfuzz
wfuzz -w /usr/share/seclists/Discovery/Web-Content/raft-medium-directories.txt https://domain.com/api/FUZZ
- ffuf - Rapide :
ffuf -c -w /usr/share/wordlists/dirb/big.txt -u http://10.10.10.10/FUZZ
- uro (python) : Ce n'est pas un spider mais un outil qui, étant donné la liste des URL trouvées, supprimera les URL "dupliquées".
- Scavenger : Extension Burp pour créer une liste de répertoires à partir de l'historique Burp de différentes pages.
- TrashCompactor : Supprime les URL avec des fonctionnalités dupliquées (basées sur les imports js).
- Chamaleon : Il utilise wapalyzer pour détecter les technologies utilisées et sélectionner les listes de mots à utiliser.
Dictionnaires recommandés :
- https://github.com/carlospolop/Auto_Wordlists/blob/main/wordlists/bf_directories.txt
- Dictionnaire inclus dans Dirsearch
- http://gist.github.com/jhaddix/b80ea67d85c13206125806f0828f4d10
- Listes de mots Assetnote
- https://github.com/danielmiessler/SecLists/tree/master/Discovery/Web-Content
- raft-large-directories-lowercase.txt
- directory-list-2.3-medium.txt
- RobotsDisallowed/top10000.txt
- https://github.com/random-robbie/bruteforce-lists
- https://github.com/google/fuzzing/tree/master/dictionaries
- https://github.com/six2dez/OneListForAll
- https://github.com/random-robbie/bruteforce-lists
- https://github.com/ayoubfathi/leaky-paths
- /usr/share/wordlists/dirb/common.txt
- /usr/share/wordlists/dirb/big.txt
- /usr/share/wordlists/dirbuster/directory-list-2.3-medium.txt
Notez que chaque fois qu'un nouveau répertoire est découvert lors du brute-forcing ou du spidering, il doit être brute-forcé.
Que vérifier sur chaque fichier trouvé
- Broken link checker : Trouver des liens brisés à l'intérieur des HTML qui peuvent être sujets à des prises de contrôle.
- Sauvegardes de fichiers : Une fois que vous avez trouvé tous les fichiers, recherchez des sauvegardes de tous les fichiers exécutables (".php", ".aspx"...). Les variations courantes pour nommer une sauvegarde sont : file.ext~, #file.ext#, ~file.ext, file.ext.bak, file.ext.tmp, file.ext.old, file.bak, file.tmp et file.old. Vous pouvez également utiliser l'outil bfac ou backup-gen.
- Découvrir de nouveaux paramètres : Vous pouvez utiliser des outils comme Arjun, parameth, x8 et Param Miner pour découvrir des paramètres cachés. Si vous le pouvez, vous pourriez essayer de rechercher des paramètres cachés sur chaque fichier web exécutable.
- Arjun toutes les listes de mots par défaut : https://github.com/s0md3v/Arjun/tree/master/arjun/db
- Param-miner “params” : https://github.com/PortSwigger/param-miner/blob/master/resources/params
- Assetnote “parameters_top_1m”: https://wordlists.assetnote.io/
- nullenc0de “params.txt”: https://gist.github.com/nullenc0de/9cb36260207924f8e1787279a05eb773
- Commentaires : Vérifiez les commentaires de tous les fichiers, vous pouvez trouver des identifiants ou des fonctionnalités cachées.
- Si vous jouez à un CTF, un "truc" "commun" est de cacher des informations à l'intérieur des commentaires à la droite de la page (en utilisant des centaines d'espaces pour que vous ne voyiez pas les données si vous ouvrez le code source avec le navigateur). Une autre possibilité est d'utiliser plusieurs nouvelles lignes et de cacher des informations dans un commentaire en bas de la page web.
- Clés API : Si vous trouvez une clé API, il existe un guide qui indique comment utiliser les clés API de différentes plateformes : keyhacks, zile, truffleHog, SecretFinder, RegHex, DumpsterDive, EarlyBird.
- Clés API Google : Si vous trouvez une clé API ressemblant à AIzaSyA-qLheq6xjDiEIRisP_ujUseYLQCHUjik, vous pouvez utiliser le projet gmapapiscanner pour vérifier quelles API la clé peut accéder.
- S3 Buckets : Lors du spidering, vérifiez si un sous-domaine ou un lien est lié à un bucket S3. Dans ce cas, vérifiez les permissions du bucket.
Découvertes spéciales
Lors de l'exécution du spidering et du brute-forcing, vous pourriez trouver des choses intéressantes que vous devez noter.
Fichiers intéressants
- Recherchez des liens vers d'autres fichiers à l'intérieur des fichiers CSS.
- Si vous trouvez un fichier .git, certaines informations peuvent être extraites.
- Si vous trouvez un .env, des informations telles que des clés API, des mots de passe de bases de données et d'autres informations peuvent être trouvées.
- Si vous trouvez des points de terminaison API, vous devez également les tester. Ce ne sont pas des fichiers, mais ils "ressembleront probablement" à eux.
- Fichiers JS : Dans la section spidering, plusieurs outils capables d'extraire des chemins à partir de fichiers JS ont été mentionnés. Il serait également intéressant de surveiller chaque fichier JS trouvé, car dans certaines occasions, un changement peut indiquer qu'une vulnérabilité potentielle a été introduite dans le code. Vous pourriez utiliser par exemple JSMon.
- Vous devriez également vérifier les fichiers JS découverts avec RetireJS ou JSHole pour voir s'ils sont vulnérables.
- Déobfuscateur et unpacker Javascript : https://lelinhtinh.github.io/de4js/, https://www.dcode.fr/javascript-unobfuscator.
- Beautificateur Javascript : http://jsbeautifier.org/, http://jsnice.org/.
- Déobfuscation JsFuck (javascript avec des caractères : "[]!+" https://ooze.ninja/javascript/poisonjs/).
- TrainFuck:
+72.+29.+7..+3.-67.-12.+55.+24.+3.-6.-8.-67.-23.
- Dans plusieurs occasions, vous aurez besoin de comprendre les expressions régulières utilisées, cela sera utile : https://regex101.com/.
- Vous pourriez également surveiller les fichiers où des formulaires ont été détectés, car un changement dans le paramètre ou l'apparition d'un nouveau formulaire peut indiquer une nouvelle fonctionnalité potentiellement vulnérable.
403 Interdit/Authentification de base/401 Non autorisé (bypass)
{% content-ref url="403-and-401-bypasses.md" %} 403-and-401-bypasses.md {% endcontent-ref %}
502 Erreur de proxy
Si une page répond avec ce code, c'est probablement un proxy mal configuré. Si vous envoyez une requête HTTP comme : GET https://google.com HTTP/1.1
(avec l'en-tête d'hôte et d'autres en-têtes communs), le proxy essaiera d'accéder à google.com et vous aurez trouvé un SSRF.
Authentification NTLM - Divulgation d'informations
Si le serveur en cours d'exécution demande une authentification est Windows ou si vous trouvez une connexion demandant vos identifiants (et demandant un nom de domaine), vous pouvez provoquer une divulgation d'informations.
Envoyez l'en-tête : “Authorization: NTLM TlRMTVNTUAABAAAAB4IIAAAAAAAAAAAAAAAAAAAAAAA=”
et en raison de la façon dont l'authentification NTLM fonctionne, le serveur répondra avec des informations internes (version IIS, version Windows...) à l'intérieur de l'en-tête "WWW-Authenticate".
Vous pouvez automatiser cela en utilisant le plugin nmap "http-ntlm-info.nse".
Redirection HTTP (CTF)
Il est possible de mettre du contenu à l'intérieur d'une Redirection. Ce contenu ne sera pas affiché à l'utilisateur (car le navigateur exécutera la redirection) mais quelque chose pourrait être caché là-dedans.
Vérification des vulnérabilités Web
Maintenant qu'une énumération complète de l'application web a été effectuée, il est temps de vérifier de nombreuses vulnérabilités possibles. Vous pouvez trouver la liste de contrôle ici :
{% content-ref url="../../pentesting-web/web-vulnerabilities-methodology.md" %} web-vulnerabilities-methodology.md {% endcontent-ref %}
Trouvez plus d'infos sur les vulnérabilités web dans :
- https://six2dez.gitbook.io/pentest-book/others/web-checklist
- https://kennel209.gitbooks.io/owasp-testing-guide-v4/content/en/web_application_security_testing/configuration_and_deployment_management_testing.html
- https://owasp-skf.gitbook.io/asvs-write-ups/kbid-111-client-side-template-injection
Surveiller les pages pour les changements
Vous pouvez utiliser des outils tels que https://github.com/dgtlmoon/changedetection.io pour surveiller les pages pour des modifications qui pourraient insérer des vulnérabilités.
Si vous êtes intéressé par une carrière de hacking et que vous souhaitez hacker l'inhackable - nous recrutons ! (polonais courant écrit et parlé requis).
{% embed url="https://www.stmcyber.com/careers" %}
Commandes Automatiques HackTricks
Protocol_Name: Web #Protocol Abbreviation if there is one.
Port_Number: 80,443 #Comma separated if there is more than one.
Protocol_Description: Web #Protocol Abbreviation Spelled out
Entry_1:
Name: Notes
Description: Notes for Web
Note: |
https://book.hacktricks.xyz/pentesting/pentesting-web
Entry_2:
Name: Quick Web Scan
Description: Nikto and GoBuster
Command: nikto -host {Web_Proto}://{IP}:{Web_Port} &&&& gobuster dir -w {Small_Dirlist} -u {Web_Proto}://{IP}:{Web_Port} && gobuster dir -w {Big_Dirlist} -u {Web_Proto}://{IP}:{Web_Port}
Entry_3:
Name: Nikto
Description: Basic Site Info via Nikto
Command: nikto -host {Web_Proto}://{IP}:{Web_Port}
Entry_4:
Name: WhatWeb
Description: General purpose auto scanner
Command: whatweb -a 4 {IP}
Entry_5:
Name: Directory Brute Force Non-Recursive
Description: Non-Recursive Directory Brute Force
Command: gobuster dir -w {Big_Dirlist} -u {Web_Proto}://{IP}:{Web_Port}
Entry_6:
Name: Directory Brute Force Recursive
Description: Recursive Directory Brute Force
Command: python3 {Tool_Dir}dirsearch/dirsearch.py -w {Small_Dirlist} -e php,exe,sh,py,html,pl -f -t 20 -u {Web_Proto}://{IP}:{Web_Port} -r 10
Entry_7:
Name: Directory Brute Force CGI
Description: Common Gateway Interface Brute Force
Command: gobuster dir -u {Web_Proto}://{IP}:{Web_Port}/ -w /usr/share/seclists/Discovery/Web-Content/CGIs.txt -s 200
Entry_8:
Name: Nmap Web Vuln Scan
Description: Tailored Nmap Scan for web Vulnerabilities
Command: nmap -vv --reason -Pn -sV -p {Web_Port} --script=`banner,(http* or ssl*) and not (brute or broadcast or dos or external or http-slowloris* or fuzzer)` {IP}
Entry_9:
Name: Drupal
Description: Drupal Enumeration Notes
Note: |
git clone https://github.com/immunIT/drupwn.git for low hanging fruit and git clone https://github.com/droope/droopescan.git for deeper enumeration
Entry_10:
Name: WordPress
Description: WordPress Enumeration with WPScan
Command: |
?What is the location of the wp-login.php? Example: /Yeet/cannon/wp-login.php
wpscan --url {Web_Proto}://{IP}{1} --enumerate ap,at,cb,dbe && wpscan --url {Web_Proto}://{IP}{1} --enumerate u,tt,t,vp --passwords {Big_Passwordlist} -e
Entry_11:
Name: WordPress Hydra Brute Force
Description: Need User (admin is default)
Command: hydra -l admin -P {Big_Passwordlist} {IP} -V http-form-post '/wp-login.php:log=^USER^&pwd=^PASS^&wp-submit=Log In&testcookie=1:S=Location'
Entry_12:
Name: Ffuf Vhost
Description: Simple Scan with Ffuf for discovering additional vhosts
Command: ffuf -w {Subdomain_List}:FUZZ -u {Web_Proto}://{Domain_Name} -H "Host:FUZZ.{Domain_Name}" -c -mc all {Ffuf_Filters}
{% hint style="success" %}
Apprenez et pratiquez le Hacking AWS :HackTricks Formation Expert Red Team AWS (ARTE)
Apprenez et pratiquez le Hacking GCP : HackTricks Formation Expert Red Team GCP (GRTE)
Soutenir HackTricks
- Consultez les plans d'abonnement!
- Rejoignez le 💬 groupe Discord ou le groupe telegram ou suivez nous sur Twitter 🐦 @hacktricks_live.
- Partagez des astuces de hacking en soumettant des PRs aux HackTricks et HackTricks Cloud dépôts github.