- During our continuous monitoring of LodaRAT, Cisco Talos observed changes in the threat that add new functionality.
- Multiple new versions of LodaRAT have been spotted being used in the wild.
- These new versions of LodaRAT abandoned their previous obfuscation techniques.
- Direct interaction with the threat actor was observed during analysis, indicating the actor is actively monitoring infected hosts.
What’s New?
Talos recently identified new versions of LodaRAT, a remote access trojan written in AutoIt. Not only have these versions abandoned their usual obfuscation techniques, but several functions have also been rewritten and new functionality has been added. In one version, a hex-encoded PowerShell keylogger script has been added, along with a new VB script, only to be removed in a later version. Direct interaction from the threat actor was observed during analysis.
So What?
Since our blog post on Loda in February 2020, Talos has been continually monitoring LodaRAT for new behavior. Recently there have been several changes that indicate that the authors are learning new techniques to improve the effectiveness of Loda. While these changes are somewhat minor, it shows that the authors are continually developing Loda into a more robust RAT.
DISTRIBUTION
In previous campaigns, the infection chain started with a malicious Microsoft Word document that downloaded a second document which then exploited CVE-2017-11882. The exploit payload in turn downloaded an MSI that contained the compiled Loda AutoIt script.
The samples analyzed in this post were distributed in a much simpler manner. Loda is now being distributed via a malicious RAR archive attached to phishing emails. Here’s a look at one of these emails:
The RAR attachments have the file extension “.rev” and contain the compiled Loda AutoIt binary. Actual “.rev” files are recovery files that can be created alongside multi-volume RAR archives. However, the files attached to these emails were standard RAR files with the extension name changed.
The overall complexity of this infection chain is significantly lower than previous campaigns, which may be a detriment to the effectiveness of the current campaigns. Execution relies solely on the target user double-clicking on the binary and running it, rather than triggering an exploit to start an infection chain that is more or less automated.
MALWARE
During our investigation, multiple versions of Loda were found to be distributed at the same time. The overall functionality of the different versions is quite similar to one another, with some key differences. The different versions being used at the same time could indicate that there are several threat actors using Loda, with each actor in possession of a different version. In our investigation, most samples found in the wild are older versions — the newest versions being less common.
The version numbers embedded in Loda do not have a reliable order. In our previous Loda post, the version number was “1.1.1,” which has not been incremented in some new versions, even though there have been multiple updates and changes. However, we have also identified a new version labeled “1.1.7” which has additional changes to its code and functionality. Consequently, these numbers should be considered unreliable as the sole determining factor for identifying the version of Loda being analyzed. The string “beta” has been seen in every version of Loda as well.
OBFUSCATION
The most readily apparent change in these new iterations of Loda is the complete removal of any obfuscation. Typically, Loda utilizes a combination of string obfuscation and function name randomization. These techniques may have been abandoned since they no longer provide a significant reduction in AV detection. The image below shows obfuscated code from a previous version of Loda, containing both random function names and string obfuscation.
The next image is of the same section of code from the recent version of Loda. The functions have meaningful names and there is a complete lack of string obfuscation.
1.1.1
As for new functionality, the new version labeled as 1.1.1 has implemented a PowerShell keylogger that is stored as a hex-encoded string as shown below:
This PowerShell script appears to be copied and pasted from a short blog post with the comments removed. If the command “MgPlugUp” is received from C2, the script is written to a file called “tmpwstz21.ps1” and executed. The logs are output into the temp directory as a text file named with the current date.
A VB script has also been added that searches for the Loda AutoIt script by process name to ensure only one instance is running. This script is also partially stored as a hex-encoded string that is decoded and appended to a file called “BYDVRI.vbs”.
1.1.7
The version of Loda labeled as 1.1.7 has made several changes, most notably removing the PowerShell script and the VB script mentioned above. Numerous small improvements have been made to the code’s syntax and cleanliness, although a large portion remains unchanged. This newest version focuses on what Loda was originally intended for: stealing passwords and cookies from browsers.
The only new function in 1.1.7 is shown below. First, Loda detects the OS version by using the AutoIt macro “@OSVERSION” and copies itself to either the Temp or startup directories depending on the version of Windows. After copying itself, it then executes the copy.
Although the version number is 1.1.7, this iteration of Loda appears to have reduced functionality. Some code may have been removed or altered for the sake of reliability.
USELESS CODE
There are two functions that persist through all versions of Loda that are effectively useless. The first being the command “QURAN.” This command is intended to stream audio in Windows Media Player of a reading of the Quran on the infected host using the deprecated MMS protocol (Microsoft Media Server). The URL for this stream is “live.mp3quran[.]net:9976” which seems to no longer exist, effectively making the command unusable. This command is outlined in the previous LodaRAT post.
The second function is “__SQLITE_DOWNLOAD_SQLITE3DLL” which attempts to download a SQLite3 DLL from a dead URL.
C2
For both versions, C2 communication has shifted to abusing legitimate services. Ngrok.io and portmap.io were both observed to be used during analysis. These services are intended to be used by developers and administrators to communicate with hosts not directly connected to the internet but can easily be abused by threat actors for purposes of anonymization. Talos has previously covered threats that use this technique and can be read about here.
While performing analysis on version 1.1.1, several commands from C2 were observed in real-time. The first command that Loda typically receives from C2 is the “Screen” command, which sends a screenshot of the infected host back to C2. This command is sent at regular intervals to continuously provide the threat actor with a current screenshot of the host.
After several screenshots were sent to the C2 server, the threat actor responded and interacted directly with our analysis machine. The command “MpS8x” was used to generate a small VB script to display a message box with a custom message.
Judging from the content of the message, the threat actor realized the malware was running in a sandbox. An interesting aspect of this interaction is that there is no sandbox detection function within Loda itself. Prior to this message box, there was no data sent to C2 that indicated that the malware was running on a virtual machine. Without this functionality, the threat actor realized they were looking at a sandbox purely from the appearance of the screenshot. This direct interaction indicates that the threat actor is actively monitoring infected hosts.
It is worth reiterating that most instances of Loda found in the wild are older versions that still use the same techniques. The unobfuscated versions analyzed in this post are quite rare in comparison to previous versions. The frequency of use may increase over time if the new iterations of Loda prove to be effective. It is also worth mentioning that these versions may also soon employ string obfuscation and function name randomization, as Loda has historically used these techniques regularly.
CONCLUSION
Loda continually proves to be an effective RAT and consistently changes and adds to its functionality. While some of these changes are minor and simplified in some ways, it displays that Loda is constantly evolving. This malware poses a serious threat to an infected host due to its capabilities. Loda may be simple, but it is more than effective enough to cause serious financial damage.
To read the original article:
https://blog.talosintelligence.com/2020/09/lodarat-update-alive-and-well.html