Microsoft has neutered a large-scale fraud campaign that used knock-off domains and malicious apps to scam customers in 62 countries around the world.
The software maker and cloud-service provider last week obtained a court order that allowed it to seize six domains, five of which contained the word “office.” The company said attackers used them in a sophisticated campaign designed to trick CEOs and other high-ranking business leaders into wiring large sums of money to attackers rather than trusted parties. An earlier so-called BEC, or business email compromise, that the same group of attackers carried out in December used phishing attacks to obtain unauthorized access. The emails used generic business themes such as quarterly earnings reports. Microsoft used technical means to shut it down.
The attackers returned with a new BEC that took a different tack: instead of tricking targets into logging in to lookalike sites, and consequently divulging the passwords, the scam used emails that instructed the recipient to give what was purported to be a Microsoft app access to an Office 365 account. The latest scam used the COVID-19 pandemic as a lure.
“This scheme enabled unauthorized access without explicitly requiring the victims to directly give up their login credentials at a fake website or similar interface, as they would in a more traditional phishing campaign,” Tom Burt, Microsoft’s corporate vice president for Customer Security & Trust, wrote. “After clicking through the consent prompt for the malicious web app (pictured below), the victim unwittingly granted criminals permission to access and control the victims’ Office 365 account contents, including email, contacts, notes and material stored in the victims’ OneDrive for Business cloud storage space and corporate SharePoint document management and storage system.”
Burt cited a 2019 report from the FBI that said BEC crimes caused losses of more than $1.7 billion, almost half of all financial losses caused by Internet crime. BECs were the most costly complaint received by the Internet Crime Center, according to the report. In some of the more well-executed campaigns, executives receive emails that appear to come from managers, accountants, or other people who work for the organization.
Burt didn’t give the name or affiliation of the hackers other than to say they were sophisticated and had carried out the December campaign.
Beware of OAuth
It’s not the first time attackers have tricked targets into granting network access to malicious apps. Last year, researchers disclosed at least two others, both of them designed to gain access to Google accounts. One was carried out by hackers working for Egypt, according to a report from Amnesty International. The other targeted the iOS and Android devices of Tibetans.
Both campaigns relied on OAuth, an open standard that allows users to give websites or apps access to network resources without having to give them a password. As Microsoft said, such attacks often fly under the radar of users trained to spot phishing, since there’s no request to enter a password into a fake site. In some cases, the OAuth technique may have the ability to bypass two-factor authentication, which in addition to a password, requires users to enter a temporary password or to connect a physical security key to the device that’s being authenticated.
Microsoft’s Burt didn’t explicitly say the apps used in the more recent case connected through OAuth. In a separate post published on Wednesday, however, Microsoft warned of “Consent phishing,” in which attackers use the same OAuth method.
Among the advice the Microsoft posts provide to prevent such attacks is to turn on two-factor authentication. It’s always a good idea to turn it on, but it’s not clear how effective the measure alone is at preventing these attacks. Some networks may not require the second factor for OAuth. And even when networks do enforce 2FA for OAuth, targets who are tricked into connecting an app can likely be fooled into supplying the second factor as well.
One way to protect Google and G Suite accounts against OAuth scams is to turn on Advanced Protection, which strictly enforces hardware-based 2FA for every new device or app logging in for the first time. The program also restricts all but a handful of apps from connecting even when a key is provided, so it may not be suitable for all users. It’s possible that other 2FA protections do the same.
Other ways to avoid the scams is to learn the telltale signs of phishing, such as misspelled words, bad grammar, and links to sites that name a company or product but combine it with words that aren’t commonly used by the app maker or website operator. Wednesday’s post provides a variety of ways to spot malicious OAuth apps. These measures are hardly perfect, and as a result, the effectiveness and low cost of phishing makes it one of attackers’ go-to methods for compromising accounts. The steps are nonetheless worth following.
Promoted Comments
- This is a really depressing phishing attack, you can be sure it will be the prevelent kind in the future once MFA and OAUTH is basically mandatory for O365 and other users.
The response is almost certianly going to be a lockdown of what apps can even request consent. Google is already doing an early version of this where it is quite hard to get an OAUTH client registration for global use.
The end result will be less app choices and less open source clients for cloud.
- gmerrick wrote:For office 365 there is an official microsoft authenticator app that will ping on you phone or device when attempting to log in.
It beats nothing at all by a substantial margin; but I have concerns about the app-prompt approach because it both provides a pop-up for users to get conditioned to clicking out of the way; and because(at least at the moment) it doesn’t offer, much less enforce, any context between the authorization and the login.
Assuming I have MFA enabled on my account, or a conditional access policy requires it; I get the same approval request whether I’m sitting in front of the computer I’m trying to log in to; or whether the login is being done by a bot in Nigeria; and it isn’t even obvious what exactly I’m being prompted to log in to.
The FIDO2 dongles, by contrast, are also a thing you have; but they enforce having the agent authenticating be at the device(or connected via a method that supports USB pass through) that is authenticating; rather than merely requiring a set of credentials to be plugged in somewhere and someone to hit ‘allow’ rather than ‘deny’ in some other place.
We’ve tried to minimize user desensitization by crafting the rules to avoid MFA-ing when enough other factors(eg. login is coming from a company computer or MDM-joined device; from within an expected IP range) are present just so that people don’t see the pop up as much; but it’s a matter of continued concern.
Google may be amateur hour in terms of things like “attention span”; but I love their first-class support for FIDO keys, compared to the rather anemic support for anything aside from their pop-up app or (if you insist, admin-enrolled TOTP tokens or an authentication app that isn’t the microsoft one) on the AAD side.
