perfctl: A Stealthy Malware Targeting Millions of Linux Servers

The attack initiated with the exploitation of a vulnerability in RocketMQ, allowing unauthorized command execution to gain initial access. BlueRock's Container Drift Protection (Binaries & Scripts) effectively mitigates this by preventing unauthorized executables and scripts from running, ensuring that only pre-approved binaries are executed. Once inside, the malware downloaded its main payload, which was then copied to a new location in the '/tmp' directory, a behavior characteristic of process masquerading. BlueRock's Linux/Host Drift Protection would detect such unauthorized changes to the system's file structure, alerting administrators to potential threats. The malware also employed rootkits to hide its presence and maintain persistence. BlueRock's Reverse Shell Protection prevents unauthorized attempts to bind shell input and output streams to network sockets, thereby blocking the malware's efforts to establish a backdoor for remote access. By leveraging these mechanisms, BlueRock provides comprehensive protection against the sophisticated tactics employed by the perfctl malware, ensuring system integrity and security.

• T1190: Exploit Public-Facing Application: The attack began with the exploitation of a vulnerability in RocketMQ (CVE-2023-33246), which allowed unauthorized command execution. This facilitated the initial access to the system.
• T1105: Ingress Tool Transfer: The malware then downloaded the main payload from an HTTP server controlled by the attacker, which is indicative of the use of a malicious download for initial infection.
• T1055.012: Process Injection: Process Hollowing: After downloading, the malware copied itself from memory to a new location in the '/tmp' directory, terminated the original process, and deleted the initial binary to cover its tracks. This behavior is characteristic of process injection and process masquerading.
• T1014: Rootkit: The malware employed rootkits to hide its presence, modifying the behavior of authentication mechanisms and preventing the recording of network traffic. This indicates the use of kernel module and user land rootkits.
• T1547.001: Boot or Logon Autostart Execution: Registry Run Keys / Startup Folder: To maintain persistence, the malware modified the ~/.profile script to execute itself during user login and copied itself to multiple locations with deceptive names.
• T1573.001: Encrypted Channel: Symmetric Cryptography: The malware utilized a Unix socket for internal communication and TOR for external communication, indicating the use of encrypted channels to evade network defenses.
• T1068: Exploitation for Privilege Escalation: For privilege escalation, the malware attempted to exploit the Polkit vulnerability (CVE-2021-4034).
• T1496: Resource Hijacking: The malware dropped a cryptominer and proxy-jacking software, indicating resource hijacking and unauthorized use of system resources.
• T1219: Remote Access Software: The malware opened a backdoor on the server and listened for TOR communications, which is indicative of the creation of a remote access tool (RAT).
• T1070.004: Indicator Removal: File Deletion: The malware deleted its binary after execution to avoid detection, which is a technique for defense evasion.
• T1071.001: Application Layer Protocol: Web Protocols: The malware used environment variables to store data that further affected its execution and behavior, showing an attempt to maintain persistence and evade detection.
• T1562.001: Impair Defenses: Disable or Modify Tools: The malware employed various methods to detect and terminate any competing malware, ensuring it maintained control over the infected system.
• T1027: Obfuscated Files or Information: The attacker utilized packed, stripped, and encrypted binaries to bypass defense mechanisms and hinder reverse engineering attempts.
• T1562.001: Impair Defenses: Disable or Modify Tools: The malware monitored for new user logins and suspended its activity to avoid detection, indicating the use of evasion techniques based on user activity.

F1: Initial compromise via vulnerability/misconfiguration, payload download, and process masquerading.

• Attacker exploits a known vulnerability (e.g., CVE-2023-33246 in RocketMQ) or one of over 20,000 targeted misconfigurations to gain initial access to the Linux server. (Cited from: "After exploiting a vulnerability (as in our case) or a misconfiguration", "actively sought more than 20,000 types of misconfigurations", "initial access was gained via this vulnerability (CVE-2023-33246)")
  • BR-48: Java Deserialization Protection - This mechanism is applicable if the RocketMQ vulnerability (or similar exploited service) involves Java deserialization from the network leading to OS command execution. It prevents the deserialized object from executing system-native binaries.
  • BR-70: Back-Link Directory Traversal - This mechanism is applicable if the initial access vector involves a directory traversal attack against a web application or service (like potentially exploiting misconfigurations). It blocks file IO attempts outside allowed paths when network input contains traversal patterns.
  • BR-74: Java OS Command Injection Prevention - This mechanism is applicable if the exploited vulnerability (like in RocketMQ) allows injecting OS commands directly through a Java application. It monitors the Java runtime and blocks attempts to execute system-native binaries.
  • BR-76: Python Deserialization Protection - This mechanism is applicable if the exploited vulnerability involves Python deserialization leading to OS command execution. It restricts deserialized objects from executing system-native binaries.
  • BR-77: Python OS Command Injection Prevention - This mechanism is applicable if the exploited vulnerability allows injecting OS commands directly through a Python application. It monitors the Python runtime and blocks attempts to execute system-native binaries.
  • BR-87: Process Socket Deny - This mechanism is applicable if the exploited service is a process that should not normally be making outbound connections or accepting unexpected inbound ones. A policy could deny socket operations for the vulnerable service process, potentially blocking exploit delivery or C2 setup.
  • BR-91: Sensitive File Access - This mechanism is applicable if the misconfiguration exploited involves reading sensitive files (e.g., config files with credentials). It can alert on or block access attempts to predefined sensitive files.
• Attacker downloads the initial shell script payload (rconf in the example) from an attacker-controlled HTTP server (e.g., 46.101.139.173, 104.183.100.189, 198.211.126.180). (Cited from: "the main payload is downloaded from an HTTP server controlled by the attacker", "led to download and execution of the shell script rconf", "We saw 3 download servers involved in these attacks (46.101.139.173, 104.183.100.189 and 198.211.126.180)")
  • BR-80: Tainted File Download Protection - This mechanism is applicable because it monitors network activity for specific processes (like curl/wget, which might be used here) downloading executable code (like the rconf script) and blocks subsequent execution.
  • BR-87: Process Socket Deny - This mechanism is applicable if the process initiating the download (e.g., the exploited RocketMQ process) is not on the allow list for making outbound network connections.
  • BR-90: Process Exec Deny - This mechanism is applicable if the download is performed using wget or curl (or nc), as these are blocked by default suffix matching. It prevents the execution of these specific tools.
  • BR-88: Process Path Exec Allow - This mechanism is applicable if the download tool (wget, curl, or a custom binary) is executed from a path not on the allow list (e.g., downloaded to /tmp). It would block the execution of the download tool itself.
• The rconf script executes, performing checks: verifies x86_64 architecture, ensures /tmp is writable and executable (remounting with exec if needed), creates directories (/tmp/.xdiag, /tmp/.awpvt), and sets environment variables (A2ZNODE, VEI). (Cited from: "script continues with a simple if condition, that will ensure that the targeted attacked server OS architecture is x86_64", "verifies that the /tmp directory exists and has read, write, and execute permissions", "If the noexec option is found in the mount options (no execution permissions), it remounts /tmp with the exec option", "creating two directories under /tmp path", "setting the environment variable A2ZNODE to localhost", "setting the environment variable VEI to rmq")
  • BR-54: Container Drift Protection (Binaries & Scripts) - This mechanism is applicable if the rconf script itself is considered drift (not part of the original container image) and execution is attempted within a container. It blocks the execution of unauthorized scripts.
  • BR-62: Linux/Host Drift Protection - This mechanism is applicable if the rconf script was added to the host filesystem outside of a trusted package manager post-boot. It blocks the execution of such drifted files.
  • BR-66: Host FS Mount Control - This mechanism is applicable to the step where the script attempts to remount /tmp with exec permissions. If /tmp is on a host filesystem mount not on the allow list, this could potentially interfere, although it primarily controls mounting new filesystems, not remounting existing ones.
  • BR-75: Critical Directory Write Protection - This mechanism is applicable if /tmp or the parent directory were designated as critical and write-protected by policy. It would block the creation of /tmp/.xdiag and /tmp/.awpvt.
  • BR-88: Process Path Exec Allow - This mechanism is applicable if the interpreter executing the rconf script (e.g., /bin/sh) resides in an allowed path, but the script itself (rconf) is located in a disallowed path (like /tmp if /tmp is not allowed for execution). It would block the exec() call that starts the script.
  • BR-90: Process Exec Deny - This mechanism is applicable if the script was executed via a denied interpreter (unlikely for standard shells but possible if a custom/malicious interpreter matched a deny rule).
• The rconf script uses curl, wget, or a custom function to download the main malware payload (avatar.php in the example) from the attacker's server, requiring a specific user agent to receive the actual malware instead of a decoy file. (Cited from: "uses either curl, wget, or the custom download function", "download the necessary file", "if you use the correct user agent it will drop the malware", "main payload avatar.php was downloaded")
  • BR-80: Tainted File Download Protection - This mechanism is applicable as it monitors downloads by specific processes (curl/wget) containing code (avatar.php which is the malware binary) and blocks subsequent execution.
  • BR-87: Process Socket Deny - This mechanism is applicable because the process running the rconf script (or curl/wget if called directly) needs to make an outbound connection. If this process is not on the socket allow list, the connection is blocked.
  • BR-88: Process Path Exec Allow - This mechanism is applicable if curl or wget are executed from a disallowed path. It would block the execution of these tools.
  • BR-90: Process Exec Deny - This mechanism is applicable as it denies execution of processes ending in /curl or /wget by default, preventing these tools from running to download the payload.
• The downloaded payload (avatar.php) is renamed to httpd. (Cited from: "renamed to httpd")
• The httpd binary is executed. (Cited from: "executed, we can focus on this binary")
  • BR-54: Container Drift Protection (Binaries & Scripts) - This mechanism is applicable if this execution occurs within a container and the httpd binary was not part of the original image. It blocks the execution of unauthorized binaries.
  • BR-62: Linux/Host Drift Protection - This mechanism is applicable if this execution occurs on the host and the httpd binary was added after boot outside a trusted package manager. It blocks the execution of drifted files.
  • BR-88: Process Path Exec Allow - This mechanism is applicable if the httpd binary is located in a filesystem path that is not on the execution allow list (e.g., downloaded to /tmp or a user directory). It blocks the exec() call.
  • BR-90: Process Exec Deny - This mechanism is applicable if the final path component of the httpd binary matches a pattern on the deny list (unlikely for 'httpd' unless explicitly added).
• The executed httpd process copies itself from memory to /tmp, naming the new binary after the process that executed it (e.g., sh if run via shell). It stores the original process ID in /tmp/.apid. (Cited from: "the main payload copies itself from memory to a new location in the ‘/tmp’ directory", "malware chose the name of the process that originally executed it", "In our case the malware was executed by sh, thus the name of the malware was changed from httpd to sh", "It also saves the pid under the /tmp/.apid")
  • BR-75: Critical Directory Write Protection - This mechanism is applicable if /tmp is configured as a critical directory, blocking the write of the new binary (sh) and the PID file (.apid).
  • BR-85: Ephemeral Filesystem Behavior Analysis - This mechanism is applicable as it detects suspicious activity related to memory-backed filesystems like /tmp (often tmpfs), including script/binary execution from such locations. Writing and preparing for execution from /tmp could trigger alerts.
  • BR-88: Process Path Exec Allow - This mechanism is applicable because subsequent execution will occur from /tmp. If /tmp is not an allowed execution path, BR-88 will block that future execution step (F1.9).
  • BR-91: Sensitive File Access - This mechanism is applicable if /tmp/.apid (or patterns matching hidden files in /tmp) is added to the sensitive file list. It could alert on or block the creation/writing of this file.
• The original httpd process terminates itself and the initial binary file is deleted. (Cited from: "terminates the original process, and then deletes the initial binary to cover its tracks", "Httpd then stops and deletes itself")
  • BR-24: File Operations Protection - This mechanism is applicable if the deletion involves manipulating file operation structures to hide the deletion, potentially detected as corruption.
  • BR-75: Critical Directory Write Protection - This mechanism is applicable if the initial binary was located in a protected directory (unlikely if just downloaded). It wouldn't prevent termination but could potentially block deletion if the mechanism also covers deletes.
• The masqueraded payload (now named sh in /tmp) continues execution. (Cited from: "The main payload is now executed from the /tmp directory under a different name", "The binary sh (MD5: 656e22c65bf7c04d87b5afbe52b8d800) is an exact copy of httpd. After sh is executed...")
  • BR-54: Container Drift Protection (Binaries & Scripts) - This mechanism is applicable if running in a container. Since the /tmp/sh binary was written after the container started, it's drift, and execution is blocked.
  • BR-62: Linux/Host Drift Protection - This mechanism is applicable if running on the host. Since /tmp/sh was added after boot outside a package manager, its execution is blocked.
  • BR-88: Process Path Exec Allow - This mechanism is applicable because the process is executing from /tmp. If /tmp is not in the execution allow list, the exec() call is blocked.
  • BR-90: Process Exec Deny - This mechanism is applicable if the masqueraded name happens to be nc, wget, or curl (or any other name added to the deny list). It would block execution based on the name suffix.

​

F2: Establishment of persistence, deployment of rootkits, and evasion mechanisms.

• The running malware (sh process) copies itself from memory to multiple locations with deceptive names: /root/.config/cron/perfcc, /usr/bin/perfcc, /usr/lib/libpprocps.so, and /usr/lib/libfsnkdev.so. (Cited from: "The binary sh is also copying itself from memory to various locations, as it saves itself as libpprocps.so and also as /root/.config/cron/perfcc, /usr/bin/perfcc, and /usr/lib/libfsnkdev.so.")
  • BR-75: Critical Directory Write Protection - This mechanism is applicable if /root, /usr/bin, or /usr/lib are configured as critical directories. It would block the writing of these files.
  • BR-91: Sensitive File Access - This mechanism is applicable if specific paths like /root/.config/cron/perfcc or patterns matching /usr/lib/*.so are added to the sensitive list. It could alert or block write attempts.
  • BR-65: Container Host Drift Prevention - This mechanism is applicable if running on the host. It checks if the process writing the file (sh from /tmp) is an allowed privileged container or host process. If not, subsequent execution attempts of the newly written files (perfcc, lib*.so) would be blocked.
  • BR-62: Linux/Host Drift Protection - This mechanism is applicable if running on the host. It marks these files as drift, blocking subsequent execution attempts.
• The malware modifies the ~/.profile script to execute /root/.config/cron/perfcc upon user login, ensuring the malware runs before legitimate workloads. (Cited from: "The attacker modifies the ~/.profile script... designed to execute the malware first", "It checks if /root/.config/cron/perfcc is an executable file, and if so, it runs the malware.")
  • BR-25: Read-Only File Protection - This mechanism is applicable if ~/.profile was somehow marked read-only and the write attempt used a pipe-based technique. It detects and prevents writes to read-only files via pipes.
  • BR-75: Critical Directory Write Protection - This mechanism is applicable if the user's home directory or specifically ~/.profile were configured as critical and write-protected.
  • BR-91: Sensitive File Access - This mechanism is applicable as ~/.profile could be considered a sensitive configuration file. Access attempts (write) could be alerted or blocked.
  • BR-65: Container Host Drift Prevention - This mechanism is applicable if running on the host. It checks if the process modifying .profile (sh from /tmp) is allowed. If not, it might not block the write itself, but subsequent execution based on this modification could be impacted by other drift mechanisms.
• The malware drops a persistence helper binary wizlmsh to /usr/bin, which runs as a service to ensure the main payload remains active. (Cited from: "The binary wizlmsh is dropped to /usr/bin", "It is responsible for the persistence of perfctl malware.")
  • BR-54: Container Drift Protection (Binaries & Scripts) - This mechanism is applicable if in a container, blocking subsequent execution of wizlmsh as it's drifted.
  • BR-62: Linux/Host Drift Protection - This mechanism is applicable if on the host, blocking subsequent execution of wizlmsh as it's drifted.
  • BR-75: Critical Directory Write Protection - This mechanism is applicable if /usr/bin is write-protected.
  • BR-88: Process Path Exec Allow - This mechanism is applicable as subsequent execution of /usr/bin/wizlmsh would be blocked if /usr/bin is not an allowed execution path (highly unlikely, but possible in strict policies).
• The malware drops the main rootkit payload as a shared object file (libgcwrap.so). (Cited from: "drops a rootkit", "The rootkit itself is an ELF 64-bit LSB shared object (.so) file named libgcwrap.so")
  • BR-75: Critical Directory Write Protection - This mechanism is applicable if the drop location (e.g., /usr/lib) is write-protected.
  • BR-89: Library Load Path Allow - This mechanism is applicable at the time of loading. If libgcwrap.so is dropped to a path not on the allowed library load path list (e.g., /tmp), attempts to load it (via LD_PRELOAD) would be blocked.
• The malware uses LD_PRELOAD mechanism, likely by modifying /etc/ld.so.preload, to load the libgcwrap.so rootkit before other libraries. (Cited from: "The rootkit is using LD_PRELOAD to load itself before other libraries.", "Check system logs for modifications to ~/.profile, and /etc/ld.so.preload files.")
  • BR-25: Read-Only File Protection - This mechanism is applicable if /etc/ld.so.preload was read-only and modified via a pipe technique.
  • BR-75: Critical Directory Write Protection - This mechanism is applicable if /etc or /etc/ld.so.preload is write-protected.
  • BR-89: Library Load Path Allow - This mechanism is applicable when a process starts and attempts to load libgcwrap.so due to the LD_PRELOAD instruction. If the path to libgcwrap.so is not allowed, the library load is blocked.
  • BR-91: Sensitive File Access - This mechanism is applicable as /etc/ld.so.preload is a sensitive configuration file. Write attempts can be alerted or blocked.
• The loaded libgcwrap.so rootkit hooks critical functions like pam_authenticate (potentially bypassing authentication or logging credentials) and pcap_loop (to hide malicious network traffic from capture tools). (Cited from: "hooking to Libpam symbols. Specifically, to the function pamauthenticate", "rootkit is also designed to hook Libpcap symbols, specifically to the function pcaploop... used to prevent recording of the malware traffic.")
  • BR-35: Kernel Integrity Protection - This mechanism is applicable if the hooking involves patching kernel code sections or read-only data, although the description mentions hooking library functions (Libpam, Libpcap), which might occur in user space memory. If the rootkit attempts kernel-level modifications to facilitate this, KIP applies.
  • BR-39: Integrity Patch Violation - This mechanism is applicable if the hooking mechanism involves unauthorized patching of the kernel itself to redirect library calls or modify kernel behavior related to PAM or networking.
  • BR-45: Page Table Protection - This mechanism is applicable if the hooking involves manipulating kernel page tables to redirect execution flow for library functions.
  • BR-58: X-Lib Overwrite Supply Chain Defense - This mechanism is applicable as it specifically targets preventing compromised libraries (like the rootkit acting as one) from overwriting the control flow of trusted libraries (like libpam or libpcap). It monitors and validates library calls.
  • BR-94: Netfilter Hook Protection - This mechanism is applicable if the rootkit attempts to manipulate network traffic by inserting malicious hooks into the Netfilter framework (related to pcap_loop's purpose).
• The malware modifies /etc/profile to prepend /bin/.local/bin (or /home/???/.local/bin/) to the system PATH. (Cited from: "malware replaces the /etc/profile so the path will be set on /bin/.local/bin:$PATH", "The malware Perfctl is dropping in the path /home/???/.local/bin/ 4 binaries")
  • BR-25: Read-Only File Protection - This mechanism is applicable if /etc/profile was read-only and modified via a pipe technique.
  • BR-75: Critical Directory Write Protection - This mechanism is applicable if /etc or /etc/profile is write-protected.
  • BR-91: Sensitive File Access - This mechanism is applicable as /etc/profile is a sensitive configuration file. Write attempts can be alerted or blocked.
• The malware drops modified versions of legitimate Linux utilities (ldd, lsof, top, crontab) into the prepended path (/bin/.local/bin/ or similar). These act as user-land rootkits to hide malware processes, files, network connections, or cron jobs when these specific utilities are invoked. (Cited from: "drop a few legitimate utilities such as ldd. These utilities were modified to hide specific attack elements", "In our attacks the malware dropped crontab, lsof, ldd and top.", "These tweaked binaries will hide malicious activities")
  • BR-54: Container Drift Protection (Binaries & Scripts) - This mechanism is applicable if in a container, blocking subsequent execution of these modified utilities as they are drifted.
  • BR-62: Linux/Host Drift Protection - This mechanism is applicable if on the host, blocking subsequent execution of these modified utilities as they are drifted.
  • BR-75: Critical Directory Write Protection - This mechanism is applicable if the target path (/bin/.local/bin or /home/.../.local/bin) is write-protected.
  • BR-88: Process Path Exec Allow - This mechanism is applicable because even though /usr/bin/top might be allowed, if a user executes top and the modified version from /.local/bin/top runs due to PATH precedence, BR-88 would block it if /.local/bin is not an allowed execution path.
  • BR-65: Container Host Drift Prevention - This mechanism is applicable if on the host. It blocks execution of these new files if the writing process was not allow-listed.
• The malware establishes a Unix socket (/tmp/.xdiag/int/.per.s) for internal communication between its components and uses files within /tmp/.xdiag/ for logging and storing operational data (e.g., cp for pathnames, elog for events, tordata for TOR info). (Cited from: "malware opens a Unix socket", "creates two directories under the /tmp directory, and stores data there that influences its operation", "Via /tmp/.xdiag/int/.per.s, it writes logs", "Appendix 6: Unix Socket Communication")
  • BR-55: Reverse Shell Protection - This mechanism might be applicable if the communication over the Unix socket involves interactive shell-like commands between components, although it primarily targets network sockets bound to shell FDs. Its applicability here is less direct.
  • BR-75: Critical Directory Write Protection - This mechanism is applicable if /tmp is write-protected, blocking creation of the socket file and log files.
  • BR-87: Process Socket Deny - This mechanism primarily targets network sockets (TCP/UDP), not typically Unix domain sockets. Unlikely to apply directly.
• The malware implements evasion by suspending activity when a new user login is detected via btmp or utmp files. (Cited from: "suspending its activity when it detects a new user in the btmp or utmp files")
  • BR-91: Sensitive File Access - This mechanism is applicable if btmp or utmp files are added to the sensitive file list. It could alert on the malware reading these files.

​

F3: Payload execution for monetization (cryptomining, proxy-jacking) and command & control communication.

• The malware (sh process or via wizlmsh persistence) drops and executes a packed and encrypted Monero cryptominer (XMRIG). (Cited from: "A cryptominer is also dropped", "In all cases we observed a monero cryptominer (XMRIG) executed", "The cryptominer is also packed and encrypted.")
  • BR-54: Container Drift Protection (Binaries & Scripts) - This mechanism is applicable if in a container, blocking execution of the dropped XMRIG binary.
  • BR-62: Linux/Host Drift Protection - This mechanism is applicable if on the host, blocking execution of the dropped XMRIG binary.
  • BR-75: Critical Directory Write Protection - This mechanism is applicable if the miner is dropped to a write-protected directory.
  • BR-88: Process Path Exec Allow - This mechanism is applicable if the miner is executed from a path not on the allow list (e.g., /tmp).
  • BR-90: Process Exec Deny - This mechanism is applicable if the miner binary name/path matches a deny rule.
• The cryptominer consumes significant CPU resources. (Cited from: "exhausting the server’s CPU resources")
• The cryptominer communicates with mining pools via the TOR network for anonymity. (Cited from: "the cryptomining pools are accessed via TOR.", "Figure 8: Cryptomining traffic")
  • BR-87: Process Socket Deny - This mechanism is applicable by preventing the cryptominer process (XMRIG) from making outbound network connections if it's not on the allow list.
• In some instances, the malware downloads and executes proxy-jacking software. (Cited from: "in some executions, we also observed some proxy-jacking software transferred from a remote server and executed", "in some of the attacks we’ve seen proxy-jacking via various vendors")
  • BR-54: Container Drift Protection (Binaries & Scripts) - This mechanism is applicable if in a container, blocking execution of the downloaded proxy-jacking binary.
  • BR-62: Linux/Host Drift Protection - This mechanism is applicable if on the host, blocking execution of the downloaded proxy-jacking binary.
  • BR-80: Tainted File Download Protection - This mechanism is applicable if the download uses monitored tools (curl/wget) and the software is code, blocking subsequent execution.
  • BR-87: Process Socket Deny - This mechanism is applicable to block the download if the initiating process is not allowed network access.
  • BR-88: Process Path Exec Allow - This mechanism is applicable if the software is executed from a disallowed path.
  • BR-90: Process Exec Deny - This mechanism is applicable if the download uses denied tools (wget/curl) or the proxy-jacking binary matches a deny rule.
• The proxy-jacking software communicates with services like bitping.com, earn.fm, speedshare.app, and repocket.com to sell the compromised server's bandwidth. (Cited from: "We’ve seen the communication with the following domains: bitping.com, earn.fm, speedshare.app, and repocket.com")
  • BR-87: Process Socket Deny - This mechanism is applicable by preventing the proxy-jacking process from making outbound network connections if it's not on the allow list.
• The main malware component (sh) initiates TOR communication to external C2 servers (e.g., 80.67.172.162, 176.10.107.180). (Cited from: "The binary sh is also initiating communication via Tor with few servers", "Figure 10: TOR sessions log")
  • BR-87: Process Socket Deny - This mechanism is applicable by preventing the sh malware process from making outbound TOR connections if it's not on the allow list.
• The malware opens a backdoor listening for incoming TOR communications, potentially allowing direct attacker access. (Cited from: "It opens a backdoor on the server and listens for TOR communications.", "the threat actor utilized one of the malware’s backdoors to access the honeypot")
  • BR-55: Reverse Shell Protection - This mechanism is applicable if the backdoor facilitates an interactive shell session over the TOR connection. It detects shell I/O bound to network sockets and blocks it.
  • BR-87: Process Socket Deny - This mechanism is applicable by preventing the malware process from opening listening sockets (accepting incoming connections) if it's not on the allow list.

​

F4: Attempted privilege escalation using a known vulnerability.

• The main malware payload (sh/httpd) contains an exploit for the Polkit vulnerability CVE-2021-4043. (Cited from: "The malware contains an exploit to CVE-2021-4043")
• The malware attempts to execute the Polkit exploit to gain root privileges on the server. (Cited from: "which it is trying to run in order to gain root privilege on the server.", "It attempts to exploit the Polkit vulnerability (CVE-2021-4043) to escalate privileges.")
  • BR-30: Process Credential Protection - This mechanism is applicable as it detects and prevents unauthorized privilege escalation attempts that try to overwrite or redirect process credentials, which is the goal of the Polkit exploit.
  • BR-31: Privileged Inode Protection - This mechanism is applicable if the Polkit exploit involves modifying SUID/SGID binaries (privileged inodes) to gain root access. It detects unauthorized modifications to security-relevant fields.
  • BR-46: DirtyCred Protection - This mechanism is applicable if the exploit technique resembles DirtyCred (swapping kernel credentials via file operations), although CVE-2021-4043 is typically a command injection vulnerability. If the exploit chain involved such a technique, it would apply.
  • BR-67: Container Root User Control - This mechanism is applicable if running in a container. If the exploit succeeds and tries to start a new process as root (other than PID 1), this mechanism detects and prevents it.
  • BR-78: Host Setuid File Protection - This mechanism is applicable if the exploit attempts to modify a host-owned setuid file from within a container to escalate privileges.
  • BR-54: Container Drift Protection (Binaries & Scripts) - This mechanism is applicable if the exploit involves executing a separate binary/script payload that wasn't in the original image/allowed list.
  • BR-62: Linux/Host Drift Protection - This mechanism is applicable if the exploit involves executing a separate binary/script payload added post-boot.
  • BR-88: Process Path Exec Allow - This mechanism is applicable if the exploit payload is executed from a disallowed path.