I'd not trust any app that parses /proc to obtain process information (for reasons [0]), specially if the machine has been compromised (unless by "incident", the author means another thing):
I’m struggling with the utility of this logic. The argument seems to be "because malware can intercept /proc output, any tool relying on it is inherently unreliable."
While that’s theoretically true in a security context, it feels like a 'perfect is the enemy of the good' situation. Unless the author is discussing high-stakes incident response on a compromised system, discarding /proc-based tools for debugging and troubleshooting seems like throwing the baby out with the bathwater. If your environment is so compromised that /proc is lying to you, you've likely moved past standard tooling anyway.
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.
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).
Nowadays, there's only one rootkit that can hide itself so perfectly: the Singularity rootkit. It also hides from auditd by using netlink_unicast hooking and other evasive functionalities. Analyzing a machine compromised with Singularity loaded is a real headache, since it prevents memory dumps for analysis.
Okay yeah, sure. So it's not intrinsically more reliable or anything, it's just not specifically vulnerable to LD_PRELOAD. And it's not clear to me why LD_PRELOAD would be a particularly interesting attack vector, but maybe that's just my ignorance.
it doesn't matter what netfilter frontend you use if you allow outbound connections from any binary.
In order to stop these attacks, restrict outbound connections from unknown / not allowed binaries.
This kind of malware in particular requires outbound connections to the mining pools. Others downloads scripts or binaries from remote servers, or try to communicate with their c2c servers.
On the other hand, removing exec permissions to /tmp, /var/tmp and /dev/shm is also useful.
> On the other hand, removing exec permissions to /tmp, /var/tmp and /dev/shm is also useful.
Sadly that's more of a duck tape or plaster, because any serious malware will launch their scripts with the proper '/bin/bash /path/to/dropped/payload' invocation. A non-exec mount works reasonably well only against actual binaries dropped into the paths, because it's much less common to launch them with the less known '/bin/ld.so /path/to/my/binary' stanza.
I've also at one time suggested that Debian installer should support configuring a read-only mount for /tmp, but got rejected. Too many packaging scripts depend on being able to run their various steps from /tmp (or more correctly, $TMPDIR).
I agree. That's why I said that it's also useful. It won't work in all scenarios, but in most of the cryptomining attacks, files dropped to /tmp are binaries.
I haven't taken a look at the malware, but it seems to download files from the Internet so it should have warned you to allow/deny the outbound connections.
It'd be nice to test it with a sample of aur package/malware.
it does, I am using it extensively (little snitch on mac, and open snitch on linux). My problem with it is that every new tool wants to connect to the internet and my terminal is the constant source of outbound connections. I try to review everything but the amount of tools and connections is overwhelming. It does limit the risk, but i do not trust my terminal and dev tools as usually i give them way too many permissions and any plugin or tool from AUR can contain malware
PS. Regarding downloading files from internet, every self-update tool does that nowadays, it becomes more common because of apple/others stores policies. I created a few remote control tools and it is very very difficult to caught them, and I am not even a professional malware researcher. Things they do is beyond understanding of average superuser
The campaign is using Go packages just as a mechanism to download a ransomware for Linux systems, and it specifically checks if the Documents/ directory exists for the current user. If it doesn't exist it does nothing.
That's probably why the malware sandboxes are not detecting the outbound connections and the encrypting activity.
The article misses one critical point in these attacks:
practically all these attacks require downloading remote files to the server once they gain access, using curl, wget or bash.
Restricting arbitrary downloads from curl, wget or bash (or better, any binary) makes these attacks pretty much useless.
Also these cryptominers are usually dropped to /tmp, /var/tmp or /dev/shm. They need internet access to work, so again, restricting outbound connections per binary usually mitigates these issues.
> Restricting arbitrary downloads from curl, wget or bash (or better, any binary) makes these attacks pretty much useless.
Any advice what that looks like for a docker container? My border firewall isn't going to know what binary made the request, and I'm not aware of per-process restrictions of that kind
https://github.com/pranshuparmar/witr/tree/main/internal/lin...
It should be the last option.
[0] https://news.ycombinator.com/item?id=46364057
reply