EQsecure HIPS Keep In Memory Processes

Can EQS like System Safety Monitor does keep certain processes "In Memory"?

This is an excellent feature i favored greatly in SSM and would like to see this in more HIPS such as EQSecure.

If by chance some malicious code shut down a certain app like an AV or any other security program this would be of enormous benefit. SSM would instantly restart that closed app non-stop into infinitely no matter how often it was looped to close.

Anyone also know of an app similar that works in that way for running processes that has self-protection itself but also restarts any apps you add from being permanently closed?

Thanks In Advance.

 

If a malware has got such an oppurtunity and great rights on ur system then I don,t think restarting the closed app will be of any benefit. It,s just too late IMO.

 

Hello EASTER,

The following application below will restart programs that have been disabled. I have no idea if it has self termination protection.

http://www.taskcatcher.com/

On the other hand, I believe that it is more important to prevent malware or malicious programs from terminating security applications in the first place. To that end, although a little bit off topic, for example, DefenseWall will protect other security applications from being terminated by malware that is unknowingly run as "untrusted"(default mode) or intentionally run as "untrusted"(expert mode).

Hope this helps.


Peace & Gratitude,

CogitoErgoSum


Peace & Gratitude,

CogitoErgoSum

 

Than you for the information CogitoErgoSum. I had no idea of this product. I'll be starting another thread, so as to not hijack this thread, about taskcatcher.

 

Certain core system executables are able to terminate processes when needed. I believe some of the processes involved in windows update can also do this. If an exploitable vulnerability were found in a core system process, it would be completely possible to use that core process to terminate security software, such as the firewall or AV. I don't know which HIPS prompt the user when a process tries to terminate another and allow the user to make rules regarding this. SSM does. I'd suggest all HIPS users look thru their rulesets and check which and how many processes have been granted permission to terminate another process, and check to see if it's really necessary to allow it during normal usage.

In several threads, the ability of HIPS and firewalls to resist termination has been explored. So has the ability to use apps like the paid version of SSM to protect other processes from termination. In an ideal world, malicious code wouldn't be allowed to run and wouldn't be trying to shut down security apps. In the real world, it does, and we're always trying to catch up to the ever expanding abilities and methods malicious code contains. It doesn't matter if it's done by a zero day exploit, good old social engineering. The result's the same.

Rick

 

IMO it,s not such a useful feature practically what Easter has asked.

Just think of a scenario. I am running an antivirus and SSM. A malware somehow terminates my AV, bypassing the AV and SSM. Now if i have a software that restarts my AV again, I am not going to get much benefit. There is a good chance that malware will bypass my AV again as it bypassed in the first instance.

 

As far as protecting a process from being terminated (or instantly restarting it) goes, how does that work with the protected app being updated? Avira, for eg regularly shuts down it's own services during updating, I imagine that SSM (or whatever) constantly restarting them would cause problems.

 

U can allow specific terminations by rules.

 

The "keep process in memory" option doesn't work well with AVs or with any app in which the update process can replace the executable files, which AntiVir\Avira often does. It will interfere with the update process. When I ran AntiVir with SSM, I opted to do the updating manually. For SSM to accomodate the auto-updating of AntiVir, the rules regarding all of the AntiVir executables have to be seriously weakened. Several have to be allowed to terminate processes and launch new ones that rules don't exist for. SSM has to be instructed to ignore MD5 signature changes on several of their executables. IMO, this opens up too many gaps in your defenses that can potentially be exploited. Imagine what kind of damage could be done if the AVs update server was compromised and started sending out malware instead of updated files. There are several instances of AVs being exploited and used against the PC they're installed on. If I remember correctly, NIS was once compromised to the extent that it was used to own the PCs it was installed on, and they were used in a big DDOS attack. With the increasing number of websites being compromised, including some run by AV vendors, it's only a matter of time.

Unless all the updating is done manually, AVs are not the best choice for using this option. The "keep process in memory" option is ideally suited for apps like the firewall, especially if you stay with a particular version. I use it with Kerio 2.1.5.

For this to happen, several conditions would have to be met.

1. The original malware isn't detected by the AV.
2. The user allows the malware to run, or SSM is configured so weakly that the unknown can be started.
3. The user or the SSM configuration allows the termination of processes.

A lot of the malware that attacks AVs will check for the processes of known AVs, then terminate the ones it finds. Most do not poll or continue to monitor the running processes afterwards. That will probably change as HIPS get more popular and others start using a similar idea. Same old arms race.

As for the advantages of restarting the AV, start with the question:
"Why would malware that isn't detected by the AV want to bother killing it?
Most likely, that malware will try to download other malware that an AV would detect, the main payload in the attack.

Assuming that the malware does recheck for an AV, you end up with a cycle of the malware repeatedly killing the AV and the HIPS restarting it every time. A stalemate. The malware can't bring in and launch the real payload because the AV won't stay down. In this scenario, the user wins because the attack doesn't finish, and sooner or later the user should notice all the extra activity. It would take some pretty advanced malware (or an actual person controlling the attack) to switch to another strategy in such a situation.
Rick

 

Thanks for all your inputs and i completely side with the concerns regarding AV's in these particular situations. I had in mind when i started this Topic to mainly just protect the firewall because malicious writers are always on an effort to get those defenses down (as well as AV's if they can), and single purpose firewalls (and maybe duo types) are likely candidates for such attacks to open up channels to infilitrate other potential problems.

I always respect opinions and experiences as been made here i appreciate the details and your time to point them out.

EASTER

Seems this app was suggested before to me once but i will definitely give it a more serious look and try it this time out.

Thanks