How T1528 steal application access token attacks work and where they appear
A SOC lead asking whether stolen application access tokens are visible in their logs should start from a simple answer: they are visible only if the platforms that issue and accept those tokens write authentication and application events that the SOC actually collects. T1528 Steal application access token describes an adversary obtaining a token that an application, service or user session already holds, then presenting it to act as that identity without knowing the password. Because the token is reused, the attacker often never triggers a failed login, so detection depends on whether token use is logged with enough context (client, source, scope and time) to separate it from legitimate automation.
The technique matters most where tokens are long-lived and widely trusted. In container platforms, a service account token mounted into a workload can call the cluster API. In IaaS, an access token or instance metadata credential can call cloud control planes. In identity providers and office suites, OAuth or session-bearing tokens can read mail, files or directory data. Each of these is a different log source, so a SOC should confirm, platform by platform, which token issuance, token use and application audit records are retained and for how long. Illustrative example: a token copied from a build job that later appears in a new source region would only be caught if sign-in logs and application audit logs are both ingested.
MITRE places T1528 under Credential Access (TA0006), which ATT&CK defines as the adversary trying to steal account names and passwords. Tokens are not passwords, but they serve the same purpose for an intruder: they convert a stolen secret into access. Mapping the technique to TA0006 tells defenders to review the same controls they use for credential theft, including token lifetime, scope and revocation. The technique details in this page follow Enterprise ATT&CK version 20.0. Confirm the version your detection content targets, since MITRE's ATT&CK updates page notes that releases can rename or deprecate techniques.
Which data sources reveal application access token theft
This table maps the data components most relevant to T1528 to the signal each one exposes and the open-source collector that can gather it. Read each row as a question: what would show a stolen token being read, replayed or used from an unexpected place. The main takeaway is that no single source is sufficient, so token use must be correlated across file, identity and application records, and every mapping should be checked against the ATT&CK version your team targets.
| Data component | Signal to look for | Open-source collector |
|---|---|---|
| File Access (DC0055) | Reads of token caches, configuration files or secret stores by processes that do not normally touch them | Wazuh file integrity and auditing, Velociraptor hunts |
| User Account Authentication (DC0002) | Token-based sign-ins from new client identifiers, unusual networks or impossible travel patterns | Wazuh ingestion of identity provider logs, Security Onion or Zeek for network-side authentication flows |
| Application Log Content (DC0038) | Token issuance, refresh or scope changes in SaaS and cloud application audit logs, especially when no matching user action exists | Wazuh log collection from application and cloud audit sources |
| Process Creation (DC0032) | Host processes launched that then read token material or contact identity endpoints, where host activity matters | Wazuh process telemetry, Velociraptor artifact collection |
| Network Traffic Content (DC0085) | Bearer tokens sent to unexpected destinations or over unexpected protocols, where traffic is visible | Zeek and Suricata via Security Onion |
| Correlation across sources | Same token identifier seen in file reads, sign-ins and application actions within a short window | Wazuh rules combined with Security Onion dashboards. Confirm field availability in your own environment. |
| ATT&CK version note | Confirm detection strategy and data component IDs against the version your team targets, since ATT&CK v18 changed data components and detection strategies | Check the ATT&CK updates pages before writing rules |
Detection logic for token reuse from unexpected sources
Stolen application access tokens are hard to spot because they carry valid signatures and pass normal checks. The cards below describe detection ideas built on where a token was issued, who uses it, what it does, and how the application logs record grants. Each idea needs tuning against your own baseline, and each has known benign sources that should be excluded before alerts reach an analyst.
Token used from an unfamiliar context
Correlate the issuing sign-in event with later API calls that present the same token. Flag a token whose use comes from a network range, country, autonomous system or client application that never appeared for that identity during the baseline window. Start with a tight allow-list of corporate egress and known SaaS integration addresses, then widen it only after reviewing alerts for a few weeks. Benign sources include mobile clients that roam between networks, VPN exit changes and CI runners that rotate addresses. Treat a new client identifier paired with a new network as the priority combination.
Service identity acting outside scope
Build a per-identity profile of the API operations, resource groups and data stores a service principal, workload identity or integration account normally touches. Alert when the same identity calls an operation outside that profile, especially reads of mailboxes, directory objects or storage buckets it has never accessed. Set the threshold as a count of new operation types per identity per day rather than a single event, to reduce noise from routine deployments. False positives come from new releases of an integration, scheduled backup jobs that read broadly, and administrators who onboard new services.
Token use after rotation or revocation
Record the time each client secret, certificate or refresh credential was rotated or revoked, then alert on any token request or API call that presents material from the retired credential after that moment. Successful use after revocation points to a cached or copied token that the identity provider has not yet invalidated, or to a revocation that did not propagate. Check the lifetime settings of access tokens against your revocation process, because short-lived tokens narrow the window but do not remove it. Common false positives include clients with stale caches that retry after a secret change and pipelines that still reference an old variable.
New consent and token grants
Review application log content for events that record new consent, admin consent, new application registrations, added credentials or new delegated permissions. Prioritize grants that request broad mail, file or directory scopes, grants made by accounts that do not normally administer applications, and grants made outside change windows. Confirm the audit fields your platform emits, since the exact event names and attributes vary by product and version. Expected sources of noise include legitimate SaaS onboarding, employees approving vendor tools, and automated provisioning that creates applications on schedule.
Container workloads presenting external tokens
Inspect outbound authentication from pods and containers for tokens issued by identity providers outside the cluster's expected issuer list, or for tokens whose audience does not match the workload. Use file access telemetry on mounted service account paths and environment variables to see when a token file is read by a process other than the expected application. Pipelines that deploy workloads, sidecars that refresh tokens and health checks can all look similar, so maintain an allow-list of process and image pairs. Confirm with your platform team how service account tokens are projected and how long they last in your cluster configuration.
How to validate that token theft detections fire
This sequence confirms that detections for T1528 Steal Application Access Token fire on the platforms in scope, that alerts reach the SIEM in time to matter, and that gaps are recorded and tuned. It produces a dated evidence pack that a CISO or auditor can trace back to specific log sources and detection logic.
Agree scope and rules of engagement
The security lead, the platform owners for each in-scope system (container platform, IaaS control plane, identity provider and office suite tenants), and the SOC manager agree in writing which platforms, accounts and test identities are covered, which lab or cyber range is used, who may approve activity, and how the exercise is stopped. Production tenants are excluded unless the client explicitly signs off on a bounded, monitored test. The step is done when the signed scope note names each platform and the approver for each action.
Define expected log events per platform
Detection engineers map the expected evidence for each platform to the ATT&CK data components referenced for this technique, including File Access, User Account Authentication and Application Log Content. For each platform they write down which events should appear, which fields identify the token, the principal and the source address, and which log source carries them. Confirm the ATT&CK version the mapping targets, since releases can rename or revoke techniques. The step closes when every in-scope platform has a reviewed expectation sheet with named log sources.
Run an approved simulated token reuse scenario
The red or purple team runs an agreed scenario in the range, such as a test access token being used from an unexpected network location or client context, using only the actions in the signed scope. The operator logs each action with a timestamp and the identity used, so the exercise can be reconstructed later. The scenario is considered complete when every planned action is recorded as executed, skipped or blocked, with the reason noted.
Confirm alerts reach the SIEM
The detection engineer checks that raw events from each platform arrive in the SIEM, for example through Wazuh or Security Onion pipelines, without parsing failures or dropped fields. Then they confirm that the relevant detection rules, written against the expected events, produced alerts with the token, principal and source fields populated. The step is done when each planned action has either a matching alert or a documented reason for its absence, such as a missing log source.
Record time to alert and missed events
The SOC analyst compares the timestamp of each simulated action with the timestamp of the first alert and the time the alert was acknowledged. Any action without an alert is recorded as a missed event, with the platform, the log source and the likely cause, such as disabled audit logging, delayed ingestion or an overly narrow rule. The output is a table of actions, alert times and gaps that can be reviewed by the detection owner and the platform owner.
Tune rules and retest the gaps
Detection engineers adjust rules to close confirmed gaps, reduce noise from benign token refreshes and sanctioned automation, and document each change with its reason. They then rerun only the affected scenario steps in the range to confirm the change works without breaking other detections. The step closes when each change has a before and after result and a named approver.
Retain the evidence pack
The team packages the scope note, expectation sheets, operator log, SIEM screenshots or exports, alert timing table, gap register and tuning changes into one dated evidence set linked to the ATT&CK version and the detection identifiers. Ask the auditor or assessor in advance which format they accept. The step is complete when the pack is stored under access control and the exercise owner signs off that it reflects what happened.
How identity and application logs connect for T1528 detection
A single log source rarely proves that an application access token was stolen. Token issuance happens in the identity provider, token use happens against the cloud control plane, container platform or office suite, and each of those systems records only its own slice of the sequence. An issuance event shows that a token was granted to a subject for a client, a use event shows that a request arrived somewhere, and only by joining the two can a team tell whether the same grant is now being used from an unexpected place. Plan the detection around that join before writing any single rule.
The correlation keys that make the join possible are the subject (the user or workload identity the token represents), the client (the application or service principal that requested it), the session or token identifier, and the source address. Each system names these fields differently, so the first practical task is a field map: confirm with each vendor which attribute carries the subject, which carries the client identifier, whether the session identifier is exposed in application logs at all, and whether source addresses are recorded as the client address or as an intermediate proxy address. Where a platform cannot expose a session or token identifier, the team should decide which weaker key (for example, subject plus client plus time window) it will accept and document the false positive cost of that choice.
Treat a mismatch between keys as the signal. An illustrative case: a token issued to a build service principal for one client appears later in control plane logs from a source address and user agent never seen for that client. Neither event is conclusive alone, but the mismatch is what a responder should investigate. Confirm retention periods for identity provider sign-in and token logs, control plane audit logs and container platform audit logs before rollout, because a correlation that cannot reach back far enough to link issuance and use will fail quietly during an incident.
Mitigations that reduce application access token exposure
These five cards cover the two ATT&CK mitigations mapped to T1528, User Training (M1017) and User Account Management (M1018), and three configuration controls that limit what a stolen token can reach. Together they shorten the period a token stays valid, narrow the data it can access, and reduce the ways a user can be tricked into granting it. Confirm platform-specific settings with your vendor documentation before changing production policy.
User training (M1017)
Mitigation M1017, User Training, covers the people who approve, install and operate applications that receive tokens. Train administrators, developers and users to recognize consent prompts that request broad scopes, to keep tokens and client secrets out of tickets, chat threads and source repositories, and to report sign-ins from applications they do not recognize. Training is recurring work, so schedule refreshers and test them with simulated consent phishing exercises in your cyber range.
User account management (M1018)
Mitigation M1018, User Account Management, limits who can create, own and hold the accounts and service identities that carry tokens. Review dormant service accounts and stale user accounts on a fixed schedule, remove access promptly for leavers, and restrict which roles can register applications or grant tenant-wide admin consent. Confirm how your identity provider and SaaS platforms implement these controls, since role names and audit settings differ by product.
Token lifetime policy
Access tokens are short-lived by design, but refresh tokens and long-lived application credentials can remain valid far longer and are often the more valuable target. Set lifetime and refresh policies per application based on its risk, record each exception with an owner and an expiry date, and review them when staff or integrations change. Confirm the configuration keys and default values for each product in its own documentation, because defaults vary between platforms.
Least-privilege application permissions
Grant each application only the scopes its function requires. Broad scopes, such as full mailbox access, directory write rights or repository administration, turn one stolen token into access to unrelated data. Inventory the permissions granted to each application, flag those with write or administrative scopes, and test whether they can be narrowed without breaking the integration. Ask each platform team which permission models its SaaS and cloud providers support, since application and delegated permissions behave differently.
Consent review
Consent phishing can give an attacker a working token without stealing a password, so consent grants need their own review. Keep a register of which applications hold consent, who approved them and when. Where the platform allows it, restrict user consent, route requests through an approval workflow, and alert on new grants that request high-privilege scopes. Confirm the available settings and audit log fields with each vendor's documentation before relying on them.
Triage steps when a token reuse alert fires
When a token reuse alert fires for T1528 Steal application access token, the first task is to confirm which token and which application the alert concerns. Record the token identifier, the issuing application or client ID, the identity it was issued to, the granted scopes, and the source IP address and user agent of the reuse. Then check whether that use matches the expected workload. A service principal or OAuth client that normally calls from a known CI runner, container node or SaaS integration should not suddenly appear from a new network, a new user agent or an unusual hour. Compare the observed calls against the application's documented behavior. Where the owning team cannot explain the activity within the triage window, treat the token as compromised and move to containment. Confirm with the application owner which log sources hold this evidence in your environment, because token issuance and token use are often logged in different places.
Containment comes next. Revoke the affected tokens and refresh tokens where the identity provider supports it, then rotate the client secret, certificate or API key that the application uses to obtain tokens. Revoking a token without rotating the underlying secret often leaves the attacker able to request a new one, so both steps belong in the runbook. Review the application's granted permissions and recent consent changes, including new admin consents, added redirect URIs and newly granted delegated or application permissions. Scope other tokens issued to the same identity or to the same application across your platforms, including containers, IaaS and office suite integrations, so that a single reuse does not leave sibling credentials untouched. Before you act, preserve the relevant identity provider sign-in and audit logs, application logs and any file or configuration changes, so that the investigation remains defensible if containment changes the state of the environment.
For regulated organizations, the decision to notify is often the hardest part of the triage. Agree in advance with legal, privacy and compliance leads which events escalate to the security incident process, who approves the revocation of production credentials, and how long the service owner may take to explain an anomaly before containment proceeds. Confirm with your regulator, contractual counterparties and internal policy what notification duties apply to a suspected credential compromise, since those obligations depend on your sector and jurisdiction and are not set by ATT&CK. Keep a timeline of decisions, the evidence reviewed and who approved each containment step. That record supports post-incident review and later compliance assessments. Rehearse this sequence in the private cyber range so that the escalation path, the revocation steps and the log preservation are practiced before a real alert arrives.
Rehearsing T1528 detection in a private cyber range
This tab builds a range around a self-hosted identity provider, such as Keycloak, that issues OAuth and OpenID Connect tokens to a set of test applications, with a sandboxed office-suite or collaboration service integrated through the same identity layer. Authentication logs from the identity provider and audit logs from the application are forwarded to Wazuh or Security Onion so analysts work from the same records they would use in production. Injects are planned in advance and written as scenario steps, not as commands.
- Token reuse from an unusual source: Plan an inject where a valid token is presented from an address, client or device the user has never used. Detection should key on the mismatch between token context and the user's normal authentication profile.
- Permission escalation after consent: Plan an inject where an application gains broader scopes after a user grants consent. Detection should flag new or expanded grants on sensitive scopes and consent events from unfamiliar applications.
- Response drills: Practice revoking sessions, rotating client secrets and reviewing consent grants, and confirm that the playbook names an owner for each step.
- Evidence capture: Confirm that token issuance, refresh and revocation events are retained long enough to reconstruct the timeline.
Check that the range logs carry enough identity context (user, client, scope, source) for an analyst to answer who used which token and what it accessed.
This tab uses a self-hosted cloud sandbox that mirrors the control-plane patterns of your provider, with instance metadata access, service accounts and short-lived credentials. Cloud API activity and host logs are shipped to Wazuh, and network metadata is captured by Zeek or Suricata where traffic crosses the range boundary. The aim is to test whether defenders can tell legitimate workload credential use from a token that has been lifted and used elsewhere.
- Token used from outside the workload: Plan an inject where a workload's temporary credential is used from a network location that is not the instance it was issued to. Detection should compare the source address and user agent against the workload's expected behavior.
- Unexpected API calls: Plan an inject where the reused token calls services the workload never used before. Detection should baseline API action names per identity and alert on first-seen actions.
- Response drills: Practice revoking the affected credential, isolating the workload and reviewing recent role assumptions, with each step timed by the exercise lead.
- Telemetry gaps: Record which cloud control-plane events are missing from the range and treat each gap as a finding.
Confirm with your cloud provider which audit and access logs are available for the services you plan to use, and which ones require extra configuration.
This tab runs a self-hosted Kubernetes or container platform in the range, with a workload that calls an external API using a token mounted from a secret. Audit logs from the API server, container runtime events and network flows are collected so the exercise can follow a token from the secret store to its use outside the cluster. The range is kept separate from production clusters and uses synthetic tokens only.
- External token use by a container workload: Plan an inject where a workload that normally talks only to internal services presents its token to an external endpoint. Detection should flag egress from workloads that have not previously reached that destination.
- Secret access outside the expected pattern: Plan an inject where a process reads a mounted secret it does not normally need. Detection should rely on file access events on secret paths, correlated with the pod and service account identity.
- Response drills: Practice rotating the affected secret, cordoning or restarting the workload and reviewing network policy changes.
- Image and configuration review: Confirm that the team can trace which image, deployment and secret version were active at the time.
Confirm which audit policy levels and runtime event sources your platform version supports before writing detection rules against them.
Questions SOC leads ask about T1528 detection
How do I tell token reuse from a legitimate token refresh?
Look at the context around the token, not the token event alone. A legitimate refresh usually comes from the same client application, device, network path and user session that originally obtained the token, and it follows the expected lifetime and grant pattern for that application. Token reuse often shows a token presented from a new IP address, a new user agent, an unfamiliar autonomous system, or a different client identifier than the one that requested it. Build a baseline per application and per identity over a period you can justify, then alert on deviations that combine two or more of these attributes. Test the logic against known administrative and automated workflows first, because service accounts and CI jobs produce many refreshes that look unusual to a human reviewer. Confirm with each identity provider and SaaS vendor which fields their sign-in and token logs actually record, since the available attributes differ by platform.
Which logs should I retain to investigate suspected token theft?
Retain the sources that record who obtained a token, where it was used and what it accessed. In practice this means identity provider sign-in and token issuance logs, cloud control plane audit logs, SaaS audit and admin logs, application logs that record API calls under a token, and network or proxy records that show source addresses. Map each source to the ATT&CK data components referenced for T1528, including User Account Authentication and Application Log Content, so you can show coverage in a gap review. Retention periods should follow your legal, regulatory and internal investigation requirements, which your compliance lead should set. Check whether each vendor retains token-level events by default, how far back they are searchable, and whether exports can be forwarded to your Wazuh or Security Onion pipeline without losing fields.
How should we handle the ATT&CK v18 and v19 mapping changes for T1528?
Pin every detection to the ATT&CK version it targets and record that version in the rule metadata. ATT&CK v18 replaced technique-level detections with detection strategies and analytics, updated data components and deprecated some data sources, so older rule references may point to concepts that now have different names or IDs. v19 followed on April 28, 2026, and v20 on October 13, 2026, so mappings written against one release need review against the next. Keep a short change log per rule, review mappings when a new release is published, and load the STIX bundle for your chosen version into your coverage tooling to compare. The MITRE ATT&CK updates pages list what changed in each release, and your team should read the notes for the versions you use before updating mappings.
What should we confirm with cloud and SaaS vendors about token logging?
Ask each vendor a short list of specific, checkable questions before you write detections against their logs. Confirm whether token issuance, token refresh and token use each produce a separate event, and whether those events include the client identifier, source address, user agent and granted scopes. Ask how long events are retained in the native console, whether they can be streamed or exported in near real time, and whether the export includes all fields or a reduced schema. Find out whether logs for service principals, API keys and OAuth grants are recorded in the same stream as interactive user sign-ins. Request documentation for each field and test with a controlled token in a non-production tenant. Record the answers in your detection specification so that a later vendor change is easy to assess.
How can we test T1528 rules without affecting production?
Test in a private cyber range or a non-production tenant that mirrors your log pipeline. Build a controlled scenario in which a test identity obtains a token from one client, then reuse is simulated from a different network path and client, with the expected legitimate refresh flows run alongside it. Measure whether the rule fires on the simulated misuse, whether it stays quiet on the known-good flows, and whether the alert contains the fields an analyst needs. Run the same tests after each parser or log schema change, and after each ATT&CK version update. Keep test identities isolated, use short token lifetimes where the platform allows, and schedule runs outside peak business hours. Document the expected results in a test plan so that results can be compared over time and shared with auditors.
Which ATT&CK mitigations should we rely on for T1528 besides detection?
The two mitigations ATT&CK most often maps to T1528 are User Training (M1017) and User Account Management (M1018). User Training helps staff recognize consent prompts, phishing lures that request application permissions, and unexpected sign-in notifications, which are common precursors to token theft. User Account Management covers how applications and accounts are granted scopes, how long tokens live, how service accounts are restricted, and how unused grants are removed. Both controls reduce the number of tokens that can be stolen and the damage a stolen token can do, but neither replaces detection. Review your mitigation coverage each time you update your ATT&CK mapping, and confirm the implementation with evidence such as policy exports, training records and access review results.
Who should own T1528 detection rules, and what can our team run on its own?
Ownership usually sits with the security engineering or SOC detection team, with identity administrators responsible for token lifetime, consent and scope settings. Your team can run the detection itself if it has administrative access to the identity and SaaS logs, a working log pipeline and someone who maintains the rules. External help is most useful for the planning and implementation stages: scoping log sources, writing rules against your chosen ATT&CK version, building the cyber range scenario and documenting results. DeployOpen implements, integrates and documents self-hosted open-source platforms in the client's own infrastructure, and runs security testing and private cyber ranges, but it does not issue audit reports or certifications. Any engagement is typically fixed-scope, with scope and deliverables agreed in writing before work starts.
How DeployOpen builds T1528 detections and range scenarios
DeployOpen plans T1528 detection work as a fixed-scope engagement with written deliverables, agreed before any rule is written. The first step is to pin the ATT&CK version the work targets, because releases can rename, deprecate or revoke techniques and sub-techniques. We record the version in every detection mapping, then check which data components the client's sources can actually provide for T1528, such as File Access, User Account Authentication and Application Log Content, and which platforms are in scope, such as containers, IaaS, the identity provider and the office suite. Gaps are written down as gaps. A detection that depends on a log source the client does not collect is a finding, not a silent omission. Clients should ask for this coverage matrix in the statement of work and confirm which owner signs off on it.
Rules are then built and tuned on the open-source stack the client has chosen, for example Wazuh, Security Onion, Zeek or Sigma-format rules converted for the client's SIEM. Tuning happens against the client's own logs over an agreed window, with each noisy pattern, such as legitimate service tokens rotated by automation, reviewed and either excluded with a documented reason or kept with a triage note. Purple team exercises then run in a private cyber range that mirrors the client's identity provider, container platform and cloud accounts, with the blue team unaware of the timing. Each exercise produces a record of what was expected, what fired, what was missed and which owner will close each gap. Retainers can cover re-testing after rule changes or platform upgrades. DeployOpen prepares this evidence for the client's compliance assessments but does not issue audit reports, attestations or certifications; independent auditors and certification bodies make those decisions.
