3 Ways Malware Can Bug Your Debugger

3 Ways Malware Can Bug Your Debugger

R9B
March 13, 2020

  1. Checking the BeingDebugged flag in the Windows Process Environment Block
    The Process Environment Block (PEB), is a structure within Windows that is populated at load time with various values from the operating system and the file being executed. Within the PEB structure there is a flag, set to either 1 or 0, indicating if the process is currently being examined by a debugger. If you are running malware within a sandbox instead of single-stepping through it, you may miss the check isDebuggerPresent() within the malware. Beware, though, because this function call is in MANY routine Windows binaries.The _PEB->BeingDebugged value can also be retrieved via “PEB walking”, which is performed by querying FS:[0x30] on 32-bit code or GS: [0x60] on 64-bit code, and then casting that value to a PEB structure. This allows the malware to see items, like the BeingDebugged flag, without calling any Windows API functions; making it far less likely to show up in any string searches.

    https://docs.microsoft.com/en-us/windows/win32/api/winternl/ns-winternl-peb

  2. Guard pages, works on Windows and Linux
    Malware can set up sections of memory where it will stash code that triggers an exception if anyone else were to look at it outside of their own process. In Windows, the malware would call VirtualProtect to manipulate the memory region; using the flag PAGE_GUARD. The anti-debug trick would be performed by adding an exception handler to exit the process gracefully upon that section of memory being read. The exception handler could also perform more nefarious tasks. For example, any memory currently in use by the malware may be zeroed out, making memory dumps useless. Alternatively, it could drop a batch script which deletes the malware once ran, making file recovery a pain.In Linux, the malware would call mprotect to accomplish the same task, but would register a signal handler to catch the SIGSEGV (segmentation fault) instead. This signal handler could do anything from destroying the malware you are examining, to simply exiting gracefully to avoid potential error-logging by the OS.

    https://docs.microsoft.com/en-us/windows/win32/api/memoryapi/nf-memoryapi-virtualprotect

    https://docs.microsoft.com/en-us/windows/win32/debug/using-an-exception-handler

    https://docs.microsoft.com/en-us/windows/win32/memory/creating-guard-pages?redirectedfrom=MSDN

    https://www.gnu.org/software/libc/manual/html_node/Signal-Handling.html

    https://linux.die.net/man/2/mprotect

  3. Classic Cross-OS Trick: RDTSC
    Works in x86_64 and x86_32. It’s supported by Windows AND Linux. What’s not to love about that level of portability? RTDSC is the assembly instruction which returns the current CPU tick count since last reboot, or roll-over. Malware can leverage the difference between the amount of ticks spent performing two different, sequential functions to see if someone had set a debugging breakpoint somewhere in between. Too many ticks, and the malware may simply tell itself to stop executing and move to the cleanup phase before exiting. In Windows you would check for the “QueryPerformanceCounter” or “GetTickCount”, if you wanted the Windows- specific API calls. In Linux, it is more likely to show up as “_rdtsc”, plainly.

    https://docs.microsoft.com/en-us/windows/win32/api/profileapi/nf-profileapi-queryperformancecounter

    https://docs.microsoft.com/en-us/windows/win32/api/sysinfoapi/nf-sysinfoapi-gettickcount

    https://en.wikipedia.org/wiki/Time_Stamp_Counter