An attacker who steals one session can lose it in an hour. An attacker who adds a second credential to the account can keep access for months. MITRE ATT&CK tracks this as Additional Cloud Credentials (T1098.001), a sub-technique of Account Manipulation. It maps to persistence and privilege escalation and applies to IaaS, Identity Provider and SaaS.
How attackers use it
MITRE says adversaries may add adversary controlled credentials to a cloud account to maintain persistent access to victim accounts and instances. The page gives specific cases:
- Azure and Entra ID. Adversaries may add credentials to service principals and applications, beside the legitimate ones. These include x509 keys and passwords. With sufficient permissions, there are several ways to do it, including the Azure Portal, the Azure command line interface and Azure or Az PowerShell modules. MITRE gives an example: an adversary with the Application Administrator role can add a new set of credentials to an application.
- SSH keys on IaaS. After gaining access through cloud accounts, adversaries may generate or import their own SSH keys, using the CreateKeyPair or ImportKeyPair API in AWS, or the gcloud compute os-login ssh-keys add command in GCP. This gives persistent access to instances without further use of the compromised cloud account.
- Access keys and passwords. The CreateAccessKey API in AWS or gcloud iam service-accounts keys create in GCP adds access keys. The CreateLoginProfile API in AWS adds a password for the management console.
If the target account has different permissions from the requesting account, the adversary may also escalate privileges.
These new credentials are long lived and may not depend on the original login. Resetting the stolen password does not remove them.
How to detect it
MITRE's strategy (DET0531) lists three analytics:
- Credentials such as keys, app passwords or x.509 certificates added to existing cloud accounts, service principals or OAuth apps, through portal or API, by non-standard identities or from unusual IP ranges.
- Cloud API use to create or import SSH keys or generate new access keys, for example CreateAccessKey, ImportKeyPair and CreateLoginProfile, from non-console access or unusual principals.
- Credential related changes in productivity apps, such as API key creation in Google Workspace, app tokens in Slack, or user level OAuth credentials in Microsoft 365.
The data source is the cloud control plane audit log. Alert on these specific event names in every account, and route them to a person. Credential creation is rare enough that most organizations can review each one.
After any suspected compromise, list credentials on the affected identities, not just the password. A clean password reset with a leftover access key is an open door.
How to reduce the risk
MITRE lists these mitigations:
- Use multi-factor authentication for user and privileged accounts. MITRE suggests considering MFA enforcement for the CreateKeyPair and ImportKeyPair API calls through IAM policies (Multi-factor Authentication).
- Remove unnecessary and abusable authentication mechanisms. In Entra ID, disable the app password feature unless it is required (Disable or Remove Feature or Program).
- Make sure low privileged users cannot add access keys to accounts. In AWS, prohibit calling the sts:GetFederationToken API unless it is required (User Account Management).
- Do not use domain administrator or root accounts for day to day work on unprivileged systems (Privileged Account Management).
- Limit access to critical systems with access controls and firewalls, and use separate VPCs where supported (Network Segmentation).
Check your own environment
- List access keys for every IAM user and service account. Which are old, unused or unowned?
- Which applications and service principals have more than one credential, and why?
- Who can create credentials? Is it limited to a small admin group?
- Are credential creation events alerted on?
With the AWS command line, these read-only calls help:
aws iam list-access-keys --user-name EXAMPLE_USER
aws iam get-access-key-last-used --access-key-id EXAMPLE_KEY_ID
Replace the example values with names from your account.
Try it yourself
Long lived keys are also the thing that leaks from code and build files. This demo shows how a secrets scan surfaces them.
Click through it at your own pace, or open it full screen.
Quick check
Why does resetting a compromised password not always end the intrusion?
The adversary may have added their own keys, passwords or certificates to the account, which keep working independently of the original password.
Which AWS API calls does MITRE name for adding access keys and console passwords?
CreateAccessKey for access keys and CreateLoginProfile for a console password. CreateKeyPair and ImportKeyPair cover SSH keys.
Sources
- MITRE ATT&CK, T1098.001 Additional Cloud Credentials: https://attack.mitre.org/techniques/T1098/001/
