0

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).

  • 1) can you explain how it would be possible to attach a dummy debugger to every userspace process at creation without modifying the kernel or execve? 2) How do you propose one could use LD_PRELOAD in conjunction with statically-linked binaries? – julian Jul 12 '17 at 16:42
  • @SYS_V: Good point. A kernel patch is certainly the most robust way to do this as far as I know. – Mark K Cowan Jul 12 '17 at 16:44
  • 1
    It would only really be necessary to change the PEB->BeingDebugged value in each process's Process Environment Block. – Will Jul 12 '17 at 18:06
  • 1
    You could use the HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\CurrentVersion\Windows\AppInit_DLLS registry key - along with a custom dll - to implement the PEB->BeingDebugged change to all processes that load user32.dll. – Will Jul 12 '17 at 18:13
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

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.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.