Application Loader Design

In this chapter, we will learn how a simple application loader can execute EXE files in memory without creating a child process. We will learn how to import an address table in a PE structure and write C programs to analyze them. We will then learn how to hijack Windows API calls, replace API behaviors with malicious code, and do DLL side-loading using examples.

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

• Import Address Table in PE
• Import API analyzer example
• Examples of IAT hijack
• DLL side-loading example

Import Address Table in PE

As we mentioned in Chapter 1, From Source to Binaries – The Journey of a C Program, when a program is executed, the following procedure is performed. First, a new process is created and the static contents are loaded into it as a file map; the first thread of this process then calls the loader function located in ntdll.dll. After the necessary corrections have been made to the PE module mounted in memory, the entry function of the EXE module can be executed and the program will run normally as a process.

In this chapter, we will look more closely at the application loader that comes by default with the operating system. This variation can be used to develop a program packer, fileless attacks, staged payloads (such as staged payloads in Metasploit), and so on.

Let’s go back to the basics first. Figure 5.1 is identical to Figure 1.3 and illustrates a program that will pop up a message with MessageBoxA:

Figure 5...

Import API analyzer example

The following example is the iat_parser.cpp source code under the Chapter#5 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 read the full project.

Let’s try writing tools to analyze which system functions are imported into EXE programs. Figure 5.4 shows the entry function of iat_parser.cpp:

Figure 5.4 – The main function of iat_parser.cpp

At lines 44-50 of the code, we first read the entire program into memory by fopen, and get the size of the global IAT and its RVA from the 13th item (i.e., IMAGE_DIRECTORY_ENTRY_IAT) in DataDirectory. Since each field in the global IAT is the correct system function address that is referenced in the .text section, and will point to the RVA of the system function name storage structure (IMAGE_IMPORT_BY_NAME) on the INT, each field is therefore an IMAGE_THUNK_DATA variable. We simply...

Examples of IAT hijack

Since each IMAGE_THUNK_DATA in an IAT holds the system function address, wouldn’t it be possible to monitor and hijack a program’s active behavior if we could overwrite the contents of IMAGE_THUNK_DATA with a function for monitoring purposes? The answer is yes. Let’s try it out with a sample program.

The following example is the source code of iatHook.cpp in the Chapter#5 folder of the GitHub project. In order to save space, this book only extracts the highlighted code; please refer to the full source code to read the full project:

Figure 5.10 – The iathook function

Figure 5.10 shows the source code of the iatHook function, which reads in four parameters:

• module: Points to the loaded module to be monitored
• szHook_ApiName: The name of the function to be hijacked
• callback: The function for monitoring purposes
• apiAddr: The original correct address of the hijacked function

At...

DLL side-loading example

DLL side-loading or DLL hijacking is a classic hacking technique that is documented in MITRE ATT&CK® as the attack technique Hijack Execution Flow: DLL Side-Loading, Sub-technique T1574.002 (attack.mitre.org/techniques/T1574/002/).

The core principle is to replace the loaded system DLL with one designed by the hacker to take control of the execution of a process. This means that by precisely placing the right malicious DLL module, the hacker can run it as any EXE process, for example, by pretending to be a system service process with a digital signature.

Many antivirus software rules treat programs with digital signatures as benignware in their detection engines. This is why APT groups use this technique extensively to avoid static antivirus scanning, active defensive monitoring, or UAC prompting for privilege escalation. For more details on this, you can refer to the arms vendor FireEye’s public disclosure report, DLL Side-Loading: Another...

Summary

In this chapter, we explained how the application loader is executed through the IAT in the PE structure and explained in detail the various fields in the IAT. We also learned about attacks such as directly calling programs in memory, IAT hijacking, and DLL side-loading. These techniques are often used by attackers to develop deshells, fileless attacks, and staged payloads to escalate privileges, bypass antivirus software, or hide backdoors. By understanding how these techniques work, you will be able to develop techniques for red team testing or blue team defending in the future.

In the next chapter, we will look at a more in-depth question: what if the PE binary cannot be placed in the memory location (image base) desired by the compiler? The redirection design of the PE module can help! Simply apply the redirection correction, which will allow us to place the PE module on any image base that is not assumed by the compiler. Therefore, in the next chapter, we will be able...