Overview of Linux Threats category

Supported in:

Google SecOps SIEM

Note: This feature is covered by Pre-GA Offerings Terms of the Google Security Operations Service Specific Terms. Pre-GA features might have limited support, and changes to pre-GA features might not be compatible with other pre-GA versions. For more information, see the Google Security Operations Technical Support Service guidelines and the Google Security Operations Service Specific Terms.

Note: This feature might not be available to all customers in all regions.

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 built-in 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.
• Mandiant Front-Line Threats - This rule set contains rules derived from Mandiant's investigation and response to active incidents across the world. These rules cover commonly seen TTPs such as execution using script interpreters (T1059), use of web services for command and control (T1102), and use of scheduled tasks to maintain persistence (T1053).
• Mandiant Intel Emerging Threats - This rule set contains rules derived from Mandiant Intelligence Campaigns and Significant Events, which cover highly impactful geopolitical and threat activity, as assessed by Mandiant. This activity may include geopolitical conflict, exploitation, phishing, malvertising, ransomware, and supply chain compromises.

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

Fields needed by Linux Threats category

The following section describes specific data needed by rule sets in the Linux Threats category to get the greatest benefit. Make sure that your devices are configured to record the following data to device event logs.

Dataset	UDM field (where data is stored)	Definition
Principal Process Path	principal.process.file.full_path	Location on disk of the current running process, if available.
Principal Process Command Line	principal.process.command_line	Command line parameters of the process, if available.
Target Process Path	target.process.file.full_path	Location on disk of the target process, if available.
Target Process Command Line	target.process.command_line	Command line
Network DNS Query Domain	network.dns.questions.name	Domain name of DNS queries, if available.

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.hostname
• target.user.userid
• principal.process.command_line
• target.domain.name
• target.process.command_line