On a Linux server running the Syslogk rootkit, some of the files sitting on disk simply do not come back when you run ls. Change into the directory by name and they are all there. That gap between what the disk holds and what the operating system will admit to is the entire point of the rootkit, and AhnLab's Security Intelligence Center (ASEC) has published a breakdown of how it does it and how to get the hidden material back on screen.
Syslogk is not new. Researchers at Avast documented it in 2022, when it was still under development and was being used to load a Linux backdoor called Rekoobe. What ASEC adds is a current, defender-facing map of the concealment machinery, drawn from its own analysis of the sample.
Rewriting the kernel so it lies to you
Syslogk is a loadable kernel module, which means it runs inside the Linux kernel itself rather than as an ordinary program. That position lets it answer questions on the kernel's behalf. It finds the functions it wants by reading the symbol table the kernel publishes at /proc/kallsyms, clears the processor's write-protect bit so that read-only kernel memory becomes writable, and then patches the first few instructions of those functions so its own code runs first.
Two functions get that treatment, according to ASEC. The first, proc_root_readdir, fills in the process list that ps, top and pstree read. Syslogk lets the real function run but swaps in its own callback, which quietly drops any process named was_sys_relay, along with its children and their children. Everything else is returned normally, so the list looks complete. The second, tcp4_seq_show, prints one line per TCP socket when something reads /proc/net/tcp. Syslogk removes the lines matching a particular port, so netstat shows no trace of that connection.
Files are hidden a different way. The kernel keeps a table of pointers to filesystem operations, and Syslogk replaces the pointer for readdir, the call behind every directory listing. Its replacement withholds any entry whose name contains the string was-patch. ASEC points out the limitation, and it is the most useful line in the report for defenders: the path itself is not blocked. You cannot see a was-patch directory in ls, but you can still cd into it and read what is inside. A directory you can enter but cannot see is a cheap thing to hunt for.
It also deletes itself from the module list
The rootkit hides its own presence with the same bluntness. It unlinks its node from the doubly linked list the kernel uses to track loaded modules, which is the list lsmod prints, so it stops appearing there. It then removes its own object from /sys/module and resets the internal flag recording whether the module is registered in sysfs back to 1, so the kernel's own bookkeeping still reads as normal.
Look for what the tools will not show you
ASEC says its V3 Net for Linux Server product detected the hidden kernel module on a test system and restored visibility, after which the concealed files appeared in ordinary listings again. That is a vendor claim about a vendor product, but the underlying point holds for any toolset. Kernel-level concealment defeats the standard checks precisely because those checks ask the kernel. Compare what a listing tool reports against what you can reach directly, and treat a mismatch as an incident.
The report publishes one indicator, the MD5 hash 8433c3f870729889f4b9712e26fe2fc8, with the remainder held behind AhnLab's threat intelligence subscription. Kernel-mode hiding is not a Linux problem alone: we covered a Chinese espionage backdoor that moved its concealment into the Windows kernel last month, and a rootkit shipped through backdoored Arch Linux packages in June. Once an attacker owns the layer that answers your questions, you have to stop asking it.
This briefing is provided by IntelFusions for informational and defensive purposes only. It is based on sources assessed to be reliable at the time of writing, and analytic judgments carry the confidence levels indicated. Indicators of compromise are defanged; re-arm them only in controlled environments. IntelFusions is not affiliated with the organizations named and makes no warranty as to completeness or accuracy.