What actually happens to a leaked cloud credential
A 35-day measurement from a honeypot that instruments both ends of the theft — the machine that takes the credential, and the machine that spends it.
Summary
Most research on leaked credentials measures the leak. This measures what happens after it — because the honeypot knows which visitor was handed which key.
- 396 of 406 credentials were used from a different machine than the one that took them. Ten were used from the harvesting host; two had no resolvable source.
- 32 addresses did all the harvesting. 353 addresses did the using — an 11× fan-out. Collection is centralised; exploitation is distributed.
- 67% of API calls were spam-capability probes. They were not looking at data. They were asking whether the account could send email and SMS at volume.
- 7 calls were
InvokeModel— Bedrock. Credentials stolen specifically to run models on someone else's bill. - Reputation feeds would have flagged 8.3% of the hosts that used a key. GreyNoise flagged 3.2%. Only 6.8% had ever touched the honeypot before.
The last point is the one that matters operationally: the standard automated response to a honeypot hit — enrich the source IP, block the source IP — is aimed at a host that has already passed the credential on.
Method
Every visitor to a bait file is issued its own AWS credential, minted per visitor rather than shared. The credential grants nothing; it only reports. When it is used anywhere against AWS, the report carries the caller's address, user agent, timestamp and the API action attempted.
Because the credential was unique, the harvest event and the use event resolve to one another with certainty. No fingerprint similarity, no heuristic correlation — a shared secret that only one visitor was ever given.
That is the whole instrument. Everything below follows from having both ends.
1 · Harvest and use are different machines
| Measure | Value |
|---|---|
| Credential uses observed | 408 |
| Used from a different IP than harvested | 396 |
| Used from the same IP | 10 |
| Distinct harvesting addresses | 32 |
| Distinct using addresses | 353 |
| Fan-out | ≈11× |
Ten same-IP cases are worth naming rather than rounding away: immediate self-validation does happen, it is just rare. The dominant pattern is that the machine which scrapes the credential is not the machine which spends it.
Note on interpretation. This shows harvest and use run on different infrastructure. It does not distinguish between one operator rotating egress, a harvest-then-sell pipeline, and a shared validation service. From the defender's vantage point that distinction does not change the consequence: the address you would have blocked is not the address that used the credential.
2 · The time between theft and use
Median: 2.7 days. But the distribution is bimodal, and the shape is the finding.
| Window | Uses |
|---|---|
| Under 10 minutes | 30 |
| 10–60 minutes | 26 |
| 1–6 hours | 76 |
| 6–24 hours | 19 |
| 1–7 days | 171 |
| Over 7 days | 86 |
14% within the hour. 37% within a day. But the median sits at 2.7 days and the tail runs past 100.
There appear to be two behaviours: a fast lane that validates a credential almost immediately (23 uses inside five minutes), and a slow lane that batches harvested material and works through it days or weeks later.
Both defeat IP-based response, for different reasons. The fast lane outruns any human-in-the-loop process and most feed propagation. The slow lane means that by the time the credential is used, any reputation signal attached to the harvesting host is stale and the using host is new.
3 · What they wanted
Of 346 recorded API actions:
| Action | Count | What it tells you |
|---|---|---|
GetSendQuota | 183 | Can this account send bulk email? |
GetAccount | 58 | SES account posture |
GetCallerIdentity | 39 | Orientation — who am I? |
GetSMSAttributes | 20 | Can it send SMS? |
VerifyEmailIdentity | 20 | Set up a sending identity |
InvokeModel | 7 | Run inference on the victim's bill |
GetSendStatistics | 7 | Sending reputation |
DescribeInstances | 6 | Compute inventory |
67% of all activity was probing spam capability. Not data theft, not lateral movement, not persistence — deliverability. A stolen cloud credential is, to most of the people using it, a potential mail relay.
The seven Bedrock calls are a small but distinct signal: credential theft aimed at stealing compute for inference. LLMjacking is documented as a phenomenon; here it appears end-to-end, with the harvest side instrumented.
4 · The counterfactual: would the usual controls have helped?
For every credential use, the question was asked retrospectively: at that moment, would a common control have stopped the host that used it?
| Control | Would have flagged |
|---|---|
| GreyNoise classification "malicious" | 3.2% (13 / 408) |
| AbuseIPDB score ≥ 80 | 5.1% (21 / 408) |
| Either feed | 8.3% (34 / 408) |
| Had any prior history with this honeypot | 6.8% (24 / 353) |
An accumulation rule — this honeypot's own autoblock triggers on three trap paths or twenty hits in 24 hours — would have caught approximately none of them. The using hosts average roughly one event each. The counter never reaches the threshold because the actor never returns.
But infrastructure concentrates where addresses do not. Across 79 distinct networks, the top five carry 38% of all credential use.
The address is disposable. The network is not. If you are going to key a control on something the attacker controls, ASN is a far better bet than IP — with the obvious caveat that some of those top networks are consumer ISPs, and blocking those is not a serious proposal. Use it as a risk multiplier feeding step-up, not a deny rule.
5 · Who is calling
| Client | Uses |
|---|---|
| Boto3 / botocore | 259 |
| aws-cli | 112 |
| aiohttp | 13 |
| axios | 9 |
| other / none | 15 |
| browsers | 0 |
Not one credential was used from a browser. This is automation end to end.
What this does not say: Boto3 is a Python SDK and has been since long before LLMs. Automation is proven; an autonomous agent driving it is not. Those are separate claims and this dataset only supports the first.
6 · Honest limits
The sample is skewed by campaigns. Three days account for a large share of the total (108, 76 and 73 uses respectively — the top two days alone are 45%). These look like distribution events, where a batch of harvested credentials was fanned out to many hosts at once. Effective independent sample size is well below 408.
One honeypot, one credential type, 35 days. The phenomenon generalises; the rates should not be quoted as representative of the internet.
The environment recruits its own population. The host advertises bait through robots.txt and a sitemap. It is deliberately attractive to credential-scraping traffic, and then reports on credential-scraping traffic. That is a selection effect and it should be assumed present in every number above.
Latency is measured from credential issuance, not from the moment of scraping. If a visitor took the file and used it later, that gap is included. It is an upper bound on the attacker's own turnaround.
No claim is made about AI. Nothing here demonstrates a model in the loop.
7 · What a defender should do with this
Plant unique canary credentials in the places attackers loot — CI/CD environment files, repo .env, backup archives, jump-box credential files, internal wikis. Make each one unique per location so the fire tells you which surface leaked.
Treat a fire as an identity event, not a network event. Revoke and rotate the real credentials co-located with the canary. Audit that identity's recent API calls. Hunt backwards from where the canary lived — not from the address that used it. Blocking the firing IP is close to theatre: it would have mattered in under 9% of these cases.
Carry a join key across data sources. The harvest event and the use event arrive in different logs, hours or days apart, with no shared address. Without an identifier that survives the gap, they are two shrugs in two queues. With one, they are an incident.
Re-scope rate limits off the source address. Count against the credential, the account, or the target resource. The justification is one number: roughly one use per address.
Kill static long-lived credentials wherever you own the auth boundary. Every use observed here involved a bearer credential with no second factor. That is the property being exploited. Short-lived STS, OIDC federation, and IAM conditions remove the class of attack rather than detecting it.
Reproducing this
The instrument is not exotic. Canary credentials are free at canarytokens.org; the only engineering is issuing a unique one per visitor and recording who received which. That single property is what turns a tripwire into a measurement.
Everything in this document comes from 408 rows, each carrying five fields: who was served the credential, who used it, when, what they called, and with what client.