Category Archives: Anti-*

Beyond good ol’ Run key, Part 97

Posted on by

When I explore new persistence mechanisms, I usually try to focus on a native OS functionality. The main reason for such approach is the omnipresence of these mechanisms – they can be used on most versions of the Windows OS no matter what other software is present.

Every once in a while I do look at other persistence ‘vectors’ tho. Ones that focus on popular applications e.g. Office, Total Commander, popular archivers, email or torrent clients. They are so prevalent that they form a separate ‘cloud’ of apps that can be abused for persistence simply because they are so popular.

Today’s subject is a software that is very unusual – the burning software. 15 years ago everyone was using it. Today it’s really a bit of a remnant of the good old times. I have not burnt a single CD/DVD since 2009-2010. I really can’t recall any instance where I would do so within last 8 years. The cloud, the USB 3.0, and capacity of external drives pretty much rendered media burning obsolete.

Except, according to my quick Twitter quiz question many still use it.

Nero was and still is one of the best media burning applications. While I won’t cover its features in detail I do want to acknowledge its role in shaping the media burning industry – at some stage it was a staple program used by many ‘burners’.

Its popularity, even today, can be used for not-so-nice-reasons.

How?

The simplest way is to drop a fake plug-in inside the following location:

  • c:\Program Files\Common Files\Ahead\AudioPlugins

The plug-in must be a DLL file named with a ‘nx’ prefix, and exporting two functions:

  • NERO_PLUGIN_GetPrimaryAudioObject
  • NERO_PLUGIN_ReadyToFinish

Such plug-in can be then loaded anytime user wants to burn the Audio CD. For testing purposes, the easiest way to ‘trigger’ the execution is by going to Tools, and looking at Plugins Options. All the DLLs, as long as properly named, will load and execute at least their DllMain.

There are more locations that can be potentially abused:

  • HKLM\SOFTWARE\Ahead\Shared\AudioEffects\DXPlugins
  • HKLM\SOFTWARE\Ahead\Nero PhotoSnap Shared\PluginManager\Plugins
  • HKLM\SOFTWARE\Ahead\Nero Mobile\Installer\Signed=<exe>
  • HKLM\SOFTWARE\Ahead\Nero Mobile\Installer\Unsigned=<exe>
  • HKLM\SOFTWARE\Ahead\Nero BurnRights\PathToBurnRights =<exe>
  • HKLM\SOFTWARE\Ahead\InCD\UI\LaunchOnBlankDisc=<exe>
  • HKLM\SOFTWARE\Ahead\Shared\<various registry names can be replaced>

Some of these executable paths could be replaced with others (man in the middle attack). Some can point to new plugins added under respective Nero applications suite.

And Nero is just an example. I think most of the popular applications that thrived in early noughties and survived to this day can be abused in a similar way as long as they offer some options for customization, and support plugins.

Using Virtual Machine tools for Guest OS fingerprinting

Posted on by

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.

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).

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.:

  • rpctool “info-set guestinfo.foo 1234”
  • rpctool “info-get guestinfo.foo”

Malware could either use the tool, or talk to the RPC interface directly.

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.

So, it could be yet another potential anti-sandbox trick/evasion.

There are more Guest OS tools.

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?

For example, using a tool VMwareToolboxCmd.exe, one can retrieve the time of the host machine:

  • VMwareToolboxCmd.exe stat hosttime

If the host and guest times are not synchronized, what could be the reason?

An alternative method can check if the time synchronization is enabled at all:

  • VMwareToolboxCmd.exe timesync status

Yet another way to detect possible customized properties of the guest OS is by looking at its scripts e.g.:

  • VMwareToolboxCmd.exe script power default

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 long time ago.

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.

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:

  • VMwareToolboxCmd.exe upgrade status

There is probably more possibilities out there…