Session Cookie Vulnerability Lets Attackers Bypass Entra ID MFA and Impersonate Users

A flaw in a custom session-cookie system allowed an unauthenticated attacker to pose as employees and administrators in a yard management platform.

The issue did not break Microsoft Entra ID itself. Instead, it let a weak application-side session layer accept a forged identity after the normal sign-in controls had been bypassed.

The affected platform used Entra ID single sign-on and multi-factor authentication, but also relied on a signed cookie to maintain application sessions.

That design created the same risk seen in cookie-based account takeover attacks, where control of a trusted session can matter more than a password.

Resecurity said in a report shared with Cyber Security News (CSN) that its authorized assessment uncovered the weakness while reviewing a supply-chain yard management system.

The researchers said no production systems were tested, test records were restored, and the identities referenced in the proof of concept were anonymized.

Researchers successfully impersonated 95 employee accounts from 241 tested user IDs, including accounts with elevated rights. A forged administrator session was able to perform a state-changing API request, meaning the flaw could expose operational data and let an intruder act under a legitimate employee’s identity.

Session Cookie Vulnerability

The bypass came from two linked design errors. The application signed a cookie with a hard-coded secret that matched the cookie name, while the signed value was a user’s publicly exposed database identifier. Neither value should have been sufficient to establish an authenticated session.

A signed cookie normally detects changes by applying a server-held cryptographic secret to a random session reference. Here, the target CUID could be obtained from API responses, including the authenticated-user endpoint and directory responses.

With a predictable secret, an attacker could make a cookie the server treated as belonging to another user. That distinction matters because the resulting request never needed the victim’s password, a fresh MFA approval, or an Entra ID access token.

It was a failure in the application’s trust model, not evidence that Entra ID cryptography was compromised. Recent reporting on Entra refresh token theft similarly shows why identity defenses must protect the artifacts issued after sign-in.

The platform’s broader controls appeared sound during testing: it used RS256-signed access tokens, schema validation and parameterized database access.

However, the separate session cookie became an alternate route into the application. The researchers also found an unauthenticated Swagger interface that exposed the full 251-route API surface, giving the assessment added visibility.

Containing the Session-Layer Risk

The priority is to rotate the compromised session-signing secret and invalidate existing sessions. This cuts off cookies produced with that key.

Teams should then review authentication and application logs for unusual session creation, account changes, administrative actions, or activity that does not match the expected user or device.

Developers should replace identity-bearing, client-controlled session values with randomly generated session identifiers stored and verified on the server.

Separate, high-entropy secrets should be held securely for development, staging, and production, never reused across environments. A secure cookie flag alone cannot protect a session design that trusts a predictable value.

Organizations should also assess every custom layer added around a cloud identity provider. Strong upstream single sign-on and MFA cannot compensate when an application accepts a separate credential as decisive proof of identity.

Defenders can apply lessons from the Cookie-Bite session hijacking technique, including monitoring suspicious sign-ins, restricting unapproved browser extensions, enforcing compliant-device access, and applying token protections.

If stateless tokens remain necessary, Resecurity recommends strong cryptographic keys, expiration limits and replay protections. Teams should ensure session revocation covers every host that accepts the cookie.

The same forged cookie in this case worked on both the API and administrative application hosts. Reports on Microsoft 365 session theft have likewise stressed that password resets alone may not terminate authenticated sessions.

The case is a reminder that MFA verifies a login event, while session management decides what happens afterward. A random server-side session reference, rotated secrets, and meaningful monitoring reduce the chance that an attacker can turn an exposed identifier into account impersonation.

Cut every SOC alert investigation by 21 min. Power your SOC with instant IOC context for immediate response: Integrate TI Lookup in your SOC