-
Notifications
You must be signed in to change notification settings - Fork 521
/
Copy pathprivilege_escalation_endgame_process_injection_prevented.toml
88 lines (68 loc) · 5.99 KB
/
privilege_escalation_endgame_process_injection_prevented.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
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
[metadata]
creation_date = "2020/02/18"
maturity = "production"
promotion = true
updated_date = "2025/01/15"
[rule]
author = ["Elastic"]
description = """
Elastic Endgame prevented Process Injection. 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 = "Process Injection - Prevented - Elastic Endgame"
risk_score = 47
rule_id = "990838aa-a953-4f3e-b3cb-6ddf7584de9e"
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 = "medium"
tags = ["Data Source: Elastic Endgame", "Use Case: Threat Detection", "Tactic: Privilege Escalation", "Resources: Investigation Guide"]
timestamp_override = "event.ingested"
type = "query"
query = '''
event.kind:alert and event.module:endgame and endgame.metadata.type:prevention and (event.action:kernel_shellcode_event or endgame.event_subtype_full:kernel_shellcode_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 Process Injection - Prevented - Elastic Endgame
Elastic Endgame is a security solution that prevents malicious activities like process injection, a technique often used by adversaries to execute code within the address space of another process, enabling privilege escalation. This detection rule identifies attempts by monitoring alerts for specific kernel shellcode events, indicating potential injection attempts, and helps mitigate threats by leveraging prevention capabilities.
### Possible investigation steps
- Review the alert details to confirm the presence of event.kind:alert and event.module:endgame, ensuring the alert is related to Elastic Endgame's prevention capabilities.
- Examine the event.action and endgame.event_subtype_full fields for kernel_shellcode_event to identify the specific type of process injection attempt.
- Investigate the source process and target process involved in the injection attempt to understand the context and potential impact on the system.
- Check for any associated alerts or logs around the same timeframe to identify if this is part of a larger attack pattern or isolated incident.
- Assess the risk score and severity to prioritize the investigation and determine if immediate action is required to mitigate potential threats.
- Consult the MITRE ATT&CK framework for additional context on the T1055 Process Injection technique to understand common methods and potential mitigations.
### False positive analysis
- Legitimate software updates or installations may trigger kernel shellcode events. Users can create exceptions for known update processes by identifying their unique process identifiers or paths.
- Security tools or monitoring software that perform deep system scans might mimic process injection behavior. Exclude these tools by specifying their executable names or hashes in the exception list.
- Custom scripts or automation tools that interact with system processes could be flagged. Review these scripts and whitelist them if they are verified as safe and necessary for operations.
- Development environments or debugging tools that inject code for testing purposes may cause alerts. Establish exceptions for these environments by defining rules based on the development tools' signatures or process names.
- Virtualization software that uses process injection techniques for managing virtual machines can be mistakenly identified. Add these applications to the exclusion list by recognizing their specific process attributes.
### Response and remediation
- Immediately isolate the affected system from the network to prevent further malicious activity and lateral movement.
- Terminate any suspicious processes identified by the alert, particularly those associated with the kernel shellcode event, to halt ongoing malicious actions.
- Conduct a thorough analysis of the affected system to identify any additional indicators of compromise or secondary payloads that may have been deployed.
- Restore the affected system from a known good backup to ensure any injected code or malicious modifications are removed.
- Apply security patches and updates to the operating system and all installed software to close any vulnerabilities that may have been exploited.
- Monitor the network and systems for any signs of similar process injection attempts, using enhanced logging and alerting based on the identified threat indicators.
- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if additional systems are affected."""
[[rule.threat]]
framework = "MITRE ATT&CK"
[[rule.threat.technique]]
id = "T1055"
name = "Process Injection"
reference = "https://attack.mitre.org/techniques/T1055/"
[rule.threat.tactic]
id = "TA0004"
name = "Privilege Escalation"
reference = "https://attack.mitre.org/tactics/TA0004/"