This playbook describes how to use the Stories Workbench to investigate stories based on vulnerabilities and scanning activities.
This playbook outlines a systematic approach for SOC engineers to investigate potential security incidents related to scanning activities and vulnerabilities. It provides a framework for gathering initial information, analyzing network traffic, and drawing conclusions about the nature of the threat.
The playbook helps you identify the different stages of an attack across the network for attacks based on scanning activity and vulnerability exploitation. These are some of the tactics commonly associated with these attacks:
-
Reconnaissance
-
Initial access
-
Privilege escalation
-
Lateral movement
-
Exfiltration
The XDR engines identify scanner and vulnerability stories mostly based on IPS signatures that match specific threat behaviors. Understanding the behavior that triggered the story gives you a better idea of how to investigate it. The following table shows the formats for different IPS signatures for these types of stories, and describes the potentially malicious behavior that matches the signature.
|
IPS Signature |
Explanation |
|---|---|
|
cid_cve_* |
Vulnerabilities with CVE identifier |
|
cid_vuln_* |
Vulnerabilities without CVE identifier |
|
cid_scan_* |
For network scanners |
|
cid_waf_* |
For network scanners and vulnerabilities directed to web services |
|
feed_cid_cve_* |
For specific vulnerability-related threat intelligence sources |
|
feed_threat_scanner* |
For inbound traffic associated with IPs that were classified as Threat Scanners |
This section explains the investigation workflow for identifying an attack that originated from a scanning activity or vulnerability exploitation attempt.
Use the Details widget in the story to gather basic information about the potential threat. Review the Description of the story. This can help focus the investigation based on the logic that generated the story. In addition, the Similar Stories section shows other stories that share similar indicators and observables.
To decide if further investigation is required, review additional data, for example:
-
Direction: This impacts the investigation process, for more information see Step 3 - Investigating According to the Direction.
-
Source/Target: This tab displays data about the impacted devices.
Note: For inbound stories, the Target refers to the affected host, while the Source refers to the investigated object located outside of Cato. This can occasionally be caused by devices or sites that are not set up as part of the Cato network, or by configuration errors.
-
Indication Catalog: This can help understand the logic of the indication.
In a Scanner Story you can identify the type of scanner based on the signature that triggered the story and the application indicated in the signature. These can be associated with a specific type such as Nessus, or Qualys, or based on a generic service/application and amount of traffic.
In a Vulnerability Story the references in the events help you understand the vulnerability and focus the investigation on the relevant IOCs.
The Threat Reference field in the event provides the link to look up the threat in the National Vulnerability Database.
The Direction of the story impacts the next steps in the investigation:
The purpose of this stage of the investigation is to identify and verify the possibility of an Information Gathering / Infiltration attempt by an external adversary.
In the Sources table, examine the identified sources to ascertain their potential malicious intent:
-
Analysis of Table Parameters for Risk Evaluation: Evaluate parameters such as the malicious score, popularity, associated categories, and the number of threat intelligence feeds associated with the source to determine the likelihood of the source being malicious.
-
Use Source Links for External Search: Perform an external search using the source links on reputable third-party search engines and security databases. Look for any historical context, associations, or indicators of malicious behavior linked to the source. Correlate the gathered data to identify connections between the sources and other entities and try to determine if there are any links to known threat actors, campaigns, or techniques.
-
Attack Related Flows/Events: Use the designated table to inspect the unprocessed data flow samples corresponding to the triggered story. Analyze supplementary data points from the flows, such as URLs, user agents, file names, and additional relevant attributes, and compare these parameters against the findings from the previous investigation steps and gain insights regarding the final verdict of the communicating source.
After understanding the type of threats based on the related events of the story it is important to drill down to the related events to get additional insights regarding the traffic. For example:
-
Verifying the traffic and classifying it as a true positive or true negative based on the signature’s reference correlating with the data found in the events.
-
Understanding the scope of the threat:
-
Check for additional traffic from the communicating source in to understand if this communication is new, or seen before.
-
Check for additional sources with similar traffic characteristics (application, destination port)
-
Check for additional targets/hosts that were communicated by the investigated source
-
Check for differences between the events such as different URLs, destination ports, request method, etc.
-
Check if the traffic was blocked based on the Action field
-
Conclusion
For Scanner Investigations, there are multiple classifications of known scanners and scanning methods such as:
-
Nessus
-
Nmap
-
Xmas
-
Ping Sweep
For Vulnerability investigations, there are classifications of known vulnerabilities such as:
-
SQL Injection
-
Cross-Site Scripting Injection (XSS Injection)
If the specific vulnerability in the story does not exist on the classification list, you can add it locally to your account by clicking on New and filling in the relevant fields.
In case the story is a true positive and was not blocked, it is highly recommended to add the investigated sources to the RPF policy blocklist. For more information, see Configuring Remote Port Forwarding for the Account.
In case the story is a false positive, you can classify it as Benign/Informational and also add it to a Mute Stories rule. (If the story results from a legitimate scan/penetration test it is recommended to add to a Mute Stories rule for a specific time range.)
The purpose of the investigation is to identify and verify possible cases of exfiltration, Command & Control traffic, botnet activity, etc.
In the Targets table, examine the identified targets to ascertain their potential malicious intent:
-
Analysis of Table Parameters for Risk Evaluation: Evaluate parameters such as the malicious score, popularity, associated categories, and the number of threat intelligence feeds associated with the target to determine the likelihood of the target being malicious.
-
Use Target Links for External Search: In cases of outbound scanning activity, the target investigation can be difficult as most of the communicated targets are not recognized by many if any security engines and lack external data.
However, it is recommended to use external sources to find as much context as possible using any historical context, associations, or indicators of malicious behavior linked to the target. Correlate the gathered data to identify connections between the targets and other entities and try to determine if there are any linkages to known threat actors, campaigns, or techniques.
-
Attack Related Flows/Events: Use the designated table to inspect the unprocessed data flow samples corresponding to the triggered story. Analyze supplementary data points from the flows, such as destination ports, applications, URLs, user agents, destination countries, and additional relevant attributes, and compare these parameters against the findings from the prior investigation and gain insights regarding the final verdict of the communicating target.
After understanding the type of threats based on the related events of the story it is important to drill down to the related events to get additional insights regarding the traffic. For example:
-
Verifying the traffic and classifying it as a true positive or true true negative based on the signature’s reference correlating with the data found on events.
-
Understanding the scope of the threat:
-
Check for additional traffic from the communicating target to understand if this communication is new, or seen before.
-
Check for additional targets with similar traffic characteristics (application, destination port)
-
Check for additional targets/hosts that were communicated to by the investigated target
-
Check for differences between the events such as different URLs, different destination ports, request method, etc.
-
Check if the traffic was blocked based on the Action field
Conclusion
For scanner Investigations, there are multiple classifications of known scanners and scanning methods such as:
-
ICMP Scan
-
SYN Scan
-
SMTP Scan
For Vulnerability investigations, there are classifications of known vulnerabilities such as:
-
SQL Injection
-
Cross-Site Scripting Injection (XSS Injection)
In case the specific vulnerability that was found for the story doesn't exist on the classification list, you can add it locally by clicking on New and filling in the relevant fields.
In case the story is a true positive and was not blocked, it is highly recommended to add the investigated targets to an Internet firewall block rule. In addition, for cases where the IPS signature is allowlisted, it is recommended to block it using the a firewall rule or editing the IPS allow rule to include only known targets.
In case the story is a false positive, you can classify it as Benign/Informational and also add it to a Mute Stories rule. In case the story results from a legitimate scan/penetration test it is recommended to add to a Mute Stories rule for a specific time range.
-
The purpose of the investigation is to identify and verify possible cases of exfiltration, lateral movement, privilege escalation, etc.
The Targets table can provide visibility for all communicated targets.
Utilize the table to inspect the unprocessed data flow samples corresponding to the triggered story. Analyze supplementary data points from the flows, such as URLs, user agents, file names, and additional relevant attributes, and compare these parameters against the findings from the previous investigation steps and gain insights regarding the final verdict of the communicating source.
After understanding the type of threats based on the related events of the story it is important to drill down to the related events to get additional insights regarding the traffic. For example:
-
Verifying the traffic and classifying it as a true positive or true negative based on the signature’s reference correlating with the data found on events
-
Understanding the scope of the threat:
-
Checking for additional traffic from the communicating source to understand if this communication is new, or seen before
-
Checking for additional sources with similar traffic characteristics (application, destination port)
-
Checking for additional targets/hosts that were communicated to by the investigated source
-
Checking for differences between the events such as different URLs, different destination ports, Request Method, etc.
-
Checking if the traffic was blocked based on the Action field
For scanner investigations, there are multiple classifications of known scanners/scanning methods such as:
-
Nessus
-
Nmap
-
Xmas
-
Ping Sweep
For Vulnerability investigations, there are classifications of known vulnerabilities such as:
-
SQL Injection
-
Cross-Site Scripting Injection (XSS Injection)
In case the specific vulnerability that was found for the story doesn't exist on the classification list, you can add it locally by clicking on New and filling in the relevant fields.
In case the story is a true positive and was not blocked, it is highly recommended to add the investigated targets to a WAN firewall block rule. In addition,for cases where the IPS signature is allowlisted, it is recommended to block it using a firewall rule or by editing the IPS allow rule to include only known targets.
In case the story is a false Positive, you can classify it as Benign/Informational and also add it to a Mute Stories rule. If the story results from a legitimate scan or penetration test it is recommended to add it to a Mute Stories rule for a specific time range.
-
0 comments
Please sign in to leave a comment.