- Packer: absent
Compilation dates:
- 30.07.2019 04:12:08 (x64 version)
- 30.07.2019 04:12:29 (x86 version)
SHA1 hashes:
- bfa1e457afbb1f160094f65b456503b64832d249 (x64 version)
- ce3fc5b40231b5a9dd4aeeb0f0c7ef6f7779c53e (x86 version)
Description
A backdoor written in C++ and designed to run on 32- and 64-bit Microsoft Windows operating systems. The functionality of the 32-bit and 64-bit versions is identical. The backdoor is linked to the OpenSSL library, which implements AES- and RSA-based encryption, as well as key generation. It is used in targeted attacks on information systems to gain unauthorized access to data and transferring it to C&C servers. In the infected system, the sample was located in System32 as a DLL named ssdtvrs.dll. It was installed by the ssdtvrs service. This description is based on the 64-bit version.
Operating routine
It exports the service entry point ServiceMain. Once launched, the backdoor registers a function that handles control requests, creates a thread in which it performs the main functions, and then waits in a loop for the service to stop.
The main thread
First, it prepares a configuration that can be stored both in the registry of the infected computer and in the body of the backdoor. It theen decrypts the name of the registry key Software\Microsoft\Internet Explorer\Security.
The backdoor checks the presence of this key first in the HKCU section, then in the HKLM section of the registry. Then, it loads the encrypted configuration from a parameter whose name matches the name of the malicious DLL file (in this case, ssdtvrs). If the configuration is not in the registry, the backdoor uses the hardcoded one.
The configuration is encrypted with RC4 and the key is generated using the following algorithm:
The configuration is stored as a sequence of blocks.
| BYTE | BYTE | BYTE[item_len] |
| item_id | item_len | item_data |
The backdoor parses all the blocks in turn and saves the resulting configuration as a structure:
//values 0xXX - item_id
struct cfg
{
DWORD item_0x1E;
BYTE item_0x1F[32];
BYTE item_0x20[32];
BYTE item_0x21[64];
BYTE C2_0[64];
WORD C2_0_port;
BYTE C2_1[32];
WORD C2_1_port;
BYTE C2_2[32];
WORD C2_2_port;
BYTE item_0x0A[64];
WORD item_0x0A_word;
BYTE item_0x0B[32];
WORD item_0x0B_word;
BYTE item_0x0C[32];
WORD item_0x0C_word;
BYTE C2_index_0x0D;
BYTE item_0x14[32];
WORD item_0x14_word;
BYTE item_0x15[32];
BYTE item_0x16[32];
BYTE item_0x17;
BYTE item_0x28[32];
SYSTEMTIME time_1;
SYSTEMTIME time_2;
BYTE gap[16];
BYTE item_0x29[64];
BYTE module_file_name[16];
};
After preparing the configuration, BackDoor.Siggen2.3268 checks that the current system time ranges between cfg.time_1 and cfg.time_2, and waits until this condition is met.
It then prepares and sends the registration packet to the C&C server. First, it creates an object of the SBC02DEFE6 class (RTTI structures remained in the backdoor). This object contains another object that stores connection information, and also encapsulates the AZ092342345 object, which is responsible for data encryption. After creating the SBC02DEFE6 object, the backdoor attempts to hinder the debugging process by closing a deliberately incorrect handle. The exception that occurs is processed; and if the debugger is not present, the backdoor continues to operate.
After that, the cfg.C2_index_0x0D parameter is checked, according to which a specific C&C server is selected from the configuration. The following addresses are hardcoded in the configuration:
- 144.34.145.168
- snow.swingfished[.]com
The backdoor then creates a TCP socket to connect to the server, and then prepares the encryption keys. The backdoor has a hardcoded public RSA key, which is encrypted with the same algorithm that is used to encrypt the registry key that stores the configuration.
The decrypted RSA key is shown below.
-----BEGIN PUBLIC KEY-----
MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA8W8cpiAwGjiSebyCFRQq
9Mxmdj6zIGGh6R9DJ+HD7KxZTU51y20YfQbNt0n6fSYkTfysuKanHaN59jnfk1mU
buXnoQDLc7GzCRk8f7Btumd251/v7eFXVsXA1qbZHucZpcy/t946VvY+txMbCduQ
7Wg7X+m2GJoQBX11th/1IWOoJ2usqZbzhlAJqR9B4q5xLiei/CbsbP6YFwBjpEb5
9kUOpT1D27LorxqIp9YqaqLtMh4PXLu3gcewN0rRGqHsBH4X2ZRs7yWvm8zMBPFS
HsTK9rTZqWS66WlCc9WS73NAnyFjrwam98aLVmuRkGMTRUFclQp8fd//NiKFeMBX
GQIDAQAB
-----END PUBLIC KEY-----
.\>openssl rsa -noout -text -inform PEM -in pubkey.pem -pubin
Public-Key: (2048 bit)
Modulus:
00:f1:6f:1c:a6:20:30:1a:38:92:79:bc:82:15:14:
2a:f4:cc:66:76:3e:b3:20:61:a1:e9:1f:43:27:e1:
c3:ec:ac:59:4d:4e:75:cb:6d:18:7d:06:cd:b7:49:
fa:7d:26:24:4d:fc:ac:b8:a6:a7:1d:a3:79:f6:39:
df:93:59:94:6e:e5:e7:a1:00:cb:73:b1:b3:09:19:
3c:7f:b0:6d:ba:67:76:e7:5f:ef:ed:e1:57:56:c5:
c0:d6:a6:d9:1e:e7:19:a5:cc:bf:b7:de:3a:56:f6:
3e:b7:13:1b:09:db:90:ed:68:3b:5f:e9:b6:18:9a:
10:05:7d:75:b6:1f:f5:21:63:a8:27:6b:ac:a9:96:
f3:86:50:09:a9:1f:41:e2:ae:71:2e:27:a2:fc:26:
ec:6c:fe:98:17:00:63:a4:46:f9:f6:45:0e:a5:3d:
43:db:b2:e8:af:1a:88:a7:d6:2a:6a:a2:ed:32:1e:
0f:5c:bb:b7:81:c7:b0:37:4a:d1:1a:a1:ec:04:7e:
17:d9:94:6c:ef:25:af:9b:cc:cc:04:f1:52:1e:c4:
ca:f6:b4:d9:a9:64:ba:e9:69:42:73:d5:92:ef:73:
40:9f:21:63:af:06:a6:f7:c6:8b:56:6b:91:90:63:
13:45:41:5c:95:0a:7c:7d:df:ff:36:22:85:78:c0:
57:19
Exponent: 65537 (0x10001)
After that, the backdoor generates a random WORD type value, which will be used to form a packet and check the response from the server.
Then, using OpenSSL, it generates a random AES key (256 bits) and generates encryption and decryption keys.
It uses the RSA key to encrypt the generated key for further transmission to the C&C server.
The backdoor stores keys in the AZ092342345 object. Its structure can be represented as follows:
struct AZ092342345
{
vtable_AZ092342345 *vtable;
AB2952354 o_AB2952354_response_data;
AB2952354 o_AB2952354_decoded_data;
AB2952354 o_AB2952354_3;
AB2952354 o_AB2952354_4;
WORD check_word;
BYTE gap[6];
RSA **p_RSA; //RSA - the structure from OpenSSL library
AES_key AES_key;
WORD rnd_word;
DWORD dword_362;
};
struct AB2952354 //objects of the AB2952354 class are used as data containers, such as those sent and received from the server
{
vtable_AB2952354 *vtable;
BYTE *p_buffer;
BYTE *p_buffer_end;
DWORD data_size;
CRITICAL_SECTION crit_sect;
};
struct AES_key
{
char userKey[32];
char ivec[20];
int field_34;
QWORD field_38;
AES_KEY encryptKey; //AES_KEY structure from OpenSSL
AES_KEY decryptKey;
};
The packet sent during the handshake has a 0x10A + <rnd>
| WORD | DWORD | DWORD | BYTE[] |
| a test value | a random value | the random part of packet length | the encrypted AES key |
The first test value (WORD) is formed as follows.
The packet is sent to the server and a separate thread is started, which uses select to wait for a response transmitted to the socket from which the handshake packet was sent. When receiving a response, it checks the first 2 bytes of the incoming packet.
If the result is 1, the connection is reset. Otherwise, the backdoor parses the packet with the following header.
| WORD | DWORD | DWORD | DWORD |
| a test value | the packet length with a header | the length of the compressed data | the length of the decompressed data |
The data is encrypted using the AES algorithm with the key sent to the server in a handshake packet and also compressed by the zlib library.
The KCPOI982S object is initialized in the main backdoor thread and is responsible for processing commands from the C&C server.
After initializing the handshake procedure, BackDoor.Siggen2.3268 encrypts the configuration using RC4 in the main thread and stores it in the registry. Next, it prepares information about the system for subsequent transmission to the server. The packet header is equivalent to the packet header received from the server during the handshake process; the data is compressed by zlib and encrypted using the AES algorithm. The transmitted information about the infected system is represented by the structure:
struct sysinfo
{
BYTE id;
OSVERSIONINFOEXA os_version;
DWORD CPU_MHz;
DWORD sin_addr;
BYTE cfg_item_0x29_or_hostname[64];
BYTE cfg_C2_index;
DWORD tick_count_diff;
char field_F0[64];
};
id is the packet ID. In this case it is equal to 0x66.
sin_addr is the IP address of the C&C server to which the connection is established.
cfg_item_0x29_or_hostname is the value of the configuration parameter with the ID equal to 0x29. If it is not specified, the name of the infected computer is used as the value.
field_F0 takes values depending on the configuration parameter with the ID equal to 0x1E.
- cfg_item_0x1E == 0 => cfg.item_0x1F
- cfg_item_0x1E == 1 => cfg.item_0x21
- cfg_item_0x1E == 2 => "c"
- cfg_item_0x1E == 3 => "p"
After the sysinfo structure, a random sequence of 0 to 255 bytes is appended.
After sending the system information, an object of the KCPOI982S class is created to process commands from the C&C server. The main purpose of this object is to check the command ID and create another object designed to handle a specific command. The KCPOI982S object and other command handler objects are inherited from the AM1876234af3 class, which contains only an event descriptor for synchronization and a reference to the SBC02DEFE6 object for managing the connection.
KCPOI982S creates separate threads for each command and stores an array of descriptors of these threads and interrupts them in its destructor.
Processing the C&C server’s commands
The command ID is contained in the 1st byte of the packet payload sent by the server (after decryption and unpacking).
| id | Name of the handler object | Description |
|---|---|---|
| 0x10 | BCJI09RUC | To send a list of processes The following structure is formed for each process:
|
| 0x15 | AS01243895 | To create a command shell from cmd.exe. The backdoor runs cmd.exe with StdIn,StdOut,StdErr redirection to pipes. It then sends a packet with the 0x76 byte in the payload. After that, it attempts to read the result from the pipe and send it to the server in a loop. |
| 0x01 | AF434faf845 | To send information about all disks (iterates through the letters, except A and B). The following structure is formed for each disk:
|
| 0x20 | AC92784f908234 | To send the configuration to the C&C server. The packet’s payload is represented as the following structure:
|
| 0x00 | - | To reset the connection |
Artifacts
BackDoor.Siggen2.3268 contains numerous debugging strings and the links are missing.
.rdata:00000001800D4DF8 00000008 C started
.rdata:00000001800D4E00 0000001B C get test connect style: %d
.rdata:00000001800D4E20 00000013 C Read config error!
.rdata:00000001800D4E38 00000024 C begin connecting, connect style: %d
.rdata:00000001800D4E60 00000015 C - main connect fail!
.rdata:00000001800D4E78 00000032 C !MainThread, sendLoginInfo error, reconnect again
.rdata:00000001800D4EB0 0000000F C - Not Actived!
.rdata:00000001800D4EC0 00000012 C ++ Server Actived
.rdata:00000001800D4ED8 00000027 C !send Heartbeat error, repeat connect.
.rdata:00000001800D4F00 0000000F C !in Debug,out\n
.rdata:00000001800D4F10 0000001B C TestConnectModeI %d Error!
.rdata:00000001800D4F30 00000020 C Test Connect BackDomain Succeed
.rdata:00000001800D4F50 00000016 C begin iBackStyle = %d
.rdata:00000001800D4F68 0000000F C con test again
.rdata:00000001800D4F78 0000001E C Succeed Test, iBackStyle = %d
.rdata:00000001800D4F98 0000001E C Test Failure, Sleep 10-30m!!!
.rdata:00000001800D4FB8 00000035 C Test toatl Failure, Sleep 20_50m!!!, totalcount = %d
.rdata:00000001800D5088 00000016 C configure data key:%s
.rdata:00000001800D50A0 0000000F C !read1 reg, %d
.rdata:00000001800D50B0 0000000F C !read2 reg, %d
.rdata:00000001800D50C0 00000010 C !write1 reg, %d
.rdata:00000001800D50D0 00000010 C !write2 reg, %d
.rdata:00000001800D50E0 00000010 C !write3 reg, %d
.rdata:00000001800D50F0 00000010 C !write4 reg, %d
.rdata:00000001800D5100 00000018 C Public Encrypt failed\n
.rdata:00000001800D5118 00000017 C !UnzipPacket: not flag
.rdata:00000001800D5130 00000016 C !UnzipPacket: Decrypt
.rdata:00000001800D5178 00000015 C @@ TCP Construct end
.rdata:00000001800D5190 0000001C C @@<- TCP begin DisConstruct
.rdata:00000001800D51B0 00000024 C @@-- TCP Disconnect in DisConstruct
.rdata:00000001800D51D8 0000001A C DisConstruct: closesocket
.rdata:00000001800D51F8 0000001C C Discontruct: close m_hEvent
.rdata:00000001800D5218 0000001A C @@-> TCP End DisConstruct
.rdata:00000001800D5238 00000027 C TCPConnecting begin, Host:%s, Port: %d
.rdata:00000001800D5260 00000018 C !Connect, lpszHost = %s
.rdata:00000001800D5278 00000015 C Create Socket error!
.rdata:00000001800D5290 00000021 C !TCP gethostbyname(),lpszHost=%s
.rdata:00000001800D52B8 00000013 C TCP connect error!
.rdata:00000001800D52D0 00000014 C new key buf error!\n
.rdata:00000001800D52E8 00000012 C const key failed\n
.rdata:00000001800D5300 00000013 C send askey failed\n
.rdata:00000001800D5318 00000017 C TCPConnecting succeed!
.rdata:00000001800D5330 00000018 C <-- TCP disconnect into
.rdata:00000001800D5348 00000019 C <-- TCP disconnect begin
.rdata:00000001800D5368 00000017 C --> TCP disconnect end
.rdata:00000001800D5380 00000018 C <-- TCP disconnect exit
.rdata:00000001800D5398 00000019 C !Send error, Disonnect()
.rdata:00000001800D53B8 0000001A C TCP send1 to SendRetry:%d
.rdata:00000001800D53D8 0000001A C TCP send2 to SendRetry:%d
.rdata:00000001800D53F8 00000017 C Create TCP WorkThread!
.rdata:00000001800D5410 0000001C C begin into WorkThread while
.rdata:00000001800D5430 00000028 C !WorkThread, select error, Disconnect()
.rdata:00000001800D5458 00000026 C !WorkThread, recv error, Disconnect()
.rdata:00000001800D5480 00000015 C Exit TCP WorkThread!
.rdata:00000001800D5498 00000024 C !OnRead, dwIoSize = 0, Disconnect()
.rdata:00000001800D54C0 00000025 C !recv only packet flag, Disconnect()
.rdata:00000001800D54E8 00000008 C bad buf
.rdata:00000001800D54F0 00000024 C !UnzipPacket failure!, Disconnect()
.rdata:00000001800D5528 0000000E C JnteroetPpenA
