Attackers Are Testing Stolen AWS Keys for Amazon Bedrock Access, Leaving a Pattern Defenders Can Spot

LONDON - Attackers who steal Amazon Web Services access keys are checking for more than whether the keys still work. They are testing whether the keys can reach Amazon Bedrock, the AWS service that runs commercial AI models, and they are doing it with a short, repeatable run of API calls that defenders can watch for, according to research Datadog Security Labs published on Tuesday. Datadog said it had found a credential harvesting platform called KMON_NOC that treats Bedrock access as its own category of stolen key, along with two Python scripts on VirusTotal that test AWS credentials against Bedrock in several regions. Hosts tied to KMON_NOC have scanned and probed for credentials at more than 80 Datadog Cloud SIEM customers since August 31, the company said, and over the past 30 days it saw 12 organizations show similar malicious behavior. "Not all credentials are created equal," wrote Martin McCloskey, a staff security engineer at Datadog.

The practice has a precedent. For years, Datadog said, attackers holding AWS keys have called email and text messaging APIs such as GetSendQuota, GetSMSAttributes and GetSMSSandboxAccountStatus to learn whether an account is in production or a sandbox and how much it can send, because "the usefulness of the credentials affects their resale value." Keys that can run AI models now have a market of their own. Datadog cited August research from Unit 42, the Palo Alto Networks threat research group, on token jacking, in which gray-market resellers known as transfer stations sell access to frontier AI models at a fraction of the retail cost. Unit 42 said those services depend on legitimate API tokens, that many operators turn to stolen credentials because buying tokens at full price to resell them is not profitable, and that it had responded to cases where exposed credentials were stolen and plugged into a transfer station within minutes, which led to "nearly a million dollars in charges before discovery and containment."

KMON_NOC sits behind a login page that asks for an access password, and Datadog said it could neither get in nor observe AWS API activity from the platform's infrastructure. Instead, it analyzed a publicly accessible JavaScript bundle that the portal loads. According to that code, the platform first validates each AWS key pair with the Security Token Service call GetCallerIdentity, signed with Signature Version 4, and then puts the valid keys through a separate check for Bedrock access. A field named keysWithBedrock feeds counters labeled BEDROCK and BEDROCK ACCESS that sit beside the dashboard's totals of keys found and keys that proved valid. The code also extracts AWS_BEARER_TOKEN_BEDROCK, the environment variable that AWS documentation says Bedrock recognizes for its API keys, and gives operators buttons to reveal and copy those tokens. Datadog said its account of KMON_NOC rests on inferences from front-end code and that it is monitoring for any AWS activity tied to the platform.

The two scripts show the whole routine. Both process lists of credentials, identify the AWS principal behind each one, test Bedrock across multiple regions and keep the working credentials in plaintext, Datadog said. In the script it took apart, identified by the SHA-256 hash 923641364ef0ce3a6f1d944890244082b8c7f29c9600c0433b2a0ca9822c0608, each key is first checked with GetCallerIdentity, which returns the account ID, ARN and user ID. In every selected region, the script then calls Bedrock's ListFoundationModels to confirm the endpoint is reachable and to tally the available models and providers, lists the account's inference profiles with ListInferenceProfiles, and finally calls the Bedrock runtime Converse API with the prompt "ping," capping the reply at four tokens to keep each test cheap. Any successful reply counts as usable access. The script defaults to smaller, cheaper models such as haiku, nova-lite and titan-text-lite. A dedicated Anthropic mode prioritizes Claude models and recognizes the error AWS returns when an account has not submitted Anthropic's use case details form, then stops trying Claude models in that region. An opt-in option, which the other script lacks, calls the billing API GetCredits to read promotional credit balances, currency, expiration dates and whether the credits cover Bedrock. Datadog said the script's unusually verbose comments could indicate that it was designed by an LLM.

Datadog's own telemetry shows the same steps. In most of the 12 organizations, it saw failed ListFoundationModels calls in multiple regions with no follow-up ListInferenceProfiles or Converse calls, consistent with the way the script handles errors. In one case, the attacker made successful ListFoundationModels and ListInferenceProfiles calls across regions and then several Converse calls that returned AccessDenied for three Anthropic models: anthropic.claude-opus-5, anthropic.claude-fable-5 and anthropic.claude-fable-5-1. "We cannot establish a link between the script analyzed in this post and the telemetry observed; however, there is a recurring pattern of behavior," Datadog wrote. A Datadog report on September 18 about two exposed credential harvesting dashboards, which it called Loot and UltraVault, described a similar pattern from the host serving them: GetCallerIdentity, then ListFoundationModels, then bursts of InvokeModel calls against multiple Anthropic model versions, repeated dozens of times across regions in under a minute. That report singled out two user agents as detection opportunities, a Boto3 client whose platform string included kali-cloud and a bare Python-urllib/3.13, and said temporary STS credentials, identifiable by the ASIA access key prefix, were being validated by the same host.

For detection teams, the first rule is to watch both ways of calling a model. Converse offers one message format across models while InvokeModel needs a model-specific request, and "either call can be used to test compromised credentials, so defenders should monitor both," Datadog wrote. Hunting pivots drawn from the research include a GetCallerIdentity call followed by ListFoundationModels in several regions from the same access key, particularly a long-term key; Bedrock discovery or inference calls from an identity with no history of AI use or from a new network; strings of AccessDenied or ValidationException errors across Bedrock models; a GetCredits call from a key that has just touched Bedrock; new Bedrock API keys created with no expiration date; and requests to raise Bedrock service quotas. Datadog published 64 IP addresses seen attempting the validation pattern since August 31, but said they are a mix of residential proxies, VPNs and hosting providers and should be used only alongside the AWS activity it described. It also published the hashes of both scripts, c9335bb8a21bd2c568d03b040fb86a0e72145691e54a33495ee0cfaac55835dc and 923641364ef0ce3a6f1d944890244082b8c7f29c9600c0433b2a0ca9822c0608. "Unexpected Bedrock activity, particularly from a new source or by an identity with no history of AI usage, should be investigated," the company said.

There are limits to what the research shows. Datadog's picture of KMON_NOC comes from front-end code rather than observed AWS activity, the company does not tie either script to the activity it saw in customer accounts, and it sells Cloud SIEM rules for these patterns, which its post lists. The stakes it describes are financial. "Minimal validation behavior could be a precursor to an attack with a larger financial impact," Datadog wrote, and catching it early "is essential to avoiding a larger bill further down the line." Unit 42's advice for limiting the damage is to set spending limits on AI usage that alert when usage departs sharply from a baseline, review the privileged accounts that can provision resources or change those limits, move from long-term access keys to short-term bearer tokens, and put network boundaries around compute so that stolen keys cannot be used from outside corporate infrastructure.