New modular downloaders fingerprint systems - Part 3: CobInt

September 11, 2018
Proofpoint Staff


Proofpoint researchers discovered two new modular downloaders this summer: Marap [1] and AdvisorsBot [2], both of which were noteworthy for their small footprints, stealthy infections, and apparent focus on reconnaissance. We have also observed an actor commonly known as Cobalt Gang (or Group) using another new downloader that shares many of these characteristics since early 2018. Group-IB named this malware “CobInt” and released a report on its use by Cobalt Gang in May [3]. While we noticed that Cobalt Gang appeared to stop using CobInt as a first-stage downloader around the time researchers at Group-IB published their findings, they have since returned to using the downloader as of July. Arbor Networks also recently released a blog post detailing some of the renewed CobInt activity [4]. In this post, we describe recent activity that we have observed and analyze the multi-stage CobInt malware in detail.

Campaign Analysis

On August 2, 2018, we observed messages with the subject “Подозрение на мошенничество” (Translated from Russian: “Suspicion of fraud”) purporting to be from “Interkassa” using a sender email address with a lookalike domain “denis[@]inter-kassa[.]com”. The messages contained two URLs. The first linked to a macro document that ultimately installed the More_eggs downloader [5], while the second linked directly to the CobInt stage 1 executable. This campaign was also detailed in Arbor’s report [4].

On August 14, 2018, we observed messages spoofing the Single Euro Payments Area (SEPA) with lookalike sender domains sepa-europa[.]com or sepa-europa[.]info and subjects such as “notification”, “letter”, “message”, and “notice”. The messages (Figure 1) contained:

  1. A Microsoft Word attachment (sepa rules.doc) -- a ThreadKit [6] exploit document that would exploit CVE-2017-8570, CVE-2017-11882, or CVE-2018-0802 -- to execute the embedded CobInt Stage 1 payload.
  2. In some cases, URLs linking directly to the CobInt downloader.

Figure 1: Example message from August 14

On August 16, 2018, we observed messages purporting to be from Alfa Bank using a lookalike domain aifabank[.]com and subjects such as “Fraud Control”, “Фрауд” (Translates to “Fraud”), “Предотвращение хищения” (Translates to “Prevention of theft“), and “Блокирование транзакций” (Translates to “Transaction Blocking”). The messages (Figure 2) contain URLs linking to a hosted ThreadKit exploit document that would exploit CVE-2017-8570, CVE-2017-11882, or CVE-2018-0802, to execute the embedded CobInt Stage 1.

Figure 2: Example message from August 16, with stolen branding

On September 4, 2018, we observed messages purporting to be from Raiffeisen Bank using lookalike sender domains ralffeisen[.]com and subjects such as “Fraudulent transaction”, “Wire Transfer Fraud”, and “Request for data”. The messages (Figure 3) contained a Microsoft Word attachment that used a relationship object to download an external VBscript file containing an exploit for CVE-2018-8174 leading to the execution of CobInt stage 1.

Figure 3: Example message from the September 4 campaign

Malware Analysis

CobInt is a downloader malware written in C. Its name is based on the association of the malware with the “Cobalt Group” threat actor and an internal DLL name of “int.dll” used in some of the samples. The malware can be broken up into three stages: an initial downloader that downloads the main component, the main component itself, and various additional modules.

Stage 1: Basic Downloader

The first stage is a basic downloader with the purpose of downloading the main CobInt component. As with other downloaders we have examined recently, its functionality is disguised by the use of Windows API function hashing (an implementation of the hashing algorithm in Python is available on Github [7]).

The command and control (C&C) host and URI are stored as encrypted strings. The encryption algorithm is a basic XOR with a 4-byte key that changes from sample to sample (an IDA Pro Python script that extracts and decrypts the strings from a memory dump is available on Github [8]). In the analyzed sample (from August 14) the C&C host and URI were “rietumu[.]me” and “xaczkajeieypiarll” respectively.

The next stage is downloaded via HTTPS and an example of request and response data is shown in Figures 4 and 5.

Figure 4: Stage 1 HTTPS request

Figure 5: Stage 1 HTTPS response data

The response data is encrypted using three layers (a Python script that decrypts the response is available on Github [9]):

  1. A character-based substitution cipher
  2. Base64 encoding
  3. XOR using the same XOR key as used for string encryption

The decrypted data contains a DLL, which is CobInt’s main component. Stage 1 finishes by loading and executing the DLL.

Stage 2: Main Component

The main component downloads and executes various modules from its C&C. C&C hosts are stored in a 64-byte chunk of encrypted data. They can be decrypted by XORing with a 64-byte XOR key (an IDA Pro Python script that can extract and decrypt the hosts from a memory dump is available on Github [10]). C&C hosts are pipe delimited, but at the time of publication we have not seen more than one host specified in the encrypted text. In the analyzed sample, the C&C host was the same as the stage 1 C&C: rietumu[.]me.

The malware uses HTTPS to communicate with the C&C server. An example command poll request is shown in Figure 6.

Figure 6: Stage 2 HTTPS command poll request

The C&C URI is similar to the stage 1 URI, but instead of being hardcoded, the URI is generated for each request. The URI generation encodes information that is likely used as a “bot ID” to identify the victim:

  • A random 4- to 10-byte XOR key is generated
  • The following data is hashed with the algorithm shown in Figure 7 below:
    • Hash of the MAC Address (same algorithm as in Figure 7)
    • Current process ID
    • Unknown argument (hardcoded to 0x01)
  • The hashed data is XOR-encoded using the randomly generated XOR key
  • The following data is organized into a binary structure:
    • Random XOR key length
    • Random XOR key
    • XOR-encoded hashed data
  • The entire structure is XOR-encoded with the 64-byte XOR key used in the C&C host obfuscation
  • The binary data is encoded into characters using an unknown encoding algorithm

Figure 7: Hash function used in various parts of stage 2

An example of response data is shown in Figure 8.

Figure 8: Stage 2 HTTPS response data

The response is meant to look like an HTML file by including various HTML tags (a creative way to potentially make analysts and tools overlook it), but, in fact, contains encrypted data. It can be decrypted using the following process (Python scripts that perform the decryption are available on Github [11]):

  • Remove HTML tags
  • Convert all text to lowercase
  • Remove all characters that are not “a-z”
  • Convert the characters into binary data via an unknown decoding algorithm
  • XOR decrypt the binary data with the embedded 64-byte XOR key used in C&C host decryption
  • Perform a second round of XOR decryption using the following key:
    • XOR key length is indicated by the last byte of data
    • XOR key is the last “X” bytes of data (excluding length byte), where “X” is the length of the key

A decrypted response contains the following structure:

  • Command (BYTE)
  • Command ID (DWORD)
  • Command data

We have identified four commands that may be sent to the malware from the C&C:

  1. Load/execute module
  2. Stop polling C&C
  3. Execute function set by module (at the time of publication we have not seen how this functionality is used)
  4. Update C&C polling wait time

Stage 3: Modules

Command 1 above implements the main functionality of CobInt: to download and execute additional modules. The data for this command is organized in the following binary structure:

  • Module hash (see Figure 7 above) (DWORD)
  • Module length (DWORD)
  • Module
  • Entry point (DWORD)
  • Unknown DWORD passed to module
  • Unknown remaining data passed to module

Modules are loaded as shellcode and begin executing at the indicated entry point. The code at the entry point XOR decrypts itself with a 4-byte XOR key that changes from module to module (see Figure 8). Once decrypted, the module turns into a DLL.

Figure 9: Example of module decrypting itself into a DLL

When the module DLL is executed, an “operations” function is also passed to it from the main component that defines two operations:

  1. Queue data in the main component to be sent to the C&C server
  2. Register a function to be executed by command 3 (at the time of publication we have not seen how this functionality is used)

Module responses and error messages are queued up and sent to the C&C server during the next command poll request. If there are any messages to be sent during the command poll, the HTTPS request is switched from GET to POST and the message is included as POST data. Message data is formatted in the following binary structure:

  • Module hash
  • Response/error code
  • Data length
  • Data
  • Random 32- or 64-byte XOR key

The message is encrypted in 3 layers:

  1. First four components are XOR-encrypted using the randomly generated XOR key
  2. The entire structure is XOR-encrypted using the embedded 64-byte XOR key used in C&C host encryption
  3. The binary data is converted to characters using an unknown encoding algorithm

At the time of publication we have observed two modules being sent from a C&C server, whose function was to:

  1. Send a screenshot to the C&C
  2. Send a list of running process names to the C&C

We assume then that, following the reconnaissance actions above, threat actors would deploy additional modules to infected systems of interest.


CobInt provides additional evidence that threat actors -- from newer players we featured in our AdvisorsBot blog to established actors like TA505 and Cobalt Group-- are increasingly looking to stealthy downloaders to initially infect systems and then only install additional malware on systems of interest. As defenses improve across the board, threat actors must innovate to improve the returns on their investments in malware and infection vectors, making this approach consistent with the “follow the money” theme we have associated with a range of financially motivated campaigns over the years. This appears to be the latest trend as threat actors look to increase their effectiveness and differentiate final payloads based on user profiles.














Indicators of Compromise (IOCs)


IOC Type




Download URL to Macro Document (August 2)




Download URL to CobInt Stage 1 (August 2)




Download URL to CobInt Stage 1 (August 2)



Macro Document (August 2)



CobInt Stage 1 (August 2)



CobInt C&C (August 2)



ThreadKit Attachment (August 14)




CobInt Stage 1 Download URL (August 14)




CobInt Stage 1 Download URL (August 14)



CobInt Stage 1 Download URL (August 14)



CobInt Stage 1 (August 14)



CobInt C&C (August 14)



CobInt Stage 2 (August 14)



Decrypted Screenshot Module (August 14)



Decrypted Get Process Names Module (September 4)



Download URL to ThreadKit Document (August 16)



ThreadKit Document (August 16)



CobInt Stage 1 (August 16)



CobInt C&C (August 16)



Exploit Document (September 4)



Download URL to CVE-2018-8174 VBS (September 4)



CVE-2018-8174 VBS (September 4)



CobInt C&C (September 4)


ET and ETPRO Suricata/Snort Signatures

2832437 || ETPRO TROJAN Observed Malicious SSL Cert (cobint Downloader)

2832171 || ETPRO TROJAN Observed Malicious SSL Cert (cobint Module CnC)