Nick Harbour: Stealth Secrets of the Malware Ninjas

Black Hat Briefings, USA 2007 [Audio] Presentations from the security conference.

It is important for the security professional to understand the techniques used by those they hope to defend against. This presentation focuses on the anti-forensic techniques which malware authors incorporate into their malicious code, as opposed to relying solely on an external rootkit. In addition to describing a number of known but scarcely documented techniques, this presentation will describe techniques which have never been observed through the presenter?s experience with incident response and malware reverse engineering. This presentation will also demonstrate a new technique for executing a malicious program directly from memory under unix. A new technique for avoiding entropy detection of packed or encrypted executables will also be discussed.
This presentation will contain a great deal of highly technical content which covers the specifics of the techniques down to the machine instruction level. For the security professional/enthusiast with a limited technical background in this area, this presentation will serve as an eye-opening overview of malware anti-forensic techniques as well as a limited introduction to forensic analysis.
The Executable Toolkit (exetk) will be introduced and demonstrated throughout the presentation. Included in the toolkit are various utilities for data hiding, manipulation and infection of executable files.
The ability to execute a program directly from memory greatly enhances its stealth. With this ability, one malicious program can use any technique it chooses (such as downloading from the web) to fill a memory buffer with an executable, and then launch it directly without that executable ever being written to disk. If the executable is never written to disk there will be no binary for a forensic examiner to capture. A somewhat similar technique has been described before by ?the grugq?, though its inner workings were never fully described nor promised source code released. The approach taken by ?the grugq? was also significantly more obtuse and importable.
The approach to executing a process directly from memory under unix which I describe for the first time in this presentation will take the following three stage approach. The first stage is a part of an executable program which is either stand alone or infected into another legitimate process or program file. The job of the first stage loader is to first act as a debugger, and launch a debugged process with a breakpoint at the entry point. This is accomplished through the ptrace() system call. With the debugged process suspended by a breakpoint at its entry point, the first stage loader will overwrite the memory at the entry point with the second stage loader, then resume continuous execution on the process. When the debugged process resumes continuous execution the code of the second stage loader begins executing.
The role of the second stage loader is to first allocate enough memory for the new malicious executable. It then adjusts the memory protection on the new memory area to allow for writing and executing in addition to reading. The purpose for having a third stage loader is that the new executable code will likely have to be written to the same memory area in which the second stage loader currently resides. The third stage loader is a part of the same program which contains the first stage loader and performs its memory operations on the debugged process in the same fashion tradition debuggers use to alter process memory.
Control is passed from the second stage loader to the third stage loader simply by setting a breakpoint interrupt at the end of the second stage loader. Control will return to the same program which contains the first stage loader but its role at this point is changed. The job of the third stage loader is to copy the malicious program into the new process memory in the same fashion as the operating system would had the program been executed traditionally. The third stage loader must also manually resolve program imports by loading all dynamic libraries and finding the appropriate exported symbols and populating the pointers in the program?s import table accordingly. Once everything has been loaded and dynamically linked, the instruction pointer of the new malicious process is set to its entry point and execution is resumed. At this point the process containing the first and third stage loader may detach itself from debugging if necessary.
Packers will be discussed in detail. Use of a common packer such as UPX or PECompact can mask the malicious functionality of an executable but it is also very easy to ?unpack? these executables. This presentation will discuss how exactly a packer works and how you can write your own. The Executable Toolkit (exetk) will be demonstrated as a clean reference implementation for a simple obfuscating packer.
The latest malware detection software is beginning to scan for such custom packers through the use of entropy (randomness) detection. The presentation will discuss a technique to create a packer which obscures program contents which keeping a non-suspicious entropy within the data.