Zoheb here again with my colleague Simon Woolley from the beautiful city of Dubai and today we will be sharing some details on how we helped one of our SMC customer find a compromised user and remediate the impact.
If you haven’t read the 1st blog which covers the background do give it a read now before continuing here.
Let me continue our story about Protecting the compromised user.
Our customer got alerted through Azure AD Risky Sign in Activity that the user is in high Risk and has done impossible travel.
This was an important user in the organization as he was from the CFO office.
The customer’s security team reached out to SMC to check why we are seeing such impossible travel alerts for this specific user.
SMC team checked and found that most of the Risky Sign ins were from multiple Geographies for Exchange Online, we made this user change password and enforced MFA.
See this blog to know How To Identity Investigate Risk
Based on the Sign in activities we were able to see Success in many of the Risky Sign in activities, unfortunately the customer did not have any Identity Protection enabled till then. To further investigate the issue, we involved the customer messaging team and Microsoft Incident Response team.
Simon found that several actions had been taken in this user's mailbox, indicating that the users' Identity had been compromised and was being used to gather additional credentials.
The attacker actions included the following:
Going back further we noted that a week before this the user had clicked on a URL that was determined by ATP to be malicious.
Basically, the attacker tried to compromise multiple users.
Our immediate response to this issue consisted of the following.
Reference for detailed information on similar remediation
Being part of the Microsoft Mission Critical Solution team, we always go above and beyond to support our customers. The first step is always to quickly resolve the reactive issue, then identify the Root Cause, and finally through our Proactive Delivery Methodology, making sure this does not happen again.
In this case we helped our SMC customer identify the cause and gave all necessary recommendations to avoid any future certificate issues. Below are the reasons this issue occurred:
Detailed long-term solution
Enforced MFA through an Identity Protection Policy based on the users Risk level.
Enabled MFA for any user not using a trusted IP.
See the blog below for more information on how we implemented this.
Azure Logic App
We developed a logic app in Azure that triggered when a user clicks on a malicious link.
This logic app then performs the following actions.
Created a new outbound antispam policy to limit the number of recipients per hour internally, externally and a total number of recipients per day. This is to limit the scope of compromise.
Users that need to send more had to provide a business case and are added to a group to enforce MFA and this group was assigned to an outbound anti-spam policy with higher limits.
Please see this blog for more details on recommended settings for eop
This resulted in a drastic reduction in the number of risky users and risky sign-ins. Additionally we helped implement a process of investigation and remediation of these at- risk accounts from the service desk to the internal security department.
NOTE: The features and guidelines implemented in this case were specific to this customer’s requirements and environment, so this is not a “General” guideline to enable any of the mentioned features.
Simon & Zoheb
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.