Golden Ticket attack – detecting Kerberos attacks and securing Active Directory

Why the KRBTGT account is critical

The KRBTGT account is a special service account in the domain whose sole purpose is to maintain the cryptographic key used by the KDC to sign and validate Ticket Granting Tickets. In other words: when the KDC issues a TGT, it contains a portion protected with the key associated with the KRBTGT account. Every TGT must be verifiable by the KDC using this key — hence the term “master key.” Possession of the KRBTGT key enables the creation of TGTs that the KDC accepts as valid.

Consequences of compromising KRBTGT

• An attacker who has the key can generate TGTs outside the system — they no longer need direct access to the domain controller to obtain credentials.

• The generated TGTs can contain any fields (any identity, any groups, and especially a very long validity period), which enables persistent access and privilege escalation.

• Because the ticket’s signature and encryption are correct, most security mechanisms will not identify obvious anomalies — to the system, this is a legitimate Kerberos operation.

Where and how the KRBTGT key is stored

The KRBTGT account key is stored in the Active Directory database and is accessible to processes capable of reading directory data (for example, through directory replication privileges). Attackers typically use one of the following methods: gaining administrative access to the domain controller and copying directory files, using tools that simulate directory replication to extract the key material, or relying on other methods of retrieving information to extract the key. After obtaining the key, the creation of TGTs is performed offline using publicly available tools.

Technical characteristics of the ticket that make KRBTGT a key target

A TGT contains fields that are critical for detecting anomalies: the issuance time, the expiration time, the renewal limit, technical attributes controlling ticket behavior, the encryption method, the user identifier, the service identifier, group memberships, and the key version number. The KDC verifies the TGT signature using the key corresponding to the current version number of the KRBTGT account. If an attacker uses a correct key, the KDC accepts the ticket without further validation — hence the need for KRBTGT rotation to invalidate previously issued or forged tickets.

Ticket lifecycle — example and meaning of fields

A typical scenario: a user logs in and receives a TGT valid for several hours, with a limited renewal period. The encryption method follows the domain’s security policy, and the technical attributes indicate, for example, that the ticket can be forwarded or renewed. Standard lifetimes last for hours, and the renewal period is limited to a few days. In a Golden Ticket attack, the attacker may generate a TGT with an expiration date extended by years, with a weaker or inconsistent encryption method, and with the identity set to a privileged account. Such a ticket appears valid and will be accepted. Detection requires analyzing these fields and comparing them with the domain’s policy.

KRBTGT key rotation — what it changes and what its limitations are

Rotating the KRBTGT password or key changes its version number. After rotation, tickets signed with the old key are no longer valid. This is the only direct method of invalidating forged TGTs created using a stolen key. However, rotation is operationally costly: it requires synchronization across the entire domain, regression testing of services that rely on Kerberos, and often a multi-step procedure (in practice, at least two password changes are recommended, spaced apart, to avoid issues with replication and compatibility). Rotation will not prevent future attacks if the original compromise is not resolved — it should be treated as part of remediation, not the only solution.

Kerberos operates as a ticketing system, and its security relies on the secrecy of keys associated with accounts. The KRBTGT account holds the most critical key: compromising it enables attackers to generate tickets that appear legitimate, granting access to domain resources without further interaction with the domain controller. Therefore, defensive priorities include restricting access to directory replication mechanisms, continuously monitoring Kerberos ticket fields (lifetime, encryption type, identity, technical attributes), and maintaining a tested process for rotating the KRBTGT key as part of the remediation plan.

Golden Ticket attack mechanics — step by step

Step 1 — obtaining access

What the attacker does:
Gains access to the network and elevates privileges to an administrative account. The goal is the ability to operate on privileged hosts and, ultimately, to reach the domain controller or accounts that hold directory replication permissions.

Typical vectors and tools:
Targeted phishing messages, exploitation of weak or leaked passwords, remote connections made with insufficiently protected accounts, abuse of administrative processes and remote command-execution mechanisms, and local privilege escalations through system vulnerabilities.

Artifacts and telemetry to collect:

• System logs: unusual interactive logins, privileged accounts logging in from new or rare sources.

• Remote access: remote connections from unusual locations, spikes in incoming sessions.

• Processes and file activity: execution of administrative tools, creation of system tasks by unusual accounts, appearance of new binaries.

• Network traffic: increased communication between workstations and servers, unusual connections to administrative shares.

• Security monitoring: processes launching from non-administrative contexts, suspicious memory access by system processes.

What to monitor immediately:
Login anomalies on privileged accounts, new accounts gaining local admin rights, use of administrative tools on user endpoints.

Step 2 — stealing the KRBTGT hash (obtaining key material)

What the attacker does:
Obtains the KRBTGT account key or other material that enables signing Kerberos tickets. This is done by reading directory data, abusing replication mechanisms, or accessing process memory.

Typical tools and techniques:
Credential-extraction utilities, unauthorized use of directory replication mechanisms, copying of directory files, creation of backup snapshots, and reading memory of authentication-related processes.

Artifacts and telemetry to collect:

• Directory replication: replication requests coming from hosts that are not domain controllers.

• Files and backups: snapshot creation on domain controllers, copying of directory files, unexpected operations on system files.

• Process memory: attempts to read memory of authentication processes, increased I/O associated with those processes.

• Credential-extraction indicators: artifacts suggesting use of tools designed to extract account information.

• Directory audit: access events targeting account attributes and directory objects outside normal operations.

Detection and limitations:
Alert every replication attempt performed outside domain controllers, detect and block reads of authentication-process memory, limit accounts that hold replication rights, and apply least-privilege principles to administrative accounts.

Step 3 — forging the TGT (offline creation)

What the attacker does:
Outside the domain environment, creates a TGT signed with the stolen KRBTGT key. Ticket fields are set to the attacker’s needs — including identity, group membership, technical ticket parameters and validity period (often drastically extended).

Typical operations:
Use of tools capable of generating Kerberos structures offline and modifying parameters such as lifetime or encryption type.

Symptoms in telemetry:

• Tickets with validity far exceeding domain policy.

• Tickets using encryption types inconsistent with domain settings.

• Tickets issued for inactive or non-existent accounts.

• Key version numbers inconsistent with the current policy.

What to monitor:
Complete Kerberos log data and network traffic, comparison of ticket parameters with domain policy, correlation with directory data (account status, last logon, group membership).

Step 4 — using the ticket (in-environment exploitation)

What the attacker does:
Presents the forged TGT to directory services, obtains service tickets, and uses them for lateral movement, privilege escalation, and accessing resources.

Typical behavior patterns:

• Sudden bursts of service requests: many access requests to various services in a short period of time.

• Access to key services using unexpected accounts: e.g., directory or file-share access from accounts that normally do not perform such actions.

• No login failures: most events are successful logins, which complicates detection.

• Unexpected sources: tickets presented from hosts not associated with the account’s normal profile.

Telemetry for correlation:

• Kerberos events for TGT and TGS requests.

• Service logs showing Kerberos-authorized access.

• Network traffic preceding and following ticket use.

• Directory data: account status, last activity, permission changes.

Immediate response:
When anomalies are detected, isolate involved hosts, block accounts presenting suspicious tickets, collect forensic material, and—if confirmed—prepare the KRBTGT key rotation process.

Key data sources

A Golden Ticket attack is a sequence of actions leading to acquisition of the KRBTGT key. Possession of that key allows creation of fully valid Kerberos credentials. Defense must operate on two parallel planes: securing access to the key material and performing detailed monitoring of ticket parameters and their usage.

1) Domain controllers / Active Directory

What to collect: file-system operations on directory files, access logs for directory objects, replication events.
Signals: snapshots, copying directory files, unauthorized replication requests.
Priority: critical.

2) Kerberos logs and network traffic

What to collect: complete ticket-issuance events including parameters.
Signals: tickets with long lifetimes, mismatched encryption types, tickets for non-existent accounts.
Priority: high.

3) Endpoints and memory

What to collect: events indicating suspicious memory access, use of credential-extraction utilities.
Priority: high.

4) Permissions and replication

What to collect: lists of accounts with replication privileges, changes to privileged groups.
Priority: critical.

5) Ticket-usage patterns

What to collect: rate of requests, host mapping, number of services accessed.
Priority: high.

Quick list of alerts to deploy

• Unauthorized replication requests — critical

• Tickets with lifetime > 24 hours — high

• Encryption types inconsistent with domain policy — high

• Sudden bursts of service requests by a single principal — high

• Reading memory of authentication processes or snapshot creation on domain controllers — critical

Why the Golden Ticket attack is difficult to detect

The Golden Ticket attack targets the protocol and cryptographic layer rather than the process or file layer. This means that most security tools — antivirus, endpoint protection, firewalls, simple SIEM rules — observe the wrong signals. This section explains the mechanical reasons for this problem, the technical consequences for detection, and short, practical guidelines on what exactly must change in the approach to have a real chance of detecting misuse.

Problem #1 — the ticket is “legitimate” (cryptographic correctness)

What happens:
A forged TGT is signed with the correct key used by the domain. Services verifying the ticket treat it as authentic because all cryptographic checks pass. At the protocol level there is no “error”; Kerberos traffic appears syntactically correct.

Why traditional mechanisms fail:

• Endpoint protection detects malicious binaries, malicious processes, unusual system calls — none of these occur when the ticket is presented.

• Network protection sees normal Kerberos traffic and has no rules that would block a valid Kerberos exchange.

• SIEM rules based on simple signatures (failed logons, malformed packets, known IOC) will not trigger because events appear as successes.

Consequences for detection:
Detection must focus on the semantics of the ticket, not on whether the signature is valid. It must read and interpret ticket fields — start/end/renew-till values, encryption type, key version number, client identity, and group identifiers — and compare them with policy and historical patterns.

Practical detection rules:

• Parse and store full Kerberos authentication events instead of aggregating them.

• Alert on TGT/TGS tickets with end or renew-till values exceeding policy (for example, more than 24 hours).

• Alert on encryption types that do not match the domain’s policy.

• Correlate ticket data with account state: unusual client identities combined with disabled or nonexistent accounts require elevated priority.

• Monitor historical key version numbers — unusual or inconsistent values may indicate forged tickets.

Problem #2 — persistence

What happens:
With access to the cryptographic material, the attacker can generate tickets at any time and use them from any host — even one that has never been compromised. This can be repeated indefinitely, without maintaining access to the domain or reinfecting machines. The ticket may have a long validity period, enabling persistent access without further intrusion.

Why traditional mechanisms fail:

• Endpoint monitoring detects activity on compromised hosts, but the attacker may use a forged ticket on a clean, uncompromised machine.

• SIEM may not correlate a “single use” of a ticket with the earlier compromise of the key material if historical data is missing.

• Many procedures rely on detecting a high number of failed attempts — but here all operations succeed.

Consequences for detection:
Detection requires monitoring long-term anomalies and the ticket history associated with each account; short-term snapshots are insufficient.

Practical detection rules:

• Retain Kerberos logs for a long period and make it possible to reconstruct the timeline of ticket use.

• Alert when a privileged account becomes active again with long-lived tickets after an extended period of inactivity.

• Use host-mapping: if a ticket is presented from a machine outside the normal profile for a given identity, raise priority.

• Detect backdated or long-lived tickets by comparing their validity with domain policy.

Problem #3 — log evasion (no obvious authentication errors)

What happens:
A forged TGT is valid — the domain grants service tickets, and logons appear as successful. There are no authentication errors, so rules detecting brute force or failed attempts do not trigger. Additionally, many environments aggregate or filter logs, treating successful Kerberos events as noise, which reduces visibility.

Why traditional mechanisms fail:

• Security systems often focus on failed authentication, not on anomalies within successful events.

• Domain controller logs may be normalized or aggregated in a way that removes detailed ticket fields required for detection.

• Lack of correlation with directory data (account status, last logon time, group membership) prevents correct interpretation of successful but suspicious events.

Consequences for detection:
Detection must treat “successes” as potentially malicious and correlate them with directory context and behavioral network indicators. Counting failed attempts is not sufficient; analyzing patterns of successful events is required.

Practical detection rules:

• Collect full, non-normalized Kerberos authentication events with all fields.

• Correlate successful Kerberos events with account metadata: disabled state, last logon time, group membership changes; a success involving a disabled account should raise an immediate alert.

• Monitor the rate of successful service ticket issuance: if a single identity obtains access to many services in a short window, treat it as reconnaissance.

• Analyze the “signature” of the ticket: key version history, unusual encryption types, validity fields inconsistent with policy.

Short technical checklists

Immediate actions:

• Parse and store full Kerberos authentication details (client identity, service identity, key version, encryption type, start/end/renew-till values, flags).

• Alert when validity exceeds 24 hours; raise to a higher level above seven days; treat above one year as critical.

• Alert when encryption types deviate from policy.

• Alert on successful Kerberos events involving disabled or nonexistent accounts.

• Retain Kerberos logs for at least 90 days (365 recommended in high-risk environments).

Short-term operational actions:

• Audit and minimize rights related to directory replication; monitor replication-related operations.

• Implement dedicated, hardened administrative workstations and just-in-time access for privileged accounts.

• Prepare a tested procedure for rotating the key used to sign tickets.

The problem does not lie in a “lack of tools” but in underlying assumptions — traditional systems look for errors and malicious processes, while the Golden Ticket attack operates at the protocol level, generating valid transactions. Detection requires shifting focus from “what broke” to “whether what looks correct actually matches normal behavior and policy.” Implementing Kerberos ticket parsing, correlating data with directory metadata, and long-term behavioral analysis are essential.

What network anomalies can indicate Kerberos attacks?

To detect Kerberos abuse, you must look deeper than just identifying “Kerberos traffic.” What matters is how the ticket itself looks and how it behaves when used. Below are four key indicators — what to examine, why it matters, how to reduce false positives, and what actions to take once detected.

1. Unusual ticket lifetime

What to examine:

• the time the ticket becomes valid,

• the time it expires,

• the renewal limit,

• and the difference between the start and end times.

Standard Kerberos tickets in Active Directory last only a few hours. Tickets valid for days, weeks, months, or even years are a critical red flag.

Example severity thresholds:

• more than one day — warning sign,

• more than a week — high priority,

• more than a year — critical.

Why it works:
Attackers extend ticket lifetimes to ensure long-term, stealthy access.

How to reduce false positives:
Some batch or background services may rely on longer ticket durations. These should be placed on an exception list.

The alert should be considered high priority especially when extended ticket lifetime appears together with other anomalies, such as unusual encryption type or use from unexpected hosts.

Response:
Verify the associated account, examine which hosts are presenting the ticket, determine the privilege level, and begin remediation if necessary.

2. Weak or unexpected encryption algorithms (enctype mismatch)

What to examine:

• the encryption algorithm used in the ticket.

Modern AD environments normally use AES-based encryption. If older methods such as RC4 suddenly appear — especially in an environment enforcing AES — this is a strong indicator of a manually generated ticket.

Why it works:
Offensive tools often rely on older algorithms because they are faster or widely compatible.

How to reduce false positives:
Some legacy applications genuinely require older encryption algorithms, and they should be identified and included on an exception list.

Response:
If the ticket does not come from a known legacy service and uses an unexpected algorithm, treat it as a serious indicator of compromise and begin forensic investigation.

3. Tickets issued for nonexistent or long-inactive accounts

What to examine:

• whether the account is active or disabled,

• when it last authenticated,

• its group memberships.

If tickets suddenly appear for accounts that have been disabled or unused for many months, this is a very strong sign of credential misuse.

Why it works:
Attackers often try to use old admin accounts or “ghost” accounts that have stayed unnoticed in daily monitoring.

How to reduce false positives:
Some service accounts may intentionally remain disabled or rarely used. These should be marked as exceptions where appropriate.

Response:
Verify the account immediately, block the ticket if possible, and investigate the hosts that presented the ticket.

4. Unusual service request patterns (TGS bursts)

What to examine:

• how many different services a single account requests in a short time,

• how many hosts are presenting tickets for that account.

If a single account suddenly requests access to many services in just a few minutes, this resembles reconnaissance or lateral movement.

Example thresholds:

• more than about 20 different services in several minutes — suspicious,

• more than about 50 — high-confidence alert,

• combined with multiple hosts presenting the ticket — very high certainty of malicious activity.

Why it works:
Attackers test where their stolen or forged tickets can be used.

How to reduce false positives:
Automated deployment or management processes may legitimately generate many service requests; add such processes to exception lists.

Response:
Isolate affected hosts, block or restrict the account, limit Kerberos traffic from suspicious endpoints, and start incident investigation.

Quick summary: indicator → priority → first response

Unusual ticket lifetime (more than 24 hours)
• priority: high
• first action: identify the account, compare with typical host activity

Unexpected encryption algorithm
• priority: high
• first action: verify whether the service is legacy; if not, escalate

Ticket for a disabled or long-inactive account
• priority: critical
• first action: block the account and investigate the host that used it

Burst of TGS requests
• priority: high to critical
• first action: isolate source hosts and analyze the activity

Practical deployment tips

• Analyze full Kerberos ticket fields instead of relying only on event counts.

• Correlate authentication logs with directory data — account status, last logon, privilege level.

• A single signal may not mean much; two or three correlated signals usually indicate a real incident.

• Tune detection thresholds to match your environment’s behavior.

• Track effectiveness — reaction time, false-positive rate, and how much ticket activity you are capturing.

Related attack techniques: Kerberoasting and Pass-the-Ticket

Kerberoasting and Pass-the-Ticket often appear together in APT campaigns and can either serve as steps leading to the creation of a Golden Ticket or emerge as side effects of a broader compromise. Both techniques operate on Kerberos credentials, but they differ in the origin and nature of these credentials: Kerberoasting extracts encrypted service tickets to crack service account passwords offline, while Pass-the-Ticket consists of stealing an existing, legitimate ticket from memory and reusing it. A Golden Ticket, meanwhile, is a forgery—possession of the KRBTGT key allows the attacker to generate entirely new, cryptographically valid TGTs.

Distinguishing these techniques has direct implications for detection and remediation. Kerberoasting indicates reconnaissance activity and preparation for privilege escalation (requiring monitoring of service ticket requests and directory queries related to SPN values). Pass-the-Ticket suggests a host or memory compromise (requiring analysis of anomalies in memory access and host mapping). Detection of a Golden Ticket requires immediate focus on KRBTGT key material and planned key rotation. Below are the technical details, telemetry, and detection rules for each of these techniques.

Kerberoasting — mechanics and signatures

Mechanics:
The attack relies on requesting service tickets for service accounts associated with SPN values. A portion of each service ticket is encrypted with a key derived from the service account’s password. The attacker saves the encrypted ticket and performs offline password cracking. A successful crack reveals the service account password, which often allows privilege escalation or lateral movement—potentially leading to access levels that can ultimately enable the creation of a Golden Ticket.

Where it strikes:
Service accounts with SPN values, especially those with elevated rights or tied to critical services.

Telemetry and artifacts

• A high number of service ticket requests directed at service accounts.

• Increased directory queries related to SPN values.

• Local storage or export of tickets linked to processes retrieving Kerberos tickets.

• No failed authentication attempts — service ticket requests appear legitimate.

Detection — short rules

• Trigger an alert when the number of service ticket requests for an account significantly exceeds its usual baseline.

• Trigger an alert when there is a sudden increase in directory queries related to SPN values.

• Correlate activity: Kerberoasting indicators combined with subsequent unusual account behavior → raise alert priority.

Mitigations

• Use managed service accounts where possible (random, rotating passwords).

• Enforce strong, random passwords for service accounts.

• Minimize service account privileges; avoid using them as domain administrators.

• Monitor and restrict directory queries related to SPN values; maintain allow-lists for legitimate automation tools.

Pass-the-Ticket — mechanics and signatures

Mechanics:
The attacker obtains a legitimate Kerberos ticket (authentication or service ticket) from system memory or local ticket cache and uses it on another host. The attacker does not need the password — they reuse existing credentials. This allows instant lateral movement and access to services with the privileges of the ticket owner.

Where it strikes:
Initially in the memory of the compromised host; later in the systems where the stolen ticket is presented.

Telemetry and artifacts

• Actions indicating memory inspection or copying of security-related processes.

• Kerberos logon events from hosts that do not match the typical activity profile for a given principal.

• Lateral movement patterns where access to resources appears without failed authentication attempts.

• Changes in local ticket caches.

Detection — short rules

• Trigger an alert when memory inspection activities targeting authentication-related processes are detected.

• Trigger an alert when Kerberos logon success events originate from hosts unrelated to the principal’s historical host set.

• Correlate: an indicator of ticket reuse combined with subsequent bursts of service ticket activity → high confidence.

Mitigations

• Enable mechanisms that isolate authentication secrets in memory.

• Restrict privileges that allow memory debugging or inspection.

• Block unapproved creation of process memory dumps.

• Enforce role separation and require administrators to use hardened admin workstations.

Differences compared to Golden Ticket

• Source of credentials:
  Kerberoasting and Pass-the-Ticket rely on existing credentials. Golden Ticket relies on compromise of the KRBTGT key.

• Mode of operation:
  Kerberoasting → offline cracking of a service account password.
  Pass-the-Ticket → reusing a stolen legitimate ticket.
  Golden Ticket → full credential forgery.

• Scope of impact:
  Golden Ticket enables the attacker to generate tickets with arbitrary lifetime and group memberships, giving the highest level of persistence.
  Pass-the-Ticket is limited to the privileges of the stolen ticket.
  Kerberoasting may lead to access that enables further escalation.

Immediate detection rules

• High volume of service ticket requests → possible Kerberoasting.

• Detection of memory access related to credential processes → possible Pass-the-Ticket.

• Ticket usage from a host outside the principal’s normal host profile → possible Pass-the-Ticket or lateral movement.

• Kerberoasting indicators followed by anomalous logons or service ticket bursts → high certainty of escalation activity.

Immediate operational mitigations

• Deploy managed service accounts and strong passwords for service accounts; regularly review SPN assignments.

• Restrict debugging-level privileges and memory-access permissions; enable memory protection features.

• Monitor and restrict directory replication privileges; audit accounts with elevated replication rights.

• Maintain a response playbook:
  – For Kerberoasting → identify the requesting account, block or reset the service account.
  – For Pass-the-Ticket → isolate source and destination hosts, collect memory artifacts, analyze ticket timelines.
  – For potential Golden Ticket → examine replication activity and prepare a KRBTGT rotation plan.

Monitoring as the foundation of an Active Directory security strategy

Active Directory is built on a trust model — Kerberos was designed as a mechanism that allows services to trust tokens issued by a central service. This architecture is its strength, but also its weakness: when an attacker takes over the signing key (KRBTGT), they can create legitimate-looking credentials and operate for a long time without being noticed. In this reality, prevention and detection must always go hand in hand.

Prevention reduces the likelihood of an attacker obtaining credentials: minimizing privileges, separation of roles, using hardened admin hosts, JIT/JEA and MFA are the foundations. A special role is played by planned rotation of the KRBTGT key — this is the only technical method to invalidate previously stolen tickets. However, rotation is operationally risky and requires testing, which is why it should be part of routine procedures, not a chaotic reaction.

Despite these measures, every team must assume that prevention will fail at some point. Then detection becomes the only real chance to stop the damage. It is not enough to look at “processes” or count failed logins — it is necessary to understand Kerberos semantics and monitor anomalies at the ticket level and in usage patterns.

What monitoring must do

Monitoring must read tickets, understand them, and compare them with domain context. This means extracting from AS-REP and TGS-REP fields such as client principal, service principal, start, end, renew_till, enctype, kvno and flags, and then correlating this data with AD metadata (account status, lastLogon, group memberships, replication rights).

Actions to implement:

• Enable Kerberos parsing at the network layer (PCAP/NetFlow) and store full 4768/4769 events with all fields.

• Integrate SIEM with AD lookups (account status, lastLogon, memberOf, accounts with replication rights).

• Store these events long-term (minimum 90 days, recommended 365 days for critical environments).

How to combine prevention with detection

Prevention (e.g., limiting DCSync rights, gMSA, MFA) reduces risk but does not eliminate the need for detection. Detection must be designed to quickly identify anomalies that indicate the use of stolen tickets.

Operational checklist:

• Limit AD replication rights to the absolute minimum and monitor every use of these rights (DCSync).

• Implement gMSA wherever possible; remove weak service accounts with high-level privileges.

• Enforce MFA on privileged accounts; ensure administration is performed only from hardened admin hosts.

Key signals that monitoring must detect

A forged ticket looks correct, but it leaves traces in fields and usage patterns. Monitoring should detect long lifetimes, enctype mismatches, tickets for inactive accounts, and TGS request bursts.

Rules for immediate implementation:

• Alert: ticket_lifetime > 24h (raise to critical at >7 days, highest priority at >365 days).

• Alert: enctype outside the list of allowed algorithms (e.g., appearance of RC4 in an AES-only environment).

• Alert: ticket for a disabled account or with lastLogon > 365 days.

• Alert: TGS burst (e.g., >20 unique service principals requested by one principal in 5 minutes).

Operational response — how monitoring translates into action

When the alert score increases, actions must be fast and organized: isolation of hosts presenting suspicious tickets, securing privileged accounts, collecting artifacts for forensics, and assessing the need for KRBTGT rotation.

Reaction sequence:

• Collect full Kerberos events, PCAP, and AD lookup for the principal.

• Isolate source hosts and stop Kerberos traffic from them (NAC/firewall).

• Temporarily block/de-escalate the principal account (considering impact on services).

• Collect LSASS memory dumps, NTDS.dit snapshots and replication logs; if KRBTGT is compromised, initiate the rotation plan (two-stage, tested).

EDR detects attacks on hosts, SIEM aggregates logs, but only NDR can parse the Kerberos protocol in traffic, interpret ticket fields, and correlate them with the domain map in real time. This combination makes it possible to detect an attack that looks “legitimate” from the system’s perspective.

Active Directory security is a process in which prevention minimizes risk, and monitoring — by understanding the protocol and domain context — provides a real opportunity to detect and stop an attacker before they cause irreversible damage. Implementing Kerberos parsing, AD correlation, and a prepared KRBTGT rotation plan are three elements worth starting immediately.