Skip to content

New attack technique: Reuse an Amazon Cognito Refresh Token #910

Description

@Edd88-pixel

Context

The March 2026 update of the AWS Threat Technique Catalog introduced T1098.A006 — Account Manipulation: Cognito Refresh Token Abuse.

AWS CIRT documented that an attacker who obtains a valid Amazon Cognito refresh token can exchange it for new access and ID tokens while the refresh token remains valid.

When refresh-token rotation is disabled, possession of the refresh token can allow repeated token exchanges until the token expires or is revoked.

When rotation is enabled, Cognito issues a new refresh token and invalidates the submitted token after the configured grace period, which changes the attacker's persistence behavior.

References:

How it works

An attacker first obtains a valid refresh token issued by an Amazon Cognito user pool.

The attacker calls GetTokensFromRefreshToken to exchange the compromised refresh token for new access and ID tokens.

This can preserve authenticated access without knowing the user's password or repeating the initial authentication flow.

The exact persistence behavior depends on whether refresh-token rotation is enabled and on the configured expiration and grace-period settings.

Proposed technique

Potential technique ID:

aws.persistence.cognito-refresh-token-reuse

Potential MITRE ATT&CK tactic:

Persistence

Potential AWS Threat Technique Catalog mapping:

T1098.A006 — Account Manipulation: Cognito Refresh Token Abuse

Warm-up:

  • Create an Amazon Cognito user pool.
  • Create an app client configured to issue refresh tokens.
  • Create and confirm a test user.
  • Obtain a valid refresh token through a controlled setup flow.
  • Pass the refresh token to the detonation phase without writing it to logs, generated documentation or Terraform state when avoidable.

Detonation:

  • Call GetTokensFromRefreshToken with the previously obtained refresh token.
  • Confirm that Cognito returns new tokens.
  • Do not print or persist the returned token values.
  • Log only non-sensitive metadata indicating that the exchange succeeded.

The main implementation question is how the warm-up phase should safely obtain and pass the refresh token while preserving the separation between prerequisite setup and the atomic detonation step.

The initial user authentication flow should not be part of the detonation.

Relevant SDK functions

AWS SDK for Go v2 package:

github.com/aws/aws-sdk-go-v2/service/cognitoidentityprovider

Primary method:

cognitoidentityprovider.Client.GetTokensFromRefreshToken

Potential supporting setup methods:

cognitoidentityprovider.Client.AdminCreateUser
cognitoidentityprovider.Client.AdminSetUserPassword
cognitoidentityprovider.Client.AdminInitiateAuth

CloudTrail details to monitor:

eventSource: cognito-idp.amazonaws.com
eventName: GetTokensFromRefreshToken

AWS TTC action:

cognito-idp:GetTokensFromRefreshToken

This technique would require adding the Cognito Identity Provider AWS SDK service dependency, which is not currently imported by an existing Stratus technique.

Activity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions