This article explains how ThreatDefence uses monitored honeytoken accounts to detect suspicious activity targeting privileged or high-value identities across Active Directory environments.

A honeytoken account is a controlled decoy identity that should never be used by a person, service, application, script, scheduled task, or administrative process. Because the expected activity baseline is zero, any authentication attempt, Kerberos ticket request, sign-in event, or account interaction involving the honeytoken account is treated as highly suspicious and generates a high-fidelity signal for SOC investigation.

This control is intentionally simple: deploy decoy identities, ensure they have no legitimate operational use, monitor them continuously, and alert when they are accessed or targeted. It is not a replacement for preventative identity controls, but it provides a strong detection layer for activity that may indicate account discovery, password spraying, Kerberoasting, credential misuse, or post-compromise reconnaissance.

Why Honeytoken Accounts Are Useful

Identity-based attacks in Microsoft environments often produce noisy telemetry. In Active Directory, Kerberos is used constantly for normal authentication. When a user accesses a file share, application, database, web service, or other domain-integrated resource, the workstation may request Kerberos tickets from a domain controller. This can generate high volumes of events, especially Event ID 4768 for Ticket Granting Ticket requests and Event ID 4769 for service ticket requests.

For normal user or service accounts, this activity often requires baselining before it can be classified as suspicious. A Kerberos service ticket request for a real service account may be legitimate, misconfigured, or malicious depending on the context.

Honeytoken accounts remove much of this ambiguity. There should be no valid business process that causes a user, host, or application to authenticate as the honeytoken account, request a ticket for it, or interact with it in Entra ID. As a result, even a single event involving the account becomes a high-confidence signal for investigation.

ThreatDefence monitors honeytoken accounts as part of its MDR service and correlates activity with surrounding telemetry, including the source user, source host, IP address, domain controller, application, device details, and related events.

The actual account names and configuration details are customer-specific and are not disclosed in public documentation.

Honeytokens in Active Directory Environments

In Active Directory environments, honeytoken accounts provide high-fidelity detection signals for suspicious identity activity. They help identify account reconnaissance, attempts to interact with identities that should never be used, and attacks such as Kerberoasting.

Kerberos is a legitimate authentication protocol used in every Active Directory deployment to verify user and computer identities and allow access to domain resources such as file shares, applications, databases, and internal services. Under normal conditions, Kerberos authentication works as follows:

1. The workstation requests a Ticket Granting Ticket from the domain controller.
2. The domain controller issues the Ticket Granting Ticket and a session key.
3. When the user accesses a domain-integrated resource, the workstation requests a service ticket.
4. The domain controller issues the service ticket and associated session key.
5. The workstation presents the service ticket to the resource server.
6. The resource server validates the ticket and grants access.

The same mechanisms used for legitimate authentication can be abused for privilege escalation and lateral movement. An attacker with access to a standard domain account may enumerate accounts with Service Principal Names and request Kerberos service tickets for those accounts. The attacker can then extract ticket material and attempt to crack it offline to recover the service account password, especially if the password is weak or reused.

A typical Kerberoasting flow is:

1. The attacker uses a valid domain account to request a Ticket Granting Ticket from the domain controller.
2. The domain controller issues the Ticket Granting Ticket.
3. The attacker requests a service ticket for an account with a Service Principal Name.
4. The domain controller issues the service ticket.
5. The attacker extracts the ticket material and attempts to crack it offline.

This behaviour can often be reconstructed from Windows security events and SIEM telemetry. The challenge is that this telemetry does not automatically prove malicious activity. Kerberos service ticket requests are completely normal in Active Directory. A real service account may legitimately receive authentication activity from multiple systems, applications, or users. In larger environments, the SOC must correlate the source user, source host, target account, service name, ticket options, encryption type, expected access patterns, and related endpoint or network activity before determining whether the event is suspicious.

Common Kerberoasting detections usually look for patterns such as:

• high-volume service ticket requests from one user or host;
• requests for rarely used Service Principal Names;
• requests from users that do not normally access those services;
• service ticket requests from unusual workstations;
• use of weaker encryption types;
• unusual activity involving privileged or high-value service accounts.

These detections are useful, but they can still be noisy in real environments because legitimate administrative tools, applications, scanners, and business systems may produce similar patterns.

With honeytokens in place, detection becomes more direct. A high-confidence alert can be generated when a domain controller records a Kerberos service ticket request, authentication attempt, or other account interaction involving a honeytoken identity. Unlike a normal service account, there is no expected business process to explain the activity, so the event can be treated as suspicious immediately and prioritised for SOC investigation.

The key event source is usually Windows Security Event ID 4769, which records Kerberos service ticket requests. Important fields for investigation : include

How to Enable Honeytokens

In the Customer Portal, go to Deployment → Honeytokens to view instructions on how to enable the feature.