Thanks to “” for this photo – it demonstrates how small glitches over time can add up if they aren’t addressed rapidly – or better yet, not allowed to start in the first place.

Cross section of layers of paint showing deformation due to imperfections magnified with each layer.
Layers of paint – credit to MaricxX from Reddit –

At a previous job it was common to take our Windows virtual machine templates and power them on once a month to patch the OS and apply the latest security configurations. We had been doing this with our Red Hat Linux images, but a couple years ago I converted our process so each month we built those VM templates fresh from an ISO and a Hashicorp Packer script using VMware Workstation.

This monthly fresh build ensured that we always knew how to build the VM templates in the event of a disaster, and it ensured that our build process contained exactly what we planned and advertised (through our team Git repository). As new requirements were received from the InfoSec team or other sources with system concerns that could only be readily addressed during the initial build phase, we would add those steps to the Packer config file, then test and build new.

With the prevalence of new worms and other highly effective infection vectors, my fear was that we would get a piece of malware onto the templates and then that malware would be automatically replicated each time a new system was built. And there were many times when we started the patching process each month only to find that a couple of the Windows templates had been left running since the previous months patch effort. There is no telling what might have crawled onto these unmanaged systems in the intervening time, only waiting for us to start using them over time.

While the paint analogy doesn’t perfectly match with the IT world, there are sufficient correlations that it makes the possibility of replicating and amplifying a small defect all the more understandable. Still, I prefer to have my freshly-built template with it’s minimal layers of paint knowing that I am confident that it only contains the bits we wanted.


Windows 10, VMware Workstation 15.5, and “Device/Credential Guard”

So I’m trying to create some documentation around our VMware template build process and I’m starting from a freshly built Windows 10 system with all patches as of December 2019. Our process uses Hashicorp Packer to automate the build of our Red Hat VM templates using VMware Workstation 15.5 running a Bash script under Windows Subsystem for Linux (WSL). It is a bit more complex than I wanted, but ultimately we want this to run in a fully automated process on a Linux build server so WSL is a good bridge.

Today when I was going through our pre-requisite setup steps, my fresh VMware installation would throw an error pop-up message:

Googling for an answer, I found a lot of one-off solutions but none of them worked. After searching for most of the day, I came across this YouTube video by Britec09 :

I usually don’t sit through YouTube videos for issues such as these, but this time I was getting desperate for an answer.

And Mr. Britec09 came through!

To cut to the chase, the steps he provided were all similar or identical to others I had found, except his ran in this order and all at once seemed to be my solution.

To save time if this happens to me again, here are the steps as he included them in his YouTube notes.

NOTE: Please be careful – many of these tools used below will permit you to accidentally break your system.

Step 1. – In the search box type “gpedit” then Goto Computer Configuration Administrative Templates System Device Guard Turn on Virtualization Based Security.
Double click that option and choose “Disable”

Step 2. In search box, type Turn Windows features on or off, then uncheck Hyper-V and restart system.

Step 3. Open Registry Editor by typing regedit in the search box. Go to HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\DeviceGuard. Right-click in the right panel, add a new DWORD value named EnableVirtualizationBasedSecurity and set it to 0 to disable it.
Next Go to HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\LSA. Right-click and add a new DWORD value named LsaCfgFlags and set it to 0 to disable it.

Step 4. Open command prompt as a administrator and type the following commands

bcdedit /create {0cb3b571-2f2e-4343-a879-d86a476d7215} /d "DebugTool"  /application osloader

Then copy paste the rest below and press enter – there are four lines of commands, each beginning with “bcedit”.

bcdedit /set {0cb3b571-2f2e-4343-a879-d86a476d7215} path  "\EFI\Microsoft\Boot\SecConfig.efi"

bcdedit /set {bootmgr} bootsequence  {0cb3b571-2f2e-4343-a879-d86a476d7215}

bcdedit /set {0cb3b571-2f2e-4343-a879-d86a476d7215} loadoptions  DISABLE-LSA-ISO,DISABLE-VBS

bcdedit /set hypervisorlaunchtype off 

Step 5. If all of that worked without any errors, reboot your system and re-try VMware Workstation.