---
type: "mapping-set"
title: "ATT&CK techniques → #4 Identity Theft"
description: "33 ATT&CK techniques entries mapped to TLCTC #4 Identity Theft."
resource: "tlctc:mapping:attack:cluster-4"
tags:
  - "mapping"
  - "attack"
  - "cluster-4"
---
# ATT&CK techniques → #4 Identity Theft

> Source: MITRE ATT&CK Enterprise → TLCTC mapping (`mappings/mitre-attack-enterprise/`).

Mapped entries: **33**. Cluster: [#4 Identity Theft](/clusters/cluster-4.md).

| Technique | Name | TLCTC | Rationale |
|---|---|---|---|
| T1021 | Remote Services | #4 → #1 | Remote-service lateral movement is two distinct steps per Axiom VI / R-CRED / Axiom X: (a) authenticate to the service by presenting a valid identity artifact — `#4` (credential application is always `#4`, regardless of how the credential was acquired); (b) use the now-authenticated session to invoke the service's designed remote-access functions for command execution, file transfer, or further pivoting — `#1`. Path: `#4 → #1`. The acquisition of the credential is a separate prior step in its own enabling cluster. |
| T1021.001 | Remote Desktop Protocol | #4 → #1 | RDP for lateral movement: authenticate with valid credentials (`#4` per R-CRED) and operate the desktop/command session through RDP's designed functionality (`#1`). Path: `#4 → #1`. (When an authenticated-RDP exploit is used post-auth, append `→ #2` instead of/before `#1`.) |
| T1021.002 | SMB/Windows Admin Shares | #4 → #1 | SMB / Windows admin shares for lateral movement: authenticate with valid credentials (`#4` per R-CRED), then read/write files and execute via admin-share semantics — `#1`. Path: `#4 → #1`. |
| T1021.003 | Remote Services: Distributed Component Object Model | #4 → #1 | DCOM remote object invocation for lateral movement: authenticate (`#4`), then invoke remote COM methods through their designed RPC interfaces (`#1`). Path: `#4 → #1`. |
| T1021.004 | SSH | #4 → #1 | SSH for lateral movement: authenticate with password or private key (`#4` per R-CRED), then operate the remote shell through its designed functionality (`#1`). Path: `#4 → #1`. |
| T1021.005 | Remote Services: VNC | #4 → #1 | VNC for lateral movement: authenticate (`#4`), then control the remote desktop session via VNC's designed remote-control functions (`#1`). Path: `#4 → #1`. |
| T1021.006 | Remote Services: Windows Remote Management | #4 → #1 | WinRM for lateral movement: authenticate (`#4`), then invoke remote PowerShell/WMI through WinRM's designed management interface (`#1`). Path: `#4 → #1`. |
| T1021.007 | Remote Services: Cloud Services | #4 → #1 | Cloud-service lateral movement: authenticate to the cloud control plane (`#4`), then invoke its designed APIs to access or manipulate other tenants/resources (`#1`). Path: `#4 → #1`. When auth flows through an external IdP, mark transit: `#4 \|\|[auth][@Org⇒@IdP→@Org]\|\| → #1`. |
| T1021.008 | Remote Services: Direct Cloud VM Connections | #4 → #1 | Direct cloud-VM connections (cloud-native serial console, instance-connect APIs, EC2 Instance Connect, Azure Bastion programmatic access): authenticate (`#4`), then operate the VM session through the provider's designed connection function (`#1`). Path: `#4 → #1`. |
| T1078 | Valid Accounts | #4 | Initial access using a valid account (default, local, domain, or cloud) is **credential application** — presenting an identity artifact to authenticate. Per **R-CRED** and **Axiom X**, application is always #4 regardless of how the credential was acquired (the acquisition step belongs to its own enabling cluster: phishing → #9, dump → #1, brute force → #4 itself, etc.). Path: `#4 \|\|[auth][@External→@Org]\|\|`. |
| T1078.001 | Valid Accounts: Default Accounts | #4 | Authenticating with a default credential left in place by the vendor or operator. Identity artifact is presented to the auth surface — #4 per R-CRED. Path: `#4 \|\|[auth][@External→@Org]\|\|`. |
| T1078.002 | Valid Accounts: Domain Accounts | #4 | Authenticating with a domain account (Active Directory, equivalent directory). Credential application — #4 per R-CRED. Path: `#4 \|\|[auth][@External→@Org]\|\|`. Acquisition of the domain credential is a separate step in its own cluster. |
| T1078.003 | Valid Accounts: Local Accounts | #4 | Authenticating with a local account on a host. #4 per R-CRED. Path: `#4 \|\|[auth][@External→@Org]\|\|`. |
| T1078.004 | Valid Accounts: Cloud Accounts | #4 | Authenticating with a cloud account (IAM user, federated identity, service principal). When access goes through an external identity provider, mark it as transit: `#4 \|\|[auth][@External⇒@IdP→@Org]\|\|`. Otherwise: `#4 \|\|[auth][@External→@Org]\|\|`. #4 per R-CRED. |
| T1110 | Brute Force | #4 | Brute force is repeated **credential application** against an auth surface — many candidates presented per unit time. Per **R-CRED / Axiom X**, credential application is always `#4`, independent of how the candidate set is generated. Path: `#4 \|\|[auth][@External→@Org]\|\|` (online); for offline cracking the computation step is on attacker infrastructure and does not cross @Org boundary, with the cracked credential subsequently applied as a `#4` step. |
| T1110.001 | Password Guessing | #4 | Password Guessing: small candidate set tried per account. Repeated `#4` per R-CRED / Axiom X. |
| T1110.002 | Password Cracking | #4 | Password Cracking: offline computation against a captured hash. The hash itself was acquired in a prior step (typically `#1`/`#7` per R-CRED for dumping) and the cracking is offline transformation on attacker infrastructure (no @Org boundary crossed). The cracked plaintext is then applied — `#4`. Path step recorded here is the eventual `#4` application. |
| T1110.003 | Password Spraying | #4 | Password Spraying: small password set tried across many accounts to evade lockout. Repeated `#4` per R-CRED / Axiom X. |
| T1110.004 | Brute Force: Credential Stuffing | #4 | Credential Stuffing: large credential pairs (from external breach dumps) tried against @Org auth surface. Repeated `#4` per R-CRED / Axiom X. The dump-acquisition was on someone else's infrastructure (`@OtherVictims` — outside @Org's threat scope at acquisition); only the application against @Org is the in-scope step. |
| T1114 | Email Collection | #4 → #1 | Collect email content. Authenticate to the mail system using a valid identity artifact (`#4` per R-CRED) and use designed mail-reading interfaces (MAPI, IMAP, EWS, Graph) — `#1`. Outcome `[DRE: C]`. Path: `#4 → #1 + [DRE: C]`. |
| T1114.001 | Email Collection: Local Email Collection | #4 → #1 | Local Email Collection: read mailbox files / cached mail on the local host (`.pst`, `.ost`, Maildir, `Mail.app` mailboxes). May not require interactive auth if file access is direct, but logical access to the mailbox material is presented as identity-bound use — `#4 → #1`. Outcome `[DRE: C]`. |
| T1114.002 | Remote Email Collection | #4 → #1 | Remote Email Collection: authenticate to mail server (`#4`) and pull mailboxes via IMAP/POP/EWS/Graph (`#1`). Outcome `[DRE: C]`. |
| T1114.003 | Email Collection: Email Forwarding Rule | #4 → #1 | Email Forwarding Rule: authenticate to mail account (`#4`) and configure a forwarding/auto-redirect rule via designed mail-rules UI/API (`#1`) so that subsequent inbound mail is silently copied to attacker. Outcome `[DRE: C]` (continuous data exposure for the lifetime of the rule). |
| T1133 | External Remote Services | #4 | External remote services (VPN, Citrix, RDP gateway, SSH bastion, cloud admin portals) are accessed by **presenting valid credentials** at their auth surface. Per MITRE description: "Access to Valid Accounts to use the service is often a requirement." This is credential application — #4 per R-CRED. Cluster corrected from prior `#2`: exploiting an implementation flaw in the remote service is a different technique (T1190 Exploit Public-Facing Application — #2). T1133 is the auth-via-creds path. Path: `#4 \|\|[auth][@External→@Org]\|\|`. |
| T1530 | Data from Cloud Storage | #4 → #1 | Read data from cloud storage (S3, Azure Blob, GCS, Box, Dropbox, OneDrive). Authenticate via valid identity artifact (`#4` per R-CRED) and invoke designed object-listing/download APIs (`#1`). Outcome `[DRE: C]`. Path: `#4 → #1 + [DRE: C]`. |
| T1550 | Use Alternate Authentication Material | #4 | Using alternate authentication material (tokens, hashes, tickets, cookies) to authenticate without re-entering a password is **credential application** — presenting an identity artifact to an auth surface. Per **R-CRED** and **Axiom X**, application is always `#4`, regardless of the artifact type. Cluster corrected from prior `#1` (with a copy-pasted "defense evasion uses legitimate capabilities" rationale that did not apply): the artifacts here are credentials, and using them to impersonate an identity is by definition `#4`, not generic function abuse. Path: `#4`. The acquisition of the artifact (dump, intercept, theft) is a separate prior step in its own cluster. |
| T1550.001 | Use Alternate Authentication Material: Application Access Token | #4 | Application access tokens (OAuth bearer tokens, SaaS API tokens, cloud session tokens) are identity artifacts that authenticate API calls. Presenting a stolen token to authenticate is `#4` per R-CRED / Axiom X. Cluster corrected from prior `#1`. Path: `#4`. |
| T1550.002 | Pass the Hash | #4 | Pass-the-Hash: stolen NTLM hash presented as authentication material to a Windows auth surface. Identity artifact application — `#4` per R-CRED. Path: `#4`. |
| T1550.003 | Pass the Ticket | #4 | Pass-the-Ticket: stolen Kerberos ticket (TGT or service ticket) presented to authenticate. Identity artifact application — `#4` per R-CRED. Path: `#4`. |
| T1550.004 | Use Alternate Authentication Material: Web Session Cookie | #4 | Web session cookies are identity artifacts that prove an authenticated session. Presenting a stolen cookie to an application to impersonate the session owner is `#4` per R-CRED / Axiom X. Cluster corrected from prior `#1` (the "defense evasion" framing missed Axiom X — a cookie that authenticates a session is a credential). Path: `#4`. |
| T1558.002 | Silver Ticket | #4 | Silver Ticket: forged service ticket using a previously-acquired service-account hash. Forging is offline; presenting the ticket to the service is `#4` per R-CRED. (Cluster `#4`-only because the technique boundary excludes the upstream hash acquisition, which is recorded as a separate technique.) |
| T1570 | Lateral Tool Transfer | #4 → #1 | Transferring attacker tools between @Org hosts: authenticate to the target host (`#4` per R-CRED, using whatever auth artifact is in hand), then invoke designed file-transfer functions (SMB copy, scp, rsync, BITS, cloud storage upload) to move the tool — `#1`. Path: `#4 → #1`. The subsequent execution of the transferred tool on the new host is a separate step in its own cluster (typically `#7` per R-EXEC). |
| T1606.002 | SAML Tokens | #4 | Forge SAML tokens (Golden SAML): forging assumes the token-signing certificate is already in attacker hands (acquired via separate technique). Forging is offline; presenting the forged SAML assertion to the service provider is `#4` per R-CRED. |