MITRE ATT&CK T1098.001 Account Manipulation: Additional Cloud Credentials: Detecting and Removing Persistence

An attacker who adds their own secret, certificate or access key to an identity you already trust gets a way back in that survives password resets, MFA changes and session revocation. MITRE ATT&CK tracks this as T1098.001 Additional Cloud Credentials, a sub-technique of T1098 Account Manipulation that sits in Persistence (TA0003) and Privilege Escalation (TA0004) on IaaS, identity provider and SaaS platforms. Most of the targets are non-human identities: Entra ID applications and service principals, AWS IAM users, and Google Cloud service accounts. This guide goes deeper than the parent technique page: the exact audit signals per platform, how to baseline credentials so an addition stands out, how to find and remove every added credential during an incident, and the tenant settings that stop most additions in the first place. It is for detection engineers, cloud and identity administrators and incident responders, and it contains no attack procedures.

Key takeaways

• The credential is new, the identity is not. T1098.001 hides inside an existing, trusted application or account, so inventory-based reviews that look for new identities miss it; you have to watch credential collections.
• Every platform logs the addition. Entra ID "Add service principal credentials" and "Update application - Certificates and secrets management", AWS CloudTrail CreateAccessKey, CreateLoginProfile and ImportKeyPair, and Google Cloud CreateServiceAccountKey and UploadServiceAccountKey are all admin audit events.
• Preventive settings exist and are underused. Entra app management policies, app instance property lock, Google Cloud key creation and upload constraints, and AWS policies limiting who can call CreateAccessKey remove most of the attack surface.
• Password resets do nothing here. Responders must enumerate and remove credentials on every identity the attacker could reach, then revoke sessions and tokens already issued with them.
• Baselines make the alert usable. Know which identities should ever gain a credential, through which pipeline, and of which type; everything else is a high-priority event.

What T1098.001 covers, and what the parent guide does not

ATT&CK v20 describes the sub-technique as adding adversary-controlled credentials to a cloud account to keep persistent access. The parent MITRE ATT&CK T1098 Account Manipulation Guide covers all seven sub-techniques at one row each. This page covers only the credential addition case, in enough depth to build detections and run a clean-up.

ATT&CK also notes the privilege escalation angle: an identity allowed to add credentials to another identity inherits that identity's permissions. Its example is an Entra ID Application Administrator adding credentials to a service principal that holds more powerful roles than the administrator does. That is why the set of principals who can manage application credentials matters as much as the set who hold Global Administrator.

Where it has been seen

• SolarWinds compromise (ATT&CK C0024): ATT&CK records that APT29 added credentials to OAuth applications and service principals, which extended the intrusion into cloud tenants.
• Cloud resource abuse: in the Storm-1283 OAuth Apps Abuse 2023, Microsoft reported that the actor added its own credentials to existing line-of-business applications as well as creating a new one, then used the app identities to deploy mining virtual machines. The customer-side lesson is an alert on credential additions to existing apps.
• Scattered Spider (ATT&CK C0027): ATT&CK records the group creating temporary federated credentials for fake users to obscure which AWS credential had been compromised.

Detection: the audit events per platform

Credential additions are control plane writes, so they appear in admin audit logs that are on by default or cheap to keep. The work is in routing them centrally and adding context.

Making the alerts precise

• Correlate both Entra entries: Microsoft's security operations guidance notes that application and service principal updates are written as two separate audit entries, so join them when investigating. It rates new credentials on existing applications as high risk and suggests alerting when additions happen outside normal workflows, use a credential type you do not use, or land on a non-SAML service principal.
• Use the shipped content: Microsoft lists a Sentinel analytic, "Alert when new app or service principal credentials added", and a Defender for Cloud Apps anomaly for unusual credential additions to OAuth apps. Hunt queries are in the KQL for Threat Hunting Guide.
• Caller is not target (AWS): a CreateAccessKey where the calling principal differs from the target user is rarer and more suspicious than a user creating their own key. A CreateLoginProfile on an identity that has only ever used the API is a strong signal.
• Watch where STS events land: AWS documents that requests to the STS global endpoint are logged in US East (N. Virginia), and regional endpoint requests in their own Region. A trail that does not cover all Regions can miss GetFederationToken calls.
• Follow the first use: a new credential followed within hours by sign-ins from a new IP range or autonomous system, or by new API patterns, is the strongest single indicator. For Entra, link the new key ID to service principal sign-in logs.

Baselining so additions stand out

Alerting on every credential event in a large tenant is noisy because legitimate rotation creates the same events. NHI Mgmt Group recommends a short baseline exercise before tuning:

1. Inventory credential holders: list every application and service principal with password or key credentials, every IAM user with access keys or a login profile, and every service account with user-managed keys, with counts, types and end dates.
2. Record the legitimate path: for each identity, note which pipeline, vault or team rotates its credential and from which principal. A rotation from that principal is expected; a rotation from anyone else is not.
3. Flag the ones that should never change: apps that authenticate only with a managed identity or federated credential, and AWS or Google Cloud identities with no keys today, should alert on any credential event at all.
4. Measure lifetimes: Microsoft recommends reviewing applications for credentials with long expiry. Our suggestion is to treat an Entra secret or AWS key older than your rotation policy as a hygiene finding and a new one with an unusually long lifetime as a detection.

The platform guides cover the inventory side in depth: the Entra ID Applications and Consent Guide, the AWS Access Keys Security Guide and the Google Cloud Service Account Keys Security Guide.

Prevention: settings that remove the attack surface

• Shrink who can add credentials: the Application Administrator and Cloud Application Administrator roles and application owner assignments in Entra ID, iam:CreateAccessKey in AWS and iam.serviceAccountKeys.create in Google Cloud are the real privilege boundary. Put the directory roles behind just-in-time activation and remove standing owners from high-privilege apps (ATT&CK M1026).
• Remove the need for secrets: managed identities, workload identity federation and IAM roles leave no long-term credential to add alongside. Microsoft recommends certificates or managed identities over client secrets. See the guide to replacing Google Cloud service account keys.
• MFA on sensitive API calls: ATT&CK M1032 suggests requiring MFA through IAM policy conditions for CreateKeyPair and ImportKeyPair.

Choosing what to do first

Responding to a confirmed or suspected addition

The response goal is to find every credential the attacker added, not only the one that triggered the alert. Use the Workload Identity Compromise Response Playbook for the wider process; the steps specific to T1098.001 are:

1. Preserve evidence: export the relevant Entra audit and service principal sign-in logs, CloudTrail events and Google Cloud Admin Activity logs before retention or attacker clean-up removes them. Record key IDs, thumbprints and end dates of every credential on affected identities.
2. Scope by the actor, not the alert: list every credential addition made by the same initiating principal, IP range or session across the whole tenant and organisation for the full window of compromise.
3. Remove unrecognised credentials: delete added Entra secrets and certificates, delete added Google Cloud keys, and for AWS deactivate the key first so you can confirm nothing legitimate breaks, then delete it. Delete unexpected login profiles and EC2 key pairs.
4. Kill issued sessions: credentials already exchanged for tokens keep working. AWS documents denying a specific federated user session with an explicit deny conditioned on aws:PrincipalArn or aws:userid, and adding the same deny to resource policies that allow the principal. In Entra, access tokens already issued to the app remain valid until they expire, so consider disabling the service principal while you clean up if the business can tolerate it.
5. Rotate the legitimate credentials too: if the attacker could read them, they are burned. Rotate from the approved pipeline only.
6. Close the door used: remove the role or ownership that allowed the addition, then apply the preventive settings above. Check for the sibling persistence types (roles, delegates, devices) using the parent guide.

For a key exposed rather than added, follow the Cloud Access Key Leak Playbook instead.

Measuring whether it works

• Alert coverage: percentage of tenants, AWS accounts and Google Cloud projects whose credential addition events reach the SIEM with a live, tested rule. Target 100 per cent.
• Unexplained additions: credential events not matched to an approved pipeline or change within one business day. Target zero.
• Secret-bearing identities: number of apps with client secrets, IAM users with access keys and service accounts with user-managed keys, trending down.
• Credential adders: number of principals able to add credentials to another identity, trending down.
• Time to remove: median time from an unexplained addition to removal of the credential and its sessions.

Common failure patterns

• Treating the password reset as the fix: resetting the compromised user leaves the secret it added to an app, and Entra app passwords also survive resets.
• Watching new apps only: rules that alert on application registration miss credentials added to existing, trusted apps, the pattern in the Storm-1283 OAuth Apps Abuse 2023.
• Single-Region trails: STS and IAM events missed because the trail does not cover the Region where they were logged.
• Disabling app passwords and stopping there: existing app passwords keep working until legacy authentication is blocked.
• Deleting the key but not the session: federation tokens and issued access tokens remain valid for their lifetime.
• Owners nobody reviews: application owners can manage the configuration of the apps they own, yet ownership is rarely included in privileged access reviews. See how to find and remove stale service principals in Entra ID.

Framework mapping

Practitioner checklist

• Route Entra ApplicationManagement audit events, all-Region CloudTrail IAM and STS events and Google Cloud Admin Activity logs to one SIEM.
• Alert on credential additions to existing apps and on caller-not-target CreateAccessKey and any CreateLoginProfile.
• Baseline which identities may gain credentials and through which pipeline principal.
• Turn on Entra app management policy restrictions for secrets and lifetimes, with caller exclusions for rotation pipelines.
• Review app instance property lock on apps created before June 2026.
• Disable app password creation and block legacy authentication with Conditional Access.
• Enforce Google Cloud key creation and upload constraints, with dated exceptions.
• Restrict CreateAccessKey, CreateLoginProfile and GetFederationToken to named automation roles in AWS.
• Add application owners and credential administrators to privileged access reviews.
• In every identity incident, enumerate and remove added credentials and revoke their sessions.

Standards and references

• MITRE ATT&CK: T1098.001 Account Manipulation: Additional Cloud Credentials
• Microsoft Learn: Microsoft Entra security operations guide for applications
• Microsoft Learn: Configure app management policies
• Microsoft Learn: Configure app instance property lock
• Microsoft Learn: Enforce Microsoft Entra multifactor authentication with legacy applications using app passwords
• AWS: Logging IAM and AWS STS API calls with AWS CloudTrail
• AWS: Disabling permissions for temporary security credentials
• Google Cloud: Restricting service account usage

Related NHI Mgmt Group resources: MITRE ATT&CK T1098 Account Manipulation Guide · Multi-Cloud Identity Guide · Identity Incident Response Playbook · How to find unused AWS IAM roles and access keys