Security - Rootkit

What is a Rootkit?

A Rootkit is a type of malicious software designed to give an attacker privileged access ("root" access) to a computer while actively hiding its presence from administrators and antivirus software.

If a standard virus is a burglar smashing a window, a Rootkit is a burglar who breaks in, steals your jewelry, replaces it with fake jewelry so you don't notice, and then hacks your security cameras to loop footage of an empty room.

1. The Core Function: Stealth

The defining characteristic of a rootkit is not destruction, but deception. When you ask the computer a question, the rootkit intercepts the answer and lies to you.

You run ls (list files): The rootkit intercepts the request, looks at the list of files, deletes its own filenames from the list, and passes the "clean" list to you.
You run Task Manager (top): The rootkit modifies the process list to remove the entry for its bitcoin miner or spyware.
You check Network Connections (netstat): The rootkit hides the open connection sending your data to Russia/China.

2. How They Work (The "Hook")

Rootkits typically rely on a technique called Hooking.

Imagine the Operating System as a switchboard operator. When an application needs to do something (open a file, start a process), it calls the kernel.

Normal: App -> Kernel -> Hardware.
Rootkit: App -> Rootkit (Filter) -> Kernel -> Hardware.

The rootkit places itself in the middle of the execution flow. This allows it to modify the data coming back to the user.

3. The Types of Rootkits (Levels of Depth)

Rootkits are categorized by how deep into the system they bury themselves.

A. User-Mode Rootkits (Ring 3)

How: These replace standard system executable files (binaries) or libraries (DLLs/.so files).
Example: Replacing the ls or ps command on Linux with a modified version that knows not to show the hacker's files.
Detection: Relatively easy. File integrity checkers (like Tripwire) can see that the file size or hash has changed.

B. Kernel-Mode Rootkits (Ring 0)

How: These load directly into the operating system kernel (usually as a driver or kernel module).
Danger: Because they run with the same privileges as the OS itself, they are incredibly dangerous and hard to detect. If the kernel is lying, you cannot trust anything the computer tells you.
Connection to your previous questions: These rootkits often use Kprobes or BPF techniques to hook system calls without modifying the file system, making them memory-resident and very stealthy.

C. Bootkits / Firmware Rootkits

How: These infect the Master Boot Record (MBR), the UEFI/BIOS, or even the firmware of your hardware (like your network card or hard drive controller).
Danger: They load before the Operating System starts. Even if you wipe your hard drive and reinstall Windows or Linux, the rootkit survives because it lives on the motherboard or the drive's controller chip.

D. Hypervisor Rootkits (The "Blue Pill")

How: The rootkit installs a lightweight virtual machine monitor (Hypervisor) and then moves your entire running Operating System inside a virtual machine.
Danger: Your OS thinks it is running on real hardware, but it is actually living inside a simulation controlled by the rootkit.

4. The eBPF Rootkit (The Modern Threat)

eBPF is now a popular vector for modern rootkits.

Old School: Attackers had to write complex kernel modules (LKM) which could crash the system (Kernel Panic), alerting the admin.
New School: Attackers use eBPF programs.
- They are "safe" (won't crash the kernel).
- They are designed to trace/monitor data (perfect for spying).
- They can modify network packets or system call arguments on the fly.
- Example: An eBPF rootkit can hook the sys_getdents64 system call (used to list directory contents) and filter out specific filenames before the user sees them.

5. How do you detect/remove them?

If you suspect a kernel-mode rootkit, you cannot trust the infected machine to diagnose itself.

Memory Forensics: Taking a snapshot of the RAM and analyzing it on a different computer (using tools like Volatility).
Live Boot: Booting from a "clean" USB stick (trusted OS). Since the rootkit isn't running, you can scan the hard drive and see the hidden files.
Secure Boot: This feature in modern UEFI prevents the computer from loading drivers or kernels that haven't been digitally signed by a trusted vendor (like Microsoft or RedHat).

The Golden Rule: If a computer is confirmed to have a rootkit, the only safe solution is to "Nuke it from Orbit." Wipe the drive completely, flash the BIOS/Firmware, and reinstall from scratch. You can rarely "clean" a rootkit 100%.

Kernel Rootkit vs User-land Rootkit

It comes down to where it lives and how much power it has.

User-land Rootkit: An intruder who modifies regular programs to hide their presence. They are operating at the same privilege level as you or your applications.
Kernel Rootkit: An intruder who modifies the core of the operating system itself. They are operating at the highest possible privilege level, becoming part of the "god" of the system.

User-land Rootkit

A user-land rootkit works by tricking the security guards (the system utilities like ls, ps, top, netstat).

The Attack: An attacker gains access to the system and wants to hide their malicious process (evil.exe) and the files they've stored (stolen_data.zip).
The Method: The attacker replaces the legitimate security guards with their own imposters. They will replace the real /bin/ls program with a modified version. They do the same for /bin/ps, netstat, etc.
The Deception:
- Now, when a legitimate administrator logs in and runs the ps command to see all running processes, they are not running the real ps. They are running the attacker's fake ps.
- This fake ps is programmed to show a list of all processes, except for evil.exe.
- Similarly, the fake ls is programmed to list all files in a directory, except for stolen_data.zip.
The Weakness: The deception only works if you trust the guards. A skilled administrator might notice something is wrong. They could:
- Bring in their own, trusted security guard (e.g., upload a statically compiled, clean version of ps). Running this trusted ps would immediately reveal the hidden evil.exe.
- Check the guards' credentials (e.g., run a checksum on the /bin/ps file and compare it to a known-good value). They would immediately see that the file has been altered.

In summary, a user-land rootkit subverts common system utilities to lie to the user about the state of the system.

Kernel Rootkit

A kernel rootkit is far more powerful and insidious. It doesn't bother with the security guards; it corrupts the kernel directly.

The Attack: The attacker gains administrative (root) access and then finds a way to load malicious code directly into the running kernel. This is usually done by loading a malicious kernel module (.ko in Linux, .sys in Windows).
The Method: This malicious code hooks into the very core of the operating system. It intercepts the fundamental "system calls" that all programs (including ls and ps) must use to get information from the kernel.
The Deception:
- Now, when the administrator runs the ps command, they are running the real, legitimate /bin/ps program. The security guard is clean.
- The ps program makes a system call to the kernel, asking, "Please give me the list of all running processes."
- This request is intercepted by the attacker's rootkit code running inside the kernel.
- The rootkit gets the true list of processes from the kernel's scheduler, removes evil.exe from the list, and then passes the filtered, deceptive list back to the ps program.
- The ps program has no idea it has been lied to. It faithfully prints the deceptive list it received from the "trusted" kernel.
The Strength (Why it's so dangerous):
- Ultimate Stealth: Bringing in your own trusted security guard (a clean ps binary) won't help, because that clean binary will also be lied to by the compromised kernel.
- Complete Control: The rootkit can hide files, processes, network connections, and its own kernel module from view. It can also intercept keyboard strokes, sniff network traffic, and disable security software, all from within the kernel's privileged position.
- Difficult to Detect: Detecting a kernel rootkit is extremely difficult because it controls the very tools you would use to look for it. Detection often requires offline analysis (booting from a clean CD) or specialized tools that look for inconsistencies in the kernel's data structures.

Example: Ebury - A Modern, Sophisticated SSH Backdoor and Credential Stealer

At its core, Ebury is primarily a user-land rootkit, but a very advanced one. Its main goal is not just to hide, but to steal valuable information, specifically SSH credentials, and to provide a persistent backdoor for attackers.

Its target is Linux servers, especially those used by hosting providers and data centers, because compromising one of these servers can give attackers access to thousands of downstream clients.

Here’s a step-by-step explanation of how it works:

1. The Initial Infection Vector

The first step for any attack is getting a foothold on the system. The Ebury operators are known to use several methods:

Compromised Credentials: They might buy stolen SSH usernames and passwords from other criminals on the dark web.
Exploiting Vulnerabilities: They could exploit an unpatched vulnerability in a public-facing service on the server.
Supply Chain Attacks: In some cases, they've been known to compromise the infrastructure of smaller hosting providers to gain access to their customers' servers.

Once they gain initial root access, the real work of the Ebury rootkit begins.

2. The Core of the Attack: Modifying a Critical System Library

Unlike older user-land rootkits that replaced binaries like ls or ps, Ebury uses a much more subtle and effective technique: it modifies a fundamental shared library that many critical programs depend on.

The primary target is often the OpenSSH server daemon (sshd) and related libraries. The attackers will either:

Patch the sshd binary directly: They modify the running SSH server program.
Modify a core system library: A more advanced technique is to modify a library that sshd uses, such as libkeyutils.so. They replace the legitimate library file with their own malicious version.

Why is this so clever? When the operating system starts the SSH server, it automatically loads this malicious library into its memory. The attackers don't need to replace the main sshd program, which makes detection harder. Verifying the checksum of sshd will show that it's clean, but the malicious code is loaded alongside it from the compromised library.

3. The Malicious Logic: How Ebury Steals and Hides

Once the malicious code is running in the memory of the SSH server, it "hooks" into several key functions. This means it intercepts the normal flow of the program to perform its own malicious actions.

A. Credential Stealing (The "What")

Hooking the Authentication Function: The rootkit intercepts the part of the SSH login process where the username and password are checked.
Harvesting Credentials: When a legitimate user (or another attacker) logs into the compromised server using a password, Ebury captures the username and password in plain text just before they are authenticated.
Exfiltration: It then sends these stolen credentials to a Command and Control (C2) server controlled by the attackers. This allows them to expand their network of compromised machines.

B. Backdoor Functionality (The "How")

A Secret Knock: The rootkit adds a secret backdoor. An attacker who knows the special "Ebury password" can log into the server with any username, and the rootkit will grant them access without checking the real system password. This gives them persistent access even if the original compromised account's password is changed.

C. Hiding its Presence (The "Rootkit" Part)

This is where it acts like a classic user-land rootkit, but again, in a more advanced way.

Hiding Network Connections: When an administrator runs netstat or ss to see active network connections, they might see the rootkit communicating with its C2 server. To prevent this, Ebury hooks the system calls related to listing network sockets and filters out its own malicious connections from the results.
Hiding Processes and Files (Less Common for Ebury): While it can hide files, Ebury's main focus is on modifying in-memory processes. Its stealth comes from patching libraries rather than leaving lots of suspicious files on disk.

4. The Broader Operation: A Criminal Enterprise

Ebury is not a standalone tool. It's part of a massive, financially motivated operation often referred to as "Operation Windigo."

The attackers use Ebury to steal SSH credentials from thousands of servers.
They use these stolen credentials to log into other servers, spreading the Ebury infection further.
Once they control a large network of servers (a botnet), they use them for other malicious activities:
- Sending Spam: Using the compromised servers to send millions of spam emails.
- Hosting Malware: Storing malicious files for other malware campaigns.
- Click Fraud: Directing traffic to generate fraudulent ad revenue.

How is Ebury Detected?

Because Ebury is a user-land rootkit (even if advanced), it's not invincible. Detection methods include:

Memory Forensics: Tools like Volatility can analyze a live memory dump of the server and find the hooks and modifications made by Ebury inside the sshd process memory.
Network Monitoring: Detecting suspicious outbound connections from your SSH server to unknown IP addresses on unusual ports.
Specialized Scanners: Security companies like ESET (who did much of the original research on Ebury) have created specific scripts and tools that know exactly which libraries to check and what modifications to look for.
Checking for Shared Memory Segments: Ebury often uses shared memory segments to store the credentials it has stolen. An experienced sysadmin might notice unusual shared memory usage associated with the sshd process.