Hiding

A malware process wants to avoid easy identification if someone were to check the list of processes running on the system using a Task Manager, and an odd-looking process meets their eye. Similarly, malware might also want to hide from anti-malware products.

To achieve this, the malware process wants to hide its presence, and it does so by injecting all or part of its code into other legitimate processes running on the system (e.g., explorer, svchost, and winlogon) and exiting its primary malware process. Though the primary malware process now has exited, the malware is still running but as a part of another legitimate process via the code it earlier injected. As a result, it now avoids scrutiny and investigation by both users looking at the Task Manager for weird processes, and anti-malware products that might skip investigating and scanning these legitimate system processes, which is illustrated in Figure 10-2.

Process Piggybacking

If malware wants to connect to the Internet, a firewall on the system might block this from happening, if it tries to connect from its own created process. The reason could be the firewall on the system might allow only a few well-known processes on the system to connect to the Internet. So how can the malware bypass the firewall?

Malware can inject its code and run from other legitimate native processes like explorer, svchost, winlogon, and so forth, which have permission to connect to the Internet. So by piggybacking on the permission and privileges of these other legitimate processes, the malware was able to bypass restrictions put by the OS policies on its own process, as illustrated in Figure 10-3.

Altering Functionality

Another motive of code injection is to alter the functionality of certain processes or maybe even the entire OS/system. This is largely used by malware for code hooking, rootkits, and API interceptions in attacks such as man-in-the-browser.

Let’s take an example of malware that drops/creates certain files on the system disk, which has the name MalwareFile.exe and it doesn’t want either the user or any anti-malware products to delete it. To delete files on the system, the OS provides the DeleteFile()Win32 API, which is called by the antivirus or users to delete a file on disk.

Now to prevent deletion of its file MalwareFile.exe, all the malware must do is alter the functionality of the DeleteFile() API, and it does by code injection and API hooking. The malware alters DeleteFile() API, thereby hijacking it and then transfer control to its fake version of the API called FakeDeleteFile(). FakeDeleteFile()checks if the user is trying to delete MalwareFile.exe, and if so, it does not delete it. But if the user is trying to delete any other file other than MalwareFile.exe, FakeDeleteFile() doesn’t interfere with the behavior, allowing the system/user to delete the file. This technique is called code hooking , which we explain later in the chapter. The process is illustrated in Figure 10-4.

Steps for Process User-Mode Code Injection

User-mode code injection involves all the steps discussed, with the only difference being the target is a process. The target process is often referred to as the remote process or target process. The process that does the injection is often called the injector process . At a high level, the whole process can be described. In the following steps, we use pseudo API names called MemAlloc(), WriteRemoteMemory(), and ExecuteInjectedCode() to simplify your understanding. In the subsequent subsections, we introduce you to and describe the exact APIs used in the code injection process.

1. 1.

   An injector process selects the target process into which it wants to inject its code, as described by Figure 10-5. You can also see that the current instruction pointer in the target process is pointing to and executing the target process’s code.

    

1. 2.

   Now that the target process has been figured out, the injector process allocates memory in the target process, and it does so by calling an API MemAlloc() , as seen in Figure 10-6.

    

1. 3.

   Now that memory has been allocated in the target process, the injector process copies its code into the allocated space using the WriteRemoteMemory()API , as seen in Figure 10-7.

    

1. 4.

   After copying the code into the target process, the injector process needs to make sure that the target process runs its injected code and that the instruction pointer point to its code. It does so by calling the ExecuteInjectedCode() API. As you can see in Figure 10-8, the instruction pointer now points to and executes the injected code.

    

This should give you a high-level overview of how code injection works in User Space. In the next set of subsections, we go into detailed technical details on how code injection works and work with hands-on exercises to see the whole process in action.

Step 1: Locating the Target Process

Malware may want to inject its code into system processes like Explorer or svchost or browsers like Chrome and Firefox. To inject code into a process, it first needs to open the process using an OpenProcess()Win32 API, which takes the PID of the process as a parameter. But how does the malware know the PID of its target process?

For this, malware uses a set of APIs available on Windows to search for the target process by name and, once found, retrieve its PID. The APIs in question are CreateTool32HelpSnapshot(), Process32First() and Process32Next().

Malware first wants to get a list of all processes running on the system, which it gets using the help of the CreateTool32HelpSnapshot()API. This API returns a linked list of processes, where each node represents details of the process, represented by a structure called PROCESSENTRY32.

The PROCESSENTRY32 structure contains various details of the process, including the name and the PID of the process. The returned linked list of processes is then iterated using the help of the Process32First() and Process32Next()APIs. For each node in the list, if the name of the process matches the name of the process that the malware intends to inject into, the malware uses the PID of that process for its subsequent operations and APIs, including in the call to OpenProcess().

Listing 10-1 shows a sample code excerpt that gets the list of processes running on the system.

HANDLE hSnapshot;

DWORD remote_pid;

hSnapshot= CreateToolhelp32Snapshot(TH32CS_SNAPPROCESS, NULL);

/* PROC_NAME holds the name of the process the malware

 * wants to inject into */

if (Process32FirstW(hSnapshot, &entry)) {

    do {

        if (!_wcsicmp(PROC_NAME, entry.szExeFile)) {

            /* Match found for PROC_NAME. Extract PID */

            remote_pid = entry.th32ProcessID;

            break;

        }

    } while (Process32NextW(hSnapshot, &entry));

}

Listing 10-1

Sample Code Snippet That Obtains the List of Processes Running on the System

Now you can run Sample-10-1 from the samples repo, which utilizes the code in Listing 10-1 and prints the process name and PID of every process running on the system. You must add the .exe extension suffix to the sample file. To run the sample, you can open the command prompt and execute the sample, as seen in Figure 10-9. The partial output of running this sample is seen in Figure 10-9. You can verify the output by opening Process Hacker and comparing the process name and PID value to the ones printed by the sample.

Instead of the malware picking a target process from a set of existing processes running on a system, malware is also known to spawn/create a new process out of a native clean program on the system but in a suspended state. After creating this suspended process, it then injects its code into this suspended process and then resume the process but from its injected code. In this case, you see two new sets of additional APIs: CreateProcess() or its variations in step 1, and ResumeThread() or its variations in step 4.

The following is a list of the important APIs in step 1 of code injection. As analysts, we need to remember these APIs. It is handy to know them during dynamic analysis, where a detection tool like APIMiner can help you visualize the APIs used by a malware process. Knowing that a malware process uses a certain set of APIs, like the ones listed next, helps us investigate whether the malware process is carrying code injection or not.

• CreateToolhelp32Snapshot

• Process32First

• Process32Next

• CreateProcessA

• CreateProcessW

• CreateProcessInternalW

• CreateProcessInternalA

Step 2: Allocating Memory in a Remote Target Process

Now that we have the PID, we can open a handle to the remote process. Most operations and API calls to the remote process are against the process handle. Do note that the injector process needs to obtain debug privileges to manipulate the virtual memory of the target process, and hence a handle to the process has to be opened in debug mode (PROCESS_ALL_ACCCESS covers all privilege types). It does this by calling the OpenProcess()API, as seen in Listing 10-2.

/* Opens handle to the process with ALL privileges including

 * debug privileges */

HANDLE remote_process_handle = OpenProcess(PROCESS_ALL_ACCESS,

                                         TRUE,

                                         remote_process_pid);

Listing 10-2

Sample Code That Opens a Handle to a Process with Debug Privileges

You do need to be aware of the fact that every process is treated like an object on Windows. A process object has certain attributes, which include privilege level. A security token is associated with a process that decides which resources a process can access. Certain APIs cannot be successfully called by the process if it does not have the required privileges. The injector process can obtain these privileges by adjusting the security tokens. This is done by the injector process by using a sequence of API calls, which include OpenProcessToken(), LookupPrivilegeValue(), and AdjustTokenPrivileges(). Using these APIs, the injector process can adjust its privilege. For more information on the API, you can look it up on MSDN.

After obtaining the handle to the target process, the injector process now allocates memory in the target process by calling the API VirtualAllocEx(), as seen in Listing 10-3.

LPVOID allocated_adddress;

/* size_to_allocate holds the size of the memory that needs to

 * be allocated in the remote target process

 * process_handle - Handle of the target process from Step2

 * size_to_allocate - Size of the memory that needs to be

 *                    allocated in the target process

 * PAGE_EXECUTE_READWRITE - Permissions for memory allocated

 */

allocated_address = VirtualAllocEx(process_handle,

                                   NULL,

                                   size_to_allocate,

                                   MEM_COMMIT,

                                   PAGE_EXECUTE_READWRITE);

Listing 10-3

Sample Code That Allocates Memory in Remote Process

VirtualAllocEx() allocates memory of the requested size(size_to_allocate) in the remote target process identified by the process HANDLE. Another thing that you may have noticed is the permission of the memory above PAGE_EXECUTE_READWRITE. You learned about page permissions in Chapter 4. When you are specifying VirtualAllocEx() API, you can specify the permissions to assign to the allocated memory or rather to the pages in allocated memory. In this particular case, it is all read, write, and execute permissions because the injector process wants to first write code into the memory; hence, it has write permissions. After that, since it wants to execute the written/injected code, it has execute permissions.

To see the APIs in action, we can now run Sample-10-2, which we illustrated in Figure 10-10. Make sure you add the .exe extension suffix to the sample. The sample is an interactive sample that you need to run from the command prompt. The sample requests you to start Notepad.exe so that it can allocate memory in it. Once you start Notepad.exe, you can obtain the PID using Process Hacker, and enter it when the sample requests you to. You can also enter the size and the permissions of the memory you want to allocate in the remote process. The sample then allocates memory using VirtualAllocEx(), which you can verify in the remote process (Notepad.exe) using Process Hacker.

Note

An alternate method to VirtualAllocEx() and WriteProcessMemory() that is used in steps 2 and 3. In this method, the malware uses sections and views, where it maps a part of its memory to the target process, basically creating a reflection of a part of its memory in the target process. To do so, it uses another set of APIs.

We now verify if the memory is allocated by checking the memory of the Notepad.exe process using Process Hacker, as seen in Figure 10-11. You see a new memory size of 4096 bytes allocated at address 0x1e0000 as described by the sample program output in Figure 10-10. Do note that the output of running the sample might vary on your machine since the address of the memory allocated might be different.

We recommend that you play around more with Sample-10-2, trying out various other memory permissions (1–5) and memory sizes, and verifying in Process Hacker that memory is allocated in the remote process.

An alternative to setting EXECUTE permissions while allocating memory, the malware can first allocate memory but using just READ_WRITE permissions and later after step 3, but before we enter step 4, manually change the permissions of the allocated memory to EXECUTE as well using the API VirtualProtect(). So while analyzing malware samples, you have to watch out not just for VirtualAllocEx() API but also VirtualProtect(). If you see a combination of these two APIs operating against a remote process, there’s something fishy going on, and it deserves more investigation from the point of view of code injection and malware infection.

The following is a list of the important APIs from step 2 in code injection.

• OpenProcess

• VirtualAllocEx

• LookupPrivilegeValue

• AdjustTokenPrivileges

• OpenProcessToken

• VirtualProtect

Step 3: Writing into Remote Target Memory

After space is allocated, the code that needs to be executed in the target process is copied into the target process using WriteProcessMemory() API , as seen in Listing 10-4.

str = “MALWARE ANALYSIS AND DETECTION ENGINEERING”

WriteProcessMemory(process_handle,

                   allocated_address,

                   str,

                   SIZE_T)(strlen(str) + 1),

                   &numBytesWritten)

Listing 10-4

Sample Code That Allocates Memory in Remote Process

To see the APIs in action, we can now run Sample-10-3, which we have illustrated in Figure 10-12. Don’t forget to add the .exe file suffix extension to the sample. The sample is an interactive sample that you need to run from the command prompt, very similar to Sample-10-2 in the previous section, with the extra addition being it writes into the allocated memory the string MALWARE ANALYSIS AND DETECTION ENGINEERING. The sample uses the WriteProcessMemory() API to write the string into the allocated memory.

We now verify if the memory is allocated and the string written to it by checking the contents of the memory location 0x350000 of the Notepad.exe process using Process Hacker, as seen in Figure 10-13. Do note that the address location allocated on your system might vary from the one we have specified here. Please pick the allocated address as indicated by the output of this sample process on your system.

The method mentioned in step 2 and step 3, which uses VirtualAllocEx() and WriteProcessMemory() to allocate memory and code into the target process, is quite common in most malware.

There exists another method of allocating memory and copying code from the injector process into the target process, which involves section objects and views. Before we head into step 4, let’s investigate this alternate technique.

Section Object and Section Views

Section objects and views is a provision by Windows in which a portion of virtual memory belonging to a process is shared/mapped with/into other processes.

There are two processes: the injector process and the target process. The injector process wants to map some of its code and data into the target process. To do this, the injector process first starts by creating a Section object by calling the NtCreateSection() API, as seen in Figure 10-14. Creating a section object doesn’t mean any memory is allocated in its virtual memory. Or at least not yet. While creating a Section object, it can also specify its size in bytes.

Now that the injector process has created a section, it creates a view of this section, which allocates memory for this section in the virtual memory. The injector process using the NTMapViewOfSection() API creates two views of the same section it earlier created: one locally in its own process and another in the target process, as seen in Figure 10-15.

The multiple views created act as a mirror image. If the injector process modifies the contents in its own view, it automatically is reflected in the view of the target process, as illustrated in Figure 10-16.

Malware is known to use this feature to inject code into a target process, instead of always relying on APIs like VirtualAllocEx() and WriteProcessMemory(), where malware using sections and views writes its malicious injected code in its own view, and it automatically is copied/reflected in the view of the target process. While any code injection technique can use this method, it is more commonly used in a technique called process hollowing (also called RunPE), which we cover in detail in a later section.

The following is a list of the important APIs from step 3 in code injection. As analysts, we need to remember these APIs come in handy during dynamic analysis.

• WriteProcessMemory

• NtUnmapViewOfSection

• NtCreateSection

• NtMapViewOfSection

Step 4: Executing Code in Remote Process

Now that the injector process has injected its code into the target process, it now needs to get the target process to run this injected code. Several techniques have been developed to execute the injected code in the target process. The following are the most popular.

• Remote thread creation APIs. Using APIs like CreateRemoteThread() and other similar APIs, the injector process can create threads in the target process.

• Asynchronous procedure call (APC) queues

• Altering thread context. The instruction pointer of an existing current thread in the remote/target process is made to point to the injected code, using the GetThreadContext() and SetThreadContext()APIs.

Remote Thread Creation API

In this technique, the malware spawn/create a brand-new thread in the target process but pointing this thread it to run from its injected code. This is illustrated in Figure 10-17.

Some of the APIs that are used by malware to create a remote thread are CreateRemoteThread(), RtlCreateUserThread(), and NtCreateThreadEx().

To see this technique in action, you can run Sample-10-4 from the samples repo, whose output from my run is seen in Figure 10-18. Do note to the add the .exe extension suffix to the sample. The sample very similar to the earlier samples takes the PID of the target process in which it creates the remote thread. The sample request you to open Notepad.exe to use it as the target process for the exercise. Once you open Notepad.exe, go down to Process Hacker and make a note of no of threads currently used by the Notepad.exe process, as seen in the top right of Figure 10-18. After fully running the sample, you can then recheck the no of threads in Notepad.exe to observe a newly created thread that was created by the injector process Sample-10-4.exe, as seen in the bottom of Figure 10-19.

As seen in Figure 10-19, you can see an extra thread created, which has been created by the injector process.

Asynchronous Procedure Call (APC) Queues

Creating a new thread is sometimes an overhead as new resources need to be allocated to start the thread. Creating a new thread in a remote thread can easily be detected by anti-malware products that are listening to the event log and logs such an event as suspicious.

So instead of creating a remote thread to execute the injected code, we can request one of the existing running threads in the remote target process to run the injected code. This is done using an asynchronous procedure call (APC) queue. Let’s now look at how it works.

APC is a method for already executing threads within an application to take a break from their current tasks and perform another queued task or function asynchronously, and then return and continue from where it left off. But a thread can’t just randomly run these tasks/functions that are queued to it. It can only run these tasks when it enters an alertable state.

A thread enters an alertable state when it calls one of these APIs: SleepEx(), WaitForSingleObjectEx(), WaitForMultipleObjectsEx(), SignalObjectAndWait(), and MsgWaitForMultipleObjects(). When a thread enters an alertable state by calling any of these APIs, it checks its APC queue for any queued task or functions; and if any, it executes them and then returns to where it left off. The APC process is described in Figure 10-20.

To queue a task into the APC queue of the target process, the injector process calls the QueueUserAPC()API.

Malware misuses this Windows feature by injecting a malicious code that contains a function in a remote/target process’ memory, then queue that injected function as APC into the remote process’ APC queue.

Altering the Thread Context

Every thread in a process has an EIP or instruction pointer, which holds the address of the code/instruction the thread is currently executing. The EIP of a thread is held in the thread’s context. Once the code is injected into the remote target process, an injector process can reset the EIP of a thread on the target process to point to the injected code, thereby forcing the target process to run its injected code.

The following steps carry this out.

1. 1.

   The remote thread whose context must be modified should be suspended first. If the thread is not suspended already, it is suspended by calling the SuspendThread()API.

    
2. 2.

   The current context of the remote thread is obtained using the GetThreadContext()API, which returns the context structure, which holds the context of the thread, including the current EIP of the thread.

    
3. 3.

   The EIP field in the context structure is modified to point to the address of the injected code that should be executed.

    
4. 4.

   With the modified context, the injector process then calls SetThreadContext() to reset the instruction pointer of the remote thread to the value set in the EIP field of the context.

    
5. 5.

   Call ResumeThread() to resume the suspended thread, which now executes from the injected code.

    

Listing 10-5 shows the structure of the CONTEXT struct that holds the context of a thread. It has a field named EIP that points to the address of the current code/instruction that the thread is executing.

typedef struct _CONTEXT

{

    ULONG ContextFlags;

    ..............

    ULONG Ecx;

    ULONG Eax;

    ULONG Ebp;

    ULONG Eip; // Holds instruction pointer

    .........

} CONTEXT, *PCONTEXT;

Listing 10-5

CONTEXT Struct Holds the State of a Thread, Including EIP, the Instruction Pointer

The following is a list of the important APIs from step 4 in code injection.

• QueueUserAPC

• SuspendThread

• ResumeThread

• CreateRemoteThread

• RtlCreateUserThread

• NtCreateThreadEx

• GetThreadContext

• SetThreadContext

In the next set of sections, we stitch together what you learned and run more hands-on exercises that detail full-fledged code injection techniques.

Identify Hooking Point/Target

You learned about identifying the hooking point or location to place the hook for Interception, basically step 4 from the previous section. Let’s take the example of a Win32 API call made by your program—DeleteFile(), as illustrated in Figure 10-33.

When our process makes a call to a Win32 API (DeleteFile() in our case), it takes multiple hops via its own IAT, which holds the address of the DeleteFile() function located in Kernel32.dll. This DLL then redirects it to another function, NtDeleteFile(), located in ntdll.dll. This DLL then redirects it into the kernel via a syscall, which finally talks to the file system driver.

Now there are multiple locations where a hook is placed. It is highlighted in yellow: 1, 2, 3, 4, 5, and 6. At a high level, locations 1, 2, and 3 are user space hook locations and 4, 5, and 6 are kernel space hook locations.

In the next section, we explain the various techniques of placing hooks in the user space.

Placing Hooks in User Space

Before we dig into these two techniques, let’s revisit how a normal API call is placed by using Figure 10-34 as an example.

As you can see in the diagram, when a process calls an API like DeleteFile(), which is located in another module (Kernel32.dll), the process obtains the address of Kernel32.DeleteFile() by referring to its IAT (import address table). The IAT acts like a jump table. Using the address obtained from the IAT, the process can jump and reach the function code for DeleteFile() located in Kernel32.dll.

This is pretty much how the code flows for every API call. Now let’s investigate the two hooking techniques that malware can use to plug itself into the code flow to place its hook.

IAT Hooking

With IAT hooking , all the malware does is replace the address of DeleteFile() in the IAT table to the address of a fake malicious DeleteFile() that the malware provides in its injected code. Now when the process calls DeleteFile() API and refers its IAT, the address of DeleteFile() in IAT points to the fake malware DeleteFile(), thereby redirecting all DeleteFile() API calls to the malicious DeleteFile() in the injected malware code. Figure 10-35 shows IAT hooking in action. You can use Figure 10-34 as a reference and compare it to the changes made by IAT hooking in Figure 10-35.

Inline Hooking

One of the defects of IAT hooking is that sometimes the code in a process might call an API in another DLL without needing to obtain the address of the API it needs from the IAT. So malware modifying the IAT with the address of its malicious code is useless. This defect can be solved by using inline hooking.

With inline hooking, the malware modifies the first few instructions in the real Kernel32.DeleteFile() API by inserting new instructions that effectively transfer the code flow to the malware injected code. This is best illustrated in Figure 10-36.

An alternate illustration of how the Hooked API Function Code looks after inline API hooking is seen in Figure 10-37.

So far, we have seen now how the code hooks can be placed in user mode. But code hooks can also be placed in kernel mode. For user-mode hooks, the injector process first injects code into the target process, and when the injected code runs in the target process, it places the hooks. For kernel-mode hooks, similarly, a kernel module needs to be injected into the kernel, which creates the hooks in kernel space. We cover kernel-mode hooks in Chapter 11.

Why a Malware Hooks?

All these operations can be intercepted and manipulated by API hooking. Let’s see some of the implications. We give you the list of APIs as well that are commonly hooked by malware for each of the malware use cases.

Application of Hooks in Security Software

Security software needs to monitor system activities for any malware infections. Very similar to malware, many of the antiviruses and anti-malware products hook on APIs to monitor file, registry, and network activity. Security software also needs to protect themselves from getting deleted, or their processes getting killed, or their processes being injected by malware code. All these require these anti-malware products to hook APIs in both user and kernel space by using the same hooking procedures we explained earlier.

Apart from products like antiviruses, another well-known tool that uses hooks extensively is an API logger like APIMiner. API loggers hook both user space Win32 APIs, and also system calls in kernel space to identify the various APIs used by a process. API loggers are largely used by malware sandboxes to identify the behavior of malware by logging the Win32 APIs the malware uses. Some of the well known free and open source API loggers are APIMiner and Cuckoo Sandbox.

Hook Scanning Tools

Most of the tools called rootkit scanners are actually hook scanners. GMER is one of the most popular ones. Another popular one is the Ring3 API Hook Scanner from www.novirusthanks.com. The installation of both tools was covered in Chapter 2. Running these hook scanner tools can help us identify if any of the APIs in the system are hooked and thereby identify any malware infection that relies on API hooking.

As we described in the previous section, an important point to remember is that many security software, as well as malware analysis tools, may create hooks in the system. Running your hook scanning tools might pop up these hooks from this security software on your system, which are real hooks, but they can be ignored. It’s good practice to take note of these hook entries from these clean software in case you are performing forensic analysis so that you can learn to ignore them when you look at these entries later on when you are analyzing a malware infection.

These hook scanning tools may bring up some false positives as well. Figure 10-38 displays the scan results for the GMER tool on a clean VM that is running Internet Explorer. As an exercise, please start the Internet Explorer browser and run the GMER tool.

The screenshot from GMER shows that Internet Explorer is hooked even though it may not be, or it might be hooked—not by malware, but by one of its own components as a security measure. You need to learn to identify these otherwise benign entries in GMER and ignore them when you analyze a real malware which hooks Internet Explorer and other processes on the system. Let's now dissect the structure of GMER logs, as seen in Figure 10-39.

The GMER logs on your system might be different from the one you see in the screenshot.

The right way to use hook scanning tools like GMER and Ring3 API Hook Scanner is to first run these tools before you execute malware to analyze it, make a note of the GMER logs and save the logs. Now you run the malware and re-run GMER and save the logs. Now compare the difference in GMER logs before and after running the malware to identify any hooks by the malware.

You can now retry the steps to see how the Ring3 API Hook Scanner logs look in comparison to GMER.

Case Study: DeleteFile() Hooked

Now let’s run Sample-10-7. Rename this file by adding the .exe file suffix extension. Also, make sure the same folder containing Sample-10-7.exe also has the file Sample-10-7-module.dll. In the same folder, create new text files: hello.txt and malware.txt. The folder contents should look like Figure 10-40.

Double-click Sample-10-7.exe to run it. Sample-10-7 is a hooking sample that injects code into the Explorer.exe process of your system. You might remember that Explorer.exe is the Windows file browser that you use to browse the files on your system. To view a folder’s contents, you use the Windows file browser.

Sample-10-7.exe injects code into Explorer.exe using one of the code injection techniques we covered earlier in the chapter and then inline hooks the DeleteFileW() API in Kernel32.dll module in Explorer.exe. With the hook in place, it redirects all API calls to Kernel32.DeleteFileW() to its own version of FakeDeleteFile() that checks if the user is trying to delete a file that has the word malware in it. If it does, it blocks the user from deleting the file. If the user tries to delete any file that doesn’t have the word malware in it, it allows the user to delete the file.

To test it, try deleting the malware.txt file that you created earlier (see Figure 10-40). To delete the file, don’t use the Delete button on your keyboard. Also, do not right-click the file and click Delete. These techniques do not permanently delete the file; they only move it to the Recycle Bin. Instead, you want to permanently delete the file, and you can do so by selecting the file and simultaneously pressing Shift+Delete on your keyboard. Doing this for malware.txt results in the system opening a message box informing you that it is about to permanently delete the file, as seen in Figure 10-41.

But although you clicked Yes to permanently delete the file, the hook that Sample-10-7.exe has put in place intercepts the API call to DeleteFileW() and blocks deletion of the file as seen in Figure 10-42.

Now you can try deleting hello.txt from the same folder using Shift+Delete as before, and the hook doesn’t block it from being permanently deleted, as seen in Figure 10-43, where hello.txt is no longer shown since Explorer.exe has deleted it.

Now run the Ring3 API Hook Scanner tool, which scans the system and shows that Explorer.exe has been hooked by our Sample-10-7.exe as seen in Figure 10-44.

Case Study: Internet Explorer Hooked

Let’s now explore a malware sample that hooks some network related APIs in the Internet Explorer browser. You can open the text file Sample-10-8.txt from the samples repo. This is just a text file that contains the hash and instructions on how to download the actual malware sample from various sources on the web. Once you download the malware sample, rename it as Sample-10-8.exe. Please note all downloads of malware and handling of these samples should be done inside your analysis VM only.

Before you can run the malware executable Sample-10-8.exe, please launch the Internet Explorer browser inside your analysis VM. Now run Sample-10-8.exe. Now run the GMER tool and start the scan. Figure 10-45 displays the scan results of GMER on our system. Do note that the results might vary when compared to the scan results on your system.

Figure 10-46 is an enlarged view of the logs. Not all the hook entries shown by GMER are from the malware. Most of them are false positives that you should learn to ignore. But you can note the actual hook as highlighted in the bottom two rows.

We give you hints on which of the GMER entries are actual hooks placed by the malware, and the rest are just false positives. But as you gain more experience, you learn to skim through these entries and easily identify the malicious hooks from GMER and other such tools’ logs.

To scan GMER looks and try to identify hooks that are not from the malware Sample-10-8.exe, look for jump targets that don’t lie in an unknown module. Also another way to find the actual hooks is by the process of elimination (i.e., you run GMER with Internet Explorer open before you run the malware sample, obtain the logs and save them). Now execute the malware sample with Internet Explorer open and re-run GMER and save the logs and compare it with the logs you saved earlier. The new entries point to hooks placed by the malware sample you ran.

We found that the hooks are in the HTTPSendRequestA and HTTPSendRequestW APIs, and it possibly indicates that we are dealing with malware, which is some sort of banking trojan that possibly intercepts user credentials via these hooks. More accurate details about the malware can only be found out by reverse-engineering the sample.

Now that we have identified the hook, let’s look at the memory location where the malware hook jumps into after intercepting an API call. The addresses as seen in Figure 10-46 are 0x01E816C0 and 0x01E817A0. Please do note the addresses might be different in your GMER logs. If we open the memory tab in process hacker for Internet Explorer, these addresses lie in a memory block that starts from 0x1e80000, as seen in Figure 10-47.

Note that the memory block has RWX (read, write, and execute) permissions. You learned that malware that injects code allocates memory with RWX permissions, thereby indicating that this memory block must be the injected code by Sample-10-8.exe.

APIMiner

APIMiner is a tool developed by us that you can use to log APIs used by malware samples. As opposed to sandboxes like Cuckoo, you can instead use APIMiner in your existing analysis VM to inspect malware samples. APIMiner is a command-line, and we have covered its installation in your analysis VM in Chapter 2. APIMiner is used via the command prompt by using the command line shown in Figure 10-48, where you supply the path to the sample that you want to analyze, as an argument to the --app option. APIMiner hooks the Win32 APIs in the sample process and logs the APIs used by the sample process into log files in the same directory, which starts with the apiminer_traces filename prefix.

As an exercise, let’s reanalyze Sample-10-2.exe from earlier in the chapter using APIMiner, as seen in Figure 10-48. Run the command and go through the whole exercise. Make sure you have an instance of notepad.exe process running while running the command, since Sample-10-2.exe needs it. After running the whole exercise, you can see an API log file starting with apiminer_traces in the same directory where the sample is located.

Open this log file, and as you can see, APIMiner has logged the various APIs used by this sample. As you learned in the Sample-10-2.exe exercise, this sample calls the VirtualAllocEx Win32 API to allocate memory in the notepad.exe process that you have started. In the API logs file, you can see the call to the NtAllocateVirtualMemory API, which is the NT API version invoked by the VirtualAllocEx (APIMiner logs NT APIs) API called by the sample.

Using APIMiner, you can easily analyze malware samples and log the APIs used by it, helping you easily identify any form of code injection. As an exercise, run all the exercises in this chapter using APIMiner, and examine the API logs and identify all the APIs that are used by the sample for code injection.

Summary

Code injection is one of the most common techniques used by malware. It helps analysts identify and classify the malware in question. In this chapter, you learned about code injection using various hands-on samples. We covered the different types of code injection techniques that are prevalent in malware these days. We also covered process hollowing, a notorious code injection technique used primarily for stealth. You also learned about API hooking, a primary motive for malware to inject code. Using hands-on exercises and samples, we investigated how API hooking works and the implications of using it. You also learned about anti-malware hook scanning tools like GMER And Ring3 API Hook Scanner for detecting any hooks that malware placed on a system.