|
|
|
|
|
|
by grugq
717 days ago
|
|
|
And you can detect when you are being ptrace()d because a process cannot be ptrace()d twice. Unless they changed Linux again. There are also timing issues that show up, and you can do any number of anti-debugging tricks which would reveal that the environment is being manipulated. Which is an instant red flag. In general if the attacker is running at the same privilege level, you can probably evade it or at least detect it. I’m somewhat surprised there isn’t a basic forensics tool that automates all of these tests already. “sus: [-h] [-v] [-V] [-o file] [-O format] Sus tests for common indicators of compromise using on generic tests for common methods of implementing userland rootkits. It will check for LD_PRELOAD, ptrace(), inotify() and verify the system binaries match the upstream distribution hashsums. It can be used to dump the file system directly (warning, slow!) for comparison against the output of `find`. See EXAMPLES for more.” Implementation is left as an exercise for the reader. |
|
|
> 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