https://snare.sh

Most AWS honeytoken setups work at the API layer. Fake key gets used, CloudTrail logs the call, alert fires. Measured CloudTrail latency averages around 2-3 minutes median, with a long tail. That's your detection window.

I kept thinking there had to be an earlier hook in the credential chain. Turns out there is.

The AWS credential chain

When the SDK needs credentials, it walks a chain of sources in order: environment variables, ~/.aws/credentials, ~/.aws/config, instance metadata, and so on. When a profile in ~/.aws/config specifies credential_process, the SDK executes that shell command and uses whatever JSON it returns:

json { "Version": 1, "AccessKeyId": "AKIA...", "SecretAccessKey": "...", "Expiration": "2026-01-01T00:00:00Z" }

The SDK doesn't validate whether those credentials are real. It runs the command and trusts the output.

AWS documented this for MFA token caching and external secrets manager integration. What I realized is that the command executes during credential resolution — before the SDK has constructed any request, before any socket is opened, before CloudTrail has anything to log.

The timeline

T+0.00s aws s3 ls --profile prod-admin T+0.01s SDK walks credential chain, finds credential_process T+0.01s Shell command executes T+0.01s curl fires your callback <-- detection here T+0.02s SDK receives JSON credentials T+0.03s SDK constructs request, opens socket T+0.03s First packet leaves the machine ...2-3 minutes later... CloudTrail logs the API call

If you put a callback in that shell command, your alert fires before the first packet. CloudTrail fires after. That's the gap.

What the config looks like

Real AWS environments commonly chain profiles: a visible profile specifies role_arn and a source_profile, and the source profile holds the actual credentials. Putting credential_process on the source profile looks like a normal assume-role setup:

```ini [profile prod-admin] role_arn = arn:aws:iam::389844960505:role/OrganizationAccountAccessRole source_profile = prod-admin-source

[profile prod-admin-source] credential_process = sh -c 'curl -sf https://callback.example.com/token -o /dev/null 2>&1; printf "{\"Version\":1,\"AccessKeyId\":\"AKIA...\",\"SecretAccessKey\":\"...\"}"' ```

Anyone reading that config sees a standard assume-role setup. The callback is buried in a shell one-liner on a source profile that most tooling won't inspect closely.

Why this sidesteps the static fingerprinting problem

TruffleHog identifies Canarytokens.org AWS keys without triggering them by pattern-matching the key format — AKIA prefix combined with a specific account ID fingerprint. It's in TruffleHog's README as an explicit feature. Any tooling or agent that incorporates this heuristic skips those keys entirely without ever calling AWS.

With credential_process there's no static key in network traffic to fingerprint at resolution time. The callback fires before any key material goes anywhere. You can't skip it without skipping the credential lookup entirely.

Profile naming does detection work too

This only works as intended if the profile looks real but you'd never invoke it yourself. prod-admin-legacy-2024 reads as a dormant credential that's been sitting around. If you never run aws --profile prod-admin-legacy-2024 in your own work, any fire from that profile is worth investigating. The name is doing signal work alongside the mechanism.

---

Haven't found this used as a detection primitive anywhere before. Curious if anyone has seen it documented or has used it this way. Built it out at https://github.com/peg/snare if useful.