If you want to **know** about my **latest modifications**/**additions** or you have **any suggestion for HackTricks or PEASS**, ****join the 💬 **PEASS & HackTricks telegram group here, or follow me on Twitter** 🐦@carlospolopm.
If you want to share some tricks with the community you can also submit pull requests to ****https://github.com/carlospolop/hacktricks ****that will be reflected in this book.
Don’t forget to give ⭐ on the github to motivate me to continue developing this book.
The web service is the most common and extensive service and a lot of different types of vulnerabilities exists.
Default 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
In this methodology we are going to suppose that you are going to a attack a domain (or subdomain) and only that. So, you should apply this methodology to each discovered domain, subdomain or IP with undetermined web server inside the scope.
Check if there are known vulnerabilities for the server version that is running.
The HTTP headers and cookies of the response could be very useful to identify the technologies and/or version being used. Nmap scan can identify the server version, but it could also be useful the tools whatweb, webtech or https://builtwith.com/:
whatweb -a 1 <URL> #Stealthy
whatweb -a 3 <URL> #Aggresive
webtech -u <URL>
Search ****for ****vulnerabilities of the web application version****
Check if any WAF
As commented the cookies can be very useful to identify the technology in used (if well known) but if the used cookies are custom, they could be vulnerable. So if you find a custom sensitive cookie you should check it for vulnerabilities.
Also, the flags of the cookies can also be interesting from a security point of view.
Some tricks for finding vulnerabilities in different well known technologies being used:
If the source code of the application is available in github, apart of performing by your own a White box test of the application (no guide available yet in hacktricks) there is some information that could be useful for the current Black-Box testing:
Take into account that the same domain can be using different technologies in different ports, folders and subdomains.
If the web application is using any well known tech/platform listed before or any other, don’t forget to search on the Internet new tricks (and let me know!).
You should look for these kind of vulnerabilities every time you find a path were a different technology is running. For example, if you find a java webapp and in /wordpress
a wordpress is running.
nikto -h <URL>
whatweb -a 4 <URL>
wapiti -u <URL>
W3af
If a CMS is used don’t forget to run a scanner, maybe something juicy is found:
Clusterd**:** JBoss**, ColdFusion, WebLogic,** Tomcat**, Railo, Axis2, Glassfish**
CMSScan: WordPress, Drupal, **Joomla**, **vBulletin** websites for Security issues. (GUI)
VulnX**: Joomla,** Wordpress,** Drupal, PrestaShop, Opencart
CMSMap**: (W)ordpress, (J)oomla,** (D)rupal** or (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
At this point you should already have some information of the web server being used by the client (if any data is given) and some tricks to keep in mind during the test. If you are lucky you have even found a CMS and run some scanner.
From this point we are going to start interacting with the web application.
If you find that WebDav is enabled but you don’t have enough permissions for uploading files in the root folder try to:
Use testssl.sh to checks for vulnerabilities (In Bug Bounty programs probably these kind of vulnerabilities won’t be accepted) and use a2sv to recheck the 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>
Information about SSL/TLS vulnerabilities:
Launch some kind of spider inside the web. The goal of the spider is:
Note that anytime a new directory is discovered during brute-forcing or spidering, it should be spidered.
Start brute-forcing from the root folder and be sure to brute-force all the directories found using this method and all the directories discovered by the Spidering (you can do this brute-forcing recursively and appending at the beginning of the used wordlist the names of the found directories).
Tools:
wfuzz -w /usr/share/seclists/Discovery/Web-Content/raft-medium-directories.txt https://domain.com/api/FUZZ
ffuf -c -w /usr/share/wordlists/dirb/big.txt -u http://10.10.10.10/FUZZ
Recommended dictionaries:
Note that anytime a new directory is discovered during brute-forcing or spidering, it should be Brute-Forced.
Once you have found all the files, look for backups of all the executable files (".php", “.aspx”…). Common variations for naming a backup are: file.ext~, #file.ext#, ~file.ext, file.ext.bak, file.ext.tmp, file.ext.old, file.bak, file.tmp and file.old
You use tools like ****Arjun and Parameth to discover hidden parameters. If you can, you could try to search hidden parameters on each executable web file.
While performing the spidering and brute-forcing you could find interesting things that you have to notice.
The JS code of a web application can be really interesting: It could contain API keys, credentials, other endpoints, and understanding it you could be able to bypass security measures.
It could be also very useful to parse the JS files in order to search for other endpoints: LinkFinder, JSScanner (wrap of LinkFinder), JSParser, relative-url-extractor.
Another interesting approach could be monitoring the JS files with a tool like JSMon that checks for changes.
You should also check if the application is using any outdated and vulnerable javascript library with: RetireJS****
If the javascript code is obfuscated, these tools could be useful:
In several occasions you will need to understand regular expressions used, this will be useful: https://regex101.com/
Try using different verbs to access the file: GET, POST, INVENTED
If /path is blocked, try using /%2e/path __(if the access is blocked by a proxy, this could bypass the protection). Try also _/%252e/path_ (double URL encode)
Try Unicode bypass: /%ef%bc%8fpath (The URL encoded chars are like “/") so when encoded back it will be //path and maybe you will have already bypassed the /path name check
Try to stress the server sending common GET requests (It worked for this guy wit Facebook).
Change the protocol: from http to https, or for https to http
Change Host header to some arbitrary value (that worked here)
Other path bypasses:
Other bypasses:
Go to https://archive.org/web/ and check if in the past that file was worldwide accessible.
Fuzz the page: Try using HTTP Proxy Headers, HTTP Authentication Basic and NTLM brute-force (with a few combinations only) and other techniques. To do all of this I have created the tool fuzzhttpbypass.
X-Originating-IP: 127.0.0.1
X-Forwarded-For: 127.0.0.1
X-Remote-IP: 127.0.0.1
X-Remote-Addr: 127.0.0.1
X-ProxyUser-Ip: 127.0.0.1
X-Original-URL: 127.0.0.1
X-Original-URL: /admin/console
X-Rewrite-URL: /admin/console
Guess the password: Test the following common credentials. Do you know something about the victim? Or the CTF challenge name?
{% code title=“Common creds” %}
admin admin
admin password
admin 1234
admin admin1234
admin 123456
root toor
test test
guest guest
{% endcode %}
If any page responds with that code, it’s probably a bad configured proxy. ****If you send a HTTP request like: GET https://google.com HTTP/1.1
(with the host header and other common headers), the proxy will try to access google.com and you will have found a SSRF.
If the running server asking for authentication is Windows or you find a login asking for your credentials (and asking for domain name), you can provoke an information disclosure.
Send the header: “Authorization: NTLM TlRMTVNTUAABAAAAB4IIAAAAAAAAAAAAAAAAAAAAAAA=”
and due to how the NTLM authentication works, the server will respond with internal info (IIS version, Windows version…) inside the header “WWW-Authenticate”.
You can automate this using the nmap plugin “http-ntlm-info.nse”.
It is possible to put content inside a Redirection. This content won’t be shown to the user (as the browser will execute the redirection) but something could be hidden in there.
If you find a login page, here you can find some techniques to try to bypass it:
You should also check for:
Check for ****SQL INSERT INTO Injections.****
Check for this vulnerabilities:
More references for each Web Vulnerability: https://cyberzombie.in/bug-bounty-methodology-techniques-tools-procedures/
Another checklist: https://six2dez.gitbook.io/pentest-book/others/web-checklist