App Review The Comodo's challenge.

[Nikola Milanovic]

So Xcitium Auto-Containment is the strongest right?

 

[cruelsister]

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.

​

 

[Pico]

Does this fileless attack need a script? Could it be executed as plain zero-day code instead?

 

[Andy Ful]

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.

 

[Andy Ful]

Could it be executed as plain zero-day code instead?

Yes, it could.
But no worry. I will keep the secret to myself, except if a Comodo staff will be interested.

 

[simmerskool]

Xcitium is the best AV

I was interested in putting it on VMware win10, but for unclear reasons before I downloaded it, xcitium sales people started calling me to the point of annoyance. I backed away.

 

[rashmi]

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.

 

[Pico]

It seems that it doesn't ring the Alarm-Bells at Comodo's, it not even worries them so it seems...

 

[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

 

[Andy Ful]

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.
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.

 

[ErzCrz]

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]

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

Comodo Bypass by CMD file

App Review - The Comodo’s challenge. | MalwareTips Forums In this conversation, a user manages to stop Comodo services using a CMD shortcut. as he describes in conversation. He said he is willing to help Comodo if they want to fix the problem.

forums.comodo.com

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]

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

Comodo Bypass by CMD file

App Review - The Comodo’s challenge. | MalwareTips Forums In this conversation, a user manages to stop Comodo services using a CMD shortcut. as he describes in conversation. He said he is willing to help Comodo if they want to fix the problem.

forums.comodo.com

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]

It makes me happy to see a video of Comodo being bypassed by a developer
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]

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]

It makes me happy to see a video of Comodo being bypassed by a developer
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.

 

[Pico]

What do we learn from Comodo's response?
When HIPS was enabled with Proactive config then this attack would have failed?

 

[Andy Ful]

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.

 

[rashmi]

What do we learn from Comodo's response?
When HIPS was enabled with Proactive config then this attack would have failed?

Yes, this is what the team meant. Also, the team meant Comodo would prevent such an attack from an unknown program even if HIPS was in the disabled state.

 

[Pico]

I always use HIPS module enabled.