Primary Response SafeConnect Update

For all of those who are interested,

With Shadow Defender enabled and DefenseWall disabled, under Vista 32 I tested PRSC product version 3.0.0.1443 configuration version 159 against the following malware samples.

Prueba/Bifrost Trojan - Detected(Quarantined)
SohandIM Worm - Detected(Quarantined)
SSDT Unhooker Rootkit(http://membres.lycos.fr/nicmtests/Unhookers/unhooking_tests.htm) - Detected(Quarantined)
Brontok Worm - Detected(Quarantined)
Zilla( Browsezilla) Trojan/ Worm - Detected(Quarantined)
W32/ Virut.P Trojan - Detected(Quarantined)
Qucan IM Worm - Detected(Quarantined)
POC Malware(https://www.wilderssecurity.com/showthread.php?t=195340) - Detected(Quarantined)
Bot Trojan Malware(Nugache, Rizo & Storm) - Detected(Quarantined)


Peace & Gratitude,

CogitoErgoSum

 

Hi,

Perhaps a stupid question, but I´m not real familiar with this tool, so are these malware samples detected by signature or by behavior?

 

Antibot doesn't have signatures. It gives names to malware if they fit a specific set of actions, but they're just names, not signatures.

 

Hi,

Nice to know that PRSC can intercept those malwares.

Would Shadow Defender remove these malwares w/ DW and PRSC's absence upon reboot?

I think PRSC/AntiBot has improved quite a bit.

 

To make a correction to my post(#26), I hastily by mistake included "Rbot" to the list of bot trojan malware tested. I have made the necessary changes.


Peace & Gratitude,

CogitoErgoSum

 

Hello Perman,

Yes, Shadow Defender(SD) will remove all the above malware after a reboot with both DefenseWall and PRSC disabled or uninstalled. FYI, I primarily use SD for testing malware.


Peace & Gratitude,

CogitoErgoSum

 

For all of those who are interested,

With Shadow Defender enabled and DefenseWall disabled, under Vista 32 I tested PRSC product version 3.0.0.1443 configuration version 159 against the following malware samples.

Gozi Trojan Family:
LdPinch.BSG - Detected(Quarantined)
CWS.D - Detected(Quarantined)
CWS.E3134899 - Detected(Quarantined)

PRG Tojan Family:
ntos - Detected(Quarantined)


Peace & Gratitude,

CogitoErgoSum

 

Hi,

Good to know again.

A new breed of anti-malware weapon has born.

Those signature-based ones even with tireless efforts will be replaced by this new approach one day ?

 

For those who are interested,

With Shadow Defender v1.1.0.237 enabled and DefenseWall v2.21 disabled, under Vista 32 SP1 I tested PRSC product version 3.0.0.1443 configuration version 165 against the following malware samples.

Rustock Rootkit Family:
Rustock.M - Detected(Quarantined)
Rustock.NBS - Detected(Quarantined)

Srizbi Trojan/Rootkit Family:
Srizbi.AC - Detected(Quarantined)


Peace & Gratitude,

CogitoErgoSum

 

I think the real test is in running without ShadowDefender and DefenseWall, since the former can significantly cripple malware (I've had instances where a malware is undetected when not sandboxed and vice versa), while the latter makes one oblivious to PRSC's sometimes very atrocious cleanup abilities. Also,

Unless they've added MBR protection recently, I severely doubt this.

 

Hello solcroft,

While I acknowledge that PRSC does not protect against low level disk access intrusions(MBR, etc...), believe it or not, it does in fact flag this POC malware(https://www.wilderssecurity.com/showthread.php?t=195340). On the other hand, I have tested PRSC against both the MBR rootkit and killdisk and it fails in both cases.

With Shadow Defender v1.1.0.237 enabled and DefenseWall v2.21 disabled, under Vista 32 SP1 I retested PRSC product version 3.0.0.1443 configuration version 167 against the POC and got the same results. Feel free to test this POC against Norton AntiBot or PRSC for yourself.


Peace & Gratitude,

CogitoErgoSum

 

Just out of curiosity, did you run any other tool like blacklight or rootkit revealer after detection to make sure the rootkits were removed? Some variants of rustock are notoriously difficult to remove completely.

Cheers!

 

Hello grumbleduke,

Unfortunately, I did not run any rootkit detection tools to verify that PRSC removed all traces of the Rustock variants. In any case, Shadow Defender which virtualized the testing session, restored my computer to malware-free condition after a reboot.


Peace & Gratitude,

CogitoErgoSum

 

In that case it's worse. Here we have a product flagging a POC test and giving users a false sense of security, while failing against actual ITW malware.

I'll try this out as soon as I get the chance.

 

Thanks for clarifying this, solcroft. I must admit that I have always suspected these kind of tools from adding some kind of signatures and then acting like the malware is caught by behavior monitoring. Also, you didn´t respond to my PM, so I guess you don´t want to send me the samples. OK cool (well not really ) but can you at least give some info about the trojans using the NTFS method?

@ CogitoErgoSum, I can´t remember if I PMed you or not, but thanks for the samples.

 

Hello Rasheed187,

You are very welcome.


Peace & Gratitude,

CogitoErgoSum

 

First off, sorry about not sending you the samples. I don't have internet access at home any more, and handling malware samples through the uni network is grounds for instant locking of my account.

To address your question, it's a technical impossibility that behavioral blockers cheat by using signatures and pretend they block malware by behavior. Currently behavior blockers enjoy a far greater success rate than even the best blacklist scanners available on the market, and if they really do cheat, then that means the sample collection and detection abilities of small companies like Sana Security, Micropoint and Novatix (PC Tools) outstrip the abilities of market leaders like Symantec and Kaspersky by orders of magnitude. Obviously this doesn't make sense.

 

I know someone here that thinks that behavior can be turned into signature by a product, in memory of course.

 

OK thanks for letting me know Solcroft. And you know why I´m still a bit skeptical about "smart" HIPS? Because I would first like to see a test: execute 1000 malware samples, and 1000 non-malware samples who both trigger malicious activity, and let´s see how many malware is missed, and how many "false positives" you will get to see.

 

Clean samples with malicious activity is known as riskware/grayware and includes a vast range of software: packet sniffers, network monitoring tools, RATs, intrusion detection tools, malware cleaning tools, cracks/keygens (specially those that use custom/modified packers), game trainers, anticheat software, SMTP servers, IRC-related software, DRM software, comercial keyloggers, jokes, etc.
A behaviour blocker would have a hard time analyzing these samples. If a behaviour blocker doesn't trigger false alarms on a common Windows installation with common software, I consider it good enough.

 

It is actually entirely feasible for a behavior based security system to also have signatures for detection, naming (classification), and/or categorization. The fundamental problem is, though, the word 'signature' has become so overloaded and meaningless that it invites more confusion to the debate than clarity. Peter Szor's book, the Art of Computer Virus Research ( http://www.amazon.com/Computer-Virus-Research-Defense-Symantec/dp/0321304543 ) is a good place to start when it comes to understanding the history and styles of signature based security products.

Some behavioral products use 'signatures' to assign names to threats, so a person using the product may have a higher degree of trust that the conviction of that program was warranted. Other products might have really simple signatures (like checksums/hashes) to help them with false negatives in their behavioral engine. And others might employ sophisticated signatures to aid their behavioral detection.

Are signatures in a behavioral engine cheating, or a bad thing? Personally, I don't think so. It isn't ideal, but computer security is difficult and usually does not have any one straightforward answer (filling your case with concrete doesn't count as security ).

 

Couldn't agree more. For end-users a "Trojan.Downloader.Gen" alert is more appropiate than a "Process xx tries to connect invisibly with a remote server using IE" alert.

 

OK I see, so even behavior blockers would still alert about the tools that you mentioned. But I still don´t trust it, basically they are using some kind of heuristics (or rules) to determine if an app is bad or not, right? But are they able to recognize the difference between (for example) a rootkit driver from a non malicious one? And what do you mean with common software? I mean, I suppose normal HIPS would also not trigger a whole lot of alerts with "common software".

 

The rules, heuristics, behaviors, characteristics, and so on are the 'secret sauce' behind any of the behavior based anti malware products. Since there are lots of ways to define even something as seemingly straightforward as 'rootkit', there are lots and lots of ways of describing in code terms how they are different from normal device drivers.

Here are a few examples of techniques a product might take to determine if a driver is malicious or not. Is the driver digitally signed? Does it pass WHQL? Is it installed by a digitally signed application? Can a user mode application see the drivers registry key in hklm\system\controlset001? Can a user mode application see the actual .sys file on disk? Was the driver installed by an IE exploit? Heck, you might even use more than one behavior to convict a piece of software as being malicious (the software has to do this *and* that to be bad).

These are just some ideas off the top of my head, but what I'm trying to illustrate is there is no one way to detect even one type of threat, so unless you want to completely lock your machine down and audit every change there implicitly must be a level of trust in the vendor of the software. I hope i answered your questions!

 

@ grumbleduke, thanks a lot for the feedback, this is some useful stuff to know about. I´m really hoping that HIPS will be able to make "the next step", with that I mean, I hope that they will become a lot smarter and more powerfull. Personally I would like to see a mix between pure "dumb" HIPS and behavior blockers. And until I see an extensive malware test, I still wouldn´t rely only on tools like TF and PRSC.

But is it possible to spot certain rootkit behavior from a driver when it tries to modify the kernel?