AppJacking

Mitigating risk from endpoint apps

Zero-day attacks, breaches due to missing patches, weaponised documents, drive-by downloads, and some code injections are examples of AppJacking. Read on how to find out more about AppJacking concepts and understand better ways to mitigate these risks using Zero Trust principles within endpoints.

AppJacking is when adversaries hijack control of applications on endpoints via various ways to do harm to the enterprise using those and other applications. Familiar cyber stack elements struggle to deal with AppJacking, which are better recognised as zero-day attacks, breaches due to missing patches, weaponized documents, drive-by downloads, code injections, etc.


Why another cyber term? Because, regardless of how applications are hijacked, the term helps non-technical people better conceptualise the problem. The enterprise must now allow its applications to perform AppJacking actions.
You might be surprised at how non-technical these various actions can be summarised.

How does AppJacking Occur?

First, applications are processes on endpoints that execute instructions that manifest the functionality that we all use. AppJacking is the state whereby your applications execute an adversary’s instructions. Conceptually, we’ll look at three methods to hijack an application. Readers need not understand these methods for the remainder of this post.

Brief explanation of AppJacking methods

Vulnerability Exploit

A programming mistake in the source code is exploited such that malicious instructions are executed by the application. This is the cause of patch management.

Design Weakness

An application’s vendor failed to consider or anticipate how its application’s design could be used by adversaries to execute malicious instructions. Some percentage of weaponized document attacks take advantage of how Microsoft Office was designed, using legitimate macro and script engine functionality to harm.

Injection

Malicious instructions are written into memory or loaded into memory via malicious library files, requiring no flaw in the targeted application.


These Applications Might have been used to Harm your Enterprise in 2021


Here is a list of vulnerability exploits in the wild reported by Google’s “Project Zero” alone. It’s not a clearinghouse for all application zero-days. They do not claim to report all zero-day attacks observed in the wild by the entire cyber community.


• Google Chrome - CVE-2021-21148
• Adobe Reader - CVE-2021-21017
• Google Chrome - CVE-2021-21166
• Microsoft Exchange Server - CVE-2021-26855
• Microsoft Exchange Server - CVE-2021-26857
• Microsoft Exchange Server - CVE-2021-26858
• Microsoft Exchange Server - CVE-2021-27065
• Microsoft Internet Explorer - CVE-2021-26411
• Google Chrome - CVE-2021-21166
• Microsoft Internet Explorer - CVE-2021-26411
• Google Chrome - CVE-2021-21193
• Google Chrome - CVE-2021-21220
• Adobe Reader - CVE-2021-21220 {not a typo}
• Microsoft Internet Explorer - CVE-2021-33742
• Google Chrome - CVE-2021-30551
• Google Chrome - CVE-2021-30554
• Microsoft Internet Explorer - CVE-2021-34448
• Google Chrome - CVE-2021-30563
• Microsoft Internet Explorer - CVE-2021-40444
• Google Chrome - CVE-2021-30632
• Google Chrome - CVE-2021-30633
• Google Chrome - CVE-2021-37973
• Google Chrome - CVE-2021-37975
• Google Chrome - CVE-2021-37976


The above represent AppJacking via vulnerability exploits for which no patch existed before exploitation in the wild (a.k.a., zero-day attacks). One never knows whether other zero-days are attacking. It never ends.


AppJacking: Generalising the Actions within Endpoints


Why should these actions matter to you? Detection-based protection is far from perfect. Behavioural tools rely on pattern matching detection data to determine if an application’s action is legitimate or malicious. Whether the statistical confidence of a match is high or low makes all the difference. Clever attackers know this and season their techniques with extra actors and objects as well as time delays in-between stages to lower that statistical confidence. At best, that means more alerts for Level III analysts to analyze and investigate as well as IT-Ops to clean up the mess. At worst, detection is eluded entirely. Then again, if those AppJacking actions were not allowed, then attacks could be defeated without having to detect (i.e., recognize) them, which is why we’re summarizing them.


AppJacking performs the following generalised actions:

AppJacking Actions

Explanation

Downloads files to Disk

  • Instead of having the hijacked application perform all needed malicious instructions itself, it downloads and runs something else to do them

Launch/load files on disk

Alter critical system or application files already on disk

  • Modify something legitimate to gain an advantage
  • Ensure malware launches when host restarts

Read/steal data from the memory of OS or other Applications

  • Steal credentials and/or valuable data 

Inject malicious instructions into another App’s memory

  • Transform the same or another application into a hacker tool by filling it with numerous malicious instructions
  • Some applications, such as Chrome, are watched more than others, using Chrome to hijack another less-watched application to do the bulk of the malicious actions can be stealthier

Load malicious libraries into another App’s memory

Add/alter registry keys

  • Ensure malware launches when host restarts
  • Disable select security controls

Launch and use OS utilities 

  • Malicious files on disk might be detected
  • OS utilities can do the harm malicious files otherwise would do

Launch/use fileless processes 

  • Malicious files on disk might be detected, or cannot be written to disk
  • Numerous malicious instructions can be loaded into these

Receive and execute commands from remote adversary

  • Human controlled actions can adapt to the endpoint
  • Remote use of tools such as Cobalt Strike 

Transmit stolen data

  • China stole trillions of dollars of intellectual property this way

The above table is not intended to be all-inclusive.

Applied zero-trust principles can mitigate AppJacking risks

Each row in the “AppJacking Actions” table above characterises the different ways a hijacked application is used to do harm to the enterprise. Applying zero trust means using security controls that block these actions. The beauty of this approach means one doesn’t have to determine what is abnormal or malicious. No detection is needed! The result is real-time protection at early attack stages before endpoints are compromised and before detection alerts are generated that Level III EDR analysts must investigate.
Unfortunately, most EPP agents lack these capabilities or the ones they have are too administratively onerous.

Endpoint Protection Agent Mitigations to AppJacking


The table below characterizes different generic EPP capabilities and how they might or might not mitigate risks posed by AppJacking. Later, we’ll look at what they can and cannot do with regard to zero trust principles.


Different EPP Capabilities Related to AppJacking Risks

EPP Features

 

 

Patch Management

  • No longer considered a standard EPP feature
  • Eliminates or shields software vulnerabilities so applications cannot be exploited
  • Does not mitigate the other two AppJacking methods (i.e., design weaknesses, code injections)

Anti-Exploit

  • Injects code into applications striving to prevent AppJacking via vulnerability exploit; does nothing once an application is hijacked
  • No known empirical evidence on its actual contributions in the field; some analysts question whether it works in the wild

Signature Detection

  • Can prevent AppJacking if it recognizes a malicious file before it is loaded into the memory of the targeted application
  • File manipulation to evade detection is so easy that this seldom prevents AppJacking

Machine Learning File Detection

  • Analyses file for malicious instructions prevents AppJacking if malice is detected
  • Numerous obfuscation techniques are used to evade detection
  • Some EPP upload files for cloud analysis but do not do so for potentially weaponised documents due to privacy and data leakage concerns

Application Control

  • Applies only some zero-trust principles (see table below)
  • All implementations feature pre-launch but few do post-launch
  • Pre-launch blocks executable, script, and library file launch/loads, which can perform complex, harmful actions 
  • Post-launch (a.k.a., peri-launch) restricts applications’ file/folder read/write operations; less than 0.1% of enterprises use this due to complexities

Behaviour Detection (a.k.a., EDR)

  • Uses machine learning and heuristics to detect malicious behaviour
  • If detection has high statistical confidence, it terminates processes and quarantines files in milliseconds
  • When detection is low statistical confidence, it generates an alert for Level III analysts to investigate and respond while AppJacking actions proceed
  • If an alert proved valid, sometimes there is an automated clean-up, other times require manual clean-up
  • Google’s Project Zero says this in many of its zero-day exploit analyses, “These types of exploits are likely hard to detect generically”, or they make no recommendations for detection

Application Containment

  • Can only apply some zero trust principles (see table below)
  • Restricts the read/write actions of contained applications across two or more dimensions (file, registry, memory, children, privilege, network)
  • Microsoft Application Guard is the only EPP offering featuring this; it is free to all Windows enterprise licensees but less than 1% use it
  • There are various implementations enterprises can buy from other vendors

 

Zero-trust principles vs generic endpoint protection mechanisms


Again, applying zero trust principles to high-risk applications means not allowing them to perform the potentially malicious actions listed in the “AppJacking Actions” table above. These are tabulated below versus four types of tools an enterprise might have in its cyber stack.


Application Control is split into pre-execution and post-execution (a.k.a., peri execution) because few Application Control tools support post-execution and those that do are considered too difficult to use. Nonetheless, we can see what zero trust mitigations each could potentially apply to high-risk applications.


Covered/Missed Zero Trust Principles for AppJacking

Application Control (Pre-Execution)

Application Control (Post-Execution)

Behaviour Detection (EDR)

Containment

Downloads files to Disk

No

Yes

No

Yes

Launch/load files on disk

Yes

No

Maybe

No

Alter critical system or application files already on disk

No

Yes

Maybe

Yes

Read/steal data from the memory of OS or other Applications

No

No

Maybe

Yes

Inject malicious instructions into another App’s memory

No

No

Maybe

Yes

Load malicious libraries into another App’s memory

Yes

No

Maybe

Yes

Add/alter registry keys

No

Yes

Maybe

Yes

Launch and use OS utilities 

Yes

No

Maybe

Yes

Launch/use fileless processes 

No

Yes

Maybe

Yes

Receive and execute commands from a remote adversary

No

No

Maybe

Yes

Transmit stolen data

No

No

No

Yes


 

Behaviour Detection (a.k.a., EDR) is Not a Zero Trust Mechanism


The many “Maybe” answer for Behaviour Detection (a.k.a., EDR) demand explanation. An AppJacking attack might involve ten stages. If detection occurs at stage three, and if the detection is of high statistical confidence, then the Behavior Detection agent would terminate all processes identified in the attack within a second. This might or might not occur before stages four through maybe six, which means stages seven through ten never occur. The prevention of stages seven through ten might equate to one or more of the rows in the table above that would be blocked. But these are reactions rather than zero trust denials. And the behaviour detection agent wouldn’t explicitly block the actions of rows seven through ten. Instead, terminating related processes results in terminating those would-be actions. Behaviour detection is not a zero-trust mechanism from the default-denial perspective. Zero trust mechanisms are inherently deterministic: allow/deny specific actions.


Mitigate Appjacking AND reduce costs

Excellent medical care consists of preventative measures such as vaccines to avoid infection and detection methods to treat illnesses early. Enterprise cyber defence is likewise better with both. The detection tools defeat recognizable malware attacks. Instead of recognising malware, zero-trust tools defeat attacks by blocking their harmful actions. One can block what the other misses, or earlier than the other would. That’s excellent cyber defence.


With a zero-trust tool blocking what detection misses and blocking some detectable attacks before detection tools react, the addition of a tool that applies zero trust within endpoints reduces alert volumes of multiple detection tools in the cyber stack, which reduces workloads for the respective cyber teams. Also, zero trust controls within endpoints block attacks in real-time, which usually precedes endpoint compromise. Such tools alleviate workloads for those that must remediate endpoints when detection tools react after endpoint compromise.


Containment looks great, but is little deployed because most implementations are excruciating


This topic is worthy of its own blog post. In short, there are several different kinds of containment tools. Host sandboxing, not the same as network or cloud sandboxing, was a dumpster fire and was ripped out of enterprise endpoints years ago. Microsoft offers “Application Guard”, which employs process virtualization. This requires that application source code be modified so applications can pierce the boundaries to work across the endpoint. Few applications have been so modified. “Application Guard” is free with a Windows Enterprise license yet less than 1% of enterprises choose to use it. Bromium’s driver-based containment tool suffered the same fate as host sandboxing. Few if any EPPs include containment. One must get these from a 3rd party.


Zero-trust capabilities the enterprise needs to compliment detection defences


AppGuard combines “Containment” and “Pre-Execution Application Control”, which equates to all of the “Yes” entries in the table summarizing the harmful actions that result from AppJacking, detailed in the table at the bottom.


Minimal operational effort


AppGuard does not suffer nearly the operational difficulties of either Application Control or Containment tools from the past and present. AppGuard does require some tuning upfront and sometimes later if major changes are made to the host it protects. During a brief discovery phase, while policies are not enforced, one sees that one or a few legitimate applications require policy tuning. A little more tuning might be required in the first week or two of policy enforcement. This tuning effort is small and brief based on the observation that less than one per cent of policies in deployed agents differs from the vendor specified default policies.


AppGuard avoids the never-ending policy change quagmire of typical Application Control and Containment tools with its patented technology that ensures that the host agent automatically adapts to application changes. For example, to continuously mitigate AppJacking risks for say Google Chrome or Microsoft Word, other tools require that their policies be revised whenever those applications experienced an update, patch, or a new plug-in. AppGuard automatically adapts to such changes. AppGuard’s patented inheritance technology ensures that all of an application’s processes inherit the policies of their application parent. If the full pathname of the parent changes, then AppGuard might require a policy update. However, the full path names for Google Chrome and Microsoft Word have not changed in over a decade.


Even better, AppGuard’s inheritance technology also adapts to unanticipated malware technique changes. For example, if Microsoft Word should rely on an operating system component that handles PNG images, that component automatically inherits the containment controls. Consequently, if there were to be a zero-day exploit in the wild for that imaging component, the imaging component would inherit the containment from Microsoft Word, mitigating the AppJacking risks. AppGuard policy administrators do not have to anticipate such permutations. See the related blog posts for insight on how AppGuard technology avoids administrative burdens for its other use-cases and security controls.


All this means that AppGuard adds great non-detection-based protection for less effort than alternatives. AppGuard is an excellent zero trust complement to any detection defences of any enterprise.

More Detail on How AppGuard Mitigates AppJacking Risks

 

AppJacking Actions

AppGuard Mitigation

AppGuard Launch Controls

AppGuard Containment

Downloads files to Disk

 

Blocks write to sensitive places on a disk

Launch/load files on disk

Allows only trustworthy (e.g., digitally signed) executables, scripts, and/or library files to launch/load from high-risk folders

 

Alter critical system or application files already on disk

 

Blocks write to sensitive places on disk to sensitive places on a disk

Read/steal data from the memory of OS or other Applications

 

Restricts memory read/writes among applications and/or OS processes

Inject malicious instructions into another App’s memory

 

Restricts memory read/writes among applications and/or OS processes

Load malicious libraries into another App’s memory

Only libraries (i.e., DLL) signed by trusted publishers can load from high-risk folders

 

Add/alter registry keys

 

Blocks write to sensitive registry keys

Launch and use OS utilities 

Prohibits the use of OS utilities except by IT/Sec-Ops designated tools

Blocks read/write actions to files, registry, and memory for select OS utilities

Launch/use fileless processes 

Restricts select high-risk applications from launching unapproved tools or applications

Allowed child processes automatically inherit the containment restrictions of their parent application

Receive and execute commands from a remote adversary

 

Optional: restricts network communications, allowing pre-approved but denying unknown

 

The table above shows that AppGuard mitigates AppJacking risks by effectively blocking potentially malicious actions without having to guess good vs bad or normal vs abnormal. It is deterministic and it is effective at neutralizing AppJacking attacks.

Technology Spotlight
Related Stories
The Human Side of Breach Avoidance & Readiness
Rate the Article

Click the link below to rate this article

Rate this article
Have you seen...

Get all of the Azure migration tools and guidance you need to plan and implement your move to the cloud – and track your progress using a central dashboard that provides intelligent insights.

Watch Video
Related Articles