Airlock Digital announces plans for growth, expansion with investment from CyberCX

Adelaide, 28 June 2022 Airlock Digital, a world-leading solution for application allowlisting, has today announced plans for further growth and expansion following an investment from CyberCX, Australia and New Zealand’s largest cyber security services firm.

Founded in Adelaide in 2014, Airlock has become the preferred allowlisting solution for a growing number of enterprise organisations and government agencies in Australia, New Zealand (ANZ) and globally, achieving rapid growth and earning a strong reputation for its innovative solutions and customer success.

Allowlisting is considered one of the most effective security strategies to prevent threats such as ransomware and malware from infecting an organisation’s systems, and is recognised in standards such as the Australian Cyber Security Centre’s Essential 8 mitigation strategies, the Canadian Centre for Cyber Security’s Top 10 IT Security Actions and the Center for Internet Security’s Basic Six. Despite being an essential security measure, allowlisting has traditionally been expensive and laborious to implement and maintain.

Airlock offers a unique solution to these issues, using smart workflows to significantly reduce maintenance time, enabling organisations to effectively and efficiently use allowlisting within their suite of cyber security measures.

Airlock already has an established customer base in the US, supporting customers to implement effective allowlisting and application controls. With this new investment, Airlock intends to accelerate an ambitious global growth strategy, expanding its presence in the North American and European markets and launch a new software-as-a-service (SaaS) offering.

This investment will also assist Airlock in growing its already strong network of channel partners, leveraging Airlock’s enhanced allowlisting solution for managed service providers (MSPs).

Airlock CEO David Cottingham said today’s announcement is a milestone event for the company, “This investment will fuel unprecedented growth for us and accelerate market adoption of our proven platform, further empowering us to deliver forward thinking endpoint protection for customers around the world.

“We’re excited to partner with a market leader like CyberCX that has deep expertise and experience in solving cyber security challenges with a broad range of customers, across the ANZ region and beyond.

“With CyberCX providing further access and insights into the market, we will be able to deliver on Airlock’s ambitious growth plan even faster.” Cottingham added.

In confirming the company’s investment in Airlock Digital, CyberCX CEO John Paitaridis said the company strongly backs Airlock’s growth strategy and is committed to helping accelerate their expansion into international markets, “As the region’s leading cyber security services firm, CyberCX is committed to supporting Australian cyber security technology companies through strategic partnerships and investment.

“We want to support cyber security innovators with truly exceptional platforms like Airlock, become global cyber technology leaders and take on the world.” Paitaridis added.

About Airlock

Airlock enables customers to easily create and manage secure allowlists (formerly application whitelists) in dynamically changing computing environments. Airlock technology is practitioner built, from real world experience, enabling organisations to operationalise allowlisting without negatively impacting their business.

About CyberCX

CyberCX is the leading provider of cyber security services across Australia and New Zealand. With a workforce of over 1000 cyber security professionals, CyberCX is a trusted partner to private and public sector organisations, helping customers confidently manage cyber risk, respond to incidents and build resilience in an increasingly complex and challenging threat environment.

Preventing Ransomware and Zero Days Using an Overlooked Basic Security Control

Continued successful exploitation of the software supply chain

As the world continues to assess the scope of the biggest global ransomware attack on record – with the REvil/Sodinokibi group claiming to have infected over one million systems, outpacing even WannaCry from 2017, it is becoming clear that ransomware continues to be a successful business model for criminal groups and poses as a significant risk to businesses and government organisations. 

Just this month, Australian businesses UnitingCare Queensland and JBS Foods became the latest victims of ransomware and the exploitation of a vulnerability on the US based managed services platform provider Kaseya showed continued escalation of successful attacks targeted on the software supply chain.

While the full impact of the attack is still undergoing investigation, the Australian Cyber Security Center has confirmed that at least three Australian MSPs had been affected by the attack and had customers data encrypted.

The PrintNightmare that won’t go away

Continuing to make big news for the last couple weeks is the PrintNightmare privilege escalation vulnerability (CVE-2021-167, CVE-2021-28344) which refuses to go away despite multiple patches from Microsoft and mixed messaging with-in the the information security community on how to effectively mitigate vulnerability in the Windows Print Spooler service.

How did this Happen?

REvil Ransomware delivered via Kaseya Platform

For the Kaseya supply chain attack the REvil group used the Kaseya Agent software itself to distribute malware, going through a variety of steps before executing the file “agent.exe” which had been signed with a likely stolen certificate.

The payload distributed by the REvil group using Kaseya platform

When executed the file extracted an old copy of Windows Defender binary “msmpeng.exe” and a DLL file “mpsvc.dll” which is the actual ransomware payload. The agent then starts the Windows Defender binary which sideloads payload the DLL and the machine contents are encrypted.

Whats HapPen? Workstation after being ransomwared by REvil on Kaseya platform

PrintNightmare delivered via user action

Looking  into the recent PrintNightMare vulnerability (CVE-2021-167), we can observe that that either locally or remotely an unprivileged user can escalate their privileges to SYSTEM by calling the AddPrinterDriverEx API call, delivering malicious code that will then be executed as a DLL on the target.

A malicious DLL file being loaded by the printer service, creating a new local adm1n user

In both these cases, these vulnerabilities rely on the deployment of malicious code using trusted processes. These are run with system privileges by executing malicious .dll files and even used PowerShell (trusted system process) to turn off Microsoft Defender.

The Race To The Fix

As security professionals across the world scramble to apply patches, mitigations and IOCs to their security suite, is there a security control that is able to prevent such threats from happening in the first place? 

Yes, Allowlisting  – A long forgotten friend

One of these foundational controls, Allowlisting (formerly Application Whitelisting), is a security strategy that involves only allowing applications trusted by an organisation to run and then blocking all other files. This an alternative strategy to a signature based blocklisting approach of allowing everything to run by default and only blocking what’s known to be bad (eg anti-virus).  

Allowlisting is not a new idea; it has been around for a long time and has been regarded as one of the most effective controls against threats like ransomware, fileless malware and lateral movement. Yet it is also one of the most overlooked security controls and is often put on the backburner. Most organisations that are not mandated by the ACSC Essential 8 framework, do not feel inspired to pick it up. This is mostly due to the first-hand experience people have had or have heard of, with Allowlisting taking an excruciatingly long time to implement and at some point, or another, resulting in situations of heated user disruption (especially with the dev team).

No security practitioner wants to devote huge amounts of skilled resources and time into implementing a security policy which at the end results in major BAU interruptions. Apart from problems with implementation, there are also significant gaps in the majority of allowlisting solutions like:

  • Focusing only on controlling applications (.exe files) when adversaries are utilising .dll and script-based processes to deploy payloads
  • Policies not applying to privileged user groups like admin and system accounts (exploited in these recent attacks)
  • Confusing Allowlisting with privilege access management and often mixing the two together
  • No way to make temporary exceptions to run unapproved apps that are needed urgently

Do these problems and gaps still hold up in 2021? 

The answer is no. 

Airlock Digital, an Australian company, created by security practitioners who were implementing allowlisting solutions at federal government organisations and seeing the traditional problems first hand. Taking these learnings, they developed a solution that covers these gaps and busts the myth that allowlisting is simply too hard to do. 

This is made possible through features like:

  • Workflow driven processes to trust applications quickly and easily;
  • The ability for all IT staff to learn and manage the allowlist, with no previous security experience required;
  • Allowlisting that applies to all security contexts (including admin & system);
  • Comprehensive self managed policies which include .dll files and scripts;
  • Blocklist rules to perform system hardening and prevent the execution of legacy software; 
  • Blacklisting policies that block malicious use of core system processes like PowerShell 
  • End to end average deployment time to enforcement mode of 3-4 weeks.

With comprehensive policies in place, threats like REvil ransomware and zero day exploits like Kaseya & PrintNightmare, will automatically be blocked because the publisher of the executables, and the .dll files that are run afterwards, are simply not approved to run in the environment.

Airlock preventing untrusted DLL being loaded by Windows Print Spooler

This avoids a lot of panic and saves time from trying to find a fix for zero days that are regularly found. Here’s what one of Airlock’s customers recently said in the light of the recent attacks:

“Airlock Digital worked great for the Kaseya ransomware threat last weekend. While we were not hit, we use Kaseya, and after analysing the Indicators of Compromise, our Airlock Digital Allowlisting solution would have blocked the main applications used for delivery of the code even though they were delivered using Kaseya and MS defender. Airlock also allowed us to react quickly by blocklisting the malicious and known indicators of compromise as they were being identified.”

Airlock preventing untrusted agent.exe extractor being called. If this would be allowed, the subsequent DLL sideload would also have been blocked.

Conclusion

While there is no silver bullet to cyber risk and defence in depth is always best practice, performing basic security practices like Allowlisting right, can go a long way in proactively stopping breaches. 

If you would like to know more about Allowlisting and how it can make a difference in your security posture, contact Airlock Digital at [email protected].

Opinion: Why the Information Security Manual (ISM) Control ‘1471’ isn’t practical for allowlisting at scale

TLDR; Take a look at the tables containing Product Names for Adobe Acrobat DC in this article, the variations in product names are staggering.

Overview

At Airlock Digital, we often hear from new and existing Australian customers regarding the Australian Government Information Security Manual (ISM) control 1471. In particular, customers ask how they can achieve compliance with this control using the Airlock allowlisting platform.

The control was first introduced in 2019 and reads as follows:

Security Control: 1471; Revision: 2; Updated: Apr-20; Applicability: O, P, S, TS
When implementing application control using publisher certificate rules, both publisher names and product names are used.
Source: https://www.cyber.gov.au/acsc/view-all-content/ism

This article will describe the practicality of allowlisting using this rule type at scale. Allowlisting is the process of choosing which files you trust and blocking everything else on an endpoint. 

The Intent

The intent of this control is clear, ensure companies are reducing the attack surface of publisher rules by tying them to specific products. This does two things:

  • Ensures that administrators are only allowing specific applications rather than trusting any file a company digitally signs; and
  • Reduces the attack surface when a certificate compromise at a software vendor occurs, constraining the ability for an attacker to run signed malicious code in an environment (unless the attacker knows the customers ruleset of course).

Sounds straightforward right? Ultimately it is good security advice. However, in reality, practical implementation and management of this control is near impossible in dynamic computing environments (any environment with users), regardless of the allowlisting technology used.

The working example I’m going to use in this article is a fairly common one. Let’s say the organisation wants to allow Acrobat Reader DC, on the surface it would seem as simple as trusting ‘Adobe Inc’ as the publisher and then ‘Acrobat Reader DC’ as the product name.

The Data
Let’s take a look at the files that make up an Acrobat Reader DC installation. Executable files in the application are all signed by the publisher ‘Adobe Inc.’, which is a great start. The following table displays all executable files with their associated product names:

Executable Name Product Name
AcroCEF.exe
SingleClientServicesUpdater.exe
WCChromeNativeMessagingHost.exe Adobe Create PDF
32BitMAPIBroker.exe Adobe Acrobat 32BitMAPIBroker
64BitMAPIBroker.exe Adobe Acrobat 64BitMAPIBroker
FullTrustNotifier.exe
Acrobat.exe Adobe Acrobat DC
Acrobat.exe Adobe Acrobat DC
AcrobatInfo.exe Adobe Acrobat DC
acrobat_sl.exe Adobe Acrobat
AcroBroker.exe Adobe PDF Broker Process for Internet Explorer
AcroTextExtractor.exe Adobe Acrobat text extractor for non-PDF files
ADelRCP.exe ADelRCP Dynamic Link Library
AdobeCollabSync.exe
CRLogTransport.exe CRLogTransport Application
CRWindowsClientService.exe Adobe Crash Reporter Service
Eula.exe EULA
LogTransport2.exe LogTransport Application

Table 1: Acrobat Reader DC Executable Product Names

 

Let’s now take a look at application library names, keeping in mind that all listed files are signed by ‘Adobe Inc’:

Application Library Name Product Name
chrome_elf.dll Chromium
icudt.dll International Components for Unicode
libcef.dll Chromium Embedded Framework (CEF) Dynamic Link Library
nppdf32.dll Adobe Acrobat
nppdf32.dll Adobe Acrobat
Acrobat32OL.dll
Onix32.dll Onix
ACE.dll ACE 2020/12/23-20:41:48
AdobeXMP.dll Adobe XMP Core 2020/06/15-10:20:05
AGM.dll AGM 2020/12/23-20:41:48
AIDE.dll AIDE 2020/08/13-20:41:23
BIB.dll BIB 2020/12/23-20:41:48
BIBUtils.dll BIBUtils 2020/12/23-20:41:48
CoolType.dll CoolType 2020/12/23-20:41:48
JP2KLib.dll JP2KLib 2021/01/15-07:39:31
A3DUtils.dll 3D Utilities Library
ACE.dll ACE 2020/12/23-20:41:48
Acrobat.dll Adobe Acrobat DC
AcrobatRes.dll Adobe Acrobat DC
adobeafp.dll Adobe Acrobat File Preview
AdobeLinguis…  Adobe Linguisitc Library
AdobeXMP.dll Adobe XMP Core 2020/06/15-10:20:05
AGM.dll AGM 2020/12/23-20:41:48
ahclient.dll AdobeHelp Dynamic Link Library
AIDE.dll AIDE 2020/08/13-20:41:23
ANCUtility.dll Adobe Acrobat
AXE8SharedEx…  AXE8SharedExpat 2020/12/23-09:04:30
AXSLE.dll AXSLE 2020/06/16-12:37:28
BIB.dll BIB 2020/12/23-20:41:48
BIBUtils.dll BIBUtils 2020/12/23-20:41:48
ccme_asym.dll RSA BSAFE Crypto-C ME
ccme_base.dll RSA BSAFE Crypto-C ME
ccme_base_no…  RSA BSAFE Crypto-C ME
ccme_ecc.dll RSA BSAFE Crypto-C ME
CoolType.dll CoolType 2020/12/23-20:41:48
CRClient.dll Adobe Crash Reporter Client DLL
cryptocme.dll RSA BSAFE Crypto-C ME
DirectInk.dll DirectInk
ExtendScript…  ExtendScript 2019/07/29-10:07:31
icucnv58.dll
icucnv67.dll International Components for Unicode
icudt58.dll
icudt67.dll International Components for Unicode
icuuc58.dll
icuuc67.dll International Components for Unicode
JP2KLib.dll JP2KLib 2021/01/15-07:39:31
logsession.dll LogSession
PDFPrevHndlr…  Adobe PDF Preview Handler
pe.dll PE
ReaderUC.dll
rt3d.dll 3D Runtime Dynamic Link Library
ScCore.dll ScCore 2019/07/29-10:07:31
sqlite.dll sqlite Dynamic Link Library
ViewerPS.dll Acrobat Viewer ProxyStub Library

Table 2: Acrobat Reader DC Application LibraryProduct Names


Looking at the tables above, you can start to see the scale of the challenge due to the significant variation in product names across files.

The Challenges

Challenge One: Software is nearly always more than a single executable file

Software comes in many shapes and sizes and is nearly always composed of multiple executable files and application libraries (.dll’s). Additionally, third party software is bundled within software which can be seen above, with Chromium dll’s shipped with Adobe Acrobat DC and signed by Adobe Inc.

This may be manageable when allowlisting executable files only (I’m looking at you default AppLocker deployments). However, if a customer intends on achieving Maturity Level Two or greater for application control on the ACSC Essential eight maturity model, the sheer number of files and application libraries that need to be handled to allow a single product to run can be overwhelming.

In order to allow Acrobat Reader DC via product names:

  • 13 rules would be required for executables; and
  • 45 rules would be required for application libraries.

This could be cut down with creative wildcarding, however if you are allowing the product name ‘*Adobe*’ it defeats the purpose of the ISM control 1471 in the first instance.

Challenge Two: The Product Name field can be blank

As you can see from the above files, many of them contain a blank Product Name field as it is an optional entry for developers at the time of software compilation. This makes the original ISM rule impossible to apply on these files and they effectively require an exemption.

Challenge Three: Scale and Maturity

Extrapolating the above data out, it is easy to see how the scale of rules required is staggering. Additionally, maintaining this ruleset through application updates (note that Adobe uses compilation dates in a number of files above) makes management near impossible, regardless of the technology used even with automated and slick product workflows.

Proposed Compensating Control

So if this isn’t practical? What can be done to achieve the intent of the control?

Combining Publisher and Path rules is an alternative and has the following benefits:

  • Typically only one or two rules are required per application, as applications are often located in static paths;
  • Applications are easier to identify and group by paths and avoids the confusion of trusting ‘Chromium’ signed by ‘Adobe Inc.’ as shown in Table 2 above;
  • The ability for an attacker to execute code in an environment with a stolen code signing certificate is still reduced as signed malware must be dropped in the relevant directories.

Airlock Digital appreciates the guidance ACSC provides with the ISM, which continues to drive the maturity uplift of organisations. Proposing the above compensating control is not intended to water down the security requirements of 1471, it’s simply an alternative to customers not being able to comply due to administrative overhead.

Airlock Recommendations

Organisations can use the Airlock Blocklisting rule engine to achieve compliance with this control. In the event organisations are struggling to comply due to management overhead, Airlock recommends customers consider the implementation of publishers and path rules as an alternative.

Each organisation should use a risk based approach when assessing if this alternative is right for them.


Fig 1: The Edit Blocklist Metadata Rule Window


Shown in the Window above is a rule that applies to any file containing ‘Adobe Inc’ as a publisher and is not part of the default ‘Acrobat DC’ folder path. Since Blocklisting is a negative match, files that are signed by Adobe Inc and are located outside of this folder path will be blocked.

Author: David Cottingham

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 – https://jxy-s.github.io/herpaderping/.

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!

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

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.

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

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: https://risky.biz/RB573 – 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.

Footnotes

1. https://en.oxforddictionaries.com/definition/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: https://www.airlockdigital.com/AirlockApps/Airlock_Application_Whitelisting_Macro_Security_Auditor_v1.0.doc
SHA256Sum: e39b1abff16db7a7f6d3b52e6d01d29dd423da0504358082acd1073e439c5723

Please let us know if you find this useful or have any feedback by contacting [email protected] 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.