In 2022 we investigated a series of attacks against industrial organizations in Eastern Europe. In the campaigns, the attackers aimed to establish a permanent channel for data exfiltration, including data stored on air-gapped systems.
Based on similarities found between these campaigns and previously researched campaigns (e.g., ExCone, DexCone), including the use of FourteenHi variants, specific TTPs and the scope of the attack, we have medium to high confidence that a threat actor called APT31, also known as Judgment Panda and Zirconium, is behind the activities described in this report.
To exfiltrate data and deliver next-stage malware, the threat actor (or actors) abuse(s) a cloud-based data storage, e.g., Dropbox or Yandex Disk, as well as a service used for temporary file sharing. They also use C2 deployed on regular virtual private servers (VPS). In addition, the threat actor(s) deploy(s) a stack of implants that collect data from air-gapped networks via infected removable drives.
For most implants, the threat actor(s) use(s) similar implementations of DLL hijacking (often associated with Shadowpad malware) and memory injection techniques, along with using RC4 encryption to hide the payload and to evade detectionlibssl.dll or libcurl.dll was statically linked to implants to implement encrypted C2 communications.
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:aaaaaa
- 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
Technical details of the attacks, as well as recommendations and indicators of compromise, can be found in the full public version of the article on the Kaspersky ICS CERT website.
A private version of the article has been published on Kaspersky Threat Intelligence.
For more information please contact ics-cert@kaspersky.com.
First-stage implants for remote access
Variants of FourteenHi
FourteenHi is a malware family discovered in 2021 in a campaign that was dubbed ExCone (1, 2), active since mid-March 2021 and targeting government entities. In 2022 we discovered new variants used in attacks against industrial organizations.
Various samples of FourteenHi (both x64 and x86) are significantly different from each other in their code structure, i loaders, and C2 types. But their core distinctive features, such as the C2 communication protocol and the list of commands, are pretty much the same.
The loading scheme is more or less the same for all of the variants and consists of three main components:
All known variants of FourteenHi have config data embedded in their code and encrypted with RC4. The configuration defines the campaign ID, C2 address and port. The configuration of FourteenHi x64 also defines the name and description of the Windows service it creates for persistence when executed without parameters.
MeatBall backdoor
The MeatBall backdoor is a new implant that we discovered in the process of researching attacks. It has vast remote access capabilities, including making lists of running processes, connected devices and disks, performing file operations, capturing screenshots, using remote shell, and self-updating. The implant exists in variants for x86 and x64.
The implant also uses a loading scheme based on the DLL hijacking technique, but unlike many other implants, the payload is stored in the malicious DLL loader itself, not in a separate file.
The implant is statically linked with libssl.dll, which is used for SSL encryption of C2 communication.
Implant using Yandex Cloud as C2
Another implant we found was one that uses the Yandex Cloud data storage as a C2 (https://cloud-api.yandex[.]net) similarly to the malware described in an earlier report. The implant uses a DLL hijacking based loading scheme, in which the malicious DLL decrypts the implant’s body stored in a separate file and injects it into a legitimate process’s memory.
The implant uses statically linked libcurl.dll for SSL-encrypted communication.
The implant collects the following data on the host:
- Computer name
- User name
- IP address
- MAC address
- OS version
- Path to %System%
To upload the data collected to C2, the implant sends a request using an embedded API token to create a directory with a name that is unique to the victim host.
All uploaded and downloaded data is encrypted with the RC4 algorithm.
Second-stage implants for gathering data and files
Dedicated implant for gathering local files
In May 2022, a dedicated implant for gathering local files was discovered. The implant uses a loading scheme based on the DLL hijacking technique, where the malicious DLL loader ensures persistence by creating a service named “WinSystemHost”, decrypting and injecting the payload stored as binary data in a separate file into the memory of a legitimate process.
The implant starts “msiexec.exe” then read and decrypt the payload from separate file and inject it into the memory of “msiexec.exe”.
Once the payload starts to be executed in the memory of “msiexec.exe”, it runs into an endless loop consisting of 6 simple steps:
- Create folders for file storage (if they do not exist) and find the path to “WinRar.exe”
- Decrypt strings
- Read config and start searching for files on all disks
- Copy files and write log
- Archive copied files and clean up
- Sleep for 10 minutes
In order to exfiltrate the data collected, the threat actor uses a stack of implants to upload the archives to Dropbox.
Stack of implants used to exfiltrate data from air-gapped networks via removable drives
In April 2022, we discovered malware designed to exfiltrate data from air-gapped systems by infecting removable drives.
Simplified diagram of the interaction of the implant with a removable media
The first (main) module is responsible for handling removable drives, including:
- collecting information about a drive,
- cloning each drive’s filesystem structure to a local temporary folder and keeping the structure up to date,
- collecting stolen files from a drive and planting second-step malware on newly connected drives,
- capturing screenshots and window titles on the infected machine.
The main module creates a folder in “%TEMP%”, where it will store logs, info on connected drives and the drives’ contents.
Next, for each removable drive, the implant creates a subfolder, where the subfolder’s name is the same as the serial number of the drive.
The implant also checks these folders for the following files that are used to infect a removable drive whose serial number matches the name of the folder:
- “mcods.exe”, which is a legitimate McAfee executable vulnerable to DLL hijacking
- “McVsoCfg.dll”, which is the second-step payload
- “DOC”, “PDF” or “DIR” files, which define the lure link file to be used
The presence of the files mentioned above in the folder assigned to a specific removable drive indicates that the attackers first analyze the contents of removable drives for some time and only then copy the files used to infect a specific removable drive to the folder specified.
To infect a removable drive, the main module simply copies two files, “mcods.exe” and a second-step malware “McVsoCfg.dll”, to the drive’s root directory and sets the “Hidden” attribute for both files.
In addition, if a fourth-step malware exists, it will also be copied to the removable drive together with the second-step implant.
Then the main module produces a lure link file in the root directory of the removable drive.
When a user opens the lure “.lnk” file, the OS will load “mcods.exe”, which will load “McVsoCfg.dll” and call its function “McVsoCfgGetObject”.
Simplified scheme of infecting a computer in an isolated network segment through an infected removable media
After that, the implant deploys the third-step malware executable by extracting it from its own file (“McVsoCfg.dll”) and saving it to “%APPDATA%” with the name “msgui.exe” on the host being attacked.
The third-step implant, “msgui.exe”, is quite small and simple – it is designed to execute a batch script with “cmd.exe” to collect data and save the output to the drive’s “$RECYCLE.BIN” folder so that it can be collected by the main module of the malware (when connected to the originally infected host). Then it looks for any fourth-step file to be executed and then deleted (if it exists).
The fourth-step malware consists of two files:
- A simple dropper of the payload (similar to that used by second-step malware)
- The payload, which is, in fact, a modified version of the first-step module and is also designed to collect information about a drive, collect files, capture screenshots and keystrokes (when connected to the originally infected host), but without the routine responsible for infecting a removable drive
Both modules (first-step and fourth-step) have similar configurations and data saving routines:
Simplified scheme for collecting data stolen from a computer in an isolated network segment through an infected removable media
To collect all the stolen data, the threat actor uses a remote shell to run implants designed to upload data.
Third-stage implants and tools used to upload data to C2
The third-stage implants were deployed by the threat actor(s) via the first-stage, as well as the second-stage, implants.
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.
Stack of implants used to upload files to Dropbox
A stack of implants for uploading files to Dropbox is 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.
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.
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.
All the third-step variants are designed to upload the “.rar” files collected to Dropbox from “C:ProgramDataNetWorksZZ” on the local 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.
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”.
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.
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.
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.
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.
Threat actors keep making it more difficult to detect and analyze threats by hiding payloads in encrypted form in separate binary data files and by hiding malicious code in the memory of legitimate applications via DLL hijacking and a chain of memory injections.
In most cases for exfiltration of data from air-gapped networks threat actors choose TTPs based on infecting removable media.
The tendency to abuse cloud services (e.g., Dropbox, Yandex, Google, etc.) is not new, but it continues to expand, because it is hard to restrict / mitigate in cases when an organization’s business processes depend on using such services.
At the same time, abusing popular cloud-based data storages 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).
Source:: Securelist