Mitigating risk from endpoint apps
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.
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.
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. |
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.
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 Actions |
Explanation |
Downloads files to Disk |
|
Launch/load files on disk |
|
Alter critical system or application files already on disk |
|
Read/steal data from the memory of OS or other Applications |
|
Inject malicious instructions into another App’s memory |
|
Load malicious libraries into another App’s memory |
|
Add/alter registry keys |
|
Launch and use OS utilities |
|
Launch/use fileless processes |
|
Receive and execute commands from remote adversary |
|
Transmit stolen data |
|
The above table is not intended to be all-inclusive.
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.
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 |
|
Patch Management |
|
Anti-Exploit |
|
Signature Detection |
|
Machine Learning File Detection |
|
Application Control |
|
Behaviour Detection (a.k.a., EDR) |
|
Application Containment |
|
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 |
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.
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.
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.
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 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.
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.
10 PRO TIPS
Let us know what you think about the article.