Nested virtualization using VMware hypervisors

Nested virtualization is the act of running a hypervisor nested within another hypervisor.

For example, it is possible to run a Nested VMware ESXi 6.0 hypervisor over a VMware Player 7 hypervisor:


We may need to make some changes to the Nested Hypervisor virtual machine configuration file, as described in (VMware: Running Nested VMs – VMware: Running Nested VMs ).

It would be interesting for a guest machine to be able to detect to be running over a Nested Hypervisor.

I haven’t found a direct method (virtual hardware-based) yet. Some network testing and MAC Address and ESXi services correlation could do the trick, when networking is available.

For example, consider the following NMAP scan:

# nmap -vv -sV --version-all -p 443
Starting Nmap 6.47 ( ) at 2016-01-22 10:45 EST
Scanning [1 port]
443/tcp open ssl/http VMware ESXi Server httpd
MAC Address: 00:0C:29:BD:16:1F (VMware)

NMAP detects that there is an ESXi Server at IP and that its MAC Address is 00:0C:29:BD:16:1F, inside the VMware virtual MAC address range. This indicates that this machine may well be a Nested ESXi.

More details in the full paper at VMware hypervisor fingerprinting Tool ( & Paper)


VMware hypervisor fingerprinting Tool ( & Paper)

Just published a new tool vmhost_report.rb (and a paper about it) for VMware hypervisor fingerprinting. The tool is released with an open source license (GPL), you can use it freely.

In the paper, I show you how to determine hypervisor properties (such as hypervisor version or virtual CPU Limits) by running commands in the guest operating system, without any special privileges in the host machine running the hypervisor.

This can be useful for penetration testing, information gathering, determining the best software configuration for virtualization-sensitive and virtualization-aware software.

I have developed a reporting tool vmhost_report.rb that unifies all the presented methods, by running them all in sequence and gathering the information in a useful report that can be run from any guest system. Currently, Linux and Nested ESXi are supported.

You can run it as “ruby vmhost_report.rb“. It will return a lot of useful information in the vmhost_report.log file.

These reports can be used to learn a lot about VMware internals or a particular guest system or network. You can find report examples in the Paper’s “Annex A”.

Some of the described methods can be used even if the VMware Tools are disabled or not installed, or if some of the methods are disabled by host configuration. Some of the methods require “root” privileges, while others do not need it.




Domain Specific Languages (DSLs) – SLIDES

I’ve uploaded some slides about DSLs, you can find them at:



Reposting my previous post about DSLs bellow.

Screen Shot 09-01-16 at 04.54 PM

Byzantine mysteries

Domain Specific Languages (DSLs) are special-purpose programming languages developed for a specific domain. Some of its most interesting benefits include:

  • increasing productivity (by reducing the lines of code that have to be written manually)
  • test generation
  • formal verification

These languages work by using higher-level constructions and restrictions. They can be either textual (declarative or imperative) or graphical, and can include multiple views for the same domain.

I’ve used this type of languages extensively in my work and it saves a lot of time. “Preprocessing” is one of the tyipcal ways to implement them. Some subtypes include:

  • Macro processing
  • Source-to-source transformation (conversion between languages)
  • Pipeline
  • Lexical processing

( more info at )

You can use these languages for several purposes, including:

  • Defining an entity model
  • Protocol definition
  • High-level user interface description
  • Automated test case description
  • Software architecture description

Microsoft has some easy to use DSL editor tools in Visual Studio…

View original post 78 more words