Does the firewall can detect when a legit process is being exploited (hollowed), i don't remember it does... So useless.
Comodo Embedded Code Detection -- What to Add?
- Thread starter shmu26
- Start date
Please provide comments and solutions that are helpful to the author of this topic.
- Status
- Jul 3, 2015
- 8,153
I am no expert on the firewall component, but I don't think it can detect process hollowing.
Firewall original purpose was to prevent inbound connections, years ago security vendors implemented outbound monitoring, but it was when calling home malware were simple and easily recognizable.
Now they are so sophisticated that outbound monitoring can barely detect them especially if they use some cryptic Windows processes.
Security is about preventing suspicious things to get in, if something try to get out, the battle is already lost, you are good to reformat your system.
Now they are so sophisticated that outbound monitoring can barely detect them especially if they use some cryptic Windows processes.
Security is about preventing suspicious things to get in, if something try to get out, the battle is already lost, you are good to reformat your system.
- May 4, 2018
- 2,261
- Jul 3, 2015
- 8,153
Hey, all the fun is in the bugs! Forticlient = no fun! LOLThink I'll be sticking to Forticlient for the time being then
~LDogg
- May 4, 2018
- 2,261
- May 29, 2018
- 2,728
- Apr 24, 2016
- 7,415
I don't have that kind of problems with the latest version 11.0.0.6728 with my config
Am I missing something or just lucky?
- Jul 3, 2015
- 8,153
I am guessing that you already made the necessary allow rules, before you updated to .6728I don't have that kind of problems with the latest version 11.0.0.6728 with my config
- Apr 24, 2016
- 7,415
Maybe, but don't remember that many blocks.
Unfortunately I can't find any logs to see what is allowed by the user
Would be great if we could compare that in a different thread.
- Jul 3, 2015
- 8,153
Just look in the firewall rules and see if there are any custom rules in there, or only the default global rules. If no custom rules, and everything works, then you are lucky. If there are custom rules, and everything works, then you are smart.Maybe, but don't remember that many blocks.
Unfortunately I can't find any logs to see what is allowed by the user
Would be great if we could compare that in a different thread.
- Apr 21, 2018
- 397
I have also Bitsadmin enabled, for embedded code detection, but i am not sure if it will make any conflicts with windows updates.Otherwise it will add to security.I disabled CMD due to many notifications.
- Apr 24, 2016
- 7,415
Thanks for pointing me in the right directionJust look in the firewall rules and see if there are any custom rules in there, or only the default global rules. If no custom rules, and everything works, then you are lucky. If there are custom rules, and everything works, then you are smart.
I'believe I'm more lucky than smart according to your definitions
:
Edit: removed all the custom rules.
After a reboot I had to add Kaspersky (avp.exe) and OneDrive to my custom rules because they were blocked by the firewall.
Thanks again @shmu26 Will see how it goes from here...
Last edited:
- Jul 3, 2015
- 8,153
I don't think that adding bitsadmin will do anything. Embedded code detection works with interpeters that have a file type associated with them, so the code can be written to file, but that's not the case with bitsadmin.
- Apr 21, 2018
- 397
Thanks, i was reading in Trend Micro Forum that a variant of Locky used bitsadmin and some other malware.
- Jul 3, 2015
- 8,153
Yes, you are right, bitsadmin can definitely be abused. It is used by malware to download the payload. Unfortunately, Comodo embedded code detection cannot block it, AFAIK.
What does it make a difference if an alert tells the user that it is wscript or *.vbs attempting to connect out to the network ?
Without the user knowing anything, what it says in an alert doesn't matter; a user has to study the extended list.
The HIPS can already do what embedded code does. The only difference is the alert is the attribution.
Messing about with COMODO's stuff, thinking it will be awesome, is a waste of time. You can create rules only to have them randomly disappear. So many people here have confirmed it.
Without the user knowing anything, what it says in an alert doesn't matter; a user has to study the extended list.
The HIPS can already do what embedded code does. The only difference is the alert is the attribution.
Messing about with COMODO's stuff, thinking it will be awesome, is a waste of time. You can create rules only to have them randomly disappear. So many people here have confirmed it.
Bitsadmin connecting out is attributed to SYSTEM.
Bitsadmin has virtually no legitimate purpose on home user systems and should be disabled. In fact, bitsadmin is deprecated by Microsoft.
- Jul 3, 2015
- 8,153
If Comodo is working correctly, the user will not normally get any firewall alerts. So when he does get one from some wierd process he never heard of, he might think twice. And if he has followed CS's advice, he has set the firewall to block without alerting.
So let's say I mark bitsadmin as unrecognized. Normally, an unrecognized process will generate an alert. That won't work with bitsadmin, because it will be seen as SYSTEM? Is this only as regards firewall actions? Or does it mean that as soon as bitsadmin executes, it is already seen as SYSTEM, so no rule to block bitsadmin will work?
1. You will never get any alert from COMODO because the interpreters and sponsors are trusted. It's ridiculous that all the AVs treat interpreters and sponsors as trusted. When Microsoft explicitly advises that they be disabled if not needed. Obviously they're running amateur night.
2. The COMODO documentation states the only difference is in the alert and what is attributed.
3. CS' advice to block outbound firewall only applies to sandboxed processes. That means exploit\malicious code can still be downloaded outside of the sandbox on the real system and run, for example in a memory buffer. It will more or less use trusted Windows processes and the system is hacked.
4. Bitsadmin connecting out on the network is attributed as SYSTEM. You have to block SYSTEM.
Bitsadmin is deprecated by Microsoft. It shouldn't even be enabled on anyone's system.
5. There is only one way to protect systems - and that is to follow Microsoft's own advice - which is to disable what is not needed. 99.999 % of home users across the world do not need the usual suspects. Microsoft is irresponsible and negligent in shipping Windows with them enabled or even included at in Windows for the masses.
- Status
Similar threads
