How to Detect Session Hijacking in Your SaaS Applications

In the final post of our three-part, technical blog series on session hijacking, we’ll explore strategies to detect compromised sessions in SaaS applications. Our first post examined how sessions work and how they can be compromised, while our second post delved into the challenges associated with detecting a compromised session. This blog will highlight rule-based and user behavior analytics (UEBA) approaches for identifying anomalies in user sessions that may indicate hijacking. 

How the AppOmni SaaS security platform detects session hijacking

As a refresher, session hijacking occurs when a bad actor gains unauthorized access to an active session to impersonate the legitimate user. Here’s an example: While reviewing audit logs for Alice’s activity in Microsoft 365, we see that she signed in, sent emails, reviewed documents, and then changed her password before logging off. But, as we dig deeper, we notice that the password change event originates from a different IP address and user-agent string than all the previous events.

State rule-based approach

To detect similar incidents like the example above, AppOmni customers have several out-of-the-box rules enabled to detect session hijacking. Let’s dive into one such rule: “Suspicious Session Activity Detected.”

This rule relies on events that have been normalized and enriched by the AppOmni SaaS Security Platform.

This rule triggers an alert when two events match the conditions in the rule logic within a 1-hour timeframe. For both events, the service type, user name, and session ID must be identical. However, the source Autonomous System (AS) domain and operating system type must be different for each of the two events.

What is the significance of the state fields?

Source AS domain: In our earlier example, we noticed that the IP address changed within Alice’s session which is a possible indicator of a hijacked session. So why are we looking for a change in the source AS domain instead of the source IP address? With the exception of remote workers, employee devices are often dynamically assigned one of several public IP addresses leased by the business, which may periodically change. 

For example, if an IP address changes from 198.51.100.1 to 198.51.100.2, we can assume the employee remains on the same network. The AS domain will be the same for both IP addresses. However, if the IP address belongs to a different network, it will be associated with a different AS organization. This method helps reduce false positives when IP changes occur within the same network during a session.

Operating system type: User agent strings contain information about the user’s operating system and browser, including versions. If the operating system or browser updates during the user’s session, which can happen frequently, the user agent string will slightly change. AppOmni extracts the operating system and browser name from the UA string which does not include version numbers. This approach reduces the rate of false positives when a change in the OS or browser version occurs during a session.

What is the significance of the logic conditions?

Beyond the field changes already discussed, this rule only triggers an alert when other conditions are also met in both events. Events must have one of the listed event actions which are values normalized by AppOmni. This curated list is based on applicable high-value events from the SaaS service for this rule. 

UEBA rule-based approach

User and entity behavior analytics (UEBA) capabilities allow AppOmni to write detection rules that alert when events occur that are new or anomalous based on a user’s baseline activity. For example, if a user normally logs in to a SaaS service from a specific region but one day logs in from another country, we can alert on that anonymous login event.

We can use UEBA to detect anomalous events within a user’s session. Let’s take a look at the rule: “Session Activity Detected From New Location.”

How to detect anomalous user behavior across new network sessions

This UEBA rule will detect when a sequence of events matches the logic and the second event is anomalous based on the user’s baseline activity. 

1. A user logs in to a SaaS service and starts a session (normal).
2. A user performs an action in the same session from a new ASN not previously used in the past 30 days.

Challenges in detecting session hijacking across SaaS platforms

Detecting session hijacking is possible when a SaaS service generates events that include key details such as session ID, IP address (from which the AS domain is derived), and host information like the user agent, browser name, or operating system. Although it’s feasible to detect a hijacked session using either network or host data alone, combining both network and host information within the same session improves detection accuracy and reduces the likelihood of false positives.

But, the level of event logging can vary significantly between SaaS services. For example, a login event from Microsoft 365 is structured very differently than from one in Salesforce. To explore which attributes are supported and view sample events from common SaaS providers, visit our open-source Event Maturity Matrix tool. 

Final thoughts

Session hijacking remains a common and effective attack method used by threat actors to compromise SaaS accounts. Without proper controls and detection mechanisms, organizations may not realize an attacker has accessed their accounts until long after the breach has occurred. Implementing reliable methods to detect indicators of session hijacking is essential for maintaining security in critical SaaS environments.