Detected New Advanced Threat Alert by BitDam – Technical Analysis
BitDam’s engine detected an interesting file called “Request.doc” in one of our customers.
The file, with sha1 of ebe28e25e2e976120afb0a687fc19618fcf9003d was not present in VirusTotal or any other site at the time we’ve detected it.
That file uses interesting obfuscation methods, running a vba macro that launches a cmd, launching a Powershell, downloading and invoking an executable that drops a Banker Trojan and registers it to run on startup.
Afterwards, it restarts the computer to make the Trojan run.
Relevant sha1s –
Doc file – ebe28e25e2e976120afb0a687fc19618fcf9003d
Dropper – 13f76ea4c868004e1720395bc2737318e45c0d0c
Trojan – 79dde9c7e0cceee8e5d9626819e2c33f9cce0425
Upon opening, the file asks the user to enable macros, as shown in Figure 1.
When I was looking at the file, I expected to find a simple macro, but as I looked at it, I found that it’s more interesting than I initially thought.
A quick glance at the macro is enough to see that it’s obfuscated, like most of the macros.
The authors of this macro used interesting techniques to avoid static detections;
The macro is over 800 lines, which is far more than the usual malicious macros we encounter. In addition, instead of using the common ‘Chr’ functions, this has an excessive use of ‘Hex’ and ‘Atn’ (arctangent) functions to perform the obfuscation.
Once the execution line was ready, instead of using the obvious WScript.Shell (or one of the obvious permutations), the authors wrapped ‘Shell’ with brackets, which probably spared them a decent amount of detections (as you can see in figure 2).
Once the Shell’s arguments were evaluated, it started a command prompt, running the monstrous command line shown in figure 3.
This command line is not common nor a simple one; It obfuscates the execution line into several environment variables, avoiding the need to write suspicious keywords such as ‘Powershell’ or ‘WebClient’ implicitly.
The Powershell command (Figure 4) itself is also obfuscated, but we can see strings like ‘Syst’, ’em.Net.Web’, ‘Clien’ that can state the obvious – this Powershell line is a downloader that downloads an executable and invokes it.
As expected, Powershell reaches the domain ‘9qwe8q9w7asqw[.c]om’ (See the request in Figure 5).
The server sends the executable (Sha1 – 13f76ea4c868004e1720395bc2737318e45c0d0c) and Powershell invokes it.
Attempting to avoid arousing suspicion and being detected by AVs, the executable itself doesn’t seem to do much and is not the last part in the attacker’s chain.
A short static and dynamic analysis of the executable shows us what it’s intended to do;
It drops another executable called ‘credocker.exe’ (sha1 – 79dde9c7e0cceee8e5d9626819e2c33f9cce0425), which is placed in “%appdata%\Roaming\Microsoft\Bicore”.
The programs don’t invoke “credocker.exe”, perhaps due to the suspiciousness of such actions.
The program creates a registry key whose value is automatically executed on startup.
The key is created under ‘Run’, which is created under the path shown in Figure 6.
In order to validate the execution of ‘credocker.exe’, there’s an irregular execution in the end of the program’s flow.
In Figure 7, the program acquires the current process’ token, adjusting its privileges with ‘SeShutdownPrivilege’.
Figure 7. Adjusting token privileges
After that, as shown in Figure 8, the program calls ExitWindowsEx function.
edi register, which represents the ‘uFlags’ parameter of ExitWindowsEx, stores the value 2, which stands for ‘EWX_REBOOT’.
Once the system was rebooted, the registry value, which by now looks as shown in Figure 9 is read by the OS and ‘credocker.exe’ is launched.
‘credocker.exe’ is the attacker’s final payload. It seems that this Trojan is Banker Trojan, aiming to hijack passwords and files.