Malware bypassed ShadowSurfer

I have run the malware under three situations:

1. VBox admin guest system (XP Pro Sp3) via command line using limited services profile.
2. Repeated number 1.
3. Again in VBox admin guest system, this time with all default services running.

In all three cases I did not notice anything untoward happening more than five minutes after rebooting and running either IE8 or Firefox 3.5.2 browsers, running over 10 minutes in test 3. I believe the malware ran because of brief appearance of hourglass after launching and cmd line prompt returning to previous status, but the malware does not seem to do anything in my VBox environment. It was not even run sandboxed. And no, I did not revert to current snapshot after the reboots. However, before attempts 2 and 3, I did revert to current snapshot.

All I can conclude is that the malware does not work properly under the VBox environment?

 

DW blocks this. (Verified by Ilya.)

 

Okay, it does work, but this time before running I installed Malware Defender HIPS on the VBox guest to inspect. This time, however, I did not reboot but the virus sprung in to action about a minute after I launched it. MD alerted numerous times, eventually leading to network access attempts by the virus to various ip addresses, especially to the US. Interesting stuff.

*EDIT*

One last test:

Reverted to current snapshot in VBox, re-installed MD, then launched the malware (via cmd line of course) from the VBox limited account. Results are vastly different, as one might expect:

This time MD alerted many, many pop-ups, but they were all repeated attempts by the virus to infiltrate the registry and attempting to install the autorun.inf and some taping.dll file. I permitted all the alerts. It was clear to me the virus was unsuccessful in its attempts to properly install itself due to the restrictions imposed by the limited account. it just kept running in an endless loop trying to assert itself. There was one early network access attempt but no others after that, as it was fruitlessly trying to breech the registry.

Now I'm certainly no experienced malware tester by a long shot, but with this test of an obviously virulent file here and the killdisk test last night where the limited account was barely scathed by the tests, it is quite evident and proof that running limited has tremendous merit in avoiding serious infection, especially via unexpected drive-by or similar attacks. I'm a believer more than ever now

 

Hi Aigle,

Got to love that chinese cuisine

After your request to look at the infection i know why Comodo did'nt flag the creation of the service entry...

It is because the service entry already existed(legitimate driver) but the legitimate system file had got replaced and its load entry subsequently hidden(not created).

This is also how it survived reboot and started bringing the rain in the second session.

Use Rootrepeal to copy the hidden file and you have your culprit

MBAM enjoyed all the chinese malwares with this infection so no new signatures for me

 

Hi thanks a lot. So it was a simple but clever trick. Really love it. I have few questions.
1. After reboot i scanned my XP partition by MBAM from other partition from within win 7 but it detected nothing.
2.No other scanners caught the infected sys file.
3. Was it atapi.sys showed by rootrepeal only once, but never after that. See my pic in the initial posts.
Thanks again.

 

I have tested this malware with Returnil, Deep freeze, Shadow Defender.

Results:

Returnil 2008 2.0.1.9002 has been bypassed
Returnil 2010 Beta 8 (3.0.5636) has been bypassed
Deep freeze 6.53.20.2763 has been bypassed
Shadow Defender 1.1.0.278 has been bypassed

Shadow Defender 1.1.0.280 (beta) has not been bypassed

 

Would a HIPS blocking direct disk access have prevented this?

 

i blocked direct disk access with comodo and allowed all others and it bypassed.

 

Interesting. I was under the impression that direct disk access was the only way to bypass a virtualiser. Out of curiosity which virtualiser were you using when you blocked direct disk access?

 

Indeed.

Based on screenshots posted by Aigle earlier in this thread, it might be interesting to note a couple of things:

1. This malware attempts to obtain the all-powerful SeDebugPrivilege that can be used to inject code into processes running as SYSTEM to gain complete control of the entire system - limited users don't have that, so that's failure number one for the malware and score one for LUA.

2. Apparently the malware also tries to create a dll file C:\daping.dll - limited users can't do that, either, since they can't create files there, another failure for the malware.

3. Then the malware tries to modify AV software registry keys in HKLM - limited users can't do that, assuming the AV software doesn't stupidly grant Everyone - Full Control to its most important registry keys, so it's already the third failure for the malware and things aren't looking all that bright.

4. The malware tries direct disk access - limited users can't do that. Too bad, for the malware.

5. The malware tries to replace the legit but not critically important driver asyncmac.sys, MS remote access serial network driver, with a malicious version - limited users certainly can't do this, having no write access to System32\Drivers. At this point, it's pretty safe to say that the malware has achieved a pathetic failure in infecting the system, or even killing AV scanners running in the system. It's likely that the malware is so stupid it expects to be executed as admin, and fails entirely in LUA, without being able to even infect the user account - which wouldn't be hard to do, if the author bothered to do it.

Of course, LUA couldn't do anything against a stupid user who really just has to install something from an untrusted source. In such a case, they'd just execute this as admin and it could do anything it wants. But, as we can see from this thread right here, even if you're running security software that's supposed to protect you from this kind of thing, you can still get burned. So, the obvious solution: don't execute untrusted code as admin. If you really have to, keep in mind that your security software may not be able to save you, even if it's the fancy HIPS type. Malware, like this sample here, can attempt to evade rather many security software products by first changing trusted system files and processes and then using those against the security software. Threads like this should also serve as a reminder that most people, even in security forums, shouldn't play around with malware, and certainly not with their personal systems they use for anything important. Some malware may slip past the cracks in security software, and then surprises can happen. Of course, running tests in a virtual machine is one way to vastly decrease the risk of surprises. But then one should be aware that some malware acts differently in virtual environments, and may not do all that it's supposed to do, resulting in an incomplete analysis of the malware and possibly even a complete misidentifcation and false negative (this has happened to malware analysts in AV companies).

 

Interesting can someone please pm me sample with pass cheers.

 

ShadowSurfer

 

Oh, OK then.
We will all stop to play around with malware immediately.
Thanks for the advice.

Cheers

 

Good point Windchild. For a while now, I have had a keen interest in testing some malware samples (because I have no interest in long term testing) just to actually see what can happen to get a better appreciation for the threat possibilities, not only when launched within an admin account but especially under a limited account, because it is the latter scenario that interests me the most; exactly how well a limited account can protect against these threats (because it is obvious the admin account opens the doors wide for infection manifestation) even without the aid of security tools (so of course I allowed the HIPS alerts, except the internet acces attempts). I was pleasantly surprised at how ineffective the malware was against the limited account, where basically the malware was beating its figurative head against the wall trying to breech the restrictions.

It also surprises me at how little this is even mentioned by others; most are only interested in what security software the malware can breech, rather than how it can be mitigated or outright stopped with simple measures. Anyways, that is not my problem but felt compelled to mention it.

Phhhttt! No guts, no glory Windchild Seriously, point well taken but it is a risk I had no problems taking, given the measures I have in place in case of breech of containment. I'm sure the same can be said of others who tested this.

Actually, I am quite convinced there is no reason to sandbox the VM or even run the sandbox within the VM. The VM alone easily contained the samples I ran, but I do understand the extra sandbox measure could help in the evnt the VM leaks.

 

Stealth MBR rootkits would either go for low-level disk access to mess up or rewrite the MBR or use a kernel driver to access the mbr just like this rootkit detection utility from Gmer called mbr.exe... http://www2.gmer.net/mbr/

So any virtualizers or virtualizing softwares must have a component with Anti-Executable or a component with HIPS functionality guarding low-level disk access as well as kerneldriver loading. Or the user must supplemment with a companion standalone HIPS or AE or LUA-SRP or a Sandboxing solution.

 

2nd round of this malware testing is here.

https://www.wilderssecurity.com/showthread.php?t=252508

 

Default deny policy approach like AE is just the one needed by those who wants to run their system in Admin. A virtualizer like Returnil(Ram mode) or Deepfreeze with AE is a good combo like Rmus'.

 

So just to be clear a virtualiser can be bypassed in only 3 different ways:

1) Direct Disk Access
2) Low-level disk access to mess up the mbr
3) Using a kernel driver to rewrite the mbr

Is this correct? And is the purpose of direct disk access also to re-write the mbr? Would this mean that protecting the mbr itself would be enough to prevent malware from bypassing light virtualisation?

 

Hopefully you don't mean my security approach I actually ran the samples in the VM guest both as admin and limited (reverting to current snapshot between test environments), with the host always as limited. This way, in the unlikely event of leakage through the VM, the virus would have had to deal with limited restrictions on the host, which was also protected by Outpost with its host protection enabled. The virtualbox.exe's Internet access was blocked. Of course later on I added Malware Defender to the VM so I could actually get a detailed view of what the virus was trying to do. If this fortress had failed, well, I always have Acronis.

I don't know about more exciting; I don't think you can count on one product stopping everything, anyways. And of course it goes without saying the malware has to be allowed to launch to properly test the effectiveness, or lack thereof, of the security software and, if desired as was my case, the effectiveness of the limited account. On the software front, I was impressed with the effectiveness of Malware Defender to alert on every single one of the virus' attempts at infiltrating the system.

I'm curious about this too. The killdisk malware only messed up the MBR of the virtual machine's disk. However, it was a very easy fix to simply revert to the current snapshot. Remember, I ran the VM on my host's limited account, so I'm not yet convinced the real system is at that much danger as long as the environment is limited. Still, I'm interested to see some informed opinions.

 

Low level disk access is the same banana as direct disk access. Absolutely right, the mbr is the only place not virtualized in a virtualizer in memory caching mode(all writes will go to RAM) and so it is the achilles' heel. So, it must be protected at all cost from direct disk access as well as from the kernel driver accessing it. In disk overlay type, the malware can write at lowlevel on other sectors of the hard disk besides the mbr.

I have tried killdisk trojan on a real system. It will mess up the partition table. I have to delete the partitions and to format it and do a linux install to rewrite the partition table as well as the bootsectors for my imaging program to successfully restore an image back up.

 

So as long as the mbr is protected the virtualiser cant be bypassed? Doesnt Returnil have some sort of feature protecting the MBR? Were these features active when forum member developers tested returnil 2008 and 2010 beta?

developers any response to this?

 

Virtualisers try to protect MBR themselves, it's an internal feature, you can't activate or deactivate it.

New MBR rootkit VS Returnil: Returnil 2010 beta has protected the MBR

DDOS worm: Returnil 2010 beta has protected the MBR

Technical Returnil question regarding malware: how an Instant System Recovery software can be bypassed

W32.SafeSys.Worm VS Returnil: this worm can bypass several ISR.

I have tested Returnil 2010 with Virus Guard disabled, and Returnil 2008 without AntiexEcute tool, because Deep Freeze and Shadow Defender haven't these protections. So, only virtualization VS malware.

 

If that's the case, then how was I able to easily revert to the current snapshot after killdisk compromised the vm's mbr? Is it because I'm running the VM on the host's limited account?

 

Yup, just like windchild said, 'lua protects mbr'.

 

Ahh, I missed that. Okay, thanks, good to know