When Mozilla shipped Firefox 150 with fixes for 271 issues identified by Anthropic’s Mythos model, the headlines focused on the count. The detail that mattered was further down: Mozilla credited only three CVEs to the model. The remaining 268 were classified as defense-in-depth, hardening, or bugs in code paths that could not be exploited.
That gap, between what AI can find and what attackers can use, is where modern defense lives. The rest of the public record reinforces it. Mozilla’s CTO and independent researchers have publicly stated that Mythos finds what skilled humans could find, just faster.
The UK AI Security Institute’s end-to-end simulation showed Mythos succeeding in three of ten attempts. AISLE’s replication work showed older, cheaper models could reproduce most of the discovery, while exploitation remained the harder, frontier-dependent problem. Palo Alto Networks has reported that Mythos can chain multiple lower-severity issues into critical exploits.
That is real. But every link in a chain still must do something physical to memory, tokens, processes, or files. Those actions are visible to a defender who knows what to watch for, regardless of which vulnerability the attacker started with. Exploitation is also only one of several ways attackers reach their goals. Phishing, stolen credentials, insider threats, and supply chain compromise bypass the exploit step entirely.
Sophos sits at the layer below all those entry vectors. There is a small set of mechanics every attacker must use when trying to do something on a real machine. Whether the attacker is an AI-driven exploit pipeline, a ransomware affiliate with stolen credentials, or a nation-state operator with hands on the keyboard, they all hit the same wall of architectural mitigations, on every process, by default.
We do not claim that attackers cannot get through. We claim Sophos Endpoint makes exploiting a vulnerability substantially more difficult, and friction is where defenders win.
The openness problem
Windows is, by design, an extraordinarily open operating system. The platform’s success rests in part on that flexibility. Debuggers inspect other processes, plugin frameworks load arbitrary modules, accessibility tools interact programmatically with applications, and decades of legitimate software depend on those primitives remaining permissive.
The same primitives are what attackers reach for first. On a default Windows installation, an attacker with code execution as a normal user can write code into another running process, allocate executable memory dynamically, manipulate security-sensitive structures inside trusted processes, and patch system DLLs to disable inspection. None of this requires a vulnerability or elevation.
Microsoft has invested seriously in protections, from EMET through Windows Defender Exploit Guard and Attack Surface Reduction rules. The unavoidable problem is compatibility. The most powerful in-process mitigations (Code Integrity Guard, Arbitrary Code Guard, Disable Win32k System Calls, Export Address Filtering) are opt-in by design.
They have to be: applying them to an application that wasn’t architected around them breaks JIT compilers, .NET runtimes, browsers, and most third-party software. Even Microsoft hasn’t opted its own Office suite into them, and its documentation describes them as broadly incompatible with normal applications. Outside of Edge and a handful of hardened browser processes, the aggressive mitigations are absent across most of the operating system.
The applications that do run with these mitigations (Edge, Chrome, Firefox) got there by re-architecting into multi-process designs that isolate dynamic-code generation from untrusted content. That option isn’t available to applications built around in-process integration: VBA, COM automation, add-ins, OLE. Office is the canonical example.
Sophos took a different path. Rather than ask Microsoft, application developers, or customers to opt in, we built our own mitigation layer (independent of the OS, independent of the application) that constrains the primitives attackers rely on (code-path deviation, dynamic executable memory, code injection, patching system DLLs) at runtime, on every process, by default.
The same guardrails apply to whatever the attacker runs next: dropped payloads, post-exploitation tools, and ransomware binaries are processes, too. Owning both the mitigations and the infrastructure that controls them is what made that viable: it took years of compatibility engineering to deliver, and we keep evolving them as the threat landscape shifts.
Why AI does not change our approach
Three things in the public record on AI-driven offense are easy to miss.
- AI scales discovery, but AI does not invent new exploitation primitives. There is a meaningful difference between finding bugs and inventing new ways to turn bugs into running code. The current record on offensive AI does not show frontier models inventing primitives. It shows them applying, combining, and varying primitives the security community already understands. That is the finite set Sophos has been targeting for years.
- Obfuscation makes Sophos’ mitigations more likely to fire, not less. Signature engines struggle with obfuscation because the bytes do not match. Sophos’ mitigations sit below the obfuscation. Obfuscated or encrypted attacker code must de-obfuscate itself in memory before it can run, which requires allocating writable-then-executable memory, decrypting into it, and transferring control. That sequence is exactly what Sophos’ memory-integrity layer is built to detect. More elaborate obfuscation makes the attacker more conspicuous, not less.
- When AI is asked to produce evasive exploit code, what it produces is the playbook attackers have always reached for: direct syscalls, hardware-breakpoint redirection, call-stack spoofing, ETW patching, AMSI bypasses, and in-memory hook tampering. Each of those is a named Sophos mitigation. The more an AI tries to evade detection by reaching for advanced tradecraft, the more named Sophos mitigations it walks into.
A mitigation that isn’t enabled isn’t a mitigation
Sophos Endpoint ships more than 60 named exploit mitigation checks enabled by default, on every protected endpoint, without per-application tuning, exclusion lists, or audit periods. That is not how most competitors ship them.
Microsoft’s Exploit Protection is configurable per application, with the more aggressive mitigations typically scoped narrowly. Most third-party EDR products are built primarily for detection and response, not prevention: they ship a small set of memory-layer mitigations (often just force-enabling Microsoft’s existing ones such as DEP, ASLR, and SEHOP), and the most powerful Windows mitigations only apply where the application developer has opted in.
The result, across the industry, is that most enterprise endpoints have some capability to be more protected and the reality of running with most protections off.
Compatibility is what makes default-on sustainable. When a Sophos mitigation occasionally fires on legitimate code, our Sophos X-Ops teams can publish a thumbprint that allows the specific legitimate behavior past the mitigation while the mitigation itself stays active.
The carve-out is scoped to a single code path, a single module, or (rarely) a single application. Every other behavior, including any malicious behavior in the same process, continues to be evaluated. The fix propagates without a product update, often before the customer has filed a support case.
What this looks like in practice: the trojanized CPU-Z installer
In April 2026, attackers compromised a backend API on cpuid.com for six hours and redirected CPU-Z downloads to a trojanized installer: the real signed executable bundled with a malicious CRYPTBASE.dll.
When users ran it, Windows DLL search order pulled the malicious DLL in transitively through ADVAPI32.dll, where it ran inside a signed, trusted process and launched a multi-stage in-memory unpacking chain ending in a remote access trojan with hidden desktop control and credential-theft tooling. No disk artifacts after the initial DLL.
No software vulnerability was exploited. Legitimate components behaved as designed. What was weaponized was a trusted binary plus an attacker-controlled DLL in the right directory.
This is why Sophos treats vulnerability exploitation and abuse of legitimate functionality as the same problem. Watering holes, supply-chain compromises, phishing, and stolen credentials all bypass the exploit step, then converge at the same primitives once malware is running.
The initial-access weaknesses behind them (a misconfigured API, an exposed admin interface, a leaked credential) are themselves a class of vulnerability AI can find at scale. Convergence at the primitive layer is what makes the defense durable.
Zero CVEs used. More than 150 systems hit. Microsoft Defender coverage was reportedly mixed before catching up days later. Those systems fell into the gap.
The attacker engineered the DLL to evade EDR, including NTDLL proxying through a .NET assembly to bypass userland hooks. They tuned against the Windows endpoint controls. They did not tune against Sophos, and most attackers won’t.
Iterating against signatures is a recompile. Iterating against behavioral rules could be a timing tweak. Iterating against a primitive-level mitigation requires engineering a staging chain that doesn’t use the primitive: weeks of work, out of reach for most actors. Sophos doesn’t make you unbypassable. It puts you outside the target population.
On a Sophos endpoint, behavior detection (Evade_28j) blocked this before staging. But consider the counterfactual: strip every detection layer away and leave only Dynamic Shellcode Protection, shipped in 2018.
When the DLL allocated executable memory for stage two, the mitigation would have fired, because the caller of VirtualAlloc was code running in anonymous, dynamically-allocated memory: the universal fingerprint of a stager. No sample, signature, IoC, cloud lookup, or rule update. A 2018 architectural mitigation breaks a 2026 attack at stage two.
That same property makes it work where cloud connectivity is intermittent or absent: industrial networks, segmented healthcare devices, classified systems, ships at sea. Connections can be severed and detection pipelines have latency. An architectural mitigation that depends on neither is the floor that holds when everything above it is degraded.
The same fingerprint fires whether the loader was hand-written by a 2015 affiliate or generated by a 2027 model. That is the bet Sophos made: target the primitives, not the provenance.
Questions worth asking
The AI era is going to push every vendor to claim AI-readiness. The defenses that hold up are architectural, not algorithmic. When evaluating an endpoint security vendor, the questions that matter are practical:
- How many exploit mitigations are enabled by default on every process today, without configuration?
- How long have those mitigations been deployed at scale, and what is the compatibility track record?
- Does the mitigation layer cover post-exploitation behaviors (credential theft, privilege escalation, persistence, ransomware payload delivery), or only the initial exploit?
- When a compatibility issue occurs, is the fix surgical, or does it require weakening protection across the estate?
The bottom line
We do not claim Sophos is impenetrable. We claim Sophos Endpoint makes exploiting a vulnerability substantially more difficult, and friction is where defenders win.
AI is going to change a great deal about how attackers find vulnerabilities. It is going to change much less about what they must do once they have one. That asymmetry is why Sophos Endpoint is uniquely positioned as the threat landscape continues to shift
AI finds the bugs. Sophos lives where finding must become exploiting. That is the wall.
You can read more in this companion article: “AI just became the world’s most dangerous exploit writer. Here’s why Sophos Endpoint is built to stop it.”
Learn more at sophos.com/endpoint.
About Author
