In the past few years, we have witnessed a significant shift in the attack landscape, from stealing clear text credentials to targeting session-based authentication. This trend is driven by the proliferation of multi-factor authentication (MFA), which makes it harder for attackers to compromise accounts with just passwords. However, MFA is not a silver bullet, and post-authentication materials like session tokens, cookies, API keys and machine certificates can still be exploited to bypass authentication and gain access to sensitive systems and data.
In this blog post, I will share some of our red team insights and explain how session-based attacks are evolving beyond the web browser. I will also recommend ways for organizations to protect themselves from these threats and reduce their attack surfaces.
What Are Post-Authentication Attacks and Why Are They Dangerous?
Post-authentication attacks are a type of attack that targets the authentication tokens that are used to maintain a user’s or a machine’s identity and access rights after the initial login process. These tokens can take various forms, such as cookies, API keys, machine certificates and OAuth tokens. They are often stored in the browser, in files, in memory or in databases and are transmitted over the network when a user or a machine interacts with a web application or an API.
The main advantage of session-based attacks for the attackers is that because they happen after the authentication phase and the user is already validated, they can bypass MFA and other security controls applied at the login stage. An attacker can impersonate the user or the machine and access their authorized resources by stealing or forging a valid session token (via the Golden Ticket or Golden SAML attack technique). Moreover, session tokens are often long-lived and have broad privileges, meaning the attacker can maintain persistence and move laterally within the network.
How Post-Authentication Threats Are Evolving Amid the Expanding Attack Surface
The most well-known and common form of post-authentication attack is cookie stealing, which involves capturing or manipulating the cookies used by web browsers to authenticate users to web applications. Cookies are session tokens issued to the web server after users log in with their credentials and MFA and are stored in the browser. The browser then sends the cookies along with every request to the web server, which validates them and grants access to the user.
Cookie stealing can be performed in various ways, such as:
- Exploiting vulnerabilities in the web application or the browser, such as cross-site scripting (XSS), cross-site request forgery (CSRF) or XML external entity (XXE) injection, that allow the attacker to execute malicious code or requests on behalf of the user and access their cookies.
- Sniffing or intercepting the network traffic between the user and the web server and extracting the cookies from the HTTP headers. This can be done by compromising the user’s device, the web server or any intermediate node on the network, such as a router, a proxy or a firewall.
- Accessing the browser’s storage, where the cookies are saved, and copying them to the attacker’s device. This can be done by exploiting the user’s device or by tricking the user into downloading a malicious browser extension, a file or software that can read the browser’s storage.
- Scraping the browser process memory space, some cookies are stored as session cookies, which means they are not written to disk and exist only within the browser memory as ephemeral cookies for the duration of the session and as long as the browser is open. Since the browsers are designed to run as unprivileged applications, any other program with the same level of access (unprivileged) can read the browser memory.
As you can see, cookies are key security material and are thought out by threat actors. If you were to eliminate cookies from the browser, the experience would become more secure. And that’s no longer a hypothetical scenario, with the arrival of our recently released, identity-centric CyberArk Secure Browser – an industry first (and which our red team helped develop). The browser eliminates the writing of cookies to a device’s disk, which means there are no cookies for attackers to steal. By eliminating cookies from the disk, organizations can help protect themselves from certain types of session-based attacks that rely on stealing cookies to bypass the authentication process.
However, cookies are not the only form of session token that session-based attacks can target. As web applications and APIs become more complex and diverse, and as more machines and devices communicate with each other over the internet, other forms of session tokens are emerging and becoming more prevalent. These include:
- API keys, which are secret tokens that are used to authenticate and authorize machines or programmatic users to access APIs. API keys are often used for programmatic or automated interactions with cloud services, such as spinning up virtual machines, accessing storage buckets or sending notifications. API keys are usually stored in files or databases and transmitted over the network as HTTP headers or parameters.
- Machine certificates, which are digital certificates that are used to authenticate and authorize the communication between machines or devices. Machine certificates, such as VPNs, HTTPS or SSH, are often used to secure connections between servers, clients and IoT devices. Machine certificates are usually stored in files or hardware modules and are transmitted over the network as part of the TLS handshake.
- OAuth tokens, which are tokens that are used to delegate access to third-party applications or services. OAuth tokens are often used for social login, where a user can sign in to a web application using their existing account from another platform, such as Google, Facebook or X (née Twitter). OAuth tokens are usually stored in the browser or databases and transmitted over the network as HTTP headers or parameters.
These session tokens are also vulnerable to session-based attacks and can be stolen or forged by attackers in ways similar to cookies. For example:
- API keys can be exposed by vulnerabilities in the API or the client, by network sniffing or interception – or by accessing the files or databases where they are stored
- Machine certificates can be compromised by vulnerabilities in the TLS protocol or the implementation, network sniffing or interception or accessing the files or hardware modules where they are stored.
- OAuth tokens can be hijacked by vulnerabilities in the OAuth protocol or the implementation, network sniffing or interception or accessing the browser or databases where they are stored. (A recent example of this is APT29’s attack on Microsoft, where the attackers breached a legacy test OAuth application and then created a series of malicious OAuth apps, which enabled them to gain further access. This ultimately allowed the attackers to access certain corporate email accounts.)
How Organizations Can Help Protect Themselves From Post-Authentication Attacks
Post-authentication attacks are a serious and growing threat, and organizations need to take proactive measures to protect themselves and their users from these attacks. Some of the best practices and recommendations that organizations can follow are:
- Implement the principle of least privilege (PoLP) and limit the scope and duration of the session tokens. Session tokens should only grant the minimum access rights needed, when needed (just-in-time), for the specific task or interaction and should expire or be revoked as soon as possible. This can reduce the impact and the risk of session token compromise.
- Enforce strong encryption and integrity checks on the network communication and the session tokens. Session tokens should be encrypted and signed by the issuer and transmitted only over secure channels, such as HTTPS or TLS. This can prevent the attackers from sniffing, intercepting or tampering with them.
- Monitor and audit the usage and activity of session tokens. The issuer should log and track session tokens and any abnormal or suspicious behavior, such as multiple or concurrent logins, unusual locations or devices or anomalous requests or actions, should be detected and alerted. This can help organizations identify and respond to session token compromise.
- Educate and train the users and the developers on the risks and the best practices of session token security. Users should be aware of the dangers of phishing, malware and social engineering and avoid clicking on suspicious links, downloading unknown files or sharing their session tokens with anyone. Developers should be familiar with the latest session token security standards and guidelines and follow secure coding and testing practices.
With attackers relentlessly finding new ways to exploit them, post-authentication attacks are a complex and evolving challenge. Organizations must be prepared and vigilant to defend themselves from these threats by implementing security measures such as least privilege, monitoring and maintaining an assume breach mindset. Additionally, solutions such as CyberArk Secure Browser, which completely eliminates cookies from the disk, can provide an added layer of protection.
Shay Nahari is VP of CyberArk Red Team Services.
Editor’s note: For more insights from Shay Nahari on this subject, secure web browsing and beyond, listen to the April 2024 CyberArk Trust Issues podcast episode, “Secure Browsing and Session-Based Threats.” The episode is available in the player below and on most major podcast platforms.
