Follow-up to #3180. Research proposal, not implemented or live-validated.
F1 — P1: binary-safe evidence, extending the existing classifier
Title: Preserve bounded binary HTTP evidence and capture completeness alongside existing serialization classification
Labels: security, analysis, enhancement
Proposal: Extend the current HTTP/API event contract with explicit capture completeness and safe binary evidence. Keep body collection bounded; record captured length, truncation/read-error state, encoding and a hash with clear semantics (captured prefix vs complete body). Retain a restricted byte-safe representation or artifact reference rather than claim a JSON string preserves arbitrary bytes. Add separate Java-marker evidence without replacing the current ordered serialized-object class shared with PHP. Never instantiate or deserialize received objects. Reuse established event ingestion/presentation, not the closed Suricata-display work.
Evidence: main.go:34-77,482-485,727-748; filebeat.yml:82-88; backend-service/src/events.rs:126,184.
Safe synthetic-event acceptance criteria:
- A four-byte Java stream header followed only by inert test text survives the selected binary representation byte-for-byte; no valid object graph, class name or executable content is used.
- Ordinary text, unrelated binary data, a PHP-like marker fixture and a short coincidental base64 prefix do not become confirmed Java exploitation events.
- Exactly-at-limit, over-limit and simulated read-error cases distinguish complete, truncated and unknown capture; hashes explicitly describe the bytes hashed.
- An earlier-priority classifier match does not erase a separate marker-observed field; existing payload-class semantics are retained.
- Offline serialization/normalization fixtures retain the new fields under
honeypot.*; ordinary presentation does not expose captured credentials or bearer tokens.
- Labels remain “marker/content observed,” never “RCE succeeded,” “CVE confirmed,” or “Interlock.”
Snapshot assessed: 00593d1d693cc7fe792beb7d24724dca5f55b2b8. Evidence paths are relative to APIARY. All acceptance tests must be offline and use inert fixtures; no exploitation, credentials, appliance access or deployment is authorized.
Follow-up to #3180. Research proposal, not implemented or live-validated.
F1 — P1: binary-safe evidence, extending the existing classifier
Title: Preserve bounded binary HTTP evidence and capture completeness alongside existing serialization classification
Labels:
security,analysis,enhancementProposal: Extend the current HTTP/API event contract with explicit capture completeness and safe binary evidence. Keep body collection bounded; record captured length, truncation/read-error state, encoding and a hash with clear semantics (captured prefix vs complete body). Retain a restricted byte-safe representation or artifact reference rather than claim a JSON string preserves arbitrary bytes. Add separate Java-marker evidence without replacing the current ordered
serialized-objectclass shared with PHP. Never instantiate or deserialize received objects. Reuse established event ingestion/presentation, not the closed Suricata-display work.Evidence:
main.go:34-77,482-485,727-748;filebeat.yml:82-88;backend-service/src/events.rs:126,184.Safe synthetic-event acceptance criteria:
honeypot.*; ordinary presentation does not expose captured credentials or bearer tokens.Snapshot assessed:
00593d1d693cc7fe792beb7d24724dca5f55b2b8. Evidence paths are relative to APIARY. All acceptance tests must be offline and use inert fixtures; no exploitation, credentials, appliance access or deployment is authorized.