App Review BYOVD attack - CIS case

[Andy Ful]

Content source

https://youtu.be/wU-BcQOPSkA

Bring Your Own Vulnerable Driver attack - CIS case.

Most readers can skip the part of the video from 1:34 to 7:18, which is about the CIS settings.



This video is an example of targeted attack on the AV via vulnerable driver + external LOLBin + UAC bypass.
That attack silently compromises the system and will dismantle the AV protection after Windows restart.
The method used is well known and I used Comodo Internet Security 2025 (CIS) as an AV example.
The information needed to perform such attacks is publicly available on the web.

Attack flow:
ISO file ---> user opens it and runs the content ---> system silently compromised
No UAC prompt, no Comodo alerts.
The user can see that something is wrong only after restarting Windows.

A similar type of attack can be done against any AV. It is different from "AV challenge" POCs used by me in the
series of videos on the MalwareTips forum to dismantle the AVs protection.

Edit.
The attack is different from Kill-floor malware (different execution method and driver):

Hackers abuse Avast anti-rootkit driver to disable defenses

A new malicious campaign is using a legitimate but old and vulnerable Avast Anti-Rootkit driver to evade detection and take control of the target system by disabling security components.

www.bleepingcomputer.com

The Kill-floor malware can be easily contained by Comodo, so no Comodo products are on the target list of that malware. Bypassing Comodo requires non-standard execution methods to bypass auto-containment and Script Analysis.

 

[Bot]

Thanks for sharing this informative video. It's a stark reminder of the importance of keeping systems updated and regularly checking for vulnerabilities, even in trusted anti-virus software. The "silent" nature of this attack is particularly concerning.

 

[Victor M]

@Bot, most attacks are silent. Where did you learn that attacks makes noise?

 

[simmerskool]

I have not watched the video yet, if the answer is in the video, is there a defense to this attack eg Andy Ful's tools...

 

[Sandbox Breaker]

@Andy Ful
Does this work on a system with elevation disabled on a LUA? We obviously have app control and lolbins locked down and monitored but I want to know only in relation to this working on a standard account that cannot elevate.

 

[Andy Ful]

@Andy Ful
Does this work on a system with elevation disabled on a LUA? We obviously have app control and lolbins locked down and monitored but I want to know only in relation to this working on a standard account that cannot elevate.

What do you mean by "elevation disabled on a LUA"?
If you meant the UAC setting ValidateAdminCodeSignatures = 1 (unsigned programs cannot elevate), it is bypassed with any UAC bypass (also from the video).

 

[Andy Ful]

I have not watched the video yet, if the answer is in the video, is there a defense to this attack eg Andy Ful's tools...

Yes, the SRP settings used in WHHLight and H_C would prevent the attack from the video. However, the attacker who knows the settings used in WHHLight or H_C can probably adjust the attack to bypass the protection in the Enterprise environment. It would be hardly possible against the home user, but home users can hardly be the targets of such attacks.

 

[Vitali Ortzi]

Yes, the SRP settings used in WHHLight and H_C would prevent the attack from the video. However, the attacker who knows the settings used in WHHLight or H_C can probably adjust the attack to bypass the protection in the Enterprise environment. It would be hardly possible against the home user, but home users can hardly be the targets of such attacks.

Does the system have to reboot in order to load the malicious driver and disable an antivirus?
Could you do any damage until a reboot?
Would be interesting if you make it into a full attack

 

[Andy Ful]

Does the system have to reboot in order to load the malicious driver and disable an antivirus?

Yes.

Could you do any damage until a reboot?

Yes. After reboot, the system is unprotected for a few minutes, until Microsoft Defender is reactivated. The attacker could also add the code to dismantle Microsoft Defender.

Would be interesting if you make it into a full attack

It is an attack, with a skipped delivery part. The malware can be delivered from a flash drive, local network share, etc. I cannot make a video about malware delivery in the Enterprise environment. It would require the access to the Enterprise network.

I could add the delivery part in the non-enterprise environment, but non-enterprise users can hardly be the targets.
Anyway, if you are interested, the possible attack flow could be as follows:

Email with URL ----> user downloads the password-protected RAR archive ----> user extracts the open_me.iso from the archive ---> the rest is just like in the video

Comodo cannot detect files until the open_me.iso is mounted and it follows from the video, that it could not also detect/block what happened next.
Of course, the attacker must use the URL that is not blacklisted.

 

[ErzCrz]

Nice video.

Was this driver automatically added as trusted?

I think any AV will scan/check/ or in the case of Comodo, contain the "delivery" file but given that you ran it from a CD, just proves that wrong. I don't really know whether this is an AV issues or an OS issue and not sure disabling UAC with Comodo is the safest solution.

I do wish Enable automatic startup for services installed in the container was disabled by default in the Containment settings but I do like that there's an option in Device Control to block access to peripherals.

This topic posted yesterday where malware abuses drivers quite interesting : Hackers abuse Avast anti-rootkit driver to disable defenses

It's good that your demonstrating the issue with AVs these days. I'd love to see how Emsisoft fares.

 

[Andy Ful]

Nice video.

Was this driver automatically added as trusted?
View attachment 286405

Yes.

I don't really know whether this is an AV issues or an OS issue and not sure disabling UAC with Comodo is the safest solution.

It is a bad idea that cannot help much and may hurt severely.

I do wish Enable automatic startup for services installed in the container was disabled by default in the Containment settings but I do like that there's an option in Device Control to block access to peripherals.

It does not matter in the attack, because it was not contained.

This topic posted yesterday where malware abuses drivers quite interesting : Hackers abuse Avast anti-rootkit driver to disable defenses

Yes, it is one of many examples. But, the above method would be blocked by CIS. Most attacks (also BYOVD) that are successful against popular AVs will fail against Comodo.
However, some deadly attacks against Comodo can be easily detected by popular AVs. For example, the attack from the video is blocked by Microsoft Defender (UAC bypass) or Avast (vulnerable driver).

It's good that your demonstrating the issue with AVs these days. I'd love to see how Emsisoft fares.

Any AV can be bypassed via a targeted BYOVD attack. One only has to adjust the attack to the target.

 

[ErzCrz]

Yes, it is one of many examples. But, the above method would be blocked by CIS. Most attacks (also BYOVD) that are successful against popular AVs will fail against Comodo.
However, some deadly attacks against Comodo can be easily detected by popular AVs. For example, the attack from the video is blocked by Microsoft Defender (UAC bypass) or Avast (vulnerable driver).

Any AV can be bypassed via a targeted BYOVD attack. One only has to adjust the attack to the target.

Thanks for the clarification / explanations.

 

[Sandbox Breaker]

What do you mean by "elevation disabled on a LUA"?
If you meant the UAC setting ValidateAdminCodeSignatures = 1 (unsigned programs cannot elevate), it is bypassed with any UAC bypass (also from the video).

Disabled elevation for standard accounts

 

[Andy Ful]

Disabled elevation for standard accounts

Understand. You probably mean the UAC setting ConsentPromptBehaviorUser = 0. This setting will fully block the UAC bypass from the video. However, ConsentPromptBehaviorUser = 0 does not disable the elevation but blocks the possibility of entering the credentials via the UAC credential prompt on SUA. This can be bypassed if the attacker knows the Admin password and can pass it through without using the credential prompt.

Technically, process elevation is impossible on SUA. To elevate, the process execution must be redirected to the Admin account. In Windows, this is usually done via the UAC credential prompt, but there are other possibilities too. After entering the credentials the process runs with high privileges on the Admin account.

Anyway, the UAC bypass in the video uses the auto elevation feature of the Windows system process. This method will not work on SUA even on default UAC settings (elevation tweak for standard accounts is not required). Next, the malware can behave in three ways:

1. It will run with standard rights on SUA.
2. It will refuse to run.
3. It can trigger the UAC credential prompt (POC from the video, blocked by ConsentPromptBehaviorUser = 0)

 

[simmerskool]

Email with URL ----> user downloads the password-protected RAR archive ----> user extracts the open_me.iso from the archive ---> the rest is just like in the video

timeout @Vitali Ortzi PM'd me a rar file the other day (was this an unannounced "test" as I'm reading this a day late)...