-
Notifications
You must be signed in to change notification settings - Fork 522
/
Copy pathendgame_ransomware_detected.toml
73 lines (57 loc) · 5.59 KB
/
endgame_ransomware_detected.toml
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
[metadata]
creation_date = "2020/02/18"
maturity = "production"
promotion = true
updated_date = "2025/01/15"
[rule]
author = ["Elastic"]
description = """
Elastic Endgame detected ransomware. Click the Elastic Endgame icon in the event.module column or the link in the
rule.reference column for additional information.
"""
from = "now-15m"
index = ["endgame-*"]
interval = "10m"
language = "kuery"
license = "Elastic License v2"
max_signals = 10000
name = "Ransomware - Detected - Elastic Endgame"
risk_score = 99
rule_id = "8cb4f625-7743-4dfb-ae1b-ad92be9df7bd"
setup = """## Setup
This 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.
**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.
To 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.
**NOTE:** Changing `xpack.alerting.rules.run.alerts.max` is not possible in Serverless projects."""
severity = "critical"
tags = ["Data Source: Elastic Endgame", "Resources: Investigation Guide"]
timestamp_override = "event.ingested"
type = "query"
query = '''
event.kind:alert and event.module:endgame and endgame.metadata.type:detection and (event.action:ransomware_event or endgame.event_subtype_full:ransomware_event)
'''
note = """## Triage and analysis
> **Disclaimer**:
> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs.
### Investigating Ransomware - Detected - Elastic Endgame
Elastic Endgame is a security solution designed to detect and respond to threats like ransomware by analyzing system events and behaviors. Adversaries exploit vulnerabilities to deploy ransomware, encrypting files and demanding payment. The detection rule identifies ransomware activity by monitoring specific alert types and event actions, flagging critical threats for immediate investigation.
### Possible investigation steps
- Review the alert details in Elastic Endgame by clicking the icon in the event.module column or the link in the rule.reference column to gather more context about the detected ransomware event.
- Analyze the event.kind:alert and event.module:endgame fields to confirm the alert's origin and ensure it aligns with known ransomware activity.
- Examine the event.action:ransomware_event and endgame.event_subtype_full:ransomware_event fields to identify the specific actions or behaviors that triggered the alert.
- Investigate the affected systems and endpoints to determine the scope of the ransomware impact, focusing on any encrypted files or unusual system behaviors.
- Check for any additional alerts or related events in the Elastic Endgame logs that might indicate lateral movement or further malicious activity associated with the ransomware.
### False positive analysis
- Routine backup operations can sometimes mimic ransomware behavior by accessing and modifying large numbers of files. Users should review backup schedules and processes to ensure they are not triggering alerts.
- Legitimate software updates or installations may be flagged as ransomware events due to their file modification activities. Users can create exceptions for trusted software update processes to prevent false positives.
- Automated file encryption tools used for legitimate purposes, such as data protection, might trigger ransomware alerts. Users should whitelist these tools if they are verified and necessary for business operations.
- Security testing or penetration testing activities that simulate ransomware attacks can be mistaken for real threats. Ensure that these activities are coordinated with the security team and excluded from detection rules during testing periods.
- Frequent alerts from specific non-critical systems or applications that are known to exhibit similar behaviors should be reviewed and, if deemed safe, added to an exception list to reduce noise.
### Response and remediation
- Isolate the affected systems immediately to prevent the spread of ransomware to other networked devices. Disconnect them from the network and any shared storage.
- Identify and terminate any malicious processes associated with the ransomware event using endpoint detection and response tools.
- Restore encrypted files from the most recent clean backup. Ensure backups are scanned for malware before restoration to avoid reinfection.
- Conduct a thorough forensic analysis to determine the initial point of entry and the scope of the compromise. This will help in understanding how the ransomware was deployed.
- Apply security patches to address any vulnerabilities exploited by the ransomware. Ensure all systems are updated to prevent similar attacks.
- Enhance monitoring and detection capabilities by configuring alerts for similar event patterns and behaviors identified in the query fields.
- Report the incident to relevant authorities and stakeholders as per organizational policy and legal requirements, ensuring compliance with any regulatory obligations."""