enSilo researcher, Ben Hunter, discovered a relatively new multipurpose attack tool called L0rdix. L0rdix is written in .NET, aimed at infecting Windows based machines and available for purchase in forums hosted by cyber criminals and in underground channels. While L0rdix doesn’t present any unseen techniques, what makes it a potent threat is that it combines stealing and mining methods.
Figure 1:L0rdix sold in online forums
Figure 2 - L0rdix sold in online forums
The tool presents the user with easy configuration options and multiple functionalities:
Figure 3 - Panel view
L0rdix is a 32-bit .NET application obfuscated using the standard ConfuserEx obfuscator. Some samples were packed with the more advanced .NETGuard obfuscator which is also based on ConfuserEx.
Anti-analysis and anti VM
L0rdix goes to great lengths to avoid being executed in virtual environments and analyzed by common malware analysis tools. While employing simple checks such as scanning for common monitoring tool names, such as “procmon” (see appendix A for full list), it also uses WMI queries and registry keys to search for strings that indicate being run under a virtual environment (see appendix B).
The less common checks made by L0rdix include searching processes that load sbiedll.dll which belongs to the sandboxie product, aspiring to increase its chances to avoid running in a simple free virtual environment tools.
L0rdix supports a wide variety of actions aiming to make it a universal “go to” tool for attackers that require different capabilities. It’s obvious that the writers preferred code simplicity while investing in a larger spectrum of capabilities to offer the buyer. To provide a firm separation between the tool’s different modules and allow easy future development, L0rdix consists of five main embedded modules that are executed and determined by the global constants and pre-determined configuration data. The “main” code of L0rdix starts out by running (if configured to) the described anti-VM tests and after their validation it continues to try and update the configurations with new ones from the server.
Before querying the server for a new configuration file, L0rdix collects (using WMI queries and registry keys) the following data about the infected machine in order to use it as a unique identifier in the server.
- The logical disk hardware device ID
- The OS product name
- Processor model (CPU)
- Graphic controller model (GPU)
- Installed anti-virus products
- The current user privileges
- The hashrate constant passed in the initial configuration
- The profile constant passed in the initial configuration
- Information about the RAM available on the machine
- A string that is consisted of Drive_name:/free_space_in_it
All the collected data is encrypted using simple AES.
The last step before contacting the server includes producing a screenshot of the machine to send as the value for the server. For example, the URL for getting a new configuration’s settings will be:
[changing prefix] + connect.php? + [unique collected data]
The server will replay with a JSON file that contains parameters to be parsed.
Few of the more interesting parameters are:
- Mining_status – to determine whether L0rdix should perform mining activity
- Warn_processes and Warn_windows – allows to update the scanned windows and processes name that will fail the next anti-vm and anti-analysis checks
- Steal – to determine whether L0rdix should steal personal information
The first thread that will execute is the USB infecting module, which maps all the connected removable devices and for each file and directory it changes their attributes to hidden and copies itself with their name and icon instead. All of this is done to make sure that the malware will execute by the user double- clicking it on another machine.
Figure 4 – Replacing existing files with the malware
The thread will keep waiting for new remove-able devices to infect.
The second thread is responsible for setting the persistency on the machine. The configurations file contains a list of tuples of (name,location) which L0rdix will copy itself to. Each copied instance is made persistent using the classic schtasks util:
Schtasks /create /tn [copy name] /tr [copy path] /st 00:00 /du 9999:59 /sc daily /ri [interval from configs] /f
This persistency method will keep executing every setup_interval milliseconds (defined in the configurations file).
The botnet thread starts out by building the same communication strings we saw in the initial configurations setting.
This time, the received JSON file contains 3 main objects:
- Plain text to be encrypted with the encryption key, upon sending a reply to the server
- A string hash that’ll contain the command passed
- Optional arguments string to be passed to the invoked command
The botnet offers a diverse range of actions, some of which are:
- Open a specific URL in a browser
- Execute cmd commands
- Kill a specified process
- Upload a file
- Download and execute an executable file
One command that is worth mentioning is HTTP traffic overloading feature that L0rdix implements. This simple feature allows for threaded flooding on a specific host by sending it a big number of HTTP requests. This feature allows the bot controller to execute DDOS attacks.
Figure 5 – HTTP flooding method
Crypto Wallet stealing
L0rdix monitors the clipboard and searches new copies in the clipboard for the following patterns the consist of a regex and a specific wallet type:
Figure 6 – Search patterns for wallets and their matching coins
When locating a matching string, the content will be sent to the server along with the specified matching coin type, and new text from the server will be replaced in the clipboard.
L0rdix aims to collect 3 categories of information from the machine. The first category is saved login details for each browser in the list below. L0rdix kills the browser, if it’s running, and extracts saved login details by simply copying the data base and extracting the details using SQLite utility.
L0rdix targets a wide variety of browsers such as:
The second category is cookies information from each browser. The third category is all of the files that match the list of extensions from the configurations data and are located in the desktop or in its directories. The default is .txt files. Upon completing data collection, L0rdix stored all the information in the Temp directory which will zip the directory and send it to the server.
The miner module was created in later stages of the development, as some samples miss the miner’s logic implementation. L0rdix doesn’t actually imbed the miner’s functionality in its code, but rather it uses the well-known process hollowing technique to run its own malicious code that it gets from the server inside the legitimate process attrib.exe.
Figure 7- smethod_0 calls the process hollowing method
While it’s very easy to notice that most of the effort was put into evading virtual environments and analysis tools along with implementing the stealing module, L0rdix still presents unfinished modules and weak implementation details such as simple encryption or simple data handling between the server and the client. Those indicators might suggest that the tool is still under development. We can expect to see more sophisticated versions of L0rdix in the future or the indicators are evident of an inexperienced malware author.
Contacted Domain Prefixes
Dropped process’s details
Names of the analysis tools that l0rdix searches for:
- Searches the manufacturer and model fields for any occurrences of “VMware” or “Microsoft Corporation” using the WMI query 'Select * from Win32_ComputerSystem'.
- Searches the graphic hardware’s registry keys for any occurrences of “VMware SVGA ll” or “VirtualBox Graphic Adapter”using the WMI query 'select * from Win32_VideoController'.