Public Network-Level Discovery - Using Whois and DNS Probing

Public Network-Level Discovery

Using Whois and DNS Probing

Eleanore Young
by Eleanore Young
on August 03, 2017
time to read: 9 minutes

When assessing the security of computer systems, web applications are most commonly the target today. However, network based assessments (and thus also attacks) are almost equally important, especially when multiple machines of a particular organization are exposed to the internet. In this article, we will be looking into how to perform the first steps of discovering and probing an organization from a network perspective.

Discovering Domain and Hosts

Usually, one would start off either with an IP address range (ex. 192.0.2.0/24) or a domain name (ex. example.com). Our goal is to obtain an IP range as complete as possible for a given organization and the name of their servers (including the domain name). This is where the Domain Name System (DNS) comes into play. It translates human-readable domains names to corresponding IP addresses, and sometimes vice-versa.

Whois Records

Assuming that we’ve been given only the domain name, we will first query the Whois database in order to obtain information about the domain, its registrar and related name servers. A Whois record must be created when a particular domain is registered. Whois data is important because it may sometimes display personal data on persons responsible for IT management in a particular organization, which is very useful for social engineering attacks.

$ whois example.com
whois: This information is subject to an Acceptable Use Policy.
See https://www.nic.ch/terms/aup/

Domain name:
example.com

Holder of domain name:
Example Holdings Inc.
Jane Doe
101 First Street
New York, NY
United States of America
Contractual Language: English

Technical contact:
Any Hosting Inc.
Philip Johnson
525 Flower Lane
New York, NY
United States of America

Registrar:
Network Registrar Corp.

First registration date:
2001-01-01

DNSSEC:N

Name servers:
ns1.net-reg.com
ns2.net-reg.com

Dig and the Domain Name System

But we would also like to know the IP addresses of the name servers and possibly a web server behind example.com. For this, we consult dig, an invaluable tool for querying DNS records. Dig itself has many options for issuing different DNS queries, but for now, a simple A query will work just fine (although already rather old, Madboa has a wonderful introduction into Dig).

$ dig example.com A

; <<>> DiG 9.10.3-P4-Debian <<>> example.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: xxxxx
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 2

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;example.com.			IN	A

;; ANSWER SECTION:
example.com.		85937	IN	A	192.0.2.1

;; AUTHORITY SECTION:
example.com.		3137	IN	NS	ns1.net-reg.com.
example.com.		3137	IN	NS	ns2.net-reg.com.

;; ADDITIONAL SECTION:
ns1.net-reg.com.	494	IN	A	192.0.3.53
ns2.net-reg.com.	494	IN	A	192.0.3.52

So, based on this, we now know the IP addresses of the web server and the two DNS servers. But let’s try to find more information about the organization in question. The MX record will likely give us the names of the organization’s mail servers, while the SOA record will tell us the authoritative name server, and the TXT record will sometimes provide information about the Sender Policy Framework (SPF). SPF was designed to curtail e-mail address spoofing, but for us, this tells us what hosts are allowed to send e-mail for the given domain.

Lastly, we’ll try to obtain a list of all hosts of this particular domain, using the AXFR record. However, these so-called zone transfers fail most of the time, for good reasons.

$ dig example.com MX +short
10 mail.example.com
$ dig example.com SOA +short
ns1.net-reg.com. net-reg.anyhosting.com. 2017042502 10800 3600 604800 600
$ dig example.com TXT +short
"v=spf1 mx a ip4:192.0.2.0/24 ip4:192.0.3.52/31 ip4:192.0.4.0/24 ~all"
$ dig example.com AXFR +short
; Transfer failed.

Now, despite the fact that we were unable to execute a zone transfer, the TXT record was very helpful, because it told us exactly which IP address blocks belong to that domain. We now have all necessary information to assess the security of the individual hosts through various means.

But so-far, we assumed that we already knew the name of the organization’s domain. What if we only know a few IP-addresses, such as 192.0.2.0/24? While it can be misleading, the Whois database will again be the first place to look for information. In this case, we managed to glean information on telephone numbers, the internet service provider, and hints towards the domain name. Based on these hints, we can use common search engines or Dig to try to identify the correct domain, and we can continue with the steps outlined earlier in the article.

$ whois 192.0.2.0
inetnum:        192.0.2.0 - 192.0.2.255
netname:        EXAMPLE-NET
descr:          Example Inc.
descr:          New York
country:        US
admin-c:        JD92-RIPE
tech-c:         JD92-RIPE
status:         ASSIGNED PA
mnt-by:         US-UNISOURCE-MNT
created:        2009-05-15T09:20:00Z
last-modified:  2009-06-19T08:42:58Z
source:         RIPE

person:         Jane Doe
address:        Example Inc.
address:        101 First Street
address:        New York
phone:          +1-(555)-800 10 30
fax-no:         +1-(555)-800 10 03
nic-hdl:        JD92-RIPE
created:        2009-05-10T00:00:00Z
last-modified:  2016-02-01T00:00:00Z
mnt-by:         RIPE-NCC-LOCKED-MNT
source:         RIPE # Filtered

route:          192.0.0.0/8
descr:          Some-ISP NET-REG aggregate
origin:         ASxxxx
mnt-by:         US-UNISOURCE-MNT
created:        2003-02-01T00:00:00Z
last-modified:  2003-02-01T00:00:00Z
source:         RIPE

Probing Hosts Further

As soon as we have a reasonably complete list of hosts of the target domain, we are able to scan individual hosts for available services and information made available by them. As opposed to querying Whois or DNS, this step is bound to send network traffic to the hosts of the target domain, and you might not want that for fear of being discovered. There are two ways to approach this problem: either you use a search engine such as Shodan, or you scan the hosts such that your traffic will get lost in all other traffic. The SANS institute has a great introduction into using Shodan effectively, for those interested. The other option is to use scanning software directly. Common tools that can be used to scan hosts, are Nmap, ZMap, and Masscan.

About the Author

Eleanore Young

Eleanore Young has completed her master degree in electrical engineering and information technology in 2014 at ETH Zurich. Her areas of focus include computer architectures, operating systems and applied research.

Links

You want more than a simple security test with Nessus und Nmap?

Our experts will get in contact with you!

×
JWT Issues

JWT Issues

Andrea Hauser

CIS Controls

CIS Controls

Tomaso Vasella

Ransomware Detection, Defense, and Analysis

Ransomware Detection, Defense, and Analysis

Marc Ruef

Trustworthy AI

Trustworthy AI

Prisca Quadroni-Renella

You want more?

Further articles available here

You need support in such a project?

Our experts will get in contact with you!

You want more?

Further articles available here