SIEM

Correlation Rules

With Ali Ali

 SIEM
Correlation Rules
Intro
Definition
• Correlation rules are conditions used
to identify patterns or sequences of
events in log data
• These patterns could indicate
a security threat

Purpose
• Correlation rules play a crucial role
in SIEM systems
• They help detect complex attacks by
combining multiple individual
events into meaningful sequences
 SIEM
Correlation Rules
How correlation rules can indicate a security threat?
1. Contextual Patterns:
• Correlation rules analyze log data from various sources (such as
network traffic, system logs, or application logs)
• They look for contextual patterns that might not be evident in
individual events
• For example, a series of failed login attempts followed by a successful
login from the same IP address could indicate a brute-force attack

Examples cover a range of scenarios where contextual patterns play a key role in
identifying potential security breaches:
• Spear Phishing: Targeted email attacks with spoofed sender information
• Business Email Compromise (BEC): Compromised email accounts used for
fraud
• Account Takeover (ATO): Unauthorized access to user accounts
• Watering Hole Attacks: Compromised websites targeting specific groups
 SIEM
Correlation Rules
How correlation rules can indicate a security threat?
2. Sequences and Anomalies:
• Correlation rules focus on sequences of events
• They identify patterns where seemingly unrelated events occur
together
• Anomalies, such as a user accessing sensitive files during non-working
hours, can be flagged by correlation rules

Sequence Attacks:
• Port Scanning Attack: Automated tools scan for open ports to find
vulnerabilities
• SQL Injection: Malicious SQL code is injected to manipulate databases
• SSH Brute Force Attack: Multiple login attempts are made to guess
passwords

Anomaly Attacks:
• Denial-of-Service (DoS) Attack: Overloading a system with traffic to disrupt
service
• Zero-Day Attack: Exploiting unknown vulnerabilities in software
• Fileless Malware: Executing malicious activities without writing to disk
 SIEM
Correlation Rules
How correlation rules can indicate a security threat?
3. Chaining Events:
• Correlation rules allow us to chain events based on specific conditions
• For instance, if a user accesses a critical server, followed by an
unusual outbound connection, it could signal a data exfiltration
attempt

• Supply Chain Attack: Compromising a vendor’s software to gain access to a

target’s systems
• Watering Hole Attack with Malware Download: Infecting websites visited
by a target group to distribute malware
• Phishing with Remote Access Tool (RAT): Deceiving users into installing a
RAT via a phishing email
 SIEM
Correlation Rules
How correlation rules can indicate a security threat?
4. Complex Attack Detection:
• By combining multiple events, correlation rules help
detect complex attacks
• These attacks often involve several steps, such as
reconnaissance, exploitation, and lateral movement
• Correlation rules piece together these steps to identify
the overall attack pattern
5. Thresholds and Aggregation:
• Correlation rules consider thresholds and aggregation
• For instance, if a user fails login 10 times within 5
minutes, it might trigger an alert
• Aggregating events over time helps identify patterns that
might otherwise go unnoticed
6. Behavioral Anomalies:
• Correlation rules can detect behavioral anomalies
• For example, a sudden increase in file deletions by a user
who rarely performs such actions could be suspicious
 SIEM
Correlation Rules
How correlation rules can indicate a security threat?
Complex Attack Detection & Thresholds:
• Distributed Denial-of-Service (DDoS) Attack with Spoofed Source
IPs: Analyzing traffic patterns to identify attacks that use spoofed IPs
to avoid detection
• Multi-Stage Malware: Monitoring sequences of events and file
interactions to detect malware that downloads additional
components post-infection

Aggregation & Behavioral Anomalies:

• Lateral Movement: Examining login activities across the network to
spot unusual patterns indicative of lateral movement within a
network
• Privilege Escalation: Analyzing command history to detect attempts
to gain higher system privileges
 SIEM
Correlation Rules
Correlation Rule Syntax
 Explanation of the XML Syntax Used in Wazuh:
 Wazuh uses XML to define its correlation rules, which allows for structured and hierarchical
configuration
 The XML syntax for Wazuh rules is designed to be both human-readable and machine-processable
 It consists of a series of nested tags that define the properties and behavior of each rule
 Rules Syntax - Ruleset XML syntax · Wazuh documentation
 SIEM
Correlation Rules
Correlation Rule Syntax
 Tags: The fundamental building blocks of XML are “tags,” which are used to mark the
beginning and end of elements in the document. In Wazuh, each rule is enclosed
within <rule> and </rule> tags

 Attributes: Within the tags, you can specify attributes that provide additional
information about the element. For example, a rule might have an ID attribute that
uniquely identifies it

 Nesting: Tags can be nested within each other to create a hierarchical structure. This is
useful for defining complex rules where one rule may depend on the conditions of
another

 Human-Readable: The tags and attributes are designed to be self-descriptive, making it

easier for humans to understand the purpose of each rule and its components

 Machine-Processable: The structured format of XML allows machines to parse the

document efficiently and interpret the rules accurately for automated processing

 Rule Definition: Each rule in Wazuh’s XML configuration typically contains several
nested tags that define its logic, such as the conditions that trigger the rule, the level of
severity, and the description of the alert
 SIEM
Correlation Rules
Correlation Rule Syntax
 For instance, a simple Wazuh rule in XML might look like this:
<rule id="100001" level="12">
<decoded_as>json</decoded_as>
<description>Alert on high severity event</description>
<condition>condition1 AND condition2</condition>
<action>Alert</action>
</rule>

In this example:
• id is an attribute that uniquely identifies the rule
• level is an attribute that indicates the severity of the alert
• <decoded_as> is a tag that specifies how the log data should be
interpreted
• <description> provides a human-readable explanation of what the rule
detects
• <condition> defines the logic for when the rule should trigger
• <action> specifies what should be done when the rule conditions are met
 SIEM
Correlation Rules
Correlation Rule Syntax
 Key Elements of a Rule:

• <rule>: This is the root element for defining

a rule. It includes attributes that specify the
rule’s ID, level, and other options

• <if_sid>: Stands for “if source ID”. It is used

to create a condition that checks if a
previous rule (identified by its ID) has been
triggered

• <match>: This element contains a regular

expression that is matched against the log
message. If the log message fits the pattern
defined in <match>, the rule is triggered
 SIEM
Correlation Rules
Correlation Rule Syntax
Key Elements of a Rule:
Here’s an example of a basic correlation rule in XML syntax:

<group name="syscheck,">
<rule id="100010" level="7">
<if_sid>100000</if_sid>
<match>sshd:session closed for user</match>
<description>SSH session closed</description>
</rule>
</group>

In this example:
• The <group> tag categorizes the rule under ‘syscheck’
• The <rule> tag starts the definition of a new rule with an ID of ‘100010’ and a severity level
of ‘7’
• The <if_sid> tag specifies that this rule should only be considered if rule ‘100000’ has been
triggered
• The <match> tag contains a regular expression that looks for the specific log message
pattern
• The <description> tag provides a human-readable explanation of what the rule detects
This structure allows Wazuh to efficiently process events and generate alerts based on complex
criteria, enhancing the security monitoring capabilities of the system
SIEM
Correlation Rules
Correlation Rule Syntax
 Condition:
• The condition in a correlation rule defines the criteria that
must be met for the rule to trigger. It specifies the
circumstances or events that need to occur for the rule to
activate
• Conditions can be based on various factors, such as:
 Event Attributes: These include properties associated
with an event, such as timestamps, source IP addresses,
or specific keywords
 Thresholds: Conditions can involve thresholds, where
certain values must exceed or fall below a predefined
limit
 Logical Operators: You can use logical operators
like AND, OR, and NOT to combine multiple conditions
 Time Windows: Conditions can be time-based,
requiring events to occur within a specific time frame
• For example, a condition might be: “If more than 10 failed
login attempts occur within 5 minutes from the same IP
address, trigger the rule.”
SIEM
Correlation Rules
Correlation Rule Syntax
 Action:
• The action specifies what should happen when the correlation rule
matches the defined conditions
• Actions can vary widely based on the system or context. Some common
examples include:
 Alerts: Generating an alert or notification to inform relevant parties
about the detected event
 Blocking or Quarantining: Taking preventive measures, such as
blocking an IP address or quarantining a suspicious file
 Logging: Recording relevant information for further analysis
 Remediation: Initiating automated responses to mitigate the impact
of the event
• For instance, an action might be: “Send an email alert to the security
team when a brute-force attack is detected.”
 SIEM
Correlation Rules
Correlation Rule Syntax
 Action:
• Example: if
(condition1) and (condition2) and (condition3)
then
action
Python
# Define the conditions
condition1 = True
condition2 = False
condition3 = True
# Check if all conditions are true
if condition1 and condition2 and condition3:
# Perform the action
print("All conditions are true. Action executed.")
else:
# If any condition is not true, this block will execute
print("Not all conditions are true. Action not executed.")

The output will be???

SIEM
Correlation Rules
Correlation Rule Syntax
 Putting It Together:
• A complete correlation rule combines the
condition(s) and action(s). Here’s an
example:
 Condition: If more than 5 failed login
attempts occur within 1 minute from
the same user account
 Action: Generate an alert and
temporarily block the user account for
15 minutes
• The rule triggers when the specified
condition is met, and the defined action is
executed accordingly
 SIEM
Correlation Rules
Correlation Rule Functions
• contains():
 The contains() function is used to check if a specific string or
pattern is present in log data
 For example, you might create a condition like: “If the log entry
contains the phrase ‘SQL injection attempt,’ trigger the rule.”
• count():
 The count() function tallies the occurrences of a specific event
within a defined timeframe
 It helps track patterns or anomalies. For instance:
o “If there are more than 10 failed login attempts within 5
minutes, raise an alert.”
• timeframe():
 The timeframe() function sets the time window for evaluating
events
 It allows you to specify how far back in time the rule should
consider events
 Example:
o “Evaluate events within the last 30 minutes.”
 SIEM
Correlation Rules
Correlation Rule Functions
 Examples:
• Suppose you’re monitoring a web server’s logs:
 Condition: If the log entry contains the string “404 Not Found” more than
5 times within the last hour
 Action: Generate an alert and investigate potential issues with the server

if
(contains($source, “404 not found")) and (count($source, " 404 not found ")
> 5 within 1 minute)
then
action

• Another example:
 Condition: If the count of “Suspicious IP” entries exceeds 20 within the last
10 minutes
 Action: Block the suspicious IP address for 1 hour
 SIEM
Correlation Rules
Sample Rules for Multi-Step Attacks Detection
1. Detecting Lateral Movement:

• Objective: Lateral movement refers to an attacker’s attempt to move

laterally within a network after gaining initial access. It involves
compromising additional systems or accounts

• Sample Rule:
 Condition: If an account logs in from multiple distinct IP addresses
within a short time frame (e.g., 5 different IPs within 10 minutes)

 Action: Generate an alert and investigate potential lateral

movement
 SIEM
Correlation Rules
Sample Rules for Multi-Step Attacks Detection
1. Detecting Lateral Movement:

• Example: Let’s say we have an account named ‘User123’

 Under normal circumstances, ‘User123’ logs in from a single
IP address
 However, within a span of 10 minutes, ‘User123’ is seen
logging in from five different IP addresses: 192.168.1.1,
192.168.1.2, 192.168.1.3, 192.168.1.4, and 192.168.1.5
 This is unusual and triggers our rule

• Action: An alert is generated, and the security team is notified to

investigate the possibility of lateral movement

• Implementation: XML
 SIEM
Correlation Rules
Sample Rules for Multi-Step Attacks Detection
1. Detecting Lateral Movement:
<rule name="Detect Lateral Movement">
<description>Trigger an alert when a user logs in from multiple IP addresses in a short time
frame.</description>
<user_account>User123</user_account>
<normal_behavior>
<login_ips>
<ip>192.168.1.1</ip>
</login_ips>
</normal_behavior>
<detected_behavior>
<login_ips>
<ip>192.168.1.1</ip>
<ip>192.168.1.2</ip>
<ip>192.168.1.3</ip>
<ip>192.168.1.4</ip>
<ip>192.168.1.5</ip>
</login_ips>
<time_frame>10 minutes</time_frame>
</detected_behavior>
<alert triggered="True">
<action>Notify security team to investigate potential lateral movement.</action>
</alert>
</rule>
 SIEM
Correlation Rules
Sample Rules for Multi-Step Attacks Detection
1. Detecting Lateral Movement:
<rule id="lateral-movement-detection" name="Detect Lateral Movement">
<description>Generates an alert when 'User123' logs in from multiple IP addresses within a short time
frame.</description>
<condition>
<user_account>User123</user_account>
<threshold>
<ip_count>5</ip_count>
<time_frame>10 minutes</time_frame>
</threshold>
</condition>
<decoder type="multiple_ip_login">
<parameters>
<ip_addresses>
<ip_address>192.168.1.1</ip_address>
<ip_address>192.168.1.2</ip_address>
<ip_address>192.168.1.3</ip_address>
<ip_address>192.168.1.4</ip_address>
<ip_address>192.168.1.5</ip_address>
</ip_addresses>
</parameters>
</decoder>
<alert triggered_on="multiple_ip_login">
<action>Notify security team to investigate potential lateral movement.</action>
</alert>
</rule>
 SIEM
Correlation Rules
Sample Rules for Multi-Step Attacks Detection
1. Detecting Lateral Movement:
{
"rule_name": "Detect Lateral Movement",
"description": "Trigger an alert when a user logs in from multiple IP addresses in a short time frame.",
"user_account": "User123",
"normal_behavior": {
"login_ips": ["192.168.1.1"]
},
"detected_behavior": {
"login_ips": [
"192.168.1.1",
"192.168.1.2",
"192.168.1.3",
"192.168.1.4",
"192.168.1.5"
],
"time_frame": "10 minutes"
},
"alert": {
"triggered": true,
"action": "Notify security team to investigate potential lateral movement."
}
}
 SIEM
Correlation Rules
Sample Rules for Multi-Step Attacks Detection
1. Detecting Lateral Movement:
{
"rule": {
"id": "lateral-movement-detection",
"name": "Detect Lateral Movement",
"description": "Generates an alert when 'User123' logs in from multiple IP addresses within a short time frame.",
"condition": {
"user_account": "User123",
"threshold": {
"ip_count": 5,
"time_frame": "10 minutes"
}
},
"decoder": {
"type": "multiple_ip_login",
"parameters": {
"ip_addresses": [
"192.168.1.1",
"192.168.1.2",
"192.168.1.3",
"192.168.1.4",
"192.168.1.5"
]
}
}
},
"alert": {
"triggered_on": "multiple_ip_login",
"action": "Notify security team to investigate potential lateral movement."
}
}
 SIEM
Correlation Rules
Sample Rules for Multi-Step Attacks Detection
1. Detecting Lateral Movement:
“rule”: This is the main object that contains the details of the detection rule
“id”: A unique identifier for the rule, here it is “lateral-movement-detection”
“name”: The name of the rule, which is “Detect Lateral Movement”
“description”: A brief explanation of what the rule does. In this case, it generates an alert if ‘User123’
logs in from multiple IP addresses within a short time frame
“condition”: The criteria that must be met to trigger the rule
“user_account”: Specifies the user account to monitor, which is ‘User123’.
“threshold”: Defines the conditions under which an alert should be triggered
“ip_count”: The number of different IP addresses that, if logged in from within the specified
time, would trigger the alert. Here, the count is 5
“time_frame”: The time window in which the login attempts from different IP addresses must
occur to trigger the alert. Here, it is “10 minutes”
“decoder”: Describes how to interpret the login attempts
“type”: The category of behavior to detect, which is “multiple_ip_login”
“parameters”: The specific details to monitor
“ip_addresses”: A list of IP addresses that, if ‘User123’ logs in from within the specified time
frame, would trigger the alert
“alert”: This object defines the actions to be taken when the rule is triggered
“triggered_on”: Specifies the type of behavior that causes the alert, which matches the “type” in the
decoder
“action”: The response to the triggered alert. In this case, it is to notify the security team to investigate
the possibility of lateral movement
 SIEM
Correlation Rules
Sample Rules for Multi-Step Attacks Detection
1. Detecting Lateral Movement:

Implementation: XML

<group name="syscheck,">
<!-- Frequency rule for detecting multiple failed login attempts -->
<rule id="100001" level="10">
<decoded_as>json</decoded_as>
<field name="event_id">4625</field>
<description>Multiple failed login attempts detected, possible lateral
movement</description>
<frequency>5</frequency>
<timeframe>120</timeframe>
<mitre>
<id>T1110</id>
</mitre>
</rule>
 SIEM
Correlation Rules
Sample Rules for Multi-Step Attacks Detection
1. Detecting Lateral Movement:
<!-- Rule for detecting unusual process execution path -->
<rule id="100002" level="9">
<decoded_as>json</decoded_as>
<field name="win.eventdata.imagePath">^C:\\\\Windows\\\\</field>
<description>Unusual process execution path, possible lateral
movement</description>
<mitre>
<id>T1021</id>
</mitre>
</rule>
</group>
This XML snippet defines two rules:
• The first rule (ID 100001) triggers an alert if there are multiple failed login attempts within a short
timeframe, which could indicate an attempt at lateral movement

• The second rule (ID 100002) looks for processes executed from an unusual path, another indicator of
potential lateral movement
 SIEM
Correlation Rules
Sample Rules for Multi-Step Attacks Detection
1. Detecting Lateral Movement:
• Group Name: syscheck, - This indicates that the rule belongs to the ‘syscheck’ group, which
typically monitors file integrity

• Rule ID: 100001 - This is a unique identifier for the rule

• Level: 10 - This represents the severity level of the rule, with 10 indicating a high severity
• Decoded As: json - This specifies that the log format expected is JSON
• Field Name: event_id - This is the specific field in the log that the rule monitors. In this case, it’s
looking for event ID 4625, which is a Windows Security event for a failed login attempt

• Description: The rule’s purpose is described here. It’s set to trigger an alert when multiple failed
login attempts are detected, which could be a sign of an attacker trying to move laterally within
the network
• Frequency: 5 - This is the number of times the event must occur to trigger the rule
• Timeframe: 120 seconds - This is the window during which the specified number of occurrences
must happen to consider the activity suspicious

• MITRE ID: T1110 - This refers to the MITRE ATT&CK framework, which categorizes different types
of cyber threats. T1110 is associated with brute force attacks, often used in lateral movement
attempts
 SIEM
Correlation Rules
Sample Rules for Multi-Step Attacks Detection
1. Detecting Lateral Movement:

• Field Name: win.eventdata.imagePath - This field specifies the path where the process is
executed. The rule is looking for paths that start with C:\\Windows\\, which is a common
directory for system processes

• Description: It provides a brief explanation of what the rule detects—unusual process execution
paths that may suggest lateral movement within the network

• MITRE ID: T1021 - This refers to the MITRE ATT&CK framework, categorizing this behavior as
related to the use of remote services to conduct lateral movement
• The rule uses a regular expression (^C:\\\\Windows\\\\) to match any process execution path that
begins with C:\\Windows\\. If a process is running from this path but is not recognized as a
typical system process, it could be suspicious

• This rule helps in identifying such anomalies, which are often signs of an attacker’s presence in
the network
 SIEM
Correlation Rules
Sample Rules for Multi-Step Attacks Detection
2. Identifying Privilege Escalation:
• Objective: Privilege escalation occurs
when an attacker elevates their access
level within a system or network.
Detecting this is crucial to prevent
unauthorized privilege escalation
• Sample Rule:
 Condition: If a user account suddenly
gains administrative privileges (e.g.,
becomes a member of the “Domain
Admins” group)
 Action: Raise an alert and review the
account’s activity
 SIEM
Correlation Rules
Sample Rules for Multi-Step Attacks Detection
2. Identifying Privilege Escalation:
<rule id="privilege-escalation-detection" name="Identify Privilege Escalation">
<description>Detects unauthorized privilege escalation by monitoring changes in
user account privileges.</description>
<condition>
<user_account_changes>
<new_privilege>Domain Admins</new_privilege>
</user_account_changes>
</condition>
<action>
<alert>Raise an alert and review the account's activity.</alert>
</action>
</rule>
 SIEM
Correlation Rules
Sample Rules for Multi-Step Attacks Detection
3. Flagging Data Exfiltration Attempts:
• Objective: Detecting data exfiltration helps prevent sensitive
information from leaving the network. Attackers often use multi-
step techniques to exfiltrate data
• Sample Rule:
 Condition: If a user account accesses an unusually large volume
of files or transfers data to external IP addresses
 Action: Trigger an alert and initiate incident response
procedures
 SIEM
Correlation Rules
Sample Rules for Multi-Step Attacks Detection
3. Flagging Data Exfiltration Attempts:

<rule id="data-exfiltration-detection" name="Flag Data Exfiltration Attempts">

<description>Detects potential data exfiltration by monitoring large volume file access
or data transfer to external IP addresses.</description>
<condition>
<or>
<large_volume_file_access>true</large_volume_file_access>
<data_transfer>
<to_external_ip>true</to_external_ip>
</data_transfer>
</or>
</condition>
<action>
<alert>Trigger an alert and initiate incident response procedures.</alert>
</action>
</rule>
 SIEM
Correlation Rules
Practice Writing New Rules
1. Understand the Context:
• Before diving into rule creation, grasp the
context
• What system or network are you monitoring?
• What are the critical assets?
• What threats are you concerned about?
• For instance, if you’re managing a web
server, consider potential attack vectors like
SQL injection, brute force attempts, or
suspicious file access
2. Start Simple:
• Begin with straightforward rules
• Focus on detecting common anomalies
• Example: “Alert when more than 5 failed
login attempts occur within 1 minute.”
 SIEM
Correlation Rules
Practice Writing New Rules
3. Learn from Existing Rules:
• Study existing correlation rules
• Understand their structure, conditions, and
actions
• Adapt and modify them to suit your
environment
• Remember, practice involves learning from
others’ work too
4. Write Hypothetical Rules:
• Imagine scenarios and create rules
accordingly
• Example: “If a user accesses sensitive files
outside business hours, generate an alert.”

Adobe Acrobat
Document
 SIEM
Correlation Rules
Practice Writing New Rules
Example: “If a user accesses sensitive files outside business hours, generate an
alert.”

<rule id="sensitive-file-access-detection" name="Detect Sensitive File Access Outside

Business Hours">
<description>Generates an alert when a user accesses sensitive files outside of
standard business hours.</description>
<condition>
<file_access>
<file_type>sensitive</file_type>
<time>
<outside_business_hours>true</outside_business_hours>
</time>
</file_access>
</condition>
<action>
<alert>Generate an alert for potential security breach.</alert>
</action>
</rule>
 SIEM
Correlation Rules
Practice Writing New Rules
5. Test Your Rules:
• Use sample log data or historical events to
test your rules
• Ensure they trigger when expected and don’t
generate false positives
6. Iterate and Refine:
• Rule writing is iterative. Revise and improve
• Seek feedback from colleagues or mentors
7. Explore Advanced Techniques:
• Once comfortable, explore more complex
rules:
 Multi-step attack detection (like lateral
movement or privilege escalation)
 Behavioral analysis (e.g., sudden spikes in
activity)
 Cross-correlation (combining multiple
conditions)
 SIEM
Correlation Rules
Practice Writing New Rules
1. Detecting Lateral Movement:
• Scenario: An attacker gains access to a low-privileged
user account and attempts to move laterally across the
network to escalate privileges or access sensitive data
• Sample Rule:
 Condition: If an account logs in from multiple
distinct IP addresses within a short time
frame (e.g., 5 different IPs within 10 minutes)
 Action: Generate an alert and investigate
potential lateral movement
 Implementation:
o Create custom decoders to parse login
events
o Write rules triggered after successful
logins (accept) or failed logins (reject)
o Correlate multiple failed logins within a
specific timeframe to detect lateral
movement
 SIEM
Correlation Rules
Practice Writing New Rules
1. Detecting Lateral Movement:

if
(source_user="low_priv_user") and (action="login") and (destination_host!="original_host")
then
escalate_alert
 SIEM
Correlation Rules
Practice of correlation rule writing using Wazuh SIEM
2. Identifying Privilege Escalation:
• Scenario: An attacker elevates their access level
within the system, After gaining initial access, an
attacker attempts to escalate privileges by exploiting
vulnerabilities or misconfigurations on the target
system
• Sample Rule:
 Condition: If a user account suddenly gains
administrative privileges (e.g., becomes a
member of the “Domain Admins” group)
 Action: Raise an alert and review the
account’s activity
 Implementation:
o Customize rules to trigger based on
privilege changes
o Monitor group membership
modifications
 SIEM
Correlation Rules
Practice of correlation rule writing using Wazuh SIEM
2. Identifying Privilege Escalation:

If
(source_user="attacker") and (action="execute_command") and (command="sudo su")
Then
escalate_alert
 SIEM
Correlation Rules
Practice of correlation rule writing using Wazuh SIEM
3. Flagging Data Exfiltration Attempts:
• Scenario: Detecting data exfiltration to prevent
sensitive information from leaving the network
• Sample Rule:
 Condition: If a user account accesses an
unusually large volume of files or transfers
data to external IP addresses
 Action: Trigger an alert and initiate incident
response procedures
 Implementation:
o Write rules that correlate file access
patterns and network traffic
 SIEM
Correlation Rules
Practice of correlation rule writing using Wazuh SIEM
3. Flagging Data Exfiltration Attempts:
• Use-Case: an attacker attempts to exfiltrate sensitive
data by transferring files to an external server or using
other communication channels

If
(source_user="attacker") and (action="file_transfer") and (destination="external_server")
Then
data_exfiltration_alert
 SIEM
Correlation Rules
Practice of correlation rule writing using Wazuh SIEM
4. Multiple Failed Logins:
• Scenario: Identifying brute-force attacks
• Sample Rule:
 Condition: If there are more than 2 failed
login attempts within a 30-second
timeframe
 Action: Raise an alert and block the source
IP
 Implementation:
o Create a rule triggered after multiple
failed login attempts
o Set frequency and timeframe
parameters
 SIEM
Correlation Rules
Practice of correlation rule writing using Wazuh SIEM
4. Multiple Failed Logins:

<rule id="multiple-failed-logins-detection" name="Detect Multiple Failed Logins">

<description>Identifies brute-force attacks by detecting multiple failed login
attempts.</description>
<condition>
<failed_login_attempts>
<count>2</count>
<timeframe>30</timeframe>
</failed_login_attempts>
</condition>
<action>
<alert>Raise an alert and block the source IP.</alert>
</action>
</rule>
 SIEM
Correlation Rules
Practice of correlation rule writing using Wazuh SIEM
5. Suspicious User Behavior:
• Scenario: Detecting anomalous user activity
• Sample Rule:
 Condition: If a user accesses sensitive files
outside business hours
 Action: Generate an alert and investigate
 Implementation:
o Customize rules based on user behavior
patterns
 SIEM
Correlation Rules
Practice of correlation rule writing using Wazuh SIEM
5. Suspicious User Behavior:
<rule id="suspicious-user-behavior-detection" name="Detect
Suspicious User Behavior">
<description>Detects anomalous user activity by monitoring
access to sensitive files outside of business hours.</description>
<condition>
<user_activity>
<access_to_sensitive_files>
<outside_business_hours>true</outside_business_hours>
</access_to_sensitive_files>
</user_activity>
</condition>
<action>
<alert>Generate an alert and investigate.</alert>
</action>
</rule>
 SIEM
Correlation Rules
Practice of correlation rule writing using Wazuh SIEM
6. Cross-Event Correlation:
• Scenario: Combining different events for context-
aware detection
• Sample Rule:
 Condition: If a failed login occurs, followed
by a successful login from the same user
within 5 minutes
 Action: Trigger an alert
 Implementation:
o Create a rule that correlates both login
events
 SIEM
Correlation Rules
Practice of correlation rule writing using Wazuh SIEM
6. Cross-Event Correlation:
<rule id="context-aware-login-detection" name="Detect Context-
Aware Login Anomalies">
<description>Triggers an alert if a failed login is followed by a
successful login from the same user within 5 minutes.</description>
<conditions>
<condition type="failed_login">
<user_account>$USER_ACCOUNT</user_account>
</condition>
<condition type="successful_login">
<user_account>$USER_ACCOUNT</user_account>
<within_timeframe>5</within_timeframe>
</condition>
</conditions>
<action>
<alert>Trigger an alert for potential security review.</alert>
</action>
</rule>
 SIEM
Correlation Rules
Use-Case of correlation rule writing using Wazuh SIEM
1. Command and Control (C2) Communication Detection:
Use-case: An attacker establishes a command and control channel to remotely
control compromised systems and exfiltrate data
if (destination_ip="known_C2_IP") and (action="outbound_connection") and
(destination_port="C2_port")
Then
c2_communication_alert

<rule id="command-and-control-detection" name="Detect Command and Control Channel">

<description>Detects the establishment of a command and control channel used to remotely control
compromised systems and exfiltrate data.</description>
<condition>
<network_activity>
<outbound_connection>
<to_known_c2_server>true</to_known_c2_server>
</outbound_connection>
</network_activity>
</condition>
<action>
<alert>Generate an alert and initiate a security investigation.</alert>
</action>
</rule>
 SIEM
Correlation Rules
Use-Case of correlation rule writing using Wazuh SIEM
2. Credential Dumping Detection:
Use-case: An attacker compromises a system and attempts to extract passwords and
hashes from memory or stored files

if (source_user="attacker") and (action="access_memory") and (process="lsass.exe")

then
credential_dumping_alert
<rule id="credential-extraction-detection" name="Detect Credential Extraction">
<description>Detects attempts to extract passwords or hashes from memory and stored files.</description
<condition>
<system_activity>
<suspicious_process>
<accessing_sensitive_files>true</accessing_sensitive_files>
<memory_dump>true</memory_dump>
</suspicious_process>
</system_activity>
</condition>
<action>
<alert>Generate an alert and initiate a security investigation.</alert>
</action>
</rule>
 SIEM
Correlation Rules
Wazuh rule categories

• Ignored (Level 0):

 No action is taken for these rules. They are used to
avoid false positives
 Include events with no significant security relevance
• System Low Priority Notification (Level 2):
 These rules relate to system notifications or status
messages
 They have no direct security relevance
• Successful/Authorized Events (Level 3):
 These rules cover successful login attempts, firewall
allow events, and similar authorized actions
• System Low Priority Error (Level 4):
 Errors related to bad configurations or unused
devices/applications fall into this category
 These errors usually have no security relevance and
may result from default installations or software
testing
 SIEM
Correlation Rules
Wazuh rule categories

• User Generated Error (Level 5):

 These rules include missed passwords, denied
actions, and similar user-generated errors
 By themselves, these events have no direct
security relevance
• Low Relevance Attack (Level 6):
 Indicate low-impact attacks, such as worms or
viruses that don’t affect the system significantly
 Also includes frequently triggered IDS events
and common errors
• “Bad Word” Matching (Level 7):
 These rules match events containing words like
“bad” or “error.”
 While often unclassified, they may have some
security relevance
 SIEM
Correlation Rules
Wazuh rule categories

• First Time Seen (Level 8):

 Include events observed for the first time, such as
initial IDS alerts or user logins
 Also covers security-relevant actions
• Error from Invalid Source (Level 9):
 Detects attempts to log in as an unknown user or
from an invalid source
 May have security relevance, especially if repeated
• Multiple User Generated Errors (Level 10):
 Includes multiple bad passwords, failed logins, etc
 May indicate an attack or simply user forgetfulness
• Integrity Checking Warning (Level 11):
 Alerts related to binary modification or rootkit
presence (by Rootcheck)
 May indicate a successful attack
 Also includes IDS events to be ignored due to high
repetition
 SIEM
Correlation Rules
Wazuh rule categories

• High Importance Event (Level 12):

 Covers error or warning messages from
the system, kernel, etc
 May indicate an attack against a specific
application
• Unusual Error (High Importance) (Level 13):
 Often matches common attack patterns
• High Importance Security Event (Level 14):
 Usually determined through correlation
 Indicates an attack
• Severe Attack (Level 15):
 No chances of false positives
 Immediate attention is necessary

Rules classification - Ruleset · Wazuh

documentation
SIEM
Correlation Rules
Process to write Correlation Rules
 The 7-step process to a real-world example using
Wazuh SIEM to write correlation rules for security
event management

•Step 1: Define the Objective

Our objective is to detect a potential security breach by identifying a
pattern of multiple failed login attempts followed by a successful
login
•Step 2: Understand the Data
We have logs from a network that include timestamps, user IDs, and
login success or failure messages
•Step 3: Use Logical Conditions
We create rules to categorize login attempts as either ‘failed’ or
‘successful’
•Example:
IF (login_status = "failed") THEN (alert_level = "low")
IF (login_status = "successful" AND previous_status = "failed") THEN
(alert_level = "high")
SIEM
Correlation Rules
Process to write Correlation Rules

•Step 4: Incorporate Regular Expressions

We use regex to parse the logs and extract the necessary information such as user
ID and login status

•Example:
User '(\w+)' (\w+) from '(\d{1,3}\.\d{1,3}\.\d{1,3}\.\d{1,3})’

User 'Alice' logged in from '192.168.1.10'

This regex captures the user ID, login status, and IP address from the log entries

•Step 5: Test the Rules

We apply these rules to a subset of historical logs to verify that they correctly
identify failed and successful login attempts
•Step 6: Implement and Monitor
After testing, we implement the rules in the Wazuh SIEM and monitor for alerts that
match our correlation rule for potential security breaches
•Step 7: Documentation
We document the correlation rules, their logic, and any incidents they detect for
future reference and analysis
 SIEM
Correlation Rules
Examples of Rules
 Brute Force Attack
 Explanation: Multiple login attempts to guess the correct
credentials
 Sample Rule: XML
<rule id="100001" level="10">
<decoded_as>json</decoded_as>
<field name="event.action">login_attempt</field>
<field name="event.outcome">failure</field>
<description>Brute force attack detection</description>
<frequency>10</frequency>
<timeframe>60</timeframe>
</rule>
• Field Name: event.action - This field specifies the type of event the rule is looking for, which in
this case is a login_attempt
• Field Name: event.outcome - This field specifies the outcome of the event, which in this case
is failure, indicating a failed login attempt
• Frequency: 10 - This is the number of times the event must occur to trigger the rule
• Timeframe: 60 seconds - This is the window during which the specified number of
occurrences must happen to consider the activity suspicious
SIEM
Correlation Rules
Examples of Rules
 SQL Injection
 Explanation: Insertion of malicious SQL queries via user input

 Sample Rule: XML

<rule id="100002" level="12">
<decoded_as>json</decoded_as>
<field name="sql.query">regex</field>
<regex>' OR '1'='1</regex>
<description>SQL Injection attempt</description>
</rule>

•Field Name: sql.query - This field specifies that the rule is looking for
patterns within SQL queries

•Regex: ' OR '1'=‘1, The pattern ' OR '1'='1 is a common SQL injection
technique used to manipulate SQL queries and gain unauthorized access
to databases
 SIEM
Correlation Rules
Examples of Rules
 SQL Injection
Regex: ' OR '1'=‘1: Matches a string used in SQL injection attacks
 The pattern ' OR '1'='1 is a logic condition that is always true and can be used by
an attacker to manipulate a database query to gain unauthorized access to data

•’ OR ': logical operator in a SQL query, which is often used to combine multiple
conditions

•‘1’='1’: In SQL, comparing '1' to '1' will always return true, regardless of any other
conditions in the query

Here’s a simplified example of how it might be used in an attack:

SELECT * FROM users WHERE username = 'admin' AND password = '' OR '1'='1’;

In this case, the attacker doesn’t know the admin’s password, but the injected ' OR
'1'='1 condition causes the query to return true, granting them access as the admin user
 SIEM
Correlation Rules
Conclusion
• Correlation rules are your
allies in the battle against
cyber threats

• With the right syntax,

functions, and continuous
practice, you can enhance
your organization’s security
posture

• Remember, security is a
dynamic field—keep
learning, adapting, and
refining your rules
It’s NOT BUSINESS, It’s Very PERSONAL
Questions

Ali Ali