Which logs show evidence of log poisoning?

Where log poisoning shows up first

The clearest evidence is usually in application and system logs, especially where raw user input is recorded and later re-read by a log viewer, parser, or alerting pipeline. Watch for entries that contain control characters, forged timestamps, unusual delimiters, embedded script, or command content, because those patterns can indicate that the log data itself has been manipulated rather than simply reflecting normal activity.

When the application logs are web-facing, the same event may also appear in request, access, error, and security logs, but the key question is whether the recorded line looks structurally altered or contains payload material that should never have been treated as log text.

For web application environments, the attack pattern sits inside broader injection and output-handling problems described in the Web Application Attacks Guide, because the same untrusted input problem can affect logging, display, and downstream processing.

What the log entry usually looks like

log poisoning often leaves a trail that looks odd to an analyst before it looks malicious to a parser. Common signs include multiline entries that should have been single-line, unexpected quote marks or separators, spoofed severity labels, broken field alignment, and payload fragments that resemble HTML, JavaScript, shell syntax, or template syntax. These are especially suspicious when they appear in fields that normally hold usernames, user agents, referrers, filenames, or request parameters.

In practice, the strongest clue is not one character by itself but a mismatch between the field’s normal format and what was actually written. If a field that should be plain text suddenly contains a newline, delimiter, or executable-looking content, treat that as evidence of attempted log injection until proven otherwise.

That kind of payload is often associated with broader injection behaviour, so the same defensive review used for other application attacks should be applied to the logging path as well, not only to the application feature being attacked.

How to confirm and respond without trusting the log file blindly

Confirm exposure by checking the original request, upstream gateway logs, and any immutable or centralised copy of the event, rather than relying only on the tainted log source. Compare the same event across layers to see whether the suspicious text was inserted before logging, written by the application, or modified afterward by a processor or viewer. If the log viewer rendered the content as HTML or interpreted embedded commands, the issue may extend beyond poisoning to secondary execution risk.

If log processing is automated, inspect the parser, normalisation step, and forwarding pipeline for unsafe assumptions about line breaks, delimiters, encodings, or escaping. Sanitising input before logging, escaping on display, and making log consumers treat all values as data are the core controls. The same principle also applies to admin consoles and SIEM dashboards that render log content back to analysts.

For teams that want a more complete view of adjacent application abuse patterns, the OWASP API Security Top 10 is useful where logs include API request context, and the NIST SP 800-53 Rev 5 Security and Privacy Controls gives a control vocabulary for logging, access control, and integrity protections.

Risk and Threat Considerations

Log poisoning is risky because it can turn telemetry into a delivery path for deception or secondary execution. A poisoned log can mislead defenders, contaminate investigations, trigger false alerts, or, if a viewer or downstream processor is unsafe, execute embedded content in an analyst workflow.

Failure mechanism: The attacker injects data that is later written to a log, then relies on inadequate escaping, unsafe parsing, or a rendering flaw in the log consumer to preserve or interpret the payload.

Impact: Analysts may trust fabricated events, miss the true attack sequence, or expose themselves to script execution or command execution through the logging toolchain.

Practitioner Guidance

What to verify: Check whether the suspicious line is present in the raw source event, the central log store, and the viewer output. If only the rendered view looks altered, the issue may be in the presentation layer; if the raw record is already poisoned, the application input path is the priority.

Decision rule: If the log content can influence parsing or display, treat escaping and output encoding as mandatory controls, not optional hardening. If the content is only being stored for later search, still assume it is hostile data and keep it inert until the moment of display.

Practitioner takeaway: Evidence of log poisoning is strongest when a log line breaks its expected structure and carries payload text that should have remained inert; verify the raw event path first, then harden both logging and log viewing so untrusted content never becomes executable or misleading.

Related resources from NHI Mgmt Group

• Which logs show evidence of ADIDNS poisoning?
• Which logs show evidence of fast-flux DNS?
• Which logs show evidence of Modify Cloud Compute Infrastructure?
• Which logs show evidence of Create Cloud Instance?