Late last year saw the re-emergence of a nasty phishing tactic that allows the attacker to gain full access to a user’s data stored in the cloud without actually stealing the account password. The phishing lure starts with a link that leads to the real login page for a cloud email and/or file storage service. Anyone who takes the bait will inadvertently forward a digital token to the attackers that gives them indefinite access to the victim’s email, files and contacts — even after the victim has changed their password.
Before delving into the details, it’s important to note two things. First, while the most recent versions of this stealthy phish targeted corporate users of Microsoft’s Office 365 service, the same approach could be leveraged to ensnare users of many other cloud providers. Second, this attack is not exactly new: In 2017, for instance, phishers used a similar technique to plunder accounts at Google’s Gmail service.
Still, this phishing tactic is worth highlighting because recent examples of it received relatively little press coverage. Also, the resulting compromise is quite persistent and sidesteps two-factor authentication, and it seems likely we will see this approach exploited more frequently in the future.
In early December, security experts at PhishLabs detailed a sophisticated phishing scheme targeting Office 365 users that used a malicious link which took people who clicked to an official Office 365 login page — login.microsoftonline.com. Anyone suspicious about the link would have seen nothing immediately amiss in their browser’s address bar, and could quite easily verify that the link indeed took them to Microsoft’s real login page:
Only by copying and pasting the link or by scrolling far to the right in the URL bar can we detect that something isn’t quite right:
As we can see from the URL in the image directly above, the link tells Microsoft to forward the authorization token produced by a successful login to the domain officesuited[.]com. From there, the user will be presented with a prompt that says an app is requesting permissions to read your email, contacts, OneNote notebooks, access your files, read/write to your mailbox settings, sign you in, read your profile, and maintain access to that data.
According to PhishLabs, the app that generates this request was created using information apparently stolen from a legitimate organization. The domain hosting the malicious app pictured above — officemtr[.]com — is different from the one I saw in late December, but it was hosted at the same Internet address as officesuited[.]com and likely signed using the same legitimate company’s credentials.
PhishLabs says the attackers are exploiting a feature of Outlook known as “add-ins,” which are applications built by third-party developers that can be installed either from a file or URL from the Office store.
“By default, any user can apply add-ins to their outlook application,” wrote PhishLabs’ Michael Tyler. “Additionally, Microsoft allows Office 365 add-ins and apps to be installed via side loading without going through the Office Store, and thereby avoiding any review process.”
In an interview with KrebsOnSecurity, Tyler said he views this attack method more like malware than traditional phishing, which tries to trick someone into giving their password to the scammers.
“The difference here is instead of handing off credentials to someone, they are allowing an outside application to start interacting with their Office 365 environment directly,” he said.
Many readers at this point may be thinking that they would hesitate before approving such powerful permissions as those requested by this malicious application. But Tyler said this assumes the user somehow understands that there is a malicious third-party involved in the transaction.
“We can look at the reason phishing is still around, and it’s because people are making decisions they shouldn’t be making or shouldn’t be able to make,” he said. “Even employees who are trained on security are trained to make sure it’s a legitimate site before entering their credentials. Well, in this attack the site is legitimate, and at that point their guard is down. I look at this and think, would I be more likely to type my password into a box or more likely to click a button that says ‘okay’?”
The scary part about this attack is that once a user grants the malicious app permissions to read their files and emails, the attackers can maintain access to the account even after the user changes his password. What’s more, Tyler said the malicious app they tested was not visible as an add-in at the individual user level; only system administrators responsible for managing user accounts could see that the app had been approved.
Furthermore, even if an organization requires multi-factor authentication at sign-in, recall that this phish’s login process takes place on Microsoft’s own Web site. That means having two-factor enabled for an account would do nothing to prevent a malicious app that has already been approved by the user from accessing their emails or files.
Once given permission to access the user’s email and files, the app will retain that access until one of two things happen: Microsoft discovers and disables the malicious app, or an administrator on the victim user’s domain removes the program from the user’s account.
Expecting swift action from Microsoft might not be ideal: From my testing, Microsoft appears to have disabled the malicious app being served from officesuited[.]com sometime around Dec. 19 — roughly one week after it went live.
In a statement provided to KrebsOnSecurity, Microsoft Senior Director Jeff Jones said the company continues to monitor for potential new variations of this malicious activity and will take action to disable applications as they are identified.
“The technique described relies on a sophisticated phishing campaign that invites users to permit a malicious Azure Active Directory Application,” Jones said. “We’ve notified impacted customers and worked with them to help remediate their environments.”
Microsoft’s instructions for detecting and removing illicit consent grants in Office 365 are here. Microsoft says administrators can enable a setting that blocks users from installing third-party apps into Office 365, but it calls this a “drastic step” that “isn’t strongly recommended as it severely impairs your users’ ability to be productive with third-party applications.”
PhishLabs’ Tyler said he disagrees with Microsoft here, and encourages Office 365 administrators to block users from installing apps altogether — or at the very least restrict them to apps from the official Microsoft store.
Apart from that, he said, it’s important for Office 365 administrators to periodically look for suspicious apps installed on their Office 365 environment.
“If an organization were to fall prey to this, your traditional methods of eradicating things involve activating two-factor authentication, clearing the user’s sessions, and so on, but that won’t do anything here,” he said. “It’s important that response teams know about this tactic so they can look for problems. If you can’t or don’t want to do that, at least make sure you have security logging turned on so it’s generating an alert when people are introducing new software into your infrastructure.”
Wow!
If only MS had some historical reference, like a system-integrated browser blindly allowing, oh, random ActiveX from the internet, that would let them understand how foolish this misfeature is.
Thanks for the heads-up, Brian!
I’m guessing this is associated with corporate/government agendas.
Thank you for bringing attention to this.
officesuited (dot) com is hosted on Bcloud in Bulgaria which doesn’t surprise me.
Having lost count of the Microsoft account phishing sites I personally have seen hosted on Azure, I mildly surprised officesuited (dot) com was on Azure itself.
It doesn’t help Microsoft’s abuse form seems designed to discourage complaints.
Hosting is cheap and you can order it online, so it doesn’t matter where is hosted.
And for info, the contact phone in hosting site is UK-wide (+44 330 ….)
There’s no way that this is a commonly-fell for tactic. It’s not any different than installing an app to your phone, nobody is really that dumb.
Are you referring to the app permissions page? I thought the same thing. The unfortunate thing is that people don’t read those and just blindly hit “Accept”. But, come on, “have full access to all files you have access to”, “read and write to your mailbox settings”… how are those not dead giveaways?
As a third party app developer, I can attest that my “advanced” email client will not work properly unless the user configures it to work with his/her email provider/host, which is O365 for subscribers. if developers do not educate their users/customers about the importance of the permissions being requested and the importance of knowing the requesting app (and the importance of checking which apps have gained access), then the developer has some degree of liability along with the users, who are blinded by the technology they use but do not understand and will click to enable access without reading it.
A security-educated user is a better employee and spouse.
Well, maybe, but what constitutes “security education” is changing so rapidly, and becoming more complex, only professionals can keep up-to-date, and that’s of course excluding day-zeros.
“How are those not dead giveaways?”
Users are basically stupid.
“Nobody is really that dumb”
Famous last words.
Soooooo true.
Over 90% of security incidents are caused by either people doing something they shouldn’t do, or someone not doing something they should do. Humans aren’t perfect, shocking, I know, but it’s true. The brightest people in the world, yes even “security experts,” can fall for a scam if you catch them at the right time.
yeah i wish that was true… you must have some great, educated, brilliant users… this **** keeps me up at night
“nobody is really that dumb.”
You must not have much experience working in IT. Users do dumb things all the time, and then lie about doing said dumb thing.
My heart almost stopped I thought this was Google accounts but I have seen same fishing emails being sent as a Apple cloud account from Arab countries especially. Privacy is going to be uphill battle Thank you for giving us a heads up Please make it a priority if you have anything on Google because that’s where the mass is live with to step authentication. Anyway keep up the good work and thank you for bringing this to our attention.
For users with the right M365 licenses, Microsoft Cloud App Security can alert on these types of illicit OAuth grants.
Security costs extra
How many ways does the ‘bottom line’ affect these things? When such features are implemented, what are decision-makers actually thinking?
The root cause is the many years that Microsoft has taught users to click by rote: “Next > Next > Next ….”, “OK > OK > OK….” , “I Agree > I Agree > I Agree…”, “Accept > Accept > Accept…”
Spot on – Most users click then follow the prompts because the computer is telling them to and they typically don’t pay attention or understand what is occurring. Anyone thinking that this is abnormal user behavior has departed from reality.
“…even if an organization requires multi-factor authentication at sign-in, recall that this phish’s login process takes place on Microsoft’s own Web site. That means having two-factor enabled for an account would do nothing to prevent a malicious app that has already been approved by the user from accessing their emails or files…” Brian Krebs
The “Cloud” is getting darker by the day. I wonder if this is huge rigged three card Monty scam or a well choreographed multinational confidence game. I am dubious MS is actually putting their customer’s security over their corporate profits. Data harvesting seems to be a big winner for certain big players these days.
Is this only an MS/Outlook/Office365 issue? Or can this use Gmail or other sites? The article seems to say MS had to set up this feature before it could be used improperly. Are any other tools capable of allowing their users to be hoodwinked in a similar way?
Russ, from the second paragraph of the story:
“Before delving into the details, it’s important to note two things. First, while the most recent versions of this stealthy phish targeted corporate users of Microsoft’s Office 365 service, the same approach could be leveraged to ensnare users of many other cloud providers. Second, this attack is not exactly new: In 2017, for instance, phishers used a similar technique to plunder accounts at Google’s Gmail service.”
So we can safely say google itself has been hacked, for all intents and purposes. This ‘stealthy’ technique will not be the last ‘stealthy’ technique showing up on “advanced” platforms like google.
I wrote to Brian Krebs when I published my article here in agreement with Microsoft (after a few request to delay disclosure)
https://securityintheenterprise.blogspot.com/2019/11/microsoft-azuread-and-office365-not.html – But that was not interesting then, or drowned in his mailbox.
I detail more attack vectors. The first is a link to MicrosoftOnline.com on a webpage or in a mail.
I have a sample page fake product page. Any app or webservice posing as legitimate could abuse access. Maybe if the service gets in financial trouble they can start abusing at a later stage.
One web only app that gets read/write access to onedrive is draw.io – Legitimate as far as I know. Certainly provides value. But from a GDPR point of view, I can not allow my users to give 3rd parties access to company data (on enterprise onedrive) without a data processing agreement.
Sorry, I don’t get how this is sophisticated. Dangerous yes, definitely. Clever, maybe. But sophisticated?
If I understand the story correctly -please feel free to correct me if needed- they found a way to get users to click on a link.
The link contains standard OAuth functionality:
– it directs Microsoft to give access to the users’ resources to a consumer (in this case, the attacker)
– Microsoft correctly asks the users if they’re ok with this
– The users reply “yes”, granting the attacker access
Really the only cleverness here is getting the user in a context where such a prompt is not unexpected, therefore multiplying the chances that the users will click “yes”.
IMHO the proposal from Phishlabs -essentially to defend against malicious links being presented to users- is little more than a stopgap. Bad actors will always find a way to present malicious links to users.
I think the correct -more robust anyway- defence against this is to whitelist which applications get to ask for access. Not sure if this is standard functionality in Office 365 or other cloud providers though.
Just my 2 rappen 🙂
Or just set everyone’s email to text. Then there are no active links.
I mean pinch me if I am sleeping here BK, but this is a simple open redirect problem. Microsoft owns that. It’s their fault. Redirects are supposed to be whitelisted. It’s like a RFI vulnerability. It’s a vulnerability in their site and it needs to be restricted to valid domains, like any whitelisted app store or plugin architecture would. Openly allowing “Add-Ins” from any domain is grossly negligent–it doesn’t matter what level of sophistication is required to exploit it–at global scale, the sophistication will occur. What am I missing here? What a dumb excuse from Microsoft. Seems like a CVSS 10 bullethole in Microsoft’s cloud, to me. It’s like subjecting a world of O365 users to a Cydia-dumpster-reality by default.
The Open redirect vulnerability has been on the OWASP Top 10 since 2010. It is so nice to see Microsoft ‘taking security seriously’. Did they do any real threat modeling or was that limited to playing the ‘Elevation of Privilege’ card game?
Brian, thank you for incorporating links to change the settings in O365 in the article, you made it easy for me to improve my security posture even while simultaneously reading your article, well done.
I recently bought a new desk top and approved a prompt similar to this when setting it up my office suite (I had not used the internet browser to go to any other sites). Should I be concerned?
There is a less drastic step than Turning Integrated Apps on or off.
The recommended configuration change is to disable end-user consent, and then enable a new preview feature that routes the oAuth request to an Administrator who can review the URL to make sure its safe. Here is the announcement about the new admin consent workflow in Azure AD:
https://docs.microsoft.com/en-us/azure/active-directory/manage-apps/configure-admin-consent-workflow
Hey Joe, that’s interesting, I didn’t even know that was a thing. So, according to that article you linked, it states:
“Select reviewers for this workflow from a set of users that have the global administrator, cloud application administrator, and application administrator roles”
If I’m understanding this correctly, this is essentially how a typical approval workflow operates in a lot of organizations. User requests resource > resource request gets routed to an approver > the approver reviews the request > request is either approved or denied.
Pardon my ignorance, but the only issue that I see with that is, due to the Open Redirect vulnerability, wouldn’t this still bypass the administrator approval workflow that is mentioned in the article you linked? Since the malicious link tells Microsoft to forward the authorization token produced by a successful login to the domain officesuited[.]com, Microsoft is not in the workflow anymore — the attacker is and the entire workflow is then disrupted.
“routes the oAuth request to an Administrator who can review the URL ”
Hell no, I do enough of that all day when I have real work to do. Just lock email down to text only. Malicious links look to scary for people to try and copy and paste into a browser then.
Crooks can use a URL shortener, so links don’t look so scary.
That is also why the common anti-phishing tactic, “take a look at the url”, sometimes doesn’t work.
True quotes – “Why can’t I put pictures in my emails anymore? We do birthday cakes with little candles when we announce whose birthday it is, and it’s so cute! I’m tired of security always making things worse!”
I have to defend the users here. It’s by no means an irrational demand for someone to want to send formatted text and pictures. Email is a commutation tool and these things -bold, underline, a graph- are necessary.
That we, IT people collectively, cannot provide something so basic without adding huge risks is our industry’s failure. Let’s not blame the victim.
Most users in the U.S. have no need to visit sites in Bulgaria or most other non-English- or non-Spanish-speaking countries, for that matter.
For maximum security at some job sites, I configure routers (sonicwall or pfsense) to block all traffic to and from any country other than the U.S., Canada and the UK. Besides preventing users from clicking a phishing email’s contents or ad that leads outside of the whitelisted area, geo blocking prevents lots of malware from phoning home outside of the whitelisted countries.
To access legitimate websites outside of the U.S., users start their workstation’s VPN, which ironically bypasses the router’s geo blocking. After visiting a router-blocked foreign site, users then turn off their workstation VPN to resume protection by the the router’s geo blocking.
This probably only works for small job sites like mine that are extremely worried about security and have diligent users. They only start their workstation VPN after a website is blocked — pretty rare — maybe once a quarter per user.
In such routers and job sites, it’s best in my opinion to whitelist instead of blacklist countries. This catches all sorts of odd listings (e.g., obscure islands most people never heard of and uncategorized mystery-country IDs).
If you’re in Brazil you could just white-list Brazil and a few other countries your users frequent. And if you’re in the U.S. but visit sites in Taiwan or the Philippines frequently, you’d whitelist those, too.
NOTE: these job sites are very small. For larger sites, many users would no doubt bypass the geo blocking by running their workstation VPN all the time! (Annoyingly, the workstation VPN doesn’t offer its own geo-blocking options, so one user got phished from Botswana while his VPN was active, though the VPN service security called us soon after to alert us.)
Yet another vector that demonstrates legacy 2fa implementations like FIDO are a waste of time and resources. Users need a custom key set to prevent being tricked by broad scale attacks. Claims that Users can be protected by observation the mantra of the cybersecurity elite have now been well and truly debunked.
>Yet another vector that demonstrates legacy 2fa implementations like FIDO are a waste of time and resources.
Please clarify – I see nothing to conclude that FIDO is a waste of time. The point of this article is the additional vector(s) that must be managed.
Does anyone actually (for anything sensitive in their online life) actually use an email that is NOT protected by U2F-FIDO? For example, Yubikeys, Thetis, etc and/or others??
I mean, cripes, even Google itself lets a person set up a U2F-FIDO-protected account (email too) under their “Advanced Protection” (AP) program. AP also even allows users to stop any login, password and account re-settings–in other words, lose your U2F-FIDO key/device, and your account is locked/gone for good. Google cannot get back into it, and they tell you this plainly, straight up-front if you set up a AP account. Not even the NSA can get back into it, despite what tin-foil hat wearers want to believe—–there’s a reason that people at the NSA itself carry around these keys for their accounts.
U2F-FIDO has made most of 2FA (two-factor authentication) darn near obsolete.
Unlike many current 2FA methods, stealing/harvesting digital tokens has zero effect on email (and other) account security when set up with U2F-FIDO.
The future arrived. Years ago. I guess the question is when will people and organizations wake up and take steps??
When I was a scientist at the USAF, we used yubi, so that checks out. I’m curious if this is really useful – in particular, can a pair of identical yubi (thinking personal accounts here, with emergency backup stored in a safe) could be set up? Is it useful for both email and cloud-stored data (i.e., google hacking)?
Is there a decent (read: trustable) DIY for setting up one’s online life via U2F-FIDO?
Origin binding – how could that possibly work against random phishing links in an email client?
https://www.blackhat.com/docs/us-16/materials/us-16-Chong-Breaking-FIDO-Are-Exploits-In-There.pdf
While it might not be a technically sophisticated phishing scheme, it is definitely sophisticated from a psychological point of view. It aims to work around common anti-phishing tactics like “take a look at the url” by simply hiding the malicious part. It also underlines that phishing needs to be addressed on an organizational level.
It would be better to teach employees not to click on any links in emails (from your email provider) and instead to always use a bookmark in the browser.
Studies show that users are also often not able to adapt one situation to another: So if you told them “just make sure the link in your email goes to the official website” they will let their guard down, not look at the full link, as proven in this scheme.
Isn’t phishing, by definition, psychological? A form of social engineering?
I wonder if this would be harder to do if a user wasn’t in the Cloud. Perhaps we should come back to earth!
Regards,
Who is dumb enough to use MS365? Kaching Kaching.
Well, just speculating about google getting hacked – yep, this is hacked. Why would we feel the cloud would be safe?
I learned the hard way 15 years ago to carefully examine the full extended address for any link before I clicked on something in an incoming e-mail (or a webpage) when I was suckered by what appeared to be a PDF attachment but was actually a PIF (executable) file, as the full filename contained a lot of spaces following the initial grouping with that PDF filename that ended in .PIF. I was working on a World Bank project in Kyrgyzstan with a dial-up Internet connection, and had logged off before I took the misstep, and realized shortly afterward I had downloaded a trojan of some sort when my laptop (then running XP SP3) began repeatedly trying to launch a dial-up connection.
It took me most of the rest of that day to figure out what the malware had installed, then to delete it (in Safe Mode) from the hard drive and run a series of malware scans to ensure my OS was again free of infection.
Thanks for the information on this latest malware vector, Brian.
The door has been open widely for quite a long time. It has been publicly discussed in mid 2018. In this video, an attack is simulated. https://www.youtube.com/watch?v=OZuZk_RhhO0
When moving to cloud, the attack surface will be also changed from end point to cloud service. Such attack will occur more and more in future, not only for office 365, but also for G Suite, Dropbox, etc.
This javascript link will check the address
{javascript:alert(%22The%20actual%20URL%20is:\t\t%22%20+%20location.protocol%20+%20%22//%22%20+%20location.hostname%20+%20%22/%22%20+%20%22\nTheaddress%20URL%20is:\t\t%22%20+%20location.href%20+%20%22\n%22%20+%20%22\nIf%20the%20server%20names%20do%20not%20match,%20this%20may%20be%20a%20spoof.%22);}
Just make it a bookmark
Excuse my ignorance or lack of knowledge – but how exactly would this “bookmark” work? Or was this being sarcastic?
Using Firefox, Create a new bookmark on say a blank page, then edit the properties by pasting in the javascript to the location. Works in legacy Edge as well.
A major problem with OAuth and token based authentication in general is that a password change doesn’t automatically invalidate all tokens. There are some services what ask on password change if I wish to log out from all other devices, but it should be the other way around, i.e. ask me if I want to stay logged in on other devices or if it doesn’t ask just log me out.
That would prevent hacks like this too:
https://www.theregister.co.uk/2019/11/04/amazons_unlisted_devices/
Jon d’Shade’s Amazon account was fraudulently linked to a smart tv and despite him changing password the device stayed linked to account.
Interesting comment, thanks, Metz.
We have had one client fall for the URL injection.
Education, education, education.