Criminals frequently get caught because they leave evidence at the scene of the crime—fingerprints, DNA, and the like. Cybercriminals are no different, often leaving files behind on the systems they infect.
In an effort to reduce the evidence left behind after an attack, cybercriminals developed fileless malware, a variant of computer-related malicious software that exists exclusively as a computer memory-based artifact. In short, the infection or malware does not write any executable files to the infected system’s hard drive.
By leaving few traces behind, malware authors try to postpone detection by security vendors for as long as possible.
During the past few years, the use of fileless infection has been adopted by numerous forms of malware and advanced persistent threats (APTs). These fileless infection chains can employ multiple techniques to deliver the final payload. In one example, the Kovter Trojan stored the payload in a Windows registry. The Hancitor Trojan wrote a payload in the hollow process spawned by shellcode injected from a Word document macro in a Microsoft Word process.
Lately, we have been seeing an increase in fileless infection techniques that are leveraging legitimate applications available in the victim’s machine. These techniques do not rely on storing executable files and leave no direct traces on disks, making detection and removal a challenge. In this blog, we will discuss the recent malware campaigns that have used fileless infection mechanisms leveraging legitimate applications.
Figure 1: Stats showing hits of fileless infection chains
Case 1: njRat Backdoor
Although njRat has been around for a long time, we recently observed that this backdoor is being loaded by a fileless infection chain. A .docx file is received as an attachment in a phishing email by the victim. Once the .docx file is opened, the infection cycle begins.
Figure 2: The njRat payload loaded by fileless infection
The .docx file contains external references to remote OLE objects to be referenced in the “document.xml.rels,” which is a Rich Text Format (RTF) exploit CVE-2017-0199 that further opens the embedded .doc file containing a Visual Basic for Applications (VBA) macro.
Figure 3: The .docx downloading an RTF file
The VBA macro contains an encoded PowerShell script. It downloads the VBScript from “www[.]m9c[.]net/uploads/15676549681.jpg.” The VBScript then decodes and executes the embedded PowerShell script. The PowerShell script then downloads the encrypted Portable Executable (PE) file from “www[.]m9c[.]net/uploads/15676547971.jpg,” which is the njRat executable.
Figure 4: The VBS PowerShell downloads an encoded PE file
This VBScript decrypts the PE file, which is a .NET executable that is directly loaded in the memory and runs in the context of an MSbuild.exe. No traces of a disk write are observed and the backdoor njRat silently executes under the hood by communicating with the CnC server “borapegar147[.]ddns[.]net”.
Case 2: Sodinokibi Ransomware
The Sodinokibi ransomware (also known as REvil) is one of the most well-known ransomware types in the wild today. It has been on the rise since the threat group behind the malware operation GandCrab announced that it had shut down its operations at the end of May. Recently, we have noticed that Sodinokibi has adopted a fileless mechanism.
Figure 5: The Sodinokibi payload loaded by a fileless infection
The fileless infection cycle starts when the victim clicks the BAT file that is received as an attachment in a phishing email. The BAT file contains a PowerShell script containing Base64 encoded expressions.
Figure 6: The BAT file received via MalSpam
As shown below in the decoded PowerShell script, this script downloads another PowerShell script containing more than 3,000 lines of code and a Base64-encoded portable executable file (PE) from a pastebin URL and loads it while invoking a function that initiates the attack in the system's memory.
Figure 7: The decoded PowerShell expressions
Figure 8: The encoded PE file in PowerShell downloaded from the pastebin
This script decodes and provides the PE file to a loader function, which takes care of injecting this file directly into the system's memory. The loaded PE file, which appears to be a DLL, is actually Sodinokibi ransomware. We see no traces of the DLL being saved on the disk as the ransomware silently starts encrypting files on the system.
Case 3: Astaroth Backdoor
The Astaroth Trojan is known for stealing credentials, keystrokes, and other system information. An analysis of the backdoor and the infection cycle is covered in detail by Microsoft. The infection chain starts with a victim clicking on an LNK file that is delivered via a phishing email. This LNK file contains an obfuscated WMIC command, which downloads an XSL file containing obfuscated JavaScript.
Figure 9: The obfuscated WMIC command
This JavaScript code downloads a Base64-encoded payload by abusing the Bitsadmin tool and decodes it using the Certutil tool. The payloads are XOR-encrypted PE files except one of the DLL files, which is loaded by leveraging the Regsvr32 tool. Finally, this DLL file decrypts the payload of the backdoor Astaroth and maps it in the Windows userinit process.
Figure 10: Obfuscated JavaScript in an XSL file
During the entire attack chain, only system utilities are leveraged to load the final payload. The Astaroth payload executes silently without traces on the filesystem.
The case studies described above are based on techniques that take advantage of legitimate applications, such as PowerShell and Windows Management Instrumentation (WMI). However, there are other techniques in which the payload is stored in the registry and delivered by taking advantage of zero-day vulnerabilities in applications or in the operating systems themselves. In one example, the famous Equifax breach used a vulnerability in Apache Struts to deliver the payload. As the PowerShell scripts were stored in the registry, there was no direct trace of the malware being stored.
Conclusion
Fileless infection campaigns are difficult to detect. That's why the Zscaler ThreatLabZ team continually monitors malware delivery mechanisms from several sources to ensure that Zscaler customers are protected.
