User Scammed/Hacked past random pwd and SMS MFA

[Ahhzz]

I ran into this, and I'm looking to make sure exactly how the process broke. Can I get some input/feedback?
Client sent an email, appeared to be typical "Looks like our user, requested a change of banking info, please investigate". I scrolled down the email, and the address looked legit; decent spoof, I'll check headers. But first, go for the obvious: user sent it.
TAP to the sent box, nothing there, hit the deleted, nothing there, go to the "recovery", and there it is. "Oh crap, did they manage to get MFA disabled??!!" Blocked sign-in, revoked authenticators and sessions, changed the password. Called the user, and discussed while I went digging, and while in discussion, user reported they had "had to use their password earlier this week, or a few days ago", but couldn't remember where or why. Great.
Called management, explained the steps so far, and received permission to investigate and re-enable with extra reinforcement for phishing attacks. (after the discussion, I'm pretty sure the user won't put their password in *anywhere* for at least three months without calling me first).
After prompting and digging, determined the following:

• User had some junkware "Driver Updater" on laptop used at home over the weekend, was removed without verifying possibility of attack vector
• Password is a randomly generated >12 character mess: no dictionary words or leet speek
• Password is saved in Edge on "home" laptop for checking email
• Received a MFA SMS Monday afternoon, 1st day of account compromise, but user didn't see it/know it/request it
• Entra shows access from approx 2500 miles away near the opposite coast starting that day
• Client is a large company, multi-national, but not infra-structure critical, not F500, and the targeted user was a low-level employee in accounting: very little ability to change much, and the spoofed email request was out of the ordinary enough to prompt a phone call. in other words, neither the client nor the user were whale targets
• User is not a disgruntled employee, just a little absent minded, but not enough to not remember someone else asking for an MFA code... I think....
• None of the users for the company display the level of skill required to clone a phone, and absolutely none in the immediate physical area of the user have that skill level, and again: weak target, small fish
• Entra sign-in indicates
  • Authentication requirement Multifactor authentication
  • MFA requirement satisfied by claim in the token

Assuming either the user entered their password on a site I couldn't find in history, or it was scavenged from the browser remotely somehow, how would someone get past the MFA? and wth does the log mean : "requirement satisfied by the token"?
thanks!

 

[Chrispy_]

It broke because SMS isn't a valid 2FA and hasn't been for 4-5 years.

SMS is unencrypted and just about anyone with motivation can gain access to SMS data using freely-available toolkits that your average bad actor will have at their disposal.

I've been enforcing biometric 2FA for almost two years now, and I feel I was lucky that nobody using SMS had their account compromised before that!

The biggest shock to me is that Azure/Entra still allows SMS as an authentication method

 

[natr0n]

If I had to guess the hacker source might be from Indonesia. They are doing things like this lately.

 

[Bill_Bright]

Client sent an email, appeared to be typical "Looks like our user, requested a change of banking info, please investigate". I scrolled down the email, and the address looked legit; decent spoof, I'll check headers. But first, go for the obvious: user sent it.

This is a bank account? Is any money missing?

Obviously, a new password is required.

Then instruct client to request changes to the account via "Secure Messaging" from the bank's official website - not standard email.

 

[MentalAcetylide]

It sucks stuff like this happens; especially nowadays given how a lot of stuff is integrated. I'm all for the death penalty or life imprisonment when it comes to scumbags that commit cyber-crimes. As it is right now, there's just not enough of a deterrent punishment-wise.

The fact of the matter is if something is connected to the internet, it can be breached, regardless of the security.

 

[Ahhzz]

This is a bank account? Is any money missing?

Obviously, a new password is required.

Then instruct client to request changes to the account via "Secure Messaging" from the bank's official website - not standard email.

It was an email "from" the user to a vendor, asking to change the client's banking info, so the vendor would pay to the scammer's account. Did the password, revoked all sessions, etc.

SMS is unencrypted and just about anyone with motivation can gain access to SMS data using freely-available toolkits that your average bad actor will have at their disposal.

I knew it was unencrypted, but most of the end users weren't of a high enough visibility to push the resistance. Some of our users are low-hanging fruit, tho... and you pick enough bad apples, you can scrape together enough to make a decent pie....
I also wasn't aware of any easily available tools to scrape the SMS, the ones I recall tended to be countered pretty rapidly, so they weren't really used for the small fish. No reason to use dynamite on a 20 foot pond. But I haven't prowled in the back alleys lately. Time to gear up and take a stroll, I see.

 

[Bill_Bright]

It was an email "from" the user to a vendor, asking to change the client's banking info

Sorry if I'm a bit slow this morning.

If I understand correctly, this would be something like Amazon storing my "Payment methods" (my Visa credit card, for example) on their site. Then next time I order something, I don't have to enter the card number, name, and expiration date again. But if that card expires, or if I want to use my MasterCard instead, I would have to log into my account, then change that information. I would not "email" (or call) Amazon.

Or another example would be registering my check account information with PayPal so I can transfer money. If I decide to change banks, I would log into PayPal. I would not "email" PP.

Does this vendor not do it that way?

I am confused why any client these days would attempt to make such changes via email?

***

Anyway, I suspect this was hacker just fishing - based on the description of this company and the employees (small fish). It may have even been a AI Bot.

I also agree that 2FA/MFA is less secure than many believe - though it is effective for most private citizens/users.

The better option however, would be an authentication app such as Google Authenticator, Microsoft Authenticator or Authy. Along with a good does of employee training.

 

[Chrispy_]

I also wasn't aware of any easily available tools to scrape the SMS, the ones I recall tended to be countered pretty rapidly, so they weren't really used for the small fish. No reason to use dynamite on a 20 foot pond. But I haven't prowled in the back alleys lately. Time to gear up and take a stroll, I see.

• Received a MFA SMS Monday afternoon, 1st day of account compromise, but user didn't see it/know it/request it

What you said there makes me almost certain the SMS was intercepted. Like you, I don't frequent the shady corners of the dark net, but I do occasionally listen to Darknet Diaries podcasts and there have been at least two or three episodes I've heard that involved MFA being compromised because of SMS in the last few years - and I haven't even listened to all of them.

I'm not a security expert but informal chats with our Sophos MDR agents and firewall specialists have convinced me that SMS is almost useless as security now, a bit like WEP WiFi keys or SHA-1 certificates that can be brute-forced by a rented AWS cluster almost instantly or using GPU farms in a minute or two. They're paid to know this stuff, so I value their opinion even if it's only opinion.

 

[phanbuey]

It broke because SMS isn't a valid 2FA and hasn't been for 4-5 years.

SMS is unencrypted and just about anyone with motivation can gain access to SMS data using freely-available toolkits that your average bad actor will have at their disposal.

I've been enforcing biometric 2FA for almost two years now, and I feel I was lucky that nobody using SMS had their account compromised before that!

The biggest shock to me is that Azure/Entra still allows SMS as an authentication method

It's because their app is so busted that it doesn't work for some users -- especially if those users were on entra from another company on their personal device - forget it.

We had a 20% could not log in ticket rate - 2 out every 10 people couldn't log in with ms authenticator MFA due to random bugs.

SMS is better than nothing - but we still run SentinelOne and have some very strict IP filtering rules on our devices -- the MFA is so shoddily implemented on our MS environment that it's basically security theater at this point.

We had a user download PDFs she found online and it immediately started trying to connect to servers in Poland - we basically assume our endpoints are compromised/unsafe and all of our security is focused on gapping the sensitive/protected data at the database/source sys level.

 

[Caring1]

It broke because SMS isn't a valid 2FA and hasn't been for 4-5 years.

SMS is unencrypted and just about anyone with motivation can gain access to SMS data using freely-available toolkits that your average bad actor will have at their disposal.

What about RCS texting?

 

[Dr. Dro]

What about RCS texting?

As I understand it, RCS is an attempt to standardize a message format that is interoperable between chat services. It uses an E2E encryption scheme similar to the most popular messenger applications such as WhatsApp or Telegram, and should be vulnerable to the same key retrieval exploits that can be used against these messengers (such as malicious/modified clients). It should be safer than SMS for 2FA due to rich media and delivery confirmation support, but it wouldn't be my first choice either.

There are some key concerns, way I see it:

1. The RCS architecture officially supports a customization server which may act as a MITM between clients (for example, an OEM may have their own RCS servers to provide extra functionality to people who use devices of the same type)
2. Device support is not yet complete (Google has long supported RCS, since Android 5, so even though most Android phones are quickly abandoned, they should be compatible with the standard - the same situation isn't found over at the Apple camp. RCS support will be added on iOS 18 - which will require iPhone XR/Xs or newer, as far as I know, Apple has made no mention of backporting RCS support to earlier iPhones that are on security support schedule running iOS 16, used on the iPhone 8 and the original iPhone X, or iOS 15 used on 6s and 7 series)
3. Both ends must have RCS support explicitly enabled in their messaging client, at least on iOS 18, it is possible to disable RCS support which will cause all RCS messages to be rejected

In Brazil, using WhatsApp for business has become almost an universal thing: from shops to banks, they have a WhatsApp bot, I personally find it laughable, but if they feel that is safe enough... perhaps RCS will be. I still don't think it's a proper replacement for a 2FA solution. Biometrics are even better if the application can support it. Passwordless + biometrics (such as Face/Touch ID) is the future of digital security, IMHO.

 

[R0H1T]

Like you, I don't frequent the shady corners of the dark net, but I do occasionally listen to Darknet Diaries podcasts and there have been at least two or three episodes I've heard that involved MFA being compromised because of SMS in the last few years - and I haven't even listened to all of them.

Well you can always go 3FA or even 4FA, 5FA in extreme cases. The issue though will always be the end user as they're the weakest link of the chain!

 

[Ahhzz]

Well you can always go 3FA or even 4FA, 5FA in extreme cases. The issue though will always be the end user as they're the weakest link of the chain!

Too true. Based on a little searching, I think the most likely is a lucky, semi-crafted social engineering, at this point. She's still not sure where she put in her password, and she had several tabs open in incognito mode when I was working with her. I've moved her onto the MSA, even tho it gave her a bit of a fit to begin with, and wouldn't kick out a code.

I did spot a couple of questionable options for the SMS intercept, but neither seemed particularly viable for this scenario, or seriously effective. However, that was a quick, first pass. I've had a couple of back-and-forths with management, and I've recommended that we go ahead and start moving users to an app of one flavor or another. If the MSA is cranky, I'll just drop Authy or Google's version in, and keep moving. Thanks for the replies, everyone.