Dns — CraftedSignal Threat Feed

Potential Kerberos SPN Spoofing via Suspicious DNS Query

hello@craftedsignal.io — Fri, 01 May 2026 17:31:25 +0000

This detection identifies a specific pattern in DNS queries indicative of Kerberos SPN spoofing, a technique used to coerce systems into authenticating to attacker-controlled hosts. The pattern “UWhRCA…BAAAA” represents a marshaled CREDENTIAL_TARGET_INFORMATION structure. Attackers exploit this by crafting malicious DNS names to trick victim systems into requesting Kerberos tickets for legitimate services, often their own identity, but directed towards an attacker-controlled endpoint. This can lead to Kerberos relay or NTLM reflection/relay attacks, bypassing normal NTLM fallback mechanisms. The technique is associated with tools like RemoteKrbRelay and wspcoerce. This activity has been observed in various attacks targeting Windows environments where Kerberos authentication is prevalent. Defenders need to detect and mitigate this early stage of credential access.

Attack Chain

The attacker identifies a target Windows system within the network.
The attacker sets up a malicious server to receive coerced authentication requests.
The attacker crafts a malicious DNS query containing a base64-encoded blob “UWhRCA…BAAAA” representing a marshaled CREDENTIAL_TARGET_INFORMATION structure.
The victim system, triggered by an external factor (e.g., RPC call, scheduled task, or web request), attempts to resolve the crafted DNS name.
The malicious DNS query is sent to the DNS server, which resolves to the attacker’s server.
The victim system initiates a Kerberos authentication request to the attacker’s server, believing it to be a legitimate service.
The attacker’s server relays the Kerberos ticket or uses NTLM reflection/relay techniques to gain unauthorized access.
The attacker compromises the victim system or pivots to other systems within the network using the stolen credentials.

Impact

Successful exploitation can lead to credential compromise, lateral movement, and domain takeover. Victims in Active Directory environments are particularly vulnerable. The impact includes unauthorized access to sensitive data, disruption of services, and potential ransomware deployment. If the coerced service has high privileges, the attacker can gain complete control over the compromised system or even the entire domain. Organizations using Kerberos authentication are at risk.

Recommendation

Deploy the “Potential Kerberos SPN Spoofing via Suspicious DNS Query” rule to your SIEM and tune for your environment to detect malicious DNS queries.
Enable Sysmon Event ID 22 - DNS Query logging to provide the necessary data for detection.
Investigate and block any DNS queries resolving to external IPs that contain the “UWhRCA…BAAAA” pattern.
Monitor process creation events for processes initiating DNS queries containing the suspicious pattern, specifically looking for known coercion tools.
Implement network segmentation to limit the impact of lateral movement if a system is compromised.
Review and harden Kerberos configurations to prevent SPN spoofing and relay attacks.

Hickory DNS Recursor Cache Poisoning via Sibling Zone Delegation

hello@craftedsignal.io — Thu, 30 Apr 2026 18:10:58 +0000

The Hickory DNS project’s experimental hickory-recursor crate, now integrated into hickory-resolver under the recursor feature, contains a vulnerability in its DNS record cache (DnsLru). The cache stores records based on the record’s name and type, rather than the originating query. This design flaw allows for cross-zone cache poisoning because the cache_response() function chains ANSWER, AUTHORITY, and ADDITIONAL sections into a single record iterator during insertion. The bailiwick filter uses the zone context of the NS pool that serviced the lookup, leading to improper validation of records from sibling zones. This issue affects all published versions of the experimental hickory-recursor crate prior to its integration into hickory-resolver 0.26.0. Users of the hickory-dns binary configured with the recursor feature are affected.

Attack Chain

Attacker registers the domain attacker.poc. and sets up a malicious nameserver.
Hickory DNS server queries the nameserver for attacker.poc. to build its NS pool.
The attacker’s nameserver responds with an AUTHORITY section that includes a malicious record delegating a sibling zone, such as victim.poc., to ns.evil.poc..
The Hickory DNS server’s bailiwick check incorrectly validates the malicious victim.poc. NS ns.evil.poc. record because victim.poc. is a subdomain of the parent zone poc..
The malicious NS record for victim.poc. is stored in the cache, keyed by (victim.poc., NS).
A client queries the Hickory DNS server for a name within the victim.poc. zone.
Hickory DNS server builds its NS pool for victim.poc. using the poisoned cache entry, directing queries to ns.evil.poc..
The attacker’s nameserver now receives queries intended for the legitimate victim.poc. nameserver, allowing the attacker to intercept and manipulate DNS resolution.

Impact

Successful exploitation of this vulnerability allows an attacker to redirect DNS queries for a target domain to an attacker-controlled nameserver. This can lead to various malicious activities, including phishing attacks, man-in-the-middle attacks, and the distribution of malware. The vulnerability affects any system using Hickory DNS with the recursor feature enabled, potentially impacting a wide range of users relying on the resolver for DNS resolution. If the targeted domain is critical for service delivery (e.g., email, web), the impact could be significant.

Recommendation

Upgrade to hickory-resolver version 0.26.0 or later with the recursor feature enabled to address the vulnerability as described in the advisory (https://github.com/advisories/GHSA-83hf-93m4-rgwq).
If upgrading is not immediately feasible, disable the recursor feature in hickory-dns to prevent exploitation.
Implement monitoring for unexpected NS record changes, focusing on AUTHORITY sections of DNS responses, using a custom rule based on your environment and typical DNS configurations.

Internet Systems Consortium BIND Vulnerabilities Leading to Denial of Service

hello@craftedsignal.io — Mon, 30 Mar 2026 10:14:09 +0000

The Internet Systems Consortium (ISC) BIND (Berkeley Internet Name Domain) is a widely used open-source DNS server software. Multiple vulnerabilities exist within BIND that can be exploited by remote attackers. An unauthenticated attacker can leverage these flaws to conduct denial-of-service (DoS) attacks, disrupting DNS resolution services. The specific versions affected are not specified in the provided source, but administrators should consult ISC’s security advisories for detailed version information. Exploitation of these vulnerabilities can severely impact the availability of services that rely on DNS resolution.

Attack Chain

The attacker identifies a vulnerable BIND DNS server exposed to the internet.
The attacker sends specially crafted DNS queries to the target server. These queries exploit known vulnerabilities within the BIND software.
The BIND server, upon processing the malicious queries, experiences a resource exhaustion issue.
The excessive resource consumption leads to the BIND process becoming unresponsive.
Legitimate DNS requests are no longer processed, resulting in a denial of service for clients relying on the BIND server for name resolution.
The attacker repeats the process to maintain the denial of service condition.
The impact is widespread as applications and services reliant on DNS name resolution become unavailable.

Impact

Successful exploitation of these BIND vulnerabilities can lead to a denial-of-service condition, disrupting DNS resolution services. This impacts all services reliant on the affected BIND server, potentially affecting thousands of users and systems. The lack of DNS resolution can lead to widespread application failures, service unavailability, and reputational damage. The absence of specific victim counts prevents a definitive assessment of impact scope.

Recommendation

Monitor DNS server logs for anomalies indicative of denial-of-service attacks, focusing on query rates and resource utilization.
Deploy the Sigma rules provided in this brief to your SIEM to identify potentially malicious DNS queries targeting BIND servers.
Consult ISC’s security advisories for specific vulnerability details and apply the necessary patches to your BIND installations.

Potential Kerberos Coercion via DNS-Based SPN Spoofing

hello@craftedsignal.io — Fri, 26 Jan 2024 12:00:00 +0000

This detection identifies potential Kerberos coercion attempts via DNS-based SPN spoofing on Windows systems. The technique abuses MicrosoftDNS records, specifically looking for directory-service access or creation events (event codes 4662 and 5137) involving a MicrosoftDNS record that contains a base64-encoded blob matching the pattern “UWhRCA…BAAAA”. This blob pattern corresponds to a marshaled CREDENTIAL_TARGET_INFORMATION structure, a known indicator of DNS-based SPN spoofing used in Kerberos coercion tradecraft. The goal is to detect adversaries coercing victim systems into authenticating to attacker-controlled hosts while requesting Kerberos tickets for legitimate services. This activity is typically observed within Windows Security Event Logs.

Attack Chain

The adversary gains initial access to a system with privileges to modify DNS records in Active Directory.
The attacker creates a new MicrosoftDNS record or modifies an existing one.
Within the DNS record, specifically in the AdditionalInfo or ObjectDN attributes, the attacker inserts a base64-encoded blob matching the pattern “UWhRCA…BAAAA”. This blob contains a marshaled CREDENTIAL_TARGET_INFORMATION structure.
The attacker configures the DNS record to point to an attacker-controlled host. This involves manipulating the record’s name and associated IP address.
The attacker triggers a victim system to resolve the manipulated DNS record, causing the victim to attempt Kerberos authentication with the attacker-controlled host, believing it to be a legitimate service.
The attacker intercepts the Kerberos authentication request.
The attacker relays the Kerberos ticket to a legitimate service, impersonating the victim system.
The attacker gains unauthorized access to the legitimate service using the relayed Kerberos ticket.

Impact

Successful Kerberos coercion can grant attackers unauthorized access to critical systems and services within the Active Directory domain. This may lead to privilege escalation, lateral movement, data exfiltration, and other malicious activities. The scope of impact depends on the permissions and access rights of the coerced victim system and the targeted services.

Recommendation

Enable “Audit Directory Service Access” and “Audit Directory Service Changes” Windows audit policies to ensure relevant events are logged (Setup section).
Deploy the Sigma rules provided in this brief to your SIEM to detect potential Kerberos coercion attempts via DNS-based SPN spoofing. Tune the rules based on your environment and known legitimate activity.
Investigate any alerts generated by the Sigma rules, focusing on the associated user accounts, systems, and modified DNS records (rule titles).
Restrict access to modify DNS records in Active Directory to only authorized personnel and systems to prevent unauthorized manipulation (Overview section).
Monitor Windows Security authentication events for any suspicious Kerberos activity following the modification of DNS records (Attack Chain steps 5-8).

RMM Domain DNS Queries from Non-Browser Processes

hello@craftedsignal.io — Wed, 03 Jan 2024 12:00:00 +0000

This detection identifies potentially malicious use of Remote Monitoring and Management (RMM) tools by detecting DNS queries to known RMM domains originating from processes that are not web browsers. Attackers frequently abuse legitimate RMM software for command and control, persistence, and lateral movement within compromised networks. This rule focuses on surfacing RMM clients, scripts, or other non-browser activity contacting these services, thereby increasing the likelihood of detecting unauthorized remote access or malicious activity. The rule aims to reduce false positives by excluding common browser processes and focusing on unusual network activity. The identified domains are associated with various RMM tools like TeamViewer, AnyDesk, and ScreenConnect. This detection is relevant for organizations concerned about insider threats, supply chain attacks, or general compromise leading to unauthorized remote access.

Attack Chain

An attacker gains initial access to a system, possibly through phishing or exploiting a vulnerability.
The attacker installs an unauthorized RMM tool (e.g., using a script or installer).
The RMM tool initiates a DNS query to resolve its command and control domain (e.g., teamviewer.com).
The system, now running the RMM agent, establishes a connection to the attacker-controlled RMM server.
The attacker uses the RMM tool to execute commands on the compromised system.
The attacker uses the RMM tool for lateral movement within the network.
The attacker uses the RMM tool to maintain persistence on the compromised system.

Impact

Compromise via unauthorized RMM tools can provide attackers with persistent remote access, enabling them to perform a range of malicious activities, including data theft, ransomware deployment, and further lateral movement within the network. Successful exploitation can lead to significant financial loss, reputational damage, and disruption of business operations. The number of affected systems can vary depending on the scope of the initial compromise and the attacker’s ability to move laterally.

Recommendation

Deploy the Sigma rule RMM Domain DNS Queries from Non-Browser Processes to your SIEM and tune it to your environment, excluding legitimate non-browser processes that use RMM tools.
Investigate any alerts generated by the rule, focusing on identifying the process making the DNS query and its parent process, as outlined in the rule’s description.
Monitor DNS query logs for queries to the RMM domains listed in the IOC table, and block them at the DNS resolver if unauthorized RMM use is confirmed.
Enable Sysmon Event ID 22 (DNS Query) logging to provide the necessary data for this detection, as recommended in the “Setup” section of the content.

Suspicious DNS Queries to Telegram API by Non-Telegram Processes

hello@craftedsignal.io — Wed, 03 Jan 2024 10:00:00 +0000

This alert identifies systems querying the Telegram API domain (api.telegram.org) using processes other than the legitimate Telegram application. Threat actors frequently leverage Telegram bots for C2, due to their ease of use, encryption, and widespread availability. Malware can use these bots to receive commands, exfiltrate data, or perform other malicious activities. Detecting DNS queries for Telegram’s API from unexpected processes can uncover compromised systems or unauthorized use of Telegram for covert communication. The detection focuses on non-standard Telegram clients resolving the api.telegram.org domain to filter out legitimate Telegram application traffic and focus on suspicious processes.

Attack Chain

A user inadvertently downloads and executes a malicious payload (e.g., via phishing or drive-by download).
The malware establishes persistence on the system (e.g., via registry keys or scheduled tasks).
The malware initiates a DNS query to resolve api.telegram.org to identify the Telegram API server IP address.
The malware establishes a communication channel with a Telegram bot controlled by the attacker using the resolved IP address.
The attacker sends commands to the bot, which are relayed to the compromised system.
The malware executes the received commands, potentially including data exfiltration or further malicious actions.
The malware exfiltrates sensitive data to the attacker via the Telegram bot.
The attacker maintains persistent access and control over the compromised system via the Telegram bot.

Impact

Compromised systems can be remotely controlled by attackers, leading to data theft, system disruption, or further propagation of malware within the network. The use of Telegram bots enables covert communication, making it difficult to detect malicious activity using traditional methods. Multiple threat actors employ Telegram-based C2, including those associated with information stealers, keyloggers, and crypto-mining malware. A successful attack can lead to significant data breaches and financial losses.

Recommendation

Deploy the Sigma rule Detect Suspicious Telegram DNS Queries to your SIEM to identify processes making DNS queries to the Telegram API (api.telegram.org) other than the legitimate Telegram application.
Investigate any alerts generated by the Sigma rule by examining the process execution history, network connections, and related system activity.
Block the domain api.telegram.org at the DNS resolver or firewall to prevent compromised systems from communicating with Telegram bots, unless legitimate business use requires it.
Enable Sysmon Event ID 22 (DNS Query) logging to capture DNS query events on endpoints.
Update Sysmon to at least version 6.0.4 to ensure comprehensive DNS event logging.

CoreDNS Transfer Plugin ACL Bypass Vulnerability

hello@craftedsignal.io — Wed, 03 Jan 2024 10:00:00 +0000

A vulnerability exists in the CoreDNS transfer plugin related to Access Control List (ACL) stanza selection. When both a parent zone and a more-specific subzone are configured with transfer rules, CoreDNS versions prior to 1.14.3 may incorrectly prioritize the parent zone’s rule over the subzone’s due to a lexicographic string comparison instead of a proper longest-match algorithm. This can lead to a permissive parent-zone transfer rule overriding a more restrictive subzone rule, allowing unauthorized clients to perform AXFR/IXFR requests and retrieve zone contents they should not have access to. This vulnerability matters because it can expose sensitive DNS information to unauthorized parties, potentially aiding reconnaissance or enabling further attacks.

Attack Chain

An attacker identifies a CoreDNS server running a version prior to 1.14.3.
The attacker determines that the CoreDNS server is configured with both a parent zone (e.g., example.org.) and a subzone (e.g., a.example.org.) with different transfer ACLs. The parent zone’s ACL is more permissive than the subzone’s.
The attacker crafts an AXFR or IXFR request specifically targeting the subzone (a.example.org.).
The CoreDNS server’s transfer plugin incorrectly selects the parent zone’s ACL due to the lexicographic comparison logic, which favors “example.org.” over “a.example.org.”.
The server authorizes the transfer based on the permissive parent zone ACL.
The CoreDNS server responds to the attacker’s request, providing the full zone contents of the subzone.
The attacker receives the zone data, gaining access to information such as hostnames, IP addresses, and other DNS records that should have been protected by the subzone’s restrictive ACL.

Impact

Successful exploitation of this vulnerability allows unauthorized zone transfers, exposing sensitive DNS information. The impact is significant as it can lead to the disclosure of internal network structures, server names, and other critical data, potentially facilitating reconnaissance for further attacks. The severity is compounded by the non-intuitive nature of the vulnerability, making it difficult to detect and remediate without a clear understanding of the underlying issue.

Recommendation

Upgrade CoreDNS to version 1.14.3 or later to address the vulnerability (CVE-2026-33489).
Review CoreDNS transfer configurations to ensure subzone ACLs are not inadvertently bypassed by more permissive parent zone ACLs.