First advertised as an information stealer and keylogger when it first appeared in underground forums, LokiBot has added various capabilities over the years. Recent activity has seen the malware family abusing Windows Installer for its installation and introducing a new delivery method that involves spam mails containing malicious ISO file attachments. Our analysis of a new LokiBot variant shows that it has improved its capabilities for staying undetected within a system via an updated persistence mechanism and the use of steganography to hide its code.
Background of the incident
We first became aware of this specific LokiBot variant (detected by Trend Micro as TrojanSpy.Win32.LOKI.TIOIBOGE) when we alerted a Southeast Asian company subscribed to Trend Micro’s Managed Detection and Response (MDR) service regarding a possible threat — an email with an attachment— allegedly from a confectionery company based in India. An alert from the Virtual Analyzer of the company’s Trend Micro Deep Discovery Inspector, along with the suspicious nature of the email, led us to notify the company regarding the potentially malicious threat, after which Trend Micro Research went further into investigation and analysis.
Figure 1. Screenshot of the actual email sample that contained a LokiBot attachment
The email sample
There were several elements in the email that raised red flags. The first and most obvious was that the sender name and the email signature didn’t match, immediately signifying that it was a potentially malicious message. The second was the sense of urgency: The email was sent on July 1, with the text notifying the receiver that the products that were allegedly ordered would be shipped in mid-July. This is meant to instil the recipient with a sense of urgency to open the attachment at the soonest possible time. Finally, the IP address of the email source (37[.]49[.]230[.]149) is known to be malicious and is blocked by Trend Micro’s Email Reputation Services (ERS).
The attachment itself, New Order July.DOC, (detected as Trojan.W97M.DLOADER.PUQ) had two embedded objects:
- a Microsoft Excel 97-2003 Worksheet
- a package labelled 'package.json'
Upon execution, the document will immediately show a Microsoft Excel worksheet, which in turn would execute the VBS macro code embedded in the worksheet. The step-by-step process is shown below:
Figure 2. Lokibot's infection chain
Based on the email header, the email seemed to be a newly created email, not a forwarded or reply message as the subject indicated. There was no indication that an existing email account was compromised. This means it is likely the sender spoofed a legitimate account since the IP address did not match the sender domain. Our Dial-Up User List also showed that the email had most likely been sent from a botnet or a compromised machine infected with malware.
The Trend Micro™ Smart Protection Network™ infrastructure showed that the IP address used had also sent other spam mails that included the following email subjects:
- PO #201 API documents attached (Dye and colour sample)
- PO #2789 Approved documents
- RE RE new ORDER #37789 (MT) 230KG
- RE RE new ORDER #37789 249 CBM
- RE RE new ORDER (COA) 230KG
This shows that the threat actors are using rather generic titles for their emails rather than any targeted form of social engineering.
The code hidden in an image file
After recognising a possible attack, we decided to try finding samples with characteristics analogous to the email that was provided to us. By sifting through VirusTotal, we found that similar samples had been added between June 24 and July 5. Our analysis of the samples revealed some interesting additions to LokiBot’s capabilities.
The filenames of the malware samples varied, but in general, they were gibberish:
- exe / bpxssh.jpg
- exe / sittey.jpg
- exe / jkcgjj.jpg
We determined, based on what we found, that the LokiBot variant may also arrive via a malicious spam email containing a malicious Rich Text Format (RTF) file attachment. The RTF file contains an embedded Excel OLE object that uses Windows Management Instrumentation (WMI) and PowerShell to download and execute the malware.
Figure 3. One of the VirusTotal email samples that contains a LokiBot attachment
For installation, this LokiBot variant initially installs itself as %Temp%\[filename].exe along with %temp%\[filename].jpg (the image file that it uses as part of its routine). One characteristic of the image file that we found interesting is that it can actually be opened as an image. However, it also contains data that LokiBot references in its unpacking routine.
Figure 4. The image file when opened
The image contains the encrypted binary that will be used throughout the different unpacking stages until the main LokiBot code is decrypted in memory.
Before loading the main code, it creates a directory in %appdatalocal% where the Loki binary and the image (same as those in %temp%) will be placed. At this point, it also drops a Visual Basic script (VBS) file that then runs the LokiBot file. During this stage, it also creates an autostart registry that points to the VBS file as a persistence mechanism. While LokiBot uses an autostart routine, there are variants, including this one, that use “broken” autostart registries created by the same autostart function, although it is currently unknown why these variants have these kinds of autostart registries. From analysis, one can see in memory that it tries to write the autostart registry but was overwritten, resulting in a broken registry. This may be a result of coding/modifying error on the threat actors’ part or of something that went wrong at the time of compilation.
In the latter stages of the unpacking routine, the main LokiBot code is finally loaded and executed. From this point, the actual LokiBot indicators can already be seen. By analysing the main code of this specific variant and comparing it to previous variants, we found that there were minimal major updates aside from changes to the target applications for credential stealing, which vary according to the variant.
LokiBot’s use of steganography
A previous incident involving LokiBot was reported back in April in which the malware variant was seen using malicious Zipx file attachments hidden inside a PNG image file.
In this case, the LokiBot variant hides the encrypted binary inside the image file, first by looking for the “marker” that signifies the start of the encrypted file. The string appears to be “#$%^&*()__#@$#57$#!@”, which it searches for via a substring function.
Figure 5. The encrypted binary inside the image file
After locating the file, it then begins the decryption process. The resulting decrypted file is then loaded for the succeeding stages of unpacking. Based on the input and output, it does not use a block cypher such as AES to decrypt the contents of the file and uses its own method of decryption instead.
Figure 6. The decryption routine
Figures 7 and 8. Before and after decryption
One likely reason for this particular variant’s reliance on steganography is that it adds another layer of obfuscation — wscript (the VBS file interpreter) is used to execute the malware instead of the actual malware executing itself. Since the autostart mechanism uses a script, future variants can choose to change the persistence method by modifying the script file on the fly.
As one of the most active information stealers in the wild today, LokiBot shows no signs of slowing down. The updates to its persistence and obfuscation mechanisms show that LokiBot is still being updated and will likely remain a threat to be dealt with in the near future.
Fighting LokiBot with Managed Detection and Response (MDR)
In the specific case we handled, the LokiBot variant was proactively flagged by the internal sandbox and we were able to provide analysis within a day, allowing the sender’s email address to be blocked before any lasting damage could occur. However, we discovered that the same email had been sent to at least 55 targets in other organisations, which means that the attack was not a one-off incident. Given the prevalence of LokiBot, it wouldn’t be surprising either to see the threat actors launch similar attacks of greater scale.
As mentioned earlier, the malicious email used a very convincing email address. In fact, without the sandbox alert, it’s very probable that the message would have slipped through unnoticed. Although the targeted company had its own security team in place, detecting the threat, as well as analysing it given its various evasion mechanisms, could have proven difficult without prior familiarity with LokiBot.
It is often the case that the most significant threats to an organisation — and the ones that have the greatest impact — are not targeted attacks, but rather the smaller, more common incidents that are difficult to detect and constantly reoccur. This is one aspect where a security service like managed detection and response can help even organisations that have their own security teams. MDR provides the ability to investigate incidents, analyse threats, and perhaps most importantly, gain a clearer picture of what the organisation is dealing with by correlating different and seemingly unrelated indicators. In this case, having previous familiarity and experience with LokiBot allowed our MDR and analysis teams to provide feedback and remediation recommendations within a day.
In addition to being well-versed in internal and external threat intelligence resources, the MDR team has experience in using advanced security solutions from the Trend Micro suite. One of these is the Deep Discovery Inspector, which allows the detection of a threat‘s lateral movement within the organisation.
Indicators of Compromise (IoCs)
|File name||SHA-256 hashes||Detection name|
|New Order July.DOC||7812e7564a1e2480412b228daf4c53e9f5291bbdb06120aec778cf4ed0a6654d7||Trojan.W97M.DLOADER.PUQ|
|fd908abce7885430fb344aedb21cee0aa73f2bd7b82ab118974674afdfe45fc2||TrojanSpy.Win32.LOKI.TIOIBOGE Troj.Win32.TRX.XXPE50FFF031 (TrendX)|