Introducing the Cyber Concepts Series
The articles in this series are intended to be conceptual expositions on technical topics. Engineers and uber security analysts likely prefer far more nuanced details. The non-technical person will find these articles a bit of a stretch, straddling the fence between ‘too simple’ and ‘too much’. The ultimate purpose of this series is to provide readers reluctantly drawn into cybersecurity matters with enough building blocks to understand where things fit in the big picture and how the dots are connected. Articles will sacrifice ‘detailed perfection’ in favor of ‘good enough’ clarity. Of course, such things are subjective.
These Categories will Help Simplify Endpoint Security Product Evaluation
The terms, names, and jargon cumulatively found reading cybersecurity articles even confuse and befuddles the people that write them. For years, anti-malware vendors and researchers have gained 15 minutes of fame after naming a malware family or variant they discovered and analyzed. Now, there are zillions of them. The omnipresent keyword chaos literally complicates endpoint security.
The figure below categorizes the zillions down to four fairly mutually exclusive methods of malicious code methods of attack on enterprise interests.
Why use the Term “Malicious Code”?
After years of the industry referring to virus, worms, etc., it finally lumped them all together as “Malware”. Typically, it was the “Malware” that did all the bad stuff on the endpoints. Well, adversaries have been accomplishing their goals on enterprise endpoints without installing malware on them.
What are Non-Malware Attacks?
Application Exploit Attacks, the Traditional Approach
People wrote the applications and components of applications on our enterprise endpoints. They make programming mistakes. If there’s justice, some of these people will eventually wind up in hell. Some of these programming mistakes can theoretically be manipulated by third parties to seize control. We call these mistakes software vulnerabilities. When someone figures out how to actually do this, we call it an application exploit. Basically, the adversary delivers a file or blob to a target with the software vulnerability. After the application ingests the blog, there are enough malicious instructions loaded into the application that the remote attacker has effectively hijacked or partially hijacked the application.
Much of what you know about computers is perceived and tracked via the computer’s file system. Most endpoint protection tools see little to nothing beyond the file system. They are blind to the activities that never touch the file system. These take place in the computer’s memory among the many different processes running there. This blindness attracted the adversaries to these in-memory methods.
For example, one can inject malicious code into a legitimate process such as notepad.exe, temporarily transforming it into a remotely controlled weaponized tool. Malicious code attacks do not generally begin with in-memory methods. But, application exploits and non-malware attacks increasingly use in-memory methods.
What About “Fileless” Attacks?
Different people use this term differently. It is often necessary to ask someone to clarify what they mean by the term. “Fileless” can pertain to both “Non-Malware” and “In-Memory” methods. Worse, many “Fileless” attacks aren’t actually fileless; these often involve a weaponized document at the beginning and/or an executable somewhere near the end.
Social Engineering Malicious Code Attacks
This is a small subset of social engineering attacks whose intermediate goal is to install or merely run malicious code on an enterprise endpoint. They do so without exploiting a software vulnerability. Instead, they exploit something far more difficult to patch: employees. This involves tricking them to click here and there, usually upon fake prompts that exploit fear in the employee.
How does this Taxonomy Simplify Selecting Endpoint Protection Products?
Most tools have one or more mitigations for application exploits. Many have little to nothing for in-memory methods. Some products can only mitigate non-malware attacks by completely disabling the legitimate utilities, which were originally created to deliver validated value to the enterprise. These words are the bones for hard-hitting questions to vendors. Subsequent posts here will add flesh and cartilage.