# AWS CLI Login Phishing: Abusing `aws login --remote` Cross-Device Authentication to Steal Console/CLI Sessions

> Mitiga Security researchers demonstrated a phishing technique that abuses the AWS CLI's new `aws login --remote` cross-device authentication flow, hosting a fake 'session expired' page on legitimate-looking S3 infrastructure to social-engineer victims into pasting their AWS verification code, which the attacker's own CLI process then exchanges for a fully authenticated, MFA-bypassing session on attacker-controlled infrastructure.

- **Published:** 2026-07-23T00:00:00Z
- **Last reviewed:** 2026-07-23T00:00:00Z
- **Canonical:** https://intel.threadlinqs.com/threat/TL-2026-1646
- **ID:** TL-2026-1646
- **Severity:** HIGH
- **Category:** PHISHING
- **Status:** ACTIVE
- **Detections:** 9 · **IOCs:** 19 (full data via the Threadlinqs MCP server — Purple tier)

## Description

In November 2025, AWS introduced `aws login`, a new CLI command that lets a device without a local browser (a server, container, or remote workstation) authenticate a user by generating a device code and directing the user to complete sign-in on a separate device — a pattern known as 'cross-device' or 'device code' OAuth authentication. AWS CLI marks these sessions with the OAuth client ID `arn:aws:signin:::devtools/cross-device` and the CloudTrail events `AuthorizeOAuth2Access` and `CreateOAuth2Token`.

Because the flow intentionally decouples the device performing browser authentication from the device that ultimately receives the session, it is structurally phishable: whoever possesses the verification code displayed to the user can complete the login from any device, anywhere. Mitiga researchers Idan Cohen and Asad Saffoury built a full proof-of-concept attack chain entirely on native AWS infrastructure to weaponize this gap.

The attacker first runs `aws login --remote` on their own EC2 instance (automated via an `expect` script that waits for a verification code to be fed to the waiting CLI process). This generates a device code and a 10-minute authentication window. The attacker then sends the victim a phishing email claiming their AWS session has expired or that a security verification is required, linking to a page hosted on Amazon S3 at a bucket such as `aws-session-expired.s3.us-east-1.amazonaws.com`. Because the phishing page is served from a genuine `*.amazonaws.com` domain, it evades email security filters, allow-listed corporate proxies, and casual visual inspection that would normally flag a suspicious external domain.

When the victim visits the page and clicks through, they are walked through a completely legitimate AWS authentication flow at `signin.amazonaws.com` — real username/password and MFA challenge — because the underlying device code and session belong to the attacker's real `aws login --remote` invocation, not a spoofed login form. AWS then displays the victim a legitimate Base64-encoded JWT verification code and instructs them to enter it to confirm the device. The victim, believing they are resolving their own 'expired session,' pastes this code into the attacker's fake webpage instead of (or in addition to) the real AWS confirmation UI.

The fake page's supporting backend — an API Gateway-fronted Lambda function with three endpoints (`/start`, `/session/{id}`, `/token/{id}`) and a DynamoDB table keyed by `sessionId` — captures the submitted code via a POST to `/token/{id}` and relays it to the attacker's EC2 instance using AWS Systems Manager `SendCommand`. The waiting `expect` script feeds the stolen code into the attacker's paused `aws login --remote` process, which then exchanges it for temporary AWS credentials. Because the victim performed real MFA on the real AWS authentication surface, the attacker's session inherits that MFA assurance — the technique effectively bypasses phishing-resistant MFA by phishing session material downstream of authentication rather than credentials upstream of it. Once the attacker holds working CLI credentials, all subsequent AWS API activity is logged as the legitimate user, enabling IAM persistence (new users/roles, access keys, trust-policy backdoors), lateral movement across accounts, and reconnaissance/exfiltration that blends into normal CloudTrail activity.

The root abuse condition — a code-confirmation UI whose authenticity a human cannot verify — is not unique to `aws login --remote`; independent research (Christophe Tafani-Dereeper, 2024; Adan Alvarez; Common Fate/Granted) has previously documented the identical class of weakness in AWS IAM Identity Center SSO device-code authentication and other OAuth device-flow implementations, and mitigation tooling (the Granted browser extension) already exists for the SSO variant. Mitiga's contribution is demonstrating a complete, automated, AWS-native (S3/Lambda/DynamoDB/API Gateway/EC2/SSM) attack chain specifically against the newer `aws login --remote` command, plus a concrete CloudTrail detection and SCP-based prevention strategy.

## MITRE ATT&CK

- T1589 Gather Victim Identity Information
- T1583 Acquire Infrastructure
- T1585 Establish Accounts
- T1587 Develop Capabilities
- T1566 Phishing
- T1199 Trusted Relationship
- T1059 Command and Scripting Interpreter
- T1651 Cloud Administration Command
- T1136 Create Account
- T1098 Account Manipulation
- T1078 Valid Accounts
- T1078 Valid Accounts
- T1098 Account Manipulation
- T1078 Valid Accounts
- T1685 Disable or Modify Tools
- T1550 Use Alternate Authentication Material
- T1528 Steal Application Access Token
- T1621 Multi-Factor Authentication Request Generation
- T1552 Unsecured Credentials
- T1526 Cloud Service Discovery
- T1069 Permission Groups Discovery
- T1580 Cloud Infrastructure Discovery
- T1550 Use Alternate Authentication Material
- T1530 Data from Cloud Storage
- T1102 Web Service
- T1104 Multi-Stage Channels
- T1071 Application Layer Protocol
- T1567 Exfiltration Over Web Service
- T1531 Account Access Removal

## Sources

- [AWS Login Phishing Attack: How Attackers Exploit New Authentication](https://www.mitiga.io/blog/inside-aws-login-exploring-a-new-phishing-method)
- [Phishing for AWS Credentials via the New 'aws login' Flow](https://medium.com/@adan.alvarez/phishing-for-aws-credentials-via-the-new-aws-login-flow-39f6969b4eae)
- [aws login: What AWS CLI's New Console-Credential Command Can (and Can't) Do](https://builder.aws.com/content/3FvKQrWHg5jyCbBQoyA5MyODrH2/aws-login-what-aws-clis-new-console-credential-command-can-and-cant-do)
- [Granted now mitigates device auth phishing in AWS IAM Identity Center](https://www.commonfate.io/blog/granted-mitigates-aws-phishing)
- [Phishing for AWS credentials via AWS SSO device code authentication (updated 2024)](https://blog.christophetd.fr/phishing-for-aws-credentials-via-aws-sso-device-code-authentication/)
- [Configuring IAM Identity Center authentication with the AWS CLI](https://docs.aws.amazon.com/cli/latest/userguide/cli-configure-sso.html)
- [Sign in through the AWS Command Line Interface](https://docs.aws.amazon.com/signin/latest/userguide/command-line-sign-in.html)
- [Authentication and access credentials for the AWS CLI](https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-authentication.html)

## Full data

Detection queries (Splunk SPL / Microsoft KQL / Sigma) and IOC values require the Threadlinqs MCP server (Purple tier): https://intel.threadlinqs.com/mcp

Canonical: https://intel.threadlinqs.com/threat/TL-2026-1646