Security Alerts

Analysis
Network Security
Agenda
Writing Snort Rules

IDS Rules Best Practices

IDS Alert Analysis

2
Understanding SNORT Rules

Action: informs Snort what kind of action to be performed when it detects a packet
that matches the rule description. The default action is alert, the other actions are:
log, pass, drop, reject and sdrop.

3
SNORT Question

4
Understanding SNORT Rules

Protocol: this option tell snort to apply this rule for a specific protocol e.g (ip, tcp, udp,
icmp, any)
Source IP: this option tell snort to apply this rule for a specific source IP address, subnet or
any ip address.
Source Port: This part of header describes the source Port from which traffic is coming.

5
Understanding SNORT Rules

Direction operator (“->”, “<>”): It denotes the direction of traffic flow between sender and receiver networks.

Destination IP: This part of header describes the destination network interface in which traffic is coming for
establishing a connection.

Destination Port: This part of header describes the destination Port on which traffic is coming for
establishing a connection.

6
Understanding SNORT Rules
Rule Options: The body for rule option is usually written between circular
brackets “( )” that contains keywords with their argument and the keyword are
separated by semicolon “;”
There are general options and the keywords, and there are options and keywords that
are protocol specific.
In the options we may specify or search for a unique pattern in the packet payload
using the keyword content
You may use regex or regular expression to match payload contents

7
Writing Snort Rules
We can write a SNORT rule to generate an alert when we detect incoming or outgoing
ICMP ping request
alert icmp any any < > any any (itype:8;msg: "ping detected"; sid:1000001;)
The above rule will generate an alert message on every ping packet detect by the IDS
regardless the ping message direction.

The above rule is an example of a valid SNORT rule but a bad one.

8
Writing Snort Rules
Let us write a rule to detect a DOS Jolt attack.
Jolt attack is a denial of service (DoS) attack caused by a very large ICMP packet that
is fragmented in such a way that the targeted machine is unable to reassemble it
alert ip $EXTERNAL_NET any -> $HOME_NET any (msg:"DOS Jolt attack";
dsize:408; fragbits:M; reference:cve,1999-0345; classtype:attempted-dos;
sid:268; rev:4;)

9
Writing Snort Rules
Let us write a rule to detect potential SQL injection attacks that use SQL keywords like [and,
or] or attacks that use special characters

alert tcp any any -> any 80 (msg: “AND SQL Injection”; content:
“and” ; nocase; sid:100000008; )
alert tcp any any -> any 80 (msg: “OR SQL Injection”; content:
“or” ; nocase; sid:100000009; )

alert tcp any any -> any 80 (msg: “Form Based SQL Injection”;
content: “%27” ; sid:1000003; )

10
Writing Snort Rules
Let us write a rule to malicious attachments (e.g. virus, botnet, etc) in TCP traffic.
alert tcp $HOME_NET any -> $EXTERNAL_NET 25 (msg:"VIRUS OUTBOUND bad file
attachment"; flow:to_server,established; content: "Content-Disposition|3A|";nocase;
pcre:"/filename\s*=\s*.*?\.(?=[abcdehijlmnoprsvwx])(a(d[ep]|s[dfx])|c([ho]m|li|md|pp)
|d(iz|ll|ot)|e(m[fl]|xe)|h(lp|sq|ta)|jse?|m(d[abew]|s[ip])|p(p[st]|if|[lm]|ot)|r(eg|tf)|s(cr|[
hy]s|wf)|v(b[es]?|cf|xd)|w(m[dfsz]|p[dmsz]|s[cfh])|xl[tw]|bat|ini|lnk|nws|ocx)[\x27\x22
\n\r\s]/iR"; classtype:suspicious-filename-detect; sid:721; rev:8;)

11
SNORT Question

12
Write and Deploy your own Snort Rules
As a new SNORT user it is recommend that you write your new snort rules into the
file local.rules. Which is commonly used to store custom SNORT rules for a given site.

To open this file use any text editor using the following command

sudo gedit /etc/snort/rules/local.rules

13
Write and Deploy your own Snort Rules
As you can see the local.rules is by default an empty file (no predefined rules)

14
Write and Deploy your own Snort Rules
Let us add the following rule and save the file:

alert tcp any any -> any 443 (msg: "detect HTTPs traffic"; sid:80000000001; rev:1;)

15
SNORT Log files
SNORT logs are by default stored /var/log/snort/

16
SNORT Alerts in CSV file

17
IDS Rules Best Practice
1. Disable all rules and only enable the rules that match your organization security
policy.

2. Use passive actions like log and alert until you are confident that the rules are
correct. Then, you may consider more active actions.

3. Use simple rules and avoid complex rules that try to detect multiple attacks
patterns.

18
IDS Rules Best Practice
4. Avoid overgeneralized rules; overgeneralized rules will result in false positives

19
IDS Rules Best Practice
5. Avoid overfitting rules that use single attribute for the matching like port
number or content. This is usually will increase the false negative.

20
IDS Rules Best Practice
6. Group your custom rules by application, services or attacks.

7. Only log packages that you plan to inspect or use for forensic analysis. Example
log packets about a virus and malware but do not log packets with spoofed IP

8. Use informative log and alert messages.

9. Check the available ruleset to make sure you are not creating duplicate rules

21
IDS Rules Best Practice
10. Add as many as possible information about the attack pattern or signature

22
Indicator of Attacks
● An indicator of attack (IoA) is a type of security event that can indicate that an
attempted or successful cyber attack is occurring or has occurred.
● IoAs focus on the behavior associated with attacks, allowing security teams to
potentially stop attacks in progress before they reach their objectives.
● They are often more complex to detect and interpret because they require
understanding the context of the observed actions.
● IoAs are generated by analyzing network traffic, system logs, and other data
sources for patterns or behaviors that are commonly associated with specific
types of attacks.

23
IoA Examples
● Sequential failed login attempts: Indicative of a brute force attack.

● Unusual file modifications: Could suggest tampering or attempts to introduce

malware.
● Registry or system setting changes: Often used by attackers to establish
persistence or disable security features.
● Spike in database read volume: Could indicate data exfiltration attempts.
● Suspicious network connections: Connections to rare external ports or servers
that are not typically accessed.

24
Indicator of Compromise
● An indicator of compromise (IoC) is similar to an IoA, but it refers specifically to
evidence that an attack has already occurred and that an attacker has
successfully gained access to a system or network.
● Generated by analyzing system logs, network traffic, and other data sources.
● IoCs are pieces of forensic data that are found in system logs, files, or observed as
network traffic that suggest an intrusion.
● IoCs are retrospective in nature; they are used after an event to confirm that a
breach has occurred. They help in the mitigation process by allowing defenders
to search for and identify specific known bad entities within a system or
network.

25
IoC Examples
● IP addresses: IPs known to be associated with malicious activities.
● Domain names: Domains involved in hosting malicious content.
● URLs: Specific URLs that deliver malware or are part of phishing attacks.
● File hashes: Signatures of known malicious software.
● Malware signatures: Patterns in file code or behavior that match known
malware.
● Unusual outbound traffic: Data being sent to unauthorized destinations.
● Anomalies in account behavior: Such as unexpected logins at odd hours or
high-volume data transfers.

26
Using IoAs and IoCs in Threats Detection
Both IOAs and IOCs are important for threat detection and response:

● By monitoring for these types of indicators, security teams can quickly identify
and respond to potential cyber attacks.

● However, IOAs and IOCs are not foolproof, and attackers may be able to evade
detection by using advanced techniques or by taking steps to hide their activities.
● A comprehensive security strategy is necessary, including multiple layers of
protection and ongoing monitoring and analysis of security events.

27
IoAs and IoCs in Threats Detection and Analysis
By effectively using IoCs and IoAs, organizations can enhance their ability to detect, respond
to, and prevent security threats, thereby strengthening their overall cybersecurity posture.
HOW??
● Detection: They provide the necessary information to configure security tools to detect
malicious activities efficiently.
● Response: Armed with knowledge about IoCs and IoAs, security teams can craft
responses that are appropriate not just to the threats themselves but also to their
potential impact and progression.
● Forensic Analysis: IoCs are particularly useful for forensics, helping analysts trace back
the origins of an attack and understand its impact.
● Preventive Measures: IoAs help in configuring security systems to preemptively block
or alert on activities that are likely precursors to an attack.

28
Challenges in IDS Alerts Analysis
● The challenges in IDS alerts analysis could be grouped into two main categories:
● Correctness Challenges:
○ Alert Flooding
○ False Positive
○ False Negative
○ Isolation
● Automation Challenges:
○ Interoperability
○ Machine Readability
○ Complex and Symbolic Data

29
Correctness Challenge Alert Flooding
● Massive number of alerts
● A single IDS sensor generates on average 400 alerts per minute

30
Correctness Challenge: False Positive and False Negative

31
Correctness Challenge: Isolation
IDS Isolation
● IDS generates isolated low-level alerts.
● IDS not designed to detect implicit or explicit relations between alerts
Example:
● Horizontal Scan ( Same port different IP)
● Vertical Scan ( Same IP different port)
● Box Scan
Why IDS alerts are isolated?
● Detecting implicit or explicit relations is expensive.

32
Automation Challenges: Machine Readability
● Alerts are expressed in a format that cannot easily be interpreted by computers.
● Alerts are generated primarily toward human consumption

33
Automation Challenges: Interoperability
● Alerts generated by heterogeneous IDS sensors may use different keywords,
vocabularies, and formats.
● Intrusion Detection Message Exchange Format (IDMEF).

34
Automation Challenges: Complex and Symbolic Data
● IDS alerts are encoded using complex and symbolic data format.
● Knowledge required for alert analysis are implicit in the alert message.
● Can not measure similarity or distance between alert

35
Snort Alert Example
alert tcp any any -> $HOME_NET 80 (msg:"Possible DDoS attempt
detected"; flags:S; threshold: type both, track by_src, count 100,
seconds 1; classtype:attempted-dos; sid:1000001; rev:1;)

Explain the alert signature?

When it will be trigger?

Is this alert trigger by IoC or IoA?

36
IDS Alert Analysis
● Alert analysis in the context of cybersecurity refers to the process of examining
and interpreting alerts generated by security systems, such as Intrusion
Detection Systems (IDS), Security Information and Event Management (SIEM)
systems, or antivirus software.

● Due to the high volume of alerts that can be generated, especially in large or
complex environments, the first step is often to triage the alerts. This means
prioritizing them based on their severity, potential impact, and the reliability of
the detection method used.

37
Common IDS Alert Analysis Tasks
1. Alerts normalization: alerts generated by different IDS sensors are usually stored in
different data stores and different format which create an interoperability problem.
2. Alerts filtering or verification: Not all the generated IDS alerts report actual attack
attempts. False positive alerts is a known issue in IDS. Therefore a security analyst needs to
inspect the reported alerts to check if the attack is real or not
3. Alerts fusion or aggregation: Eliminate duplicated, near duplicate alerts and similar alerts
to reduce the number of alerts needs investigation
4. Alerts correlation : Group related alerts that belong to the same attack pattern or scenario
to reconstruct the attack scenario. Sophisticated attacks are usually a multistage attack
scenario.

38
Alerts Normalization
● Normalization involves transforming data from various sources into a common
format.
● This step is crucial because it allows data from different systems or software to
be analyzed collectively and consistently.
● For example, time formats, IP address representations, or event codes from
different systems might be standardized so they can be compared and analyzed
uniformly. This is especially important in environments with diverse security
tools.

39
Alerts Normalization Example
Alerts Received:

● Alert from Firewall: "10.0.0.5 attempted to connect to known malicious IP 201.168.45.67 on 14/05/2024 at 15:32."
● Alert from Antivirus: "Malware detected on machine 10.0.0.5 at 3:32 PM on May 14, 2024."

Normalization Process:

● Standardize IP address format if needed.

● Unify date and time format to "YYYY-MM-DD HH:MM" (24-hour format).
● Merge similar terminology and codify severity levels.

Normalized Alerts:

● "2024-05-14 15:32: Host 10.0.0.5 attempted to connect to known malicious IP 192.168.45.67. [Firewall]"
● "2024-05-14 15:32: Malware detected on host 10.0.0.5. [Antivirus]"

40
Alerts Verification
● Verification is the process of validating alerts to determine their accuracy and
relevance.
● This involves confirming whether an alert truly represents a security threat (true
positive) or is a benign event incorrectly flagged as malicious (false positive).
● Verification helps in reducing the noise in the alert system and ensures that
security personnel focus their efforts on genuine threats.

Contextualization is adding context to the alert by correlating it with other data

sources, such as logs from other systems, recent changes in the network, or threat
intelligence reports. It is the key for effective verification.

41
Alert Verification Process
Typical Alert Verification Pipeline

● Automated Initial Triage

● Integration with Threat Intelligence

● Contextualization
● Standard Operating Procedures (SOPs)

42
Alerts Verification Example
Alerts in Question
● "2024-05-14 15:32: Host 10.0.0.5 attempted to connect to known malicious IP 201.168.45.67.
[Firewall]"
● "2024-05-14 15:32: Malware detected on host 10.0.0.5. [Antivirus]"
Verification Process:
● Check the reliability of the source IPs and the detection engines' accuracy.
● Verify the reputation of the flagged IP address against updated threat intelligence.
● Check for any reported false positives related to the current malware signature.
Verification Outcome:
● Both alerts are verified as true positives: the IP address is still listed in recent threat reports,
and the malware signature matches a known threat without recent false positives.

43
Alerts Aggregation
● Aggregation refers to the grouping of similar alerts into a single incident to
reduce the volume of alerts that need to be handled individually.

● This can mean combining multiple alerts from the same source, or about the
same event, into a single, more manageable alert.
● Aggregation helps in simplifying the analysis by reducing the number of alerts to
be reviewed and focusing on broader patterns or repeated attacks.

44
Alerts Aggregation Process
A simple aggregation approach

● Identify alerts that originate from the same host and occur within a short
timeframe.
● Combine these alerts into a single incident report, noting that multiple security
issues were detected on the same machine simultaneously.

45
Alerts Aggregation Example
Alerts in Question

● "2024-05-14 15:32: Host 10.0.0.5 attempted to connect to known malicious IP

201.168.45.67. [Firewall]"
● "2024-05-14 15:32: Malware detected on host 10.0.0.5. [Antivirus]"

Aggregated Incident:

● "2024-05-14 15:32: Multiple security threats detected on host 10.0.0.5, including

a connection attempt to a malicious IP and malware detection. [Firewall,
Antivirus]"

46
Alerts Correlation
● Correlation is the process of linking related alerts to identify patterns or
potential attack campaigns.

● By analyzing the relationship between different alerts, correlation can reveal

complex multi-step threats that might be overlooked if the alerts were
considered separately.
● Correlation can involve time-based linking (events that occur close in time),
causal linking (one event leading to another), or situational linking (events
related by the context of a larger scenario).

47
Alerts Correlation Process
● Examine other security logs for related events, such as unauthorized access
attempts, unusual outbound traffic, or system changes around the same time.
● Look for similar patterns across different machines or over a historical timeline
to identify broader attack patterns or campaigns.
● A common approach to alert correlation focuses on identifying the
pre-conditions and post-conditions of incidents, which helps security teams
better understand the sequence of events and their implications.

48
Alerts Correlation Example
Alerts in Question
1. alert tcp any any -> $HOME_NET 445 (msg:"Possible SMB Reconnaissance";
content:"|00 01 00 81 00|"; flow:to_server,established; sid:1000001; rev:1;
2. alert tcp any any -> $HOME_NET 445 (msg:"SMB Exploit Attempt"; content:"|ff
ff ff ff|"; flow:to_server,established; sid:1000002; rev:1;)
3. alert tcp $HOME_NET any -> $HOME_NET 445 (msg:"Suspected Lateral Movement
via SMB"; content:"|00 00 00 00|"; flow:to_server,established; sid:1000003;
rev:1;)
4. alert tcp $HOME_NET any -> any 80 (msg:"Potential Ransomware C2
Communication"; content:"/encrypt_ready"; flow:to_server,established;
sid:1000004; rev:1;)

49
Alerts Correlation Example
● In this scenario, correlating these alerts would involve recognizing the sequence
from reconnaissance (Alert 1) to exploitation (Alert 2), followed by lateral
movement (Alert 3), and finally, command and control activities (Alert 4).

● By analyzing the progression of these alerts, security teams can more effectively
understand the scope of the attack, respond appropriately, and possibly intercept
the attack before significant damage occurs (such as file encryption in a
ransomware attack).

50
Alerts Analysis in Nutshell
● Alert Generation: Security systems detect anomalies and threats, generating
alerts.
● Normalization: Standardizing data formats from various sources for uniform
analysis.
● Verification: Assessing alerts to confirm genuine threats versus benign activities.
● Aggregation: Combining similar alerts to reduce volume and simplify
management.
● Correlation: Linking related alerts to identify complex, multi-stage attacks.
● Prioritization and Response: Determining the urgency and appropriate actions
for each alert.

51
The End
Questions??

52