{
	"id": "e8867f37-831e-445c-9002-7c4f8dc2a009",
	"created_at": "2026-04-06T00:10:32.033711Z",
	"updated_at": "2026-04-10T03:21:25.73944Z",
	"deleted_at": null,
	"sha1_hash": "ffa94ca52a693ee7bcbbafde6cd9e993f75eeae6",
	"title": "Lesser Known Techniques for Attacking AWS Environments",
	"llm_title": "",
	"authors": "",
	"file_creation_date": "0001-01-01T00:00:00Z",
	"file_modification_date": "0001-01-01T00:00:00Z",
	"file_size": 629909,
	"plain_text": "Lesser Known Techniques for Attacking AWS Environments\r\nBy Clint Gibler\r\nPublished: 2020-01-15 · Archived: 2026-04-05 20:31:21 UTC\r\nThis post will discuss lesser known attack techniques that I would use in attacking AWS accounts and conclude\r\nwith a discussion of defenses. A common theme among many of these concepts is abusing trust, whether that is\r\nincorrectly trusting attacker controlled resources hosted on AWS, or the trust relationships between accounts or\r\nwithin an account.\r\nI’ll discuss a few techniques in gaining initial access, recon, lateral movement between accounts, and data\r\nexfiltration.\r\ntl;dr\r\nInitial access: Backdoor community resources (e.g. AMIs, CloudFormation templates, Lambda Layers,\r\netc.) or phish with Stack Sets.\r\nDefense: Consider using Infrastructure as Code scanning tools to enforce secure defaults and\r\nresources that are allowed to be used.\r\nRecon Abuse naming patterns to guess resource IDs (like S3 bucket names) or fingerprint existing roles or\r\nservices or vendors in use.\r\nDefense: Follow least privilege so that even resources with known names cannot be accessed unless\r\nneeded, and consider randomizing resource names.\r\nLateral movement: Abusing trust and privileges across accounts (IAM, network-level, etc.).\r\nDefense: Follow least privilege for cross account trust, assess if your cloud security posture has a\r\n\"soft center,\" that if an attacker gets inside it's game over.\r\nExfiltration: Share compromised resources to an account you control to speed exfiltration, or use DNS for\r\nstealthy exfiltration.\r\nDefense: Set up auto-remediation that will automatically unshare resources shared with unknown\r\naccounts, and turn on logging for any VPC DNS resolvers. If you want to have an isolated network,\r\nconsider running your own DNS resolver and disabling the one run by AWS.\r\nAbout the author\r\nMy name is Scott Piper and I do independent AWS security consulting through my company Summit Route,\r\nhelping in a variety of ways to improve the security of AWS environments for companies, primarily by providing\r\ntraining.\r\nhttps://tldrsec.com/p/blog-lesser-known-aws-attacks\r\nPage 1 of 8\n\nI’m often asked by red teams and pentesting companies what types of AWS attack techniques I would use. There\r\nare concepts from actual breaches and public techniques that I might use, but in this post I’ll discuss some\r\nadditional, possibly lesser known, concepts or slight adjustments to known techniques.\r\nInitial access\r\nThe idea of backdooring community AMIs was first mentioned at Black Hat 2009 by Nicholas Arvanitis, Marco\r\nSlaviero, and Haroon Meer in their talk “Clobbering the Cloud” (slides and video). I investigated a malicious AMI\r\nin 2018 that would do Monero mining, and there have been other reports of this issue.\r\nThis same concept though can be applied to other resources on AWS, such as CloudFormation templates,\r\nTerraform modules, CDK libraries, Lambda Layers, SSM documents, Serverless Application Repository\r\napplications, Marketplace resources, container base images, etc.\r\nThe concept here is to make one of these resources available for people to use that when used would provide you\r\nwith access to their account.\r\nAs part of AWS’s “shared responsibility model” AWS doesn’t seem to do any auditing of the resources in any of\r\ntheir “marketplaces”, meaning ways in which they host community generated resources.\r\nGetting people to run these might be a little difficult, but an attacker could attempt to target the supply chain by\r\ngoing after the owners of existing popular resources here. We’ve seen that in the world of Chrome browser\r\nextensions where the owners of popular extensions have been phished, or had their extensions purchased and then\r\nused to deploy adware. Other marketplaces have encountered similar issues, such as Ruby gems hijacked.\r\nThey may also be able to abuse aspects of how search and access works in the marketplace. For example, the\r\nMonero backdoored AMI I had investigated was able to find its way into a number of AWS accounts because the\r\nAWS CLI and other tooling did not require an owners flag be passed, which resulted in AWS randomly picking\r\nAMIs that matched the other attributes people specified. This flaw was registered as CVE-2018-15869.\r\nPhishing with Stack Sets\r\nWhen I do AWS security assessments for clients, I send them a link to a CloudFormation Stack Set. When they\r\nclick this link, they’ll be asked to log into their AWS account if they haven’t already. Then they’ll be prompted\r\nasking them if they want to create resources in their environment. This will create an IAM role that I can assume\r\ninto that has privileges for me to investigate their account. This makes it very easy for me to gain access to\r\naccounts to perform the work I need to do.\r\nAn attacker could use this same technique to trick someone into deploying a more privileged role, a backdoored\r\nEC2, or other badness. The URL is on the the domain us-east-1.console.aws.amazon.com and the referenced\r\nStack Set is hosted in an S3 bucket (here), so everything is on AWS domains and thus for an attacker’s goals, this\r\nappears trustworthy.\r\nBut again, due to the shared responsibility model, AWS doesn’t audit any of these.\r\nhttps://tldrsec.com/p/blog-lesser-known-aws-attacks\r\nPage 2 of 8\n\nStack set creation\r\nRecon\r\nAbusing naming patterns\r\nIan Mckay wrote a post titled S3 Bucket Namesquatting - Abusing predictable S3 bucket names where he talks\r\nabout how AWS and vendors frequently use naming patterns for their S3 bucket and how an attacker could abuse\r\nthis predictably by creating an S3 bucket that uses this naming pattern. This attack is also referred to as bucket\r\nsniping.\r\nIan avoided diving into the specifics of the attack, so to describe this issue further with an example, Athena by\r\ndefault uses the pattern aws-athena-query-results-ACCOUNTID-REGION . If an attacker knew your account ID, and\r\nyou hadn’t yet started using Athena, but planned on it, they could create an S3 bucket in their own account that\r\nmatched that pattern before you did, and either block you from using Athena by denying read/write access to that\r\nbucket, or they could open up read/write access to you on that bucket so you’d unknowingly be writing your\r\nAthena query results into the attacker’s bucket.\r\nhttps://tldrsec.com/p/blog-lesser-known-aws-attacks\r\nPage 3 of 8\n\nLuckily Athena encrypted the results, and around November 2019 they required you to create the bucket as\r\nopposed to just attempting to use it. It’s likely now with the new s3:ResourceAccount policy condition and the –\r\nexpected-bucket-owner API condition that opportunities to abuse this concept by creating a public bucket would\r\nbe reduced further.\r\nHowever, instead of abusing this concept by creating an S3 bucket, an attacker could abuse it for recon.\r\nFor example, let’s say the attacker compromises an EC2 that has an IAM role that allows s3:ListBucket and\r\ns3:GetObject on * . This would allow them to read any S3 buckets, but they would have to guess the names of\r\nthe buckets. This is an excellent place for someone to abuse these naming patterns.\r\nAs an example, AWS Config by default uses the S3 bucket config-bucket-ACCOUNTID . That data then records the\r\nnames of all the S3 buckets in the account. Therefore by knowing that one S3 bucket name and reading the\r\ncontents, the attacker could find out the names of all other S3 buckets in the account and read those, along with\r\nknowing all the other metadata in the account.\r\nThere are other S3 buckets with naming patterns that may be valuable, and there may also be other types of\r\nresources.\r\nService usage recon\r\nIn order to determine if AWS Config is being used, you can check for the role associated with it,\r\nAWSServiceRoleForConfig . If this has been setup from the Organization level, that role will be\r\nAWSServiceRoleForConfigMultiAccountSetup . If they run GuardDuty, there will be a role named\r\nAWSServiceRoleForAmazonGuardDuty .\r\nIt is possible to identify the existence of IAM roles in one account from another account by creating an IAM role\r\ntrust policy and attempting to reference a role in another account and seeing if it errors. This concept was first\r\ndiscovered by Daniel Grzelak and presented at Kiwicon in 2016 (video, slides, code and wordlist). That video is\r\nhilariously bad filming as it was done via a cellphone from someone in the audience and broken up into 6-minute\r\nclips. This concept is more thoroughly explained in Spencer Gietzen’s post Unauthenticated AWS Role\r\nEnumeration (IAM Revisited) and is incorporated into pacu.\r\nOnce you identify that certain AWS services, vendors, or maybe just popular CloudFormation templates have been\r\ndeployed in an account, it may help you narrow in on resources associated with those that use default names or\r\nnaming patterns. By knowing those services are used in advance, you could avoid having Access Denied errors\r\nrecorded in CloudTrail, which are more likely to generate alarms.\r\nLateral movement between accounts\r\nCompanies are creating more and more AWS accounts for themselves, in large part due to separate accounts being\r\na strong security boundary. However, they then interconnect those accounts heavily, which can blur or erase those\r\nsecurity boundaries.\r\nIf an attacker had admin access inside one account, they could look to see what accounts it knows about and if\r\nthey can access them. They could use CloudMapper’s weboftrust command to try to figure some of this out. That\r\nhttps://tldrsec.com/p/blog-lesser-known-aws-attacks\r\nPage 4 of 8\n\ncommand is mostly for finding what accounts the account being assessed trusts to access it though, and not which\r\nexternal accounts trust it.\r\nKnowing who trusts your account can be valuable though. CloudMapper’s weboftrust and the AWS service\r\nAccess Analyzer can show which resources in my account are trusted by other accounts and I would like to extend\r\nthis further, looking at things like shared AMIs etc.\r\nFor an attacker, this could enable RCE into the other accounts. For example, I’ve seen one company where they\r\nhad an S3 bucket that hosted a bash script that every EC2 at the company was supposed to run at boot. So if you\r\nmodified that bash script you’d get RCE on every EC2 across every account at the company.\r\nAn attacker could look at the IAM privileges in an account to see if they are granted access to other accounts.\r\nThey could also look in CloudTrail logs, specifically CloudTrail Event History (since that can be accessed even if\r\nthe S3 bucket where logs might be sent can’t be), and look to see where things in the compromised account are\r\nassuming roles to. This is discussed further in my post Lateral movement between AWS accounts - Abusing trust\r\nrelationships.\r\nAn attacker could look at what resources are referenced from one account, but aren’t part of that account. For\r\nexample, companies frequently have CloudTrail logs all sent to a single S3 bucket. Sometimes those companies\r\nthen make those logs easily accessible to all accounts, by having a bucket policy that includes a condition such as:\r\n\"Condition\" : { \"ForAnyValue:StringLike\" : {\r\n \"aws:PrincipalOrgPaths\":[\"o-a1b2c3d4e5/*\"]\r\n}}\r\nThis will likely allow you to read the CloudTrail logs for not only your own account, but all AWS accounts that\r\nare part of the organization. Using these logs, an attacker could start to understand the other AWS accounts.\r\nAn attacker could look at networking trusts, such as transit gateway, VPC peering, etc. to see what networks trusts\r\nthe compromised account to again move laterally.\r\nFrom the concepts above, an attacker should have identified other AWS accounts in the organization. Often\r\norganizations will grant trusts between other AWS accounts within the organization such that an attacker could\r\nattempt to brute force assume into IAM roles in the other accounts.\r\nSpencer Gietzen discussed the idea of brute-forcing IAM roles that were publicly accessible in his post Assume\r\nthe Worst: Enumerating AWS Roles through ‘AssumeRole’, but this technique would be more effective for\r\nattempting to move laterally between the accounts in an organization.\r\nData exfiltration\r\nResource sharing\r\nOnce an attacker identifies resources of interest, it is often in their best interest to get that data out of the account\r\nas quickly as possible because remaining inside the account increases the likelihood of their detection.\r\nhttps://tldrsec.com/p/blog-lesser-known-aws-attacks\r\nPage 5 of 8\n\nIn order to move the data out of the account as quickly as possible, sharing the resources to another account is a\r\ntechnique that can be used.\r\nFor example, if an attacker finds a lot of RDS snapshots, instead of attempting to spin up an RDS inside the\r\naccount, they could share those snapshots to another account. It is advantageous to an attacker to have other victim\r\nAWS accounts for this purpose, which could potentially be obained using the concepts of “Backdooring\r\ncommunity resources” discussed earlier.\r\nI’ve heard the idea of making the resources public for this purpose, but I believe that increases the likelihood of\r\nthe activity being detected, because it is more common to identify resources being made public than being shared\r\nwith another account. Finding a resource is public is likely to be a high severity alert, but finding it shared with an\r\nunknown account is likely to be lower severity.\r\nDNS\r\nCompanies that try to control their network traffic often overlook the VPC DNS resolver. In my post on Isolated\r\nnetworks on AWS I discussed how this can be abused to exfiltrate data in environments that have restricted\r\nnetwork traffic.\r\nSince I wrote that post, AWS has now made those logs accessible, but I believe it is still fairly rare for companies\r\nto be recording those.\r\nDefenses\r\nInitial Access\r\nThe initial access section discusses ways of abusing community resources. Having Infrastructure as Code\r\nprocesses where code can be reviewed by another person can help. That code can also be scanned by static\r\nanalysis tools.\r\nThe Stack Set phishing concept could be mitigated by blocking all CloudFormation scripts except for ones that\r\ncome from buckets you own, by using a policy such as the following:\r\n{\r\n \"Version\":\"2012-10-17\",\r\n \"Statement\":[\r\n {\r\n \"Effect\" : \"Deny\",\r\n \"Action\" : [ \"cloudformation:CreateStack\", \"cloudformation:UpdateStack\" ],\r\n \"Resource\" : \"*\",\r\n \"Condition\" : {\r\n \"ForAllValues:StringNotLike\" : {\r\n \"cloudformation:TemplateUrl\" : [ \"https://s3.amazonaws.com/mybucket/*\" ]\r\n }\r\n }\r\n }\r\nhttps://tldrsec.com/p/blog-lesser-known-aws-attacks\r\nPage 6 of 8\n\n]\r\n}\r\nRecon\r\nThe idea of abusing naming patterns is best mitigated by practicing a least privilege strategy to ensure that even\r\nresources with known names cannot be accessed. There may also be some benefit in vendors and those creating\r\npopular resources to take steps to randomize some of their names. AWS especially should consider this.\r\nLateral movement\r\nThe concepts for moving laterally are also best mitigated through least privilege strategies for the cross account\r\ntrusts. You should also consider the threat of what happens when an attacker compromises one of your AWS\r\naccounts and whether you have a “soft center” security model where onces something gets inside, it becomes\r\ninherently trusted.\r\nData exfiltration\r\nFor data exfiltration, the idea of sharing resources is best mitigated by having auto-remediation solutions that can\r\nunshare resources that are being shared with unknown accounts, and followed up quickly by incident responders.\r\nThis autoremediation solution and incident response roles should be protected by Service Control Policies (SCPs)\r\nso that an attacker could not disable those.\r\nAWS should expand Access Advisor’s coverage to all resources that can be shared or made public so that people\r\nwould be more motivated to use that service and integrate it into things. Currently that service is limited, with\r\ncoverage for only about 6 resource types when I believe there are at least 24 (see my aws_exposable_resources\r\nrepo).\r\nFor data exfiltration via DNS, you should turn on logging for any VPC DNS resolvers. This may help you detect\r\ntechnique being used, but if you want to have an isolated network, you should look into running your own DNS\r\nresolver and disabling the one run by AWS.\r\nTooling we need\r\nI believe there is still a lot that can and should be done to understand the interconnections between accounts and\r\nI’d love to see more tooling there.\r\nPrimarily, I’d like to better visualize these trust relationships, and do so for all the various resource types that can\r\nbe configured for these trusts. If Access Advisor gets better resource coverage, people could build on the data from\r\nthat service.\r\nI’ll close with one of my favorite quotes about AWS security, which comes from Marco Slaviero in 2017😀 \r\n“The number of known attacks against AWS is small, which is at odds with the huge number (and complexity) of\r\nservices available. It’s not a deep insight to argue that the number of classes of cloud specific attacks will rise.”\r\nhttps://tldrsec.com/p/blog-lesser-known-aws-attacks\r\nPage 7 of 8\n\nMarco Slaviero\r\nEditor’s note: Scott is one of my favorite people to follow for the latest and greatest in AWS security. I highly\r\nrecommend checking out his blog or training if you want to level up your AWS skills. He also created flaws.cloud,\r\nan interactive tutorial/CTF for learning common AWS security mistakes.\r\nSource: https://tldrsec.com/p/blog-lesser-known-aws-attacks\r\nhttps://tldrsec.com/p/blog-lesser-known-aws-attacks\r\nPage 8 of 8",
	"extraction_quality": 1,
	"language": "EN",
	"sources": [
		"MITRE"
	],
	"references": [
		"https://tldrsec.com/p/blog-lesser-known-aws-attacks"
	],
	"report_names": [
		"blog-lesser-known-aws-attacks"
	],
	"threat_actors": [],
	"ts_created_at": 1775434232,
	"ts_updated_at": 1775791285,
	"ts_creation_date": 0,
	"ts_modification_date": 0,
	"files": {
		"pdf": "https://archive.orkl.eu/ffa94ca52a693ee7bcbbafde6cd9e993f75eeae6.pdf",
		"text": "https://archive.orkl.eu/ffa94ca52a693ee7bcbbafde6cd9e993f75eeae6.txt",
		"img": "https://archive.orkl.eu/ffa94ca52a693ee7bcbbafde6cd9e993f75eeae6.jpg"
	}
}