App Review Malware Obfuscation- Part 2

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
cruelsister
The video is a demonstration of Comodo's capabilities to prevent many evasive malware that can sometimes bypass popular AVs.
This follows from its different approach to malware fighting.
However, Comodo does not have some features that are included in Xcitium for good reasons.

It would be interesting to test the malware, which is the reason for the extended Xcitium protection.(y)
Comodo may fail on some malware that is prevented/detected by popular AVs, which can follow from its different approach to malware fighting.

Here is an example of malware in the wild that could infect Comodo while detected by some popular AVs (including MD):

1770202428889.png

1770202343281.png

The malware (Shai-Hulud) was active in November 2025. The malicious code is contained in the JS script executed by trusted web applications. The attack does not use Windows Script Host or LOLBins, so it cannot be prevented by Comodo's Script Analysis Module.
A similar attack (via malicious Node.js) can be done by abusing legal Electron applications (like older versions of Microsoft Teams).
 
The logic of sandboxing (containment) over outright blocking is rooted in Business Continuity and Threat Intelligence. While blocking an "Unknown" file is more restrictive, it frequently results in false positives that halt legitimate work. Containment allows a file to execute in a virtualized state where it can be observed and verdicted without risking the host system, effectively eliminating the "patient zero" problem while maintaining productivity.
Blocking or allowing to run within a hardened container depends upon the mandate which governs the system. If the system is a:

NURO
SCS
GRS
NGA
DI
JIO
NCF
DSTL

system, as a limited subset of IC/'CI agencies, then 100% whitelitsting is required. As in the "absolutte" definition of whitelisting. Translation= Block ALL by Default, Allow Only AFTER An Extensive Vetting Process by Exception:

A. Identified
B. Documented
C. Vetted initially and continuously
E. Monitored continuously
F. Protected from modification
G. Audited 24/7
H. Other stuff

Software is really just a collection of artifacts that together make a program run. Some are executable, some are configuration, some are data, and some are supporting resources. There’s no single “official” complete list because different platforms use different components, but you can map out the full landscape of what software is typically made of.

The fact that an object has been published and signed my Microsoft and resides in C:\Windows\System?? matters not a jot.

There are many tools used to perform what is required and they work well, but human eyeballs are mandated the final verdicts.

Since this is all about playing with civilian meatspace security software I will leave it at that.

For MT and lesser types, Melih figured out that a virtual container solves almost the full extent of human behaviors that are dangerous. He performed what Charlie Munger figured out but applied to cybersecurity:

Charlie Munger used the term “Lollapalooza” to describe situations where multiple psychological biases act together, reinforcing one another so strongly that they produce extreme, irrational, and often disastrous human behavior.

 
For MT and lesser types, Melih figured out that a virtual container solves almost the full extent of human behaviors that are dangerous. He performed what Charlie Munger figured out but applied to cybersecurity:
Two questions: Are you Melih's shrink? How come you know all his thoughts and considerations?

Charlie Munger comparison needs explaining in this context:
A) Do you mean Melih is the example of Charlie Munger's key take away (what cyber security companies often do WRONG, but better should NOT do)? or
B) Are you saying Melih is the best practice example on how a feasible ROI based innovation strategy should be implemented?
 
Last edited:
The malware (Shai-Hulud) was active in November 2025. The malicious code is contained in the JS script executed by trusted web applications. The attack does not use Windows Script Host or LOLBins, so it cannot be prevented by Comodo's Script Analysis Module.
A similar attack (via malicious Node.js) can be done by abusing legal Electron applications (like older versions of Microsoft Teams).
Actually Comodo stops this worm quite efficiently. Once thrown off by whatever application it was woven into, once spawned Version 2.0 (bin_enviornment.js) gets contained and will error out once there.
 
Actually Comodo stops this worm quite efficiently. Once thrown off by whatever application it was woven into, once spawned Version 2.0 (bin_enviornment.js) gets contained and will error out once there.

Are you sure that Comodo had blocked the attack 8 days ago (as it was shown in my post)?
Which of Comodo's features makes it currently autocontained?
I saw examples of attacks that used PowerShell or CMD in some stages of infection. Comodo's Script Analysis can mitigate such attacks.
The problem is when the attack does not use LOLBins or uses LOLBins not included in Script Analysis.
However, this also shows that Comodo can be quite effective, because the attackers often use LOLBins already included in Script Analysis.(y)

Post corrected.
 
Last edited:
Are you sure that Comodo had blocked the attack 8 days ago (as it was shown in my post)?
Which of Comodo's features makes it currently autocontained?
This version 2.0 sample I had was from the beginning of December. As it was but a JavaScript code, it was autocontained as would any other malicious JScript (eg MyLittlePony)= barely an inconvenience.