Detecting T1558 Steal or forge Kerberos tickets

How T1558 Kerberos ticket theft and forgery reaches your domain

T1558, Steal or forge Kerberos tickets, lets an adversary under the Credential Access tactic (TA0006) obtain or fabricate Kerberos tickets so they can act as an identity without ever seeing its password. Kerberos is the trust backbone of most Windows estates, so a valid ticket often opens the same doors as a valid logon. In Enterprise ATT&CK 20.0, T1558 groups five sub-techniques that describe different ways tickets are taken or forged, which means a single detection rule will not cover the whole technique. For a SOC lead, the practical question is which of those five paths your environment exposes and which of them your telemetry can actually see.

Ticket abuse rarely starts from nothing. It usually appears after an identity has already been compromised, for example through a phished user, a misused service account or a foothold on an endpoint that holds cached credentials. Once an adversary has that foothold, ticket material can extend their reach across services without generating the failed-logon noise that password guessing produces. This is why T1558 detections belong in the same review as identity compromise response, not only in the endpoint queue. Confirm with your identity team which service accounts can request service tickets, which accounts have Kerberos pre-authentication disabled, and which encryption types are still permitted in your domain policy, since each of these changes what normal looks like.

Before you commit detection effort, pin the ATT&CK version you are mapping to. The Enterprise matrix is updated regularly, and MITRE notes that releases can rename, deprecate or revoke techniques, so your coverage record should name the version it targets. Then ask your team whether domain controllers and endpoints can supply the data components ATT&CK links to Credential Access, including User Account Authentication (DC0002), File Access (DC0055) and Process Access (DC0035). If one of those sources is missing, you have a visibility gap to close before any rule for T1558 can be trusted, and that gap is a decision for your platform owners, not a detail for the rule author.

Which telemetry reveals Kerberos ticket abuse

This table maps the ATT&CK data components relevant to T1558 to the signals they can reveal, where each collector sits, and which open-source tool gathers the data. Read each row as a starting point for analytics, then confirm data component coverage against the ATT&CK version your team targets, since releases can change mappings. The main takeaway is that no single source covers all five sub-techniques, so domain controller logs and endpoint file and process telemetry must be collected together.

Data component	Signal to look for	Collection point and open-source collector
File Access (DC0055)	Access to Kerberos credential cache files or keytab files by processes that are not the expected Kerberos client	Linux hosts with Kerberos clients, collected with Wazuh agent file integrity or audit rules, and Velociraptor artifacts on demand
Process Access (DC0035)	Non-system processes opening the LSASS process or other ticket-holding memory with ticket-related access rights	Windows endpoints, collected with Sysmon process access events forwarded through Windows Event Forwarding to Wazuh or Security Onion
User Account Authentication (DC0002)	Ticket requests for service accounts from unusual hosts, unusual encryption types, or ticket lifetimes that deviate from domain policy	Domain controllers, collected from Security event logs for Kerberos authentication through Windows Event Forwarding into Wazuh
Application Log Content (DC0038)	Kerberos ticket requests and failures recorded by services, identity middleware, or Linux authentication stacks	Domain controllers, application servers and Linux hosts, collected with Wazuh log collection and Zeek logs for Kerberos traffic
Logon Session Metadata	Logon sessions that reuse ticket material or appear without a matching interactive or network logon	Windows endpoints and domain controllers, collected from logon event metadata through Windows Event Forwarding and Wazuh rules
Network Traffic Content (DC0085)	Kerberos messages on TCP or UDP port 88 with request patterns that do not match normal client behavior	Network sensors on domain controller segments, collected with Zeek Kerberos logs and Suricata alerts in Security Onion
Coverage check	Each data component mapping depends on the ATT&CK version and detection strategies in use	Ask the team to confirm data component coverage for the targeted ATT&CK version before tuning rules in a private cyber range

Detection logic for Kerberos ticket theft and forgery

The four to six ideas below cover the Kerberos behaviors that most often reveal stolen or forged tickets: unusual ticket properties, requests without the expected authentication, tickets used from the wrong place, and session metadata that contradicts the account. Each idea needs a baseline before it can produce useful alerts, and each one depends on the same discipline: tune against your own environment and document every exception.

Anomalous ticket lifetime and encryption

Compare the lifetime and encryption type of issued Kerberos tickets against a baseline for each account class, such as interactive users, service accounts and computer accounts. Tickets with lifetimes or encryption types outside the observed range for that class deserve review, especially when the same account suddenly requests weaker encryption. Build the baseline over a window long enough to include month-end jobs and patch cycles, usually several weeks. Expect false positives from legacy applications that still negotiate older encryption types and from service accounts with custom lifetime policies. Record each exception with an owner and a review date, so the rule stays narrow over time.

Service tickets without preceding authentication

Flag service ticket requests where the requesting identity has no matching ticket-granting ticket issued within the expected window. This pattern can indicate forged or replayed tickets, since a valid session normally begins with an initial authentication event. Set the time window by measuring normal gaps between initial and service requests in your domain controller logs, and treat gaps beyond that window as candidates for triage. Common false positives include cached ticket reuse on long-lived workstation sessions, scheduled tasks running under stored credentials, and time skew between hosts that shifts event ordering. Confirm your clocks are synchronized before tuning the threshold.

Tickets used from unexpected hosts

Correlate the client address and workstation name recorded in ticket requests with the host where the account normally authenticates. A ticket for a user that appears from a server, a jump host outside its usual pattern, or an address never seen for that account warrants investigation. Build a per-account host profile over a baseline window and alert on first-seen source pairs for privileged accounts first. Expect noise from vulnerability scanners, backup agents, monitoring platforms and administrators using remote management tools, so maintain an allowlist of those sources. Validate the rule by replaying a known legitimate administrative session in your cyber range before relying on it.

Session metadata that contradicts the account

Compare logon session metadata, including logon type, authentication package and session start time, against what the account is expected to produce. Mismatches such as a service-only account creating interactive logons, or a session using an authentication package the account has never used, are high-value signals. Tune thresholds per account tier rather than per domain, because privileged and standard accounts have very different baselines. Typical false positives include legacy services that authenticate through older packages, batch jobs with unusual logon types and help desk tools that impersonate users. Ask your identity team to document every service account that is expected to deviate from the norm.

Sigma rules as shared detection logic

Express each of the detection ideas above as a Sigma rule so that the logic can be reviewed, versioned and converted to the query language of your SIEM, such as Wazuh or Security Onion. Sigma rules separate the detection logic from the backend, which makes it easier for a second engineer to audit thresholds and exceptions. Record the ATT&CK version each rule targets, since technique and detection mappings change between releases. Keep a changelog for every tuning decision, and link each rule to the cyber range test that validated it. Confirm which log sources and field names your domain controllers produce before converting any rule.

How to validate that T1558 detections fire

This sequence proves, in a private lab or cyber range, that each T1558 detection produces an alert the blue team can act on, and it turns every gap into a dated, re-testable tuning item. It runs against a named ATT&CK version so results stay comparable after releases.

Agree scope and ATT&CK version
The red and blue teams, with the platform owner for Active Directory or identity, agree which T1558 sub-techniques are in scope, which Windows, Linux and macOS hosts or service accounts are used, and which ATT&CK version the mapping targets. Pin the version in the test plan because MITRE can rename, deprecate or revoke techniques between releases. The step is done when the signed scope names the version, the hosts, the test accounts and the rules of engagement, and the blue team confirms it can see the data sources it expects to use.
Confirm telemetry and collector baselines
Before any emulation, the blue team checks that the relevant data components are being collected on the in-scope hosts and domain controllers. For T1558 this typically means Logon Session Metadata, User Account Authentication and Process Access where the platform supports them, plus File Access for any ticket cache or keytab paths in scope. Record the agent versions, log forwarding status, time synchronization and event volume per host as a baseline. The step is done when a benign test logon appears in the SIEM from every in-scope source within the time the team has agreed as acceptable.
Run approved emulation per sub-technique category
The emulation team runs an approved, scoped exercise for each sub-technique category in the agreed plan, using a test account and a range domain that has no production trust. Commands and tooling stay in the controlled runbook and are not published, and each run is given a unique identifier and start and end timestamps. The step is done when every run has a completed record showing the category tested, the host and account involved, and whether the activity was stopped as planned.
Confirm events reach the SIEM
For each run, the blue team searches the SIEM for the events the detection depends on and compares them with the run identifier and timestamps. The check covers whether the raw events arrived, whether fields such as account name, source host and logon identifiers were parsed, and how long ingestion took. Missing or unparsed fields are logged as collection gaps rather than detection gaps, because they point to a different fix. The step is done when each run has a yes or no for ingestion and a list of any missing fields.
Measure alert fidelity
The team checks whether each detection rule, written in a format such as Sigma and deployed in Wazuh, Security Onion or the chosen SIEM, produced an alert for the matching run. For each alert, they record whether it fired, whether it named the right account and host, and whether it fired on benign activity from the baseline period. Results are classified as detected, partially detected, missed or noisy. The step is done when every run has a classification and every false positive has a documented cause.
Record gaps and tuning changes
Each gap is logged as a finding with the ATT&CK technique and sub-technique, the detection identifier, the data source involved, the owner and the proposed change. Tuning changes, such as adjusting an allowlist for a service account or adding a field mapping, are recorded with their author, date and the rule version they produce. The record also notes when a finding is a limitation that the team accepts and why. The step is done when every gap has an owner and a status, and no tuning change has been made without a matching entry.
Re-test after each change
After any change to rules, collectors, domain configuration or the ATT&CK mapping, the same emulation runs are repeated against the same scope so results can be compared with the earlier record. The blue team confirms the change did not break detections that already worked and that the previously missed runs now produce the expected alert or a documented reason why not. The step is done when the re-test record references the original run identifiers and shows before and after results for each affected category.

Preventive controls that reduce Kerberos ticket abuse

Kerberos ticket abuse succeeds most often where logging is thin and where directory secrets and protocol choices are left at their defaults. The cards below pair the two ATT&CK mitigations mapped to T1558, Audit (M1047) and Encrypt Sensitive Information (M1041), with related controls to review for your directory.

Audit policy on domain controllers

Audit policy decides whether Kerberos ticket requests reach your logs at all. On domain controllers, confirm that Kerberos service ticket and ticket-granting ticket events are captured for success and failure, and that the event volume is forwarded to your SIEM, such as Wazuh, before retention windows close. Without these events, the detections for forged tickets and anomalous ticket requests have nothing to read. Check the audit subcategories against your baseline, since a missing subcategory creates a silent gap.

Endpoint audit coverage for service accounts

Service accounts are a frequent target because their tickets are long-lived and their activity is rarely reviewed. Extend audit settings to the servers hosting service accounts and to any host where a privileged account authenticates. Confirm that logon session metadata and process access events are retained on those hosts so a ticket used from an unexpected machine can be traced. Test the collection with a known service account login in a lab before relying on it.

Kerberos encryption type policy

Weak encryption types for Kerberos tickets, such as RC4-based types, make offline cracking and forgery easier to attempt. Review the domain and host policies for which encryption types are permitted and whether legacy types can be disabled for accounts that do not need them. Inventory the applications that depend on older types before changing the policy, because a blanket change can break authentication. Record the decision and the exceptions in your change log.

Protecting sensitive directory data at rest

Encrypt Sensitive Information applies to the stores where account secrets and keytab files live. Identify where service account keytabs, exported ticket caches and directory backups are kept, and restrict them with encryption and tight file permissions. Confirm that backups of domain controllers are encrypted and that access to them is logged. A stolen keytab or backup gives an attacker the material needed to forge tickets, so treat these files as high-value assets.

Protecting Kerberos traffic in transit

Encryption in transit limits what an observer on the network can capture. Confirm that LDAP connections that carry directory queries use signing and channel protection where your environment supports them, and that legacy unencrypted paths are identified and retired. Network sensors such as Zeek or Suricata can then focus on what remains visible. Verify each change with a test authentication, because some older clients will fail when protections are raised.

Related controls to review

Active Directory Configuration (M1015) and User Account Management (M1018) are related controls to review alongside audit and encryption. Review domain functional level, delegation settings and privileged group membership under M1015, and review account lifecycle and service account ownership under M1018. Confirm with your directory administrators and your compliance lead which of these apply to your environment, and record the result as a documented decision.

Triaging a T1558 alert without tipping off the adversary

When a Kerberos detection fires, the first decision is whether the alert describes a real misuse of tickets or an approved workload that behaves unusually. Confirm the account name, the source host, the requesting address and the time window before anyone changes anything. Then check the activity against your change records and service inventory: a service account that requests tickets for a known scheduled job or backup agent is a different case from a user account requesting service tickets for hosts it has never touched. Keep the triage inside a small group of analysts and the identity team, and avoid announcing the alert in shared chat channels, because an adversary with a foothold may be watching the same tools.

Preserve evidence before you reset anything. Export the relevant domain controller security events and the endpoint telemetry for the source host while retention still covers the window, and record the hashes of exported files. Resetting a password or disabling an account often erases the context you need to scope the intrusion, so capture logon session metadata and ticket request details first. Scope the blast radius by listing every account and service principal that the suspected ticket activity touched, the hosts those tickets were used against, and any accounts with delegation rights on those hosts. Confirm each item with your own directory and logging configuration, since the fields available depend on how auditing is set up in your environment.

Plan credential resets in a deliberate order rather than all at once. Resetting the krbtgt account or a widely shared service account credential is a recovery decision with broad effects on authentication, so it must be scheduled with the identity team, the service owners and the incident lead, and rehearsed in advance. Reset compromised user and service credentials first in the scoped set, then move to shared trust material only if the scope requires it. Confirm the exact procedure, its sequencing and its effect on existing tickets with your directory vendor's documentation before you act, and note that the vendor documentation and your own change process govern the steps, not this page.

Rehearsing T1558 detection in a private cyber range

This is the core environment for T1558 because Kerberos is the authentication backbone of Active Directory. The range should include at least two domain controllers in a test forest, a set of domain-joined workstations and member servers, and a SIEM or log pipeline receiving Security event logs from every host. Exercise injects should be described at a high level as scenarios: a ticket-related activity against a service account, a ticket request pattern that departs from normal baselines, and a follow-on use of the ticket from an unexpected host. Your detection team should expect telemetry from authentication events on the domain controllers, process and file activity on the endpoints, and logon session metadata that ties a ticket use to an account and host.

Topology: Separate domain controllers, a workstation segment and a log collector, with time synchronization verified across all nodes before the exercise starts.
Injects: Scripted scenarios agreed in writing, with the expected account and host recorded in advance so that attribution can be scored.
Expected telemetry: Domain controller authentication records, endpoint process and file access records, and logon session metadata forwarded to the SIEM.
Detection quality: An alert within the window agreed for the exercise, naming the correct account and source host rather than a generic service name.
Response quality: Documented triage, a containment decision recorded with its rationale, and post-exercise tuning of rules that fired late or noisily.

Confirm with your Windows and identity team which audit policies are enabled in the range, because missing Kerberos audit settings will make every later score meaningless.

Questions SOC leads ask about T1558 detection

Which ATT&CK version should a T1558 detection target, and why does the mapping need to name it?

Name the exact ATT&CK version in every detection mapping, because releases can rename, deprecate or revoke techniques and their sub-techniques. The pages on this site use Enterprise ATT&CK version 20.0, and the mapping should say so in its header so a reviewer can tell whether it still matches the current matrix. Recent releases were v18 on October 28, 2025, v19 on April 28, 2026 and v20 on October 13, 2026. When you upgrade, re-check each T1558 sub-technique against the ATT&CK updates page and record which detections changed. Without a version tag, coverage reports become impossible to trust during an audit.

How do we handle the five T1558 sub-techniques without generating duplicate alerts?

Map each sub-technique to its own detection, but correlate related events into one incident before they reach analysts. Several sub-techniques can share the same underlying domain controller events, so a single ticket request can trigger more than one rule. Group alerts by account, source host and a short time window, and keep the sub-technique tag as an attribute rather than a separate case. Document the rule for each sub-technique so an analyst can see why it fired. Confirm your SIEM supports this grouping (for example, correlation or aggregation in Wazuh rules) before you commit to the design.

How do we tune Kerberos detections for service accounts and legacy applications?

Start by building an inventory of service accounts, their expected ticket request patterns and the hosts they run from, then suppress only what that inventory explains. Legacy applications often request tickets with older encryption types or from unusual hosts, so these will look anomalous without context. Tie every exclusion to a named owner, a reason and a review date, and prefer narrowing by account and source over broad allowlists. Track how many alerts each exclusion removes so you can spot one that hides real activity. Expect tuning to be iterative and plan for it in your timeline.

Which logs must be enabled on domain controllers before T1558 detection is possible?

Enable Kerberos authentication auditing on domain controllers, including ticket-granting service requests and ticket-granting ticket events, before expecting any detection to fire. Without these events, the User Account Authentication data component is largely blind, and no rule can match. Also confirm that logon session events are collected, because they supply the context needed to tie a ticket request to an account and host. Forward these events to your SIEM with reliable timestamps, and verify the audit policy with a test request in a lab before relying on it. Confirm the exact event IDs and audit subcategories against Microsoft's current documentation for your domain functional level.

How can we test T1558 detections safely in a production-like environment?

Test in a private cyber range or a staging domain that mirrors your domain controller configuration, audit policy and service account layout, rather than in production. Agree the test plan, accounts, time window and stop conditions in writing before anything runs, and keep a named contact on call during the exercise. Use controlled, pre-approved test activity that produces the expected events, then confirm that each rule fires, enriches correctly and routes to the right queue. Record results against the ATT&CK version tag so you can repeat the test after changes. Whether your team can run this internally depends on skills and staffing, which should be assessed before the engagement starts.

How do we measure T1558 detection coverage over time?

Measure coverage as the share of your T1558 sub-techniques that have a tested, deployed detection, a documented owner and a passing validation within an agreed review cycle. Track it per data source as well, because a rule is only as good as the logs feeding it. Review gaps after every ATT&CK release and after any change to domain controllers, audit policy or the SIEM. Keep a dated record of each validation so auditors and leadership can see trend rather than a single snapshot. Coverage percentages should come from your own inventory, not from vendor claims.

How are Sigma rules converted for Wazuh or another SIEM, and what should we confirm?

Sigma rules are written in a platform-neutral format and converted by a backend tool into the query language of your SIEM. Choose the conversion pipeline that matches your target, then review every converted rule because field names, event sources and time windows often need mapping to your log schema. For Wazuh, confirm which Sigma backend or conversion path your version supports and how it maps Windows event fields, since support can differ by release. For any other SIEM, ask the vendor or community maintainer which backend and pipeline they support and test each converted rule against sample events before deployment. Keep the original Sigma rule and its ATT&CK tag under version control so the converted output can be regenerated.

How DeployOpen builds T1558 detections and range exercises

DeployOpen works on T1558 Steal or forge Kerberos tickets as a self-hosted, defender-side engagement inside the client's own environment. The work moves from a written scope to detections tuned for the telemetry the client actually collects, then to range exercises that prove the detections fire and the response runs.

How we scope

Confirm which operating systems, domains and identity sources are in the written scope for T1558 review.
Inventory Kerberos-relevant telemetry such as File Access, Process Access and Logon Session Metadata before writing any rule.
Record the ATT&CK version the detections target, since releases can rename or deprecate techniques.
Agree in writing which of the five T1558 sub-techniques are covered and which are excluded.

How we build

Map each in-scope sub-technique to a detection strategy and its analytics, described in plain logic first.
Build open-source rules for the agreed stack, such as Wazuh, Sigma and Zeek where the collected data supports them.
Test rules against recorded benign Kerberos activity to measure noise before they reach production alerting.
Document data gaps where a sub-technique cannot be observed with the logging the client currently has enabled.

How we hand over

Deliver rule logic, data source requirements, tuning notes and a response runbook for each covered sub-technique.
Run cyber range exercises in a private range so the client's analysts rehearse detection and response on T1558.
Provide a written validation record showing which detections fired, which missed and what was changed.
Map mitigation coverage for Audit and Encrypt Sensitive Information to the client's existing control evidence.

How we support

Engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts.
Ask for a quote based on the written scope, including which logging changes the client must fund and carry out.
Ongoing support, rule upgrades for new ATT&CK versions and continuous testing are available as a retainer.
Confirm with DeployOpen during scoping which parts of the work recur and which are one-time deliverables.

T1558 Steal or forge Kerberos tickets