# Using Honeybuckets to Characterize Cloud Storage Scanning in the Wild

Katherine Izhikevich
Stefan Savage
University of California San Diego  University of California San Diego  Geoff
Voelker
Liz Izhikevich  University of California San Diego  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 [63]. 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 [73] 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 [68].

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
[57, 58, 59, 33, 42, 49], 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 [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 [58]—can use one of several scanning
methodologies. The simplest bucket scanners rely on a pre-defined list of
strings and patterns (e.g., Slurp [65], s3enum [90], and BucketStream [82]),
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 [55]. Continella _et al._ show that some such names can
be identified using passive DNS collection services [70] (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 [68].

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._ [70] and Cable _et
al._ [68] found thousands of public buckets that exposed sensitive data,
including private keys and national defense documents. Ero [73] 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 [62, 67,
77], IPv6 address space [64, 86, 94], cloud compute services [76, 89, 97, 78],
DNS [61, 87, 92], and BGP [69, 71, 75, 96]. In these other environments,
researchers have also used honeypots—infrastructure deployed for the purpose
of detecting malicious behavior [79]—to characterize IPv4 scanning [31, 45,
84], email security [81] and DNS activity [83]. 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 pilot111We use the results of the pilot study to
inform a refined experiment in Section 4. 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
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 [68]. We do not use AWS decoy resources [88],
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 XI.

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 [65], DNSpop [66], and
bucket-stream-permutation-feature [82].222We also considered s3enum [90] and
s3Mining [93], but after comparing outputs we found that their generated
bucket names were proper subsets of the other TGAs.  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.333We used sensitive keywords defined by
the U.S. Justice Department [54] and non-sensitive keywords defined by the
disjoint set of those sensitive keywords and the top 1000 most common English
words [1]. 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.

TABLE I: 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 |  |  |

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.

####  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 I 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 [74]. 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 [80] 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

TABLE II: Top 20 Buckets With The Most Attempted Operations—Five out of six buckets named after Tesla experienced the most attempted operations.  Bucket name | Type | # Ops | # IPs
---|---|---|---
teslaproduction | Company | 2538 | 467
teslapublic | Company | 1620 | 355
tesladownload | Company | 1601 | 375
teslasecurity | Company | 1470 | 339
teslaprivate | Company | 1456 | 342
origin-www | TGA | 1379 | 349
| (DNSpop) |  |
612 | TGA | 1312 | 446
| (DNSpop) |  |
lyncdiscover | TGA | 980 | 278
| (DNSpop) |  |
www-download | TGA | 894 | 323
| (Pastebin) |  |
walmartproduction | Company | 872 | 170
tinderproduction | Company | 755 | 178
ucsdprivate | Universities | 747 | 143
fbiproduction | Government | 627 | 179
www-slack | TGA | 604 | 260
| (Pastebin) |  |
www-security | TGA | 572 | 220
| (Pastebin) |  |
screenshots-www | TGA | 552 | 245
| (Pastebin) |  |
tinderpublic | Company | 542 | 139
tinderdownload | Company | 527 | 129
walmartsecurity | Company | 516 | 133
ciaproduction | Government | 508 | 151
TABLE III: 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.  Type | IPs | ASNs | IPs | ASNs
---|---|---|---|---
| # unique on average per bucket
| total | per day
Companies | $195.39$ | $35.72$ |  $1.63$* |  $1.44$*
Universities | $133.83$ | $20.75$ | $1.27$ | $1.19$
Government | $100.22$ | $19.5$ |  $1.08$* |  $1.04$*
Non-sensitive | $74.50$ | $15.00$ | $0.95$ | $0.90$
Keywords |  |  |  |
Sensitive | $43.50$ | $8.50$ | $0.74$ | $0.72$
Keywords |  |  |  |
Cryptocurrency | $27.75$ | $7.75$ |  $0.56$* |  $0.54$*
TGA | $12.67$ | $12.67$ |  $0.42$* |  $0.46$*
\- filtered |  |  |  |
Leaked | $6.17$ | $3.22$ |  $0.46$* | $0.45$
Control | $1.17$ | $1.17$ | $0.44$ |  $0.44$*

Buckets named after companies were scanned with the most number of operations
and IP addresses. Table II 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 III 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 significantly444We 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. 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 address555The majority of actors used a single IP address when
scanning (Section 4). 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 III, 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).

TABLE IV: 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. Name | # Unique IPs Targeting Org-Keyword Bucket
---|---
| production | download | public | private | security | hidden | Total
Tesla | 467 | 375 | 355 | 342 | 339 | 8 | 1886
Walmart | 170 | 142 | 140 | 139 | 133 | 8 | 732
Tinder | 178 | 129 | 139 | 125 | 108 | 5 | 684
Public | 130 | 131 | 128 | 143 | 129 | 3 | 664
University |  |  |  |  |  |  |
Private | 163 | 173 | 162 | 158 | 158 | 3 | 817
University |  |  |  |  |  |  |
FBI | 179 | 122 | 119 | 116 | 127 | 4 | 667
CIA | 151 | 116 | 116 | 117 | 118 | 4 | 622
NYPD | 78 | 78 | 76 | 78 | 78 | 3 | 391
Total | 1516 | 1266 | 1235 | 1218 | 1190 | 38 | 6463

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 III). Among the buckets associated with organizations, bucket names
concatenated with the word “production” were scanned the most. Table IV 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 [68]. 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 II), 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 X 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 I). We did not find any file to
have a statistically significantly666We calculated statistical significance
using the methodology from Section 3.2.1. greater number of downloads 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 [43].

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 I

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

TABLE V: 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. User | IPs used | ASN | Buckets Visited | Operations
---|---|---|---|---
user/energi-0001 | 103.157.116.108/32 | Cloud Teknologi (137331) | All DNSpop | Check exist, List dir.,
|  |  |  | Get ACL
assumed-role/… | 12 IPs in | DC Protection (198949) | “origin-www” (DNSpop) | Get ACL
Admin…/xbotusr | 148.177.96/24 |  |  |
user/Admin | 186.29.129.113/32 | ETB (19429) | “612” (DNSpop) | List dir., Get ACL
| 190.25.111.135/32 |  |  |
user/bref-cli | 159.89.129.123/32 | DIGITAL OCEAN (14061) | “lyncdiscover” (DNSpop) | Check exist, List dir.,
|  |  |  | Get ACL
user/Administrator | 143.238.166.88/32 | Telstra (1221) | “origin-www” (DNSpop) | Check exist, List dir.,
|  |  | “lyncdiscover” (DNSpop) | Get ACL
user/s3bug | 103.105.154.178/32 | Global Ra Net (135692) | 3/4 Tinder buckets | Get ACL
user/bug | 103.79.171.204/32 | MNR Broadband (133648) | “tinderpublic” | List dir., Upload object
user/pudsec | 216.126.238.240/32 | Hostodo (399804) | “612” (DNSpop) | Check exist, List dir.,
|  |  |  | Get ACL

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,777Amazon
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]. allowing the user to remain anonymous.
However, 27 actors authenticated themselves, and eight used non-alphanumeric
usernames. Table V 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.888The 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. 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
V). 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 [32, 16]. 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 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.999This 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 [53].

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 “carvanadownload”). Table XII in the
Appendix lists the names of all chosen companies,101010During bucket
deployment, we encountered an already-existing bucket, “Blackrockproduction”.
We replaced Blackrock with another randomly-chosen Fortune 500 company. 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 [74]. 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,111111After 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 XII) that fit our criteria from Section 4.1.1. 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 goal, in the document we also included an SSH username,
password, and IP address for a Cowrie SSH honeypot [84] 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-ssh-quickstart-{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.

####  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 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 [91, 95]. Deleting objects was forbidden.

###  4.2 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
VII).

We found that certain scanners used VPNs, prompting us to develop a scalable
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).

####  4.2.1 Understanding Company Targets

TABLE VI: 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 *.  Company Attribute | Avg IPs per bucket
---|---
Has VDP |  $17.75$*
No VDP | $10.78$
Technology |  $28.19$*
Healthcare | $16.20$
Transportation | $16.00$
Financials | $15.69$
Retail | $10.25$
Chem./Energy/Industrial | $8.78$
Eng./Construction/Materials | $5.83$
Aerospace/Defense | $5.50$
Business Services | $4.00$
TABLE VII: 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. Bucket Name | # Unique IPs
---|---
americanexpressdownload | 139
americanexpressproduction | 140
oracledownload | 112
intuitproduction | 55
oracleproduction | 54
intuitdownload | 46
nvidiadownload | 44
nvidiaproduction | 44
targetdownload | 43
polarisproduction | 42
Total | 719 (58.55 %)

Buckets that contained the names of companies with a vulnerability disclosure
program (“VDP companies”) were statistically significantly121212We used the
same one-sided Mann-Whitney U methodology from Section 3. more likely to be
scanned. Table VI 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 [60] 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 significantly131313Accounting 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 (8),
Engineering (6), Aerospace (4), and Business Services (2). more likely to be
scanned by unique IPs compared to any other sector. Buckets named after
technology companies141414We determine sector by using the Fortune 500 sector
label. 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 VII 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.

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 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 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].151515Indeed, 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.
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.

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

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:

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

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

  3. 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 III the number of unique IPs
that visited a bucket per day—let alone per hour—is often too low (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 [72] and, in most
countries, civil and criminal law as well. 161616For example, in the US
unauthorized access of this form is a violation of 18 USC 1030, the Computer
Fraud and Abuse Act. 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. 171717The 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 [50], belongs to
the category of organizations that attract the most scanning traffic.

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 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
[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.181818While 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 [51]. 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 [56].

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.191919Moreover, 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.

###  4.3 Summary

Actor engagement with company buckets increased with the presence of a
vulnerability disclosure program (Section VII). 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 [85].

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

##  6 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 [70] has shown that thousands of buckets remain
publicly exposed with sensitive information. Furthermore, over time, buckets
are more likely to be misconfigured [68]. 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. BrandShield [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 VII). 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 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.

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

## 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 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 — cybersecrurity.  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-phisihing 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] Northwestern mutual vdp.  https://bugcrowd.com/northwestern-vdp/.  Accessed on 2023-05-23.
  * [36] Nvidia vulnerability disclosure program.  https://www.nvidia.com/en-us/security/psirt-policies/.  Accessed on 2023-05-23.
  * [37] Oracle vulnerability disclosure program.  https://www.oracle.com/corporate/security-practices/assurance/vulnerability/disclosure.html.  Accessed on 2023-05-23.
  * [38] Otis worldwide vulnerability disclosure program.  https://www.otis.com/en/uk/cyber-security.  Accessed on 2023-05-23.
  * [39] Pfizer vulnerability disclosure program.  https://hackerone.com/pfizer?type=team.  Accessed on 2023-05-23.
  * [40] Pnc financial services group vulnerability disclosure program.  https://www.pnc.com/en/security-privacy/responsible-disclosure-program.html.  Accessed on 2023-05-23.
  * [41] 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.
  * [42] 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.
  * [43] s3sec.  https://github.com/0xmoot/s3sec.  Accessed: 2023-05-13.
  * [44] State farm insurance vulnerability disclosure program.  https://www.statefarm.com/customer-care/privacy-security/security/vulnerability-disclosure-policy.  Accessed on 2023-05-23.
  * [45] T-pot - the all in one multi honeypot platform.  https://github.com/telekom-security/tpotce.  Accessed on 2023-05-23.
  * [46] Target vulnerability disclosure program.  https://security.target.com/vdp.  Accessed on 2023-05-23.
  * [47] 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.
  * [48] Tractor supply vulnerability disclosure program.  https://www.tractorsupply.com/policies-information_customer-solutions_responsible-disclosure-statement.  Accessed on 2023-05-23.
  * [49] 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.
  * [50] Usaa vulnerability disclosure program.  https://bugcrowd.com/usaa.  Accessed on 2023-05-23.
  * [51] Venturebeat: Netspi expands.  https://venturebeat.com/security/pentesting-firm-netspi-expands-into-attack-surface-management/amp/.  Accessed: 2023-05-04.
  * [52] Vulnerability disclosure program.  https://www.optum.com/business/vulnerability.html#:~:text=Bug%20Bounties,in%20accordance%20with%20this%20policy. Accessed on 2023-05-23.
  * [53] 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.
  * [54] Protecting yourself while using the internet.  https://www.justice.gov/usao-ndga/protecting-yourself-while-using-internet, 2015.  [Accessed on: 2023-11-01].
  * [55] Bucket of staging files after deploying an app engine.  https://stackoverflow.com/questions/42947918/bucket-of-staging-files-after-deploying-an-app-engine, 2017.
  * [56] 31173 services ab.  https://www.31173.se/, 2022.  Accessed: 2023-05-20.
  * [57] 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.
  * [58] 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.
  * [59] 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.
  * [60] 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.
  * [61] 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.
  * [62] 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.
  * [63] 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.
  * [64] 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.
  * [65] Bharath.  Slurp’s S3 string formatting permuations.  https://github.com/0xbharath/slurp/blob/master/permutations.json, 2018.  Accessed: 2023-05-26.
  * [66] Bitquark.  Dnspop.  https://github.com/bitquark/dnspop/blob/master/results/bitquark_20160227_subdomains_popular_1000000, 2016.  Accessed: 2023-05-26.
  * [67] 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.
  * [68] 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.
  * [69] 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.
  * [70] 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.
  * [71] 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.
  * [72] 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.
  * [73] Cameron Ero.  The bucket list: Experiences operating S3 honeypots.  In BSidesSF, 2018.
  * [74] Daniele Faraglia and Other Contributors.  Faker.  https://github.com/joke2k/faker.  Accessed: 2023-05-30.
  * [75] Artyom Gavrichenkov.  Breaking https with bgp hijacking.  Black Hat. Briefings, 2015.
  * [76] Elizabeth Izhikevich.  Building and Breaking Burst-Parallel Systems.  University of California, San Diego, 2018.
  * [77] Liz Izhikevich, Renata Teixeira, and Zakir Durumeric.  LZR: Identifying unexpected Internet services.  In USENIX Security Symposium, 2021.
  * [78] 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.
  * [79] 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.
  * [80] 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.
  * [81] 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.
  * [82] Moorer.  Pastebin bucket-stream-permutation-feature.  https://pastebin.com/RpUkywbV, 2018.  Accessed: 2023-05-26.
  * [83] 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.
  * [84] Michel Oosterhof.  Cowrie SSH and Telnet Honeypot.  https://github.com/cowrie/cowrie.  Accessed: 2023-05-30.
  * [85] Eric Pauley and Patrick McDaniel.  Understanding the ethical frameworks of internet measurement studies.
  * [86] 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\.
  * [87] 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.
  * [88] 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].
  * [89] 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.
  * [90] Koen Rouwhorst.  s3enum.  https://github.com/koenrh/s3enum, 2021.  Accessed: 2023-05-26.
  * [91] 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].
  * [92] 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.
  * [93] Treebuilder.  S3 mining.  https://github.com/treebuilder/s3-mining/blob/master/s3.py, 2017.  Accessed: 2023-05-26.
  * [94] 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.
  * [95] 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].
  * [96] Pierre-Antoine Vervier, Olivier Thonnard, and Marc Dacier.  Mind your blocks: On the stealthiness of malicious bgp hijacks.  In NDSS, 2015.
  * [97] 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.

##  Appendix A Appendix

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

TABLE VIII: 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. Leaking service | How buckets are leaked
---|---
Github repository | Both links in README.md
Pastebin | One link per paste
Twitter | One link in a tweet
Lab website | Both links in HTML
Google’s DNS | Query link’s A Record
Spectrum’s DNS | Query link’s A Record
AT&T’s DNS | Query link’s A Record
Open DNS (Russian AS12714) | Query link’s A Record
Open DNS (Chinese AS4134) | Query link’s A Record
Gmail drafts | Both links in email
TABLE IX: 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. Operation | Occurence | Rolling
---|---|---
| (n=12233) | sum
Check bucket existence | 59.23% (7246) | 59.23%
List bucket directory | 29.03% (3551) | 88.26%
Get object metadata | 2.49% (305) | 90.75%
1.Check bucket existence, | 1.51% (185) | 92.26%
2\. List bucket directory |  |
Upload object | 1.37% (167) | 93.63%
Fail to download an object | 0.89% (109) | 94.52%
1.Check bucket existence, | 0.83% (102) | 95.35%
2.Get ACL |  |
1.List bucket directory, | 0.76% (93) | 96.11%
2.Fail to download an object |  |
Successfully download an object | 0.62% (76) | 96.73%
1.Get ACL, | 0.36% (44) | 97.09%
2.Check bucket existence |  |
TABLE X: 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. File Name | Description | Category | #
---|---|---|---
|  |  | Up.
‘upload.png’ | Warning | Warn | 1
‘s3sec.txt’ | Warning | Warn | 1
‘poc.jsp/’ | reverse shell | Mal | 5
‘_snapshot/test’ | request | Mal | 5
| /etc/password |  |
‘_snapshot/test2’ | request | Mal | 5
| /etc/password |  |
‘test-file.svg’ | re-direct to | Mal | 1
| (ngrok.io) |  |
‘bucket.png’ | No access | - | 1
‘test’ | No access | - | 1
‘test.txt’ | No access | - | 1
‘indexx.html’ | No access | - | 1
‘hello.txt’ | No access | - | 1
‘s3-test.txt’ | No access | - | 1
‘xss.svg’ | image | Benign | 1
‘xss1.svg’ | image | Benign | 1
‘Read.txt’ |  pen-test doc [43] | Benign | 1
‘testfile-nullg0re.txt’ | “this is a test” | Benign | 4
‘test-test-nullg0re.txt’ | “this is a test” | Benign | 1
‘testfile’ | “this is a test” | Benign | 1

###  A.1 Bucket Scanning Ecosystem Experiment

TABLE XI: 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. Type | Bucket name
---|---
Cryptocurrency | bitcoin-confidential
| bitcoin-secret
| ethereum-wallet
| ethereum-passwords
Sensitive Keywords | passport10
| bank10
Non-sensitive keywords | pretty10
| pictures10
DNSpop TGA | lyncdiscover
| 612
| origin-www
| liboyulecheng
Slurp TGA | advogado
| applogie
| blognovo
| click1mail
Pastebin TGA | screenshots-www
| www-slack
| www-download
| www-security
Comparison Set | confidentialfiles
(not in any TGA) | dont-open
| ignore-me
| pretty-pictures
Organization | teslaproduction, tesladownload
| teslapublic, teslaprivate
| teslasecurity, teslahidden
| walmartproduction, walmartdownload
| walmartpublic, walmartprivate
| walmartsecurity, walmarthidden
| tinderproduction, tinderdownload
| tinderpublic, tinderprivate
| tindersecurity, tinderhidden
| ucsdproduction
| ucsddownload
| ucsdpublic
| ucsdprivate
| ucsdsecurity
| ucsdhidden
| stanfordproduction
| stanforddownload
| stanfordpublic
| stanfordprivate
| stanfordsecurity
| stanfordhidden
| fbiproduction, fbidownload
| fbipublic, fbiprivate
| fbisecurity, fbihidden
| ciaproduction, ciadownload
| ciapublic, ciaprivate
| ciasecurity, ciahidden
| nypdproduction, nypddownload
| nypdpublic, nypdprivate
| nypdsecurity, nypdhidden

In Section 3, we conducted an initial experiment to broadly study the bucket
scanning ecosystem. In Table VIII, we describe the platforms on which we leak
our random alpha-numeric buckets. In Table XI, 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 IX, 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 X, 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
><EMAIL_ADDRESS>>     %%%%%%%%%%%%
>     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
><EMAIL_ADDRESS>>

###  A.3 Fortune 500 Companies

TABLE XII: 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.  Vulnerability Disclosure Program | No Vulnerability Disclosure Program
---|---
Name | Rank | Vulnerability | Name | Rank
|  | Disclosure |  |
|  | Program |  |
CVS Health | 4 |  $ [18] | Raytheon Technologies | 58
United Health Group | 5 | [52] | Charter Communications | 69
Target | 32 | [46] | Tyson Foods | 81
State Farm Insurance | 42 | [44] | 3M | 102
Pfizer | 43 | [39] | Applied Materials | 156
General Electric | 48 | [24] | Lithia Motors | 158
Goldman Sachs Group | 57 |  $ [25] | Hartford Financial Services | 160
HCA Healthcare | 62 | [27] | Lincoln National | 187
Deere | 84 | [19] | Wesco International | 200
American Express | 85 | [6] | L3 Harris Technologies | 206
TIAA | 90 | [47] | Automatic Data Processing | 242
Oracle | 91 | [37] | Pioneer Natural Resources | 248
USAA | 96 |  $ [50] | Pulte Group | 267
Northwestern Mutual | 97 | [35] | Oreilly Automotive | 279
Capital One Financial | 108 | [13] | Rocket Companies | 282
Nvidia | 134 | [36] | Vistra | 315
PNC Financial Services | 178 | [40] | Unum Group | 317
Charles Schwab | 188 | [15] | Altice USA | 355
Otis Worldwide | 254 | [38] | ODP | 379
Discover Financial Services | 281 | [21] | Delek US Holdings | 346
Carvana | 290 | [14] | Univar Solutions | 369
Tractor Supply | 294 | [48] | Burlington Stores | 377
Keurig Dr Pepper | 296 | [30] | Jefferies Financial Group | 387
CSX | 298 | [17] | Polaris | 419
Boston Scientific | 319 | [11] | MasTec | 429
Booking Holdings | 340 |  $ [10] | GXO Logistics | 430
Intuit | 366 | [29] | Westinghouse Air Brake Tech | 439
Dover | 433 | [22] | Hertz Global Holdings | 462
Analog Devices | 463 | [7] | Graphic Packaging Holding | 466
Regions Financial | 489 | [41] | Landstar System | 491

In Table XII, 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

// extract filename from token

if  _token==valid SSH password_ then

file = unhash(token)

end if

else if  _token==informative doc_ then

file = token

else

return // IP did not download a file or SSH

end if

// base case: no collusion

if  _$\mbox{time(`IP lists directory')} <\mbox{time(`IP downloads file')}$_
then

return IP // the IP listed directory for itself

end if

// 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

if  _!successful_download_ then

cut_off=delete_time // file already deleted by download time

end if

// 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’] $\geq$ upload_time &
logs[logs[‘ips’]==i][‘time’] $\leq$ cut_off_ then

colluding_ips.append(i)

end if

end for

return colluding_ips

Algorithm 1 find_colluding_ips(IP,token):

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.