{
	"id": "c605bd73-ad57-4c16-9b72-e5c22f549e40",
	"created_at": "2026-04-06T00:06:18.50279Z",
	"updated_at": "2026-04-10T03:22:00.622079Z",
	"deleted_at": null,
	"sha1_hash": "451326be9615fb846b2f18ea76c0925285cab76c",
	"title": "Compromised Cloud Compute Credentials: Case Studies From the Wild",
	"llm_title": "",
	"authors": "",
	"file_creation_date": "0001-01-01T00:00:00Z",
	"file_modification_date": "0001-01-01T00:00:00Z",
	"file_size": 580324,
	"plain_text": "Compromised Cloud Compute Credentials: Case Studies From the\r\nWild\r\nBy Dror Alon\r\nPublished: 2022-12-08 · Archived: 2026-04-05 20:08:15 UTC\r\nExecutive Summary\r\nCloud breaches often stem from misconfigured storage services or exposed credentials. A growing trend of attacks\r\nspecifically targets cloud compute services to steal associated credentials and illicitly gain access to cloud\r\ninfrastructure. These attacks could cost targeted organizations both in terms of unexpected charges for extra cloud\r\nresources added by the threat actor, as well as time required to remediate the damage.\r\nThis blog highlights two examples of cloud compute credentials attacks in the wild. While the initial access phase\r\nis important, we will focus on the post-breach actions executed during the attack, and share the flow of these two\r\nattacks against the cloud infrastructure. The attack flows show how threat actors abuse stolen compute credentials\r\nto pursue a variety of attack vectors (such as cryptomining, data theft, etc.) and abuse cloud services in unexpected\r\nways.\r\nTo detect the attacks described below, cloud logging and monitoring best practices as outlined by Amazon Web\r\nServices (AWS) and Google Cloud are essential, as they provide visibility into activity at the cloud infrastructure\r\nlevel. This emphasizes how important it is to follow Amazon Web Services and Google Cloud logging and\r\nmonitoring best practices.\r\nPalo Alto Networks helps organizations address security issues in the cloud with Cortex XDR for cloud, which\r\ndetects cloud attacks such as cloud compute credentials theft and Prisma Cloud, which manages identity\r\nentitlement with least privilege entitlements.\r\nKey Principle of Working in the Cloud\r\nBefore diving in, we should understand a very basic and important rule of working in the cloud. An entity, whether\r\na human or a compute workload, needs legitimate and associated credentials to access a cloud environment at the\r\ninfrastructure level. The credentials are used for authentication (to verify the entity’s identity) and authorization\r\n(to verify what the entity is allowed to do).\r\nAs a best practice, when a compute workload executes API calls in the cloud (e.g., to query a storage service), the\r\nworkload’s associated credentials should be dedicated only to it. They should also be used only by that workload\r\nor human, and not by anyone else.\r\nAs we will see in both examples, an important security principle that can help reduce risk in cloud compute\r\ncredentials attacks is least privilege access. In particular, this means that the privileges associated with those\r\nhttps://unit42.paloaltonetworks.com/compromised-cloud-compute-credentials/\r\nPage 1 of 9\n\ncredentials should be scoped down to the minimum set actually required by the code using them.This limits the\r\nactions an attacker can take when compute credentials are stolen.\r\nAttack Case 1: Compromised AWS Lambda Credentials Led to Phishing Attack\r\nAn attacker was able to execute API calls on the behalf of the Lambda function by stealing the Lambda’s\r\ncredentials. This allowed the attacker to execute multiple API calls and enumerate different services in the cloud\r\nenvironment, as shown in Figure 1. While most of these API calls were not allowed due to lack of privileges, the\r\nattack resulted in a phishing attack launched from a AWS Simple Email Service (SES) that the threat actor\r\ncreated.\r\nFigure 1. An attacker enumerating the cloud environment using a compromised Lambda function’s\r\ncredentials.\r\nThis phishing attack not only resulted in unexpected costs for the organization, it also exposed other organizations\r\nto extra risk as well.\r\nWhile the outcome of this attack caused substantial impact, it could have been greater. In this case the victim\r\ndidn’t have an active SES, but if they had, the attacker could have abused it to launch an attack on the victim’s\r\norganization or they could even have used a legitimate email account for the phishing attack.\r\nDue to the variety of cloud services used by organizations, it can be difficult to predict where a cloud attack will\r\nend. Going from cloud to phishing was not necessarily an expected path.\r\nAttack Flow\r\nAn attacker was able to exfiltrate the Lambda’s environment variables and export them into their attacking\r\nmachine (AWS_ACCESS_KEY_ID, AWS_SECRET_ACCESS_KEY, AWS_SESSION_TOKEN).\r\nAs the credentials were exfiltrated, the attack was launched with the following steps:\r\n\u003e WHOAMI - 2022-05-20T20:35:49 UTC\r\nhttps://unit42.paloaltonetworks.com/compromised-cloud-compute-credentials/\r\nPage 2 of 9\n\nThe attack started with the GetCallerIdentity command. This command is equivalent to whoami, as it provides\r\ninformation about the entity the credentials are associated with. From the response, the attacker can gain\r\nadditional information such as the account ID and the credentials type that was stolen. They cannot, however,\r\ndetermine anything about the privileges associated with the identity.\r\n\u003e Identify and Access Management (IAM) Enumeration - 2022-05-20T20:35:55 UTC\r\nThe next phase of the attack was an identity and access management (IAM) enumeration. IAM is considered to be\r\na crown jewel for an attack. By gaining access to IAM, an attacker can elevate permissions and gain persistence\r\non the victim’s account.\r\nThe IAM enumeration included two API calls, which were denied due to lack of permissions:\r\nListAttachedRolePolicies\r\nListRolePolicies\r\nIt is fair to assume that the attacker noticed the lack of permission and therefore terminated the IAM enumeration\r\nafter only two commands (possibly to avoid making unnecessary noise).\r\n\u003e General Enumeration 2022-05-20T20:39:59 UTC\r\nAfter failing to enumerate IAM, the attacker started an enumeration on different services in different regions. This\r\ntechnique is much noisier as the attacker is trying to learn the architecture of the targeted account and, more\r\nimportantly, gain access to sensitive information that could exist in the cloud account.\r\nSome of the main services and API calls that were executed were:\r\nStorage Enumeration\r\nListBuckets\r\nGetBucketCors\r\nGetBucketInventoryConfiguration\r\nGetBucketPublicAccessBlock\r\nGetBucketMetricsConfiguration\r\nGetBucketPolicy\r\nGetBucketTagging\r\nEC2 Enumeration\r\nGetConsoleScreenshot\r\nGetLaunchTemplateData\r\nDescribeInstanceTypes\r\nDescribeBundleTasks\r\nDescribeInstanceAttribute\r\nDescribeReplaceRootVolumeTasks\r\nhttps://unit42.paloaltonetworks.com/compromised-cloud-compute-credentials/\r\nPage 3 of 9\n\nNetwork Enumeration\r\nDescribeCarrierGateways\r\nDescribeVpcEndpointConnectionNotifications\r\nDescribeTransitGatewayMulticastDomains\r\nDescribeClientVpnRoutes\r\nDescribeDhcpOptions\r\nGetTransitGatewayRouteTableAssociations\r\nLogging Enumeration\r\nGetQueryResults\r\nGetBucketLogging\r\nGetLogRecord\r\nGetFlowLogsIntegrationTemplate\r\nDescribeLogGroups\r\nDescribeLogStreams\r\nDescribeFlowLogs\r\nDescribeSubscriptionFilters\r\nListTagsLogGroup\r\nBackup Enumeration\r\nGetPasswordData\r\nGetEbsEncryptionByDefault\r\nGetEbsDefaultKmsKeyId\r\nGetBucketReplication\r\nDescribeVolumes\r\nDescribeVolumesModifications\r\nDescribeSnapshotAttribute\r\nDescribeSnapshotTierStatus\r\nDescribeImages\r\nSES Enumeration\r\nGetAccount\r\nListIdentities\r\nGeneral Enumeration\r\nDescribeRegions\r\nDescribeAvailabilityZones\r\nDescribeAccountAttributes\r\n\u003e Backdoor 2022-05-20T20:43:22 UTC\r\nhttps://unit42.paloaltonetworks.com/compromised-cloud-compute-credentials/\r\nPage 4 of 9\n\nWhile failing to enumerate IAM, the attacker tried (unsuccessfully) to create a new user by executing the\r\nCreateUser command.\r\n\u003e From the Cloud to a Phishing Attack 2022-05-20T20:44:40 UTC\r\nAs most of the API calls during the enumeration resulted in permission denied, the attacker was able to\r\nsuccessfully enumerate SES. Therefore, the attacker launched a phishing attack by abusing the cloud email\r\nservice, which included executing commands such as VerifyEmailIdentity and UpdateAccountSendingEnabled.\r\n\u003e Defense Evasion 2022-05-20T23:07:06 UTC\r\nFinally, the attacker tried to hide some of his activities by deleting the SES identity by executing the\r\nDeleteIdentity command.\r\nAdditional Insights for Detection\r\nA very important indicator of compromise (IoC) for this attack was the IP address 50.82.94[.]112.\r\nAPI calls from the Lambda function are typically executed from its IP with the credentials (including\r\nAccessKeyId) that were generated for the Lambda. Therefore, every API call with that AccessKeyId is considered\r\nto be the Lambda function. However, during the attack, the threat actor was able to steal the Lambda's credentials,\r\nallowing the attacker to impersonate it.\r\nBecause of this, the IP is the key IoC as it is the way to detect that this is not the Lambda. The attacker was using\r\nthe stolen credentials to impersonate and execute API calls on behalf of the Lambda function, but they were doing\r\nso from an IP address that wasn't attached to the Lambda, nor did it belong to the cloud environment.\r\nAttack Case 2: A Compromised Google Cloud App Engine Service Account\r\nDeploying Cryptomining Instances\r\nAn attacker was able to steal the credentials for a Google Cloud App Engine service account (SA). There are many\r\nways that attackers can accomplish this that are not necessarily related to any vulnerability in the cloud service\r\nprovider. In many cases, for example, users store credentials in insecure locations or use easily guessed or brute-forced passwords.\r\nIn this case, the stolen SA was the default SA, which had a highly privileged role (Project Editor). This allowed\r\nthe threat actor to launch an attack that ended with the creation of multiple high-core CPU virtual machines (VMs)\r\nfor cryptomining purposes, as shown in Figure 2.\r\nhttps://unit42.paloaltonetworks.com/compromised-cloud-compute-credentials/\r\nPage 5 of 9\n\nFigure 2. An attacker abusing a compromised App Engine SA to allocate multiple cloud instances\r\nfor mining.\r\nWhen the threat actor launched thousands of VMs in the victim’s environment, it significantly increased their\r\nexpected costs. Even if someone had noticed an attack like this in their environment after a short period of time, it\r\nwould still have had a substantial cost impact.\r\nAttack Flow\r\nGoogle App Engine is a Google Cloud fully managed serverless platform, and the service account is the token.\r\nWhen the user creates an App Engine instance, the cloud provider creates a default SA and attaches it to the\r\ncreated App Engine.\r\nThis App Engine default SA has the editor role in the project. The editor role is highly privileged, which is a key\r\nfactor the attacker took advantage of. This role allowed execution of high-privilege API calls, such as the\r\nfollowing:\r\nCompute workload launch\r\nFirewall (FW) rule modification\r\nSA key creation\r\n\u003e Privilege Escalation 2022-06-16T12:21:17.624 UTC\r\nThe attack started with an attempt to escalate privileges. As mentioned above, by default the App Engine’s SA has\r\neditor permissions on the project. With these permissions, the attacker tried to add the compute/admin role by\r\nadding the following object into the IAM policy:\r\nAs we can see, the appspot in the SA domain prefix indicates this SA belongs to an App Engine service.\r\n\u003e Allow Any/Any 2022-06-16T12:21:29.406 UTC\r\nhttps://unit42.paloaltonetworks.com/compromised-cloud-compute-credentials/\r\nPage 6 of 9\n\nNext the attacker modified the FW rules on the project level. First, the attacker attempted to create a subnet\r\n(named default). Then, the attacker added the rule below into that subnet:\r\nThis action furthers the attacker’s goal of mining cryptocurrency. To enable unlimited cryptocurrency mining, the\r\nattacker removed any limitation on the networking level.\r\nIt is important to note the priority field. By setting this to zero, the attacker’s rule is set to the highest priority,\r\nmeaning it will take effect first in the order of the existing FW rules.\r\n\u003e An Army of Miners 2022-06-16T12:21:38.916 UTC\r\nOnce setup was complete, the main phase of the attack began, launching VMs in multiple regions.\r\nWhile the attacker could have created high CPU machines, in this case the attacker instead created a standard VM\r\n(e.g., n1-standard-2) equipped with four high performance GPUs (e.g., nvidia-tesla-p100):\r\nhttps://unit42.paloaltonetworks.com/compromised-cloud-compute-credentials/\r\nPage 7 of 9\n\nOverall, more than 1,600 VMs were created during this attack.\r\n\u003e Backdoor 2022-06-16T13:25:56.037 UTC\r\nThe attacker assumed the SA key used for the attack would be detected and revoked, and therefore created\r\nmultiple SA keys (for later usage) by executing the google.iam.admin.v1.CreateServiceAccountKey API call.\r\nAdditional Insights for Detection\r\nAs in the first case we discussed, the IP is an important IoC. In this case, the attack was launched from multiple\r\nIPs (nine different IPs overall), some of which were active Tor exit nodes.\r\nAgain, we expect the App Engine’s SA to be used from an IP within the cloud environment. It definitely should\r\nnot be used from a Tor exit node.\r\nFirewall rule modification is a common and popular technique used in attacks like these. Many organizations\r\nenforce network traffic rules that deny access to active mining pools, so attackers must modify firewall rules to\r\naccomplish their goals.\r\nhttps://unit42.paloaltonetworks.com/compromised-cloud-compute-credentials/\r\nPage 8 of 9\n\nLastly, by editing a network named default, the attacker tried to avoid detection. Unless this option is disabled, by\r\ndefault each new project is created with a default network. It seems the attacker was trying to take advantage of\r\nthis, thus avoiding having to create their own network.\r\nConclusion: Compute Token Theft Is a Growing Threat\r\nThe theft of a compute workload’s token is the common denominator for both cases we’ve discussed. While both\r\nexamples above involve serverless services, this attack vector is relevant to all compute services.\r\nIt is important to emphasize that this type of attack could occur from different attack paths – including application\r\nvulnerabilities or zero-day exploits such as Log4Shell – not only from misconfigurations or poor cloud security\r\nposture management (CSPM).\r\nTo handle such attacks, cloud audit logs are essential, both for detection and for investigation and response (IR).\r\nCloud audit monitoring is even more critical for serverless workloads where agents cannot be installed, thus\r\nmaking it harder to stop such attacks.\r\nLogging and monitoring best practices provided by AWS and Google Cloud give clear guidance for how to\r\nprevent such cases. The AWS GuardDuty service could also help with detecting and alerting on similar attacks,\r\nsuch as EC2 instance credentials used from another AWS account. An additional prevention method is to\r\nconfigure an interface endpoint policy for Lambda to limit the usage of Lambda only within a VPC.\r\nPalo Alto Networks customers receive protections from compute token theft with:\r\nCortex XDR for cloud, which provides SOC teams with a full incident story across the entire digital\r\ndomain by integrating activity from cloud hosts, cloud traffic, and audit logs together with endpoint and\r\nnetwork data.\r\nPrisma Cloud, which assists organizations in managing identity entitlement, addresses the security\r\nchallenges of managing IAM in cloud environments. Prisma Cloud IAM security capabilities automatically\r\ncalculate effective permissions across cloud service providers, detect overly permissive access, and suggest\r\ncorrections to reach least privilege entitlements.\r\nFind out how you can protect your organization from cloud environment attacks with Unit 42 Cloud Incident\r\nResponse services to investigate and respond to attacks and Cyber Risk Management Services to assess your\r\nsecurity posture before an attack takes place.\r\nLearn How to Detect Cloud Threats at Ignite ’22\r\nAttend the session “Unearth advanced threats using your network and cloud data,” at Palo Alto Networks Ignite\r\n’22, the security conference of the future, to find out how to detect compromised cloud compute tokens. Our\r\nresearchers will show you how to investigate and respond to cloud attacks with a live demonstration. Register\r\nnow!\r\nSource: https://unit42.paloaltonetworks.com/compromised-cloud-compute-credentials/\r\nhttps://unit42.paloaltonetworks.com/compromised-cloud-compute-credentials/\r\nPage 9 of 9",
	"extraction_quality": 1,
	"language": "EN",
	"sources": [
		"MITRE"
	],
	"references": [
		"https://unit42.paloaltonetworks.com/compromised-cloud-compute-credentials/"
	],
	"report_names": [
		"compromised-cloud-compute-credentials"
	],
	"threat_actors": [],
	"ts_created_at": 1775433978,
	"ts_updated_at": 1775791320,
	"ts_creation_date": 0,
	"ts_modification_date": 0,
	"files": {
		"pdf": "https://archive.orkl.eu/451326be9615fb846b2f18ea76c0925285cab76c.pdf",
		"text": "https://archive.orkl.eu/451326be9615fb846b2f18ea76c0925285cab76c.txt",
		"img": "https://archive.orkl.eu/451326be9615fb846b2f18ea76c0925285cab76c.jpg"
	}
}