Scenario

Our work with a newly onboarded client began with an immediate challenge: an active rootkit infection. At the time of our investigation, official documentation from the FBI and NHTCU had not yet been released, which required us to rely entirely on system forensics to identify the Ebury malware and determine the full extent of the breach.

Technical Analysis: What is Ebury?

A Rootkit is a specific type of malicious software designed to provide an attacker with Persistence and Stealth. This means it stays on the system even after a reboot and hides its activities from the user. It achieves this by modifying core operating system files so that standard administrative tools cannot “see” it. Based on the official Ebury documentation, we now have a clear understanding of how this rootkit operates.

• SSH Targeting: Ebury specifically targets the SSH (Secure Shell) protocol, which is the standard method we use to log into and manage servers. By compromising this protocol, the rootkit can perform Credential Theft, capturing usernames and passwords in plain text the moment an administrator logs in.
• Library Hijacking: To embed itself, Ebury uses a technique called Library Hijacking. It targets a system library named libkeyutils.so. By tampering with this file, Ebury ensures its malicious code is loaded into the system’s memory every time the server handles a security key or an SSH connection.
• Stealth Communication: For communication, Ebury uses Abstract UNIX Sockets. These are internal data channels used by programs to talk to each other. Because they do not appear as standard files on the hard drive, they are much harder to detect than traditional network connections.
• Data Exfiltration: It performs Data Exfiltration by hiding stolen credentials inside DNS TXT Records. This allows the stolen data to leave the network disguised as a standard request for a website’s IP address, often bypassing firewalls.

IOC (Indicators of Compromise)

To identify the rootkit, we looked for specific Indicators of Compromise (IOCs). These are the digital fingerprints left behind by an attacker. We used several system commands to find these clues:

• Suspicious Symbolic Links (Symlinks): We used the command ll -a to list all files and their connections. We discovered an extra link in the lib64 directory, such as libkeyutils.so.2. A Symlink is a shortcut that points one filename to another. The rootkit used this extra link to redirect the system away from the real security library and toward its malicious version.
• Orphaned Files: We ran rpm -qf against the suspicious library. The RPM (Red Hat Package Manager) is the system’s official database of authorized software. On a clean system, this command identifies which package “owns” a file. In our case, it returned nothing, proving the file was an Orphan, meaning it was likely placed there by an intruder rather than a legitimate installer.
• Integrity Mismatches: Using rpm -ql, which lists every file that should be in a package, we confirmed that the files on our disk did not match the official public records for those libraries.
• Hidden Processes: We used lsof (List Open Files) to identify active Unix sockets. This revealed the hidden communication channels the rootkit was using to coordinate its activity in the background.

Remediation and Recovery Strategy

Once the rootkit’s presence was confirmed, we executed a multi-stage remediation process to neutralize the threat and return the environment to a known-secure state. While our Endpoint Protection Platform (EPP) had already mitigated the primary malicious files, the rootkit had left behind unauthorized configuration changes that required manual intervention to fully resolve.

To get the system back to a clean state, we took the following actions:

Remove Malicious Links

We deleted the symbolic links created by the attacker to prevent the system from loading malicious code.

Restore Official Links

We re-established the legitimate links to ensure system calls correctly route to original, untampered libraries.

Reinstall Core Packages

We forced a reinstallation of affected packages from official repositories to overwrite any tampered files with clean, verified versions.

rpm -Uvh –replacefiles –replacepkgs [Official_Repository_URL]

Update and Sync

A full system update was performed to ensure all software and security patches were fully synchronized.

System Reboot

We performed a full reboot to clear the system’s RAM and ensure no malicious code remained active in the background.

Using this knowledge we looked for the same on other environment and wrote an automated remediation script. This allowed us to efficiently restore system integrity across the fleet, minimizing downtime and ensuring a uniform security posture.

Conclusion

The process of Threat Hunting never truly stops. It requires constant curiosity and a willingness to look deep into the system libraries when something feels off. Here’s to many more findings and to staying one step ahead of the adversaries.