This information includes the starting address of the thread, which Process Explorer helpfully translates to a name and offset using symbols. While looking through various system information in Process Explorer, I noticed that thread information for the System process (PID 4) was shown even when it was run without administrative privileges. Since drivers may create a certain number of threads, with varying predictable properties, these attributes can be used to fingerprint them and build heuristics that are useful for detection. The trick, put simply, involves detecting kernel mode drivers by the threads that they create. Proof of concept source code can be found here. Not only that, but it also leaks the addresses of driver code in kernel memory space, which is useful in driver exploitation scenarios. You can use this trick to stealthily discover the presence of almost any driver on the system you’re executing code on, using only a common multi-purpose API, without ever interacting with the driver service or driver files. This month’s trick was discovered accidentally, while researching something unrelated, but it is actually useful for much more than just VM detection. While hardware discrepancies are a rich source of VM detection tricks, it is also worth looking at the guest-side software used by virtualization solutions. In the first article we investigated the use of physical memory maps as a way of distinguishing between real and virtualized hardware. These detection tricks will be focused on 64-bit Windows 10 or Windows Server 2019 guests, targeting a variety of VM platforms. This year we’re documenting a series of new and as-yet undocumented VM detection tricks.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |