Many LD_PRELOAD rootkits hide their activity from the system by manipulating the output of libc functions like readdir(), open(), stat(), etc. kernel rootkits can hide whatever they need, but the common functionality is also to hide data from /proc.
That's why netstat, ps, *top or lsof are not reliable tools if the system is compromised. ss is a bit different and is a bit more reliable.
In this case, snitch is written in Go, which doesn't use the libc functions, so probably it'll be able to obtain information from /proc even if hidden by a LD_PRELOAD rootkit.
Another option would be to compile the binary statically.
Anyways, these tools are not meant to unhide malicious traffic or processes, so I think detecting beacons, inspecting traffic, etc, is out of the scope.
Resources:
https://github.com/gustavo-iniguez-goya/decloaker
User-space library rootkits revisited: Are user-space detection mechanisms futile? - https://arxiv.org html/2506.07827v1
The Hidden Threat: Analysis of Linux Rootkit Techniques and Limitations of Current Detection Tools - https://dl.acm.org/doi/10.1145/3688808
https://matheuzsecurity.github.io/hacking/bypass-userland-ho...
In any case, interesting to think of shared libraries (specifically shared libc) as a risk here. Makes sense, but I hadn't thought about it before.
That said, I'm having a hard time doing a threat model where you worry about an attacker only setting LD_PRELOAD but not modifying PATH. The latter is more general and can screw you with all programs (doesn't cover shell builtins, but it's not like those would just be one more step).
https://manpages.debian.org/bookworm/manpages/sock_diag.7.en...
https://github.com/vishvananda/netlink/blob/main/inet_diag.g...
Not many rootkits tamper the netlink channel, so in most cases it's a bit more reliable.
Just my two snitches.
https://www.icir.org/mallman/pubs/APT07/APT07.pdf
> The “SH” state indicates that the remote peer sent a SYN followed by a FIN—however, the monitor never recorded a SYN-ACK from the local peer. At first glance, this would seem to indicate a scanner that is trying to make connection attempts look as real as possible in the hopes of not triggering an alarm. However, such connections can also indicate a vantage point problem whereby the monitor is not observing outgoing traffic from some hosts. While in general the monitor placement at LBNL can observe both incoming and outgoing traffic, there were periods of time where the traffic for some LBNL hosts would partially bypass the monitor. From a measurement perspective this is clearly undesirable.