UnDefend does exactly what its name suggests. The Microsoft Defender zero-day, one of three disclosed this month and confirmed under active exploitation on April 17, allows a standard user to disable the endpoint protection tool that comes enabled by default on virtually every Windows installation. The tool millions of organizations trust to protect their endpoints can now be switched off by the people it was supposed to protect against.

That same week, CERT-EU attributed a 92-gigabyte breach of the European Commission’s AWS infrastructure to TeamPCP’s exploitation of the compromised Trivy vulnerability scanner. The attack’s self-propagating CanisterWorm had seeded 47 npm packages, turning every CI/CD pipeline that executed the trusted scanner into a distribution node for malware. The tool organizations relied on to find vulnerabilities had become the vulnerability.

Meanwhile, Google’s Threat Intelligence Group disclosed UNC6783, a threat cluster that has extorted dozens of organizations by engaging help desk staff through live chat. Rather than sending phishing emails, UNC6783 operators conduct real-time conversations, diverting support workers to fraudulent Okta login pages and enrolling attacker-controlled devices for persistent access. The human infrastructure of IT support had become the attack vector.

Three incidents, three technical domains, one strategic pattern. Attackers are no longer trying to bypass defenses. They are turning defenses into weapons. Understanding why this works, and what it demands from defenders, requires looking past the CVEs and IOCs into the cognitive assumptions that make trusted infrastructure such a reliable target.

When Endpoint Protection Becomes Endpoint Risk

The three Defender zero-days, tracked as BlueHammer, RedSun, and UnDefend, sit in a product line that enjoys one of the highest levels of assumed trust in the defender toolchain. Defender runs with SYSTEM-level privileges. It ships enabled by default. It is present on nearly every Windows endpoint an enterprise owns. That combination is precisely what makes it valuable to attackers: compromise Defender, and the tool responsible for reporting anomalous behavior becomes the thing causing it.

Help Net Security’s reporting on the active exploitation noted that two of the three vulnerabilities remain unpatched as of mid-April. UnDefend is the most operationally consequential of the three, because it attacks the assumption at the heart of endpoint protection: that the tool is watching even when an attacker has gained a foothold. If a low-privilege user can silence Defender or block it from receiving updates, every downstream detection and response workflow that depends on Defender telemetry becomes unreliable in the exact scenarios where it matters most.

The secondary implication is harder. Most organizations maintain detection playbooks that assume the security stack is operational. Defender stops sending telemetry and an alert fires somewhere. Unless a team has explicitly engineered for silent failure, though, the absence of telemetry can be interpreted as the absence of activity.

From Vulnerability Scanner to Vulnerability

The Trivy compromise has been unfolding for weeks, but the EU Commission attribution sharpened its meaning. CrowdStrike’s analysis traced the initial access to a malicious GitHub Actions workflow that harvested credentials from organizations running Trivy scans against their container images. Palo Alto Networks documented the self-propagating mechanism: compromised Trivy binaries pushed CanisterWorm into downstream npm packages, which then executed in the build environments of every organization that pulled the packages as dependencies.

The architectural lesson is that vulnerability scanners occupy an unusual trust position in the software supply chain. They are granted access to everything, including production credentials, container registries, and cloud infrastructure, for the explicit purpose of finding flaws. That access is the payoff when the scanner is compromised. TeamPCP did not need to breach the European Commission’s perimeter. They needed to be inside a tool the Commission had already given the keys to.

Trivy was trusted because it found vulnerabilities. The vulnerability it exposed is the trust itself.

The Conversational Attack Surface

UNC6783 operates at the other end of the stack, where cognition matters more than code. The cluster’s methodology, detailed in the Google Threat Intelligence Group disclosure, abandons email phishing in favor of real-time conversations with help desk staff. The operator initiates a support chat, impersonates an internal employee, and walks the agent through a fabricated access issue that terminates at a fraudulent Okta login page or an MFA enrollment for an attacker-controlled device.

Email phishing succeeds in part because attackers can iterate asynchronously and at scale. Live chat succeeds for a different reason: help desk staff are trained to be helpful and responsive under time pressure, and those qualities are exploitable when the attacker is a persuasive interlocutor rather than a suspicious email. Training programs built around “spot the suspicious link” do not transfer cleanly to conversations where the attacker adjusts rhetoric in real time based on the agent’s responses.

The disclosure also highlighted a supply chain angle that deserves attention. Many enterprises outsource their help desks to BPO providers, and UNC6783 has exploited that by targeting the BPO rather than the end client. The BPO inherits the client’s trust, which means a successful social engineering attempt at the vendor layer cascades into privileged access at the customer.

The Adversarial Logic of Trust Inversion

These three incidents are worth reading together because they reveal the same strategic calculation applied across different technical domains. Attackers are systematically mapping the trust assumptions embedded in defensive architectures and targeting them in priority order. Endpoint protection holds the highest technical trust. Vulnerability scanning holds the highest pipeline trust. Help desks hold the highest human trust. The priority order is not accidental.

What makes trust inversion effective is that defenders are cognitively predisposed not to question the tools and processes they depend on. Security teams carry heavy workloads and operate under time pressure. Trusted infrastructure is trusted precisely because treating every component as suspect is impractical. Attackers exploit that necessity. The result is a trust inversion in which the most dangerous threats arrive embedded in the infrastructure defenders lean on hardest.

This is adversarial cognition operating at the strategic level. The attackers are not just modeling how the target’s systems work. They are modeling how the target thinks about those systems, then exploiting the gap between the defender’s assumption and the technical reality.

Defending When the Defenses Are Suspect

The remediation challenge here is not purely technical, though technical work is part of it. Patching Defender, rotating Trivy credentials, and hardening help desk authentication are necessary. None of them address the underlying assumption that created the opportunity.

Defenders should audit the trust assumptions embedded in their architectures and model what happens if each one is compromised. A tabletop exercise that begins with “Defender is silently disabled across the fleet” or “Trivy is exfiltrating credentials during every scan” reveals capability gaps that conventional IR playbooks do not. Independent monitoring matters here. If the tool responsible for telling you something has gone wrong is the thing that has gone wrong, the detection must come from somewhere else.

Help desk readiness requires the same rethink. Phishing simulations built around email do not prepare agents for live conversational manipulation. The training that actually transfers comes from red team scenarios that replicate the pacing and pressure of real chat-based social engineering, including scenarios routed through BPO partners.

Architecturally, the principle of least privilege applies to security tools as much as to anything else. Trivy did not need persistent access to production AWS credentials to scan for vulnerabilities. Defender does not need to be the only line of detection for behavior that every other layer can also observe. The blast radius when a trusted component is compromised is a design choice, not a technical inevitability.

Trust is not a property of a tool. It is an assumption a defender makes. Attackers have read that assumption more carefully than the defenders making it, and this week is the evidence.