Passive Recon for infrastructure
As part of the recon process we will also want to gather information about our targets infrastructure. For example, to identify servers used to host different parts of the system. This can help us to further target our recon process. For example, identifying mail servers or DNS servers can shape further investigation.
While active recon is our main way of gathering information on the targets infrastructure, there are times we may be able to gather this data passively.
Netcraft
One such tool we could use for this is Netcraft, a UK based company, that has been involved in the countries cyber security strategy2. In their own words.
Quote
Netcraft provide internet security services including anti-fraud and anti-phishing services, application testing and PCI scanning. We also analyse many aspects of the internet, including the market share of web servers, operating systems, hosting providers and SSL certificate authorities. [^netcraft:]
As well as several paid services, such as security audit, and Phishing detection and prevention. Netcraft provide us with an excellent passive reconnaissance tool that helps us discover information about the systems and services a website is running on.
This is an excellent resource as it allows us to gain some of the information that could be found using scanning techniques, without having to perform the scan ourselves.
Note
As we will see when we discuss active recon, OS fingerprinting, and Service detection will never be 100% accurate.
While Netcraft (and nmap) are very good at their jobs, the information given may be inaccurate.
Getting a Site Report
Entering any domain in the What's that Site Running bar, will show us the results of Netcraft s latest audit.
Examining the Site Report for Nmap.org
Entering nmap.org into the search box, brings up several sites with the word nmap.org in their name.
While there are a couple of false positives (for example coinmap.org), its nice that we can also identify some subdomains of the main nmap site: - www.nmap.org - scanme.nmap.org
Clicking on the report section takes us to the site report for Nmap
Network Section and Hosting History
The network and hosting history section can give us some further information that can be used in DNS enumeration of our target, For example we can see:
- IP address that the server lives at
- Netblock Information
- A Netblock is a group of IP addresses that has been assigned to an organisation (such as an ISP)
- This tells us that Nmap.org is hosted with Linode
- DNS information.
- Gives us some details about the sites DNS (Domain Name Service) records, we will examine the types of information DNS can give us in a future article
The Hosting history also gives us some useful information, including the OS type and Web Server information. Here we can see that the Web Server has been identified as Apache, running on Centos 2.4.6
Site Technology Section
Gives us information on the various technologies that have been detected on the site. Again this can give us an idea of what types of attack may work, how the site has been developed, and possible complications for the pen test process.
Examining the Site Report for Coventry.ac.uk
Lets look at the site report for coventry.ac.uk and see what information we can discover
Subdomains
In the case of large organisations, subdomains can be a great source of information. Often they are setup to individual teams within the org, and may fall out of the control of a centralised IT infrastructure, which means that they may be an easier target.
- Here we get several sub domains identified
- cuoodle.coventry.ac uk
- computing.coventry.ac.uk
- webapp.services.coventry.ac.uk
Technologies
Identifying the server technology is a little harder, as everything is hidden behind the load balancing software (bigIP)
However, we could infer some thing about the technology used using the Server-Side elements. We can see that the system has detected Atlas and ASP.net This gives us an indication that the web server is likely to be Microsoft based.
Netcraft summary
Netcraft can be a useful source of information on a organisations services and infrastructure. It can give us an overview of the servers on a site, and may help fingerprint some of the common technologies used.
DNS Records
So far we have looked at discovering some basic information about an organisation. While netcraft can give us an insight into the network structure of a target, performing a more detailed DNS reconnaissance can provide more detailed information, and disclose the network infrastructure of an organisation.
Discovering something about the network structure.
DNS enumeration is the process of examining the DNS (Domain Name Service) records for a target. DNS acts like a "address book" for online services, mapping host names "www.coventry.ac.uk" to an IP address of a server such as 10.10.10.101. However, DNS records can also contain information on things such as Email servers, subdomains, and other servers in the organisation.
This can be useful to reduce the amount of work we need to do in the
Active reconnaissance phase, for example if we identify a range of IP
addresses, then we can limit our port scanning to these addresses.
Additionally, subdomains can provide hints on the services a machine
may be running. For example, ftp.company.com would indicate
that there is some form of files sharing.
Understanding DNS records.
There are many different types of DNS record, (for a detailed list visit https://en.wikipedia.org/wiki/List_of_DNS_record_types common ones you may come across include:
| Type | Description |
|---|---|
| A | IPv4 Address Record: Commonly used to map host name to an address |
| AAAA | IPv6 Address Record: |
| CNAME | Canonical Name Record: Alias of one name to another |
| MX | Mail Server Record: Address of Mail Server |
| SOA | Authority Record: Can contain information on Primary name server, email of domain administrator etc. |
DNS enumeration using DIG
The First tool we will look at for DNS enumeration is Dig, a tool designed to run DNS queries.
A Basic lookup of the coventry.ac.uk domain gives the following output.
root@kali:~# dig coventry.ac.uk any
; <<>> DiG 9.10.3-P4-Debian <<>> coventry.ac.uk any
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 26837
;; flags: qr rd ra; QUERY: 1, ANSWER: 17, AUTHORITY: 0, ADDITIONAL: 5
;; QUESTION SECTION:
;coventry.ac.uk. IN ANY
;; ANSWER SECTION:
coventry.ac.uk. 5 IN A 192.168.69.2
coventry.ac.uk. 5 IN A 192.168.69.7
coventry.ac.uk. 5 IN A 192.168.69.8
coventry.ac.uk. 5 IN A 192.168.69.6
coventry.ac.uk. 5 IN A 192.168.69.5
coventry.ac.uk. 5 IN A 192.168.69.1
coventry.ac.uk. 5 IN A 192.168.32.11
coventry.ac.uk. 5 IN NS gbcuadds04.coventry.ac.uk.
coventry.ac.uk. 5 IN NS gbbcadds01.coventry.ac.uk.
coventry.ac.uk. 5 IN NS gbcuadds06.coventry.ac.uk.
coventry.ac.uk. 5 IN NS gbcuadds02.coventry.ac.uk.
coventry.ac.uk. 5 IN NS gbcuadds03.coventry.ac.uk.
coventry.ac.uk. 5 IN NS gbcuadds01.coventry.ac.uk.
coventry.ac.uk. 5 IN NS gbcuadds05.coventry.ac.uk.
coventry.ac.uk. 5 IN SOA gbcuadds01.coventry.ac.uk. hostmaster.coventry.ac.uk. 28155204 900 600 86400 3600
coventry.ac.uk. 5 IN MX 1 gbcuexch04.coventry.ac.uk.
coventry.ac.uk. 5 IN MX 1 gbcuexch03.coventry.ac.uk.
;; ADDITIONAL SECTION:
gbcuadds04.coventry.ac.uk. 5 IN A 192.168.69.8
gbbcadds01.coventry.ac.uk. 5 IN A 192.168.32.11
gbcuadds06.coventry.ac.uk. 5 IN A 192.168.69.2
gbcuadds02.coventry.ac.uk. 5 IN A 192.168.69.7
gbcuadds03.coventry.ac.uk. 5 IN A 192.168.69.6
;; Query time: 1 msec
;; SERVER: 192.168.227.2#53(192.168.227.2)
;; WHEN: Fri Mar 01 11:57:54 GMT 2019
;; MSG SIZE rcvd: 500
We can see from this there a lot of information gets returned. There are:
- several servers linked to the domain, (A records)
- internal name servers used for routing traffic within the coventry.ac.uk domain.
- two mail servers
In the additional section, we can also link the name server records to a given IP address.
DNS Reconnaissance with dnsenum
Another tool we can use for DNS reconnaissance is dnsrecon. I find this provides slightly more readable information than dig.
root@kali:~# dnsenum coventry.ac.uk
Smartmatch is experimental at /usr/bin/dnsenum line 698.
Smartmatch is experimental at /usr/bin/dnsenum line 698.
dnsenum VERSION:1.2.4
----- coventry.ac.uk -----
Host's addresses:
__________________
coventry.ac.uk. 5 IN A 192.168.69.2
coventry.ac.uk. 5 IN A 192.168.69.7
coventry.ac.uk. 5 IN A 192.168.69.8
coventry.ac.uk. 5 IN A 192.168.69.6
coventry.ac.uk. 5 IN A 192.168.69.5
coventry.ac.uk. 5 IN A 192.168.69.1
coventry.ac.uk. 5 IN A 192.168.32.11
Name Servers:
______________
gbbcadds01.coventry.ac.uk. 5 IN A 192.168.32.11
gbcuadds06.coventry.ac.uk. 5 IN A 192.168.69.2
gbcuadds02.coventry.ac.uk. 5 IN A 192.168.69.7
gbcuadds03.coventry.ac.uk. 5 IN A 192.168.69.6
gbcuadds01.coventry.ac.uk. 5 IN A 192.168.69.5
gbcuadds05.coventry.ac.uk. 5 IN A 192.168.69.1
gbcuadds04.coventry.ac.uk. 5 IN A 192.168.69.8
Mail (MX) Servers:
___________________
gbcuexch04.coventry.ac.uk. 5 IN A 192.168.69.56
gbcuexch03.coventry.ac.uk. 5 IN A 192.168.69.41
Trying Zone Transfers and getting Bind Versions:
_________________________________________________
Trying Zone Transfer for coventry.ac.uk on gbcuadds04.coventry.ac.uk ...
AXFR record query failed: REFUSED
brute force file not specified, bay.
root@kali:~#
Again, a large amount of information on the IP addresses associated with the Coventry domain has been revealed.
Zone Transfers
Zone transfers are a tool that were designed to let servers and admins replicate DNS data between servers. If we can do a zone transfer on the target network, then we will get the full DNS information (and information on external (and possibly internal) services. Over the past few years, DNS configs have been getting better, so getting a zone transfer to work may not be possible.
However, the legality of (and reactions to) Zone transfer is debated. If you own the domain then it is fine, but others might kick up a fuss.
Having been bitten in the past, but an organisation that wanted to take one of the students to court, we wont cover them here.
Summary
DNS reconnaissance can provide information on the structure of a network, revealing different servers, and services that are accessible via the Internet. This information can be used in to focus the effort during the active reconnaissance phase of a penetration test.