Cloud Workload Runtime and Exploitation Behavior
An adversary has exploited a public-facing containerized application and is maintaining persistence through binary drift or suspicious shell execution within the workload runtime.
Based on research by Microsoft 2026-09-20 12 steps · 3 queries T1059 T1190 T1542
Brief
Why now
Recent industry evaluations, such as the report where Microsoft named a Leader in the Frost Radar™: Cloud Workload Protection Platforms, 2026 (https://www.microsoft.com/en-us/security/blog/2026/08/19/microsoft-named-a-leader-in-the-frost-radar-cloud-workload-protection-platforms-2026/), underscore the maturing state of cloud security. While posture management identifies misconfigurations, adversaries still find gaps in public-facing applications. We developed this hunt to bridge the gap between static image risk and active runtime exploitation.
How the hunt flows
The first query identifies risk by scanning Databricks compute clusters. The query searches for images using generic or development tags like "latest", "dev", or "test". These tags often bypass strict version control and may contain unpatched vulnerabilities. An analyst reviews these results to determine which clusters represent production workloads that warrant deeper inspection.
If the analyst identifies high-risk clusters, the hunt proceeds to a parallel execution phase. This phase targets two distinct behaviors: suspicious shell launches and rare binary drift. The process query looks for interactive shells, such as /bin/sh or /bin/bash, where the parent process is a common web runtime like Java, Python, or Node.js. This pattern is a high-fidelity indicator of remote code execution (RCE).
Simultaneously, the file activity query searches for "binary drift." It baselines writes to protected directories like /bin/, /usr/bin/, and /etc/ across the scoped hosts. The hunt filters for activity occurring on only one or two hosts in the fleet. Widespread changes usually indicate legitimate updates, whereas isolated modifications suggest an adversary has manually altered system files to establish persistence.
In the final phase, an analyst or automated agent synthesizes the results. They correlate the presence of a high-risk image with any observed runtime anomalies to provide a verdict. If the activity is malicious, the playbook provides instructions to isolate the host while preserving the container state for forensics.
What the hunt cannot see
This hunt has two primary blind spots. First, the scoping step is currently limited to Databricks environments. If an adversary exploits a workload in a different service like EKS or GKE using the same high-risk images, this hunt will not see it. Second, the file activity surface relies on changes being flushed to the host disk. If an adversary modifies files in a memory-backed overlay or a temporary layer that osquery cannot observe, the drift remains invisible.
In this series
Steps
-
Identify high-risk container images
Query · scopingFind clusters running images with tags that bypass version control, representing a high risk for unpatched vulnerabilities.
reads databricks_compute_clustersqlSELECT cluster_name, docker_image, creator_user_name, cluster_id FROM databricks_compute_cluster WHERE docker_image IS NOT NULL AND docker_image LIKE '%:%' AND instr(',' || '{{vulnerable_tags}}' || ',', ',' || REPLACE(LOWER(docker_image), SUBSTR(LOWER(docker_image), 1, INSTR(LOWER(docker_image), ':')), '') || ',') > 0What a hit looks like. A list of clusters using non-versioned image tags. Silence suggests all production workloads use pinned, versioned tags.
-
Evaluate Scoping Risk
Agent triageDecide if any found clusters warrant a deep runtime hunt and provide the hostname scope for the analyst.
-
Lead Gate
DecisionTerminate the hunt early if no risky images are found, avoiding expensive telemetry queries.
-
Suspicious Shell Launches
Query · detection candidateDetect interactive shells spawned by web applications, a primary indicator of successful RCE.
reads hb_process_activitysqlSELECT device_hostname, process_name, process_cmd_line, parent_process_name, time FROM hb_process_activity WHERE ('{{scope_hosts}}' = '' OR instr(',' || '{{scope_hosts}}' || ',', ',' || device_hostname || ',') > 0) AND (on_disk = 0 OR (LOWER(process_name) LIKE '%sh' AND (LOWER(parent_process_name) LIKE '%java%' OR LOWER(parent_process_name) LIKE '%python%' OR LOWER(parent_process_name) LIKE '%node%' OR LOWER(parent_process_name) LIKE '%php%'))) AND time >= datetime('now', '-{{lookback_days}} days')What a hit looks like. A shell process whose parent is a web-facing service. Silence confirms no common RCE patterns are active.
-
Rare Binary Drift in Containers
Query · baselineIdentify unauthorized changes to system binaries on a small number of hosts, suggesting persistence.
reads hb_file_activitysqlSELECT LOWER(file_path) AS path, COUNT(DISTINCT device_hostname) AS host_count, MIN(time) AS first_seen FROM hb_file_activity WHERE ('{{scope_hosts}}' = '' OR instr(',' || '{{scope_hosts}}' || ',', ',' || device_hostname || ',') > 0) AND activity_id IN (1, 3, 5) AND (LOWER(file_path) LIKE '/bin/%' OR LOWER(file_path) LIKE '/usr/bin/%' OR LOWER(file_path) LIKE '/etc/%') AND time >= datetime('now', '-{{lookback_days}} days') GROUP BY path HAVING host_count <= 2 ORDER BY host_count ASCWhat a hit looks like. File writes to protected system paths occurring on only one or two hosts. Fleet-wide writes are likely updates and ignored.
-
Runtime Triage
Agent triageSynthesize initial image risk with observed behavioral anomalies to provide a final verdict.
-
Final Routing
DecisionRoute malicious findings to containment actions or suspicious findings to manual review.
-
Isolate Workload
Response actionContain the potentially compromised container node while preserving its state for forensics.
-
Analyst Final Review
Analyst taskReview findings, confirm drift, and coordinate with the development team for a clean redeployment.
-
Close Out (No Findings)
Analyst taskRecord the hunt execution over the risk-based scope with a negative result.
-
Close Out Hunt
Analyst taskFinalize the hunt record and document lessons learned.
Coverage
Scenario coverage
| Stage | Covered | How, or why not |
|---|---|---|
| Exploit Public-Facing Application T1190 |
Yes | identify-high-risk-images, evaluate-scoping-risk |
| Malicious Process Execution in Containers T1059 |
Yes | suspicious-shell-launches |
| Container Binary Drift T1542 |
Yes | rare-binary-drift |
| Abuse of Over-Permissioned Identities T1078 |
Out of scope | Belongs to another part of the 'Microsoft named a Leader in the Frost Radar™: Cloud Workload Protection Platforms, 2026' series. |
| Outbound Command and Control T1071 |
Out of scope | Belongs to another part of the 'Microsoft named a Leader in the Frost Radar™: Cloud Workload Protection Platforms, 2026' series. |
Blind spots
- Needs Unified cloud inventory across AWS, Azure, and GCP. The scoping step is limited to Databricks; other container environments like EKS or GKE are not evaluated for the same risk in this hunt. It would answer Are there other unmanaged workloads outside of Databricks running these images?.
- Needs hb_file_activity with container layer awareness. If an adversary modifies files in a memory-backed overlay that is not flushed to the host disk, the file activity surface may not capture the drift. It would answer Are modifications occurring in temporary file layers that osquery cannot observe?.
Parameters & data
Parameters
| Parameter | Type | Default | What it is |
|---|---|---|---|
lookback_days | number | 14 | Days of history to examine for runtime behavior. |
scope_hosts | list[host] | — | Hostnames extracted from the scoping step to focus the runtime queries. |
vulnerable_tags | list[string] | latest, dev, test, old | Image tags suspected of representing unversioned or high-risk development builds. |
Telemetry
| Source | Category | Telemetry |
|---|---|---|
| Endpoint telemetry (hb_ surfaces) | endpoint | endpoint |
Source
---
analysis: A single detection rule would struggle with the noise of legitimate software
updates and shell usage. This hunt uses a risk-based lead to gate expensive queries,
applies prevalence counting across the fleet to isolate rare drift, and uses an
agent to correlate image risk with runtime behavior across three different telemetry
surfaces.
blind_spots:
- id: limited-inventory-visibility
question: Are there other unmanaged workloads outside of Databricks running these
images?
requires: Unified cloud inventory across AWS, Azure, and GCP
risk: The scoping step is limited to Databricks; other container environments like
EKS or GKE are not evaluated for the same risk in this hunt.
stage: initial-access-exploit
- id: container-drift-blindness
question: Are modifications occurring in temporary file layers that osquery cannot
observe?
requires: hb_file_activity with container layer awareness
risk: If an adversary modifies files in a memory-backed overlay that is not flushed
to the host disk, the file activity surface may not capture the drift.
stage: persistence-through-drift
coverage:
- stage: initial-access-exploit
status: covered
steps:
- identify-high-risk-images
- evaluate-scoping-risk
- stage: runtime-container-execution
status: covered
steps:
- suspicious-shell-launches
- stage: persistence-through-drift
status: covered
steps:
- rare-binary-drift
- reason: "Belongs to another part of the 'Microsoft named a Leader in the Frost Radar\u2122\
: Cloud Workload Protection Platforms, 2026' series."
stage: over-permissioned-identity-access
status: out_of_scope
- reason: "Belongs to another part of the 'Microsoft named a Leader in the Frost Radar\u2122\
: Cloud Workload Protection Platforms, 2026' series."
stage: outbound-command-and-control
status: out_of_scope
guardrails:
claims: no_unsupported
evidence: citation_required
missing_data: not_benign
telemetry: untrusted
hunt:
applicability: campaign-specific
handoff: promote-to-detection
justification: Modern cloud workloads are high-value targets where posture scanning
is insufficient. Identifying exploitation at runtime through shell activity and
binary drift is critical for stopping compromises that bypass initial deployment
gates.
methodology: model-assisted
trigger: intel-report
hypothesis: An adversary has exploited a public-facing containerized application and
is maintaining persistence through binary drift or suspicious shell execution within
the workload runtime.
labels:
- hunt
- attack.t1190
- attack.t1059
- attack.t1542
name: Cloud Workload Runtime and Exploitation Behavior
parameters:
lookback_days:
default: '14'
description: Days of history to examine for runtime behavior.
from:
kind: manual
observed: '2026-08-19'
ref: hunt-standard
type: number
scope_hosts:
default: []
description: Hostnames extracted from the scoping step to focus the runtime queries.
from:
kind: manual
observed: '2026-08-19'
ref: analyst-scoping
type: list[host]
vulnerable_tags:
default:
- latest
- dev
- test
- old
description: Image tags suspected of representing unversioned or high-risk development
builds.
from:
kind: article
observed: '2026-08-19'
ref: frost-radar-2026
type: list[string]
provenance:
authors:
- name: Huntbase hunt generation
org: huntbase.io
generated:
by: huntbase-hunt-generation
from: https://www.microsoft.com/en-us/security/blog/2026/08/19/microsoft-named-a-leader-in-the-frost-radar-cloud-workload-protection-platforms-2026/
gates:
- dry-run
- lint
model: hb_google/gemini-3-flash-preview
rationale: Start with Databricks compute clusters running containers with non-specific
tags. These clusters represent the highest risk for unpatched, public-facing vulnerabilities.
references:
- name: 'Microsoft named a Leader in the Frost Radar: Cloud Workload Protection Platforms,
2026'
url: https://www.microsoft.com/en-us/security/blog/2026/08/19/microsoft-named-a-leader-in-the-frost-radar-cloud-workload-protection-platforms-2026/
related:
- hunt: over-permissioned-identity-access
reason: That hunt focuses on the misuse of cloud identities after the workload has
already been compromised.
relation: out-of-scope-alternative
scenario:
stages:
- name: Exploit Public-Facing Application
observables:
- Incoming HTTP requests to vulnerable web applications
- Presence of known vulnerabilities on internet-exposed assets
- Misconfigured cloud infrastructure services
slug: initial-access-exploit
tactic: initial-access
techniques:
- T1190
- name: Malicious Process Execution in Containers
observables:
- Suspicious process launches in Kubernetes pods
- eBPF-detected anomalous runtime events
- Interactive shell execution within running containers
slug: runtime-container-execution
tactic: execution
techniques:
- T1059
- name: Container Binary Drift
observables:
- Unauthorized binary changes mid-run (drift)
- Modifications to files within running container layers
- Unexpected process activity from modified binaries
slug: persistence-through-drift
tactic: defense-evasion
techniques:
- T1542
- name: Abuse of Over-Permissioned Identities
observables:
- Authentication using high-privilege service accounts
- Anomalous sign-ins to cloud control planes (Azure, AWS, GCP)
- Identity-linked access to Kubernetes API and resources
slug: over-permissioned-identity-access
tactic: credential-access
techniques:
- T1078
- name: Outbound Command and Control
observables:
- DNS queries from Kubernetes pods to external domains
- Outbound network connections to suspicious IP addresses
- High-volume data transfer from container workloads
slug: outbound-command-and-control
tactic: command-and-control
techniques:
- T1071
summary: This campaign involves the exploitation of public-facing applications to
gain initial access to cloud workloads, particularly Kubernetes environments.
Once inside, attackers execute malicious processes, leverage over-permissioned
identities, and establish persistence through binary drift and outbound command-and-control
traffic.
series:
index: 1
slug: microsoft-named-a-leader-in-the-frost-radar-cloud-workload-protection-platforms-2026
title: "Microsoft named a Leader in the Frost Radar\u2122: Cloud Workload Protection\
\ Platforms, 2026"
total: 2
severity: medium
targets:
analyst:
name: Tier-2 analyst
role: analyst
databricks:
category: siem
huntbase:
product: databricks
name: databricks
endpoint:
category: endpoint
name: Endpoint telemetry (hb_ surfaces)
telemetry:
- endpoint
hunter:
agent: true
name: Hunt agent
tlp: clear
type: investigation
---
# Cloud Workload Runtime and Exploitation Behavior
This hunt targets the exploitation of public-facing cloud workloads by correlating high-risk container images with suspicious runtime behavior. It starts with a scoping query of Databricks clusters running images with generic or development tags, then gates deeper analysis on identified risks. The hunt subsequently fans out to find interactive shells spawned by web processes and rare file modifications within the container file system, providing a unified view of exploitation and drift.
## identify-high-risk-images
<!-- Identify high-risk container images -->
Find clusters running images with tags that bypass version control, representing a high risk for unpatched vulnerabilities.
```sqlite target=databricks role=scoping params=(vulnerable_tags=vulnerable_tags)
~~~yaml
expected: A list of clusters using non-versioned image tags. Silence suggests all
production workloads use pinned, versioned tags.
reads:
- cluster_name
- docker_image
- creator_user_name
- cluster_id
silence: not_evidence_of_absence
source: databricks_compute_cluster
verified: dry-run
verified_at: '2026-09-20'
~~~
SELECT cluster_name, docker_image, creator_user_name, cluster_id FROM databricks_compute_cluster WHERE docker_image IS NOT NULL AND docker_image LIKE '%:%' AND instr(',' || '{{vulnerable_tags}}' || ',', ',' || REPLACE(LOWER(docker_image), SUBSTR(LOWER(docker_image), 1, INSTR(LOWER(docker_image), ':')), '') || ',') > 0
```
## evaluate-scoping-risk
<!-- Evaluate Scoping Risk -->
```agent target=hunter
cite: required
context:
- identify-high-risk-images
max_iterations: 3
objective: Review the images identified and determine if they represent production
workloads. If high-risk clusters exist, provide the mapped device hostnames to be
used for the scope_hosts parameter in the next phase.
success_criteria: A verdict naming high-risk hostnames to be scoped.
tools:
- databricks
- endpoint
```
## lead-gate
<!-- Lead Gate -->
if~: "The evaluate-scoping-risk verdict identifies at least one high-risk cluster hostname." (confidence: high, judge=hunter)
then: → runtime-fan-out
indeterminate: → close-out-negative
unavailable: → close-out-negative (blind_spot: limited-inventory-visibility)
else: → close-out-negative
## runtime-fan-out
<!-- Runtime Evidence Gathering -->
parallel:
- → suspicious-shell-launches
- → rare-binary-drift
join: → runtime-triage
## suspicious-shell-launches
<!-- Suspicious Shell Launches -->
Detect interactive shells spawned by web applications, a primary indicator of successful RCE.
```sqlite target=endpoint role=detection-candidate params=(scope_hosts=scope_hosts, lookback_days=lookback_days)
~~~yaml
expected: A shell process whose parent is a web-facing service. Silence confirms no
common RCE patterns are active.
reads:
- device_hostname
- process_name
- process_cmd_line
- parent_process_name
- time
- on_disk
silence: evidence_of_absence
source: hb_process_activity
verified: dry-run
verified_at: '2026-09-20'
~~~
SELECT device_hostname, process_name, process_cmd_line, parent_process_name, time FROM hb_process_activity WHERE ('{{scope_hosts}}' = '' OR instr(',' || '{{scope_hosts}}' || ',', ',' || device_hostname || ',') > 0) AND (on_disk = 0 OR (LOWER(process_name) LIKE '%sh' AND (LOWER(parent_process_name) LIKE '%java%' OR LOWER(parent_process_name) LIKE '%python%' OR LOWER(parent_process_name) LIKE '%node%' OR LOWER(parent_process_name) LIKE '%php%'))) AND time >= datetime('now', '-{{lookback_days}} days')
```
## rare-binary-drift
<!-- Rare Binary Drift in Containers -->
Identify unauthorized changes to system binaries on a small number of hosts, suggesting persistence.
```sqlite target=endpoint role=baseline params=(scope_hosts=scope_hosts, lookback_days=lookback_days)
~~~yaml
baseline:
compare: first_seen
window: '{{lookback_days}}d'
expected: File writes to protected system paths occurring on only one or two hosts.
Fleet-wide writes are likely updates and ignored.
prevalence:
by: device_hostname
key:
- file_path
rare_below: 3
reads:
- file_path
- device_hostname
- activity_id
- time
silence: not_evidence_of_absence
source: hb_file_activity
verified: dry-run
verified_at: '2026-09-20'
~~~
SELECT LOWER(file_path) AS path, COUNT(DISTINCT device_hostname) AS host_count, MIN(time) AS first_seen FROM hb_file_activity WHERE ('{{scope_hosts}}' = '' OR instr(',' || '{{scope_hosts}}' || ',', ',' || device_hostname || ',') > 0) AND activity_id IN (1, 3, 5) AND (LOWER(file_path) LIKE '/bin/%' OR LOWER(file_path) LIKE '/usr/bin/%' OR LOWER(file_path) LIKE '/etc/%') AND time >= datetime('now', '-{{lookback_days}} days') GROUP BY path HAVING host_count <= 2 ORDER BY host_count ASC
```
## runtime-triage
<!-- Runtime Triage -->
```agent target=hunter
cite: required
context:
- evaluate-scoping-risk
- suspicious-shell-launches
- rare-binary-drift
max_iterations: 5
objective: Determine if the combination of a high-risk container image, a suspicious
shell launch, and rare binary drift indicates a successful compromise. Citing specific
hosts and processes is required.
success_criteria: A verdict of malicious | suspicious | benign per host.
tools:
- databricks
- endpoint
```
## final-routing
<!-- Final Routing -->
if~: "The runtime-triage verdict is malicious for at least one host." (confidence: high, judge=hunter)
then: → isolate-workload
indeterminate: → analyst-final-review
unavailable: → analyst-final-review (blind_spot: container-drift-blindness)
else: → analyst-final-review
## isolate-workload
<!-- Isolate Workload -->
```action target=endpoint
~~~yaml
approval: required
~~~
Isolate the compromised host node using the EDR control plane. Do not terminate running pods until a memory dump of the suspicious process is captured.
```
→ analyst-final-review
## analyst-final-review
<!-- Analyst Final Review -->
```manual target=analyst
Examine the rare file writes and shell execution context. Verify if the activity corresponds to known maintenance. Coordinate with the cluster owner to redeploy using a hardened, versioned Docker image.
```
→ close-out-hunt
## close-out-negative
<!-- Close Out (No Findings) -->
```manual target=analyst
Record that the current cluster inventory uses versioned images or that no high-risk tags were found. File a recommendation to enforce image pinning at the policy level.
```
→ end
## close-out-hunt
<!-- Close Out Hunt -->
```manual target=analyst
Update the security policy based on findings. If binary drift was confirmed, work with the platform team to enable immutable infrastructure controls.
```
→ end
Run it
Take this hunt into your environment.
Open it in Huntbase to run every step against your own connections, with Scout weighing the evidence and your analysts in command. Or take the open hunt.md file anywhere that reads the format.
Machine-drafted by huntbase-hunt-generation using hb_google/gemini-3-flash-preview, gated by dry-run, lint, then reviewed by a person.