Cybersecurity is a vast, ever-growing field with new attacks and malware coming up every year. 2017, apparently, was he year of non-malware attacks and they are one the rise.
Non-malware-based cyberattacks were behind the majority of cyber incidents reported in 2017, despite proliferation of malware available to both the professional and amateur hacker.
Non-malware, or file-less, attacks using PowerShell and Windows Management Instrumentation tools, normally utilized by IT staffers along with exploiting exploit in-memory access and running applications, like web browsers and Office applications, were used in 52 percent of all attacks, according to security company Carbon Black.
Non-malware attacks have been in the news a lot recently. Let’s take a step back and understand what we are up against and what can be done.
A non-malware attack is one in which an attacker uses existing software, allowed applications and authorized protocols to carry out malicious activities. Non-malware attacks are capable of gaining control of computers without downloading any malicious files, hence the name. Non-malware attacks are also referred to as fileless, memory-based or “living-off-the-land” attacks.
With non-malware attacks, an attacker is able to infiltrate, take control and carry out objectives by taking advantage of vulnerable software that a typical end user would leverage on a day-to-day basis (think web browsers or Office-suite applications). Attackers will also use the successful exploit to gain access to native operating system tools (think PowerShell or Windows Management Instrumentation – WMI) or other applications that grant the attacker a level of execution freedom.
These native tools grant users exceptional rights and privileges to carry out the most basic commands across a network that lead to valuable data.
Let’s take a look at an example attack:
1. A user visits a website using Firefox, perhaps getting a link from a phishing email.
2. On this page, Flash is loaded. Flash is a common attack vector due to its seemingly never-ending set of vulnerabilities.
3. Flash invokes PowerShell, an OS tool that exists on every Windows machine, and feeds it instructions through the command line — all operating in memory.
4. PowerShell connects to a stealth command and control server, where it downloads a malicious PowerShell script that finds sensitive data and sends it to the attacker This attack never downloads any malware.
In this way, the whole kill chain can be conducted without installing anything or dropping any binary to disk. When we talk about non-malware leveraging built-in tools like PowerShell or FTP or Remote Desktop the attack is using something that system admins would normally use anyway. Non malware attacks work because they are following the path of least resistance.
Many current endpoint security solutions (such as traditional antivirus and machine-learning antivirus) do nothing to prevent (or even detect) non-malware attacks, providing attackers with a point of entry that goes completely overlooked.
Traditional antivirus and machine-learning antivirus are designed to only identify threats at a single point in time – when a file is written to disk. Since they only look at the attributes of an executable file, they are completely blind in the face of attacks where no files are involved – as is the case with non-malware attacks.
If the goal of an attack is to gain a foothold or exfiltrate valuable data, then non-malware attacks accomplish this goal without fear of detection, especially when organizations are relying on legacy AV and machine-learning AV.
Defending against NM attacks :
Detecting non-malware intrusions requires more than just looking at files; it requires monitoring processes. The easiest approach, but not the be all and end all, is to look at the relationship and the command line. As soon as you can see PowerShell being used, you have to ask, why would a Powershell get spawned when what you are using is MS Word? You have to look at the context where the more traditional approaches just look at the individual programs that are running.
A second approach is to look at the content of the command line. What usually happens from an attacker is a bunch of arguments get pasted onto the command line, and the script itself is usually encoded with some encryption scheme, so it just looks like random characters rather than English text.
A third approach looks at the execution of the script. You should think of the running processes like an iceberg – be aware that what you are looking at is usually just the tip of the iceberg. So once PowerShell starts running, you check to see if it is behaving normally. Is it trying to access a large number of files in a very short space of time; or perhaps trying to communicate outside of the network? Both of these would be considered unusual and should be blocked.
The key is in establishing what is normal behavior. If you set the bar too high, then uncommon rather than abnormal will be blocked, and business processes will be disturbed. If you set it too low, then malicious activity can proceed undetected. The solution is a continuous learning process, tweaking the system to gain the optimum performance in line with the user's individual risk posture. On this basis we can chose to allow, alert or block.
But as a rule of thumb, the more the user can whitelist processes the stronger will be the defense. As an example if it is known that the only valid use of PowerShell is a particular script from IT that runs at a set time each night to update applications across the system, then this can whitelisted and allowed, and all other uses of PowerShell will automatically be blocked. In this scenario, the PowerShell wouldn't even get out of its macro.
Until next post stay tuned !!!