Think about a burglar using the homeowner's spare key because the house gave it to them. That is the scary idea behind a new proof-of-concept technique called DefenderWrite. It helps attackers put harmful DLLs right in antivirus program folders so that the security program will run bad code.
What is DefenderWrite, and why is it important?
DefenderWrite is a tool and proof of concept that finds programs on Windows that are legitimately signed or trusted and already have permission to write to folders that endpoint security usually protects.
To put it simply, an attacker doesn't break into an antivirus program; instead, they find another program that the antivirus trusts, use that program to write files to the folder where the antivirus keeps its executables, and then drop a malicious DLL there. When a DLL is in the AV executable folder, the security product or other trusted processes can pick it up or load it. This gives attackers stealth and persistence.
There are two reasons why this is dangerous. First, antivirus companies usually stop random writes to their installation folders to keep people from messing with them. Second, if a malicious DLL is in a trusted folder, it may be able to run without the AV's knowledge, which would make it harder to fix the problem.
A number of recent articles and posts in the community talk about how DefenderWrite uses whitelisted programs and existing permissions to do this. This is a clear step up from DLL hijack and arbitrary write techniques.
How Defenderwrite works, step by step (in theory)
At its core, DefenderWrite automates a reconnaissance and abuse chain that experienced red teamers are very familiar with, but it makes it easier for more people to use. The tool first checks the system for installed programs, paying special attention to those that are whitelisted by the AV, run with higher privileges from time to time, or can write to folders that other programs own.
Next, it checks to see if those programs can be forced to write any file into the directory where the antivirus executable is stored. Finally, it drops a specially made DLL that a target process can load or that can be used in DLL hijacking attacks.
The method combines two well-known ideas in offensive security. One is using whitelisted or trusted programs in ways that they shouldn't be used to get capabilities that attackers wouldn't normally have.
The other is DLL hijacking and injection, which is when bad libraries take the place of or hide expected libraries and are loaded by good code. Defenderwrite puts the two together in a way that goes after one of the most sensitive parts of a computer: the antivirus install folder.
Effects and examples in the real world
Imagine a managed printing service, a vendor updater, or a system tool that can install updates on other programs for your convenience.
If an AV program is on a whitelist, DefenderWrite can find it and use it to write to the AV folder. Researchers demonstrated in laboratory reports and community posts that this technique can effectively counter various antivirus products in controlled environments. That doesn't mean that every AV is broken the same way, but it does show the security teams what they need to watch out for.
It helps to think of something in the real world. Think of a bank branch where only bank employees can get into the vault. If a delivery service is trusted to leave official packages in the vault area and is tricked into leaving a package with a skeleton key, the vault's security is weakened. Defenderwrite works the same way: it uses trusted channels to put a bad package where defenses are weakest.
DefenderWrite accepts these parameters:source
The process scans C:\Windows for executables, then runs DefenderWrite to identify those approved by the antivirus whitelist.source
Why DLL injection and DLL hijacking work in this case
DLL injection and hijacking have been used in Windows attack chains for a long time. When you load a DLL from a trusted folder, the code runs in the context of a trusted process. Attackers love that because many monitoring tools think the behavior is real.
DefenderWrite works because it focuses on the write control instead of the loading mechanism itself. Traditional heuristics that look for suspicious downloads or unsigned executables are less likely to go off if you make sure that a malicious DLL is in a folder that the AV trusts. The method is a way to attack that works with in-memory injection and other ways to get around security measures.
Problems with blue teams finding things
It is hard to find defender-write-style activity. The first write might look like normal behavior from an application that is on the whitelist, and the DLL itself can be made to look harmless or to use the names of real libraries.
If the AV trusts that directory or the DLL is hidden, traditional signature-based antivirus scanning might not flag the file. So, behavioral detection needs to link strange file writes to protected folders with process ancestry and unexpected network or system activity. Community posts and vendor write-ups suggest that you use both file system auditing and process monitoring to find these hidden chains.
DefenderWrite Findings:source
Steps to make things safer and less likely to go wrong
There is no one-size-fits-all solution, but there are a few things you can do to lower your risk. First, treat antivirus executable folders like valuable assets, and make sure that only the AV installer and official update mechanisms can write to them by using strict access control lists. Second, set up and fine-tune application allowlists and controlled folder access so that only update processes that you know about can access those folders. Third, use endpoint detection that looks for behavior like writing files to protected directories when they shouldn't be, strange parent-child process relationships, or sudden changes in DLL load lists.
Microsoft's advice on running Defender in a sandbox and using controlled folder access are good things to think about.
Keep track of the third-party software your organization uses and decide which programs are allowed to update or write to other installations. The defender-write pattern works well because it is possible to force trusted programs to do things. This makes it much harder for attackers to find programs that they can use.
Defenders' short-term fixes
If you think something like DefenderWrite is going on, start by taking forensic snapshots of the AV folders and the processes that have recently written to them. Look for DLLs that have been changed recently, compare file hashes to threat intelligence, and follow the parent processes back to see how the write happened.
Take away permissions from any programs that don't need to change those directories and make group policy settings stricter. Finally, install vendor updates because many AV vendors quickly fix their update handling or folder protections when certain misuse chains are made public.
How red teams and researchers are using DefenderWrite in a safe way
Researchers who are responsible use tools like DefenderWrite to point out the weak spots to defenders. Public disclosures and PoC demonstrations help vendors fix behaviors and make default settings less open.
A lot of community posts and blog posts stress that DefenderWrite is a research tool that should make defenders think differently about what they trust on an endpoint. Still, once a PoC is public, attackers can and do use the ideas again. That's why quick and useful fixes are important.
Long-term controls and thinking about architecture
Architectures that keep core security processes separate are safer than just patching and changing ACLs. When antivirus scanning engines, update services, and core detection components run in isolated or sandboxed environments, it is less likely that a third-party writer will be able to access the executable folder.
Think about endpoint architectures where the product's most important parts run under different security identifiers and the paths for updates are protected by cryptography. Tools like DefenderWrite become less useful as the chain from file write to DLL load relies more on signed, validated updates.
What businesses should do tomorrow
Start by taking stock and quickly hardening the ACL. Tell the blue team and incident response that defender-write-style attacks are real and that they should look for signs of arbitrary writes into AV directories. Patch and keep an eye on things, and give priority to vendor advice and any signatures or YARA rules that catch the technique.
Use micro-segmentation on sensitive endpoints when you can, and only let certain processes run installers or automatic updates. Finally, if you think your product is vulnerable to this pattern, get in touch with the AV vendor. They often release fixes or configuration changes that close the gap.
Things to remember
DefenderWrite is a reminder that attackers don't usually need to break the strongest lock if they can find a door that opens it for them. The tool isn't a new exploit that works like magic; it's a smart way to automate reconnaissance and privilege abuse that targets trust relationships on Windows endpoints.
The lesson for defenders is both easy and hard at the same time. Friction is necessary for trust. Locking down who can write to folders that are important for security, keeping an eye out for strange file operations, and limiting the number of programs that are trusted by default will make DefenderWrite-style attacks much less profitable.
This is the most important lesson to remember: protecting endpoints is more than just installing security software. It's about deciding who and what can change that software. If you do that well, DefenderWrite will no longer be an easy way to stay persistent.
Follow us on X (Twitter) and LinkedIn for more cybersecurity news and updates. Stay connected on YouTube, Facebook, and Instagram as well.
