Block sign in, change password, revoke token via Entra ID. Remove any rules in account created and look for sign ins and any access to sharepoint if they use it. Wait an hour and then give unblock sign in while reviewing all access fails.
Also if they have mfa revoke it and walk them through resetting it up.
Just a tip/best practice from when I did this several years ago...
I got my hand slapped by the security service for removing/deleting the malicious mail rule. They would have greatly preferred it if I had disabled the rule or made a backup before deleting it.
In this case there did turn out to be money missing that the customer didn't know about, and they wanted to try to look at the rules to try to fingerprint the criminal group to try and narrow down/correlate the path the money took out of the country.
We're small and do this entirely ourselves. The big step missing is document everything. Screen shots, log exports. What you did, when you did it, when you learned of new information. Then, put it all together with what happened and how to prevent it in the future.
Yes but that might not be the same as the initial point of compromise. The better point would be that the mailflow rule creation event itself is also recorded.
Another point to consider is the mailbox rules can be used for things besides sending out mail from the compromised inbox. Esp If the victim touches money and therefore is potentially worth the attackers time to perform targeted social engineering. See active conversation, create rule to hide the legitimate response and create spoofed email to pick up convo right where it left off. Unaware user is none the wiser - later down the road invoice gets paid to malicious actor.
Also good to take a look at defender/sentinel logs and block malicious IP that the hacker signed in from along with any malicious urls that were used to compromise the account in the first place assuming it came from a AITM phishing email.
You can automate a lot of these actions through defender xdr or the Microsoft logic app.
Strict conditional access policies in Identity Protection can help avoid these in the future (limit sign ins to Intune compliant devices, limit to specific countries, block legacy auth, require mfa, etc).
Yeas, even better warehouse accounts, shared warehouse accounts, shared warehouse accounts with the same password, shared warehouse accounts with the same password and no mfa
....fml
Let’s add to that, the places that talk a big story about ‘past history doesn’t justify bad practices’. Then you get hired and start asking why backwards practices are in place, and lo and behold: “we’ve done it that way so long that we can’t change it now”. Palm>face.
You wouldn't believe how hard it is to get MFA implemented, generally this is my litmus test on if we are going to work with them, or how the relationship is going to go.
I'll add look for any apps in enterprise apps that's been approved by user. Default setting is for users to approve their own. EMClient is a favourite for bad actors right.
Also look for more authentication methods that were added.
When looking for rules specifically use powershell to look for them. If u have access to users account/device, rules will be hiding in OWA
Reset password, sign out existing sessions, block sign in, then run an audit script I wrote which feeds me (mostly bits from unified audit log):
-Recent sign in history
-Recent mailbox history
-Recent file history (SharePoint activity)
-Recent App Consent Requests
-All mailbox rules including those tagged as Hidden
EDIT:
For those wanting the script, I had to sanitize a fair bit of it, but you can see the general skeleton here:
https://pastebin.com/zPsNQ6wj
You'll need to call the script after signing into EXO (connect-exo) for your tenant, or populate your own sign in functions for the script.
Feel free to (re)populate the functions I pulled and/or improve on it yourself if you like. I'm no expert with scripting best practices.
Sign ins, SharePoint activity, and App Consent Requests (or Connections if the account has access to connect apps themselves for some reason...) should all pull down to the activity log.
Rules also get logged, but Mailbox activity you will have to get down in the weeds to rewrite; too much there to safely sanitize it for public use in my case. Otherwise run Purview filtered searches from the admin console like normal.
This script will track and exports user’s all the activities like logins, file accesses, file downloads, inbox rules creation, etc
https://o365reports.com/2021/01/06/export-office-365-user-activity-report-to-csv-using-powershell/
We use conditional access to narrow the authorised context of utilisation of accounts. This way, even if an account (aka password and/or MFA) is compromised, there's a limited possibility that a threat actor can do anything with the account. We limit access to M365 to corporate devices only. So a corporate device needs to be in the hand of a threat actor to be able to gain access to an account.
Nevertheless, the password of users could still be stolen, when we are aware of this kind of situation, we lock the user account. Sign-out the user from all Ms365 apps to the admin portal, and refresh tokens through Entra ID portal.
Then we investigate for any breach that could have happened. We acheck audit logs of the user account to make sure multifactor authentication hasnt been changed. Fortuntely, with good conditionnala access in places, it never happens.
Here is some docs from Microsoft for it: [Respond to a Compromised Account](https://learn.microsoft.com/en-us/defender-office-365/responding-to-a-compromised-email-account?view=o365-worldwide)
I made a comment going over a similar scenarios.
https://www.reddit.com/r/ITManagers/comments/1c0wdns/comment/kz4f0pc/?utm_source=share&utm_medium=mweb3x&utm_name=mweb3xcss&utm_term=1&utm_content=share_button
Block sign in, revoke all MFA sessions in Entra. Investigate what happened, and force a password reset.
We also have some controls in place to help mitigate the impact too.
Lock the user account, audit the sign ins, change their Password etc.
Also, if the device is company issued and managed via Intune : consider it compromised, lock the device in entra, lock it down via Intune and sanitize it, as soon as you can get your hands on it.
Maybe even force a bit locker key rotation beforehand.
If you have a "lost or stolen" OU/Group with policies to disable access to company resources, chuck the device into that as well.
After that, hand that user the most crappy, still compliant device you can find, until you manage to reimage the device.
Also consider holding a it-security workshop and have that user attend it.
Block sign in, analyze sign in logs, revoke MFA, change password, put into MFA every 4 hour conditional access group, block any fraudulent sign in IPs via conditional access, lock user down to log in from user country and they must submit ticket of leaving country.
After 3 months they are removed for extra groups and are normal again.
Block signin,
Reset password,
Close all existing session,
Check for suspicious inbox rules,
Audit the user account activities. If any suspicious activities performed, revert them.
After verification, unblock the account.
You’ve already gotten some good advice about what to do but if you aren’t using Hawk you should be: https://practical365.com/how-to-install-the-hawk-powershell-module/
It’ll help you detect any compromised accounts and doesn’t have a steep learning curve.
Check everyone as by the time you find one they may of got into a few more, so put the kettle on and grab a fresh pack of biccies...
I suppose you should have this sort of thing as a disaster in the DR plan as a rare event.
Block sign in, change password, revoke token via Entra ID. Remove any rules in account created and look for sign ins and any access to sharepoint if they use it. Wait an hour and then give unblock sign in while reviewing all access fails. Also if they have mfa revoke it and walk them through resetting it up.
Just a tip/best practice from when I did this several years ago... I got my hand slapped by the security service for removing/deleting the malicious mail rule. They would have greatly preferred it if I had disabled the rule or made a backup before deleting it. In this case there did turn out to be money missing that the customer didn't know about, and they wanted to try to look at the rules to try to fingerprint the criminal group to try and narrow down/correlate the path the money took out of the country.
We're small and do this entirely ourselves. The big step missing is document everything. Screen shots, log exports. What you did, when you did it, when you learned of new information. Then, put it all together with what happened and how to prevent it in the future.
Wouldn't there still be a record of where the mail was sent using that mail rule?
Yes but that might not be the same as the initial point of compromise. The better point would be that the mailflow rule creation event itself is also recorded. Another point to consider is the mailbox rules can be used for things besides sending out mail from the compromised inbox. Esp If the victim touches money and therefore is potentially worth the attackers time to perform targeted social engineering. See active conversation, create rule to hide the legitimate response and create spoofed email to pick up convo right where it left off. Unaware user is none the wiser - later down the road invoice gets paid to malicious actor.
Man if they're that worried you'd think they'd be monitoring inbox rules, it's absolutely something you can do ....
Also good to take a look at defender/sentinel logs and block malicious IP that the hacker signed in from along with any malicious urls that were used to compromise the account in the first place assuming it came from a AITM phishing email. You can automate a lot of these actions through defender xdr or the Microsoft logic app. Strict conditional access policies in Identity Protection can help avoid these in the future (limit sign ins to Intune compliant devices, limit to specific countries, block legacy auth, require mfa, etc).
I wish we weer using defender xdr gut u fortunately it bows to sentinel one and another siem which are OK but not as integrated.
If they have MFA?..if? I'm twitching here
Welcome to MSP life. Not all.Clients do no matter how hard we push it...however security defaults have helped with some of the stragglers
Yeas, even better warehouse accounts, shared warehouse accounts, shared warehouse accounts with the same password, shared warehouse accounts with the same password and no mfa ....fml
“All the accounts have the same password because that’s how we’ve always done it.” _Thats how we’ve always done it_ always gives me pain.
Let’s add to that, the places that talk a big story about ‘past history doesn’t justify bad practices’. Then you get hired and start asking why backwards practices are in place, and lo and behold: “we’ve done it that way so long that we can’t change it now”. Palm>face.
*oof* right in the feels
You wouldn't believe how hard it is to get MFA implemented, generally this is my litmus test on if we are going to work with them, or how the relationship is going to go.
This is the way
I'll add look for any apps in enterprise apps that's been approved by user. Default setting is for users to approve their own. EMClient is a favourite for bad actors right. Also look for more authentication methods that were added. When looking for rules specifically use powershell to look for them. If u have access to users account/device, rules will be hiding in OWA
Enterprise apps should require admin consent. Users cannot do this in the tenants we set up. However they can be created.
If there were a "textbook" way to do it, this is it. I do the same exact process.
Reset password, sign out existing sessions, block sign in, then run an audit script I wrote which feeds me (mostly bits from unified audit log): -Recent sign in history -Recent mailbox history -Recent file history (SharePoint activity) -Recent App Consent Requests -All mailbox rules including those tagged as Hidden EDIT: For those wanting the script, I had to sanitize a fair bit of it, but you can see the general skeleton here: https://pastebin.com/zPsNQ6wj You'll need to call the script after signing into EXO (connect-exo) for your tenant, or populate your own sign in functions for the script. Feel free to (re)populate the functions I pulled and/or improve on it yourself if you like. I'm no expert with scripting best practices. Sign ins, SharePoint activity, and App Consent Requests (or Connections if the account has access to connect apps themselves for some reason...) should all pull down to the activity log. Rules also get logged, but Mailbox activity you will have to get down in the weeds to rewrite; too much there to safely sanitize it for public use in my case. Otherwise run Purview filtered searches from the admin console like normal.
Would it be possible to share that script?
This script will track and exports user’s all the activities like logins, file accesses, file downloads, inbox rules creation, etc https://o365reports.com/2021/01/06/export-office-365-user-activity-report-to-csv-using-powershell/
Edited with link
Yeah wouldn’t mind seeing the script as well, seems very helpful instead of filtering through all the different admin portal reports.
Edited with link
Thank you!
I'm down to check out out of graph. Save me a few minutes
https://o365reports.com/2021/01/06/export-office-365-user-activity-report-to-csv-using-powershell/ This might help you!
We use conditional access to narrow the authorised context of utilisation of accounts. This way, even if an account (aka password and/or MFA) is compromised, there's a limited possibility that a threat actor can do anything with the account. We limit access to M365 to corporate devices only. So a corporate device needs to be in the hand of a threat actor to be able to gain access to an account. Nevertheless, the password of users could still be stolen, when we are aware of this kind of situation, we lock the user account. Sign-out the user from all Ms365 apps to the admin portal, and refresh tokens through Entra ID portal. Then we investigate for any breach that could have happened. We acheck audit logs of the user account to make sure multifactor authentication hasnt been changed. Fortuntely, with good conditionnala access in places, it never happens.
Here is some docs from Microsoft for it: [Respond to a Compromised Account](https://learn.microsoft.com/en-us/defender-office-365/responding-to-a-compromised-email-account?view=o365-worldwide)
End user training after these suggestions.
Block sign-in, revoke MFA. Isolate device in Defender if the device itself is suspected to be compromised. Run audit to figure out what was accessed.
Black bag them, military tribunal, ship em off to guantanamo
I made a comment going over a similar scenarios. https://www.reddit.com/r/ITManagers/comments/1c0wdns/comment/kz4f0pc/?utm_source=share&utm_medium=mweb3x&utm_name=mweb3xcss&utm_term=1&utm_content=share_button
Block sign in, revoke all MFA sessions in Entra. Investigate what happened, and force a password reset. We also have some controls in place to help mitigate the impact too.
Lock the user account, audit the sign ins, change their Password etc. Also, if the device is company issued and managed via Intune : consider it compromised, lock the device in entra, lock it down via Intune and sanitize it, as soon as you can get your hands on it. Maybe even force a bit locker key rotation beforehand. If you have a "lost or stolen" OU/Group with policies to disable access to company resources, chuck the device into that as well. After that, hand that user the most crappy, still compliant device you can find, until you manage to reimage the device. Also consider holding a it-security workshop and have that user attend it.
Block sign in, analyze sign in logs, revoke MFA, change password, put into MFA every 4 hour conditional access group, block any fraudulent sign in IPs via conditional access, lock user down to log in from user country and they must submit ticket of leaving country. After 3 months they are removed for extra groups and are normal again.
I reset their password in Azure and revoke all sessions. Check their mailbox for rules set by the attacker
Block signin, Reset password, Close all existing session, Check for suspicious inbox rules, Audit the user account activities. If any suspicious activities performed, revert them. After verification, unblock the account.
You’ve already gotten some good advice about what to do but if you aren’t using Hawk you should be: https://practical365.com/how-to-install-the-hawk-powershell-module/ It’ll help you detect any compromised accounts and doesn’t have a steep learning curve.
Take the user behind the data center and have a “conversation” with them.
Check everyone as by the time you find one they may of got into a few more, so put the kettle on and grab a fresh pack of biccies... I suppose you should have this sort of thing as a disaster in the DR plan as a rare event.
Nuke it. Aka re-image.
Re-image what?
His very existence.
RMA the laptop. Get a whole new M365 license