A malware named DTrack is recently being found infecting most of the institutional and research groups in India. Pukhraj Singh, a cyber threat intelligence analyst claimed on social media that Kudankulam Nuclear Power Plant (KKNPP) was under an attack by the same malware. The malware being found in the KKNPP stirred a lot of commotion and thus began the detailed analysis of the malware, DTrack.
Impact and Speculations
After a lot of research, it was confirmed that the DTrack is a different strain of the famous ATMDTrack malware which targeted Automated Teller Machines in 2018. ATMDtrack was found in more than 18 states in India targeting financial institutions raising significant concern for security systems.
Almost 180 new malware samples were found which had similarities with the ATMDTrack. Both of these malwares also shared code similarities with the Dark Seoul Campaign where the North Korea’s infamous hacker group Lazarus were responsible.
The first step was to ensure that the obtained malware was not corrupted and the same was uploaded in VirusTotal and verified. A lot of the major anti-virus vendors (58/72) were able to identify the malware.
Figure 1 Hash
The hash: bfb39f486372a509f307cde3361795a2f9f759cbeb4cac07562dcbaebc070364
Figure 2 Virus Total hash match
To check whether the malware was packed or not, a tool named PEiD was used. The result of the tool revealed that the malware was not packed.
Figure 3 Malware not packed
All the strings that are used in the malware was extracted to see if anything interesting comes up. The output of that operation gave a lot of information. For example, values like KKNPP\administrator were hardcoded into the malware which can be seen in Figure 4.
Figure 4 Username hardcoded
Along with the username, several IPs were found hardcoded in the malware (shown in Figure 5). All this information being explicitly written in the program suggests that there is a possibility that the malware was explicitly written in order to target the powerplant in KudanKulam.
Figure 5 Hardcoded IPs
The summary of the changes in the registry values are as follows.
• Registry keys added – 2
• Registry values added – 1
• Registry values modified - 18
After spending hours and hours in analyzing the malware, there were three functions that did most of the operation. Those three functions are as follows.
1. Imports required libraries and functions
2. Enumerates local information
3. Enumerates data present in the system and stores it in a temp file.
Figure 6 The important three functions
The first function sub_40100 contains all the important dll’s and libraries that are required for setting up the harvesting. The below screenshot will have few of the imported dll’s and libraries. These libraries will be loaded first when the malware is executed.
The string manipulation functions makes it more obvious that the DTrack malware is correlated to the ATMDTrack, because its functionality is the same as ATMDTrack malware. It checks if there is a CCS_ substring at the beginning of the parameter string, cuts it out and returns a modified one. Otherwise, it uses the first byte as an XOR argument and returns a decrypted string.
Figure 7 Loading the modules for local enumeration
So, basically the malware creates it own address table with APIs in the first function.
The second function sub_403040 gets the target machines local information which will be helpful in carrying out the harvesting process. The information includes host name, environment path, startup information and so on.
Figure 8 Querying Local Information
The third function sub_4033B0 carries out the most important tasks such as creating processes, storing results and transferring the data to the destination machine. Additionally, the malware also collects the browser history. This function also has hardcoded usernames and IP’s which are explained below.
It then also creates various process such as
3. Ipconfig /all
The results of the above process are also stored in the human readable format in the local machine.
Figure 11 shows the execution of the above listed processes.
Figure 9 Gaining Information
The same can be seen in the debugger also.
Figure 10 Harvesting the Information
After harvesting all the data, the malware then creates a folder in the name of the local IP address (127.0.0.1 in this case) and started to store all the information in tmp file.
The malware also stores the result of the command line output in a file along with the created folder which can be seen in the following figure.
Figure 11 Harvested files
Figure 12 The tmp file
Each one of the files and programs that are in the victim’s machine is collected and stored in the c.tmp~ file. Initially, the malware creates a temporary folder inside a temporary folder and creates the temporary file. The information collected can be seen in Figure 13 as it is.
Although most of the content present in the file c.tmp~ is not human-readable, the names of the files and programs present in the system is printed in the file, the same can be which can be seen when opened in a notepad.
Figure 13 Contents of c.tmp~ file
The function present at dtrack.01164AD finds all the names of the files and folders and stores it in the tmp file.
Figure 14 Harvesting the files
And the function dtrack.11F1DA0 compresses the new file.
After harvesting all the files, the malware then copies the tmp~ file into another tmp file with the same name without the “~” in the extension and compresses it with the password as “dkwero38oerA^t@#’,0”. It is notable that this password was also used by the Lazarus group in the 2007 cyber-attack.
Figure 15 Encrypting the new file
Figure 16 Password for compression
The below two figures show the change in the content of the files before and after compression.
Figure 17 c.tmp~ file (Before compression)
Figure 18 c.tmp file (After compression)
Finally, after collecting all the files from the C drive, the malware also brute forces for other directories in order to enumerate even more data.
After doing all this, the malware then takes a copy of the compressed file and renames it in a specific format. Like said before, this new file is then stored in the same location as the temp folder that is inside the AppData/Local.