Persistent AWS Authentication Cookies: A Phishing Risk That Survives Password Changes

This article is based on research by Spencer Gietzen, lead cloud penetration tester at Rhino Security Labs, originally reported by Duo Security. The original research post details a phishing technique tested against AWS IAM accounts.

The Problem: AWS Session Cookies That Outlive Logout

Phishing remains one of the most reliable attack vectors in both offensive security and real-world attacks. It is effective against cloud platforms just as it is against on-premises services — and a discovery by Spencer Gietzen at Rhino Security Labs highlights a particularly persistent threat specific to Amazon Web Services.

Gietzen found that authentication cookies issued by the AWS web console remain valid for approximately 12 hours — even if the account owner changes their password and explicitly logs out after suspecting a compromise. This means an attacker who successfully phishes a victim’s AWS credentials and captures the session cookie has a significant window of persistent access, independent of any subsequent remediation steps the victim takes.

How the Attack Works: Reverse-Proxy Phishing

Standard phishing captures a username and password but is often defeated by multi-factor authentication (MFA). A more sophisticated variant uses a reverse proxy positioned between the victim and the legitimate service. In this setup:

1. The victim is directed to a phishing page that transparently proxies the real AWS login page.
2. Because the content is proxied from the real AWS site, the page looks and behaves identically to the genuine one.
3. When the victim enters credentials and an MFA code, the proxy intercepts both, uses them to create a valid session with AWS, and then redirects the victim to the real AWS site.
4. The victim’s credentials, MFA code, and — critically — the resulting authentication cookie are all captured and stored.

Gietzen used Modlishka, an open-source reverse-proxy phishing framework, to demonstrate this technique during a customer penetration testing engagement.

“Because Modlishka is just proxying the AWS web page to our target user, it will be able to phish them, regardless of whether or not they have MFA enabled. Once the user is prompted for their MFA code and enters it, Modlishka will interject. It will create a valid login session with the AWS web console, store the details, then send the target user off to the actual AWS website and away from our phishing page. The user’s credentials and cookies will be stored in the cookie jar.”

— Spencer Gietzen, Rhino Security Labs

The Cookie Persistence Issue

In most services, session cookies are invalidated when a user logs out or changes their password. AWS behaves differently. Gietzen’s testing showed:

• Stolen AWS session cookies remained valid for approximately 12 hours after issuance.
• Changing the account password did not invalidate the stolen cookie.
• Logging out of the web console did not invalidate the stolen cookie.
• Removing and replacing the MFA device on the account did not invalidate the stolen cookie.
• Changing the password and logging out simultaneously still did not invalidate the stolen cookie.

“We found that after doing this, the session was still valid. This showed us that even after a target user changes their IAM user’s password and logs out, the phished cookies could still create a multi-factor authenticated session to the AWS web console.”

— Spencer Gietzen, Rhino Security Labs

Amazon’s Response: Intended Behavior

When Gietzen reported his findings to Amazon, the company confirmed that the long-lived cookie behavior is intentional. The design is meant to support workloads and sessions that run for extended periods, even after the initiating user logs out of the console.

Because AWS has classified this as expected behavior rather than a vulnerability, it is unlikely to be patched. This places the burden of defense entirely on AWS users and administrators.

Scope and Limitations of the Attack

This technique targets the AWS Identity and Access Management (IAM) system and the AWS web console specifically. Several important constraints apply:

• The attack is effective against software-based MFA (such as authenticator apps) and hardware OTP devices.
• The attack does not work against hardware-based U2F tokens (such as a YubiKey), because U2F performs origin binding — the key’s cryptographic challenge response is tied to the legitimate domain URL and cannot be replayed through a proxy.
• However, U2F tokens are not universally supported across all AWS workflows, including CLI-based access, which limits their applicability as a complete solution.

Defensive Recommendations

Gietzen outlined several mitigations, ranging from highly effective to partially effective:

1. Use a Hardware U2F Security Key

This is the strongest defense. U2F keys such as a YubiKey perform origin verification in the browser, meaning they will refuse to respond to authentication challenges from a phishing domain, even one that perfectly mirrors the legitimate AWS login page. This blocks the reverse-proxy attack entirely at the MFA step.

2. Eliminate IAM Users in Favor of IAM Roles and Temporary Credentials

IAM users have long-lived credentials tied to usernames and passwords — exactly the combination that makes this attack possible. Migrating to IAM roles with temporary, automatically-rotating credentials (via AWS STS) significantly reduces the attack surface. Temporary credentials have short lifespans and cannot be phished in the same way as persistent login sessions.

3. Enforce IP-Based or Context-Based Access Policies

AWS IAM policies can be scoped to restrict console access to known IP ranges or specific conditions. This does not prevent cookie theft but may limit where stolen cookies can be used.

4. Monitor CloudTrail for Unusual Console Activity

AWS CloudTrail logs API and console activity. Unusual login times, geographic anomalies, or activity shortly after a password change should be treated as indicators of compromise and investigated promptly.

Key Takeaways for AWS Administrators

• MFA alone does not protect against reverse-proxy phishing — the MFA code is intercepted in real time and used immediately.
• AWS console session cookies survive password changes and logouts for up to approximately 12 hours by design.
• Hardware U2F keys are the most effective phishing-resistant MFA option currently available for the AWS console.
• Reducing reliance on IAM users with long-lived credentials is a sound architectural defense — prefer roles and temporary credentials wherever possible.
• Incident response plans should account for the possibility that session cookies are still valid even after credentials have been rotated.

The research underscores a broader principle: credential rotation alone is insufficient incident response when session tokens are independent of the underlying credentials. AWS users should treat any suspected phishing event as requiring both credential rotation and session revocation — and should be aware that, by AWS’s own design, full session revocation through the console may not be immediately possible.