An analyst sees an attacker replaying a stolen SaaS OAuth token to list storage buckets via API, with no OS process or password logon. Which ATT&CK technique category should guide the mapping?
Select an answer to reveal the explanation.
Short Explanation
Think of it like this: if the attacker is waving a stolen cloud badge, you map it to cloud account valid accounts, not a local password dump. The trap is treating API token abuse like a Windows hash issue just because the word credential appears.
Full Explanation
Cloud identity token abuse is modeled through ATT&CK techniques that address valid accounts used in cloud control planes, especially cloud account valid accounts, because the artifact is an authentication token or identity assertion rather than a compromised local OS credential. In response mapping, the analyst records the tactic and technique that explain API-based access to cloud resources, then traces the token source, scope, expiration, and conditional-access gaps. A host credential-access category is wrong because SAM, LSASS, or local password hashes describe Windows or local OS secrets and would require host telemetry, not SaaS API calls. A network lateral-movement category is wrong because pass-the-hash or remote service abuse moves across hosts using network authentication protocols, whereas the observed behavior is a bearer token accepted by a cloud service. A mobile session-hijacking category is wrong because webview or app-session abuse targets mobile application runtime controls and device-side session storage, not cloud identity APIs. Exam caveat: ATT&CK techniques can overlap, so choose the one that matches the primary evidence source and control plane. Operational check: correlate the token identifier, issuing tenant, granted scopes, and API calls, then revoke or rotate the token and review conditional-access policies.