A DaemonSet can turn a single cluster compromise into node-wide execution. Once deployed, it schedules a pod on every node, which makes it useful for cryptomining, credential access, and broad resource hijacking. In this campaign, the attacker used the DaemonSet to run a miner and expand impact beyond the original API abuse. That shifts the incident from access abuse to active consumption of cluster capacity.
How a DaemonSet changes the blast radius after Kubernetes access
A DaemonSet is the kind of workload an attacker uses when persistence and scale matter more than stealth. Because Kubernetes schedules one pod per eligible node, a single malicious deployment can rapidly become node-wide execution, turning API abuse into distributed runtime control. That makes it useful for mining, credential theft, log tampering, and other cluster-wide abuse.
In practice, the security significance is not the DaemonSet object itself, but the scheduling guarantee it gives the attacker. Once admitted, the pod follows node growth and rescheduling behavior, so the compromise can persist as the cluster changes. That is why defenders should treat an unexpected DaemonSet as an indicator of elevated control over the cluster, not just another workload.
The main operational consequence is blast-radius expansion. A one-off foothold can become a foothold on every node, which increases CPU consumption, widens the set of files and secrets reachable from host-mounted paths, and gives the actor many more places to hide activity. NIST SP 800-190 Container Security is useful here because it frames orchestrator and runtime risk as a first-class concern, not a deployment detail.
Why attackers prefer DaemonSets for cluster abuse
Attackers favor DaemonSets when they want repeated execution across the fleet without manually placing pods on each node. That makes the technique well suited to cryptomining, node reconnaissance, secret harvesting from host paths, and distributed persistence. It is especially attractive after initial access because the attacker can convert a single control-plane action into broad workload placement.
The technique also helps with survivability. If a node is drained, replaced, or added, the DaemonSet reconciles and can reappear where scheduling is allowed. In other words, the attacker is not just running code, they are leveraging the orchestration system’s own reconciliation loop to keep code present. MITRE ATT&CK Enterprise Matrix is the best general reference for mapping that pattern to privilege escalation, credential access, and lateral movement behaviors.
For defenders, the key distinction is between a malicious DaemonSet and a legitimate DaemonSet used for logging, monitoring, or node agents. The same workload type can be normal infrastructure or a sign of compromise, so the surrounding image source, service account, volume mounts, and node selectors matter more than the kind label alone. That is why CIS Controls v8 remains relevant for account management, logging, and malware defense around cluster workloads.
What defenders should verify when a DaemonSet appears unexpectedly
An unexpected DaemonSet should trigger verification of who created it, what service account it uses, what nodes it targets, and whether it mounts host paths or injects privileges that exceed the workload’s purpose. The most important question is whether the DaemonSet has any reason to exist in the affected namespace and whether its execution pattern matches approved node agents or observability tooling.
Review the pod spec for privileged mode, hostNetwork, hostPID, hostPath volumes, and image provenance. Those details determine whether the DaemonSet is merely noisy or whether it can touch node-level resources, harvest credentials, or interfere with local security tools. NIST SP 800-53 Rev 5 Security and Privacy Controls is directly relevant where you need access control, configuration management, auditability, and integrity controls around the cluster.
If the DaemonSet is mining, the immediate operational signal is resource saturation rather than a traditional data theft pattern. That means the response should include capacity review, pod deletion, owner reference tracing, and the search for the original API path that allowed the object to be created. The cluster event trail usually tells you whether the DaemonSet is the payload or simply the persistence layer for a broader compromise.
Risk and Threat Considerations
DaemonSets are dangerous in post-compromise Kubernetes scenarios because they turn control-plane access into a fleet-wide execution primitive. The main risk is not only persistence, but also rapid expansion of impact across every schedulable node, which can raise costs, exhaust resources, and expose node-local secrets or credentials.
Failure mechanism: An attacker with API access creates a DaemonSet that the scheduler places on each node, then uses that universal placement to run miners, steal material from host-mounted paths, or maintain presence through normal reconciliation.
Impact: The incident shifts from a single-workload compromise to cluster-wide abuse, with greater blast radius, harder cleanup, and a much larger chance of follow-on credential access or service disruption.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-53 Rev 5, CIS Controls v8 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | AC-6 — Least Privilege | DaemonSet abuse often reflects overbroad cluster permissions. |
| AU-2 — Event Logging | Unexpected DaemonSets require auditable Kubernetes change trails. | |
| CM-6 — Configuration Settings | DaemonSet risk depends on unsafe pod settings such as privilege and host mounts. | |
| Recommendation — Restrict workload and service account permissions to the minimum needed. Log workload creation and privilege changes for rapid investigation. Standardize approved pod settings and block privileged exceptions by default. | ||
| CIS Controls v8 | CIS-5 — Account Management | Unauthorized DaemonSet deployment usually depends on abused identities or accounts. |
| Recommendation — Review accounts and tokens that can create cluster-wide workloads. | ||
| NIST CSF 2.0 | PR.AA-05 — Identity Management, Authentication, and Access Control | Cluster-wide pod creation is an access-control outcome that must be bounded. |
| Recommendation — Enforce least-privilege authorization for workload creation paths. | ||
Practitioner Guidance
What to prioritise: Treat any unexpected DaemonSet as a node-level control event, not a routine workload review. Verify the creator identity, the namespace owner, the image source, and whether the pod needs privileged access or host mounts before deciding whether it is legitimate.
What good looks like: Approved DaemonSets have a clear owner, a documented purpose, constrained permissions, and observable change records. If you cannot tie the object to an approved operational function, assume the scheduler is being used to broaden the attacker’s reach.
Practitioner takeaway: The key judgment is blast radius, if the workload can run on every node, it can also turn a narrow compromise into cluster-wide execution and persistence.
Related resources from NHI Mgmt Group
- What happens when attackers deploy custom malware after gaining access to a manufacturing network?
- What happens when attackers leak sensitive records from enterprise systems after gaining access to a network?
- What happens after attackers obtain access tokens through device code phishing?
- What happens after attackers gain valid account access in a ransomware campaign against a large enterprise?
