SilentButDeadly is an open-source network communication blocker that targets one of the most fragile assumptions in modern endpoint security: that Endpoint Detection and Response (EDR) and antivirus (AV) agents can always talk to their cloud backends. The tool, authored by security researcher Ryan Framiñán, uses the Windows Filtering Platform (WFP) to cut off cloud connectivity for selected security processes while it leaves the operating system and the agents themselves running.
Because many EDR platforms depend heavily on cloud telemetry for analytics, detection, and policy updates, SilentButDeadly demonstrates how an attacker or red team can blind those sensors without killing them. As a result, dashboards still show apparently healthy agents, yet those sensors no longer send events or receive new rules. For defenders, that scenario should trigger uncomfortable questions about visibility, resilience, and how much they rely on cloud-linked analytics to see real attacks in motion.
Importantly, the author presents SilentButDeadly as a research and red-team tool, not as a turnkey criminal implant. Nevertheless, the technique sits firmly in the same family of EDR “killers” and bypass tools that real ransomware operators already test and deploy. That overlap means security teams should treat SilentButDeadly as a proof-of-concept for an increasingly common threat pattern, not as an isolated curiosity.
𝗛𝗼𝘄 𝗦𝗶𝗹𝗲𝗻𝘁𝗕𝘂𝘁𝗗𝗲𝗮𝗱𝗹𝘆 𝗶𝗻𝗶𝘁𝗶𝗮𝗹𝗶𝘇𝗲𝘀 𝗮𝗻𝗱 𝗽𝗿𝗲𝗽𝗮𝗿𝗲𝘀 𝘁𝗵𝗲 𝗴𝗿𝗼𝘂𝗻𝗱
SilentButDeadly starts by checking whether it runs with administrator privileges, since WFP filter management and service control both require elevated rights. It uses standard Windows APIs such as CheckTokenMembership() to verify that level of access and then prompts the operator before it moves forward. That interactive behavior gives red-teamers a chance to confirm scope and timing instead of firing everything automatically.
After the privilege check, SilentButDeadly performs a dedicated EDR discovery phase. It takes a snapshot of running processes via CreateToolhelp32Snapshot(), walks that snapshot, and matches each process against a predefined list of known EDR and AV components. Out of the box, the tool focuses on targets like SentinelOne’s SentinelAgent.exe, Microsoft Defender’s MsMpEng.exe, and Defender for Endpoint’s MsSense.exe, although the configuration remains extensible. In practice, an operator can extend that list with additional vendor agents as needed.
When it finds a match, SilentButDeadly resolves the full process image path by calling QueryFullProcessImageNameW(). That path becomes a key ingredient later, because WFP application filters tie their rules to an AppID blob that represents the executable on disk. The tool converts the file path to that AppID by calling FwpmGetAppIdFromFileName0(), which allows extremely precise policy: only traffic from the chosen security agent gets blocked, while the rest of the system continues to talk to the network without interference.
𝗨𝗻𝗱𝗲𝗿 𝘁𝗵𝗲 𝗵𝗼𝗼𝗱: 𝗵𝗼𝘄 𝗶𝘁 𝗲𝘅𝗽𝗹𝗼𝗶𝘁𝘀 𝗪𝗶𝗻𝗱𝗼𝘄𝘀 𝗙𝗶𝗹𝘁𝗲𝗿𝗶𝗻𝗴 𝗣𝗹𝗮𝘁𝗳𝗼𝗿𝗺
Once SilentButDeadly knows which processes it wants to isolate, it opens a dynamic WFP session. That session uses the FWPM_SESSION_FLAG_DYNAMIC flag so Windows automatically cleans up filters when the tool exits or the system reboots. From a red-team perspective, that behavior reduces forensic noise and lowers the risk of breaking networking permanently. From a defender’s vantage point, however, it also means that an attacker can blind an EDR sensor temporarily and then leave almost no persistent configuration behind.
Inside that session, SilentButDeadly registers a high-priority WFP sublayer and then attaches filters at two critical Application Layer Enforcement (ALE) layers:
– Outbound connections at FWPM_LAYER_ALE_AUTH_CONNECT_V4
– Inbound acceptance at FWPM_LAYER_ALE_AUTH_RECV_ACCEPT_V4
Each filter carries a high weight (0x7FFF) and an action of FWP_ACTION_BLOCK. The filters also apply a process-specific condition using FWPM_CONDITION_ALE_APP_ID. Together, those attributes ensure that SilentButDeadly blocks only the EDR or AV processes it targets, while the rest of the endpoint still talks to DNS, web servers, and APIs as usual. GitHub+1
Because the tool runs entirely in user mode and relies solely on documented Windows APIs, it never loads custom kernel drivers and never patches the operating system. Many EDR- and AV-bypass tools lean on “bring your own vulnerable driver” (BYOVD) techniques, direct kernel tampering, or process termination; SilentButDeadly stays on the opposite end of that spectrum and focuses on network isolation without kernel modifications. That choice raises the bar for detection, since normal EDR analytics often prioritize process kills or driver tampering rather than subtle network-layer changes around their own agents.
𝗦𝗲𝗿𝘃𝗶𝗰𝗲 𝗱𝗶𝘀𝗿𝘂𝗽𝘁𝗶𝗼𝗻 𝗮𝗻𝗱 𝘁𝗵𝗲 𝗶𝗺𝗽𝗮𝗰𝘁 𝗼𝗻 𝗻𝗼𝗿𝗺𝗮𝗹 𝗘𝗗𝗥 𝗼𝗽𝗲𝗿𝗮𝘁𝗶𝗼𝗻
SilentButDeadly does more than just block network flows. After the tool isolates EDR and AV agents at the WFP layer, it attempts to disrupt the backing Windows services that manage those agents. It opens the Service Control Manager, looks up service entries associated with targeted processes, and issues graceful stop requests. When a stop succeeds, it switches the startup type to SERVICE_DISABLED so Windows does not restart the service automatically.
This approach avoids crude process-kill loops and instead uses the same management channels that administrators rely on. That behavior, in turn, mirrors how a determined attacker might operate when they want to avoid drawing attention from simple “process terminated” alerts. By halting future restarts and leaving network filters in place, SilentButDeadly can keep agents present but functionally blind, a combination that undermines many organizations’ assumptions about their monitoring coverage.
At the end of a run, SilentButDeadly prints a concise operation summary that lists each affected product, process identifiers, counts of network blocks applied, and the overall WFP status. The operator can then remove filters and clean up the session, which causes WFP to tear down the provider and associated rules. That summary helps red teams validate that the tool achieved the intended isolation before they proceed with further testing or simulation.
𝗪𝗵𝗲𝗿𝗲 𝗮𝗻 𝗮𝘁𝘁𝗮𝗰𝗸𝗲𝗿 𝗼𝗿 𝗿𝗲𝗱 𝘁𝗲𝗮𝗺 𝗴𝗲𝘁𝘀 𝗹𝗲𝘃𝗲𝗿𝗮𝗴𝗲 𝗶𝗻 𝗿𝗲𝗮𝗹 𝗼𝗽𝗲𝗿𝗮𝘁𝗶𝗼𝗻𝘀
SilentButDeadly fits naturally into a broader EDR bypass and evasion toolkit. Over the past few years, extortion crews and advanced threat actors have shifted from simply obfuscating payloads to directly targeting the endpoint defenses themselves. They use BYOVD implants, vulnerable drivers, and abuse of platform features to disable, freeze, or blind security components. SilentButDeadly adds another angle: network-only silencing of those agents.
In a real-world intrusion, an operator could deploy SilentButDeadly after establishing local administrator control. They might already have footholds via misconfigured remote management tools, stolen VPN credentials, or phishing-based payloads. Once they sit on a critical workstation or server, they can cut telemetry and policy updates from EDR and AV components, then run additional tooling with a lower chance of detection. Meanwhile, the central console continues to show green checks for the affected endpoints, because the agent processes still run and the last-known status remains healthy.
For red teams working under strict rules of engagement, SilentButDeadly also provides a controlled way to test organizational assumptions about EDR visibility. Instead of uninstalling agents or crashing them, a test team can simulate a scenario where connectivity disappears while processes remain intact. That scenario lets defenders validate whether their SOC recognizes silent endpoints, whether alerts fire when cloud ingestion stops, and whether they correlate service changes or WFP filter events with potential tampering.
𝗛𝗼𝘄 𝗱𝗲𝗳𝗲𝗻𝗱𝗲𝗿𝘀 𝘀𝗵𝗼𝘂𝗹𝗱 𝗿𝗲𝗮𝗰𝘁 𝘁𝗼 𝗦𝗶𝗹𝗲𝗻𝘁𝗕𝘂𝘁𝗗𝗲𝗮𝗱𝗹𝘆-𝘀𝘁𝘆𝗹𝗲 𝘁𝗮𝗺𝗽𝗲𝗿𝗶𝗻𝗴
From a defensive standpoint, SilentButDeadly forces teams to treat the EDR itself as an attack surface. Relying on a single control that depends heavily on constant cloud connectivity creates a brittle architecture. Instead, modern programs should combine local detection capabilities, layered telemetry paths, and out-of-band monitoring that does not sit behind the same agent.
First, teams should ensure that EDR and AV agents log local tampering indicators. WFP filter creation events, unusual access to the WFP engine, and repeated attempts to stop or disable security services should all feed into security analytics. Even if a tool like SilentButDeadly cuts cloud telemetry, Windows and local logging pipelines still record those actions, and defenders can forward them through alternate channels where possible.
Next, monitoring should extend beyond “agent check-in” signals. Security teams need health checks that compare expected telemetry volume with reality. When a busy endpoint or critical server suddenly goes quiet while the console claims that everything looks fine, that discrepancy should raise an immediate investigation. That pattern often appears when attackers freeze or blind EDR components rather than uninstalling them.
Finally, organizations should fold EDR bypass scenarios into red-team exercises and purple-team drills. When teams rehearse incidents that include tools like SilentButDeadly, they reveal gaps in detection content, incident-response playbooks, and escalation paths. Over time, that feedback loop improves visibility, reduces blind spots, and makes it far more expensive for attackers to rely on EDR-neutralization as a primary tactic.
𝙁𝘼𝙌𝙨
Q: What problem does SilentButDeadly actually exploit?
A: SilentButDeadly exploits the fact that many EDR and AV platforms depend on cloud connectivity for analytics, detection, and policy enforcement. By cutting that network path at the WFP layer while agents keep running, the tool blinds those platforms to local activity and disrupts remote management.
Q: Does SilentButDeadly uninstall or kill security software?
A: No. SilentButDeadly blocks communications and disrupts services instead of uninstalling agents or tampering with the kernel. That design keeps the tool closer to legitimate platform features and reduces the obvious forensic traces that simple process-kill loops would create.
Q: How could a real attacker abuse this technique?
A: An attacker with administrator access could deploy SilentButDeadly to silence EDR sensors on high-value endpoints before they move laterally or execute further payloads. In that scenario, the security console may still show healthy agents, yet defenders lose real-time visibility and reliable alerts from those systems.
Q: What should defenders monitor to catch SilentButDeadly-like behavior?
A: Defenders should monitor for new WFP filters, unusual WFP provider registrations, suspicious service stop and disable operations against security products, and endpoints that suddenly stop sending telemetry. Correlating those signals provides early warning that an attacker is actively trying to neutralize endpoint defenses.
Q: How can security teams use SilentButDeadly safely?
A: Security teams can use SilentButDeadly in authorized test environments to validate EDR resilience, improve detection content, and refine incident-response workflows. They should run it under strict rules of engagement, document each test, and treat the results as an input to hardening decisions rather than as a shortcut to weaken production monitoring.
