{ "id": "0e67a058-7fc7-4f49-8f8c-062720a06a6a", "created_at": "2026-04-06T00:19:31.894804Z", "updated_at": "2026-04-10T13:11:18.832512Z", "deleted_at": null, "sha1_hash": "521330952c9e03e66643079d1f93f40908e6661d", "title": "Hacking with AWS: incorporating leaky buckets into your OSINT workflow", "llm_title": "", "authors": "", "file_creation_date": "0001-01-01T00:00:00Z", "file_modification_date": "0001-01-01T00:00:00Z", "file_size": 405832, "plain_text": "Hacking with AWS: incorporating leaky buckets into your OSINT\r\nworkflow\r\nBy Vasilios Hioureas\r\nPublished: 2019-09-12 · Archived: 2026-04-05 23:17:07 UTC\r\nPenetration testing is often conducted by security researchers to help organizations identify holes in their security\r\nand fix them, before cybercriminals have the chance. While there’s no malicious intent for the researcher, part of\r\nhis job is to think and act like a cybercriminal would when hacking, or attempting to breach, an enterprise\r\nnetwork.\r\nTherefore, in this article, I will review Amazon AWS buckets as an avenue for successful penetration tests. The\r\ncase study I’m using is from a reconnaissance engagement I conducted against a business. I will specifically focus\r\non how I was able to use AWS buckets as an additional avenue to enrich my results and obtain more valuable data\r\nduring this phase.\r\nNOTE: For the safety of the company, I will not be using real names, domains, or files obtained. However,\r\nthe concept will be clearly illustrated despite the lack of specifics.\r\nThe goal of this article is to present an alternative or an additional method for professionals conducting pen-tests\r\nagainst an organization. In addition, I hope that it may also serve as a warning for companies deciding to use AWS\r\nto host private data and a reminder to secure potentially leaky buckets.\r\nWhat is an AWS bucket?\r\nAmazon Simple Storage Service (S3) provides an individual or business the ability to store and access content\r\nfrom Amazon’s cloud. This concept is not new, however, because businesses use AWS buckets to not only store\r\nand share files between employees, but also host Internet-facing services, we have seen a wealth of private data\r\nbeing exposed publicly.\r\nThe types of data we have discovered range from server backups and backend web scripts to company documents\r\nand contracts. Files within S3 are organized into “buckets,” which are named logical containers accessible by a\r\nstatic URL.\r\nA bucket is typically considered public if any user can list the contents of the bucket, and private if the bucket’s\r\ncontents can only be listed or written by certain S3 users.\r\nChecking if a bucket is public or private is easy. All buckets have a predictable and publicly accessible URL. By\r\ndefault this URL will be either of the following:\r\ns3.amazonaws.com/[bucket_name]/\r\nor\r\n[bucket_name].s3.amazonaws.com/\r\nhttps://blog.malwarebytes.com/researchers-corner/2019/09/hacking-with-aws-incorporating-leaky-buckets-osint-workflow/\r\nPage 1 of 5\n\nPen-test workflow: hacking phases\r\nLet’s begin by talking about the first phase of a penetration test: reconnoissance. The purpose of this phase is to\r\ngather as much information about a target in order to build an organized list of data which will be used in future\r\nhacking phases (scanning, enumeration, and gaining access).\r\nIn general, some of the data which pen-testers hope to obtain during this phase is as follows:\r\nNames, email addresses, and phone numbers of employees (to be used for phishing)\r\nDetails of systems used by the business (domains, IPs, and other services to be enumerated in future\r\nphases)\r\nFiles containing usernames, passwords, leaked data, or other access-related items\r\nSpec sheets, contracts, vendor documents, infrastructure outlines, notes\r\nCustomer data (side channel compromise of a trusted third party can be just as valuable as the target\r\nthemselves)\r\nAlternate infrastructure\r\nhttps://blog.malwarebytes.com/researchers-corner/2019/09/hacking-with-aws-incorporating-leaky-buckets-osint-workflow/\r\nPage 2 of 5\n\nAll of the items above are examples of things we can and have found while scouring AWS buckets. But first,\r\nbefore we get into the information discovered, let’s talk about finding the buckets themselves and the role that an\r\nS3 bucket search can play in a pen-test.\r\nAn easy first step in any recon phase is to enumerate the primary domain via brute force hacking or any other\r\nmethod, looking to hopefully find subdomains which may be hosting services within a company. This is pretty\r\nstandard procedure, but a business does not always have all of its data or resources internally hosted. Often there\r\nare unofficial IPs that may be hosted offsite serving a secondary role to the primary business or possibly hosting\r\ndeveloper resources or even file storage.\r\nWhile the company’s internal services, such as mail, websites, firewalls, security, and documentation may be\r\nhosted within a subdomain, for several reasons there are still possibilities that offsite or separate servers are used\r\nby the company. For this reason, it is a good idea to expand your search, using not only Google hacks and\r\nkeywords to look for related services or domains.\r\nExternal resource example\r\nOnce specific example related to this was a PACS server data leak from one of UCLA’s medical centers. Now\r\nwhile this server was technically operated by a UCLA med centers, it was not an official service of UCLA, so to\r\nspeak.\r\nTranslation: This server was not part of the UCLA domain. It happened to be independently hosted by one of the\r\nresiding med center employees, yet in a more obscure way, it was still related to the company. This is an example\r\nof the sort of side channel opportunities available to criminals.\r\nFinding leaky buckets\r\nMoving forward, an Amazon S3 bucket is a prime example of one such “unrelated” service not directly tied to the\r\nbusiness’ infrastructure. My main purpose for introducing this is to give pen-testers a new hacking avenue in\r\naddition to Google hacks. Because although Google searching on a company can lead you to their AWS bucket, it\r\nis more effective to search the open buckets directly.\r\nThere are a number of tools that can be used to discover wide-open buckets. The one I’d like to highlight is the\r\nweb application Grayhat Warfare. Of all the tools I use, it is the most user friendly and most easily accessible.\r\nAs you can see below, it is quite intuitive:\r\nhttps://blog.malwarebytes.com/researchers-corner/2019/09/hacking-with-aws-incorporating-leaky-buckets-osint-workflow/\r\nPage 3 of 5\n\nLet’s take a look at this application and see how a pen-tester might try to use it to discover a bucket owned by an\r\norganization.\r\nThere are a few ways in which pen testers can uncover unsecured data at their companies. One is by searching for\r\nfilenames that you might expect to find from the target organization. For example, knowing some of the services\r\nor products the enterprise produces, you might search those specific product names, or company_name.bak.\r\nAdditionally, having completed some other recon, incorporating usernames in this search can lead to some results.\r\nIn general, this is the part of the process that requires all of the creativity and thinking outside of the box.\r\nHacking with AWS case study\r\nNow let’s dig into the case study to see these recon methods in action. In this specific case, the target was an\r\nentertainment company that produces content for the music industry. From some Google searching, I happened to\r\ncome across the fact that they developed an Android app. The app name in this case had no relation to the actual\r\ncompany name; these are exactly the discoveries needed to make to expand searches of leaky buckets.\r\nUsing the name of the app and searching it within Grayhat Warfare, I was lucky enough to find an AWS bucket\r\ncontaining a file with the name of the app. One important thing to note is that the bucket name and URL were also\r\ncompletely different and unrelated to the name of the company.\r\nThis unrelated naming scheme is often by design. Rather than creating an obvious name, business infrastructure\r\narchitects often name servers according to themes. You might see planets, Greek gods, Star Wars characters, or\r\nfavorite bands. This makes searching for services a bit more obscure for a hacker.\r\nOnce the app filename was found within a bucket, it was simply a matter of manually looking through the rest of\r\nthe files to verify if the bucket in fact belonged to the target organization. This eventuality led me to find even\r\nmore info to use for a deeper recon search.\r\nhttps://blog.malwarebytes.com/researchers-corner/2019/09/hacking-with-aws-incorporating-leaky-buckets-osint-workflow/\r\nPage 4 of 5\n\nOne amazing find on this server was actually a zip file with the app’s source code. This contained database IPs,\r\nusernames, and passwords. This is something that may never have been discovered using traditional recon\r\nmethods since the IP happened to be an offsite DreamHost account. It was completely untied to any of the\r\ncompany’s resources.\r\nOSINT standards plus AWS buckets = more data\r\nThe main point I wanted to illustrate from my test case is how hacking with AWS can be incorporated into the\r\npen-test workflow as an iterative fingerprinting cycle. Using Google hacks, Shodan, and social networks are a\r\nstandard for open source intelligence (OSINT). We use these traditional methods to gather as much data as\r\npossible, then once we have found as much as we can find, we can blast that data against bucket search tools to\r\nretrieve deeper info.\r\nFrom that point, pen-testers can restart the whole search process with this new data. Recon can often be recursive,\r\none result leading to another, leading to another. However, incorporating AWS bucket searching into your pen-test\r\nworkflow can provide data that may not have been obtained using the other methods.\r\nIf any readers have other hacking or search tools they have come across or alternative methods for recon, please\r\nfeel free to mention them below in the comments.\r\nAbout the author\r\nReverse engineer, software developer, malware analyst, smart city hacker, RF hacker, IOT exploit researcher.\r\nSource: https://blog.malwarebytes.com/researchers-corner/2019/09/hacking-with-aws-incorporating-leaky-buckets-osint-workflow/\r\nhttps://blog.malwarebytes.com/researchers-corner/2019/09/hacking-with-aws-incorporating-leaky-buckets-osint-workflow/\r\nPage 5 of 5", "extraction_quality": 1, "language": "EN", "sources": [ "MITRE" ], "origins": [ "web" ], "references": [ "https://blog.malwarebytes.com/researchers-corner/2019/09/hacking-with-aws-incorporating-leaky-buckets-osint-workflow/" ], "report_names": [ "hacking-with-aws-incorporating-leaky-buckets-osint-workflow" ], "threat_actors": [ { "id": "75108fc1-7f6a-450e-b024-10284f3f62bb", "created_at": "2024-11-01T02:00:52.756877Z", "updated_at": "2026-04-10T02:00:05.273746Z", "deleted_at": null, "main_name": "Play", "aliases": null, "source_name": "MITRE:Play", "tools": [ "Nltest", "AdFind", "PsExec", "Wevtutil", "Cobalt Strike", "Playcrypt", "Mimikatz" ], "source_id": "MITRE", "reports": null } ], "ts_created_at": 1775434771, "ts_updated_at": 1775826678, "ts_creation_date": 0, "ts_modification_date": 0, "files": { "pdf": "https://archive.orkl.eu/521330952c9e03e66643079d1f93f40908e6661d.pdf", "text": "https://archive.orkl.eu/521330952c9e03e66643079d1f93f40908e6661d.txt", "img": "https://archive.orkl.eu/521330952c9e03e66643079d1f93f40908e6661d.jpg" } }