# Using Honeybuckets to Characterize Cloud Storage Scanning in the Wild

Katherine Izhikevich, Geoffrey M Voelker, Stefan Savage, Liz Izhikevich

<figure><img src="image_1.png" /></figure>

## To cite this version:

Katherine Izhikevich, Geoffrey M Voelker, Stefan Savage, Liz Izhikevich. Using Honeybuckets to Characterize Cloud Storage Scanning in the Wild. 2023. hal-04303613

HAL Id: hal-04303613

https://hal.science/hal-04303613v1

Preprint submitted on 23 Nov 2023

HAL is a multi-disciplinary open access archive for the deposit and dissemination of scientific research documents, whether they are published or not. The documents may come from teaching and research institutions in France or abroad, or from public or private research centers.

L'archive ouverte pluridisciplinaire HAL, est destinée au dépôt et à la diffusion de documents scientifiques de niveau recherche, publiés ou non, émanant des établissements d'enseignement et de recherche français ou étrangers, des laboratoires publics ou privés.

<figure><img src="image_2.png" /></figure>

Distributed under a Creative Commons CC BY 4.0 - Attribution - International License
# Using Honeybuckets to Characterize Cloud Storage Scanning in the Wild

Katherine Izhikevich
UC San Diego

Geoffrey M. Voelker
UC San Diego

Stefan Savage
UC San Diego

Liz Izhikevich
Stanford University

## Abstract

In this work, we analyze to what extent actors target poorly-secured cloud storage buckets for attack. We deployed hundreds of AWS S3 honeybuckets with different names and content to lure and measure different scanning strategies. Actors exhibited clear preferences for scanning buckets that appeared to belong to organizations, especially commercial entities in the technology sector with a vulnerability disclosure program. Actors continuously engaged with the content of buckets by downloading, uploading, and deleting files. Most alarmingly, we recorded multiple instances in which malicious actors downloaded, read, and understood a document from our honeybucket, leading them to attempt to gain unauthorized server access.

## 1 Introduction

This paper explores a simple but poorly understood question: *to what extent is insecure cloud storage actively targeted for attack?*

Storage in the cloud, such as Amazon Simple Storage Service (S3) and Google Cloud Storage, provides reliable, available, and elastic storage on demand to virtually anyone with the means to pay. Moreover, it is extremely easy to deploy. A client need only choose a name for their storage “bucket” and specify its access control list, before it is ready to serve files. This ease of use has made such services extremely popular; in 2021, Amazon’s S3 service hosted more than 100 trillion files on behalf of its users [64]. However, this same flexibility has given rise to new risks. The confidentiality of each bucket is not governed by traditional enterprise security mechanisms, but by the correct configuration of individual access control settings by the bucket operator. Thus, if a bucket is misconfigured to be public, then any party guessing its *name* may gain access to all of its sensitive content. In 2018, Ero [74] found that unsolicited parties were indeed guessing the names of public storage buckets. Shortly after, a survey of almost 200,000 buckets revealed that 10%

contained sensitive data, including passports and financial records [69].

However, it remains unclear how scanners find such buckets and how many of these are targeted in actual attacks. To put it another way: is this merely an abstract risk, or are concrete threat actors actively searching for such vulnerabilities and exploiting them in the wild? While more than a few high profile breaches have been publicly attributed to misconfigured cloud storage [33, 43, 50, 58–60], none have documented how these attacks took place, nor the mechanism by which attackers identified the opportunity. Indeed, scanning for buckets is non-trivial as an attacker must correctly guess the bucket’s full name; the potential search space of these names is $10^{62}$ times larger than IPv6 and no public repository of buckets-in-use exists. The names of misconfigured buckets must therefore either be guessed, or found in an unrelated passive data source (e.g., DNS).

In this work, we empirically analyze this question by deploying a range of “honeybuckets” on the AWS S3 platform, configured with names, permissions, and content to lure and measure different scanning strategies. By modulating how our buckets are named and whether they are leaked to other data sources, we have been able to identify the most widely used strategies employed by third-parties to scan for misconfigured buckets. We identify that there are clear preferences for scanning particular kinds of organizations, notably commercial entities in the technology sector. Moreover, while we find that it is common for all such actors to hide behind proxy servers, we show how to automatically group seemingly disparate IP addresses by dynamically modulating file-name content to create causal dependencies between metadata and attempts to access individual files.

To distinguish between potential benign actors who may be scanning to help notify vulnerable parties [26] (or at least to try to sell a subscription to such a security scanning service) and those who have malicious aims, we further configured our honeybuckets to create multiple opportunities for actors to engage in clearly malicious acts. First, we configure our buckets to allow actors to delete or upload data.
We consider users who delete data or upload content that is designed to gain unauthorized access (i.e., to compromise a user who interacts with it and spawn a reverse shell) to be malicious. Second, we create lures whose value requires one to affirmatively violate a security norm (i.e., an unauthorized login to a third-party server exploiting an ssh credential extracted from one of our buckets). We show that all of these behaviors occur in our data.

In summary, we provide strong empirical evidence that shows how unsecured data on cloud storage is exploited today. While many targeted scans may reflect benign security interests, there is a range of malicious activity targeting commercial data. We conclude with a range of recommendations for how organizations might better protect such cloud assets in practice.

## 2 Background and Related Works

Cloud storage mimics a traditional file system interface. Files are stored in a file directory structure, with the top level directory referred to as a “bucket.” Buckets are simple to create: a client must, at minimum, (1) choose a service-wide globally unique name that is 3–64 alphanumeric-symbolic characters long and (2) configure the bucket contents to be private (the default option) or publicly accessible. Once a bucket is created, it is accessible via the cloud provider’s API, cloud browser interface, or through a cloud-specific subdomain (e.g., mybucket.s3.amazonaws.com). A user with sufficient access can upload an unlimited number of files and delete files, among other bucket operations [9].

Once a bucket is accessible (i.e., its access controls allow public access), a third-party must know its name to access it. There is no mechanism for enumerating names, nor any public repository of bucket names (public or otherwise). Thus, any party who does not possess a priori knowledge of a bucket’s name must either guess it – from a potential namespace of roughly $10^{101}$ possibilities – or find it in another data source.

An attacker seeking to narrow the search space for guessing such names—to find and sell stolen data, for example [59]—can use one of several scanning methodologies. The simplest bucket scanners rely on a pre-defined list of strings and patterns (e.g., Slurp [66], s3enum [91], and BucketStream [83]), tailored towards targeting likely-popular bucket names. Similar to password guessing software, bucket scanners generate target names by mechanically combining dictionary words, technology terms, etc.

However, not all bucket names will be simple or use popular words—for example, a number of applications generate random bucket names (e.g., project ids) for intermediate storage [56]. Continella et al. show that some such names can be identified using passive DNS collection services [71] (i.e., where another party exposes the name via their DNS lookups) and Cable et al. generalize this idea by showing

that such data can be used to train a machine learning model to generate a large set of valid names [69].

Such approaches have been used by the research community to explore the storage bucket ecosystem and empirically establish the widespread existence of misconfigured buckets. Indeed, both Continella et al. [71] and Cable et al. [69] found thousands of public buckets that exposed sensitive data, including private keys and national defense documents. Ero [74] and Cable et al. further deployed empty storage buckets to establish the existence of online bucket scanning behavior. However, while both found evidence of unsolicited scans, neither investigated the method by which names were targeted, nor the actions taken once such buckets were found. We are the first to demonstrate how public storage buckets are attacked (i.e., when actors delete, modify, upload, and exploit content) in the wild.

Overall, attacks on cloud storage have been relatively understudied, especially when compared to the broad literature characterizing active attacks on other infrastructure namespaces such as the IPv4 address space [63, 68, 78], IPv6 address space [65, 87, 95], cloud compute services [77, 79, 90, 98], DNS [62, 88, 93], and BGP [70, 72, 76, 97]. In these other environments, researchers have also used honeypots—infrastructure deployed for the purpose of detecting malicious behavior [80]—to characterize IPv4 scanning [31, 46, 85], email security [82] and DNS activity [84]. Our work brings this approach to the cloud storage context, particularly in service to understanding more about the nature of unsolicited visitors—how they target victims and the extent to which they reveal clear malicious intent.

## 3 Pilot study: How Buckets Are Targeted

This section describes our pilot<fnref n="1" /> experiment to broadly understand how, and to what extent, buckets are targeted for attack. Using a deployment of more than one hundred honeybuckets over a period of six months, we show that exploitation of misconfigured buckets is very real: hundreds of IP addresses attempted to download, delete, or upload objects—including malicious shell scripts. Notably, the first honeybucket was scanned only 40 minutes after deployment. Buckets named after companies, universities, and government organizations were scanned and attacked the most, implying that actors intentionally scan for specific targets.

### 3.1 Methodology

To understand how actors scan and interact with sensitive bucket content, we deployed 112 unique buckets (i.e., “honeybuckets”) on the AWS S3 platform on February 18, 2022, and hosted them for 6 continuous months. We configured the

<footnote n="1">¹We use the results of the pilot study to inform a refined experiment in Section 4.</footnote>
bucket names, permissions, and contents to attract bucket-
scanning actors that use various scanning strategies to find
public buckets. We focused only on the AWS S3 platform,
as prior work found that AWS S3 receives the largest amount
of unsolicited scanning traffic [69]. We do not use AWS de-
coy resources [89], as these decoys neither provide bucket
naming schemes nor sample content.

**3.1.1 Bucket Names**

Scanning buckets is not a trivial task. The enormous search-
space of bucket names is too large to exhaustively enumerate.
Thus, actors must employ directed strategies for scanning for
public buckets. We used five approaches to name buckets,
each designed to measure a unique bucket-scanning strategy.
We list all bucket names in the Appendix in Table 11.

**Target Generated Buckets.** To increase the success rate of finding public buckets, actors can use an open-source tool to discover commonly-named S3 buckets. These tools generate their scanning targets using target generation algorithms (TGAs), a method that uses a pre-defined list of strings and patterns—often common bucket names—and optionally concatenates them with a user-provided list of keywords.

To measure if actors use open-source tools to find buckets,
we named 12 of the 112 buckets with names generated by
three of the most popular bucket enumeration tools found on
Github and Pastebin—Slurp [66], DNSpop [67], and bucket-
stream-permutation-feature [83].<fnref n="2" /> To identify an actor’s use
of a particular enumeration tool, we computed the disjoint
set of target names that belong to each tool—and not to any
other—to create a set of honeybucket names that are likely to
be found by one—and only one—to tool. We chose four unique
bucket names from each disjoint set, for a total of 12 buckets
covering the three tools. To act as a control group, we cre-
ated four additional buckets named with strings that did not
appear in any of the bucket enumeration tools. Crucially, all
chosen target names were a part of a fixed set of names that
the TGA scans, no matter if the user provides the keyword;
it is not clear if this is a bug or a feature of the TGAs.

**Company, University, and Government Buckets.** Rather than only scanning for popular bucket names, an actor might curate a list of names that target a specific entity. To detect whether actors explicitly search for buckets named after organizations, we named 48 of the 112 buckets after the names of companies (Tesla, Walmart, Tinder), government organizations (FBI, CIA, NYPD) and universities (UCSD and Stanford). We concatenated each of the eight organizations with six unique keywords that appeared in a subset of the bucket enumeration tools. The six unique keywords consisted of three sensitive (“hidden”, “private”, “security”)

and three non-sensitive (“production”, “download”, “pub-
lic”) keywords, to additionally measure if a sensitive bucket
name influences the type of organizational bucket scanners
search for.

**Cryptocurrency Buckets.** If an actor targets specific con-
tent, rather than a specific entity, they might scan for buck-
ets named after the content. To detect actors who may be
searching for buckets storing cryptocurrency, we named four
of the 112 buckets after two cryptocurrencies: Bitcoin and
Ethereum. At the time of our experiment, many variations of
“bitcoin” and “ethereum” bucket names already existed, so
we hyphenated the names of the cryptocurrencies with key-
words found in the most popular bucket enumeration tools
(e.g., “bitcoin-confidential”).

**Sensitive and Non-Sensitive Buckets.** To search for sensitive content, but not restrict oneself to a specific entity or content-type, an attacker might scan for bucket names with sensitive keywords. To compare the discovery rate of buckets named after sensitive keywords (e.g., “passport” and “bank”) to non-sensitive keywords (e.g., “pictures” and “pretty”), we named four of the 112 buckets using each of these keywords.<fnref n="3" /> At the time of our experiment, bucket names with only the keyword already existed, so we hyphenated all sensitive and non-sensitive keywords with a non-sensitive keyword found in the most popular bucket enumeration tools (“10”).

**Leaked-Alphanumeric Buckets.** Rather than blindly guessing names, an actor might harvest bucket names from client activity (e.g., DNS queries) to increase the likelihood of discovering buckets. To measure if scanning actors are harvesting names, we assigned 40 out of the 112 honeybuckets with “unlikely-guessable” names: randomly generated alphanumeric names of length 16 (e.g., “q81osr2ba5wnid4g”). To identify potential sources of leaked buckets, we leaked 20 of our 40 unlikely-guessable honeybuckets across a variety of platforms, including a Github repository, a new Pastebin repository, a single tweet on a new Twitter account, and the HTML of an academic website (but not visible in a browser). We leaked two buckets at a time on each platform to verify whether a scanner likely guessed the bucket by chance (i.e., visited only one bucket) or likely found the bucket on the leaked platform (i.e., visited both buckets). To identify if scanners used passive DNS as sources for bucket names, we also queried the domains of two unlikely-guessable honeybuckets across DNS resolvers: two resolvers operated by Google, two by Spectrum, two by AT&T, two by a Russian ISP (ASN 12714), and two by a Chinese ISP (ASN 4134). Finally, to identify if scanners, such as Google bots, unsolicitedly download content from bucket names found in email, we saved two unlikely-

<footnote n="2">²We also considered s3enum [91] and s3Mining [94], but after compar-
ing outputs we found that their generated bucket names were proper subsets
of the other TGAs.</footnote>

<footnote n="3">³We used sensitive keywords defined by the U.S. Justice Depart-
ment [55] and non-sensitive keywords defined by the disjoint set of those
sensitive keywords and the top 1000 most common English words [1].</footnote>
<table><caption>Table 1: **Honeybucket File Contents**—Each honeybucket hosted nine unique files that contained a variety of sensitive names and content, intended to attract scanning actors with different target preferences.</caption><thead><tr><th>File name</th><th>Content</th><th>Unique IPs</th><th>Unique ASNs</th><th>Downloads</th></tr></thead><tbody><tr><td>Client_list_Dec_2021</td><td>Fake names, SSNs, addresses</td><td>88</td><td>56</td><td>160</td></tr><tr><td>Backup.pst</td><td>Sensitive mail folder names</td><td>69</td><td>47</td><td>155</td></tr><tr><td>README1</td><td>AAA...</td><td>64</td><td>41</td><td>127</td></tr><tr><td>Outlook.pst</td><td>Sensitive mail folder names</td><td>54</td><td>34</td><td>110</td></tr><tr><td>README2</td><td>Empty File</td><td>53</td><td>32</td><td>112</td></tr><tr><td>id_ed25519</td><td>SSH private key</td><td>53</td><td>31</td><td>117</td></tr><tr><td>Inbox.mbox</td><td>Google Takeout backup</td><td>50</td><td>32</td><td>107</td></tr><tr><td>UTC...</td><td>UTC Wallet</td><td>48</td><td>30</td><td>112</td></tr><tr><td>javazoom.jar</td><td>Benign jar file</td><td>41</td><td>21</td><td>103</td></tr></tbody></table>

guessable honeybuckets in a single email draft on Gmail. We withheld and did not leak the remaining 20 of 40 alphanumeric buckets to serve as a control group.

### 3.1.2 Bucket Permissions

Having chosen candidate bucket names to scan, an attacker could use one or more of Amazon's 100 operations to interact with the bucket. To capture as many potential interactions as possible, we gave bucket-scanning actors considerable freedom to interact with our honeybuckets: all honeybuckets allowed any actor to read the contents of the bucket and write new content to the bucket. However, deleting files originally uploaded by us was forbidden (although we could detect deletion attempts). We enabled bucket versioning—a

feature that saves all past versions of files in a bucket—to track how actors upload, delete, and modify the files they themselves upload. We recorded all available metadata of interactions with the honeybuckets, including the time of interaction, actor's IP address, actor's AWS account (if the actor sent an authenticated request [2]), request URI, and any error messages the actor received if their request was malformed or forbidden. To promote reproducibility, we will share our raw data with researchers.

### 3.1.3 Bucket Contents

After listing the directory of a bucket, an actor might only choose to download a subset of “interesting” files. We uploaded files with a variety of enticing names and contents to each honeybucket to test for file-download preferences amongst scanning actors. Table 1 lists the nine files we placed in each honeybucket. To function as controlled variables when comparing download preferences amongst scanning actors, the file names and contents were identical across all buckets. For example, each honeybucket included a “Client_list_Dec_2021” file to lure scanning actors searching for sensitive client information. The file included fake names, home addresses, and social security numbers generated by Faker [75]. Files named “Backup.pst”, “Outlook.pst”, “id_ed25519”, and “Inbox.mbox” were uploaded to lure actors who were searching for sensitive email folder names, SSH private keys, and Google takeout backups, respectively. Each file contained fake data in the expected format. We additionally included a file with the commonly abused .jar extension [81] to test for malicious actors who might wish to replace existing .jar files with hidden “trojan” malware. The content of the uploaded .jar file emulated a benign calculator program. Finally, we included two README files—sized 0 bytes and 2 kilobytes—to test if actors checked for file size prior to downloading.

## 3.2 Pilot Study Results

In this section we characterize how scanning actors engaged with our honeybuckets. We investigate the most common methods actors used to scan for buckets, the type of abusive activities buckets received, the amount of time actors spent interacting with a public bucket, and who was hunting for buckets. Most notably, we found that **buckets named after companies were the most likely to be accessed** (Section 3.2.1). Although the majority of bucket interactions only checked for bucket existence, **hundreds of IP addresses attempted to download, delete, or upload objects**—including malicious shell scripts (Section 3.2.2). This activity happened quickly after the buckets become accessible: **actors scanned public buckets within 40 minutes of deployment and uploaded unsolicited content within 10 days** (Section 3.2.3).
### 3.2.1 How Buckets Were Found

Buckets named after companies were scanned with the most number of operations and IP addresses. Table 2 lists the top 20 buckets with the most attempted operations. Half of these top 20 buckets had a company in their name, with the top five named after “Tesla.” For a detailed breakdown, Table 3 presents the number of unique IP addresses and Autonomous Systems (ASes) that targeted each bucket on average per bucket type. Company buckets were targeted with statistically significantly<fnref n="4" /> more IPs and ASes per day compared to all other bucket types. On average, at least one unique IP and AS visited a company bucket per day. In Section 4, we further investigate why actors are lured towards particular companies by deploying a second honeybucket experiment.

Seven of the top 20 buckets with the most number of interactions had names from open source bucket target generators (i.e., TGAs); however, the majority of actors did not appear to use only the TGAs to generate these bucket names. Rather, actors were likely using their own list of target bucket names that coincided with the TGA's list. We considered an actor to be using a TGA if (1) a single IP address⁵ targeted all four bucket names that belonged to that TGA; or (2) all TGA buckets were scanned by a uniform distribution of unique IP addresses—which accounts for actors that used multiple IPs (e.g., VPNs) when scanning. In Table 3, we filtered for IP addresses that targeted all four buckets from a single TGA and found statistically significantly fewer actors that exhaustively used the TGA names compared to the number of unique IPs that scanned buckets named after organizations. Furthermore, we found TGA buckets were not targeted by a uniform number of IP addresses (e.g., “origin-www” from DNSpop was targeted by 349 IPs, whereas “lyncdiscover” from DNSpop was targeted by 278 IPs).

Buckets named after universities or a government service were the second most likely to be scanned, with no statistically-significant difference between the two (Table 3). Among the buckets associated with organizations, bucket names concatenated with the word “production” were scanned the most. Table 4 shows the relationship between the number of scanning IPs and the organization/keywords in the bucket name. While 467 unique IPs scanned “teslaproduction,” only 375 unique IPs scanned “tesladownload.” On the other hand, across all organization types, bucket names concatenated with the word “hidden” were an order of magnitude less likely to be targeted than all other keywords (e.g.,

4 compared to 127 unique IPs for “fbihidden” vs “fbisecurty”).

Buckets leaked to passive data sources were the least likely to be scanned: an average of just 0.46 unique IP addresses visited a leaked bucket per day compared to an average of 1.63 IPs that visited a company bucket per day.

Since the search space for buckets is vast, prior work has found that targeting shorter and lower entropy names results in an overall higher hit rate when scanning buckets [69]. However, our results imply that actors are optimizing to find specific targets in addition to maximizing overall hit rate. For example, while bucket “612” contained the least amount of entropy in our honeybucket set, it was scanned by fewer unique IP addresses than five of the six Tesla buckets (Table 2), each of which was substantially longer and higher in entropy. Using the Kolmogorov-Smirnov test, we found no statistically significant difference between the number of unique IPs and ASes that targeted buckets “612” and “teslaproduction” (the Tesla bucket with the highest number of operations) per day, indicating that maximizing overall hit rate was not the only popular scanning strategy. Overall, we found that buckets named after companies were scanned the most compared to TGA buckets, leaked buckets, and buckets with names of a lower entropy.

### 3.2.2 Bucket Interactions and Abuse

Over 100 unique IP addresses (0.9% of all IPs) uploaded at least one file to a bucket, for a total of 206 files. Through manual investigation, we identified four unique files that hosted malicious content (uploaded across 16 unique buckets): (1) a “poc.jsp/” JavaScript file that spawned a reverse shell to a server specified by a command-line argument; (2) a “test-file.svg” file that, when opened, re-directed to a suspicious domain (“ngrok.io”); and (3) two files, named “_snapshot/test” and “_snapshot/test2”, that contained code to send the contents of the /etc/passwd file to the actor who uploaded the file.

Only two files, “upload.png” and “s3sec.txt,” contained a message to the bucket owner as a warning that their bucket was public. Notably ironic, these good-samaritan warnings were shared through an unsolicited upload. Of the remaining uploaded files, six unique files uploaded across nine buckets contained benign content, six files were not accessible due to the object permissions set by the actor, and 188 files were empty. We summarize the contents of all uploaded files in Table 10 in the Appendix.

Over 700 unique IP addresses (6% of all IPs) attempted to download a file from a unique bucket. The client list file was downloaded the most, with 160 total downloads across 88 unique IP addresses (Table 1). We did not find any file to have a statistically significantly<fnref n="6" /> greater number of down-

<footnote n="4">⁴We used a one-sided Mann-Whitney U test to evaluate whether the volume of traffic per day that targeted a specific bucket type was stochastically greater than the volume that targeted the bucket type with the next greatest volume of traffic per day. We used *p* < 0.05 and additionally applied a Bonferroni correction—to account for multiple comparisons—when determining statistical significance.

⁵The majority of actors used a single IP address when scanning (Section 4).</footnote>

<footnote n="6">⁶We calculated statistical significance using the methodology from Section 3.2.1.</footnote>
loads per day, likely due to the infrequent nature of downloads per day (i.e., on average, there are 0.00005 downloads per bucket per day). We summarize the remaining non-abusive bucket interactions in Appendix A.1, which often consists of checking a bucket's existence and/or listing files.

### 3.2.3 Time-to-Compromise of Buckets

Actors were quick to find buckets: within 40 minutes, the first bucket—"walmartdownload"—had its directory listed. However, it took at least one week for an actor to abuse a bucket (i.e., upload an unsolicited object to the "lyncdiscover" bucket generated with the TGA DNSpop). We considered a bucket to be abused when an actor attempted an upload, download, or delete operation on the bucket.

Buckets named after TGA targets or company names were the only two categories to experience uploads, with a bucket receiving a first upload within an average of 71 days. The first successful upload across all 112 buckets occurred 10 days after deployment in which an unauthenticated actor uploaded a file with instructions on how to make the bucket private. The file was called "s3sec.txt" and can be found in the Github repository s3sec [44].

Compared to uploading content, actors were much slower to download content. The average time-to-first download across all bucket types was 78 days, with the first successful download of the file "Backup.pst," 27 days after deployment, in the bucket "tesladownload." Content inside the non-sensitive keyword and control buckets was never downloaded over the course of the experiment.

The most rare and slowest-to-occur abuse of a bucket was file deletion: the only attempt to delete a file from Table 1 occurred 134 days after bucket deployment. Thus we conclude that actors were quick to find buckets and overall performed abusive operations by uploading unsolicited files and downloading files, but rarely attempted to delete our files from our buckets.

### 3.2.4 Identifying Bucket-Scanning Actors

A total of 6,567 unique IP addresses performed at least one operation to at least one bucket. Nearly all (99.9%) IP addresses sent an unauthenticated AWS request,<fnref n="7" /> allowing the user to remain anonymous. However, 27 actors authenticated themselves, and eight used non-alphanumeric usernames. Table 5 lists the eight actors, providing their username, IP addresses used, buckets visited, etc. Three actors had usernames that alluded to bugfinding (i.e., "s3bug", "bug", "pudsec"). The user "bug" uploaded a "Read.txt" file that described how to pen-test buckets for the purposes of

receiving a bug bounty. Three remaining users used administrator accounts, in which at least one alluded to being a "bot" for scanning (i.e., "Admin.../xbotusr"). The remaining 19 authenticated users used non-informative, random alphanumeric names. In Section 4, we deploy a new set of experiments to filter for only non-bot scanners.

Authenticated users also gave a glimpse into understanding if bucket-scanning actors often used multiple source IP addresses, and whether a unique IP address was likely to identify a unique scanning actor. We used the authenticated actor set as an approximate ground truth mapping of unique users to IP addresses.<fnref n="8" /> IP addresses were a sufficient approximate indicator of unique scanning actors: 90% of authenticated actors used only one scanning IP address and 100% of authenticated actors used IP addresses from the same autonomous system (Table 5). In Section 4.1, we show that the vast majority of bucket scanning actors were likely only using one IP address.

All scanners originated from a set of 330 autonomous systems, a subset of which have security-critical reputations. Approximately 66% of scanners originated from three ASes: M247 (ASN 9009), HostRoyale (ASN 203020), and CHOOPA (ASN 20473). Clients using M247 and Choopa are known to be consistently engaged in high-risk and highly fraudulent behavior [16,32]. HostRoyale's clients are known to use its anonymizing VPN services [28].

## 3.3 Summary

This pilot study systematically demonstrated that scanning strategies are not random: our honeybuckets named after well-known companies received the most activity (Section 3.2.1). Scanners were quick to discover new publicly accessible buckets, finding buckets within 40 minutes of deployment (Section 3.2.3). Finally, scanning actors actively interacted with the bucket contents in a variety of concerning ways: at least one file containing sensitive data was downloaded across nearly all buckets, many buckets had malicious files uploaded to them, and some had files targeted for deletion (Section 3.2.2).

While this experiment established many aspects of scanning activity, a number of questions remain. It is unclear why actors were lured towards particular companies, how actors might take further advantage of downloaded sensitive data, and whether identical files across buckets could cause actors to recognize the decoys and modify their behavior. Furthermore, actors can use multiple IPs and VPNs to mask their activity, and such aliasing leaves unresolved how to attribute multiple interactions to the same actor. In the next section, we build on our pilot study and deploy a new, refined honeybucket experiment to provide more insight into precisely

<footnote n="7">⁷Amazon allows users to be unauthenticated, which is when a user does not have an AWS account [2] or when an authenticated user adds the flag "--no-sign-request" to their command line argument [3].</footnote>

<footnote n="8">⁸The set is likely biased towards users that did not care about concealing their identity and thus served as an expected upper-bound of the number of actors that used only one scanning IP address.</footnote>
these questions.

# 4 Exploitation of Company Buckets

In our pilot study, actors were most likely to scan and download sensitive files from buckets named after companies, while occasionally using multiple IPs. In this section, we conduct a new, refined experiment to broadly investigate (1) what types (e.g., industry sector, Fortune 500 standing, having a vulnerability disclosure program) of companies receive the most traffic, (2) if actors using multiple IP addresses can be more easily identified and, most importantly, (3) whether downloaded content is exploited. We indeed found that companies with a vulnerability disclosure program were more likely to be scanned. Most alarmingly, we recorded eight instances of actors exploiting downloaded content from our buckets, which directly led to unauthorized attempts to login to one of our servers.

## 4.1 Methodology for Bucket Configuration

We deployed 120 honeybuckets on the AWS S3 platform on October 2, 2022 and hosted them for 1 month. We configured buckets with three primary differences from the methodology in Section 3.1: (1) names followed a single enterprise-themed naming scheme, (2) buckets contained an informative document that tracked the longevity of information post-download, and (3) bucket content used a unique identifier that helped track actors who used multiple IPs.

### 4.1.1 Bucket Names

We investigated what factors cause the buckets of one company to be at a higher risk of abuse (e.g., malicious uploads, malicious downloads) than another company. To study the cloud-storage attack surface of enterprises, we named 120 new buckets after 60 Fortune 500 companies [23]. We created the set of 60 companies by (1) removing company names with an “&”, as that symbol is not allowed in bucket names, (2) randomly ordering the remaining Fortune 500 companies, and (3) selecting the first 30 companies that had a clear vulnerability disclosure procedure (VDP) and the first 30 companies that did not appear to have a VDP. To determine if a company hosted a VDP, we used Google to search for “<company name> vulnerability disclosure” and looked for a disclosure procedure within the top 10 results.<fnref n="9" />

To construct the bucket names, we concatenated (with no spaces) each chosen company with the two keywords from Section 3.2.1 that attracted the greatest number of actors—“production” and “download”—thereby assigning two buckets per company (e.g., “carvanaproduction” and “carvanad-

download”). Table 12 in the Appendix lists the names of all chosen companies,<fnref n="10" /> their offering of a VDP and/or bug bounty, and their 2022 Fortune 500 ranking. In Section 5, we discuss the ethics of this methodology.

### 4.1.2 Bucket Contents

Recall that in Section 3.2, some actors downloaded at least one file from the bucket. In this experiment, our goals are to (1) identify what actors do after downloading a file, and (2) better estimate the number of actors engaging with the buckets. To accomplish these goals, all buckets in our second experiment hosted (1) fictitious sensitive content to lure actors to interact with our honeybuckets in a way that allowed for tracking their actions, and (2) a new text document that served as a source of information to trace the identity of actors.

**Sensitive Information.** To lure actors into interacting with our honeybuckets, we hosted a nested directory of fake financial data generated by the Faker tool [75]. Each honeybucket hosted unique data (unlike our first experiment in Section 3.1), to reduce the chance of actors finding multiple company-named honeybuckets and possibly growing suspicious if they encountered identical data. We named the nested directory with an hourly-changing hashed time stamp (i.e., “update_2022 Chargeback_{unix time}”). As a result, an actor who used multiple IP addresses across multiple hours to list bucket contents and download individual files could be identified using the hashed time stamp. To avoid triggering alarms,<fnref n="11" /> we zip-encrypted the contents of individual sensitive files across all honeybuckets.

**Informative Document.** All buckets hosted a single, unencrypted text document that (1) encouraged actors to contact the bucket owner, (2) traced the longevity of sensitive information post-download, and (3) identified actors who used multiple IP addresses. To encourage actors to contact us, the document included an email address that we controlled, and attributed bucket ownership to an ambiguous financial analytics contractor of the Fortune 500 company. In this way, we could still measure interactions associated with buckets named after Fortune 500 companies, but—assuming the actor read the informative document—re-direct follow-up email interactions to us.

We also wanted to infer whether actors who downloaded sensitive data had malicious intentions, such as using the downloaded information for nefarious purposes. For this

<footnote n="9">⁹This search methodology identified that 21% of the first set of the 60 randomly chosen companies had a vulnerability disclosure program, which is nearly-identical to what prior work has found [54].</footnote>

<footnote n="10">¹⁰During bucket deployment, we encountered an already-existing bucket, “Blackrockproduction”. We replaced Blackrock with another randomly-chosen Fortune 500 company.</footnote>

<footnote n="11">¹¹After nine days of deployment, Amazon sent a note to an email address associated with our lab’s AWS account, warning us that two out of 120 honeybuckets were “publicly hosting highly sensitive and confidential information.” We immediately configured these buckets to be private and renamed them to incorporate the names of two new Fortune 500 companies (Table 12) that fit our criteria from Section 4.1.1.</footnote>
goal, in the document we also included an SSH username,
password, and IP address for a Cowrie SSH honeypot [85]
that we hosted. To lure an actor to login via SSH, we
(falsely) stated that the encryption key to the sensitive files
in the bucket could be found in our SSH honeypot. While no
username or password combination granted entry into our
Cowrie honeypot, we monitored login attempts (i.e., IP ad-
dress, timestamp, username and password attempted) to see
if any attempted SSH credentials matched the credentials
provided in the honeybucket.

In the first experiment (Section 3.2), thousands of unique
IP addresses interacted with our buckets. To identify individ-
ual actors who may have used multiple IP addresses to search
for buckets and SSH into our honeypot, we updated the SSH
password in the informative document every hour by con-
catenating the password with a hash of the current times-
tamp. We then used the SSH password as a link between
the IP address that obtained the password and the IP address
that used it. In a similar manner, we updated the name of
the text document to trace actors who may have used differ-
ent IP addresses to list directory contents and download in-
dividual files. To attract actors to our informative document,
we named the informative document ‘secure-encryption-ssh-
quickstart-{unix time}.txt’ to attract downloads with its en-
ticing name. Relative to all other bucket content, the docu-
ment’s name was alphabetically first, which ensured that our
informative document appeared first when an actor listed the
contents of the bucket. We provide the exact text of the doc-
ument in Appendix A.2.

4.1.3 Bucket Permissions

In Section 3.2.2, we documented actors uploading over
100 files—some of which were inaccessible to us—across
different buckets. To preserve the integrity of our bucket con-
figuration, in this experiment actors were only allowed to (1)
list the bucket directory, (2) download all objects, and (3) up-
load an object if and only if the actor transferred ownership
of the uploaded object to the bucket owner. Currently, this is
the only solution to automatically ensure uploaded files can
be accessed by the bucket owners, since files are automati-
cally owned by the uploader [92, 96]. Deleting objects was
forbidden.

4.2 Results

In this section, we use the increased lures and tracking ca-
pabilities to further understand how bucket scanners oper-
ate. We start by investigating what kinds of companies lured
the most actors and found a **significantly increased num-**
**ber of actors and significantly increased amount of abu-**
**sive behavior correlated with companies with a vulnera-**
**bility disclosure program (Section 4.2.1).** We found that
certain scanners used VPNs, prompting us to develop a scal-

able approach to track and group colluding IPs as belonging
to the same actor. Using this approach, we found most ac-
tors still only used 1 IP address (Section 4.2.3). Finally, we
analyze the “abusiveness” of actor behavior, distinguishing
between those actors who merely downloaded our purport-
edly sensitive information and those who used that data to
login to another machine that they were not authorized to
access. **We traced over 3000 login attempts to 8 unique
actors who had previously downloaded content from our
bucket** (Section 4.2.4).

**4.2.1 Understanding Company Targets**

Buckets that contained the names of companies with a vul-
nerability disclosure program (“VDP companies”) were sta-
tistically significantly<fnref n="12" /> more likely to be scanned. Table 6
presents the number of IP addresses who scanned different
categories of companies. On average, VDP-company buck-
ets were scanned by 60% more IP addresses compared to
non-VDP company buckets, attracting roughly 18 IPs per
day. VDP-company buckets were responsible for the ma-
jority (6/8) of the abusive SSH behavior (Section 4.2.4). Our
results are consistent with previous work [61] that found a
positive correlation between bug bounty programs and data
breaches when studying government-reported breaches. One
possible explanation is that potential financial incentives at-
tract scanners, but we cannot discount the possibility that
companies with valuable online assets are simply more likely
to institute VDPs (perhaps due to being attacked more fre-
quently).

Additionally, buckets with names of companies in the
technology sector were statistically significantly<fnref n="13" /> more
likely to be scanned by unique IPs compared to any other
sector. Buckets named after technology companies¹⁴ were
scanned by 74% more IPs on average than healthcare buck-
ets, the second-most scanned sector. Technology company
buckets attracting the most IPs was not a symptom of having
a VDP: while 5 out of 8 technology companies had a VDP,
10 out of 10 of the health companies and 10 out of 16 of the
financial companies also had a VDP. We found no correla-
tion between a company's Fortune 500 rank and the number
of IP addresses who scanned its corresponding bucket.

Table 7 lists the top ten buckets that were scanned by
the greatest number of unique IP addresses. The two most-
scanned buckets were both named after American Express,
which has a VDP. Unique actors consistently scanned
American Express buckets throughout our experiment.

<footnote n="12">¹²We used the same one-sided Mann-Whitney U methodology from Section 3.</footnote>

<footnote n="13">¹³Accounting for Bonferroni correction, the Mann-Whitney U method-
ology only returns significant p-values for sample sizes greater than 10.
Thus, the following company sectors were excluded from statistical anal-
ysis: Healthcare (10 buckets total), Transportation (8), Engineering (6),
Aerospace (4), and Business Services (2).</footnote>

<footnote>We determine sector by using the Fortune 500 sector label.</footnote>
Six out of the top ten most-scanned buckets were named after technology companies, and nine were named after companies with a VDP.

### 4.2.2 AWS Triggered Reports

We received two AWS triggered reports throughout the course of our experiment. These reports were not prompted by an internal AWS hygiene system. Instead, they were investigated by humans (employees or contractors) that explicitly searched for buckets named after these companies. Our first AWS report regarded one of our buckets named after a technology company. AWS included the emails of the “original abuse reporter[s]:” two employees of that company. Our second report regarded two of our buckets named after a healthcare company, with the contact information of a security employee from said company. After removing the buckets, as per their request, we spoke with the healthcare security team and learned that the buckets were reported to them by a third-party rather than an internal scanning system or team. Thus, we see that both AWS and the company rely on good Samaritans to report bucket misconfigurations, instead of AWS’s internal, automated detection systems [4, 5].<fnref n="15" /> Furthermore, this healthcare company operates a vulnerability disclosure program, reinforcing that the presence of such a program may influence how scanners pick their targets.

### 4.2.3 Identifying and Tracking Unique Actors

Since some actors are likely to use VPNs to interact with the buckets, we developed an algorithm to identify “colluding” IP addresses to better identify and track *at scale* a single actor’s operations across multiple IP addresses. We define a single actor using colluding IP addresses to be either one scanner operating under a VPN or multiple parties colluding by sharing or selling information to each other. We used this algorithm to better approximate the true number of actors interacting with the buckets, rather than just using the number of unique IP addresses.

**Algorithm.** To identify colluding IP addresses, we relied on the hourly updates of unique identifiers in bucket file-names (Section 4.1.2), which provided a link between colluding IP addresses that execute operations on behalf of each other. Concretely, there are three cases of operations that revealed colluding IPs:

**Failure:** Without having ever listed the directory, there was an attempt to download a file that used to, but no longer, exists. For example, in Figure 1, IP9 never listed the directory, but attempted to download file “d,” which no

longer existed. IP8 was the only IP that listed the directory during file d’s existence, thus IP8 and IP9 must have been colluding IPs.

**Success:** Without having ever listed the directory, there was a successful download of a file. For example, in Figure 1, IP6 never listed the directory, but successfully downloaded file “c”. IP5 was the only IP address that listed the directory after file c was uploaded, but before IP6 downloaded file c, thus IP6 must have been colluding with IP5.

**SSH:** Without having ever downloaded the informative document, there was an attempt to login to the SSH Honeypot. For example, in Figure 1, IP12 never listed the directory, but attempted to login to the SSH Honeypot using the credentials only found in file “f”. IP11 was the only IP address that successfully downloaded file f, thus IP12 and IP11 must be colluding IPs. We use the Success case above to determine that IP10 and IP11 must have been the same actor as well.

We formalize the logic to detect all three cases of likely-colluding events in the Appendix in Algorithm 1. Algorithm 1 takes as input (1) an IP address and (2) a token associated with the IP address. The algorithm returns as output a (potentially empty) set of IP addresses that colluded with the input IP address based upon the time of their operations. The token associated with the IP address is the informative document or SSH password that the IP address had downloaded or used. The token contains the unique time-based identifier that identifies which time frame another colluding IP could have downloaded the token from. Upon identifying the time frame, the algorithm simply searches for which other IP addresses downloaded the token in the target time frame, and assigns those IP addresses to the returned colluding set. We note that if the input IP address did not download a document or abuse an SSH password (i.e., “token == none”), then the algorithm will not return any colluding IPs for the current IP. Instead, if it was indeed a colluding IP, it may be returned as a colluding IP for another IP address that did download a document or abuse an SSH password.

Notably, the algorithm’s accuracy directly depends upon the granularity of content updates. For example, since our methodology updates bucket file names every hour, IP addresses that appear together within the same hour—whether by accident or due to collusion—often cannot be differentiated and are all considered candidates for collusion. This is seen with IP2, IP3, and IP4 in Figure 1, where IP2 and IP3 both listed the bucket directory and therefore are both considered candidates for colluding with IP4. Further, the algorithm cannot detect if two unique actors are using two VPNs within the same hour on the same bucket. Nevertheless, as shown in Table 3 the number of unique IPs that visited a bucket per day—let alone per hour—is often too low

<footnote n="15">¹⁵Indeed, to the best of our knowledge, neither the AWS security investigator, Detective [4], nor the AWS threat detection service, GuardDuty [5], specifically monitor for buckets hosting exposed sensitive data.</footnote>
<figure><img src="image_3.png" /><figcaption>Figure 1: **Identifying Colluding IP Addresses**— We identified colluding IPs using the causal dependencies created by hourly-updated filenames. In our figure, “DIR: [a]” is the return of a directory listing with the filename “a,” “REQ(a)” is the request of filename “a,” and “SSH(a)” is the extraction of SSH credentials from filename “a.” When an IP requested a file without having listed the directory (e.g., IP4), all IPs that listed the directory within the same hour (e.g., IP2 and IP3) were identified as potentially colluding with the file-requesting IP. An IP that SSH’ed into our honeypot server (e.g., IP12), without having downloaded the file with the SSH instructions, was identified as colluding with the IP that downloaded the file with the matching SSH credentials (e.g., IP11).</figcaption></figure>

(i.e., < 1 unique IP per day) for the algorithm's limitation to be a problem.

**Characterizing Actors.** Applying this algorithm across all logged bucket operations, the vast majority (94.6%) of actors appeared to use only one IP address. In the most extreme case, one actor used 45 unique IPs—a subset of which map to known VPN products and Tor exit nodes—to download files. In Section 4.2.4, the actors who used more than one IP address were more likely to participate in security-critical behavior. The remaining 5.4% (61 out of 1128) of IP addresses clustered to at most six unique actors.

### 4.2.4 Abusive access

Among the challenges for a study like ours is that threat actors are anonymous and their underlying motivations are undeclared. Thus, it can be difficult to distinguish between the visits of a benign scanner (e.g., a security researcher or pentester), and a malicious party who is seeking to exploit exposed resources. It is to address this ambiguity that we introduced the SSH honeypot component of our experiment. By creating an opportunity for scanners to “cross the line” and attempt an unauthorized login to third-party infrastructure using credentials harvested from our buckets, we create a measurement that is clearly interpretable. Independent of any motivation, such actions are widely understood to violate ethical norms [73] and, in most countries, civil and criminal law as well.<fnref n="16" /> To put this another way, there is no motivation that excuses an attempt to use purloined credentials to gain

unauthorized access to an unknown server. Indeed, it would be particularly worrying if purportedly benign researchers were taking such action. Thus, we consider all such accesses to be malicious.

We tracked the downloads of the informative document and monitored our SSH honeypot over a span of 6 months. A total of 182 unique IP addresses downloaded at least one bucket's informative document, which contained an email address (i.e., a direct method to contact the bucket owner) and leaked SSH credentials. Eight unique IPs, traced to eight unique actors, collectively performed over 3000 login attempts using the leaked SSH credentials. Only one actor sent an email message.<fnref n="17" />

Using the algorithm outlined in Section 4.2.3 we have distinguished two categories of SSH-abuse from our data. We call not enumerating all possible passwords “SSH Attempt,” which was performed by 5 actors, and call using all 1000 possible passwords “SSH Brute Force,” which was performed by 3 actors.

**SSH Attempt.** Five unique actors—whose IP addresses belong to Microsoft Cloud (AS 8075), Charter Communications (AS 11427), the high-fraud risk Cloudvisor (AS 66240), TIAA (AS 2923), and NETSPI (AS 397919)—attempt at most eight passwords against our SSH honeypot.

In the first SSH case (16 days after bucket deployment), a

<footnote n="16">¹⁶For example, in the US unauthorized access of this form is a violation of 18 USC 1030, the Computer Fraud and Abuse Act.</footnote>

<footnote n="17">¹⁷The single message we received was from a party warning us, in our capacity as the purported financial analytics contractor, that our *usaadownload* bucket was public. This “good Samaritan” requested that we pay a bug bounty and sent three follow up-mails insisting on a reward. We note that USAA, which operates a monetary VDP [51], belongs to the category of organizations that attract the most scanning traffic.</footnote>
single actor used two IP addresses to find a company bucket, download the informative document, and attempt to login to the SSH Honeypot—all within 3 minutes. The actor used address IP1 to list the directory of the bucket “tiaadownload” and download the informative document. Within two minutes, address IP2 attempted to login to the SSH Honeypot using both the username and password originally displayed to IP1 a few minutes prior. IP1 was the only address to download the informative document with the credentials used by IP2. We therefore conclude that the two IPs must have been the same actor who downloaded and used the leaked SSH credentials.

The IP addresses both resolve to the “vpn.netspi.com” domain, which belongs to NetSPI, a penetration testing, threat and attack surface management company [34]. While NetSPI used the SSH credentials found in TIAA’s bucket, we do not find public evidence that TIAA is a customer of NetSPI.<fnref n="18" /> However, even if TIAA were a customer of NetSPI who authorized them to act on their behalf, neither the credentials we provided, nor the domain accessed belonged to TIAA. Indeed, the downloaded informative document clearly stated that the SSH credentials belonged to a third-party contractor, and not to TIAA. Notably, NetSPI did not append a three-digit identification number to the SSH password, which the informative document instructed to do. While it is conceivable that NetSPI understood that no access would be accomplished, their attempt at unauthorized access violates ethical norms.

**SSH Brute Force.** Three unique actors—whose IP addresses belong to the high-fraud risk Packethub (AS 147049), Midco VPN (AS,11232), and 31173 Services VPN (AS 39351)—attempt all one thousand variations of the password leaked in the informative document.

In the first brute force event, an actor used multiple IP addresses to find a company bucket, download the informative document, and attempt to log into the SSH Honeypot, across a 24-hour period. We determined that two IP addresses used in these interactions belonged to the same actor. On October 30th, address IP1 listed the directory of the bucket “oracledownload.” Nearly 24 hours later, address IP2 attempted to download the informative document, DocA, in “oracledownload” that was originally presented to IP1. However, IP2 was unsuccessful due to DocA having already been deleted because of our hourly updates (Section 4.1.2). Since IP1 was the only IP address to list the directory during DocA’s existence, IP1 and IP2 must have been the same actor.

We determined that this actor also used two additional IP addresses. Since the actor realized that the original DocA was no longer in the bucket, within 10 seconds a new address, IP3, listed the bucket directory again. Yet another address, IP4, then downloaded the new informative document

(DocB) originally listed to IP3. Having finally successfully downloaded DocB, which contained the leaked SSH credentials, IP1 attempted to login to the SSH Honeypot using the username and password displayed to IP4 five minutes prior. We therefore conclude that these four IP addresses were all the same actor that ultimately found and used the leaked SSH credentials. All four IPs belong to AS39351, “31173 Services AB,” which provides a VPN service [57].

However, unlike the other SSH-abuse attempts, this actor clearly understood the requirement to append a three-digit identification number to the SSH password, as they iterated through all 1000 possibilities while attempting to login. It is difficult to construct a credible scenario in which the actor could have believed these actions were authorized.<fnref n="19" />

## 4.3 Summary

Actor engagement with company buckets increased with the presence of a vulnerability disclosure program (Section 4.2.1). To identify scanners using VPNs and to better approximate unique actor activity, we developed a scalable approach to identify colluding IP addresses (Section 4.2.3). Colluding IP addresses were more likely to participate in security critical behavior. In the most abusive case, we identified eight separate events in which colluding IP addresses downloaded, read and understood our informative document, leading them to perform unauthorized login attempts into our honeypot server (Section 4.2.4).

## 5 Ethics

We considered two classes of ethical issues in this work: potential human subject issues and potential harms to companies. As per discussions with our university’s human subjects office, our work does not constitute human subjects research for the purposes of the US HHS Common Rule (45 CFR 46) because we are not collecting information about individuals. Indeed, we have not solicited for any contact and any data that we receive is a byproduct of explicit actions taken to search for our buckets. We take no actions with this data (i.e., we do not act on the unauthorized logins to our infrastructure other than to log it) and thus we reason that any harms are minimal. This is consistent with a long line of research into third-party scanning behavior that has long been considered within the ethical norms of the community [86].

The second issue we considered was potential harm to companies due to trademark confusion or unwarranted reputational damage. Working with the guidance of our university’s general counsel, we designed our methodology to minimize these issues in several ways. First, during the targeting phase of the study, we did not leak (i.e., advertise) buckets

<footnote n="18">¹⁸While TIAA is not a public customer of NetSPI, both companies do have another connection: NetSPI’s current CTO previously worked for TIAA as the Head of Cybersecurity Technology [35, 52].</footnote>

<footnote n="19">¹⁹Moreover, since in most countries such unauthorized accesses are criminal acts (e.g., in the US under the Computer Fraud and Abuse Act, 18 USC 1030) this would be a substantial risk for a benign organization to take.</footnote>
that included organizational names. Thus, organizational-
named buckets could only be found by those actively and
blindly guessing the names (minimizing any potential for
confusion). Second, we provided multiple paths for resolv-
ing any confusion: including a contact email address in the
informative document, a university affiliation that became
clear if a visitor requested the access control list, and the nor-
mal notification path via AWS. Finally, in the two instances
in which we were contacted by brandholders (themselves
notified by third parties, Section 4.2.2) we immediately re-
moved the associated buckets as per their request.

As well, we adhered to AWS terms of service, did not host
any (real) sensitive data, and did not allow unauthorized lo-
gin attempts from the attackers who sought to exploit our
seemingly misconfigured buckets.

6 Recommendations

Our work demonstrates that buckets named after commer-
cial entities are actively targeted and exploited. Defending
against cloud storage attackers is simple: configure buck-
ets with sensitive information to be private. Unfortunately,
prior work [71] has shown that thousands of buckets remain
publicly exposed with sensitive information. Furthermore,
over time, buckets are more likely to be misconfigured [69].
It is possible that misconfigured buckets are a symptom of
owners who are unaware of the perils of exposing sensitive
information, or are unaware that the bucket is theirs in the
first place.

Nevertheless, we propose the following recommendations
for decreasing the risk of bucket exploitation, beyond simply
making buckets private:

**Scan assets.** Buckets named after the organization itself—as opposed to just low-entropy names—are the most attractive targets for scanners (Section 3.2.1). We recommend that organizations consistently scan for both known and unknown cloud storage assets to immediately detect misconfigurations. To scan for known assets, organizations can maintain a bucket bookkeeping system that periodically scans all buckets. To scan for unknown assets (e.g., [20]), organizations should scan for “easy-to-guess” buckets named after the organization itself. Scanning for unknown organization-named assets is not a new concept: prominent organizations (e.g., Levi’s, New Balance, etc) already use products (e.g. Brand-Shield [12]) that protect brand reputation by scanning for organization-named Internet domains (e.g., ‘Levis.xyz’) that might be engaging in phishing, fraud, or trademark infringement. Thus, such brand-reputation scanning protections can, with likely minimal overhead, also scan for the presence of organization-named buckets to help protect organizations from data breaches (another threat against brand reputation).

**Weigh risk according to organization type.** Companies with a VDP are more likely to be at risk than universities (Section 4.2.1). We recommend that security services which

exist to help organizations trace stray and unknown assets
(e.g., Censys [8]) weigh the risk of exposed bucket exploita-
tion according to the organization type. Such services can
more aggressively scan and push to patch according to the
organization type.

**Use high entropy names.** High entropy names are less likely to be found and exploited because most scanners are simply guessing for bucket names (Section 3.2.1). Thus, organizations who create buckets with high entropy names (e.g., “usaa-production-16219531”) are less likely to be found by the most common attacker strategy (albeit security through obscurity).

**Encourage cloud providers to protect customer assets.** No matter the cause of misconfigured buckets, we believe cloud providers are in the best position to help trace and notify misconfigured bucket owners for two reasons. First, while it is challenging for a third party to identify who truly owns a misconfigured bucket, cloud providers can use the email address registered with the bucket owner's account to remind owners of buckets that are open to public access. Second, while no public repository enumerating all existing buckets exists, cloud providers likely have some internal bookkeeping of resources that can be used to exhaustively identify all public buckets. Currently, our experience with AWS is that it provided only limited proactive notifications: across the 232 honeybuckets deployed across a total of 8 months, AWS only notified our account about four buckets that were publicly exposing sensitive data.

7 Conclusion

Actors scan and abuse the information found in cloud stor-
age buckets. We deployed honeybuckets across two different
experiments to measure how actors scan for buckets. Buck-
ets named after companies—especially with a vulnerability
disclosure program—were the most likely to be scanned and
abused. Attackers constantly abused the permissions of the
bucket they found: downloading files, uploading malicious
executables, and even deleting existing content. Most con-
cerning, we found that actors read and exploited the con-
tents they downloaded; in eight cases, SSH login instructions
leaked from our honeybuckets were precisely followed and
used to attempt to gain unauthorized server access. Given
that attackers exploiting cloud storage is a reality, we hope
our findings encourage both cloud storage operators and cus-
tomers to track and secure their misconfigured buckets.

Data Availability

To promote reproducibility, upon request, we will share with
researchers all raw data collected during this work’s experi-
ments. Raw data will include logs of all scans that target any
honeybucket or SSH-server. We will also share the source-code used to identify colluding IPs.

## References

[1] 1000 most common us english words - github repository by deekayen. https://gist.github.com/deekayen/4148741. [Accessed on: 2023-11-01].

[2] Access control list (acl) overview. https://docs.aws.amazon.com/AmazonS3/latest/userguide/acl-overview.html. Accessed: 2023-04-14.

[3] Access s3 public data without credentials. https://dev.to/aws-builders/access-s3-public-data-without-credentials-4f06. Accessed: 2023-04-14.

[4] Amazon detective documentation. https://docs.aws.amazon.com/detective/. [Accessed on: 2023-11-01].

[5] Amazon guardduty features. https://aws.amazon.com/guardduty/features/. [Accessed on: 2023-11-01].

[6] American express | cybersecurity. https://www.americanexpress.com/us/security-center/cybersecurity.html. Accessed: 2023-05-20.

[7] Analog devices vulnerability disclosure program. https://www.analog.com/en/support/technical-support/product-security-response-center/vulnerability-disclosure-policy.html. Accessed on 2023-05-23.

[8] Attack surface management and data solutions. https://censys.io. Accessed: 2023-05-30.

[9] Aws S3 actions. https://docs.aws.amazon.com/AmazonS3/latest/userguide/using-with-s3-actions.html#using-with-s3-actions-related-to-buckets. Accessed: 2023-05-1.

[10] Booking holdings vulnerability disclosure program. https://raw.githubusercontent.com/arkadiyt/bounty-targets-data/master/data/hackerone_data.json. Accessed on 2023-05-23.

[11] Boston scientific vulnerability disclosure program. https://www.bostonscientific.com/en-US/customer-service/product-security/responsible-disclosure.html. Accessed on 2023-05-23.

[12] Brandshield | anti-phishing solutions. https://www.brandshield.com/products/anti-phishing/. Accessed: 2023-05-26.

[13] Capital one financial vulnerability disclosure program. https://www.capitalone.com/digital/responsible-disclosure/. Accessed on 2023-05-23.

[14] Carvana vulnerability disclosure program. https://www.carvana.com/responsible-disclosure. Accessed on 2023-05-23.

[15] Charles schwab vulnerability disclosure program. https://www.schwab.com/schwabsafe/report-a-vulnerability. Accessed on 2023-05-23.

[16] Choopa - fraud risk. https://scamalytics.com/ip/isp/choopa. Accessed: 2023-05-26.

[17] Csx vulnerability disclosure program. https://www.csx.com/index.cfm/about-us/contact-us/csx-responsible-disclosure-policy/. Accessed on 2023-05-23.

[18] Cvs health vulnerability disclosure program. https://www.cvshealth.com/vulnerability-disclosure-program. Accessed on 2023-05-23.

[19] Deere vulnerability disclosure program. https://www.deere.com/en/digital-security/responsible-disclosure/. Accessed on 2023-05-23.

[20] Defending assets you don't know about, against cyberattacks. https://threatpost.com/defending-unknown-assets-cyberattacks/175730/. Accessed on 2023-05-23.

[21] Discover financial services vulnerability disclosure program. https://discover.responsibledisclosure.com/hc/en-us. Accessed on 2023-05-23.

[22] Dover vulnerability disclosure program. https://www.dover.com/privacy-policy. Accessed on 2023-05-23.

[23] Fortune 500 list. https://fortune.com/fortune500/2022/search. Accessed: 2023-05-13.

[24] General electric vulnerability disclosure program. https://www.ge.com/gas-power/products/digital-and-controls/cybersecurity/vulnerability-response. Accessed on 2023-05-23.
[25] Goldman sachs vulnerability disclosure program. https://firebounty.com/416-goldman-sachs-vdp/. Accessed on 2023-05-23.

[26] Grayhat warfare. https://grayhatwarfare.com. Accessed: 2023-05-02.

[27] Hca healthcare vulnerability disclosure program. https://hcahealthcare.com/legal/index.dot#responsible-disclosure. Accessed on 2023-05-23.

[28] Hostroyale - fraud risk. https://scamalytics.com/ip/isp/hostroyale. Accessed: 2023-05-26.

[29] Intuit vulnerability disclosure program. https://security.intuit.com/responsible-disclosure. Accessed on 2023-05-23.

[30] Keurig dr pepper vulnerability disclosure program. https://hackerone.com/keurigdrpepper?type=team. Accessed on 2023-05-23.

[31] Kippo. https://github.com/desaster/kippo. Accessed on 2022-05-22.

[32] M247 - fraud risk. https://scamalytics.com/ip/isp/m247. Accessed: 2023-05-26.

[33] Misconfigured aws s3 bucket leaks 36,000 inmate records. https://www.trendmicro.com/vinfo/ph/security/news/cybercrime-and-digital-threats/misconfigured-aws-s3-bucket-leaks-36-000-inmate-records. Accessed on 2023-05-21.

[34] Netspi. https://www.netspi.com/. Accessed: 2023-05-04.

[35] Netspi. https://www.netspi.com/webinars/financial-services-cybersecurity-part-two/. Accessed: 2023-05-04.

[36] Northwestern mutual vdp. https://bugcrowd.com/northwestern-vdp/. Accessed on 2023-05-23.

[37] Nvidia vulnerability disclosure program. https://www.nvidia.com/en-us/security/psirt-policies/. Accessed on 2023-05-23.

[38] Oracle vulnerability disclosure program. https://www.oracle.com/corporate/security-practices/assurance/vulnerability-disclosure.html. Accessed on 2023-05-23.

[39] Otis worldwide vulnerability disclosure program. https://www.otis.com/en/uk/cyber-security. Accessed on 2023-05-23.

[40] Pfizer vulnerability disclosure program. https://hackerone.com/pfizer?type=team. Accessed on 2023-05-23.

[41] Pnc financial services group vulnerability disclosure program. https://www.pnc.com/en/security-privacy/responsible-disclosure-program.html. Accessed on 2023-05-23.

[42] Regions financial vulnerability disclosure program. https://www.regions.com/about-regions/privacy-security/vulnerability-disclosure-program#:~:text=Regions%20Bank%20does%20not%20operate,a%20code%20or%20configuration%20change. Accessed on 2023-05-23.

[43] S3 misconfiguration exposes sensitive data on more than 3 million senior citizens. https://www.scmagazine.com/news/cloud-security/s3-misconfiguration-exposes-sensitive-data-on-more-than-3-million-senior-citizens. Accessed on 2023-05-21.

[44] s3sec. https://github.com/0xmoot/s3sec. Accessed: 2023-05-13.

[45] State farm insurance vulnerability disclosure program. https://www.statefarm.com/customer-care/privacy-security/security/vulnerability-disclosure-policy. Accessed on 2023-05-23.

[46] T-pot - the all in one multi honeypot platform. https://github.com/telekom-security/tpotce. Accessed on 2023-05-23.

[47] Target vulnerability disclosure program. https://security.target.com/vdp. Accessed on 2023-05-23.

[48] Tiaa vulnerability disclosure program. https://tiaa.responsibledisclosure.com/hc/en-us#:~:text=If%20you%20have%20reported%20an,a%20fix%20has%20been%20issued. Accessed on 2023-05-23.

[49] Tractor supply vulnerability disclosure program. https://www.tractorsupply.com/policies-information_customer-solutions_responsible-disclosure-statement. Accessed on 2023-05-23.

[50] Uk data protection regulator receiving 'large number of reports' about capital. https://therecord.media/capita-data-breaches-information-commissioners-office. Accessed on 2023-05-29.
[51] Usaa vulnerability disclosure program. https://bugcrowd.com/usaa. Accessed on 2023-05-23.

[52] Venturebeat: Netspi expands. https://venturebeat.com/security/pentesting-firm-netspi-expands-into-attack-surface-management/amp/. Accessed: 2023-05-04.

[53] Vulnerability disclosure program. https://www.optum.com/business/vulnerability.html#:~:text=Bug%20Bounties,in%20accordance%20with%20this%20policy. Accessed on 2023-05-23.

[54] Vulnerability disclosure programs among the fortune 500. https://www.rapid7.com/blog/post/2021/05/21/rapid7s-2021-icer-takeaways-vulnerability-disclosure-programs-among-the-fortune-500/. Accessed: 2023-05-30.

[55] Protecting yourself while using the internet. https://www.justice.gov/usao-ndga/protecting-yourself-while-using-internet, 2015. [Accessed on: 2023-11-01].

[56] Bucket of staging files after deploying an app engine. https:// stackoverflow.com/questions/42947918/bucket-of-staging-files-after-deploying-an-app-engine, 2017.

[57] 31173 services ab. https://www.31173.se/, 2022. Accessed: 2023-05-20.

[58] A cyberattack illuminates the shaky state of student privacy. https://www.nytimes.com/2022/07/31/business/student-privacy-illuminate-hack.html?referringSource=articleShare, 2022. Accessed: 2023-05-26.

[59] A huge data leak of 1 billion records exposes china's vast surveillance state | techcrunch. https://techcrunch.com/2022/07/07/china-leak-police-database/?guccounter=1, 2022. Accessed: 2023-05-26.

[60] Microsoft leaked 2.4tb of data belonging to sensitive customer. critics are furious. https://arstechnica.com/information-technology/2022/10/microsoft-under-fire-for-response-to-leak-of-2-4tb-of-sensitive-customer-data/?utm brand=arstechnica&utm_source=twitter&utm social-type=owned&utm_medium=social, 2022. Accessed: 2023-05-26.

[61] Aleksi Aaltonen and Yiwen Gao. Does the outsider help? the impact of bug bounty programs on data breaches. In *Fox School of Business Research Paper*, 2021.

[62] Gautam Akiwate, Raffaele Sommese, Mattijs Jonker, Zakir Durumeric, KC Claffy, Geoffrey M Voelker, and Stefan Savage. Retroactive identification of targeted dns infrastructure hijacking. In *Proceedings of the 22nd ACM Internet Measurement Conference*, pages 14–32, 2022.

[63] Manos Antonakakis, Tim April, Michael Bailey, Matt Bernhard, Elie Bursztein, Jaime Cochran, Zakir Durumeric, J Alex Halderman, Luca Invernizzi, Michalis Kallitsis, et al. Understanding the mirai botnet. In *USENIX Security Symposium*, 2017.

[64] Jeff Barr. Celebrate 15 years of amazon s3 with 'pi week' livestream events. https://aws.amazon.com/blogs/aws/amazon-s3s-15th-birthday-it-is-still-day-1-after-5475-days-100-trillion-objects/, 2021.

[65] David Barrera, Glenn Wurster, and Paul C van Oorschot. Back to the future: revisiting ipv6 privacy extensions. *LOGIN: The USENIX Magazine*, 36(1):16–26, 2011.

[66] Bharath. Slurp's S3 string formatting permutations. https://github.com/0xbharath/slurp/blob/master/permutations.json, 2018. Accessed: 2023-05-26.

[67] Bitquark. Dnspop. https://github.com/bitquark/dnspop/blob/master/results/bitquark_20160227_subdomains popular 1000000, 2016. Accessed: 2023-05-26.

[68] Kevin Bock, Abdulrahman Alaraj, Yair Fax, Kyle Hurley, Eric Wustrow, and Dave Levin. Weaponizing middleboxes for {TCP} reflected amplification. In *30th USENIX Security Symposium (USENIX Security 21)*, pages 3345–3361, 2021.

[69] Jack Cable, Drew Gregory, Liz Izhikevich, and Zakir Durumeric. Stratosphere: Finding vulnerable cloud storage buckets. In *24th International Symposium on Research in Attacks, Intrusions and Defenses*, pages 399–411, 2021.

[70] Shinyoung Cho, Romain Fontugne, Kenjiro Cho, Alberto Dainotti, and Phillipa Gill. Bgp hijacking classification. In *2019 Network Traffic Measurement and Analysis Conference (TMA)*, pages 25–32. IEEE, 2019.

[71] Andrea Continella, Mario Polino, Marcello Pogliani, and Stefano Zanero. There's a hole in that bucket! a large-scale analysis of misconfigured s3 buckets. In *Proceedings of the 34th Annual Computer Security Applications Conference*, pages 702–711, 2018.
[72] Chris C Demchak and Yuval Shavitt. China's maxim-leave no access point unexploited: The hidden story of china telecom's bgp hijacking. *Military Cyber Affairs*, 3(1):7, 2018.

[73] Zakir Durumeric, Eric Wustrow, and J Alex Halderman. Zmap: Fast internet-wide scanning and its security applications. In *USENIX Security Symposium*, volume 8, pages 47–53, 2013.

[74] Cameron Ero. The bucket list: Experiences operating S3 honeypots. In *BSidesSF*, 2018.

[75] Daniele Faraglia and Other Contributors.mas. https://github.com/joke2k/faker. Accessed: 2023-05-30.

[76] Artyom Gavrichenkov. Breaking https with bgp hijacking. *Black Hat. Briefings*, 2015.

[77] Elizabeth Izhikevich. *Building and Breaking Burst-Parallel Systems*. University of California, San Diego, 2018.

[78] Liz Izhikevich, Renata Teixeira, and Zakir Durumeric. LZR: Identifying unexpected Internet services. In *USENIX Security Symposium*, 2021.

[79] Liz Izhikevich, Manda Tran, Michalis Kallitsis, Aurore Fass, and Zakir Durumeric. Cloud watching: Understanding attacks against cloud-hosted services. In *Proceedings of the 2023 ACM on Internet Measurement Conference*, pages 313–327, 2023.

[80] Christopher Kiekintveld, Viliam Lisý, and Radek Píbil. Game-theoretic foundations for the strategic use of honeypots in network security. In *Cyber warfare*, pages 81–101. Springer, 2015.

[81] Lilia Elena Gonzalez Medina. A brazilian trojan using a jar file, vb scripts and a dll for its multi-stage infection. https://www.fortinet.com/blog/threat-research/a-brazilian-trojan-using-a-jar-file-vb-scripts-and-a-dll-for-its-multi-stage-infection. Accessed on 2022-12-01.

[82] Ariana Mirian, Joe DeBlasio, Stefan Savage, Geoffrey M Voelker, and Kurt Thomas. Hack for hire: Exploring the emerging market for account hijacking. In *The World Wide Web Conference*, pages 1279–1289, 2019.

[83] Moorer. Pastebin bucket-stream-permutation-feature. https://pastebin.com/RpUkywbV, 2018. Accessed: 2023-05-26.

[84] Jon Oberheide, Manish Karir, and Z Morley Mao. Characterizing dark dns behavior. In *International*

*Conference on Detection of Intrusions and Malware, and Vulnerability Assessment*, pages 140–156. Springer, 2007.

[85] Michel Oosterhof. Cowrie SSH and Telnet Honeypot. https://github.com/cowrie/cowrie. Accessed: 2023-05-30.

[86] Eric Pauley and Patrick McDaniel. Understanding the ethical frameworks of internet measurement studies.

[87] Vasile Claudiu Perta, M Barbera, Gareth Tyson, Hamed Haddadi, Alessandro Mei, et al. A glance through the vpn looking glass: IPv6 leakage and dns hijacking in commercial vpn clients. 2015.

[88] Audrey Randall, Enze Liu, Ramakrishna Padmanabhan, Gautam Akiwate, Geoffrey M Voelker, Stefan Savage, and Aaron Schulman. Home is where the hijacking is: understanding dns interception by residential routers. In *Proceedings of the 21st ACM Internet Measurement Conference*, pages 390–397, 2021.

[89] Maitreya Ranganath and Mark Keating. How to detect suspicious activity in your aws account by using private decoy resources. https://aws.amazon.com/blogs/security/how-to-detect-suspicious-activity-in-your-aws-account-by-using-private-decoy-resources/, 2022. [Accessed on: 2023-10-31].

[90] Thomas Ristenpart, Eran Tromer, Hovav Shacham, and Stefan Savage. Hey, you, get off of my cloud: Exploring information leakage in third-party compute clouds. In *Proceedings of the 16th ACM Conference on Computer and Communications Security*, CCS '09, pages 199–212, New York, NY, USA, 2009. ACM.

[91] Koen Rouwhorst. s3enum. https://github.com/koenrh/s3enum, 2021. Accessed: 2023-05-26.

[92] Vikas Shah, Ganesh Sundaresan, and Lee Kear. Enforcing ownership of amazon s3 objects in a multi-account environment. https://aws.amazon.com/blogs/storage/enforcing-ownership-of-amazon-s3-objects-in-a-multi-account-environment/, 2021. [Accessed on: 2023-10-31].

[93] Raffaele Sommese, Mattijs Jonker, and KC Claffy. Observable kindns: validating dns hygiene. In *Proceedings of the 22nd ACM Internet Measurement Conference*, pages 740–741, 2022.

[94] Treebuilder. S3 mining. https://github.com/treebuilder/s3-mining/blob/master/s3.py, 2017. Accessed: 2023-05-26.
[95] Johanna Ullrich, Katharina Krombholz, Heidelinde Hobel, Adrian Dabrowski, and Edgar Weippl. {IPv6} security: Attacks and countermeasures in a nutshell. In *8th USENIX Workshop on Offensive Technologies (WOOT 14)*, 2014.

[96] Nino van Hooff. How to download files that others put in your aws s3 bucket. https://medium.com/artificial-industry/how-to-download-files-that-others-put-in-your-aws-s3-bucket-2269e20ed041, 2019. [Accessed on: 2023-10-31].

[97] Pierre-Antoine Vervier, Olivier Thonnard, and Marc Dacier. Mind your blocks: On the stealthiness of malicious bgp hijacks. In *NDSS*, 2015.

[98] Anil Yelam, Shibani Subbareddy, Keerthana Ganesan, Stefan Savage, and Ariana Mirian. Coresident evil: Covert communication in the cloud with lambdas. In *Proceedings of the Web Conference 2021*, pages 1005–1016, 2021.

## A Appendix

We provide additional details regarding our honeybucket deployment, analysis, and results from Section 3 and Section 4.

<table><caption>Table 8: **Leaking Bucket Names**—We leaked alphanumeric names of length 16 on a variety of platforms—public media, DNS, email—to measure if scanning actors are harvesting candidate names from passive sources.</caption><thead><tr><td>Leaking service</td><td>How buckets are leaked</td></tr></thead><tbody><tr><td>Github repository</td><td>Both links in README.md</td></tr><tr><td>Pastebin</td><td>One link per paste</td></tr><tr><td>Twitter</td><td>One link in a tweet</td></tr><tr><td>Lab website</td><td>Both links in HTML</td></tr><tr><td>Google's DNS</td><td>Query link's A Record</td></tr><tr><td>Spectrum's DNS</td><td>Query link's A Record</td></tr><tr><td>AT&T's DNS</td><td>Query link's A Record</td></tr><tr><td>Open DNS (Russian AS12714)</td><td>Query link's A Record</td></tr><tr><td>Open DNS (Chinese AS4134)</td><td>Query link's A Record</td></tr><tr><td>Gmail drafts</td><td>Both links in email</td></tr></tbody></table>

<table><caption>Table 9: **Most Common Bucket Interactions**—The majority of bucket-IP pairs only checked for the bucket’s existence, but did not pursue further action. Note, the respective bucket-IP pairs listed completed *only* those operations.</caption><thead><tr><td>Operation</td><td>Occurence (n=12233)</td><td>Rolling sum</td></tr></thead><tbody><tr><td>Check bucket existence</td><td>59.23% (7246)</td><td>59.23%</td></tr><tr><td>List bucket directory</td><td>29.03% (3551)</td><td>88.26%</td></tr><tr><td>Get object metadata</td><td>2.49% (305)</td><td>90.75%</td></tr><tr><td>1. Check bucket existence, 2. List bucket directory</td><td>1.51% (185)</td><td>92.26%</td></tr><tr><td>Upload object</td><td>1.37% (167)</td><td>93.63%</td></tr><tr><td>Fail to download an object</td><td>0.89% (109)</td><td>94.52%</td></tr><tr><td>1. Check bucket existence, 2. Get ACL</td><td>0.83% (102)</td><td>95.35%</td></tr><tr><td>1. List bucket directory, 2. Fail to download an object</td><td>0.76% (93)</td><td>96.11%</td></tr><tr><td>Successfully download an object</td><td>0.62% (76)</td><td>96.73%</td></tr><tr><td>1. Get ACL, 2. Check bucket existence</td><td>0.36% (44)</td><td>97.09%</td></tr></tbody></table>

### A.1 Bucket Scanning Ecosystem Experiment

In Section 3, we conducted an initial experiment to broadly study the bucket scanning ecosystem. In Table 8, we describe the platforms on which we leak our random alpha-numeric buckets. In Table 11, we list the exact names of all honeybuckets. For brevity, we exclude the exact names of the
40 random-alphanumeric buckets that we leaked on various platforms.

In Table 9, we provide a general breakdown of the most popular operations performed by actors. Notably, 60% of all operations only checked for the bucket's existence and 30% only listed the files in a bucket without pursuing a further action (e.g., downloading a file). In Table 10, we provide information about the 14 unique files that were uploaded by other users. We give the exact name of the file; an abbreviated description of its contents; whether the upload is a warning, malicious, or appears to serve no purpose; and the number of buckets the file appeared in. To protect researchers from any harm these unsolicited uploads may cause, researchers should download files in a protected and isolating computer environment to minimize the potential for harm introduced by these unsolicited uploads. However, simply listing the bucket contents can be done on a research machine.

## A.2 Informative Document

In Section 4, we conducted a follow-up experiment with additional lures, to understand to what extent will actors engage with the content they download. We provide the exact text of the Informative Document, which is uploaded to all honeybuckets, below.

```
## Financial Analytics Storage Quick Start
## This private storage bucket is used as a temporary mechanism to transfer data from the on-premise storage server to the client. Transaction data provided is only from the past three months. For security reasons, each csv file is zip encrypted. See Encryption Key Access tounzip. To provide the client with more historical data, an analysis consultant must manually copy the data from the on-premise storage server to the storage bucket.
## Login instructions:
## To access the storage server, add the following entry to your ~/.ssh/config file.
Host transaction\_storage
Hostname 35.162.99.242
User bain\_fin\_analytics
``

```
## Password Instructions:
## Concatenate your unique 3-digit token with the secure numeric key, like so:
## <token>62514653

If you do not have your unique 3-digit token, please ask your manager or email fanalytics.bain.IT@gmail.com.
## Encryption Key Access:
```

```
Once logged into the server, navigate to "/etc/s3\_zip\_encrypt", in which the encryption key can be found.
## Data transfer instructions:
## Once logged into the server, navigate to "/mnt/transactions/<client name>/raw/", in which the raw historical data will be found. Transferring data to and from the storage server can be done through the following command:

```
'aws s3 sync /path/to/dir/ s3://COMPANY\_BUCKET'
```

## A.3 Fortune 500 Companies

In Table 12, we list the set of companies we name our buckets after from Section 4. We separate buckets that do and do not have vulnerability disclosure programs, as well as indicate whether a monetary bug bounty is offered.

## A.4 Identifying Colluding IPs

In Algorithm 1, we present the pseudocode to detect all cases of likely-colluding events from Section 4.2.3. Algorithm 1 takes in as input (1) an IP address and (2) a token associated with the IP address. The algorithm outputs a set of likely colluding IPs.
**Algorithm 1:** find_colluding_ips(IP, token):
    // extract filename from token
    if token==valid SSH password then
        file = unhash(token)
    end
    else if token==informative doc then
        file = token
    else
        return // IP did not download a file or SSH
    end
    // base case: no collusion
    if time('IP lists directory') < time('IP downloads file') then
        return IP // the IP listed directory for itself
    end
    // get time of first download
    first_download=MIN(logs[logs['ips']==IP][time])
    // get bucket of first download
    bucket=logs[logs['time']==first_download ('bucket_name')]
    // find if download was successful
    successful_download=
    logs[logs['time'] ==first_download] ['error']
    // get upload time
    upload_time =get upload_time (file)
    // get deletion time
    delete_time=upload_time + 1 hour
    if successful_download then
        cut_off=first_download // file not deleted by
download time
    end
    if successful_download then
        cut_off=delete_time // file already deleted by
download time
    end
    // get all directory-listing IPs
    ips_list_dir= logs[logs['operation'] == 'list directory'] ['ips']
    for i in ips_list_dir do
        // if directory listing between upload and cut
        off time, mark colluding_ips
        if logs[logs['ips'] ==i] ['time'] ≥ upload_time &
        logs[logs['ips'] ==i] ['time'] ≤ cut_off then
            colluding_ips.append(i)
        end
    end
    return colluding_ips

<table><caption>Table 2: Top 20 Buckets With The Most Attempted Operations—Five out of six buckets named after Tesla experienced the most attempted operations.</caption><thead><tr><th>Bucket name</th><th>Type</th><th># Ops</th><th># IPs</th></tr></thead><tbody><tr><td>teslaproduction</td><td>Company</td><td>2538</td><td>467</td></tr><tr><td>teslapublic</td><td>Company</td><td>1620</td><td>355</td></tr><tr><td>tesladownload</td><td>Company</td><td>1601</td><td>375</td></tr><tr><td>teslasecurity</td><td>Company</td><td>1470</td><td>339</td></tr><tr><td>teslaprivate</td><td>Company</td><td>1456</td><td>342</td></tr><tr><td>origin-www</td><td>TGA<br>(DNSpop)</td><td>1379</td><td>349</td></tr><tr><td>612</td><td>TGA<br>(DNSpop)</td><td>1312</td><td>446</td></tr><tr><td>lyncc discover</td><td>TGA<br>(DNSpop)</td><td>980</td><td>278</td></tr><tr><td>www-download</td><td>TGA<br>(Pastebin)</td><td>894</td><td>323</td></tr><tr><td>walmartproduction</td><td>Company</td><td>872</td><td>170</td></tr><tr><td>tinderproduction</td><td>Company</td><td>755</td><td>178</td></tr><tr><td>ucsdprivate</td><td>Universities</td><td>747</td><td>143</td></tr><tr><td>fbiproduction</td><td>Government</td><td>627</td><td>179</td></tr><tr><td>www-slack</td><td>TGA<br>(Pastebin)</td><td>604</td><td>260</td></tr><tr><td>www-security</td><td>TGA<br>(Pastebin)</td><td>572</td><td>220</td></tr><tr><td>screenshots-www</td><td>TGA<br>(Pastebin)</td><td>552</td><td>245</td></tr><tr><td>tinderpublic</td><td>Company</td><td>542</td><td>139</td></tr><tr><td>tinderdownload</td><td>Company</td><td>527</td><td>129</td></tr><tr><td>walmartsecurity</td><td>Company</td><td>516</td><td>133</td></tr><tr><td>ciaproduction</td><td>Government</td><td>508</td><td>151</td></tr></tbody></table>
<table><caption>Table 3: Traffic Across Bucket-Types—Buckets named after companies experienced the most traffic on average both overall and per day. Statistically significant increases of traffic per day, relative to all other types buckets that experienced less average traffic per day, are marked with a *. For example, while university buckets did not experience statistically significantly more traffic than government buckets, government buckets did experience significantly more traffic than all bucket types except for company buckets.</caption><thead><tr><th rowspan="3">Type</th><th>IPs</th><th>ASNs</th><th>IPs</th><th>ASNs</th></tr><tr><th colspan="4" style="text-align:center;"># unique on average per bucket</th></tr><tr><th colspan="2" style="text-align:center;">total</th><th colspan="2" style="text-align:center;">per day</th></tr></thead><tbody><tr><td>Companies</td><td>195.39</td><td>35.72</td><td>1.63*</td><td>1.44*</td></tr><tr><td>Universities</td><td>133.83</td><td>20.75</td><td>1.27</td><td>1.19</td></tr><tr><td>Government</td><td>100.22</td><td>19.5</td><td>1.08*</td><td>1.04*</td></tr><tr><td>Non-sensitive Keywords</td><td>74.50</td><td>15.00</td><td>0.95</td><td>0.90</td></tr><tr><td>Sensitive Keywords</td><td>43.50</td><td>8.50</td><td>0.74</td><td>0.72</td></tr><tr><td>Cryptocurrency</td><td>27.75</td><td>7.75</td><td>0.56*</td><td>0.54*</td></tr><tr><td>TGA - filtered</td><td>12.67</td><td>12.67</td><td>0.42*</td><td>0.46*</td></tr><tr><td>Leaked</td><td>6.17</td><td>3.22</td><td>0.46*</td><td>0.45</td></tr><tr><td>Control</td><td>1.17</td><td>1.17</td><td>0.44</td><td>0.44*</td></tr></tbody></table>
<table><caption>Table 4: **The Impact of Bucket Name Construction on Received Scans**—Buckets that contained the keyword “production” were targeted by more unique IP addresses than buckets containing any other keyword, no matter the organization.</caption><thead><tr><th rowspan="2">Name</th><th colspan="6"># Unique IPs Targeting Org-Keyword Bucket</th><th rowspan="2">Total</th></tr><tr><th>production</th><th>download</th><th>public</th><th>private</th><th>security</th><th>hidden</th></tr></thead><tbody><tr><td>Tesla</td><td>467</td><td>375</td><td>355</td><td>342</td><td>339</td><td>8</td><td>1886</td></tr><tr><td>Walmart</td><td>170</td><td>142</td><td>140</td><td>139</td><td>133</td><td>8</td><td>732</td></tr><tr><td>Tinder</td><td>178</td><td>129</td><td>139</td><td>125</td><td>108</td><td>5</td><td>684</td></tr><tr><td>Public University</td><td>130</td><td>131</td><td>128</td><td>143</td><td>129</td><td>3</td><td>664</td></tr><tr><td>Private University</td><td>163</td><td>173</td><td>162</td><td>158</td><td>158</td><td>3</td><td>817</td></tr><tr><td>FBI</td><td>179</td><td>122</td><td>119</td><td>116</td><td>127</td><td>4</td><td>667</td></tr><tr><td>CIA</td><td>151</td><td>116</td><td>116</td><td>117</td><td>118</td><td>4</td><td>622</td></tr><tr><td>NYPD</td><td>78</td><td>78</td><td>76</td><td>78</td><td>78</td><td>3</td><td>391</td></tr><tr><td>Total</td><td>1516</td><td>1266</td><td>1235</td><td>1218</td><td>1190</td><td>38</td><td>6463</td></tr></tbody></table>

<table><caption>Table 5: **Authenticated User Activity**— We present a list (8 out of 27) of all authenticated users who used non-alphanumeric usernames (omitting their unique account ID for brevity). The majority of authenticated users used only one IP address to scan, only visited buckets of one type (e.g., TGA, company), and did not interact with bucket content.</caption><thead><tr><th>User</th><th>IPs used</th><th>ASN</th><th>Buckets Visited</th><th>Operations</th></tr></thead><tbody><tr><td>user/energi-0001</td><td>103.157.116.108/32</td><td>Cloud Teknologi (137331)</td><td>All DNSpop</td><td>Check exist, List dir., Get ACL</td></tr><tr><td>assumed-role/...<br>Admin.../xbotusr</td><td>12 IPs in<br>148.177.96/24</td><td>DC Protection (198949)</td><td>"origin-www" (DNSpop)</td><td>Get ACL</td></tr><tr><td>user/Admin</td><td>186.29.129.113/32<br>190.25.111.135/32</td><td>ETB (19429)</td><td>"612" (DNSpop)</td><td>List dir., Get ACL</td></tr><tr><td>user/bref-cli</td><td>159.89.129.123/32</td><td>DIGITAL OCEAN (14061)</td><td>"lyncdiscover" (DNSpop)</td><td>Check exist, List dir., Get ACL</td></tr><tr><td>user/Administrator</td><td>143.238.166.88/32</td><td>Telstra (1221)</td><td>"origin-www" (DNSpop)<br>"lyncdiscover" (DNSpop)</td><td>Check exist, List dir., Get ACL</td></tr><tr><td>user/s3bug</td><td>103.105.154.178/32</td><td>Global Ra Net (135692)</td><td>3/4 Tinder buckets</td><td>Get ACL</td></tr><tr><td>user/bug</td><td>103.79.171.204/32</td><td>MNR Broadband (133648)</td><td>"tinderpublic"</td><td>List dir., Upload object</td></tr><tr><td>user/pudsec</td><td>216.126.238.240/32</td><td>Hostodo (399804)</td><td>"612" (DNSpop)</td><td>Check exist, List dir., Get ACL</td></tr></tbody></table>
<table><caption>**Table 6: Company Attribute Impact On Scanning—**
Buckets that were named after companies with vulnerability disclosure programs (VDPs), or were in the technology sector, attracted statistically significantly more IP addresses. Statistically significant increases of a metric, relative to all metrics with a smaller average value, are marked with a *.</caption><thead><tr><th>Company Attribute</th><th>Avg IPs per bucket</th></tr></thead><tbody><tr><td>Has VDP</td><td>17.75*</td></tr><tr><td>No VDP</td><td>10.78</td></tr><tr><td>Technology</td><td>28.19*</td></tr><tr><td>Healthcare</td><td>16.20</td></tr><tr><td>Transportation</td><td>16.00</td></tr><tr><td>Financials</td><td>15.69</td></tr><tr><td>Retail</td><td>10.25</td></tr><tr><td>Chem./Energy/Industrial</td><td>8.78</td></tr><tr><td>Eng./Construction/Materials</td><td>5.83</td></tr><tr><td>Aerospace/Defense</td><td>5.50</td></tr><tr><td>Business Services</td><td>4.00</td></tr></tbody></table>

<table><caption>**Table 7: Top 10 Most Scanned Buckets—**Over 58% of the total number of IPs scanned the top 10 buckets, which spanned six companies. Every company, except Polaris, has a vulnerability disclosure program.</caption><thead><tr><th>Bucket Name</th><th># Unique IPs</th></tr></thead><tbody><tr><td>americanexpressdownload</td><td>139</td></tr><tr><td>americanexpressproduction</td><td>140</td></tr><tr><td>oracledownload</td><td>112</td></tr><tr><td>intuitproduction</td><td>55</td></tr><tr><td>oracleproduction</td><td>54</td></tr><tr><td>intuitdownload</td><td>46</td></tr><tr><td>nvidiadownload</td><td>44</td></tr><tr><td>nvidiaproduction</td><td>44</td></tr><tr><td>targetdownload</td><td>43</td></tr><tr><td>polarisproduction</td><td>42</td></tr><tr><td>Total</td><td>719 (58.55 %)</td></tr></tbody></table>

<table><caption>**Table 10: Uploaded Files With Content—**A total of 18 unique files were uploaded, of which only two were warning us that our buckets were misconfigured. Four files had malicious code and six files were inaccessible due to the uploader not permitting the read operation. Note that an additional 206 files were also uploaded, of which 91.3% were of size zero.</caption><thead><tr><th>File Name</th><th>Description</th><th>Category</th><th># Up.</th></tr></thead><tbody><tr><td>'upload.png'</td><td>Warning</td><td>Warn</td><td>1</td></tr><tr><td>'s3sec.txt'</td><td>Warning</td><td>Warn</td><td>1</td></tr><tr><td>'poc.jsp/'</td><td>reverse shell</td><td>Mal</td><td>5</td></tr><tr><td>'_snapshot/test'</td><td>request /etc/password</td><td>Mal</td><td>5</td></tr><tr><td>'_snapshot/test2'</td><td>request /etc/password</td><td>Mal</td><td>5</td></tr><tr><td>'test-file.svg'</td><td>re-direct to (ngrok.io)</td><td>Mal</td><td>1</td></tr><tr><td>'bucket.png'</td><td>No access</td><td>-</td><td>1</td></tr><tr><td>'test'</td><td>No access</td><td>-</td><td>1</td></tr><tr><td>'test.txt'</td><td>No access</td><td>-</td><td>1</td></tr><tr><td>'indexx.html'</td><td>No access</td><td>-</td><td>1</td></tr><tr><td>'hello.txt'</td><td>No access</td><td>-</td><td>1</td></tr><tr><td>'s3-test.txt'</td><td>No access</td><td>-</td><td>1</td></tr><tr><td>'xss.svg'</td><td>image</td><td>Benign</td><td>1</td></tr><tr><td>'xss1.svg'</td><td>image</td><td>Benign</td><td>1</td></tr><tr><td>'Read.txt'</td><td>pen-test doc [44]</td><td>Benign</td><td>1</td></tr><tr><td>'testfile-nullg0re.txt'</td><td>"this is a test"</td><td>Benign</td><td>4</td></tr><tr><td>'test-test-nullg0re.txt'</td><td>"this is a test"</td><td>Benign</td><td>1</td></tr><tr><td>'testfile'</td><td>"this is a test"</td><td>Benign</td><td>1</td></tr></tbody></table>
<table><caption>Table 11: **Bucket Names**—A list of bucket names from our first experiment from Section 3, in which we broadly studied the bucket scanning ecosystem. For brevity, we exclude the 40 alphanumeric leaked buckets.</caption><thead><tr><th>Type</th><th>Bucket name</th></tr></thead><tbody><tr><td>Cryptocurrency</td><td>bitcoin-confidential<br>bitcoin-secret<br>ethereum-wallet<br>ethereum-passwords</td></tr><tr><td>Sensitive Keywords</td><td>passport10<br>bank10</td></tr><tr><td>Non-sensitive keywords</td><td>pretty10<br>pictures10</td></tr><tr><td>DNSpop TGA</td><td>lyncdiscover<br>612<br>origin-www<br>liboyulecheng</td></tr><tr><td>Slurp TGA</td><td>advogado<br>applogie<br>blognovo<br>click1mail</td></tr><tr><td>Pastebin TGA</td><td>screenshots-www<br>www-slack<br>www-download<br>www-security</td></tr><tr><td>Comparison Set<br>(not in any TGA)</td><td>confidentialfiles<br>dont-open<br>ignore-me<br>pretty-pictures</td></tr><tr><td>Organization</td><td>teslaproduction, tesladownload<br>teslapublic, teslaprivate<br>teslasecurity, teslahidden<br>walmartproduction, walmartdownload<br>walmartpublic, walmartprivate<br>walmartsecurity, walmarthidden<br>tinderproduction, tinderdownload<br>tinderpublic, tinderprivate<br>tindersecurity, tinderhidden<br>ucsdproduction<br>ucsddownload<br>ucsdpublic<br>ucsdpriate<br>ucsdssecurity<br>ucsdhidden<br>stanfordproduction<br>stanforddownload<br>stanfordpublic<br>stanfordprivate<br>stanfordsecurity<br>stanfordhidden<br>fbiproduction, fbidownload<br>fbipublic, fbiprivate<br>fbisecurity, fbihidden<br>ciaproduction, ciadownload<br>ciapublic, ciaprivate<br>ciasecurity, ciahidden<br>nypdproduction, nypddownload<br>nypdpublic, nypdprivate<br>nypdsecurity, nypdhidden</td></tr></tbody></table>
<table><caption>Table 12: **Company Names**—The final list of companies we used in naming our buckets, with each name concatenated with 'download' and 'production' (e.g. 3mproduction, 3mdownload). The names indicated with a * were originally Comcast and Equinix. In the vulnerability disclosure program column we cite the source explaining the company's vulnerability disclosure program and indicate with a $ if the company has a monetary bug bounty.</caption><thead><tr><th colspan="3">Vulnerability Disclosure Program</th><th colspan="2">No Vulnerability Disclosure Program</th></tr><tr><th>Name</th><th>Rank</th><th>Vulnerability Disclosure Program</th><th>Name</th><th>Rank</th></tr></thead><tbody><tr><td>CVS Health</td><td>4</td><td>$ [18]</td><td>Raytheon Technologies</td><td>58</td></tr><tr><td>United Health Group</td><td>5</td><td>[53]</td><td>Charter Communications</td><td>69</td></tr><tr><td>Target</td><td>32</td><td>[47]</td><td>Tyson Foods</td><td>81</td></tr><tr><td>State Farm Insurance</td><td>42</td><td>[45]</td><td>3M</td><td>102</td></tr><tr><td>Pfizer</td><td>43</td><td>[40]</td><td>Applied Materials</td><td>156</td></tr><tr><td>General Electric</td><td>48</td><td>[24]</td><td>Lithia Motors</td><td>158</td></tr><tr><td>Goldman Sachs Group</td><td>57</td><td>$ [25]</td><td>Hartford Financial Services</td><td>160</td></tr><tr><td>HCA Healthcare</td><td>62</td><td>[27]</td><td>Lincoln National</td><td>187</td></tr><tr><td>Deere</td><td>84</td><td>[19]</td><td>Wesco International</td><td>200</td></tr><tr><td>American Express</td><td>85</td><td>[6]</td><td>L3 Harris Technologies</td><td>206</td></tr><tr><td>TIAA</td><td>90</td><td>[48]</td><td>Automatic Data Processing</td><td>242</td></tr><tr><td>*Oracle</td><td>91</td><td>[38]</td><td>Pioneer Natural Resources</td><td>248</td></tr><tr><td>USAA</td><td>96</td><td>$ [51]</td><td>Pulte Group</td><td>267</td></tr><tr><td>Northwestern Mutual</td><td>97</td><td>[36]</td><td>Oreilly Automotive</td><td>279</td></tr><tr><td>Capital One Financial</td><td>108</td><td>[13]</td><td>Rocket Companies</td><td>282</td></tr><tr><td>Nvidia</td><td>134</td><td>[37]</td><td>Vistra</td><td>315</td></tr><tr><td>PNC Financial Services</td><td>178</td><td>[41]</td><td>Unum Group</td><td>317</td></tr><tr><td>Charles Schwab</td><td>188</td><td>[15]</td><td>Altice USA</td><td>355</td></tr><tr><td>Otis Worldwide</td><td>254</td><td>[39]</td><td>ODP</td><td>379</td></tr><tr><td>Discover Financial Services</td><td>281</td><td>[21]</td><td>Delek US Holdings</td><td>346</td></tr><tr><td>Carvana</td><td>290</td><td>[14]</td><td>Univar Solutions</td><td>369</td></tr><tr><td>Tractor Supply</td><td>294</td><td>[49]</td><td>Burlington Stores</td><td>377</td></tr><tr><td>Keurig Dr Pepper</td><td>296</td><td>[30]</td><td>Jefferies Financial Group</td><td>387</td></tr><tr><td>CSX</td><td>298</td><td>[17]</td><td>Polaris</td><td>419</td></tr><tr><td>Boston Scientific</td><td>319</td><td>[11]</td><td>MasTec</td><td>429</td></tr><tr><td>Booking Holdings</td><td>340</td><td>$ [10]</td><td>GXO Logistics</td><td>430</td></tr><tr><td>*Intuit</td><td>366</td><td>[29]</td><td>Westinghouse Air Brake Tech</td><td>439</td></tr><tr><td>Dover</td><td>433</td><td>[22]</td><td>Hertz Global Holdings</td><td>462</td></tr><tr><td>Analog Devices</td><td>463</td><td>[7]</td><td>Graphic Packaging Holding</td><td>466</td></tr><tr><td>Regions Financial</td><td>489</td><td>[42]</td><td>Landstar System</td><td>491</td></tr></tbody></table>