Unveiling sedexp: A Stealthy Linux Malware Exploiting udev Rules

The sedexp malware begins its attack by exploiting udev rules to maintain persistence on a Linux system. This allows the malware to execute malicious scripts whenever specific device events occur, such as when the /dev/random device is loaded. BlueRock's Container Drift Protection (Binaries & Scripts) can mitigate this by preventing unauthorized executables and scripts from running, ensuring that only binaries present in the original container image are executed. The malware also provides reverse shell capabilities, allowing attackers to maintain control over the compromised system. BlueRock's Reverse Shell Protection effectively counters this by blocking unauthorized attempts to bind shell input and output streams to network sockets, thus preventing reverse shell attacks. Additionally, the malware's potential to escape from a containerized environment is mitigated by BlueRock's Container Capability Control, which restricts container capabilities to prevent actions that could lead to container escapes, such as mounting the host filesystem or executing privileged commands. These mechanisms collectively enhance the security posture against the sophisticated tactics employed by sedexp.

• T1547.010: Boot or Logon Autostart Execution: Port Monitors: The initial compromise of the system is not explicitly described, but the article implies that the malware was able to get onto the system. This could have been through various means, but since it's not detailed, we start with the first clear technique: the malware achieving persistence through udev rules. 'Sedexp utilizes udev rules to maintain persistence.'
• T1053.005: Scheduled Task/Job: Scheduled Task: The udev rule ensures that the malware is run whenever /dev/random is loaded, which happens on every system reboot. 'This rule ensures that the malware is run whenever /dev/random is loaded. /dev/random is a special file that serves as a random number generator, used by various system processes and applications to obtain entropy for cryptographic operations, secure communications, and other functions requiring randomness.'
• T1219: Remote Access Software: The malware includes a reverse shell capability, allowing the attacker to maintain control over the compromised system. 'Reverse Shell Capability: It includes a reverse shell, allowing the threat actor to maintain control over the compromised system.'
• T1564.001: Hide Artifacts: Hidden Files and Directories: The malware modifies memory to hide any file containing the string 'sedexp' from commands like ls or find. 'Memory Modification for Stealth: The malware modifies memory to hide any file containing the string "sedexp" from commands like ls or find.'
• T1036.004: Masquerading: Masquerade Task or Service: The malware manipulates arguments to obfuscate its presence and changes the process name to blend in with legitimate system processes. 'Memory Allocation and Argument Handling: The malware manipulates arguments to obfuscate its presence. It changes the process name to kdevtmpfs using prctl to blend in with legitimate system processes.'
• T1547.010: Boot or Logon Autostart Execution: Port Monitors: The malware sets up persistence by copying itself to a specific location and creating a udev rule. 'Persistence Setup: The malware sets up persistence by copying itself to a specific location and creating a udev rule.'
• T1110.001: Brute Force: Password Guessing: The malware was used to hide credit card scraping code on a webserver, indicating a focus on financial gain. 'Credit Card Scraping: The malware was used to hide credit card scraping code on a webserver, indicating a focus on financial gain.'
• T1611: Escape to Host: The malware could theoretically be used to escape outside of a containerized workload.

F1: Initial compromise, installation, persistence establishment, and basic stealth implementation by the sedexp malware.

• Attacker gains initial access to the target Linux system (Method not specified in text, assumed prerequisite).
• The sedexp malware binary is executed on the compromised system.
  • BR-54: Container Drift Protection (Binaries & Scripts) - This mechanism is applicable because if the malware binary sedexp was introduced after the container image was loaded (i.e., not part of the original image), BR-54 would detect this drift and block the execution attempt within the container.
  • BR-62: Linux/Host Drift Protection - This mechanism is applicable because if the malware binary was added to the host filesystem after boot and outside of a trusted package manager, BR-62 would detect this drift and block its execution on the host.
  • BR-88: Process Path Exec Allow - This mechanism is applicable because if the malware binary is executed from a filesystem path (e.g., /tmp, a user's home directory) that is not included in the configured allow list, BR-88 would intercept the exec() call and block the execution.
  • BR-90: Process Exec Deny - This mechanism is applicable if the malware binary's name coincidentally matches a pattern on the deny list (e.g., if it ended in /nc, /wget, or /curl as per the default deny list mentioned in BR-90 description, although unlikely for initial execution). It would block execution based on the name suffix.
• The malware determines its own execution path using readlink("/proc/self/exe", ...).
• The malware copies itself to a location under /lib/udev/, using its original base filename (e.g., /lib/udev/asedexpb). (Cited from: "snprintf(newpath, sizeof(newpath), "/lib/udev/%s", basename(buffer)); system("cp -f %s %s && sync", buffer, new_path);")
  • BR-75: Critical Directory Write Protection - This mechanism is applicable because if /lib/udev/ is configured as a critical directory protected against writes by any process, this mechanism would block the cp command (executed via system()) from writing the malware binary into that directory.
  • BR-52: Data Resource Mandatory Access Control - This mechanism is applicable because if /lib/udev/ is configured as a critical data directory, BR-52 enforces an allow-list of binaries permitted to access it. If the process executing the cp command (or the malware process itself) is not on this allow-list, the write operation would be blocked.
• The malware constructs a path for a new udev rule file in /etc/udev/rules.d/ using its base filename (e.g., /etc/udev/rules.d/99-asedexpb.rules). (Cited from: "snprintf(rulepath, sizeof(rulepath), "/etc/udev/rules.d/99-%s.rules", basename(buffer));")
• The malware creates and writes a udev rule to this file, configured to trigger on the addition (ACTION=="add") of the device with MAJOR=="1" and MINOR=="8" (corresponding to /dev/random). (Cited from: "FILE *rulefile = fopen(rulepath, "w+");", "fprintf(rulefile, "ACTION==\"add\", ENV{MAJOR}==\"1\", ENV{MINOR}==\"8\", RUN+=\"%s %s:+\"\n", newpath, "run");", "ENV{MINOR}=="8": This condition checks if the device's minor number is 8, which corresponds to /dev/random for major number 1.")
  • BR-75: Critical Directory Write Protection - This mechanism is applicable because if /etc/udev/rules.d/ is configured as a critical directory protected against writes by any process, this mechanism would block the malware's attempt to create or write to the .rules file.
  • BR-52: Data Resource Mandatory Access Control - This mechanism is applicable because if /etc/udev/rules.d/ is configured as a critical data directory, BR-52 enforces an allow-list of binaries permitted to access it. If the malware process attempting the write (fopen, fprintf) is not on this allow-list, the write operation would be blocked.
• The RUN+= action in the udev rule is set to execute the copied malware binary (e.g., /lib/udev/asedexpb) with the argument run:+. (Cited from: "RUN+=\"%s %s:+\"\n", new_path, "run");")
• The malware manipulates its own process arguments in memory, zeroing them out to obfuscate its execution parameters. (Cited from: "memset(arguments[i], 0, strlen(arguments[i]));")
• The malware changes its process name to kdevtmpfs using prctl(PRSETNAME, ...) to blend in with legitimate system processes. (Cited from: "arguments[0] = "kdevtmpfs"; prctl(PRSETNAME, "kdevtmpfs", 0, 0, 0);")
• The malware employs memory modification techniques to hide files containing the string sedexp (including its own binary and the created udev rule) from directory listing commands like ls or find. (Cited from: "The malware modifies memory to hide any file containing the string "sedexp" from commands like ls or find.", "this capability was used to conceal ... the udev rule itself.")
  • BR-24: File Operations Protection - This mechanism is applicable because it specifically targets rootkit techniques that modify file operation data structures in the kernel to hide activities (like hiding files). If sedexp modifies file struct members or related pointers to intercept file listing operations, BR-24 would detect this manipulation.
  • BR-35: Kernel Integrity Protection - This mechanism is applicable if the memory modification technique involves patching kernel code sections or read-only data structures (e.g., hooking the syscall table for getdents) to filter file listings. BR-35 protects these regions from unauthorized writes.
  • BR-45: Page Table Protection - This mechanism could potentially apply if the hiding mechanism involves manipulating kernel page tables related to filesystem operations, although this is less direct than modifying file operations structures or kernel code.

​

F2: Activation of sedexp via the udev persistence mechanism and establishment of a reverse shell.

• The system reboots or the /dev/random device is otherwise re-initialized, triggering a udev add event for major 1, minor 8. (Cited from: "It is loaded by the operating system on every reboot, meaning this rule would effectively ensure that the sedexp script is run upon system reboot.", "ACTION=="add", ENV{MAJOR}=="1", ENV{MINOR}=="8"")
• The udev daemon processes the rule file created by the malware (e.g., /etc/udev/rules.d/99-asedexpb.rules).
• The RUN+= directive in the matching rule causes the udev daemon to execute the malware binary (e.g., /lib/udev/asedexpb run:+). (Cited from: "RUN+=\"%s %s:+\"\n", new_path, "run");")
  • BR-54: Container Drift Protection (Binaries & Scripts) - This mechanism is applicable because if the malware binary /lib/udev/asedexpb executed by udev was not part of the original container image, BR-54 would block its execution.
  • BR-62: Linux/Host Drift Protection - This mechanism is applicable because if the malware binary was added to the host filesystem post-boot and outside of a trusted package manager, BR-62 would block its execution by udev.
  • BR-88: Process Path Exec Allow - This mechanism is applicable because if the path /lib/udev/ (or wherever the malware was copied) is not on the execution allow list, BR-88 would block udev from executing the malware.
  • BR-90: Process Exec Deny - This mechanism is applicable if the malware's filename (e.g., asedexpb) matches a denied suffix, blocking its execution by udev.
  • BR-47: Container Capability Control - This mechanism is applicable because if the malware, when executed by udev, requires capabilities (e.g., network access, process manipulation) that are disallowed by the container's capability policy enforced by BR-47, its actions could be restricted or blocked.
• The executed malware instance identifies the run argument (or similar logic based on invocation context).
• The malware initiates its reverse shell capability. (Cited from: "It includes a reverse shell, allowing the threat actor to maintain control over the compromised system.")
• The malware creates a TCP socket (socket(AFINET, SOCKSTREAM, 0)). (Cited from: Code analysis snippet showing socket call)
  • BR-87: Process Socket Deny - This mechanism is applicable because if a policy is configured to deny network socket creation for the malware process (identified by name asedexpb or masqueraded name kdevtmpfs), BR-87 would block the socket() call.
  • BR-47: Container Capability Control - This mechanism is applicable because creating network sockets often requires capabilities like CAPNETRAW or CAPNETBIND_SERVICE. If the container policy enforced by BR-47 denies these capabilities to the malware process, the socket() call could fail.
• The malware attempts to connect (connect(...)) to a hardcoded or configured attacker-controlled IP address and port. (Cited from: Code analysis snippet showing connect call)
  • BR-87: Process Socket Deny - This mechanism is applicable because if socket operations are denied for the malware process, the connect() call would be blocked.
  • BR-47: Container Capability Control - This mechanism is applicable as network connection capabilities might be restricted, preventing the connect() call.
  • BR-55: Reverse Shell Protection - This mechanism is applicable because it monitors for the pattern of shell I/O being bound to network sockets. While the block might occur at the dup2 or execl stage, the connect() call is a prerequisite step in establishing the connection that BR-55 aims to prevent abuse of.
• Upon successful connection, the malware duplicates the socket file descriptor to standard input (STDIN_FILENO), standard output (STDOUT_FILENO), and standard error (STDERR_FILENO) using dup2. (Cited from: Code analysis snippet showing dup2 calls)
  • BR-55: Reverse Shell Protection - This mechanism is directly applicable because it specifically detects and blocks attempts to bind a shell's standard I/O file descriptors (STDIN, STDOUT, STDERR) to network sockets, which is the primary characteristic of a reverse shell setup.
• The malware executes /bin/sh using execl("/bin/sh", "sh", NULL), providing the attacker with a remote shell session over the established socket connection. (Cited from: Code analysis snippet showing execl call)
  • BR-55: Reverse Shell Protection - This mechanism is directly applicable because the execution of a shell (/bin/sh) immediately after binding its I/O to a network socket is the action BR-55 is designed to prevent.
  • BR-88: Process Path Exec Allow - This mechanism is unlikely to block /bin/sh as it's typically in an allowed path (e.g., /bin).
  • BR-54: Container Drift Protection (Binaries & Scripts) - This mechanism is unlikely to block /bin/sh as it's almost always part of the base container image.

​

F3: Observed attack scenario involving sedexp used by a financially motivated actor to conceal credit card scraping activities on a webserver.

• A financially motivated threat actor compromises a webserver. (Cited from: "the malware was employed by a financially motivated threat actor.")
• The actor deploys credit card scraping code onto the webserver (e.g., modifies web application code or server configurations). (Cited from: "The malware was used to hide credit card scraping code on a webserver, indicating a focus on financial gain.")
  • BR-75: Critical Directory Write Protection - This mechanism is applicable if the webserver's application directories or configuration directories where the scraper code is placed are defined as critical and write-protected.
  • BR-52: Data Resource Mandatory Access Control - This mechanism is applicable if the webserver directories are protected by MAC policy and the process used to deploy the scraper code is not on the allow list for write access.
• The actor deploys and executes the sedexp malware, which establishes persistence using the udev rule technique targeting /dev/random. (Cited from: See F1 steps 2-7)
  • BR-54: Container Drift Protection (Binaries & Scripts) - Applicable if on container and binary is new (See F1.2).
  • BR-62: Linux/Host Drift Protection - Applicable if on host and binary is new/unmanaged (See F1.2).
  • BR-88: Process Path Exec Allow - Applicable if executed from disallowed path (See F1.2).
  • BR-75: Critical Directory Write Protection - Applicable to writing binary/rule file to protected dirs (See F1.4, F1.6).
  • BR-52: Data Resource Mandatory Access Control - Applicable to writing binary/rule file if process not allowed (See F1.4, F1.6).
• The sedexp malware uses its memory modification capabilities to hide the presence of the credit card scraping code files. (Cited from: "The malware modifies memory to hide any file containing the string "sedexp" from commands like ls or find." - Extrapolated to hide scraper code based on observed use case)
  • BR-24: File Operations Protection - Applicable if hiding involves modifying file operation structures (See F1.10).
  • BR-35: Kernel Integrity Protection - Applicable if hiding involves patching kernel code/RO data (See F1.10).
  • BR-91: Sensitive File Access - This mechanism is applicable if the scraper code files have paths or names matching configured sensitive patterns. Attempts by ls/find (or the malware's hiding mechanism) to access these files could be alerted or blocked.
• The sedexp malware may also hide modified webserver configuration files (e.g., Apache configuration) related to the scraping activity. (Cited from: "this capability was used to conceal webshells, modified Apache configuration files...")
  • BR-24: File Operations Protection - Applicable if hiding involves modifying file operation structures (See F1.10).
  • BR-35: Kernel Integrity Protection - Applicable if hiding involves patching kernel code/RO data (See F1.10).
  • BR-75: Critical Directory Write Protection - Applicable if the modification of the Apache config file itself was blocked initially.
  • BR-91: Sensitive File Access - Applicable if the Apache configuration file path matches sensitive patterns. Access attempts could be alerted/blocked.
• The malware maintains stealth by masking its process name as kdevtmpfs and hiding its own files and the udev rule. (Cited from: See F1 steps 9-10)
  • BR-24: File Operations Protection - Applicable to file hiding (See F1.10).
  • BR-35: Kernel Integrity Protection - Applicable to file hiding via kernel patching (See F1.10).
• The actor potentially uses the sedexp reverse shell capability (activated on reboot) for ongoing access and management of the scraping operation. (Cited from: See F2 steps)
  • BR-54: Container Drift Protection (Binaries & Scripts) - Applicable if malware execution blocked on activation (See F2.3).
  • BR-62: Linux/Host Drift Protection - Applicable if malware execution blocked on activation (See F2.3).
  • BR-88: Process Path Exec Allow - Applicable if malware execution blocked on activation (See F2.3).
  • BR-47: Container Capability Control - Applicable if needed capabilities are restricted (See F2.3, F2.6, F2.7).
  • BR-87: Process Socket Deny - Applicable if socket creation/connection blocked (See F2.6, F2.7).
  • BR-55: Reverse Shell Protection - Applicable if shell I/O binding is blocked (See F2.7, F2.8, F2.9).