Introduction 

Behavioral IOCs are key indicators based on patterns of activity that suggest malicious intent. They focus on how attackers exploit systems rather than just the individual tools or resources they use. These indicators typically highlight anomalies in user behavior, unusual API activity, or specific changes to configurations and permissions. Behavioral indicators relate to runtime telemetry and activity logs and are therefore utilized in more complex detections than atomic indicators. If Tactics, Techniques & Procedures (TTPs) describe what an attacker does, behavioral IOCs are how we know they've done so in a given environment (see also Zack Allen’s talk on this subject from fwd:cloudsec). 

In the first part of this series, we covered how the unique infrastructure of cloud environments creates opportunities for new and useful atomic indicators of compromise. In this second part, we would like to examine the other side of the coin –  the behavioral IOCs. Additionally, we’ll go into detail about malicious activity conducted by a threat actor we call “Bapak”, an opportunistic attacker that abuses exposed keys. We’ll use this activity as a case study to discuss a method we’ve been employing to fingerprint and rapidly detect these kinds of attacks. 

What are behavioral IOCs? 

Behavioral Indicators can be used to describe any of the following activities, as reflected in various logs such as CloudTrail: 

1. Actions (e.g., CreateUser)

2. Actions with specific parameter values (e.g., CreateUser with the name ses_xcatze)

3. Series of actions / time-series (where the order and timing of the actions can indicate the usage of a specific script)

4. Contextualized actions (e.g., an API call from a TOR IP address in an environment where TOR is not normally in use)

Based on the above, we can derive two main types of behavioral IOCs: 

1. Actions or series of actions that are specific to a known actor or tool - for example, AndroxGh0st can be identified by the following series of actions:

   1. Calls GetSendQuota. 

   2. Calls CreateUser with the name ses_xcatze. 

   3. Repeats multiple times in different regions. 

2. Generic identifiers of TTPs, not specific to a known actor or tool - for example, the following series is a pattern commonly observed in multiple attacks after the threat actor gained initial access to a compromised account:

   1. Multiple Successive calls to GetCallerIdentity and ListAttachedUserPolicies. 

   2. All called with the Boto3 user agent (meaning it was a scripted action). 

   3. Additional examples of generic behavioral IOCs can be found in the appendices. 

Linguistics of malicious behavior 

Malicious behavior in cloud environments can be thought of as composed of multiple layers, each layer building upon the ones below it to create a coherent attack narrative. At the most granular level, individual events—such as an API call to GetCallerIdentity—serve as the foundation of higher-order actions. These events, when combined, form actions that represent specific attacker behaviors, like enumerating the permissions of a compromised user account (through a sequence of API calls). Going up another level, when multiple actions are orchestrated in a coordinated manner, they constitute techniques, such as privilege escalation or infrastructure setup for persistence. 

For example, a series of API calls to CreateUser, AttachPolicy, and ImportKeyPair could combine to execute a technique aimed at establishing unauthorized access. Understanding this layered structure enables security teams to build detection rules, contextualize individual events, and respond to malicious behavior at every stage of an attack. 

Additionally, by correlating observed techniques with the cloud context of the involved resources and threat intelligence related to the principal IP address of the API caller, security teams can more easily triage alerts and prioritize their efforts to deal with threats posing the highest business impact to their cloud environment.  

Case study: “Bapak” 

In the course of our threat hunting efforts, we occasionally run into attempts by low sophistication threat actors to utilize stolen cloud credentials. In recent engagements, we encountered several instances of what appears to be the same actor or set of related actors operating out of a suspicious ASN located in Indonesia. The actors' choice of naming schemes in their API calls also seems to indicate an Indonesian origin. 

`Bapak` is a group we detected across multiple customers, suggesting a systematic scanning of exposed credentials without any specific targeting. The group mainly operates out of IP addresses located in Indonesia, but occasionally employs VPNs to try and mask their activity. 

After gaining access to a cloud key (regardless of how they may have acquired it), the attacker first tries to establish a foothold in the victim’s environment, calling ImportKeyPair to enable access to the machines it will later try to create. Surprisingly the group used the same SSH key (i.e., the same public key material) in multiple incidents, which made it simple to link the different incidents to the same actor. 

In the next stage, they gather information about the permissions associated with the leaked key as well as general details about the victim’s environment, usually calling: 

- GetCallerIdentity 

- DescribeSubnets

- DescribeInstances 

These actions are followed by a call to the ECS API CreateCluster attempting to create a cluster with the name bapak1. Fortunately, in the incidents we observed the attacker lacked the permissions required to actually create this cluster. 

Investigation methodology 

Compromised credential attacks are some of the most common attacks we see on cloud environments and with a 71% increase of incidents year-over-year, this trend doesn’t seem to be slowing down. That is why at Wiz we are always looking for novel methods to identify theft and abuse of compromised credentials. 

A while ago, in an effort to research how compromised credentials are abused by threat actors, we set up a cloud honeypot. The gist of it is we purposefully “leak” various access keys in a variety of publicly accessible locations in order to then observe how quickly attackers are acquiring and using those credentials and what exactly they are attempting to do with them, providing us with high-quality leads for threat hunting in real cloud environments. The theory behind this method is summarized in the following diagram, which we will explain in detail below: 

This method is designed to detect two common cases of compromised credentials: 

• A public leak, for example accidentally publishing an AWS key to a public git repo. 

• An infostealer operator who sells credentials to as many buyers as possible. 

In both cases the credentials are likely to be used by more than one malicious party, which is something we can use to our advantage.  

One of the benefits of our cloud honeypot system is that we get a constant and up-to-date stream of malicious, attacker-owned IP addresses. Additionally, we can group attackers’ API calls by the credentials they used and the caller’s IP metadata (ASN, Country, etc.). This is an easy way to cluster the various activities we observe to different actors. While this method is not perfect, it gives us simple patterns to look for in the next step. 

For example, let’s say our starting point is a small set of IP addresses observed in our honeypot calling unique AI-related API calls, like PutUseCaseForModelAccess: 

We can now query real cloud environments for the same set of IP addresses as the one observed in our honeypot while applying the same API call grouping method. By searching in a narrow time range, around 7 days, we can reduce the chance of IP addresses changing hands and thereby creating false positives. 

By pivoting on common API call groups sourced from the honeypot data, we can identify real IAM credentials that were stolen and abused by the same attackers. Continuing our example here, we can see results resembling the group we observed in the honeypot – these actions in real environments share the same principal IP addresses and API calls as the results from our original honeypot data:  

These findings led us to identify an LLMjacking campaign conducted by a threat actor we call JINX-2401, as described in more detail in our recent blogpost on the subject. 

Re-search 

At this stage, we have a list of real compromised identities, which is a great first step and actionable in and of itself, but the exciting part is that we can use these identities themselves as an additional pivot point to find more attacks and other compromised credentials! We now basically repeat the same process described above, but while focusing on additional suspicious activity related to these compromised identities. In many cases, the same identities might have been compromised by multiple threat actors (perhaps they each found the same exposed credentials or purchased them from the same source on the dark web). The result of this query is once again API calls grouped by common IP metadata. 

At this point, we have a list of IP addresses associated with malicious activity (at least during the relevant timeframe) – the next step is to look for API parameter values that might uniquely identify specific actors. For example, let’s say we observe this suspicious group of API calls from an ASN in Indonesia: 

We can now review the logs to extract specific request parameters from these API calls and use these as actor-specific behavioral cloud IOCs to create more robust detections for this activity. Let’s demonstrate this method with two API calls: CreateCluster and ImportKeyPair. 

CreateCluster 

The CreateCluster API is part of AWS’s ECS service. Using a newly created Cluster, an attacker could spin up a large number of EC2 instances, most commonly used with the intention of mining cryptocurrency. 

When examining an API call in an effort to extract cloud IOCs, we look for request parameters that fulfil two main requirements: 

1. The parameter needs to be logged (in AWS this would usually mean CloudTrail logs). 

2. The parameters can contain unique user-controlled input. 

In the case of CreateCluster, a parameter we have found useful is clusterName. By default when creating a cluster it will be simply named default, but a custom cluster name can be sent as part of the API call. 

If our attackers are using some kind of script, we can assume that this name will be constant across instances, or at least generated in a predictable way. Returning to our example, we extracted all clusterName parameters from all failed or successful calls for CreateCluster from our set of malicious IP addresses and noticed that they shared the same name: bapak1. With this information in hand, we can now create a new hunting query that looks for all cases of attempted creation of clusters with the name bapak1, regardless of principal IP address. 

ImportKeyPair 

The same process can be done for the ImportKeyPair API call – we can check the attempted keyName which might be unique enough to serve as an IOC, or ideally even the publicKeyMaterial itself, which is very likely to be unique. In other words, if we observe the same public key across multiple environments, we can be quite sure that the exact same actor is involved in all cases. 

In this case, the attackers used multiple relatively unique key names (appek, appes, dfgfg) but the exact same publicKeyMaterial each time. Therefore, we created a query for all ImportKeyPair calls with the specific publicKeyMaterial, once again regardless of principal IP address. 

Just keep pivoting 

These queries give us strong indicators for this threat actor, at least until they decide to change the parameter values, and running them against our data leads us to discover even more compromised accounts! With the results, we can repeat the process described above and find even more attacks and even more potential IOCs… 

Strategies for using behavioral cloud IOCs 

Implementing behavioral indicators of compromise effectively within detection pipelines requires a combination of technical and procedural strategies. Here are some actionable steps organizations can take in order to do so: 

Monitoring and Analysis: 

1. Leverage runtime telemetry (such as IMDS call commands observed via runtime agents deployed on compute resources) and cloud activity logs for continuous monitoring and anomaly detection. 

2. Based on this telemetry, integrate behavioral IOC detection rules into a unified SIEM (Security Information and Event Management) or cloud-native security platform. 

3. Incorporate behavior-based queries and alerts into your incident response processes to ensure timely intervention. 

Threat Intelligence Collection: 

1. Collaborate with partners in the cloud security and threat intelligence communities to share and receive atomic and behavioral cloud IOCs, as well as insights on emerging malicious behaviors and effective detection methods to counter them. 

2. Leverage honeypots to simulate cloud environments and identify emerging behavioral IOCs. 

3. Engage in proactive threat hunting to search for patterns indicative of compromised credentials and other generic malicious behaviors. 

Regularly Update Behavioral Baselines: 

1. Establish and maintain baselines for normal user and system behavior, to more easily discern activity by threat actors attempting stealthy defense evasion techniques. 

2. Periodically refine these baselines to reflect any organizational or architectural changes. 

Training and Awareness: 

1. Educate security teams on the importance of recognizing behavioral cloud IOCs and incorporating them in threat detection and incident response systems. 

2. Brief your security teams on emerging attacker TTPs referenced in the latest threat reporting, and explain their associated generic behavioral IOCs (i.e., how these TTPs manifest in telemetry). 

How can Wiz help 

Wiz Defend has built-in detection rules incorporating both atomic and behavioral cloud IOCs, sourced from public threat reporting, private threat intelligence sharing, and threat intel collected by Wiz Research in the course of our own threat hunting and incident response engagements.  

Furthermore, using Wiz you can also define your own custom threat detection rules with your own atomic cloud IOCs. 

Summary 

Behavioral IOCs provide a nuanced lens for identifying threats in cloud environments by focusing on patterns rather than isolated events. Through strategic monitoring, automated detection, and threat intelligence sharing, organizations can utilize these indicators to uncover and mitigate attacks efficiently. 

We believe the case study of Bapak illustrates how behavioral IOCs, such as repeated API patterns correlated with geographical metadata, can link seemingly separate incidents to a single threat actor. By continuously refining detection methods, organizations can stay ahead of evolving threats in the dynamic cloud security landscape. 

For practical steps to help you optimize your logging configuration across all the categories in our readiness framework, from selecting the right log types to implementing cost-effective strategies to ensure you’re getting the most value out of the logs you gather, make sure to check out our full logging guide here. 

Appendix A – Indicators of Compromise (IOCs) 

Appendix B – Cloud-specific generic behavioral IOCs 

Container / VM images 

1. Use of images from untrusted or known bad sources. 

2. Use of images with embedded malware (such as cryptomining software). 

3. Use of images vulnerable to container escape vulnerabilities. 

4. Attempts to use unauthorized or unverified images when image allowlisting is in place. 

5. Use of images with hidden layers. 

6. Anomalies in image deployment patterns, such as sudden spikes in the usage of certain images in an organization, or use of rarely deployed images (which are more likely to be unvetted by security teams). 

Cloud subscriptions, user accounts, and service accounts 

1. High privileges granted to an unknown external subscription (note that this requires maintaining lists of known or trusted subscriptions). 

2. Assignment of highly privileged roles to a non-privileged user. 

3. Spikes in activity related to otherwise rarely observed subscriptions. 

4. Unusual login attempts from unexpected locations or IP addresses, such as: 

   1. Connections from TOR nodes (since these are less likely to be in normal use in corporate or production environments). 

   2. Connections from VPN providers not normally used in a particular environment. 

   3. Connections from addresses geolocated to areas from which connections are not normally observed in a particular environment. 

5. Unapproved changes to subscription settings, such as enabling new regions, changing security settings, or modifying user roles and permissions. 

6. User logins from unusual locations or at unusual times (relative to each specific user). 

7. Note that attackers can use tools like Quiet Riot or Pacu to automate the identification of IAM roles and users without alerting the target, as these activities are logged only in the attacker’s environment. 

Lambda layers  

1. Attempted use of unauthorized Lambda layers where layer allowlisting is in place. 

2. Unexpected changes in layer runtime environments. 

3. Unauthorized modifications to existing Lambda layers, which can introduce vulnerabilities or malicious functionality. 

Infrastructure-as-Code (IaC) 

1. Unauthorized or unexpected changes to existing IaC configurations. 

2. Terraform state files being accessed or modified unexpectedly. 

3. Use of IaC configurations that enable excessive permissions or disable logging.