Pass-The-Cookie (PTC), also known as token compromise, is a common attack technique employed by threat actors in SaaS environments. 

In the past, Obsidian’s Threat Research team noted a pattern where most PTC attacks focused on stealing the identity provider (IdP) primary authentication cookie. However, there has since been a shift in attacks–now targeting authentication cookies for SaaS applications that extend beyond the IdP. 

In this blog post, we explore the phases of a PTC attack, leveraging a recent instance detected on the Obsidian platform. We then offer guidance for how to address these attacks through session monitoring and remediation. 

Despite additional security provided by Okta Multi-Factor Authentication (MFA), the threat actor managed to defeat this, leading to the compromise of both Okta and O365 environments. 

Let’s explore what happened:

Obsidian detected a Pass-the-Cookie: New Malicious Microsoft Session event and raised an alert.

 Looking into the sequence of events from the alert, we can see:

• The user successfully authenticated with MFA factor via Okta from  162.XXX.XXX.XXX and a Windows user agent.
• The user then accessed the Office 365 application. However, the session quickly switched to a suspicious IP address 67.2XX.XXX.XXX with a mismatched user agent.

Upon further investigation, the 67.2XX.XXX.XXX IP address was identified to be part of the TOR Guard VPN service provider to anonymize traffic originations and obfuscate payload details.

In this instance, the compromise appears to be targeted as it did not authenticate into any other application other than O365.

• This stolen authentication cookie not only provides entry to the user’s O365 account but also grants access to any data the account is authorized to retrieve. This could include PII, passwords, or sensitive business information.
• Application sessions offer ideal opportunities for threat actors to establish persistence. Without additional security control by a security team, these sessions often have significantly longer timeout periods by default than restricted IdP sessions. This extended timeframe offers attackers the chance to secure persistent access to the application, a vulnerability frequently overlooked by security teams.
• Incident response playbooks often advise revoking a user’s session and changing passwords in the IdP for account compromise. Yet, this may fall short, as malicious actors can retain access via stolen application session cookies (e.g. Office 365). A more effective strategy involves revoking all compromised application session tokens, extending beyond the IdP session token.

#1: Establish logging and detection across SaaS applications, beyond the IdP.

1. Build a logging and detection system: To detect suspicious activity, create a logging and detection system that can correlate all login and activity events. 
2. Understand user activity: Gain a comprehensive understanding of user activity by correlating events. This involves looking at activities not just within the IdP but across all SaaS applications. 
3. Identify anomalies: Focus on detecting anomalous activity within user application sessions. This step involves understanding where user sessions are authenticated and where application access originates.
4. Alert team for investigation: When anomalous activity is detected, generate alerts to notify the security team for further investigation. It’s crucial to provide sufficient context for successful triage.
5. Tune system to minimize false positives: Fine-tune the detection system to reduce false positives. This involves distinguishing normal activities such as user VPNs and mobile networks from potentially malicious behavior.

You can leverage the Obsidian platform to help you complete these actions. Here, you can observe the platform in action, offering practical insights into the PTC attack we examined earlier. It provides analysts with detailed information on a single page, significantly reducing triage and remediation time–reducing the overall risk profile for organizations.

#2: Update incident response playbooks to remove all persistence vectors.

1. Terminate all sessions: Addressing a compromised SaaS identity requires more than just remediation in the IdP. In the given scenario, it’s essential to terminate both the Okta and O365 sessions to eliminate the threat actor from the environment. Following best practices, revoke all user sessions and reset any compromised passwords. 

2. Check for Additional Persistence: Look for signs of persistence. Identify and remove any new MFA devices associated with the compromised account. You should also verify and eliminate any unfamiliar email addresses or phone numbers linked to the compromised account.

If you are a SaaS application developer, you can help by implementing mechanisms to terminate sessions and revoke active tokens in your application/s. Ensure your application provides the following capabilities: 

• Session and token termination via administration account: The application should offer application administrators a mechanism to terminate sessions and tokens on demand. 
• Session and token termination via API endpoints: Ensure the application has a mechanism to revoke tokens via API endpoints. Given the decentralized nature of SaaS management, security teams may not be the administrator of each application. The inclusion of an API endpoint facilitates centralized incident response, reducing remediation time that often lags due to the need for additional resourcing.  

Addressing Pass-The-Cookie attacks demands a proactive approach. Discover how Obsidian can help you address these evolving instances by downloading The Forrester Wave: SaaS Security Posture Management, Q4 2023, or schedule a demo today.

The post Behind the Breach: Pass-The-Cookie Beyond IdPs appeared first on Obsidian Security.

*** This is a Security Bloggers Network syndicated blog from Obsidian Security authored by Farah Iyer. Read the original post at: https://www.obsidiansecurity.com/blog/behind-the-breach-pass-the-cookie-beyond-idps/