Separate HTTP status, credential extraction and simulated authentication outcomes in web telemetry

[Xore]

Follow-up to #3180. Research proposal, not implemented or live-validated.

F2 — P1: authentication evidence and outcomes

Title: Separate HTTP status, credential extraction and simulated authentication outcomes in web telemetry

Labels: security, analysis, enhancement

Proposal: Define credential presence/extraction status and outcome provenance for existing HTTP/management decoys. Distinguish absent, present-but-unparsed and unknown credentials, HTTP response status, and simulated/real/unknown authentication outcome. Use source event/session correlation only where genuinely available. Restrict secret-bearing values; routine detections need presence and verified-indicator-match booleans, not password text. Do not introduce a supposed FMC default-credential list or infer real auth success from 200.

Evidence: HTTP main.go:751-783,926-929; ASA event schema main.go:41-58 and webvpn.go:161-165.

Safe synthetic-event acceptance criteria:

• Canned login-page HTTP 200 and tarpit HTTP 200 never count as successful authentication or auth bypass.
• A fictional form, a fictional Basic header, an unknown JSON shape, missing fields and a truncated form produce distinct extraction/presence states without printing credential values.
• A request with a preexisting synthetic session is not classified credential-free solely because this request omits login fields.
• A fictional static-credential indicator can mark an attempted use only within its fictional product/account scope; it cannot mark successful access or CVE-2026-20316 exploitation.
• A test explicitly rejects the inference “port 8443 + status 200 = FMC bypass.” Unknown outcomes remain unknown after ingestion and rendering.

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.