Various entities across GCC received several spam emails embedded with a malicious document. Keep in mind that this doc was able to evade all the security measures and landed in the mailbox of victims. A sample is below:
Even without opening the file, the properties section of the file is shouting, “I am a bad boy.” Yet, confirmation is inevitable.
When I Opened the file, I got a prompt for enabling macros. Wait! How many of us would really enable it? Maybe a small percentage of people. However, I hope at least in the near future; the percentage should be zero.
Straight away, I rushed to the macro section and took control of it. Debugging the script within the same malicious file is quite a feel good 😉 “Document_Open ()” tells, this script will automatically run once the victim opens the document.
When we statically analyze the code, we can see a couple of promising sections. If we see these snippets of code, some encoded strings are being passed to the “RraiseeventR” variable, and the outcome is meant to be stored in another variable. We can see multiple other variables like these. In all those, there is a unique variable “RraiseeventR.“ So we can assume that this can be responsible for decryption routine.
The portion of Function “RraiseeventR” is shown below
A little more static analysis revealed a point where all these variables concatenated together to a result. The main advantage of debugging is that the code itself is allowed to decode or decrypt its encoded parts.
We can now see the above-defined variables have the decoded parameters stored and it is very promising. At a glance, it looks like PowerShell scripts, and we can see a “URL.”
All the stored results are concatenated to a variable “inEmptyMe” resulting in a full “PowerShell Script.”
I derived the scripts from the variable and made it readable almost like below. From this PowerShell script, it is very clear about downloading a file and executing it. If we look closely, there is an underlying tactic in the code which bypasses the UAC and other detections.
How about diving into the code? Here you go..
Initially, the powershell.exe is evoked headless, and then we can see PowerShell script variables being defined. $wscript variable is defined to run command shell with arguments. Next, a $webclient variable is defined, which is for sending data to and receiving data from a resource identified by a URI. Each web client call will be accompanied by a web request class like “DownloadFile” (e.g., WebClient.DownloadFile Or WebClient.UploadFile) $random variable is defined for randomizing numbers (range 1 – 65536). $urls variable is defined with a malicious Url which downloads an executable file. Which means that this script acts as a downloader and executes another file. The path where the executable should be saved is defined by concatenating “temp” folder and number-randomizing variable and ending it with “.exe.” This renames the executable file which script downloaded, into {random numbers}.exe and saves to a temp folder. We can see a Registry variable “$hkey” being set with “HKCUSoftwareClassesmscfileshellopencommand.” Next, the URL is accessed, downloaded the file which is then string converted and saved in the above mentioned “temp” folder with {random name}.exe.
Now from here, the tactic used in this PowerShell script comes into the picture: The method used here is file-less Bypassing of the UAC, acquiring highest integrity by manipulating the registry By looking the code closely, Let’s ask two questions:
Why is the script editing the data at “HKCUSoftwareClassesmscfileshellopencommand” and adding the path of the malicious executable?
Why is the “eventvwr.exe” evoked?
Well, there is a big link between both. Let us move the spotlight to the event viewer and the mentioned registry key. If we manually go to the said registry key, we can see the data is the path of “mmc.exe” (Microsoft Management Console).
“mmc.exe” is responsible for opening any Microsoft saved consoles (.msc) like lusrmgr.msc , eventvwr.msc etc. Oh! Did I say “eventvwr.msc”? There you go.. Let’s keep the malware aside for a while. Let’s talk about event viewer. Normally when we start eventvwr.exe, it first queries the Registry “HKCUSoftwareClassesmscfileshellopencommand” for mmc.exe. Unfortunately when it queried, the result was “NAME NOT FOUND.” Here comes another lesson: In Registry, “HKEY_CLASSES_ROOT” = “HKEY_LOCAL_MACHINESOFTWAREClasses” + “HKEY_CURRENT_USERSoftwareClasses” That said, as a high integrity process, if “eventvwr.exe” is failed to get the parameter from HKCU, it will immediately query for HKCR for the registry key, and here it succeeds:
“mmc.exe” once the eventvwr.exe evokes it through the registry will then evoke the “eventvwr.msc” which is then presented to us as a GUI.
Also, we can see the manifest of eventvwr.exe, tells it is having high integrity with execution level at its highest in process space and is auto-elevated, so it is very sensitive to security perspective:
Now coming back to our sample, the malicious PowerShell script is adding the data to the above-said registry key (HKCU) and adding the path to the already downloaded malicious executable which stays in temp folder with {randomname}.exe. Then eventvwr.exe is evoked. So the event viewer will run the malware by querying this HKCU without getting a chance to query HKCR for actual mmc.exe, in turn running the malware with high integrity. Now we know what will happen next. When we run the document with macro enabled to evaluate the above assumptions. As we suspected, Power Shell was evoked, the malware was downloaded from the remote host, saved as {random numbered}.exe at temp folder, and evoked itself through manipulating eventvwr and mmc Registry key values
Also, we can see that the malware is running in the “High” integrity level. Keep in mind that whatever malware does will be in its high execution level elevated:
Now the duty of malicious document ends and handed over the baton to the newly dropped malware. Thus Malware document could infect the machine by creating a PowerShell script to download another file and then managed to execute it with High execution level by bypassing UAC feature of Windows through manipulating event viewer and MMC Registry.
Now, what about malware playing in the machine.
Just a surface analysis shows the malware executable comes up with highly evading skills. It is VMaware, Debugger aware and another monitoring tool aware. Yes it is “Rootkit” an info stealer Once the malware is executed, it will drop a batch script as a means for anti-forensics capability or a self-suicide mechanism if it detects that it is being analyzed. The batch script is dropped and executed in the same temp folder where the executable is running and have High integrity as well, the reason we already discussed.
Self-suicide batch script:
The malware again drops a vb script file inside the startup folder, as a means of persistence. Every time the machine restarts, the malware is evoked through calling a shell.
Just when we throw the malware in the debugger, we can see some strings very interesting like “Welcome to China!” , Progman, etc. Also at a glance, we can see a prominent anti-reverse engineering tactic used – Structured Exception handler invoking.
Also, the malware is invoking some anti-analysis API calls including, GetTickCount, IsDebuggerPresent, CreateToolhelp32Snapshot, FindWindowA, etc. etc. Now, it is time to get inside the workshop for dissecting it further. All the above explained will happen only if the User interacts with this document. That is the reason why all security firms and security advisories keep on talking about “User Awareness.” Nowadays there has been an increasing spam mail campaign which transports malware files or malicious document with macros or embedded OLE objects. Now there are records 3rd wave of Shamoon APT widely spreading via Spam emails. I have already grabbed a bunch. After “user awareness,” what next? Each entity should sit, decide and brainstorm regarding how to maintain a rigid security posture. A small example came to my mind is what if we can add small policies at endpoint security measures, like disallowing any file to execute from “Temp folder” at least a bunch of these types of infections can be stopped. Like this, we can make a cheat sheet for best hardening of all controls. Malware authors are introducing new techniques to evade and infect us. Are we capable enough to defend them? Well… the answer echoes in each one of us… https://cysinfo.com/ https://zeltser.com/analyzing-malicious-documents/ https://digital-forensics.sans.org/blog/2009/11/23/extracting-vb-macros-from-malicious-documents/ https://enigma0x3.net/ https://blog.malwarebytes.com/threat-analysis/2015/10/beware-of-doc-a-look-on-malicious-macros/
