Exposed AWS Credentials Are Used in Under 90 Seconds: Findings from AI Infrastructure Research

May 2026

How quickly are exposed AWS credentials abused?

Exposed AWS credentials were used against live AWS APIs within 67 seconds of being harvested, faster than CloudTrail typically delivers the first event to a defender. This is the speed of AWS credential theft once a key is exposed on internet-facing infrastructure: the harvest-to-validation pipeline outruns any defender workflow, and the credentials keep circulating through validator infrastructure for at least 10 days after the source is taken offline.

The observations come from two iterations of the research deployment, running approximately three weeks apart in May 2026 in different geographic regions. Both iterations instrumented internet-exposed AI infrastructure with AWS access keys configured to produce independent timestamped alerts when used in authenticated AWS API calls. The harvest events were logged on the research deployment; the validation events were logged by a third-party callback infrastructure under different administrative control. Two independent clocks, two independent storage systems, one measurable transition.

The cases detailed in this article come from the first iteration. The second iteration observed the same patterns across a different regional operator population; a fuller second-iteration analysis will follow in a subsequent piece. The deployment builds on the AI infrastructure scanning research that established credential harvesting as the dominant exploitation pathway.

The research surface was AI infrastructure, but the finding is about AWS credential exposure. It applies to any team running access keys in .env files, CI pipelines, or container images, whether or not an AI workload is involved. Attackers respond to the credential, not its origin.

Credential harvesting works because applications routinely store AWS access keys in plaintext .env files, and any of those files reachable over the internet can be read with a single request. Automated scanners walk known credential paths across thousands of hosts, harvest whatever keys they find, and feed them straight into validation tooling. The window this article measures is the gap between that harvest and the first authenticated AWS API call.

What the cross-source data shows is unambiguous: the fastest observed credential-theft pipeline completed in 67 seconds, and every fast-pipeline case observed completed in under 90 seconds. In each one, exposed credentials moved from discovery to authenticated AWS API use faster than CloudTrail delivers the first event to a defender.

That timing matters because it does not match how defender programmes operate. Incident-response queues, credential-rotation workflows, and cloud-security monitoring typically run on minute-to-hour timescales. The operators observed in this research run on second-to-minute timescales.

A sub-90-second credential theft case, start to finish

During the first iteration of the research deployment in May 2026, IP 85[.]11[.]167[.]149 requested /.env on port 80 at 13:59:52 UTC. The deployment served an AWS access key in the response body. Within 67 seconds, the same IP authenticated against live AWS services using that key.

The case is worth working through because it is methodologically the cleanest evidence of sub-90-second pipeline operation in the dataset.

The same IP harvested the access key and used it. That binding matters. The access keys placed in the deployment produce alerts when used in an authenticated AWS API call; the alert identifies the IP making the call. When the IP that harvests the access key and the IP that uses it are the same machine, the chain closes: that operator must have used a key it received from this deployment, because the key reached that machine through no other channel.

What surprised me in this case was how tight the window was. Sixty-seven seconds is fast enough that the credential is in active AWS use before a defender team's chat notification has rendered. The operator's tooling reads the harvested credential, parses it, and executes an authenticated AWS API call within a window that would not register as a discrete event to a human in the loop. The pipeline is not "fast"; it is end-to-end automated, including the credential extraction step that some defender models assume requires manual handling.

The credential abuse pipeline does not require multi-stage orchestration to be fast. A single operator with credential-extraction tooling and a validation client on the same machine completes the cycle in well under two minutes. Whatever defender programme is designed around "we'll see the API call on the next CloudTrail delivery" is already too slow.

Is sub-90-second credential abuse a pattern or a fluke?

The case above is the tightest measurement in the dataset, not the only one.

Across the first iteration of the research deployment, several distinct operators ran SAME-IP harvest-to-validation cycles under 90 seconds at the upper bound. The three fastest observed cases:

The full population extends beyond these three. Additional operators ran similar sub-90-second cycles in the same range, while others ran slower pipelines extending to several minutes.

DIFFERENT-IP architectures, where one machine harvests and a separate validator infrastructure executes the API call, also showed sub-90-second timings independently of the SAME-IP cases. These architectures are attributable through TLS fingerprinting, including operators in the AndroxGh0st family observed elsewhere in this research programme. Sub-90-second pipeline operation is observable across operator architectures and across deployments.

Validation activity continued from separate operators against the harvested credentials for at least 10 days after the research deployment was decommissioned. Across the observed deployment windows, the ratio of validation events to harvest events exceeded 1:1, indicating credentials enter a distribution system that routes each credential to multiple downstream consumers rather than being used once by the original harvester.

Many of these validators never touched the deployment directly. They are orphan validators: machines that consume credentials produced by other harvesters via redistribution channels documented in public reporting (credential marketplaces, shared databases, operator-curated Telegram channels). Credentials reach these consumer pools and continue circulating beyond the lifetime of the source infrastructure and beyond the original harvester.

What attackers do with stolen AWS credentials

Operators are not checking whether the credential works. They are checking what it can do.

In the cleanest single-operator case from the first iteration's dataset, the operator followed validation with a six-minute capability walk across four AWS services, each mapping to a different monetisation path:

The pattern is consistent with monetisation-capability assessment, not identity verification. Operators with valid credentials and monetisable capability act fast because AWS abuse detection closes windows quickly: high-volume EC2 resource creation, SES email above account thresholds, and SNS topic patterns outside the account's baseline all trigger automated billing alarms or abuse detection. One credential exposure produces enumeration intent across multiple AWS service categories within minutes of validation. Scope-limiting matters not just for any single service but across the full AWS service surface the credential can touch.

The defender response window for exposed credentials

The sub-90-second window changes what defender programmes can do. The defender response window for exposed AWS credentials is not measured in minutes or hours; it is measured in tens of seconds for the first response and at least 10 days for the extended response.

Why CloudTrail-based detection cannot catch sub-90-second credential abuse

AWS CloudTrail aggregates events and delivers them in batches, typically within 5 to 15 minutes of an API call per AWS documentation. Delivery is not guaranteed. SIEM ingestion latency adds further delay before events reach a SOC's alerting infrastructure.

A sub-90-second harvest-to-validation pipeline completes before that first event reaches the defender. By the time the SOC has visibility, the operator has run their capability assessment and either continued to next-step actions or dropped the credential.

This is structural, not a tuning problem. No configuration of CloudTrail-based detection can outpace the operator's pipeline because the credential is already in use before the audit log delivery cycle completes.

A detection rule for sequential AWS service enumeration

The capability-walk pattern is detectable in CloudTrail once events arrive. From a single source IP, the same access key making calls to three or more of (STS, S3, SES, SNS) within ten minutes is a signature of validator behaviour distinct from normal application traffic, which typically uses one or two services in any given window.

WHEN events come from same source_ip AND same access_key_id
  WITHIN 10 minutes
  AND event_source includes (sts, s3, ses, sns)
  AND distinct service count >= 3
THEN alert: "Sequential AWS service enumeration"

The rule is reactive (the credential has already been used) and CloudTrail-bound (the rule sees events when CloudTrail delivers them), so it does not prevent the abuse. It catches it within the delivery window, which is useful for credential rotation triggers and forensic alerts but is not a substitute for prevention.

What changes for exposed credentials defender programmes

The fastest fix is upstream of detection: don't put credentials in files where alternatives exist. Modern AWS infrastructure provides task-scoped IAM roles (EKS pod identity, ECS task roles, EC2 instance profiles, Lambda execution roles) and secret management services (AWS Secrets Manager, HashiCorp Vault) that eliminate the need for credentials on disk. These are foundational cloud security controls, not AI-specific ones.

Where access keys must exist, scope them tightly with IAM policies. A credential that grants AdministratorAccess and a credential that grants s3:GetObject on one specific bucket are not the same risk: operators that harvest the first have many monetisation paths, operators that harvest the second have a single bucket of data. These patterns are well-documented; the gap between recommendation and deployment persists in legacy applications and ad-hoc tooling where migration from key-based to role-based access is operationally complex.

For the response layer, three changes follow when credentials are exposed despite hygiene.

Automate credential rotation when exposure is detected. Human-mediated rotation through the AWS console runs in tens of seconds; the operator's pipeline runs in seconds. Rotation must trigger automatically on credential exposure detection, not through a human paging step that adds minutes. Rotation alone does not end the exposure; validation attempts continue from downstream consumers for days, but rotation removes the operational value of the credential to anyone who eventually attempts to use it.

Move detection to the credential creation point, not the credential use point. By the time CloudTrail sees an API call from an exposed credential, the credential is already exposed. Detection at the moment of unexpected access key creation, or at unauthorised access pattern formation, operates on a different timescale to abuse-of-existing-credential detection.

Treat .env exposure as compromise-on-discovery. Any production-adjacent infrastructure that has .env accessible externally is best assumed to have credentials in active use by adversaries within minutes. This is consistent with a continuous exposure management framework, where exposure detection triggers immediate remediation rather than entering a triage queue.

The defender response window for exposed AWS credentials is not closing. It already closed.

Methodology: measuring credential theft timing

The harvest-to-validation timing measurements use two structurally independent data sources.

The harvest event is observable in the research deployment's request logs as a successful HTTP response containing an AWS access key. The deployment's request logs sit on the research infrastructure under one administrative control.

The validation event is observable as an alert from the access key's callback infrastructure when the captured key is used in an authenticated AWS API call. The callback infrastructure sits with a third-party vendor under different administrative control. Neither party controls the other's clock or storage.

The harvest-to-validation latency is the time delta between these two independent timestamps. The cross-source bridge protects against single-source artefacts: if the deployment's clock drifted or the request logs were truncated, the validation timing would still be detectable on the callback side, and the difference between sources would surface in the data. In the datasets reported here, the two sources are clock-aligned within seconds across both iterations.

The request events captured in the deployments included zero requests from Boto3, aws-cli, or other AWS SDK user agents against the deployment's HTTP or SSH surfaces. The validators observed do not touch the research deployment at all. Their existence in the credential pipeline is observable only through the alerts generated when captured access keys are used. The placed AWS access keys are structurally essential to this methodology, not just useful: they convert credential exposure into measurable credential use, observed by a party that does not control the deployment.

A methodology limitation: each placement in these deployments serves one fixed AWS access key. Multiple harvesters of the same placement receive the same access key value. For SAME-IP cases (the sub-90-second case above) the cryptographic binding is solid because the same operator harvested and validated. For DIFFERENT-IP cases, specific harvester-to-validator attribution requires further study in a future publication.

Honest limitations

The harvest-to-validation timing finding has limitations.

Scope. The dataset covers two iterations of the research deployment in two different geographic regions, observed across windows totalling approximately eight days of harvest activity in May 2026. Cross-region observation strengthens the timing findings; the geographic and temporal scope remains limited.

Detection by operators. Operators who recognise a deployment as research-grade may behave differently than they would against real infrastructure. The validation activity observed in these datasets represents operators who either did not recognise the research-deployment signature or did not adjust their behaviour after recognising it.

Empirical not predictive. The timing measurements describe what this research observed in these datasets. They are not predictions about what will happen against any particular organisation's infrastructure. The observed latency range does not generalise as a guaranteed minimum or maximum for any new exposure event.

This article documents one iteration in an ongoing programme studying AI infrastructure scanning and the credential ecosystem that operates against it.

Apparatus configuration values are deliberately withheld. Configuration values become signatures, and once operators know the specific values used, they can identify and avoid the deployment in future iterations of the research.

Acknowledgements

The research deployments used credential instrumentation techniques inspired by and supported through Canarytokens. Their work continues to make practical security research and exposure detection more accessible to defenders.