What is it?
Additional Cloud Credential Persistence is an attack pattern in which new keys, certificates, secrets, or credentials are added to a compromised cloud identity. The learning goal is to identify the trust boundary being abused, the attacker’s sequence, and the telemetry that records it.
How it works in plain English
Use this three-part model to understand the attack without memorizing a tool name.
The control plane trusts an identity, API token, workload role, policy, image, or orchestrator request.
The attacker uses legitimate APIs or workload access to read secrets, alter permissions, create resources, or move data.
Cloud investigation is API-centric: identify the principal, credential type, source, method name, target resource, authorization decision, and follow-on calls.
Worked example: how the sequence may look
Access to or influence over the relevant AWS, Azure, GCP environment.
Trigger the condition that enables additional cloud credential persistence.
Cloud control-plane audit logs, identity events, API calls, and configuration history.
Baseline the affected identity, host, application, service, or protocol.
If successful, the attacker may continue with Cloud IAM Privilege Escalation. This is a possibility, not a guaranteed next step.
This is a defensive learning scenario. Real incidents vary, and the listed outcome is only one possible path.
Why do attackers use it?
Advance an objective associated with initial access / privilege escalation.
Exploit a weak control, unsafe default, exposed service, trusted relationship, or human decision.
Create access, gain privilege, evade defenses, steal information, or disrupt operations.
Prerequisites
Access to or influence over the relevant AWS, Azure, GCP environment.
Knowledge of the target’s technology, identities, configuration, or user behavior.
A weakness, misconfiguration, exposed interface, stolen secret, or social opportunity.
A path to observe success and continue toward the objective.
Attack path possibilities
Attack chains are not fixed. These links show common possibilities to investigate before and after this behavior.
Stolen credentials, tokens, or recovery paths control a cloud identity.
T1552 Cloud Access Key TheftLong-lived or temporary cloud API credentials are stolen and replayed.
Concept Server-Side Request ForgeryA server is manipulated into requesting internal or restricted destinations.
T1528 OAuth Consent PhishingA user grants a malicious app access to cloud data.
Permissions and role paths are abused for stronger privileges.
T1098.003 Additional Cloud Role PersistenceRoles or permissions are added to preserve privileged cloud access.
T1555.006 Cloud Secrets Store TheftSecrets are requested from a cloud vault or secrets-management service.
T1537 Cloud Snapshot TheftDisk, database, or machine snapshots are copied or shared to expose stored data.
Step-by-step attack flow
Reconnoiter the target and identify the exposed trust boundary.
Prepare the infrastructure, lure, input, credential, or payload required.
Trigger the condition that enables additional cloud credential persistence.
Confirm access or effect while attempting to avoid controls.
Use the result for follow-on access, execution, collection, movement, persistence, or impact.
Remove evidence, rotate infrastructure, or repeat against other targets.
MITRE ATT&CK mapping
ATT&CK is updated over time. Verify the live technique before operationalizing a detection.
Logs and artifacts
Cloud control-plane audit logs, identity events, API calls, and configuration history.
Container runtime, orchestrator audit, workload, registry, and network-flow telemetry.
Unusual role assumption, secret access, public exposure, or data-transfer activity.
Realistic log examples
These records use realistic field names and formats but synthetic organizations, users, addresses, and identifiers. A single event is not proof; correlate time, identity, source, target, and the resulting action.
Who called which AWS API, from where, with what session and MFA context.
{"eventTime":"2026-07-16T14:31:22Z","eventSource":"sts.amazonaws.com",
"eventName":"AssumeRole","awsRegion":"ap-south-1",
"sourceIPAddress":"203.0.113.48","userAgent":"aws-cli/2.17",
"userIdentity":{"type":"IAMUser","arn":"arn:aws:iam::111122223333:user/build"},
"requestParameters":{"roleArn":"arn:aws:iam::111122223333:role/Admin"},
"responseElements":{"credentials":{"accessKeyId":"ASIA...REDACTED"}}}Baseline the affected identity, host, application, service, or protocol.
Azure control-plane operation, caller, resource, correlation, and authorization result.
2026-07-16T14:32:16Z OperationName="Create or Update Role Assignment"
Category=Administrative ActivityStatus=Succeeded
Caller=build@corp.example CallerIpAddress=203.0.113.48
ResourceId=/subscriptions/0000.../providers/Microsoft.Authorization/roleAssignments/7c21...
CorrelationId=1a2c8432-1f10-4b38-a962-14577bb41d0eDetect rare combinations of source, target, action, timing, volume, and result.
Principal, API method, resource, caller IP, and authorization context.
{"timestamp":"2026-07-16T14:33:02Z",
"logName":"projects/acme-prod/logs/cloudaudit.googleapis.com%2Factivity",
"protoPayload":{"authenticationInfo":{"principalEmail":"build@acme-prod.iam.gserviceaccount.com"},
"methodName":"SetIamPolicy","resourceName":"projects/acme-prod",
"requestMetadata":{"callerIp":"203.0.113.48","callerSuppliedUserAgent":"gcloud/480.0"}}}Correlate identity, endpoint, network, application, and control-plane evidence across the sequence.
API verb, principal, source, resource, namespace, decision, and response code.
{"apiVersion":"audit.k8s.io/v1","stage":"ResponseComplete",
"requestURI":"/api/v1/namespaces/prod/secrets/db-admin",
"verb":"get","user":{"username":"system:serviceaccount:ci:runner"},
"sourceIPs":["10.24.18.77"],"objectRef":{"resource":"secrets",
"namespace":"prod","name":"db-admin"},"responseStatus":{"code":200}}Prioritize activity followed by successful access, privilege change, execution, or data movement.
- Who or what identity acted?
- From which device, process, IP, or workload?
- What target and operation were involved?
- Did it fail, succeed, or change state?
- What correlated event happened immediately before and after?
Detection logic / SIEM queries
Baseline the affected identity, host, application, service, or protocol.
Detect rare combinations of source, target, action, timing, volume, and result.
Correlate identity, endpoint, network, application, and control-plane evidence across the sequence.
Prioritize activity followed by successful access, privilege change, execution, or data movement.
FROM security_events
WHERE event_time > now() - 30m
AND behavior = "Additional Cloud Credential Persistence"
GROUP BY source, target, user
HAVING count(*) > baseline(source, target, user)
OR rare(action, source, target) = true
CORRELATE WITH success, privilege_change, execution, data_accessMitigations
Reduce exposed attack surface and remove unused services, identities, features, and trust relationships.
Apply least privilege, strong authentication, secure defaults, segmentation, and timely patching.
Validate untrusted input and independently authorize sensitive operations.
Centralize and protect relevant logs; test detections with controlled simulations.
Maintain a response playbook for containment, credential rotation, evidence preservation, and recovery.
Real-world examples
Additional Cloud Credential Persistence appears in opportunistic campaigns and targeted intrusions when the required condition exists.
Real incidents usually combine it with credential theft, phishing, exploitation, persistence, or exfiltration.
The best case studies describe the full attack chain rather than an isolated tool or indicator.
Common questions
01What makes Additional Cloud Credential Persistence possible?
A trust assumption fails: an identity, input, component, network message, user decision, or software relationship is accepted without enough verification.
02What should a defender collect first?
Start with logs closest to the decision point, then add identity, endpoint, network, and control-plane context.
03How should I study this attack?
Learn the concept, identify prerequisites, map observable steps, write a detection hypothesis, and validate it safely in a lab.