DNS (T1590.002)

Ultimate Guide to Gather Victim Network Information - DNS: Attack & Defense

---

Gather Victim Host Information via DNS is a critical reconnaissance step where attackers map your digital infrastructure by querying public domain records, identifying key servers, and planning their intrusion.

---

---

Table of Contents

---

Understanding Gather Victim Host Information in Simple Terms

Imagine a burglar casing a neighborhood before a robbery. They don't just pick a random house. They note which homes have security systems (alarm company stickers), dogs (beware of dog signs), and predictable routines (when lights turn off). Gather Victim Host Information via DNS is the digital equivalent of this reconnaissance phase.

Before launching any attack, adversaries need a map. They turn to the internet's public phone book, the Domain Name System (DNS). By querying DNS records for your company's domain, they can list your public-facing web servers (mail.company.com), identify your email provider (MX records), and even find subdomains for development or staging environments that might be less secure. This technique is low-risk, entirely legal from public infrastructure, and provides the essential blueprint for subsequent intrusions.

---

Decoding the Jargon: Key Terms for Gather Victim Host Information

Term	Definition	Why It Matters
DNS (Domain Name System)	The internet's directory service that translates human-readable domain names (like google.com) into machine-readable IP addresses (like 142.250.185.78).	It's the primary public database attackers query to discover your organization's internet-facing assets.
DNS Record	A specific entry in a DNS zone file that provides information about a domain. Common types include A, AAAA, MX, TXT, NS, and CNAME records.	Each record type reveals different pieces of your infrastructure (e.g., A records for web servers, MX for mail servers).
Passive DNS	A collection of historical DNS query/response data gathered from various points on the internet, not directly from the authoritative name servers.	Attackers use passive DNS databases to see historical associations between domains and IPs, revealing infrastructure changes and related assets.
Subdomain Enumeration	The process of finding all subdomains associated with a primary domain (e.g., dev.example.com, vpn.example.com).	Discovers less-monitored, potentially vulnerable entry points that aren't listed on the main corporate website.
Zone Transfer (AXFR)	A DNS transaction where a secondary DNS server requests a full copy of all records from a primary DNS server.	If misconfigured, an attacker can request a zone transfer and get a complete list of all internal hosts, a reconnaissance jackpot.

---

The Attacker's Playbook: Executing Gather Victim Host Information

The process of Gather Victim Host Information is methodical and automated. Attackers blend basic commands with powerful open-source intelligence (OSINT) tools to build a comprehensive profile without triggering a single internal alert.

Step-by-Step Breakdown

1. Target Selection: The attacker identifies the target organization's primary domain (e.g., `acme-corp.com`).
2. Initial DNS Recon: Using command-line tools like `nslookup` or `dig`, they retrieve basic records (A, MX, NS) to identify primary servers and service providers.
3. Subdomain Discovery: They employ brute-force tools (like `gobuster` or `amass`) with extensive wordlists to guess and validate subdomains (`dev.acme-corp.com`, `vpn.acme-corp.com`, `test.acme-corp.com`).
4. Historical Analysis: They query passive DNS databases (like SecurityTrails, VirusTotal) to find IP addresses the domain has historically resolved to, revealing old or forgotten infrastructure.
5. Service Mapping: For each discovered host and IP, they perform port scans to identify running services (web servers, databases, remote access).
6. Target Prioritization: The compiled list is analyzed. Less secure-looking targets (e.g., a subdomain running an outdated web server) are flagged for the next phase of the attack.

Red Team Analogy & Mindset

Think like a documentary filmmaker planning to shoot in a remote location. You wouldn't just show up. You'd study maps (DNS), read travel blogs about the area (passive DNS), identify potential campsites (subdomains), and note the weather patterns (service banners). Your goal isn't to interact yet, just to observe and plan. The red teamer's mindset here is one of patient curiosity. Every piece of public data is a clue. A subdomain called `legacy-api` suggests a possibly deprecated, less-patched system. An MX record pointing to a specific cloud provider reveals a potential phishing target or a known vulnerability in that platform.

Tools & Command-Line Examples

• dig (Domain Information Groper): The Swiss Army knife for DNS queries.
• Amass: An in-depth attack surface mapping and asset discovery tool.
• dnsrecon: A Python script for comprehensive DNS enumeration.

Example Commands:

# Basic lookup for A and MX records
$ dig acme-corp.com A +short
$ dig acme-corp.com MX +short

# Attempt a zone transfer (often fails, but worth trying)
$ dig @ns1.acme-corp.com acme-corp.com AXFR

# Using dnsrecon for comprehensive enumeration
$ dnsrecon -d acme-corp.com -t std,axfr,brt -D /usr/share/wordlists/subdomains.txt

Real-World Campaign Example

The APT29 group (also known as Cozy Bear or Midnight Blizzard), associated with Russian intelligence, is renowned for its meticulous reconnaissance. In campaigns targeting government and think-tank networks, APT29 extensively used DNS probing and subdomain enumeration to identify specific individuals and departments.

They would harvest email addresses from public sources, then use DNS to find the associated organization's mail server configuration (MX records). This information was then used to craft highly targeted phishing emails that appeared to come from legitimate internal or partner addresses, dramatically increasing their success rate. This demonstrates how Gather Victim Host Information directly enables more effective social engineering and initial access attacks.

Reference: For an in-depth analysis of APT29's tactics, including reconnaissance, read the joint advisory by the UK's NCSC and the US's CISA, FBI, and NSA: CISA Alert (AA20-106A) on APT29.

---

The Defender's Handbook: Stopping Gather Victim Host Information

You can't stop someone from looking up your public DNS records. Detection of this specific phase is nearly impossible on your own network. Therefore, the defender's focus must shift from detecting the reconnaissance to managing the exposure it creates and detecting the follow-on actions that inevitably come next.

Blue Team Analogy & Detection Philosophy

Think of your public DNS information as the company's listing in a phone book. You can't stop people from reading it. But you can ensure the listed numbers are only for the main switchboard (a secure front-end proxy) and not the direct line to the CEO's desk (an internal server). Your philosophy is exposure management. Assume an attacker has your DNS map. Your job is to ensure that map doesn't lead them to a vulnerable, directly accessible system.

SOC Reality Check: What to Look For

Since you won't see the attacker's DNS lookups, look for the next step. Correlate these signals:

• Internal Logs: A sudden spike in scanning activity from a single external IP against multiple hosts discovered via DNS (e.g., hitting `web1`, `mail`, `dev` subdomains in quick succession).
• Edge Device Alerts: IDS/IPS or WAF alerts for vulnerability scanning tools (Nikto, Nessus) or exploit attempts targeting services identified during the recon phase.
• Cloud Logs: Unusual spikes in out-of-band DNS queries from your infrastructure to external resolvers could indicate malware callbacks, but this is a later stage.

Threat Hunter's Eye: Practical Query

Hunt for internal systems conducting suspicious, high-volume scans that mirror a target list built from public DNS data. The following Sigma rule looks for patterns of horizontal scanning.

# Sigma Rule: Horizontal Scanning Pattern Post-DNS Recon
# This rule detects a single source rapidly connecting to multiple different hosts on a specific port,
# mimicking post-reconnaissance service validation.
title: Possible Post-DNS Reconnaissance Horizontal Scan
id: a1b2c3d4-1234-5678-abcd-0123456789ab
status: experimental
description: Detects a source IP making successful connections to many distinct destination IPs on a common port (e.g., 443, 22) within a short time.
author: Your SOC
logsource:
    product: firewall
    category: firewall
detection:
    selection:
        event_type: "connection_allowed"
        dst_port: (443, 22, 3389, 445)
    timeframe: 5m
    condition: selection | count(dst_ip) by src_ip > 20
falsepositives:
    - Legitimate network scanners
    - Load balancer health checks
level: medium
tags:
    - attack.reconnaissance
    - attack.t1590.002

Key Data Sources for Detection

• Firewall/Network Edge Logs: Source of truth for inbound connection attempts to your public IP space.
• Web Application Firewall (WAF) Logs: Can show targeted scanning against specific subdomains or paths.
• IDS/IPS Alerts: Signatures for known scanning tools and vulnerability probes.
• Cloud Provider Logs (AWS CloudTrail, Azure Activity Log): For cloud-hosted assets, look for unauthorized Describe/List API calls that could mirror reconnaissance.

---

Building Resilience: Mitigation Strategies for Gather Victim Host Information

Mitigation is your primary weapon. Make the information gleaned from DNS as useless or misleading as possible to the attacker.

Actionable Mitigation Controls

• Minimize Public Footprint: Only expose essential services to the internet. Use a secure VPN or Zero Trust network access for employees, rather than exposing RDP, SSH, or database ports directly.
• Regular DNS Audits: Quarterly, audit your public DNS records. Remove stale A, CNAME, or MX records pointing to decommissioned systems. Ask, "Do we still need this subdomain publicly resolvable?"
• Secure Zone Transfers: Configure your authoritative DNS servers to only allow zone transfers (AXFR) from explicitly authorized secondary servers, not from any IP.
• Use Generic Names: Avoid revealing software or function in subdomain names (e.g., use `gateway.company.com` instead of `fortigate-vpn.company.com`).
• Deploy a Robust WAF/CDN: Place all public-facing web assets behind a Web Application Firewall or Content Delivery Network. This obscures the true origin server IP and provides an additional layer of defense.

Red vs. Blue: A Quick Comparison

Attacker's Goal (Red Team)	Defender's Action (Blue Team)
Discover all internet-facing assets.	Minimize and actively manage the public attack surface.
Identify vulnerable, less-monitored subdomains.	Apply consistent security standards (patching, WAF) to ALL public assets, not just "www".
Map the network to plan initial access.	Implement network segmentation so that compromising one public server doesn't grant access to the internal network.
Gather info silently and passively.	Assume the info is gathered, and focus on making it obsolete or misleading through architectural controls.

---

Gather Victim Host Information Cheat Sheet

---

Conclusion and Next Steps

Gather Victim Host Information (DNS) is the unavoidable starting pistol of many cyber campaigns. As defenders, we cannot win the race by trying to stop the starting shot. Instead, we must build a track that is confusing, well-guarded, and full of dead ends.

Your immediate next steps should be operational:

1. Conduct a Self-Recon: Use tools like Amass or OWASP Amass (passively) against your own primary domain. Document every discovery.
2. Initiate a Cleanup: Work with your network and application teams to remove unnecessary public DNS records and ensure all remaining public hosts are patched and behind a WAF.
3. Implement Proactive Hunting: Integrate the Sigma rule or its logic into your SIEM to hunt for horizontal scanning patterns.

To deepen your understanding of the attack chain, explore related techniques: Phishing for Initial Access (T1566) and External Remote Services for Persistence (T1133).

For further strategic guidance, refer to the NIST SP 800-53 Security and Privacy Controls, specifically the CA-8 (Penetration Testing) and RA-3 (Risk Assessment) families, which formalize the need for understanding and managing your attack surface.

Stay vigilant, manage your exposure, and assume the adversary already has your map.