The page may not load correctly.
An analysis of the technologies used by cybercriminals allows us to draw conclusions about the virus industry’s possible vectors of development and more effectively confront future threats. You, too, can learn what actions various malicious programs take in infected systems and how to withstand them.
A file infector designed to download other modules via the P2P protocol. A payload is implemented as an executable file compressed with UPX that, when launched, initializes data, including the UDP port
GetComputerNameA((LPSTR)&buf[1], &size);
if ( lstrlenA((LPCSTR)&buf[1]) > 2 )
{
B1 = buf[1];
Bn = buf[lstrlenA((LPCSTR)&buf[1])];
LOWORD(PORT) = Bn * B1 + 1060;
}
and the TCP port.
TCP_PORT=PORT+19
Opens a shared memory created by the purity_control_4428 shellcode that contains valid configuration data and pairs of IP addresses and ports (nods) to connect to a P2P network. Then the infector opens the shared hh8geqpHJTkdns6 memory where it saves a list of nodes during the module's operation. The nodes are saved to the Windows system registry.
HKEY_CURRENT_USER\Software\<[a-z]*>\%c%d_%d
%c - PC_SEED
%d—parameter number (addr,port,id_peer,count_answer)
%d—node index
Configuration data of large amount is saved to
%SYSTEM32%\<[a-z]*>\[a-z]*.log
or
%TEMP%\<[a-z]*>\[a-z]*.log
Moreover, the file infector also saves the URL list to
HKEY_CURRENT_USER\Software\PC_SEED*PC_SEED\%d\
where %d indicates a parameter number (url list, signature, data size, and so on).
Then Win32.Sector initializes a public key as follows:
E=
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 01 00 01
N=
BB D2 96 8E ED 0B 93 8A 82 E4 E9 BC C3 C5 32 72
4C 08 AA 56 9F 2D 64 0F 1B 86 68 0E 2B 62 E9 C6
35 6D 75 B6 32 2D 4F A8 B8 D9 2A 44 8B F0 7F E0
D9 8E BE 66 9D A6 7A 9A 6D E1 45 F1 D3 48 01 0D
39 2E 9D 2A 45 FB 0B FB 1D 96 F3 B7 4F 55 E5 E1
16 5B F7 A1 CC 7C 87 C0 C8 9C EF 4E CE 29 58 E2
99 BD 8A 7A 55 BE B4 1C D9 79 52 25 D8 28 86 7B
81 39 98 5F 2C 6F 14 BB A5 6B CE 44 E5 91 93 38
8B 9A C1 74 46 84 E1 26 EC 04 94 96 75 09 E3 B5
88 D6 08 F0 4A B7 84 D3 13 2F 00 CC D5 2A 8C 17
07 09 DE 6F B0 D3 D6 2B C6 A6 9D 38 18 8C 74 9D
86 16 D5 48 6E 97 32 DB E1 4E F8 04 A6 00 7C 16
2E 70 1C 23 37 DD 5A 52 76 62 70 D4 86 66 6E DF
0C E9 A1 68 F9 5E E8 DD 09 0C 02 7D 35 D0 54 E7
00 C0 14 9F CE 4A 9F F3 99 50 1A 0B CD CC FF 05
B9 04 12 E2 11 76 2F FF A4 6E 64 18 E0 D0 7B 3B
After that, the file infector initiates several threads that serve the following purposes:
The malicious program injects its code into all running processes using VirtualAllocEx/WriteProcessMemory/CreateRemoteThread.
The file infector tries to install its driver as follows:
SYSTEM32\drivers\[a-z]*.sys
Using this driver or by calling the TerminateProcess function, it tries to kill the following processes (if they are running):
Moreover, it attempts to delete the following system services:
The driver creates the following device:
\Device\amsint32
\DosDevices\amsint32
Then it decrypts website address list as follows:
After that, the file infector sets IRP handlers to communicate with the driver in user mode. It makes execution of the following commands possible:
If DWORD=666, buffer contains KeServiceDescriptorTable addresses found by the bot in usermode (table is required to search for NtTerminateProcess).
Sets the driver handler function at \Device\IPFILTERDRIVER.
Thus,
IoBuildDeviceIoControlRequest(0x128058u, DeviceObject, &pfunc, 4u, 0, 0, 0, 0, &IoStatusBlock);
As a result, handler monitors all incoming connections, and, if the corresponding option is enabled, connections to websites from the specified list are blocked.
The virus infects hard drives by planting the autorun.inf file as follows:
;xmMgM
[AutoRun]
;foXjogjgAirFrJaIWvWCFYOjVdeptddJqu
;qxltVAjtFsQy
SHell\Open\defAult=1
OPeN =eromp.exe
;
ShelL\open\cOmmAND =eromp.exe
;elrktM
ShEll\ExploRe\ComMAnD=eromp.exe
;rtLT xwoG
shElL\autOplAy\ComManD =eromp.exe
;pbmyU igvQEdlfgtjgTs
[AutoRun]
;kWxFMtJjds ntDcm JsyqrhIKdiyp
;flpkohOJMJ
shEll\oPen\dEfauLt=1
;
SHeLl\opeN\CoMMaNd=xsvsf.pif
;
oPEn =xsvsf.pif
SHelL\EXploRe\COmmand = xsvsf.pif
;vWgFu HkdyJEhwpgeiEdbvSCyiYmisLkvq
shell\AuToplaY\coMMaND=xsvsf.pif
It infects all files in the following system registry branches:
Then it infects all files detected in the following network folders:
Once the computer is infected, the virus connects to P2P resources at specified addresses, downloads executable files, checks the digital signature and saves it to the following file:
%SYSTEM32%\<[a-z]*>\[a-z]*.log or %TEMP%\<[a-z]*>\[a-z]*.log
Every time it is launched, the file infector extracts modules from the configuration file and runs them from the %temp% folder.
The modules are as follows:
The protocol consists of a UDP server responsible for node exchange (P2P network's “address–port” lists) and a TCP server that is used to download configuration data. The node list structure looks as follows:
struct tnode
{
DWORD addr; //ip
WORD port; //udp port
WORD w1;
DWORD id_peer; //bot ID; if the bot has a public IP, then ID is larger than 16000000
DWORD count_answer; //number of successful requests
DWORD time; //GetTickCount time
};
Every UDP packet has a header that can look as follows:
struct P2P_HEAD
{
WORD crc16; //checksum of the crc16 message
WORD len; //message length
};
UDP packets are encrypted with RC4 (the P2P_HEAD value is taken as a key).
To exchange configuration data, the file infector starts sending consecutive requests.
OP_03—request for configuration ID.
The packet has the following structure:
struct OP_03
{
BYTE ver; //protocol version 4
DWORD id; //configuration ID
BYTE op; //0x03 command
BYTE b4Fh; //0x4F
BYTE b4Bh; //0x4B
DWORD size_cfg; //0xFEFEFEFE or packet size
WORD w1; // 0x0
};
As a reply, the file infector receives the same packet with node configuration ID. If the received ID is smaller than the current one, the following request for configuration is sent:
struct OP_23{
BYTE ver; //4
DWORD id; //id cfg
BYTE op; //0x23
BYTE b4Fh; //0x4F
BYTE b4Bh; //0x4B
BYTE b1; //-2
BYTE b2; //-2
BYTE b3; //-2
BYTE b4; //-2
DWORD size_cfg; //URL size
};
In reply, the malicious program gets the packet that looks as follows:
struct tcfg_head
{
DWORD size; //configuration size
DWORD crc32; //crc32
};
struct tcfg_sign
{
BYTE sign[0x100]; //digital signature
};
struct tcfg_info
{
DWORD id; //configuration ID
BYTE b1;
BYTE b2;
WORD w1;
DWORD size_cfg; //configuration size
};
struct tcfg{
tcfg_head head;
tcfg_sign sign;
tcfg_info info;
WORD count; //number of URLs in a packet
BYTE urls[754];//addresses
};
The UDP protocol is used to transfer only configuration packets of small size. If the size exceeds 0x400, the malicious program sends the TCP sever a request to download configuration data.
If configuration IPs are the same, but size values are different, configuration data is either downloaded from a P2P network node or is uploaded to the server via the TCP protocol.
To check for NAT, the file infector uses a request with the following structure:
struct OP_FLAG
{
BYTE ver;// 4
DWORD id; //id cfg
BYTE op; //0x1
DWORD status; //current NAT status
WORD port; //own UDP port
};
Once the server receives such a packet, it attempts to send the source a request via a new socket at a new local port address. Then it sends the OP_03 packet. If a reply is received, the sever considers NAT to be unavailable and assigns the bot with an ID larger than 16000000. Then the server adds this bot to the list. An outgoing packet has the following structure:
struct OP_01
{
BYTE ver; //4
DWORD id; //id cfg
BYTE op; //0x01
DWORD id_peer; //ID assigned to the bot
};
To request a new IP address of a P2P network node, the bot sends the OP_FLAG command (op=0x02). In reply, the server sends the following packet:
struct OP_02
{
BYTE ver; //4
DWORD id; //id cfg
BYTE op; //0x02
DWORD addr; //random IP from the node list
WORD port; //port from the node list
DWORD id_peer; //node ID from the node list
};
The TCP protocol is used to exchange large data packets. To get configuration data from the server, the following request is used:
struct P2P_CFG_REQ{
DWORD rnd1;
DWORD rnd2;
};
The reply has the tcfg structure described above. It is encrypted using RC4 with the purity_control_%x key, where %x indicates head.size.
Since the bot cannot modify the payload, it is compressed with UPX. At the same time, configuration data and the list of P2P nodes need to be updated in every infected file. For this purpose, a shellcode is used. It creates and initializes a shared memory with address list and configuration data and uploads the file infector's payload into the memory.
According to statistics, every fifth program for Android contains a vulnerability (or, in other words, a "loophole") that lets cybercriminals successfully introduce Trojans onto mobile devices and manipulate them into doing whatever actions they need them to.
Dr.Web Security Auditor for Android diagnoses and analyses a mobile device’s security and offers solutions to address security problems and vulnerabilities.