pattern·published·3 exhibits

Security Tool As Primitive

The privileged action of your security tool becomes the attack. Defender's hands become attacker's hands.

A security tool's job is to carry privileges you would never grant any other process. Read every file on the disk. Write to kernel memory. Make network calls on behalf of the machine. Enumerate user accounts. Modify startup paths. The tool needs those primitives to do defensive work. That is the whole point.

The problem is that the primitives do not have an allegiance. A privilege to scan every file is a privilege to exfiltrate every file. A privilege to patch memory is a privilege to inject into memory. A privilege to quarantine files is a privilege to delete them. Same syscall, different caller.

Mechanism

Security tooling is trusted because of what it does. It performs dangerous actions and is supposed to perform them safely. The trust is structural: you cannot build a meaningful defender without granting it the primitives attackers want. The enterprise asks its security tool to be the most privileged thing on every endpoint, and then asks the tool not to be hostile.

The pattern: an attacker reaches the tool itself, via code execution inside it, compromise of its update channel, abuse of its RPC interface, or the legitimate use of its documented API in unintended ways, and inherits every primitive the tool has on every endpoint it runs on. The attacker did not write the code that does file read across every disk in the fleet. The code was already there. The attacker just had to steer it.

What makes this specific (rather than generic trust-inversion) is the deploy-everywhere homogeneity. One compromise of a defender's agent does not just breach one machine. It breaches every machine where the agent runs, because the agent is the same binary doing the same job under the same trust model on each one. The blast radius scales with deployment footprint, which for a security product is usually: everywhere.

Exhibits

RedSun: How Windows Defender's Remediation Became a SYSTEM File Write. Windows Defender's remediation path, the feature that removes malicious files, can be steered to write arbitrary content as SYSTEM. The primitive Defender needs in order to delete a malicious file at the kernel level is the same primitive an attacker needs to write their own. The tool is literally named Defender. The write is literally SYSTEM.

UnDefend: What Chaotic Eclipse Held Back This Time. An EDR with enough privilege to unhook, disable, and tamper with other defensive components on the endpoint. The feature set is everything you would need to build a defender, and also everything you would need to disable one. Chaotic Eclipse's choice of what to ship (and what to hold back) is the tell: they know what the tool is capable of.

BlueHammer: What the Researcher Commented Out. A research PoC with the weaponizer commented out. The defensive tool (the research code that studies the attack) is one git checkout away from being the attack itself. The commented-out sections are load-bearing documentation: they show exactly what the tool's privileges enable. The researcher chose restraint. The tool does not require it.

Boundaries

Not every elevated-privilege process. If a non-security program runs as SYSTEM, that is a privilege escalation waiting to happen, but it is not security-tool-as-primitive. The pattern requires that the tool's DEFENSIVE MISSION is what granted it the privilege. A random SYSTEM service is just a wide ACL.

Not every EDR bypass. Bypasses get the attacker around the tool. Security-tool-as-primitive makes the tool work FOR the attacker. The distinction matters for the playbook: if your concern is bypasses, you harden configurations. If your concern is abuse of the tool itself, you model the tool as a capable malware platform that happens to be on your payroll.

Not generic supply chain. A backdoor in a compiler is a supply-chain compromise. Security-tool-as-primitive does not require supply-chain corruption; it requires that the tool's correct, undiscounted, intended behavior produces primitives the attacker wants. Often the tool is running exactly as designed. That is the problem.

Defender playbook

Enumerate what your security tools can do, not what they are configured to do. The configuration is the current posture. The primitives are the ceiling. When triaging a compromise, "what COULD this agent have done if the attacker reached its command interface" is the question.

Map your security agent footprint the same way you map your attack surface. Every host running your EDR is a potential read-every-file surface. Every host running your patching agent is a potential write-arbitrary-binary surface. The trust model should assume that agent compromise is in-scope for incident response.

Watch the update channels. Security tools update frequently. A signed update is a documented privileged code delivery mechanism. Updates from the vendor are trusted by construction; attackers who reach the update-signing pipeline reach every deployment at the next heartbeat.

Distrust the vendor's threat model on behalf of your users. Security vendors model themselves as defenders, not as a compromise surface. Your model must include them. Ask the vendor what happens if their build system is compromised, their cert is stolen, their RPC is abused. If the answer requires a recall, you are operating inside someone else's revocation gap.

Do not give the security team its own parallel unobserved infrastructure. The team that hunts attackers on your network has the profile of an attacker on your network. The same logging, review, and least-privilege that applies to engineers must apply to the SOC. Treating the defensive stack as above-scrutiny is how defensive-stack compromise stays invisible.

Kinship

Trust Inversion. The parent pattern. Security-tool-as-primitive is trust inversion where the compromised authorizer is a defensive tool specifically, and the attacker inherits deploy-everywhere reach as a consequence of the tool's deployment model.

The Detector Is The Target. Sibling shape applied to detection rather than broad security tooling. Sandbox, SIEM, scanner, each of these has the same mechanism, but their role is observation rather than action. Security-tool-as-primitive is about action. The-detector-is-the-target is about the tool that watches.

Persistent Blindspot. The tool that blinds you to its own abuse is the hardest case. An EDR that suppresses its own alerts when tampered with, a scanner that reports clean because it was modified to report clean, a patch agent whose logs the attacker edited. The compromise of the defensive tool often takes the defensive instrumentation down with it.

Your SOC has the profile of your adversary. That is not a metaphor. It is a trust boundary nobody drew.