BackDoor.Skeye.1

• Packer: absent
• Compilation date: 01.04.2019 15:00:46
• SHA1 hash: a259db436aa8883cc99af1d59f05f4b1d97c178b

Description

A backdoor written in C and designed to operate in the 64-bit versions of Microsoft Windows operating systems. It is used for targeted attacks on information systems, collecting information about the infected devices and remotely controlling them by launching cmd.exe and redirecting the I/O to the attacker's C&C server. The malicious module’s original name is sk.exe. The backdoor’s code has similarities with the code of Mikroceen and Logtu malware.

Operating routine

It has one exported function DllEntry of the following structure:

When running the sample as an EXE file, only the malmain function is run.

The backdoor writes the event log to the %TEMP%\\wcrypt32.dll file containing the date and time of the message; but instead of the readable message, the program logs its code. The table below shows the message codes decryption.

The backdoor initializes the list of commands it can execute upon operation.

This is followed by the initial check for any debugging processes—the backdoor checks the BeingDebugged flag in the PEB (Process Environment Block). If there is a debugging process, the backdoor closes.

Next, it creates a test0 or test0_cu mutex in case it is not run from NT AUTHORITY/SYSTEM. If the specified mutex already exists, the backdoor terminates.

It then reads the bot ID from the file %TEMP%\\test0.dat. An 8-byte encryption key is initialized based on the bot ID.

Next, BackDoor.Skeye.1 begins operation with the C&C server. Before sending requests, it again checks whether the sample debugging process is present. This time, using the NtQueryInformationProcess function it checks ProcessDebugPort, ProcessDebugObjectHandle and ProcessDebugFlags. If the backdoor spots the debugging process, it closes.

The requests use the User-Agent string:

Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 6.1; Trident/4.0; SLCC2; .NET CLR 2.0.50727; .NET CLR 3.5.30729; .NET CLR 3.0.30729; Media Center PC 6.0; InfoPath.2)

When connection to the C&C server, the backdoor first sends a GET request to check the availability of the server; the sample contains two sets (server-port) of the C&C addresses. hxxps://atob.kommesantor.com/?t=%d&&s=%d&&p=%s&&k=%d, where t parameter is the bot ID, s is session number, p is dut6@bV0 string, and k is the result of the GetTickCount() function.

If the response is code 200, it means the server connection has been successfully established, and the backdoor requests an execution command. If the response is code 403, the program tries to repeat the request, while it enters www.mail[.]ru in the Host HTTP header instead of entering the C&C address. If the code 200 still cannot be obtained, the backdoor then checks the second C&C server. In case of repeated failure, it waits for a few seconds and then makes another attempt.

A GET request with the address hxxps://atob.kommesantor.com/?e=%d&&t=%d&&k=%d is used to request the command, where e is null, t is the bot ID, and k is the result of the GetTickCount() function.

If the response is the code 200, the cookie of that response contains the ID of the command to be executed, and the response data is encrypted with an XOR operation with an 8-byte key based on the bot ID.

A POST request with the address hxxps://atob.kommesantor.com/?e=%d&&t=%d&&k=%d is used to send back the results, where e is the command ID, t is the bot ID, and k is the result of the GetTickCount() function; the result of the request is transmitted as data encrypted by an XOR operation with an 8-byte key based on the bot ID.

Commands list

During the investigation of the related targeted attack, the following servers were found:

atob[.]kommesantor[.]com
term[.]internnetionfax[.]com
    
rps[.]news-click[.]net

All three domains are resolved to 103.97.124[.]193.

Other modifications of the Skeye backdoor

Another uncovered backdoor sample (0b33a10c0b286c6ffa1d45b261d8a338) has been added to Dr.Web database as BackDoor.Skeye.2.

The key differences of this modification are:

• Exported functions are absent.
• The sample runs as a service, installing or deleting itself, depending on the arguments it is running with (install, uninstall, without arguments).

The malmain function is also run from ServiceMain;

• The bot ID is read from the file %TEMP%\Date, but the encryption key is generated in the same manner.
• The configuration (mutex name, server address, port, proxy) is encrypted with the XOR operation with the key 0xB7. www2.morgoclass[.]com is the C&C address, the port is 443;

  

• The protocol of communication with the C&C server is binary. The connection is made via a TCP socket. After connecting to the server, the backdoor sends an 8-byte packet: the first 4 bytes are the bot ID, the second 4 bytes are zeros. Receiving a response from the server is performed in 2 stages: first, a packet with the length of the data (header) is received, then the data itself is received and decrypted. The header structure is the followng:

  struct packet_header
        {
            BYTE marker;
            DWORD cmd_id;
            DWORD size;
        }
        

With that, the marker field must be equal to 0xFF. The data is sent to the server by a single call to send with the same header.

• This sample does not include all the commands described in the first sample (a259db436aa8883cc99af1d59f05f4b1d97c178b). Commands 80, 81, 85, and 86 are absent
• There are differences in the event log message codes. Codes 10, 65-68, and 70-72 are absent.

The event log message codes are shown in the table.

It is worth noting that the two samples use different sets of codes to log the connection to the C&C server. In the first case, these are the codes 70-72, while the connection to the server is made via HTTP. In the second case, these are the codes 24-26, and the connection is made via a socket.