Overview of Linux Threats category
This document provides an overview of the rule sets in the Linux Threats category, the required data sources, and configuration you can use to tune the alerts generated by these rule sets.
Rule sets in the Linux Threats category help identify threats in Linux environments using CrowdStrike Falcon, Linux Auditing System (AuditD), and Unix system logs. This category includes the following rule sets:
- OS Privilege Escalation Tools: Detects behavior commonly seen in open source Linux privilege escalation tools.
- Persistence Mechanisms: Activity used by adversaries to establish and maintain persistent access on Linux hosts.
- Privilege Modifications: Activity associated with privileged authentication attempts and actions, commonly used to privilege-escalate or persist on Linux hosts.
- Malware Signals - Suspicious LOTL Binary Activity: Detects suspicious native tool usage (Living Off the Land) scenarios based on the observed activity of Linux malware in real-world environments.
- Malware Signals - Suspicious Download Activity: Detects behavior seen in relation to malicious download activity on Linux in real-world environments.
- Malware Signals - Suspicious Execution: Detects signals generated from observed behaviors of Linux malware detected in real-world environments with a focus on Execution (TA0002) behaviors.
Supported devices and log types
Rule sets in the Linux Threats category have been tested and are supported with the following Google Security Operations supported data sources:
- Linux Auditing System (
AUDITD) - Unix system (
NIX_SYSTEM) - CrowdStrike Falcon (
CS_EDR)
For a list of all Google Security Operations supported data sources, see Supported default parsers
Configure devices to generate correct log data
For the rules in the Linux Threats category to function as designed, devices must generate log data in the expected format. Configure the following persistent audit rules for the Linux Audit Daemon on each device where you will collect logs and sent to Google Security Operations.
For details about how to implement persistent audit rules for the Linux Audit Daemon, see documentation specific to the operating system.
# Inserts the machine hostname into each log event
name_format = hostname
# Process creation (32 and 64-bit)
-a exit,always -F arch=b32 -S execve
-a exit,always -F arch=b64 -S execve
# Persistence: Cron
-w /etc/cron.allow -p wa -k cron
-w /etc/cron.d/ -p wa -k cron
-w /etc/cron.daily/ -p wa -k cron
-w /etc/cron.deny -p wa -k cron
-w /etc/cron.hourly/ -p wa -k cron
-w /etc/cron.monthly/ -p wa -k cron
-w /etc/cron.weekly/ -p wa -k cron
-w /etc/crontab -p wa -k cron
-w /var/spool/cron/ -p wa -k cron
# Persistence: System Startup
-w /etc/init/ -p wa -k init
-w /etc/init.d/ -p wa -k init
-w /etc/inittab -p wa -k init
# Persistence: Systemd Units and Generators
-w /etc/systemd/user -p wa -k systemd
-w /usr/lib/systemd/user -p wa -k systemd
-w /var/lib/systemd/linger -p wa -k systemd
-w /root/.config/systemd/user -pa wa -k systemd
-w /etc/systemd/system -p wa -k systemd
-w /usr/lib/systemd/system -p wa -k systemd
-w /run/systemd/system-generators -p wa -k systemd
-w /etc/systemd/system-generators -p wa -k systemd
-w /usr/local/lib/systemd/system-generators -p wa -k systemd
-w /usr/lib/systemd/system-generators -p wa -k systemd
-w /run/systemd/user-generators -pa wa -k systemd
-w /etc/systemd/user-generators -pa wa -k systemd
-w /usr/local/lib/systemd/user-generators -pa wa -k systemd
-w /usr/lib/systemd/user-generators -pa wa -k systemd
# Persistence: IAM
-w /etc/group -p wa -k iam_etcgroup
-w /etc/passwd -p wa -k iam_etcpasswd
-w /etc/gshadow -k iam_etcgroup
-w /etc/shadow -k iam_etcpasswd
-w /etc/sudoers -p wa -k iam_sudoers
-w /etc/sudoers.d/ -p wa -k iam_sudoers_d
-w /usr/bin/passwd -p x -k iam_passwd
-w /usr/sbin/groupadd -p x -k iam_groupmod
-w /usr/sbin/groupmod -p x -k iam_groupmod
-w /usr/sbin/addgroup -p x -k iam_groupmod
-w /usr/sbin/useradd -p x -k iam_usermod
-w /usr/sbin/userdel -p x -k iam_usermod
-w /usr/sbin/usermod -p x -k iam_usermod
-w /usr/sbin/adduser -p x -k iam_usermod
# Privilege Escalation
-w /bin/su -p x -k privesc
-w /usr/bin/sudo -p x -k privesc
# Persistence: Libraries
-w /etc/ld.so.conf -p wa -k libmod
-w /etc/ld.so.conf.d -p wa -k libmod
-w /etc/ld.so.preload -p wa -k libmod
# Persistence: PAM
-w /etc/pam.d/ -p wa -k pam
-w /etc/security/ -p wa -k pam
# Persistence: SSH
-w /etc/ssh/ -p wa -k sshconfig
-w /root/.ssh/ -p wa -k sshconfig
# Persistence: Shell Configuration
-w /etc/bashrc -p wa -k shellconfig
-w /etc/csh.cshrc -p wa -k shellconfig
-w /etc/csh.login -p wa -k shellconfig
-w /etc/fish/ -p wa -k shellconfig
-w /etc/profile -p wa -k shellconfig
-w /etc/profile.d/ -p wa -k shellconfig
-w /etc/shells -p wa -k shellconfig
-w /etc/zsh/ -p wa -k shellconfig
# Injection
-a always,exit -F arch=b32 -S ptrace
-a always,exit -F arch=b64 -S ptrace
# Failed Access Attempts
-a always,exit -F arch=b64 -S open -F dir=/bin -F success=0 -k file_err
-a always,exit -F arch=b64 -S open -F dir=/etc -F success=0 -k file_err
-a always,exit -F arch=b64 -S open -F dir=/home -F success=0 -k file_err
-a always,exit -F arch=b64 -S open -F dir=/sbin -F success=0 -k file_err
-a always,exit -F arch=b64 -S open -F dir=/srv -F success=0 -k file_err
-a always,exit -F arch=b64 -S open -F dir=/usr/bin -F success=0 -k file_err
-a always,exit -F arch=b64 -S open -F dir=/usr/sbin -F success=0 -k file_err
-a always,exit -F arch=b64 -S open -F dir=/var -F success=0 -k file_err
# Network connections
-a always,exit -F arch=b64 -S connect -F a2=16 -F success=1 -k net_v4
-a always,exit -F arch=b32 -S connect -F a2=16 -F success=1 -k net_v4
-a always,exit -F arch=b64 -S connect -F a2=28 -F success=1 -k net_v6
-a always,exit -F arch=b32 -S connect -F a2=28 -F success=1 -k net_v6
-a always,exit -F arch=b32 -S socket -F a0=2 -k sock_v4
-a always,exit -F arch=b64 -S socket -F a0=2 -k sock_v4
-a always,exit -F arch=b32 -S socket -F a0=10 -k sock_v6
-a always,exit -F arch=b64 -S socket -F a0=10 -k sock_v6
Tuning alerts returned by Linux Threats category
You can reduce the number of detections a rule or rule set generates using rule exclusions.
In the rule exclusion, you define the criteria of a UDM event that excludes the event from being evaluated by the rule set.
Create one or more rule exclusions to identify criteria in a UDM event that exclude the event from being evaluated by this rule set or by specific rules in the rule set. See Configure rule exclusions for information about how to do this.
For example, you might exclude events based on the following UDM fields:
principal.hostnametarget.user.userid