Most recent Cutwail/Bulknet malware discussion

Hey jlo,

Slightly OT but since you mention PDM of KAV as a blocker since i don't have that part of KAV installed could you solicit some information from your KAV sources about it

How dose PDM react to Runtime3(Most recent Cutwail/Bulknet evo) if the file is unknown to the KASP target database.

The reason i ask is that particular malware code dose'nt unhook the SSDT table(ala Bifrose) it completetly replaces it and all the few HIPS i have tested todate have all been borked once the code has been granted execution

TIA

 

Re: The Storm Worm is back

Not sure. You are best posting here http://forum.kaspersky.com/index.php?showtopic=56252 and one of the KAV technicians may be able to answer your question.

Best wishes

Jlo

 

Re: The Storm Worm is back

May I ask which HIPS you have tested? Perhaps you can test Neoava Guard? It´s able to detect changes to drivers, but I´m not sure if this is enough. It can also protect files/folders from being modified, I wonder what would happen if I protect the "C:\WINDOWS\system32\drivers" folder, I´m not sure if this is a good idea?

 

Re: The Storm Worm is back

Hi, fcukdat!

Do you check this sample against ProSecurity?



PS:
ciao, EraserHW

 

Re: The Storm Worm is back

Apologies folks that want their HIBS tested but unfortunely that take a bit too much of my time currently to install,configure and test to a set standard.It is party season y'know

Processguard&SSM free were whacked but they are the only 2 HIPS i have in my toolbox....

IF any of you are of the level that could deal with the raw malware infection once live then PM me a request and i will hook you up with a dropper for RT3 Cutwail/Bulknet

 

Re: The Storm Worm is back

Just tested with the latest pre-2.10 version of my HIPS- had no problems with this piece of malware. I assume, you should check out other HIPS solutions as well as some will be able to stop it to death.

 

Re: The Storm Worm is back

Thanks Ilya,

I use my HIBS(PG principally) for slowing down and controlling an infection as it goes native on my victim(harvesting)enviroment so i still want the infection to run its cycle to an end result

I'm curious after execution permission was granted to eCard.scr how your HIBS prevented the SSDT table from being replaced?

TIA

NB The malcode being referred too is not *storm* worm RK payload but Runtime3(deployed by eCard.scr)

 

Re: The Storm Worm is back

Very interesting. fcukdat! can u tel us something more about this malware. How does sandboxes stand against it? Can it be tried in a VM or Shadow products safely?

Thanks

 

Re: The Storm Worm is back

Unfortunetly not too much aigle,
I have not tested against sandbox's,VM or others as i use none of these during the course of malware harvesting

The initial .scr(executable) deploys Cutwail/Bulknet Rootkit but if the infected machine has access to the net it will import *others*.Attached is an Inctrl5 report of install today.....please note it imported (hidden from WinAPI)Ntos.exe which is a password stealer hence why a lot of cookies got nuked!

 

Re: The Storm Worm is back

Hi fcukdat,

Thanks for the sample. Regarding ProSecurity 1.40, the bad news is that when eCard is allowed to execute it does indeed replace the SSDT table without any alerts. RkU 3.7.300.509, RootKit Hook Analyzer 3.02, and errors in XP's system log confirm this. ProSecurity's tray icon looks normal but its protection is gone.

The good news, I guess, is that ProSecurity does "wake up" after a restart with its hooks in place...

ntos.exe
[EXECUTE] 2007.12.27 09:57:26
[BLOCK] C:\WINDOWS\system32\ntos.exe
Command Line:C:\WINDOWS\system32\ntos.exe
[FROM] C:\WINDOWS\system32\winlogon.exe
Command Line:winlogon.exe

mainserv.exe
[EXECUTE CHANGED PROGRAM] 2007.12.27 09:57:27
[BLOCK] C:\Program Files\APC\APC PowerChute Personal Edition\mainserv.exe
Command Line:"C:\Program Files\APC\APC PowerChute Personal Edition\mainserv.exe"
[ACCESS TO] C:\WINDOWS\system32\services.exe
Command Line:C:\WINDOWS\system32\services.exe

380031.exe
[EXECUTE] 2007.12.27 09:57:27
[BLOCK] C:\WINDOWS\TEMP\380031.exe
Command Line:C:\WINDOWS\TEMP\380031.exe
[FROM] C:\WINDOWS\system32\services.exe
Command Line:C:\WINDOWS\system32\services.exe

188921.exe
[EXECUTE] 2007.12.27 10:00:11
[BLOCK] C:\WINDOWS\TEMP\188921.exe
Command Line:"C:\WINDOWS\TEMP\188921.exe"
[FROM] C:\WINDOWS\system32\svchost.exe
Command Line:C:\WINDOWS\system32\svchost -k DcomLaunch

191812.exe
[EXECUTE] 2007.12.27 10:00:12
[BLOCK] C:\WINDOWS\TEMP\191812.exe
Command Line:"C:\WINDOWS\TEMP\191812.exe"
[FROM] C:\WINDOWS\system32\svchost.exe
Command Line:C:\WINDOWS\system32\svchost -k DcomLaunch

I imaged that test partition and can play with it again if required.

Nick

 

Re: The Storm Worm is back

Only if you choose to allow it to, or didn't create/enable a rule to monitor that action.

 

Re: The Storm Worm is back

Of course.

 

Re: The Storm Worm is back

Yeah my 2 HIBS reinstated their respective controls when rebooted but for the *purists* the damage had already been done when they were nulled by the SSDT wipeout.

This is highlighted by the fact in this case Ntos/wspoem(PWS stealer) would have harvested any re-entered passwords and phoned home new data whilst the software firewall was bypassed(subverted in ring0 by Runtime3 RK)in the current session.

 

Re: The Storm Worm is back

Then don't you think that saying ProSec didnt raise any alerts has about as much point as saying an antivirus let this trojan execute without warning, because you turned the realtime guard off?

 

Re: The Storm Worm is back

Per fcukdat's request, the premise of the test was to let it execute...

 

Re: The Storm Worm is back

You can let it execute, AND block it from accessing the OS kernel.

 

Re: The Storm Worm is back

Hi, nick s:

i'm not expert like you but, as a simple PS user, i would be intrested to know better about your result...

Could you provide my more explanation about PS failur?

Txs a lot!

 

Re: The Storm Worm is back

Not really its a bit like folks that knock ProcessGuard as out of date/ineffective yet to this date no driveby install has infected past its execution control on my machine to go native.

At that point the PG arguement becomes about post execution of code and what the software dose/dose not do.

Applying that logic... judge 1 then judge them all

 

Re: The Storm Worm is back

Can you elaborate? I allowed to eCard to execute once when alerted by PS. The next alert warned of eCard's attempt at low level disk access. I blocked that once. No alerts thereafter.

 

Re: The Storm Worm is back

Judging is best done when you've used the software and know it well.

ProSec was one of the earliest HIPS (that I know of) that implemented kernel access control. It's also got a fearsome reputation among malware exchange forums, where people execute samples for the heck of it. I seriously doubt something as weak as Storm could knock it off the SSDT without it giving so much as a squeak.

 

Re: The Storm Worm is back

May I ask you to post screenshots of your ruleset and/or prog settings?

 

Re: The Storm Worm is back

Understood but that is exactly why i declined to test when requested other HIBS i am not fammiliar with

FYI It's not Storm payload RK that is being tested but RT3 Cutwail/Bulknet(eCard.scr)which being spammed in a different malware campaign currently.If you missed it earliar on this particular malcode dose not unhook SSDT hooks,it completely replaces the table.

We kinda of wandered OT when KAV PDM got mentioned back a few pages...

HTH

 

Re: The Storm Worm is back

My System State for the test...

(Note that I have "Auto allow new libraries to load" enabled. That is the reason why the Library Monitor status bar is less than full. If I disable that, the first eCard alert is actually for the loading of the eCard.scr library file. That is followed by the execution alert and, then, by the low level disk access alert.)

 

Re: The Storm Worm is back

Hi,

@ fcukdat

I´ve tested ecard.exe (in VM), and after execution, it fired up enough alerts to let me know that this thing is malicious, to be precise: According to Neoava Guard, it wanted to have "low level disk access", plus it wanted to modify/directly load drivers. SSM didn´t give me any alert about "low level disk access". I´ve also tested it with KAV v7, and strangely enough, KAV was not able to stop this attack, it did manage to spot the hidden process of IE, and could kill it, but still all hooks were wiped.

Are you sure about this? It´s very surprising to me, must be some programming error? AFAIK, it also monitors the stuff that SSM and NG alerted about. Btw, I just saw the other posts, so seems like you´re sure about it. I also wonder if some HIPS might malfunction if tested in a VM.