Computer Forensics

As an addition to the method of finding the presence of Debuggers and Virtual environment, exploiting the debugging tools have started. Recently we came across a new variant of BKDR.IRCBot was found to perform such a trick of exploiting this unexplored vulnerability existing in the LoadExportSymbols() function of dbghelp.dll. This vulnerability causes Olly Debugger (or any other debugger) using this unfixed version of DLL to crash or execute remote code while they load such crafted executables or DLL’s.

When any debugger tries to load the executable, it crashes without any error or crash report. This being a suspicious behavior of anti-debugging, took made me to analyze the file further. Prior to loading in debugger, I noted the file to contain TLS table entry with a TLS Callback function registered with it. I started looking for other simple documented anti-debugging tricks, but could not find any. This is where we sensed that malware is challenging with some out-of-ordinary anti-debugging tricks.

On further analysis of the file’s structure values like Data Directory entries, Import Table entries and its corresponding API’s imported, Export Table, etc. For an executable, existence an export table made me suspicious. It had one export function with very long random bytes. Upon parsing the file in Hex Editor I could conclude the export table function name is 0xC1C bytes long. Now, what does this long name had to do with the crash of a debugger?

Further analysis of the crash narrowed me down to the crash at dbghelp.dll one of the libraries imported by any debugger. The function LoadExportSymbols() was the place where the execution crashes. Further analysis at this module helped me sense that this function will not check the length of the export name string being copied from the buffer to the stack and hence causing buffer overflow in the module. This can better be understood from the illustration below.

In the fig, we could see that at the memory location 0x6D529AFF, the export table name data is being copied from buffer to the stack. The buffer can be seen in the dump screen at offset 0x01E72613, and the corresponding data being moved to the stack at 0x0012A491. A normal scenario which can be found in any buffer overflow vulnerability.

If someone has not updated their toolset or dbghelp.dll in the Olly directory in this case or in any applications where one uses this DLL, this method can be used as a simple anti-debugging technique.

Malware writers find various places to store their malware so that they can use that location hard-coded in their downloaders they distribute and can change their original payload with different files so that they can infect efficiently with different executables and can be left un-detected. Googlecode have become one such location where malware writers can have a repository of such executables and can modify when necessary. Check the screenshot below which states one such example.

Most of the files are executable files along with archived “.rar” files. The time stamps show that the files have been uploaded over the course of the last coupe of months. The download count also suggests the count of people in who maybe infected. This suggests that an Trojan-Downloader is actively using this free service to spread malware.

All the malware has to do is just use the HTTP get requests to download the file and execute it in the victim’s machine.

Another code page is displayed below.

The advantage the malware have here is that these sites are not blocked by any firewalls or Internet security suite and hence can bypass that level of protection. As Google Code is free hosting website for developers, attackers are taking advantage of the service to push their malware.

A thread can be said as the smallest entity of a process that is  scheduled to be executed by an operating system. Since the processor can execute only instructions, a multi-tasking operating system splits a long process into small unit called threads. These threads are scheduled to execute for 10ms (For Example).  These thread are given a unique identifier number called ThreadID. After the execution, the operating system saves the state of the thread executes the next thread. Some of the saved state contains CPU registers, The Kernel Space Stack and the User Space Stack, Thread Local Storage, storage area.

Some of the essential components of the thread are:

1. Contnets of set of CPU registers like Accumulator, Stack pointer, Count and Data Register along with Instruction Pointer
2. Kernel Mode Stack information
3. User Mode Stack information
4. thread-local-storage (TLS) for use by runtime libraries.
5. Thread Context and Security context for storing privileges.

MapAndLoad()

The IMAGEHLP.DLL can also take care of memory mapping a PE file for you. The MapAndLoad() function maps the requested PE file in memory and fills in the LOADED_IMAGE structure with some useful information about the mapped file.

BOOL MapAndLoad(
LPSTR ImageName,
LPSTR DllPath,
PLOADED_IMAGE LoadedImage,
BOOL DotDll,
BOOL ReadOnly
);

PARAMETERS

The function sets the members in the structure appropriately after loading the PE file.

ImageNtHeader()

The ImageRvaToVa() function needs a pointer to the PE header. The ImageNtHeader exported from the IMAGEHLP.DLL can provide you this pointer.

PIMAGE_NT_HEADERS ImageNtHeader(
LPVOID ImageBase
);

PARAMETERS

RETURN VALUES
If the function succeeds, the return value is a pointer to the IMAGE_NT_HEADERS structure within the mapped file; otherwise, it returns NULL.

ImageRvaToVa()

Description:

LPVOID ImageRvaToVa(
PIMAGE_NT_HEADERS NtHeaders,
LPVOID Base,
DWORD Rva,
PIMAGE_SECTION_HEADER *LastRvaSection
);


PARAMETERS
NtHeaders Pointer to an IMAGE_NT_HEADERS structure. This structure represents the PE header and is defined in the WINNT.h file. A pointer to the PE header within a PE file can be obtained using the ImageNtHeader() function exported by IMAGEHLP.DLL.
Base Base address where the PE file is mapped into memory using the Win32 API for the memory mapping of files.
Rva Given relative virtual address.
LastRvaSection Last RVA section. This is an optional parameter, and you can pass NULL. When specified, it points to a variable that contains the last section value used for the specified image to translate an RVA to a VA. This is used for optimizing the section search, in case the given RVA also falls within the same section as the one for the previous call to the function. The LastRVASection is checked first, and the regular sequential search for the section is carried out only if the given RVA does not fall within the LastRVASection.

RETURN VALUES
If the function succeeds, the return value is the virtual address in the mapped file; otherwise, it is NULL. The error number can be retrieved using the GetLastError() function.

Abstract

Anti-Debugging techniques take different forms from hiding code from reverse engineers and also to avoiding programs from automated analysis in virtual environments. Gone were days where the malwares encryption used XOR or some algorithms implemented like LZMA in UPX or used simple API to check debugger detection. My day-to-day experience with malwares through Comodo Antivirus for 3 years not only enabled me to keep myself updated with the latest anti-debugging techniques by different malwares and protectors but also made me write Anti-Anti debugging techniques. In this paper I would like to share my research on the currently prevailing anti-debugging techniques used by various commercial software like ASProtect, Armadillo, Themida, SVKP, VMProtect, and some of the famous malwares tricks based on the Windows NT operating system platform.

Read more on this paper available for free download Here

Abstract

File Infector type viruses modify the code in any frequently used legitimate files in such a way that they can be up before your original application’s process starts. Malwares can achieve this by modifying or inserting the malicious code into any legitimate files in such a way that it can be persistent to the system even after shutdown. This information is of importance for a forensic analyst to assess the ways havoc has been caused in case of a malware infection. This paper will discuss these topics starting from Introduction to PE Files, Different types of PE infectors, classification on the basis of infection, their behavior, with examples.

My work experience of above 3 years as senior threat research analyst with “Comodo antivirus” enhanced me with lots of ideas, concepts, and kept me up to date with the latest malware and their the infection methodologies. I came up with this topic to share my experiences of my research on this topic since has been an area of limited research since it needs a lot of understanding of both assembly language and windows internal architecture.

Read more on this paper available for free download Here

View Steve Jobb’s Stanford Commencement Speech, 2005

A quick way to completely prevent any AUTORUN.INF from auto execution is to deceive windows and make it think that there is no content in the autorun.inf that windows encounters.

All you do is to do is to save these 3 lines to a file and execute it.

REGEDIT4

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\IniFileMapping\Autorun.inf]
@="@SYS:DoesNotExist"

What happens internally is “Whenever you(Windows) have to handle a file called AUTORUN.INF, don’t use the values from the file. You’ll find alternative values at HKEY_LOCAL_MACHINE\SOFTWARE\…\=@DoesNotExist.” And since that key does not exist, it’s as if AUTORUN.INF is completely empty, and so nothing autoruns, and nothing is added to the Explorer double-click action. And hence worms with such design cannot get in unless you start double-clicking executables to see what they do, in which case, you deserve to have your PC infected.