Introduction
VB6 compiler can be treated as a packer because of its translation from what is known as P-code into assembly code. This makes static analysis of it impossible unless manual unpacked, which will be implemented using a debugger such as x64dbg. For reference, see A.1 of the appendix for what an unpacked version VB6 looks like in IDA pro.
Unpacking Procedure
This sample utilized allocated memory to write and, at the same time, change its protection rights to start a new execution. This approach is typical and can be captured through the usage of setting breakpoints on the following APIs. IsDebuggerPresent, VirtualAlloc, and VirtualProtect, CreateProcessInternalW and or CreateProcessInternalA.
IsDebuggerPresent is typical because of anti-debugging in malware such as these. Setting a breakpoint at this function can allow us to zero out its return value, thus negating its effects.
This sample called upon VirtualAlloc more than ten times, all while returning the same address, except the very last one. This was very tedious, and I recommend the following approach.
- Set a break point solely on CreateProcessInternal(A/W) and wait until its execution.
- Search the executable for strings that would be included within every PE executable.
- Because it is known that a PE executable is to be written inside an allocated memory the words “This program cannot” should be enough as this is included in the header of every type of PE executable.
- Finding the start address of this allocated memory can then be dumped to file and analyzed. Debugging should be stopped unless further dynamic analysis would want to be done on the new executed file.
Static Analysis - Unpacked Sample
The sample is compiled with Borland Delphi compiler version 2.25. Based on the entropy, it was determined that the resource section is packed in some way. The sample also included VirtualAlloc, Sleep, HeapAlloc and GetProcessAddress, and LoadLibrary. The last two indicate that some dynamic linking is done along with static linkage.
It could be determined that the resource section was being unpacked with an unknown algorithm. It is best to allow the program to handle this itself in these situations, and it will be noted during debugging.
Dynamic Analysis - Debugger
I decided to set the following API breakpoints moving on from static analysis. The following are standard. Breakpoints are set on CreateFile(A/W), CreateProcessInternal(A/W), MapViewofFile, VirtualAlloc, VirtualProtect, CreateFileMapping(A/W), WriteFile and ResumeThread. Through these APIs, the following behavior was found.
The windows executables were being used for execution:
- Powershell.exe
- Mshta.exe
- Regsvr32.exe
See Appendix A.2 - A.4 for more background information on the previously stated windows executables.
Techniques and Tactics
Diffuse gravity utilizes many standard techniques to prevent it from being detected, especially by an unsuspecting user. For its abilities, I categorize it as malware, a lay of the land. It utilizes trusted tools provided by Windows to do most of the heavy lifting.
Network Communication Hiding
This malware utilizes Regsvr32.exe as a means of communication with outside networks. It uses its network capabilities to send TCP communications outbound through HTTP. Although no analytical data was captured, it was observed that several IP addresses that had no official Microsoft affiliation were being used. With a program like regsvr32.exe, any network communications would have regular occurring IP addresses, but log analysis showed irregular and an abundance of non-windows IP addresses. Log analysis using Procmon has demonstrated that the application regsvr32.exe has been looking through the HKCU\Software\cnatdatkc registry directory. This was created and has components on it that can restart the entire process with a .htm file.
The Procmon log file will be included in the Appendix A.5.
Shell Code Running and Code Obfuscation
The primary function of this malware is to act as a loader of payloads which are then executed by more trusted software such as PowerShell. One such example is the shellcode found in a PowerShell script file and run. This PowerShell script can be found in Appendix A.6 but should be noted that this file has been de-obfuscated, and the original was in the base64 encoding, an encoding used a lot throughout this sample.
Analysis of the shellcode proved to be complicated. Using tools such as scdbg proved to be ineffective as the output did not make much sense. The shellcode can be found in Appendix A.7. In addition to the process tree, which can be found in Appendix A.8, it is fair to say that this shellcode is what might be injected into the regsvr32.exe file—also, the previously mentioned log files and the odd behavior displayed by regsvr32.exe back up this claim.
While base64 is the primary obfuscation technique here, it is not the only one, as self-created algorithms have been formed to keep detection low. This will be talked about in relation to this malware’s persistence solution.
Persistence
Diffusegravity utilizes the registry to gain persistence after reboot, executing a very obfuscated JavaScript file that utilizes its own XOR algorithm to decrypt the data. This file can be found in Appendix A.9. The data is decrypted to a PowerShell script which again utilizes base64 to hide its contents. This data is then Invoked to execute PowerShell. The decoding of this data reveals to be the setup and shellcode for which my analysis makes me believe being injected into regsvr32.exe and causing it to run and contact outside IP addresses.
Conclusion
My analysis has not brought to a conclusion. Because of my lack of evidence, it is hard to say what is happening within the regsvr32 executable. One thing that can be stated is that this sample is a Trojan and loader. It disguises itself as a clock with an icon as such. What makes this Trojan so dangerous is how it hides. Upon complete execution of this malware itself deletes itself, and its last shellcode utilizes the tools provided by the system to execute what is further needed.
Even after a system restart with the help of the registry and without the need of the original loader, it can restart the programs mshta, PowerShell, and regsvr32 to do the commands it needs to do. This malware could be a botnet, ransomware dropper, or espionage code. Speculation should be saved from this paper as further analysis is necessary to determine the validity of these statements.
Furthermore, I would categorize this as semi-fileless as its only disk fingerprint is the registry but otherwise exists entirely within memory. The usage of trusted programs will make detection of this very hard for most and almost impossible for those who aren’t looking for it specifically. An utterly autonomous malware that travels from windows program to windows program undetected is a dangerous thing.
Indicators of Compromise I.O.C
Original Packed Payload Sha256: fc4f695752f8eb20b17689e60a7161a43665fa3455dc379aeb2a251838eb4da6
Unpacked Payload ef8970501e077afabde3142d2ff30d82253bfce50cc1b07812f64ccab85af720
Registry Created
- HKCU\Software\cnatdatkc
- HKCU\Software\cnatdatkc\xobkepd
- HKCU\Software\cnatdatkc\dxcn
- HKCU\Software\cnatdatkc\plwf
- HKCU\Software\cnatdatkc\ppee
- HKCU\Software\cnatdatkc\mrfsocc
- HKCU\Software\cnatdatkc\gpmtife
Registry Modified
- HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Run
Appendix
A.1
A.2
Powershell: https://docs.microsoft.com/en-us/powershell/
A3
A.4
Regsvr32.exe: https://docs.microsoft.com/en-us/windows-server/administration/windows-commands/regsvr32
A.5
https://github.com/ByridianBlack/Malware-Reports/blob/main/DiffuseGravity/diffuseGravityLogFile.PML
A.6
https://github.com/ByridianBlack/Malware-Reports/blob/main/DiffuseGravity/decoded_data.ps1
A. 7
https://github.com/ByridianBlack/Malware-Reports/blob/main/DiffuseGravity/extracted.ps1
A.8
A.9
https://github.com/ByridianBlack/Malware-Reports/blob/main/DiffuseGravity/registry_data.js
💬 Comment: