Detection of DNS Queries to Suspicious Top-Level Domains

This brief details a detection rule from Elastic designed to identify suspicious DNS queries originating from Linux systems. The rule targets a broad list of top-level domains (TLDs) that are frequently abused by threat actors for various malicious purposes. These TLDs, such as .ru, .xyz, .top, .info, and many others, are common choices for hosting command and control (C2) infrastructure, facilitating data exfiltration, or serving as staging grounds for downloading additional malware payloads. The goal of this detection is to provide early warning of potential compromises or ongoing malicious activities by flagging communications with infrastructure known for its illicit use. Defenders can deploy this rule to monitor network traffic for anomalous outbound connections from Linux endpoints, thereby enhancing their ability to detect and respond to covert attacker communications.

Attack Chain

(No specific attack chain is documented in the source. This detection focuses on identifying post-compromise network behaviors rather than initial access or specific exploitation.)

Impact

Failure to detect and block DNS queries to suspicious TLDs can lead to significant consequences for an organization. If a compromised Linux system successfully establishes command and control (C2) with attacker infrastructure, it enables persistent access, further exploitation, data exfiltration, or the deployment of ransomware. The impact can range from data breaches and intellectual property theft to complete network disruption and financial losses. Early detection of such communication attempts is crucial to prevent the progression of an attack and mitigate potential damage, which could otherwise affect any system within the network communicating with these domains.

Recommendation

• Deploy the provided Sigma rule to your SIEM and tune it for your Linux environment, prioritizing critical servers and workstations.
• Ensure DNS logging is enabled for all Linux endpoints, capturing dns.question.name, host.os.type, and process.name to activate the rule effectively.
• Consider implementing network egress filtering to restrict outbound DNS queries to only known, legitimate TLDs or internal DNS resolvers.
• Investigate all alerts generated by the "DNS Request to Suspicious Top Level Domain" rule by examining the source process and the full domain name for context.