This blog was written by Inhee Han.
The McAfee Mobile Research team recently examined a new threat, Android malware that contains a backdoor file in the executable and linkable format (ELF). The ELF file is similar to several executables that have been reported to belong to the Lazarus cybercrime group. (For more on Lazarus, read this post from our Advanced Threat Research Team.)
The malware poses as a legitimate APK, available from Google Play, for reading the Bible in Korean. The legit app has been installed more than 1,300 times. The malware has never appeared on Google Play, and we do not know how the repackaged APK is spread in the wild.
Figure 1: Description of the legitimate app on Google Play.
Figure 2: An overview of the malware’s operation.
Comparing Certificates
The repackaged APK has been signed by a different certificate from the legitimate APK. We can see the differences in the following two screen captures:
Figure 3: The certificate of the malicious, repackaged APK.
Figure 4: The certificate of the legitimate APK.
Once the malicious APK installs its code, it attempts to execute the backdoor ELF from “assets/while.” If the ELF successfully executes, it turns the device into a bot.
Figure 5. The main function for executing the backdoor ELF.
Analyzing the Backdoor
Once the backdoor ELF starts, it turns into a zombie process to protect itself. It remains as a zombie even if the parent process terminates, as long as the “dex” execute() method has been implemented successfully.
Figure 6. The malware turns itself into a zombie process.
The malware contains a list of IP addresses of control servers. The list is encoded and written to the file /data/system/dnscd.db.
The preceding table lists information for each of the IP addresses. None of these is available now.
Figure 7. The flow of writing the encoded control server IPs to a file.
The IP address array is encoded by a simple routine when it is loaded into memory from the read-only data section; that encoded data is written to the file /data/system/dnscd.db. The decoded file is then loaded into memory to select an IP address to connect to.
One of control servers is selected randomly immediately before the backdoor process attempts to connect to its address. The attempt is performed repeatedly to successfully connect with one of the control servers.
Figure 8. The malware creates a socket and connects to a randomly selected control server.
Once connected with a control server, the malware begins to fill the buffer using a callback beacon. Figure 9 shows a part of the message-generating code. Several fields of the packet are hardcoded, particularly the bytes at offsets 0, 4, and 5. After we realized that the message only pretended to use the SSL handshake protocol, we understood the meaning of the hardcoded bytes. The byte at offset 0 is the handshake type; offsets 4 and 5 are the SSL version of the handshake layer, a part of transport layer security.
Figure 9. A part of the function for generating a callback beacon.
Figure 10. Transferring data to be used as the callback beacon to the control server.
After the message is generated, it sends the following packet (Figure 11) to the control server as a callback beacon. There is a randomly selected well-known domain in the packet where the server name indicator field is placed as a field of extension data. We suspect this is an evasion technique to avoid detection by security solutions looking for suspicious behaviors.
Figure 11. A captured packet from the callback beacon.
Figure 12. The list of legitimate (well-known) domains in the binary.
After sending the callback beacon, the malware assigns global variables that contain device information which is transferred to the control server once it receives the command code 0x5249. Figure 13 shows the jump table for implementing commands and its pseudo code.
Figure 13. The jump table for implementing commands from the control server and the structure for receiving data.
The functions are described in the following table. Command code and arguments arrive as structured data from the control server, as shown in Figure 13. The command code and arguments are assigned, respectively, to the CMD and DATA member variables of the received data structure.
After performing commands received from the control server, the malware returns the results to the control server using the codes in Figures 14 and 15. Before transferring the results, the return code and data are stored in a structure described in the following pseudo code.
Figures 14 and 15. The codes and data structure returned to the control server.
Similarities to Lazarus Malware
In Figure 16, the function on the left is from the backdoor ELF we have analyzed. On the right, we see procedures found in several executables used by the Lazarus Group in various attacks.
Figure 16. Similar functions to the executable used in the Sony Pictures attack.
Both functions look very similar. And the hexadecimal seeds for generating a key for encryption and decryption are the same. Both functions are also used to generate a message encryption and decryption key between the victim and control server. Figure 17 shows the functions of both the backdoor ELF and an executable recently used by the Lazarus Group. The function connects to the control server, and generates a disguised SSL ClientHello packet. Then the generated packet is sent to the control server as callback beacon.
Figure 17. The functions to establish a connection to the control server (ELF on the left).
The function in Figure 18 generates a disguised ClientHello packet to use as a callback beacon.
Figure 18. Generating the disguised ClientHello packet (ELF on the left).
Both backdoors use same protocol, as we confirmed when analyzing the function for receiving a message from the control server. Figure 19 shows the protocol for transferring a message between the backdoor and the control server.
Figure 19. The receive message function included in the checking protocol (ELF on the left).
To transfer a message from the source, the malware first sends a five-byte message to the destination. The message contains information on the size of the next packet, a hardcoded value, and the type of message. The hardcoded value is 0x0301 and the type of message can be between 0x14–0x17. The message type can also be used to check the validation of the received packet. The following is pseudo code from the receive function:
Figure 20. The five-byte packet sent before the source sends its primary message.
Figure 21. Pseudo code from the receive message function.
Conclusion
The security industry keeps an eye on the Lazarus Group, and McAfee Mobile Security researchers actively monitor for mobile threats by Lazarus and other actors. We compared our findings with the threat intelligence research of our Advanced Threat Research team, which studies several groups and their techniques. Due to the reuse of recent campaign infrastructure, code similarities, and functions such as the fake transport layer security, these tactics match many we have observed from the Lazarus Group.
We do not know if this is Lazarus’ first activity on a mobile platform. But based on the code similarities we can say it with high confidence that the Lazarus Group is now operating in the mobile world.
McAfee Mobile Security detects this malware as “Android/Backdoor.” Always keep your mobile security application updated to the latest version. And never install applications from unverified sources. This habit will reduce the risk of infection by malware.
Indicators of Compromise:
Hashes
12cc14bbc421275c3c6145bfa186dff
24f61120946ddac5e1d15cd64c48b7e6
8b98bdf2c6a299e1fed217889af54845
9ce9a0b3876aacbf0e8023c97fd0a21d
Domains
mail[.]wavenet.com.ar
vmware-probe[.]zol.co.zw
wtps[.]org
IP addresses
110[.]45.145.103
114[.]215.130.173
119[.]29.11.203
124[.]248.228.30
139[.]196.55.146
14[.]139.200.107
175[.]100.189.174
181[.]119.19.100
197[.]211.212.31
199[.]180.148.134
217[.]117.4.110
61[.]106.2.96