Katherine Izhikevich

U C San

Diego Geoffrey

M Voelker

Diego Stefan Savage

Liz Izhikevich

Using Honeybuckets to Characterize Cloud Storage Scanning in the Wild

In this work, we analyze to what extent actors target poorlysecured 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.

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 [START_REF] Barr | Celebrate 15 years of amazon s3 with 'pi week' livestream events[END_REF]. 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 [START_REF] Ero | The bucket list: Experiences operating S3 honeypots[END_REF] 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 [START_REF] Cable | Stratosphere: Finding vulnerable cloud storage buckets[END_REF].

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 [START_REF]Misconfigured aws s3 bucket leaks 36,000 inmate records[END_REF][START_REF]S3 misconfiguration exposes sensitive data on more than 3 million senior citizens[END_REF][START_REF]Uk data protection regulator receiving 'large number of reports' about capital[END_REF][START_REF]A cyberattack illuminates the shaky state of student privacy[END_REF][START_REF]A huge data leak of 1 billion records exposes china's vast surveillance state | techcrunch[END_REF][START_REF]Microsoft leaked 2.4tb of data belonging to sensitive customer. critics are furious[END_REF], 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 filename 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 [START_REF]Grayhat warfare[END_REF] (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.

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 [START_REF]Aws S3 actions[END_REF].

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 [START_REF]A huge data leak of 1 billion records exposes china's vast surveillance state | techcrunch[END_REF]-can use one of several scanning methodologies. The simplest bucket scanners rely on a pre-defined list of strings and patterns (e.g., Slurp [START_REF] Bharath | Slurp's S3 string formatting permuations[END_REF], s3enum [START_REF] Rouwhorst | s3enum[END_REF], and BucketStream [START_REF] Moorer | Pastebin bucket-stream-permutation-feature[END_REF]), tailored towards targeting likelypopular 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 [START_REF]Bucket of staging files after deploying an app engine[END_REF]. Continella et al. show that some such names can be identified using passive DNS collection services [START_REF] Continella | There's a hole in that bucket! a large-scale analysis of misconfigured s3 buckets[END_REF] (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 [START_REF] Cable | Stratosphere: Finding vulnerable cloud storage buckets[END_REF].

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. [START_REF] Continella | There's a hole in that bucket! a large-scale analysis of misconfigured s3 buckets[END_REF] and Cable et al. [START_REF] Cable | Stratosphere: Finding vulnerable cloud storage buckets[END_REF] found thousands of public buckets that exposed sensitive data, including private keys and national defense documents. Ero [START_REF] Ero | The bucket list: Experiences operating S3 honeypots[END_REF] 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 [START_REF] Antonakakis | Understanding the mirai botnet[END_REF][START_REF] Bock | Weaponizing middleboxes for {TCP} reflected amplification[END_REF][START_REF] Izhikevich | LZR: Identifying unexpected Internet services[END_REF], IPv6 address space [START_REF] Barrera | Back to the future: revisiting ipv6 privacy extensions[END_REF][START_REF] Vasile Claudiu Perta | A glance through the vpn looking glass: Ipv6 leakage and dns hijacking in commercial vpn clients[END_REF][START_REF] Ullrich | {IPv6} security: Attacks and countermeasures in a nutshell[END_REF], cloud compute services [START_REF] Izhikevich | Building and Breaking Burst-Parallel Systems[END_REF][START_REF] Izhikevich | Cloud watching: Understanding attacks against cloud-hosted services[END_REF][START_REF] Ristenpart | Hey, you, get off of my cloud: Exploring information leakage in third-party compute clouds[END_REF][START_REF] Yelam | Coresident evil: Covert communication in the cloud with lambdas[END_REF], DNS [START_REF] Gautam Akiwate | Retroactive identification of targeted dns infrastructure hijacking[END_REF][START_REF] Randall | Home is where the hijacking is: understanding dns interception by residential routers[END_REF][START_REF] Sommese | Observable kindns: validating dns hygiene[END_REF], and BGP [START_REF] Cho | Bgp hijacking classification[END_REF][START_REF] Chris | China's maximleave no access point unexploited: The hidden story of china telecom's bgp hijacking[END_REF][START_REF] Gavrichenkov | Breaking https with bgp hijacking[END_REF][START_REF] Vervier | Mind your blocks: On the stealthiness of malicious bgp hijacks[END_REF]. In these other environments, researchers have also used honeypots-infrastructure deployed for the purpose of detecting malicious behavior [START_REF] Kiekintveld | Game-theoretic foundations for the strategic use of honeypots in network security[END_REF]-to characterize IPv4 scanning [START_REF] Kippo | [END_REF][START_REF]T-pot -the all in one multi honeypot platform[END_REF][START_REF] Oosterhof | Cowrie SSH and Telnet Honeypot[END_REF], email security [START_REF] Mirian | Hack for hire: Exploring the emerging market for account hijacking[END_REF] and DNS activity [START_REF] Oberheide | Characterizing dark dns behavior[END_REF]. 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.

Pilot study: How Buckets Are Targeted

This section describes our pilot1 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.

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 bucket names, permissions, and contents to attract bucketscanning 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 [START_REF] Cable | Stratosphere: Finding vulnerable cloud storage buckets[END_REF]. We do not use AWS decoy resources [START_REF] Ranganath | How to detect suspicious activity in your aws account by using private decoy resources[END_REF], as these decoys neither provide bucket naming schemes nor sample content.

Bucket Names

Scanning buckets is not a trivial task. The enormous searchspace 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 [START_REF] Bharath | Slurp's S3 string formatting permuations[END_REF], DNSpop [START_REF] Bitquark | Dnspop[END_REF], and bucketstream-permutation-feature [START_REF] Moorer | Pastebin bucket-stream-permutation-feature[END_REF]. 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-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 created 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", "public") 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 content, rather than a specific entity, they might scan for buckets 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 keywords 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. 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- 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.

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 [START_REF]Access control list (acl) overview[END_REF]), 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.

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 [START_REF] Faraglia | Faker[END_REF]. 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 [START_REF] Elena | A brazilian trojan using a jar file, vb scripts and a dll for its multi-stage infection[END_REF] 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.

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).

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 significantly4 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 5 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 "fbisecurity").

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 [START_REF] Cable | Stratosphere: Finding vulnerable cloud storage buckets[END_REF]. 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.

Bucket Interactions and Abuse

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 nonabusive bucket interactions in Appendix A.1, which often consists of checking a bucket's existence and/or listing files.

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.

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, 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. 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 [START_REF]Choopa -fraud risk[END_REF][START_REF]-fraud risk[END_REF]. HostRoyale's clients are known to use its anonymizing VPN services [START_REF]Hostroyale -fraud risk[END_REF].

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 these questions.

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.

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 enterprisethemed naming scheme, (2) buckets contained an informative document that tracked the longevity of information postdownload, and (3) bucket content used a unique identifier that helped track actors who used multiple IPs.

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 [START_REF][END_REF]. 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. 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- 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 [START_REF]Vulnerability disclosure programs among the fortune 500[END_REF].

ownload"). Table 12 in the Appendix lists the names of all chosen companies,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.

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 [START_REF] Faraglia | Faker[END_REF]. 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, 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 followup 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 goal, in the document we also included an SSH username, password, and IP address for a Cowrie SSH honeypot [START_REF] Oosterhof | Cowrie SSH and Telnet Honeypot[END_REF] 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 address, 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 individual 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 concatenating the password with a hash of the current timestamp. 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 different IP addresses to list directory contents and download individual files. To attract actors to our informative document, we named the informative document 'secure-encryption-sshquickstart-{unix time}.txt' to attract downloads with its enticing name. Relative to all other bucket content, the document'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 document in Appendix A.2.

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 configuration, in this experiment actors were only allowed to (1) list the bucket directory, (2) download all objects, and (3) upload 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 automatically owned by the uploader [START_REF] Shah | Enforcing ownership of amazon s3 objects in a multi-account environment[END_REF][START_REF] Nino Van Hooff | How to download files that others put in your aws s3 bucket[END_REF]. Deleting objects was forbidden.

Results

In this section, we use the increased lures and tracking capabilities to further understand how bucket scanners operate. We start by investigating what kinds of companies lured the most actors and found a significantly increased number of actors and significantly increased amount of abusive behavior correlated with companies with a vulnerability 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 actors 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 purportedly 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).

Understanding Company Targets

Buckets that contained the names of companies with a vulnerability disclosure program ("VDP companies") were statistically significantly 12 more likely to be scanned. Table 6 presents the number of IP addresses who scanned different categories of companies. On average, VDP-company buckets 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 majority (6/8) of the abusive SSH behavior (Section 4.2.4). Our results are consistent with previous work [START_REF] Aaltonen | Does the outsider help? the impact of bug bounty programs on data breaches[END_REF] 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 attract 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 frequently).

Additionally, buckets with names of companies in the technology sector were statistically significantly 13 more likely to be scanned by unique IPs compared to any other sector. Buckets named after technology companies 14 were scanned by 74% more IPs on average than healthcare buckets, 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 correlation 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 mostscanned buckets were both named after American Express, which has a VDP. Unique actors consistently scanned American Express buckets throughout our experiment.

Six out of the top ten most-scanned buckets were named after technology companies, and nine were named after companies with a VDP.

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 instigated 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 thirdparty 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,[START_REF]Amazon guardduty features[END_REF]. 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.

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 filenames (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 likelycolluding 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 " 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).

(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.

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 [START_REF] Durumeric | Zmap: Fast internet-wide scanning and its security applications[END_REF] and, in most countries, civil and criminal law as well. 16 To put this another way, there is no motivation that excuses an attempt to use purloined credentials to gain 16 For example, in the US unauthorized access of this form is a violation of 18 USC 1030, the Computer Fraud and Abuse Act. 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. 17Using 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 Cloudvider (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 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 [START_REF]Netspi[END_REF]. While Net-SPI used the SSH credentials found in TIAA's bucket, we do not find public evidence that TIAA is a customer of Net-SPI. 18 However, even if TIAA were a customer of Net-SPI 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. 19

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).

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 [START_REF] Pauley | Understanding the ethical frameworks of internet measurement studies[END_REF].

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 that included organizational names. Thus, organizationalnamed buckets could only be found by those actively and blindly guessing the names (minimizing any potential for confusion). Second, we provided multiple paths for resolving 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 normal 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 removed 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 login attempts from the attackers who sought to exploit our seemingly misconfigured buckets.

Recommendations

Our work demonstrates that buckets named after commercial entities are actively targeted and exploited. Defending against cloud storage attackers is simple: configure buckets with sensitive information to be private. Unfortunately, prior work [START_REF] Continella | There's a hole in that bucket! a large-scale analysis of misconfigured s3 buckets[END_REF] has shown that thousands of buckets remain publicly exposed with sensitive information. Furthermore, over time, buckets are more likely to be misconfigured [START_REF] Cable | Stratosphere: Finding vulnerable cloud storage buckets[END_REF]. 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 itselfas 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., [START_REF]Defending assets you don't know about, against cyberattacks[END_REF]), 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 [START_REF]Brandshield | anti-phisihing solutions[END_REF]) 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 [START_REF]Attack surface management and data solutions[END_REF]) weigh the risk of exposed bucket exploitation 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.

Conclusion

Actors scan and abuse the information found in cloud storage buckets. We deployed honeybuckets across two different experiments to measure how actors scan for buckets. Buckets 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 concerning, we found that actors read and exploited the contents 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 customers to track and secure their misconfigured buckets. honeybucket or SSH-server. We will also share the sourcecode used to identify colluding IPs. 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' %%%%%%%%%%%%%%% Questions: %%%%%%%%%%%%%%% For all other questions, email fanalytics.bain.IT@gmail.com.

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. 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 types except for company buckets.

Figure 1 :

 1 Figure1: Identifying Colluding IP Addresses-We identified colluding IPs using the causal dependencies created by hourlyupdated 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).

Table 1 :

 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.

	File name	Content	Unique Unique Down-
			IPs	ASNs	loads
	Client_list_	Fake	88	56	160
	Dec_2021	names,
		SSNs,
		addresses
	Backup.pst	Sensitive	69	47	155
		mail
		folder
		names
	README1	AAA...	64	41	127
	Outlook.pst	Sensitive	54	34	110
		mail
		folder
		names
	README2	Empty	53	32	112
		File
	id_ed25519	SSH	53	31	117
		private
		key
	Inbox.mbox Google	50	32	107
		Takeout
		backup
	UTC...	UTC	48	30	112
		Wallet
	javazoom.jar Benign	41	21	103
		jar
		file

Table 11 :

 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.

We use the results of the pilot study to inform a refined experiment in Section 4.

We also considered s3enum[START_REF] Rouwhorst | s3enum[END_REF] and s3Mining[START_REF]Treebuilder[END_REF], but after comparing outputs we found that their generated bucket names were proper subsets of the other TGAs.

We used sensitive keywords defined by the U.S. Justice Department[START_REF]Protecting yourself while using the internet[END_REF] and non-sensitive keywords defined by the disjoint set of those sensitive keywords and the top 1000 most common English words [1].

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 stochasticlly 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.[START_REF]Amazon guardduty features[END_REF] The majority of actors used a single IP address when scanning (Section 4).

We calculated statistical significance using the methodology from Section 3.2.1.

Amazon allows users to be unauthenticated, which is when a user does not have an AWS account[START_REF]Access control list (acl) overview[END_REF] or when an authenticated user adds the flag "-no-sign-request" to their command line argument[START_REF]Access s3 public data without credentials[END_REF].

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.

During bucket deployment, we encountered an already-existing bucket, "Blackrockproduction". We replaced Blackrock with another randomlychosen Fortune 500 company.

[START_REF]Boston scientific vulnerability disclosure program[END_REF] 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 (Table12) that fit our criteria from Section 4.1.1.

We used the same one-sided Mann-Whitney U methodology from Section 3.

[START_REF]Capital one financial vulnerability disclosure program[END_REF] Accounting for Bonferroni correction, the Mann-Whitney U methodology only returns significant p-values for sample sizes greater than 10. Thus, the following company sectors were excluded from statistical analysis: Healthcare (10 buckets total), Transportation[START_REF]Attack surface management and data solutions[END_REF], Engineering (6), Aerospace (4), and Business

Services (2).[START_REF]Carvana vulnerability disclosure program[END_REF] We determine sector by using the Fortune 500 sector label.

Indeed, to the best of our knowledge, neither the AWS security investigator, Detective [4], nor the AWS threat detection service, GuardDuty[START_REF]Amazon guardduty features[END_REF], specifically monitor for buckets hosting exposed sensitive data.

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-emails insisting on a reward. We note that USAA, which operates a monetary VDP[START_REF]Usaa vulnerability disclosure program[END_REF], belongs to the category of organizations that attract the most scanning traffic.

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[START_REF]Netspi[END_REF][START_REF]Netspi expands[END_REF].

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.

Data Availability

To promote reproducibility, upon request, we will share with researchers all raw data collected during this work's experiments. Raw data will include logs of all scans that target any

A Appendix

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

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 Algorithm 1: find_colluding_ips(IP,token): 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.