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 recognized 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 conceptualize 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 summarized.

Blog Summary

How does AppJacking Occur
Table: AppJacking Methods
These Applications Might have been used to Harm your Enterprise in 2021
AppJacking: Generalizing the Actions within Endpoints
Table: AppJacking Actions (i.e., conceptually, what defenses ought to block)
Ideally, Applied Zero Trust Principles can Mitigate AppJacking Risks
Endpoint Protection Agent Mitigations to AppJacking
Table: EPP Features (i.e., what they do against AppJacking)
Zero Trust Principles vs Generic Endpoint Protection Mechanisms
Table: Covered/Missed Zero Trust Principles for AppJacking
Behavior Detection (a.k.a., EDR) is Not a Zero Trust Mechanism
Adding Zero Trust WITHIN Endpoints to Cyber Defenses is Essential to Mitigating AppJacking Risks and Reducing Labor Costs
Containment looks Great but is little Deployed because most Implementations are Excruciating
AppGuard Delivers the Zero Trust Capabilities the Enterprise Needs to Complement Detection Defenses
AppGuard’s Operational Level of Effort is Minor Compared to Alternatives
Table: More Detail on How AppGuard Mitigates AppJacking Risks

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.

AppJacking Methods	Explanation
Vulnerability Exploit	A programming mistake in the source code is exploited such that malicious instructions are executed by the application. This is the cause for 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 do 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 is 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 prior to exploitation in the wild (a.k.a., zero-day attacks). One never knows whether other zero-days are attacking. It never ends.

AppJacking: Generalizing the Actions within Endpoints

Why should these actions matter to you? Clearly, detection-based protection is far from perfect. Behavioral 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 generalized 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 advantage Ensure malware launches when host restarts
Read/steal data from 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 more stealthy
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.

Ideally, Applied Zero Trust Principles can Mitigate AppJacking Risks

Each row in the “AppJacking Actions” table above characterizes 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.

EPP Features	Different EPP Capabilities Related to AppJacking Risks
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 actually 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	Analyzes 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 weaponized 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
Behavior Detection (a.k.a., EDR)	Uses machine learning and heuristics to detect malicious behavior If a 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)	Behavior 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 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 remote adversary	No	No	Maybe	Yes
Transmit stolen data	No	No	No	Yes

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

The many “Maybe” answers for Behavior 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 behavior detection agent wouldn’t explicitly block the actions of rows seven through ten. Instead, terminating related processes results in terminating those would-be actions. Behavior detection is not a zero trust mechanism from the default-denial perspective. Zero trust mechanisms are inherently deterministic: allow/deny specific actions.

Adding Zero Trust WITHIN Endpoints to Cyber Defenses is Essential to Mitigating AppJacking Risks and Reducing Labor Costs

Excellent medical care consists of preventative measures such as vaccines to avoid infection and detection methods to treat illnesses early. Enterprise cyber defense is likewises better with both. The detection tools defeat recognizable malware attacks. Instead of recognizing 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 defense.

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 of host sandboxing. Few if any EPPs include containment. One must get these from a 3rd party.

AppGuard Delivers the Zero Trust Capabilities the Enterprise Needs to Complement Detection Defenses

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.

AppGuard’s Operational Level of Effort is Minor Compared to Alternatives

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 up front 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 percent of policies in deployed agents differ 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 path name 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 defenses of any enterprise.

More Detail on How AppGuard Mitigates AppJacking Risks

AppJacking Actions	AppGuard Mitigation
AppJacking Actions	AppGuard Launch Controls	AppGuard Containment
Downloads files to Disk		Blocks writes to sensitive places on 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 writes to sensitive places on disk to sensitive places on disk
Read/steal data from 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 writes to sensitive registry keys
Launch and use OS utilities	Prohibits 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 remote adversary		Optional: restricts network communications, allowing pre-approved but denying unknown
Transmit stolen data

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.

AppJacking – Mitigating Risks from your own Endpoint Applications