Reptile 2.0 Rootkit Introduces New Kernel Loading Method
/ 4 min read
Quick take - The Reptile version 2.0 rootkit employs a custom launcher to load kernel-level components without using traditional methods, incorporating advanced encryption and evasion techniques that complicate detection while still allowing for potential monitoring through syscall auditing.
Fast Facts
- The Reptile version 2.0 rootkit uses a custom launcher to load kernel components, bypassing the traditional
insmod
command. - UNC3886, a cyber threat group, has been observed utilizing this custom launcher, which includes a function for daemonizing processes.
- A random 32-bit hexadecimal value is generated during kernel module compilation, serving as an encryption key that complicates detection efforts.
- The custom loader decrypts the kernel object using a bitwise XOR operation and a bit rotation function, allowing for programmatic insertion into the Linux kernel.
- Despite advanced evasion techniques, monitoring syscalls with tools like Auditd_manager can help detect malicious kernel module loading and identify potential security breaches.
Reptile Version 2.0 Rootkit: New Methods for Kernel-Level Components
Introduction of Custom Launcher
The Reptile version 2.0 rootkit has introduced a new method for loading kernel-level components, moving away from the traditional insmod
command. This development involves a custom launcher specifically created for this purpose. Mandiant has observed that this custom launcher has been utilized by the cyber threat group UNC3886. The group has incorporated a new function aimed at daemonizing processes.
Key Features and Functionality
A key feature of the Reptile rootkit is its ability to bypass standard Linux commands used for loading kernel modules. During the compilation of the kernel module, a random 32-bit hexadecimal value is generated. This value serves as an encryption key for the Reptile kernel object, complicating the identification of the module through conventional hash searches or hex value searches on the filesystem. The encrypted kernel module is stored in a designated location.
The custom loader is defined within a source file titled loader.c
. The core operation of the custom launcher involves decrypting the kernel object, transferring the decrypted object to an appropriate location, and subsequently loading it into the kernel. The decryption process uses a function that executes a bitwise XOR operation, complemented by a custom bit rotation function that enhances obfuscation. This function shifts bits in a 32-bit integer. Once decrypted, the kernel module is loaded using the system call, circumventing the standard init_module()
command.
Key parameters for the init_module
system call include the compiled kernel module code, module image size, and initialization parameters. A macro is defined within the Reptile rootkit to streamline this process, facilitating direct interaction with the syscall and avoiding traditional C library functions, thus providing an additional layer of evasion.
Detection and Security Implications
Despite these advanced methods of evasion, detection of the malicious kernel module loading is still possible. Auditd_manager rules can monitor syscalls employed for loading kernel modules, enhancing the ability to identify the loading of harmful kernel modules on servers. The introduction of a malicious kernel module can result in a tainted kernel, marked with flags that signify potential security issues. These flags indicate conditions that may compromise the kernel’s stability or functionality, including the loading of proprietary (non-GPL) modules, unsupported modules, and modules with incompatible licensing.
Critical errors or bugs within the kernel can also result in tainting. Tainted kernel flags play a crucial role in diagnosing and troubleshooting kernel issues, facilitating the identification of potential security breaches. Tracing the origin of a loaded kernel module presents its own challenges, necessitating the examination of various artifacts, such as the .bash_history
of the root user, and conducting filesystem searches for kernel files with the .ko
extension. Enabling auditing measures can significantly enhance the capacity to track kernel module loads, providing a more robust defense against the threats posed by sophisticated rootkits like Reptile version 2.0.
Original Source: Read the Full Article Here