Trustwave SpiderLabs Uncovers Ov3r_Stealer Malware Spread via Phishing and Facebook Advertising. Learn More

Trustwave SpiderLabs Uncovers Ov3r_Stealer Malware Spread via Phishing and Facebook Advertising. Learn More

Managed Detection & Response

Eliminate active threats with 24/7 threat detection, investigation, and response.

Co-Managed SOC (SIEM)

Maximize your SIEM investment, stop alert fatigue, and enhance your team with hybrid security operations support.

Advisory & Diagnostics

Advance your cybersecurity program and get expert guidance where you need it most.

Penetration Testing

Test your physical locations and IT infrastructure to shore up weaknesses before exploitation.

Database Security

Prevent unauthorized access and exceed compliance requirements.

Email Security

Stop email threats others miss and secure your organization against the #1 ransomware attack vector.

Digital Forensics & Incident Response

Prepare for the inevitable with 24/7 global breach response in-region and available on-site.

Firewall & Technology Management

Mitigate risk of a cyberattack with 24/7 incident and health monitoring and the latest threat intelligence.

Microsoft Exchange Server Attacks
Stay protected against emerging threats
Rapidly Secure New Environments
Security for rapid response situations
Securing the Cloud
Safely navigate and stay protected
Securing the IoT Landscape
Test, monitor and secure network objects
Why Trustwave
About Us
Awards and Accolades
Trustwave SpiderLabs Team
Trustwave Fusion Security Operations Platform
Trustwave Security Colony
Technology Alliance Partners
Key alliances who align and support our ecosystem of security offerings
Trustwave PartnerOne Program
Join forces with Trustwave to protect against the most advance cybersecurity threats
SpiderLabs Blog

ModSecurity Advanced Topic of the Week: Inbound/Outbound Correlation

Alert Management - Correlated Events

One important alert management issue for security analysts to deal with was that of prioritization. From an incident response perspective, many ModSecurity/CRS users were having a difficult time figuring out which alerts they needed to fully review and follow-up on. This is especially true if running ModSecurity in DetectionOnly mode - as you may get alerts but you are not actively blocking attacks or information leakages. This blog post outlines out the OWASP ModSecurity CRS uses inbound/outbound correlation of events to prioritize events.

Inbound/Outbound Correlation

If you are running the OWASP ModSecurity CRS in Anomaly Scoring Mode, then you have the added advantage of correlating rule matches to achieve more intelligence about transactional issues.

Here is the following information related to standard Severity ratings->Anomaly Scoring in the main configuration file:

## -=[ Anomaly Scoring Severity Levels ]=-## These are the default scoring points for each severity level.  You may# adjust these to you liking.  These settings will be used in macro expansion# in the rules to increment the anomaly scores when rules match.## These are the default Severity ratings (with anomaly scores) of the individual rules -##    - 2: Critical - Anomaly Score of 5.#         Is the highest severity level possible without correlation.  It is#         normally generated by the web attack rules (40 level files).#    - 3: Error - Anomaly Score of 4.#         Is generated mostly from outbound leakage rules (50 level files).#    - 4: Warning - Anomaly Score of 3.#         Is generated by malicious client rules (35 level files).#    - 5: Notice - Anomaly Score of 2.#         Is generated by the Protocol policy and anomaly files.#SecAction "phase:1,t:none,nolog,pass, \setvar:tx.critical_anomaly_score=5, \setvar:tx.error_anomaly_score=4, \setvar:tx.warning_anomaly_score=3, \setvar:tx.notice_anomaly_score=2"

This means that the highest severity rating that an identified inbound attack can have is 2 (Critical). In order to have a higher Severity rating (1 or 0) you need to use correlation. At the end of both the Request and Response Phases, the CRS will save the final rule match message data.

After the transaction has completed (in phase:5 logging), the rules in the base_rules/modsecurity_crs_60_correlation.conf file will conduct further post-processing by analyzing any inbound events with any outbound events in order to provide a more intelligent/priority correlated event.

  • Was there in inbound attack?
  • Was there an HTTP Response Status Code Error (4xx/5xx level)?
  • Was there an application information leakage event?

If an inbound attack was detected and either an outbound application status code error or infoleak was detected, then the overall event severity is raised:

  • 0 - EMERGENCY: is generated from correlation of anomaly scoring data where there is an inbound attack and an outbound leakage.
  • 1 - ALERT: is generated from correlation where there is an inbound attack and an outbound application level error

Example Correlated Event

Let's look at an example SQL Injection attack scenario. If an attacker sends inbound SQL Injection attack payloads and the application responds normally, then you would see a ModSecurity alert message similar to the following:

[Fri Mar 11 01:57:45 2011] [error] [client] ModSecurity: Warning. Operator GE matched 20 at TX:anomaly_score. [file "/etc/apache2/modsecurity/base_rules/modsecurity_crs_60_correlation.conf"] [line "85"] [msg "Transactional Anomaly Score (score 46): SQL Injection Attack"] [hostname ""] [uri "/"] [unique_id "-lF5UX8AAQEAAF1s0sgAAAAQ"]

While this is certainly useful information, this does only indicates that an attacker is probing the application. If, on the other hand, the target application does not properly handle this input and instead returns detailed database error information such as the following then you would want to follow up on that issue and initiate blocking:

An Error Has Occurred


Syntax error in string in query expression 'username = ''''.

Error Message:

System.Data.OleDb.OleDbException: Syntax error in string in query expression 'username = ''''. at System.Data.OleDb.OleDbCommand.ExecuteCommandTextErrorHandling(OleDbHResult hr) at System.Data.OleDb.OleDbCommand.ExecuteCommandTextForSingleResult(tagDBPARAMS dbParams, Object& executeResult) at System.Data.OleDb.OleDbCommand.ExecuteCommandText(Object& executeResult) at System.Data.OleDb.OleDbCommand.ExecuteCommand(CommandBehavior behavior, Object& executeResult) at System.Data.OleDb.OleDbCommand.ExecuteReaderInternal(CommandBehavior behavior, String method) at System.Data.OleDb.OleDbCommand.ExecuteReader(CommandBehavior behavior) at System.Data.OleDb.OleDbCommand.System.Data.IDbCommand.ExecuteReader(CommandBehavior behavior) at System.Data.Common.DbDataAdapter.FillInternal(DataSet dataset, DataTable[] datatables, Int32 startRecord, Int32 maxRecords, String srcTable, IDbCommand command, CommandBehavior behavior) at System.Data.Common.DbDataAdapter.Fill(DataSet dataSet, Int32 startRecord, Int32 maxRecords, String srcTable, IDbCommand command, CommandBehavior behavior) at System.Data.Common.DbDataAdapter.Fill(DataSet dataSet, String srcTable) at Altoro.Authentication.ValidateUser(String uName, String pWord) in d:\downloads\AltoroMutual_v6\website\bank\login.aspx.cs:line 73 at Altoro.Authentication.Page_Load(Object sender, EventArgs e) in d:\downloads\AltoroMutual_v6\website\bank\login.aspx.cs:line 33 at System.Web.Util.CalliHelper.EventArgFunctionCaller(IntPtr fp, Object o, Object t, EventArgs e) at System.Web.Util.CalliEventHandlerDelegateProxy.Callback(Object sender, EventArgs e) at System.Web.UI.Control.OnLoad(EventArgs e) at System.Web.UI.Control.LoadRecursive() at System.Web.UI.Page.ProcessRequestMain(Boolean includeStagesBeforeAsyncPoint, Boolean includeStagesAfterAsyncPoint)

In this situation, the CRS will correlate the inbound SQL Injection Attack with the outbound SQL Error Leakge and generate an higher level Severity alert message such as the following:

[Fri Mar 11 01:38:56 2011] [error] [client] ModSecurity: Warning. Operator GE matched 1 at TX. [file "/etc/apache2/modsecurity/base_rules/modsecurity_crs_60_correlation.conf"] [line "68"] [msg "Correlated Successful Attack Identified: Inbound Attack (9000042-Detects classic SQL injection probings 1/2) + Outbound Data Leakage (SQL Information Leakage) - (Transactional Anomaly Score: 6)"] [severity "EMERGENCY"] [hostname ""] [uri "/"] [unique_id "uwabqH8AAQEAAFzSougAAAAV"]

This correlated event provides much more actionable data to a security analyst and allows them to either implement more aggressive blocking mechanisms. This may include blocking all categories of SQL Injection attacks and/or blocking for this particular parameter on the page.


Correlated event analysis helps to greatly expedite the incident response process and allows security operations teams to focus their efforts on actionable situations instead of only inbound attacks.


Latest SpiderLabs Blogs

Breakdown of Tycoon Phishing-as-a-Service System

Just weeks after Trustwave SpiderLabs reported on the Greatness phishing-as-a-service (PaaS) framework, SpiderLabs’ Global Threat Operations team uncovered another PaaS that it has dubbed Tycoon...

Read More

Physical Address Strangeness in Spam

Ten years ago, Congress passed the "CAN-SPAM Act" (also known as theYou-CAN-SPAM Act, since it defined legal spam and supersedes any stricter state-antispam laws). One of the provisions of the act is...

Read More

Trustwave SpiderLabs Uncovers Ov3r_Stealer Malware Spread via Phishing and Facebook Advertising

During an Advanced Continual Threat Hunt (ACTH) investigation that took place in early December 2023, Trustwave SpiderLabs discovered Ov3r_Stealer, an infostealer distributed using Facebook...

Read More