Figure 1 Impact Analysis of NGR Bot
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 (0x200) 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
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. Table 1 Sample Bot Commands (Without prepend of symbol)
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
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
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
Spread via LNK File (Social Engineering)
The malware was found to spread itself using LNK files with the following steps:
Create a hidden folder named “RECYCLER” in the root of the removable drive, and duplicate a copy of the malware in this hidden folder. Set the folders at the root of the removable drive as hidden folders. Create a LNK file for each hidden folder with the same name. 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
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
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
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. 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
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:
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.
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.
