Find hidden files and directories

TLDR

#dirsearch
/opt/dirsearch/dirsearch.py -w /usr/share/wordlists/dirbuster/directory-list-2.3-medium.txt -u http://TARGETIP -e php -t 20


# Dirb
dirb https://192.168.1.101

# Gobuster 

gobuster dir -u 10.10.10.X -l -w /usr/share/wordlists/dirbuster/directory-list-2.3-medium.txt  -t 20

- specify relevant response codes
gobuster dir -u http://192.168.1.101 -w /usr/share/seclists/Discovery/Web_Content/common.txt -s '200,204,301,302,307,403,500' -e

- simple auth and extenstions
gobuster dir -u 172.16.1.24 -U username -P Password1234 -w /usr/share/SecLists/Discovery/Web-Content/big.txt -t 20 -x php,txt,pl,sh,asp,aspx,html,json,py,cfm,rb,cgi

About

There is essentially no way for a user to know which files are found in which directories on a web-server, unless the whole server has directory listing by default. However, if you go directly to the page it will be shown. So what the attacker can do is to brute force hidden files and directories. Just test a bunch of them. There are several tools for doing this. The attack is of course very noisy and will show up fast in the logs.

Dirb

This is a really easy tool to use:

dirb http://target.com

Dirbuster

It is a GUI
You start it with:

dirbuster

wordlist=/usr/share/wordlists/dirbuster/directory-list-2.3-medium.txt

file extensions=php,txt,pl,sh,asp,aspx,html,json,py,cfm,rb,cgi

OWASP ZAP

Insert your target.
Add it to the context
Click the plus-sign
Click on Forced Browse

Wfuzz

You can find the manual by typing:

wfuzz -h
wfuzz -c -z file,/root/.ZAP/fuzzers/dirbuster/directory-list-2.3-big.txt --sc 200 http://pegasus.dev:8088/FUZZ.php

Gobuster

# Gobuster - remove relevant responde codes (403 for example)
gobuster -u http://192.168.1.101 -w /usr/share/seclists/Discovery/Web_Content/common.txt -s '200,204,301,302,307,403,500' -e

note: to append a forward slash to each item in wordlist, use -f
note2: another good list is /usr/share/wordlists/dirbuster/directory-list-1.0.txt

WAF - Web application firewall

It might be that dirb shows you 403 errors, instead of the expected 404. This might mean that there is a WAF protecting the site. To get around it we might have to change our request header to it looks more like a normal request.

dirb http://target.com -a "Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/51.0.2704.106 Safari/537.36"

results matching ""

    No results matching ""