Logging & Monitoring Failures

§Basic information

Logging & monitoring failures are the two-way break of the audit pipeline. Either the log records too much — plaintext passwords, API keys, bearer tokens, and PII pulled into a file that a lower-privileged reader can reach — or it records too little / wrong — entries an attacker can forge, drop, or strip of attribution so detection and incident response never fire. A log is a durable, replayable credential store that outlives the request and sits outside the app's own access-control model: whoever can read the log effectively reads every secret that flowed through it.

The core mechanism is that sanitization is applied on the happy path and forgotten on the failure path. Auth code scrubs the password when login succeeds, then an exception handler serializes the call arguments — password included — the instant login fails. On the audit side, defenders check "is the action logged?" but not what is logged, so an event can be present yet forensically useless (blanked source IP) or absent entirely (an alternate endpoint wired to a different logging path). Treat logging bugs as a credential-harvest and anti-forensics primitive, not a compliance nit.

§Methodology

1. Get a log-read primitive first — decide how you can read logs, then decide what leaked. Log-read can be: local admin / shared container, a pods/log RBAC grant, a log-viewer feature in the app, an LFI/path-traversal, or an exposed/guessable log file (error.log, debug.log, *_ERROR_LOG).
2. Grep the reachable logs for the classic secret sinks (authorization, bearer, access_token, api_key, password) and for argument-dump signatures (ldap_bind, validateUserPass, toCurl).
3. Force the error/failure path — this is where scrubbing is weakest. Make the auth backend unreachable, fail a 2FA/WebDAV login, break SMTP mid-signup, or raise log verbosity so debug dumpers fire.
4. Read the secret out of the log and reuse it — a harvested password/token is replayed against the same or an adjacent service (LDAP, cluster API, the linked OAuth system).
5. For attacker-controlled fields (username, method, path, X-Forwarded-For), test whether they land in logs unescaped → log forging, entry-drop, ANSI injection, or audit-IP spoofing.
6. For audit evasion, don't ask "is it logged?" — baseline the production call, then diff an alternate endpoint (non-prod / FIPS / mirror) and check whether the event appears at all, and whether WHO/WHERE fields survive.

§Leak & lie sinks

Find which of these the target exhibits, then apply the matching probe.

Argument-dump / exception loggers

The single most common sink. A generic handler serializes the arguments of the failing call — and the secret was passed as one of those arguments. Trigger the failure path to make it fire.

Verbose / debug request dumpers

toCurl(), request/response dumpers, and "log the full HTTP call" helpers serialize headers — including Authorization and Cookie — often masking in one branch but not the sibling curl-dump branch. Raise verbosity to trigger them.

Raw SQL / query error logs

On DB failure, an error handler writes the entire failed statement — with every field value — into a log file. Find a reachable log, then grep for statements, not just stack traces.

Log injection & forging (attacker-controlled fields)

Any request-controlled value written into a space/quote-delimited log without escaping lets you forge lines, drop entries, or inject terminal escapes. The fields defenders forget: $remote_user (Basic-auth username), REQUEST_METHOD, path, and User-Agent.

The same class, delivered as raw control bytes. Send 0x08 (backspace) / 0x1b (ESC) inside a field the logger prints verbatim, and the sequence executes when an operator tails the log in a terminal.

Audit-trail spoofing & evasion

Two distinct failures. Spoof the recorded identity by poisoning a trusted-but-forgeable field; or evade by routing the call through an endpoint wired to a different (or no) logging path.

§Bypasses

§Escalation & impact

Logging bugs are almost never the endpoint — they feed the next stage.

• Log secret → credential reuse / privesc — a harvested plaintext password is replayed against LDAP or an adjacent service (#244092, #264426); a leaked bearer token is replayed to impersonate the user (#952771); a leaked Kubernetes service-account token is a direct cluster privesc (#966383); an OAuth token grants access to the linked system (#1394399).
• LFI / path-traversal → log-read → secret — any file-read primitive turns a secret-in-log sink into disclosure. Chain with path-traversal / file-upload primitives to reach the log file, then grep it.
• Audit evasion → invisible attack — silent IAM enumeration maps a stolen identity's exact privileges with no failed-call spike for defenders to alert on (#3780277), then attribution-blanking hides the follow-on actions (#2979238).
• Log-drop → anti-forensics — smuggling a delimiter to drop the log entry (#447488) hides the malicious request itself; pair it with any noisy exploit to blind the SIEM.
• PII in logs → mass disclosure — one reachable error log full of raw INSERT statements is a bulk customer-data breach with no SQLi required (#3242830).

§Prevention

• Scrub by parameter name, not a method allowlist — redact $password/token/secret wherever they appear, so a new method or an error path can't leak (fixes #264426, #1662194).
• Mask in every logging code path — request dumpers, toCurl()/toString() helpers, and each debug branch must reuse the same masking routine (#952771).
• Never log raw input before validation and never log raw SQL statements or DB rows; redact tokens before writing (#972561, #3242830, #1394399).
• Escape / strip control chars and delimiters in any attacker-controlled field written to logs, and quote every log_format placeholder so a smuggled space can't add a column (#1411867, #447488).
• Derive client IP from a trusted-proxy chain, not raw X-Forwarded-For / X-Real-IP (#296632).
• Treat every endpoint family (FIPS / mirror / non-prod) as needing full, attributed audit coverage — same signed request, different host must not mean different or absent logging (#3780277, #2979238).
• Scope log-read tightly — logs inherit none of the app's access control; restrict pods/log, log-viewer features, and file permissions to the same trust level as the secrets they may contain.

§Tools

• grep -RniE over log directories — the primary tool here; the queries in Methodology are the workhorses.
• Certificate Transparency (crt.sh / certstream) — discover alternate / non-prod / FIPS endpoints to audit-diff (#3780277).
• AWS CLI --endpoint-url — redirect a signed request to an alternate host and diff CloudTrail across all regions.
• Burp Repeater / Intruder — inject control chars, delimiters, and spoofed X-Forwarded-For into request fields.
• Source audit (grep the codebase for arg-dump loggers, toCurl/toString request dumpers, and the log-scrub allowlist) — see the 18-source-code-audit and log-analysis skills; ha-insecure-logging for the Android logcat variant.

✦Specimens — real-world examples

The techniques above are the general method. Below, each disclosed HackerOne report is a catalogued example — concrete payload, outcome, and matching practice lab. 14 in this class.

§References & practice

1. No dedicated PortSwigger lab for this class; use the methodology above and the cited reports.
2. All 14 disclosed reports for this class are catalogued as specimens above.
3. See also: exploit chains · payload libraries · methodology.