4.1 WHOIS Records, Domain Registrars & Autonomous Systems

4.1 WHOIS Records, Domain Registrars & Autonomous Systems

Passive reconnaissance is the initial phase of an ethical hacking or penetration testing engagement. Under the CREST Practitioner Security Analyst (CPSA) framework, passive reconnaissance requires gathering intelligence about the target organization without transmitting packets directly to their network gateways or security perimeters. By leveraging public registries, routing databases, and historical administrative archives, a penetration tester can establish the boundaries of an organization's digital footprint, discover unpublicized IP allocations, and identify potential attack surfaces before active probing begins.

---

1. Regional Internet Registries (RIRs) & Global IP Allocation

The allocation of global Internet Protocol (IPv4 and IPv6) address space and Autonomous System Numbers (ASNs) is governed hierarchically. At the root sits the Internet Assigned Numbers Authority (IANA), operated by the Internet Corporation for Assigned Names and Numbers (ICANN). IANA delegates large regional pools of addresses to five Regional Internet Registries (RIRs), each responsible for a distinct geographic jurisdiction.

+-------------------------------------------------------------------------+
|          IANA / ICANN (Global Root Allocation & Policy Oversight)       |
+-------------------------------------------------------------------------+
                                     |
     +------------+------------+-----+------+------------+
     |            |            |            |            |
     v            v            v            v            v
+---------+  +---------+  +---------+  +---------+  +---------+
| RIPE NCC|  |  ARIN   |  |  APNIC  |  | LACNIC  |  | AFRINIC |
| (Europe/|  | (North  |  | (Asia-  |  | (Latin  |  | (Africa)|
| MidEast)|  | America)|  | Pacific)|  | America)|  +---------+
+---------+  +---------+  +---------+  +---------+

The Five Regional Internet Registries

Database Query Mechanics & Referral Chains

When querying IP allocations, client tools must connect to the appropriate RIR database. If an analyst queries ARIN for an IP address owned by a European entity, ARIN's server returns a referral pointer to whois.ripe.net.

Command-line WHOIS clients query specific RIRs using server flags:

# Querying ARIN directly for an IPv4 prefix with detailed network information
whois -h whois.arin.net "n + NET-198-51-100-0-1"

# Querying RIPE NCC directly with recursion disabled to inspect the exact inetnum record
whois -h whois.ripe.net -- "-r -T inetnum 198.51.100.0/24"

# Querying APNIC for autonomous system allocations
whois -h whois.apnic.net "AS13335"

Within RIR databases, objects are categorized into distinct types:

• inetnum (IPv4 address range) and inet6num (IPv6 address range)
• aut-num (Autonomous System record, including BGP routing policies import and export)
• person (Individual administrative or technical contact)
• role (Functional contact group, such as NOC-ROLE or SOC-TEAM)
• route (BGP route object binding an IP prefix to an origin ASN)

---

2. The WHOIS Protocol (RFC 3912) vs. RDAP

For decades, directory lookups across domain names and IP addresses relied on the legacy WHOIS protocol.

The Legacy WHOIS Protocol (RFC 3912)

• Transport: Operates over TCP port 43.
• Protocol Architecture: Connection-oriented, human-readable text exchange. The client opens a TCP connection to port 43, transmits a query string terminated by a carriage return line feed (CRLF / \r\n), and the server responds with unstructured text before terminating the TCP connection.
• Architectural Limitations:
  1. Unstructured Data: Output varies significantly between registrars and RIRs, making programmatic parsing fragile.
  2. Lack of Authentication: No built-in authentication mechanism; cannot support role-based access control.
  3. No Internationalization: RFC 3912 lacks native support for non-ASCII characters, creating failures with Internationalized Domain Names (IDNs).
  4. No Standardized Error Handling: Errors are delivered as conversational text rather than programmatic response codes.

Legacy WHOIS Transaction (RFC 3912):
Client ──[ TCP Syn: Port 43 ]──► Server
Client ◄──[ TCP Syn/Ack ]─────── Server
Client ──[ "target.com\r\n" ]──► Server
Client ◄──[ Plaintext Response ]─ Server
Server ──[ TCP FIN / Close ]───► Client

Modern RDAP (Registration Data Access Protocol)

To overcome the structural deficiencies of RFC 3912, the Internet Engineering Task Force (IETF) standardized the Registration Data Access Protocol (RDAP) in RFCs 7480–7484.

• Transport & Structure: Uses HTTPS (TCP port 443) delivering structured JSON payloads via RESTful API endpoints.
• Standardized Bootstrapping (RFC 7484): Allows clients to determine the authoritative RDAP server for any domain or IP prefix automatically via central IANA bootstrap registries (e.g., https://rdap.iana.org/).
• Tiered & Authenticated Access (RFC 7481): Enables registries to provide basic redacted data to anonymous public queries while granting authorized penetration testers, incident responders, or law enforcement access to full registrant records using OAuth tokens or client certificates.
• Standardized Error Handling: Leverages standard HTTP status codes (200 OK, 400 Bad Request, 404 Not Found, 429 Too Many Requests).

# Querying RDAP via curl for structured JSON domain data
curl -s -H "Accept: application/rdap+json" https://rdap.org/domain/example.com | jq .

# Querying RDAP for network block allocation
curl -s -H "Accept: application/rdap+json" https://rdap.arin.net/registry/ip/198.51.100.0 | jq '.name, .startAddress, .endAddress'

---

3. Domain Registration Mechanics & EPP Status Codes

Domain name administration operates on a tripartite model coordinating three separate entities:

+-------------------------------------------------------------------------+
|                REGISTRY (Authoritative TLD Database Manager)             |
|             Examples: Verisign (.com, .net), Nominet (.uk)              |
+-------------------------------------------------------------------------+
                                     ▲
                                     │ EPP Protocol (TCP Port 700)
                                     ▼
+-------------------------------------------------------------------------+
|               REGISTRAR (ICANN-Accredited Commercial Retailer)          |
|           Examples: MarkMonitor, Cloudflare, GoDaddy, Namecheap         |
+-------------------------------------------------------------------------+
                                     ▲
                                     │ Retail Web Interface / API
                                     ▼
+-------------------------------------------------------------------------+
|                   REGISTRANT (Domain Licensee / Purchaser)              |
|               Examples: Corporate Entity, Penetration Testing Client    |
+-------------------------------------------------------------------------+

1. The Registry: The master operator maintaining the central database for an entire Top-Level Domain (TLD). For example, Verisign operates .com and .net; Nominet operates .uk.
2. The Registrar: An ICANN-accredited commercial organization licensed to sell domain registrations to consumers and businesses. Registrars submit registration orders to registries using the Extensible Provisioning Protocol (EPP) over TCP port 700.
3. The Registrant: The individual or corporate entity purchasing the right to use the domain name for an agreed lease term.

Extensible Provisioning Protocol (EPP) Domain Status Codes

When reviewing WHOIS or RDAP records during reconnaissance, penetration testers inspect domain status codes. These codes reflect the domain's operational state, security locks, and renewal lifecycle:

---

4. Autonomous System Numbers (ASNs) & BGP Routing Analysis

An Autonomous System (AS) is a collection of connected IP routing prefixes under the control of one or more network operators that presents a common, clearly defined routing policy to the Internet. Autonomous Systems exchange routing reachability using the Border Gateway Protocol (BGP).

16-Bit vs. 32-Bit ASNs

• 16-Bit ASNs (RFC 1771): Historically, ASNs were 16-bit integers providing $2^{16} = 65,536$ unique identifiers. Under RFC 6996, the range 64512 to 65534 is reserved for private use (analogous to RFC 1918 private IP addresses) and cannot be advertised to the global Internet routing table. ASN 65535 is reserved.
• 32-Bit ASNs (RFC 4893 / 6793): To avert ASN exhaustion, the pool was expanded to 32-bit integers, yielding over 4.29 billion identifiers (0 to 4294967295). Within this space, the range 4200000000 to 4294967294 is reserved for private use.

BGP Routing Tables & Prefix Mapping

To discover an organization's complete internet-facing footprint, a penetration tester maps the target's Autonomous System Number. An organization might run hundreds of scattered web services across dozens of separate Class C (/24) blocks. Looking up a single domain reveals only one IP address; looking up the ASN reveals all IP prefixes announced by that organization across global BGP tables.

Target FQDN: portal.target.com ──► Resolves to: 198.51.100.25
                                              │
                                              ▼
BGP Origin Lookup ───────────────► Maps to Origin: AS15169
                                              │
                                              ▼
BGP Announcement Enumeration ────► Discovers All Announced Prefixes:
                                   ├── 198.51.100.0/24 (Target Primary)
                                   ├── 203.0.113.0/23  (Forgotten Data Center)
                                   └── 2001:db8:a00::/48 (IPv6 Infrastructure)

Practical IP-to-ASN & Routing Database Queries

1. Team Cymru IP-to-ASN Lookup Service: Operates a high-performance DNS and WHOIS interface allowing analysts to map individual IPs or lists of addresses to ASNs and allocations:

# Querying Team Cymru via whois for an IP address
whois -h whois.cymru.com " -v 198.51.100.25"
# Output returns: ASN | IP | BGP Prefix | CC | Registry | Allocated
# Example: 15169 | 198.51.100.25 | 198.51.100.0/24 | US | arin | 2012-04-10

1. Routing Assets Database (RADb): RADb is the commercial Internet Routing Registry (IRR) used by network operators to publish routing policies and prefix announcements. Querying RADb reveals all IP prefixes registered to an origin ASN:

# Enumerate all IPv4 prefixes announced by AS15169
whois -h whois.radb.net -- "-i origin AS15169"

1. Online Routing Intelligence Portals:
   • bgp.he.net (Hurricane Electric BGP Toolkit): Displays visual graphs of an AS's BGP peers, upstream transit providers, downstream customers, announced prefixes, and historical IXP connections.
   • PeeringDB (peeringdb.com): Lists peering locations, public data center presences, and internet exchange points (IXPs) where target organizations maintain physical switching fabrics.

---

5. WHOIS Privacy Shielding & Historical WHOIS Mining

Modern privacy laws and commercial shielding services have dramatically transformed WHOIS reconnaissance.

Privacy Proxy Services & GDPR Impact

• Privacy / Proxy Shielding Services: Services such as DomainsByProxy, WhoisGuard, or registrar-specific proxies replace the registrant's name, physical address, email, and phone number with corporate placeholder data (e.g., Domains By Proxy, LLC, Scottsdale, Arizona).
• The General Data Protection Regulation (GDPR) Impact: Enforced in May 2018, the EU GDPR mandated data minimization. In response, ICANN adopted the Temporary Specification for gTLD Registration Data, leading to ubiquitous redaction across all public WHOIS queries. Fields like Registrant Name, Registrant Street, and Registrant Phone now routinely show REDACTED FOR PRIVACY or Contact Privacy Inc. even for domains that did not purchase commercial privacy shields.

Bypassing Privacy via Historical WHOIS Analysis

While modern WHOIS lookups are frequently redacted, organizations typically owned domains for years—often decades—before enabling privacy proxies or before GDPR enforcement in 2018. During initial registration, IT staff or founders frequently used real personal or corporate information.

+-------------------------------------------------------------------------+
|                        HISTORICAL WHOIS TIMELINE                        |
+-------------------------------------------------------------------------+
 2012: Initial Registration    ──► Registrant: john.smith@targetcorp.co.uk
                                   Physical Address: 124 Fleet St, London
                                   DNS: ns1.internal-datacenter.net
                                              │
                                              ▼
 2016: Privacy Proxy Purchased ──► Registrant: WhoisPrivacyCorp LLC
                                   Physical Address: Redacted
                                              │
                                              ▼
 2018: GDPR Enforcement        ──► Registrant: REDACTED FOR PRIVACY
                                   (Current Public WHOIS)

Intelligence Yielded by Historical WHOIS Records

1. Personal Identity & Social Engineering: Early records reveal names, direct-dial phone numbers, and personal email addresses (target_founder@gmail.com) used to bootstrap the company.
2. Corporate Entity Linkages: Historical records link subsidiary companies, former corporate names, and acquisitions that may host forgotten external assets.
3. Reverse-WHOIS Pivoting: Using tools like SecurityTrails, DomainTools Iris, or Whoxy, a tester takes a historical administrator email (admin@targetcorp.co.uk) and queries for all other domains ever registered using that specific email address. This technique frequently uncovers:
   • Development portals and staging environments (target-dev-app.com).
   • Unlinked microsites, marketing campaigns, and abandoned brand domains.
   • Shadow IT assets running out-of-date, unpatched software completely absent from the client's official scoping inventory.