rootkit driver install not intercepted by CFP?

Ok, another unexpected result for CFP, atleast on my system. I tried to install a rootkit driver manually via w2k_loqd.exe. CFP gave SCM access alert. I denied it but driver seems to be loaded as shown by rootrepeal. Wonder if any one can confirm it.

Thanks

EQS- stopped it.
GesWall- stopped it too.

PS: Tested on a fresh snapshot of Eaz-Fix , XP Home SP2, no other security software installed at all. Fresh install of CFP with paranoid settings. Used shadowSurfer for testing though.

 

Aigle,I see you are still at it and besides your extensive testing, Geswall Is just kicking Some Butt. Proud To be a Geswall user.

 

I'm using CPF myself and wonder how would be an outcome of such test on my system, because I additionally use ThreatFire.

Maybe I could test it on RVS and see what happens?

Regards

 

Hi!

Finally, I got some time and made some tests. Well, well, well - have you posted your results on Comodo forums? Because I think that some of the developers might want to take a look at that (but that's just my opinion).

Here you go with some screenshots:
http://img363.imageshack.us/my.php?image=80199228vx2.jpg
http://img357.imageshack.us/my.php?image=37694241wa1.jpg
http://img80.imageshack.us/img80/5084/19469594ex6.jpg
http://img185.imageshack.us/img185/264/92335083pq3.jpg
http://img208.imageshack.us/img208/4665/32048945pf5.jpg

Again, it looks like that a layered security solution is actually the only one working, because both ThreatFire and CPF _failed_ to stop the rootkit driver from loading.
But, what's even more interesting - Avira DID detect if - during these few steps of loading rootkit driver into system I had quite a few alerts from Avira guard.

So, my conclusion from this test is - behavior blocking is cool, but relying strictly on such kind of resident malware analysis is not the way to go. Not for me, at least.

Thanks to Aigle for providing me with the test files.

Now - it's time to reboot

EDIT: some more thoughts - it is as well funny as somewhat ironic that in spite of not showing any alerts by ThreatFire during inch.sys load it, for example did show an alert when I lauched RootRepeal. Moreover, CPF did too show some alerts. On one hand this could be funny, but honestly speaking - that made me wonder about one thing: isn't using a HIPS and behavioral analysis blocker a bit delusive? Because, you get some alerts, certainly you click the right buttons, so you tell yourself that everything is ok and all systems go, but is that really a matter of fact?
Out of curiosity - I scanned the test folder provided to me by Aigle and - while Avira still alerts me every minute - bot A-Squared and MBAM _did_not_ find any malicious files after scanning it. Deeply interesting.

 

Thanks for ur testing. I already posted there. But no response so far.

The driver is a rootkit driver, but loader is a utility rather than malware as I still have not got the actual loader. Antivir detected that,s OK but I highly doubt that Antivir can detect this installed and loaded rootkit driver in actual scenario.

Seems detection of service/ driver isntall/ loading is one of the areas where CFP needs to be improved a lot. Sadly I have not got any response from developers though I have post about atleast five threads where CFP seems to fail or seems buggy( 3 about driver loading/ install, one about physical memory access and one about file creation).

 

Both Defensewall 2.44 and OA (build 131) stopped rootkit driver loading.

With w2k_load.exe set to Run Safer in OA, rootkit driver did not load and there were no more pop-up's. If Run Safer not selected, the last two pop-up's appeared. Selecting Block on either prevented Rootkit driver loading. Only when Allow selected 3 times would driver load successfully.

 

in response to your 'note' i too have found Avira to be very much on-point, with it's detections. and at the risk of fanboy outrage, MBAM has yet to detect a single file as malicious, (that i have context menu scanned), nor a running infection i have quick or full scanned against. perhaps not the right malware types....i dunno. as far as A2, it's Anti-Malware version is pretty strong in my limited experience, (against un-sandboxed application level apps {SafeSpace in my case}) and has stopped in it's tracks everything i have run against it (unsandboxed).

nice testing. btw, what is that interesting looking application residing on the right side (as you look at it) of your desk top??


Mike

 

Its to bad SAS was not used to see if it detects.

 

SAS does not detect any malicious files on a scan and does not detect anything when the driver is installed.

 

Thanks for the confirmation.

 

What about SandboxIE folks?

PS: I have to say, I love your testings

 

When w2k_load.exe is run sandboxed, rootkit driver fails to load. PASS

 

anyone tryed it against kis2009?

 

TEST1: ROOTKIT VS. DRIVESENTRY : ROOTKIT WIN

TEST2: ROOTKIT VS THREATFIRE:ROOTKIT WIN

TEST3: ROOTKIT VS. A2 : A2 WIN

TEST4: ROOTKIT VS. ZEMANA:ZEMANA WIN

OTHERS:
SANDBOXIE WIN
GESWALL WIN
DEFENSEWALL WIN
COMODO FAIL

 

Comodo people have acknowledged the bug and it will be fixed in next update.

 

Hats off to you Aigle. Nice work.

 

For those who are interested,

I can personally confirm that DefenseWall v2.45 successfully blocks and confines the rootkit driver and creation of related service, etc... I have attached my DW events log as proof.


Peace & Gratitude,

CogitoErgoSum

 

Thanks hammerman!

 

Thanks for the testing. Aigle, Hammerman,SwordFish,and guest for Drive Sentry.

 

You are welcome.

 

That's Samurize with (slightly modified) Axiom config.

Regards,
a.

 

As Aigle said - comodo devs have already acknowledged this bug. I will probably post this issue on PC Tools forum and quite possobly do some more testing.

Regards,
a.

 

Ok guys time to wade in with some facts/history just so you all can stop chasing your tails on whether brand X,Y or Z will detect this sample etc

Here is where *inch.sys* was first presented to the public c/o a topic brought at sysinternals by a d_13(author of RootRepeal)
http://forum.sysinternals.com/forum_posts.asp?TID=15413&PN=1

At the same time in closed malware research forum there was another sample brought in from the wild by Nosirrah(MBAM 's most talented malware fighter )

Unfortunetly since that was at closed forum then no links or direct info can be displayed from that topic but suffice to say it was reported that MBAM's engine was being blocked from *seeing* this driver alongside the mighty GMER ARK tool

It was confirmed in both topics that this particular Rootkit driver was coded with anti ARK capability and that anytool utilizing rawdisk read was being blocked
It must also to be noted none of tools/softwares not using rawdisk read would be capable of detecting this malware rootkit either

So in short the mighty ARK tools such as GMER,RootRepeal,RootKitUnhooker(3.7) were all being beaten at that point in time

The botkillers using raw disk read such as SAS & MBAM were waxed and the AV's such as Symantec,Kasperksy and AntiVir were also blinded by this loaded driver

** it has to be noted that static identification of unloaded driver by file scan or upload to service such as VirusTotal mean absolutely squat when it boils down to loaded driver as that when its anti-ARK capabilities kick in and suddenly it is invisible to these softwares

Net result forced ARK tools under devs to roll out new versions incorperating hotfix's to block the anti ARK technique of this particular rootkit driver.Both RootRepeal and RKU have since released new versions

That said The AV's and botkillers are still lagging although i believe PrevX CSI has updated its ARK module to counter this driver's anti ARK capabilities and i will be hopefully testing Dr Web Cure-it at some point too versus loaded inch.sys

 

Thanks fcukdat. Very infromaritive. BTW still waiting for ur write up about phide_ex.exe rootkit.

 

Hi,

Just to clarify i have not tested versus PDM as in realtime blocking/capture of driver as it is loaded.

My comment's to Kaspersky being bypassed were based on the driver already be native(loaded) on a test machine and in which case all versions of Kaspersky would be thoeretically blind to the loaded rootkit.

Early versions not using raw disk read would be blind to the Ring0 dwelling driver.... more recent raw disk read builds would be *blinded* the same as all the other Raw disk readers until they upgrade their ARK module

HTH