Dynamic API Calling – Thread, Process, and Environment Information

In this chapter, we will learn the basics of Windows API calls in x86 assembly. We will first learn about the Thread Environment Block (TEB) and the Process Environment Block (PEB), and how attackers use these features in malicious software. By the end of this chapter, you should have a better understanding of how the compiler makes dynamic calls through calling conventions so that the program will run as we expect. With these foundations in place, you can move step by step toward the goal of writing your own Windows shellcode. For example, calling a Windows API that does not exist in our source code allows evading antivirus detection of blacklisted API names.

In this chapter, we’re going to cover the following main topics:

• Function calling convention
• Thread Environment Block (TEB)
• Process Environment Block (PEB)
• Examples of process parameter forgery
• Examples of enumerating loaded...

Sample programs

The sample programs mentioned in this chapter are available on the GitHub website, where you can download the exercises, at the following URL: https://github.com/PacktPublishing/Windows-APT-Warfare/tree/main/chapter%2303

Function calling convention

In the previous chapters, we learned that the compiler saves chunks of code in different sections depending on the function of the source code. For example, the code is converted to machine code and stored in the .text section, the data is stored in the .data or .rdata section, and the import address table (IAT) is stored in the .idata section, as shown in Figure 3.1:

Figure 3.1 – Native code of msgbox.exe

Shellcode is a concise machine code script. When we can hijack a thread’s program counter, such as the EIP or RIP registers or the return address, we can control it in shellcode to perform specific and precise tasks (calling a specific set of system APIs). Common behaviors (such as downloading and executing malware, reverse shell connections, pop-up windows, etc.) are all achieved by calling the system API.

However, unlike PE programs, shellcode does not run with the help of the kernel to do file mapping or...

Thread Environment Block (TEB)

TEB is one of Microsoft’s unpublished structures. The contents listed in Figure 3.4 here are extracted from Undocumented 32-bit PEB and TEB Structures (bytepointer.com/resources/tebpeb32.htm):

Figure 3.4 – TEB structure

These are the partial contents of the TEB after 32-bit reverse engineering. The total size of TEB is as large as 0xFF8. However, for the sake of explanation, we will only mention the 0x30 bytes at the beginning, and the other parts are for Windows internal implementation.

As we mentioned in Chapter 2, Process Memory – File Mapping, PE Parser, tinyLinker, and Hollowing, when each process is generated, there must be a PEB stored in the process memory to record the details of the process being generated. And what about threads? Yes. Let’s take the multithread concept that you have studied in your operating system class. If there are multiple threads running in parallel in the same...

Process Environment Block

One of the main topics of this book is the PEB structure. Figure 3.6 shows some contents of the PEB structure, but for the sake of brevity, only the main points are included. The complete structure can be found in the unpublished Process-Environment-Block (https://www.aldeid.com/wiki/PEB-Process-Environment-Block) listed on the ALDEID website:

Figure 3.6 – PEB structure

Figure 3.6 lists the only status information block for the current process. It holds information such as BeingDebugged at +0x02, which is the value returned internally by the developer when using WINAPI IsDebuggerPresent to check whether it is being debugged. ImageBaseAddress at +0x08, which appeared earlier in the process hollowing technique, is used to record which EXE file is the main PE module of the current process.

ProcessParameters at +0x10 in the 32-bit PEB structure records information about the parameters inherited by the current process when...

Examples of process parameter forgery

The following example is the masqueradeCmdline, which can be found in the Chapter#3 folder of the GitHub project, which is publicly available in this book's repository. In order to save space, this book only extracts the highlights code; please refer to the complete source code to see the full project.

Many Red Teams or attackers who conduct attacks on local machines often encounter antivirus software, endpoint defense products, or event logging monitoring, and expect their attack commands to be undetected or untraceable. The process hollowing (RunPE) technique we looked at in Chapter 2 proposed an idea: If we create a child process with bogus parameters and the actual execution reads the attack parameters that we have placed, can this bypass local monitoring by antivirus?

For example, ransomware often uses the vssadmin delete shadows /all /quiet command to delete a user’s backup data. Each antivirus software will strictly check...

Examples of enumerating loaded modules without an API

Antivirus nowadays always checks whether a program is using an API that can be easily abused to determine whether it is malicious, for example, using LoadLibraryA to mount Kernel32.dll to get its ImageBase. So, if we can get the address of Kernel32.dll by not using LoadLibraryA, we can escape antivirus detection and make it think that we are not trying to use the Kernel32 DLL.

The following example is the source code of ldrParser.c, which is publicly available in the Chapter#3 folder of the GitHub project. In order to save space, this book only extracts the highlighted code; please refer to the complete source code to see the full project.

As mentioned earlier, the distribution of records in the PEB→LDR dynamic execution phase allows us to enumerate the loaded module information, so the first step is to get the current PEB address.

Figure 3.14 shows the source code of ldrParser.c:

Figure...

Examples of disguising and hiding loaded DLLs

The following example is the module_disguise.c code under the Chapter#3 folder of the GitHub project, which is publicly available in this book's repository. In order to save space, this book only extracts the highlighted code; please refer to the complete source code to see all the details of the project.

In the previous section, you have seen that we can crawl the PEB→LDR structure in dynamic memory to get the desired function module image base address. The next question is whether the information recorded in these dynamic modules can be forged for malicious use. The answer is yes. In this section, we design two functions: renameDynModule and HideModule. The former is used to disguise dynamic module information with confusing paths and names, while the latter is used to hide the specified dynamically loaded module from the record.

Figure 3.17 shows the renameDynModule function, which has only one input parameter for the...

Summary

Many of today’s antivirus software, endpoint monitoring and protection, and event log monitoring solutions are designed to increase performance by analyzing memory information only, without verifying that the content has been forged. In this chapter, we learned the basics of Windows API calls in x86 assembly, including TEBs and PEBs, as well as forged parameters, forged and hidden loaded DLLs, and more. With a proper understanding of the basics and the tactics used by malicious attackers, we can gain a better insight into the popular stalking techniques favored by a first-line cyber army. In the next chapter, we are going to further study how to analyze individual DLL modules in memory and get the desired API address without calling Windows APIs. We will also learn how hackers write Windows shellcode in x86 to execute specific attacks.