Skip navigation.
Home

Analyzing VM-detecting malware

|

About a year ago, I read something about VM-detecting malware.
After studying this subject, there were a few thoughts which came to mind.
First thought was "How to analyze the behaviour/payload of VM-detecting malware without the use of a Virtual Computer, without sacrificing your computer, without the need to re-install your OS after the analysis (=infection)?
According to a SANS-Article this can be addressed either by patching the malware so it doesn't look for signs of VM environments, or by making changes to the VM environment that will trick the malware.

But there has to be an other way....
From there the idea started.

At the moment, I'm developing a computer-system for the purpose of analyzing (malicious) software, without the use of a Virtual Environment and without a 'Go Back'-app (like Roxio).
You may call it a 'sacrificial machine', but it isn't really 'sacrificial', because this computer is developed for the purpose of malware-behaviour-analysis (read: infecting), following by simply recover/disinfect the machine and prepare it for the next analysis without leaving a trace of the previous infection.
In other words: The computer is able to 'simply' disinfect and recover itself.
I don't use a 'Go-back'-application, so I also can analyze malware-behaviour after a computer-reboot and the, so called, 'trigger'-malware.

After the static analysis (identificate, de-compile/reverse engineering, decrypt, etc), I start the dynamic analysis by real infecting the machine while "in the background" some real-time monitor-apps and other progs are running, for gathering information about the behaviour/payload of the sample. After that, it is quite simple to recover/disinfect the machine for the next analysis.

At this moment, after a few month of developing, testing and improving this system, I'm quite satisfied. Now it's time for 'hard-core'-testing.
That brings me to my question:

Which malware do YOU think I have to analyze with this system? Of course I'm particularly interested in VM-detecting malware (like Red Pill, Scoopy, Jerry).
Which malware has to be analyzed in a non-VM-environment?
(i'm only interested in the names/alias. I already have a large, well organized, collection. So (probably) I don't need samples. Most of them I already have.)

Maybe you're interested in the following: I already did some analysis with this computer (of course) and the results were often very different from the virii-analysis/descriptions made by the AV-Companies. The only reason I can give for this is that the behaviour of such malware is different in a VM/Sandbox. Only with 'real-infection' the real payload appears.

Ergo: which malware is VM-detecting and has to be analyzed in a 'real-machine'? (Of course, the most interesting analysis-results will be published at OC)
Other suggestions and comments about the above are also welcome.

Thanks in advance,

Chato

Real Hardware Analysis Setup

You don't necessarily have to have a "real" machine to do malware analysis. There are ways to duplicate the entire setup of a virtual machine, minus the runtime snapshotting.

My setup makes use of Faronics Deepfreeze, the Windows kernel debugger over a 1394 cable, and all the tools preloaded on the system. That seems to work great and your cleanup is handled with a reboot.

Not related to VM detection...

...so excuse me in advanced if this seems to go out of topic,
but regarding DeepFreeze...for the most part of it,
it certainly is a so-called "killer" app,
but there have been some worries though lately,
that some samples can bypass it...for reference:
http://www.wilderssecurity.com/showthread.php?p=1119935

Regarding this specific,supposedly notorious "pcihdd.sys",
I've found a few addresses hosting it a couple of days ago,
haven't attempted yet to verify though,
if the aformentioned DeepFreeze-bypass info stands true...
http://www.malwaredomainlist.com/forums/index.php?topic=1534.0

More info on my setup

You're absolutely right about deepfreeze not being an all-in-one solution. I don't use it that way, and certainly don't use it on my everyday system. It certainly works for the average run of the mill stuff. Even with deepfreeze I have my install disks readily available.

deepfreeze weakness

Deep freeze has a weakness against the KILLDISK TROJANS. also other security softwares like rollbackrxl has a weakness aginst new mallwares. So no security product is 100% effective.
see wilders security & search.

You can read about a VM

You can read about a VM detecting malware here:

http://www.vitalsecurity.org/2007/04/chinese-malware-goes-hunting-for-vmware.html

but it´s difficult to identify the piece of malware because none name or alias is given.

Anyway you can try with malwares compressed with Themida.

Any chance of betatesting your malware analysis system?

Regards,

VirusBuster

P.S. In the meantime I just found this interesting entry in a blog:

http://secmatters.blogspot.com/2006/11/first-post-virtual-machine-detection.html

Why not partition the

Why not partition the machine and use Symantec Ghost. First partition the disk, then setup your test environment on Partition 1. Save an image of Part 1 onto Part 2.

Then you can run whatever you want on the first partition (disable access to Part 2 beforehand). When you want to reset, simply reboot the machine and boot up into ghost. An XP image should reghost in 1 minute or so when done of a partition.

In this case you really are using a real machine.

Thanks for your replies

First of all thanks for your replies and apologies for not getting back sooner.
I agree with Dannyquist that it isn't really necessarily to have a "real" machine to do VM-detecting-malware analysis. And it's interesting to see the different ways all of you use to analyze malware without the use of a VM.

Thanks to Dannyquist. I didn't know this DeepFreeze existed. Now I read about it and it seems to be a nice app. It isn't an all-in-one solution, but it "certainly works for the average run of the mill stuff", as you said. When I have the time, I will take a deeper look to the DeepFreeze-appl.

@VirusBuster,
Thanks for the tips.
In the link you gave me (the blog from Johnny Foo), I read about Foo's way to analyze VM-Detecting malware. This guy uses the IDA Pro's remote debugging and hardware cards that restore the OS state (e.g. the "Juzt-Reboot™ Data Recovery Card").

@RobertMcArdle
nice idea....never really thought of that before... partition the machine and use Symantec Ghost...that's also a way to analyze without the use of a VM. An interesting idea...

I'm sure that there are more ways to analyze in a non-VM-environment. And also I know that there isn't an all-in-one-solution. And 'the best way' doesn't exist. It has to do with personal preferences. But, also it has to do with the real purposes of analyzing. In my case it is to develop removal-tools. So the 'automatic-restore-tools', aren't very useful to me. After the infection I have to test my removal-tools.
Therefore I'm happy with my own 'malware analysis system'.
A friend of mine (he had seen it working) called it a "save environment for analyzing malware in a real computer with integrated/implemented analysis-tools'.

Maybe you have to see it working, to understand why I'm so proud of this system. So, if you plan a holiday in the Netherlands: you're welcome...... :)

Regards,
Chato

Live or Memorex

With only minimal experience in this field,Im sure of one thing,if you want the real payload for all malware on a daily basis,vm or non vm detectables.

You need a sacrificial lamb and thats the end of that story.

By the time everyone has went out and bought the tools they need and installed them,my 10 year old test machines will have digested the malwares,analyzed them and generated a report.

For me to fully understand the malwares implementations and usage,I must go about the removal process manually,therfore I have a real time idea of what the end user is facing.

I believe for each individual,this is unique,as in my case,time is more important than money and money is more important than some silly software app I can pretty much replicate by hand.

So,its all a matter of prefrence,as each of the apps like deep freeze are built,skiddies are out there determing a way to detect and react to it.

The live test machine is the one steadfast tool,I cant live without. :)

Quick Edit:

Partitioning your hdd and using a ghost app is kinda like having sex without a condom,eventually something is gonna fall off.

that's exactly my point

Thanks for your reply, MWRCM.

[QUOTE]
For me to fully understand the malwares implementations and usage,I must go about the removal process manually,therefore I have a real time idea of what the end user is facing.
[/QUOTE]

And that's exactly my point. Thats the reason I use the system I mentioned in my first post.
For developing removal-tool and removal-'workarounds' you have to test the malware in a sacrificial machine. Only in a non-VM you see exactly what the victim sees. After a reboot the machine has to be still infected. Only in this way I can develop the removal-tools. Most of this tools need a reboot to do the job. When the computer is desinfected after a reboot because of an other app (e.g. Returnil, Deepfreeze) I cannot test the rem-tools.
So, to make a long tale short, I totally agree with you and I'm glad that at least somebody sees the advantage of malware-analysis in a sacificial computer.

My first test machine took

My first test machine took less than 25 dollars to put together and after that experience,each machine thereafter was a total cost of $0.00

One mans trash is another mans treasure. :)

Patching VM-Detect Code

Well, for a project that is upcoming (to be released soon), I just finished some VMWare cloaking code. My method simply involved walking the disassembly of the binary (assuming that it's not packed, or that you have unpacked already) and finding the SIDT/SLDT/SGDT commands.

Once the command search has completed, it detour patches those instructions and in the detoured function writes the value of a valid host machine's descriptor table into the operand.

Original:
SIDT DWORD PTR SS:[ESP]

Detour:
MOV DWORD PTR [ESP], 0x00408003

This method has worked effectively against scoopy, redpill and nopill. Of course this isn't the end-all-be-all of thwarting vm detection, but I think it's a good start. There is one other method for the descriptor table checking that I will implement and repost on when I have a chance.

that sounds

pretty badass. I cant wait to see it!

V.