Microsoft called out as big malware hoster – thanks to OneDrive and Office 365 abuse Microsoft has been branded as "the world's best malware hoster for about a decade," thanks to abuse of the Office 365 and Live platform, as well as its slow response to reports by security researchers. Infosec expert Kevin Beaumont, who worked at Microsoft as a senior threat intelligence analyst between June 2020 and April …
Some of the more dangerous phishing attacks I've seen include a fake Office 365 login form (an HTML document) hosted at Live.com or OneDrive.com.
Employees see the perfectly duplicated sign-in form, and when they double-check the browser bar they see the TLS lock symbol with a certificate for Microsoft Corporation.
It's a series of failures at every layer: poor spam filters allow emails that look an awful lot like they are from Microsft, which link to a ubiquitous (but faked) sign-on screen, hosted on servers that are certified as Microsoft. It goes even further if your admins added either site to the Trusted Domains list.
I loudly protest at the claim that Office 365 is more secure than its on-premises predecessors.
I'm amazed, disgusted, & dismayed at all the attempts that land in my junk folder, and even moreso by the stuff that manages to get through. Since I'm blind & my screen reader renders all international domains into plain text, it's often ludicrously easy to realize that the embedded url claiming to be to one source actually goes to a different one. Am I going to click that link to someone else's onedrive/google docs account? Hell no. So I click the "report as spam" link & delete it from my email client.
I fear what sighted folks that don't bother to check such things wind up falling victim to, clicking links willy nilly as if they were safe & harmless.
I often wonder what the internet would be like if a common sense/IQ test were required to gain access. Given that evolution keeps creating better idiots, I'm not sure "idiot proofing" would do any good...
I see items arrive in the Junk Mail folder that the email server has scanned and thought were clean - only a couple of days later when the AV software has been updated about a dozen times it finally detects an infection attempt in the junk mail folder.
We don't blame Facebook for posting stupid social media "information" - we just say that people are stupid for reading it. So we're not going to blame Onedrive for storing malware, we will only blame people for downloading it.
El Reg - can I have a wire-cutter icon for my posts please?
"I see items arrive in the Junk Mail folder that the email server has scanned and thought were clean"
And the other way around: my Proton account sends a new mail notification to my MS outlook account... which consistently keeps labelling Proton messages as Junk. Even after millions of times helping them out and marking "not junk". Productivity™ vs. Making The Check Come In® I suppose...
"poor spam filters allow emails that look an awful lot like they are from Microsft"
If there's one thing Microsoft really ought to be able to trap it's spam that claims to come from them and doesn't and yet it seems to account for most of the spam that gets through. The usual Nigerian Prince and similar stuff is routinely trapped.
Even if Microsoft and Google speed up their resolution of these things, someone is still going to put malware on anything which can distribute data. When I train users, which fortunately I just do informally, this is one of the things I try to get across. Links to a storage service are links to unknown content and no more trustworthy than a link to an unknown website. It's also worth knowing that people will use other tricks to make their content appear to come from a site users trust. I have seen a few attempts using Google Translate so the domain appears to be google.com but contains another domain in the query parameters which the web app will kindly render for the victim. Not all spam is obvious.
> Google... Google... Google...
Aha! Here you are!
What about Google????
https://www.merriam-webster.com/words-at-play/whataboutism-origin-meaning
Whataboutism:
[ ... ] is essentially a reversal of accusation, arguing that an opponent is guilty of an offense just as egregious or worse than what the original party was accused of doing, however unconnected the offenses may be.
The article is about Microsoft and OneDrive. Not about Google.
You will note a few things in my post and the article. One thing you will notice is that I mentioned Microsoft first, and started by talking about their and Google's drive services. I referred to both of them for a specific reason: the article compared those and found problems in both. Google was faster at removal but stored more malware in aggregate, or didn't you read it? As for the translate links, I believe an attacker could use Microsoft's translation service to the same effect, but I have not seen it used yet. I have seen Google's used in that way, and it is a similar method to cloak the real source of content online.
Whataboutism is a method of distracting from a point. I did not distract from the problem of malware in Microsoft's cloud, and in fact the only other place I mentioned was the one the article used as a comparison.
@doublelayer
"Not all spam is obvious".
I used to be very confident that I will not be fooled/caught by spam/phishing/ransomware, until one of our clients were hit by a ransomware attack.
In discussing it with the person who opened the offending document (the secretary to a main board director), I discovered the following:
The company had placed job advertisements in various papers and social media, requesting CV's to be sent to said secretary, setting out exactly what information they wanted and the format it had to be in.
To all outward appearances it looked like a legitimate job application - even to the point that the attacker had a long string of spaces after "My CV.docx", to guard against people who display file extentions.
I would have opened that document in those circumstances as well.
.. but maybe you would have someone who had set Office documents to NOT execute macros.
Ever.
Not that I'm a fan of MS Office (we ditched it completely), but IMHO people should be asked during installation if they absolutely needed macro functionality. For 99.9% of users, this is overkill and can be disabled. If someone wants it enabled they should be required to sit through a security briefing, to be repeated at least annually to retain the privilege of having the ability to invite malware.
(and no, anti virus isn't an asnwer as it lags behind especially zero day exploits).
"I have seen a few attempts using Google Translate so the domain appears to be google.com but contains another domain in the query parameters which the web app will kindly render for the victim."
Domain in the query parameters _is rendered_. Thanks, today I learned another thing to watch out for. I would expect any URL run through a translation to be the same string in the target language. But probably Google's API is using the domain in the parameters to assist in attribution, tracking, callback, etc. Feature or bug?
It's a feature, sort of, in that it allows someone to link to a translated page rather than its original. Instead of requiring each user to know that you can go to translate.google.com and put in a URL, you can directly link. For example, this article translated to Spanish gives the following URL, which doesn't have google.com in it because they have their vanity TLD and they're going to use it:
https://www-theregister-com.translate.goog/2021/10/18/microsoft_malware_brand/?_x_tr_sl=en&_x_tr_tl=es&_x_tr_hl=en-US&_x_tr_pto=nui
This format is more obvious about where it's going, but the old format did all of it with query parameters and probably still works. The user needs to know that something starting with translate.google.com doesn't mean Google approved the content.
MS and Google provide hosting. They are not responsible for what is put in their hosted storage, however they are liable for any threat activity that emanates from their service.
Maybe a government audit function is needed to protect citizens as with all other industries that present harmful output
What if every home Onedrive account requires 2FA to authorise the sharing of file types known to be potentially dangerous ie .iso, .dll, .exe, etc?
As a business user of Microsoft 365 sharing content, at least the URLs generated are specific to that tenant eg https://foo-my.sharepoint.com/.... which makes it easy to filter out the bad from the good.
I think there are several things here:
1. The company hosting the data content cannot be responsible the content people upload
2. After being notified of malicious content the company hosting it needs to react appropriately
3. The company hosting the content should be AV scanning stuff at some point
The answers to those are possibly along the lines of:
1. The T&Cs should have (if they don't already) acceptable use clauses which should include not hosting malware.
2. There needs to be well established SLAs for removing positively identified malware. There is simply no excuse for the removal to take weeks. In the case of Google and Microsoft these are huge corporations making billions of dollars of profit. Now that final point is the issue, to react more quickly presumable costs money!
3. I thought that Microsoft already scanned content going into OneDrive and SharePoint for dodgy payloads. This reasoning is based on what we have been repeatedly told by the people that look after out O365 stuff. They also trumpeted very loudly that after an incident, scanning the affected OneDrives showed there to be no issues. This begs the question if the tools that are doing the scanning are actually any use.
The scanning tools are of use in detecting known malware, but not so useful for finding the new stuff. If it's a method for providing a basic CDN for delivery, most of the content is likely unknown to scanning, and it can also be obfuscated if the initial vector can decode it on the victim's machine. Those two factors make scanning less useful.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
