Kerberos authentication attacks

Threat snapshot

Kerberos is the default authentication protocol for Windows Active Directory environments. Every domain logon, every service ticket, and every remote resource access in a corporate Windows network flows through Kerberos. Its design relies on a trusted third party, the Key Distribution Center on the domain controller, to issue tickets that prove identity between clients and services. That trust model is also its attack surface: an attacker who can manipulate how Kerberos resolves service names can redirect authentication requests to a system they control, capturing the Kerberos ticket material exchanged during that process.

Kerberos coercion via DNS SPN spoofing is a technique that exploits the relationship between DNS resolution and Service Principal Name lookup in Active Directory. When a Windows system attempts to authenticate to a service, it resolves the service's hostname via DNS and then requests a Kerberos ticket for the Service Principal Name associated with that hostname. An attacker who can manipulate the DNS record for a target hostname can redirect these authentication attempts to a host they control, capturing Net-NTLMv2 hashes or Kerberos tickets that can be used for offline cracking, relay attacks, or impersonation. Log360 detects this technique through the Attempts of Kerberos Coercion Via DNS SPN Spoofing rule.

At a glance

How this attack works

Service Principal Names are identifiers registered in Active Directory that map Kerberos service tickets to specific accounts. For example, when a client authenticates to a file server named FILESERVER01, it requests a Kerberos ticket for the SPN HOST/FILESERVER01.domain.com. The Key Distribution Center issues a ticket encrypted with the service account's credentials. This ticket proves to FILESERVER01 that the client has been authenticated.

The DNS SPN spoofing attack targets the DNS resolution step that precedes the Kerberos ticket request. The attack proceeds in four stages. First, the attacker identifies a target machine or service account whose credentials they want to capture. Second, they manipulate a DNS record, either by adding a new DNS entry or modifying an existing one, to point the target hostname to an IP address they control. Third, they trigger or wait for a Kerberos authentication attempt from a victim machine to what it believes is the legitimate service at that hostname. Fourth, the victim's Kerberos authentication attempt arrives at the attacker's machine, which captures the Net-NTLMv2 hash or Kerberos ticket material presented during the authentication handshake.

The captured credential material can then be used in several ways. Net-NTLMv2 hashes can be cracked offline using hashcat or similar tools to recover the plaintext password. They can also be relayed in real time to another service using NTLM relay techniques if relay protections such as SMB signing are not enforced. Kerberos tickets can be used in Pass-the-Ticket attacks to authenticate as the captured account without knowing the password.

The DNS manipulation step is what makes this technique detectable. Unauthorised DNS record creation or modification in Active Directory-integrated DNS generates specific events in the DNS server event log and the Windows Security event log when object access auditing is configured. The Log360 rule targets the DNS manipulation activity that is the necessary precursor to the authentication coercion.

Why DNS is the attack surface

Active Directory environments typically use AD-integrated DNS, where DNS records are stored as objects in Active Directory and replicated to all domain controllers. In many default configurations, standard domain users have permission to create DNS records in specific zones, particularly in the default zone used for dynamic DNS registration. An attacker with standard domain user credentials can create or modify DNS records in these writable zones without any administrative rights. The ability to create a DNS record pointing an arbitrary hostname to the attacker's IP is all that is required to redirect Kerberos authentication attempts for that hostname.

Attack chain

The table below maps each stage of a Kerberos coercion via DNS SPN spoofing attack to the corresponding MITRE ATT&CK technique.

Real-world scenario

A financial services organisation runs a Windows Active Directory environment with approximately 500 users. The Active Directory-integrated DNS is configured with the default zone permissions, which allow domain computers to create DNS records dynamically. A threat actor who obtained a standard domain user account credential through a phishing campaign begins exploring the environment.

Using the compromised domain user account, the attacker queries Active Directory to identify Service Principal Names registered for high-value accounts, focusing on accounts associated with SQL Server and file server services. They create a new DNS A record in the writable DNS zone, pointing the hostname SQLBACKUP01 to their listening host's IP address. The hostname SQLBACKUP01 does not currently exist in DNS, so no legitimate record is overwritten.

The attacker then triggers a connection attempt from a domain-joined machine to SQLBACKUP01 using a method that forces a Kerberos authentication. The domain-joined machine resolves SQLBACKUP01 via DNS, receives the attacker's IP, and begins a Kerberos authentication handshake with the attacker's listener. The attacker captures a Net-NTLMv2 hash for the machine account of the domain-joined computer. This hash is cracked offline within two hours, recovering the machine account password.

Log360 fires the Kerberos Coercion Via DNS SPN Spoofing alert when the DNS record creation event is detected. The SOC analyst reviewing the alert identifies the newly created DNS record, notes that SQLBACKUP01 does not correspond to any known host in the environment, and identifies the account that created the record as a standard user with no administrative rights. The record is deleted and the compromised account is disabled before the captured hash can be exploited further.

Why this happens

DNS record creation in AD-integrated zones is a permitted operation for domain computers and, in many default configurations, for standard domain users. The feature exists to support dynamic DNS registration, where computers automatically register their own A records when they join the network. The same mechanism that supports legitimate dynamic DNS allows an attacker with domain user rights to create arbitrary DNS records pointing to any IP address. Most environments do not monitor DNS record creation events because DNS changes are considered routine infrastructure activity. Without specific detection rules targeting DNS record creation by non-administrative accounts, the spoofing step goes unnoticed.

Business impact: What can go wrong

Successful Kerberos coercion via DNS SPN spoofing results in credential material capture with wide-ranging consequences:

• Machine account credential compromise: coerced authentication from domain-joined computers yields machine account credentials. Machine account hashes cracked or relayed can be used to authenticate as the computer account, which has significant Active Directory read permissions and may be used for further domain enumeration or lateral movement.
• Service account credential capture: if the coercion targets a service account SPN, the captured ticket material may include the service account's Kerberos ticket-granting service ticket, which can be used in Pass-the-Ticket attacks to access any service the account is authorised to reach.
• NTLM relay to high-value services: captured Net-NTLMv2 hashes can be relayed in real time to services that do not enforce SMB signing or that accept NTLM authentication, granting the attacker authenticated access to those services without cracking the hash. Common relay targets include file servers, Exchange servers, and any service accepting NTLM authentication.
• Offline hash cracking: service account passwords that are not complex or that follow predictable patterns can be cracked from the captured Net-NTLMv2 hash offline in hours to days, yielding the plaintext credential for direct use across any service where the account is registered.
• Domain-wide lateral movement: a single successful coercion that captures and cracks or relays a privileged account credential provides access to every system that account is authorised to reach, potentially spanning the entire domain.
• Persistence via Kerberoasting combination: attackers who use DNS SPN spoofing to capture service account material frequently combine it with Kerberoasting against the same SPNs, using the captured tickets as offline cracking material without needing to trigger further authentication events.

Indicators of compromise and detection signals

Prerequisites for detection using Log360

Before the Kerberos Coercion Via DNS SPN Spoofing rule can fire reliably, ensure the following are in place:

• DNS Server audit logging is enabled on all domain controllers acting as DNS servers. The DNS Server operational log must be enabled and collecting events, specifically DNS Server Audit events (event source Microsoft-Windows-DNSServer, audit category). This log captures DNS record creation, modification, and deletion events including the account responsible and the record details. By default, DNS audit logging may not be enabled and must be explicitly configured.
• Active Directory object access auditing is enabled for DNS zone objects. Enable Object Access auditing under Advanced Audit Policy Configuration and configure audit SACLs on the DNS application partition objects in Active Directory to generate Event ID 4662 when DNS zone objects are modified. This provides a secondary audit record independent of the DNS Server operational log.
• Domain controller logs are forwarded to Log360 in near-real-time via the Log360 agent or Windows Event Forwarding. DNS record creation events are generated on the domain controller that processes the DNS write operation. All domain controllers acting as DNS servers must be in scope, as the write may be directed to any available DNS server.
• Kerberos authentication event logging is enabled to generate Event ID 4768 (Kerberos TGT request) and Event ID 4769 (Kerberos service ticket request) on domain controllers, and Event ID 4771 (Kerberos pre-authentication failure) for failed attempts. These events provide the downstream authentication signals that confirm whether a coercion attempt triggered authentication toward the spoofed DNS record.

Note: DNS Server audit logging is not enabled by default on Windows Server domain controllers. Before enabling the Log360 rule, verify that the DNS Server operational log is capturing audit events on all domain controllers that serve DNS. Without this log source, DNS record creation by non-administrative accounts will not generate any event that Log360 can detect. To enable DNS audit logging, open DNS Manager, right-click the server, select Properties, and enable event logging for all events under the Event Logging tab, or use the following PowerShell command on each DNS server: Set-DnsServerDiagnostics -All $true.

Detecting Kerberos coercion via DNS SPN spoofing using Log360

Once log collection is configured, follow these steps to enable and tune detection in Log360:

Step 1: Enable the detection rule

Navigate to Security > Manage Rules > Rule Library in the Log360 console. Install and enable the rule: Attempts of Kerberos Coercion Via DNS SPN Spoofing. Configure an alert profile for the same. Set the severity to Critical. DNS record creation by a non-administrative account pointing to an unrecognised IP is a high-confidence attack signal in environments that have established and documented DNS management procedures.

Step 2: Read the alert

When the rule fires, the alert will display the domain controller hostname on which the DNS event was captured, the account that created the DNS record, the record type and name, the IP address the record points to, and the timestamp. Review the creating account first: a standard domain user or computer account creating a DNS record in a sensitive zone is the primary indicator. Then review the IP address: an address outside your documented internal ranges is immediately high confidence. Finally check the hostname: a name with no corresponding machine account in Active Directory was created manually rather than through legitimate dynamic registration.

Investigating an alert

When the Kerberos Coercion Via DNS SPN Spoofing rule fires, an L2 analyst should work through the following steps:

• Verify the DNS record and its content. Query the DNS server to confirm the record exists and retrieve its current value. Identify the hostname, the record type (A, CNAME, or other), and the IP address it points to. Verify whether this hostname corresponds to any known host in the environment by checking Active Directory computer accounts and the documented IP address inventory.
• Assess the creating account. Identify the account that created the DNS record and determine its role and group membership. A standard domain user with no DNS administration responsibilities creating a DNS record is a high-confidence indicator. Check whether the account has any documented reason to manage DNS records. If no reason exists, treat the creation as confirmed suspicious and continue investigating while initiating preliminary containment.
• Check for preceding enumeration activity. Query Log360 for LDAP query events or Active Directory object access events from the creating account in the 30 minutes before the DNS record creation. Look for queries targeting the DNS application partition, SPN enumeration, or computer account enumeration. Discovery activity immediately before DNS record creation confirms deliberate attack preparation rather than accidental or legitimate DNS management.
• Check for authentication events targeting the spoofed hostname. Query Log360 for Kerberos events (Event ID 4768, 4769, 4771) and NTLM authentication events (Event ID 4776) where the service name or client address involves the hostname in the newly created DNS record. A Kerberos authentication attempt directed toward the spoofed hostname confirms the coercion step has been triggered.
• Check for network traffic to the IP in the DNS record. If the DNS record points to an internal IP, identify which host owns that IP and determine whether it is a known attacker-controlled host or a compromised internal machine being used as the listener. If the record points to an external IP, check perimeter firewall and proxy logs for any outbound connections to that IP from domain-joined hosts following the DNS record creation.
• Assess the scope of accounts that may have authenticated toward the spoofed record. Identify all domain-joined machines that may have attempted to resolve or authenticate to the spoofed hostname since the DNS record was created. All machine accounts and user accounts that generated authentication events toward the spoofed hostname must have their credentials treated as potentially captured.

Escalation trigger

Escalate immediately to L3 if the DNS A record points to an IP outside your documented internal infrastructure; if any Kerberos or NTLM authentication events targeting the spoofed hostname are confirmed; if the creating account is a standard domain user with no DNS administration role; or if network connections from internal hosts to the IP in the spoofed DNS record are observed. Delete the malicious DNS record immediately as a containment step, and initiate credential rotation for any machine or user accounts confirmed to have authenticated toward the spoofed hostname.

Responding and remediating

Immediate containment

• Delete the malicious DNS record from the Active Directory-integrated DNS zone immediately. Use the DNS Manager console on a domain controller or PowerShell: Remove-DnsServerResourceRecord -ZoneName <zonename> -Name <hostname> -RRType A. Confirm the record has been deleted and is not replicated to other DNS servers before closing the containment step.
• Disable the account that created the malicious DNS record. If the account is a standard domain user, disable it in Active Directory and force a password reset. If the account is a computer account that was used to create the record, assess whether the machine is compromised and initiate host investigation.
• Block network access to the IP address specified in the spoofed DNS record at the perimeter firewall and on internal network controls if the IP is external. If the IP is internal, isolate the host that owns that IP to prevent it from continuing to act as a credential capture listener.

Forensic preservation

• Export the DNS Server operational log from all domain controllers acting as DNS servers covering the full period from the DNS record creation to the time of containment. These logs are the primary record of the DNS manipulation and any subsequent DNS query activity related to the spoofed record.
• Export Windows Security event logs from all domain controllers covering Kerberos authentication events (4768, 4769, 4771) and NTLM events (4776) for the period following the DNS record creation. These logs identify which accounts generated authentication toward the spoofed record and therefore which credentials must be treated as captured.
• Document the full details of the malicious DNS record before deletion: the hostname, IP address, record type, TTL, creation timestamp, and creating account. This information is required for the incident record and for identifying the full scope of accounts that may have cached the record and attempted authentication.

Eradication and recovery

• Rotate credentials for all machine accounts and user accounts confirmed to have authenticated toward the spoofed DNS hostname. Machine account password rotation can be triggered by disabling and re-enabling the computer account in Active Directory, which forces the machine to negotiate a new password at the next domain communication.
• Review and restrict DNS zone permissions to prevent standard domain users from creating records in sensitive zones. Use the DNS Manager or Active Directory Sites and Services to review the security permissions on the DNS application partition. Remove the Create DNS Zones or Create All Child Objects permission from the Authenticated Users or Domain Users groups if present, restricting DNS record creation to specific documented service accounts and administrative groups.
• Audit all DNS records created in the preceding 72 hours for anomalous entries. Query the DNS Server operational log for all DNS record creation events in the incident window and verify each created record against the documented host inventory. Remove any additional records created by non-administrative accounts that cannot be attributed to legitimate dynamic DNS registration.
• Enable SMB signing as required across all domain-joined systems. SMB signing prevents NTLM relay attacks that exploit captured Net-NTLMv2 hashes. Enforcing SMB signing via Group Policy (Microsoft network server: Digitally sign communications always) significantly reduces the lateral movement value of captured NTLM hashes.

False positive guidance

DNS record creation events are common in Active Directory environments due to dynamic DNS registration. The following scenarios may produce false positive alerts:

• Dynamic DNS registration by domain-joined computers: when a computer joins the domain or obtains a new DHCP lease, it automatically registers its A record in the DNS zone using its computer account. These events will be generated by the computer account of the registering machine, the IP will be the machine's own address (within the documented internal range), and the hostname will match the computer's name as registered in Active Directory. Verify these three conditions and the alert is a false positive.
• DHCP server-integrated DNS updates: in environments where the DHCP server performs DNS registration on behalf of clients (particularly common for non-Windows clients), the DHCP server's service account creates DNS records. These will consistently come from the DHCP service account, target the internal IP range, and occur on a pattern that correlates with DHCP lease events. Identify the DHCP service account and create a scoped exclusion.
• Authorised IT administrator DNS management: IT administrators who manually create DNS records for new hosts, services, or applications will trigger the rule if the rule does not distinguish between administrative and non-administrative accounts. If the creating account is a member of the Domain Admins, DNS Admins, or a documented DNS management group, verify the record content and create a scoped exclusion for those groups if manual DNS management is a routine administrative activity.
• Automated DNS management tooling: IP address management tools, network discovery tools, and automation platforms that create DNS records programmatically will trigger the rule. Identify the service account used by these tools and verify the records they create are within the documented internal IP range and correspond to known hosts. Create scoped exclusions for the tool's service account.

Key differentiator

Legitimate DNS record creation events come from computer accounts registering their own hostnames at their own IP addresses, from DHCP service accounts registering client leases, or from documented DNS administrator accounts managing known infrastructure hosts. The IP address in a legitimate DNS record will always be within the documented internal IP range and will correspond to a known device. An attacker-created DNS record will be created by a standard user account rather than a computer account or administrative account, will point to an IP that does not correspond to a known host in the environment, and will create a hostname that has no corresponding Active Directory computer account. Any DNS record failing all three of these legitimacy checks should be treated as malicious.

Hardening and prevention

The following controls reduce the risk of Kerberos coercion via DNS SPN spoofing in your environment:

• Restrict DNS zone write permissions to prevent standard domain users from creating records. Review the DACL on the DNS application partition in Active Directory and remove the ability for Authenticated Users or Domain Users to create child objects in DNS zones. Restrict this permission to the DNS Admins group, the DHCP server service account, and documented automation service accounts.
• Enable DNS Server audit logging on all domain controllers acting as DNS servers. The DNS Server operational log is the primary detection source for this technique and must be enabled for the Log360 rule to fire. Without DNS audit logging, no event is generated when DNS records are created.
• Enforce SMB signing as required across all domain-joined systems via Group Policy. SMB signing prevents NTLM relay attacks that exploit Net-NTLMv2 hashes captured through DNS spoofing coercion. Set Microsoft network server: Digitally sign communications always to Enabled in the Default Domain Policy.
• Enable Extended Protection for Authentication (EPA) on services that support it, including IIS, Exchange, and LDAP. EPA prevents NTLM relay attacks by binding authentication to the specific TLS channel, making captured authentication material non-replayable against services with EPA enabled.
• Deploy and enforce LDAP signing and LDAP channel binding on all domain controllers. These controls prevent NTLM relay to LDAP, which is one of the highest-value relay targets because successful relay to LDAP can be used to modify Active Directory objects including account permissions.
• Implement DNS monitoring as a standing control independent of the Log360 rule. Run a weekly automated comparison of all DNS records against the documented host inventory. Any record not attributable to a known host, DHCP registration, or documented DNS management action should generate a remediation ticket.