Exploits like “DefenderSwitch” and “DefenderStop” can disable Windows Defender. Do they also succeed in doing so on a hardened system? We have tested it.
How well does system hardening work in practice?
We get asked this question all the time. So we unleash potentially malicious software on systems that have been hardened by us. We observe the results while eating popcorn, and then we analyze the impact of the malware-versus-hardening duel.
Dangerous: “DefenderSwitch” abuses SeDebugPrivileges
When you work for a company that has made secure configurations and system hardening its passion, you like to search the Internet for new challenges to measure your skills against.
When we stumbled across a Git repository that contained everything needed to compile a tool called DefenderSwitch, we immediately wanted to play around with it. Why? This sneaky little piece of software manages to turn off Windows Defender. DefenderSwitch accomplishes this by abusing SeDebugPrivileges. With this, it appropriates system handles and then pretends to be TrustedInstaller.
Behind the tool is a pasta-loving collective called APT. In this case, the abbreviation does not stand for “Advanced Persistant Thread”, but for “Advanced Persistent Tortellini”. The clever developers reveal how this name came about in their blog:
[…]the Advanced Persistent Tortellini collective is made of a bunch of Italian guys interested in deeply technical topics and offensive techniques. […]
How secure is a hardened system really?
We see SeDebugPrivileges as highly risky. We always advise that no one in a company should have these rights. Because if these privileges get into the hands of “cyber gangsters”, it opens the door for them to access all important systems.
The use of DefenderSwitch is a good example to show again the risks of SeDebugPrivileges. And the tool is equally well suited for checking how hardened systems react when you run the dangerous program.
Note: Similar programs to DefenderSwitch are LSADUMP and Mimikatz. These likewise exploit SeDebug privileges, but don’t have pasta in them 😉
Before we started our test, we asked ourselves: How will our hardened test systems react? We had two answers to that:
-
- If one performs system hardening according to the Microsoft or CIS benchmarks, DefenderSwitch should be successful. Because with these standards, it is recommended to restrict the SeDebugPrivileges only to members of the administrators group. So the privileges remain, just in a smaller circle.
- On systems that we harden to our own, stricter standards, DefenderSwitch is unlikely to succeed. Since we always remove the SeDebugPrivileges, the tool cannot obtain the necessary handles to impersonate TrustedInstaller.
We set up four systems with Windows 10 for our test:
| System 1 | Without System Hardening |
| System 2 | Hardening according to Microsoft benchmarks |
| System 3 | Hardening according to CIS-Benchmarks |
| System 4 | Combination of CIS, Microsoft and self-developed benchmarks |
Note: Unfortunately, when setting up the test computers and compiling DefenderSwitch, we encountered some problems that we could not solve in an acceptable time frame. Therefore, we switched to DefenderStop, which is basically a C# version of its C++ predecessor.
With DefenderStop, we were able to compile the software without any problems and achieve stable results.
The results of our tests
How did the systems perform against DefenderStop? Were you “cracked” or not?
System 1 – unhardened
We could literally hear the poor unhardened system crying in pain as it was robbed of its valuable Defender capabilities. Operation successful, patient dead.
System 2 – Microsoft hardening
As expected, DefenderStop lived up to its name: It stopped Windows Defender because hardening according to Microsoft recommendations was too lax in this case. This would knock out the “Windows guard” and allow cyber criminals to comfortably enter the system.
System 3 – CIS hardening
When hardening according to the CIS benchmarks, the result is the same: Windows Defender is successfully disabled by DefenderStop.
System 4 – FB-Pro hardening
Only on our very strongly hardened system did DefenderStop bite its teeth. Understandable, since there was no SeDebugPrivilege.
Conclusion
Ah, what a satisfying result! System hardening works – if you do it intensively enough.
Now we have two final questions for you:
-
- Do you know who in your company has SeDebugPrivilege?
- Guess what we have for dinner today 😉
– Update –
After our testing, Microsoft released a cumulative patch that removed TrustedInstaller as the owner. Even removing the patch does not bring this setting back.
But the bottom line of this article remains the same: SeDebugPrivileges are dangerous privileges! Abuse by special tools is still a given.
Do you need help with system hardening?
Do you want to harden systems professionally in your company? Our experts are here for you! Contact us without any obligation and we will get back to you as soon as possible.
Images: Freepik, Screenshots: Microsoft/FB Pro