How to Quarantine a Malicious File in Java

Scanning file uploads for viruses, malware, and other threats is standard practice in any application that processes files from an external source.  

No matter which antimalware we use, the goal is always the same: to prevent malicious executables from reaching a downstream user (directly, via database storage, etc.) or automated workflow that might inadvertently execute the malicious content.

In this article, we’ll discuss the value of quarantining malicious files after they’re flagged by an antimalware solution instead of outright deleting them. We’ll highlight several APIs Java developers can leverage to quarantine malicious content seamlessly in their application workflow.

Deleting vs. Quarantining Malicious Files

While there’s zero debate around whether external files should be scanned for malicious content, there’s a bit more room for debate around how malicious files should be handled once antimalware policies flag them.

The simplest (and overall safest) option is to programmatically delete malicious files as soon as they’re flagged. The logic for deleting a threat is straightforward: it completely removes the possibility that downstream users or processes might unwittingly execute the malicious content. If our antimalware false positive rate is extremely low — which it ideally should be — we don’t need to spend too much time debating whether the file in question was misdiagnosed. We can shoot first and ask questions later.

When we elect to programmatically quarantine malicious files, we take on risk in an already-risky situation — but that risk can yield significant rewards. If we can safely contain a malicious file within an isolated directory (e.g., a secure zip archive), we can preserve the opportunity to analyze the threat and gain valuable insights from it. This is a bit like sealing a potentially venomous snake in a glass container; with a closer look, we can find out if the snake is truly dangerous, misidentified, or an entirely unique specimen that demands further study to adequately understand.

In quarantining a malicious file, we might be preserving the latest update of some well-known and oft-employed black market malware library, or in cases involving heuristic malware detection policies, we might be capturing an as-of-yet-unseen malware iteration. Giving threat researchers the opportunity to analyze malicious files in a sandbox can, for example, tell us how iterations of a known malware library have evolved, and in the event of a false-positive threat diagnosis, it can tell us that our antimalware solution may need an urgent update. Further, quarantining gives us the opportunity to collect useful data about the attack vectors (in this case, insecure file upload) threat actors are presently exploiting to harm our system. 

Using ZIP Archives as Isolated Directories for Quarantine

The simplest and most effective way to quarantine a malicious file is to lock it within a compressed ZIP archive. ZIP archives are well-positioned as lightweight, secure, and easily transferrable isolated directories. After compressing a malicious file in a ZIP archive, we can encrypt the archive to restrict access and prevent accidental execution, and we can apply password-protection policies to ensure only folks with specific privileges can decrypt and “unzip” the archive.

Open-Source APIs for Handling ZIP Compression, Encryption, and Password-Protection in Java

In Java, we have several open-source tools at our disposal for archiving a file securely in any capacity.   We could, for example, use the Apache Commons Compress library to create the initial zip archive that we compress the malicious file in (this library adds some notable features to the standard java.util.zip package), and we could subsequently use a robust cryptography API like Tink (by Google) to securely encrypt the archive. 

After that, we could leverage another popular library like Zip4j to password protect the archive (it's worth noting we could handle all three steps via Zip4j if we preferred; this library features the ability to create archives, encrypt them with AES or other zip standard encryption methods, and create password protection policies).

Creating a ZIP Quarantine File With a Web API

If open-source technologies won’t fit into the scope of our project, another option is to use a single, fully realized zip quarantine API in our Java workflow. This can help simplify the end-to-end quarantining process and mitigate some of the risks involved in handling malicious files by abstracting the entire process to an external server.

Below, we’ll walk through how to implement one such solution into our Java project. This solution is free to use with a free API key, and it offers a simple set of parameters for creating a password, compressing a malicious file, and encrypting the archive.

We can install the Java SDK with Maven by first adding a reference to the repository in pom.xml:

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

And after that, we can add a reference to the dependency in pom.xml:

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

For a Gradle project, we could instead place the below snippet in our root build.gradle:

allprojects {
	repositories {
		...
		maven { url 'https://jitpack.io' }
	}
}

And we could then add the following dependency in our build.gradle:

dependencies {
        implementation 'com.github.Cloudmersive:Cloudmersive.APIClient.Java:v4.25'
}

With installation out of the way, we can copy the import classes at 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.ZipArchiveApi;

Now, we can configure our API key to authorize the zip quarantine request:

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");

Finally, we can create an instance of the ZipArchiveApi and configure our password, file input, and encryption parameters. We can customize our encryption algorithm by selecting from one of three options: AES-256, AES-128, and PK-Zip (AES-256 is the default value if we leave this parameter empty; PK-Zip is technically a valid option but not recommended). We can then call the API and handle errors via the try/catch block.

ZipArchiveApi apiInstance = new ZipArchiveApi();
String password = "password_example"; // String | Password to place on the Zip file; the longer the password, the more secure
File inputFile1 = new File("/path/to/inputfile"); // File | First input file to perform the operation on.
String encryptionAlgorithm = "encryptionAlgorithm_example"; // String | Encryption algorithm to use; possible values are AES-256 (recommended), AES-128, and PK-Zip (not recommended; legacy, weak encryption algorithm). Default is AES-256.
try {
    Object result = apiInstance.zipArchiveZipCreateQuarantine(password, inputFile1, encryptionAlgorithm);
    System.out.println(result);
} catch (ApiException e) {
    System.err.println("Exception when calling ZipArchiveApi#zipArchiveZipCreateQuarantine");
    e.printStackTrace();
}

After the API returns our quarantined file, we can upload the archive to a cloud-based quarantine repository, transfer it to a virtual machine, or take any number of different actions.

Conclusion

In this article, we discussed the benefits of quarantining malicious files after our antimalware software flags them. We then highlighted several open-source Java libraries that can be collectively used to quarantine malicious files in an encrypted, password-protected zip archive. Finally, we highlighted one fully realized (not open source) web API solution for handling each stage of that process with minimal code.