What do you think of this test?
It looks like it didn’t go well and the PC was encrypted:
Looking at it, it appears it might have been a bypass.
However would need more information though to know if it was or not.
Would need to know:
- All Settings
- Sample that caused the file changes
It should also be noted that even though HIPS possibly warned the user that they were about to run an unknown file (can’t read Russian so I’m not sure), the person in the video seemingly selected to run it.
That said, it was the seemingly recommended action in green (can’t read Russian so not sure what the text recommended if anything), so you can’t really blame the user if HIPS was recommending that, if it was that which caused it.
So it was better if HIPS was disabled. Only automatic containment would have intervened without running the risk that the user would have made the choice to click on the green button.
Would need to know the settings and sample used to see what happened.
Otherwise we are just speculating.
Yes of corse
I don’t understand something in that video…
At time point 13:41 the desktop in the video suddenly changes to black with the red text message “ATTENTION! … disks were encrypted …”.
What action did cause that screen to show up actually?
It seems that the protection has gone off and the Windows 10 message has come out … at least it seems so to me …
Could it be that the files already were encrypted before CIS / HIPS started popping up those Alerts?
HIPS as far as I know should not prevent Auto-Containment from working.
As far as I can see, if it was the user clicking to run the file(s) from the HIPS popup(s), clicking to block it might have prevented it.
I would have HIPS turned on, then block any unknown files from running until we know more.
I’m trying to say that maybe it wasn’t CIS fault after all and that the files/disks already were encrypted.
However I’m not sure about this, the video is not very clear to me.
At minute 3:26 you can see the Tester moved/extracted all Malware packs into the ‘Downloads’ folder which is set by default as an exception at ‘Do not virtualize access to the specified files/folders’ (Shared Space file group). This explains why Containment failed to prevent encryption.
It is always better to leave HIPS Enabled - CIS self-protection is stronger with it enabled than with it disabled… Set it to ‘Do not show Popup alerts: Block Requests’, Safe Mode should be OK - it will never alert for files signed by Trusted Vendors or Trusted by Cloud Lookup.
HIPS has nothing to do with recommendations or anything like that, just warning then u choice
:P0l
I don’t think the Desktop is included in this, however it does appear that files were dropped onto it and background changed.
Nothing to do with HIPS or containment settings, I’m willing to bet it was somehow trusted by file lookup, until we can get the sample its pointless to speculate further. This isn’t the first time a video from this channel doing same testing, had a sample modify the file system instead of being run in containment.
For any interested, I’m fairly certain that the ransomware in question is a Shade variant, specifically crypted000007 (widely available at the usual places as it it a few years old). A short video is here: AppCheck Anti-Ransomware : Shade Ransomware (.crypted000007) Block Video - YouTube
Regarding how Comodo handles it, even at the lowest containment setting running the malware results in no system changes.
No clue what settings/methods the video author used.
Indeed not the first time and I’ve noticed they always extract/execute the Malware files from the Downloads folder in every test, which is clearly a mistake. But like you said, without the sample anything is speculation.
IMO Comodo Staff should contact this Youtube channel to request infos on what actually happened in both situations… The reputation of CIS is being damaged with such testing results.
Safemode- With containment enabled it doesn’t matter from where the malware is run (downloads or desktop or usb). But if you are referring to the Containment setting of “Do Not Virtualize Access to” being enabled or not enabled, this makes no difference malware run from within the Download directory will be virtualized no matter if the setting is checked or unchecked. The Default setting will allow contained applications to make changes to this folder; unchecking it will protect the folder from being modified.
As to what happened in that video test, the malware that infected the system was the Shade variant (crypted000007) as I mentioned above:
SHA256: dba88e22f0763e2475c366c066928d5df4b507366598e76bc45f85d056d9bc5c.
Why Comodo will stop this one on every system in the world with the exception of the one used in the video I will leave to others to discuss, but I don’t think that Comodo is in any way damaged by the video.
Crucial to know is: What happened to and on the test system of the video author during the time of the video transition effect at time stamp 13:40? Nobody can answer that.
Thanks for explaining, actually this exception rule for Downloads folder being at fault was just a wild guess on my part, as with everybody else, since we can’t know more details regarding the testing procedure.
The Malware file which you mentioned, SHA256:dba88e22f0763e2475c366c066928d5df4b507366598e76bc45f85d056d9bc5c, SHA1:267a1fa4679624d3f998bddeaa3ef18438db3258 is indeed rated as Unknown by both Valkyrie File Verdict and Comodo File Intelligence.
I still maintain that Comodo Staff should contact the Youtube channel in question to request information and discover what actually happened, especially since this is not the first time a similar result (infection/encryption) is achieved in a test from this channel. This would shed some light over this mystery…
Protection of Comodo internet security is preventive, in other words, comodo internet security detect and prevent action malicious from spywares; :-TU
Other security softwares detect, but not prevent as comodo internet security…