Behind the scenes: Hack for hire services that hijack accounts
A few researchers from University of California, San Diego, hired account hijacking services to learn how they went about hacking into email accounts. They published their findings in a 2019 paper “Hack for hire: Exploring the emerging market for account hijacking” in which they explained the process of hiring these black market services, and their observations of how some attackers eventually managed to hijack accounts. I would say it’s a must read for all app developers, esp. those who create or deal with account logins.
In collaboration with Google, the researchers created honeypot Gmail accounts that they asked the attackers to take over. They provided information about the (fake) account owners. The researchers had set up 2FA on the accounts to see how the attackers would overcome that, which some of them were able to.
Summary of attack methodology
- Out of the five services, four used phishing to lure their targets and one sent an email with malware.
- The attackers created fake Gmail login page and sent the link through phishing emails. Their expectations was that the victims will provide their email address and password on the phishing pages.
- The services were sophisticated enough that after harvesting the credentials, they immediately attempted to log in to Gmail using those credentials.
- When they unexpectedly hit 2FA prompts, some of the services adapted. They asked the researchers to share the victim’s phone number, and then attempted to phish the victims again. This time, the phishing pages asked the victims to enter the 2FA code sent to their cell phone after the password page. Once the victim entered the codes, the attackers were able to successfully log in.
- After successfully logging in, the attackers removed account activity emails that Google sends so the victim will not find out about a potential account takeover. Additionally, they disabled 2FA which would have allowed them to log in again using only the password and not needing to phish the 2FA code again.
- The attackers were generally able to craft emails that would bypass Gmail’s spam detection. The researchers state that it is possible that the attackers created a few test accounts and first sent phishing emails to those accounts to check which emails would pass spam filters so those can be sent to the victims.
Why would someone click on the phishing email(s)?
- The attackers sent multiple emails with different types of lures waiting for the victims to click on any. Only one click is sufficient for account compromise.
- The researchers observed five types of allures: 1) an associate, 2) a stranger, 3) a bank, 4) Google, and 5) a government authority. Usually, they convey a sense of urgency so the victim would immediately click the links in the emails.
- Phishing email impersonating Google mimicked a real world warning that Google sends to inform users about device sign-ins.
Some additional thoughts
Even though this paper is from 2019, phishing is still a common method to hijack accounts. And even though accounts with 2FA can sometimes be hacked, it makes it much harder for the attackers to succeed. That’s why major email and cloud providers (Microsoft and Google included) strongly urge users to enable 2FA. As the paper explains, some services just backed out when they learnt that the accounts had 2FA enabled.
In general, luring in victims using time-sensitive threats is perhaps the most effective way to get cooperation. These have included threats of imprisonment or fines from the government, portraying that a loved one is in danger, appearing to provide (shady) services, or simply a message from someone familiar asking to click a link.
The paper also states that Google used forensics from these attacks to identify more than 300 other accounts which may have been attacked in a similar fashion.
As a software engineer who has also worked in the identity and security space, I would say that it’s extremely hard to secure accounts. Securing and protecting accounts requires a lot of investment that is often times unclear to the app developers. It’s not just creating a DB with usernames and password hashes. It’s similar to arms race in which tech companies are evolving more ways to detect and secure accounts, and bad actors are continuing to use whatever is at their disposal to hack into them. So, for most app developers, it’s usually best to either use a third-party identity platform like Okta, Azure AD B2C, Firebase, etc. or just integrate with social logins like Apple, Google and others.