Last week, we wrote a blog on the takedown of Genesis Market and the implications for session hijacking going forward. In this blog, we’ll explore session hijacking in more depth and provide practical advice for detecting and preventing it.
Session hijacking is an attack where an attacker takes over an active session between a user and a website or application. The attacker can then use the session to access the user's sensitive information or perform unauthorized actions.
There are several specific techniques for session hijacking, including stealing cookie information and infecting devices. For those Mitre ATT&CK fanatics, there are numerous variations of session hijacking.
Cookies are often used to hijack sessions because they are used to store session IDs, which are unique identifiers that allow servers to associate a user's requests with their ongoing session. Stealing session IDs can often mean attackers do not have to log in and sometimes even bypass MFA controls.
At a higher level, it is possible to make comparisons with credential sharing. Didi did just this in a recent video you can watch below.
Session hijacking is not a particularly new tactic, so why does it seem so trendy right now? There are four reasons we can think of.
First, it’s become more popular with the growth of MFA and the adoption of second factors. Cybercriminals now have more obstacles to navigate, and so the simplicity of session hijacking is appealing. You can bypass MFA.
Second, the growth of SSO has made it more appealing to steal a session. All of a sudden, you’re not just getting access to one application but many that fall under SSO.
Third, the professionalization of cybercriminal services (such as Genesis) makes it incredibly easy to perform session hijacking.
Finally, we are becoming better at detecting it, and awareness is growing around this technique. More on the different types of detection in the following section!
It’s not particularly easy to detect session hijacking, but there are a few methods security teams use.
The first (and most basic) approach is to track impossible travel. Impossible travel detects logins that would be geographically impossible – i.e., someone logs in from Boston at 1.00 pm, and then from Oslo at 1.05 pm. This is a good starting point to understand the scale of the problem, but be aware that this will have a lot of noise.
Moving beyond detection, ensuring you do not have excessively long sessions is important. Go into your Okta or Azure AD and make sure the settings are appropriate (we’d suggest a maximum session of no more than one working day).
Oort has several checks that help to identify and prevent session hijacking. Let’s dig in!
The main insight Oort customers have into session hijacking is through the “Risky Parallel Sessions” check, which you can see below. This check identities users that have different session IDs in a one-minute timeframe from at least two unique user agents and two unique IPs.
It’s also possible to search by the Session IDs themselves and view all associated activity.
With Oort’s “Okta Session Length Policy Compliance”, you can be notified when:
Any of your active Okta authentication policies do not have a maximum session lifetime value.
If the session idle expiration value is higher than the Oort value. This is 120 minutes by default, but that is configurable.
Finally, we also detect when there are long-running sessions themselves. Extremely long sessions without re-authentication pose a security threat and can increase the chance of session hijacking. We recommend setting "Maximum Okta session lifetime" to 16 hours (one working day) and "Expire session after the user has been idle on Okta for" to 2 hours.
For responding to users with long-running sessions, we have a solution! Our new “Log out user” action makes it possible to clear the end user sessions and require re-authentication.
If you’d like to understand more about how you can detect and prevent session hijacking in Okta and Azure AD, we’re happy to chat and talk through Oort’s approach. We’re continually working with our customers and Okta to add additional detections in this space.
Similarly, if you’ve built a detection rule that you think is awesome and should be in this blog, let us know!
If you’re a Splunk (and Okta) user, consider checking out some of the the Okta team has released, including detection for . This is a great start, but consider that you will need to tune the rule to accommodate for common IP addresses and commercial VPN usage. For example, products like Zscaler will obfuscate account IP addresses.
For Okta users, you should pay attention to your “” setting. While the setting is enabled by default with Okta Identity Engine, the Classic Engine will not be enabled by default.
