Skip to content

[New BBR] Potential Suspicious File Edit #2960

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 3 commits into from
Jul 26, 2023
Merged

[New BBR] Potential Suspicious File Edit #2960

Changes from 1 commit
Commits
Show all changes
3 commits
Select commit Hold shift + click to select a range
eba11bf
[New BBR] Potential Suspicious File Edit
Aegrah Jul 25, 2023
de58821
Added a few more interesting files
Aegrah Jul 26, 2023
15ec8c0
Merge branch 'main' into new-bbr-file-edited-by-editor
shashank-elastic Jul 26, 2023
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
106 changes: 106 additions & 0 deletions rules_building_block/persistence_suspicious_file_opened_through_editor.toml
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -0,0 +1,106 @@
[metadata]
creation_date = "2023/07/25"
maturity = "production"
min_stack_comments = "New fields added: required_fields, related_integrations, setup"
min_stack_version = "8.3.0"
updated_date = "2023/07/25"
integration = ["endpoint"]

[rule]
author = ["Elastic"]
description = """
This rule monitors for the potential edit of a suspicious file. In Linux, when editing a file through an editor, a
temporary .swp file is created. By monitoring for the creation of this .swp file, we can detect potential file edits of
suspicious files. The execution of this rule is not a clear sign of the file being edited, as just opening the file
through an editor will trigger this event. Attackers may alter any of the files added in this rule to establish
persistence, escalate privileges or perform reconnaisance on the system.
"""
from = "now-119m"
interval = "60m"
index = ["logs-endpoint.events.*", "endgame-*"]
language = "eql"
license = "Elastic License v2"
name = "Potential Suspicious File Edit"
risk_score = 21
rule_id = "3728c08d-9b70-456b-b6b8-007c7d246128"
severity = "low"
tags = ["Domain: Endpoint", "OS: Linux", "Use Case: Threat Detection", "Tactic: Persistence", "Tactic: Privilege Escalation", "Data Source: Elastic Endgame", "Rule Type: BBR"]
timestamp_override = "event.ingested"
type = "eql"
building_block_type = "default"

query = '''
file where event.action in ("creation", "file_create_event") and file.extension == "swp" and
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why are we not using change or file modify events such as

  • change
  • updated
  • renamed or rename will also file name changes for sensitive files.

We already have a similar rule to monitor /etc/ld.so.preload which was tuned in 8.9 Telemetry analysis and event action was added. Where we found updated event was very helpful in reducing false positives as it reflected the changes to the file. rules/linux/privilege_escalation_ld_preload_shared_object_modif.toml

I am a bit unclear why .swp files?

Am also providing a sample file event actions that could be of help
creation
rename
renamed
changed-file-permissions-of
attributes_modified
changed-file-ownership-of
created
moved

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

#2960 (comment)

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The edit file should also be reflected in "changed" or "updated" right? Make it enough to monitor the original file as opposed to .swp files?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@Aegrah I am curious to check if you run the suggested query with change or updated for original file and not the swp file extension ones do we still see the same result in ur test cluster like you have hits for the swp files.
If not then it gets interesting to understand what does changed or updated actually reflect in file events

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@shashank-elastic The whole point of this rule is to bypass our current limitations with regards to file edits. We are currently not able to detect file edits in any other way. As everything is a file, Linux always needs to keep a current state and a new state while editing in an editor. That's why .swp files are created when editing files using an editor, so it can afterwards overwrite the new file with the .swp file, or just remove the .swp file if no changes are made. The logic provided in this rule bypasses our limitation, by looking at the .swp files in order to detect file edits, because of the .swp file creation event.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@shashank-elastic #1608

file.path : (
/* common interesting files and locations */
"/etc/.shadow.swp", "/etc/.passwd.swp", "/etc/.hosts.swp", "/etc/.environment.swp", "/etc/.profile.swp",
"/etc/ld.so.conf.d/.*.swp", "/etc/sudoers.d/.*.swp", "/etc/init.d/.*.swp", "/etc/.rc.local.swp", "/etc/rc*.d/.*.swp",
"/dev/shm/.*.swp", "/etc/update-motd.d/.*.swp", "/usr/lib/update-notifier/.*.swp",

/* service, timer, want, socket and lock files */
"/etc/systemd/system/.*.swp", "/usr/local/lib/systemd/system/.*.swp", "/lib/systemd/system/.*.swp",
"/usr/lib/systemd/system/.*.swp","/home/*/.config/systemd/user/.*.swp", "/run/.*.swp", "/var/run/.*.swp/",

/* profile and shell configuration files */
"/home/*.profile.swp", "/home/*.bash_profile.swp", "/home/*.bash_login.swp", "/home/*.bashrc.swp", "/home/*.bash_logout.swp",
"/home/*.zshrc.swp", "/home/*.zlogin.swp", "/home/*.tcshrc.swp", "/home/*.kshrc.swp", "/home/*.config.fish.swp",
"/root/*.profile.swp", "/root/*.bash_profile.swp", "/root/*.bash_login.swp", "/root/*.bashrc.swp", "/root/*.bash_logout.swp",
"/root/*.zshrc.swp", "/root/*.zlogin.swp", "/root/*.tcshrc.swp", "/root/*.kshrc.swp", "/root/*.config.fish.swp"
)
'''

[[rule.threat]]
framework = "MITRE ATT&CK"

[rule.threat.tactic]
id = "TA0003"
name = "Persistence"
reference = "https://attack.mitre.org/tactics/TA0003/"

[[rule.threat.technique]]
id = "T1037"
name = "Boot or Logon Initialization Scripts"
reference = "https://attack.mitre.org/techniques/T1037/"

[[rule.threat.technique.subtechnique]]
id = "T1037.004"
name = "RC Scripts"
reference = "https://attack.mitre.org/techniques/T1037/004/"

[[rule.threat.technique]]
id = "T1574"
name = "Hijack Execution Flow"
reference = "https://attack.mitre.org/techniques/T1574/"

[[rule.threat.technique.subtechnique]]
id = "T1574.006"
name = "Dynamic Linker Hijacking"
reference = "https://attack.mitre.org/techniques/T1574/006/"

[[rule.threat.technique]]
id = "T1543"
name = "Create or Modify System Process"
reference = "https://attack.mitre.org/techniques/T1543/"

[[rule.threat.technique.subtechnique]]
id = "T1543.002"
name = "Systemd Service"
reference = "https://attack.mitre.org/techniques/T1543/002/"

[[rule.threat]]
framework = "MITRE ATT&CK"

[rule.threat.tactic]
id = "TA0004"
name = "Privilege Escalation"
reference = "https://attack.mitre.org/tactics/TA0004/"

[[rule.threat.technique]]
id = "T1548"
name = "Abuse Elevation Control Mechanism"
reference = "https://attack.mitre.org/techniques/T1548/"

[[rule.threat.technique.subtechnique]]
id = "T1548.003"
name = "Sudo and Sudo Caching"
reference = "https://attack.mitre.org/techniques/T1548/003/"