Network Security Assessment, 3rd Edition

Chapter 4. Internet Network Discovery

This chapter describes the first steps taken when assuming the role of an Internet-based attacker. A competent adversary will use open sources to map an organization’s networks and identify its users. Here are three of those sources:

• Web search engines and sites (e.g., Google, Netcraft, and LinkedIn)

• WHOIS registries

• Accessible DNS servers

The majority of this probing is indirect, sending traffic to websites including Google, and public WHOIS and DNS servers. Two tactics involve sending traffic to the target network, however, as follows:

• Probing the target’s own DNS servers

• Network probing via SMTP

Through initial reconnaissance, you can identify potential weaknesses. Peripheral systems are commonly insecure when compared to publicized web, application server, and mail endpoints.

The reconnaissance process is iterative, repeating enumeration tasks upon uncovering new information (such as a domain name, or office location). The agreed scope of an assessment exercise defines the boundaries, which sometimes might include third parties. Target Corporation suffered a severe compromise in 2013, in which the VPN credentials of a vendor were reportedly used to gain access to the internal network, resulting in the exposure of 70 million customer records.¹

Querying Search Engines and Websites

Search engines catalog useful information. Google and other sites provide advanced search functions that let attackers build a clear picture of the networks they plan to attack later.

In particular, the following classes of data are often uncovered:

• Physical addresses of office locations

• Contact details, including email addresses and telephone numbers

• Details of internal email systems and routing

• DNS layout and naming conventions

• Files residing on publicly accessible servers

With regard to the final bullet in this list, Offensive Security maintains the Google Hacking Database,² which contains details of searches that reveal sensitive material on vulnerable web servers. Entire books are also dedicated to the subject, including Google Hacking for Penetration Testers (Syngress, 2015). The following sections detail popular tactics that adversaries can adopt to map networks and identify useful content.

Google Search

Attackers use Google to gather useful information through its advanced search panel. Searches are refined to include or exclude certain keywords, or to hit on keywords in specific file formats, under specific Internet domains, or parts of the web page (e.g., the page title). Table 4-1 lists useful Google search directives.

Metadata from publicly available materials found via Google (e.g., Microsoft Office formats and PDF files) can also be parsed to reveal usernames and client software details, as demonstrated by the Metagoofil tool.

Table 4-1. Google search directives

Directive	Example	Description
intext	intext:password filetype:xlsx	Displays hits within page text
intitle	intitle:"index of /backup"	Displays hits within the page title
inurl	inurl:dyn_sensors.htm	Displays hits within the page URL
filetype	filetype:log intext:password	Return results with a specific file type (e.g., passwords within log files)
site	site:edu filetype:key intext:private	Show results within a particular domain (e.g., RSA private keys within the EDU top-level domain)

Enumerating contact details

Google searches often reveal contact details, including email addresses and telephone and fax numbers. Figure 4-1 shows the results of a simple query passed to Google to enumerate users at NIST.

Figure 4-1. Using Google to enumerate users

Identifying web servers

You can query Google in many ways, depending on the data you seek. Figures 4-2 and 4-3 show how Google is used to enumerate web servers at MIT and list web servers that support directory indexing at NASA, respectively.

Figure 4-2. Enumerating MIT’s web servers via Google

Figure 4-3. Identifying indexed web directories under nasa.gov

Obtaining VPN configuration files

Some organizations publicly distribute configuration files and keys for VPN systems. Cisco profile configuration files (PCFs) contain IPsec VPN client variables, including the following:

• VPN server endpoint addresses

• Plaintext credentials (group name and password)

• Encrypted credentials (an obfuscated group password)

Table 4-2 lists Google search strings you can use to uncover Cisco VPN, OpenVPN, and SSH configuration materials and keys. Figure 4-4 demonstrates a search revealing PCF files of academic institutions in the United States. During testing, change the site variable to encompass each domain within scope.

Table 4-2. Search strings revealing VPN and SSH configuration files

Technology	Example query strings
Cisco VPN	filetype:pcf site:edu grouppwd
OpenVPN	filetype:ovpn site:tk filetype:key site:edu +client
SSH	filetype:key site:edu +id_dsa filetype:id_rsa

Many of the exposed PCF files shown in Figure 4-4 contain a 3DES-encrypted password (enc_GroupPwd). A design flaw means the key used to decrypt the password is contained within the ciphertext, and so the encryption mechanism is largely obfuscative.

The following sites provide tools to instantly decrypt these passwords:

• Cisco VPN client password decoder

• Cisco VPN client password cracker

Figure 4-4. Identifying Cisco PCF files via Google

Maurice Massar published cisco-decrypt.c,³ which can be built and run locally from Unix-based environments (upon installing libgpg-error and libgcrypt⁴), as demonstrated by Example 4-1.

Example 4-1. Building and executing cisco-decrypt within Apple OS X

$ wget http://bit.ly/2aAs1IM
$ gcc -Wall -o cisco-decrypt cisco-decrypt.c $(libgcrypt-config --libs --cflags)
$ ./cisco-decrypt 992C9F91B9AF94528891390F09C783805E33FDBB1C6146556CDADAD4A06D
secret

Armed with a VPN endpoint address and credentials, you can use an IPsec VPN client (e.g., VPNC within Kali Linux) to establish a connection and evaluate the level of network access granted. Chapter 10 describes IPsec VPN assessment in detail.

Querying Netcraft

Netcraft retains historic server fingerprint details. You can use the Netcraft web interface to map network blocks, displaying operating platform details and other useful information. Figure 4-5 shows Netcraft queried to list web servers within the nist.gov domain.

Figure 4-5. Using Netcraft to identify and fingerprint web servers

Using Shodan

Shodan is a searchable database of network scan data. Upon registering, you can enumerate valid hostnames and exposed network services, and identify unhardened systems (e.g., Internet-connected devices using default passwords). Figure 4-6 demonstrates the exposed systems at Zappos.com, and Table 4-2 details Shodan search filters. Metasploit also contains a Shodan search module,⁵ which you can use to identify known systems within target network blocks.

Figure 4-6. Enumerating Internet-exposed services with Shodan

Table 4-3. Shodan search filters

Filter	Example	Description
city	sendmail city: "london"	Sendmail servers in London
country	nginx country:DE	Nginx servers in Germany
geo	apache geo:32.8,-117,50	Apache servers within 50 km of San Diego (coordinates 32.8, -117)
hostname	hostname:sslvpn	Known hostnames containing sslvpn
net	net:216.219.0.0/16	All data for 216.219.0.0/16
os	jboss os:linux	JBoss running on Linux
port	avaya port:5060	Avaya SIP VoIP endpoints
before	nginx before:18/1/2010	Nginx endpoints found before 18 January 2010
after	apache after:22/3/2010 before:4/6/2010	Apache servers found after 22 March 2010 and before 4 June 2010

Note

There have been numerous Internet-wide scans and surveys undertaken by other groups, including academic researchers and commercial entities. The Internet-Wide Scan Data Repository is a public archive of the data collected through these efforts.

DomainTools

DomainTools provides a number of useful tools:

• Reverse IP WHOIS, revealing IP ranges registered to a particular entity

• Domain WHOIS history, providing details of a domain’s previous registrants

• Reverse IP lookup, presenting the known hostnames for a given network

• Reverse NS lookup, showing the domains using a given name server

• Reverse MX lookup, providing the domains using a given mail server

The WHOIS dataset is indexed by Google, and so a search of a given mailing address or company name will reveal associated domains, as shown in Figure 4-7. Armed with a professional account, you can use the various tools directly.

Figure 4-7. Domains associated with a particular address

PGP Public Key Servers

Organizations maintain servers that provide public PGP keys to clients. You can query these to reveal user email addresses and details, as shown in Figure 4-8. Public servers at the time of writing include the following:

• https://pgp.mit.edu

• https://keyserver.ubuntu.com

• http://pgp.uni-mainz.de

Figure 4-8. Querying pgp.mit.edu to reveal user details

Searching LinkedIn

LinkedIn often reveals useful information about an organization and its people, along with details of technologies used internally. With a LinkedIn Premium account, you can obtain full names and roles of users (restricted to 700 results per search) that can be funneled into spear phishing and brute-force password grinding efforts. Figure 4-9 demonstrates the various search fields that you can use during testing.

Note

Attackers successfully breached a large corporation in 2013 upon identifying systems administrators using LinkedIn, compromising their home machines, and eventually securing corporate VPN access.

Figure 4-9. Using LinkedIn to search for users

Domain WHOIS

During testing, you can quiz domain registries to obtain useful information regarding domain names registered by the target organization. There are many top-level domains (TLDs) and associated registries at the time of writing, including generic TLDs and country-code TLDs. ICANN and IANA maintain lists of registries at the following locations:

• gTLD registries

• ccTLD registries

These registries provide the following information:

• Administrative contact details (names, email addresses, and telephone numbers)

• Mailing addresses for office locations relating to the target organization

• Details of authoritative name servers for each domain

Here are some tools that you can use to perform domain WHOIS querying:

• The whois command-line client

• Web interfaces maintained by each domain registry

• Third-party services run by Hurricane Electric (HE), DomainTools, and others

Manual WHOIS Querying

You can use the whois utility (found within Kali Linux, Apple OS X, and other systems) to query both IP and domain WHOIS services. In Example 4-2, I use the tool to reveal useful information regarding the blah.com domain, including administrative contact details, and authoritative DNS name server names.

Example 4-2. Obtaining the domain WHOIS record for blah.com

root@kali:~# whois blah.com

Domain names in the .com and .net domains can now be registered
with many different competing registrars. Go to http://www.internic.net
for detailed information.

   Domain Name: BLAH.COM
   Registrar: TUCOWS DOMAINS INC.
   Whois Server: whois.tucows.com
   Referral URL: http://domainhelp.opensrs.net
   Name Server: RJOCPDNE01.TIMBRASIL.COM.BR
   Name Server: RJOCPDNE02.TIMBRASIL.COM.BR
   Status: ok
   Updated Date: 09-jan-2014
   Creation Date: 20-mar-1995
   Expiration Date: 21-mar-2016

>>> Last update of whois database: Sun, 27 Apr 2014 01:14:30 UTC <<<

The Registry database contains ONLY .COM, .NET, .EDU domains and
Registrars.

Domain Name: BLAH.COM
Registry Domain ID: 1803012_DOMAIN_COM-VRSN
Registry Registrant ID:
Registrant Name: Marcello do Nascimento
Registrant Organization: Tim Celular SA
Registrant Street: Avenida das Americas, 3434
Registrant City: Rio de Janeiro
Registrant State/Province: RJ
Registrant Postal Code: 22640-102
Registrant Country: BR
Registrant Phone: [phone]
Registrant Phone Ext:
Registrant Fax: [phone]
Registrant Fax Ext:
Registrant Email: [e-mail]
Registry Admin ID:
Name Server: RJOCPDNE01.TIMBRASIL.COM.BR
Name Server: RJOCPDNE02.TIMBRASIL.COM.BR
DNSSEC: Unsigned

Alternatively, the Whois tab of http://bgp.he.net/dns/blah.com provides the registration information, as shown in Figure 4-10. Other public sites support this type of querying, including DomainTools.

Figure 4-10. Using a web interface to query WHOIS

IP WHOIS

Regional Internet Registries (RIRs) provide useful information relating to IP network allocations. IP WHOIS database objects define which areas of Internet space are registered to which organizations, including routing information and contact details.

Internet addresses fall under different geographic regions. Table 4-3 lists the respective RIRs you can query to glean useful information (including names of operations staff, details of IP network blocks, and physical office locations).

Table 4-4. Regional Internet Registries

Name	Region	Website
ARIN	North America	http://www.arin.net
RIPE	Europe	http://www.ripe.net
APNIC	Asia Pacific	http://www.apnic.net
LACNIC	Latin America and Caribbean	http://www.lacnic.net
AFRNIC	Africa	http://www.afrnic.net

Note

Each regional WHOIS database contains information relevant to that particular region. For example, the RIPE database doesn’t contain details of objects found in the Americas.

IP WHOIS Querying Tools and Examples

Here are some tools that you can use to query IP WHOIS databases:

• The whois command-line client

• RIR WHOIS web interfaces

• Third-party applications (e.g., DomainTools)

Enumerating database objects via WHOIS

You can use the whois utility to enumerate IP WHOIS database objects. Command-line flags and syntax vary by operating system and WHOIS server. In Example 4-3, I submit a query to enumerate all the objects in the ARIN database for Nintendo, from a Apple OS X client.

Example 4-3. Enumerating the Nintendo objects in ARIN

$ whois -a "z / nintendo*"

# ARIN WHOIS data and services are subject to the Terms of Use
# available at: https://www.arin.net/whois_tou.html

Nintendo Of America inc. NINTENDO-COM (NET-205-166-76-0-1)
205.166.76.0 - 205.166.76.255
NINTENDO HEADQUARTERS 1 NINTENDOHEADQUARTERS1 (NET-70-89-123-72-1)
70.89.123.72 - 70.89.123.79

Nintendo Of America inc. (AS11278) NINTENDO 11278

Nintendo North America (NNA-21)
Nintendo of America (TEND)
NINTENDO OF AMERICA INC (NA-101)
NINTENDO OF AMERICA INC (NA-103)
NINTENDO OF AMERICA INC (NA-53)
NINTENDO OF AMERICA INC (NA-62)
NINTENDO OF AMERICA INC (NA-83)
NINTENDO OF AMERICA INC (NINTE-3)
Nintendo Of America inc. (NINTEN)
Nintendo of America, Inc. (NINTE-1)
Nintendo of America, Inc. (NINTE-2)

Nintendo Network Administration (NNA12-ARIN) [e-mail]

NINTENDO (C00975304) ABOV-T461-209-133-66-88-29 (NET-209-133-66-88-1)
209.133.66.88 - 209.133.66.95
NINTENDO (C00975329) ABOV-T461-209-133-66-72-29 (NET-209-133-66-72-1)
209.133.66.72 - 209.133.66.79
NINTENDO HEADQUARTERS 1 (C01807503) NINTENDOHEADQUARTERS1 (NET-70-89-123-72-1) 
70.89.123.72 - 70.89.123.79
Nintendo of America Inc. (C02551839) INAP-SEF-NINTENDO-39421 (NET-69-25-139-128-1) 
69.25.139.128 - 69.25.139.255
Nintendo of America Inc. (C02563750) INAP-SEF-NINTENDO-39650 (NET-63-251-6-64-1) 
63.251.6.64 - 63.251.6.79

The –a flag specifies the ARIN database, and the "z / instructs the WHOIS server to provide us with all the material it has for objects relating to the nintendo* string. If we specify an @ instead, the query will reveal users at the organization, as demonstrated by Example 4-4.

Example 4-4. Enumerating the Nintendo email accounts in ARIN

$ whois -a "z @ nintendo*"

# ARIN WHOIS data and services are subject to the Terms of Use
# available at: https://www.arin.net/whois_tou.html

BILL, OLARTE  (BILLO2-ARIN) [e-mail] [phone]
Dan, Lambert  (LDA31-ARIN) [e-mail] [phone]
Darling, Caleb  (CDA73-ARIN) [e-mail] [phone]
Garlock, Jeff  (GARLO5-ARIN) [e-mail] [phone]
Lambert, Dan  (DLA46-ARIN) [e-mail] [phone]
Nintendo Network Administration (NNA12-ARIN) [e-mail]

ARIN indexes details of North American objects, and so we must reissue the query to other registries (e.g., APNIC) to enumerate those in different regions, as shown in Example 4-5.

Example 4-5. Enumerating the Nintendo objects in APNIC

$ whois -A nintendo
% [whois.apnic.net]
% Whois data copyright terms    http://www.apnic.net/db/dbcopyright.html

% Information related to '60.32.179.16 - 60.32.179.23'

inetnum:        60.32.179.16 - 60.32.179.23
netname:        NINTENDO
descr:          Nintendo Co.,Ltd.
country:        JP
admin-c:        FH829JP
tech-c:         FH829JP
remarks:        This information has been partially mirrored by APNIC from
remarks:        JPNIC. To obtain more specific information, please use the
remarks:        JPNIC WHOIS Gateway at
remarks:        http://www.nic.ad.jp/en/db/whois/en-gateway.html or
remarks:        whois.nic.ad.jp for WHOIS client. (The WHOIS client
remarks:        defaults to Japanese output, use the /e switch for English
remarks:        output)
changed:        [e-mail] 20060208
source:         JPNIC

% Information related to '60.36.183.152 - 60.36.183.159'

inetnum:        60.36.183.152 - 60.36.183.159
netname:        NINTENDO
descr:          Nintendo Co.,Ltd.
country:        JP
admin-c:        FH829JP
tech-c:         MI7247JP
remarks:        This information has been partially mirrored by APNIC from
remarks:        JPNIC. To obtain more specific information, please use the
remarks:        JPNIC WHOIS Gateway at
remarks:        http://www.nic.ad.jp/en/db/whois/en-gateway.html or
remarks:        whois.nic.ad.jp for WHOIS client. (The WHOIS client
remarks:        defaults to Japanese output, use the /e switch for English
remarks:        output)
changed:        [e-mail] 20050729
source:         JPNIC

Using the Apple OS X whois client, we specify –a to query ARIN and –A to query APNIC. Other versions of the client let you use an arbitrary WHOIS server hostname (e.g., whois nintendo -h whois.apnic.net). To complicate things further, each server also supports different search syntax, so you’ll need to refer to the documentation for whichever client–server pair you are using during testing.

Using WHOIS web interfaces

You also can use web interfaces run by registries to obtain useful information. Figure 4-11 shows that if a postal code is known for a location, you can use it to enumerate the associated IP space within RIPE.

Figure 4-11. Querying the RIPE search engine using a postal code

BGP Enumeration

Traffic between Internet-based networks is controlled by using BGP and AS numbers. The IANA assigns AS numbers to RIRs, which in turn are allocated to ISPs and organizations so that they can manage their IP router networks and upstream connections.

The WHOIS query in Example 4-3 revealed this AS number for Nintendo:

Nintendo Of America inc. (AS11278) NINTENDO 11278

You can cross-reference AS11278 by using the HE BGP Toolkit to reveal the IPv4 prefixes announced by the AS number, as shown in Figure 4-12. If an AS announces IPv6 address space, you can enumerate it in the same way.

Figure 4-12. Cross-referencing AS numbers to reveal IP blocks

DNS Querying

You can use command-line utilities (e.g., nslookup and dig) to query name servers. Automated tools are also used to perform reverse sweeping and forward grinding attacks against accessible name servers.

Table 4-5 lists the useful DNS resource records provided by name servers during testing. RFC 1035 details the low-level mechanics and use of all but the AAAA IPv6 address and SRV service locator records.

Table 4-5. Useful DNS resource records

Record	Description	Reveals
SOA	Start of authority	The source host where the DNS zone was created
NS	Name server	Names of authoritative DNS servers for a given domain
A	Address (IPv4)	IPv4 addresses for a hostname
AAAA	Address (IPv6)	IPv6 addresses for a hostname
PTR	Pointer	Hostname of a given IPv4 or IPv6 address
CNAME	Canonical name	Hostname which the CNAME is an alias of
MX	Mail exchange	Mail servers for a given domain
HINFO	Host information	Operating system or other information for a host
SRV	Service locator	Application service endpoints within a domain, including Kerberos, LDAP, SIP, and XMPP
TXT	Text string	Materials including SPF and DKIM fields used to provide security, depending on configuration

Forward DNS Querying

DNS records are used by most network applications. Two common scenarios are web browsing (i.e., a domain resolving to a web server IP address via an A or CNAME record) and sending mail (i.e., messages being sent to users within a domain through valid MX records being presented).

Manual querying

Example 4-6 demonstrates how you can use nslookup in an interactive fashion to obtain the MX records for nintendo.com (revealing the inbound SMTP server hostnames for the domain).

Example 4-6. Using nslookup to enumerate basic domain details

root@kali:~# nslookup
> set querytype=any
> nintendo.com

Non-authoritative answer:
nintendo.com
    origin = gtm-west.nintendo.com
    mail addr = webadmin.noa.nintendo.com
    serial = 2010034461
    refresh = 600
    retry = 300
    expire = 604800
    minimum = 300
nintendo.com  nameserver = gtm-east.nintendo.com.
nintendo.com  nameserver = gtm-west.nintendo.com.
Name:    nintendo.com
Address: 205.166.76.26
nintendo.com  mail exchanger = 10 smtpgw1.nintendo.com.
nintendo.com  mail exchanger = 20 smtpgw2.nintendo.com.
nintendo.com  text = "v=spf1 mx ip4:205.166.76.16 ip4:205.166.76.35 ip4:202.32.117.170 
ip4:202.32.117.171 ip4:111.168.21.4 a:bgwia.nintendo.com a:bgate.nintendo.com ~all"

These hostnames are useful because mail servers often reside on the corporate network boundary between the Internet and internal network. By scanning around such hosts, we can often identify systems that, in turn, interact with internal assets.

DNS querying reveals the authoritative DNS server hostnames as gtm-east and gtm-west, along with the mail servers of smtpgw1 and smtpgw2. The four IP addresses of these hosts can next be cross-referenced with WHOIS, revealing 192.195.204.0/24 and 205.166.76.0/24 as two IP network blocks used by the organization.

The SPF text record is used to prevent spam from being sent from the domain; it contains details of authorized outbound mail servers (both hostnames and IP addresses). In this case, three are new and two are already known.

Automated querying

Within Kali Linux, you can use dnsenum to automate basic forward DNS querying, as shown in Example 4-7. The tool also attempts DNS zone transfers (as discussed in the following section) and can fingerprint exposed name servers.

Example 4-7. Running dnsenum against nintendo.com

root@kali:~# dnsenum nintendo.com
dnsenum.pl VERSION:1.2.3

-----   nintendo.com   -----

Host's addresses:
nintendo.com.                  5   IN   A   192.195.204.26

Wildcard detection using: fpaznhjfcwil
fpaznhjfcwil.nintendo.com.     5   IN   A   10.3.0.1

Name Servers:
gtm-west.nintendo.com.         5   IN   A   205.166.76.190
gtm-east.nintendo.com.         5   IN   A   192.195.204.190

Mail (MX) Servers:
smtpgw2.nintendo.com.          5   IN   A   205.166.76.164
smtpgw1.nintendo.com           5   IN   A   205.166.76.97

Note the wildcard detection component in Example 4-7; this tool and others like it generate a random hostname to resolve, and if it does, it shows that nonexistent names point to a particular IP (10.3.0.1 in this case, which is a local proxy endpoint within my environment, and not the target network). Names resolving to this address by subsequent DNS requests are then ignored.

Note

Manual assessment of DNS records is critical because IP addresses revealed in Example 4-6 are not uncovered through automated querying. Be sure to manually review both the TXT and SRV records returned for the domains within scope during testing.

Obtaining SRV records

Nmap’s dns-srv-enum script enumerates common SRV records for a given domain name, exposing internal server endpoints used by applications (e.g., Microsoft Active Directory, Microsoft Exchange, Kerberos, VoIP handsets, and XMPP clients). Example 4-8 demonstrates the script run against ebay.com.

Example 4-8. SRV record enumeration using Nmap

root@kali:~# nmap --script dns-srv-enum --script-args dns-srv-enum.domain=ebay.com

Starting Nmap 6.46 (http://nmap.org) at 2014-09-09 02:16 UTC
Pre-scan script results:
| dns-srv-enum:
|   Exchange Autodiscovery
|     service  prio  weight  host
|     443/tcp  0     0       molecule.corp.ebay.com
|   XMPP server-to-server
|     service   prio  weight  host
|_    5269/tcp  0     0       xmpp.corp.ebay.com

DNS Zone Transfer Techniques

Organizations use multiple name servers for load balancing and fault tolerance reasons. A zone transfer is performed over TCP port 53 to propagate current DNS zone material to other name servers that support the operation.

Zone files contain DNS records that relate to particular domains and IP blocks. Misconfigured servers honor transfer requests from untrusted sources (e.g., the public Internet), and you can use this to map a given network.

Example 4-9 demonstrates how, upon obtaining the authoritative server details for a domain (whois.net in this case), you can use dig to perform a zone transfer. You should attempt such a transfer against authoritative name servers, and after you have undertaken port scanning, any name server within scope that exposes TCP port 53.

Example 4-9. Performing a zone transfer of whois.net

$ dig whois.net ns +short
glb-ns4.it.verio.net.
glb-ns1.it.verio.net.
glb-ns2.it.verio.net.
glb-ns3.it.verio.net.
$ dig @glb-ns4.it.verio.net whois.net axfr

; <<>> DiG 9.8.3-P1 <<>> @glb-ns4.it.verio.net whois.net axfr
;; global options: +cmd
whois.net.                     3600 IN   SOA    nsx.NTX.net. system.NTX.net. 
                                                2014081401 86400 7200 2592000 3600
whois.net.                     3600 IN   MX     0 x210.NTX.net.
whois.net.                     900  IN   NS     glb-ns1.it.verio.net.
whois.net.                     900  IN   NS     glb-ns2.it.verio.net.
whois.net.                     900  IN   NS     glb-ns3.it.verio.net.
whois.net.                     900  IN   NS     glb-ns4.it.verio.net.
whois.net.                     30   IN   A      131.103.218.176
whois.net.                     30   IN   A      198.171.79.36
whois.net.                     30   IN   A      204.202.20.53
blog.whois.net.                600  IN   A      161.58.211.91
dev.whois.net.                 600  IN   A      10.227.2.237
forum.whois.net.               600  IN   A      161.58.211.91
ftp.whois.net.                 600  IN   CNAME  whois.net.
dev.legacy.whois.net.          3600 IN   A      131.103.218.162
qa.legacy.whois.net.           3600 IN   A      198.171.79.34
qa.legacy.whois.net.           3600 IN   A      204.202.20.50
qa.legacy.whois.net.           3600 IN   A      131.103.218.131
qa01-fl.qa.legacy.whois.net.   3600 IN   A      131.103.218.131
qa02-ca.qa.legacy.whois.net.   3600 IN   A      204.202.20.50
whois.net.                     900  IN   NS     glb-ns3.it.verio.net.
wisqlfld1.whois.net.           3600 IN   A      10.227.2.239
wisqlflq1.whois.net.           3600 IN   A      10.227.2.240
wisqlva1.whois.net.            3600 IN   A      198.171.79.130
www.whois.net.                 60   IN   CNAME  whois.net.
whois.net.                     3600 IN   SOA    nsx.NTX.net. system.NTX.net. 
                                                2014081401 86400 7200 2592000 3600

This DNS zone provides details of internal IP addresses of hosts including dev.whois.net. Upon identifying a server that supports zone transfer, you can query by using an IP block and reveal valid PTR records (used to resolve IP addresses back to hostnames). Example 4-10 demonstrates using dig to perform a zone transfer of the 198.171.79.0/24 subnet.

Example 4-10. Performing a zone transfer of 198.171.79.0/24

$ dig @glb-ns4.it.verio.net 79.171.198.in-addr.arpa axfr

; <<>> DiG 9.8.3-P1 <<>> @glb-ns4.it.verio.net 79.171.198.in-addr.arpa axfr
; (1 server found)
;; global options: +cmd
79.171.198.in-addr.arpa.     86400 IN   SOA    ns1.secure.net. hostmaster.secure.net. 
                                               2013120602 86400 7200 2592000 86400
79.171.198.in-addr.arpa.     86400 IN   NS     ns1.secure.net.
79.171.198.in-addr.arpa.     86400 IN   NS     ns2.secure.net.
102.79.171.198.in-addr.arpa. 86400 IN   PTR    va1-salsa02.ops.verio.net.
27.79.171.198.in-addr.arpa.  86400 IN   PTR    stngva1-dc02.corp.verio.net.
38.79.171.198.in-addr.arpa.  86400 IN   PTR    stngva1-dc01.corp.verio.net.
42.79.171.198.in-addr.arpa.  86400 IN   PTR    va1-itmail.it.verio.net.
47.79.171.198.in-addr.arpa.  86400 IN   PTR    va1-itmail01.it.verio.net.
48.79.171.198.in-addr.arpa.  86400 IN   PTR    va1-itmail02.it.verio.net.
50.79.171.198.in-addr.arpa.  86400 IN   PTR    va1-w8mon01.isg.win.smewh.net.
52.79.171.198.in-addr.arpa.  86400 IN   PTR    va1-w8mon02.isg.win.smewh.net.
54.79.171.198.in-addr.arpa.  86400 IN   PTR    va1-w8sql01.isg.win.smewh.net.
56.79.171.198.in-addr.arpa.  86400 IN   PTR    va1-w8sql02.isg.win.smewh.net.
62.79.171.198.in-addr.arpa.  86400 IN   PTR    stngva1-dc04.corp.verio.net.
69.79.171.198.in-addr.arpa.  86400 IN   PTR    va1-salsa01.ops.verio.net.
7.79.171.198.in-addr.arpa.   86400 IN   PTR    stngva1-dc03.corp.verio.net.
79.171.198.in-addr.arpa.     86400 IN   SOA    ns1.secure.net. hostmaster.secure.net. 
                                               2013120602 86400 7200 2592000 86400

The PTR records in Example 4-10 reveal new domains and subdomains that can, in turn, be fed back into other enumeration processes (e.g., zone transfers, and forward grinding attacks, as detailed in the following section).

Forward DNS Grinding

If zone transfers are not permitted by the available name servers, you should adopt active grinding tactics to identify valid DNS address records, including:

• Dictionary attack using A record requests

• NSEC and NSEC3 record enumeration

Dictionary attack

The fierce utility within Kali Linux attempts a zone transfer against each authoritative name server for a domain and then launches a forward DNS grinding attack using an inbuilt dictionary (/usr/share/fierce/hosts.txt). Example 4-11 shows the tool revealing hostnames within the academi.com domain.

Example 4-11. Forward DNS grinding with fierce

root@kali:~# fierce -dns academi.com
DNS Servers for academi.com:
    ns1.dnsbycomodo.net
    ns2.dnsbycomodo.net

Trying zone transfer first...
Unsuccessful in zone transfer (it was worth a shot)
Okay, trying the good old fashioned way... brute force

Now performing 2280 test(s)...
67.238.84.228 email.academi.com
67.238.84.242 extranet.academi.com
67.238.84.240 mail.academi.com
67.238.84.230 secure.academi.com
67.238.84.227 vault.academi.com
54.243.51.249 www.academi.com

Subnets found (may want to probe here using nmap or unicornscan):
    54.243.51.0-255 : 1 hostnames found.
    67.238.84.0-255 : 5 hostnames found.

Here are alternative tools for Unix-based platforms (including Apple OS X) that you can use to enumerate hostnames through forward grinding:

• Nmap⁶

• knockpy⁷

• dnsenum⁸

• dnsmap⁹

• bfdomain.py¹⁰

In some scenarios, you will need to launch an attack against a particular server. Example 4-12 demonstrates how to identify the authoritative DNS servers for the academi.com domain, prepare a dictionary file of hostnames (academi.txt), and use dig to query a specific server (ns2.dnsbycomodo.com). It is common for subordinate name servers to be unhardened, and so testing each available DNS service is encouraged.

Example 4-12. Using dig to perform forward grinding

root@kali:~# dig academi.com ns +short
ns1.dnsbycomodo.net.
ns2.dnsbycomodo.net.
root@kali:~# cat /usr/share/fierce/hosts.txt | awk '{printf("%s.academi.com\n",$1);}' > out.txt
root@kali:~# dig @ns2.dnsbycomodo.net -f out.txt +noall +answer
careers.academi.com.     200  IN   CNAME  academi.catsone.com.
email.academi.com.       3600 IN   A      67.238.84.228
extranet.academi.com.    7200 IN   A      67.238.84.242
mail.academi.com.        3600 IN   A      67.238.84.240
secure.academi.com.      7200 IN   A      67.238.84.230
vault.academi.com.       7200 IN   A      67.238.84.227
www.academi.com.         3600 IN   A      54.243.51.249

NSEC and NSEC3 enumeration

You can quiz name servers supporting DNSSEC to reveal valid hostnames. Scripts that automate this are dns-nsec-enum and dns-nsec3-enum. Example 4-13 demonstrates enumeration of PayPal hostnames using the approach (output stripped for brevity).

Example 4-13. NSEC hostname enumeration using Nmap

root@kali:~# nmap -sSU -p53 --script dns-nsec-enum \
--script-args dns-nsec-enum.domains=paypal.com ns3.isc-sns.info

Starting Nmap 6.46 (http://nmap.org) at 2014-09-09 01:48 UTC
Nmap scan report for ns3.isc-sns.info (63.243.194.1)
PORT   STATE SERVICE
53/tcp open  domain
53/udp open  domain
| dns-nsec-enum:
|   paypal.com
|     paypal.com
|     0cd20b6fe61233e4a24bf70f30c9ba46.paypal.com
|     _dmarc.paypal.com
|     _adsp._domainkey.paypal.com
|     ant2._domainkey.paypal.com
|     maps.dkim._domainkey.paypal.com
|     salesforce.dkim._domainkey.paypal.com
|     dphr2._domainkey.paypal.com
|     gfk._domainkey.paypal.com
|     gld2._domainkey.paypal.com
|     paypalcorp._domainkey.paypal.com
|     pp-dkim1._domainkey.paypal.com
|     pp-docusign1._domainkey.paypal.com
|     pp-dphr._domainkey.paypal.com
|     pp-eloqua._domainkey.paypal.com
|     pp-eloqua1._domainkey.paypal.com
|     pp-gapps._domainkey.paypal.com
|     pp-mailgun1._domainkey.paypal.com
|     pp2._domainkey.paypal.com
|     ppcorp2._domainkey.paypal.com
|     salesforce._domainkey.paypal.com

The entire dataset includes 753 entries. Upon extracting the names to /tmp/paypal.txt, you can use dig to perform forward grinding, and then awk and grep to identify private addresses,¹¹ as shown in Example 4-14.

Example 4-14. Identifying private addresses by using dig

root@kali:~# dig @ns3.isc-sns.info -f /tmp/paypal.txt +noall +answer | awk \
'{printf("%s %s\n",$5,$1);}' | grep -E '^(10\.)'
10.190.3.56 fallback-mx.paypal.com.
10.73.195.104 ffxadmin.paypal.com.
10.190.3.55 mx.paypal.com.
10.190.3.83 phx01monip01.phx.paypal.com.
10.190.65.153 phx01mreportdb01.phx.paypal.com.
10.190.65.153 phx01mreportdb01.paypal.com.
10.73.100.115 siteview.paypal.com.
10.74.100.115 siteview.paypal.com.
10.190.24.188 siteview.paypal.com.

You can obtain individual DNS records by using dig, as shown in Example 4-15 (for _sipfederationtls._tcp.paypal.com). This query reveals the SRV record used for SIP federation within the organization (as consumed by Microsoft Lync, Cisco Unified Presence, and others), along with DNSSEC records that mitigate spoofing attacks.

Example 4-15. Retrieving individual DNS records by using dig

$ dig @ns3.isc-sns.info _sipfederationtls._tcp.paypal.com any +noall +answer

; <<>> DiG 9.8.3-P1 <<>> @ns3.isc-sns.info _sipfederationtls._tcp.paypal.com any +noall +answer
; (1 server found)
;; global options: +cmd
_sipfederationtls._tcp.paypal.com. 300 IN SRV 0 0 5061 siplb.paypal.com.
_sipfederationtls._tcp.paypal.com. 300 IN RRSIG SRV 5 4 300 20141006135741 2014090613165811811 
paypal.com. p2YwplhbYlWCq5Lpw3iD+1PfkYJn//bNsvbBGZBwQpp4dbBTMa7DTyQBLF/B35dbDwnMADdsjoxxzWKurc
XPvOYE1nQN6mew+ZndcEoM7YKVXdba BzR/SiMpElh4ZAiyMNVy6nBRPpwJbOPEQyqsMJ/9U4b7jlvuUboB8o9a ZZA=
_sipfederationtls._tcp.paypal.com. 60  IN NSEC  _sip._tls.paypal.com. SRV RRSIG NSEC
_sipfederationtls._tcp.paypal.com. 60  IN RRSIG NSEC 5 4 60 20141006141217 2014090613452211811 
paypal.com. eNGi3sM4IRMSrPQ8I9vOPfLUDc48bDMi6DXR3NUEkWV+wdq0UpVCyHfhqTDQXR0S2GrqhZdY+1jXb9O6hu
2Zc5ADtKKEePvfwuskumWFt/kNC+9L VAmP8b+91cWY7QTOVfA/134Sd/gy/14NVyGJGzqMiIZ7dIoaLR5ZhAF5 88c=

Reverse DNS Sweeping

Upon building a list of IP network blocks, use reverse sweeping to reveal hostnames. Within Nmap, you can use the –sL flag along with grep and awk to format the results, as shown in Example 4-16.

Example 4-16. Using Nmap to perform reverse DNS sweeping

$ nmap -sL 205.166.76.0/24 | grep "(" | awk '{printf("%s %s\n",$5,$6);}'
proxy1.nintendo.com (205.166.76.3)
noa3dns-w.nintendo.com (205.166.76.8)
mail.gamecubepower.com (205.166.76.9)
proxy2.nintendo.com (205.166.76.13)
proxy3.nintendo.com (205.166.76.15)
smtpout.nintendo.com (205.166.76.16)
www.nintendo.com (205.166.76.26)
cmail.nintendo.com (205.166.76.35)
wkstn.nintendo.com (205.166.76.69)
border.nintendo.com (205.166.76.79)
www.returns.nintendo.com (205.166.76.92)
email.nintendo.com (205.166.76.95)
smtpgw1.nintendo.com (205.166.76.97)
mail.nintendo.com (205.166.76.98)
store.nintendo.com (205.166.76.99)
gwsmtp.nintendo.com (205.166.76.109)
service.nintendo.com (205.166.76.129)
dns1.nintendo.com (205.166.76.132)
dns2.nintendo.com (205.166.76.133)
gateway.nintendo.com (205.166.76.136)
smtpgw2.nintendo.com (205.166.76.164)
wwwmail.pokemon-tcg.com (205.166.76.167)
qaretail.siras.com (205.166.76.195)
venus.siras.com (205.166.76.196)
router.siras.com (205.166.76.197)
proxync.nintendo.com (205.166.76.200)
sgate.nintendo.com (205.166.76.213)
mercury.siras.com (205.166.76.253)

This process often reveals new domains and subdomains, which are fed into further web searches and DNS queries to identify further systems of interest. By modifying the name server value within your local /etc/resolv.conf file, you can force the querying of particular DNS servers.

Using the HE BGP Toolkit, you can obtain the DNS records for a given IP range, as shown in Figure 4-13. The PTR records are authoritative and relate to the target environment; however, the A records should be taken with a pinch of salt because they could stem from an error in a different DNS zone.

Figure 4-13. Mapping DNS by using the HE BGP Toolkit

Note

Building a list of valid hostnames within an environment is particularly useful when testing web server endpoints later. Load balancers and reverse proxies are commonplace: if misconfigured, they make it possible for adversaries to access web applications through providing valid Host header values within HTTP 1.1 requests.

IPv6 Host Enumeration

You can identify IPv6 servers through DNS grinding (via AAAA requests). Example 4-17 demonstrates the dnsdict6 utility found within Kali Linux used to identify IPv6 address of predictable hostnames within the ripe.net domain.

Example 4-17. IPv6 address enumeration via forward grinding

root@kali:~# dnsdict6 -s -t 32 ripe.net
Starting DNS enumeration work on ripe.net. ...
Starting enumerating ripe.net. - creating 32 threads for 100 words...
Estimated time to completion: 1 to 1 minute
dns.ripe.net. => 2001:67c:e0::6
ftp.ripe.net. => 2001:67c:2e8:22::c100:68c
fw.ripe.net. => 2001:67c:2e8:1::1
ns.ripe.net. => 2001:67c:e0::6
portal.ripe.net. => 2001:67c:2e8:22::c100:6a2
irc.ripe.net. => 2001:67c:2e8:11::c100:1302
mailhost.ripe.net. => 2001:67c:2e8:1::c100:168
ipv6.ripe.net. => 2001:67c:2e8:22::c100:68b
www.ripe.net. => 2001:67c:2e8:22::c100:68b
ntp.ripe.net. => 2001:67c:2e8:14:ffff::229
webmail.ripe.net. => 2001:67c:2e8:11::c100:1355
imap.ripe.net. => 2001:67c:2e8:1::c100:168

Depending on the name server configuration, you also can use dnsrevenum6 to identify valid hostname and IPv6 address pairs, as shown in Example 4-18 (the first argument is the name server to perform grinding against, followed by the IPv6 network).

Example 4-18. Reverse grinding by using dnsrevenum6

root@kali:~# dnsrevenum6 pri.authdns.ripe.net 2001:67c:2e8::/48
Starting DNS reverse enumeration of 2001:67c:2e8:: on server pri.authdns.ripe.net.
Found: 2001:67c:2e8:1::1 is gw.office.ripe.net.
Found: 2001:67c:2e8:1::c100:105 is vifa-1.ipv6.office-lb-1.ripe.net.
Found: 2001:67c:2e8:1::c100:106 is vifa-1.ipv6.bigip-3600-1.ripe.net.
Found: 2001:67c:2e8:1::c100:107 is vifa-1.ipv6.bigip-3600-2.ripe.net.
Found: 2001:67c:2e8:1::c100:10c is pademelon.ripe.net.
Found: 2001:67c:2e8:1::c100:10d is dingo.ripe.net.
Found: 2001:67c:2e8:1::c100:10e is koala.ripe.net.
Found: 2001:67c:2e8:1::c100:114 is desman.ripe.net.
Found: 2001:67c:2e8:1::c100:115 is jaguar.ripe.net.
Found: 2001:67c:2e8:1::c100:116 is db-www3.ripe.net.
Found: 2001:67c:2e8:1::c100:118 is bulbul.ripe.net.
Found: 2001:67c:2e8:1::c100:119 is buldog.ripe.net.
Found: 2001:67c:2e8:1::c100:11a is pumapard.ripe.net.
Found: 2001:67c:2e8:1::c100:11b is urutu.ripe.net.
Found: 2001:67c:2e8:1::c100:11c is int.db.ripe.net.
Found: 2001:67c:2e8:1::c100:11d is dropbear.ripe.net.
Found: 2001:67c:2e8:1::c100:11e is db-int-2.ripe.net.
Found: 2001:67c:2e8:1::c100:11f is moth.ripe.net.
Found: 2001:67c:2e8:1::c100:122 is pulpo.ripe.net.
Found: 2001:67c:2e8:1::c100:123 is iguana.ripe.net.
Found: 2001:67c:2e8:1::c100:124 is nik-sus-1.ripe.net.
Found: 2001:67c:2e8:1::c100:125 is tel-sus-1.ripe.net.
Found: 2001:67c:2e8:1::c100:126 is tonton.ripe.net.

Cross-Referencing DNS Datasets

Three websites used to cross-reference mail servers, name servers, and individual IP addresses to domains and hostnames are mxlist.net, nslist.net, and iplist.net. Figures 4-14 and 4-15 demonstrate how you can use the sites to show all of the domains served by mail1.cia.gov and gtm-west.nintendo.com. You also can use iplist.net to show the known DNS hostnames for a given IP address, as shown in Figure 4-16.

Figure 4-14. Querying mxlist.net

Figure 4-15. Querying nslist.net

Figure 4-16. Querying iplist.net

SMTP Probing

Mail gateways support the transmission of mail across networks via SMTP. Simply sending an email message to a nonexistent address at a target domain often reveals useful internal network information through a nondelivery notification (NDN). Example 4-19 shows how  email sent to a user account that doesn’t exist within the nintendo.com domain spawns an NDN, which reveals internal network information.

Example 4-19. An undeliverable mail transcript from nintendo.com

Generating server: noa.nintendo.com

[e-mail]
#550 5.1.1 RESOLVER.ADR.RecipNotFound; not found ##

Original message headers:

Received: from ONERDEDGE02.one.nintendo.com (10.13.20.35) by
 onerdexch08.one.nintendo.com (10.13.30.39) with Microsoft SMTP Server (TLS)
 id 14.3.174.1; Sat, 26 Apr 2014 16:52:22 -0700
Received: from barracuda.noa.nintendo.com (205.166.76.35) by
 ONERDEDGE02.one.nintendo.com (10.13.20.35) with Microsoft SMTP Server (TLS)
 id 14.3.174.1; Sat, 26 Apr 2014 16:51:22 -0700
X-ASG-Debug-ID: 1398556333-0614671716199b0d0001-zOQ9WJ
Received: from gateway05.websitewelcome.com (gateway05.websitewelcome.com  [69.93.154.37]) by 
barracuda.noa.nintendo.com with ESMTP id xVNPkwaqGgdyH5Ag for <[e-mail]>; Sat, 
26 Apr 2014 16:52:13 -0700 (PDT)
X-Barracuda-Envelope-From: [e-mail]
X-Barracuda-Apparent-Source-IP: 69.93.154.37

The following data in this transcript is useful:

• Internal hostnames, IP addresses, and subdomain layout

• The mail server is running Microsoft Exchange Server 2010 SP3

• A Barracuda Networks device is used to perform content filtering

A Google search for “exchange 14.3.174.1” reveals the patch level of the Exchange 2010 server as SP3 with Update Rollup 4 installed. A full list of build numbers and the respective patch levels is available from Microsoft.¹²

At Black Hat USA 2014, Ben Williams of NCC Group presented research that took advantage of this verbose behavior to reveal email content filtering policy of a mail gateway.¹³ Chapter 9 details SMTP testing strategies.

Automating Enumeration

Table 4-6 lists a number of tools that support Internet-based network and host enumeration from a single interface, adopting many of the tactics outlined in this chapter. To achieve the best coverage, I advise a combination of manual and automated testing.

Table 4-6. Automated enumeration tools

Name	Platform(s)	URL
Discover	Kali Linux	https://github.com/leebaird/discover
SpiderFoot	Windows, Linux	http://www.spiderfoot.net
Yeti	Java	https://spyeti.blogspot.com
TheHarvester	Kali Linux	http://www.edge-security.com/theharvester.php

Enumeration Technique Recap

What follows is an overview of Internet-based querying techniques and their application:

Web searches

Use Google, Netcraft, Shodan, LinkedIn, PGP key servers, and other sites to perform searches against known domain names and IP blocks to identify personnel, hostnames, domain names, and useful data residing on exposed web servers.

WHOIS querying

Query domain and IP registries to retrieve network block, routing, and contact details related to the target networks and domain names. IP WHOIS querying provides information relating to the sizes of reserved network blocks (useful later when performing intrusive network scanning) and AS number details.

BGP enumeration

Cross-reference AS numbers with BGP sites to enumerate the associated IP blocks under the AS, and then feed these details back into other query paths (such as DNS or further WHOIS querying).

DNS querying

Query accessible name servers to enumerate domains, subdomains, hostnames, and nonpublic IP address details. Misconfigured DNS servers also serve zone files that list subdomains, hostnames, operating platforms of devices, and internal network details.

SMTP probing

Send mail to nonexistent accounts target domains to map internal network space by analyzing the responses from the mail system (including relay servers and content filtering appliances).

Enumeration Countermeasures

Use the following checklist of countermeasures to effectively configure your Internet-facing systems so that they do not leak sensitive information to adversaries:

• Harden web servers by disabling directory indexing for directories that don’t contain index.html or similar files (default.asp under Microsoft IIS, for example), and use robots.txt directives on peripheral servers (i.e., those that you don’t want to be indexed by search engines) to prevent indexing of content.

• Do not rely on robots.txt directives to protect sensitive web server content.

• Use a generic, centralized network administration contact detail in WHOIS databases and TLS certificates to prevent social engineering and war dialing attacks against IT departments from being effective.

• Configure name servers to disallow DNS zone transfers to untrusted hosts, and actively test your network (i.e., port scan for TCP and UDP port 53) from the Internet to identify rogue name servers.

• Prune DNS zone files so that unnecessary information is not disclosed (primarily nonpublic IP address and hostname details) and DNS grinding attacks are not effective. Ideally, you should use PTR records only if absolutely needed (for SMTP mail servers and other critical systems that need to resolve both ways).

• Configure SMTP servers to not send NDNs upon encountering problems (e.g., nonexistent mailbox), which will prevent attackers from enumerating the internal mail servers and configuration.

• Consider and review your IPv6 networks and DNS configuration (if any).

¹ Brian Krebs, “Target Hackers Broke in via HVAC Company”, Krebs on Security, February 5, 2014.

² See “Google Hacking Database (GHDB)” in Offensive Security’s Exploit Database archive.

³ cisco-decrypt.c is available at http://bit.ly/2aAs1IM.

⁴ Both are available from https://www.gnupg.org/download/.

⁵ Metasploit shodan_search module.

⁶ Nmap dns-brute script.

⁷ See knockpy on GitHub.

⁸ See dnsenum on GitHub.

⁹ See dnsmap in the Google Code Archive.

¹⁰ See http://blog.0x0lab.org/2011/12/dns-brute-force/.

¹¹ See RFC 1918.

¹² Arman Obosyan, “Exchange Server and Update Rollup Build Numbers”, Microsoft TechNet Wiki, March 3, 2010.

¹³ Ben Williams, “Automated Enumeration of Email Filtering Solutions”, NCC Group, 2014.