Pierluigi Paganini
February 19, 2019
Muncy is the name dubbed by SI-LAB that analyzed this threat. Now, the malware is targeting user’s worldwide and has been spread via phishing campaigns.
Malicious actors are using SMTP servers leveraging bad server’s configuration. Email spoofing technique is used to impersonate the giant DHL; a popular distribution firm; sending a shipment notification to the user’s email inbox.
The email used to carry out this campaign is: <support@dhl[.]com>.
This technique is not novel and many web servers available online don’t have the right security configurations to prevent attacks this line.
Users who access the email need to extract the malicious attachment. The malware is an .exe file that scans users’ computers and collects information, including FTP data.
The process flow diagram below shown how the malware works.
The malware is packed, and after the initial execution, a new process is created and executed (the unpacked malware). That process executes a mass scan in user’s C:\ drive obtaining sensitive information that is sent to a domain managed by crooks and available at sameerd[.]net.
No persistence was identified in the user’s devices during malware infection life-cycle.
Users who receive emails this nature should be aware if they are part of a social engineering campaign. If you do not expect any orders, then ignores that.
SI-LAB has already notified DHL firm but no public comments were observed at this moment.
For more details, see below.
———————————————————————————————————————————————————
Threat name: DHL Original Receipt_PDF.exe
Original name: Muncy.exe
MD5: 4df6d097671e0f12b74e8db080b66519
SHA-1: 568035f0e96b9e065049491004ccee5a4cd180c7
Imphash: 8a6e3bc29ee49f829483143f1dc39442
———————————————————————————————————————————————————
During the last week, Segurança Informática (SI) Lab identified infection attempts aimed to install Muncy malware directed to the DHL shipment notifications. The malicious email messages contained a particular trojan spreading via phishing campaigns tailored to lure victims.
Leveraging bad SMTP server’s configuration, malicious actors are sending phishing emails trying to impersonate DHL (see Figure 1).
Figure 1: Email body and malicious attachment.
A preliminary analysis of the malicious email shows a domain (duntonintlsrc.com) used to say EHL to the target SMTP server. SMTP servers with bad configurations are a majestic vector to spread malicious campaigns.
Figure 2: Email spoofing and DHL impersonation.
In detail, the first wave observed was on February 12th, 2019. This is an important indicator to remember later.
The email body is not a plain-text message, instead, a PNG image was embedded on it — we can observe the email has attached from the local path: C:/Users/Administrator/Desktop/DHL.png.
Figure 3: Email message body.
Muncy malware is one of the most active trojans now. SI-LAB dubbed it Muncy due to its original name hardcoded in the executable file. Step-by-step of Muncy malware is presented in Figure 4.
Figure 4: How Muncy malware works.
The malware is packed, and during the malware analysis, we cannot unpack it. After the first execution, it is unpacked to the PE File .data section that was empty at start. The threat executes a scan to all C:\ drive trying to find sensitive data and files (mainly FTP files) and that will be send to a final endpoint managed by crooks (sameerd.net).
At first glance, it appears as a PDF file — an old technique to deceive the most careless users.
Figure 5: Muncy is masked with a PDF icon.
Muncy is the name attributed this threat due to its original name. Note that English is the principal language detected and used by crooks to develop this malware.
Other interesting strings are CompanyName: Somers2 and ProductName: HARPALUS8.
Well, in fact, very interesting. Let’s investigate.
Somers2: nothing interesting.
Harpalus: Harpalus luteicornis is a species of ground beetle native to the Palearctic. Nice finding
Let’s look at the next figure where the information discussed above can be found.
Figure 6: Muncy origin.
The FileVersion is also interesting (1.01.0005) — this threat seems to be something still in development.
Let’s look closer. The file has high entropy, and two offsets (0x71000 and 0x7F400) with rising entropy can be noted.
Figure 7: Muncy entropy offsets.
It’s interesting to observe the offsets where entropy increases. In order to confirm our findings, let’s look at the entropy curve depicted in Figure 8.
Figure 8: File entropy curve.
In detail, it’s important to highlight two interesting points:
Furthermore, the digital certificate presents within this executable also contribute to the high entropy in the .text section. We can easily observe that in the file overlay offsets presented below.
Figure 9: Executable overlay, digital certificate creation date, name, and organization.
In addition, we need to observe the following three important points:
Note that the phishing campaign was noticed on February 12th, and the certificate associated with malware was created on 11th, the day before.
The PE file has three sections: .text, .data and .rsrc; and two of them are suspicious. Why? Pay attention.
The .text section is packed and has high entropy. It’s common to find no data correlation with high entropy. An encrypted snippet of code, for instance, has high entropy associated.
The second note: .data section; it has a size equal to zero (it’s empty), and a virtual size associated (0xbb4). The malware will be injected here after unpacking. It’s a runtime packer!
Figure 10: Malware entropy and suspicious sections.
The next image confirms that a great part of the binary data is packed (see the entropy – middle).
Figure 11: Binary data overview.
Muncy malware was developed in VisualBasic 6.0 and is compiled in p-code as shown below.
Figure 12: Compiler used to develop Muncy malware.
Performing analysis on a Visual Basic (VB) script is hard. Unfortunately when Visual Basic is compiled to a Windows Portable Executable (PE) file it can become a nightmare for many malware analysts and reverse engineers.
Visual Basic binaries have a reputation for making an analysts job difficult due to the many aspects of its compilation that differ from standard C/C binaries. To analyze a VB PE binary it helps to be familiar with the VB scripting syntax and semantics since their constructs will appear throughout the binary’s disassembly. VB binaries have their own API interpreted by Microsoft’s VB virtual machine (VB 6.0 uses msvbvm60.dll). Many of the APIs are wrappers for more commonly used Win32 APIs leveraged from other system DLLs.
Reverse engineering VB binaries will often involve reverse engineering VB internals for various VB APIs, a task dreaded by many.
VB5/6 can be compiled to either native or pcode. Even when native the program flow is not linear from the entry point but is based on form, module and class structures passed into the vb runtime at startup.
In detail, the malware imports the MSVBM60.DLL (Microsoft Visual Basic Machine, like JVM – Java Virtual Machine). Another important DLL present in IAT is shell.dll, that will be used to perform several actions such as open, create and delete files, open a Windows powershell, etc.
Figure 13: Malware IAT.
Many imported functions from MSVBM60.DLL are now classified as malicious by AV engines (see figure 14).
Figure 14: Malware IAT blacklisted.
But keep in mind that a benign software also can use that blacklisted functions in the right way. In this sense, the information extracted from Figure 14 would be false positive.
By analyzing the malware, it’s possible to disassemble the malware p-code. That seems the right way to dissecting this threat.
We can view that four sub-routines are declared in API declarations, namely the inconforming5, farfel3 and ondascop9 that are imported from shell32.dll, and, finally, the sub-routine waterbed that is imported from the kernel32 DLL.
Figure 15: API declarations in source-code.
In detail, the malware has a form with some objects declared (passagang). Nonetheless, all the disassembled code did not add much detail to our analysis as the source-code from the sub-routines presented in Figure 15 and discussed above are not loaded (API sub-routines). That happens because the malware is packed and is evading reverse engineering.
Figure 16: Malware decompiling.
Of course, in case of a program compiled to p-code (this case), the decompilation success rate will be lower, and no additional input is noted.
The code is very hard, and it is packed.
Figure 17: Packed malware.
However, some strings hardcoded in the malware were found — they are used to compare the result of one of the packed APIs from Figure 15. We can not get more detail about that, but we suspect that they are used to perform brute-force attacks on FTP services.
Figure 18: Strings hardcoded in the malware.
Increasing suspicions, we perform a memory dump during the malware execution. As shown, other strings were found — probably, are hidden at the start and hardcoded in the packed malware.
Figure 19: Strings extracted from memory and malicious endpoint detected.
Here, an interesting point needs to be analyzed. The endpoint managed by crooks were found (http://sameerd[.]net/grace/panelnew/gate.php). Additional analysis on it is delivered later.
An important aspect of VB6 is related to the fact that VB6 internals lack any sort of official documentation. The inner workings of the VB6 virtual machine and the functionality of its exported functions are literally a mystery to anyone who has not taken an in-depth look atmsvbvm60.dll.
Loading the malware into the debugger, we can see the following.
Figure 19: Muncy initial entry-point.
We are sitting at the very first instruction for the executable which is pushing an address to the stack (arg1) before calling MSVBVM60.ThunRTMain.
Looking up the ThunRTMain function, we find that it takes a single argument (The address 0x4763BC being pushed to the stack) and that argument is a pointer to a VBHeader Structure that tells the application how to start. This VBHeader Structure appears in memory, like so (Figure 20):
Figure 20: Muncy VBHeader Structure.
Of these values, the address assigned to aSubMain (0x00000000) is the most important as it is the address for the main function that will be called once the executable’s environment has been set up.
Nonetheless, as shown in Figure 20 below, that address is empty. If the aSubMain value is 0000 0000 then it’s a load form call.
Figure 21: Muncy — Original entry point (OEP); it’s a load form call.
During the malware analysis, the OEP was not found. When the malware is executed inside a debugger it crashes and an EXCEPTION_ACCESS_VIOLATION is triggered. Thus, the debugger is a useless piece of analysis to this threat.
Figure 22: EXCEPTION_ACCESS_VIOLATION happens when the malware is debugged.
According to the literature, If the EXCEPTION_ACCESS_VIOLATION (0xC0000005) or EXCEPTION_GUARD_PAGE (0x80000001) exception is seen and is not within the bounds of a memory breakpoint, then the hook returns a status that the event was not handled. This hides debuggers from the guard page detection method.
Next, several anti-VM and anti-debug techniques were used in order to unpack the malware but they were not shown efficient.
Returning to the dynamic analysis, when the malware is executed, it spikes the CPU; in fact, the unpacking process is initiated.
Figure 23: CPU spikes when malware is unpacked.
As shown in the malware main process illustred in Figure 4, two processes are created during the malware life-cycle.
The first one (PID 580) concerning the unpacking task, and the second one (PID 1256) is related to the malware behavior itself. All malicious activity is made here.
Figure 24: Two processes created during the malware execution.
One of the things that malware does after unpacking (second process, PID 1256) is a mass scan in the machine trying to collect sensitive information from FTP files.
Figure 25: Malware trying to collect information from FTP files.
In addition, the malware creates a temporary file (DFF90D.tmp) in the Windows Tempfolder. No sensitive information was possible to extract from that file.
Figure 26: Malware creates a file in the Windows temp folder.
More, a .bat file is also created in the temporary files, and which is then executed via a Windows powershell (PID 2552).
Figure 27: .bat file created by malware.
That file is created by malware (parent PID=1256) and it receives a parameter in the argv vector — a target file. That file is deleted. More, all the files created during malware execution are deleted. This powershell process is running the code inside the .bat file.
The .bat file deletes itself and the other ones passed via argv array. Look’s at source-code present within the file.
All the network traffic on the machine has now been monitored, but no connections to the Internet has been performed.
To get more details on malware, we run the malware again on a new machine. That machine has the Firefox browser, CutePDF and Filezilla installed and executing.
In this stage, we find that the malware found some target folders and files!
Figure 27: Some target files were found.
At this moment, and after the malware execution, communications to a specific domain were observed.
The malware tries to resolve the DNS: sameerd.net.
Figure 28: Malware invokes the domain: sameerd.net.
Beforehand, we simulate a fake Internet, and the malicious request was received.
Figure 29: POST request performed by Muncy malware.
The malware is trying to send a POST request to /grace/panelnew/gate.php, on port 80.
Figure 30: POST request content.
The POST content is encoded in binary and was not possible decode its content. The decompression process performed by Wireshark has generated an error as well.
In order to validate whether the domain reply on port 80, a telnet connection has been performed. As shown, the DNS has not been resolved.
The domain seems to be offline, but it was possible to get some indicators on it on Shodan and with the last update on 2019-02-12.
Figure 31: Available ports of the malicious DNS.
According to VirusTotal, it’s possible to validate that this domain is associated with three detections in the last days — the malware under analysis.
The malware was submitted first time by SI-LAB on February 12th (its first occurrence on VT).
Figure 32: VT malware detections.
As shown, the domain was created on February 12th.
Figure 33: Domain creation date.
In addition, we need to observe the following three points:
More, there are other passive DNS replications also created between February, 04th – 12th (complete list at the end of the article).
Figure 3: Passive DNS replication.
Muncy malware shows how malicious actors may quickly vary attack techniques and artifact characteristics. Due to that, detect its intent is very difficult and that makes much harder the malware analyst work!
As shown, static code analysis and even the use of a debugger became inefficient, and when a debugger is running, the malware simply triggered an error evading its analysis.
Despite these details, indicators about this threat were collected via a dynamic analysis. Some interesting behaviors, such as a scanning finding FTP files were observed.
Further details, including Indicators of Compromise (IoCs), are reported in the analysis published by Pedro Tavares.
About the author Pedro Tavares
Pedro Tavares is a professional in the field of information security working as an Ethical Hacker, Malware Analyst and also a Security Evangelist. He is also a founding member and
| [adrotate banner=”9″] | [adrotate banner=”12″] |
(
[adrotate banner=”5″]
[adrotate banner=”13″]
