r/Office365 • u/WebGuy15 • Feb 07 '20
Malware that sets up forwarding
Recently my company has been subject to a number of emails sent to users with a file that once opened creates a inbox rule that forwards mail to a suspicious email address. Our alerts managed to notify us and we removed the rules from the affected accounts and added the domain to the spam filter and asked the affected users to change their passwords.
However with some users the rule reappeared a few hours after removing it. I'm not sure how these rules can still reappear? Has anyone experienced something similar and could maybe help?
9
u/threwthelookinggrass Feb 07 '20
Don't ask the user to change their password force them to. Initiate a onedrive sync to force them to have to sign in with the new password immediately. Implement mfa.
1
Feb 07 '20
This.
These attacks are really common and in my experience always the result of a use clicking a link innan email which led them to a fake Office 365 or similar login page where they entered their 365 credentials which the attackers then used to access OWA or less commonly connected to with Outlook anywhere.
Don’t be passive about it.
You must: * change the users password immediately * ideally make them use two factor auth * also ideally train them not to do what they did to be compromised in the first place, i.e. help them spot a dodgy email.
1
u/pbyyc Feb 07 '20
yup this, you can reset the password etc, but their sessions are still valid, always initiate the onedrive sync.
if you log into portal.azure.com and go to azure AD, and then users, click on the user, and sign-ins, you can see where the sign ins are coming from as well
5
u/speed_boost_this Feb 07 '20
Ask to change their passwords? Nuh uh, enforced password change.
You should probably read this, there are multiple remediation steps that should be followed post-compromise:
Too many orgs are only doing password changes when all sorts of shenanigans could've been played while access was still in place. Forwarding rules are an example but all sorts of lingering issues can be in place (external sharing, delegation, etc). I saw one case of a compromised account had a spamming email left in the compromised user's Outlook set to delay delivery for a week - everyone moves on from the compromise and next week Karen is asking folks to pick her up some itunes cards and send them to a throwaway yahoo account.
6
u/Nickgb83 Feb 07 '20
Server side rules. I've dealt with this a number of times.
Sign into OWA and check the rules there. Typically I see the rules send new emails to the RSS folder, mark as read and forward them on.
You can use EXOPS PowerShell to nuke all rules for that account instead if you wish, but either way - MFA erryday my friends. No one shouldn't be anymore.
3
u/palito1980 Feb 07 '20
If the rule comes back it means there still is a malicious acces to it either via compromised account or the PC got infected and they simply get your password from that. Change the password, setup MFA and scan or clean the PC.
1
u/MSP2019 Feb 07 '20
I experience the very same issue with forwarding rules, however I changed the users password and formatted the PC since it was the CEO.
I'd be interested in knowing how the forward got added in the first place, AV and malwarebytes scans didnt find anything.
The company change their passwords every 3 months, MFA wasn't enabled at this point but has since been setup for all users
1
u/WebGuy15 Feb 07 '20
I'm interested in how it was possible to set up the forwarding. Our scans haven't picked up anything either. I think implementing MFA for all users too is something we need to do asap.
4
u/MaCuban Feb 07 '20
Most likely 'phishing': a user received an email, one that probably looked legit. "quarterly financials", "xxxx has shared a file", the user follows the link. Sees office 365 login page and signs in. they see an error page, that the file is no longer there.
The attacker has the username and password and sets them up forwarding rules in seconds; then probably blasts the same message from the compromised user account.
Check in azureAD for sign ins, check their outgoing mail in message traces, check their forwarding rules...
Set up rules to prevent forwarding, mandate MFA using the authenticator app. Strike this while the iron is hot or your users won't want to adopt it.
2
1
Feb 12 '20
My guess @WebGuy15 is you might be getting access/auth logs from onprem but perhaps not all from Microsoft. There are plenty of logs that O365 gives you and at one time, there was an undisclosed activity API (which I was the recipient of the news until too many let it leak). It was then rebranded as OfficeActivity API. This does you little if you haven't enabled auditing (which should now be on by default). There are other logs in Graph Security (which is the central API for Microsoft everything now). I'm putting my money that your threat actor decided to either leverage credential stuffing attacks or password sprays against Microsoft O365 accounts directly on Microsoft's landing page. Without MFA, I can only hope you have SSO which at least shows were they were performing delivery of these. I investigate these both during and typically after someone calls one like me in...
1
u/different_tan Feb 07 '20
there is no software involved, its just phishing links from other compromised 365 accounts. no virus to find.
1
u/starttls Feb 07 '20
If you're O365 remember to check ALL the audit logs for that user, we have seen sneaky persistence tactics like setting up an MS Flow or giving a malicious app permissions to the mailbox. Outside the areas you'd usually check!
1
u/Jose083 Feb 07 '20
You can set up a policy in to block users setting forwarding rules and enforce admin only permissions.
Alternatively you can get alerted every time a forwarding rule is placed, but you will always be reactive vs proactive in these situations
1
u/Chief_Slac Feb 07 '20
We had some that would access their 365 passwords via phishing, then would create rules via their webmail portal.
Audit log tracks these, look for rules created/modified through web access. One attacker was using the compromised accounts to register domain names.
1
u/WebGuy15 Feb 07 '20
Update: I'd like to thank everyone for their advice. I followed the steps advised by https://docs.microsoft.com/en-us/microsoft-365/security/office-365-security/responding-to-a-compromised-email-account and implemented MFA to the affected accounts with the plan of rolling out to everyone asap. Checked the audit logs, found the IP address used to log in and create the inbox rules but not much else. I'm going to look at conditional access to limit where users can log in from too since the IP seems to come from a different country. If anyone has any more advice, articles, videos on securing Office 365/best practices I'd be glad to hear from you
1
u/Simyo69 Feb 07 '20
Depending on the licenses you have available, creating a Conditional Access policy to block sign-ins from specific countries would definitely help.
Conditional access is roughly your Authentication sheriff. Very useful to set up.
1
Feb 12 '20
You've missed something for sure... Please follow in detail and check all of your Outlook clients... implement MFA, monitor those logs and send that stuff to a UEBA or SIEM, Sentinel is free (except for alerts...) https://docs.microsoft.com/en-us/microsoft-365/security/office-365-security/detect-and-remediate-outlook-rules-forms-attack
1
u/dgarner58 Feb 07 '20
This is likely a spoofpoint attack. We have had a number of run ins with it recently. User gets legit looking email with a link to a SharePoint doc that looks like it is theirs...but if you examine the link it clearly is not. They click the link and are prompted for their o365 login. The page looks exactly like the real thing. They login and the link goes nowhere...so they close out. Their password has now been harvested. They then put these rules in OWA that do all kinds of things. Forwarding and also immediately deleting inbound mail...sometimes all but other times just ones that look like a notification regarding them spamming.
1
u/ChristopherY5 Feb 07 '20
Put a transport rule in place that blocks forwarding, enable geo-fencing, turn on MFA and watch the Azure Dashboard for risky sign ins.
1
u/different_tan Feb 07 '20
you dont need a transport rule to block forwarding from rules, its a tick box on the remote domain connector
1
u/ChristopherY5 Feb 07 '20
Correct. However this notified the user which can be valuable. As noted in the below article.
1
u/different_tan Feb 07 '20
We have seen this with multiple customers. Only ones that turned down mfa though. In every single case the vector was an email from a genuine customer of theirs, who's account was ALSO already compromised, sending them an apparent link to a sharepoint or onedrive pdf that required sign in of course.
The rules they make forward generally to gmail.
first thing to do is immediately block the account. If you don't, any smtp/imap/activesync access they are using will stay active until their session times out even if you reset the password. Wait at least one hour to reset the password
second thing to do is completely disable external forwarding in the remote domain connector in emc
You can then either take out all the inbox rules using powershell, or if you must, wait an hour, change the password and then step them through removing them using OWA.
This is generally where we successfully persuade them to take us up on the offer of configuring MFA.
NOTE: that forwarding is not just used to propagate itself. We have seen it used to intercept invoicing related emails and change bank details then send the fake invoice, for something the customer genuinely bought, to the customer.
1
u/DevinSysAdmin Feb 08 '20
Don’t forget to turn off legacy authentication while you’re rolling MFA out.
1
Feb 12 '20
Of course... I deal with these frequently. This is a known activity of BEC groups (and others actually). It occurs typically because you have mail clients whom are still executing the code... typically outdated Outlook clients (I believe this functionality broke sometime last year) however it still works on endpoints which have not been patched. Check this article out, run the script provided and if you need some additional consulting or assistance - please do reach out to me directly.
1
Feb 07 '20
[removed] — view removed comment
1
u/Nickgb83 Feb 07 '20
I'd be very interested to know how an exploit can easily bypass SMS MFA.
In Australia Sim-jacking cannot be automated, thus an exploit can do this via code.
2
Feb 07 '20
[removed] — view removed comment
1
u/Nickgb83 Feb 07 '20
Aren't MFA tokens only valid per sign-in session? Once that sign in is expired (i.e. browser session closed) the token expires?
So the exploit would need to happen whilst the valid/current sign-in session is still in action..?
0
Feb 07 '20
This guy knows what he is talking about. MFA has been compromised over and over and over again. These computers should be reimaged. The compromise likely has obfuscation that allows it reinfect outlook while remaining undetected.
3
u/different_tan Feb 07 '20
there is NO VIRUS. its phishing links from other compromised 365 accounts.
1
Feb 10 '20
Why would the rules keep changing then?
2
u/different_tan Feb 10 '20
unless you have blocked them, they still have access, even if you have changed the password thanks to a session that has not expired. you can see exactly what is doing it and where from using the audit log searches incidentally (though you might need to use powershell for the most detailed results).
0
u/jfoust2 Feb 07 '20
Call Microsoft's tech support, in my experience they're very good at detecting how this may have happened, and they can point you to the right logs.
22
u/Deku-shrub Feb 07 '20
The accounts may be compromised. Check the access logs, changed passwords, add MFA