A fresh approach to an old technique
The talk of the town within the first half of the year on Cyber Security community is the term “fileless” attack. It is an attack technique that does not require downloading nor dropping malicious files into the system to execute its malicious behavior, but rather leverages on exploits to run malicious commands or launch scripts directly from memory via legitimate system tools. In fact, attacks such as Code Red and SQL Slammer worms in the early 2000s do not save itself to any disk but store its malicious code solely in memory.
However, the term "fileless" can also be a misnomer as there are attacks that may involve presence of files on the computer, such as opening an attachment from spam emails. Once executed, it may still save a file on disk and later use fileless techniques to gather information on the system and spread the infection throughout the network. These techniques can be in the form of exploits and code injections to execute malicious code directly in memory, storing scripts in registry, and executing commands via legitimate tools. In 2017 alone, 13% of the gathered malware uses PowerShell to compromise the system.
Legitimate system tools such as PowerShell and Windows Management Instrumentation are being abused for malicious activities, since these are all built-in tools that run in Windows operating system. One known malware family that uses PowerShell to download and execute malicious files is the Emotet downloader.
There are even old malwares that changed its technique and now uses fileless attack. These malwares aim to be more effective in terms of infecting machines and avoiding detection like Rozena.
Rozena is a backdoor-type malware capable of opening a remote shell connection leading back to the malware author. A successful connection to the malware author yields numerous security concerns not only to the affected machine, but also to other computers connected on its network.
This was first seen in 2015 and made a comeback on March 2018. The old and new Rozena malware still targets Microsoft Windows operating systems, but what made the difference is the new one’s adaption to the fileless technique which uses PowerShell scripts to execute its malicious intent. A survey done by Barkly and the Ponemon Institute, which polled 665 IT and security leaders, found out that fileless attack are 10 times more likely to succeed than those of file-based attacks. This could be the probable reason why malware authors are now following the fileless trail.
This file may arrive on a system as a dropped file by another malware or as a downloaded file when visiting malicious sites. It may also arrive as an attachment on a crafted spam email. Rozena is an executable file that masks itself as a Microsoft Word file. Upon execution, it will create a text file named Hi6kI7hcxZwU in %temp% folder. Then the exeutable file will launch obfuscated and encoded PowerShell commands with specific order and purpose. In this case, we name these scripts as CREATOR script, DECODER script and INJECTOR script for easier tagging in the In-Depth Analysis. The creator script is responsible in spawning the decoder script. The decoder script is to decrypt the content of Hi6kI7hcxZwU and execute it. The decoded script will yield the injector script that will injects shellcode to PowerShell.exe.
This injected shellcode will create a reverse TCP connection to a remote server that will give an access to the malware author. It is like opening a door to the thieves that makes them take and do whatever they want to the house, and can go beyond in reaching all its neighbors.
One of the common techniques used to lure users in executing files from unknown sender or unknown downloads is to make them look harmless. Since the default Windows’ feature is not to show the file extension, it is easier for the malware author to bait the user to execute the file as shown in Figure 2. Rozena chooses to use Microsoft Word Icon, but it is a Windows executable file as shown in Figure 3 for Rozena’s file header.
Upon execution, it will create a file in %temp% folder with a fixed filename Hi6kI7hcxZwUI.
Then it will call CreateProcessA to a PowerShell script via command line, where we name the first script as CREATOR Script.
Now let's take a closer look at the PowerShell parameters:
The parameters and functions consist of mixed lower and upper cases, and this is one of the obfuscation techniques used by this file for executing PowerShell scripts. PowerShell commands by default is not case sensitive, thus doing this cannot affect its execution. Almost all parameters used by this file has similar format – mixed cases and shortened syntax.
-wIndOwsTY, is a syntax for -WindowStyle parameter of PowerShell. The truncating of syntax is also for obfuscation and anti-detection, and this is still a valid parameter because of how PowerShell handles parameter binding.
HiddeN, which means that it will set the window style for this session to hidden. This parameter is widely used to prevent the PowerShell from displaying a window when it executes a script.
-c, short for -Command. It will execute a command that follows the parameter as though they were typed at the PowerShell command prompt. The value after the command is an encrypted script block.
Using join, split and convert functions from PowerShell, this code will be decrypted as a script as shown on Figure 8. The script also uses a pipeline operator (|) to send the command string to Invoke -Expression, that will execute the script on the infected machine. For obfuscation and not to be detected easily, the 'iNVOKE-EXPreS'+'sIOn' is a concatenated string for Invoke-Expression.
The first section that is boxed in red is only for variable declarations to be later used in the PowerShell parameter. The lower part which is boxed in gray are the new parameters for the second PowerShell that will be spawned.
Now let us take a look at the newly created PowerShell script and its parameters:
The upper part boxed in red consists of PowerShell parameters and some obfuscation functions.
Now let's break down each parameter:
-noniNtE, shortened syntax for -NonInteractive. It is used to prevent showing an interactive prompt to the user. It is often combined with -WindowStyle Hidden to hide any script execution.
-nOlOG, shortened syntax for -NoLogo. Hides the copyright banner when PowerShell is executed.
-NOpROFI, shortened syntax for -NoProfile. Does not load the PowerShell profile.
-wIndOwsTY HiddeN, shortened syntax for -WindowStyle Hidden. As mentioned above, to prevent PowerShell from displaying when executed.
-ExeCUTIonPOlic BypaSS, truncated syntax for -ExecutionPolicy bypass. It is used to set the default execution policy for the current session. This parameter does not make any changes to the PowerShell execution policy set in Windows Registry, nor writes file on disk to evade security checks and hide malicious execution.
Setting the execution policy to bypass will not block any script execution and there are no warnings or prompts to alarm the user. It is also regardless of the user’s profile, whether administrator or not, the PowerShell script will still be executed.
After -ExeCUTIonPOlic BypaSS, there is an obfuscated code that only yields ‘-ec’ when decrypted.
-ec, truncated syntax for encodedcommand, it accepts a base-64-encoded data block version of a command. This parameter is used to submit commands to PowerShell that require complex quotation marks or curly braces. This parameter runs the base64-encoded command highlighted section from Figure 8.
Decrypting the part boxed in green in Figure 9 which is a base-64-encoded data block. This will generate another PowerShell script, calling this as the DECODER script.
The procedure is the same in the decrypted CREATOR Script shown in Figure 8. The part boxed in red is just variable declarations which will be used later as a parameter for PowerShell execution. The part boxed in gray has the same parameters as Figure 9, but with different obfuscations used.
In the DECODER script, it used some new parameters highlighted in green, which is somehow readable even with the strings are concatenated.
New-Object is used to create an instance of a .NET Framework class, which in this script, it creates System.Net.Webclient which is used to send and receive data from remote resources. Most of the threats today, especially downloaders that uses PowerShell scripts uses this code.
-f / -File, run commands from a specified file which points to the output of DownloadString()
that downloads the content from Hi6kI7hcxZwU (file located in %temp% folder shown in Figure 2 to a buffer in the memory.
Since this is an encrypted string, it will then be decrypted using XOR operation as seen on the last part of the PowerShell script (DECODER script). The file Hi6kI7hcxZwU will subsequently be deleted.
The decrypted output has the same structure as the CREATOR script. Notice the last part of this script in Figure 11, it is an obfuscated parameter for Invoke-Expression and this will be the third PowerShell Script to be executed by this file, calling this as the INJECTOR script. This is a common anti-debugging technique by most malware wherein wrapping their code with multiple layers of obfuscation and encryption. Decrypting this code, will yield us another base-64-encoded data block.
After decrypting this base-64-encoded data block in Figure 12.a, we finally can see the script in its full glory:
The upper part highlighted in red has much a lot of readable strings and only few string obfuscations. There is DLLImport for kernel32.dll and msvcrt.dll, for importing APIs in Windows Kernel and msvcrt library. There are specific APIs that can be seen: VirtualAlloc, CreateThread and memset. These are common APIs used for executing a code injection. The middle part contains hexadecimal byte values that make up a block of code and assign it to a variable. This block of code is referred to as the shellcode. In the bottom part, hightighted in green, the obfuscated functions will copy the hexadecimal byte values to the allocated memory and inject it to the running PowerShell.exe, using VirtualAlloc and memset.
The following APIs will be harvested and used:
It will try to establish a connection to a server: 18[.]231[.]121[.]185[:]443 (down at the time of analysis). Notice that it also uses TCP port 443 which is used for SSL connections, as shown on Figure 13. This means that all data passed through the server to the receiver remains private and integral and a way to avoid security checks and network detections. The IP address and port number are hard-coded in the shellcode as hexadecimal byte values.
Rozena will make four attempts to establish a connection. The IP address was unreachable at the time of analysis, however.
Given that the IP address was not available for a connection, we might as well have stopped at this point. However: doing so would mean that we could not find out what Rozena can do to an infected machine. In order to proceed with the analysis, we set up a test environment. Since the IP address and port number were hard-coded in the shellcode, we just modified it to point to an internal dummy server for the sole purpose of continuing the analysis. This is the only modification done in the whole script for further analysis. We also destroyed the modified malware after the test so it will not find its way into anyone’s malware collection.
Once the connection between the server and the infected machine is established, it is now ready to receive files from the server that will be allocated in the memory and be executed.
The series of code above is from the Metasploit framework that creates a reverse TCP connection. In a reverse TCP connection, the infected machine will open the port that the server will connect to. This is mostly used by backdoor malware since it bypasses firewall restrictions on open ports.
The infected machine is now connected to the dummy server that uses Kali Linux environment with Metasploit Framework. It uses meterpreter to craft and send files to the infected machine or any other commands shown below.
To be infected by a backdoor malware and looking on the few commands above that can be used to compromise the system is no doubt terrifying. It can literally do anything with the infected machine, the files, be familiar with the system and infecting its network. This poses a lot of security threats and can cause huge amount of damage. Now that Rozena follows the fileless trail, its stealthy way of delivering and executing its malicious activity intensifies.
As the world changes, malware authors adapt and make use of built-in legitimate tools for their infection that might leave us defenseless. But there is always a way to shield ourselves from these types of attack.
1. Keep operating systems and software up-to-date, including security updates. Especially knowing that older systems have numerous vulnerabilities that can be exploit and be use for the infection.
2. It is strongly advised to download, save or execute files from known and trusted sources. malware authors still use traditional arrival vector to lure users for executing malicious files.
If disabling system tools especially PowerShell is not an option, you will find some alternative ways to configure PowerShell to prevent malicious script execution.
3. Set PowerShell Constrained Language Mode – this will limit the capability of PowerShell by removing advanced feature such as .Net and Windows API calls, since most PowerShell scripts rely on these parameters and methods.
4. Pairing PowerShell with AppLocker – this will prevent unauthorized binary file from being executed.
Executable File (masks as Microsoft Word): c23d6700e93903d05079ca1ea4c1e36151cdba4c5518750dc604829c0d7b80a7
Created File (filename Hi6kI7hcxZwU): d906dc14dae9f23878da980aa0a3108c52fc3685cb746702593dfa881c23d13f
Connected to remote server: 18[.]231[.]121[.]185[:]443