Hysolate Workstations NOT impacted by CryptoAPI Vulnerability

Tal Zamir
January 16, 2020


Microsoft recently disclosed a spoofing vulnerability that enables an attacker to sign a malicious executable, making it appear that the file was from a trusted, legitimate source. It also enables attackers to conduct man-in-the-middle network attacks. In the recommended configuration of Hysolate, Hysolate customers are not impacted by this vulnerability due to Hysolate’s secure-by-design architecture that prevents contamination of the privileged VM if the general VM has been compromised. Furthermore, the Hysolate platform includes a Linux-based network security VM that is unaffected by the Windows vulnerability. This security VM can identify any issues with a certificate, and would block the connection if an attacker were to attempt this exploit on a Hysolate workstation. 


In January 2020, Microsoft disclosed the following vulnerability:

“A spoofing vulnerability exists in the way Windows CryptoAPI (Crypt32.dll) validates Elliptic Curve Cryptography (ECC) certificates. 

An attacker could exploit the vulnerability by using a spoofed code-signing certificate to sign a malicious executable, making it appear the file was from a trusted, legitimate source. The user would have no way of knowing the file was malicious, because the digital signature would appear to be from a trusted provider.

A successful exploit could also allow the attacker to conduct man-in-the-middle attacks and decrypt confidential information on user connections to the affected software.”

Impact on Windows Machines

There are severe implications of this vulnerability on non-Hysolate Windows machines. Specifically, it allows an attacker to conduct the following simple attacks (as an example):

  1. Convince a user to download and launch an executable. The normal protections and warnings of Windows wouldn’t work as Windows would believe the executable is properly signed. 
  2. If the attacker is on the same network as the target machine, he can try to perform a man-in-the-middle attack and successfully impersonate a server (e.g. a banking server, a software update server, …) by presenting a malicious certificate that leverages the cryptographic Windows vulnerability above. By doing so, the attacker can make Windows executables of his choice or make the user type his credentials into an attacker-controlled server.

No Impact on Hysolate Machines

Hysolate machines are unaffected by this and many other Windows vulnerabilities. 

The diagram below shows a sample setup of a Hysolate machine in which there are two zones: 

  1. A “general zone”: a VM running a day-to-day Windows OS for productivity apps, email, internet, etc.
  2. A “privileged zone”: a VM running a locked-down Windows OS with sensitive apps and data.

An attacker can convince the user to run a malicious executable in the general VM (e.g. via email / casual browsing / drive-by download) and potentially own the Windows OS in the general VM. However, the attacker would not be able to access anything on the privileged OS as it’s running in a hypervisor-isolated VM. The Hysolate architecture protects the privileged VM by-design.

Furthermore, with Hysolate, man-in-the-middle attacks on the compromised general VM would be futile. All network traffic goes through a dedicated locked-down Linux-based network security VM that by default inspects TLS connections and verifies server certificates. If the attacker attempts a man-in-the-middle attack against a Hysolate machine, faking the certificate of a server, the Linux-based network security VM (which is unaffected by this Windows cryptographic vulnerability) would identify the issue with the certificate and would block the connection. 

This is in accordance with the following NSA advisory:

“Properly configured and managed TLS inspection proxies independently validate TLS certificates from external entities and will reject invalid or untrusted certificates, protecting endpoints from certificates that attempt to exploit the vulnerabilities.”

As a general note, Hysolate machines are secure-by-design, built with a multi-layered defense-in-depth strategy. The fact that any TLS network connection gets validated both by a Linux-based network security VM and by the Windows operating system in the guest, makes it extremely hard for an attacker to exploit TLS vulnerabilities, requiring the attacker to combine multiple zero-day TLS vulnerabilities in different operating systems. 

Next steps

  • Hysolate customers using the Hysolate web filtering feature do not need to take any action to mitigate the Windows cryptographic vulnerability other than verifying the certificate validation option has not been turned off by the Hysolate administrator. You can contact your technical contact at Hysolate to verify your policies are set up to support that.
  • As always, it is recommended to patch your Windows operating systems (including those running on Hysolate VMs) to the latest version via Windows Update as in most cases you also want to prevent an infection of one of the guest operating systems running on Hysolate.

Tal Zamir

Tal is a 20-year software industry leader with a track record of solving urgent business challenges by reimagining how technology works. An entrepreneur at heart, he has pioneered multiple breakthrough cybersecurity and virtualization products. Before founding Hysolate, Tal incubated next-gen end-user computing products in the CTO office at VMware. Earlier, he was part of the leadership team at Wanova, a desktop virtualization startup acquired by VMware. Tal began his career in an elite IDF technology unit, leading mission-critical cybersecurity projects that won the prestigious Israeli Defense Award. He holds multiple US patents as well as an M.Sc. degree in Computer Science, and the honor of valedictorian, from the Technion.