# AWS Login Phishing: Abuse of `aws login --remote` Cross-Device Authentication Flow (Mitiga PoC)

> Mitiga researchers (Idan Cohen, Asad Saffoury) published a proof-of-concept phishing method that abuses the AWS CLI `aws login --remote` cross-device flow: a victim is lured to an AWS-hosted 'session expired' page, authenticates (including MFA) on signin.amazonaws.com, and relays the verification code to the attacker's waiting CLI, yielding a valid AWS session. No in-the-wild exploitation or actor attribution is stated.

- **Published:** 2026-11-12T18:19:30Z
- **Last reviewed:** 2026-11-12T18:19:30Z
- **Canonical:** https://intel.threadlinqs.com/threat/TL-2026-5879
- **Card image:** https://intel.threadlinqs.com/og/threat/TL-2026-5879.png
- **ID:** TL-2026-5879
- **Severity:** MEDIUM
- **Category:** PHISHING
- **Status:** MONITORING
- **Detections:** 9 (1 shown free below) · **IOCs:** 16 (2 shown free below)

## Description

AWS introduced `aws login` (AWS CLI 2.32.0+, announced 2025-11-19) so developers can obtain short-lived CLI/SDK credentials using their console sign-in (root, IAM user, or IAM federation) via a browser-based OAuth 2.0 + PKCE flow. Sessions last up to 12 hours (bounded by the IAM principal's session duration) with credentials rotated every 15 minutes. The `--remote` option provides cross-device authentication for hosts without a browser: the CLI prints a login URL tied to a device_code (expires after 10 minutes), the user authenticates on signin.amazonaws.com in a browser on another device, and AWS returns a verification code that the user pastes back into the CLI. The identity needs the SignInLocalDevelopmentAccess managed policy (or the signin:AuthorizeOAuth2Access and signin:CreateOAuth2Token actions); root users need no extra permissions.

Mitiga's research (published 2026-03-16) shows that this design can be turned into a phishing primitive. The attacker starts `aws login --remote` to obtain a fresh login URL and then lures the victim to a page styled as an AWS 'session expired' notice hosted on amazonaws.com infrastructure, which the authors note is difficult to block without breaking legitimate AWS access. The victim signs in normally, including MFA, and is then prompted to submit the verification code, which the attacker relays to their own waiting CLI. The authors report that a plain code relay is not sufficient because a device-state value must match between the victim's browser and the CLI session; they did not get an AiTM-style approach working reliably, so the attack depends on a session-aware lure in which the victim completes the browser step and returns the code. The lure borrows the ClickFix/ConsentFix social-engineering pattern (a mandatory-looking 'fix' step framed as routine maintenance). MFA is not bypassed; it is completed by the victim. Third-party commentary (FAUN link aggregation) claims the CLI and browser sessions are not bound and that phishing-resistant MFA could be dodged, which is not asserted in Mitiga's post.

The PoC kit is built entirely from AWS services: S3 static hosting for the lookalike page (example bucket aws-session-expired on s3.us-east-1.amazonaws.com), DynamoDB keyed by a per-visitor session ID, an API Gateway REST API with three endpoints (start session, poll for URL, submit code), Lambda orchestration with access to DynamoDB, SSM and CloudWatch Logs, and an EC2 instance running the CLI managed via SSM (AmazonSSMManagedInstanceCore, driven by expect). The authors considered a lookalike domain (amazoon.inc) but moved away from it for cost and credibility reasons. Mitiga does not provide a complete build guide.

With a valid session the attacker can perform actions available to the victim identity: inventory the environment and map sensitive assets, exfiltrate data, create IAM users, access keys, or roles that bypass SSO and MFA for persistence, assume automation roles, move across reachable accounts, and blend in with normal API activity. The authors argue that alerting based only on unusual logins or IP rules is insufficient. Mitiga says these are possibilities and reports no observed incidents; it does not state whether the issue was reported to AWS or any AWS response.

Related prior art: device-code phishing against AWS IAM Identity Center (SSO OIDC) was documented by Christophe Tafani-Dereeper in 2021 (updated 2024/2025; AWS treats it as by design) and mitigated client-side by Common Fate's Granted extension in October 2024. The `aws login --remote` flow is a distinct IAM sign-in OAuth flow, but the lure logic is analogous.

Detection (per Mitiga): hunt CloudTrail for requestParameters.client_id = arn:aws:signin:::devtools/cross-device, expected to be uncommon in most environments, and correlate the AuthorizeOAuth2Access and CreateOAuth2Token events (logged by signin.amazonaws.com in the sign-in Region) on user/session. Combine signals such as differing source IPs, differing user agents, unusual geography, unusual timing between the two events, and unexpected cross-device use by a user who does not normally use it; no single signal should alert alone and IP mismatch alone is unreliable. AWS sample same-device events use client_id arn:aws:signin:::devtools/same-device, and CreateOAuth2Token carries a user agent with aws-cli/2.32.0 and md/command#login. Prevention: Service Control Policies denying signin:AuthorizeOAuth2Access and signin:CreateOAuth2Token org-wide or scoped to OUs/accounts/identities where cross-device sign-in is not needed. AWS documentation also exposes resource ARNs arn:aws:signin:{region}:{account-id}:oauth2/public-client/remote (cross-device) and .../public-client/localhost (same-device) for IAM policy control. AWS sample CloudTrail records show mfaAuthenticated as false. No CVE or CVSS exists; the source publishes no malicious domains, IPs, hashes, or account IDs.

## MITRE ATT&CK

- T1583.006 Web Services
- T1566.002 Spearphishing Link
- T1204.001 Malicious Link
- T1059.009 Cloud API
- T1528 Steal Application Access Token
- T1078.004 Cloud Accounts
- T1550.001 Application Access Token
- T1136.003 Cloud Account
- T1098.001 Additional Cloud Credentials
- T1098.003 Additional Cloud Roles
- T1580 Cloud Infrastructure Discovery
- T1087.004 Cloud Account
- T1530 Data from Cloud Storage

## Free detection (Splunk SPL, Microsoft KQL, Sigma)

**AWS Login Cross-Device (devtools/cross-device) OAuth2 Sign-In — Phishing Exploitation** (`TL-2026-5879-SPL-001`)

TL-2026-5879: Hunts CloudTrail signin.amazonaws.com AuthorizeOAuth2Access/CreateOAuth2Token events carrying requestParameters.client_id = arn:aws:signin:::devtools/cross-device, the fingerprint of the `aws login --remote` flow that Mitiga showed can be turned into a verification-code phishing primitive (T1528, T1566.002). The client_id is uncommon in most environments, so every hit should be triaged against the user's expected remote-login behaviour; no single field proves abuse.

- **Languages:** Splunk SPL, Microsoft KQL, Sigma
- **ATT&CK:** T1528, T1550.001, T1078.004, T1566.002
- **Data sources:** AWS CloudTrail (index=aws sourcetype=aws:cloudtrail), Microsoft Sentinel AWSCloudTrail table
- **Severity:** medium
- **Confidence:** medium

### Splunk SPL

````spl
index=aws sourcetype="aws:cloudtrail" eventSource="signin.amazonaws.com" eventName IN ("AuthorizeOAuth2Access","CreateOAuth2Token") earliest=-24h
```keep only the cross-device client_id fingerprint, the Mitiga primary hunt pivot; same-device baseline is devtools/same-device```
| where match(_raw,"arn:aws:signin:::devtools/cross-device")
| eval actor=coalesce('userIdentity.arn','userIdentity.userName','userIdentity.principalId')
| stats count as events min(_time) as first_seen max(_time) as last_seen values(eventName) as event_names dc(sourceIPAddress) as src_ip_count values(sourceIPAddress) as src_ips values(userAgent) as user_agents values(awsRegion) as regions values(recipientAccountId) as accounts by actor
| eval first_seen=strftime(first_seen,"%Y-%m-%d %H:%M:%S"), last_seen=strftime(last_seen,"%Y-%m-%d %H:%M:%S")
| table actor first_seen last_seen events event_names src_ip_count src_ips user_agents regions accounts
````

### Microsoft KQL

```kql
AWSCloudTrail
| where TimeGenerated > ago(24h)
| where EventSource == "signin.amazonaws.com" and EventName in ("AuthorizeOAuth2Access","CreateOAuth2Token")
| where RequestParameters has "arn:aws:signin:::devtools/cross-device"
| extend Actor = iif(isnotempty(UserIdentityArn), UserIdentityArn, UserIdentityUserName)
| summarize Events = count(), FirstSeen = min(TimeGenerated), LastSeen = max(TimeGenerated), EventNames = make_set(EventName), SourceIPs = make_set(SourceIpAddress, 20), UserAgents = make_set(UserAgent, 20), Regions = make_set(AWSRegion), Accounts = make_set(RecipientAccountId) by Actor
| project Actor, FirstSeen, LastSeen, Events, EventNames, SourceIPs, UserAgents, Regions, Accounts
```

### Sigma

```yaml
title: AWS Cross-Device Sign-In OAuth2 Authorization (aws login --remote)
id: a3f1c2d4-5b6e-4f70-8a91-0c2d3e4f5a61
status: experimental
description: Detects AuthorizeOAuth2Access events from signin.amazonaws.com whose client_id is the cross-device fingerprint used by aws login --remote, the flow abused by the Mitiga AWS Login phishing PoC (TL-2026-5879).
references:
    - https://www.mitiga.io/blog/inside-aws-login-exploring-a-new-phishing-method
    - https://aws.amazon.com/blogs/security/simplified-developer-access-to-aws-with-aws-login
    - https://docs.aws.amazon.com/signin/latest/userguide/command-line-sign-in.html
author: Threadlinqs Team
date: 2026-11-12
tags:
    - attack.credential-access
    - attack.t1528
    - attack.initial-access
    - attack.t1566.002
    - attack.t1078.004
logsource:
    product: aws
    service: cloudtrail
detection:
    selection:
        eventSource: signin.amazonaws.com
        eventName: AuthorizeOAuth2Access
        requestParameters.client_id: 'arn:aws:signin:::devtools/cross-device'
    condition: selection
falsepositives:
    - Developers legitimately using aws login --remote from headless hosts, containers or SSH sessions
    - Root or IAM users approving a login started on a remote workstation
level: medium

```

**Known false positives:**

- Developers who legitimately run aws login --remote from headless servers, containers or SSH sessions
- Break-glass or root users approving a CLI login started on another device

**Tuning notes:** Baseline cross-device use per principal for 30 days and allow-list known remote-login users; escalate when the actor has never used devtools/cross-device before or when src_ip_count > 1. Adjust the index name to your CloudTrail index. Pair with SPL-003 for relay IP mismatch. Do not alert on this signal alone.

### 8 more detection rules (Splunk SPL, Microsoft KQL, Sigma), unlock with TL Creds

- AWS Session-Expired Lure on S3 Static Website — Phishing Delivery (locked: unlock with TL Creds)
- AWS Environment Enumeration and Storage Listing After Cross-Device Sign-In (locked: unlock with TL Creds)
- AWS CLI `aws login --remote` Execution — Cross-Device Flow Initiation (locked: unlock with TL Creds)
- AWS Root User Cross-Device aws login Sign-In — Exploitation of Highest-Privilege Identity (locked: unlock with TL Creds)
- AWS IAM Persistence Primitives Issued via AWS CLI — Post-Exploitation Backdoor Creation (locked: unlock with TL Creds)
- Automated `aws login --remote` via expect/SSM Agent — Relay Host Pattern (locked: unlock with TL Creds)
- AWS IAM Persistence Following Cross-Device Sign-In — Post-Exploitation (locked: unlock with TL Creds)
- AWS Login Verification-Code Relay — Authorize/[indicator] IP Mismatch (locked: unlock with TL Creds)

Sign up free to unlock the detection rules: https://threadlinqs.com/?modal=signup

## Sample indicators (2 of 16)

Defanged, TLP:CLEAR.

- Domain: `aws-session-expired[.]s3[.]us-east-1[.]amazonaws[.]com`
- Domain: `amazoon[.]inc`

Full set of 16 indicators unlocks with TL Creds: https://threadlinqs.com/tl-creds

## Sources

- [Mitiga: AWS Login Phishing Attack: How Attackers Exploit New Authentication (Idan Cohen, Asad Saffoury)](https://www.mitiga.io/blog/inside-aws-login-exploring-a-new-phishing-method)
- [AWS Security Blog: Simplified developer access to AWS with aws login](https://aws.amazon.com/blogs/security/simplified-developer-access-to-aws-with-aws-login)
- [AWS Docs: Sign in through the AWS Command Line Interface](https://docs.aws.amazon.com/signin/latest/userguide/command-line-sign-in.html)
- [AWS What's New: Console credentials for AWS CLI and SDK authentication](https://aws.amazon.com/about-aws/whats-new/2025/11/console-credentials-aws-cli-sdk-authentication)
- [AWS Docs: Sign-In with OAuth 2.0](https://docs.aws.amazon.com/signin/latest/userguide/oauth-sign-in-overview.html)
- [AWS CLI User Guide: Login for AWS local development using console credentials](https://docs.aws.amazon.com/cli/latest/userguide/cli-configure-sign-in.html)
- [AWS Builder Center: aws login - what the 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)
- [Common Fate: Granted now mitigates device auth phishing in AWS IAM Identity Center](https://commonfate.io/blog/granted-mitigates-aws-phishing)
- [FAUN: Phishing for AWS credentials via the new aws login flow (link aggregation)](https://faun.dev/c/links/varbear/phishing-for-aws-credentials-via-the-new-aws-login-flow)
- [Christophe Tafani-Dereeper: Phishing for AWS credentials via AWS SSO device code authentication](https://blog.christophetd.fr/phishing-for-aws-credentials-via-aws-sso-device-code-authentication/)
- [Classmethod: Using the aws login command on a remote machine (Japanese)](https://dev.classmethod.jp/articles/run-aws-login-from-remote-host/)

## Full data

The other 8 detection rules (Splunk SPL / Microsoft KQL / Sigma) unlock with TL Creds; a free account includes daily creds: https://threadlinqs.com/?modal=signup
Indicator values unlock with TL Creds, at a lower price on Red and Purple; AI agents can query rules and IOCs through the Threadlinqs MCP server (Purple): https://intel.threadlinqs.com/mcp

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