Rapid7 Threat Command CVEs Correlation
This rule is triggered when CVEs collected from the Rapid7 Threat Command Integration have a match against vulnerabilities that were found in the customer environment.
Elastic rule (View on GitHub)
1[metadata]
2creation_date = "2024/05/29"
3integration = ["ti_rapid7_threat_command"]
4maturity = "production"
5min_stack_comments = "Breaking change at 8.13.0 for Rapid7 Threat Command Integration"
6min_stack_version = "8.13.0"
7updated_date = "2024/08/06"
8
9[rule]
10author = ["Elastic"]
11description = """
12This rule is triggered when CVEs collected from the Rapid7 Threat Command Integration have a match against
13vulnerabilities that were found in the customer environment.
14"""
15from = "now-35m"
16index = ["auditbeat-*", "endgame-*", "filebeat-*", "logs-*", "packetbeat-*", "winlogbeat-*"]
17interval = "30m"
18language = "kuery"
19license = "Elastic License v2"
20max_signals = 10000
21name = "Rapid7 Threat Command CVEs Correlation"
22note = """## Triage and Analysis
23
24### Investigating Rapid7 Threat Command CVEs Correlation
25
26Rapid7 Threat Command CVEs Correlation rule allows matching CVEs from user indices within the vulnerabilities collected from Rapid7 Threat Command integrations.
27
28The matches will be based on the latest values of CVEs from the last 180 days. So it's essential to validate the data and review the results by investigating the associated activity to determine if it requires further investigation.
29
30If a vulnerability matches a local observation, the following enriched fields will be generated to identify the vulnerability, field, and type matched.
31
32- `threat.indicator.matched.atomic` - this identifies the atomic vulnerability that matched the local observation
33- `threat.indicator.matched.field` - this identifies the vulnerability field that matched the local observation
34- `threat.indicator.matched.type` - this identifies the vulnerability type that matched the local observation
35
36Additional investigation can be done by reviewing the source of the activity and considering the history of the vulnerability that was matched. This can help understand if the activity is related to legitimate behavior.
37
38- Investigation can be validated and reviewed based on the data that was matched and by viewing the source of that activity.
39- Consider the history of the vulnerability that was matched. Has it happened before? Is it happening on multiple machines? These kinds of questions can help understand if the activity is related to legitimate behavior.
40- Consider the user and their role within the company: is this something related to their job or work function?
41"""
42references = [
43 "https://www.elastic.co/guide/en/beats/filebeat/current/filebeat-module-threatintel.html",
44 "https://docs.elastic.co/integrations/ti_rapid7_threat_command"]
45risk_score = 99
46rule_id = "3a657da0-1df2-11ef-a327-f661ea17fbcc"
47setup = """
48
49## Setup
50
51This rule needs threat intelligence indicators to work.
52Threat intelligence indicators can be collected using an [Elastic Agent integration](https://www.elastic.co/guide/en/security/current/es-threat-intel-integrations.html#agent-ti-integration),
53the [Threat Intel module](https://www.elastic.co/guide/en/security/current/es-threat-intel-integrations.html#ti-mod-integration),
54or a [custom integration](https://www.elastic.co/guide/en/security/current/es-threat-intel-integrations.html#custom-ti-integration).
55
56More information can be found [here](https://www.elastic.co/guide/en/security/current/es-threat-intel-integrations.html).
57
58## Max Signals
59
60This rule is configured to generate more **Max alerts per run** than the default 1000 alerts per run set for all rules. This is to ensure that it captures as many alerts as possible.
61
62**IMPORTANT:** The rule's **Max alerts per run** setting can be superseded by the `xpack.alerting.rules.run.alerts.max` Kibana config setting, which determines the maximum alerts generated by _any_ rule in the Kibana alerting framework. For example, if `xpack.alerting.rules.run.alerts.max` is set to 1000, this rule will still generate no more than 1000 alerts even if its own **Max alerts per run** is set higher.
63
64To make sure this rule can generate as many alerts as it's configured in its own **Max alerts per run** setting, increase the `xpack.alerting.rules.run.alerts.max` system setting accordingly.
65
66**NOTE:** Changing `xpack.alerting.rules.run.alerts.max` is not possible in Serverless projects.
67"""
68severity = "critical"
69tags = [
70 "OS: Windows",
71 "Data Source: Elastic Endgame",
72 "Data Source: Windows",
73 "Data Source: Network",
74 "Data Source: Rapid7 Threat Command",
75 "Rule Type: Threat Match",
76 "Resources: Investigation Guide",
77 "Use Case: Vulnerability",
78 "Use Case: Asset Visibility",
79 "Use Case: Continuous Monitoring",
80]
81threat_index = ["logs-ti_rapid7_threat_command_latest.vulnerability"]
82threat_indicator_path = "rapid7.tc.vulnerability"
83threat_language = "kuery"
84threat_query = """
85@timestamp >= "now-30d/d" and vulnerability.id : * and event.module: ti_rapid7_threat_command
86"""
87timestamp_override = "event.ingested"
88type = "threat_match"
89
90query = '''
91vulnerability.id : *
92'''
93
94
95[[rule.filters]]
96
97[rule.filters."$state"]
98store = "appState"
99[rule.filters.meta]
100disabled = false
101key = "rapid7.tc.vulnerability.id"
102negate = true
103type = "exists"
104[rule.filters.query.exists]
105field = "rapid7.tc.vulnerability.id"
106[[rule.threat_mapping]]
107
108[[rule.threat_mapping.entries]]
109field = "vulnerability.id"
110type = "mapping"
111value = "vulnerability.id"
Triage and Analysis
Investigating Rapid7 Threat Command CVEs Correlation
Rapid7 Threat Command CVEs Correlation rule allows matching CVEs from user indices within the vulnerabilities collected from Rapid7 Threat Command integrations.
The matches will be based on the latest values of CVEs from the last 180 days. So it's essential to validate the data and review the results by investigating the associated activity to determine if it requires further investigation.
If a vulnerability matches a local observation, the following enriched fields will be generated to identify the vulnerability, field, and type matched.
threat.indicator.matched.atomic
- this identifies the atomic vulnerability that matched the local observationthreat.indicator.matched.field
- this identifies the vulnerability field that matched the local observationthreat.indicator.matched.type
- this identifies the vulnerability type that matched the local observation
Additional investigation can be done by reviewing the source of the activity and considering the history of the vulnerability that was matched. This can help understand if the activity is related to legitimate behavior.
- Investigation can be validated and reviewed based on the data that was matched and by viewing the source of that activity.
- Consider the history of the vulnerability that was matched. Has it happened before? Is it happening on multiple machines? These kinds of questions can help understand if the activity is related to legitimate behavior.
- Consider the user and their role within the company: is this something related to their job or work function?
References
Related rules
- Persistence via Update Orchestrator Service Hijack
- Service DACL Modification via sc.exe
- Component Object Model Hijacking
- Creation of a Hidden Local User Account
- Registry Persistence via AppInit DLL