Essentially, an attacker who has the capability to execute arbitrary code is able to launch additional arbitrary code in a novel manner. Launching code with Herpaderp will:
- Make it look like the target code was not launched at all; and
- Avoid the target code being scanned by endpoint protection solutions upon launch
How would an attacker use this in practice?
As Herpaderp has a number of moving parts, the code to perform this attack goes beyond calling a single operating system function and requires a software stager.
An attacker would use this as follows:
- Drop the staging code to the target machine (currently on disk, but it’s likely to end up being ported for more flexibility)
- Execute the stager and specify the ‘target’ code you want to launch and ‘reference’ file you want to impersonate
- Enjoy.
This is demonstrated in the Herpaderp writeup in a video showing Mimikatz appearing to be signed by Google Chrome. This bypasses Windows Defender detection. Cool and scary stuff!
Detection?
The Herpaderp writeup shows that this technique of loading files is missed by the majority of security vendors on the market today. It is likely that security vendors will quickly flag the stagers (and the inevitable variants that appear) as malware.
Just as an interesting experiment, at the time of writing only two security vendors identify the compiled Herpaderp code as malicious, likely via their machine learning capability (VT link)
Application Allowlisting configured well, prevents the stager from being used in the first instance effectively preventing the attack without signatures. Matt Graeber had a very succinct take on the matter
Clarification: This technique, while novel, is not an application control solution bypass. Executing the technique in the first place would have already required a bypass.
Note the intentional AppLocker bypass policy: allow all except processhacker.exe.https://t.co/JKMkGJk0GV
— Matt Graeber (@mattifestation) October 27, 2020
Ultimately, preventing the staging code is the best chance of detection and will likely be the focus for defenders in the future.
Why would an attacker use this vs other options?
To avoid malicious code being detected as malware by endpoint protection products. Herpaderp is also great for attackers looking to fool incident responders by masking the actual file executed.
To be clear, if the target code being launched is on disk already on the target system, many Anti-Virus products will likely scan the file before launch. The attacker needs a way of delivering the target code to the Herpaderp stager, in a diskless manner.
While this technique is novel, if you are an attacker that already has:
- The ability to execute code; and
- The ability to stage code in a diskless manner
Then there are a number of techniques available such as .NET assembly reflection that do not require stagers, although these may have a higher chance of being caught or monitored.
Thoughts on the lack of Microsoft servicing?
The Herpaderp writeup highlights that Microsoft have not seen fit to provide an immediate fix for this technique, and that from Microsoft’s perspective the case is closed without resolution. The authors disagree, and provide the following reasoning:
We disagree on the severity of this bug; this was communicated to MSRC on 8/27/2020.
- There are similar vulnerabilities in this class (Hollowing and Doppelganging).
- The vulnerability is shown to defeat security features inherent to the OS (Windows Defender).
- The vulnerability allows an actor to gain execution of arbitrary code.
- The user is not notified of the execution of unintended code.
- The process information presented to the user does not accurately reflect what is executing.
- Facilities to accurately identify the process are not intuitive or incorrect, even from the kernel.
Source: https://jxy-s.github.io/herpaderping/.
We suspect that Microsoft has not serviced this due to point three above “The vulnerability allows an actor to gain execution of arbitrary code”. The catch 22 here is that the technique needs the execution of arbitrary (untrusted) code in the first instance in order to perform the attack and the attacker needs a way to stage malicious code without touching disk to avoid AV. It’s just a difficult technique to set up without being detected in the first instance.
There are also difficulties in servicing the solution as it deals with core Windows internals and may have compatibility implications.
Are we likely to see this as a widespread technique in the future?
It’s very likely we will see this method of execution added to the menus of offensive tooling frameworks in the near future. We would also expect to see the method being ported to other languages such as Powershell as attackers attempt to find ways around defenses as detections are created for the current PoC code.
What is the impact of Process Herpaderping in an allowlisting / application control context?
To use this method an attacker requires arbitrary code execution, and allowlisting is a great preventative control which will stop the use of the technique at this time.
The Herpaderp method also does not provide any obvious way of retaining persistence, something that other known techniques (also requiring arbitrary execution) are capable of today.
The caveat is that an allowlisting solution is as only as good as its implementation. It is important to understand if an attacker discovers a way of executing the Herpaderp stager, they would be able execute any other code with ease and therefore it is important to understand the level of coverage and protection your allowlisting implementation provides.
TLDR;
The advantage of Herpaderp is that it is a new technique which is difficult to detect and fix. However, the disadvantage is it requires a stager which in itself can be detected.
The research behind Herpaderp is technically brilliant, however while a stager is required to perform the attack it’s unlikely that this will be seen as a viable option for threat actors going forward. If someone can figure out how to use this technique without staging, then it’s a whole different ball game.
Authors: Daniel Schell & David Cottingham
