How to Simulate Session Hijacking in Your SaaS Applications

Originally published by AppOmni.

Written by Justin Blackburn, Sr. Cloud Threat Detection Engineer, AppOmni.

In our recent post on session hijacking, we examined how sessions work and discussed how sessions can be compromised. We also outlined mitigations that practitioners implement to thwart session hijacking and mitigate the impact of a compromised session.

In this second installment of our technical blog series on session security, we’ll explore some of the challenges associated with detecting a compromised session. We’ll then walk through how to simulate session hijacking in a lab environment so that you can evaluate indicators of a potential compromise.

Key takeaways:

• Server-side audit logs help detect attacks regardless of the method a bad actor used to steal session cookies.
• Because not all SaaS apps generate audit logs with the amount of information needed to easily detect hijacked sessions, it can be challenging to identify this attack path in your environment.
• The best way to hone your session hijacking detection strategy involves creating a testing environment and simulating your own attack.

Session hijacking detection: Some key challenges

There are a number of methods used to steal a user’s session cookies, including cross-site scripting (XSS), browser hijackers, and phishing. Some browser and endpoint security solutions may be able to detect client-side indicators in some conditions. For example, these solutions might block XSS or alert you to the presence of a malicious browser extension.

But what if cookies are stolen in another way, like via a phishing attack? Using the server-side audit logs of the service gives us the opportunity to detect the attack regardless of the method used to steal the victim’s session cookies.

Each and every SaaS application logs events differently. Some are quite verbose and log many events with a high level of context, while other apps do not. As a result, some SaaS applications may not provide the required visibility to detect, with a high degree of confidence, indicators of a compromised session.

Below are two audit log examples for creating a new user in two different SaaS services. In both examples, Mallory is creating a new user, Bob. Notice that the format and level of detail provided varies by service, which can impact the detection strategy later.

<code>
{
  "kind": "admin#reports#activity",
  "id": {
    "time": "2024-04-15T17:27:02.768Z",
    "uniqueQualifier": "3314472940692087123",
    "applicationName": "admin",
    "customerId": "C02abcdeab"
  },
  "etag": "\"rQ3qpTrpjMqlOD9Fi6ZCgnwwpo6zAd3g53g55U0J6c8Yw/5pzih88L6fo0NupRAuuLv2Ar50\"",
  "actor": {
    "email": "[email protected]",
    "profileId": "111620519819984001",
    "callerType": "USER"
  },
  "ipAddress": "198.51.100.5",
  "event": {
    "type": "USER_SETTINGS",
    "name": "CREATE_USER",
    "parameters": [
      {
        "value": "[email protected]",
        "name": "USER_EMAIL"
      }
    ]
  }
}</code>

An audit log for creating a new user in a SaaS service

<code>{
    "action": "user_created",
    "actor":
    {
        "type": "user",
        "user":
        {
            "email": "[email protected]",
            "id": "U1A1AABCD",
            "name": "Mallory Miller",
            "team": "T00111AA2"
        }
    },
    "context":
    {
        "ip_address": "198.51.100.5",
        "location":
        {
            "domain": "acme",
            "id": "T00111AA2",
            "name": "Acme",
            "type": "workspace"
        },
        "session_id": 5750000001234,
        "ua": "Mozilla/5.0 (Macintosh; Intel Mac OS X 13_5_0) AppleWebKit/537.36 
            (KHTML, like Gecko) Slack/4.33.84 Chrome/114.0.5735.134 
            Electron/25.2.0 Safari/537.36 AppleSilicon Sonic Slack_SSB/4.33.84"
    },
    "date_create": 1691752039,
    "details": null,
    "entity":
    {
        "type": "user",
        "user":
        {
            "email": "[email protected]",
            "id": "U01AA2B2CAA",
            "name": "Bob Smith",
            "team": "T00111AA2"
        }
    },
    "id": "18ab534a-0000-4100-a123-aa12bb32ff35"
}</code>

An audit log for creating a new user in a different SaaS service

Session hijacking can also be difficult to detect even in SaaS applications that generate excellent audit logs. As we discussed in our first post on session hijacking, when an adversary uses a compromised session cookie/token to impersonate the victim, they bypass the entire authentication process—including multi-factor authentication (MFA).

Most cloud services log authentication events so that you know each time a user signs in. However, there will not be another authentication event if an adversary uses a stolen session token to access the victim’s account. Therefore, it’s important to keep in mind that we won’t see an authentication event from a bad actor—instead, we will see the next logged action that the bad actor takes in the compromised account.

Let’s walk through a tutorial of a simulated attack so that we can see how to use a SaaS app’s audit logs to detect a hijacked session.

Tutorial: Simulating a compromised session

Tutorial prerequisites

In this tutorial, we will perform session hijacking in a testing environment. First, we need to determine which SaaS applications we want to test. Then, we’ll obtain access to a developer or test account in each service.

Before we begin testing, we must establish a way to collect the generated audit logs from our target SaaS application. Most applications provide a method to export audit logs to a SIEM or data lake. Some applications also provide a UI for viewing audit logs on demand within an admin portal, but many of those applications don’t provide the full event details in the UI. We recommend that you export your app’s audit logs to a SIEM or data lake so that you have access to the full event information.

Our testing environment

The environment we need to test session hijacking is fairly simple. We’ll need two different testing machines—either physical or virtual—with different public IP addresses. In our simulation, we used a Windows computer and MacBook computer in different physical locations, but you can use any operating system as you follow along with this tutorial.

We’ll also need a web browser with a cookie editor plugin installed on each testing machine. We used Firefox with the Cookie-Editor plugin.

While this is the simplest method to simulate a session compromise, there are several more advanced tools that may be required for some SaaS apps if they have implemented session protections. Evilginx—a popular open-source AitM attack framework—can be used to phish login credentials and capture session cookies in that process. Burp Suite—a security app used for web app penetration testing—can also be useful for capturing and replaying sessions. For this tutorial, we’ll just use a browser cookie editor plugin for simplicity.

Tutorial: Simulating the attack

On test machine A, log in to a test account for the SaaS application we want to evaluate. Then, export all the cookies in JSON format from this domain using a browser cookie editor plugin.

On test machine B, follow the steps below:

Step 1: Browse to the URL of the SaaS application being tested. If the authenticated URL differs from the login URL, use that URL. For example, lets say after logging in to example.com, it redirects to app.example.com. In this case, browse to app.example.com.

Step 2: Import the cookies obtained from test machine A by using a cookie editor plugin. It’s usually necessary to refresh the page or return to the authenticated URL after importing cookies if you’ve been redirected back to a login or home page after the first attempt.

Step 3: If you’re successful, you will have an authenticated session on machine B. If you’re not successful, you may be continuously redirected to a login or home page. The service may have session protections in place to prevent this type of attack.

Step 4: If you’re successful, perform at least one action that you have verified is logged by the service. For example, change the name of a user.

Evaluating the attack

If you successfully hijack machine A’s session on test machine B, the next step is to analyze the generated audit logs.

First, locate the initial event where your user initially logged in on test machine A. Identify which fields are present in the audit log and make note of the value of several key fields—especially the IP address, session ID, ASN (Autonomous System Number), and user agent string. At a minimum, if an IP address and session ID aren’t present, confidently detecting session hijacking will be tricky.

Next, locate the event generated from the action you took on test machine B, like changing the name of your user. Again, locate the IP address, session ID, ASN, and user agent string if present. You should notice the session ID has not changed from the initial login event, but the IP address, ASN, and user agent string are different. While there are some exceptions and additional considerations that we’ll discuss in the next section, these signals would represent a likely compromised session.

Some considerations as you evaluate your results

A change in the IP address, and ASN, for a single session can sometimes be attributed to the user toggling the VPN or switching locations if they were on a mobile device. In this case, we want to take into account the user agent string if it’s present. In this scenario, the user agent string should remain the same since the user has not changed their device or browser.

We also want to consider a scenario in which the IP address just slightly changes between events generated within the same session. For example, the initial authentication event indicates an IP address of 198.51.100.2, but subsequent events indicate 198.51.100.3 for the same user and session. In this case, it’s fairly safe to assume that the user is on a network with a range of public IPs, which may periodically change based on time or specific location of the user.