Attack Ent T1550 001 Application Access Token

MITRE ATT&CK T1550.001: Application Access Token

When to use this skill

Use this skill when the task involves T1550.001, Application Access Token, enterprise ATT&CK, TTP mapping, detection engineering, hunting, incident-response enrichment, control validation, or authorized adversary-emulation planning. Treat it as a defensive analysis aid: keep outputs focused on understanding, detecting, mitigating, and safely validating this ATT&CK sub-technique.

Technique context

• ATT&CK domain: enterprise
• ATT&CK ID: T1550.001
• Technique name: Application Access Token
• Type: sub-technique
• ATT&CK URL: https://attack.mitre.org/techniques/T1550/001
• Tactics: lateral-movement
• Platforms: Containers, IaaS, Identity Provider, Office Suite, SaaS
• Required permissions: Not specified
• Effective permissions: Not specified
• Defenses bypassed: Not specified

ATT&CK description

Adversaries may use stolen application access tokens to bypass the typical authentication process and access restricted accounts, information, or services on remote systems. These tokens are typically stolen from users or services and used in lieu of login credentials.

Application access tokens are used to make authorized API requests on behalf of a user or service and are commonly used to access resources in cloud, container-based applications, and software-as-a-service (SaaS).(Citation: Auth0 - Why You Should Always Use Access Tokens to Secure APIs Sept 2019)

OAuth is one commonly implemented framework that issues tokens to users for access to systems. These frameworks are used collaboratively to verify the user and determine what actions the user is allowed to perform. Once identity is established, the token allows actions to be authorized, without passing the actual credentials of the user. Therefore, compromise of the token can grant the adversary access to resources of other sites through a malicious application.(Citation: okta)

For example, with a cloud-based email service, once an OAuth access token is granted to a malicious application, it can potentially gain long-term access to features of the user account if a "refresh" token enabling background access is awarded.(Citation: Microsoft Identity Platform Access 2019) With an OAuth access token an adversary can use the user-granted REST API to perform functions such as email searching and contact enumeration.(Citation: Staaldraad Phishing with OAuth 2017)

Compromised access tokens may be used as an initial step in compromising other services. For example, if a token grants access to a victim’s primary email, the adversary may be able to extend access to all other services which the target subscribes by triggering forgotten password routines. In AWS and GCP environments, adversaries can trigger a request for a short-lived access token with the privileges of another user account.(Citation: Google Cloud Service Account Credentials)(Citation: AWS Temporary Security Credentials) The adversary can then use this token to request data or perform actions the original account could not. If permissions for this feature are misconfigured – for example, by allowing all users to request a token for a particular account - an adversary may be able to gain initial access to a Cloud Account or escalate their privileges.(Citation: Rhino Security Labs Enumerating AWS Roles)

Direct API access through a token negates the effectiveness of a second authentication factor and may be immune to intuitive countermeasures like changing passwords. For example, in AWS environments, an adversary who compromises a user’s AWS API credentials may be able to use the sts:GetFederationToken API call to create a federated user session, which will have the same permissions as the original user but may persist even if the original user credentials are deactivated.(Citation: Crowdstrike AWS User Federation Persistence) Additionally, access abuse over an API channel can be difficult to detect even from the service provider end, as the access can still align well with a legitimate workflow.

Agent workflow

1. Clarify scope: identify the system, asset class, log sources, cloud or endpoint platform, and whether the user wants triage, detection, coverage assessment, or safe emulation planning.
2. Load bundled resources as needed: use references/technique-profile.json for structured metadata, references/detection-and-mitigation.md for triage and telemetry guidance, references/known-threat-context.md for ATT&CK relationship context, and templates/ for repeatable outputs.
3. Map observations to ATT&CK: compare the user's evidence to the ATT&CK description, tactics, platforms, and known procedure patterns before asserting a match.
4. Produce defensive outputs: prioritize hypotheses, telemetry requirements, detection logic ideas, validation steps, containment guidance, and mitigations.
5. Preserve uncertainty: distinguish confirmed evidence, plausible indicators, assumptions, and gaps. Recommend what to collect next.
6. Stay safe: do not provide malware, credential theft, persistence, evasion, destructive automation, or unauthorized exploitation instructions. For adversary emulation, keep steps bounded to approved lab or control-validation contexts and omit operational abuse details.

Bundled resources

• references/technique-profile.json: machine-readable ATT&CK metadata for this technique.
• references/detection-and-mitigation.md: detection notes, telemetry checklist, triage questions, mitigation candidates, and false-positive considerations.
• references/known-threat-context.md: ATT&CK relationship context with attribution cautions.
• templates/detection-brief.md: detection engineering brief template.
• templates/hunt-plan.md: threat hunt plan template.
• templates/incident-response-note.md: incident response note template.
• templates/coverage-assessment.md: ATT&CK coverage assessment template.
• scripts/render_brief.py: local helper that renders a Markdown defensive brief from technique-profile.json.
• assets/output-schema.json: JSON schema for structured technique analysis outputs.

To generate a quick brief, run python scripts/render_brief.py --output brief.md from inside this skill directory, or adapt the templates directly.

Detection guidance

No ATT&CK detection guidance was present in the source STIX object.

Useful telemetry and data sources

• Not specified in the STIX object.

Mitigations to consider

• Account Use Policies
• Application Developer Guidance
• Audit
• Encrypt Sensitive Information
• Restrict Web-Based Content

Known threat context

Use these examples only as contextual leads, not as proof that an observed event is this technique:

• APT28 (intrusion-set)
• CreepyDrive (malware)
• HAFNIUM (intrusion-set)
• Peirates (tool)
• Shai-Hulud (malware)
• SolarWinds Compromise (campaign)

Recommended output pattern

When responding with this skill, structure the answer as:

• Assessment: whether the evidence supports this ATT&CK mapping and why.
• Evidence: specific indicators, logs, behaviors, and assumptions.
• Detection: telemetry sources, analytic logic, and tuning considerations.
• Response: containment, eradication, recovery, and validation actions.
• Coverage gaps: missing logs, sensors, controls, or environmental details.
• References: include the ATT&CK URL and any user-provided evidence references.

ATT&CK contributors

• Blake Strom, Microsoft Threat Intelligence
• Dylan Silva, AWS Security
• Ian Davila, Tidal Cyber
• Jack Burns, HubSpot
• Jeff Sakowicz, Microsoft Identity Developer Platform Services (IDPM Services)
• Mark Wee
• Pawel Partyka, Microsoft Threat Intelligence
• Saisha Agrawal, Microsoft Threat Intelligent Center (MSTIC)
• Shailesh Tiwary (Indian Army)