22 March 2017

Detecting deserialization bugs with DNS exfiltration

Written by Philippe Arteau | 22 March 2017

At the moment, Java deserialization vulnerabilities are becoming well known by vendors and attackers. Nevertheless, pentesters will still encounter these types of vulnerabilities. The low-hanging fruits can be identified with the current tools. Most of the available tools rely on the command execution API. However, the command from the payload may fail because of Operating System specific conditions. Additionally, the command used might be missing or the arguments it requires may differ due to the version of the command or the flavor installed (ie: GNU netcat vs OpenBSD netcat for example).

Due to the above-mentioned limitations of executing commands, detecting these bugs requires some trial and error. Having to send multiple payloads per target makes automation harder. Crafting a universal payload would simplify large scale detection of deserialization bugs. Before introducing our scanning approach, let’s define a set of objectives for a more reliable payload.


  • Make the payload totally agnostic of the operating system such as Windows, Ubuntu, Alpine Linux (Docker), Solaris, AIX, etc.
  • Detect occurrences even if the targeted web container is running with a security manager or is sandboxed
  • Support the most common JVM version 1.6+ and maybe 1.5 *

* This is already the case of most payloads generated by YSoSerial

duke java deserialization

Example Scenario

The GoSecure penetration testing team has encountered few cases where modification of current gadgets was needed. For example, an old instance of JBoss was found (5.1.0 GA – EOL support) with JMXInvokerServlet exposed. Based on the version, it is expected to be vulnerable. Surprisingly, all known exploits tested against this instance of JBoss failed.

The failure of those exploits could mean two things: the gadget is not functional on this specific environment or the system was patched (as this is the expected behavior if the vulnerable Commons-Collection jar is replaced manually). Other known gadgets were tested without success. However, a simple payload that does a DNS query confirmed that the system is indeed vulnerable. Based on this assertion, it is now useful to build an alternative gadget that avoids the command execution API.


Creating a DNS Gadget

To confirm exploitability, we are going to modify one of the existing gadgets provided by YSoSerial. We are going to replace the command execution payload with a simple code that triggers a DNS resolution.

One of the most common payloads used is Commons Collection (no pun intended). The transformer chain below will trigger the following code:

Transformer chain (Command execution payload):

Code triggered:


We can’t use the nslookup command to trigger the DNS resolution, as we want to avoid using the command execution API, we will use Java API directly. The only special requirement is that the code sequence must use a telescopic API or in other words, no temporary variable can be used.

Transformer chain (DNS resolution payload):

Code triggered:

The transformer chain is equivalent to the following Java code. It will try to initiate an HTTP connection but the key element here is to trigger a DNS resolution.


Confirming vulnerability

We can now generate a gadget that will resolve a unique hostname. The unique name is a way to track if the server has done any deserialization. The server may evaluate the payload more than once or with a delay. Using unique hostnames avoids confusion especially when scanning multiple hosts. The complete PoC is available on our fork of ysoserial.

If a DNS query is received, the vulnerability is confirmed. To record the DNS queries, DNS chef, Burp Collaborator or tcpdump can be used. In the sample below, we can see DNS queries reaching a test server running with DNSChef.


dns exfiltration java scanner

Visual representation of a asynchronous scan

Additional considerations

Once the vulnerability is confirmed, the pentester may need to do some trial and error of commands to execute in order to get a shell. Here are a few useful tips getting that working:

  • Make sure you have tested various reverse shell commands (see Reverse Shell Cheat-Sheet)
  • Common collection payload may fail on certain JVM (IBM J9 for example). Mathias Kaiser made a payload specifically to support less common JVM: see CommonsCollections6.
  • If a security manager is enforced, you may need to craft a custom gadget. You can use DEADCODE’s blog article to understand the general recipe of transformer chain. One prevalent approach is to find the path to the web root directory and write a web shell that could be later executed. A sample gadget is available on this GoSecure repository. Again, this is only needed if the gadget is executed inside a security manager that blocks command execution.



Here is a short demonstration of the tool Break Fast Serial. It demonstrate the scanning of a single web server. The vulnerability is confirmed through DNS exfiltration. The tool also support a scanning mode to cover multiple IPs and ports. The scanner will detect vulnerable versions of JBoss, Weblogic and Jenkins. For more information, refer to the manual.



DNS exfiltration has three benefits:

  • It improves detection of deserialization vulnerabilities
  • It facilitates automated scanning of multiple hosts
  • It will identify vulnerable servers even in strictly firewalled environments

We published an automated scanner to find deserialization vulnerabilities in JBoss, Weblogic and Jenkins servers asynchronously. We plan to support other services. We invite testers to participate in the development. This broader and faster approach will help the defense side detect deserialization vulnerabilities sooner.

The current article focuses on CommonsCollection but the API used to build the gadget is reusable in other payloads. The same principle can also be used to detect vulnerabilities such as the recent Struts vulnerability.

UPDATE : A more elegant and simpler DNS gadget was created by Gabriel Lawrence. For more information, see Gabriel’s Blog and the code on the ysoerial.

NorthSec An advanced application security training will be given at NorthSec in May 2017 by Philippe Arteau the author of this blog article. The training will consist of many advanced techniques for the exploitation of modern Web applications. Make sure to register before the last early bird (March 31st).