Compromised in 90 seconds: how fast harvested credentials on AI infrastructure reach AWS APIs

May 2026

What happens to AWS credentials exposed on AI infrastructure

Most harvested AWS credentials from exposed AI infrastructure are validated against live cloud APIs in under 90 seconds.

The finding comes from five days of controlled observation in May 2026, with six independent operator architectures executing the same workflow against an AI infrastructure research deployment configured with credential-decoy surfaces and honeypot tokens for AWS. The credentials seeded across those paths were AWS access keys, the kind that AI applications routinely deploy in .env files for cloud storage, compute, and service integrations.

The most important detail is not the speed alone. Across six observed cases in May 2026, the harvest-to-validation window for AWS credentials exposed on AI infrastructure ranged from 30 to 105 seconds, with four of six cases completing in under 90 seconds. Credential abuse from separate validator infrastructure continued for at least 17 hours after the deployment was decommissioned.

That timing matters because it does not match how defender programmes are built. Standard credential rotation workflows, incident response queues, and even automated detection systems run in minutes-to-hours; the operators moving against exposed credentials run in seconds. The window between exposure and active use is too short to defend through reaction.

This article builds on Article 1 of this research programme, which characterised the scanning and harvesting layer rather than the validation pipeline. Article 1 established that AI infrastructure attracts scanners and credential hunters as its primary exploitation vector, with most operators engaged in enumeration rather than AI-capability-specific attacks. That finding left a follow-on question open: once credentials are harvested, how fast does the use pipeline run?

AWS credentials were the natural focus for this iteration. Article 1's data showed AWS as the most-probed cloud-credential ecosystem in operator wordlists, the highest-signal target for measuring post-harvest pipeline timing.

This piece documents what happens after a credential is exposed: how fast the post-harvest pipeline runs, where the credential goes next, and what that timing means for incident response programmes.

The term harvest-to-validation window is used throughout this article to mean a specific measured quantity: the elapsed time from a credential first being read by an adversary to that credential being first used in an authenticated AWS API call. Specifying this precise transition matters because the available coverage of credential-misuse uses vaguer concepts that confound multiple distinct timing windows.

The first observed pipeline, examined in the next section, involved two IPs in the same /24, different toolchains, and a window of under 50 seconds from credential exposure to the first authenticated AWS API call.

How fast were the first harvested credentials validated?

Public research on credential abuse measures incidents after the fact. This research measured the pipeline as it ran. The first harvested credentials moved from /.env to an authenticated AWS API call in 28 seconds.

At 18:57:32 UTC on the second day of observation, IP 185[.]177[.]72[.]17 harvested credentials from /.env using a curl-based wordlist tool. Between 28 and 48 seconds later, IP 185[.]177[.]72[.]3 used those same credentials in authenticated AWS API calls from a Node.js axios client on a separate machine in the same /24. A second API call from the same validator IP followed approximately one minute after.

The case is worth working through because the timing constraints it surfaces rule out attack models that defender programmes still implicitly assume.

The harvester operated from 185[.]177[.]72[.]17 using a curl/8.7.1 user agent. Across 19 seconds it walked a wordlist of 1,139 distinct paths targeting .env, .aws/credentials, .git, backup files, and configuration endpoints across multiple frameworks. Two /.env reads returned successful HTTP responses containing the seeded honeypot tokens for AWS.

The validator operated from 185[.]177[.]72[.]3 using an axios/1.7.7 user agent. Same /24, different machines, different language stacks: curl is a command-line HTTP tool typical of shell-based scripts; axios is a Node.js HTTP library that runs in JavaScript runtime environments.

Three observations matter more than the IP pair itself.

No human-driven workflow could have produced this timing. Harvesting a credential, routing it across IP infrastructure to a different machine on a different language stack, and executing a successful AWS API call within 48 seconds rules out manual intervention. The pipeline is automated end to end: the harvest tool extracts the credential, parses it, routes it to validation infrastructure, and the validation tool executes the API call before a defender could have noticed the harvest event itself.

The cross-IP behaviour rules out single-tool exploitation. The harvester and validator run on different machines using different HTTP libraries from different language ecosystems. The credential must therefore traverse some inter-machine transmission step, completing in under 50 seconds.

The curl-to-axios handoff suggests separate tooling layers: shell-based for fast wordlist enumeration, Node.js for parallel asynchronous API calls. Whether one operator orchestrates both machines or coordinated actors hand off, the routing between them is operator infrastructure rather than off-the-shelf public tooling.

The validator's two API calls reveal dwell time, not retry behaviour. Inter-call latency sits between 60 and 87 seconds; both calls use the same client library, source IP, and credential. That spacing rules out cross-operator resale, distributed validation fan-out, and different-validator retry behaviour. The pattern is consistent with sequential reconnaissance on a single validator machine: validate the credential is real, then discover what it can do.

Same-operator attribution from this single case is more limited than the timing finding. Both IPs sit in the same /24, and the harvest-to-validation window of 28-48 seconds falls within the broader population pattern (range 30 to 105 seconds, four of six under 90). Same-operator multi-IP architecture is the most plausible reading, but /24 proximity alone does not rule out coincidence.

The 1,139 distinct paths in 19 seconds came from a wordlist targeting multiple cloud providers, multiple application frameworks, and multiple deployment patterns. Harvest-side mechanics, including the operator's wordlist taxonomy and multi-cloud credential-hunting targeting, are covered in a follow-up article.

What matters in the context of this article is the back end. The harvested credentials moved from exposure to validation in under a minute and across at least two machines. That is the pattern the next section confirms across five additional cases, with three running on entirely different architectures and toolchain families.

Sub-90-second credential validation across five additional cases

The first case showed the pattern. Five more confirmed it.

Across the next five observed harvest-to-validation cases, harvested credentials moved to authenticated AWS API calls in 30 to 105 seconds. Four of the six cases (including the opening case) closed under 90 seconds. The remaining two extended to 100 and 105 seconds.

A seventh observed event sat outside the fast-pipeline pattern and is examined at the end of this section. The seventh took 37 minutes through what appears to be a queue-based architecture.

The .NET self-validation pipeline case (93.123.109.180)

The second case is the cleanest evidence of single-operator attribution in this dataset. IP 93[.]123[.]109[.]180 harvested credentials from /.env and used the same credentials in authenticated AWS API calls from the same IP, 74 seconds later. Harvest and validation run on one machine; the operator's pipeline is end to end on a single host.

After the initial validation call, the same IP performed a six-minute capability-assessment walk across AWS services from a Windows .NET HTTP client: STS GetCallerIdentity, then S3, then SES, then SNS. Four distinct API endpoints generated six token alerts, all from the same client library and the same source IP.

The four-service sequence walks common AWS monetisation paths: identity verification, data access, mail relay, notification fraud. The operator is not pinging STS to keep the credential alive; they are systematically enumerating which AWS services the credential can access, building a capability map per harvested credential. Whether individual API attempts succeed depends on credential permissions; the enumeration pattern itself is what this research observes.

The 30-second harvest-to-validation case (chain B orphan validator)

The fastest harvest-to-validation observed in this dataset closed in 30 seconds. IP 85[.]11[.]167[.]149 read /.env via HTTPS with an AndroxGh0st-family TLS fingerprint distinct from the primary cluster hash (JA3 db687c576d7ee0017b289fc05e0f8574). Thirty seconds later, IP 45[.]128[.]199[.]231 used those credentials in an authenticated AWS API call with a PHP/Guzzle client library.

The validator IP touched the deployment zero times. It appears nowhere in the deployment's request logs, only in the token alert from the credential's callback infrastructure. This is what the article refers to as an orphan validator: a downstream consumer of the credential that never touched the source.

How the credential travelled from harvester to validator in 30 seconds across two different networks is part of the redistribution pattern the next section documents.

Three cluster harvesters and the Azure validator fleet (chain A)

Three observed harvester IPs (38[.]248[.]95[.]236, 168[.]222[.]97[.]137, 155[.]117[.]232[.]180) read credentials on the HTTP surface using the AndroxGh0st cluster's primary JA3 (b885946e72ad51dca6c70abc2f773506). The JA3 fingerprint and the request patterns match AndroxGh0st operator infrastructure as documented in published research by Lacework, Cado, and others. Harvests fell across the second and third days of observation.

Validation of those three credentials came from a different fleet of IPs: three Azure-hosted machines using identical Boto3, Python, and Linux Azure toolchains. Harvest-to-validation timing per credential ranged from 80 to 105 seconds.

The Azure validator fleet IPs never touched the deployment. They appear in zero request log entries; their existence is observable only through the token alerts of the credentials they used. The cross-network redistribution pattern this implies is examined in the next section.

The 37-minute outlier validation case (74.0.32.57)

The outlier case sat outside the fast-pipeline pattern. IP 74[.]0[.]32[.]57 harvested a credential and the same credential was used in an authenticated AWS API call 37 minutes later. That timing is more than 20 times slower than the median across the other six cases.

The most plausible interpretation is queue-based architecture: the harvest event went into a credential queue for batch processing, with validation triggered when the queue was next polled. The 37-minute gap is consistent with cron-driven processing intervals or with a low-priority validation worker behind a backlog.

This is not the same architectural pattern as the fast-pipeline cases. It is the same outcome (credential validation against AWS) via a different operator design. Defender programmes need to be effective against both.

How sub-90-second validation behaves as a population pattern

Across the six fast-pipeline cases, harvest-to-validation closed in 30 to 105 seconds, with four under 90. The 37-minute outlier sat outside the pattern but confirmed that queue-based architectures coexist with the fast pipelines.

The population shows enough consistency to treat sub-two-minute harvest-to-validation as a structural property of credential-misuse pipelines as a class, not as a behaviour particular to any single operator family. The cases span single-IP architectures (the .NET self-pipeline), cross-IP same-/24 architectures (the opening case), and cross-network redistribution architectures (the AndroxGh0st cluster to Azure fleet, the chain B harvest to PHP/Guzzle orphan).

What that timing rules out is the same across every fast case: human-in-the-loop validation. What it enables is what the next section examines: where the credentials go after the first validation event.

Where harvested AWS credentials go beyond the first validator

The credentials do not stay with the first machine.

Two harvest-to-validation chains came out of the previous section. Chain A's AndroxGh0st cluster harvesters ended up validated by a fleet of Azure-hosted machines on a different network. Chain B's harvester credential ended up validated by a PHP/Guzzle machine on a third network entirely.

The downstream validators in both chains share a structural property worth naming. They are what this article calls orphan validators: machines that use a harvested credential without ever having appeared in the deployment's request logs. Their existence is observable only through the token alerts of the credentials they used.

They could not have read the credential from the deployment directly. The credential reached them through redistribution: someone else harvested it and made it available through a secondary channel.

Chain B's orphan validator used the credential 30 seconds after the harvest event, comparable to several of the harvest-to-validation windows documented earlier in this article. The redistribution mechanism between harvester and orphan validator operates in near-real-time. Credential marketplaces, shared databases, and Telegram channels are all documented mechanisms in public reporting; this research does not directly observe which one.

The chain A Azure fleet did not stop after the deployment closed. Three Azure-hosted IPs sharing identical Boto3, Python, and Linux Azure toolchains validated the chain A credential repeatedly across a window that extended well past the exposure window. Two of the three IPs share a /24, the third sits in a different /16; the toolchain identity across all three strongly suggests one operator running multiple Azure VMs, though network co-location is correlative not definitive.

Each Azure IP fired three token alerts within a 5-22 minute window, with bursts separated by hours. The pattern is consistent with a triage routine running across captured credentials: each credential is re-checked against accessible AWS services to confirm continued validity or to assess whether it can be monetised, with the work scaled across multiple short-lived virtual machines.

The most recent confirmed Azure-fleet validation event occurred at least 17 hours after the deployment was decommissioned. The credentials remain valid in AWS at the time of writing; the exposure is closed, but the credentials themselves have not been rotated. Past the 17-hour event, no further validation attempts against this credential have been observed in over 24 hours.

The implication for defender programmes is structural. Credential exposure on AI infrastructure is not a single-operator-single-event problem. The harvester's validation window is one moment in a credential's exploitation lifecycle, not its endpoint.

Even after the source of exposure is removed, the credential continues circulating through downstream consumers who never touched the source. Any exposed credential should be assumed to be in active use by multiple parties within minutes, and continues to be validated by parties unrelated to the original harvester for at least hours after the exposure window closes.

The next section examines what the validation window is used for. Detailed coverage of the AndroxGh0st workflow on AI infrastructure is the subject of a follow-up article.

Why the 90-second credential validation window is for capability assessment, not identity verification

Cloud credential abuse coverage typically frames validation as a simple yes/no check on credential validity. The pattern observed in this research is more structured.

Operators are not asking whether the credential works. They are asking what the credential allows them to do.

The 90-second window across the majority of observed cases is too long for a simple identity check and too short for human review. It is the right size for an automated multi-service enumeration: hit STS to confirm identity, then walk the monetisable services to determine what the credential can do.

The six-minute follow-on walk through STS, S3, SES, and SNS extends that timing pattern. The full pipeline is automated end to end, including the capability assessment that follows.

The .NET self-pipeline case examined earlier demonstrates this clearly. In the six minutes following the first validation API call, IP 93[.]123[.]109[.]180 performed a sequential service enumeration across STS, S3, SES, and SNS. Each service generated a distinct token alert.

This is not identity verification. The pattern is consistent with monetisation-capability assessment.

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. The narrow window applies to operators as much as to defenders.

What the multi-service AWS walk targets after credential validation

The four-service sequence maps to common AWS monetisation paths:

• STS GetCallerIdentity: confirms the credential is valid and returns the AWS account identity. One API call, low cost, fast filter.
• S3: storage access. Bucket listing, data exfiltration, ransomware encryption. The highest-volume monetisation patterns AWS abuse detection catches.
• SES: managed email service. Outbound spam infrastructure with the source IP set to AWS rather than the operator's home infrastructure.
• SNS: notification service. SMS spam, in-app messaging fraud, push notification abuse.

These four services are the recurring targets in public reporting on cloud credential abuse.

Whether individual API attempts succeed depends on credential permissions; this research observes the enumeration pattern, not the success rate.

What the targeting signal in credential-harvester wordlists indicates

The wordlist composition was a tell. Operators that probed /.aws/credentials during their enumeration validated against live AWS APIs at 22.2%, notably higher than operators running generic /.env-only wordlists. An operator including AWS-credential-specific paths in their wordlist signals AWS focus and a higher likelihood of being on the validation pipeline.

This pattern was observable in earlier research iterations and shaped the current deployment design. The honeypot tokens were placed at paths that prior data showed operators targeting, allowing this deployment to measure how active credential-hunting maps to active credential validation.

The population-level harvest-to-validation timing pattern

Across five days of controlled observation in May 2026, harvested AWS credentials from exposed AI infrastructure were validated against live cloud APIs in under 90 seconds in four of six observed cases (range 30 to 105 seconds across the population), with credential abuse continuing from separate validator infrastructure for at least 17 hours after the deployment was decommissioned, exposing a credential-redistribution layer that compresses the defender response window from days to minutes.

The 90-second window is not a curiosity. It is the operating tempo of an automated credential ecosystem that moves from exposure to monetisation-capability assessment in a single pipeline.

What this means for the defender response window is the subject of the next section.

The defender response window for exposed credentials

The 90-second harvest-to-validation window changes what defender programmes can do. The defender response window for exposed credentials on AI infrastructure is not measured in minutes or hours; it is measured in whatever the operator's pipeline takes to enumerate the credential's capabilities, which the data of this research places in the tens to low hundreds of seconds.

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 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 credential abuse via sequential AWS service enumeration

The .NET case examined earlier generated a detectable behaviour signature: from a single source IP, the same credential makes API calls to STS, then S3, then SES, then SNS, all within six minutes. That sequence is observable in CloudTrail with one CloudWatch alarm or one SIEM rule.

The detection logic in pseudocode:

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

This rule fires on the capability-assessment pattern observed across the .NET case and any operator following the same playbook. The rule is reactive (the credential has already been used) and CloudTrail-bound (the rule sees the 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 structural problem is that defender programmes designed around CloudTrail-paced response cannot match operator-paced exploitation. The fastest fix is upstream of detection: don't put credentials in files where the architecture allows alternatives. 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.

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 systemic-impact 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 non-trivial.

For the response layer, four 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.

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, runs against a different latency budget than abuse-of-existing-credential detection.

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

Monitor and harden against the broader credential-path family operators target. The .env path is the most-probed credential location in this dataset, but the broader path family observed is wider. The most-probed credential paths across the operator population, by distinct probing IPs, are:

Production-adjacent AI infrastructure should be checked against this family, not just /.env. Any of these paths accessible externally should be treated with the same compromise-on-discovery framing. Operators that probe specifically for these paths are observably on the validator population's path: monitoring HTTP request logs for probes of these paths is itself an exposure-detection signal.

All four changes pull in the same direction: defenders cannot rely on detection that runs on CloudTrail cycles. Exposure detection and response must run on the same tempo as the operator pipeline. The next section examines what else the deployment observed beyond the credential-validation pipelines.

Other adversary activity on AI infrastructure

The credential-validation pipelines were not the only adversary behaviour the deployment captured. The broader operator population includes multiple identifiable credential-hunter subtypes, several scanner classes that specifically targeted AI infrastructure, and one emerging exposure surface for the MCP ecosystem.

The full taxonomy of credential-hunter operator subtypes (User-Agent rotation classes, wordlist sophistication tiers, harvest-side toolchain families) is the subject of a follow-up article in this research programme. One defender-useful observation from the survey: at least one operator class rotates User-Agent strings between requests while keeping source IP constant. Rate-limiting strategies that key on User-Agent will miss these operators; rate-limit by source IP instead.

One scanner case (104[.]243[.]32[.]126) probed Streamlit-hosted AI application endpoints specifically, suggesting operator awareness of the ML web-app ecosystem. Across the broader scanner population, the deployment received GET-only requests against AI service endpoints with one notable POST exception: an attempt to write tensor weights to a model-serving inference endpoint. This is the only AI-capability-specific exploitation attempt observed across the deployment window, distinct from the credential-harvesting pattern that dominates the population; the full analysis is the subject of a follow-up article.

Toward the end of the observation window, the deployment received probes from CensysInspect and a separate scanner specifically cataloguing MCP server endpoints. MCP infrastructure is now indexed by commercial classifiers, meaning MCP servers exposed to the public internet are discoverable through standard internet-scanning services. This is an emerging exposure surface for the AI ecosystem, though the volume of activity observed in this dataset was limited.

The AndroxGh0st cluster harvesters documented earlier ran a broader operator workflow on the deployment than this hub article covers. The two-stage harvest pattern, the JA3 signatures across the cluster, and the chain A redistribution lineage to the Azure validator fleet are documented in a follow-up article on the AndroxGh0st operator family. The cluster's targeting of AI infrastructure specifically (rather than general web infrastructure) is an addition to the public record on this operator family.

The next section returns to the central question of this article: what exposed credentials on AI infrastructure mean for security teams.

What exposed credentials on AI infrastructure mean for security teams

This research observed harvested AWS credentials from exposed AI infrastructure being validated against live cloud APIs in under 90 seconds in four of six observed cases. It observed credential abuse continuing from separate validator infrastructure for at least 17 hours after the deployment was decommissioned. It documented two redistribution chains moving credentials between operators in near-real-time.

These are not isolated observations. They describe a credential ecosystem with a measurable timing signature: automated end-to-end, time-constrained by AWS abuse detection, and distributed across redistribution channels that operate in near-real-time. The credential is in active circulation within seconds of being exposed and continues to be validated by parties unrelated to the original harvester for hours after the exposure window closes.

For the cloud security engineers, detection engineers, and SOC leads responsible for AWS exposure on AI infrastructure, the operational implications follow from the timing.

Incident-response timelines built around CloudTrail-paced detection cannot match the speed of the credential pipeline; the question "has any credential been used?" arrives at the defender after the answer has already become "yes."

The standard playbook of incident triage, owner notification, and credential rotation, even when executed efficiently, runs in tens of minutes. The window between exposure and active abuse, in the data from this research, runs in tens of seconds. The two timescales do not meet.

The implication is direct. .env exposure on internet-facing AI infrastructure should be treated as compromise-on-discovery, not as a vulnerability requiring triage. The credential is in use by adversaries within the time it takes to file a ticket.

Across the deployment window, this research observed credential-harvesting as the dominant pattern, with AI-capability-specific exploitation rare and limited to a single tensor-write POST as the entire AI-capability footprint. Whether that balance reflects the broader threat landscape or only what this deployment attracted in five days is a question for further research. The balance may change as AI capabilities become economically valuable to compromise directly: the tensor-write attempt and the emerging MCP scanning in this dataset point at directions worth watching, including model integrity, inference abuse, and the broader agent infrastructure layer.

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

Methodology behind the credential validation measurements

Public coverage of credential abuse on AI infrastructure has commented on the speed of exploitation, but has not previously paired deployment-side request logs with credential-callback alerts under different administrative control to measure the harvest-to-validation transition empirically. The cross-source evidence design is what makes the timing measurements in this article defensible against single-source artefacts.

The orphan-validator model: why honeypot tokens for AWS are structurally essential

Across 7,708 request events in the deployment's logs, zero requests used a Boto3 or aws-sdk user agent. The validators observed in this research did not touch the deployment's HTTP or SSH surfaces at all. Their existence in the credential pipeline is observable only through the alerts the token's callback infrastructure generates when a captured credential is used in an authenticated AWS API call.

This is the orphan-validator model: validation activity sits outside the source's observable surface. A research method that relies only on the deployment's own logs cannot see the validation step. A research method that adds an independent credential-use observation channel (honeypot tokens for AWS in this case) can.

Honeypot tokens for AWS are therefore not merely useful for this kind of research. They are structurally essential: they convert credential exposure into credential use as a measurable transition, with timestamps under different administrative control from the deployment logs.

Cross-source bridging between research deployment logs and token alerts

Two structurally independent data sources combine to produce the harvest-to-validation timing finding. The deployment's request logs sit on the research infrastructure under one administrative control; the token alert infrastructure sits with a third-party callback vendor under different administrative control.

Neither party controls the other's clock or storage.

The harvest event is observable in the deployment's request logs as a successful HTTP response containing the seeded honeypot token. The validation event is observable in the token alert as an authenticated AWS API call against the credential. The harvest-to-validation latency is the time delta between these two independent timestamps.

The cross-source bridge protects against a class of single-source artefacts. If the deployment's clock drifted or the request logs were truncated, the harvest-to-validation timing would still be detectable through the token alert side, and the difference between the two sources would be observable as a research-grade discrepancy. In this dataset, the two sources are clock-aligned within seconds across the deployment window.

Token placement and deployment design

Six honeypot tokens for AWS were deployed across HTTP and SSH surfaces at canonical credential paths. Two tokens fired during the deployment window, both at /.env paths on standard external HTTP and HTTPS ports.

Tokens placed at less-canonical paths produced no observable adversary interaction across the deployment window. The placement strategy is itself a defender-useful finding documented in a follow-up article.

The HTTP surface served TLS by default, an evolution from the earlier deployment iteration documented in Article 1. Article 1's data showed commercial scanners that catalogue exposed services on the internet were TLS-first.

The credentials deployed had restricted AWS permissions appropriate to controlled-research design. The validation attempts observed represent operator intent to enumerate and monetise; whether the same operators would behave identically against fully-permissioned credentials is an open research question that this deployment does not directly test.

Research disclosure on apparatus configuration

Methodology and findings are public. Specific apparatus configuration values are not. The reason is direct: 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.

Honest limitations of the sub-90-second harvest-to-validation finding

The harvest-to-validation timing finding has limitations worth naming directly.

Scope. The dataset covers a single deployment, in a single geographic region, observed over a window in mid-May 2026. Five days is short. Operator behaviour over longer observation windows might differ, especially for slow-cycle operators who use harvested credentials over hours or days rather than seconds.

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 this dataset 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 this dataset. They are not predictions about what will happen against any particular organisation's infrastructure. The 30 to 105 second range does not generalise as a guaranteed minimum or maximum for any new exposure event.

Capture gap on SSH surface. Credential-harvest events on the deployment's SSH surface have observability gaps compared to the HTTP surface. The harvest-to-validation timing findings rest primarily on HTTP-surface captures; SSH-surface activity is referenced in this article but is not the primary source of the timing measurements.

Questions for further credential validation research

The dataset raises three questions worth investigating in subsequent research iterations:

1. When and why operator polling stops. Validation activity continued for at least 17 hours after the deployment was decommissioned, then ceased. The observed pattern (sustained attempts that stayed within capability-enumeration ranges across STS, S3, SES, and SNS, then stopped) is consistent with value-triage behaviour documented in public reporting on cloud credential abuse, and equally consistent with cataloguing behaviour against a larger credential queue. The research does not yet have data to distinguish between these interpretations or to identify what triggered the stop: time-based queue expiry, deduplication after a number of failed attempts, recognition of restricted credential permissions, or some other mechanism.
2. Whether credential permission scope affects operator behaviour and timing. The credentials in this research had restricted AWS permissions. Operators encountering restricted credentials may abandon them faster than they would abandon fully-permissioned credentials that initially succeed in monetisation attempts, and the timing window observed may not generalise: the harvest-to-validation window observed in this research may be the upper bound for restricted credentials, and may differ for credentials that initially deliver value.
3. How AI-specific exploitation evolves alongside the cloud-credential layer. The tensor-write POST observation and the emerging MCP scanning in this dataset point at AI-targeted probing starting to develop. Whether model integrity, inference abuse, and agent infrastructure exploitation become structured operator patterns at scale, and on what timing relative to the cloud-credential ecosystem, is an open question this research cannot answer.

Other credential vectors observed in this dataset

This research focused on harvest-to-validation timing for AWS credentials because AWS provided the most tractable cross-source measurement surface: honeypot tokens for AWS generate independent timestamped alerts when captured credentials are used in authenticated API calls. The harvesters captured in the dataset were not targeting AWS exclusively.

Operator wordlists span multiple cloud providers, mail providers, framework conventions, and source-control artefacts. Alongside AWS-specific paths, observed wordlists targeted other cloud providers' credentials, mail-service credentials, application framework environment files, and source-control configuration files. The breadth indicates operator interest in credential leakage from multiple parallel surfaces.

The credential-misuse pipeline measured for AWS credentials in this article likely has analogues across these other vectors. Validation-side measurement for each would require equivalent honeypot-token infrastructure scoped to that vector, which this research did not deploy.