Cuckoo: Cuckoo will only download .vmsn but won't download .vmem from full memory dump

[malwarfare]

Using vsphere machinery, when full memory dump is enabled, cuckoo will sucessfully request (and create) the snapshot files: snapshotX.vmsn and snapshotX.vmem, but will only download the .vmsn (2MB file), won't download the .vmem (actual memory snapshot).

HOST: Vsphere ESXi 6.0 hypervisor
GUESTs: Windows 7/8/10 guests

Thanks in advance.

[malwarfare]

Taking a look at the code (modules/machinery/vsphere.py) I see it is grabing datakey from snapshot, maybe it should grab memorykey instead?

[malwarfare]

A dirty workaround that worked for me:
datakey-=1

[jbremer]

I must say that I'm not too familiar with vSphere, but what you're saying is that there's simply a HTTP request missing - one for the .vmem file, right? Would you like to add it, i.e., put an extra one right behind the existing one in _download_snapshot and set it up with the correct datakey?
I definitely don't have a vSphere setup, so this is not something I can help you with directly.
Thanks!

[KillerInstinct]

I believe this is a ESXi 6.X thing.

I would recommend adding a version check similar to below:

if int(str(version).split(".")[0]) >= 6:
    datakey -= 1

But I'm not sure if we grab the version in that code. I migrated from ESXi (vSphere machinery) a while back due to anti-vm related issues.

[malwarfare]

@jbremer Thank you for your reply. I'm not aware enough of Cuckoo's code structure to be able to make a good update in the code.
Altough I'm not sure if vmsn file is needed, I guess @KillerInstinct should be safe enough.
But if both files are needed, then it might require other modifications in order that volatility will work properly, it est, .vmem file should be renamed to .dmp instead of .vmsn.

[malwarfare]

@KillerInstinct Thank you for your reply! Could you let me know what anti-vm (and other) issues you had with ESXi (vsphere machinery)? Thanks in advance.

[KillerInstinct]

i don't think the .vmsn is used by volatility, so it shouldn't be needed.

As far as anti-vm goes, both VMware and Virtual PC decided it would be a good idea to forcefully put in a means of communicating between the hypervisor and guest. Below is some info:
https://sites.google.com/site/chitchatvmback/backdoor

It's a pretty well known technique, basically you just wrap that into a try/except handler and if you get an access violation (unpriv instruction) than you know you're in a virtual environment. Currently there is no way to disable the backdoor.

You can run VMDE just to double check that you're effected.
https://github.com/hfiref0x/VMDE/blob/master/Source/vmde/detect.c#L66

[malwarfare]

@KillerInstinct thank you for the information. What Hypervisor would you you suggest? Virtualbox? kvm?

[KillerInstinct]

Both are good, I use KVM though just because I find it easier to use from a command-line perspective.

[jgajek]

@malwarfare The .vmsn file should contain the entire memory state of the machine (at least it does on ESXi 5.5). I don't have access to a version 6.0 environment. Did you try to run Volatility on the .vmsn file?

[Limbolindi]

some news on this topic?

[malwarfare]

I'm sorry for the delay.

Adding "datakey-=1" to the code (/modules/machinery/vsphere.py) works like a charm.
@KillerInstinct improved the code in order not to break previous versions of ESX.

After this change, cuckoo will download .vmem file.

Running volatility in the .vmem file works, since it's a current snapshot of the memory.

If you already installed and setup volatility with cuckoo, it will analyze the .vmem file, no further changes needed.

[jbremer]

Has this issue been resolved?

[jgajek]

Yes, with the PR #1051, the machinery will download the .vmem file for vSphere 6.x.

[jbremer]

That's been merged already, great. Thanks!