Multifactor Authentication Hacking is Getting Real

June 2020 ยท 10 minute read

Bad Actors are Validating SMS Targets at Scale

TL;DR - in a hurry? Jump to the Summary at the bottom of the post!

I work for a company that protects online accounts and that automates account takeover detection and remediation. Needless to say, I’m well aware of the scale of attacks using account credentials. Many people share a password or three across most their online accounts, or they fall back to creating a pattern for their passwords (such as P@ssw0rdGoogle or P@ssw0rdAmazon). When a security breach occurs and leaks email addresses and passwords, these users are likely to see their accounts get hacked on other internet sites.

Security-aware customers, or security-enforcing applications, will use some form of MFA to verify logins that look suspicious. Most often, this is an email-based or SMS-based second factor. Unfortunately, this pattern is well known by bad actors, and there are stories about million-plus dollar losses when fraudsters were able to cleverly hack the user-enabled MFA.

In this post I describe firsthand how I was able to dissect a clever scheme by which bad actors are learning two important things:

  1. Which breached user phone numbers might be used for multifactor authentication
  2. Which users can be tricked into clicking links sent to them in text messages

These pieces of information are very valuable to any person or organization that is preparing to commit fraud on a massive scale. Obviously, users that fall for this scheme are at greater risk of fraudulent account takeover.

Think like a Bad Actor

Bad Actors can buy massive sets of credentials online for cheap. Recently, Zoom was in the news because half a million Zoom user passwords were available for sale on the dark web. Zoom wasn’t at fault for this credential set; rather, many Zoom users re-used old passwords when they created their Zoom accounts. In addition to passwords, more user details are frequently available in dark web data:

Usually, the places from which user info was leaked (such as Equifax) are not the targets of future attacks. Organizations that leak user info usually shore up their defenses after discovering a breach. However, this fails to protect the end users from malicious or fraudulent activities resulting from future abuse of their leaked info.

The value of a validated SMS target

Bad actors know that many people only have one cell phone number. So it stands to reason that if they can verify that number as an SMS target, the number is likely to be used for multifactor authentication across the user’s online accounts. The number is probably being used for bank accounts, investment accounts, email accounts, gaming accounts, high-security work-related logins, etc.

Bad actors will want to minimize the amount of “dead ends” they’ll hit when it comes to hacking an MFA process. They’ll also be interested in minimizing future costs when they attempt to take over accounts. So it makes sense that they would want to narrow down their user data to a subset of users for whom they know a likely cell number. This way, future attacks can try to phish for text message one-time passcodes, or they may even try to perform some kind of Sim Swap scam.

Case-in-Point - Suspicious Text Messages Received

Now, let’s examine the specific example that initiated my deep-dive into this topic.

Over the past 2 days, I’ve received a few curious text messages. Each message came from a different US-based phone number with a unique area code. Each message was similar - something about a reward from Amazon being shipped to me:

Shipped: Your Amazon package with $100 loyalty reward will be delivered Tue, June 9th. Track at g8smv.info/{{unique-identifier}}

note: there was a real string in place of {{unique-identifier}} - I’ve removed it for my own privacy and sanity reasons

Red flags numbers 1 and 2:

  1. I rarely order things from Amazon and I most certainly have never expected a $100 loyalty reward.
  2. The text came from a US-based phone number, and not a short code number. All my prior texts from Amazon came from short code numbers

Being the curious and security-aware engineer that I am, I decided to do a bit of digging into this message.

Investigation Steps

TL;DR: This section spells out my research. Skip to What the Heck is Going On if you’re not interested in the super technical details.

Step 1 - Who Owns the Suspicious Domain?

The first place to start was to find out who owns the g8smv.info domain. I opened my terminal and typed in whois g8smv.info. The domain is registered by namecheap.com, and the registrant’s address is in Panama.

Red flag number 3: Amazon is a US-based company (amazon.com is registered to their hostmaster address in Nevada). Panama is not the US.

Step 2 - Where does the Link Point?

What can we learn about the suspicious link, g8smv.info/{{unique-identifier}}? Typing dig g8smv.info ANY +noall +answer gives me a few new details:

Red flag number 4: The IP target for the suspicious link is handled by Alibaba, which is Amazon’s biggest global competitor (many think of it as China’s version of Amazon). Alibaba offers cloud hosting services much like AWS - I will later explain why this makes attack like these so easy.

Step 3 - What Happens when the Link is Clicked?

Here’s the most suspenseful part! So what does the link actually do? Does it install malware on my phone? Does it try to log into my Amazon account?

I should give a word of caution here - don’t click a link like this directly. You could expose your location, phone or computer make and model, and you could become a victim of a zero-day browser exploitation.

Using the command line again to investigate the link, I can type curl -v g8smv.info/{{unique-identifier}} and I see a very, very simple response.

The Link is a 302 Redirect to Google.com. Like, the real http://google.com. That’s it

What the Heck is Going On?

As far as I can tell, the entire purpose of this suspicious text message was to see if I would click the link. Knowing what I know about cloud infrastructure providers such as Alibaba, AWS, Google Cloud, I think I have a good understanding of what is going on.

The bad actor knows that the user accounts of online services they want to hack use SMS-secured logins. These could be Amazon accounts, bank accounts, email accounts, gaming accounts, or others where the accounts are secured by 2-factor authentication via SMS text message. The bad actor has a list of user account details that they bought on the dark web, and they’re trying to figure out whether that list has accurate phone numbers.

Because the link in the suspicious text message is a redirect to Google, there was no work needed to build or run an application server. The bad actor is likely using an API Gateway to return a gateway response to all links of the format http://g8smv.info/*. This makes it extremely easy to record the clicked links in log files for the API Gateway, with ultra-fast deployment and bare minimal costs in infrastructure. I’m talking pennies for millions of link-clickings.

Let’s connect the dots of the bad actor’s attack plan:

  1. Obtain list of user account details from a data breach involving 100,000 accounts. Breached user data includes email, password, and phone number.
  2. Identify which users on the list should be targeted for account takeover attempts at the target internet sites. This results in 10,000 targets.

Obviously, I was identified as a target of an attack that began 2 days ago. Perhaps the bad actor is planning a future attack on Amazon accounts (since the text message context was about Amazon).

  1. Set up an API Gateway to accept all requests that point to http://g8smv.info/*. Enable a default gateway response that returns a status of 302 and a Location: http://www.google.com header to all requests. Enable logs on the gateway to record the path of each incoming request.
  2. Send 10,000 SMS messages like the one I received to each phone number on the narrowed target list. Generate a different {{unique-identifier}} for each phone number.
  3. Wait a day after all the SMS messages are sent, then download the logs that contain the {{unique-identifier}} paths that were clicked as a result of the SMS campaign.
  4. Determine which users were gullible in this attack, and therefore should be targets of future fraud involving SMS-based MFA.

Just like that, the bad actor knows which phone numbers are likely to be registered by the user for SMS-based 2-factor authentication

Cost-Benefit Analysis of the Attack

As I mentioned previously, setting up an API gateway costs pennies per millions of requests. SMS messages cost less than a penny each when sent by a cloud service provider. It probably takes a bit more set-up cost to register phone numbers to be associated with the SMS sending service, but I’d bet that we’re still looking at a cost of less than $0.05, or an American nickel, for each user that was sent an SMS message. In our example with 10,000 SMS messages sent, this means the bad actor paid a total cost of less than $500 to send these text messages.

Even if only 1% of users fall victim to a single account takeover resulting from this attack, the value of the resulting fraud only needs to be $5.00 per account hacked in order to break even.

If 1% of targets are ultimately hacked, and the average value of a hacked account is $1,000, the attack turns a 20,000% profit.

Summary

My own research into a series of suspicious text messages that I received resulted in very interesting findings. The messages were constructed to fool me into clicking a link, which they said would tell me about a reward coming my way. The reward was related to Amazon, where I am a customer.

The domain for the link in the messages is owned by a masked entity in Panama, and the domain name itself is nonsensical. The link points to an IP address that is owned by Alibaba, a huge Chinese company that is a direct competitor to Amazon. Alibaba offers cloud computing services, including an API Gateway. Clicking the link in the suspicious text messages gives me an HTTP redirect to Google’s home page. This is an easy configuration to set up via an API Gateway, and such a configuration allows for handling extremely high traffic volume, with very fast global response times, at extremely low cost. I think that the clicks of these suspicious text message links are being logged for the purpose of identifying users that will be targeted for future fraudulent and malicious purposes involving SMS. A bad actor can pay pennies per SMS message to run this kind of SMS target-validation campaign.

Conclusion

I want to be clear that using SMS-based authentication is still a very good thing for most use-cases. The moral here is that you should never, ever click a link sent to you from a strange source. This goes for text messages, email, and any other methods.

For those readers that are building applications, authenticating users, and investigating fraud, we all need to be aware that bad actors are persistent and intelligent, and their tactics are ever-evolving. Start thinking about identity-verification solutions that go beyond SMS and email workflows.