Pentest
Intro
Well a large subject...
You'll not find a howto here, more a checklist.
So why such a page?
Because I'm not doing pentests that often so when it happens, it's a bit unstructured.
Because I'm reading MISC HS 1 (in french) and I want to make some scrapbooking.
So I'll try to write down anything I do on that matter since now, starting with this HS1 and laying down everything I'm thinking about given my past experiences...
Note that a pentest doesn't imply going through *all* the steps described here, it depends what is the starting point, the surface of attack, the primary target, etc (looking on Google will not (better not!!) help you if you're assessing an internal network from inside)
Logging
- Write down what we've found, how and when
- Consider just writing what you did no matter what you found, especially when it's about grabbing bits after bits on various search engines, you don't want to redo several times the same query or to forget about trying this new juicy bit in one of your favorite search engines ;-)
- You can end up with quite a lot of infos, especially e.g. when pentesting as an insider...
- A (protected) wiki page sounds nice but confidentiality requires sometimes stronger measures such as a local encrypted deposit (cf MiscCrypto)
- The results could be divided into several files:
- a TRACE, with all the possible infos, too long to be read but you know you can find back your info here
- a TRACEDIR, for the various tools which generate generous outputs, consider also saving a summary of the juicy bits in your TRACE & REPORT
- a REPORT, with the most interesting facts, probably divided into results on the target and results as side-effects because you'll never stop just because it's a bit out-of-focus ;-) (I audited the frontdoor as you asked but btw did you know the wall is in paper?)
- a TODO, with the parts you found that are calling for further investigation, pentesting is a lot about searching a tree and backtracking once you explored one branch as far as you could (technically or logistically if you've a deadline & priorities...)
Collecting information
This section is valid also for other domains than pure pentest, e.g. find a maximum of information on the person who bought a domain name under a pseudo...
website
- postal address, about us,...
- robots.txt
- WayBack machine
http://web.archive.org/web/*/http://www.example.com from [1] - Google cache
http://209.85.135.104/search?q=cache:http://www.example.com - Coralize
http://www.example.com.nyud.net from [2] - traceroute
- CLI: traceroute / tcptraceroute
- http://www.dnsstuff.com/tools/tracert.ch?ip=http://www.example.com from [3]
- Other online DNS tools
- whois
- Reverse IP
- CLI: host / host -t NS / host -t MX / host -t PTR 44.33.22.11.in-addr.arpa
- Getting all known domains, not just reverse lookup:
Interesting for co-hosted websites, to find if the same admin is managing other sites... -> whois etc on them- http://whois.webhosting.info/11.22.33.44 from [6]
- http://search.msn.com/results.aspx?q=ip:11.22.33.44 from [7]
- RIPE whois textual search to see if the contacts have registered other IP ranges
- Try other IPs of the same range
- Subdomains
- http://searchdns.netcraft.com/?host=*.example.com from [8]
- Google:
site:example.com -inurl:www.example.com
- cf also below in DNS section
Search engines
- Big list of the top 100 alternative search engines, see also [9]
- Alexa: traffic ranking & other infos
- Google +
site:
/inurl:
/intext:
/filetype:
/-polluting_keyword
/&num=100
/ etc- wget / lynx -dump & awk / sed / grep
- combined:
(filetype:xls | filetype:doc | filetype:pdf)
& check metadata of docs as well - cf Google FAQ about supported filetypes
- Example requests to find emails:
lynx -dump "http://www.google.com/search?q=site:example.com+intext:@example.com&num=100" |\
sed -n 's/@example.com/& /p' | grep -o -e '[.[:alnum:]]\+@example.com' | sort -usite:example.com intext:"@example.com"
site:example.com intext:"mailto:"
site:example.com "Internal Server Error"
site:example.com (filetype:xls | filetype:doc | filetype:txt) mail
site:example.com filetype:csv mail address
site:example.com filetype:mdb inurl:email
site:example.com intitle:index.of inbox dbx
site:example.com filetype:wab wab
site:example.com filetype:reg reg intext:"internet account manager"
site:example.com filetype:pst inurl:"outlook.pst"
Finance
- Google Finance
- Yahoo! Finance
- http://www.societe.com/ (France)
- http://www.transnationale.org/
- http://www.hoovers.com
People
- SpoCK
- Namebase
- TheyRule
- Linked In, FaceBook, Plaxo, Beboo, Orkut, Myspace, Skyblog, Del.icio.us,...
- Fatdoor? available via Google Base
Other key people
- via patents
- via publications
Misc resources
- OpenSecrets, about lobbying efforts (US)
- Wikileaks, documents not supposed to have become public
- Wikiscanner, what are the modifications done by this company on Wikipedia?
- SourceWatch
Misc tools
- Maltego is a Java-based incredible tool to collect informations
Mapping the network
DNS
From the few domain names we got during the collect of informations, get their IP
host www.example.com
Then query whois to know the full IP range and its owner
whois [-B] 11.22.33.44
We get also the handler "nic-hdl" which can be used in turn to see if other ranges are administred by the same people:
whois -i pn <nic-hdl>
We can brute-force a reverse-lookup on the IP range to see if there are other relevant domain names:
for ((i=1;i!=255;i++)); do dig -x 11.22.33.$i|\ grep -v '^;'|\ awk '/PTR/{sub(/\.$/,"",$5);print $5}';done
For each identified domain name, see what say the TLDs:
dig NS com dig NS example.com @a.gtld-servers.net.
Cross-check with the whois results
whois example.com
We can try a zone transfer on the target NS, who knows, maybe one will allow it...
dig @<authoritative_dns_server> example.com axfr
This is also to be tested on subdomains as well...
If no transfer was possible we can try a dictionary approach:
for i in ns ns0 ns1 mx mx0 gw gw0 gw-0 db data \ www www0 mail exchange ftp dialup ecommerce \ forum smtp smtphost cvs vpn lotus webmail \ websphere private priv8 pop pop3 imap proxy secret; do host $i.example.com done 2>/dev/null
See also txdns for automating even more aggressive scans
Scans
TCP
nmap FQDN_or_IP/range... -PN: skip ping -sS/sT/sA/sW/sM: TCP SYN/Connect()/ACK/Window/Maimon scans -sN/sF/sX: TCP Null, FIN, and Xmas scans -p 111-222: port range -sV: Probe open ports to determine service/version info -O: Enable OS detection (needs to be root) -T[0-5]: Set timing template (higher is faster) -A: Enables OS detection and Version detection, Script scanning and Traceroute etc. see man page
Example: massive SYN scan on all TCP ports:
nmap -sS -PN -A -oA scan_result 11.22.33.44/24 -p 1-65535
It can help to set the source port to 20 (ftp-data) to avoid some filters as well as to try FIN or XMAS scans
Example: strange response on port 443? Maybe skype... yes!
nmap --script=skype_v2-version.nse 192.168.0.1 Starting Nmap 4.53 ( http://insecure.org ) at 2008-03-24 20:30 CET Interesting ports on 192.168.0.1: [...] 443/tcp open skype2
Subtilities: when we get a TCP Reset, compare the TTL with a TCP SYN-ACK to see if it comes from the target or a previous filtering gateway...
And when a ICMP host unreachable is replied, if it took more than a normal RTT, it means the gateway really tried to reach the machine on the local ethernet but its ARP requests faced a timeout, while an immediate response indicates a filter...
UDP
TCP ports reply to SYN with SYN ACK if open but UDP ports usually don't reply unless no service is running or unless we talk to the (unknown) application. Here nmap will reply open|filtered when it doesn't get an answer:
# nmap -sU 11.22.33.44
Combining with -sV
can help detecting the underneath application (but it's much slower)
Using UDP source ports 53, 67, 68, 69 or 123 may help bypassing some firewalls.
Example to scan for DNS servers with scapy:
# scapy Welcome to Scapy (v1.1.1 / -) >>> res,unans = sr(IP(dst="192.168.0.1/24")/UDP()/DNS(qd=DNSQR(qname="www.google.com"))) [...] >>> res.show() 0000 IP / UDP / DNS Qry "www.google.com" ==> IP / UDP / DNS Ans "www.l.google.com."
See also unicorn for other scans with applicative payload
RPC
If TCP/UDP port 111 is open, we can query the portmapper:
$ rpcinfo -p 11.22.33.44
Topology
A single mail from the target network reveals a traceroute of the MTAs in its headers
Sending a mail to a non-existing address can also reveal interesting infos, with usually the mail sent (and its MTA list) as attachment.
ACK scan
Will always reply by RST if the port is open or closed, interesting to see if the packet was dropped by a filter.
Traceroutes
To discover how many hops to the target and the IPs of the gateways (and maybe that some ports are diverted...)
Based on UDP:
traceroute
Based on TCP:
tcptraceroute
Based on ICMP echo request:
tracert (Windows)
Can be combined with applicative payload (e.g. cf DNS above)...
Discovering the other IPs of a router
When tracerouting, we see only the IP of the router which is facing us.
To discover the other IP(s) we can try to scan the range of IPs after the router with a TTL equal to the distance to the router.
The one(s) to be at the same nr of hops as the router (instead of one hop further) are believed to belong to the router, the other ones for which we get an error "ICMP Time exceeded" are further.
Note that we can have more than one IP of the supposed range for the same router if it has several interfaces and sub-ranges.
A reverse-lookup on those IPs can help to confirm the hypothesis.
Example: (scapy)
>>> res,unans=sr(IP(dst="195.219.144.2/24", ttl=7)/TCP()) [...] >>> res[TCP].show()
Windows
- Sandman Framework
- http://security4all.blogspot.com/2008/03/partytricks-winlockpwn-tutorial-or-how.html
- http://www.bugs.ms/
- http://wiki.hak5.org/wiki/Switchblade_Packages
TODO
- snmp
- Wi-Fi
- kismet
- detecting quickly the rogue APs via ARP replay & sniffing the internal network at same time, etc
- breaking WEP, WPA
- admin access on the APs
- www.penetrationtests.com