Beyond IPs: Why Your Cloud Detection Strategy is Failing

TLDR: Traditional indicators of compromise like IP addresses and file hashes are increasingly useless in cloud environments where attackers use VPNs, TOR, and ephemeral infrastructure. This research demonstrates that attackers leave distinct, repeatable behavioral footprints in IAM activity and API call sequences. By shifting focus from static indicators to these behavioral patterns, security teams can detect and attribute sophisticated cloud-native attacks even when the infrastructure is constantly rotating.

Security researchers often fall into the trap of relying on static indicators of compromise. We chase IP addresses, domain names, and file hashes because they are easy to ingest into a SIEM. But in the cloud, this approach is a losing battle. Attackers know that if they rotate their infrastructure or route their traffic through a jump box, they can bypass most automated detection rules. The real signal in cloud environments is not what the attacker is using, but what they are doing.

The Failure of Atomic Indicators

When we look at recent campaigns like the Androxgh0st malware, the industry focus remains heavily on the "what"—the specific hashes of the malicious scripts or the C2 domains. While this data is necessary for initial blocking, it ignores the "how." Cloud environments are fundamentally different from on-premise data centers because the infrastructure itself is an API-driven service.

Attackers are not just exploiting software vulnerabilities; they are exploiting the cloud control plane. They use IAM privilege escalation to move laterally, or they abuse SSRF vulnerabilities to query the Instance Metadata Service (IMDS) and steal temporary credentials. These actions are not captured by a static blocklist. If you are only looking for a known bad IP, you are missing the attacker who is already inside your AWS account, calling iam:CreateUser or ec2:ImportKeyPair with a hardcoded, attacker-controlled key.

Behavioral Patterns as the New IOC

The most effective way to track these actors is to map their specific API call sequences. Attackers are creatures of habit. They use automated toolkits, and those toolkits have predictable patterns. For example, a common reconnaissance flow involves a specific sequence of calls: GetCallerIdentity, DescribeSubnets, and DescribeInstances.

When you see this sequence performed by a user agent associated with a library like boto3, you are likely looking at an automated scan. If that sequence is followed by an ImportKeyPair call using a key name like apec or dfgfg, you have moved from generic noise to a high-confidence indicator of a specific threat actor.

Consider the following snippet of a typical malicious automation script:

import boto3

client = boto3.client('iam')
# The attacker creates a user with a hardcoded name
client.create_user(UserName='ses_xcatz')
# Then they immediately attach policies to escalate privileges
client.attach_user_policy(UserName='ses_xcatz', PolicyArn='arn:aws:iam::aws:policy/AdministratorAccess')

This is not a one-off event. It is a repeatable, observable behavior. By logging these API calls via CloudTrail, you can build detection rules that trigger on the sequence of events rather than the source IP. If you see a CreateUser call followed immediately by an AttachUserPolicy call with an AdministratorAccess ARN, you should be alerting, regardless of where the request originated.

Real-World Hunting

During a recent engagement, we observed a threat actor we dubbed "Bapak." They were not targeting a specific industry or region; they were simply scanning for exposed credentials. Because they reused the same SSH public key across multiple compromised environments, we were able to link disparate incidents to a single actor.

The methodology for finding them was straightforward:

1. Identify the footprint: We used a cloud-native honeypot to capture the initial credential usage.
2. Pivot to the environment: We searched for the same API call patterns—specifically the ImportKeyPair and CreateCluster calls—across our telemetry.
3. Correlate: We linked the malicious activity back to the same SSH key fingerprint, proving that the same actor was behind the activity in multiple, unrelated accounts.

This is the power of behavioral IOCs. They allow you to track an actor even when they switch from a VPN in Indonesia to a different exit node in another country. The infrastructure changes, but the TTPs remain constant.

Defensive Implementation

Security teams need to move away from simple alert-on-IP models. Instead, start by establishing a baseline of "normal" behavior for your service accounts and IAM users. If a developer's account suddenly starts calling DescribeInstances or ImportKeyPair, that is an anomaly.

Furthermore, you must contribute to the community. We have released our research repository of cloud-specific IOCs to help standardize how we track these behaviors. If you encounter a new attack pattern, document the API sequence and share it. The more we share these behavioral signatures, the faster we can build automated defenses that actually work against modern cloud threats.

Stop treating cloud security like a network perimeter problem. The perimeter is gone. The API is the new network, and if you aren't monitoring the calls being made to your control plane, you are effectively blind. Start hunting for the patterns, not the IPs.