Hiding CPU from Pafish

[Nagaev]

I have hardened my sandbox (desktop, documents, deletion of floppy disks, CPU cores, RAM, HDD size...) and I still notice Pafish detects the sandbox (running on VMWare vSphere).

I have succeeded in changing my CPU name etc with some strange tricks in the vmx file, but even after that it's not that satisfying.

When submitting Pafish with cuckoomon-modified, I get the following "red flags" : [] Checking the difference between CPU timestamp counters forcing VM exit... [] Checking hypervisor bit in cpuid feature bits... [] Checking cpuid hypervisor vendor for known VM vendors...

Do you know if there is a way to hide/fake these parameters? I have already seen Cuckoo configurations with no red flags, but probably running on VirtualBox with an old version of Pafish.

[doomedraven]

google is your friend here ;) https://github.com/nsmfoo/antivmdetection https://github.com/hfiref0x/VBoxHardenedLoader/ https://github.com/jbremer/vmcloak/

cpuid should be fixed in latest vbox as far as i know

[doomedraven]

and specially this one http://byte-atlas.blogspot.com.es/2017/02/hardening-vbox-win7x64.html

[Nagaev]

As I said I'm using VMWare vSphere, so these scripts will not work. I just want to know if there is an equivalent of these tools, or at least something more effective than just editing vmx files, which is not really documented nor effective.

[KillerInstinct]

The hypervisor is the end users choice. VMware is especially known for being able to be detected as a virtual environment. There are several pretty much un-patchable (via config options) vmdetect methods for ESXi. If you use it you're accepting the risk that some malware won't run on it.

It's worth noting that doomedraven is right. Google is your friend here -- for your specific issue I believe this (or similar config change) will work: http://vknowledge.net/2014/04/17/how-to-fake-a-vms-guest-os-cpuid/

Just change the vmx file of the VM on your vSphere host.

[Nagaev]

I know that vSphere is not that good. However it should be possible to hide it, but the documentation is rare and maybe it's overkill to develop a driver to do that to fool a malware.

About CPU, the problem is not really the name which can be changed with a nice trick (https://www.reddit.com/r/vmware/comments/5x7ub4/anybody_know_how_to_change_the_cpu_type_that/), but I don't find anything about changing the "hypervisor" field. Not even sure it is possible. Just asking.

[doomedraven]

sorry was reading in diagonal and saw vbox. no idea about vmware as i don't use but to hide that in KVM i was need to patch source code

strs[2] = "VMwareVMware"; /* VMware */ you need do grep for this pattern looks like you can download source also https://my.vmware.com/web/vmware/details?productId=351&downloadGroup=ESXI550_OSS

[kevoreilly]

The link mentioned by KillerInstinct mentions changing the following lines of the vmx:

cpuid.1.eax = “00000000000000110000011010101001” cpuid.1.edx = “10111111111010111111101111111111”

In cpu.c of Pafish the relevant function to test the hypervisor bit is cpuid_hv_bit:

int ecx;
__asm__ volatile("cpuid" \
        : "=c"(ecx) \
        : "a"(0x01));
return (ecx >> 31) & 0x1;

Note the use of register ecx here. Since other functions reference the registers eax-edx I would imagine that it might therefore be possible to switch the relevant bit using a line in the vmx similar to:

cpuid.1.ecx = “...

You could get the value from a VMware hypervisor, work out which bit is set that correlates with the above code, and then specify the full ecx line swapping that bit.

[jgajek]

I did add a couple of VMware-specific anti-detection string replacements to cuckoomon a while back (https://github.com/spender-sandbox/cuckoomon-modified/commit/3f19e4865af33eadf66f7c061112d749d2b53eed), but as KillerInstict said, it's not possible to make the virtualization totally undetectable. That goes for pretty much any virtualization platform. It's always good to have a physical machine handy for the (relatively rare) cases where the malware refuses to execute in a virtual guest.

[Nagaev]

Thank's for your answer. I have succeeded in removing hypervisor bit and hypervisor vendor red flags by setting the hypervisor bit (first bit of cpuid.1.ecx) to 0 by adding the line : cpuid.1.ecx="0---:----:----:----:----:----:----:----" in the VMX file.

I know it can't be perfect since there are some really effective way to spot a VM and it's impossible to hide all these parameters. However obvious checks like CPU, MAC address, specific VBox/VMWare can be frequent and easy to implement in malwares.

By the way it seemed obvious to me that bare-metal hypervisors are easier to hide than 'applicative' hypervisors. It seems it's not that simple.

[mallorybobalice]

We've had no luck hiding cpuid bit or brand string(including vendor) via vmx before for certain esx versions. Curios to hear how you go(what major and minor version) . Support told us at the time the esxi version didn't support it. Is this indeed the case vs the code and vm log?

Ps that will leave plenty of device names, pipes and acpi and such, just not in pafish. You can also fix rtdsc (also vmx setting for timing) without vmexit but not with

[mallorybobalice]

Also when the CPU full string says xeon blabla, probaly not what we want to see

[Nagaev]

About ESX version, it works perfectly for me on ESXi 6.0.0. I don't know for older versions, but since I didn't found anything related to CPU hiding in VMware documentation, just try it to be sure.

About changing the CPU full string, I managed to do that by following the smart trick described here : https://www.reddit.com/r/vmware/comments/5x7ub4/anybody_know_how_to_change_the_cpu_type_that/

AFAIK the only things which are not possible to change directly from vSphere are drivers, and the timestamp raising this Pafish flag : "Checking the difference between CPU timestamp counters forcing VM exit...". More precisely, it seems possible to solve this but you have to install VMware tools, which is clearly not worth for evading detection.

[mallorybobalice]

Thanks. There was also the unsigned open source rtdsc diver, but hopefully it would be a feature should zerom0n kernel driver analysis make it into main cuckoo or modified

[mallorybobalice]

Ps truth be told I'm me of fan of doomedraven's source patching of kvm. Or tsugumi for vbox (if only that was ported to Linux hosts), but like I said, maybe zer0mon

[Crypto-Cat]

I followed the technique suggested by @KillerInstinct and @kevoreilly but when I boot the VM i get an error saying "This virtual machine requires FXSR" and it won't boot. I think it's because the instructions are for a 32-bit VM and I am running a 64-bit Windows 7, anybody have any instructions for x64 OS?

EDIT: I used @Nagaev solution for all 3 bits and it is now passing the tests :) Just need to add this to .VMX file:

cpuid.1.eax = "0---:----:----:----:----:----:----:----" cpuid.1.ecx = "0---:----:----:----:----:----:----:----" cpuid.1.edx = "0---:----:----:----:----:----:----:----"