ATT&CK

Commonly Abused Linux Initial Access Techniques and Detection Strategies

signalblur

signalblur

— 7 min read

The volume and quality of Threat Intelligence for Linux attacks have traditionally lagged behind that for Windows, despite Linux's significant presence. Whats worse, is that most reports have focused on reverse engineering Linux-based malware and attack tools. While valuable, this approach is difficult to translate into actionable detection due to the limited data typically available to detection engineers and security analysts.

When I encounter new Linux malware research, the first thing I typically do is to identify how it was delivered and what the initial form of access was. Unfortunately, finding this information is often quite challenging. New analysts also struggle with this, as Windows malware delivery methods are typically more straightforward, often involving malicious office documents or tricking users into downloading and executing malicious executables and scripts.

As someone who has built and managed multiple Managed Detection and Response (MDR) Security Operations Centers (SOCs), I have conducted numerous large-scale investigations involving Linux systems. Here are some common initial access techniques on Linux and strategies to detect and defend against them.

SSH Brute Forcing

T1110.001 Brute Force: Password Guessing of SSH

Despite it being 2024, many Linux servers still publicly expose SSH without requiring certificate-based authentication, making them vulnerable to brute-force password attacks. When you expose an SSH port to the internet, automated brute force login attempts will start just minutes after it comes online.

Detection

You should detect successful logins using a password after repeated login failures by the same source IP address. Here is an example of an actual auditd USER_AUTH log:

type=USER_AUTH msg=audit(1719624024.063:165): pid=3014 uid=1000 auid=1000 ses=6 subj=unconfined msg='op=PAM:authentication grantors=pam_permit acct="parallels" exe="/usr/bin/sudo" hostname=? addr=? terminal=/dev/pts/2 res=success'

Detecting a log type of USER_AUTH with a value of op=PAM:authentication and res=success indicates successful password-based authentication. Successful key-based logins typically have a value of op=pubkey_auth rather than op=PAM:authentication.

Depending on the organization's maturity and size, it could be valuable to detect any successful password-based login, as it should be disabled in favor of using certificates. This can help mitigate the issue entirely. A recent Cisco Report indicates that SSH brute forcing is on the rise.

Prevention

Use certificate-based SSH authentication to eliminate this issue. It's 2024, get with the times.

Exploiting Public-Facing Applications

T1190 Exploitation of Public-Facing Applications

One common method of gaining access is exploiting an application with a Remote Code Execution (RCE) vulnerability. The internet is rife with automated scanners searching for web applications with known vulnerabilities to gain an initial foothold. Malware families such as Kinsing constantly scan the internet for commonly used applications with remote code execution vulnerabilities they can exploit to execute code on target environments.

According to the Aqua Intel Report:

Scan and exploit servers: The initial server is responsible for scanning vulnerabilities and exploiting them. It boasts advanced scanning capabilities, likely employing tools such as masscan, and possibly has access to server databases such as Zoomeye or Shodan. While the Kinsing malware includes masscan capabilities, there’s no definitive proof that the threat actor actively uses this tool.

While this method is well-known and common, what is less understood by analysts is how it appears from a defender's visibility perspective.

Common Signs of Remote Code Execution on an External Application

Despite RCE vulnerabilities being a well-known method to gain entry to a Linux system, it is surprisingly rare to find individuals who recognize this activity within logs. Even vastly different applications written in various programming languages share common behaviors that can be used as detection mechanisms.

Process Ancestry

One of the clearest signs of exploitation is the relationship between parent and child processes. In most cases, when an application is exploited, that application's process spawns the exploit process. While there are ways around this, the majority of exploitations follow this pattern. Baselining the parent process relationship of your applications is a powerful detection mechanism, even for detecting 0-days.

Detection

In your SIEM or Endpoint Detection and Response (EDR) tooling, look at new process execution (the execve syscall) to see what child processes your application spawns. A simple but powerful detect may be any event where your application spawns an unapproved child process.

It is common for the directories that are readable and writable during initial access to be limited to the root web directory. This means any binary executing out of a web directory that isn't part of your application is likely to be suspicious. This can be done by looking for common web root directories in the file path of new process executions, e.g., /var/www/evil_webshell.

Containers can make this sort of activity easier to detect. Assuming you're following best practices, your container shouldn't change in production since updates and changes should happen within the application build pipeline. Any change to the contents of a container is suspect. Most modern container runtime monitoring tools use a concept known as container "drift," which tracks changes to the contents of the container after it has been deployed, automating this detection.

Let's break down this Sigma Rule:

title: Linux Webshell Indicators
id: 818f7b24-0fba-4c49-a073-8b755573b9c7
status: test
description: Detects suspicious sub processes of web server processes
references:
    - https://www.acunetix.com/blog/articles/web-shells-101-using-php-introduction-web-shells-part-2/
    - https://media.defense.gov/2020/Jun/09/2002313081/-1/-1/0/CSI-DETECT-AND-PREVENT-WEB-SHELL-MALWARE-20200422.PDF
author: Florian Roth (Nextron Systems), Nasreddine Bencherchali (Nextron Systems)
date: 2021/10/15
modified: 2022/12/28
tags:
    - attack.persistence
    - attack.t1505.003
logsource:
    product: linux
    category: process_creation
detection:
    selection_general:
        ParentImage|endswith:
            - '/httpd'
            - '/lighttpd'
            - '/nginx'
            - '/apache2'
            - '/node'
            - '/caddy'
    selection_tomcat:
        ParentCommandLine|contains|all:
            - '/bin/java'
            - 'tomcat'
    selection_websphere:  # ? just guessing
        ParentCommandLine|contains|all:
            - '/bin/java'
            - 'websphere'
    sub_processes:
        Image|endswith:
            - '/whoami'
            - '/ifconfig'
            - '/ip'
            - '/bin/uname'
            - '/bin/cat'
            - '/bin/crontab'
            - '/hostname'
            - '/iptables'
            - '/netstat'
            - '/pwd'
            - '/route'
    condition: 1 of selection_* and sub_processes
falsepositives:
    - Web applications that invoke Linux command line tools
level: high

This detector can indicate that you may have a Remote Code Execution vulnerability in your Linux Web Application, as executing whoami and some of the other child processes listed are common recon commands used to check for vulnerabilities. It's incredibly rare for an application to need to do this legitimately, so seeing a web server spawning these could be indicative of commands being executed and your application being exploited.

Recently, fellow security researcher Stephan Berger tweeted out an investigation where multiple webshells were found on the same server.

In a recent investigation, a customer contacted us because an AV scanner detected webshells in a web root accessible from the Internet.

Thinking about this as a detection engineer, if a webshell process executes out of a web root directory, it will trigger a new process event, providing an opportunity for detection. This is especially true as it is not common for processes/scripts to execute out of a root directory, making it easy to build an allow list for known safe applications.

Regardless of programming language or vulnerability, detecting this behavior makes exploiting your applications much harder. It may even be worth utilizing the ability to kill a process using modern EDR tooling if a server triggers this rule after the false positives have been safely evaluated and removed.

title: Process Execution From Root Web Directory
id: 3b3d279e-a97a-4c5c-8be0-64b21ead5fa1
description: Detects processes where the executable or image path contains common web root directories to identify potential webshells.
status: experimental
author: David Burkett, @signalblur
tags:
    - attack.t1505.003
date: 2024/06/28
logsource:
    category: process_creation
    product: linux
detection:
    selection:
        Image|contains:
            - '/var/www/'
            - '/usr/share/nginx/'
            - '/srv/http/'
            - '/home/*/public_html/'
            - '/usr/local/nginx/'
    condition: selection
fields:
    - Image
    - CommandLine
falsepositives:
    - System administrators or developers running scripts or commands within web directories for legitimate purposes or as part of an applications functionality.
level: medium

Prevention

Keeping applications up-to-date, especially public-facing applications with known RCE vulnerabilities, goes a long way in preventing exploitation.

Using tools such as AppArmor, SELinux, or seccomp, you can harden an application by limiting the capabilities available to its processes.

Running only the necessary dependencies can make exploitation more difficult. For example, it is harder to exploit a web application running inside a container that lacks tools commonly abused to pull secondary payloads (such as curl or wget). The container itself can be made immutable, preventing any follow-on binaries from being able to write to disk, or it may not even have a bash shell to interact with.

Supply Chain Compromises

T1195 Supply Chain Compromise

Recent supply chain compromises like those involving polyfill and the xz attack have highlighted the growing risks in modern software. These attacks often have a high impact due to the widespread use of compromised libraries/dependencies and their ability to bypass traditional security controls. Attackers inject malicious code into widely used packages, which then propagate to numerous applications and systems, potentially affecting millions of users almost instantly.

Detection

Detecting a supply chain compromise is challenging due to the extensive number of third-party dependencies and libraries used in modern software. The volume and complexity of code in these libraries can be overwhelming for any security team to manage effectively. Most often, detection of such compromises occurs retroactively, after the compromise has been identified and publicized.

However, there are tools and practices that can help in identifying these issues earlier:

  • Vulnerability Scanning Tools: These tools can scan dependencies for known vulnerabilities and alert you to potential issues.
  • Container and CI/CD Tooling: Integrating security checks into your continuous integration and continuous deployment pipelines can help catch vulnerabilities before they reach production.
  • GitHub Security Alerts: For certain programming languages and ecosystems, GitHub can automatically notify you about vulnerabilities in your project's dependencies.

Proactively using these tools can improve your chances of detecting supply chain compromises before they cause significant damage. Additionally, having a good behavioral profile of your application can make detecting anomalous behavior caused by a compromised library easier. Key indicators include:

  • Parent/Child Relationships and Command Line Arguments: Understanding the normal execution patterns of your applications can help identify unusual activity.
  • Network Connectivity: Monitoring typical network connections, such as destination ports or domain names, can highlight deviations that may indicate a compromise.

Prevention

The best way to prevent a software supply chain compromise is to minimize the number of third-party libraries your software uses and reduce dependencies and software running on the underlying infrastructure hosting your application. If the library doesn't exist, it can't be backdoored.

That said, there is a balance to maintain; while ideally, you can create applications using only a programming language's standard library, it may be more secure to use a well-known software framework, especially for handling authentication. If you use a third-party library, apply the "smell test":

  • Popularity: Prefer software with a significant number of downloads (e.g., more than a couple of hundred).
  • Maintenance: Ensure it is maintained by a reputable organization or team, and ideally has been recently updated.
  • Dependencies: Choose libraries that do not introduce too many unnecessary dependencies to your application.

Some organizations may benefit from using tools like Artifactory to limit developers to libraries contained within the organization's Artifactory instance. This allows an organization to stick to well-known, regularly used versions of the software utilized in their applications.

Closing

I hope this post has provided valuable insights into the common initial access techniques used against Linux systems and the corresponding detection strategies. By understanding these methods and implementing the suggested detection and prevention measures, you can significantly enhance the security of your Linux environment. Staying vigilant and continuously updating your security practices is essential to defending against evolving threats. Thank you for reading, and stay secure!

Read more