NGR Rootkit

아 이거 얼마전에 봤는데 ㅋㅋ 기능겁나 많네 이러면서 외국 및 SNS 다 터네 생각했는데...이게 진짜 BOT중에 BOT이더라...기능 오지게 많음; 그리고 러시아 도메인쪽 들어가고..계산기랑 그림판 띄어서 인젝션으로 돌아가는것같던데..상세는 아니니 패스ㅋㅋ 여기까지만

http://resources.infosecinstitute.com/ngr-rootkit/

-------------------------------------------------------------------------------------------------

A Chat With NGR Bot

1. Executive Summary

NGR Bot (also known as Dorkbot) was examined to be a user-mode rootkit that could be remotely controlled via Internet-Relay-Chat (IRC) protocol. It was designed with the intention to steal digital identity, perform denial of service, and manipulate the domain name resolution (see image below for the impact analysis). This article aims to provide some technical insights of this NGR Bot V1.0.3 sample (MD5 “1CA4E2F3C8C327F8D823EB0E94896538″) on the following topics: (1) Encryption & tampering detection mechanism, (2) Functionalities, (3) Hooking technique, and the (4) Architecture Set-up for communicating with this malware.

Figure 1 Impact Analysis of NGR Bot

1. Encryption and Tampering Detection Mechanism

During execution, the Data Section was decrypted to reveal malicious data to be used; and an integrity check was performed to ensure that the malware had not been tampered with. See Figure 2 for the pseudo code to decrypt Data Section and perform malware integrity check.

Figure 2 Protection Mechanism

The image base location (retrieved at 8 bytes off Process Environment Block (PEB)) of the loaded executable module was then used to locate the beginning of the executable module. It was identified that the section headers were iterated until the first four bytes (of the section name) was found to be 0x7461642E (or “tad.”). As it was DWORD comparison, “tad.” should be read as “.dat” because of the little endian. Hence, it was obvious that the malware was looking for Data Section. After the data section had been identified, the entire section content was decrypted using RC4 with a 5-byte key “haxer“. See Figure 3 for the pseudo code to decrypt Data Section.

Figure 3 Decrypt “.data” Section

After the data section was decrypted, a number of bot related data (an array of integrity check structures located within the data section) was further decrypted using RC4 with a 32-byte key “27 84 23 64 63 34 04 27 C0 27 A3 99 D6 16 58 32 BE 38 F9 EB 10 46 E1 3C E3 77 E6 1C D0 84 60 03“. The integrity check structure was defined as follows:

struct IntegrityCheckStructure

{

char* stringValue;

DWORD stringLen;

DWORD precomputedHashValue

}

The string value of the integrity check structure was hashed and compared with the pre-computed hash value. Suppose that these two values were different, the data would be considered tampered with. The malware would then proceed to launch a new thread to delete the Master Boot Record (MBR) and format the hard disk.

Figure 4 Integrity Check

In order to wipe the MBR, the malware created a file handle to access “\\.\PHYSICALDRIVE0” and overwrote its first 512 (0×200) bytes (see Figure 5). This effectively prevented the victim from booting up the operating system.

Figure 5 Wipe MBR

Similarly, to wipe the hard disk, the malware also adopted the same technique by creating a file handle to access “\\.\PHYSICALDRIVE0″. Using this handle, a while loop was used to overwrite the disk data (see Figure 6). This would be very disastrous as it could result in the loss of data.

Figure 6 Wipe Disk

1. Functionalities

Since a number of research articles have already identified its functionalities, this paper shall emphasize on some of its interesting functions: (1) Bot sorting, (2) Identity stealing, and (3) Malware spreading. Below tabularizes some of the commands that this malware could possibly process. The command is prepended using different symbol for different version e.g. “!“, “~” or “.“. For the examined sample, the prepended symbol is “.” (a full stop). For example, to display the bot version, the attack would need to send “.v” to the bot.

Idx	Command (Without prepend of symbol)	Explanation
1	v	Display version information.
2	rc	Reconnect bot.
3	rm	Uninstalls the malware from the system, but does not remove its registry entry.
4	s	Join a channel that corresponds to the country code.
5	s -n	Join #new channel for newly infected machine.
6	s -a	Join #admin or #user channel depending on rights.
7	s -v	Join #<version> channel. E.g. #1.0.3
8	us	Part #country code channel.
9	us -n	Part #new channel.
10	us -a	Part #admin or #user channel depending on rights.
11	us -v	Part from version channel.
12	stats	Display login credential stealing and malware spreading status.
13	stats -l	Display login credential stealing status.
14	stats -s	Display malware spreading status.
15	logins	Display all stolen login credentials.
16	logins –c	Clear logins credentials.
17	m on	Turn on mute.
18	m off	Turn off mute.
19	dl <http file> -r	Download and execute with ruskill feature.
20	dl <http file> -n	Download and execute file.
21	mod msn <on | off>	Turn on/off MSN spreader module.
22	msn.int <interval>	Set the number of interval for messager.
23	msn.set <message to spread>	Set the message to spread on messager.
24	http.inj <on | off>	Turn on/off HTTP spreader module.
25	http.int <interval>	Set the number of interval.
26	http.set <message to spread>	Set the message to spread on HTTP sites.
27	mdns <domain>	Block domain.
28	mdns <domain 1> <domain2>	Redirect domain 1 to domain 2.
29	vs <url> 0	Visit url with windows hidden.
30	vs <url> 1	Visit url with windows shown.
31	up <URL> <MD5 sum check>	Update malware.
32	slow <URL> <number of minutes>	Perform DDOS with slow lories.
33	udp <domain> <port> <number of seconds>	Perform DDOS with UDP flood.
34	ssyn <domain> <port> <number of seconds>	Perform DDOS with SYN flood.
35	mod usbi <on | off>	Turn on/off USB auto run spreader module.

Table 1 Sample Bot Commands

1. Bot Sorting
   

This malware has been observed to offer the attacker the versatility to sort bots using four different ways: (1) Locality, (2) Access privilege, (3) Bot version and (4) Newness. Figure 7 shows examples where bots are grouped based on locality, access privilege and bot version. This flexibility would ease of command and control over the botnet, allowing the attacker to send specialized instructions for each bot groups.

Figure 7 Command and Control Through Grouping

The locality information was found to be retrieved from “api.wipmania.com“, which was a misused benign web site. Suppose if the IP address was recognized to be from Singapore, the malware would define its locality as “SG”. This could possibly allow the attacker to send malicious messages for the bot to spread with location-specific context to increase its credibility.

When the malware attempted to connect to “api.wipmania.com”, it was observed that the user agent was spoofed with the value “Mozilla/4.0” as depicted in Figure 8. Network analyst could possibly use this as a tell tail sign to identify traces of infection.

Figure 8 Spoofed User-Agent

1. Identity Stealing
   

Stealing digital identity (username and password) was found to be one of NGR Bot’s most useful features. A majority of the targeted web sites was email messaging platforms (e.g. Gmail) and social networking sites (e.g. Facebook and Twitter). Other than those mentioned sites, it was interesting to see that the hacking forum (i.e. HackForum) and dynamic DNS sites (i.e NoIP and DynDNS) were also targeted by the attacker. The figure below reveals the list of targeted web sites for digital identity stealing. However, these malicious attempts might be irrelevant if the targeted links (or post variables) were changed by the portal owner.

Figure 9 List of Targeted Web Sites

1. Malware Spreading
   

The size of a botnet is often used to measure its worth. Hence, it is important for the malware owner to design a bot that spreads easily. In this example, the NGR bot was identified to spread itself through USB removable drives, social networking sites, and messaging clients.

To spread via removable drive, two different techniques were leveraged: (1) Creation of short-cut link (LNK) files to disguise as a legitimate user folder, and (2) Windows auto-run mechanism.

Newly inserted USB device was detected by the malware, using device notification mechanism, to prepare for USB removable drive infection. See Figure 10 for the pseudo code to register for such notification.

Figure 10 Notification Registration

1. Spread via LNK File (Social Engineering)
   

The malware was found to spread itself using LNK files with the following steps:

1. Create a hidden folder named “RECYCLER” in the root of the removable drive, and duplicate a copy of the malware in this hidden folder.
2. Set the folders at the root of the removable drive as hidden folders.
3. Create a LNK file for each hidden folder with the same name.
4. Configure the “target” property of the LNK file to execute the malware (hidden at the “RECYCLER” folder) and open its corresponding hidden folder. E.g. “folder1.lnk” would run the malware and open a folder named “folder1″.

When the “folder” was opened in another machine using the LNK file (that has an icon that looks like a folder), the malware would run in that machine. The figure below exemplifies this infection process.

Figure 11 LNK File Spreading Mechanism

1. Spread Via Auto Run
   

Apart from spreading using LNK file, NGR bot could also be configured to spread using Windows auto run mechanism (with “.mod usbi on” command).

With the auto run mechanism switched on, the malware would create an additional configuration file (autorun.inf) for each detected removable drive. By this way, it would increase the probability of spread with the aid of auto run and auto play windows feature.

The autorun.inf file created was obfuscated by two ways to evade AV detection: (1) Randomization of configuration item sequence, and (2) Insertion of garbage data between configuration items. Since garbage data would not be processed by Windows, it would not impair the parsing of autorun.inf. The figure below shows an example of the obfuscated autorun.inf file.

Figure 12 Obfuscated Autorun.inf

1. Malicious Link Spread Mechanism
   

Other than removable drive, the attacker could also spread the malware by sending out malicious links with messages through messaging client (such as pidgin.exe, msnmsgr.exe, msmsgs.exe and wlcomm.exe) and social networking sites (using features such as messaging, wall, comments and tweets). One way to craft a convincing message is to include contents with location-specific context and send it to relevant bot groups.

Below reveals a list of targeted social networking sites that were used as spreading platforms. Interestingly, one of the targeted sites was identified to be a popular Russian social networking site, i.e. Vkontakte aka VK.

Figure 13 List of Targeted Http Spreading Platform

1. Hooking Technique

Inline hooking technique was used by this malware to modify Windows API results. This allowed the malware to hide its malicious artifacts and modify the network responses. Below tabularize the API of its interest.

DLL	API
advapi32.dll	RegCreateKeyExW
	RegCreateKeyExA
urlmon.dll	URLDownloadToFileW
	URLDownloadToFileA
nspr4.dll	PR_Write
dnsapi.dll	DnsQuery_W
	DnsQuery_A
wininet.dll	InternetWriteFile
	HttpSendRequestW
	HttpSendRequestA
ws2_32.dll	getaddrinfo
	send
kernel32.dll	CreateFileW
	CreateFileA
	MoveFileW
	MoveFileA
	DeleteFileW
	DeleteFileA
	CopyFileW
	CopyFileA
ntdll.dll	NtQueryDirectoryFile
	NtEnumerateValueKey

Table 2 List of Hooked API

In order to hook an API, the following actions were performed. Firstly, the first 16 bytes of the API entry point were read to prepare a code cave (which “undo” the trampoline) to facilitate the malware to invoke the original API. Subsequently, the first few bytes (minimally 5 bytes) at the function entry point were then patched with a trampoline code which performs a jump to the malicious detour function. In another words, the detoured function would be invoked whenever the injected process calls upon the hooked API.

On the other hand, to invoke the original API, the code cave, which was only known to the malware, would be called instead. This code cave would “undo” the trampoline by running the code prior to the patched code (the first few bytes that were replaced), and jump into the API function body (at a computed offset w.r.t the function entry point) for execution of the remaining code. See Figure 14 and Figure 15 for the pictorial explanation and pseudo code respectively.

Figure 14 Inline-Hooking Explained

Figure 15 Pseudo Code to Hook One API

1. Communication Architecture Set-up

Although the supported commands are necessary, it is insufficient to set up systems to communicate with this malware due to the lack of authentication information. The bot owner was authenticated stealthily via IRC messaging headers which contained the domain name of the sender. In this sample, the malware would only respond to the IRC message from the sender with the domain named “gov.ba” (see figure below). However, it is also important to note that this domain could be easily spoofed simply by setting up a custom DNS server to be used by the IRC server. Hence, any arbitrary domain name could be selected purely for “authentication” purposes.

Figure 16 Search for “gov.ba”

The figure below shows one possible way to set up systems to communicate with the malware. In this set-up, three machines are required: (1) Server to host services, (2) Victim machine to be infected and (3) Attacker machine to control the malware.

Optionally, if you have a complete understanding of your NGR malware sample, you may want to configure the machines to have partial Internet access to witness how this malware steals the login credentials. Please note that different malware variants may have different behaviors, and misconfiguration may result in further dissemination of the malware. Do this at your own risk!!!

Alternatively, you may want to view the video to see how some of the malware commands were used to control this malware.

Figure 17 System Architecture to Communicate with NGR Bot

The nickname of the malware generated was partial-randomized based on the following convention:

<Newness>{<Country code><Platform><Admin or user>}<Random string>, where

1. <Newness> is an optional character represented with “n” if the machine is deemed newly infected. If the nickname is generated within the same hour of infection, it would be prepended with the letter “n”. E.g. If the infection was at 3.30pm and a nickname was generated at 3.59pm on the same day, the nickname of the malware would be prepended with “n”. However, if the malware regenerated the nickname at 4.00pm, its nickname would not be prepended with “n”.
2. <Country code> is the locality information retrieved from “api.wipmania.com“
3. <Platform> is the type of Windows platform which could be XP, 2K, 2K3, 2K8, VIS or W7.
4. <Admin or user> is represented by either “a” or “u” which respectively means administrative or user rights.
5. <Random string> is random 7 lowercase alphabet characters.

1. Conclusion

NGR Bot was a fairly complex user-mode rootkit that was generally designed to steal credentials from targeted websites and perform denial of service. Below are some interesting observations to conclude this analysis.

1. Stream cipher (RC4) and tamper detection mechanism were employed to protect the malware for confidentiality and integrity. It would aggressively retaliate against the crackers by formatting the hard disk when threatened. This could possibly result in the loss of important data within the machine.

• Sort mechanism was utilized to aid the attacker in performing tasks more effectively. For example, the attacker could possibly send out contextualized malicious messages to relevant groups to increase their chances of success.
• IRC messages were authenticated stealthily by checking the IRC message header to ensure that the “domain” of the sender was correct. To achieve this, the custom DNS server (used by the IRC server) has to be configured such that the IP address of the attacker is reversed-resolved to the desired domain name. Hence, this is a more secure method to authenticate as compared to using a password (which could be easily identified).
• User-agents could be a tell-tail sign to identify traces of infection. In this instance, “Mozilla/4.0″ was used by this malware as its user-agent, and this is an unusually short string to be a legitimate user-agent.
• Protocols over non-corresponding port could be also used to track anomalies over the network, e.g. port 1866 (instead of 6666 or 6667) was used for IRC communication. Minimally, desktop firewall should be used to prevent unnecessary Internet access over a non-standard port.

Incoming search terms:

• spider-man suite case
• chong rong hwa
• mexican woman beheaded
• mexico narco news
• philippines wft
• plug in 2 things
• trojan engineering logo