Linux threat landscape

In recent years, threat actors have been developing more mature toolsets for compromising Linux hosts. Linux systems have long been targets for financially motivated threats, including crypto-mining and spam bots, however ransomware groups are now heavily targeting Linux, and there are a number of remote access trojans and post-exploitation frameworks that have evolved cross-platform support to run on both Windows and Linux.

An example of a cross-platform implant is this one discovered by ESET, which was used to compromise a Hong Kong university in 2021. The malware researchers conclude that the backdoor used in this campaign is a Linux variant of an already-known Windows backdoor, sharing common command and control infrastructure.

"ESET researchers have discovered a Linux variant of the SideWalk backdoor, one of the multiple custom implants used by the SparklingGoblin APT group. This variant was deployed against a Hong Kong university in February 2021 ..."

"While the group targets mostly East and Southeast Asia, we have also seen SparklingGoblin targeting a broad range of organizations and verticals around the world, with a particular focus on the academic sector."

"SparklingGoblin first compromised this particular university in May 2020, and we first detected the Linux variant of SideWalk in that university’s network in February 2021. The group continuously targeted this organization over a long period of time, successfully compromising multiple key servers, including a print server, an email server, and a server used to manage student schedules and course registrations."

It is common for universities to run critical applications on Linux, including application and database servers. Linux servers are often compromised by threat actors exploiting network services, with persistence maintained via command and control channels such as web shells, so it is essential to get detailed visibility of activity happening on these assets. One way to do that on Linux is by configuring auditd.

What is auditd?

The Linux audit system provides a way to track security-relevant information on Linux systems. There is a kernel component, which receives system calls from user-space applications and filters them, and a user-space logging tool.

System calls are functions that applications ask the operating system kernel to do, like running a process, reading or writing files, or initiating network connections.

The audit daemon (auditd) is a user-space tool that receives information from the kernel and logs these events to a file.

There is a long list of event (record) types that can be logged by auditd.

A subset of these event types that provide relevant security information for detecting threats include:

Reference: https://izyknows.medium.com/linux-auditd-for-threat-detection-d06c8b941505

To configure Linux audit logging, you need to define an audit rules file to tell the daemon what to log. The above reference contains information on how to write a rules file, with several links to examples including:

• The built-in examples
• A ruleset with tags mapped to MITRE ATT&CK (matrix shown below)
• Florian Roth's Best Practice Auditd Configuration

The OpenSCAP project provides highly detailed auditd configuration guidance for organisations to meet CIS and Essential 8 compliance. The following links include documented rules, as well as bash and ansible scripts to automate configuration and compliance checking:

• OpenSCAP Essential 8 auditing
• OpenSCAP CIS level 2 auditing

Configuring auditd event logging

Auditd has two configuration items: a rules file, and a configuration file for the audit daemon itself. Some sample rulesets are provided above, and an explanation of the daemon configuration parameters can also be found on the izyknows medium page.

To activate a ruleset and configure events to be logged centrally using syslog, follow these steps (documentation is for IBM Qradar but applicable for RHEL systems and any remote syslog service):

1. Install the audit package and configure the auditd service to start on boot
2. Configure the rules file as required, using the above example rule configuration guides. Test the configuration on a set of hosts to determine performance impacts and event volume
3. Configure auditd to log events to syslog by enabling syslog output
4. Configure rsyslog to forward the auditd events to the Log Collector Appliance (LCA)