Comment by coppsilgold
2 days ago
I always wondered how useful such tools are against a competent adversary. If you are a competent engineer designing malware, wouldn't you introduce a dormancy period into your malware executable and if possible only talk to C&C while the user is doing something that talks to other endpoints? Maybe even choose the communication protocol based on what the user is doing to blend in even better.
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/
What makes ss different?
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).
ss obtains the connections information via netlink directly from the kernel (besides parsing /proc):
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.
2 replies →
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
With a name like Snitch, it should be aimed at adversarial detection.
Just my two snitches.
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]).
That search did not come up with much. Can you elaborate?
Not tptacek, but my search yielded this which seems relevant (to the network monitoring tool once named Bro, now Zeek):
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.