Skip to main content

AWS Session Token

AWS Session Tokens are temporary security credentials used to authenticate requests to AWS services. They are part of the AWS Security Token Service (STS) and provide temporary access to AWS resources. The exposure of these tokens is a significant security concern because they can grant unauthorized access to AWS resources, potentially leading to data breaches, financial loss, and operational disruptions.

How Does It Look​

AWS Session Tokens can appear in various contexts, such as:

  • Environment variables:

    export AWS_SESSION_TOKEN="FwoGZXIvYXdzEJr//////////wEaD..."

  • Configuration files (JSON, YAML, .env):

    {
      "aws_session_token": "FwoGZXIvYXdzEJr//////////wEaD..."
    }

  • Code snippets:

    import boto3

    session = boto3.Session(
        aws_access_key_id='AKIAIOSFODNN7EXAMPLE',
        aws_secret_access_key='wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY',
        aws_session_token='FwoGZXIvYXdzEJr//////////wEaD...'
    )

  • Connection strings:

    aws_session_token=FwoGZXIvYXdzEJr//////////wEaD...

Severity​

  • 🔴 Critical

AWS Session Tokens are considered critical because they can provide temporary access to AWS resources. The blast radius depends on the permissions associated with the token, which can range from read-only access to full administrative control over AWS services.

What Can an Attacker Do?​

With immediate access to AWS resources, an attacker can exploit the session token to perform unauthorized actions.

Key actions an attacker can perform:

  • Delete or modify data (if the credential has write permissions)
  • Access billing information (if the account has billing scope enabled)
  • Spin up resources for cryptomining (if compute permissions are granted)
  • Access sensitive data (if the token has read permissions to critical resources)

An attacker can also use the session token to escalate privileges or move laterally within the AWS environment, potentially compromising additional resources and services.

Real-World Impact​

The exposure of AWS Session Tokens poses significant business risks.

Potential consequences include:

  • Data Exposure: Sensitive data stored in AWS services (if the credential has read access to sensitive data)
  • Financial Loss: Unauthorized resource creation leading to increased AWS bills (if billing/resource creation is permitted)
  • Operational Disruption: Service outages or data loss (if the attacker has delete/modify permissions)
  • Reputational Damage: Loss of customer trust and brand reputation

In the worst-case scenario, an attacker could gain full control over critical AWS resources, leading to extensive data breaches and operational failures.

Prerequisites for Exploitation​

To exploit an AWS Session Token, an attacker needs:

  • Network access to AWS endpoints
  • Knowledge of AWS account details (such as account IDs and region endpoints)
  • No IP restrictions or MFA enforcement on the token

How to Verify If It's Active​

To verify if an AWS Session Token is active, use the AWS CLI:

aws sts get-caller-identity --session-token [SESSION_TOKEN] --access-key [ACCESS_KEY] --secret-key [SECRET_KEY]

Valid credential response: The command returns the AWS account ID and user ARN.

Invalid/expired credential response: The command returns an error indicating the token is invalid or expired.

Detection Patterns​

Common Variable Names:

  • AWS_SESSION_TOKEN
  • aws_session_token
  • sessionToken
  • session_token
  • AWS_SESSION
  • awsSessionToken

File Locations:

  • .env
  • config.json
  • credentials.yml
  • aws_credentials

Regex Pattern:

[A-Za-z0-9/+=]{16,}

Remediation Steps​

  1. Revoke immediately - Go to AWS IAM > Users > Security Credentials and invalidate the session token.
  2. Audit access logs - Review AWS CloudTrail logs for unauthorized activities during the exposure window.
  3. Assess blast radius - Identify all systems, applications, and environments that used the exposed credential.
  4. Rotate credential - Generate a new session token using AWS STS with least-privilege permissions.
  5. Update dependent systems - Deploy the new credential to all applications and update CI/CD pipelines securely.
  6. Harden access controls - Enable IP allowlisting and require MFA for sensitive operations in AWS.
  7. Implement secrets management - Migrate credentials to a secrets manager (HashiCorp Vault, AWS Secrets Manager) to prevent hardcoding.
  8. Add detection controls - Set up pre-commit hooks and repository scanning to catch credential leaks before they reach production.

Credential exposures often go undetected for extended periods, increasing the window for exploitation. As a long-term strategy, plan to establish an internal process or engage an external vendor for continuous external exposure monitoring. This helps identify leaked secrets across public repositories, paste sites, dark web forums, and other external sources before attackers can leverage them. Proactive detection and rapid response are essential to minimizing the impact of credential leaks.

References​