How to investigate cloud credential compromise with Bits AI Security Analyst

Cloud environments create a flood of security signals, often reaching tens of thousands per day depending on the organization’s size. Security engineers and analysts spend a disproportionate share of their time triaging these signals instead of acting on legitimate threats. But the time-intensive parts of that work, such as identifying related signals and building a timeline, can be handled systematically, leaving teams free to focus on what actually requires human judgment.

This post walks through what a cloud security investigation looks like when most of the manual work is automated at the following stages:

• Detecting changes in behavioral baselines for a user
• Analyzing the API calls involved in the activity
• Identifying patterns in the user’s new activity
• Generating a final assessment of the activity

We’ll also show how Bits AI Security Analyst manages behavioral analysis and threat correlation at each stage, so analysts can spend less time reconstructing what happened and more time deciding how to respond.

Identify behavioral anomalies in a cloud security investigation

Imagine a scenario where an AWS Identity and Access Management (IAM) user with 60 days of typical activity suddenly generates 100 API calls to Amazon Simple Notification Service (Amazon SNS) and Amazon Simple Email Service (Amazon SES) services. The SNS and SES calls all occurred within a single day and across four AWS Regions. Is this a developer testing a new integration? A misconfigured automation job? Or an attacker staging a phishing campaign by using a compromised credential? In scenarios like these, the challenge for analysts is piecing all the available information together to answer those questions in a timely manner, before an issue escalates.

The IAM user in our scenario, Alice.Robertson, has 60 days of consistent activity on record and then suddenly began generating multiple high-priority signals for failed Amazon SNS calls.

Close dialog

A good place to start investigating is by understanding the context surrounding the activity change. For example, a user generating SNS calls for the first time is more suspicious than a sudden spike in calls to services they use regularly. The spike has a baseline of activity to compare against, but first-time service access by an established identity with predictable API calls is harder to justify.

Bits AI Security Analyst surfaced the following patterns from the user’s signal history:

1
The signal was triggered on February 25, 2026, at 15:15:48 UTC when IAM user arn:aws:iam::123456789012:user/Alice.Robertson made multiple GetSMSAttributes API calls to Amazon SNS across 4 different AWS regions (ap-south-1, ap-northeast-2, sa-east-1, and us-east-2) using long-term access key AKIAGGWFBBHBE7DEMO12.
2

3
The user demonstrated consistent daily activity from December 25, 2025 to February 25, 2026, with volumes ranging from approximately 1,500 to 7,300 events per day, following a semi-regular pattern typical for operational accounts. However, the suspicious SNS enumeration and service quota checks were concentrated only on February 25, 2026, representing a significant deviation from the user's established 60-day pattern.

The SNS enumeration—a common account discovery technique—is concentrated on a single day despite 2 months of otherwise stable activity, and it spans four AWS Regions simultaneously. These patterns are notable because they don’t reflect typical day-to-day workflows, such as a developer testing a new integration. The greater possibility is a script methodically probing the account’s SNS capabilities.

Analyze API call patterns to trace attacker tooling

Sudden changes in a user’s baseline activity can stem from minor issues, such as outdated user permissions or unexpected infrastructure misconfigurations. Distinguishing those scenarios from a compromised credential requires looking at the structure of the calls themselves.

In our scenario, analysts would need to systematically review AWS CloudTrail logs for information about the IP, user, user agent, and Amazon Resource Name (ARN) to uncover any notable patterns in the requests, such as the source of the calls and the specific services they interacted with. Bits AI Security Analyst discovered that all API calls in question traced back to a single source IP (98.92.219.88) and the same Boto3 Python SDK user agent:

1
All 100 events from IP 98.92.219.88 occurred on February 25, 2026, showing highly concentrated burst activity rather than distributed usage over time.
2

3
The IP consistently showed a United States location associated with Amazon Web Services and maintained the same Boto3 Python SDK user agent throughout all activities, indicating programmatic and likely automated access.

A single IP source indicates coordinated activity

Suspicious API calls from the same IP address rules out the possibility of a leaked, distributed credential. If a credential had been leaked broadly—for example, scraped from a misconfigured Amazon S3 bucket and posted to a public repo—analysts would typically see it associated with multiple IPs instead of one. A single IP address indicates that one actor is making deliberate and sequential API calls.

An analyst can compare that IP address against the IAM user’s activity baseline to determine if it represents a new or unexpected location. An outlier doesn’t necessarily indicate compromise, but it rules out some root causes. For example, a developer testing a new integration would typically work from an approved environment, and a CI job would originate from a registered autonomous system number (ASN), such as one used for pipelines running on GitHub Actions.

The Boto3 user agent describes the actor’s tooling

The user agent boto3/1.x.x shows that these calls were a part of a script instead of a console session or a managed AWS service. Boto3 is Python’s AWS SDK and is used in legitimate automation, so it’s not inherently suspicious. A Python script running from an unrecognized external IP, however, suggests the actor is using some kind of programmatic toolkit. Many cloud exploitation frameworks are built on Boto3, such as Pacu.

Threat intelligence lists flagged the IP address

Multiple programmatic calls from a single IP address suggest sources such as anonymizing proxies, so running the IP against threat intelligence is the next logical step in the investigation. Bits AI Security Analyst compared the IP against available threat intelligence lists to discover the nature of the source:

1
Threat intelligence revealed that IP 98.92.219.88 is associated with Amazon Web Services, Inc. (AS16509) and flagged as "suspicious" with category "hosting_proxy", specifically identified as having tunnels with risk "TUNNEL" and marked as an anonymous proxy.

An anonymous proxy classification means that the user is attempting to obscure the origin of their calls, which rules out legitimate automation or developer workflows. An analyst can assume that the requests are not coming from a developer or CI/CD pipelines running on known infrastructure.

The anonymous proxy is a straightforward example, but Bits AI Security Analyst can surface higher-value threat intel findings, including:

• IPs flagged by Spur as residential proxies, which are commonly used to disguise credential abuse and account takeover as legitimate user activity
• IPs identified as Tor exit nodes, which may indicate an attempt to anonymize API calls, and at minimum flag a policy violation worth investigating
• Hosts communicating with known malware infrastructure, as identified by ThreatFox

Map the attacker’s goals from cloud API activity

Once API calls are confirmed as suspicious, their structure reveals a lot about what an actor is trying to do in the environment. In our scenario, the user made several unauthorized attempts to call GetSMSSandboxAccountStatus for an SNS service:

1
AccessDenied: User: arn:aws:iam::123456789012:user/Alice.Robertson is not authorized to perform: SNS:GetSMSSandboxAccountStatus on resource: arn:aws:sns:us-west-1:123456789012:* because no identity-based policy allows the SNS:GetSMSSandboxAccountStatus action

An analyst would need to review other error logs to determine if the user’s API calls target only one endpoint or are spread across multiple services. A cluster of AccessDenied errors for several endpoints point to an actor attempting to test the boundaries of a user’s permissions, as well as the availability of specific AWS services, before committing to a specific action.

Bits AI confirmed the scope of the enumeration in its analysis, including the specific access key identified in the initial signals:

1
The logs revealed systematic enumeration across multiple AWS services: GetSMSAttributes (8+ instances) for SMS capabilities in SNS across regions, GetServiceQuota (12+ instances) for service limits, GetAccount (7+ instances) for account information, and GetSendQuota (5+ instances) for email sending quotas in SES.
2

3
The sudden appearance of systematic enumeration activities using Python Boto3 SDK from a United States-based AWS proxy IP, combined with access denied errors that indicate permission boundary testing, strongly suggests account compromise rather than legitimate user behavior. The temporal concentration of reconnaissance activities on a single day, despite consistent historical activity, indicates an attacker obtained the user's long-term access key AKIAGGWFBBHBE7DEMO12 and is performing intelligence gathering focused on messaging capabilities.

The type of calls point to a phishing campaign

Long-lived access keys are a persistent source of exposure in cloud environments. Once obtained, they enable actors to gather more information about an environment over time before an actual attack happens. As Bits AI confirmed, each call suggests that the actor was testing the IAM user’s permission boundaries and enumerating on available SNS and SES capabilities. Calls to endpoints such as GetSendQuota and GetSMSAttributes often precede phishing or spam campaigns in AWS environments. For example, actors make GetSendQuota API calls using compromised access keys to determine if an environment has an available SES account to send messages.

The fact that the actor is still gathering intelligence through these API calls also provides useful insights into their timelines. The timing between API calls and executed phishing campaigns has implications for how quickly analysts need to contain the threat.

Classify the threat and close out the investigation

A single known-malicious IP making programmatic API calls across SNS and SES endpoints, with no prior history of this activity, points to a compromised account involved in the early stages of a phishing campaign. Based on these factors, Bits AI delivers its classification, as seen in the following assessment:

Close dialog

Many investigations in high-volume cloud environments end without a definitive answer because there isn’t enough time to correlate everything manually. With access to assessments that are backed by behavioral analysis, threat intelligence, and API-level evidence, analysts have enough concrete information to remediate.

Turn the assessment into actionable remediation steps

Since Bits AI confirmed the activity as the initial phase of a phishing campaign, the priority for analysts is containment before the actor moves from intelligence gathering to execution. The immediate steps include:

• Revoking the access key: Because the API calls don’t originate from any internal infrastructure, analysts can remove the key without breaking a legitimate workload. They can then follow up with the user to discuss next steps for securing the account.
• Auditing both successful and failed API calls: The AccessDenied errors were confirmed as part of the investigation, but analysts should also review CloudTrail logs for any calls that completed successfully. Examples include newly created SNS subscriptions or verified SES identities.
• Expanding the scope of the investigation: It’s worth reviewing whether other IAM users in the account show similar activity patterns, particularly any with SNS or SES permissions they don’t regularly use.

Speed up cloud security investigations with Bits AI Security Analyst

Security engineers and analysts must methodically piece together logs and signals to confirm suspicious activity, and identify and fix the root cause before it escalates. Bits AI Security Analyst complements an analyst’s day-to-day workflows by reducing signal fatigue and enabling them to focus on the judgment calls that require human expertise.

You can read our blog to learn more about identifying phishing campaign activity in your AWS environment. You can also review our documentation to learn how to start using Bits AI Security Analyst in your Cloud SIEM investigations.

If you don’t have a Datadog account, you can sign up for a free 14-day trial.