From YobiWiki
Jump to navigation Jump to search


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)


  • 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...


  • postal address, about us,...
  • robots.txt
  • WayBack machine*/ from [1]
  • Google cache
  • Coralize from [2]
  • traceroute
    • CLI: traceroute / tcptraceroute
    • from [3]
  • Other online DNS tools
  • whois
    • CLI: whois / whois / whois -B
    • from [4]
    • from [5]
  • Reverse IP
    • CLI: host / host -t NS / host -t MX / host -t PTR
    • 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
      • from [6]
      • from [7]
      • RIPE whois textual search to see if the contacts have registered other IP ranges
    • Try other IPs of the same range
  • Subdomains
    •* from [8]
    • Google:
    • 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 "" |\
      sed -n 's/ /p' | grep -o -e '[.[:alnum:]]\' | sort -u
    • intext:""
    • intext:"mailto:"
    • "Internal Server Error"
    • (filetype:xls | filetype:doc | filetype:txt) mail
    • filetype:csv mail address
    • filetype:mdb inurl:email
    • intitle:index.of inbox dbx
    • filetype:wab wab
    • filetype:reg reg intext:"internet account manager"
    • filetype:pst inurl:"outlook.pst"



Other key people

Misc resources

Misc tools

  • Maltego is a Java-based incredible tool to collect informations

Mapping the network


From the few domain names we got during the collect of informations, get their IP


Then query whois to know the full IP range and its owner

whois [-B]

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

Cross-check with the whois results


We can try a zone transfer on the target NS, who knows, maybe one will allow it...

dig @<authoritative_dns_server> 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 $
done 2>/dev/null

See also txdns for automating even more aggressive scans



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 -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
Starting Nmap 4.53 ( ) at 2008-03-24 20:30 CET
Interesting ports on
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...


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

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="")/UDP()/DNS(qd=DNSQR(qname="")))
0000 IP / UDP / DNS Qry ""  ==> IP / UDP / DNS Ans "" 

See also unicorn for other scans with applicative payload


If TCP/UDP port 111 is open, we can query the portmapper:

$ rpcinfo -p



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.


To discover how many hops to the target and the IPs of the gateways (and maybe that some ports are diverted...)

Based on UDP:


Based on TCP:


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="", ttl=7)/TCP())
>>> res[TCP].show()



  • 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