Linux rootkits meta really did not change much since 1999.
Binary replacement (replacing top, ps, netstat, etc with patched versions) is the oldest trick.
Syscall hooking kernel root kits largely only vary in how exactly they hook the syscalls - there’s a few methods, but the underlying principle is the same.
And then you have userland hooks which usually use LD_PRELOAD to intercept system calls/libc calls to get the job done.
Honestly most of the time a full blown root kit is overkill, just name your binary something innocuous and have it not do anything too fucking obvious and nobody will notice.
https://www.man7.org/linux/man-pages/man2/prctl.2.html
> PR_SET_NAME
> Set the name of the calling thread
I don't understand how this survives major kernel upgrades. I have problems keeping out-of-tree modules working, intentionally. Do rootkits ship with fancy DKMS these days? Do the authors test with upcoming versions of major distros and push an upgrade to support the new release?
At one of my old jobs we had a kernel rootkit we used on occasional red team exercises that ended up having forks for 2.6, a couple of forks for 3.x, and a couple more forks for 4.x - maintenance of that was an absolute nightmare and frankly, not worth the effort in the long run, so it was not maintained into 5.x and replaced with a few much simpler userland backdoors.
That’s why you will see malware such as the one in the article shipping with stuff cobbled together from several different rootkit projects to try obtain some semblance of compatibility.