How to Analyze Virtual Disk (.VMDK) Files for Threats Using an API in Java

Virtual disk image files — also known as.vmdk files, used by VMware — certainly aren’t your average upload.

Appreciating the Scale of .VMDK as an Attack Vector

Virtual disk image files can span gigabytes, and they often contain full operating system environments. That makes them a prime target for threat actors looking to sneak malware directly into virtualized infrastructure.

If one of your Java applications handles.vmdk uploads for any reason — whether for backup imports, virtual machine provisioning, or infrastructure tooling — it’s critical to treat those files as potential vectors for executable payloads, rootkits, or system-level exploits embedded in the virtual disk content.

It shouldn’t really matter how much you think you can trust where the file came from — the risk of such a complex file compromising your system is too great to warrant any implicit trust.

Approaching .VMDK Scanning with an API

By integrating a free virus scanning API, we can run pre-processing checks that flag .vmdk files for known viruses, invalid file structures, or unsafe embedded content before our application ever mounts or handles the virtual disk.

Overall, this is intended to be lightweight solution for enforcing security without compromising functionality. However, it’s important to bear in mind that .vmdk files typically aren’t lightweight themselves. Scanning large .vmdk files (or any large file, for that matter) takes up a lot of resources — no matter how we slice it. We can use the example code provided below to scan smaller file sizes, but if we’re looking to solve this problem in an enterprise-scale context, we’ll need to provision enterprise-grade resources to meet those needs.

Let’s take a look at structuring an example API call in Java.

Get Cloudmersive’s stories in your inbox

Join Medium for free to get updates from this writer.

Remember me for faster sign in

We’ll first install the SDK with Maven. We’ll add a reference to the repository in our pom.xml:

<repositories>
    <repository>
        <id>jitpack.io</id>
        <url>https://jitpack.io</url>
    </repository>
</repositories>

And then we’ll add a reference to the dependency in our pom.xml:

<dependencies>
<dependency>
    <groupId>com.github.Cloudmersive</groupId>
    <artifactId>Cloudmersive.APIClient.Java</artifactId>
    <version>v4.25</version>
</dependency>
</dependencies>

Next, we’ll add the imports to the top of our file:

// Import classes:
//import com.cloudmersive.client.invoker.ApiClient;
//import com.cloudmersive.client.invoker.ApiException;
//import com.cloudmersive.client.invoker.Configuration;
//import com.cloudmersive.client.invoker.auth.*;
//import com.cloudmersive.client.ScanApi;

And, finally, we’ll initialize the API client, set API key for authentication (this is where our free API key comes in), and create an instance of the API, with which we’ll scan our loaded .vmdk:

ApiClient defaultClient = Configuration.getDefaultApiClient();

// Configure API key authorization: Apikey
ApiKeyAuth Apikey = (ApiKeyAuth) defaultClient.getAuthentication("Apikey");
Apikey.setApiKey("YOUR API KEY");
// Uncomment the following line to set a prefix for the API key, e.g. "Token" (defaults to null)
//Apikey.setApiKeyPrefix("Token");

ScanApi apiInstance = new ScanApi();
File inputFile = new File("/path/to/inputfile"); // File | Input file to perform the operation on.
Boolean allowExecutables = true; // Boolean | Set to false to block executable files (program code) from being allowed in the input file.  Default is false (recommended).
Boolean allowInvalidFiles = true; // Boolean | Set to false to block invalid files, such as a PDF file that is not really a valid PDF file, or a Word Document that is not a valid Word Document.  Default is false (recommended).
Boolean allowScripts = true; // Boolean | Set to false to block script files, such as a PHP files, Python scripts, and other malicious content or security threats that can be embedded in the file.  Set to true to allow these file types.  Default is false (recommended).
Boolean allowPasswordProtectedFiles = true; // Boolean | Set to false to block password protected and encrypted files, such as encrypted zip and rar files, and other files that seek to circumvent scanning through passwords.  Set to true to allow these file types.  Default is false (recommended).
Boolean allowMacros = true; // Boolean | Set to false to block macros and other threats embedded in document files, such as Word, Excel and PowerPoint embedded Macros, and other files that contain embedded content threats.  Set to true to allow these file types.  Default is false (recommended).
Boolean allowXmlExternalEntities = true; // Boolean | Set to false to block XML External Entities and other threats embedded in XML files, and other files that contain embedded content threats.  Set to true to allow these file types.  Default is false (recommended).
Boolean allowInsecureDeserialization = true; // Boolean | Set to false to block Insecure Deserialization and other threats embedded in JSON and other object serialization files, and other files that contain embedded content threats.  Set to true to allow these file types.  Default is false (recommended).
Boolean allowHtml = true; // Boolean | Set to false to block HTML input in the top level file; HTML can contain XSS, scripts, local file accesses and other threats.  Set to true to allow these file types.  Default is false (recommended) [for API keys created prior to the release of this feature default is true for backward compatability].
String restrictFileTypes = "restrictFileTypes_example"; // String | Specify a restricted set of file formats to allow as clean as a comma-separated list of file formats, such as .pdf,.docx,.png would allow only PDF, PNG and Word document files.  All files must pass content verification against this list of file formats, if they do not, then the result will be returned as CleanResult=false.  Set restrictFileTypes parameter to null or empty string to disable; default is disabled.
try {
    VirusScanAdvancedResult result = apiInstance.scanFileAdvanced(inputFile, allowExecutables, allowInvalidFiles, allowScripts, allowPasswordProtectedFiles, allowMacros, allowXmlExternalEntities, allowInsecureDeserialization, allowHtml, restrictFileTypes);
    System.out.println(result);
} catch (ApiException e) {
    System.err.println("Exception when calling ScanApi#scanFileAdvanced");
    e.printStackTrace();
}

We can look at the bleow response model to better understand how our files are being analyzed:

{
  "CleanResult": true,
  "ContainsExecutable": true,
  "ContainsInvalidFile": true,
  "ContainsScript": true,
  "ContainsPasswordProtectedFile": true,
  "ContainsRestrictedFileFormat": true,
  "ContainsMacros": true,
  "ContainsXmlExternalEntities": true,
  "ContainsInsecureDeserialization": true,
  "ContainsHtml": true,
  "ContainsUnsafeArchive": true,
  "ContainsOleEmbeddedObject": true,
  "VerifiedFileFormat": "string",
  "FoundViruses": [
    {
      "FileName": "string",
      "VirusName": "string"
    }
  ],
  "ContentInformation": {
    "ContainsJSON": true,
    "ContainsXML": true,
    "ContainsImage": true,
    "RelevantSubfileName": "string",
    "IsAuthenticodeSigned": true
  }
}

We’re getting a deep snapshot into our file when we scan our files this way. We’re treating viruses, malware, and malformed content as the equal threats they are in the modern-day threat landscape.