Introduction 

Indicators of Compromise (IOCs) are the bread and butter of many a security program. The term refers to forensic artifacts or evidence suggesting an ongoing or past security breach within a computing system. These indicators are observable traces left behind by malicious activities, and serve as signals for security practitioners to detect, investigate, and respond to potential cybersecurity incidents within the organizations they are tasked with defending. Additionally, IOCs serve as threat intelligence building blocks for clustering sets of activity together and eventually attributing them to specific threat actors. 

Some types of IOCs are more or less universal, in the sense that they are relevant regardless of the type of target environment, such as IP addresses of attacker-controlled infrastructure, or hashes of malware binaries. However, defending against malicious activity in the cloud requires handling additional types of evidence that are unique to cloud environments, such as IAM metadata and control plane API calls. Additionally, other types of forensic artifacts – such as container image names and user agent strings – may not be entirely unique to the cloud, but they do hold unique value to investigating cloud incidents and tracking the activity of cloud-fluent threat actors.

Furthermore, as we shall demonstrate in this series of blogposts, when it comes to tracking truly cloud-native malicious activity, analysts must make use of both behavioral and atomic IOCs in order to summit the pyramid of pain. While atomic indicators are specific and static data points that indicate malicious activity (e.g., attacker-controlled domain names and malware file hashes), behavioral indicators relate to runtime telemetry and activity logs and are therefore utilized in more complex detections. 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). 

Being able to collect, analyze, and monitor for cloud-specific IOCs is a crucial capability for detecting and investigating incidents and conducting threat hunting in the cloud. However, in our experience, many threat intelligence reports don’t sufficiently highlight cloud-specific IOCs, and many threat intelligence vendors fail to include these IOCs in their feeds in a machine-readable format.

To illustrate why this is a problem, imagine a SOC analyst monitoring for alerts related to an AWS environment, when they observe a role being assumed from an external AWS account following an API call performed from an unknown IP address – while they can easily query for the address in threat intelligence feeds to determine its reputation, the same is not necessarily true of the AWS account; the SOC analyst is unlikely to have a method for determining the account's reputation based on threat intelligence. Similarly, the analyst will encounter the same challenge when triaging alerts related to containers being spun up using external images, new user accounts with suspicious-looking names, and other scenarios commonly occurring in cloud environments.

These shortcomings are why we’ve chosen to write this blogpost series – strategically, we believe mutual sharing and standardizing of IOCs uniquely relevant to cloud environments can enable a stronger cloud security community, making it easier for everyone to effectively monitor and block malicious cloud activity at scale. To help with this, we’ve collected publicly available atomic IOCs in a new GitHub repository – be sure to check it out! 

The cloud threat landscape 

The cloud introduces new types of external attack surface such as cloud service provider (CSP) and Kubernetes endpoints, as well as new modes of lateral movement such as IAM privilege escalation and SSM-facilitated remote desktop connections. Additionally, cloud environments allow for abuse of well-established attack vectors such as software vulnerability exploitation, but threat actors often repurpose these “classics” to take advantage of the cloud’s unique attributes in order to achieve slightly different goals. For example, cryptojacking is often the result of a threat actor merely exploiting a software vulnerability or misconfiguration, but while taking advantage of the cloud’s scalability to quickly spin up new resources. Similarly, IMDSv1 abuse often follows traditional SSRF exploitation, which for this reason is rightfully considered more impactful in cloud environments than on-premises. 

Mirroring these adaptations in attacker tradecraft, the utility of certain traditional IOCs is somewhat different in the cloud as well. For example, most IP addresses included in commercial and open-source threat intelligence feeds these days relate to C2 servers, which are unlikely to show up in cloud access logs, since threat actors usually rely on workstations or jump boxes with different IP addresses when connecting to CSP API endpoints. In fact, more often than not, threat actors targeting the cloud will simply use anonymization services such as VPNs or TOR. This behavior makes IP addresses far less useful for cloud threat detection unless they are cross-referenced with additional metadata. For instance, one can build a threat detection rule that checks for connections from a known VPN provider that isn’t commonly used by employees of the defended organization – this can be a very useful behavioral indicator. 

The rest of this blogpost will focus exclusively on atomic indicators relevant to cloud environments, and our next blogpost in this series will discuss behavioral indicators. 

Cloud-specific atomic IOCs 

Container / VM image metadata 

Containers and virtual machines in the cloud are launched using a source image. Cloud-fluent threat actors such as TeamTNT and SilentBob have been known to build their own images with pre-installed malware and use them to spin up new containers and VMs in compromised environments (T1610). In TeamTNT’s case, Trend Micro observed the actor using custom Docker images called alpineos and sandeep078 containing rootkits, container escape exploits, cryptominers, infostealers, and more. In SilentBob’s case, Aqua Security identified Docker images used for deploying malicious scanners. 

Similarly, at Wiz we recently identified a Dero cryptojacking campaign in which the threat actor created custom docker images named nohuppo:pause, dockerproxys:pause, and dockerproxys:pauser (among others), containing pre-installed cryptominers. 

When threat actors reuse the same image across multiple targets, the image itself – as identified by its name or digest – becomes a useful atomic IOC. Furthermore, multiple images might be linked to the same CSP Subscription or Docker Hub account, allowing analysts to pivot between images with the same author. 

Cloud defenders can maintain lists of known malicious container and VM images based on threat intelligence, and continuously leverage them for detection and prevention purposes. Additionally (as we’ll discuss in more detail in the next blogpost in this series), organizations should monitor for any usage of images rarely (or never before) used in their cloud environment, as these are more likely to be unsanctioned and therefore malicious (T1204). 

Cloud subscription metadata 

Cloud subscriptions, such as AWS Accounts, are accounts that allow the customer to spin up various cloud resources such as compute, storage, and identities. Threat actors can sign up for their own subscriptions or hijack existing ones (T1098, T1078.004), using them for malicious activities such as storing malicious VM images, or creating trust relationships between their subscription and target subscriptions (such as granting a principal in their own subscription privileges to perform administrative actions in the target subscription). 

For example, Invictus identified a threat actor dubbed DangerDev using AWS subscriptions under their control (671050157472 and 265857590823) in order to assume roles within a target subscription (T1136.003). In such cases, the unique identifiers of the subscription itself can serve as valuable atomic IOCs. 

Cloud defenders should maintain lists of trusted cloud subscriptions with which their environment is permitted to maintain trust relationships, while blocking any attempts to create such relationships with unknown subscriptions (or requiring administrative approval in order to do so). Additionally, defenders should maintain lists of known bad subscriptions and monitor for any historical or current activity in their environment that involves them. 

Infrastructure-as-Code (IaC) metadata 

Infrastructure-as-Code (IaC) is the management of infrastructure (networks, VMs, load balancers, etc.) using machine-readable scripts like Terraform, CloudFormation, or Ansible, allowing for automated and consistent deployment. However, when an organization deploys infrastructure using attacker-controlled IaC, this can lead to modifications that grant the attacker initial access to the environment or escalate their existing privileges (T1578). 

For instance, consider a scenario where an attacker gains access to a Terraform state file stored in an S3 bucket used by a target organization. As described in this article from Plerion, the attacker could modify the state file to manipulate infrastructure in the target environment, such as deleting critical resources or even introducing malicious Terraform providers that execute unauthorized code during deployment. Similarly, attackers can exploit Policy-as-Code engines—like those utilized in HashiCorp Sentinel or Open Policy Agent (OPA)—by altering policy code to leak sensitive credentials; attackers can inject code that exfiltrates secrets during provisioning, such as adding an HTTP request to steal AWS credentials. 

Alternatively, an attacker could use social engineering to convince a victim to utilize a specially crafted third-party Terraform module, which performs malicious actions such as leaking database passwords to a remote attacker-controlled server. For example, xssfox developed a proof-of-concept Terraform module (`ssm-password`) that demonstrated how an attacker could add an HTTP block to exfiltrate sensitive information during infrastructure deployment. This attack vector isn’t likely to be merely theoretical – Shelly Raban from Tenable recently showed that around 0.5% of public Terraform modules contain anomalous and therefore potentially risky blocks. 

As with cloud subscriptions, defenders should maintain lists of both trusted and untrusted IaC providers and modules, blocking any attempted unauthorized deployment of infrastructure in their environment. 

Cloud user metadata 

Once threat actors get their hands on cloud keys for a target cloud subscription or gain initial access to the environment (T1586.003), they can employ toolkits that automate numerous actions for enumeration, persistence, and privilege escalation (we’ll go into more detail on this topic in the next blogpost in this series). Some of these toolkits use hardcoded unique usernames when creating new users in a compromised org, and these can be leveraged as atomic IOCs for detection purposes. 

An example can be found in FBot, a Python-based hacking tool. FBot's feature to create a new AWS user account with administrative privileges (T1136), without removing the original compromised account (T1078), enables attackers to maintain long-term privileged access to the environment. This stealthy creation of a new user account can go unnoticed if not properly monitored, allowing attackers to perform further malicious activities in the compromised environment. According to research conducted by Sentinel One, users created by FBot are identifiable by their hardcoded username and password combination (iDevXploit:MCDonald2021D#1337, at the time of writing). 

Similarly, toolkits like AndroxGh0st, Legion, and GreenBot, which have been observed in use by threat actors abusing AWS Simple Email Service (SES), also include uniquely identifiable hardcoded usernames. According to Permiso, the AndroxGh0st persistence module was found to automate the creation of IAM users named ses_xcatze and AdminsDDefault, granting them high-level privileges and creating new administrator groups within the compromised AWS account. 

By inventorying cloud users in their environment and monitoring cloud logs for creation events of new cloud users, defenders can leverage pattern recognition to scan user metadata for any users matching known bad names sourced from threat intelligence, and thereby identify potentially malicious activity targeting their organization. However, note that unlike subscription IDs or container image IDs, usernames are not globally unique identifiers, which means that ingesting them as atomic IOCs can lead to false positive detections, especially if attackers (purposefully) use generic naming schemes – care must therefore be taken when triaging such detections. 

Credential metadata 

Another important behavioral IOC relates to cloud keys, such as AWS Access Keys. These are credentials used to authenticate API calls to AWS services and are tied to an IAM principal, either an IAM user or an IAM role. There are two primary types: long-lived keys associated with IAM users, which do not expire, and temporary keys typically issued to AWS services, which are valid for a limited time. 

Obtaining an existing cloud key (T1552) for an identity in a target cloud subscription allows an attacker to perform reconnaissance through enumeration (such as determining what permissions are assigned to the compromised identity). While compromised keys are unique to specific identities and therefore don’t provide useful atomic IOCs (since they’re only viable within a specific environment), threat actors can also create their own cloud keys (T1136.003) for persistence purposes (serving as backdoors to preserve future access to the environment), and sometimes use recurring naming schemes for their keys – these names can be indicative enough to serve as atomic IOCs. 

Similarly, threat actors can upload their own SSH keys (T1021.004) to compromised compute instances (or rely on cloud control plane mechanisms to insert keys into target machines). Much like cloud key names, SSH key names can sometimes uniquely identify a specific threat actor or tool. Moreover, some threat actors even reuse the same cryptographic material between different target environments, which can serve as an even stronger atomic indicator. 

In order to make the most of this threat intelligence, defenders should inventory secrets in their cloud environment and scan for any cloud events related to the creation of new credentials, while checking for instances matching known bad credentials or credential names. 

Other cloud resources 

Besides recurring naming schemes of cloud users and credentials, threat actors sometimes use consistent naming schemes for other types of resources as well. For example, once gaining access to a target AWS environment, Palo Alto Unit 42 has observed Bling Libra (AKA ShinyHunters) creating new S3 buckets with the naming scheme contact-shinycorp-tutanota-com-# (where # is a number). As described above, such patterns can be utilized to uniquely identify activities performed by the relevant threat actor (while taking into account the possibility of false positive detections when naming schemes are overly generic). 

Cloud-unique aspects of traditional atomic IOCs 

Sophisticated threat actors targeting cloud environments commonly “live off the land”, avoiding deployment of malware and limiting the scope of their activity to the cloud control plane. Such actors rely almost exclusively on compromising and creating identities in order to enumerate the environment, move laterally and escalate their privileges, while connecting to compute resources only when absolutely necessary. These actors rarely leave uniquely identifiable forensic traces on compute instances, making traditional IOCs less useful for tracking their activity. 

Conversely, less sophisticated actors often do employ malware in target cloud environments, in which case more traditional IOCs – such as domains, malware hashes, binary patterns, registry keys, process names, etc. – remain highly applicable to tracking their activity, alongside additional novel indicators such as cryptocurrency wallets (when cryptojacking is involved). 

However, these classic IOCs play a nearly identical role in the cloud as on-premises, so explaining their significance or how to leverage them for detection purposes goes beyond the scope of this blogpost. Instead, we’ll be focusing on aspects of traditional IOCs that are unique to cloud environments, and therefore must be taken into consideration by cloud defenders. 

User agents 

User agents provide crucial insights into the tools and methods used by attackers and can sometimes even uniquely identify a malicious actor or tool. For example, in a recent Microsoft Azure account takeover campaign (T1078), Proofpoint researchers observed a user agent string, Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/120.0.0.0 Safari/537.36, in use by the threat actor when connecting to Microsoft 365 applications in the target environment. Once identified, although not globally unique, monitoring for similar activity with the same user agent served to identify additional attacks against other victims. 

Similarly, in an incident involving Bling Libra, Unit 42 investigators found that the attackers used specific tools such as S3 Browser and WinSCP to interact with target S3 buckets, perform reconnaissance, and delete data (T1485). By analyzing AWS CloudTrail logs in victim environments, they were able to track the user-agent strings associated with these tools, including S3 Browser/<Version> (https://s3browser[.]com) and WinSCP/<version> (where <version> is the tool version) to identify when they were used. 

User agents can be tracked through cloud logs, which should be monitored for the appearance of known bad user agents associated with malicious actors or tools. 

IP addresses 

Typically, attackers use IP addresses to remotely scan and exploit weaknesses (T1588.006) on target systems, communicate with compromised machines, and exfiltrate data (TA0010) from them. In the cloud, attackers also use IP addresses to make control plane API calls, though in our experience they rarely use the same IP addresses as they do for the other abovementioned activities, usually preferring to either employ a VPN or use a dedicated IP address for this purpose. 

Regardless, monitoring for cloud activity originating from known bad IP addresses uniquely associated with specific threat actors during specific timeframes (as IP addresses change hands rather frequently) can be a cost-effective method of detecting and preventing malicious activity by less OpSec-savvy actors. For example, Datadog researchers identified an unknown threat actor using the IP address 134.209.127[.]249 to make API calls against target cloud environments, and also observed this actor serving phishing landing pages on the same address. This means that if someone were investigating this particular threat actor and was initially only familiar with the phishing activity, it would certainly have been worthwhile to monitor cloud logs for API calls originating from the associated IP address. 

In the next blogpost in this series, which will focus on behavioral indicators, we’ll discuss moving beyond atomic indicators such as known bad IP addresses, and using anomaly detection to identify suspicious API calls, such as those made through a VPN provider rarely used in the target cloud environment. 

Strategies for using atomic cloud IOCs 

The value of cyber threat intelligence products is determined by how well they’re put to use by defenders, and atomic cloud IOCs are no exception – when combined with inventorying and cloud log monitoring capabilities, they can serve as valuable artifacts for detection and prevention of previously encountered threats. Our recommended approach for making the most of atomic cloud IOCs to defend your cloud environment is to implement a detection mechanism that utilizes them: 

1. Develop automated systems to collect atomic IOCs from commercial threat intelligence feeds to which you have access, as well as open-source reporting. 

2. Develop systems to automate production of inventory reports of your cloud environment and systems to monitor cloud logs using custom detection rules. To facilitate this, you can use cloud native tools, commercial solutions like Wiz, or various open-source tools such as Sigma or CloudGrappler. 

3. Build detection rules that check for actions and resources matching atomic IOCs sourced from your threat intelligence corpus. 

4. Ideally, integrate your threat intelligence feeds with your detection rule database in order to automatically update rules to include the latest emerging IOCs. 

5. If an alert triggers in your environment, you should triage it by reviewing the details of the events and resources involved and comparing them with your knowledge of the relevant past threat activity. If you determine the alert to be a true positive, you should initiate incident response procedures. 

How can Wiz help 

Wiz regularly integrates atomic IOCs like those listed above into our threat detection capabilities, sourced from numerous threat intelligence sources and partnerships as well as our own threat research: 

1. Wiz CDR alerts you to API calls or connections (logged in flow logs or cloud logs) that originated in malicious IP addresses or using known bad user agents. 

2. Wiz Sensor allows you to continuously monitor for any incoming or outgoing communication between compute instances and malicious IP addresses and domains, and also alerts you to processes matching various atomic IOCs. 

3. Wiz detects deployments of malicious container and VM images and enables customers to identify user accounts with known bad names as well as activity related to attacker-controlled subscriptions. 

4. Wiz leverages file hashes and YARA rules to detect malware via our agentless malware scanner. 

5. Wiz Research frequently updates the Threat Center to assist our customers in responding to emerging threats while leveraging all of the abovementioned detection capabilities. 

Beyond atomic IOCs, our detection capabilities also incorporate behavioral IOCs – be sure to check out our next blogpost to learn more. All of this enables our customers to proactively identify ongoing attacks against their cloud environments and respond to them in time. 

Summary 

As cloud environments become increasingly targeted by attackers, it's essential to ensure that cloud-specific IOCs are properly recognized and utilized. In our experience, threat intelligence reports often overlook these IOCs or fail to include them in standard machine-readable feeds, making it harder for cloud security teams to act upon them effectively. If you produce or consume such reports (which we definitely recommend), we hope this blogpost has underscored the importance of highlighting cloud IOCs, and that you will prioritize them in your future work. 

To help cloud defenders make the most of cloud IOCs, we’ve collected all the publicly known atomic IOCs mentioned in this blogpost in a new GitHub repository – we’ll be expanding its coverage to include both historical indicators we may have missed as well as any indicators appearing in future publications, and we invite you to contribute. 

Tune in for our next blogpost in this series on cloud IOCs, which will cover behavioral indicators and how to leverage them for threat detection and hunting in cloud environments. 

Appendix – Cloud IOCs cheat sheet 

References

• Wiz Research Public IOC Database

• Wiz Threat Landscape

• The Pyramid of Pain

• Cloudy with a chance of IoCs

• TrendMicro's blog on TeamTNT

• Aqua's SilentBob blog

• Wiz's Dero campaign blog

• Invictus DangerDev blog

• Plerion hacking Terrraform blog

• Supply chain as code blog

• Shelly Raban's fwd:cloudsec presentation

• Juniper's Androxgh0st blog

• Proofpoint's Azure account takeover campaign blog

• Unit42's BlingLibra blog

• Permiso's Androxgh0st blog

• SentinelOne's FBot blog

• DataDog's AWS SNS phishing blog