This is the third part of our research based on an investigation of a series of attacks against industrial organizations in Eastern Europe.
The attackers aimed to establish a permanent channel for data exfiltration, including data stored on air-gapped systems.
In total we have identified over 15 implants and their variants planted by the threat actor(s) in various combinations.
The entire stack of implants used in attacks can be divided into three categories based on their roles:
- First-stage implants for persistent remote access and initial data gathering
- Second-stage implants for gathering data and files, including from air-gapped systems
- Third-stage implants and tools used to upload data to C2
In this part we present information on the four types of implants and two tools used during the last (third) stage of the attacks discovered. The third-stage implants were deployed by the threat actor(s) via the first-stage, as well as the second-stage, implant.
Third-stage implants have much in common with the first-stage implants, including the use of a cloud-based data storage (e.g. Dropbox, Yandex Disk), code obfuscation, and the implementation of DLL hijacking techniques.
The full report is available on the Kaspersky Threat Intelligence portal.
For more information please contact ics-cert@kaspersky.com.
Stack of implants used to upload files to Dropbox
In the course of our research, we identified a stack of implants for uploading files to Dropbox, designed to work in tandem with a second-stage file-gathering implant.
The malware stack consists of three implants forming a straight execution chain (which consists of three steps).
The first step is used for persistence, the deployment and startup of the second-step malware module, which is responsible for uploading the files collected to the server by calling the third-step implant and cleaning up.
This architecture allows the threat actor to change the execution flow by replacing a single module in the chain. During our analysis, we identified five variants of third-step and two variants of second-step implants deployed a few months after the initial attack.
The very first variants of second-step implants in the chain were designed to decrypt a third-step payload and inject it into a legitimate process (e.g., “msiexec.exe”). All variants of third-step payloads in this chain were almost identical, except for the C2 address.
The C2 IP address in one of the third-step variants caught our attention because it was a local IP address. This means that the threat actor deployed a C2 inside the corporate perimeter and apparently used it as a proxy to exfiltrate data from hosts that didn’t have direct access to the internet.
Later, the threat actor deployed a new variant of the second-step implant, whose capabilities included looking up file names in the Outlook folder (i.e., email account names), executing remote commands and uploading local or remote “.rar” files to Dropbox by calling the third-step implant.
The table below summarizes all commands with which this second-step implant expects to be executed (it terminates if called with no command-line arguments):
| Command | Parameters | Description |
|---|---|---|
| uploadlocal | Call third-step implant to upload local .rar files from “C:ProgramDataNetWorksZZ” to a Dropbox folder and clean up. | |
| Uploadremote | [username] [domain] [SID] [host] [ntlm-hash] | Copy .rar files from ”C:ProgramDataNetWorksZZ” on a remote machine to a local folder, then delete files on the remote machine and call third-stage implant to upload local .rar files to a Dropbox folder, then clean up |
| checkoutlook | [username] [domain] [SID] [host] [ntlm-hash] | Search for an Outlook folder on a local or remote host and print file listing to stdout. |
| Wmic | [username] [domain] [SID] [host] [ntlm-hash] [command] | Execute a cmd command locally or remotely and log output to the file “c:windowsdebugout.txt”, then read the file and print its contents to stdout, then delete the file “out.txt” (locally or remotely) |
Before executing any remote command, the implant checks if the privileges are sufficient to access the remote host by calling a tool named “libvlc.exe”, which was not identified in the course of the research, with the following parameters: username, domain, SID, hostname, and ntlm hash.
To upload local files, the second-step implant calls a third-step implant, which is supposed to be already deployed on the machine either at the statically defined path “c:/users/public/” or at the same path as the second-step implant.
It should be noted that before calling the third-step implant to upload files, the second-step implant prepends a custom header to each “.rar” file. The header contains the name of the host which is the source of the file and the original file name (which is simply the file creation date and a time). The threat actor does this to avoid losing such metadata: when a file is uploaded to Dropbox, the implant changes its name to a pseudorandom sequence of numbers.
All the third-step variants are designed to upload the “.rar” files collected to Dropbox from “C:ProgramDataNetWorksZZ” on the local machine. This operation is performed as follows:
- Connect to Dropbox using an embedded OAuth token, create a folder with a name matching that of the local machine.
- Upload a small “host” file, which contains basic information about the local machine (machine name, user name, IP address, MAC address) encrypted with RC4.
- Encrypt all “.rar” files with RC4 and upload them to Dropbox.
- Remove all “.rar” files located in “C:ProgramDataNetWorksZZ” on the local machine.
Along with the stack of implants described above, we have discovered a “.bat” script file used to delete intermediate steps and artifacts in “c:UsersPublic”. The script was probably used before updating the stack of implants or if the threat actor decided to abandon an infected machine.
Tools for manual exfiltration of stolen files
Along with various other implants, we discovered two tools used by the threat actor for manual data exfiltration.
Tool used to upload files to Yandex Disk
One tool, named “AuditSvc.exe”, was designed for uploading and downloading arbitrary files to and from Yandex Disk. The OAuth token, file path and some other parameters could be passed as command line arguments. Alternatively, the parameters could be defined in a config file named “MyLog.ini”.
Tool used to upload files to temporary file sharing services
The second tool discovered, named “transfer.exe”, was designed to upload and download arbitrary files to and from any of 16 supported temporary file sharing services.
| Service | URL address |
|---|---|
| imgonl(onl) | https://img[.]onl/api/upload.php |
| litterbox(lit) | https://litterbox.catbox[.]moe/resources/internals/api.php |
| imgbb(ibb) | https://imgbb[.]com/ |
| transfer(trs) | https://transfer[.]sh |
| schollz | https://share.schollz[.]com |
| null(0x0) | https://0x0[.]st/ |
| tinyimg(tin) | https://tinyimg[.]io/upload |
| gifyu(gif) | https://gifyu[.]com/ |
| imgshare(ims) | https://imgshare[.]io/ |
| imgpile(imp) | https://imgpile[.]com/ |
| zippyimage(zip) | https://zippyimage[.]com/ |
| extraimage(ext) | https://extraimage[.]info/ |
| picpaster(pic) | https://upload.picpaste[.]me/ |
| imaurupload(imu) | https://imgurupload[.]org |
| sm.ms(sms) | https://sm[.]ms/api/v2/upload |
| easycaptures(esy) | https://easycaptures[.]com/upload_file_new.php |
Along with various parameters designed for flexibility and optimization, the tool can generate and use a client-side RSA key.
After uploading data, the tool creates a JSON file with the “upload_” prefix, which contains a URL generated by the file sharing service to access the data stored.
The threat actor most probably used the tool manually or semi-manually to upload logs and other files to file sharing services, while the resulting JSON containing URLs could be uploaded by any of the first-stage implants described in the first part of the article or by the implant designed to send a single file, “111.log”, as an email attachment via the Yandex email service (that implant is described below).
Implant used to upload files via the Yandex email service
The implant designed to send files via the Yandex email service was downloaded from Yandex Disk. It was also statically linked with libcurl.dll.
The implant is designed to exfiltrate a single file located at the static path “C:UsersPublicDownloads111.log” (which was hard-coded into the implant). The “.log” file is sent as an attachment to an email with the text “Download the attachment pls.”. The implant formatted the email body and used the “curl_perform” API of libcurl.dll to send the email via smtp.yandex.ru on TCP 465.
The file “111.log” is most probably produced by one of the previous-stage implants and can contain the output of CMD commands or URLs for files uploaded to a temporary data sharing service by a tool described above.
After a single attempt to send an email, the implant terminates. Such straight execution flow and the absence of persistence capabilities may mean that the implant was expected to be used as a tool rather than a self-sufficient service. Nevertheless, the threat actor may possibly have used a simple task scheduling technique to make it persistent and to have it executed periodically, as in the case of FourteenHi variant “E”.
Conclusion
In this research we analyzed a broad set of implants used by the threat actor(s) for remote access, to gather data and to upload data.
Abusing popular cloud-based data storages may allow the threat actor(s) to evade security measures. At the same time, it opens up the possibility for stolen data to be leaked a second time in the event that a third party gets access to a storage used by the threat actor(s).
Recommendations
- Install security software with support for centralized security policy management on all servers and workstations and keep the antivirus databases and program modules of your security solutions up-to-date.
- Check that all security solution components are enabled on all systems and that a policy is in place which requires the administrator password to be entered in the event of attempts to disable protection.
- Consider using Allowlisting and Application Control technologies to prevent unknown applications from being executed.
- Check that Active Directory policies include restrictions on user attempts to log in to systems. Users should only be allowed to log in to those systems which they need to access in order to perform their job responsibilities.
- Restrict network connections, including VPN, between systems on the OT network; block connections on all those ports the use of which is not required by the industrial process.
- Use smart cards (tokens) or one-time codes as the second authentication factor when establishing a VPN connection. In cases where this is applicable, use the Access Control List (ACL) technology to restrict the list of IP addresses from which a VPN connection can be initiated.
- Train employees of the enterprise to use the internet, email, and other communication channels securely and, specifically, explain the possible consequences of downloading and executing files from unverified sources.
- Restrict the use of accounts with local administrator and domain administrator privileges, with the exception of cases where such privileges are necessary to perform the job responsibilities.
- Consider using a password management solution to manage the passwords of local administrator accounts on all systems.
- Enforce a password policy that has password complexity requirements and requires passwords to be changed on a regular basis.
- Consider using Managed Detection and Response class services to gain quick access to high-level knowledge and expertise of security professionals.
- Use dedicated protection for the industrial process. Kaspersky Industrial CyberSecurity protects industrial endpoints and enables network monitoring on the OT network to identify and block malicious activity.
Appendix I – Indicators of compromise
Note: The indicators in this section are valid at the time of publication.
The full version of indicators of compromise, including Yara rules, is available in a .ioc file on the Kaspersky Threat Intelligence portal.
Stack of implants used to upload files to Dropbox
MD5
1A1B8EFE8D72984C4744662D2D233C02 (CrashReport.dll) 03C74722A8E6E5E7EA0A5ED0C9F23696 (a.exe) 19BC4620FB5DA10192676F01C3DC71B3 (cl.exe) EE8AFC6F3BB68F86A64FC6389F2EDC3F (cl.exe) F8553382DE7E1E349D8E91EDB7C57953 (cu.exe) 5137C61734E2096018CEE99149DAC009 (conhost.exe) 5660CB556D856D081A3DCD497549F47A (Rar2.exe) 976B59F170136B9C3C88BD9A8FC4CE4E (Rar3.exe) D6CC6A4AF4720DAF8EEE0835D6E5D374 (Rar4.exe)
Tool used to upload files to Yandex Disk
MD5
5C3A88073824A1BCE4359A7B69ED0A8D (AuditSvc.exe)
Tool used to upload files to temporary file sharing services
MD5
8BA9EE9FD6BD4B9304F7FB868CE975D8 (transfer.exe)
IP/URL
img[.]onl/api/upload.php litterbox.catbox[.]moe/resources/internals/api.php imgbb[.]com transfer[.]sh share.schollz[.]com 0x0[.]st/ tinyimg[.]io/upload gifyu[.]com/ imgshare[.]io imgpile[.]com/ zippyimage[.]com extraimage[.]info upload.picpaste[.]me imgurupload[.]org sm[.]ms/api/v2/upload easycaptures[.]com/upload_file_new.php
Implant used to upload files via the Yandex email service
MD5
971B0687C8281778B28721239801084E (qclite.dll)
Appendix II – MITRE ATT&CK Mapping
The table below contains all the TTPs identified in the analysis of the activity described in this report.
| Tactic | Technique Number | Technique Name and Description |
|---|---|---|
| Initial Access | T1566.001 | Phishing: Spearphishing Attachment Threat actors used lure documents to deploy off-the-shelf spyware. |
| Execution | T1204.002 | User Execution: Malicious File A system is infected when the user runs the malware believing it to be a legitimate document. |
| T1059.003 | Command and Scripting Interpreter: Windows Command Shell Uses cmd.exe to execute multiple commands. |
|
| T1106 | Native API Uses CreateProcessW function to execute Windows Command Line |
|
| T1053.005 | Scheduled Task/Job: Scheduled Task Malware is executed via a Windows task created by the threat actor. |
|
| Persistence | T1547.001 | Registry Run Keys / Startup Folder: Malware achieves persistence by adding itself to the Registry as a startup program. |
| T1543.003 | Create or Modify System Process: Windows Service Installs itself as a service to achieve persistence. |
|
| T1053.005 | Scheduled Task/Job: Scheduled Task Malware is executed via a Windows task created by the threat actor. |
|
| Defense Evasion | T140 | Deobfuscate/Decode Files or Information Uses an RC4 key to decrypt the malware configuration as well as communication. |
| T1055.002 | Process Injection: Portable Executable Injection Malware injects itself into various legitimate processes upon execution (msiexec.exe, svchost.exe). |
|
| T1497.001 | System Checks Employs various system checks to detect and avoid virtualization and analysis environments. |
|
| T1497.003 | Time Based Evasion Employs various time-based methods to detect and avoid virtualization and analysis environments. |
|
| T1574.002 | Hijack Execution Flow: DLL Side-Loading Threat actors abused a legitimate application binary to load a malicious DLL. |
|
| Discovery | T1083 | File and Directory Discovery The malware attempts to discover files of various types (.doc, .docx, .xls, .xlsx, .ppt, .pptx, .pdf, .rtf, .eml). |
| T1016 | System Network Configuration Discovery Threat actors use the netstat and ipconfig utilities to get local network interface configuration and enumerate open ports. |
|
| T1033 | System Owner/User Discovery Threat actors use the systeminfo, whoami, and net utilities to get information about the user and the infected system. |
|
| T1057 | Process Discovery Threat actors use tasklist to enumerate running processes. |
|
| Command and Control | T1071.001 | Application Layer Protocol: Web Protocols Malware uses HTTPS and raw TCP for communication with C2. |
| T1573.001 | Encrypted Channel: Symmetric Cryptography Malware uses RC4 and SSL TLS v3 (by libssl.dll) to encrypt communication. |
|
| Credential Access | T1003.004 | OS Credential Dumping: Cached Domain Credentials Threat actors use Mimikatz and Reg to extract cached credentials. |
| Collection | T1005 | Data from Local System Malware designed to collect and exfiltrate arbitrary data, including air-gapped systems, by abusing removable devices. |
| Exfiltration | T1041 | Exfiltration Over C2 Channel Threat actors exfiltrate data using Dropbox, Yandex Disk, Yandex email and temporary file sharing services as a C2 channel |
Authors
