Microcin is here

By GIXnews

In February 2020, we observed a Trojan injected into the system process memory on a particular host. The target turned out to be a diplomatic entity. What initially attracted our attention was the enterprise-grade API-like (application programming interface) programming style. Such an approach is not that common in the malware world and is mostly used by top-notch actors.

Due to control server reuse (Choopa VPS service), target profiling techniques and code similarities, we attribute this campaign with high confidence to the SixLittleMonkeys (aka Microcin) threat actor. Having said that, we should note that they haven’t previously applied the aforementioned coding style and software architecture. During our analysis we didn’t observe any similar open source tools, and we consider this to be the actor’s own custom code.

To deliver a new network module with a coding style that we consider enterprise-grade, Microcin used steganography inside photos, including this one of a sock (payload removed here)

SixLittleMonkeys’ sphere of interest remains the same – espionage against diplomatic entities. The actor is still also using steganography to deliver configuration data and additional modules, this time from the legitimate public image hosting service cloudinary.com. The images include one related to the notorious GitLab hiring ban on Russian and Chinese citizens. In programming terms, the API-like architecture and asynchronous work with sockets is a step forward for the actor.

Why we consider the current software architecture interesting

By “enterprise-grade API-like programming style” we mean, firstly, asynchronous work with sockets. In terms of Windows user-space entities, it was I/O completion ports. In the OS kernel space, this mechanism is actually a queue for asynchronous procedure calls (APC). We believe there’s a reason for using it in backend applications on the high-loaded server-side. Obviously, however, neither client-side software nor Trojans of this kind need this server-side programming approach. So, it looks to us like the developers have applied some habits from server-side programming.

Secondly, the exported function parameters in the injected library look more like an API: the arguments are two callback functions – encryptor/decryptor and logger. So, if the authors decide to change encryption or logging algorithms, they could do so easily without even touching the network module. Once again, even targeted malicious samples rarely take such architectural issues into consideration.

Another injected library’s exported function parameter is the host name. If the caller doesn’t pass the infected host name as this parameter, the following commands will not be executed. It filters out all messages to other hosts.

Initial infection

Module features
File name
Detection time

Backdoor sideloaded by legit GoogleCrashHandler
version.dll
2019.12.31

Downloader/decryptor inside spoolsv.exe address space
spoolsv.dll
2020.01.16

Bitmap picture with steganography inside
Random .bmp name
2020.01.16

Network module in the same spoolsv.exe address space
Module.dll
2020.01.16

Infection timeline

The backdoor is started by GoogleCrashHandler.exe, due to .dll search order hijacking (version.dll). Bitmap files with a steganography downloader and decryptor (spoolsv.dll), injected into the spoolsv.exe API-like network module, are injected into the same system process.

Let’s cover the modules one at a time. Our telemetry shows that another Microcin backdoor was already on the host before this new network module. It’s most probably a reinfection with newer malware.

Backdoor MD5
File name
Compilation timestamp
Size

c9b7acb2f7caf88d14c9a670ebb18c62
version.dll
2020.05.20 02:37:58
407552

This UPX packed .dll was executed with the legitimate GoogleCrashHandler.exe (very common library search order hijacking) just before the New Year. The compilation timestamp is obviously spoofed. In this case we don’t know how the backdoor, along with the legitimate application, was delivered.

We won’t concentrate on this backdoor in this report, because it’s fairly typical for Microcin. We just want to emphasize that the timeline above shows it existed on the host before the analyzed module.

Downloader/decryptor

The campaign in question starts with the 64-bit spoolsv.dll downloader/decryptor module that has to be loaded by spoolsv.exe into its address space.

Downloader/decryptor MD5
Modified time
Size
Build
Target ID

c7e11bec874a088a088b677aaa1175a1
2020.03.04 12:20:13
155291
20200304L02f
@TNozi96

ef9c82c481203ada31867c43825baff4
2019.10.15 11:46:04
145233
20200120L03o
@TNozi96

1169abdf350b138f8243498db8d3451e
2019.01.25 04:58:15
150195
20191119L
123456

So far, we have registered three samples of this module. The file tails contains the following encrypted configuration data.

Parameter
Length (bytes)
Possible values

.bmp URL len
4
82

.bmp URL
.bmp URL len
http://res.cloudinary.com/ded1p1ozv/image/upload/v1579489581/.bmp

Sleep time
2
17211 and other non-round random numbers

Module build length
4
15

Module build
Module build length
Date based on the previous table

Target ID length
4
9

Target ID
Target ID length
Readable strings from the previous table

Random ASCII chars
16
Randomly generated on host

Hardcoded canary
4
0x5D3A48B6

We have published the source code of our decryptor for Microcin’s configuration and steganography at https://github.com/dlegezo/common.

The bitmap URL serves to download the image (like the one with the sock shown above) with the next stage network module. The module build, target ID and random ASCII chars are for the next network module, which includes them in the control server communications.

To get the bitmap, the downloader sends an HTTP GET request to cloudinary.com. The steganography is inside the color palette part of the .bmp file. A typical decryption algorithm includes four stages:

  • Combine neighboring half bytes into one byte
  • Decrypt data length with custom XOR-based algorithm
  • Decrypt six-byte XOR key for main data
  • Decrypt data itself using decrypted length and key
  • Besides the configuration data and steganography, the same algorithm is used for the C2 traffic. As we mentioned, due to the malware architecture, the latter can easily be changed. Encryption is XOR-based, but the key scheduling is quite specific and tricky. In the corresponding appendix we provide the part of the decryptor containing the algorithm.

    Bitmap images and steganography

    Besides the sock image, the campaign operators use more social-oriented photos (payload removed here). The background here is the GitLab hiring ban on Russian and Chinese citizens

    So far, we have registered four different images. The encrypted content in all cases are PE files with the following network module and C2 domain for the files. This is the only parameter that comes from bitmap; all others are provided by the downloader.

    Image content
    C2 domain
    Network module MD5

    Sock in washing machine
    apps.uzdarakchi[.]com
    445b78b750279c8059b5e966b628950e

    Two people in hoodies
    forum.mediaok[.]info
    06fd6b47b1413e37b0c0baf55f885525

    GitLab hiring ban
    forum.uzdarakchi[.]com
    06fd6b47b1413e37b0c0baf55f885525

    Woman with child, militaries
    owa.obokay[.]com
    06fd6b47b1413e37b0c0baf55f885525

    Network in-memory module

    The downloader decrypts the configuration data and C2 domain from the bitmap and then everything is ready to start the last stage inside the same spoolsv.exe virtual address space. We consider the architectural approach in this module to be the most interesting part of the chain.

    The network module’s entry point is the exported function SystemFunction000() with multiple arguments. As a beacon, the Trojan prepares an HTTP POST request with the target’s fingerprinting data. And a lot of the parameters become part of the request.

    Exported function argument
    Parameter meaning

    Target host name
    This has to be the same as the infected machine host name. Only then will the Trojan start and receive commands. Initialized by the downloader

    Target ID
    We already enumerated these readable ASCII strings from the decrypted downloader’s config, e.g., @TNozi96

    Build version
    Inside these readable ASCII strings the dates are clearly mentioned. The C2 uses them to understand which build it’s currently working with

    WORD field of fingerprint structure
    Initialized with 0x4004 by the downloader. We don’t have enough data to describe this field’s meaning

    C2 IP address and port number
    The coordinates of the C2, initialized from the decrypted bitmap image

    ASCII string in fingerprint structure
    Unique random string generated by the downloader

    BYTE to fingerprint structure
    Initialized with 0x4004 by the downloader. We don’t have enough data to describe this field’s meaning

    Half of maximum sleep time
    Sleep time before the working cycle. Half because the full time is counted + %. It’s effectively a maximum of a maximum sleep time

    Logger address
    First callback function address. In this case it’s a logger function inside the downloader

    Encryptor/decryptor address
    Second callback function address. In this case it’s an encryptor/decryptor function inside the downloader

    The last two arguments illustrate why we call the network module API-like: any encryption and logging routine could be used without even touching the module code. We consider this programming approach as scalable and useful for large systems. Let’s take a look at these two callback arguments.

    Callback and its arguments
    Callback features

    Logger takes ASCII string as a log message
    Logger function whose parameter is the message text. In this module all the messages are shortenings like “LIOO”, “RDOE”, etc.

    Encryptor/decryptor to deal with the traffic between host and C2, takes its length, encryption key, and the flag (0 to encrypt and 1 to decrypt) as argument data
    Encryptor/decryptor function first used to encrypt beacon with target’s fingerprint. It then decrypts C2 command structures and encrypts replies to them

    The module uses the Windows API function WSAIoctl() – something rarely seen in malware – to get the ConnectEx() address and sends a prepared request. Another Windows API function, GetQueuedCompletionStatus(), is in charge of asynchronous work with I/O. In other words, the malware uses I/O completion ports for Windows user-space entities, which is effectively an APC queue in the OS kernel.

    The same data structure is used for both sides of the communication: from host to C2 and back. Let’s describe its main fields here.

    Field
    Features

    Command code
    One byte in the structure is the command code, which could vary from 0x00 to 0x16 (22). We describe the main network module commands in the table below

    Error code
    Another byte is used for the error code

    Command argument
    The main command field that takes all the necessary strings, etc. and also keeps fingerprinting data in the case of the beacon

    So far, we have described the infection chain, module architecture, custom encryption and HTTP POST-based C2 communication protocol. Last, but not least, is the command set shown in the table below.

    Command code
    Command features

    3
    Check if target’s ID meets the parameter

    4
    List logical drives

    5
    List files

    6
    Create directory

    7
    Remove directory

    8
    Copy file

    9
    Move file

    10
    Delete file

    11
    Execute PE

    12
    Execute Windows shell command

    14
    Terminate program

    15
    File download

    16
    Read from downloaded file

    17
    File upload

    18
    Write to file

    19
    Stop

    20
    Sleep

    Infrastructure

    Domain
    IP
    First seen
    ASN

    apps.uzdarakchi[.]com
    95.179.136[.]10
    November 11, 2019
    20473

    forum.uzdarakchi[.]com
    172.107.95[.]246
    February 7, 2020
    40676

    forum.mediaok[.]info
    23.152.0[.]225
    March 19, 2020
    8100

    owa.obokay[.]com
    N/A (now parked)

    To sum up

    This time the Microcin campaign has made an interesting step forward, not in terms of a fancy initial infection vector, but as programmers. The API-like network module is much easier to support and update. This improvement is not only about anti-detection or anti-analysis; it’s about software architecture and a step towards a normal non-monolithic framework implementation.

    IoC

    Downloader
    ef9c82c481203ada31867c43825baff4
    1169abdf350b138f8243498db8d3451e
    c7e11bec874a088a088b677aaa1175a1

    Network module
    f464b275ba90b3ba9d0a20b8e27879f5
    9320180ef6ee8fa718e1ede01f348689
    06fd6b47b1413e37b0c0baf55f885525
    625a052ddc80efaab99efef70ba8c84f

    Domains and IPs
    95.179.136.10
    apps.uzdarakchi[.]com
    forum.uzdarakchi[.]com
    forum.mediaok[.]info
    owa.obokay[.]com

    Source:: Securelist