The Anti-VM trick that is kinda… personal

I have written a lot about anti-vm tricks, and while this topic is so worn out that almost feels like kicking a dead horse I felt there is still a scope for some ‘novelty’ approach…

As a hobby, I started jotting down OPSEC failures from random reverse engineers and security professionals. I didn’t go too far, but once you see the list, you will get the gist and can easily expand on it a bit more.

Trust me, this is nothing personal. But yeah, it totally is ๐Ÿ™‚

Analysing screenshots shared on social media I was able to jot down some notes on the user names used by the researchers’ boxes/test environments. Some of these user names are generic, and as such, not very helpful, but hey… many actually are pretty specific!

So, a personalized anti-* trick could simply add these known user names to a ‘we don’t run here’ list i.e. if any of these user names is found on the system –> gracefully exit.

Not very complex… but you didn’t see it coming!

Twitter HandleUser name
pr0xylifepr0xylifelab
mrd0xmr.d0x
WietzeWietze
inversecosLina Lau
mohammadaskar2askar
DissectMalwareaniak
falsnegfreddy
Oddvarmoeoddva
mrAn61taro
SBousseadenbouss
vinopaljiriInferno
stvemillertimesteve
x86matthewWin10
0gtweetAdministrator
0gtweetAdmin
jonasLykjonas

Honorary mention:

Twitter HandleUser name
Ledtech3JoeUser

Update

Not all these are correct findings f.ex. see response from proxylife.

Good fileโ€ฆ (What is it good for) Part 3

We have our sampleset. We have our metadata.

What’s next?

You can very quickly script searches that will look for specific files, or their properties. I mentioned section names, PDB paths, icons, but there is more.

In my older blog post I highlighted a presence of a copy&paste crypto code block present in a number of ‘good’ files I have looked at. The reason I recognized these samples is pretty simple: they used API calls that happen to be on the list of all APIs that are of my interest.

So…

Once you get your sampleset processed, generated its preliminary metadata, you can look at the properties extracted from the files and/or either re-run some additional metadata collection tasks (often narrowed down to specific file types), and/or … disassemble/decompile these files for some quick code-based post-processing & … quick wins. The above example is one of them.

What these post-processing tasks could be?

Running yara, capa is of course a ‘must-do’ and it’s trivial. But that’s not everything. You can (and should) run instrumented oleview, or olewoo to extract additional OLE/COM info from embedded type libraries. They not only give us info about unique GUIDs, but often point us to proprietary COM interfaces and methods of interest that could be used to do some ‘funny’ stuff – think: file downloading, program execution, escalation of privileges, etc.

The next targets are drivers – they themselves are of always of interest, because ‘who runs code in kernel – owns the box’. @hFirefox (Twitter account doesn’t exist anymore as of today) created a number of POCs showing that legitimate, signed, yet vulnerable kernel drivers can be abused to deliver payloads of (user mode) choice. There is definitely more vulnerable drivers out there, and guess what… some basic kernel driver analysis can be also done statically.

If you look at a number of them, you will start recognizing a lot of patterns. For instance, it’s not uncommon for kernel mode driver developers to include the whole list of debug messages that often help understanding the internals of their creations. To be precise… for instance, grepping for ‘IOCTL_’ prefixed strings inside kernel drivers will give us a lot of hints with regards to what the driver does, and how it operates. And yes, it will give us names of many IOCTLs as well!

Yup.

We can bulk analyze these.

How?

Yes, I will cover this soon ๐Ÿ™‚