Analyzing IranuKit: A modular linux kernel rootkit

While hanging out on the Rootkit Researchers Discord Server, Matheuz discovered an open directory containing some intriguing malware samples. Among these were a bootkit, two kernel modules (dropper.ko and rootkit_loader.ko), and a shared library named systemdInjector.so.

The directory also featured an image containing the message “PWNED BY IranuKit”.

This write-up focuses on the two kernel modules and the shared library to uncover how they operate together, emphasizing stealth, persistence, and modularity.

systemdInjector.so

First things first we will get to analyzing systemdInjector.so. Upon opening it in binary ninja we can see that its job is to load dropper.ko which it assumes is located at /opt/dropper.ko, it does this by calling a function named load_module_from_path which loads a kernel module at a given filepath. load_module_from_path does this by first opening the file to get a file descriptor to it and then making a system call to finit_module with the file descriptor as an argument.

Whats interesting about systemdInjector.so is that it contains placeholders for hooks on SElinux, and also contains a function called init_module which makes a system call to init_module to load a kernel module from memory, however it doesn’t seem to utilize this function anywhere.

systemdInjector.so showed no detections on virustotal.

dropper.ko

dropper.ko’s job is to unpack a binary into /opt/observer and then executes it by calling call_usermodehelper, so I extracted the binary for later analysis.

After executing /opt/observer it then hides its own module, which it does by manipulating the kernel module list.

We can also see that it contains hooks on system calls such as getdents and getdents64 to hide /opt/observer. It also hooks API’s such as tcp4_seq_show to hide network traffic.

We can also see it targets x86_64 systems.

dropper.ko showed 1 detection on virustotal

/opt/observer (extracted)

The binary unpacked into /opt/observer, when executed first popens and pcloses gdm3, honestly I have no clue why it does this, I assume to check if its in a graphical user environment?

After it pcloses gdm3 it then loads in a kernel module located at /opt/rootkit_loader.ko by calling the load_module_from_path function, which works the same as the one we found in systemdInjector.so.

The binary unpacked into /opt/observer showed 1 detection on virustotal

rootkit_loader.ko

rootkit_loader.ko first registers a character device at /dev/rootkit (very stealth XD). Kernel rootkits targeting linux very often utilize character devices as a form of communication between userland processes and the rootkit itself.

We can also see that just like dropper.ko it’s job is to unpack a binary. This time it unpacks the binary into /opt/rootkit which it then executes by calling call_usermodehelper. I then extracted the binary for later analysis.

We can see that rootkit_loader.ko contains very similar hooks as dropper.ko.

rootkit_loader.ko showed 6 detections on virustotal.

/opt/rootkit (extracted)

The binary unpacked into /opt/rootkit starts a new thread in which it will call mmap to allocate a region of memory, then it will write its shellcode into that memory and execute it. In the main thread of the process it will keep attempting to open /dev/rootkit, when successful it kills its own process.

The binary unpacked into /opt/rootkit showed 6 detections on virustotal.

Overall analysis

1. systemdInjector.so loads a kernel module located in /opt/dropper.ko by calling a function named load_module_from_path. load_module_from_path opens the filepath of the kernel module to get a file descriptor to it, then it makes a system call to finit_module with the file descriptor as an argument to load the kernel module.

2. dropper.ko unpacks a binary into /opt/observer, then executes it, then hides itself by manipulating the module list. From analysing dropper.ko we can see it contains hooks for system calls such as getdents and getdents64 to hide /opt/observer and API’s such as tcp4_seq_show to hide network traffic.

3. the executed binary at /opt/observer popens and then pcloses gdm3 (not very sure why, maybe to check if its in a graphical user environment?), It then loads /opt/rootkit_loader.ko by calling the function named load_module_from_path, this function works the same as the one in systemdInjector.so.

4. rootkit_loader.ko registers a character device at /dev/rootkit. Then it writes a binary into /opt/rootkit and executes it. From analysing rootkit_loader.ko we can see it contains very similar hooks to dropper.ko.

5. the executed binary at /opt/rootkit then starts a new thread where it allocates a region of memory by calling mmap, writes its shellcode to that region of memory and executes it. also we can see from our analysis that it will keep attempting to open /dev/rootkit, and when it has successfully opened and got a valid file descriptor for the character device it will kill its own process.

Conclusion

In conclusion, IranuKit is a very modular kernel rootkit targetting x86_64 linux systems and has several different components which work together to achieve stealth and persistence. Given its modular nature and the fact that some components, like systemdInjector.so’s hooks on SELinux, are placeholders, it suggests that IranuKit is still under development.

If you enjoyed this then make sure to check out Matheuz’s github to learn more about linux-based malware and join the rootkit researchers discord server Rootkit Researchers where we discuss and share insights in developing aswell as detecting and analyzing malware.