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

AWS CLI Login Phishing (TL-2026-1646), also tracked as aws login --remote phishing, is a high-severity phishing campaign, first published 2026-07-23. It has no confirmed attribution, affects Amazon Web Services AWS CLI (aws login --remote / cross-device, maps to 25 MITRE ATT&CK techniques (T1059, T1069, T1071), and is covered by 9 detection rules and 19 indicators of compromise.

Key facts for TL-2026-1646

Threat ID
TL-2026-1646
Also known as
aws login --remote phishing, AWS cross-device authentication phishing, AWS device-code phishing
Severity
HIGH
Status
ACTIVE
Category
PHISHING
First published
2026-07-23
Last reviewed
2026-07-23
Attribution confidence
LOW
Motivation
UNKNOWN
Target sectors
technology, finance, cloud-hosting, saas, government administration, critical-infrastructure
Target regions
Global
Detection rules
9
Indicators of compromise
19

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.

How AWS CLI Login Phishing works

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 techniques used in TL-2026-1646

Execution

T1059 Command and Scripting Interpreter; T1651 Cloud Administration Command

Discovery

T1069 Permission Groups Discovery; T1526 Cloud Service Discovery; T1580 Cloud Infrastructure Discovery

Command and Control

T1071 Application Layer Protocol; T1102 Web Service; T1104 Multi-Stage Channels

Persistence

T1078 Valid Accounts; T1098 Account Manipulation; T1136 Create Account

Privilege Escalation

T1078 Valid Accounts; T1098 Account Manipulation

Defense Evasion

T1078 Valid Accounts

Initial Access

T1199 Trusted Relationship; T1566 Phishing

Credential Access

T1528 Steal Application Access Token; T1552 Unsecured Credentials; T1621 Multi-Factor Authentication Request Generation

Collection

T1530 Data from Cloud Storage

Impact

T1531 Account Access Removal

lateral-movement

T1550 Use Alternate Authentication Material

Lateral Movement

T1550 Use Alternate Authentication Material

Exfiltration

T1567 Exfiltration Over Web Service

Resource Development

T1583 Acquire Infrastructure; T1585 Establish Accounts; T1587 Develop Capabilities

Reconnaissance

T1589 Gather Victim Identity Information

defense-impairment

T1685 Disable or Modify Tools

Affected products and versions in AWS CLI Login Phishing

  • Amazon Web Services — AWS CLI (aws login --remote / cross-device authentication)
    Vulnerable versions: AWS CLI versions supporting `aws login --remote` (introduced November 2025)
  • Amazon Web Services — AWS IAM Identity Center (SSO device-code authentication)
    Vulnerable versions: AWS CLI versions using OAuth 2.0 device authorization / `--use-device-code`
    Fixed in: AWS CLI 2.22.0+ defaults to PKCE-based authorization instead of device code

Remediation for AWS CLI Login Phishing

Immediate actions

  • Deploy an SCP that denies `signin:AuthorizeOAuth2Access` and `signin:CreateOAuth2Token` organization-wide unless cross-device sign-in is an explicit business requirement
  • Alert on any CloudTrail event where `requestParameters.client_id = arn:aws:signin:::devtools/cross-device`, since this pattern should be rare in most environments
  • Correlate `AuthorizeOAuth2Access` and `CreateOAuth2Token` events for the same session and flag mismatched `sourceIPAddress` or `userAgent` between the two
  • Alert on `CreateOAuth2Token` events where session context shows `mfaAuthenticated: "false"` despite org-wide MFA enforcement
  • Issue a phishing-awareness bulletin specifically warning staff that legitimate-looking `*.amazonaws.com` / `*.s3.amazonaws.com` URLs can still be attacker-controlled phishing pages, and that AWS verification codes should never be entered on a page reached via an unsolicited email link

Workarounds

  • Disable cross-device/device-code sign-in entirely via SCP if the organization has no legitimate use case for browserless CLI authentication
  • Require users to independently navigate to `signin.amazonaws.com` / `console.aws.amazon.com` rather than clicking session/authentication links from email, and to verify any 'session expired' prompt out-of-band before entering credentials or verification codes

Longer-term hardening

  • Restrict cross-device sign-in (device code / `--remote`) to specific OUs, accounts, or identities that genuinely require headless/browserless CLI authentication
  • Implement continuous CloudTrail-based behavioral analytics that baseline normal IP/geo/user-agent patterns per principal and flag deviations following any OAuth2 authentication event
  • Deploy device-code phishing mitigation tooling (e.g., a Granted-style browser extension) for any SSO/device-code authentication surface still enabled in the environment
  • Monitor for post-authentication IAM persistence indicators: new IAM users/roles created shortly after a cross-device login, new access keys, or new/modified trust policies allowing external or unrecognized principals
  • Periodically review which principals and workloads actually rely on `aws login --remote` or SSO device-code flows and decommission the flow where unused

Weaknesses (CWE) in AWS CLI Login Phishing

CWE-287, CWE-346, CWE-1021

Timeline of AWS CLI Login Phishing

  • Common Fate updates its Granted CLI/browser extension to mitigate device-auth phishing against AWS IAM Identity Center by verifying device codes client-side.
  • Christophe Tafani-Dereeper publishes prior research on phishing AWS SSO via OAuth 2.0 device-code authentication, establishing the underlying technique class later re-targeted at `aws login --remote`.
  • AWS introduces the `aws login` CLI command, including the `--remote` cross-device authentication mode for browserless devices.
  • Broader identity-phishing campaigns referenced by Mitiga as context (Scattered Spider-style vishing/SSO abuse affecting Salesforce, DoorDash, SoundCloud, Betterment, and Crunchbase) underscore active attacker interest in cloud/SSO authentication-flow abuse during this period.
  • Adan Alvarez publishes an independent technical write-up, 'Phishing for AWS Credentials via the New aws login Flow,' documenting the same command syntax, CloudTrail signatures, and SCP mitigation.
  • Mitiga Security researchers Idan Cohen and Asad Saffoury publish 'Inside aws login: Exploring a New Phishing Method,' detailing a full automated attack chain (S3, Lambda, DynamoDB, API Gateway, EC2, SSM) against `aws login --remote`, plus CloudTrail detection logic and an SCP-based prevention control.
  • Mitiga updates the blog post with additional detail/refinements after initial publication.
  • Technique ingested into the Threadlinqs Intelligence Platform as TL-2026-1646 based on the Mitiga disclosure and corroborating independent research.

Sources cited for AWS CLI Login Phishing

Threats related to AWS CLI Login Phishing

Detection coverage for TL-2026-1646

As of 2026-07-23, Threadlinqs Intelligence publishes 9 detection rule(s) for TL-2026-1646 across Splunk SPL, Microsoft KQL and Sigma, covering 19 indicator(s) of compromise. The whole corpus is readable without an account; a free account unlocks full detection query text in Splunk SPL, Microsoft KQL and Sigma; paid tiers add raw indicator values, correlation and the MCP server. Threadlinqs MCP server · View plans.

Threadlinqs Intelligence — Real-Time Threat Detection Platform

[ 0 threats ] [ 0 det ] [ CRIT: 0 ] [ HIGH: 0 ]
// threat_feed
$ sort --newest
Showing all threats

Latest Threats