Debug every process to reduce the risk of successful malware attack?

Question

I've seen that quite a bit of malware (particularly ransomware) checks for a debugger and bails if one is found.

Would it (a) be practical and (b) reduce the risk of a successful malware attack if one either:

• attaches a dummy debugger to every userspace process at creation?

• has a hook which tells a user's processes that a debugger is attached, if asked? e.g. LD_PRELOAD on Linux, and I believe from WGA cracks that Windows has some API for this too.

I'm assuming that particularly on Windows it may be necessary to have a whitelist of programs not to debug (e.g. commercial software which also bails if being debugged).

Answer 1

Would it (a) be practical and (b) reduce the risk of a successful malware attack if one either:

• attaches a dummy debugger to every userspace process at creation?
• has a hook which tells a user's processes that a debugger is attached, if asked? e.g. LD_PRELOAD on Linux, and I believe from WGA cracks that Windows has some API for this too.

From a Linux perspective

LD_PRELOAD can only be used with dynamically linked binaries. It is not uncommon for ELF binaries developed for criminal purposes to be statically linked; examples include

• Linux/Moose
• Linux/Shashinga
• Linux/Elknot

and so on.

As for attaching a dummy debugger to every userspace process at creation, consider the following:

• taking advantage of the fact that a process cannot call ptrace(PTRACE_TRACEME,...) more than once is only one of several anti-debugging techniques. If use of any single anti-debugging technique results in high detection/failure rate, malware creators will adapt and the technique simply will no longer be used. Some well known executables do not even bother with anti-debugging tricks at all: Mirai and its ilk are a prominent example of this.
• userspace process creation is managed by the kernel (and if the program is dynamically linked, the dynamic linker as well). This means that if one wishes to make changes to how a program is mapped into virtual memory, one must make changes to the kernel. Does it make sense to fundamentally alter the way the kernel loads programs into memory across all architectures in order to do something like attaching a dummy debugger to each userspace process on creation, only to watch malware authors simply stop calling ptrace(PTRACE_TRACEME,...) in their binaries as a result?

• attaching a dummy debugger would revolve around use of the ptrace system call. Use of ptrace has far-reaching implications for process behavior and could even render the system unusable, due to the fact that a traced program's execution pauses upon receiving a signal:

  While being traced, the tracee will stop each time a signal is delivered, even if the signal is being ignored. (An exception is SIGKILL, which has its usual effect.) The tracer will be notified at its next call to waitpid(2) (or one of the related "wait" system calls); that call will return a status value containing information that indicates the cause of the stop in the tracee. While the tracee is stopped, the tracer can use various ptrace requests to inspect and modify the tracee. The tracer then causes the tracee to continue, optionally ignoring the delivered signal (or even delivering a different signal instead).

So no, neither of these proposals are practical or improve security.