[qweqwe14]

There's also TracerPid field in /proc/PID/status, which is non-zero when a process is being ptraced

> Sus tests for common indicators of compromise

There's a lot of stuff that Linux malware tends to do that almost no legitimate program does, this can be incorporated into the tool. Just off the top of my head, some botnet clients delete their executable after launch, in addition to being statically linked, which is an almost 100% guarantee that it's malware.

Check for deleted executables: ls -l /proc/*/task/*/exe 2>/dev/null | grep ' \(deleted\)$'

(not really reliable) check for statically linked running programs: wc -c $(grep -L libc /proc/*/task/*/maps 2>dev/null) 2>/dev/null | grep -v '^0 '

Although a malicious process can just mmap libc for giggles, and also theoretically libc can be named in a way that doesn't contain "libc". A more reliable method is parsing the ELF header in /proc/PID/exe to determine if there's an ELF interpreter defined.

You can also check for processes that trace themselves (TracerPid in status == process id), this is a common anti-debug tactic.

You can also hide the process by mounting a tmpfs on top of it's proc directory, tools like ps ignore empty proc directories due to the possibility that the process has terminated but it's proc directory is still around. This is obviously easily detectable by checking /proc/mounts or just listing empty directories with numeric names in /proc

Another heuristic can be checking /proc/PID/cmdline for two NUL bytes in a row, some malware tries to change it's process name and arguments by modifying the argv array, however they are unable to change the size of cmdline, hence having multiple NUL bytes is a viable detection mechanism. Legitimate programs do this too, but it's rather uncommon.

You can obviously combine these heuristics to make a decision whether the process is malicious, as by themselves they aren't very reliable