How T1550 alternate authentication material shows up in lateral movement
T1550 Use alternate authentication material covers adversaries reusing non-password credential material, such as tokens, hashes or tickets, to move through an environment without ever presenting a password. Under the Lateral Movement tactic (TA0008) in MITRE ATT&CK Enterprise version 20.0, the technique is described in terms of an adversary trying to move through your environment, and it is one of the reasons a SOC lead may see logons that look entirely legitimate. The typical situation is a successful authentication for an account that has a normal history on the network, but from a host that account has never used, at a time that does not match its working pattern, shortly after an endpoint in the same segment was compromised.
The difficulty is that the authentication itself often passes every control that was designed to catch bad passwords. Failed-logon counts stay low, multi-factor prompts may not appear for non-interactive or token-based sessions, and the source address may be an internal workstation or server that already talks to the target. Each sub-technique changes which artifact is reused and which platform records the evidence. Identity-provider, cloud infrastructure, Linux and container sub-techniques leave traces in different logs, so a detection built only for Windows logon events will miss much of the activity. Confirm with your own environment which of these identity and platform sources you collect today and whether they reach the SIEM with usable fields.
Before writing detections, decide who owns the baseline for each privileged and service account, which hosts those accounts are expected to authenticate from, and how exceptions are approved. Ask your identity and platform teams to confirm that authentication events for token, ticket and session-based logons are retained, and that the retention period meets your investigation needs. Mapping detections to ATT&CK version 20.0 gives you a fixed reference point, because technique and sub-technique definitions can change between releases. The MITRE ATT&CK updates page lists the release history you should check before you adopt any mapping.
Which telemetry reveals alternate authentication material use
This table maps the telemetry that exposes T1550 use of stolen or forged authentication material to each platform where it is collected, and names an open-source collector for each row. Read each row as a question to answer in your own environment: which logs exist, which agent ships them, and which fields carry the account and source details. Exact log field names must be confirmed against the deployed collector versions before any rule is written.
| Platform | Telemetry and data component | Open-source collector | What to confirm before writing a rule |
|---|---|---|---|
| Windows endpoints | Logon Session Creation (DC0067) for logons that reuse tickets or hashes, plus Process Creation (DC0032) for the processes that consume them | Wazuh agent reading the Windows Security event channel, optionally with Sysmon | Which logon types and authentication package names the agent forwards, and whether process command lines are captured |
| Linux hosts | Process Creation (DC0032) and Logon Session Creation (DC0067) from authentication and audit logs, covering reuse of tickets or keys on the host | Wazuh agent for Linux audit and authentication logs, with Zeek or Security Onion for network context | Whether auditd rules and PAM or SSH logs are enabled, and their field names in the deployed version |
| Containers | Process Creation (DC0032) inside the container and Application Log Content from the orchestrator API, showing reuse of service account tokens | Wazuh agent or Falco-style runtime monitoring where deployed, with Kubernetes audit logs shipped to the SIEM | Whether the cluster audit policy records token requests and which API server version produces the fields |
| IaaS control plane | Application Log Content (API and audit trail) showing sign-ins that use temporary credentials or tokens from unfamiliar sources | Log export from the cloud provider's audit service into Wazuh or Security Onion via a log forwarder | Retention period of the audit trail, and which credential type identifiers the provider records |
| Identity provider | Application Log Content for token issuance, token reuse and sign-in events, correlated with Logon Session Creation on endpoints | Identity provider log stream forwarded to Wazuh or a SIEM through the provider's supported connector | Whether token and session identifiers are logged, and how the provider names authentication methods |
| Network sensors | Network Traffic Content (DC0085) and Network Connection Creation (DC0082) showing authentication protocol exchanges between hosts | Zeek or Suricata in Security Onion, with protocol parsers for the authentication protocols in use | Which authentication protocols the parsers decode and whether traffic is encrypted end to end |
Detection logic for token and hash reuse across platforms
T1550 covers reuse of credentials that stand in for a password, such as tokens, session cookies and password hashes. The cards below describe detection ideas in words, each with tuning thresholds and the benign activity that will trigger it. Rules are written in Sigma and should be validated against ATT&CK v20.0, the version these pages target.
Non-interactive logons with unusual credential types
Alternate material is often presented in logon events that do not match how the account normally signs in. Flag logons where the credential type or logon type differs from the account's baseline, such as a network logon for an account that only ever signs in interactively. Start by alerting on first-seen combinations per account over a rolling window, then tune. Expect false positives from service accounts, scheduled jobs and backup agents, which legitimately authenticate over the network. Maintain an allowlist keyed to the account and the source host rather than to the account alone.
Identity provider tokens from new contexts
Token issuance or token use from a client application, device or network that the identity provider has not seen for that user is a strong signal of replayed tokens. Compare the client ID, user agent family, autonomous system and country against each user's recent history. A common threshold is to alert when two of these attributes change within a short session lifetime. Expect false positives from VPN exits, mobile carriers, single sign-on connectors and CI runners that request tokens for named users, so confirm each source against your known integrations before tuning.
Cloud API calls with tokens from unexpected sources
Container orchestrators and IaaS control planes log which token and source address made each API call. Look for a token issued to one workload being used from a different node, pod or public address, or for API verbs that the workload has never used. Alert on the mismatch between the token's bound identity and the observed caller. Expect false positives from autoscalers, sidecars that rotate tokens and developer workstations using kubeconfig files. Ask each platform team to document which identities should appear from which sources.
Linux authentication outside normal session patterns
On Linux hosts, compare authentication events for an account against its usual session pattern, including time of day, source host, number of concurrent sessions and whether a key or password was used. A sudden burst of new sessions or a key-based login from a host where that key has never been used deserves review. Set a baseline over a period you can justify, then alert on deviations. Expect false positives from configuration management tools, bastion hosts and cron jobs that open many short sessions, so tag those accounts and hosts in the rule logic.
Tuning and validating Sigma rules
Sigma is the rule format for expressing these ideas so they can be converted to the query language of your SIEM, such as Wazuh or Security Onion. Record the ATT&CK version each rule targets, the data components it depends on, and the log sources it requires. Validate every rule in a cyber range by replaying benign and simulated alternate-credential activity, then measure the alert volume and the false positive sources before enabling the rule for response.
How to validate that the T1550 detections fire
This sequence turns T1550 detection logic into tested, repeatable evidence by emulating each sub-technique in a private cyber range, checking the expected telemetry and alerts, and keeping a record that survives rule changes. It produces a validation file that security engineers and auditors can review.
Scope the sub-technique scenarios
The detection lead lists the four T1550 sub-techniques in scope and maps each to the platforms the organization runs, such as Containers, IaaS, Identity Provider and Linux. For each scenario, the team writes a plain-language description of the behavior being emulated, the assets involved and the accounts used, with no operational commands. Sign-off comes from the security owner for the lab and the system owners of any systems in the range. The step is complete when every in-scope sub-technique has an approved scenario card tied to an ATT&CK version, such as v20.0, so later reviews know which technique definitions were tested.
Define expected telemetry per platform
For each scenario, the detection engineer documents which data components should record the activity on each platform, such as Process Creation, Logon Session Creation and Application Log Content, and which log sources carry them (endpoint agents, identity provider audit logs, cloud control plane logs, container runtime or Kubernetes audit logs). The engineer also notes the expected field values that a correct rule should match, described in words. The team confirms with each platform owner which logs are actually enabled in the range and which are not. The step closes when a telemetry matrix shows, for each scenario, the expected source, the expected event and any known gap.
Set pass criteria for each detection
The team writes pass criteria before any emulation runs. A typical criterion states that the expected alert fires in the SIEM or Wazuh dashboard, is tied to the correct host, container, cloud account or identity, and appears within a time window the organization sets and agrees with its SOC. A second criterion covers false positives: the rule must not fire on the approved administrative baseline activity recorded in the range during a control period. Thresholds are set by the organization, not copied from this page. The step is complete when each detection has written pass and fail conditions signed by the detection owner and the SOC lead.
Run the emulation and record evidence
A purple team runs the approved scenarios in the private cyber range while a second person observes the log pipeline and the alert queue. For every run, the record captures start and end timestamps, the source and target assets, the alerts raised with their rule identifiers and versions, the analyst actions taken, and any screenshots or exported events. Negative control runs are recorded in the same way. The step closes when every scenario has a run record with a pass or fail result against the criteria from the previous step.
Confirm detections survive pipeline delay
The engineer deliberately slows or delays log forwarding in the range, for example by pausing a collector or throttling the path between the endpoint or identity source and the SIEM, then repeats one or more scenarios. The goal is to learn whether the rule still produces an alert once the events arrive late, whether correlation windows expire, and whether the alert carries the original event time or the ingest time. The team records the delay the pipeline tolerated before detection failed. The step is complete when the team has a documented tolerance, the known failure modes and a list of fixes, such as wider correlation windows or buffering, that the platform owners have accepted.
Tune rules and log each change
When a run fails or produces noise, the detection engineer changes the rule, the data source configuration or the threshold, and logs the change with a reason, the author, the date, the previous version and the test run that prompted it. Each change is reviewed by a second engineer. The team keeps the rule version in the same record as the run results, so an auditor can see which logic produced which alert. The step closes when every failed criterion has either a passing rerun or a documented accepted risk with an owner.
Retest after every rule or ATT&CK change
Any change to a rule, a log source, the SIEM version or the ATT&CK version the team targets triggers a targeted retest of the affected scenarios, plus a control run to check for new false positives. The team also reviews the MITRE ATT&CK release notes when a new version is published, since releases can rename, deprecate or revoke techniques and detection mappings. The output is an updated validation record that names the ATT&CK version tested and the rule versions in use. The step is complete when the retest results are filed against the change request and the validation record shows the current state of each T1550 detection.
Why identity and cloud telemetry matter more than endpoint alerts for T1550
Detection for T1550 Use Alternate Authentication Material depends more on context than on any single endpoint alert, because a replayed token, pass-the-hash logon or stolen cloud credential often produces an authentication event that looks legitimate on its own. The useful question is not whether a logon succeeded but whether it fits the account, the source host, the token issuer and the time window. Start by building a baseline for each privileged account: which hosts it normally authenticates from, which token types and issuers it uses, and during which hours. Deviations from that baseline are the signals worth triaging. Confirm with your identity team that sign-in logs from your identity provider retain the source address, device identifier, token issuer and authentication method fields, and that retention covers the lookback window your analysts need.
Correlation is where T1550 detections earn their value. Join identity provider sign-in records with IaaS control plane logs, such as cloud audit trails for role assumption, key creation and instance metadata access, and with container orchestration audit logs for service account token use from unexpected workloads. A credential accepted by the identity provider and then used against a cloud control plane from an address the account has never used is far more telling than either event alone. Map the join keys across these sources before writing rules, including session or correlation identifiers where your platforms provide them. Decide who owns each source and how quickly a suspicious join must reach an analyst. Write and track rules against a named ATT&CK version. ATT&CK v18, released October 28, 2025, replaced the detections in technique pages with detection strategies (DET IDs) and analytics, so a rule mapped to an older detection section may not map cleanly to the current structure. Record the detection strategy IDs of the version you target, note any changes in later releases such as v19 and v20, and review your mappings when MITRE publishes an update. The ATT&CK updates page is the place to check what changed.
Preventive controls that limit T1550 impact
T1550 works because stolen or forged authentication material is accepted as if it were a fresh logon, so prevention focuses on shrinking what each credential can reach and how long it stays valid. The cards below cover the two mitigations ATT&CK names for this technique, followed by adjacent controls that shape the same exposure. Confirm the effect of each control in your own environment before relying on it.
Privileged account management (M1026)
Scope privileged sessions to the tasks that need them. Administrative accounts should log on only to the systems and roles they manage, and tiered administration keeps domain or cloud control credentials away from ordinary workstations and servers. Review which privileged identities hold standing access to Linux hosts, containers and IaaS control planes, and record the owner and purpose of each one. Ask your identity team to show where privileged logons are restricted and how exceptions are approved.
Token lifetime review
Shorten the window in which a stolen token remains useful. Review access token, refresh token and session lifetimes in your identity provider and cloud platforms, and confirm which applications can extend a session without re-authentication. Long-lived service tokens and tokens issued to automation deserve the closest look because they are rarely rotated. Ask for a list of token types, their maximum lifetimes and the revocation method for each, and test that revocation actually ends access.
Audit coverage (M1047)
Log the events that show credential reuse. Audit policy should capture logon session creation, privileged group changes, token issuance and use, and authentication from unexpected hosts. Without these records, a replayed or forged credential looks like normal activity. Check that identity provider logs, domain controller security logs and cloud sign-in logs reach your SIEM or Wazuh manager, that retention covers your investigation window, and that someone reviews alerts from these sources.
Password policies (M1027)
Treat password rules as an adjacent control. Password policies reduce the chance that a password is cracked or reused, which can feed later credential theft, but they do not stop an attacker who already holds a hash or ticket. Confirm which password requirements apply to service and break-glass accounts, and whether they are enforced where those accounts authenticate. Verify the effect in your environment rather than assuming the policy covers the accounts that matter most.
User account management (M1018)
Remove unused and orphaned accounts. Dormant accounts, shared service identities and accounts left behind by former staff give an attacker credentials that nobody monitors. Review account creation, disablement and group membership processes, and compare them against the privileged inventory from the privileged account management work. Ask how service accounts are created, who approves them and how their credentials are rotated.
Triage and response when a T1550 alert fires
This sequence turns a T1550 alert into a documented decision: what credential was used, whether it belongs to a privileged identity, where it came from and went to, and what was contained. It ends with preserved evidence and detection updates so the next alert is easier to judge.
Confirm the credential type and issuing system
The on-call analyst first establishes which kind of alternate authentication material the alert describes, such as a password hash reuse, a Kerberos ticket, a web session or cookie, an access token, or a cloud access key, and which system issued it (a domain controller, an identity provider, a cloud token service, or a Linux host). Many T1550 alerts come from logs that show a logon without a matching password event, so the analyst checks the identity provider or directory log for the same account and time window. The step is complete when the analyst can name the credential type and the issuer in the case record, with the log source and event identifier cited.
Check whether the account is privileged
Next, the analyst checks the account's role against the directory, cloud IAM, or local group membership as of the event time, not only as of today. Accounts with administrative roles, service principals with broad scopes, and accounts that can reach domain controllers, identity provider admin consoles, or cloud management planes move the incident to a higher severity and bring in the identity owner. The step is complete when the case records the account's privilege level, its group or role memberships at the event time, and whether it is a human, service, or shared account.
Identify source and destination hosts
The analyst maps the origin and target of the authentication: the source address, workstation or workload name, and the destination systems that accepted the credential. Network connection records, endpoint logon sessions, and cloud sign-in logs usually provide this pairing. The analyst also notes whether the source is a managed asset, a jump host, a build runner, or an address outside expected ranges. The step is complete when the case lists each source and destination pair with timestamps and the logs that confirm them.
Review the preceding authentication history
The analyst pulls the account's authentication history for a window before the alert, typically covering the sessions, failed attempts, password or key changes, and privilege grants that came before the event. The goal is to see whether the credential was used from a new location, at unusual hours, or immediately after a prior compromise signal such as a malware alert or a credential dump. Analysts compare this history with the account's normal pattern documented in the baseline. The step is complete when the analyst records whether the sequence looks like expected use, a known administrative task with a change ticket, or unexplained activity.
Contain by revoking sessions and tokens
If the activity is not clearly authorized, the responder revokes active sessions, refresh tokens, Kerberos tickets where the directory supports it, and cloud sessions tied to the account, then disables the account or the affected service principal if business needs allow. Scope is confirmed by checking every system that accepted the same material, not only the first one that alerted. Responders confirm that revocation took effect by re-testing access from the source host and checking that new sign-ins are blocked. The step is complete when the sign-in log shows no successful use of the revoked material after the containment time.
Rotate affected secrets and preserve evidence
Once containment is in place, the team rotates the passwords, keys, certificates, or secrets that the account could have exposed, in the order that the directory and identity owners agree on so that dependent services are not broken without a plan. Before rotation or reimaging changes the state, responders export identity provider sign-in and audit logs, directory event logs, cloud control plane and API logs, and endpoint logs or memory captures from the source and destination hosts, with hashes recorded and chain of custody noted. The step is complete when the evidence set is listed in the case record, stored in write-protected storage, and the rotation is logged with the owner who approved it.
Update detections after the incident closes
After the incident is closed, the detection engineer reviews what the alert caught, what it missed, and which logs were needed but absent. Findings feed back into the Sigma or Wazuh rules, correlation thresholds, and data source coverage for the affected platform, and any mapping is recorded against the ATT&CK version the team targets so future changes in technique definitions are visible. The privileged account inventory and the mitigation owners named under Privileged Account Management and Audit are updated when the review shows gaps. The step is complete when the change is tested in the cyber range or staging rule set and the case record links to the updated rule and version.
Rehearsing T1550 detection in a private cyber range
This environment models a mixed Windows and Linux enterprise segment with a domain controller, a few workstations, a file server and a Linux administration host, all in an isolated range network. The blue team monitors through an open-source stack such as Wazuh agents on endpoints and Zeek or Suricata sensors on the segment. Injects are scripted, defensive scenarios: an authentication event on a host that does not match the account's normal logon pattern, followed by a request for the blue team to confirm whether the session was expected. Good detection means an alert fires within the time agreed in the exercise plan, the alert carries the host, account, logon type and source context, and the analyst's triage notes separate observed facts from hypotheses.
- Topology: Map each host to its role, owner and expected logon paths so analysts can judge whether an event is out of pattern.
- Injects: Schedule off-hours and out-of-pattern logons, and a credential reuse pattern observed across two hosts, without publishing the exact method.
- Detection: Confirm the Process Creation and Logon Session Creation events reach the manager with the fields the rules depend on.
- Response: Test containment steps such as disabling the account, ending sessions and isolating a host, with approvals recorded.
- Triage notes: Require timestamps, affected assets and an explicit confidence statement in every ticket.
Before each run, confirm with your own platform team which log fields your agents collect and how long they are retained.
This environment models an identity provider that federates sign-in to several business applications, with token issuance, session management and an administrative console. The range should include realistic-looking but synthetic user populations, service accounts and an application log pipeline forwarded to the same open-source monitoring stack. Injects focus on defensive signals: a session that appears to be reused from an unexpected network location, a token accepted by an application after the related session was revoked, and a service account authenticating outside its documented schedule. Good detection means the analyst can tie the identity provider session to the application log entries, the alert names the affected identity and application, and the triage notes state whether the session was revoked or still active.
- Topology: Document the identity provider, the federated applications, the log forwarding path and the owner of each service account.
- Injects: Present token reuse, revoked-session activity and off-schedule service account use as log records, not as technique steps.
- Detection: Verify that application log content includes the identifiers needed to correlate sessions across systems.
- Response: Rehearse session revocation, credential rotation for affected service accounts and communication to application owners.
- Validation: Check that alerts reach the analyst queue within the agreed window and that a re-run of the same inject produces a consistent result.
Confirm with your identity provider vendor which session and token events are exposed to your logging pipeline and at what level of detail.
This environment models a container platform and an infrastructure-as-a-service account with workloads, a cluster control plane, a cloud audit trail and a secrets store. The blue team receives injects as audit records and platform events, such as a workload using an identity that is not bound to its deployment, a cloud control plane call made with a credential whose issuance is not recorded in the change process, and an administrative action outside a change window. Telemetry comes from the cloud audit log, the cluster audit log and host-level agents on nodes. Good detection means the alert identifies the workload or principal, the cloud account and the cluster, and the analyst can trace the credential back to its issuance or to the absence of one.
- Topology: Record which workloads hold which identities and which cloud accounts sit in which trust relationships.
- Injects: Use audit records showing a principal acting outside its expected deployment or change window.
- Detection: Confirm the cluster and cloud audit logs are complete, time-synchronized and forwarded without gaps.
- Response: Rehearse revoking the affected credential, rotating secrets in the store and checking the change record for the affected workload.
- Triage notes: Require the analyst to name the cloud account, cluster, namespace and principal, and to record what evidence was preserved.
Before running this tier, confirm with your cloud and platform providers which audit events are available on your plan and how long they are retained.
Questions SOC leads ask about T1550 detection
How do I tell a legitimate service token from misuse?
Start by building a baseline of which accounts, hosts and source addresses normally use each token type, then alert on deviations from that baseline. Legitimate service tokens usually come from known automation hosts, follow predictable schedules and reuse the same client identifiers. Misuse often shows up as a token presented from an unfamiliar host, a new geography, an unusual client or user agent, or a burst of access to resources the workload never touched. Identity provider sign-in logs and cloud audit logs are the primary sources, so confirm which fields each platform records and how long it retains them. Ask each service owner to confirm the expected pattern, which turns detection into a review of known workloads. Expect the baseline to need tuning after every deployment change.
How do I handle false positives from automation accounts?
Inventory every automation account, its owner and its expected source ranges, then suppress only the specific combination of account, host and action that is documented as normal. Broad exclusions for an entire service account hide the activity that matters most. Each suppression should carry an owner and a review date so exceptions do not quietly accumulate. Review suppressions on a fixed schedule and after any change to the automation, such as a new pipeline, a migrated host or a rotated credential. Track how often each rule fires and how often analysts close alerts as benign, because a rule that is almost always closed as benign needs either tuning or a clearer description of what it should catch.
Which ATT&CK version should my detections map against?
Map detections to the ATT&CK version named in your detection documentation, and re-check that mapping whenever MITRE publishes a new release. Recent releases include v18 on October 28, 2025, v19 on April 28, 2026 and v20 on October 13, 2026. Releases can rename, deprecate or revoke techniques and sub-techniques, so a mapping that was correct for one version may need changes for the next. Record the version number next to every rule, and confirm it against the version your auditor or internal assurance team expects. Since v18, MITRE has organized detection guidance around detection strategies and analytics, so review those entries when you update your rule library. The ATT&CK updates page lists each release and its changes.
How do I test T1550 detections without affecting production?
Run the exercises in a private cyber range that mirrors your identity provider, cloud tenant, Linux hosts and container platform, using synthetic accounts and test workloads. Never use live service accounts, production tokens or real customer data in a test. Write a test plan that describes each behavior to be generated, the expected telemetry, the owner of each system involved, and the conditions that stop the exercise. Coordinate the schedule with change management so that the security operations team and platform owners know when activity is expected. After each run, confirm that the expected events were collected, that the rules fired, and that analysts could triage the alert with the information available. DeployOpen builds private cyber ranges and runs exercises in them as part of its security testing and training work, with scope agreed in writing before work starts.
How do I measure detection coverage for the four sub-techniques?
Build a coverage matrix with one row for each T1550 sub-technique in the ATT&CK version you target, and one column for each required element: data source, detection rule, validated test result, alert triage status and known gaps. Confirm which telemetry each platform records for each row, paying attention to data components such as Logon Session Creation and Process Creation, which ATT&CK references in its detection guidance. Count a row as covered only when a test in the cyber range produced the expected event and the rule fired, not when a rule merely exists in the library. Record the date of the last successful test for each row, and re-test after changes to logging, identity configuration or the rule itself. Gaps should be listed with an owner and a planned action, so the matrix shows where your visibility is weakest.
Can my team run this program alone, or do we need a partner?
Teams with mature identity logging and detection engineering can run much of this program in-house, and the main effort is ongoing tuning rather than initial setup. A partner is most useful for planning and implementing the logging pipeline, building the cyber range, and running structured exercises that your team has not yet rehearsed. DeployOpen plans, implements and tests these controls inside the client's own infrastructure, with scope, deliverables and timelines agreed in writing before work starts. Ongoing support, upgrades and continuous testing are available as retainers. DeployOpen does not publish a price list, and a quote follows from the written scope. Ask any provider to name the deliverables, the telemetry it will validate and the handover format, and confirm which parts remain your responsibility after the engagement ends.
Official ATT&CK sources for T1550 detection work
Start every T1550 detection project from the source of truth: the MITRE ATT&CK tactic page for Lateral Movement. That page defines the tactic (TA0008) in MITRE's own words, and it lists the techniques and sub-techniques that sit under it. Use it to confirm that T1550 Use alternate authentication material is still filed under Lateral Movement in the version you target, and to check the current sub-technique names before you write them into a detection backlog, a Wazuh rule set or a Sigma rule header. Record the ATT&CK version alongside every mapping, because a tactic page can change between releases.
Before you adopt or refresh any mapping, read the release notes for the versions that changed the matrix. The ATT&CK updates page lists every release, and the October 2025 notes for v18 are the place to confirm the shift from detection text in technique pages to detection strategies and analytics, along with changes to data components. Read the April 2026 notes for v19 the same way. Ask your detection engineering team to note, for each T1550 analytic, which release it was last checked against, and to flag any renamed, deprecated or revoked sub-technique in the release notes before the next review cycle.
For machine-readable checks, use the enterprise-attack 20.0 bundle in the attack-stix-data repository. The repository publishes ATT&CK content in STIX 2.1 format, one bundle per domain and version, so a script can list the T1550 sub-techniques, the data components their detection strategies reference and the mitigations mapped to them. Pin the bundle version in your pipeline, diff it against the previous release, and treat any change to the T1550 sub-technique list as a trigger to revisit the detections and cyber range scenarios that depend on it.
