Jonhnathan
7c90f1d4c4
* Initial commit
* Update Investigation guides - security-docs review
* Update command_and_control_dns_tunneling_nslookup.toml
* Update defense_evasion_amsienable_key_mod.toml
* Apply security-docs review
* Remove dot
* Update rules/windows/command_and_control_rdp_tunnel_plink.toml
Co-authored-by: nastasha-solomon <79124755+nastasha-solomon@users.noreply.github.com>
* Apply changes from review
* Apply the suggestion
Co-authored-by: nastasha-solomon <79124755+nastasha-solomon@users.noreply.github.com>
(cherry picked from commit 817b97f428)
95 lines
4.4 KiB
TOML
95 lines
4.4 KiB
TOML
[metadata]
|
|
creation_date = "2020/10/14"
|
|
maturity = "production"
|
|
updated_date = "2022/05/09"
|
|
|
|
[rule]
|
|
author = ["Elastic"]
|
|
description = """
|
|
Identifies potential use of an SSH utility to establish RDP over a reverse SSH Tunnel. This can be used by attackers to
|
|
enable routing of network packets that would otherwise not reach their intended destination.
|
|
"""
|
|
from = "now-9m"
|
|
index = ["logs-endpoint.events.*", "winlogbeat-*", "logs-windows.*"]
|
|
language = "eql"
|
|
license = "Elastic License v2"
|
|
name = "Potential Remote Desktop Tunneling Detected"
|
|
note = """## Triage and analysis
|
|
|
|
### Investigating Potential Remote Desktop Tunneling Detected
|
|
|
|
Protocol Tunneling is a mechanism that involves explicitly encapsulating a protocol within another for various use cases,
|
|
ranging from providing an outer layer of encryption (similar to a VPN) to enabling traffic that network appliances would
|
|
filter to reach their destination.
|
|
|
|
Attackers may tunnel Remote Desktop Protocol (RDP) traffic through other protocols like Secure Shell (SSH) to bypass network restrictions that block incoming RDP
|
|
connections but may be more permissive to other protocols.
|
|
|
|
This rule looks for command lines involving the `3389` port, which RDP uses by default and options commonly associated
|
|
with tools that perform tunneling.
|
|
|
|
#### Possible investigation steps
|
|
|
|
- Investigate the process execution chain (parent process tree) for unknown processes. Examine their executable files
|
|
for prevalence, whether they are located in expected locations, and if they are signed with valid digital signatures.
|
|
- Identify the user account that performed the action and whether it should perform this kind of action.
|
|
- Contact the account and system owners and confirm whether they are aware of this activity.
|
|
- Investigate other alerts associated with the user/host during the past 48 hours.
|
|
- Assess whether this behavior is prevalent in the environment by looking for similar occurrences across hosts.
|
|
- Examine network data to determine if the host communicated with external servers using the tunnel.
|
|
|
|
### False positive analysis
|
|
|
|
- This activity is unlikely to happen legitimately. Benign true positives (B-TPs) can be added as exceptions if necessary.
|
|
- Investigate the command line for the execution of programs that are unrelated to tunneling, like Remote Desktop clients.
|
|
|
|
### Response and remediation
|
|
|
|
- Initiate the incident response process based on the outcome of the triage.
|
|
- Isolate the involved host to prevent further post-compromise behavior.
|
|
- Take the necessary actions to disable the tunneling, which can be a process kill, service deletion, registry key
|
|
modification, etc. Inspect the host to learn which method was used and to determine a response for the case.
|
|
- Investigate credential exposure on systems compromised or used by the attacker to ensure all compromised accounts are
|
|
identified. Reset passwords for these accounts and other potentially compromised credentials, such as email, business
|
|
systems, and web services.
|
|
- Run a full antimalware scan. This may reveal additional artifacts left in the system, persistence mechanisms, and
|
|
malware components.
|
|
- Determine the initial vector abused by the attacker and take action to prevent reinfection through the same vector.
|
|
- Using the incident response data, update logging and audit policies to improve the mean time to detect (MTTD) and the
|
|
mean time to respond (MTTR).
|
|
|
|
|
|
## Config
|
|
|
|
If enabling an EQL rule on a non-elastic-agent index (such as beats) for versions <8.2, events will not define `event.ingested` and default fallback for EQL rules was not added until 8.2, so you will need to add a custom pipeline to populate `event.ingested` to @timestamp for this rule to work.
|
|
"""
|
|
references = ["https://blog.netspi.com/how-to-access-rdp-over-a-reverse-ssh-tunnel/"]
|
|
risk_score = 73
|
|
rule_id = "76fd43b7-3480-4dd9-8ad7-8bd36bfad92f"
|
|
severity = "high"
|
|
tags = ["Elastic", "Host", "Windows", "Threat Detection", "Command and Control"]
|
|
timestamp_override = "event.ingested"
|
|
type = "eql"
|
|
|
|
query = '''
|
|
process where event.type in ("start", "process_started") and
|
|
/* RDP port and usual SSH tunneling related switches in command line */
|
|
process.args : "*:3389" and
|
|
process.args : ("-L", "-P", "-R", "-pw", "-ssh")
|
|
'''
|
|
|
|
|
|
[[rule.threat]]
|
|
framework = "MITRE ATT&CK"
|
|
[[rule.threat.technique]]
|
|
id = "T1572"
|
|
name = "Protocol Tunneling"
|
|
reference = "https://attack.mitre.org/techniques/T1572/"
|
|
|
|
|
|
[rule.threat.tactic]
|
|
id = "TA0011"
|
|
name = "Command and Control"
|
|
reference = "https://attack.mitre.org/tactics/TA0011/"
|
|
|