At the very least, these tools should not parse /proc to obtain information of processes or connections. It should be the last option.

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...

https://ops.tips/blog/how-is-proc-able-to-list-pids/

agreed on the limits. snitch isnt aimed at adversarial detection; its a local debugging/inspection tool. a competent attacker can blend in by design, so this isnt meant to be a standalone security control

Tools like these aren't really intended for adversarial environments, and pure network tools that are designed for real adversaries have a really spotty track record (good search: [bro vantage point problem]).