If you worked in a SOC, you know that during an analysis, correlating sessions to identify malicious activity or compromise is necessary, yet hard or impossible to perform, based on the available logs from activity-based alerts from Defender for Cloud Apps. In this blog post, we will go over the following topics:
- What are the available options in the Microsoft cloud environment to correlate & validate behavior-based activity through user sessions, like impossible travel activity with Microsoft Entra ID (previously known as Azure Active Directory)
- Also, we will see what the available preventive actions are to mitigate these types of threats
A Real-Life Problem Your SOC Can Face
Once the user authenticates, Entra ID handles authentication for the specific applications in the background and without user interaction.
A “UniqueTokenIdentifier” is generated in the sign-in logs for each application sign-in, such as Microsoft Teams, Exchange Online and SharePoint. However, this cannot be traced back to the initial authentication of the user. Upon a session hijacking attack, the indicator that can be used to spot the malicious activity is the IP address. In a corporate environment, with multiple VPN gateways and public IP addresses, net, while you remain on a secure network and behind a firewall. If one of these egress points becomes unavailable, you will be routed to a new one, which can be in a different geographical location.
On the user side, this is not noticeable, but from the cloud application side, a user is connecting to the same application from a different location, within a matter of minutes, from a log analysis perspective, relying just on the IP address to determine if this activity is malicious or benign can be hard for the analyst.
You can see in the screenshot below, that the same user logged in to the Microsoft Office portal, and opened different Microsoft 365 solutions from different IP addresses:
- Initial login was made from the UK (Location column: GB)
- The IP address was changed to a Bulgarian address and opened Exchange Online from that (Location column: BG)
- SharePoint Online accessed after the egress point was changed to a Brazilian IP address (Location column: BR)
Unfortunately, the remaining available information for the events are not enough to trace back the initial login and verify the legitimacy of the user’s activity, as the identifier of that action is not tied to the user’s further activity logs.
Previously, these activities triggered separate alerts in the Defender for Cloud Apps platform, but they were noisy and generated many false positives. Currently, these activities are only marked as behaviors and do not trigger alerts, they are just used as telemetry for other detections.
Implementing the Solutions, Prevent, and Detect
Whilse the sessions cannot be correlated or traced back to the initial authentication of the user, it is still possible to take steps to analyze the events. Companies who utilize Sentinel UEBA can query the BehaviorAnalytics table for anomalies, for example using the following query:
BehaviorAnalytics
//Lookback at the last 24 hours of activity
| where TimeGenerated >= ago(24h)
//Keep line 5 'true' to capture logons where the user is connecting from a device for the first time
| where ActivityInsights.FirstTimeUserConnectedFromDevice == true
//Keep line 7 'true' to capture logons where the user is connecting from a country for the first time
| where ActivityInsights.FirstTimeUserConnectedFromCountry == true
//Keep line 9 'true' to capture logons where origin country is uncommon within the user base
| where ActivityInsights.CountryUncommonlyConnectedFromAmongPeers == true
| extend User = tostring(UsersInsights.AccountDisplayName)
| extend Application = tostring(ActivityInsights.App)
| extend DeviceInsights = extract(@'UserAgentFamily\":\"([^\"]+)\"', 1,tostring(DevicesInsights))
| summarize by User, UserName, UserPrincipalName, SourceIPLocation, Application, SourceDevice, ActionType, DeviceInsights
This query allows the analyst to search for a specific user to quickly verify if there have been sign-ins where the country and device have not been seen before.
On the other hand, there are preventive measures that can be used to protect your organization from these types of attacks. If you have Microsoft Entra ID Protection (previously known as Azure Active Directory Identity Protection) licenses, you can set up Conditional Access policies based on user-risk and sign-in risk. The user risk is representing the probability of the account being compromised and the sign-in risk is representing the probability of an unauthorized login. In the below screenshot you can see a Conditional Access policy, where you can take advantage of these user-based risks.
Diagram 1: Creation of risk-based conditional access policy
Based on the detected risk level, you can force additional steps under “Access control”, such as multi-factor authentication or password change, that must be performed by the end user to be able to access the configured application.
While we discover the capabilities of the risk-based Conditional Access policies, we cannot miss mentioning one of the built-in features in the policy. For some applications, continuous access evaluation (CAE) is available in a conditional access policy. CAE can assess critical events, such as user account deletion, or high user-risk detection near real-time and enforce the configured action in the conditional access policy.
Diagram 2: User condition change flow
In a CAE session compatible app, the token lifetime increases up-to 28 hours, because policies and risk are evaluated in real time. Critical events and policy evaluation drive revocation.
Hopefully, this post helps you achieve a better security posture and makes you more resilient against malicious actors, who tries to hijack your user’s sessions. For professional support contact us: https://www.bluevoyant.com/contact-us.