Living off the land (LOL) malware techniques, which represent roughly 35% of enterprise attacks, use legitimate operating system (OS) utilities already on targeted hosts to breach enterprises. If they were simply removed, the remaining attack surface would be radically reduced. Unfortunately, doing so can severely impact your IT/Sec-Ops, users, applications, and the OS itself. Detection-based defenses (e.g., EDR) struggle mightily with these LOL malware techniques. This blog post provides non-technical folk an introduction to this challenge, including high-level pros and cons of some remedies.

Blog summary:

• Detection-based endpoint protection against LOL attacks often fails
• Can’t live with them (LOLbins); Can’t live without them (OS Utilities)
• Prohibit OS Utilities or Allow LOLbins? There are Middle Options
• Script Engines: if Prohibiting is Unacceptable, what then?
• Maintenance Windows can be Problematic for Small Organizations
• Pros/Cons of LOLbin Attack Surface Reduction Options
• AppGuard Reduces LOLbin Risks, Gives IT/Sec-Ops Flexibility
• More on AppGuard Mitigating Risks from OS Utilities Yet Affording IT/Sec-Ops Flexibility

Detection-based Endpoint Protection against LOL Attacks often Fails

LOL attacks often evade other detection defenses, such as signature and heuristic. Behavioral detection-based defenses (a.k.a., EDR) reliably identify simple LOL techniques and swiftly react to them. These are high statistical confidence matches. However, EDR is fooled by LOL techniques mimicking legitimate workflows, operating in memory only, and/or introducing time-delays between attack stages so one stage is not associated with another to form a pattern. These represent statistical confidence matches too low for automated response and require costly human expertise to investigate and respond. Behavioral detection is certainly an improvement for the roughly 40% of enterprises that have adopted it.

Can’t Live with them (LOLbins); Can’t Live without them (OS Utilities)

In Windows, disabling WMI would cripple the OS. End-users that must run macros and scripts via Microsoft Office would be impacted if select OS utilities were prohibited. Most IT/Sec-Ops personnel depend on PowerShell. However, cyber defenders refer to these useful OS utilities as “LOLbins”, which cyber adversaries weaponize against the enterprise.

Prohibit OS Utilities or Allow LOLbins? There are Middle Options 

Symantec reported an observation that 80% of OS utility usage was legitimate. Completely prohibiting OS utilities clearly impacts legitimate operations. Not restricting them at all allows the other 20% of observed usage as LOLbins that harm the enterprise. 

Generally, the enterprise needs options in between ‘allow all’ and ‘prohibit all’ such as:

• Restrict use to demonstrably trustworthy uses when needed
• Restrict allowed actions when in use

Blocking OS utility post-launch actions significantly reduces attack surface but does not completely eliminate risk. Prohibiting a utility is safest. However, when security and operation needs disagree, these ‘in-between’ options are best.

The following bullets in this sub-section might not interest you but would appeal to your tech people:

• Allow select Apps and their child processes to use select OS utilities
• Temporarily suspend some or all controls under specific circumstances

For restricting OS utility post-launch actions after they start running, controls should block: 

• Read/write sensitive folders or registry keys
• Read/write memory of other Apps
• Launch of high-risk Apps (or none at all)

Script Engines: if Prohibiting is Unacceptable, what then?

Script engines such as PowerShell, CMD, WMI, Visual Basic, Bash/shell, Python, PHP, and others are the Swiss Army knives of OS utilities. They can do just about anything. To do so, they need to ingest instructions that can either be entered into a user interface or read from a script file. Adversaries routinely use script engines to perform malicious actions. 

Enterprises that reduce the attack surface from script engines prohibit them from running (selectively or always) and/or deny script engines read access to script files in high-risk folders. The latter is far more common than the former. 

As for “in-between'' options, some enterprises use OS settings to limit what script engines can do. We believe less than 1% of enterprises have and use Application Control tools to limit what actions script engines can do, such as perform write operations into sensitive folders, registry keys, or the memory of other applications. Some such tools can also restrict what OS utilities that script engines can launch. 

Maintenance Windows can be Problematic for Small Organizations

IT/Sec-Ops use maintenance windows to make major changes to endpoints, usually while protections are disabled to avoid interference. These allow IT/Sec-Ops to use any OS utility to do whatever. Large organizations often have sufficient redundancy to accommodate taking servers offline; smaller ones often do not. Laptops and desktops pose additional challenges. Some attack surface reduction tools allow OS utility use without disabling all controls. Some can temporarily disable all protection controls on-demand (i.e., discrete triggers). Be sure your IT/Sec-Ops people consider their use-cases when selecting such tools. 

Pros/Cons of LOLbin Attack Surface Reduction Options

AppGuard Reduces LOLbin Risks, Gives IT/Sec-Ops Flexibility

AppGuard can selectively and conditionally prohibit OS utilities (a.k.a., LOLbins) so users and IT/Sec-Ops can use them when needed but adversaries cannot. 

As for “in-between” options, AppGuard can apply containment policies to script engines or other OS utilities that limit what they can do instead of prohibiting them entirely. Additionally, if your IT/Sec-Ops are using OS settings to limit the actions of OS utilities, AppGuard can apply isolation policies to them so adversaries cannot alter them. If there are use-cases where AppGuard policies allow select IT/Sec-Ops tools to do whatever they want are not flexible enough, AppGuard provides ways for IT/Sec-Ops and power users to temporarily disable protections to make system changes.

AppGuard is an excellent complement to EDR/EPP tools. They do what they do best: detect what can be detected. AppGuard blocks attacks for which detection-pattern data does not yet exist in the cyber community. Instead of looking for bad behavior, AppGuard allows only good behavior. AppGuard does so by compartmentalizing endpoints with launch, containment, and isolation controls. Metaphorically, imagine that malware is a car that must drive from point A to point B along a zig-zag path passing through different neighborhoods (i.e., legitimate applications and OS utilities). AppGuard would be the concrete barriers and gates that do not allow the malware car to get to point B. Malware is blocked without having to recognize it. EPP/EDR tools only succeed if and when attacks are recognized, making AppGuard an excellent complement. 

More on AppGuard Mitigating Risks from OS Utilities Yet Affording IT/Sec-Ops Flexibility