[New BBR] Potential Suspicious File Edit

[Aegrah]

Summary

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.

Detection

The interesting part about this rule is that we aren't really capable of capturing file edit events on Linux, and this bypasses this limitation when files are being edited through an editor. By monitoring for the creation of a .swp file, we are basically monitoring for the file open event of a file through an editor.

This rule triggers 100+ events on my testing cluster. All of these hits however are TPs. All of the hits are me editing /etc/passwd, /etc/shadow, service, timer, init.d, rc.local, motd or other files for testing malicious persistence/privesc mechanisms.

Within red sector, this rule triggers 0 times in the last 365 days. Will add this to BBR and monitor rule executions. After some good tunings it might be able to move over to DR. Just making sure it's in BBR first before I flood DR telemetry.

file where event.action in ("creation", "file_create_event") and file.extension == "swp" and 
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"
)

[shashank-elastic]

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

[w0rk3r]

#2960 (comment)

[shashank-elastic]

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?

[shashank-elastic]

@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

[Aegrah]

@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.

[w0rk3r]

@shashank-elastic #1608