Advice Request Windows Defender disabled by malware

[Andy Ful]

After making several successful POCs and submitting them to Microsoft, I noticed the first signs of Defender's behavior-based detections. One of the executables involved in the UAC bypass is recognized as malicious (I did not submit it to Microsoft). That is good. But, after doing some unimportant changes in the code, the POC works again. Defender suspends two executables and checks them against the cloud backend. Next, the POC disables Defender successfully and runs a payload. I have also sent a message via LinkedIn to Cole Sodja (see the last Security Unlocked podcast) about this MT thread. It seems that Microsoft works on the "Automating threat actor tracking" to determine the scope of the compromise and predict how the attack will progress:

Automating threat actor tracking: Understanding attacker behavior for intelligence and contextual alerting | Microsoft Security Blog

A probabilistic graphical modeling framework used by Microsoft 365 Defender research and intelligence teams for threat actor tracking enables us to quickly predict the likely threat group responsible for an attack, as well as the likely next attack stages.

www.microsoft.com

Of course, "threat actors" are related to APT groups in the wild, so I do not think that someone from Microsoft will be interested in our thread (which is about the danger of the possible attack method). The interesting thing about this attack method is that the attacker can adjust the malware with minimum telemetry send to Microsoft. All files used in the attack (before disabling Defender) are not malicious and the attack can be detected only when the attack context is understood (it is not for now).

I did not submit the POC with UAC bypass yet. I am curious if Microsoft will be able to recognize from telemetry that something successfully bypasses UAC to disable Defender (it would be welcome). Usually, such bypasses are not urgent to Microsoft.

 

[TairikuOkami]

In the latest Dev Defender has become very persistent. I used to disable services, but it is no longer that simple, 3rd party AV has to be active and I have to restart. When I disable 3rd party AV to update tools like Nirsoft, Defender manages to enable itself, even though its services are disabled. From a security perspective that is great, from a user one, not so much.

 

[Andy Ful]

In the latest Dev Defender has become very persistent. I used to disable services, but it is no longer that simple, 3rd party AV has to be active and I have to restart. When I disable 3rd party AV to update tools like Nirsoft, Defender manages to enable itself, even though its services are disabled. From a security perspective that is great, from a user one, not so much.

If it enables itself then the user can simply turn off real-time protection from Security Center. If you do not use Defender in daily work, then you can also whitelist the Downloads folder and the folder where you keep your tools. You can use PowerShell for that. So, even if Defender reactivates itself, your tools will not be detected after downloading (until you do not execute anything).

 

[harlan4096]

I have no problems disabling completely Defender: Defender Control v1.8

 

[Templarware]

In the latest Dev Defender has become very persistent. I used to disable services, but it is no longer that simple, 3rd party AV has to be active and I have to restart. When I disable 3rd party AV to update tools like Nirsoft, Defender manages to enable itself, even though its services are disabled. From a security perspective that is great, from a user one, not so much.

So, one could argue that using a 3rd party AV is a good security feature. If your main AV gets disabled by malware, Defender will kick in. If you only use Defender, and it gets disabled by malware, you would be defenseless.

 

[blackice]

So, one could argue that using a 3rd party AV is a good security feature. If your main AV gets disabled by malware, Defender will kick in. If you only use Defender, and it gets disabled by malware, you would be defenseless.

3rd party AVs can also be disabled by malware if it is targeted to do so. Defender just happens to be one of the bigger targets.

 

[Templarware]

3rd party AVs can also be disabled by malware if it is targeted to do so. Defender just happens to be one of the bigger targets.

Again, you didn't read carefully I was talking precisely about the cases when the 3rd party AV could hypothetically get disabled by malware.

 

[blackice]

Again, you didn't read carefully I was talking precisely about the cases when the 3rd party AV could get disabled by malware.

My brain is somewhere else today, my mistake. That was a good point! Layered approach.

 

[ForgottenSeer 85179]

So, one could argue that using a 3rd party AV is a good security feature. If your main AV gets disabled by malware, Defender will kick in. If you only use Defender, and it gets disabled by malware, you would be defenseless.

AVs are never at first defense line

 

[Andy Ful]

I have no problems disabling completely Defender: Defender Control v1.8

It is usually detected as HackTool soon after pushing the new version.

 

[Andy Ful]

So, one could argue that using a 3rd party AV is a good security feature. If your main AV gets disabled by malware, Defender will kick in. If you only use Defender, and it gets disabled by malware, you would be defenseless.

Cybercriminals are not stupid. They know that Defender will kick in, so they will prepare the malware to dismantle Defender before it could kick in.

 

[Templarware]

Cybercriminals are not stupid. They know that Defender will kick in, so they will prepare the malware to dismantle Defender before it could kick in.

That would implicate them knowing that you have "two AVs".

 

[Andy Ful]

3rd party AVs can also be disabled by malware if it is targeted to do so. Defender just happens to be one of the bigger targets.

There are well-known possibilities of dismantling most AVs. It can be done by installing a vulnerable legal driver and then using 0-day malware to exploit this driver. The malware can access the Windows kernel in this way and affect the kernel locations used by AVs to monitor processes.
Furthermore, many AVs use also HIPS and other security layers which work in userland (via hooking). This can be also defeated by malware.

 

[ForgottenSeer 85179]

That would implicate them knowing that you have "two AVs".

They can check every AV with a simple script before starting malicious stuff.

 

[Andy Ful]

That would implicate them knowing that you have "two AVs".

If the attacker wants to dismantle the 3rd party AV, he already knows that on Windows 10 Defender is the default second AV.

 

[wat0114]

They can check every AV with a simple script before starting malicious stuff.

That's part of what an exploit kit does, I think?

 

[Andy Ful]

That's part of what an exploit kit does, I think?

This is also pretty common for many malware (not necessarily exploit-kits).

 

[wat0114]

This is also pretty common for many malware (not necessarily exploit-kits).

Oh I see, thanks!

 

[wat0114]

There are well-known possibilities of dismantling most AVs. It can be done by installing a vulnerable legal driver and then using 0-day malware to exploit this driver. The malware can access the Windows kernel in this way and affect the kernel locations used by AVs to monitor processes.
Furthermore, many AVs use also HIPS and other security layers which work in userland (via hooking). This can be also defeated by malware.

From what I typically read in malware analysis reports, the malware usually lands in user space, so wouldn't a properly configured HIPS or other such system hardening tool prevent the malware from launching and subsequently gaining elevated permissions?

 

[ErzCrz]

Would there be benefit in switching to If the user switches to profile "Windows_*_Strict_Recommended_Settings.hdc" to block also EXE (TMP) and MSI files in UserSpace? @Andy Ful