1200kmSECURITY RESEARCH
Loading interactive filters…

1200KM / simulation

T1528 Steal Application Access Token — Attack Simulation

Adversaries can steal application access tokens as a means of acquiring credentials to access remote systems and resources. Application access tokens are used to make authorized API requests on behalf of a user or service and are commonly used as a way to access resources in cloud and container-based applications and software-as-a-service (SaaS). Adversaries who steal account API tokens in cloud and containerized environments may be able to…

Complete technique description

Adversaries can steal application access tokens as a means of acquiring credentials to access remote systems and resources.

Application access tokens are used to make authorized API requests on behalf of a user or service and are commonly used as a way to access resources in cloud and container-based applications and software-as-a-service (SaaS).[Auth0 - Why You Should Always Use Access Tokens to Secure APIs Sept 2019] Adversaries who steal account API tokens in cloud and containerized environments may be able to access data and perform actions with the permissions of these accounts, which can lead to privilege escalation and further compromise of the environment.

For example, in Kubernetes environments, processes running inside a container may communicate with the Kubernetes API server using service account tokens. If a container is compromised, an adversary may be able to steal the container’s token and thereby gain access to Kubernetes API commands.[Kubernetes Service Accounts]

Similarly, instances within continuous-development / continuous-integration (CI/CD) pipelines will often use API tokens to authenticate to other services for testing and deployment.[Cider Security Top 10 CICD Security Risks] If these pipelines are compromised, adversaries may be able to steal these tokens and leverage their privileges.

In Azure, an adversary who compromises a resource with an attached Managed Identity, such as an Azure VM, can request short-lived tokens through the Azure Instance Metadata Service (IMDS). These tokens can then facilitate unauthorized actions or further access to other Azure services, bypassing typical credential-based authentication.[Entra Managed Identities 2025][SpecterOps Managed Identity 2022]

Token theft can also occur through social engineering, in which case user action may be required to grant access. OAuth is one commonly implemented framework that issues tokens to users for access to systems. An application desiring access to cloud-based services or protected APIs can gain entry using OAuth 2.0 through a variety of authorization protocols. An example commonly-used sequence is Microsoft's Authorization Code Grant flow.[Microsoft Identity Platform Protocols May 2019][Microsoft - OAuth Code Authorization flow - June 2019] An OAuth access token enables a third-party application to interact with resources containing user data in the ways requested by the application without obtaining user credentials.

Adversaries can leverage OAuth authorization by constructing a malicious application designed to be granted access to resources with the target user's OAuth token.[Amnesty OAuth Phishing Attacks, August 2019][Trend Micro Pawn Storm OAuth 2017] The adversary will need to complete registration of their application with the authorization server, for example Microsoft Identity Platform using Azure Portal, the Visual Studio IDE, the command-line interface, PowerShell, or REST API calls.[Microsoft - Azure AD App Registration - May 2019] Then, they can send a Spearphishing Link to the target user to entice them to grant access to the application. Once the OAuth access token is granted, the application can gain potentially long-term access to features of the user account through Application Access Token.[Microsoft - Azure AD Identity Tokens - Aug 2019]

Application access tokens may function within a limited lifetime, limiting how long an adversary can utilize the stolen token. However, in some cases, adversaries can also steal application refresh tokens[Auth0 Understanding Refresh Tokens], allowing them to obtain new access tokens without prompting the user.

Official technique definition · Open in the interactive matrix

Detection telemetry and configuration

These contracts are selected through exact technique-to-data-component relationships or explicitly labelled planning overrides. Configure a collector at the relevant observation point; a telemetry name alone is not coverage.

Application Log Content · source-mapped

DC0038 collection page — Select the application event family required by the detection and document its native schema before normalization.

Providers and collection configuration

  • Enable the application audit category or instrument the owned lab application at the authorization/action boundary.
  • Define a schema with timestamp, service, actor, object, action, result and correlation ID. Export structured records through an authenticated collector.
  • Redact secrets and personal content, separate audit from debug logs, set retention and verify delivery during rotation/restart.

Required normalized fields: service, action, actor, record_count, result.

Illustrative collection event

Project-normalized synthetic JSON, not a native provider log, captured event, attack verdict or validated detection. A parser/adapter is required for a real SIEM. Example names, IPs and values are fictional.

{
  "schema": "1200km.telemetry.example.v1",
  "synthetic": true,
  "timestamp": "2026-09-27T12:00:00Z",
  "telemetry_id": "DC0038",
  "collector": "illustrative-lab-collector",
  "observation": {
    "service": "lab-portal",
    "action": "export_requested",
    "actor": "lab-reader",
    "record_count": 3,
    "result": "authorized"
  }
}

Visibility limits: Debug output is not necessarily a durable audit trail. Application developers must emit the relevant event; installing a log pipeline does not make an absent event exist.

Cloud Service Enumeration · source-mapped

DC0083 collection page — Collect supported list/describe administrative APIs and retain caller and queried service scope; confirm read-event retention.

Providers and collection configuration

  • In the isolated account/project/subscription, route administrative audit logs to a protected destination with retention and access controls.
  • Select the relevant service, regions and read/write operations. Confirm whether the API below is a management or data event in the provider documentation.
  • Preserve actor/session, resource, request ID, service, operation, region and error details. Check delivery latency and avoid logging credentials or sensitive request bodies.

Required normalized fields: actor, service, action, result.

Illustrative collection event

Project-normalized synthetic JSON, not a native provider log, captured event, attack verdict or validated detection. A parser/adapter is required for a real SIEM. Example names, IPs and values are fictional.

{
  "schema": "1200km.telemetry.example.v1",
  "synthetic": true,
  "timestamp": "2026-09-27T12:00:00Z",
  "telemetry_id": "DC0083",
  "collector": "illustrative-lab-collector",
  "observation": {
    "actor": "lab-reader",
    "service": "lab-monitoring",
    "action": "list_resources",
    "result": "success"
  }
}

Visibility limits: AWS, Azure and Google expose different APIs and event schemas. An accepted API request does not prove the final resource state; join asynchronous outcomes and inventory.

Cloud Service Modification · source-mapped

DC0069 collection page — Collect the service-specific update API and resulting configuration state; record account/project, actor and changed settings.

Providers and collection configuration

  • In the isolated account/project/subscription, route administrative audit logs to a protected destination with retention and access controls.
  • Select the relevant service, regions and read/write operations. Confirm whether the API below is a management or data event in the provider documentation.
  • Preserve actor/session, resource, request ID, service, operation, region and error details. Check delivery latency and avoid logging credentials or sensitive request bodies.

Required normalized fields: service, resource_id, attribute, before, after.

Illustrative collection event

Project-normalized synthetic JSON, not a native provider log, captured event, attack verdict or validated detection. A parser/adapter is required for a real SIEM. Example names, IPs and values are fictional.

{
  "schema": "1200km.telemetry.example.v1",
  "synthetic": true,
  "timestamp": "2026-09-27T12:00:00Z",
  "telemetry_id": "DC0069",
  "collector": "illustrative-lab-collector",
  "observation": {
    "service": "lab-audit-service",
    "resource_id": "lab-service-1",
    "attribute": "retention_days",
    "before": 7,
    "after": 30
  }
}

Visibility limits: AWS, Azure and Google expose different APIs and event schemas. An accepted API request does not prove the final resource state; join asynchronous outcomes and inventory.

Cloud Storage Access · source-mapped

DC0025 collection page — Explicitly select relevant object-read data events; keep principal, key, request ID and result without object contents.

Providers and collection configuration

  • Choose only the lab buckets/containers and prefixes. Enable read/write data-event collection when object access is needed; management events alone are insufficient.
  • Keep administrative changes separately from object reads/writes. Set a cost budget and retention limit before enabling high-volume data logging.
  • Preserve object version/key, requesting identity, action, source address, result and request ID. Verify the collector actually receives one benign read and one benign write.

Required normalized fields: action, bucket, key, actor, result.

[
  {
    "Name": "LabObjectReads",
    "FieldSelectors": [
      {
        "Field": "eventCategory",
        "Equals": [
          "Data"
        ]
      },
      {
        "Field": "resources.type",
        "Equals": [
          "AWS::S3::Object"
        ]
      },
      {
        "Field": "resources.ARN",
        "StartsWith": [
          "arn:aws:s3:::lab-bucket/demo/"
        ]
      },
      {
        "Field": "readOnly",
        "Equals": [
          "true"
        ]
      }
    ]
  }
]

Replace the placeholder with an owned lab bucket/prefix. Review costs and merge with required selectors; applying selectors can replace an existing selection. This does not enable management-event retention or object-write coverage.

Illustrative collection event

Project-normalized synthetic JSON, not a native provider log, captured event, attack verdict or validated detection. A parser/adapter is required for a real SIEM. Example names, IPs and values are fictional.

{
  "schema": "1200km.telemetry.example.v1",
  "synthetic": true,
  "timestamp": "2026-09-27T12:00:00Z",
  "telemetry_id": "DC0025",
  "collector": "illustrative-lab-collector",
  "observation": {
    "action": "get_object",
    "bucket": "lab-bucket",
    "key": "demo.txt",
    "actor": "lab-reader",
    "result": "success"
  }
}

Visibility limits: Storage metadata, listing, object access and bucket administration are different operations. Do not equate a successful request with proven exfiltration or complete content visibility.

File Access · source-mapped

DC0055 collection page — Enable Audit File System plus a narrow SACL on a lab directory; on Linux select path/syscall rules and join associated Audit records.

Providers and collection configuration

  • Use a lab-only GPO under Computer Configuration → Windows Settings → Security Settings → Advanced Audit Policy Configuration. Enable the specific subcategory named below.
  • For object-level auditing, configure a narrow system access control list (SACL) on the test object in addition to policy. Do not audit an entire production directory by default.
  • Forward Security events from the responsible host or controller; retain subject and target identities, object identifiers, result and original XML. Confirm effective policy with auditpol /get /category:*.

Required normalized fields: path, access, actor, result.

Illustrative collection event

Project-normalized synthetic JSON, not a native provider log, captured event, attack verdict or validated detection. A parser/adapter is required for a real SIEM. Example names, IPs and values are fictional.

{
  "schema": "1200km.telemetry.example.v1",
  "synthetic": true,
  "timestamp": "2026-09-27T12:00:00Z",
  "telemetry_id": "DC0055",
  "collector": "illustrative-lab-collector",
  "observation": {
    "path": "C:\\Lab\\demo.txt",
    "access": "read",
    "actor": "LAB\\analyst",
    "result": "success"
  }
}

Visibility limits: A policy checkbox alone does not guarantee an event. Host role, SACL, success/failure selection and audit policy precedence matter. Directory changes may arrive as multiple records.

User Account Authentication · source-mapped

DC0002 collection page — Collect successful and failed sign-ins, authentication method, application and conditional-access context; distinguish account validation from session creation.

Providers and collection configuration

  • Enable/export the required identity sign-in and audit categories from the lab tenant to a protected destination. Document license, role and retention requirements.
  • Correlate issuance or administrative changes with later sign-ins using non-secret credential IDs, application IDs, user IDs and correlation IDs.
  • Exclude passwords, bearer tokens, cookies and private keys. Record success, failure, authentication context and application result separately.

Required normalized fields: account, application, result, reason, source_ip.

Illustrative collection event

Project-normalized synthetic JSON, not a native provider log, captured event, attack verdict or validated detection. A parser/adapter is required for a real SIEM. Example names, IPs and values are fictional.

{
  "schema": "1200km.telemetry.example.v1",
  "synthetic": true,
  "timestamp": "2026-09-27T12:00:00Z",
  "telemetry_id": "DC0002",
  "collector": "illustrative-lab-collector",
  "observation": {
    "account": "analyst@example.test",
    "application": "lab-portal",
    "result": "failure",
    "reason": "invalid_credential",
    "source_ip": "192.0.2.10"
  }
}

Visibility limits: A token creation record is not evidence of token use; a sign-in is not a complete record of every resource access. Some provider-side data is unavailable to the customer.

Detection rules and analytic guidance

Open the dedicated detection workspace · Existing query engineering

DET0515 Detection Strategy for T1528 - Steal Application Access Token

MITRE detection strategy

AN1423 Analytic 1423

Access and retrieval of container service account tokens followed by unauthorized API requests using those tokens to interact with the Kubernetes API server or internal services.

Platforms: Containers.

  • File Access — kubernetes:audit; channel GET or LIST requests to /var/run/secrets/kubernetes.io/serviceaccount/ followed by access to the Kubernetes API server.

AN1424 Analytic 1424

Token retrieval from instance metadata endpoints such as AWS IMDS or Azure IMDS, followed by API usage using the obtained token from non-standard applications.

Platforms: IaaS.

AN1425 Analytic 1425

Unusual OAuth app registration followed by user-granted OAuth tokens and subsequent high-privilege resource access via those tokens.

Platforms: Identity Provider.

  • Application Log Content — azure:audit; channel App registrations or consent grants by abnormal users or at unusual times.

AN1426 Analytic 1426

Use of OAuth tokens by third-party apps to access user mail, calendar, or SharePoint resources where the token was granted recently or via spearphishing.

Platforms: Office Suite.

  • Cloud Storage Access — m365:unified; channel App-only or delegated access patterns where client_id != known enterprise apps.

AN1427 Analytic 1427

Programmatic access to user content via stolen access tokens in platforms like Slack, GitHub, Google Workspace — especially from new IPs, apps, or excessive resource access.

Platforms: SaaS.

  • User Account Authentication — saas:googleworkspace; channel Access via OAuth credentials with unusual scopes or from anomalous IPs.
  • Application Log Content — saas:slack; channel OAuth token use by unknown app client_id accessing private channels or files.
Source rule directory and observation requirements

14 exact-tagged source rules. A source tag is a discovery aid, not a relevance verdict. Check the observation point and actual condition of each rule.

Before treating a rule as coverage

  1. Read the actual condition and logsource; identify attacker-side, victim-side or third-party visibility.
  2. Map native sensor fields, parse times and identities, then compile for the selected backend.
  3. Replay a behavior-positive case, a normal control, an authorized look-alike and a missing-telemetry case.
  4. Record matches and misses with rule version and source events. No match is inconclusive when required telemetry is absent.

Anomaly-based detection

No exact technique-specific Atlas model is present for T1528 in the selected source snapshot. The following is a design worksheet, not a newly validated model.

Anomaly engineering worksheet

Start from the exact analytic above. The collection-specific lenses below are analyst recommendations; they do not assert that an arbitrary statistical deviation detects this technique.

  • Application and service audit: Per application, client and route: request rate, rare actions, failure ratios and unusual state transitions. Version changes, retries, health probes and seasonal load need separate baselines.
  • Cloud control plane: Per account, role, region and API: rare actions, new role-resource relationships, enumeration bursts and configuration changes. Separate deployment automation and organization-level administrative activity.
  • Cloud storage: Per principal and bucket/container: unusual object-read counts, transferred volume, new access pairs and bulk permission/deletion activity. Model backups, migrations and lifecycle policies separately.
  • Windows and directory audit: Per principal, host and object: unusual access/request rates, new principal-object relationships, and changes outside approved administration windows. Control for service accounts and scheduled directory maintenance.
  • Identity and SaaS: Per identity and application: first-seen clients/resources, changes in authentication failures and session patterns, and unusual permission changes. Separate automation, travel, shared egress and identity-provider policy changes.
  1. Define an entity/peer group and feature; exclude the evaluation period from baseline training.
  2. Use representative normal and maintenance activity. Do not invent a production threshold from a synthetic example.
  3. Evaluate held-out behavior-positive and benign cases; measure false positives, misses and telemetry loss separately.
  4. Keep abnormality separate from maliciousness. Correlate with the behavior-specific source evidence.

Anomaly Detection Atlas · Baseline, validation and blind spots

Attack tools and documented software

Software observed in source procedures

These are exact ATT&CK software-use relationships, including malware. They provide behavior context, not recommendations to download or execute malware. No safety or detector claim is inherited.

9 source-documented software associations

Simulation design and documented procedures

Atomic evidence: 2 compatible documented candidates. Live lab status: not run for these imported procedures.

Use disposable lab hosts and test accounts, explicit target allowlists, a clean snapshot, bounded egress and a restore plan. Review every candidate and dependency before any execution.

Azure - Functions code upload - Functions code injection via File Share modification to retrieve the Functions identity access token

This test injects code into an Azure Function (RCE) to perform Subscription Privilege Escalation by retrieving the identity access token of an Azure functions instance.

Attack idea/reference: https://orca.security/resources/blog/azure-shared-key-authorization-exploitation/

Once executed, the "https://changeme" will retrieve the access token when the function app is executed on behalf of the tenant. The function may be triggered manually from authorized people, triggered in regular intervals, or in various other ways. The access token can then be used to perform further attack steps with the permissions that the function app holds (e.g. listening virtual machines).

Note:
- The Azure Function modified in this test must be hosted via Azure Files in a File Share (Info on storage considerations for Azure Function: https://learn.microsoft.com/en-us/azure/azure-functions/storage-considerations).
- For Function code upload to Azure Functions that are hosted via Azure Blob storage, refer to T1528 "Azure - Functions code upload - Functions code injection via Blob upload".
- The required input fields can be retrieved in a reconnaissance step in test T1619 "Azure - Enumerate Storage Account Objects via Key-based authentication using Azure CLI". The code of function apps may be inspected and prepared from the result of test T1530 "Azure - Dump Azure Storage Account Objects via Azure CLI".
- Important: Change the https://changeme.net in code_to_insert_path to a self-controlled endpoint. This endpoint can be hosted e.g. as request bin via Pipedream to display the body of incoming POST requests.
- The default injected code to retrieve the access token can be replaced by arbitrary other code. In this case: Replace the code defined in code_to_insert_path

Requirements:
- The test is intended to be executed in interactive mode (with -Interactive parameter) in order to complete the az login command when MFA is required.
- The EntraID user must have the role "Storage Account Contributor", or a role with similar permissions.

Execution options: Defined by the input field execution_option
- insert_code: This option (1) downloads the existing funciton code into a tmp file, (2) injects the code from code_to_insert_path at the beginning of the file, and (3) uploads the tampered file to the targeted Azure Function code (Azure File Share File).
- replace_file: This option uploads the function code defined in code_to_insert_path to the targeted Azure Function code (Azure File Share File).

Pinned Atomic procedure · 67aaf4cb-54ce-42e2-ab56-e0a9bcc089b1 · iaas:azure · powershell.

Elevation: not declared required. Cleanup: defined upstream; review required. This is source documentation, not an execution approval.

Source-defined inputs

  • storage_account_name: Name of storage account that is related to the Function (type string; source default storage_account_name_example)
  • execution_option: Chooses execution option insert_code, or replace_file (type string; source default insert_code)
  • file_share_name: Name of the file share that is related to the Function (type string; source default file_share_name_example)
  • file_path: Path to the Function file in the file share (type path; source default site/wwwroot/function_app.py)
  • code_to_insert_path: The code that will be injected into the Function (type path; source default $PathToAtomicsFolder/T1528/src/code_to_insert.py)

Review the upstream command, dependencies and cleanup at the source link. Source defaults may refer to real infrastructure or destructive actions; they are not authorized targets. No automatic install, prerequisite download or command execution is provided.

1 prerequisite definitions:

  • Azure CLI must be installed
Azure - Functions code upload - Functions code injection via Blob upload

This test injects code into an Azure Function (RCE).

Attack idea/reference: https://orca.security/resources/blog/azure-shared-key-authorization-exploitation/

Similar to T1528 "Azure - Functions code upload - Functions code injection to retrieve the Functions identity access token", the depicted code injection scenario tampers the source code of Azure Functions to perform Subscription Privilege Escalation by retrieving the identity access token of an Azure functions instance. In this case, the prepared zip file (underlying package for a Function) is expected to contain the tampered function presented in src/code_to_insert.py. Note that the endpoint https://changeme.net needs to be adapted in your packed function code.

Note:
- The Azure Function modified in this test must be hosted via Azure Blob storage (Info on storage considerations for Azure Function: https://learn.microsoft.com/en-us/azure/azure-functions/storage-considerations).
- For Function code upload to Azure Functions that are hosted via Azure Files in a File Share, refer to T1528 "Azure - Functions code upload - Functions code injection to retrieve the Functions identity access token".
- The required input fields can be retrieved in a reconnaissance step in test T1619 "Azure - Enumerate Storage Account Objects via Key-based authentication using Azure CLI". The code of function apps may be inspected and prepared from the result of test T1530 "Azure - Dump Azure Storage Account Objects via Azure CLI".

Requirements:
- The test is intended to be executed in interactive mode (with -Interactive parameter) in order to complete the az login command when MFA is required.
- The EntraID user must have the role "Storage Account Contributor", or a role with similar permissions.

Pinned Atomic procedure · 9a5352e4-56e5-45c2-9b3f-41a46d3b3a43 · iaas:azure · powershell.

Elevation: not declared required. Cleanup: defined upstream; review required. This is source documentation, not an execution approval.

Source-defined inputs

  • storage_account_name: Name of storage account that is related to the Function (type string; source default storage_account_name_example)
  • container_name: Name of the container that contains the function blob (type string; source default container_name_example)
  • blob_name: Name of the function blob (type string; source default blob_example)
  • file_path_blob: Path to the function code file to upload as blob (type path; source default $env:temp/T1528_function_code.zip)

Review the upstream command, dependencies and cleanup at the source link. Source defaults may refer to real infrastructure or destructive actions; they are not authorized targets. No automatic install, prerequisite download or command execution is provided.

1 prerequisite definitions:

  • Azure CLI must be installed

Technique-specific experiment contract

  1. Choose one procedure implementing T1528 Steal Application Access Token; identify the observable behavior in the source definition, not just its tactic.
  2. Record exact target, tool/version, inputs, privileges, network limits and approval. Never run an imported default target automatically.
  3. Enable the collection sources above and verify a benign baseline reaches the detector.
  4. Run only the approved isolated scenario; capture native events and an independent behavior observable.
  5. Evaluate the exact rule/model, restore the lab, and preserve configuration, event hashes, alerts, controls and misses.

Synthetic logs and offline contract check

Download synthetic collection fixture (JSON) · Download the complete engineering workbook

This fixture exercises the listed collection fields. It does not reproduce Steal Application Access Token, label its example events as malicious, or measure detection effectiveness. Use the exact analytic and selected procedure to build an independently labelled behavior-positive dataset.

Not run in this browser. No network scan or attack command is executed by this control.

Validation status and remaining work

Source identity
Joined by exact technique/object IDs against hash-pinned sources.
Collection fixture
Available for offline schema exercises; not attack emulation.
Native telemetry / backend / real attack
Not validated for these imported procedures. Source fidelity and page tests cannot establish sensor or detector effectiveness.

All-page audit and evidence inventory · This page’s machine-readable workbook

Sources and evidence boundaries

Pinned MITRE STIX source · SHA-256 81113ba98afa2928f3dcff62022539f7ce30c315c32e14422f11ff95ce534352. Definition and procedure context are reproduced from this snapshot, not independently re-investigated incidents.

Source-linked mitigations
  • M1017 User Training

    Users need to be trained to not authorize third-party applications they don’t recognize. The user should pay particular attention to the redirect URL: if the URL is a misspelled or convoluted sequence of words related to an expected service or SaaS application, the website is likely trying to spoof a legitimate service. Users should also be cautious about the permissions they are granting to apps. For example, offline access and access to read emails should excite higher suspicions because adversaries can utilize SaaS APIs to discover credentials and other sensitive communications.

  • M1018 User Account Management

    Enforce role-based access control to limit accounts to the least privileges they require. A Cloud Access Security Broker (CASB) can be used to set usage policies and manage user permissions on cloud applications to prevent access to application access tokens. In Kubernetes applications, set “automountServiceAccountToken: false” in the YAML specification of pods that do not require access to service account tokens.[Kubernetes Hardening Guide]

  • M1021 Restrict Web-Based Content

    Administrators can block end-user consent to OAuth applications, disabling users from authorizing third-party apps through OAuth 2.0 and forcing administrative consent for all requests. They can also block end-user registration of applications by their users, to reduce risk. A Cloud Access Security Broker can also be used to ban applications.

    Azure offers a couple of enterprise policy settings in the Azure Management Portal that may help:

    "Users -> User settings -> App registrations: Users can register applications" can be set to "no" to prevent users from registering new applications.
    "Enterprise applications -> User settings -> Enterprise applications: Users can consent to apps accessing company data on their behalf" can be set to "no" to prevent users from consenting to allow third-party multi-tenant applications

  • M1047 Audit

    Administrators should audit all cloud and container accounts to ensure that they are necessary and that the permissions granted to them are appropriate. Additionally, administrators should perform an audit of all OAuth applications and the permissions they have been granted to access organizational data. This should be done extensively on all applications in order to establish a baseline, followed up on with periodic audits of new or updated applications. Suspicious applications should be investigated and removed.

Connected ecosystem references

Linked tags

enterprisecloudcontainersidentityonpremsaasContainersIaaSIdentity ProviderOffice SuiteSaaScredential-accessisolated_authorized_labprocedure_review_requiredtelemetry_configuration_requireddisposable_tenant_and_cost_controls
Atomic candidate documentedtechniquesource_mapped

Source procedure platform / method / executor tags:

iaas:azureautomatedpowershell

Detection and collection

T1528 detection workspace

Threat actor context

These are explicit actor-to-technique associations in the existing Threat Matrix snapshot, not attribution of an event or proof that a detector identifies the actor. No tool-to-actor relationship is inferred.

Existing research

Threat Matrix: knowledge routes, evidence and actor context

Pinned research references. No browser attack runner or production-validated detector is asserted. Imported procedures remain unvalidated; any bounded lab evidence has its own scope. ATT&CK / Atomic provenance · Detection provenance.