The Final Curtain for Process Doppelganging: Unmasking the Defender

Introduction

Note: This blog does not delve deeply into this technique. However, if you want to learn more about it, you can either watch the original video on Process Doppelganging or read some blogs. One that we recommend is the blog written by hasherezade.

Process injection techniques are like the Swiss Army knives of hacking and cybersecurity. They’re methods used to sneak malicious code or software into the memory space of another running process on a computer. Think of it as a digital Trojan horse. These techniques are used by both attackers and security experts, each with different intentions. Understanding process injection techniques is vital in the ever-evolving landscape of cybersecurity, as they remain a pivotal tool in both offensive and defensive digital strategies.

Among various process injection techniques, ‘Process Doppelganging’ was one of the techniques used by attackers to outwit the detection capabilities of security products. There was a time when security products struggled to detect this technique, but those days are now behind us; Security products have made significant advancements in their capacity to detect and thwart it. To be specific, the renowned Windows inbuilt antivirus, Windows Defender, now effectively neutralises this technique. “No need to install additional security products to stop this technique”.

Brief on Process Doppelganging

Sometimes, it’s truly fascinating how attackers and researchers delve deep into their investigations to discover such astonishing techniques. When it was first introduced at the Black Hat 2017 security conference by security researchers Tal Liberman and Eugene Kogan, we came to understand how rarely used components, such as Windows NTFS Transactions, and the old process creation API (NtCreateProcessEx), which now exists for backwards compatibility reasons, can be exploited to create a technique capable of performing fileless code injection while evading detection by security products.

To implement this technique, we first need a basic understanding of Windows NTFS Transactions. NTFS Transactions are relatively lesser-known APIs in Windows, and Microsoft does not strongly recommend their use, possibly hinting at their future availability. Transactional NTFS allows multiple operations to be grouped together and either committed or rolled back as a single unit, ensuring data integrity in the face of unexpected failures. Now, this incredible feature, while heavenly in its design, can sometimes be tempted into mischief, especially when there’s another supporting feature in the shadows – the mysterious, undocumented process loader API known as NtCreateProcessEx.

Steps to Achieve Process Doppelganging

The steps won’t be detailed, but we’ll mention some key APIs that play crucial roles in Process Doppelganging.

The initial steps involve NTFS Transactions.

1. Firstly the Transaction object is created using the API NtCreateTransaction.
2. Next, the file is opened within the transaction. This marks the file as open for the transaction and also, where the malicious payload will be written later. CreateFileTransactedW API is used for this operation, which functions similarly to the CreateFileW function. The key distinction is that the CreateFileTransactedW function takes in the transaction object created in Step 1 as a parameter.
3. Now, the malware payload buffer is written into the transacted file created in Step 2. What’s intriguing is that the file remains within a transaction and isn’t written to the disk yet. As a reminder, in an NTFS transaction, the operation isn’t considered complete until it’s committed. To write the file with the payload buffer to the disk, the operation requires commitment using the API CommitTransaction. However, this is where the clever trick of this technique comes into play; instead of immediately committing the transaction, a section object is created with the help of the transacted file using API NtCreateSection with SEC_IMAGE flag which performs the PE header validation.

Note: Committing the transaction operation might write a file with the malware buffer to the disk which will definitely get scanned by the security products, so the operation is never committed even after creating the section object.

• Once the section object is created, there is no longer a need for the transacted file. Rather than committing the transaction, it is rolled back using the API RollbackTransaction/NtRollbackTransaction. This action completely removes the transacted file with the payload buffer from the system.

At this point, the role of the NTFS transaction is fulfilled. Now, emerging from the shadows comes the ultimate weapon of this technique— the undocumented process loader API known as NtCreateProcessEx.

1. NtCreateProcessEx is a legacy process creation API, however, it’s not a modern process creation API. Two cool feature of NtCreateProcessEx that make this technique possible is:
2. It accepts the section object from the user mode as a parameter, allowing the attacker to control the section object. The section object created in step 3 is now passed into the API NtCreateProcessEx as a parameter.

Note that the image section object is passed into NtCreateProcessEx to create a new process.

1. It creates only the process body and doesn’t create any threads. Attackers can define process parameters; however, defining these parameters can be a bit complex and cumbersome. Also, it’s required to create a new remote thread.
2. The previous step only creates the process body. Before creating a new thread within the process body, the process parameters are required and need to be set. And this is done by using API RtlCreateProcessParametersEx.
3. After completing all the intricate tasks of setting process parameters, a new remote thread is created, which will then execute the malicious code. The new thread is created using API NtCreateThreadEx. Following is a simple diagram to visualize the technique.