Userland Rootkits Are Lame

Author here.

The context of this post is somewhat important. It is a direct response to a post titled: Symbiote Deep-Dive: Analysis of a New, Nearly-Impossible-to-Detect Linux Threat

Userland rootkits are not “nearly-impossible-to-detect.” They are not novel, they are not impossible to detect, and they are not the pinnacle of hacker techniques.

I felt that it was worth pointing out that the history of userland rootkits goes back a ways and that they were very easy to detect because they rely on proxying all access to the system. If you bypass the hook they use to enter their proxy, they you evade them entirely.

Forensic and incident response guides used to advise using static linked binaries for exactly this reason. There are guides from the 1990s telling people to do this because userland rootkits were an issue (before kernel rootkits everyone used userland rootkits.)

Here is an example from 2013 which points out that you can’t trust any binaries/libraries on the potentially compromised machine and should use statically linked tools. [0]

LD_PRELOAD rootkits are not new and they are not nearly-impossible-to-detect to detect. My post listed a number of ways to detect them, all of which have been known for decades.

[0] https://www.forensicfocus.com/forums/general/trusted-static-...

Adversaries live by the saying "if it works it isn't stupid."

ld_preload is the lazy way of doing userland rootkits. there are other ways.

For example, you can patch libc, and by patch I mean there are different ways of patching. a simply binary patch is unreliable because it'd be pinned to a specific version but you can parse the elf symbols dynamically and patch them, even when libc is updated (assuming certain critical symbols are unlikely to ever change) so it becomes reliable. a lot of "static" programs still dynamically load libc.

There is also a more aggressive but easily detectable approach, just patch every elf file on the system so that that the _start/entry always does something to prevent discovery of the malware like messing with the plt so that all function calls are proxied through rootkit code, where the rootkit filters for parameters and return values it doesn't like.

Kernel rookits are great but secure boot is also a thing, if implemented correctly it would be very difficult to beat. you don't even have to go full on rootkit, just a stealthy implant running as root via a hijacked dynamic library (doesn't have to be libc) will do. this isn't windows, it's not like there is a reliable/common way of making sure system libraries are legit (like authenticode/pe signing). The package managers make sure the correct binaries are being installed but they don't have something like sfc on windows (system file checker) that refuses to let the system boot if files are corrupt and/or restore tampered system executables.

Is it really practical to just statically compile everything so you don't get a rootkit? Is that really the solution?

If it’s weak, I’d expect a standard distribution to detect it by itself and inform the user.

Only revealing itself to a defender who looks for it sounds like it’ll be working as intended in almost all cases.

What are uses of LD_PRELOAD that make us keep it?

This sounds like a food youtuber trying to explain how easy cooking a Turkey is. Yeah sure in a vaccum maybe, but I don't spend all day cooking food. Ive got other stuff to do.

Maybe its easy to find rootkits if you know what you are doing and use a statically compiled tcpdump. Do you know how many times I've done a TCP dump on my computer to check for root kits statically compiled or not? 0. I don't spend my time doing that. All it has to do is use less CPU and RAM than my corporate anti virus already does ( which is a lot ) and I'm never going to find it, cause im never gonna look.