Container security teams often put a lot of trust in image scanning, and for good reason: scanning helps catch vulnerable packages, misconfigurations, and known malware before workloads are deployed. But the latest Microsoft Mechanics short highlights a critical blind spot for Kubernetes and container operations: image scanning alone cannot prove what a running container is doing after deployment.
The example centers on a container attack where workloads are hijacked and used for cryptocurrency mining. The important lesson is not simply that cryptomining is noisy or costly. It is that a container can begin executing binaries or processes that were never part of the original image. That runtime change is a strong signal that the workload has drifted from its intended state and may be under active compromise.
What the short demonstrates
The video shows Microsoft Defender surfacing an alert for initial binary drift. In practical terms, this means a container that should be immutable is running something it was not built to run. The alert evidence points to runtime activity such as a suspicious parent process, a shim file used during execution, and contextual details tied to the process, file, pod, and cluster.
That evidence matters because it connects the suspicious behavior to the operational environment. Security teams do not just need to know that “something bad happened.” They need to know which pod, which cluster, which process chain, and which file activity created the risk so they can scope containment quickly.
Why image scanning is not enough
Pre-deployment scanning is still essential, but it answers a different question: what is inside the image before it runs? Runtime detection answers a more urgent question: what is the workload actually doing now?
Attackers often exploit the gap between those two moments. A clean or acceptable image can still be abused after deployment if an attacker gains execution, drops a binary, launches a miner, or uses legitimate container runtime mechanics in suspicious ways. If the security program only evaluates images and posture, it may miss the active behavior that indicates compromise.
Operational impact for cloud and platform teams
For teams running AKS, Kubernetes, or other container platforms, runtime signals should be part of the standard detection strategy. Binary drift, unexpected process trees, and suspicious file execution can help identify attacks that do not appear in the original image bill of materials.
This also changes incident response. Instead of starting with a vague container alert, responders can pivot into pod, cluster, process, and file evidence. That context helps determine whether the issue is isolated to one workload, tied to a broader cluster compromise, or related to a vulnerable deployment pattern that needs to be fixed in CI/CD.
Practical takeaways
Keep image scanning in the pipeline, but do not treat it as the final control. Pair it with runtime protection that can detect unexpected execution after deployment. Review alerts for process lineage, dropped or executed files, affected pods, and cluster-level scope. Finally, use these runtime findings to improve prevention: tighten admission controls, reduce container privileges, enforce immutable deployment patterns, and investigate why the workload could execute unexpected code in the first place.
Bottom line
Container security needs both prevention and live detection. Image scanning reduces known risk before deployment, but runtime detection catches the behavior that only appears once an attacker is inside the environment. For modern Kubernetes operations, that difference can determine whether cryptomining or another container attack becomes a small incident or a cluster-wide problem.
Source: Microsoft Mechanics video