JavaSerialKiller: A Historical Look at Burp-Integrated Deserialization Testing

Hook

In 2015, a single vulnerability class—insecure Java deserialization—was labeled "the gift that keeps on giving" by security researchers. JavaSerialKiller was among the first tools to make exploiting these flaws point-and-click simple within Burp Suite.

Context

Java deserialization vulnerabilities represent one of the most severe classes of security flaws in enterprise applications. When an application accepts serialized Java objects from untrusted sources and deserializes them without validation, attackers can achieve remote code execution by crafting malicious object graphs that trigger dangerous method chains during reconstruction. The challenge for security testers was that exploiting these vulnerabilities required deep knowledge of available "gadget chains"—sequences of existing classes in common libraries that could be chained together to execute arbitrary code.

ysoserial, released in 2015 by Chris Frohoff and Gabe Lawrence, revolutionized this space by providing a comprehensive collection of pre-built gadget chains targeting popular Java libraries like Apache Commons Collections, Spring Framework, and Groovy. However, using ysoserial in web application security assessments remained tedious: testers had to generate payloads at the command line, manually base64-encode them, copy-paste into Burp Suite requests, and repeat this cycle for each test. JavaSerialKiller emerged to solve this workflow friction by embedding ysoserial directly into Burp's interface, allowing penetration testers to generate and inject deserialization payloads with a few clicks from the context menu.

Technical Insight

JavaSerialKiller operates as a Burp Suite extension that acts as a wrapper around ysoserial's payload generation engine. When you install the extension, it adds new context menu items to Burp's Repeater, Intruder, and Proxy history. The workflow is elegant: highlight a parameter value or request body section where you suspect a serialized object is expected, right-click to access the JavaSerialKiller menu, select your target gadget chain (like CommonsCollections5 or Jdk7u21), specify your command payload, and the extension replaces the highlighted text with the generated exploit.

The architecture integrates ysoserial as a library dependency rather than shelling out to an external process. This design choice provides several advantages: faster payload generation since there's no subprocess overhead, better error handling since exceptions propagate through the Java call stack, and the ability to maintain state between payload generations. Here's how a typical integration might look in the extension code:

public byte[] generatePayload(String gadgetType, String command) {
    try {
        // Dynamically load the ysoserial payload class
        Class<?> payloadClass = Class.forName(
            "ysoserial.payloads." + gadgetType
        );
        ObjectPayload payload = (ObjectPayload) payloadClass.newInstance();
        
        // Generate the malicious serialized object
        Object exploit = payload.getObject(command);
        
        // Serialize to byte array
        ByteArrayOutputStream bos = new ByteArrayOutputStream();
        ObjectOutputStream oos = new ObjectOutputStream(bos);
        oos.writeObject(exploit);
        oos.flush();
        
        byte[] serialized = bos.toByteArray();
        
        // Optionally base64 encode if checkbox is selected
        if (shouldBase64Encode) {
            return Base64.getEncoder().encode(serialized);
        }
        return serialized;
        
    } catch (Exception e) {
        throw new PayloadGenerationException(
            "Failed to generate " + gadgetType + " payload", e
        );
    }
}

The extension's GUI provides a dropdown listing all available ysoserial gadget chains, automatically discovered by scanning ysoserial's payload classes. This dynamic discovery means that if ysoserial's payload collection grows, the extension theoretically picks up new chains without modification—though in practice, this never materialized due to the project's abandonment.

One clever implementation detail is how JavaSerialKiller handles payload replacement. When you highlight text in a request and generate a payload, the extension tracks the exact byte offsets of your selection. Since serialized Java objects and their base64-encoded forms have different lengths, naive replacement would break subsequent attempts. The extension recalculates positions intelligently, maintaining the conceptual "location" of the injection point even as the actual byte offsets shift.

The base64 encoding toggle deserves special mention. Many Java applications transmit serialized objects as base64-encoded strings in JSON, XML, or URL parameters rather than raw binary in request bodies. JavaSerialKiller's checkbox for automatic encoding eliminates a tedious manual step, though it's a simple transform—essentially Base64.getEncoder().encodeToString(serializedBytes). This seemingly minor convenience significantly accelerates the testing workflow when you're cycling through dozens of potential injection points.

Integration with Burp's extension API means JavaSerialKiller can also populate Intruder payload positions with generated exploits. This enables automated testing across multiple gadget chains or commands, turning a manual testing process into a semi-automated scan for vulnerable deserialization endpoints. The extension registers custom Intruder payload generators that invoke ysoserial with parameters you specify in the attack configuration.

Gotcha

The most critical limitation is right in the README: JavaSerialKiller is explicitly deprecated by its own author. The repository hasn't seen meaningful updates since 2017, and the maintainer actively recommends using Federico Dotta's Java-Deserialization-Scanner or other modern alternatives. This isn't just abandonment—it's a red flag from someone who knows the codebase intimately that the tool no longer meets current needs.

The Java 8 requirement creates immediate compatibility problems. Modern Burp Suite versions run on Java 11 or later, and many security testing environments have moved to Java 17+. The extension relies on specific Java 8 internals and ysoserial versions that expect Java 8's standard library structure. Attempting to load JavaSerialKiller in current Burp installations typically results in class loading errors or runtime exceptions. While you could theoretically run an older Burp version with Java 8, doing so means missing years of security fixes, feature improvements, and compatibility with modern web technologies. Additionally, ysoserial itself has evolved with new gadget chains targeting vulnerabilities in recent library versions, but JavaSerialKiller's bundled ysoserial version remains frozen in time, missing critical payloads for contemporary applications.

Verdict

Skip if: You're conducting security assessments in 2024 or later. The deprecated status, Java 8 requirement, and author's explicit recommendation to use alternatives make this a poor choice for production security testing. Modern tools like Java-Deserialization-Scanner provide superior functionality with active maintenance, support for current Java versions, and updated gadget chain collections. Use if: You're studying the history of Burp extension development, researching how early deserialization testing tools were architected, or maintaining legacy systems that specifically require Java 8 compatibility. Even then, consider running ysoserial directly via command line rather than fighting with deprecated extension compatibility. For all practical pentesting purposes, this tool belongs in the museum of security testing history—instructive to examine, inadvisable to deploy.