What mitigations reduce the risk of Kessel?

How to reduce Kessel exposure in practice

Mitigations for Kessel focus on stopping the initial delivery path and making execution harder once a malicious file reaches the host. The most effective controls are application control, explicit limits on macro and script execution, and user-facing filtering or inspection for archive and document delivery channels that commonly carry the payload.

That combination matters because Kessel-style activity often depends on a harmless-looking file reaching a user and then triggering code through trusted local tooling. If the host can only run approved software, and if document macros, script hosts, and similar interpreters are constrained, the payload has fewer ways to turn delivery into execution.

What to look for after suspicious delivery

Once you suspect Kessel, the next question is whether the file only arrived or whether it also started a broader execution chain. Investigate PowerShell, WMI, and command shell activity launched by unexpected parent processes, especially when those processes are document readers, archive handlers, or other low-trust entry points.

Follow that path into the rest of the host behaviour. File drops in unusual locations, persistence mechanisms, and outbound network connections that do not fit the system’s normal role are often the difference between a blocked attempt and an active compromise.

Why containment and role-based monitoring matter

Kessel risk is reduced when endpoints are treated according to their expected function. A workstation, server, or user profile that suddenly starts acting like a loader, relay point, or persistence host deserves attention because the behaviour itself is the signal, not just the presence of a suspicious attachment.

Good detection should therefore connect process ancestry, file system changes, and network activity into one investigative view. MITRE ATT&CK Enterprise Matrix is useful here because it helps analysts map suspicious PowerShell, WMI, and shell invocation patterns to the behaviours most commonly used to turn delivery into execution.

Risk and Threat Considerations

Kessel is risky because it blends delivery, execution, and follow-on activity into a chain that can look ordinary at first. Archive and document-based delivery is especially effective when users, mail gateways, or endpoint policy allow the initial file through but do not constrain what the file can invoke locally.

Failure mechanism: The malicious content gains a first execution point through a permitted attachment or archive, then uses script interpreters or native tools to establish persistence, drop files, and reach out to external infrastructure.

Impact: The host can move from a single suspicious file to a durable foothold, which increases the chance of data theft, lateral movement, and repeated re-entry if the original artefact is missed.

Practitioner Guidance

What to verify: Confirm whether application control actually blocks the binaries, interpreters, and child processes the environment uses most often, not just the obvious malware families. If your policy still allows broad script execution or unsigned tooling on standard user endpoints, the control is weaker than it looks.

Common mistake: Teams often focus on the attachment type and ignore the post-delivery process tree. For this threat, the high-value evidence is the sequence from parent process to interpreter to persistence or network activity, not the file name alone.

Practitioner takeaway: Reduce Kessel risk by making file delivery less executable, then make any unexpected script, shell, or network follow-on immediately visible to analysts.

Related resources from NHI Mgmt Group

• Guide: Malware Guide
• How should teams reduce the risk of exposed AI credentials being abused?
• How should teams reduce risk from malicious npm package installs?
• When do non-human identities pose the greatest risk to organizations?
• Why do non-human identities create more risk than many human accounts?