Last reviewed:
T1550 covers using tokens, hashes, tickets or certificates in place of a password. In CertiGhost, PKINIT converts a CA-issued DC certificate into a Kerberos TGT, making certificate use the bridge between issuance and replication. DCV does not represent that on-premise exchange as a single cloud finding. Detection needs the certificate issuer, serial or thumbprint from Event 4768 joined to the requesting host and target account, then linked to later privileged actions in hybrid identity or cloud administration.
Adversaries may use alternate authentication material, such as password hashes, Kerberos tickets, and application access tokens, in order to move laterally within an environment and bypass normal system access controls.
Authentication processes generally require a valid identity (e.g., username) along with one or more authentication factors (e.g., password, pin, physical smart card, token generator, etc.). Alternate authentication material is legitimately generated by systems after a user or application successfully authenticates by providing a valid identity and the required authentication factor(s). Alternate authentication material may also be generated during the identity creation process.
Caching alternate authentication material allows the system to verify an identity has successfully authenticated without asking the user to reenter authentication factor(s). Because the alternate authentication must be maintained by the system, either in memory or on disk, it may be at risk of being stolen through Credential Access techniques. By stealing alternate authentication material, adversaries are able to bypass system access controls and authenticate to systems without knowing the plaintext password or any additional authentication factors.
Platforms: Containers, IaaS, Identity Provider, Linux, Office Suite, SaaS, Windows.
DCV does not currently ship a cloud-audit-log finding mapped directly to T1550. The technique earns a library page because a13e research cites it. Detection sits downstream, on the exploitation step the technique enables.
CloudSigma does not currently ship a stand-alone rule that fires on T1550 in isolation. Generate a starting-point rule from the CVE, vulnerability disclosure, or threat-research blog post that exercises this technique, then pair it with SIEM-side correlation before enabling in production.
High-fidelity detection of T1550 requires correlation
across multiple events. For example, a credential-validation call
followed by a reconnaissance chain (List* /
Describe*) within a short window from an unfamiliar
source. A single-event Sigma rule on
GetCallerIdentity alone fires constantly on
legitimate CLI, SDK and CI/CD activity.
Where you have a specific advisory, vulnerability disclosure or blog post that exercises T1550-style abuse, CloudSigma can generate a starting-point rule from that input. You then deploy it in your SIEM and combine it with the SIEM's native correlation features (timeframe joins across users, source-IP anomalies, impossible-travel checks). For T1550 specifically the generated rule is rarely sufficient on its own; pair it with the SIEM-side correlation logic before enabling in production.
T1550 covers using tokens, hashes, tickets or certificates in place of a password. In CertiGhost, PKINIT converts a CA-issued DC certificate into a Kerberos TGT, making certificate use the bridge between issuance and replication. DCV does not represent that on-premise exchange as a single cloud finding. Detection needs the certificate issuer, serial or thumbprint from Event 4768 joined to the requesting host and target account, then linked to later privileged actions in hybrid identity or cloud administration.
T1550 has no cloud-audit-log signal of its own; DCV does not currently ship a finding mapped directly to it. The technique earns a library page because a13e research cites it. Detection sits downstream, on the exploitation step the technique enables (see Related techniques).
T1550 is part of MITRE ATT&CK TA0008 Lateral Movement: How adversaries move from one system to the next.
T1550 requires multi-event correlation that exceeds a single Sigma rule's structure. CloudSigma can generate a starting-point rule from a CVE, vulnerability disclosure, or threat-research blog post that exercises T1550-style abuse; pair it with SIEM-side correlation logic before enabling in production.