Understanding Domain Properties in Simple Terms

Imagine you're planning a sophisticated heist on a corporate headquarters. You wouldn't just show up and try the doors. You'd first gather public information: when does security change shifts? What's the company's official name? What vehicles are typically in the parking lot? Which doors are for deliveries? This is exactly what gathering domain properties entails in the digital world.

Attackers collect publicly available information about your organization's internet presence, domain names, registration details, mail server configurations, and associated subdomains. This information is all legally obtainable but becomes dangerous when used to map out attack vectors, craft convincing phishing emails, or identify outdated and vulnerable systems.

This technique is often the very first step in the cyber kill chain, occurring long before any malware is deployed or credentials are stolen. It's a low-risk, high-reward activity for threat actors that directly enables more dangerous follow-on actions like spear-phishing, credential stuffing, and brute-force attacks.

Decoding the Jargon: Key Terms for Domain Properties

Before we dive deeper, let's demystify some common terms you'll encounter when discussing this reconnaissance technique.

The Attacker's Playbook: Executing Domain Properties

Step-by-Step Breakdown

A threat actor conducting domain property reconnaissance follows a logical, layered process:

• Step 1: Foundation (WHOIS & Basic DNS): The attacker starts with the primary target domain (e.g., targetcorp.com). They perform a WHOIS lookup to get registration details, admin email (often abused for phishing), and name servers. Concurrently, they query basic DNS records (A, MX, NS, TXT) to find the main web server IP, mail servers, and any revealing TXT records.
• Step 2: Expansion (Subdomain Discovery): Using tools and public databases, they aggressively hunt for subdomains (vpn.targetcorp.com, dev.targetcorp.com, owa.targetcorp.com). These often point to external-facing applications and are prime targets for further vulnerability scanning.
• Step 3: Analysis (Service & Configuration Mapping): For each discovered IP and subdomain, the attacker identifies running services (HTTP, FTP, RDP) and examines configurations, especially email (SPF, DKIM, DMARC records) to assess the strength of anti-spoofing controls.
• Step 4: Historical Research (Passive DNS): They search historical DNS data to find "ghost" assets, old subdomains or IPs that may have been forgotten by IT but never decommissioned, representing a potential weak point in the digital armor.
• Step 5: Target Selection & Weaponization: The compiled data is analyzed to select the most promising initial access vectors. For example, a misconfigured SPF record might enable convincing spoofed emails, or an outdated "test.server.targetcorp.com" might be running vulnerable software.

Red Team Analogy & Mindset

Think like a private investigator hired to gather dirt on a public figure, using only legal, open-source methods. Your goal isn't to break in (yet), but to build a comprehensive dossier. You scour property records (WHOIS), follow the subject's daily commute patterns (DNS traffic patterns), photograph all their known residences and offices (subdomains), and dig through old newspaper archives (Passive DNS) for forgotten addresses. Every piece of data is a potential lever for future manipulation or intrusion.

The mindset is one of patience and thoroughness. A red teamer knows that the time invested here pays exponential dividends later in the operation, reducing noise, increasing success rates for phishing, and revealing paths of least resistance.

Tools & Command-Line Examples

Attackers use a blend of simple command-line utilities and powerful automated frameworks.

Common Tools:

• dig / nslookup: The bread and butter for manual DNS queries.
• WHOIS clients: Built into most Linux distros for registration lookups.
• Sublist3r / Amass / Subfinder: Specialized tools for aggressive subdomain enumeration by scraping search engines, certificates, and DNS records.
• theHarvester: A classic reconnaissance tool for gathering emails, subdomains, hosts, and open ports from public sources.

Illustrative Commands:

# 1. Basic WHOIS lookup for registration info
whois example.com

# 2. Querying MX records to find mail servers
dig MX example.com +short
# Output might be: 10 mail.example.com

# 3. Using dig to get all DNS records (zone transfer attempt - often blocked)
dig ANY example.com @ns1.example.com

# 4. Checking SPF record to see authorized email senders
dig TXT example.com | grep spf
# Output might show: "v=spf1 include:_spf.google.com ~all"

Real-World Campaign Example

The sophisticated Russian APT group known as APT29 (Cozy Bear, The Dukes), famously associated with the SolarWinds campaign, is a master of patient, thorough reconnaissance. In operations documented by cybersecurity firms, the group has been observed conducting extensive domain property reconnaissance long before launching their primary attacks.

They meticulously map target organizations' digital footprints, identifying not just primary domains but also subsidiary companies, acquired business units, and associated domain names. This intelligence allows them to craft highly convincing phishing lures and establish legitimate-looking but attacker-controlled infrastructure that blends in with the target's normal network patterns. This foundational work was critical to the success of their supply chain compromise against SolarWinds.

Reference: For an in-depth analysis of APT29's tactics, see the Mandiant Intelligence Profile on APT29.

The Defender's Handbook: Stopping Domain Properties

Blue Team Analogy & Detection Philosophy

Your job as a defender isn't to stop the reconnaissance, that's happening constantly in the public domain. Your job is to minimize its value and maximize its cost to the attacker. Think of yourself as the head of security for a celebrity. You can't stop paparazzi from taking public photos, but you can:

• Control what information is in public records (use WHOIS privacy).
• Ensure all entrances to properties are secure, even the rarely used ones (harden all subdomains).
• Monitor for people visibly casing your properties (detect reconnaissance activity).
• Regularly audit your own public footprint to see what an attacker sees.

The detection philosophy shifts from "block the recon" to "understand the recon to predict the attack." A surge in DNS queries for your SPF record from a new region might precede a phishing campaign.

SOC Reality Check: What to Look For

In a typical SOC, you won't see alerts titled "Domain Reconnaissance in Progress." Instead, you'll see subtle anomalies that require correlation.

• Log Noise: A slight but sustained increase in DNS query volume from external IPs, especially for TXT, MX, and ANY record types.
• EDR/SIEM Clues: Outbound connections from internal systems to known DNS brute-forcing or subdomain enumeration services (though most recon is done from attacker-controlled infrastructure).
• The True Signal: The actionable intelligence comes when you correlate this low-level recon data with a subsequent event, like a spear-phishing email that perfectly uses a discovered subdomain name in its lure.

Threat Hunter's Eye: Practical Query

Here is a Sigma rule designed to detect potential subdomain enumeration activity. This rule looks for a high volume of unique DNS queries for a single target domain from a single source within a short timeframe, which is indicative of automated tools like Sublist3r or Amass.

# Sigma Rule: Potential DNS Subdomain Enumeration Activity
# Author: MITRE ATT&CK Field Guide
# Reference: T1590.001 - Gather Victim Identity Information: Domain Properties
# Log Source: DNS Server Logs (e.g., Windows DNS, Bind)
title: Potential DNS Subdomain Enumeration
id: a1b2c3d4-1234-5678-abcd-123456789012
status: experimental
description: Detects a high number of failed or unique NXDOMAIN responses for subdomains of a single parent domain, suggesting automated subdomain brute-forcing.
author: Blue Team
date: 2023/10/27
logsource:
    category: dns
detection:
    selection:
        rcode: NXDOMAIN  # Query returned non-existent domain
    aggregation:
        group_by:
            - src_ip
            - query  # The domain being queried
        count: query
        condition: count > 50  # Threshold: adjust based on baseline
        timeframe: 5m
    filter:
        - query|endswith: '.com'  # Focus on relevant TLDs, adjust as needed
        - '*/_tcp.*' not in query  # Filter out common SRV query noise
        - '*/_udp.*' not in query
    condition: selection and aggregation and filter
falsepositives:
    - Legitimate security scanners
    - Misconfigured applications
level: low
tags:
    - attack.reconnaissance
    - attack.t1590.001

Key Data Sources for Detection

• DNS Server Logs (Authoritative & Recursive): The primary source. Look for patterns in query types (ANY, AXFR, TXT), volumes, and sources.
• Network Traffic (NetFlow, PCAP): External IPs making sustained, high-volume DNS requests to your servers.
• Firewall & Proxy Logs: Outbound connections from your network to domain research tools or websites (e.g., crt.sh, dnsdumpster.com) could indicate an insider threat or compromised host conducting reconnaissance.
• Cloud Provider Logs (AWS CloudTrail, Azure Activity Log): For domains hosted in the cloud, API calls to list domain-related resources can be a recon signal.

Building Resilience: Mitigation Strategies for Domain Properties

Actionable Mitigation Controls

You can't hide your domain, but you can control the information exposed and manage your assets proactively.

• Enable WHOIS Privacy/Redaction: Most domain registrars offer a privacy service that replaces your personal/company details in the public WHOIS database with the registrar's proxy information. This is a critical first step.
• Harden DNS Configuration:
  • Restrict zone transfers (AXFR) to only authorized secondary name servers.
  • Implement DNS Response Rate Limiting (RRL) to hinder brute-force enumeration tools.
  • Use generic, non-revealing names for public-facing hostnames where possible (e.g., use mail.contoso.com instead of exchange01.contoso.com).
• Implement & Maintain Strong Email Authentication: Properly configure SPF, DKIM, and DMARC with a policy of `reject` (`p=reject`). This doesn't hide the records but makes email spoofing significantly harder, reducing the ROI of the attacker's reconnaissance.
• Conduct Regular Asset Discovery & Hygiene: Proactively discover your own subdomains and external assets more often than the attackers do. Use the same tools (Amass, etc.) in a controlled manner. Decommission forgotten "ghost" assets.
• Segment Public vs. Internal Information: Ensure development, staging, and internal-use subdomains are not publicly resolvable or are protected behind authentication gateways.

Red vs. Blue: A Quick Comparison

Domain Properties Cheat Sheet

Conclusion and Next Steps

Gathering domain properties is a pervasive, low-skill entry point into the cyber kill chain that enables almost every subsequent attack stage. While you cannot prevent it, you can drastically reduce its utility to adversaries through diligent security hygiene, proactive monitoring, and robust configurations.

Your next steps should be practical:

1. Audit Your Domain: Run a tool like Amass or theHarvester against your own primary domain (ethically) to see exactly what an attacker sees.
2. Check Your Configurations: Verify your WHOIS privacy is on and your SPF/DKIM/DMARC records are correct and strict. Use a free tool like MXToolbox.
3. Deploy Detection: Work with your SIEM team to implement a version of the Sigma rule provided in this guide, tailored to your DNS environment.

Reconnaissance sets the stage for all cyber attacks. By mastering the defense of this initial phase, you force attackers to work harder, make more noise, and increase their chances of being detected before they can cause real harm.