Hacking start ICMP Queries

Ping sweeps (or ICMP ECHO packets) are only the tip of the iceberg when it comes
to ICMP information about a system. You can gather all kinds of valuable information
about a system simply by sending an ICMP packet to it. For example, with the UNIX tool
icmpquery (http://packetstormsecurity.org/UNIX/scanners/icmpquery.c) or icmpush
(http://packetstormsecurity.org/UNIX/scanners/icmpush22.tgz), you can request the
time on the system (to see the time zone the system is in) by sending an ICMP type 13
message (TIMESTAMP). Also, you can request the netmask of a particular device with
the ICMP type 17 message (ADDRESS MASK REQUEST). The netmask of a network
card is important because you can determine all the subnet of the target, and thereby
understand its default gateway and broadcast address. With the default gateway
identified you can target router attacks. And with the broadcast address you can target
denial of service attacks (DoS). With knowledge of the subnets, you can also orient your
attacks to only particular subnets and avoid hitting broadcast addresses, for example.
icmpquery has both a timestamp and an address mask request option:


icmpquery <-query> [-B] [-f fromhost] [-d delay] [-T time] targets where
is one of:
-t : icmp timestamp request (default)
-m : icmp address mask request
The delay is in microseconds to sleep between packets.
targets is a list of hostnames or addresses
-T specifies the number of seconds to wait for a host to respond.
The default is 5.
-B specifies ‘broadcast’ mode. icmpquery will wait for timeout seconds
and print all responses.
If you’re on a modem, you may wish to use a larger -d and –T

To use icmpquery to query a router’s time (typically in Greenwich Mean Time), you
can run this command:

[root] icmpquery -t 192.168.1.1
192.168.1.1 : 11:36:19


To use icmpquery to query a router’s netmask, you can run this command



[root] icmpquery -m 192.168.1.1
192.168.1.1 : 0xFFFFFFE0
Not all routers and systems allow an ICMP TIMESTAMP or NETMASK response, so
your mileage with icmpquery and icmpush may vary greatly from host to host.

Determining If The System Is Alive By Network Ping Sweeps

One of the most basic steps in mapping out a network is performing an automated ping
sweep on a range of IP addresses and network blocks to determine if individual devices
or systems are alive. Ping is traditionally used to send ICMP ECHO (ICMP Type 8)
packets to a target system in an attempt to elicit an ICMP ECHO_REPLY (ICMP Type 0)
indicating the target system is alive. Although ping is acceptable to determine the number
of systems alive in a small-to-midsize network (Class C is 254 and Class B is 65,534
potential hosts), it is inefficient for larger, enterprise networks. Scanning larger Class A
networks (16,277,214 potential hosts) can take hours if not days to complete. You must
learn a number of ways for discovering live systems.
Network pinging is the act of sending certain types of traffic to a target and analyzing
the results (or lack thereof). Typically, pinging utilizes ICMP (Internet Control Message
Protocol) and, although not the only packets available for this function, ICMP tends to be
the most heavily supported. Alternatively, one could use either TCP or UDP as well to
perform the same function of finding a host that is alive on the network.
To perform an ICMP ping sweep, you can use a myriad of tools available for both
UNIX and Windows. One of the tried-and-true techniques of performing ping sweeps in
the UNIX world is to use fping. Unlike more traditional ping sweep utilities, which
wait for a response from each system before moving on to the next potential host, fping
is a utility that will send out massively parallel ping requests in a round-robin fashion.
Thus, fping will sweep many IP addresses significantly faster than ping. fping can be
used in one of two ways: you can feed it a series of IP addresses from standard input
(stdin) or you can have it read from a file. Having fping read from a file is easy; simply
create your file with IP addresses on each line:
192.168.51.1
192.168.51.2
192.168.51.3
...
192.168.51.253
192.168.51.254

Then use the –f parameter to read in the file:

[root]$ fping –a –f in.txt
192.168.1.254 is alive
192.168.1.227 is alive
192.168.1.224 is alive
...
192.168.1.3 is alive
192.168.1.2 is alive
192.168.1.1 is alive
192.168.1.190 is alive

The –a option of fping will show only systems that are alive. You can also combine
it with the –d option to resolve hostnames if you choose. We prefer to use the –a option
with shell scripts and the –d option when we are interested in targeting systems that
have unique hostnames. Other options such as –f may interest you when scripting ping
sweeps. Type fping –h for a full listing of available options. Another utility is nmap from Fyodor.

[root] nmap –sP 192.168.1.0/24

Starting nmap V. 4.68 by fyodor@insecure.org (www.insecure.org/nmap/)

Host (192.168.1.0) seems to be a subnet broadcast
address (returned 3 extra pings).
Host (192.168.1.1) appears to be up.
Host (192.168.1.10) appears to be up.
Host (192.168.1.11 ) appears to be up.
Host (192.168.1.15) appears to be up.
Host (192.168.1.20) appears to be up.
Host (192.168.1.50) appears to be up.
Host (192.168.1.101) appears to be up.
Host (192.168.1.102) appears to be up.
Host (192.168.1.255) seems to be a subnet broadcast
address (returned 3 extra pings).
Nmap run completed -- 256 IP addresses (10 hosts up) scanned in 21 seconds

For the Windows-inclined, we like the tried-and-true freeware product SuperScan
from Foundstone. It is one of the fastest ping sweep utilities
available. Like fping, SuperScan sends out multiple ICMP ECHO packets (in addition
to three other types of ICMP) in parallel and simply waits and listens for responses. Also like
fping, SuperScan allows you to resolve hostnames and view the output in an HTML file.
For those technically minded, here’s a brief synopsis of the different types of ICMP
packets that can be used to ping a host.

The primary ICMP types are
• Message Type: 0 – Echo Reply
• Message Type: 3 – Destination Unreachable
• Message Type: 4 – Source Quench
• Message Type: 5 – Redirect
• Message Type: 8 – Echo
• Message Type: 11 – Time Exceeded
• Message Type: 12 – Parameter Problem
• Message Type: 13 – Timestamp
• Message Type: 14 – Timestamp Reply
• Message Type: 15 – Information Request
• Message Type: 16 – Information Reply

Any of these ICMP message types could potentially be used to discover a host on the
network; it just depends on the target’s ICMP implementation and how it responds to
these packet types. How the different operating systems respond or don’t respond to the
various ICMP types also aids in remote OS detection.
You may be wondering what happens if ICMP is blocked by the target site. Good
question. It is not uncommon to come across a security-conscious site that has blocked
ICMP at the border router or firewall. Although ICMP may be blocked, some additional
tools and techniques can be used to determine if systems are actually alive. However,
they are not as accurate or as efficient as a normal ping sweep.
When ICMP traffic is blocked, port scanning is the first alternate technique to determine
live hosts. By scanning for common ports on every potential IP address, we can determine which hosts are alive
if we can identify open or listening ports on the target system. This technique can be
time-consuming, but it can often unearth rogue systems or highly protected systems.
For Windows, the tool we recommend is SuperScan. As discussed earlier, SuperScan
will perform both host and service discovery using ICMP and TCP/UDP, respectively.
Using the TCP/UDP port scan options, you can determine whether a host is alive or
not—without using ICMP at all. As you can simply select the check box
for each protocol you wish to use and the type of technique you desire, and you are off
to the races.
Another tool used for this host discovery technique is the UNIX/Windows tool
nmap. The Windows version, which is nmap with the Windows wrapper called Zenmap,
is now well supported so, for the truly command line challenged amongst you, you can
easily download the latest Windows version at nmap.org and get scanning quickly. Of
course, the product installs WinPcap so be prepared: if you haven’t installed this
application before on your Windows system, you should know that this is a packet filter
driver that allows nmap to read and write raw packets from and to the wire. nmap for Windows allows for a number of ping options
to discover hosts on a network. These host discovery options have long been available to
the UNIX world, but now Windows users can also leverage them.
As mentioned previously, nmap does provide the capability to perform ICMP sweeps.
However, it offers a more advanced option called TCP ping scan. A TCP ping scan is
initiated with the –PT option and a port number such as 80. We use 80 because it is a
common port that sites will allow through their border routers to systems on their
demilitarized zone (DMZ), or even better, through their main firewall(s). This option will
spew out TCP ACK packets to the target network and wait for RST packets indicating
the host is alive. ACK packets are sent because they are more likely to get through a
nonstateful firewall such as Cisco IOS. Here’s an example:

[root] nmap -sP -PT80 192.168.1.0/24
TCP probe port is 80
Starting nmap V. 4.68
Host (192.168.1.0) appears to be up.
Host (192.168.1.1) appears to be up.
Host shadow (192.168.1.10) appears to be up.
Host (192.168.1.11) appears to be up.
Host (192.168.1.15) appears to be up.
Host (192.168.1.20) appears to be up.
Host (192.168.1.50) appears to be up.
Host (192.168.1.101) appears to be up.
Host (192.168.1.102) appears to be up.
Host (192.168.1.255) appears to be up.
Nmap run completed (10 hosts up ) scanned in 5 seconds

As you can see, this method is quite effective in determining if systems are alive,
even if the site blocks ICMP. It is worth trying a few iterations of this type of scan with
common ports such as SMTP (25), POP (110), AUTH (113), IMAP (143), or other ports
that may be unique to the site.
For the advanced technical reader, Hping2 from www.hping.org is an amazing TCP
ping utility for UNIX that should be in your toolbox. With additional TCP functionality
beyond nmap, Hping2 allows the user to control specific options of the UDP, TCP, or
Raw IP packet that may allow it to pass through certain access control devices.
To perform a simple TCP ping scan, set the TCP destination port with the –p option.
By doing this you can circumvent some access control devices similar to the traceroute
technique. Hping2 can be used to perform TCP and UDP ping
sweeps, and it has the ability to fragment packets, potentially bypassing some access
control devices. Here’s an example:

[root]# hping2 192.168.0.2 -S -p 80 -f
HPING 192.168.0.2 (eth0 192.168.0.2): S set , 40 data bytes
60 bytes from 192.168.0.2: flags = SA seq=0 ttl=64 id=418 win=5840 time=3.2 ms
60 bytes from 192.168.0.2: flags=SA seq=1 ttl=64 id=420 win=5840 time=2.1 ms
60 bytes from 192.168.0.2: flags=SA seq=2 ttl=64 id=422 win=5840 time=2.0 ms

--- 192.168.0.2 hping statistic ---
3 packets tramitted, 3 packets received , 0% packet loss

In some cases, simple access control devices cannot handle fragmented packets
correctly, thus allowing our packets to pass through and determine if the target system
is alive. Notice that the TCP SYN (S) flag and the TCP ACK (A) flag are returned whenever
a port is open (flags=SA). Hping2 can easily be integrated into shell scripts by using the
–cN packet count option, where N is the number of packets to send before moving on.
Although this method is not as fast as some of the ICMP ping sweep methods mentioned
earlier, it may be necessary given the configuration of the target network.
The final tool we will analyze is icmpenum, from Simple Nomad. This UNIX utility
is a handy ICMP enumeration tool that allows you to quickly identify systems that are
alive by sending the traditional ICMP ECHO packets as well as ICMP TIMESTAMP
REQUEST and ICMP INFO REQUEST (similar to SuperScan). Thus, if ingress (inbound)
ICMP ECHO packets are dropped by a border router or firewall, it may still be possible
to identify systems using one of these alternate ICMP types:

[shadow] icmpenum –i 2 -c 192.168.1.0
192.168.1.1 is up
192.168.1.10 is up
192.168.1.11 is up
192.168.1.15 is up
192.168.1.20 is up
192.168.1.103 is up

In this example, we enumerated the entire 192.168.1.0 Class C network using an
ICMP TIME STAMP REQUEST. However, the real power of icmpenum is to identify
systems using spoofed packets to avoid detection. Spoofed packets means they do not
contain the true, legitimate IP address as its source address, thereby making it look like
the scan is coming from another host on the network. This technique is possible because
icmpenum supports the ability to spoof packets with the -s option and passively listen
for responses with the –p switch.
To summarize, this step allows us to determine exactly what systems are alive via
ICMP or through selective port scans. Out of 255 potential addresses within the Class C
range, we have determined that several hosts are alive and have now become our targets
for subsequent interrogation.

Determine Mail Exchange (MX) Records

Determining where mail is handled is a great starting place to locate the target
organization’s firewall network. Often in a commercial environment, mail is handled on
the same system as the firewall, or at least on the same network. Therefore, we can use
the host command to help harvest even more information:

[bash]$ host example.com

example.com has address 192.168.1.7
example.com mail is handled (pri=10) by mail.example.com
example.com mail is handled (pri=20) by smtp-forward.example.com

DNS Interrogation-Zone Transfers

Now we begin to query the DNS. DNS is a distributed database used to map IP addresses to hostnames, and vice versa. If DNS isconfigured insecurely, it is possible to obtain revealing information about the organization.
One of the most serious misconfigurations a system administrator can make is
allowing untrusted Internet users to perform a DNS zone transfer. While this technique
has become almost obsolete, we include it here for three reasons:

1. This vulnerability allows for signifi cant information gathering on a target.
2. It is often the springboard to attacks that would not be present without it.
3. Believe it or not, you can fi nd many DNS servers still allowing this feature.

A zone transfer allows a secondary master server to update its zone database from the
primary master. This provides for redundancy when running DNS, should the primary
name server become unavailable. Generally, a DNS zone transfer needs to be performed
only by secondary master DNS servers. Many DNS servers, however, are misconfigured
and provide a copy of the zone to anyone who asks. This isn’t necessarily bad if the only
information provided is related to systems that are connected to the Internet and have
valid hostnames, although it makes it that much easier for attackers to find potential
targets. The real problem occurs when an organization does not use a public/private
DNS mechanism to segregate its external DNS information (which is public) from its
internal, private DNS information. In this case, internal hostnames and IP addresses are
disclosed to the attacker. Providing internal IP address information to an untrusted user
over the Internet is akin to providing a complete blueprint, or roadmap, of an organization’s
internal network.
Let’s take a look at several methods we can use to perform zone transfers and the
types of information that can be gleaned. Although many different tools are available to
perform zone transfers, we are going to limit the discussion to several common types.
A simple way to perform a zone transfer is to use the nslookup client that is usually
provided with most UNIX and Windows implementations. We can use nslookup in
interactive mode, as follows:

[bash]$ nslookup
Default Server: ns1.example.com
Address: 10.10.20.2
> 192.168.1.1
Server: ns1.example.com
Address: 10.10.20.2
Name: gate.example.com
Address: 192.168.1.1
> set type=any
> ls -d example.com. >\> /tmp/zone_out

We first run nslookup in interactive mode. Once started, it will tell us the default
name server that it is using, which is normally the organization’s DNS server or a DNS
server provided by an ISP. However, our DNS server (10.10.20.2) is not authoritative for
our target domain, so it will not have all the DNS records we are looking for. Therefore,
we need to manually tell nslookup which DNS server to query. In our example, we want
to use the primary DNS server for example.com (192.168.1.1).
Next we set the record type to “any.” This will allow us to pull any DNS records
available (man nslookup) for a complete list.
Finally, we use the ls option to list all the associated records for the domain. The –d
switch is used to list all records for the domain. We append a period (.) to the end to
signify the fully qualified domain name—however, you can leave this off most times. In
addition, we redirect our output to the file /tmp/zone_out so that we can manipulate
the output later.
After completing the zone transfer, we can view the file to see whether there is any
interesting information that will allow us to target specific systems. Let’s review simulated
output for example.com:

bash]$ more zone_out
acct18 ID IN A 192.168.230.3
ID IN HINFO “Gateway2000” “WinWKGRPS”
ID IN MX 0 exampleadmin-smtp
ID IN RP bsmith.rci bsmith.who
ID IN TXT “Location:Telephone Room”
ce ID IN CNAME aesop
au ID IN A 192.168.230.4
ID IN HINFO “Aspect” “MS-DOS”
ID IN MX 0 andromeda
ID IN RP jcoy.erebus jcoy.who
ID IN TXT “Location: Library”
acct21 ID IN A 192.168.230.5
ID IN HINFO “Gateway2000” “WinWKGRPS”
ID IN MX 0 exampleadmin-smtp
ID IN RP bsmith.rci bsmith.who
ID IN TXT “Location:Accounting”

We won’t go through each record in detail, but we will point out several important
types. We see that for each entry we have an “A” record that denotes the IP address of
the system name located to the right. In addition, each host has an HINFO record that
identifies the platform or type of operating system running (see RFC 952). HINFO records
are not needed, but they provide a wealth of information to attackers. Because we saved
the results of the zone transfer to an output file, we can easily manipulate the results
with UNIX programs such as grep, sed, awk, or perl.
Suppose we are experts in SunOS/Solaris. We could programmatically find out the
IP addresses that have an HINFO record associated with Sparc, SunOS, or Solaris:

[bash]$ grep -i solaris zone_out |wc –l
388

We can see that we have 388 potential records that reference the word “Solaris.”
Obviously, we have plenty of targets.
Suppose we wanted to find test systems, which happen to be a favorite choice for
attackers. Why? Simple: they normally don’t have many security features enabled, often
have easily guessed passwords, and administrators tend not to notice or care who logs
in to them. They’re a perfect home for any interloper. Thus, we can search for test systems
as follows:

[bash]$ grep –I tes t /tmp/zone_out |wc –l
96

So we have approximately 96 entries in the zone file that contain the word “test.”
This should equate to a fair number of actual test systems. These are just a few simple
examples. Most intruders will slice and dice this data to zero in on specific system types
with known vulnerabilities.
Keep a few points in mind. First, the aforementioned method queries only one
nameserver at a time. This means you would have to perform the same tasks for all
nameservers that are authoritative for the target domain. In addition, we queried only
the example.com domain. If there were subdomains, we would have to perform the same
type of query for each subdomain (for example, greenhouse.example.com). Finally, you
may receive a message stating that you can’t list the domain or that the query was
refused. This usually indicates that the server has been configured to disallow zone
transfers from unauthorized users. Therefore, you will not be able to perform a zone
transfer from this server. However, if there are multiple DNS servers, you may be able to
find one that will allow zone transfers.
Now that we have shown you the manual method, there are plenty of tools that
speed the process, including host, Sam Spade, axfr, and dig.
The host command comes with many flavors of UNIX. Some simple ways of using
host are as follows:
host -l example.com
and
host -l -v -t any example.com
If you need just the IP addresses to feed into a shell script, you can just cut out the IP
addresses from the host command:

host -l example.com |cut - f 4 -d"" "" >\> /tmp/ip_out

Not all footprinting functions must be performed through UNIX commands. A
number of Windows products, such as Sam Spade, provide the same information.
The UNIX dig command is a favorite with DNS administrators and is often used to
troubleshoot DNS architectures. It too can perform the various DNS interrogations
mentioned in this section. It has too many command-line options to list here; the man
page explains its features in detail.
Finally, you can use one of the best tools for performing zone transfers: axfr (http://
packetstormsecurity.nl/groups/ADM/axfr-0.5.2.tar.gz) by Gaius. This utility will
recursively transfer zone information and create a compressed database of zone and host
files for each domain queried. In addition, you can even pass top-level domains such as
.com and .edu to get all the domains associated with .com and .edu, respectively.
However, this is not recommended due to the vast number of domains within each of
these TLDs.
To run axfr, you would type the following:

[bash]$ axfr example.com
axfr: Using default directory: /root/axfrdb
Found 2 name servers for domain ''example.com.'':
Text deleted.
Received XXX answers (XXX records).
To query the axfr database for the information just obtained, you would type the
following:

[bash]$ axfrcat example.com

Hacking start IP-Related Searches

That pretty well takes care of the domain-related searches, but what about IP-related
registrations? As explained earlier, IP-related issues are handled by the various RIRs
under ICANN’s ASO. Let’s see how we go about querying this information.
The WHOIS server at ICANN (IANA) does not currently act as an authoritative
registry for all the RIRs as it does for the TLDs, but each RIR does know which IP ranges
it manages. This allows us to simply pick any one of them to start our search. If we pick
the wrong one, it will tell us which one we need to go to.
Let’s say that while perusing your security logs (as I’m sure you do religiously,
right?), you run across an interesting entry with a source IP of 61.0.0.2. You start by
entering this IP into the WHOIS search at http://www.arin.net, which tells
you that this range of IPs is actually managed by APNIC. You then go to APNIC’s site athttp://www.apnic.net to continue your search. Here you find out that this
IP address is actually managed by the National Internet Backbone of India.
This process can be followed to trace back any IP address in the world to its owner,
or at least to a point of contact that may be willing to provide the remaining details. As
with anything else, cooperation is almost completely voluntary and will vary as you deal
with different companies and different governments. Always keep in mind that there are
many ways for a hacker to masquerade their true IP. In today’s cyberworld, it’s more
likely to be an illegitimate IP address than a real one. So the IP that shows up in your logs
may be what we refer to as a laundered IP address—almost untraceable.
We can also find out IP ranges and BGP autonomous system numbers that an
organization owns by searching the RIR WHOIS servers for the organization’s literal
name. For example, if we search for “Google” at http://www.arin.net, we see the IP
ranges that Google owns under its name as well as its AS number, AS15169.It might be useful to explain why finding BGP data would be useful. IP address
information is probably pretty obvious. BGP info is probably not obvious.
The administrative contact is an important piece of information because it may tell
you the name of the person responsible for the Internet connection or firewall. Our query
also returns voice and fax numbers. This information is an enormous help when you’re
performing a dial-in penetration review. Just fire up the war-dialers in the noted range,
and you’re off to a good start in identifying potential modem numbers. In addition, an
intruder will often pose as the administrative contact using social engineering on
unsuspecting users in an organization. An attacker will send spoofed e-mail messages
posing as the administrative contact to a gullible user. It is amazing how many users will
change their passwords to whatever you like, as long as it looks like the request is being
sent from a trusted technical support person.The record creation and modification dates indicate how accurate the information is.
If the record was created five years ago but hasn’t been updated since, it is a good bet
some of the information (for example, administrative contact) may be out of date.
The last piece of information provides us with the authoritative DNS servers, which
are the sources or records for name lookups for that domain or IP. The first one listed is
the primary DNS server; subsequent DNS servers will be secondary, tertiary, and so on.
We will need this information for our DNS interrogation.
Additionally, we can try to use the network range listed as a starting point for our
network query of the ARIN database.

Hacking start Domain-Related Searches

It’s important to note that domain-related items (such as sitewelder.com) are
registered separately from IP-related items (such as IP net-blocks, BGP autonomous
system numbers, etc.). This means we will have two different paths in our methodology
for finding these details. Let’s start with domain-related details, using keyhole.com as an
example.
The first order of business is to determine which one of the many WHOIS servers
contains the information we’re after. The general process flows like this: the authoritative
Registry for a given TLD, “.com” in this case, contains information about which Registrar
the target entity registered its domain with. Then you query the appropriate Registrar to
find the Registrant details for the particular domain name you’re after. We refer to these
as the “Three Rs” of WHOIS: Registry, Registrar, and Registrant.
There are many places on the Internet that offer one-stop-shopping for WHOIS
information, but it’s important to understand how to find the information yourself for
those times that the auto-magic tools don’t work. Since the WHOIS information is based
on a hierarchy, the best place to start is the top of the tree—ICANN. As mentioned above,
ICANN (IANA) is the authoritative registry for all of the TLDs and is a great starting
point for all manual WHOIS queries If we surf to http://whois.iana.org, we can search for the authoritative registry for all
of .com. This search shows us that the authoritative registry for .com is
Verisign Global Registry Services at http://www.verisign-grs.com. If we go to that site
and click the Whois link to the right, we get the Verisign Whois Search page where we
can search for keyhole.com and find that keyhole.com is registered through http://
www.markmonitor.com. If we go to that site and search their “Search Whois” field on the
right, we can query this registrar’s WHOIS server via their web interface to
find the registrant details for keyhole.com—voilà!
This registrant detail provides physical addresses, phone numbers, names, e-mail
addresses, DNS server names, IPs, and so on. If you follow this process carefully, you shouldn’t have too much trouble finding registrant details for any (public) domain name
on the planet. Remember, some domains like .gov and .mil may not be accessible to the
public via WHOIS.
To be thorough, we could have done the same searches via the command-line WHOIS
client with the following three commands:
[bash]$ whois com –h whois.iana.org
[bash]$ whois keyhole.com –h whois.verisign-grs.com
[bash]$ whois keyhole.com –h whois.omnis.com
There are also several websites that attempt to automate this process with varying
degrees of success:
• http://www.allwhois.comhttp://www.uwhois.com
• http://www.internic.net/whois.html
Last but not least, there are several GUIs available that will also assist you in your
searches:
• SamSpade http://www.samspade.org
• SuperScan http://www.foundstone.com
• NetScan Tools Pro http://www.nwpsw.com
Once you’ve homed in on the correct WHOIS server for your target, you may be able
to perform other searches if the registrar allows it. You may be able to find all the domains
that a particular DNS server hosts, for instance, or any domain name that contains a
certain string. These types of searches are rapidly being disallowed by most WHOIS
servers, but it is still worth a look to see what the registrar permits. It may be just what
you’re after.

Hacking start WHOIS & DNS Enumeration

While much of the Internet’s appeal stems from its lack of centralized control, in
reality several of its underlying functions must be centrally managed in order to ensure
interoperability, prevent IP conflicts, and ensure universal resolvability across
geographical and political boundaries. This means that someone is managing a vast
amount of information. If you understand a little about how this is actually done, you
can effectively tap into this wealth of information! The Internet has come a long way
since its inception. The particulars of how all this information is managed, and by whom,
is still evolving as well.
So who is managing the Internet today, you ask? These core functions of the Internet
are managed by a nonprofit organization, the Internet Corporation for Assigned Names
and Numbers (ICANN; http://www.icann.org).
ICANN is a technical coordination body for the Internet. Created in October 1998 by
a broad coalition of the Internet’s business, technical, academic, and user communities,
ICANN is assuming responsibility for a set of technical functions previously performed
under U.S. government contract by the Internet Assigned Numbers Authority (IANA;
http://www.iana.org) and other groups. (In practice, IANA still handles much of the
day-to-day operations, but these will eventually be transitioned to ICANN.)
Specifically, ICANN coordinates the assignment of the following identifiers that
must be globally unique for the Internet to function:
• Internet domain names
• IP address numbers
• Protocol parameters and port numbers
In addition, ICANN coordinates the stable operation of the Internet’s root DNS server
system.
As a nonprofit, private-sector corporation, ICANN is dedicated to preserving the
operational stability of the Internet; to promoting competition; to achieving broad
representation of global Internet communities; and to developing policy through privatesector,
bottom-up, consensus-based means. ICANN welcomes the participation of any
interested Internet user, business, or organization.
While there are many parts to ICANN, three of the suborganizations are of particular
interest to us at this point:
• Address Supporting Organization (ASO), http://www.aso.icann.org
• Generic Names Supporting Organization (GNSO), http://www.gnso.icann.org
• Country Code Domain Name Supporting Organization (CCNSO), http://www
.ccnso.icann.org
The ASO reviews and develops recommendations on IP address policy and advises
the ICANN board on these matters. The ASO allocates IP address blocks to various
Regional Internet Registries (RIRs) who manage, distribute, and register public Internet
number resources within their respective regions. These RIRs then allocate IPs to
organizations, Internet service providers (ISPs), or in some cases, National Internet
Registries (NIRs) or Local Internet Registries (LIRs) if particular governments require it
(mostly in communist countries, dictatorships, etc.):
• APNIC (http://www.apnic.net) Asia-Pacifi c region
• ARIN (http://www.arin.net) North and South America, Sub-Sahara Africa
regions
• LACNIC (http://www.lacnic.net) Portions of Latin America and the
Caribbean
• RIPE (http://www.ripe.net) Europe, parts of Asia, Africa north of the equator,
and the Middle East regions
• AfriNIC (http://www.afrinic.net, currently in observer status) Eventually
both regions of Africa currently handled by ARIN and RIPE
The GNSO reviews and develops recommendations on domain-name policy for all
generic top-level domains (gTLDs) and advises the ICANN Board on these matters. It’s
important to note that the GNSO is not responsible for domain-name registration, but
rather is responsible for the generic top-level domains (for example, .com, .net, .edu, .org,
and .info), which can be found at http://www.iana.org/gtld/gtld.htm.
The CCNSO reviews and develops recommendations on domain-name policy for all
country-code top-level domains (ccTLDs) and advises the ICANN Board on these
matters. Again, ICANN does not handle domain-name registrations. The definitive list
of country-code top-level domains can be found at http://www.iana.org/cctld/cctldwhois.
htm.
Here are some other links you may find useful:
• http://www.iana.org/assignments/ipv4-address-space IP v4 allocation
• http://www.iana.org/ipaddress/ip-addresses.htm IP address services
• http://www.rfc-editor.org/rfc/rfc3330.txt Special-use IP addresses
• http://www.iana.org/assignments/port-numbers Registered port numbers
• http://www.iana.org/assignments/protocol-numbers Registered protocol
numbers
With all of this centralized management in place, mining for information should be
as simple as querying a central super-server farm somewhere, right? Not exactly. While
the management is fairly centralized, the actual data is spread across the globe in
numerous WHOIS servers for technical and political reasons. To further complicate
matters, the WHOIS query syntax, type of permitted queries, available data, and
formatting of the results can vary widely from server to server. Furthermore, many of the
registrars are actively restricting queries to combat spammers, hackers, and resource
overload; to top it all off, information for .mil and .gov have been pulled from public
view entirely due to national security concerns.
You may ask, “How do I go about finding the data I’m after?” With a few tools, a little
know-how, and some patience, you should be able to mine successfully for domain- or
IP-related registrant details for nearly any registered entity on the planet!