App Review The Comodo's challenge.

It is advised to take all reviews with a grain of salt. In extreme cases some reviews use dramatization for entertainment purposes.
Content created by
Andy Ful

Andy Ful

From Hard_Configurator Tools
Thread author
Verified
Honorary Member
Top Poster
Developer
Well-known
Dec 23, 2014
8,593
Was the service stopped prior the reboot by the fileless attack (a pending service stop operation) or stopped by the fileless attack after the reboot? How would the fileless attack survive the reboot?

If you watch the video carefully, I show that the service is not stopped before the Windows restart.
There are many fileless persistence methods. The most known is hiding the malicious code in the Registry (not used in the video).
 

cruelsister

Level 43
Verified
Honorary Member
Top Poster
Content Creator
Well-known
Apr 13, 2013
3,224
First off, I LOVE the presentation style of the video! Easy to view, easy to understand.

The need to run the file as Admin is really trivial as it is no great inconvenience to code into a file an Admin bypass. The main question that I have is if the Script Analysis function of Comodo was enabled. Having it enabled (checked) is essential and was demonstrated in a video I did ~6 months ago ("The Importance Of Comodo's Script Analysis").

If it was indeed enabled then this would be problematic.

 

Andy Ful

From Hard_Configurator Tools
Thread author
Verified
Honorary Member
Top Poster
Developer
Well-known
Dec 23, 2014
8,593
First off, I LOVE the presentation style of the video! Easy to view, easy to understand.

Thanks, Mistress. :)

The main question that I have is if the Script Analysis function of Comodo was enabled. Having it enabled (checked) is essential and was demonstrated in a video I did ~6 months ago ("The Importance Of Comodo's Script Analysis").

Yes, it was enabled. The attack vector does not use scripts. I used a shortcut with CmdLines, and this could bypass Comodo's script analysis.
Of course, I tried scripts, but they were contained by Comodo. Also, the attack was blocked when I used PowerShell instead of CMD.
Comodo has a clever method to block PowerShell CmdLines. The CmdLine is converted to .PS1 script. The script is analyzed by Comodo and contained.

If it was indeed enabled then this would be problematic.

It is problematic.
 

rashmi

Level 12
Jan 15, 2024
578
Yes, it was enabled. The attack vector does not use scripts. I used a shortcut with CmdLines, and this could bypass Comodo's script analysis.
Of course, I tried scripts, but they were contained by Comodo. Also, the attack was blocked when I used PowerShell instead of CMD.
Comodo has a clever method to block PowerShell CmdLines. The CmdLine is converted to .PS1 script. The script is analyzed by Comodo and contained.
I'm no expert, but I wonder if the attack is like those that users posted in the past where the developers replied something like "Comodo allowed the user started...). I don't remember the developer's words or response, but it was like the @ErzCrz response in post #9: " if a unknown file executed a cmd or svchost or any other program that could execute the code to disable the virtualization that both the unknown file an any process or file launched by that unknown file would be Contained. Sure, a user can run that cmd line they create on their own"

Someone posted about this on the Comodo forums. Let's see what the developers say.

Again, I'm no expert, so this may sound stupid. I wonder if script analysis would have blocked the attack like PowerShell if, like PowerShell, "Embedded Code Detection" was enabled for CMD under Script Analysis - Runtime Detection.

65ef539766e11.png
 
Last edited:
F

ForgottenSeer 107474

It seems that it doesn't ring the Alarm-Bells at Comodo's, it not even worries them so it seems...
I have used Comodo Antivirus Cloud in the past with all these settings enabled (blocking cmd etc) and never ran into an issue. Comodo Cloud AV also had the containment / virtualization module of CIS
 
  • Like
Reactions: vtqhtr413

Andy Ful

From Hard_Configurator Tools
Thread author
Verified
Honorary Member
Top Poster
Developer
Well-known
Dec 23, 2014
8,593
I wonder if script analysis would have blocked the attack like PowerShell if, like PowerShell, "Embedded Code Detection" was enabled for CMD under Script Analysis - Runtime Detection.

View attachment 282093

If the "Embedded Code Detection" is enabled for cmd[.]exe the CmdLine is converted to the .BAT file, the Comodo Containment alert is shown, and the attack can be stopped by the user. This scenario is similar to the PowerShell case, except that for PowerShell the "Embedded Code Detection" is enabled by default. (y)
The "Embeded Code Detection" is just the CmdLine Whitelisting.

Anyway, the attack still works if another LOLBin is used. Even if you enable "Embedded Code Detection" for all LOLBins listed on the Script Analysis window, there are some not-listed LOLBins that still work in the attack.
 
Last edited:

ErzCrz

Level 23
Verified
Top Poster
Well-known
Aug 19, 2019
1,222
I suppose there's the option of adding all the .exe's under Win/System32 folder so they're all covered though I don't know what impact that would have. How many of them would be able to execute such a code really?
 

Fel Grossi

Level 13
Verified
Top Poster
Well-known
Jan 17, 2014
628
Response of @ozer.metin (Comodo Staff- Chief Innovation and Technology Officer)


Regarding mentioned video. Here HIPS module not only deny any malicious cmd execution but also protects CIS internal processes, keys, files etc. So here the analyst disabled it first using admin rights. After that point, none of the sensitive processes, keys, files are protected. I think “disable CF” script also writes to registry to stop cmdvirth.exe thats why he required a restart at that point. So basically he is also stopping containment too.

So if HIPS was not disabled by admin at first place, this case wont happen anyway. Even if that state if an Unknown application launching CMD, CIS would contain it whereas the user is launching it themselves.
So Its not a programmatic attack but user himself, on the computer is turning things off.
 

rashmi

Level 12
Jan 15, 2024
578
Response of @ozer.metin (Comodo Staff- Chief Innovation and Technology Officer)

As I mentioned in my post #28, "if the attack is like those that users posted in the past where the developers replied something like (Comodo allowed the user started...)"

There were similar posts on old forums where users reported they could disable Comodo, and the developers' reply was the same as @ozer.metin.
 

Shadowra

Level 37
Verified
Top Poster
Content Creator
Malware Tester
Well-known
Sep 2, 2021
2,630
It makes me happy to see a video of Comodo being bypassed by a developer :D
And yes, unfortunately, Comodo is clearly not infallible (no AV is anyway).

Just that it's pretty easy to bypass the Sandbox. I did it once a while ago by stealing the digital signature of a well-known program.
I don't know if it's been corrected now...

So when I see comments like "Comodo is the best antivirus" already there is NO such thing because NO antivirus will protect 100%.
 

Andy Ful

From Hard_Configurator Tools
Thread author
Verified
Honorary Member
Top Poster
Developer
Well-known
Dec 23, 2014
8,593
I suppose there's the option of adding all the .exe's under Win/System32 folder so they're all covered though I don't know what impact that would have. How many of them would be able to execute such a code really?
Not many, but you do not know which should be blocked. Furthermore, some external LOLBins can do the same.
 

rashmi

Level 12
Jan 15, 2024
578
It makes me happy to see a video of Comodo being bypassed by a developer :D
And yes, unfortunately, Comodo is clearly not infallible (no AV is anyway).

Just that it's pretty easy to bypass the Sandbox. I did it once a while ago by stealing the digital signature of a well-known program.
I don't know if it's been corrected now...

So when I see comments like "Comodo is the best antivirus" already there is NO such thing because NO antivirus will protect 100%.
Yes, no AV is infallible, but to be fair, this was not a bypass of Comodo, as responded by the team. They clearly mentioned how Comodo treats the command execution.

Yours is not a bypass of the sandbox. For that, the malicious activities should break out of the sandbox. Yours is more of a feature abuse, which would also be true for any AVs automatically allowing digitally signed programs. In other terms, it's like saying, "I bypassed an AV with a virus not present in its database." If you meant Comodo alerted for your signed program, you chose (run in containment), and the program generated files on the real system - then it's a sandbox bypass.
 

Andy Ful

From Hard_Configurator Tools
Thread author
Verified
Honorary Member
Top Poster
Developer
Well-known
Dec 23, 2014
8,593
Response of @ozer.metin (Comodo Staff- Chief Innovation and Technology Officer)

Regarding mentioned video. Here HIPS module not only deny any malicious cmd execution but also protects CIS internal processes, keys, files etc. So here the analyst disabled it first using admin rights. After that point, none of the sensitive processes, keys, files are protected.

Yes, as I mentioned in my second post, when the HIPS module is enabled this particular attack can be blocked. I am not sure if HIPS can block all LOLBins (internal and external) that can be used instead of CMD. I disabled HIPS not to make the attack easier, but because it is a pretty popular practice when the Auto-Containment is set to Untrusted. As we can see, there can be some cons of that.

Response of @ozer.metin (Comodo Staff- Chief Innovation and Technology Officer)

I think “disable CF” script also writes to registry to stop cmdvirth.exe thats why he required a restart at that point.

The attack does not use Registry for that.

Response of @ozer.metin (Comodo Staff- Chief Innovation and Technology Officer)

Even if that state if an Unknown application launching CMD, CIS would contain it whereas the user is launching it themselves.

The method from my video can be used as a part of lateral movement, by dropping and executing the shortcut (.LNK file) and the .DAT file. Unknown application is not required. The full attack can be more complex and can depend on the particular Comodo settings. It will be successful in some settings and will fail in others.

Anyway, the Comodo Staff- Chief is right. The purpose of the video was not to show a real attack, but to show that kernel drivers can be disabled from UserLand without using vulnerable drivers. I chose Comodo as an example. A similar method can work for other AVs and generally for security applications that use kernel drivers.

Edit.
Home users should not worry. I do not think that home users will be the targets. :) (y)
 
Last edited:

About us

  • MalwareTips is a community-driven platform providing the latest information and resources on malware and cyber threats. Our team of experienced professionals and passionate volunteers work to keep the internet safe and secure. We provide accurate, up-to-date information and strive to build a strong and supportive community dedicated to cybersecurity.

User Menu

Follow us

Follow us on Facebook or Twitter to know first about the latest cybersecurity incidents and malware threats.

Top