there is a topic posted on malwaretips.com by one of the members , that a signed piece of malware bypassed cfw 10.
he posted a youtube link where he demonstrated the bypass :
here is what he did in his test :
check Comodo firewall settings
delete all trusted vendors
add some malware to see if Comodo is working OK
check that one malware at VT
run malware and watch:
C:\Users\Av-Gurus\AppData\Local
Task manager startup
network connection
he later did his test with hips module turned on , but the outcome was the same.
the firewall was configured , what has been commonly known as " cruelsisters settings " , which are as follows :
I did not see or was not aware enough, but you did not check the “file list”. Comodo may have classified the file as trusted (it seems, the option does not display alerts > block requests, is only valid for unknown files). Fortunately or unfortunately, this error of practicality is not exclusive to the CIS
As the user said Umbra Polaris, if you turn off cloud scanning when you install the program, you may be alerted or have the file blocked.
This should be the SHA256 signature: 190d5c8de27115b98484d653dff246fc05ce02ac69fedd009e469d7535f3faeb
While this should be the VT report of the file: VirusTotal
From what I see, Comodo AV today can intercept the file as TrojWare.Win32.Emotet.~AO with the signatures (here a more recent report).
Anyway, even if the malware isn’t trusted anymore, the entire CIS solution was bypassed because the file was Trusted by Comodo.
The entire issue was that the file was listed as Trusted (obviously a mistake). When the original malware was run it was allowed to create a directory in AppData/Local, drop the payload into it, and then set itself up for boot persistence. The file itself is just a garden variety info-stealer; similar malware are all blocked, and any manipulation to this file will also be blocked.
It is important to note that in order for any sort of info stealer to work it must be allowed to access the network to send stolen data to Command. In the case of this malware even though it was allowed to drop and autostart, the firewall stopped transmission of any data by the malware as it blocked the initial connection to a Paris server which in turn would route stuff to Command (also blocked is a connection to a server in Atlanta with recently has been a favorite for a bunch of other info stealers). So although the dropped payload remained in memory, it essentially was just hanging out looking stupid.
(note to Kronos- as of 1 minute ago if one uses Comodo Firewall there would be no AV alert at all. And since I’m already here, do the developers realize that the Firewall component of CF initially blocks vkise.exe from connecting to Comodo? I personally could care less, but it will seem odd to newbies…).
The malware was blocked by the Firewall from connecting out, so nothing malicious occurred. It was a mess up for this one particular file so the World will not End.
And I’ve never seen something like this before, so it certainly is not a repeating issue.
Hi cruelsister,
I already followed the MT thread from the origin.
I made the AV detection digression just to conclude that, since the file is detected as malware, probably has already been removed from the trusted list by Comodo. Sad to know it’s not the case.
BTW I don’t know how exactly the cloud lookup works, I doubt it’s directly linked with AV database but I was hoping these kind of updates to be spread quickly, since they are unusual but make uneffective all layers. Sad to know it’s not the case either.
Just curious how things work: if the file was seen as trusted, why did firewall block it? Aren’t trusted files automatically allowed internet access, when firewall is in safe mode?
K- for whatever reason there is a discrepancy between what CIS and CF will detect on file run. For instance, in the last video I made CIS would have detected and deleted 5 of the 9 samples I used, whereas CF only detected 1. Personally I could care less as all 9 were contained in the sandbox anyway and resulted in zero system changes.
Also, I just let the malware file that this topic is about for a few minutes and noticed 35 Firewall blocks! Poor malware- try as it might it just can’t connect to Mama!
M
Shmu- just saw your post- although the original malware file was trusted remember that this was just the carrier for the payload; the actual dropped payload (workflowscroll.exe) is what was stopped by the Firewall from connecting out.
Addendum- CF just detected the original file by the Cloud AV.
Cloud lookup is linked to the AV by hash only. Also PUA are detected by cloud lookup if the file rating setting “detect potentially unwanted applications” is enabled.
Correct the do not show alerts setting only applies to situations when an alert would be shown to ask the user if action should be allowed or blocked for applications rated as unknown or malicious when set to safe mode. In this case the dropped executable was the application that was trying to connect to the internet and was blocked. The dropper was accidentally rated as trusted but it drops another file that was rated as unknown.
I think I get it now. The payload, although rated as unknown, was able to run because it started early, before Comodo protection kicked in.
But it was not able to make an internet connection that fast, so Comodo firewall blocked it.
I’m not sure why this tread even exists? This a problem for any security software that is based on white listing approach. Because of possible mistakes there is even specific topics to report such errors when malware is incorrectly whitelisted.
This is not a digitally signed application. Trusted vendors have nothing to do with this, the file was whitelisted by file hashes. I also encountered a similar sample of the same class (Emotet - basically a banking trojan) which also copied a file to appdata and was whitelisted. The variant that I submitted has been blacklisted now.
On a side note I have tried removing the Trusted Vendors List. It seems that with cloud lookup enabled, it still checks the TVL in the cloud (vendors that are found trusted by cloud scan are added back to the TVL), so removing TVL with cloud lookup enabled is basically pointless. If you were to disable cloud lookup and remove TVL it might result in system files being sandboxed if you aren’t careful, and of course usability is impacted.
Well, most whitelisting solutions that I know of (NoVirusThanks EXE Radar Pro, VoodooShield, SecureAPlus, ReHIPS) don’t have a hidden and constantly updating whitelist that is prone to error. At the most, they have a limited Trusted Vendors List that the user can easily monitor.
However, now that I think about it, your point is quite valid as regards Avast hardened mode/aggressive, and Kaspersky Trusted Applications Mode
Which are default-allow AVs with a feature to act like default-deny ones
If you have a stable PC (meaning you don’t install new apps because you are fine with the ones you already have), you can disable cloud lookup and remove every entry in the TVL but the ones about Microsoft (and few other apps you use), as shown in this video (from cruelsister) Comodo and Trusted Vendors List - YouTube
The problem with CIS is that TVL will be restored when CIS upgrades to a new version (and also when you import your settings), unless they have fixed this bug
