T1583.002 Google Chronicle · YARA-L

Detect DNS Server in Google Chronicle

Adversaries may set up their own Domain Name System (DNS) servers that can be used during targeting. During post-compromise activity, adversaries may utilize DNS traffic for various tasks, including for Command and Control. Instead of hijacking existing DNS servers, adversaries may opt to configure and run their own DNS servers in support of operations. By running their own DNS servers, adversaries can have more control over how they administer server-side DNS C2 traffic. With control over a DNS server, adversaries can configure DNS applications to provide conditional responses to malware and, generally, have more flexibility in the structure of the DNS-based C2 channel. Real-world examples include Sea Turtle building adversary-in-the-middle DNS servers to capture credentials, Axiom acquiring dynamic DNS services for targeting operations, and HEXANE setting up custom DNS servers to send commands to compromised hosts via TXT records.

MITRE ATT&CK

Tactic
Resource Development
Technique
T1583 Acquire Infrastructure
Sub-technique
T1583.002 DNS Server
Canonical reference
https://attack.mitre.org/techniques/T1583/002/

YARA-L Detection Query

Google Chronicle (YARA-L)
yaral
rule T1583_002_c2_infrastructure {
  meta:
    author = "Detection Engineering"
    description = "Detects potential C2 infrastructure activity and reconnaissance"
    severity = "high"
    confidence = "medium"
    mitre_attack = "T1583.002"
    reference = "https://attack.mitre.org/techniques/T1583/002/"

  events:
    $e.metadata.event_type = "NETWORK_CONNECTION"
    $e.network.direction = "OUTBOUND"
    $e.target.port in (443, 8443, 4443, 8080, 53)
    not re.regex($e.target.ip, `^(10\.|172\.(1[6-9]|2[0-9]|3[01])\.|192\.168\.|127\.)`)
    re.regex($e.principal.process.file.full_path, `(?i)(powershell|cmd|wscript|cscript|nslookup|dig)`)

  condition:
    $e
}
high severity medium confidence

Google Chronicle YARA-L 2.0 detection for DNS Server. Detects adversary-controlled DNS server usage through three signals: (1) endpoints making DNS queries directly to non-authorized external IP addresses on port 53, bypassing corporate DNS infrastructur

Data Sources

Google Chronicle SIEMEndpoint telemetryDNS logs

Required Tables

NETWORK_CONNECTIONDNS

False Positives & Tuning

  • Security teams registering typosquat domains defensively to protect brand
  • Marketing teams registering new domains for campaigns or product launches
  • IT teams creating subdomains for new projects or staging environments
  • Certificate lifecycle automation triggering DNS record modifications
Download portable Sigma rule (.yml)

Other platforms for T1583.002


Testing Methodology

Validate this detection against 4 adversary techniques from Atomic Red Team. Each test below lists the behaviour to exercise and the telemetry you should expect to see. Executable commands and cleanup steps are available with Pro.

  1. Test 1Configure Windows DNS Client to Use Custom External Resolver

    Expected signal: Sysmon Event ID 13 (Registry Value Set): TargetObject containing 'SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\Interfaces\{GUID}\NameServer' or 'StaticDnsAddress' with new value '198.51.100.1'. Sysmon Event ID 1 (Process Create): Image=netsh.exe with CommandLine='interface ip set dns name=Ethernet static 198.51.100.1 primary'. Security Event ID 4688 (if command line auditing enabled). MDE DeviceRegistryEvents with RegistryValueName='NameServer' and RegistryValueData='198.51.100.1'.

  2. Test 2DNS TXT Record Query via nslookup (HEXANE-Style C2 Simulation)

    Expected signal: Sysmon Event ID 22 (DNS Query): Image=nslookup.exe and Image=powershell.exe with QueryName entries for the queried domains. Sysmon Event ID 3 (Network Connection): connections to 8.8.8.8 on port 53 from nslookup.exe and powershell.exe. Security Event ID 4688: Process Create for nslookup.exe. The second query (MNQXI2LPNZSGK3TFONZSA.example.com) will trigger high-entropy subdomain detection with FirstLabelLen=21.

  3. Test 3Set Up BIND9 Authoritative DNS Server on Linux

    Expected signal: Linux audit log (auditd): execve syscalls for apt-get/yum, systemctl, named. Syslog (/var/log/syslog or /var/log/messages): BIND9 startup messages from named daemon including 'starting BIND' and 'listening on IPv4 interface'. Process creation events: named process spawned by systemd with parent systemd. Network listener: netstat/ss showing UDP/TCP port 53 bound on 0.0.0.0 by named process. File creation events for /etc/bind/named.conf.options.

  4. Test 4DNS Tunneling Pattern Simulation with Encoded Subdomains

    Expected signal: 50 rapid DNS query events (Sysmon Event ID 22 on Windows equivalent, or DNS debug log entries on Linux). Query names follow pattern: 24-char alphanumeric label + '.c2.example.com' (total length ~40 chars). All queries occur within a 5-10 second window. Process creating queries: dig (or nslookup equivalent). Network events: 50 UDP packets to 127.0.0.1:53 in rapid succession. On Windows, if run via WSL: DeviceNetworkEvents showing high-frequency port 53 connections from the WSL process.

Unlock Pro Content

Get the full detection package for T1583.002 including response playbook, investigation guide, and atomic red team tests.

Response PlaybookInvestigation GuideHunting QueriesAtomic Red Team TestsTuning Guidance

Related Detections