Kaspersky identifies implants used by adversaries for uploading data against industrial organizations

Researchers from the Kaspersky ICS CERT team published the third and final part of its research based on an investigation of a series of attacks against industrial organizations in Eastern Europe. In total, the researchers detected over 15 implants and their variants planted by the hacker(s) in various combinations, as these adversaries aimed to establish a permanent channel for data exfiltration, including data stored on air-gapped systems.

The entire stack of implants used in attacks can be divided into three categories based on their roles, with the first-stage implants for persistent remote access and initial data gathering; the second-stage implants for gathering data and files, including from air-gapped systems; and the third-stage implants and tools used to upload data to C2. 

The researchers presented in a blog post last week that “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.”

“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 Kaspersky researchers detailed. “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 their 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[dot]exe’). All variants of third-step payloads in this chain were almost identical, except for the C2 address.”

The Kaspersky post added that “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 hacker deployed a new variant of the second-step implant, whose capabilities included looking up file names in the Outlook folder, executing remote commands and uploading local or remote ‘[dot]rar’ files to Dropbox by calling the third-step implant. “Before executing any remote command, the implant checks if the privileges are sufficient to access the remote host by calling a tool named ‘libvlc[dot]exe,’ which was not identified in the course of the research, with the following parameters: username, domain, SID, hostname, and ntlm hash,” according to the Kaspersky post. 

The researchers further detailed that 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 also noted that before calling the third-step implant to upload files, the second-step implant prepends a custom header to each ‘[dot]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.”

Kaspersky also discovered two tools used by the hacker for manual data exfiltration. One tool, named ‘AuditSvc[dot]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[dot]ini.’ 

The second tool discovered, named ‘transfer[dot]exe,’ was designed to upload and download arbitrary files to and from any of 16 supported temporary file sharing services.

“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,” according to the post. “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[dot]log.’ as an email attachment via the Yandex email service.”

The implant designed to send files via the Yandex email service was downloaded from Yandex Disk, the researchers said. “It was also statically linked with libcurl[dot]dll. The implant is designed to exfiltrate a single file located at the static path ‘C:\Users\Public\Downloads\111.log’ (which was hard-coded into the implant). The ‘[dot]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[dot]dll to send the email via smtp[dot]yandex.ru on TCP 465. The file ‘111[dot]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,” they added. 

The post also observed that 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,’” it added.

In conclusion, the Kaspersky researchers analyzed a broad set of implants used by the hacker(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).”

Anna Ribeiro

Industrial Cyber News Editor. Anna Ribeiro is a freelance journalist with over 14 years of experience in the areas of security, data storage, virtualization and IoT.