TL;DR: A custom Boto3 user_agent_extra suffix, iam_masscek/2.0, observed
validating stolen AWS credentials against a Thinkst Canarytoken. As of
2026-07-30 this string appears in no public threat feed, GitHub repository, or
vendor report.
| Date (UTC) | Source IP | ASN | Event |
|---|---|---|---|
| 2026-07-23 19:21 | 172.56.216.22 | AS21928 T-Mobile USA | GetContactInformation |
| 2026-07-23 19:23 | 97.220.48.114 | AS6167 Cellco / Verizon | GetAccount (SES) |
Boto3/1.43.40 md/Botocore#1.43.42 ua/2.1 os/linux#5.15.0-46-generic md/arch#x86_64 lang/python#3.10.12 md/pyimpl#CPython m/E,b,e,Z cfg/retry-mode#standard Botocore/1.43.42 iam_masscek/2.0
iam_masscek/2.0is appended via Boto3'suser_agent_extra— it is set deliberately, not a default. The name suggests "IAM mass check(er)".- Version
2.0implies a maintained tool rather than a throwaway script. - Platform fingerprint: Ubuntu 22.04 (
linux#5.15.0-46-generic), Python 3.10.12. - Two different US mobile carriers, two minutes apart, byte-identical user agent → a single operator rotating through residential/mobile proxy exits.
GetContactInformationandGetAccountare victim profiling: who owns this account, and does it have SES production sending access — i.e. assessing the credential's resale value.
The credentials were AWS canary tokens (Thinkst Canarytokens) placed in a decoy
.env file on a web server, reachable only by automated scanners. They grant no
real access. Over the following weeks the same credential was tested by
approximately eight distinct toolchains against SES, SNS, Bedrock, EC2, Route53,
Lambda and IAM/STS — harvested from bulletproof hosting, then exercised almost
exclusively from residential, mobile and Cloudflare egress.
If you see iam_masscek in a CloudTrail userAgent field, the credentials in
question are compromised and are being inventoried by a third party.
Related: Elastic's AWS Suspicious User Agent Fingerprint rule covers this
indicator class generally.
Thanks for this report! Have seen a similar attack, source was Norway