Mimic Research

The Exploit Path

Every vulnerability CISA has confirmed used in a ransomware campaign, and what an exploit of it must do on the host.

—ransomware-linked CVEs
—in the KEV catalog
2021–2026the whole KEV catalog

What this page shows

Every row is classified by what its class of exploit must do next — start a process, write a file, reach into another process, open a network flow. From that classification, the table shows how the Mimic node's capabilities can be used to protect against that specific CVE.

The reasoning runs through the class, so every entry sharing a classification carries the same answer. It describes how the node would be configured — not a test we have run. Where we have detonated something and recorded the event tree, the row says so.

Columns marked with a sparkle are derived by an AI model. CISA's own record sits beside them unchanged, so every inference is checkable against the description it came from — expand any row to see both.

How Mimic protects

Mimic doesn't judge an action suspicious. It builds a profile of what a server actually does, and has the ability to deny anything outside it. In practice that is pointed at the applications that matter and the resources they own — their paths, their registry keys, their objects — rather than at everything on the box. These are the controls an intrusion has to get past once the exploit itself has landed.

Show how each control works Hide details
executionfile writeregistry write cross-process accessnetwork flow newer than the baselineservice and directory hardening
executionAuthorisation is per launching image → launched image pair, so the same binary can be permitted under one launcher and denied under every other. A signed operating-system tool is not trusted because it is signed; it is permitted because that process has been authorised to launch it there.
file writeCreating, writing, renaming or deleting a file fails when policy denies it, scoped by path prefix. Read access is not part of this control on Windows.
registry writeSetting and deleting values, creating and renaming keys, changing key security. Creating a service is a registry write like any other, which is why service installation falls under this.
cross-process accessWhen one process opens a handle into another, the intrusive rights are stripped from what it is granted — the credential dumping and injection path. The handle is restricted, not refused.
network flowOutbound and inbound connections a profiled application never makes can be denied, so the fetch that pulls the payload in, and the channel that moves data out, are not available to the process that needs them. Linux today; Windows support is in flight.
newer than the baselinePolicy can name "any executable that appeared on this host after the baseline was taken" instead of a list of binaries — so it covers software nobody enumerated, including software that did not exist when the rule was written.
service and directory hardeningProtected Windows services cannot be stopped or deleted through the Service Control Manager. Group Policy objects and the rogue-domain-controller path are locked at the directory object itself, and re-lock themselves if tampered with.
Execution controlBlock processes that are not known-good for this server from launching the executable.
Write-path controlBlock writes, renames and deletes at the path or registry key, evaluated on where the write actually lands.
Object access controlStrip the intrusive rights when one process opens a handle into another.
Network controlDeny connections a profiled application never makes, so the payload cannot be fetched and the data cannot leave.
Read controlDeny the read itself, so the disclosure never happens. Linux today; Windows support is in flight.
Constrained after accessNothing denied at the moment of entry; the constraint lands on the first thing the attacker then does.
Appliance — not supportedEmbedded firmware with no host to install onto, even where it is Linux underneath.
Client device — servers onlyMimic runs on backend servers. The OS may well be one we support; the kind of machine is not what we target.
OS not supportedA server, but on an operating system a Mimic node does not run on.
Not constrainedNo action to deny.

Hover a row's How Mimic protects cell to see how these apply to that entry. Decisions are made on image paths and baseline era — not hashes, signers, users or command lines — as policy committed to the kernel in advance rather than a verdict computed per event, so every denial is attributable to the rule that caused it.

Two things this does not say. It is not a per-CVE claim: the constraint belongs to the class, and every entry in a class carries the same text. And a few classes trip none of these at the moment of exploitation — a file read, or a process over-reading its own memory. Those rows say so.

Every ransomware-linked entry

Loading…

CVEVendor / product Exploitation class What it must do next Platform How Mimic protects Added

Source: CISA's Known Exploited Vulnerabilities catalog, reproduced as published. The exploitation classes, the commentary, and every statement about Mimic on this page are ours alone. Mimic is not affiliated with, endorsed by, or sponsored by CISA or the US Department of Homeland Security, and nothing here should be read as CISA assessing, validating, or recommending any product. KEV is a floor rather than a ceiling — absence from it means "not yet proven and published", not "not exploited".