80,443 - Pentesting Web Methodology
{{#include ../../banners/hacktricks-training.md}}
Podstawowe informacje
Usługa webowa jest najbardziej powszechną i rozległą usługą, a istnieje wiele różnych typów podatności.
Domyślny port: 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 Wskazówki
{{#ref}} web-api-pentesting.md {{#endref}}
Podsumowanie metodologii
W tej metodologii zakładamy, że będziesz atakować jedną domenę (lub subdomenę) i tylko ją. Zastosuj tę metodologię do każdej odkrytej domeny, subdomeny lub IP z nieokreślonym serwerem WWW w zakresie.
- Start by identifying the technologies used by the web server. Look for tricks to keep in mind during the rest of the test if you can successfully identify the tech.
- Any known vulnerability of the version of the technology?
- Using any well known tech? Any useful trick to extract more information?
- Any specialised scanner to run (like wpscan)?
- Launch general purposes scanners. You never know if they are going to find something or if the are going to find some interesting information.
- Start with the initial checks: robots, sitemap, 404 error and SSL/TLS scan (if HTTPS).
- Start spidering the web page: It's time to find all the possible files, folders and parameters being used. Also, check for special findings.
- Note that anytime a new directory is discovered during brute-forcing or spidering, it should be spidered.
- Directory Brute-Forcing: Try to brute force all the discovered folders searching for new files and directories.
- Note that anytime a new directory is discovered during brute-forcing or spidering, it should be Brute-Forced.
- Backups checking: Test if you can find backups of discovered files appending common backup extensions.
- Brute-Force parameters: Try to find hidden parameters.
- Once you have identified all the possible endpoints accepting user input, check for all kind of vulnerabilities related to it.
- Postępuj zgodnie z tą listą kontrolną
Wersja serwera (Podatna?)
Identyfikacja
Sprawdź, czy istnieją znane podatności dla uruchomionej wersji serwera.
Nagłówki HTTP i cookies odpowiedzi mogą być bardzo pomocne przy identyfikacji używanych technologii i/lub wersji. Nmap scan może zidentyfikować wersję serwera, ale przydatne mogą być także narzędzia whatweb, webtech or https://builtwith.com/:
whatweb -a 1 <URL> #Stealthy
whatweb -a 3 <URL> #Aggresive
webtech -u <URL>
webanalyze -host https://google.com -crawl 2
Szukaj dla podatności aplikacji webowej wersji
Sprawdź czy występuje WAF
- https://github.com/EnableSecurity/wafw00f
- https://github.com/Ekultek/WhatWaf.git
- https://nmap.org/nsedoc/scripts/http-waf-detect.html
Web tech tricks
Kilka sztuczek do znajdowania podatności w różnych dobrze znanych technologiach używanych:
- AEM - Adobe Experience Cloud
- Apache
- Artifactory
- Buckets
- CGI
- Drupal
- Flask
- Git
- Golang
- GraphQL
- H2 - Java SQL database
- ISPConfig
- IIS tricks
- Microsoft SharePoint
- JBOSS
- Jenkins
- Jira
- Joomla
- JSP
- Laravel
- Moodle
- Nginx
- PHP (php has a lot of interesting tricks that could be exploited)
- Python
- Spring Actuators
- Symphony
- Tomcat
- VMWare
- Web API Pentesting
- WebDav
- Werkzeug
- Wordpress
- Electron Desktop (XSS to RCE)
- Sitecore
Weź pod uwagę, że ta sama domena może używać różnych technologii na różnych portach, folderach i subdomenach.
Jeśli aplikacja webowa używa którejkolwiek z wcześniej wymienionych dobrze znanych technologii/platform lub jakiejkolwiek innej, nie zapomnij wyszukać w Internecie nowych trików (i daj mi znać!).
Source Code Review
Jeśli kod źródłowy aplikacji jest dostępny na github, oprócz przeprowadzenia przez Ciebie White box test aplikacji istnieją pewne informacje, które mogą być przydatne dla bieżącego Black-Box testing:
- Czy istnieje plik Change-log lub Readme lub Version lub coś z informacją o wersji dostępną przez web?
- Jak i gdzie są zapisywane credentials? Czy istnieje jakiś (dostępny?) file z credentials (usernames or passwords)?
- Czy passwords są w plain text, encrypted czy jaki algorytm haszujący jest używany?
- Czy używa jakiegokolwiek master key do szyfrowania czegoś? Jaki algorytm jest używany?
- Czy możesz uzyskać dostęp do któregokolwiek z tych plików wykorzystując jakąś podatność?
- Czy są jakieś interesujące informacje na github (rozwiązane i nierozwiązane) issues? Lub w commit history (może jakieś hasło wprowadzone w starym commicie)?
{{#ref}} code-review-tools.md {{#endref}}
Automatic scanners
Automatyczne skanery ogólnego przeznaczenia
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"
Skanery CMS
Jeśli używany jest CMS, nie zapomnij uruchomić skanera, może znajdzie się coś ciekawego:
Clusterd: JBoss, ColdFusion, WebLogic, Tomcat, Railo, Axis2, Glassfish
CMSScan: WordPress, Drupal, Joomla, vBulletin witryny pod kątem problemów bezpieczeństwa. (GUI)
VulnX: Joomla, Wordpress, Drupal, PrestaShop, Opencart
CMSMap: (W)ordpress, (J)oomla, (D)rupal lub (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
W tym momencie powinieneś mieć już pewne informacje o serwerze webowym używanym przez klienta (jeśli podano jakieś dane) oraz kilka sztuczek do zapamiętania podczas testu. Jeśli masz szczęście, znalazłeś nawet CMS i uruchomiłeś jakiś skaner.
Krok po kroku — Odkrywanie aplikacji webowej
Od tego momentu zaczynamy wchodzić w interakcję z aplikacją webową.
Wstępne sprawdzenia
Domyślne strony z przydatnymi informacjami:
- /robots.txt
- /sitemap.xml
- /crossdomain.xml
- /clientaccesspolicy.xml
- /.well-known/
- Sprawdź także komentarze na stronach głównych i pomocniczych.
Wymuszanie błędów
Serwery WWW mogą zachowywać się nieoczekiwanie, gdy wysyłane są do nich nietypowe dane. Może to otworzyć vulnerabilities lub spowodować ujawnienie wrażliwych informacji.
- Odwiedź fake pages takie jak /whatever_fake.php (.aspx,.html,.etc)
- Add "[]", "]]", and "[[" w cookie values i wartościach parameter aby wywołać błędy
- Wygeneruj błąd, podając jako wejście
/~randomthing/%sna końcu URL - Spróbuj różnych HTTP Verbs jak PATCH, DEBUG lub nieprawidłowych, np. FAKE
Sprawdź, czy możesz przesyłać pliki (PUT verb, WebDav)
Jeśli odkryjesz, że WebDav jest enabled, ale nie masz wystarczających uprawnień do uploading files w root folder, spróbuj:
- Brute Force credentials
- Upload files via WebDav do reszty found folders w obrębie strony. Możliwe, że masz uprawnienia do uploadowania plików w innych folderach.
SSL/TLS vulnerabilites
- Jeśli aplikacja isn't forcing the user of HTTPS w żadnej części, to jest vulnerable to MitM
- Jeśli aplikacja sending sensitive data (passwords) using HTTP — to jest poważne vulnerability
Użyj testssl.sh aby sprawdzić vulnerabilities (W programach Bug Bounty prawdopodobnie tego typu vulnerabilities nie będą akceptowane) i użyj a2sv to aby ponownie zweryfikować vulnerabilities:
./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>
Informacje o podatnościach SSL/TLS:
- https://www.gracefulsecurity.com/tls-ssl-vulnerabilities/
- https://www.acunetix.com/blog/articles/tls-vulnerabilities-attacks-final-part/
Spidering
Uruchom jakiś rodzaj spider wewnątrz aplikacji webowej. Celem spidera jest znaleźć jak najwięcej ścieżek w testowanej aplikacji. Dlatego crawling i zewnętrzne źródła powinny być użyte, aby odnaleźć jak najwięcej prawidłowych ścieżek.
- gospider (go): HTML spider, LinkFinder w plikach JS i zewnętrzne źródła (Archive.org, CommonCrawl.org, VirusTotal.com).
- hakrawler (go): HML spider, z LinkFinder dla plików JS i Archive.org jako zewnętrzne źródło.
- dirhunt (python): HTML spider, także wskazuje "juicy files".
- evine (go): Interaktywny CLI HTML spider. Również przeszukuje Archive.org
- meg (go): To narzędzie nie jest spiderem, ale może być przydatne. Możesz podać plik z hostami i plik ze ścieżkami, a meg pobierze każdą ścieżkę na każdym hoście i zapisze odpowiedź.
- urlgrab (go): HTML spider z możliwością renderowania JS. Wygląda jednak na nieutrzymywane, prekompilowana wersja jest stara, a aktualny kod nie kompiluje się.
- gau (go): HTML spider, który używa zewnętrznych providerów (wayback, otx, commoncrawl)
- ParamSpider: Ten skrypt znajdzie URL-e z parametrami i je wypisze.
- galer (go): HTML spider z możliwością renderowania JS.
- LinkFinder (python): HTML spider, z możliwością beautify JS, potrafi wyszukać nowe ścieżki w plikach JS. Warto też rzucić okiem na JSScanner, który jest wrapperem LinkFinder.
- goLinkFinder (go): Do ekstrakcji endpointów w źródle HTML i osadzonych plikach javascript. Przydatne dla bug hunterów, red teamów, infosec ninja.
- JSParser (python2.7): Skrypt w python 2.7 używający Tornado i JSBeautifier do parsowania względnych URL-i z plików JavaScript. Przydatny do łatwego odkrywania żądań AJAX. Wygląda na nieutrzymywany.
- relative-url-extractor (ruby): Dając plik (HTML) wyciąga z niego URL-e używając sprytnych regexpów do znalezienia i ekstrakcji względnych URL-i z "brzydkich" (minify) plików.
- JSFScan (bash, several tools): Zbiera interesujące informacje z plików JS używając kilku narzędzi.
- subjs (go): Znajduje pliki JS.
- page-fetch (go): Ładuje stronę w headless browser i wypisuje wszystkie URL-e załadowane podczas ładowania strony.
- Feroxbuster (rust): Narzędzie do discovery treści łączące kilka funkcji poprzednich narzędzi.
- Javascript Parsing: Rozszerzenie Burp do znajdowania ścieżek i parametrów w plikach JS.
- Sourcemapper: Narzędzie, które podając URL .js.map zwróci zbeautyfikowany kod JS.
- xnLinkFinder: Narzędzie do odkrywania endpointów dla danego celu.
- waymore: Odkrywa linki z wayback machine (także pobierając odpowiedzi w wayback i szukając kolejnych linków).
- HTTPLoot (go): Crawl (nawet przez wypełnianie formularzy) i także znajdowanie wrażliwych informacji przy użyciu specyficznych regexów.
- SpiderSuite: Spider Suite to zaawansowany wielofunkcyjny GUI web security Crawler/Spider zaprojektowany dla profesjonalistów cyberbezpieczeństwa.
- jsluice (go): Pakiet Go i command-line tool do ekstrakcji URL-i, ścieżek, sekretów i innych interesujących danych z kodu źródłowego JavaScript.
- ParaForge: ParaForge to proste Burp Suite extension do ekstrakcji parametrów i endpointów z requestów w celu stworzenia custom wordlist do fuzzingu i enumeracji.
- katana (go): Świetne narzędzie do tego.
- Crawley (go): Wypisuje każdy link, który jest w stanie znaleźć.
Brute Force katalogi i pliki
Rozpocznij brute-forcing od katalogu głównego i upewnij się, że brute-forcujesz wszystkie znalezione katalogi używając tej metody oraz wszystkich katalogów odkrytych przez Spidering (możesz wykonywać to rekursywnie i doklejać na początku użytej wordlisty nazwy znalezionych katalogów).
Narzędzia:
- Dirb / Dirbuster - Dołączone do Kali, stare (i wolne) ale funkcjonalne. Pozwalają na certyfikaty z auto-podpisem i wyszukiwanie rekurencyjne. Zbyt wolne w porównaniu z innymi opcjami.
- Dirsearch (python): Nie pozwala na certyfikaty auto-podpisane, ale wspiera wyszukiwanie rekurencyjne.
- Gobuster (go): Pozwala na certyfikaty auto-podpisane, nie ma jednak wyszukiwania rekurencyjnego.
- Feroxbuster - Fast, supports recursive search.
- wfuzz
wfuzz -w /usr/share/seclists/Discovery/Web-Content/raft-medium-directories.txt https://domain.com/api/FUZZ - ffuf - Fast:
ffuf -c -w /usr/share/wordlists/dirb/big.txt -u http://10.10.10.10/FUZZ - uro (python): To nie jest spider, ale narzędzie które biorąc listę znalezionych URL-i usuwa "zduplikowane" URL-e.
- Scavenger: Burp Extension do tworzenia listy katalogów z historii Burp dla różnych stron.
- TrashCompactor: Usuwa URL-e o zduplikowanej funkcjonalności (na podstawie importów js).
- Chamaleon: Używa Wappalyzer do wykrycia użytych technologii i dobrania odpowiednich wordlist.
Zalecane słowniki:
- https://github.com/carlospolop/Auto_Wordlists/blob/main/wordlists/bf_directories.txt
- Dirsearch included dictionary
- http://gist.github.com/jhaddix/b80ea67d85c13206125806f0828f4d10
- Assetnote wordlists
- 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
Zauważ, że za każdym razem gdy nowy katalog zostanie odkryty podczas brute-forcingu lub spideringu, powinien być Brute-Forced.
Co sprawdzić dla każdego znalezionego pliku
- Broken link checker: Znajdź broken linki w HTML-ach, które mogą być podatne na takeovery.
- File Backups: Gdy znajdziesz wszystkie pliki, szukaj backupów wszystkich plików wykonywalnych (".php", ".aspx"...). Typowe warianty nazw backupu to: file.ext~, #file.ext#, ~file.ext, file.ext.bak, file.ext.tmp, file.ext.old, file.bak, file.tmp i file.old. Możesz także użyć narzędzia bfac lub backup-gen.
- Discover new parameters: Możesz użyć narzędzi jak Arjun, parameth, x8 oraz Param Miner do wykrywania ukrytych parametrów. Jeśli możesz, spróbuj szukać ukrytych parametrów w każdym wykonywalnym pliku webowym.
- Arjun all default wordlists: 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
- Comments: Sprawdź komentarze we wszystkich plikach — możesz znaleźć credentials lub ukrytą funkcjonalność.
- Jeśli bierzesz udział w CTF, "powszechną" sztuczką jest ukrycie informacji w komentarzach po prawej stronie strony (używając setek spacji, żeby nie widzieć danych, jeśli otworzysz źródło w przeglądarce). Inną możliwością jest użycie wielu nowych linii i ukrycie informacji w komentarzu na dole strony.
- API keys: Jeśli znajdziesz jakikolwiek API key, istnieją projekty pokazujące jak używać kluczy z różnych platform: keyhacks, zile, truffleHog, SecretFinder, RegHex, DumpsterDive, EarlyBird
- Google API keys: Jeśli znajdziesz klucz API wyglądający jak AIzaSyA-qLheq6xjDiEIRisP_ujUseYLQCHUjik możesz użyć projektu gmapapiscanner aby sprawdzić, do których API klucz ma dostęp.
- S3 Buckets: Podczas spideringu sprawdź, czy jakikolwiek subdomain lub link jest powiązany z jakimś S3 bucket. W takim przypadku sprawdź uprawnienia bucketu.
Specjalne znaleziska
Podczas wykonywania spideringu i brute-forcingu możesz natrafić na interesujące rzeczy, na które trzeba zwrócić uwagę.
Interesujące pliki
- Szukaj linków do innych plików w CSS.
- Jeśli znajdziesz .git można wyciągnąć pewne informacje
- Jeśli znajdziesz .env możesz znaleźć informacje takie jak api keys, hasła do db i inne dane.
- Jeśli znajdziesz API endpoints powinieneś je także przetestować. To nie są pliki, ale prawdopodobnie będą "wyglądać" jak pliki.
- JS files: W sekcji spideringu wspomniano kilka narzędzi, które mogą ekstrahować ścieżki z plików JS. Warto także monitorować każdy znaleziony plik JS, ponieważ w niektórych przypadkach zmiana może wskazywać, że potencjalna podatność została wprowadzona do kodu. Możesz użyć na przykład JSMon.
- Powinieneś też sprawdzić odkryte pliki JS za pomocą RetireJS lub JSHole aby znaleźć czy są podatne.
- Javascript Deobfuscator and Unpacker: https://lelinhtinh.github.io/de4js/, https://www.dcode.fr/javascript-unobfuscator
- Javascript Beautifier: http://jsbeautifier.org/, http://jsnice.org/
- JsFuck deobfuscation (javascript with chars:"[]!+" https://enkhee-osiris.github.io/Decoder-JSFuck/)
- TrainFuck](https://github.com/taco-c/trainfuck):
+72.+29.+7..+3.-67.-12.+55.+24.+3.-6.-8.-67.-23. - W wielu przypadkach będziesz musiał zrozumieć wyrażenia regularne użyte w kodzie. Przydatne będą: https://regex101.com/ lub https://pythonium.net/regex
- Możesz także monitorować pliki, w których wykryto formularze, gdyż zmiana parametrów lub pojawienie się nowego formularza może wskazywać na potencjalnie nową podatną funkcjonalność.
403 Forbidden/Basic Authentication/401 Unauthorized (bypass)
{{#ref}} 403-and-401-bypasses.md {{#endref}}
502 Proxy Error
Jeśli jakaś strona odpowiada tym kodem, prawdopodobnie jest to źle skonfigurowany proxy. Jeśli wyślesz żądanie HTTP takie jak: GET https://google.com HTTP/1.1 (z nagłówkiem host i innymi typowymi nagłówkami), proxy spróbuje dostępować się do google.com i znajdziesz SSRF.
NTLM Authentication - Info disclosure
Jeśli serwer żądający autoryzacji jest Windows lub znajdziesz login proszący o Twoje credentials (i proszący o nazwę domeny), możesz wywołać ujawnienie informacji.
Wyślij nagłówek: “Authorization: NTLM TlRMTVNTUAABAAAAB4IIAAAAAAAAAAAAAAAAAAAAAAA=” i ze względu na sposób działania NTLM authentication, serwer odpowie wewnętrznymi informacjami (wersja IIS, wersja Windows...) w nagłówku "WWW-Authenticate".
Możesz zautomatyzować to przy użyciu nmap pluginu "http-ntlm-info.nse".
HTTP Redirect (CTF)
Możliwe jest umieszczenie zawartości wewnątrz Redirection. Ta zawartość nie będzie widoczna dla użytkownika (ponieważ przeglądarka wykona przekierowanie), ale coś może być ukryte w środku.
Sprawdzanie podatności webowych
Gdy wykonano już kompleksową enumerację aplikacji webowej, czas sprawdzić wiele możliwych podatności. Możesz znaleźć checklistę tutaj:
{{#ref}} ../../pentesting-web/web-vulnerabilities-methodology.md {{#endref}}
Więcej informacji o web vulns:
- 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
Monitorowanie stron pod kątem zmian
Możesz użyć narzędzi takich jak https://github.com/dgtlmoon/changedetection.io do monitorowania stron pod kątem modyfikacji, które mogą wprowadzić podatności.
HackTricks Automatyczne polecenia
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.wiki/en/network-services-pentesting/pentesting-web/index.html
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}
{{#include ../../banners/hacktricks-training.md}}