Serialized Object Detection

Serialized Object Detection is RedAmon's insecure-deserialization capability. It is split into two halves that work as one loop:

• Detect (recon). A passive, in-memory recon module — Serialized Object Scan — reads what the pipeline already holds (response headers, Set-Cookie, and the parameters resource enumeration discovered) and flags serialized-object signatures across every major family. Each hit becomes an info-severity :Vulnerability candidate marked needs_agent_confirmation. Recon sends no extra traffic and never deserializes anything.
• Confirm (agent). The built-in Insecure Deserialization agent skill reads those candidates, confirms the one that matters with a non-destructive out-of-band oracle, and records proof so the candidate is promoted on the Priority Board.

The split is deliberate: recon flags "serialization is present and attacker-reachable" cheaply and safely; the agent does the request-side digging and the confirmation. A candidate stays a quiet lead until the agent proves it.

Why two halves

Serialized blobs mostly ride request-side — cookies, POST bodies, parameters. The recon pipeline's in-memory corpus only carries the response side plus the enumerated endpoints/parameters (request bodies are dropped). So recon seeds candidates from what it can see for free, and the agent — which has full captured-traffic access via its traffic tools — pulls the original request and confirms. This is why TrafficMind (HTTP capture) is a soft prerequisite: with it on, the agent has a request-side corpus to confirm against. The recon side still runs without it, just with a thinner corpus.

What it detects

The scan runs every candidate value through a bomb-safe decode-and-recurse normalizer (URL → base64 → gzip → zlib → hex, re-matching at each layer) and matches these families:

Honest ceiling. Recon flags serialization present and reachable, not exploitable. It misses encrypted blobs, off-HTTP channels, and anything the in-memory slice never carried. Confirmation is the agent's job.

Safety

• Never deserializes. Standard-library decode + regex only — no pickle, no yaml.load, no ObjectInputStream-equivalent. The scanner never becomes the victim.
• Bomb-safe decoder. At most 4 decode layers and ≤ 1 MiB of decompressed output per value; a decompression bomb is aborted and the candidate is flagged truncated rather than expanded.
• Render-safe evidence. The stored evidence_snippet is printable-ASCII only (non-printable bytes hex-escaped), capped at 120 characters — never raw decoded bytes.

The candidate lifecycle

1. Recon writes a :Vulnerability {source:'serialized_scan', needs_agent_confirmation:true, severity:'info'} candidate, linked to the affected Endpoint/BaseURL via HAS_VULNERABILITY, carrying deser_language, deser_format, deser_transport (cookie / param / header), deser_location, deser_encoding_layers, deser_magic and evidence_snippet.
2. On the Priority Board the info severity pins it to T4 "Track" — the bottom of the list. It is a quiet lead, not noise at the top.
3. The agent's Insecure Deserialization skill reads pending candidates (read-only query_graph), confirms with a non-destructive out-of-band oracle, and reports the finding with finding_type='vulnerability_confirmed' plus the candidate's id.
4. That lands a proof-typed (:ChainFinding)-[:CONFIRMS]->(candidate) edge, which flows through the proof gate and promotes the candidate to T1 "Act now".

Until a candidate is confirmed, Pentest Reports and the Insights Dashboard hide it — an unconfirmed info candidate is never counted as a real vulnerability there. The graph screen, Node Inspector and Priority Board keep showing it, so an operator can always see the lead. Once confirmed, it appears in the report labelled "Insecure Deserialization".

The agent half: Insecure Deserialization skill

The built-in Insecure Deserialization agent skill (badge DESER, classification key deserialization) owns confirmation. See Agent Skills for the full write-up. In short, it:

1. Reuses recon first — query_graph for pending serialized_scan candidates (deterministic read: ORDER BY v.id + an explicit LIMIT), capturing each id and its deser_* metadata.
2. Pulls the original request with its traffic tools (search by endpoint/method, or fetch_transaction) rather than re-crawling; if there are no candidates it probes from scratch using the same signatures.
3. Confirms with a non-destructive out-of-band oracle (for example a Java URLDNS or a Python __reduce__-DNS blob that only performs a callback — no code runs).
4. Reports finding_type='vulnerability_confirmed' with the candidate id, then re-queries to verify the CONFIRMS edge landed (a wrong/cross-tenant id matches nothing silently).
5. Escalation to a code-execution gadget is gated off by default — the operator opts in per project. The default path is the non-destructive oracle only.

Settings

Both halves default off — a gated posture. An operator opts in per project.

Because the module only flags candidates, the Serialized Object Scan settings card shows an alert when the scan is on but the Insecure Deserialization agent skill is off — pointing you to AI Agent → Attack Skills so the detect→confirm loop is not left half-wired. A second note recommends enabling TrafficMind so the agent has captured traffic to confirm against.

Presets

Serialized Object Scan is pre-enabled in the web/API/active-focused presets: API Security Audit, Web App Pentester, Bug Bounty - Deep Dive, Parameter & Injection Surface, Full Pipeline - Active Only, and Full Pipeline - Maximum. Every other preset leaves it off.

Pipeline position

Serialized Object Scan runs as a passive GROUP 5b step, beside JS Reconnaissance — after HTTP probing and resource enumeration (so the corpus it reads is populated), and it runs even when active scans are skipped. In the Recon Pipeline Workflow view it appears as the Serialized Objects node (passive badge) in the JS-Recon group, consuming BaseURL + Endpoint and producing Vulnerability candidates.

It is also available as a single-phase partial recon run from the workflow graph (reads BaseURLs + Endpoints from the existing graph, plus any custom URLs you paste).

Reading candidates in the graph

Pending candidates awaiting confirmation:

MATCH (e:Endpoint)-[:HAS_VULNERABILITY]->(v:Vulnerability {source:'serialized_scan'})
WHERE v.needs_agent_confirmation = true
  AND NOT (:ChainFinding)-[:CONFIRMS]->(v)
RETURN e.url, v.id, v.deser_format, v.deser_transport, v.deser_location

The deser_* properties also appear in the Node Inspector and are filterable there. See Attack Surface Graph for the :Vulnerability schema.

Related

• Agent Skills — the Insecure Deserialization confirmation skill
• TrafficMind — the capture corpus the agent confirms against
• Priority Board — the info→T4→confirmed→T1 lifecycle
• Recon Presets — which presets enable the scan
• Pentest Reports · Insights Dashboard — where confirmed findings surface