A popular way of binding samples to a specific machine is by taking a hardware fingerprint of the system, and sending it to the server. The server then encrypts the payload using a key that is derived from the system fingerprint and sends it back. The payload will only run on a system for which the payload loader can extract the same fingerprint as used to encrypt the payload.<\/p>\n\n\n\n
It turns out you can bind the sample not only to the hardware fingerprint, but also to the custom, guest-only properties assigned to the guest operating snapshots (okay, in some way it is still a hardware fingerprint).<\/p>\n\n\n\n
For VMWare, you can use a tool rpctool.exe \/ vmware-rpctool.exe \/ vmware-guestd to either set or retrieve the value of guest OS properties e.g.:<\/p>\n\n\n\n
Malware could either use the tool, or talk to the RPC interface directly. <\/p>\n\n\n\n
There are various possibilities. If the VM is a part of the farm, malware authors could enumerate existing guest OS properties in a same way they list well-known sandbox hostnames. Based on the analysis of incoming information (e.g. stats) determine then if the VM is deemed ‘infectable’. They could also set their own guest properties and only continue deployments of future updates to malware if the property still exists and contains expected value.<\/p>\n\n\n\n
So, it could be yet another potential anti-sandbox trick\/evasion.<\/p>\n\n\n\n
There are more Guest OS tools.<\/p>\n\n\n\n
Detecting VM is a popular way to evade sandboxes. With a growing number of environments that rely on VMs the way the detection is done may soon change – perhaps it will have to be a little bit more refined than before? I.e. it is OK if it is a VM, just exclude some of them?
<\/p>\n\n\n\n
For example, using a tool VMwareToolboxCmd.exe, one can retrieve the time of the host machine:<\/p>\n\n\n\n
If the host and guest times are not synchronized, what could be the reason?<\/p>\n\n\n\n
An alternative method can check if the time synchronization is enabled at all:<\/p>\n\n\n\n
Yet another way to detect possible customized properties of the guest OS is by looking at its scripts e.g.:<\/p>\n\n\n\n
The ‘power’ refers to an event that makes the script run, and can be replaced with other event names e.g. ‘resume’, ‘suspend’, ‘shutdown’, each associated with a respective script. I have described using these as a possible persistence trick<\/a> long time ago. <\/p>\n\n\n\n Turns out that using the VMwareToolboxCmd.exe tool one could modify the paths of the default scripts (i.e. it is a new persistence trick). Their content, if changed, could also be an additional fingerprint signature.<\/p>\n\n\n\n And one more command to cover: testing the availability of new version of VMWare tools. The version of VMTools, as well as the fact it is not being updated can help to enrich profile of a guest OS:<\/p>\n\n\n\n There is probably more possibilities out there… A popular way of binding samples to a specific machine is by taking a hardware fingerprint of the system, and sending it to the server. The server then encrypts the payload using a key that is derived from the system … Continue reading
<\/p>\n","protected":false},"excerpt":{"rendered":"