Blank Space: Filling the Gaps in Atomic and Composite Detection

Blank Space: Filling the Gaps in Atomic and Composite Detection

Speakers: Merav Bar & Gili Tikochinski

Conference: BSidesSF 2025 — April 26-27, 2025, San Francisco

YouTube: Watch the full talk

Reading time: ~7 minutes

TL;DR

Threat intelligence for cloud environments is systematically incomplete — the industry reports IPs, hashes, and domains while leaving cloud-specific indicators of compromise undocumented and unshared. Wiz researchers Merav Bar and Gili Tikochinski make the case for a new category of cloud IoCs, both atomic and behavioral, and demonstrate with a live attacker group called "Bapak" how this approach catches threats that traditional intelligence misses.

Introduction

When a major malware campaign hits cloud infrastructure, the resulting threat report almost always looks the same: a list of IP addresses, domain names, and file hashes. For defenders operating in AWS, Azure, or GCP environments, this is increasingly not enough. The techniques used in cloud attacks — IAM privilege escalation, SSM-facilitated remote desktop, SSRF against instance metadata services — leave artifacts that IPs and hashes cannot capture. Yet the reporting infrastructure for those artifacts barely exists.

Merav Bar and Gili Tikochinski, both threat researchers at Wiz, presented at BSidesSF 2025 to address this gap directly. Drawing on campaigns including Legion, AndroGhost, JavaGhost, and GreenBot, they argued that all of these attacks had unique, detectable cloud-specific indicators that would have enabled faster and more accurate detection — if the industry had a framework for identifying and sharing them. Their talk introduces both atomic and behavioral cloud IoCs, demonstrates their research methodology, and calls on the community to begin treating cloud indicators as first-class intelligence artifacts.

▶ Watch: The cloud threat landscape and what makes it different (02:00)

Why Traditional IoCs Fall Short in the Cloud

The three classic atomic indicators — IPs, domains, and hashes — face structural limitations against modern cloud attacks. Attackers evade IP-based detection using VPNs, Tor, or other cloud providers as jump boxes. Malware hashes are trivially rotated. Domains can be swapped out quickly. These techniques are well understood by threat actors, which is why sophisticated cloud attackers use them as a matter of routine.

More significantly, cloud environments introduce entirely new attack techniques that simply have no corresponding traditional indicator. IAM privilege escalation does not produce a hash. An SSM-facilitated lateral movement does not leave a domain record. An SSRF attack against an EC2 instance metadata service produces CloudTrail API call logs, not network traffic artifacts.

▶ Watch: Traditional atomic IoCs and why they are not enough (02:00)

A representative failure mode: the threat report for AndroGhost — a well-documented, cloud-targeting attacker — contains no mention of cloud-related IoCs. The researchers found that the report covered the group's activities without documenting any of the cloud-specific artifacts those activities left behind. Defenders reading that report and operating in cloud environments would have no actionable detection signals from it.

Cloud Atomic IoCs: The Missing Layer

Bar and Tikochinski identify several categories of cloud-specific atomic indicators that current reporting consistently overlooks.

VM and container image metadata. Attackers like TeamTNT and SilentBob deploy malicious Docker images with consistent naming schemes that can serve as high-confidence identification signals. The Dero cryptojacking campaign used a Docker image named nohopus/pause containing a cryptominer; that image was pulled over 10,000 times and could have been flagged through registry monitoring or comparison against threat intelligence feeds.

Cloud subscription metadata. Groups like FBOT used specific AWS account IDs to assume roles in victim environments. The Forward CloudStack "known AWS accounts" repository is one tool for maintaining baselines of legitimate subscriptions, enabling detection of anomalous cross-account access.

Infrastructure-as-code. A statistic the researchers highlight: 0.5% of public Terraform modules contain anomalous, risky blocks. That figure sounds small, but given the volume of public modules in use, it represents a significant exposure. Detecting malicious CloudFormation StackSets and unauthorized IaC deployments requires maintaining trusted and untrusted provider baselines.

Cloud user metadata. Hard-coded usernames in attacker scripts are among the most actionable atomic indicators in cloud environments. FBOT created users named idev_exploits; AndroGhost used SESXkaty and adminsvdefault. Because these names are hard-coded in attacker tooling, every victim environment exposed to FBOT had exactly the same username — making the indicator trivially detectable and attributable.

SSH keys. Attackers reuse SSH key material across victims, likely for operational convenience. A single cryptographic fingerprint tied to a malicious actor can serve as a definitive attribution signal. Tracking managed keys via CSP-provided logs is feasible; SSH keys existing only on compute require disk scanning or a runtime agent, but the value is high.

▶ Watch: Cloud atomic IoC categories (04:00)

Behavioral IoCs: Patterns, Not Just Points

Beyond static indicators, Bar and Tikochinski introduce behavioral IoCs — a category that captures not what an attacker used, but how they acted within a target environment. This distinction matters because it enables detection of attack patterns even when all atomic indicators are novel or absent.

The researchers define four types of behavioral indicator: plain actions (a single API call like GetCallerIdentity); actions with specific parameters (e.g., CreateUser with the username adminsvdefault); series of actions where timing or order suggests scripted behavior; and contextualized actions (an action performed from a Tor IP in an environment where that would never normally occur).

▶ Watch: Behavioral IoCs: four types and two categories (12:00)

These combine into a layered model. Individual API calls → recognizable actions → sequences indicating specific techniques like privilege escalation. By tracking logs as sequences rather than isolated events, defenders can connect dots across an attack path and build detection rules at the technique level rather than the event level. This framing echoes MITRE ATT&CK but is specifically calibrated to cloud API call semantics.

Case Study: Tracking the Bapak Attacker

The talk's most concrete section covers the researchers' investigation of an attacker group they named "Bapak" — named after the attacker's characteristic API call to CreateCluster with that cluster name, used to spin up cryptomining infrastructure.

Using Wiz's proprietary cloud honeypot, the team leaks credentials into public sources and monitors how attackers acquire and use them. They analyze API call sequences and attacker IP metadata, then pivot from honeypot environments to real cloud environments by searching for matching IPs and API calls in narrow time windows.

▶ Watch: Bapak case study methodology (16:01)

Bapak's atomic IoCs were striking: every target environment received an ImportKeyPair call with one of three key names — APEC, APES, or DFGFG — and the exact same public key material, providing a unique cryptographic fingerprint confirming attribution across all incidents. Their behavioral IoC pattern was equally consistent: every environment saw the same reconnaissance sequence — GetCallerIdentity, DescribeSubnets, DescribeInstances — in that exact order within a short timeframe, followed by the persistence technique of importing the key pair and creating the named cluster.

The researchers also discovered a novel technique for uncovering unknown threat groups: leaked credentials tend to be reused by multiple actors. By grouping activity clusters from honeypot data by API call patterns and IP geolocation, they identified distinct sub-groups using the same credentials — including a cluster of IPs from Vietnam making AI-related API calls like InvokeModel and GetCostAndUsage, suggesting credential theft for AI service abuse.

The Call to Action: Build the Cloud IoC Database

Bar and Tikochinski close with a clear diagnosis and a direct ask. Cloud IoCs are systematically left out of published threat reports — not because researchers don't have them, but because there is no established standard for reporting them. The community has VirusTotal for file hashes; there is no equivalent for cloud behavioral patterns.

▶ Watch: The gap: defenders flying blind (20:01)

The researchers maintain a public GitHub repository — WizResearchIoCs — as a starting point for a community-sourced cloud IoC database, and they are actively soliciting contributions. On the standards side, they advocate for extending STIX to include cloud IoC types, which would allow cloud indicators to integrate directly into existing security tooling that already knows how to consume that format.

Notable Quotes

"Defenders are essentially flying blind, even though the data exists. These attacks are happening, we see these patterns, and yet we are not really sharing them in a centralized place." — ▶ 20:01

"You can't expect someone to develop a very complicated tool that knows how to extract logs and match IoCs if you have no behavioral IoCs existing out there." — ▶ 28:02

"Anyone could have looked for environments, seen those IoCs, and caught the attacker in their environments quickly and very accurately." — ▶ 22:01

Key Takeaways

• Traditional IoCs (IPs, domains, hashes) are insufficient for cloud threat detection. Cloud attacks produce cloud-native artifacts that these indicators cannot capture.
• Cloud atomic IoCs — container image names, AWS account IDs, hard-coded usernames, SSH key material, IaC module fingerprints — are consistently omitted from published threat reports despite being highly detectable.
• Behavioral IoCs are distinct from TTPs. Sequences of API calls in specific orders and timing windows represent a new, detectable signal class that operates at a different layer than MITRE ATT&CK techniques.
• Attacker laziness is exploitable. Hard-coded usernames, reused SSH keys, and repeated API call sequences allow attribution across victims and incidents — if the community is collecting and sharing these signals.
• Contribute to the WizResearchIoCs repository and advocate for STIX extension to include cloud indicator types, so the tooling ecosystem can begin consuming cloud-native intelligence at scale.