Communications of the ACM

As mentioned previously, the website address was linked on the About Me section of the victim’s Facebook page. If an attacker was able to find the website via the Facebook page, this would be apparent in the network capture. The network capture would also show if any of the hacking attempts to the Google accounts were from the same IP addresses that were visiting the Web pages.

Legal and ethical considerations. Since this study involved engaging with actors that were performing illegal activities, there were legal and ethical questions to consider.

Legally, there were two concerns: unauthorized access into Google accounts and violating Google’s terms of service. In the U.S., as in many other countries, unauthorized access into an electronic account is illegal. Hiring services to perform this act could be considered aiding and abetting; however, since the email accounts were directly under our control and we were acting in collaboration with the service provider (Google), we were explicitly authorizing entities to access our accounts. Moreover, creating fake Google accounts violates Google’s terms of service, but this study was approved by both Google and the general counsel for UC San Diego, before the work was started.

Although this study is not considered human rights research by our institutional review board because we were measuring organizational behaviors and not behaviors of an individual, there were other ethical considerations. By creating fictitious victim and buyer personas, we removed the possibility of any individual being harmed during this study. Moreover, we interacted with these services within the scope of their terms and paid them if they were successful. We believe the lessons learned from this study outweigh the cost of supporting these services by paying them.

Hack-For-Hire Playbook

The controlled experiment and log-
ging infrastructure allowed examina-
tion of the playbook that attackers use
to take over a victim account. Only five
of the 27 services we contacted actually
attempted to break into the victim’s
Google account. Note that the “suc-
cess” of a hack-for-hire service was de-
pendent on our actions: in some cases,
the hack-for-hire services would attack
the associate as a way to gain access to
the victim. We also created a Facebook
page for the victim to see if the hack-
for-hire services would use it in their
attacks. All items on the Facebook page
were private (a public user would not be
able to see these items) except the About
Me section, where the victim’s Web page
was listed (as a personal advertisement
for the victim’s business).

Monitoring attacks. Because of uncertainty over which attack methods these hack-for-hire services would use, we created an extensive monitoring infrastructure that would inform us when an unauthorized user entered and modified the Google account. We also monitored the websites to record all visitors. This monitoring infrastructure contained: a Google app script for Gmail in every account; Google logs; and a network capture of all traffic to the fictitious websites.

The Google app script loaded into
Gmail for each account was a modifica-
tion from one used in a previous study. 11
The Google app script would send infor-
mation to a server controlled via a proxy
indicating whether the script was still
connected to the account and whether
there were any changes to the account.
For example, the Google app script
would indicate whether a new message
had appeared in the inbox or spam fold-
ers, if a message was moved to trash, or
if any messages marked as unread were
read by a user. This logging recorded the
actions of the attackers once they were
in the account.
We also were able to analyze any
login activity to our victim personas’
Google accounts. These logs, cap-
tured and analyzed by our Google col-
leagues, recorded login attempts into
the account and their origins, brute-
force attempts, and whether 2FA was
triggered on the account for a suspi-
cious login attempt.