Some Context, Process Herpaderping

Recently some great research has been published by Johnny Shaw outlining a method to start processes in Microsoft Windows in a manner similar to process hollowing. They have coined this term “Process Herpaderping” and there is a great detailed technical write up here –

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:

  1. Drop the staging code to the target machine (currently on disk, but it’s likely to end up being ported for more flexibility)
  2. Execute the stager and specify the ‘target’ code you want to launch and ‘reference’ file you want to impersonate
  3. 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!


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

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:

  1. The ability to execute code; and
  2. 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.

  1. There are similar vulnerabilities in this class (Hollowing and Doppelganging).
  2. The vulnerability is shown to defeat security features inherent to the OS (Windows Defender).
  3. The vulnerability allows an actor to gain execution of arbitrary code.
  4. The user is not notified of the execution of unintended code.
  5. The process information presented to the user does not accurately reflect what is executing.
  6. Facilities to accurately identify the process are not intuitive or incorrect, even from the kernel.


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.


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

Airlock interview on RiskyBusiness Podcast #573

This week Airlock Digital whitelisting was featured on the Risky Business podcast with Airlock Co-Founder, David Cottingham.

They make whitelisting software that’s actually useable. And until I did this interview I didn’t know that their agent actually does host hardening as well, which is pretty cool. Since we last spoke they’ve also popped up in CrowdStrike’s app store thingy, which means a bunch of you Crowdstrike customers will be able to dabble in some whitelisting if you want to.

Dave joins the show to talk about a bunch of stuff, including their experience having Silvio Cesare do a code audit on their agent.

-Patrick Gray

You can listen to this episode online here: – The interview starts at approximately 43:40 for the “whitelisting curious”.

Airlock Digital featured on Risky Business Snake Oilers podcast

Airlock Digital was featured on Risky Business Snake Oilers June podcast and we have had a fantastic response.

You can listen here to the interview between Patrick Gray and Airlock Co-Founder David Cottingham here.

Airlock V2 released with ReversingLabs integration

Airlock Digital, headquartered in Adelaide, South Australia, today announced that its application whitelisting solution now includes integrated file reputational lookups to streamline administration and allow non-cyber security specialists to easily assess the threat level of unknown files.

The Airlock solution is specifically built around the Australian Signals Directorate’s (ASD) controls for application whitelisting, the number one cyber threat mitigation strategy in the Australian Information Security Manual (ISM). Airlock leads the industry in ease of use with inbuilt workflows enabling application whitelisting to be implemented in days, not months.

ReversingLabs Logo

“Airlock already makes application whitelisting easy to deploy and maintain in dynamic environments,” said Daniel Schell, Co-Founder of Airlock Digital. “Adding reputation lookup through our ReversingLabs partnership makes management of the whitelist even easier by providing additional context to the trust decision making workflow.

“Despite being recognised as the most effective strategy by the ASD, organisations have resisted application whitelisting because of perceptions it is onerous to administer, resource intensive to implement and reliant on a supplied list of known good files,” said Richard Rundle, CEO and Co-Founder of Airlock Digital. “With Airlock, these perceptions are no longer the reality.”

Airlock improves implementation time by interrogating a customer’s existing environment to allow security and operations teams to quickly populate whitelists and create security policies. Integrated file reputational lookups – provided in partnership with global file classification leader, ReversingLabs – makes ongoing administration of the solution simple and easy.

“The inclusion of reputational lookups from a trusted source significantly reduces the time for administrators to make decisions about whether to trust new files,” said Rundle. “Not all people administering endpoint and server protection are security specialists, so the risk levels posed by unknown files has to be easy to understand. With ReversingLabs, we add confidence to the process.”

In addition to integrated file reputational lookups, Airlock now boasts increased performance with a single instance able to manage in excess of 20,000 devices, restriction of access to specific networks, increased collection and reporting on file metadata, and support for AppX digital signatures making granular trust of Windows Store applications possible.

“As an Australian cyber security vendor, we understand the vital roles the ASD, the Australian Cyber Security Centre and AusCERT play in helping protect and defend the Australian economy from cyber threats,” said Airlock Digital Co-Founder, David Cottingham. “We’ve taken notice, understand the value and have built a solution from the ground up to meet the cyber security challenge head on – and we continue to investigate and research successful breaches, so we can learn from them.”

Trust, in file based security

Trust, it’s a fundamental concept in cybersecurity and plays a vital role in the decisions we make, particularly if a risk based approach is taken to decision making. However, we don’t often think about how the concept of trust influences our decisions. This blog post will explore what role trust plays, in file based security.

First, it’s important to note that trust is not a one size fits all concept and is unable to be applied equally across situations. For example, trust between family members must be thought of as a completely different concept to trust between networked computer endpoints.

The oxford dictionary defines trust as:

Noun: “Firm belief in the reliability, truth, or ability of someone or something”.
Verb: “Allow someone to have, use, or look after (someone or something of importance or value) with confidence”.1

Looking at the above definitions, neither truly describes the concept of trust, when applied to files. Let me propose a more suitable definition (taking some inspiration from the Noun above):

“Firm belief in the purpose, origin and expected behavior of a file or software package”.

Let me clarify this statement. In order to decide if you should ‘trust’ a file you must satisfy the following criteria:

1) Context – The file must exist to serve a particular purpose and be attributable to an application or function. Humans should ask, why does the file exist?
2) Predictability – The file must behave in a predictable and consistent way when executed or handled. Humans should ask, does the file behave in a manner that is expected, given its context?
3) Integrity – The file must provide assurance that it has not been modified or tampered with in an unauthorized manner. Humans should ask, does the file have integrity?

Fig 1. Three domains of file trust

Answering these questions for every file on an average operating system can prove to be a daunting task, one that would simply be unfeasible using manual processes. Ultimately, we must rely on frameworks which can assist in determining if ‘trust’ should be placed in a file, at scale.

Frameworks can take many forms, such as a threat intelligence feed, hashing algorithm or even a digital certificate validation mechanism. Regardless of their function, these frameworks must be robust, as we rely upon them to provide accurate information to inform our decisions.

Now you may be thinking, what if I don’t fully ‘trust’ (have a firm belief in the reliability, truth or ability) the framework I am using? Where possible you should aim to use more than one framework to provide multiple answers for the ‘context’, ‘predictability’ and ‘integrity’ of a file. Multiple answers provide opportunity to compare the results across frameworks to ensure truthful answers are provided.

Typically, vendors/operators attempt to answer these questions using one or more of the following methods:

1) Context:

  • Has the file been seen by a large amount of users?
  • Has the file been signed by a vendor?
  • Is the file located in the correct path?
  • Does the file have a description explaining it’s purpose?

2) Predictability:

  • When is the file invoked?
  • Does the file perform any unexpected behaviors when invoked? (loading interpreters, spawning/hooking processes etc)
  • Does the file request elevated permissions?
  • Does the file load into the expected process?
  • Does the file perform any system modifications? Drop files?
  • Does the file extension match its content?

3) Integrity:

  • Is the file digitally signed by a vendor?
  • Does the files hash value match a vendor provided hash value?
  • Has the file changed hash values since I have seen the file?
  • Does the files hash match a known good sample based on threat intelligence?

These methods are not an exhaustive list and barely scratch the surface, but hopefully provide a starting point for some ideas which can be used to determine if you should trust a file or not.

Airlock Application Whitelisting provides a robust solution enabling administrators to easily choose which files they should trust in an environment. Most importantly, Airlock incorporates multiple frameworks which are needed to quickly determine trust.



Airlock releases free document to test chained trust in EDR and Application Whitelisting solutions

Today Airlock Digital is releasing a free Microsoft Word document to test ‘Chained Trust’ in EDR and Application Whitelisting solutions. is where a product will trust a parent process (such as winword.exe) and automatically place trust in any spawned child processes.

Security products that are configured to use ‘Chained Trust’ may provide a reduced level of security.

This document contains Macro code, which attempts to drop either a .dll or .exe file in the documents working directory and execute it, allowing you to audit product configurations.

You can download the document here:
SHA256Sum: e39b1abff16db7a7f6d3b52e6d01d29dd423da0504358082acd1073e439c5723

Please let us know if you find this useful or have any feedback by contacting or @airlockdigital.

Proactively Detect and Prevent Petya Ransomware

The Petya ransomware outbreak represents an evolution in the sophistication of ransomware. Employing a number of different strategies for distribution and infection the Petya ransomware has impacted small and large organisations across the globe.

This outbreak is another reminder that signature based detection is not effective in todays threat landscape.

In this video you will see the execution of Petya on a victim endpoint and discover how application whitelisting with Airlock provides zero-day proactive protection against Peta and other ransomware variants.


Remember to click the Full Screen button on the video to get a better view of the product interface.

Whitelisting & the Ransomware Worm

Ransomware activity has been rising steadily over the past four years, providing a low cost and successful income stream for criminal organisations. Over the past weekend however, the game was changed with ‘WannaCry’.

Traditional ransomware typically ran on a single end user system, encrypting files that were accessible on local disks and sometimes mapped network shares. The reason WannaCry had such a significant impact is the ability to spread aggressively through network connected computers (be that locally or over the internet) using a recently discovered Microsoft Windows SMB vulnerability. This vulnerability was patched by Microsoft in March 2017.

Even though WannaCry represents a worrying evolution in Ransomware tactics, the software itself isn’t designed with stealth and security evasion in mind. Simply by creating / mutating a new piece of software, the ransomware initially went undetected by nearly all traditional security products. The likely strategy with WannaCry was to hit the world hard and fast, before traditional security technologies like Anti-Virus and Network Intrusion Prevention has time to catch up and write detection signatures. The reactive nature of traditional security technologies are highlighted by the sheer number of hosts infected during this incident.

The Australian Signals Directorate’s (ASD) Strategies to Mitigate Cyber Security Incidents places Application Whitelisting as the number one ‘essential’ strategy to prevent malware delivery and execution. During the execution of WannaCry, five executable files are dropped and executed on the victims system. With the installation process involving the downloading of ‘Tor’ software to facilitate payment. If these executable files were proactively prevented from running, the attack would simply fail.

Incidents such as WannaCry demonstrate the need for proactive security solutions that make it extremely difficult for attackers to run malicious code. Application Whitelisting represents the most effective and proactive strategy to detect and prevent these attacks.

David Cottingham presenting at ACSC2107

Airlock Co-Founder, David Cottingham, will be presenting at the Australian Cyber Security Centre on Wednesday the 15th of March at 2:30pm in the Bradman Theatrette.

Presentation Abstract:

There is a wealth of information in the security community today about what constitutes an indication of malicious activity within enterprise environments. Even if you are lucky enough to have a consensus regarding what you should be looking for each day, many organisations are simply not resourced to actively hunt and interpret activity within their environment. During this talk I will release a free Splunk application I have developed to make this challenge easier and also demonstrate some additional utilities I find invaluable.

Information on the new free Airlock Splunk App can be found here, and an updated version of the Airlock Whitelist Auditor can be found here.

Airlock v1.2 released with publisher support

Version 1.2 of Airlock includes the following new features:

– Publisher support for trusting signed executable and DLL files;
– Differential policies significantly reducing client network traffic; and
– Citrix VDI Environment support.

The addition of publisher support makes it even easier for customers to maintain application whitelists using Airlock.

David Cottingham, Co-Founder of Airlock, commented on the release “We are excited to release v1.2 of Airlock, making application whitelisting simple even in dynamically changing environments. Application Whitelisting simplicity and security is core to our mission at Airlock.”

Version 1.2 is now available for customers and partners in our customer portal.