Process Herpaderping is a method of obscuring the intentions of a process by modifying the content on disk after the image has been mapped. This results in curious behavior by security products and the OS itself.
Generally, a security product takes action on process creation by registering a callback in the Windows Kernel (PsSetCreateProcessNotifyRoutineEx). At this point, a security product may inspect the file that was used to map the executable and determine if this process should be allowed to execute. This kernel callback is invoked when the initial thread is inserted, not when the process object is created.
Because of this, an actor can create and map a process, modify the content of
the file, then create the initial thread. A product that does inspection at the
creation callback would see the modified content. Additionally, some products
use an on-write scanning approach which consists of monitoring for file writes.
A familiar optimization here is recording the file has been written to and
defer the actual inspection until IRP_MJ_CLEANUP
occurs (e.g. the file handle is closed). Thus, an actor using a
write -> map -> modify -> execute -> close workflow will subvert on-write scanning
that solely relies on inspection at IRP_MJ_CLEANUP.
To abuse this convention, we first write a binary to a target file on disk. Then, we map an image of the target file and provide it to the OS to use for process creation. The OS kindly maps the original binary for us. Using the existing file handle, and before creating the initial thread, we modify the target file content to obscure or fake the file backing the image. Some time later, we create the initial thread to begin execution of the original binary. Finally, we will close the target file handle. Let’s walk through this step-by-step:
```plantuml @startuml hide empty description [*] --> CreateFile CreateFile --> FileHandle FileHandle --> Write FileHandle --> NtCreateSection Write -[hidden]-> NtCreateSection NtCreateSection --> SectionHandle SectionHandle --> NtCreateProcessEx FileHandle --> Modify NtCreateProcessEx -[hidden]-> Modify NtCreateProcessEx --> NtCreateThreadEx Modify -[hidden]-> NtCreateThreadEx NtCreateThreadEx --> [*] FileHandle --> CloseFile NtCreateThreadEx -[hidden]-> CloseFile NtCreateThreadEx --> PspCallProcessNotifyRoutines PspCallProcessNotifyRoutines -[hidden]-> [*] CloseFile --> IRP_MJ_CLEANUP IRP_MJ_CLEANUP -[hidden]-> [*] PspCallProcessNotifyRoutines --> Inspect PspCallProcessNotifyRoutines -[hidden]-> CloseFile IRP_MJ_CLEANUP --> Inspect Inspect -[hidden]-> [*] CreateFile : Create target file, keep handle open. Write : Write source payload into target file. Modify : Obscure the file on disk. NtCreateSection : Create section using file handle. NtCreateProcessEx : Image section for process is mapped and cached in file object. NtCreateThreadEx : The cached section is used. NtCreateThreadEx : Process notify routines fire in kernel. Inspect : The contents on disk do not match what was executed. Inspect : Inspection of the file at this point will result in incorrect attribution. @enduml ```
You’ll see in the demo below,
CMD.exe is used as the execution target. The
first run overwrites the bytes on disk with a pattern. The second run overwrites
ProcessHacker.exe. The Herpaderping tool fixes up the binary to
look as close to
ProcessHacker.exe as possible, even retaining the original
signature. Note the multiple executions of the same binary and how the process
looks to the user compared to what is in the file on disk.
We’ve observed the behavior and some of this may be surprising. Let’s try to explain this behavior.
When designing products for securing Windows platforms, many engineers in this field (myself included) have fallen on preconceived notions with respect to how the OS will handle data. In this scenario, some might expect the file on disk to remain “locked” when the process is created. You can’t delete the file. You can’t write to it. But you can rename it. Seen here, under the right conditions, you can in fact write to it. Remain vigilant on your assumptions, always question them, and do your research.
The motivation for this research came about when discovering how to do analysis when a file is written. With prior background researching process Hollowing and Doppelganging, I had theorized this might be possible. The goal is to provide better security. You cannot create a better lock without first understanding how to break the old one.
Herpaderping is similar to Hollowing and Doppelganging however there are some key differences:
Process Hollowing involves modifying the mapped section before execution
begins, which abstractly this looks like:
map -> modify section -> execute. This workflow
results in the intended execution flow of the Hollowed process diverging into
unintended code. Doppelganging might be considered a form of Hollowing.
However, Hollowing, in my opinion, is closer to injection in that Hollowing
usually involves an explicit write to the already mapped code. This differs
from Herpaderping where there are no modified sections.
Process Doppelganging is closer to Herpaderping. Doppelganging abuses
transacted file operations and generally involves these steps:
transact -> write -> map -> rollback -> execute.
In this workflow, the OS will create the image section and account for
transactions, so the cached image section ends up being what you wrote to the
transaction. The OS has patched this technique. Well, they patched the crash it caused.
Maybe they consider this a “legal” use of a transaction. Thankfully, Windows
Defender does catch the Doppelganging technique. Doppelganging differs from
Herpaderping in that Herpaderping does not rely on transacted file operations.
And Defender doesn’t catch Herpaderping.
For reference, the generalized techniques:
We can see the differences laid out here. While Herpaderping is arguably noisier than Doppelganging, in that the malicious bits do hit the disk, we’ve seen that security products are still incapable of detecting Herpaderping.
There is not a clear fix here. It seems reasonable that preventing an image section from being mapped/cached when there is write access to the file should close the hole. However, that may or may not be a practical solution.
Another option might be to flush the changes to the file through to the cached
image section if it hasn’t yet been mapped into a process. However, since the
map into the new process occurs at
NtCreateProcess that is probably not a
From a detection standpoint, there is not a great way to identify the actual
bits that got mapped, inspection at IRP_MJ_CLEANUP or
a callback registered at
results in incorrect attribution since the bits on disk have been changed, you
would have to rebuild the file from the section that got created. It’s worth
pointing out here there is a new callback in Windows 10 you may register for
however this suffers from the same problem as the previous callback, it’s
called out when the initial thread is executed, not when the process object is
created. Microsoft did add
is called out when the initial thread is inserted if registered with
PsCreateThreadNotifyNonSystem, opposed to when
it is about to begin execution (as the old callback did). Extending
PSCREATEPROCESSNOTIFYTYPE to be called out
when the process object is created won’t help either, we’ve seen in the
Diving Deeper section that the image section object is
cached on the NtCreateSection call not
We can’t easily identify what got executed. We’re left with trying to detect the exploitive behavior by the actor, I’ll leave discovery of the behavior indicators as an exercise for the reader.
Below is a list of products and Windows OSes that have been tested as of (8/31/2020). Tests were carried out with a known malicious binary.
|Windows 7 Enterprise x86||6.1.7601||Yes|
|Windows 10 Pro x64||10.0.18363.900||Yes|
|Windows 10 Pro Insider Preview x64||10.0.20170.1000||Yes|
|Windows 10 Pro Insider Preview x64||10.0.20201.1000||Yes|
|Windows Defender AntiMalware Client||4.18.2006.10||Yes|
|Windows Defender Engine||1.1.17200.2||Yes|
|Windows Defender Antivirus||1.319.1127.0||Yes|
|Windows Defender Antispyware||1.319.1127.0||Yes|
|Windows Defender AntiMalware Client||4.18.2007.6||Yes|
|Windows Defender Engine||1.1.17300.2||Yes|
|Windows Defender Antivirus||1.319.1676.0||Yes|
|Windows Defender Antispyware||1.319.1676.0||Yes|
|Windows Defender AntiMalware Client||4.18.2007.8||Yes|
|Windows Defender Engine||1.1.17400.5||Yes|
|Windows Defender Antivirus||1.323.267.0||Yes|
|Windows Defender Antispyware||1.323.267.0||Yes|
This vulnerability was disclosed to the Microsoft Security Response Center (MSRC) on 7/17/2020 and a case was opened by MSRC on 7/22/2020. MSRC concluded their investigation on 8/25/2020 and determined the findings are valid but do not meet their bar for immediate servicing. At this time their case is closed, without resolution, and is marked for future review, with no timeline.
We disagree on the severity of this bug; this was communicated to MSRC on 8/27/2020.
This repo contains a tool for exercising the Herpaderping method of process obfuscation. Usage is as follows:
Process Herpaderping Tool - Copyright (c) Johnny Shaw ProcessHerpaderping.exe SourceFile TargetFile [ReplacedWith] [Options...] Usage: SourceFile Source file to execute. TargetFile Target file to execute the source from. ReplacedWith File to replace the target with. Optional, default overwrites the binary with a pattern. -h,--help Prints tool usage. -d,--do-not-wait Does not wait for spawned process to exit, default waits. -l,--logging-mask number Specifies the logging mask, defaults to full logging. 0x1 Successes 0x2 Informational 0x4 Warnings 0x8 Errors 0x10 Contextual -q,--quiet Runs quietly, overrides logging mask, no title. -r,--random-obfuscation Uses random bytes rather than a pattern for file obfuscation. -e,--exclusive Target file is created with exclusive access and the handle is held open as long as possible. Without this option the handle has full share access and is closed as soon as possible. -u,--do-not-flush-file Does not flush file after overwrite. -c,--close-file-early Closes file before thread creation (before the process notify callback fires in the kernel). Not valid with "--exclusive" option. -k,--kill Terminates the spawned process regardless of success or failure, this is useful in some automation environments. Forces "--do-not-wait option.
The repo uses submodules, after cloning be sure to init and update the submodules. Projects files are targeted to Visual Studio 2019.
git clone https://github.com/jxy-s/herpaderping.git cd .\herpaderping\ git submodule update --init --recursive MSBuild .\herpaderping.sln
The following are used without modification. Credits to their authors.