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

Key facts

Detection coverage

As of 2026-11-12, Threadlinqs Intelligence publishes 9 detection rule(s) for TL-2026-5879 across Splunk SPL, Microsoft KQL and Sigma, covering 16 indicator(s) of compromise. The whole corpus is readable without an account. Every threat comes with one complete detection in Splunk SPL, Microsoft KQL and Sigma, free for everyone; a free account adds daily TL Creds to unlock the rest. Paid plans add a larger daily allowance, correlation and the MCP server. Threadlinqs MCP server · View plans.

Free detection: AWS Login Cross-Device (devtools/cross-device) OAuth2 Sign-In — Phishing Exploitation

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

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

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

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.

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

Indicators of compromise

As of 2026-11-12, Threadlinqs Intelligence tracks 16 indicators of compromise for TL-2026-5879.

Sample indicators (2 of 16)

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

Defanged, TLP:CLEAR. Full set of 16 indicators: unlock with TL Creds.

Technical analysis

No in-the-wild exploitation or actor attribution is stated.

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 techniques by tactic:

Execution

T1059.009 Cloud API; T1204.001 Malicious Link

Initial Access

T1078.004 Cloud Accounts; T1566.002 Spearphishing Link

Discovery

T1087.004 Cloud Account; T1580 Cloud Infrastructure Discovery

Persistence

T1098.001 Additional Cloud Credentials; T1098.003 Additional Cloud Roles; T1136.003 Cloud Account

Credential Access

T1528 Steal Application Access Token

Collection

T1530 Data from Cloud Storage

lateral-movement

T1550.001 Application Access Token

Resource Development

T1583.006 Web Services

Remediation

Immediate actions

• Hunt CloudTrail for requestParameters.client_id = arn:aws:signin:::devtools/cross-device
• Correlate AuthorizeOAuth2Access and CreateOAuth2Token events per user/session for source IP, user agent, geography, and timing mismatches
• Review IAM for newly created users, access keys, and roles with broad trust policies following any cross-device sign-in

Workarounds

• SCP denying signin:AuthorizeOAuth2Access and signin:CreateOAuth2Token (org-wide or scoped to OUs/accounts/identities)
• Scope IAM policies using resource ARN arn:aws:signin:{region}:{account-id}:oauth2/public-client/remote to control cross-device authentication separately from same-device (public-client/localhost)

Longer-term hardening

• Decide whether cross-device sign-in is needed; if not, disable it org-wide via SCP
• Use phishing-resistant MFA (passkeys/security keys) as recommended by AWS
• Train users that AWS sign-in followed by a request to paste/submit a verification code into a third-party page is a lure
• Do not rely on IP-mismatch alerting alone; baseline normal use of cross-device login

Affected and fixed versions

• Amazon Web Services — AWS CLI `aws login` (console-credentials sign-in, cross-device `--remote` option)
  Vulnerable versions: AWS CLI 2.32.0 and later where aws login --remote is permitted

Timeline

• 2021-06-09 Christophe Tafani-Dereeper publishes research on phishing AWS credentials via AWS SSO (IAM Identity Center) device-code authentication, an analogous lure where the victim approves an attacker-initiated CLI login; AWS treats it as by design. Post later updated (2024/2025).
• 2024-10-04 Common Fate releases a Granted browser extension (Granted 0.35+) that compares the Identity Center confirmation code with the CLI's code to mitigate device-code phishing in AWS IAM Identity Center.
• 2025-11-19 AWS Security Blog documents the new CloudTrail events AuthorizeOAuth2Access and CreateOAuth2Token (from signin.amazonaws.com) and notes SCPs can deny the signin:AuthorizeOAuth2Access and signin:CreateOAuth2Token actions.
• 2025-11-19 AWS announces `aws login` (AWS CLI 2.32.0+), enabling console credentials for CLI/SDK authentication via browser-based OAuth 2.0 + PKCE, including the cross-device `--remote` option.
• 2026-03-16 Mitiga (Idan Cohen, Asad Saffoury) publishes 'Inside AWS Login', describing a phishing method abusing `aws login --remote` with an AWS-hosted PoC kit (S3, DynamoDB, API Gateway, Lambda, EC2/SSM), CloudTrail detection and SCP prevention guidance; no in-the-wild use or IOCs reported.
• 2026-11-12 Threat tracked in Threadlinqs as MONITORING: public PoC technique, no CVE, no confirmed exploitation or attribution.
• 2026-11-12 Mitiga page shows an 'Updated On' date of 2026-11-12 (later than publication; the page itself may contain a metadata inconsistency).

Sources cited

• Mitiga: AWS Login Phishing Attack: How Attackers Exploit New Authentication (Idan Cohen, Asad Saffoury) mitiga.io · Research · 2026-03-16
• AWS Security Blog: Simplified developer access to AWS with aws login aws.amazon.com · Vendor report · 2025-11-19
• AWS Docs: Sign in through the AWS Command Line Interface docs.aws.amazon.com · Vendor report
• AWS What's New: Console credentials for AWS CLI and SDK authentication aws.amazon.com · Vendor report · 2025-11-19
• AWS Docs: Sign-In with OAuth 2.0 docs.aws.amazon.com · Vendor report
• AWS CLI User Guide: Login for AWS local development using console credentials docs.aws.amazon.com · Vendor report
• Christophe Tafani-Dereeper: Phishing for AWS credentials via AWS SSO device code authentication blog.christophetd.fr · Research · 2021-06-09
• AWS Builder Center: aws login - what the AWS CLI's new console credential command can and can't do builder.aws.com · Blog
• Common Fate: Granted now mitigates device auth phishing in AWS IAM Identity Center commonfate.io · Blog · 2024-10-04
• Classmethod: Using the aws login command on a remote machine (Japanese) dev.classmethod.jp · Blog
• FAUN: Phishing for AWS credentials via the new aws login flow (link aggregation) faun.dev · News

More in phishing

• Microsoft Teams Booking-Flow Device Code Phishing Campaign Targeting Microsoft 365 Accounts
• Microsoft Teams Booking-Flow Lure Used for Device Code Phishing Against Construction Sector
• Tax-Season Phishing and Malware Campaigns Impersonating India's Income Tax Department Targeting Indian Taxpayers (ITD.zip / ITD_Tax_Notice.exe)
• Lookalike Microsoft Teams domains delivered via search ads, AI search answers and SEO poisoning (no phishing email)
• 2026 FIFA World Cup Scam Wave: 35,000+ Fake Ticket, Shop and Streaming Sites