Updated Karagany Malware Targets Energy Sector

Summary

In early 2018, Secureworks^® Counter Threat Unit™ (CTU) researchers identified and analyzed a number of Karagany (originally known as xFrost) malware family variants and associated plugins. Karagany is a modular remote access trojan (RAT) linked to the threat group CTU™ researchers track as IRON LIBERTY (also known as DragonFly2.0 and Energetic Bear). CTU analysis indicates that the malware is still under active development as of July 2018. The authors have made a number of updates and changes to the core RAT component, as well as to a number of the plugins commonly used in conjunction with the framework.

Background

Dating from at least 2010, the Karagany malware family originated from criminal malware known as "Dream Loader." Reports indicate that Dream Loader was leaked onto underground forums and that limited use was seen in the wild.

CTU researchers have linked Karagany to the IRON LIBERTY threat group. Although Karagany is based on the leaked Dream Loader source code, IRON LIBERTY invested time to significantly develop and update the malware for its own operations. CTU researchers are unaware of Karagany being used by any other threat groups as of this publication.

Active since at least 2010, IRON LIBERTY targets the energy vertical, including energy companies and organizations financing the energy vertical in the U.S. and Europe. The Russian government likely tasked IRON LIBERTY with collecting intelligence and possibly pre-positioning for sabotage operations. Following public reporting of IRON LIBERTY's capabilities in 2014, CTU monitoring of the group's activity suggests that it stopped using its known tools and retired its infrastructure. In late 2016, IRON LIBERTY re-emerged with a campaign targeting the energy vertical. Analysis of Karagany samples from 2016 through 2018 shows continuous development throughout the course of that campaign.

Technical details

CTU analysis provides insight into Karagany's functionality, how the malware is delivered and installed, and its typical plugins.

Core capability

Karagany does not have a wealth of built-in capability at its core. Its main purpose is to provide the ability for a remote threat actor to maintain persistent access to a victim's network, upload/download files, and download and execute additional plugin modules. CTU researchers observed the following plugins:

• Listrix — file enumeration and directory listing
• IKLG — keylogger
• ScreenUtil — screen capture utility
• MCMD — interactive command shell module
• SysInfo — system information enumeration
• Browser Data Viewer — browser data and credential theft
• LogKatz — custom Mimikatz script for credential theft

In addition to the plugin functionality, the core module contains a limited capability to harvest browser passwords stored in the Windows Credential Store (see Figure 1).

Figure 1. Karagany credential enumeration via standard API calls. (Source: Secureworks)

Delivery

IRON LIBERTY has used existing access to target environments to manually install Karagany on victims' machines using stolen privileged credentials. CTU researchers assess that each victim was specifically targeted based on their role and access within the organization. An example of this process is the use of the legitimate Microsoft tool PsExec to gain a remote command session on the victim's machine using a compromised Active Directory service account that has local administrator privileges.

As shown in Figure 2, once on the victim's machine, the threat actors use the Microsoft Sysinternals tool ProcDump to dump the LSASS process. This dump file is then RAR-compressed and retrieved by the threat actor in order to recover the passwords of the machine's legitimate users.

Figure 2. Red Cloak process tree showing user profiling/password dumping. (Source: Secureworks)

CTU researchers assess that the threat actors used compromised privileged credentials sparingly for initial access and then ran the malware in the context of the user to enable granular victim targeting and to camouflage the malware and its subsequent operations.

Installation

Unlike pre-2017 Karagany variants, which either installed the malware into the directory it initially executed from or picked a name and path from a list of locations, all of the variants observed by CTU researchers during this campaign were hard-coded to install to a specific path: %LOCALAPPDATA%\SearchIndexer\SearchIndexer.exe.

A number of other files are created at installation time but remained empty in all observed infections:

• %LOCALAPPDATA%\SearchIndexer\up_stat.txt
• %LOCALAPPDATA%\SearchIndexer\stat_ag.txt
• %LOCALAPPDATA%\SearchIndexer\serv_stat.txt
• %LOCALAPPDATA%\SearchIndexer\proxy.txt

Any plugins downloaded by the malware are dropped into %LOCALAPPDATA%\SearchIndexer\settings and executed. Regardless of which plugin is dropped and executed, the filename convention svchost<[0-9]+>.txt is used (e.g., %LOCALAPPDATA%\SearchIndexer\settings\svchost1328525.txt). Plugin files dropped to this directory are only ever executed once. Even if the same plugin is executed multiple times, it will be re-downloaded per execution.

The core Karagany implant does not delete any of the plugins it downloads, although some of the plugins are designed to self-delete. This oversight facilitates high-fidelity forensic analysis of the majority of plugin activity carried out over the duration of the intrusion and allows a detailed timeline of threat actor activity to be compiled. The malware also creates a directory that is used for storing both plugin output data and to stage data for exfiltration. The value is hard-coded, and CTU researchers have observed the three variants listed in Table 1. The ascending numerical value of these directories likely indicates malware versioning.

Table 1. Karagany directories created for storing data.

Persistence

In all versions analyzed, the malware uses the Windows Startup folder of the infected system for persistence between reboots. An LNK file is added and usually retains the name of the malware as written to disk. In all of the 2017 and 2018 samples analyzed by CTU researchers, this name is "SearchIndexer.LNK":

%UserProfile%\Start Menu\Programs\Startup\SearchIndexer.LNK

Command and control

CTU analysis of the command and control (C2) capabilities of the Karagany malware show a number of changes designed to reduce detection.

C2 operations

Samples compiled in 2017 and 2018 were hard-coded with specific URI patterns to communicate with the C2 server via HTTP POST requests. The alphanumeric filename string is pseudo-random and differs for each transmission to the server. It does not contain any identifying information about the host.

• Pattern: https://<domain>/picture/<[a-z]{3}[0-9]{3}>.<jpeg | tiff | bmp>
• Example: https://<domain>/picture/zzz123.tiff

Variants compiled in 2016 used subtly different URI paths (e.g., https://<domain>/get_image/<[0-9]{6}>.<(jpg | png | gif)>). This change is likely an attempt to evade any basic network intrusion detections that rely on tight string matching.

The hard-coded User-Agent string "Mozilla/7.0 (Windows NT 7.0; WOW64; rv:7.0) Gecko/15103 Firefox/46.0" is used by the malware during communications with the C2 server. This User-Agent is the same across all 2017 and 2018 samples. The "Mozilla/7.0" portion of this User-Agent string is invalid and is not used by any known products as of this publication.

Once the malware has checked in with the C2 server, if the threat actor has scheduled additional tasking, a different URI path is used to retrieve the specified plugins:

https://<C2 IP address>/template/collection.php?a=tasks/<plugin path>

C2 traffic encryption

Although the C2 traffic is secured by SSL/TLS, Karagany also encrypts and encodes the packet payloads before transmission to its C2 server using the AES-128-CBC algorithm and a pseudo-randomly generated initialization vector (IV) (see Figure 3).

Figure 3. Unpacked Karagany binary strings showing AES key. (Source: Secureworks)

The AES encryption key used is hard-coded in the binary as an ASCII string of hexadecimal values and was the same in all 2017 and 2018 samples analyzed by CTU researchers. The string is visible within the unpacked Karagany binary and is not itself encrypted. Once the payload has been AES-encrypted, it is prepended with the IV value and Base64-encoded for transmission. Figures 4 and 5 show an example decode and decryption based on sinkhole data obtained by CTU researchers of a Karagany beacon payload.

Figure 4. Base64 decoding Karagany C2 beacon with CyberChef. (Source: Secureworks)

Figure 5. AES decrypting Karagany C2 beacon using CyberChef. (Source: Secureworks)

C2 configuration decryption

Although a large number of strings are visible in the unpacked Karagany executable file, the details of the hard-coded C2 servers are still obfuscated and are decrypted in memory as needed during execution. The relatively simple XOR encryption function uses the value 0xF for the first byte of the key and adds 0x1 to this value for each further byte: 0x0F, 0x10, 0x11, 0x12 [...]. In the samples observed by CTU researchers, a number of parameters were obfuscated using this technique, including the C2 IP address as well as the URL and URI path used for communication with the C2 server.

On some infected machines, the %LOCALAPPDATA%\SearchIndexer\ngate.txt file was present and contained RC4-encrypted C2 IP addresses. The RC4 decryption key for this file is hard-coded in the Karagany malware and was the same across all observed samples:

8fPa,i.h-dookmipxRFAp$'z8[%@b*U#:oXQXXa

Plugins

The main purpose of Karagany is to provide a threat actor the capability to remotely execute additional plugins on the victim's machine. CTU researchers observed a wide range of plugins dropped and executed via Karagany in 2017 and 2018. In addition to the plugins described below, CTU researchers have observed a few others compiled on-the-fly specifically to interact with other tools deployed by the IRON LIBERTY group on victims' networks.

Listrix

The most commonly observed plugin downloaded and executed by far was Listrix, a simple file-searching utility. The 2017 and 2018 versions of the module include the following hard-coded list of file extensions to search for:

*.txt,*.bat,*.pcf,*.vsd,*.zip,*.pfx,*.cer,*.crt,*.pem,*.key,*.cfg,*.conf,*.rar,*.docx,

*.xlsx,*.pst,*.doc,*.rtf,*.pass*.*,*.pdf,*.xls

During execution, a temporary file is used to stored results under %LOCALAPPDATA%\Temp\<random characters>.tmp. Once complete, this file is moved to %APPDATA%\Update\Tmp\fls.txt for collection by the threat actor. The fls.txt file uses a tab-delimited format for the three fields: file path, file size, and last write time.

Upon completion, the plugin is configured to self-delete via the following command:

cmd.exe /c del <plugin binary path> >> NUL

CTU researchers have observed multiple variants of the Listrix plugin. The main differences are the file extensions searched for and the excluded paths.

SysInfo

The SysInfo plugin runs a selection of basic reconnaissance commands on the victim's machine via a cmd.exe process:

systeminfo

cmdkey /list

tasklist /v

netstat -nao

netstat -rn 

ipconfig /all

arp -a

net share

net use

net user %username%

net user %username% /domain

set

dir %systemdrive%\Users*.*

dir %appdata%\Microsoft\Windows\Recent*.*

dir %userprofile%\Desktop\*.*

dir %programfiles(x86)

dir %programfiles%

dir %appdata% 

whoami /all 

The results of these commands are piped to a hard-coded output file: %APPDATA%\Update\Tmp\res.txt. As with other plugins, the plugin self-deletes from disk following successful execution.

ScreenUtil

The ScreenUtil module, which was first reported in 2017, takes a screenshot of the current user's desktop. All variants analyzed by CTU researchers were hard-coded to drop the captured image files to %APPDATA%\Update\Tmp\.

A number of variants of ScreenUtil have been observed by CTU researchers, showing clear changes in how the plugin operates over time.

Pre-2017 variants are much simpler in function and simply leverage the Windows GDI library to capture the screen to a file called picture.png file before self-deleting. Multiple executions of this plugin overwrite the previous screenshot if it has not been moved or renamed.

The version compiled in 2017 is much more complex, is multi-threaded, and has additional functionality:

• Creates system events "__pickill__" and "__pic__" that act as mutexes and facilitate self-removal.
• Installs itself to %APPDATA%\Roaming\Microsoft\ScreenUtil.exe.
• Creates an entry in the user's Startup folder for persistence.
• Monitors the current foreground window title for a list of hard-coded keywords (headtime, total, outlook, passw, auth, login, message, letter, enter, request, reply, scheme, plan, secret, graf, bank, mail, passview). If a window is open with any of these keywords in the title, a screenshot is taken in BMP format before being converted to a JPG file and stored to the install path as "pic.jpg". This file is then copied to the main Karagany plugin data folder %APPDATA%\Roaming\Update\Tmp and given a unique name of pic%d.jpg, where %d is the current system tick count.

Due to the persistence capability of 2017 and 2018 variants, this plugin remains resident on disk, allowing for detection through persistence mechanism monitoring.

Keylogger

CTU researchers observed a standalone keylogger plugin compiled in March 2016 on a number of infected machines. This plugin was deployed via multiple variants of Karagany and does not seem to have been subject to additional development activity.

The keylogger is similar in design to the 2017 ScreenUtil plugins and has the following characteristics:

• Creates events "__klg__" and "__klgkillsoft__" to act as mutexes and facilitate self-removal.
• Installs itself to %APPDATA%\Intel Corporation\IAStorIcon.exe.
• Creates an entry in the user's Startup folder for persistence.
• Uses the SetWindowsHookExW API function to capture keystrokes system-wide.
• Formats and writes the keylogger output to %APPDATA%\Update\Tmp\k%d.txt, where %d is the current system tick count.

LogKatz

The LogKatz plugin is a .NET C# binary compiled in 2015. It contains a Base64-encoded, Gzip-compressed version of the Invoke-Mimikatz PowerShell script (see Figure 6). The version of the script specifically embedded in variants analyzed by CTU researchers was pushed to GitHub on February 17, 2015.

Figure 6. DNSpy output showing Main function of LogKatz. (Source: Secureworks)

The binary decodes both the Invoke-Mimikatz payload and the required command-line arguments using the "GetKatz" and "GetCommand" functions (see Figure 7). It then executes these elements directly via the C# PowerShell.Invoke method.

Figure 7. DNSpy output showing GetKatz/GetCommand function of LogKatz. (Source: Secureworks)

The decoded command-line arguments are standard Mimikatz arguments:

Invoke-Mimikatz -Command "privilege::debug sekrulsa::logonpasswords exit"

The output from this command is logged to %APPDATA%\LogKatz.dat and then moved to %APPDATA%\Update\Tmp\LogKatz.dat for extraction.

There is also an unused function inside the binary called "isDomainJoined", which returns a Boolean result indicating if the machine is part of an Active Directory domain.

Browser Data Viewer

The Browser Data Viewer plugin is another binary compiled in 2015. It is used to extract credentials, form data, and browsing history entries from commonly used Internet browsers such as Chrome, Firefox, and Internet Explorer. The methods used are typical of other browser data extraction tools and do not merit in-depth analysis. The output from this plugin is stored in %APPDATA%\Update\Tmp and is dependent on which web browsers are installed and have data to extract. Possible output files include outGo.txt, outFF.txt, outIE.txt, outGA.txt, outFA.txt, and outIA.txt. This plugin does not self-delete on completion of its execution.

MCMD

The MCMD plugin is a Windows binary that provides a custom reverse command shell to the threat actor via a compromised PHP web page. As Karagany does not provide command shell access, CTU researchers have observed this tool being used to deploy additional binaries to a victim's machine, carry out initial reconnaissance, and configure other tools. In some incidents, a standalone version of MCMD was used to deploy the Karagany malware.

Links to IRON LYRIC

Many of the plugins deployed via Karagany contain various links and similarities to tools used by a threat group tracked by CTU researchers as IRON LYRIC (also known as the TeamSpy group). IRON LYRIC was last known to be active in 2013, and CTU researchers assess that it may have been operated by a Russian intelligence service and tasked with covert surveillance of individuals.

A 2013 third-party report on the TeamSpy group describes a keylogger that is similar to samples analyzed by CTU researchers in 2018. The connections are many, including the two system events "__klg__" and "__klgkillsoft__", the keylogger naming convention, the program flow, and the use of "preferences.xml". CTU researchers assess that the Karagany keylogger is derived from the codebase detailed in the report.

The Listrix plugin dropped by Karagany bears uncanny similarity to the "FileList2" plugin in the 2013 report. The temporary file naming convention, output format, and overall program flow are almost identical. The file header mentioned in the 2013 report is not included in the Listrix plugin, likely due to the ease with which it could be detected by antivirus vendors. It is highly likely that the Listrix plugin is derived from the same codebase as the "FileList2" plugin used by IRON LYRIC.

Additional similarities also exist in the file metadata of some 2017 Karagany plugins and historic IRON LYRIC binaries. A 2017 SysInfo plugin analyzed by CTU researchers has the version information shown in Figure 8. Identical metadata can be found in an IRON LYRIC TeamBot sample from 2012 (see Figure 9).

Figure 8. PE metadata from SysInfo plugin. (Source: Secureworks)

Figure 9. 2012 TeamBot metadata. (Source: VirusTotal)

Binary analysis

The majority of 2017 and 2018 Karagany samples analyzed by CTU researchers were packed using a custom packer, albeit a reasonably simple one that performs a number of binary shifts and logic operations. Karagany campaigns in 2016 and prior typically used the UPX packer as an additional layer of obfuscation, but this behavior was not observed in 2017-2018 samples. Once unpacked, the malware creates a copy of its own process with a suspended thread and injects the unpacked code into the new process before calling the ResumeThread API. Breaking on this function call in a debugger allows an analyst to dump the process and extract the unpacked Karagany binary for further analysis.

Prior to executing fully, Karagany uses a robust anti-VM detection function that can detect most commonly used virtualization platforms such as VMWare, VirtualBox, VPC, and generic virtualization techniques. A sample that was compiled in May 2018 had the anti-VM routine completely re-factored and thinned down. Only the VMWare and VirtualBox checks retained, mainly based on loaded drivers and file paths. This change dramatically reduced the file size of the malware. In all cases, the anti-VM checks return a Boolean value and can be easily patched out or evaded with a debugger as shown in Figure 10.

Figure 10. Karagany VM detection evasion. (Source: Secureworks)

Conclusion

Karagany is only one of a variety of tools operated by IRON LIBERTY. Its presence indicates a much wider compromise that utilizes and combines many other tools, techniques, and procedures. Karagany as a malware family is not particularly sophisticated, and although it has been subject to continued development since its adoption by IRON LIBERTY, its core functionality has not changed. It does not contain kernel-mode components, and many of its plugins do not require privileged access.

Incremental changes to format strings, C2 paths, and the use of custom packers have allowed Karagany to evade the majority of traditional antivirus products. Deployment of anomaly-based tools, such as an endpoint detection and response (EDR) agent, could quickly identify Karagany without signatures based on its installation, persistence, and modus operandi.

Basic security controls such as least privilege, software restriction policies, and application whitelisting can prevent malware such as Karagany from executing. Inspection of SSL traffic at the perimeter and monitoring of unusual or rare User-Agent strings can also aid analysts in detecting the unusual behavior exhibited by the malware variants discussed in this analysis.

Threat indicators

The threat indicators in Table 2 can be used to detect activity related to the Karagany malware and associated plugins, as used by IRON LIBERTY. Note that IP addresses can be reallocated. The domains, URLs, and IP addresses may contain malicious content, so consider the risks before opening them in a browser.

Table 2. Indicators for this threat.

References

Kaspersky Lab Global Research and Analysis Team (GReAT). "The ‘TeamSpy' Story - Abusing TeamViewer in Cyberespionage Campaigns." March 20, 2013. https://media.kasperskycontenthub.com/wp-content/uploads/sites/43/2018/03/20134928/theteamspystory_final_t2.pdf

Lellia, Andrea. "Dream Loader: the new bot C&C engine of your dreams." Symantec. December 20, 2010. https://www.symantec.com/connect/blogs/dream-loader-new-bot-cc-engine-your-dreams

Secureworks. "MCMD Malware Analysis." July 11, 2019. https://www.secureworks.com/research/mcmd-malware-analysis

Secureworks. "Resurgent IRON LIBERTY Targeting Energy Sector." July 11, 2019. https://www.secureworks.com/research/resurgent-iron-liberty-targeting-energy-sector

Symantec. "Dragonfly: Cyberespionage Attacks Against Energy Suppliers." July 7, 2014. https://www.symantec.com/content/en/us/enterprise/media/security_response/whitepapers/Dragonfly_Threat_Against_Western_Energy_Suppliers.pdf

Symantec. "Dragonfly: Western energy sector targeted by sophisticated attack group." October 20, 2017. https://www.symantec.com/blogs/threat-intelligence/dragonfly-energy-sector-cyber-attacks