HIDDEN COBRA Volgmer: A technical analysis

Written by: Ben Humphrey

NCC Group
Keylogged
7 min readDec 13, 2017

--

Originally published at www.nccgroup.trust.

In November, US-CERT published two alerts about malicious activity by the North Korean government, referred to as HIDDEN COBRA [1][2]. These alerts addressed the remote administration tool FALLCHILL and a Trojan called Volgmer. We’ll focus on the latter in this blog post.

Volgmer is a backdoor Trojan that was designed primarily to give covert access to infected systems and, according to US-CERT, has been in use since as early as 2013. Below, we’ll take an in-depth look into what happens when Volgmer infects a machine and the malicious actions it is capable of.

The dropper

The dropper is an x86 PE EXE file and its purpose is to install Volgmer on to the system. It does this by writing a DLL to disk and then creating a service which uses the DLL. Using a service for the persistence mechanism serves to mask the Trojan as a legitimate system component.

Embedded zip

Initial analysis of the dropper shows that it has a zip file embedded in the resources section. The zip file is password protected so it is not possible to extract the contents without further examining the binary.

Figure one — Dropper resources

Dropper execution flow

Initially, the dropper decrypts some strings using a XOR algorithm with a rolling 16 byte key. It then proceeds to dynamically load the APIs that it needs. Before it begins installation, it checks the following conditions:

  • a) The country is not Korea
  • b) The OS is Windows XP or higher and has a product type of Workstation
  • c) The uptime of the system is at least 10 hours

The dropper then checks to see if the service has already been installed. If this is the case then it will try to start the service. When these conditions have been met, the dropper will install the malware in the following phases:

  1. Name generation
  2. Registry key and file writing
  3. Service creation

Name generation

The name for the dropped file and the service name will be generated randomly from a list of strings contained in the dropper. An example of the names created can be seen below.

Figure two — Name generation

The above list contains the service short name, service long name, service description, DLL file name and DLL file path. Amusingly, the service description is written in a way that discourages removal (figure three).

Figure three — Service description

Registry and file writing

After the names are generated, the zip file in the resources section is extracted and decrypted. Helpfully, the password is contained in a list of strings that were initially decrypted, allowing manual extraction and analysis of the zip contents.

The zip actually contains two files: an x86 PE DLL and a config file. The DLL is written to the generated file path, while the config file is encrypted (using the same rolling XOR algorithm that is used for the strings) and written to a registry key: HKLM\SYSTEM\CurrentControlSet\Control\WMI\Security.

Two values are set:

  • 125463f3–2a9c-bdf0-d890–5a98b08d8898
  • f0012345–2a9c-bdf8–345d-345d67b542a1

The config file actually contains an initial list of IP address and port numbers that the service will try and connect to (see figure four).

Figure four — Config file

Service creation

Now that the DLL file has been written to disk and the IP address list has been written to the registry, the dropper will attempt to create and start the service. The service registry keys are added manually and then the service is created with the start type set to SERVICE_AUTO_START so it starts automatically when Windows boots.

Figure five — Call to CreateServiceA

The last action the dropper takes is to delete itself. It writes a batch script to disk that continually tries to delete the dropper and runs is with a CreateProcess call.

The service

The service contains the backdoor functionality of the Volgmer Trojan. Its functionality is contained entirely in the DLL, and will be invoked with svchost.exe when the system boots (or the dropper initialises the service).

There are two main phases of the service code:

  1. Setup
  2. Main loop

Setup

Like the dropper, all the strings used in the DLL are encrypted and all the APIs are loaded dynamically. So the first task for the service (aside from registering itself) is to load the APIs and decrypt all the strings.

The next task is to load the config from the registry, decrypt it and then store the list of IP addresses in memory for later use.

Just before the main loop starts, the DLL will generate a random integer using GetTickCount as the seed. This integer will be multiplied using the lea instruction and then shifted left to further increase its value.

Figure six — Sleep call

Main loop

The main loop of the service continually gathers data and checks for commands from the control servers.

Network communication

Volgmer’s network communication is completely custom, being implemented with sockets. It does not use standard network traffic encryption protocols but instead implements its own.

First of all, a 16 byte random value is created using the _rand function with GetTickCount as the seed. It then calculates the RIPEMD 160 hash of the random value and both the random data and hash are sent to the server. The server will generate a RIPEMD 160 hash of the hash it received from the client and then send it back. The client will generate the same hash and compare it with the reply from the server.

This strange form of ‘handshake’ is actually a rudimentary key exchange and the hash value will be used as the key to encrypt/decrypt communications with the server. The algorithm is the same rolling XOR that is used to decrypt the strings in both the DLL and the dropper.

The request headers that are used in the network communications are generated randomly for a list of strings. One interesting note is the misspelling of Mozilla in the user agent strings.

Figure seven — Random header strings

Information gathering

Before the server is polled for commands, Volgmer gathers some information to send to the server. There are the usual checks that one might expect to find in a Trojan (i.e. anti-VM checks, process blacklist) but the result of the checks does not influence the execution flow.

Virtual machine detection

Volgmer attempts to ascertain if it is running in a VMware or VitualBox virtual machine (VM) using two widely known anti-VM checks. Its third and final check uses the esoteric vpcext (visual property container extender) instruction. On some VMs the instruction will succeed, while on a physical machine the instruction will throw an exception.

Figure eight — vpcext instruction

Other information

A number of other checks are done, which include checks for anti-virus software (see figure nine), if the process is being debugged, a process blacklist (looking for tools like OllyDbg, Process Monitor, Wireshark, etc) and a registry key blacklist.

Registry key examples:

  • SOFTWARE\VanDyke\SecureCRT
  • SOFTWARE\RealVNC
  • SOFTWARE\Radmin
  • SOFTWARE\FileZilla Client
Figure nine — AV strings

Server commands

The table below details the commands that Volgmer can receive from the server:

Indicators of compromise

Registry keys:

IP addresses and ports

Samples analysed

Dropper (SHA256)

Service DLLs (SHA256)

References

  1. https://www.us-cert.gov/ncas/alerts/TA17-318A
  2. https://www.us-cert.gov/ncas/alerts/TA17-318B

Published date: 13 December 2017

--

--

NCC Group
Keylogged

NCC Group is a global expert in cyber security and risk mitigation.