updated runbook to include the Code Injection Hardening Rule

README.md

@@ -9,6 +9,7 @@ This repository contains detailed runbooks for responding to various security in
 - [JNDI Injection](_runbooks/jndi-injection.md) - Responding to JNDI injection attempts targeting Java applications
 - [SQL Injection](_runbooks/sql-injection.md) - Managing SQL injection attacks against database systems
 - [Expression Language Injection](_runbooks/expression-language-injection.md) - Addressing expression language injection vulnerabilities
+- [Code Injection](_runbooks/code-injection.md) - Handling code injection attacks that execute arbitrary code
 
 ### Access Control & Traversal
 - [Path Traversal](_runbooks/path-traversal.md) - Handling attempts to access files outside intended directories

_incident-runbooks/code-injection.md

@@ -0,0 +1,237 @@
+---
+layout: runbook
+title: "Code Injection Hardening"
+description: "Guide for detecting and responding to code injection hardening incidents. These incidents are triggered when an application attempts to execute code within a ScriptEngine interface or similar"
+---
+
+<!-- \ or two whitespaces used for line breaks -->
+# Code Injection Runbook
+
+Code injection is a malicious technique where attackers exploit vulnerabilities in web applications to inject and execute arbitrary code within the application itself. By manipulating input data, attackers can manipulate the application's execution flow, tricking it into running unintended code.This can result in data breaches, system compromise, etc. Contrast uses a "hardening rule" to detect code injection, this means that any call to a known code execution interface is blocked.
+
+
+Example Event - Exploited outcome Code Injection  
+`Jul 31 12:56:31 10.174.15.127 CEF:0|Contrast Security|Contrast Agent Java|6.19.0.localDevBuild|SECURITY|The following string was executed var output \= ''; Java.type('java.lang.System').out.println('hello'); 'hello'|INFO|lei=407 src=0:0:0:0:0:0:0:1 spt=8080 request=/runcmd requestMethod=GET app=test3 outcome=success`
+
+
+Example Event - Blocked outcome Code Injection  
+`Jul 31 12:53:59 10.174.15.127 CEF:0|Contrast Security|Contrast Agent Java|6.19.0.localDevBuild|SECURITY|An effective attack was detected against code-injection-hardening|WARN|pri=code-injection-hardening src=0:0:0:0:0:0:0:1 spt=8080 request=/runcmd requestMethod=GET app=test3 outcome=BLOCKED`
+
+
+
+
+\
+What is the “outcome” of the event you are triaging? (click to proceed)
+
+- [Exploited](#exploited)
+- [Blocked](#blocked)
+
+
+## Exploited
+
+"Exploited" means Contrast detected usage of a code execution interface. This could be a legitimate use of the interface, or it could be an attacker executing arbitrary code in the application.
+
+To verify this is a true positive, review the following attributes of the event for common indicators:
+
+- Does arbitrary code get run in the application as part of normal usage?
+- Has this rule been enabled for a long time? The longer the rule has been enabled, the more likely it is that the event is a true positive.
+- Is the code accessing suspicious files? (/etc/password/)
+- Is the code making outbound network connections?
+
+
+
+Does the event appear to be a true positive? (click to proceed)
+
+- [No](#exploited-false-positive)
+- [Yes, or unsure](#exploited-true-positive)
+
+
+
+## Blocked
+
+"Blocked" means Contrast detected usage of a code execution interface. This could be a legitimate use of the interface, or it could be an attacker executing arbitrary code in the application and becuase the rule is set to Block, the attempt to execute arbitrary code was stopped.
+
+To verify this is a true positive, review the following attributes of the event:
+
+- Does arbitrary code get run in the application as part of normal usage?
+- Has this rule been enabled for a long time? The longer the rule has been enabled, the more likely it is that the event is a true positive.
+- Is the code accessing suspicious files? (/etc/password/)
+- Is the code making outbound network connections?
+
+
+
+Is the event a true positive? (click to proceed)
+
+- [No](#blocked-false-positive)
+- [Yes, or unsure](#blocked-true-positive)
+
+
+## Success
+
+“Success" means that Contrast's security measures functioned as intended, preventing unauthorized access or potentially malicious activity from reaching the application. This could be due to a [virtual patch](https://docs.contrastsecurity.com/en/virtual-patches.html), [IP block](https://docs.contrastsecurity.com/en/block-or-allow-ips.html), or [bot block rule](https://docs.contrastsecurity.com/en/server-configuration.html#:~:text=Bot%20blocking%20blocks%20traffic%20from,Events%2C%20use%20the%20filter%20options.) being triggered.
+
+Generally, these events don't necessitate action because they signify the system is working correctly.
+
+However, further investigation may be beneficial in specific scenarios to gain more insights or proactively enhance security:
+
+- Should the event have been blocked?:
+    - If the event is from an [IP block](https://docs.contrastsecurity.com/en/block-or-allow-ips.html):
+        - Correlate the IP address with other events to identify any attempted malicious actions.
+        - Look up the IP address's reputation and origin to determine if it's known for malicious activity.
+        - Check if the IP is listed on any other denylists across your systems.
+    - If the event is from a [Virtual Patch](https://docs.contrastsecurity.com/en/virtual-patches.html):
+        - Correlate the event with any exploited or probed events.
+        - Confirm if the virtual patch is protecting a known vulnerability in the application.
+    - If the event is from a [Bot Block](https://docs.contrastsecurity.com/en/server-configuration.html#:~:text=Bot%20blocking%20blocks%20traffic%20from,Events%2C%20use%20the%20filter%20options.):
+        - Analyze the user-agent header of the HTTP request. Only requests originating from known scanning, fuzzing, or malicious user-agents should be blocked.
+
+\
+If the event appears to be for legitimate traffic, an [exclusion](https://docs.contrastsecurity.com/en/application-exclusions.html) can be configured.
+
+\
+[Proceed to Post-Incident Activities](#post-incident-activities)
+
+
+## Exploited True Positive
+
+It is possible that the event is a True Positive, but is benign. A Benign True Positive is when an application relies on vulnerable behavior that could potentially be exploited, but is currently necessary for operation. This determination will often require the assistance of the development or application security teams.
+
+If the event appears to be a Benign True Positive, click [here](#benign-true-positive).
+
+\
+If it does not appear to be a Benign True Positive, the most immediate action to stop an "active" attack would be to block the current attacker of the exploited event, while further triage could result in a [virtual patch](https://docs.contrastsecurity.com/en/virtual-patches.html)/[enabling block mode](https://docs.contrastsecurity.com/en/set-protect-rules.html) for the rule:
+
+- Is the attack originating from a specific IP[s] that is a real external IP address (not internal load balancer or network device) and not the public IP address for a large company network?
+    - Block using network appliance
+    - [Block using Contrast](https://docs.contrastsecurity.com/en/ip-management.html)
+- Are all of the events originating from the same application user account?
+    - Determine if the account is a legitimate account
+    - If so, attempt to help them recover the account by contacting and authenticating the legitimate user, arranging to change their credentials, and recover from any damage.
+    - If not,  consider the following options:
+        - Ban the account
+        - Disable the account
+        - Delete the account
+
+\
+\
+Once the current attack has been stopped, consider taking additional steps to prevent future exploitation.
+
+- If the only “Exploited” events for this rule are true positives, then the rule can be [switched to “Block” mode](https://docs.contrastsecurity.com/en/set-protect-rules.html) which will prevent future exploitation.
+- If there are other “Exploited” events that appear to be legitimate, benign traffic, then “Block” mode would block those events as well, which could have negative impact to the application.
+    - Before enabling “Block” mode for this situation, you must first exclude the legitimate, benign traffic being caught in the rule.
+    - Alternatively, you can set up a [Virtual Patch](https://docs.contrastsecurity.com/en/virtual-patches.html) that only allows the legitimate, benign traffic through and any non-matches will be blocked.
+
+If none of the above options are satisfactory and it's perceived the application is at great risk, you can consider shutting down the application or removing network connectivity.
+
+\
+\
+Post Containment
+
+- If confirmed this is a True Positive, it should be raised with the appsec/dev teams to get fixed. Useful information for those teams would be:
+
+    - Application name
+    - Is app in production, development, staging, etc
+    - Affected URL
+    - Attack payload
+    - Stack trace of the request
+- To better understand the extent of the incident and to ensure the attack is no longer occurring, look for other IOCs:
+    - Did the same IP Address Generate Other Alerts?
+    - Is the vulnerability being exploited by other actors?
+    - Spike in traffic or repeated access patterns to the vulnerable URL
+    - Correlate exploited events with any "probed" or "blocked" events
+    - If the attack was able to execute code, the server may need to be considered compromised and reviewed for persistence and other lateral movement.
+
+\
+\
+[Proceed to Post-Incident Activities](#post-incident-activities)
+
+
+
+## Exploited False Positive
+
+If the event seems to be a False Positive, consider the following options:
+
+- Ignore
+- [Create Exclusion](https://docs.contrastsecurity.com/en/application-exclusions.html)
+
+\
+[Proceed to Post-Incident Activities](#post-incident-activities)
+
+
+
+
+
+
+
+
+## Blocked True Positive
+
+It is possible that the event is a True Positive, but benign. A Benign True Positive is when an application’s design relies on vulnerable behavior that could potentially be exploited, but is currently necessary for operation. This determination will often require the assistance of the development or application security teams.
+
+If the event appears to be a Benign True Positive, click [here](#benign-true-positive).
+
+If it does not appear to be a Benign True Positive, consider the following options:
+
+- If one IP address is generating a lot of blocked events, it's probably worthwhile to block it.
+- Notify Dev/Appsec team of Vulnerability. Useful information for those teams would be:
+    - Application name
+    - Is app in production, development, staging, etc
+    - Affected URL
+    - payload
+    - Stack trace of the request
+- Look for IOCs of further attacks in other parts/inputs of the application
+    - Other blocked or probed events?
+    - Did anything show up as "exploited" indicating a different rule did not have blocking enabled?
+- Ignore
+
+[Proceed to Post-Incident Activities](#post-incident-activities)
+
+
+
+## Blocked False Positive
+
+If the event seems to be a False Positive, then Contrast may be blocking legitimate usage of the application, therefore negatively impacting it.
+
+- Create an exclusion to allow the legitimate traffic through so that you can continue to be protected by “Block” mode without the negative impact.
+- Alternatively, you can set up a Virtual Patch that only allows legitimate traffic through and any non-matches (attack traffic) will be blocked.
+- If neither of the above options are satisfactory and the negative impact of the application must be avoided, you can switch the rule to “Monitor” mode.
+
+[Proceed to Post-Incident Activities](#post-incident-activities)
+
+
+## Benign True Positive
+
+To review, a Benign True Positive occurs when an application relies on vulnerable behavior that could potentially be exploited, but is currently necessary for operation. Consider the following options:
+
+- Ignore
+- Create Exclusion
+- Work with the application developer on alternative implementations that do not pose such risk to the application, but meets the business needs.
+
+## Post-Incident Activities
+
+- **Documentation**
+    - **Incident Report:** Document the incident, including findings, raw events and alerts, actions taken, assets impacted, and lessons learned.
+    - **Update Documentation:** Keep security runbooks and documentation up to date.
+- **Communication**
+    - **Notify Stakeholders:** Inform relevant stakeholders about the incident and steps taken.
+    - **User Notification:** Notify affected users if there was a data breach.
+- **Review and Improve**
+    - **Review Response:** Conduct a post-mortem to review the response and identify improvement areas.
+    - **Enhance Security Posture:** Implement additional security measures and improve monitoring.
+## Handling Code Injection Hardening
+
+Code Injection Hardening refers to a block that the agent applies to the application to be able to execute arbitrary code. Most web applications have no reason to execute arbitrary code so this rule is intended to ensure that no attempts are made by an application to do so.
+
+When triaging this event type the key is in understanding if the web application executes arbitrary code under normal conditions.
+
+Choose the Appropriate Action:  
+If the application should NOT execute arbitrary code:
+- Enable Block Mode: This will prevent the application from executing arbitrary code, ensuring maximum security.
+
+\
+If the application DOES need to execute arbitrary code:
+
+- Monitor Mode (Recommended): Start with monitor mode to observe the code the application executes. This helps identify legitimate use cases and potential risks without disrupting normal functionality.
+- Exclusions: If monitoring reveals legitimate needs, configure an exclusion to allow only specific, trusted code to run. Once all legitimate executions are accounted for, the rule can be placed into Block mode.
+- Disable the Rule (Use with Caution): If the application requires code execution and other options are not feasible consider disabling the rule.
+