A series of attacks carried out against banks in the Middle East in early May were using unique scripts that are not commonly seen in crimeware campaigns, researchers at FireEye warn.
The attacks were carried out via emails containing macro-enabled Microsoft Excel files sent to bank employees. According to FireEye, the emails were targeted, with one such message supposedly containing the conversation between several employees and the contact details of employees from several banks.
When run, the malicious macro extracts base64-encoded content a worksheet, then checks for the presence of %PUBLIC%Libraries update.vbs and creates three directories under %PUBLIC%Libraries, should the file be missing. The initially extracted content is then decoded using PowerShell and dropped into %PUBLIC%Librariesupdate.vbs and %PUBLIC%Librariesdns.ps1. Next, the macro creates the GoogleUpdateTaskMachineUI scheduled task that executes update.vbs every three minutes.
FireEye’s researchers also observed that additional content was displayed after the macro executed successfully – a social engineering technique meant to convince victims that the macro was legitimately revealing additional spreadsheet data. Usually, no additional content is displayed after enabling the macros, but the attackers took the extra step in this campaign, in an attempt to eliminate possible suspicion.
After the initial step has been successfully completed and the scheduled task created, a dropped VBScript called update.vbs is launched every three minutes. The VBScript leverages PowerShell to download content from a specific URL, including a BAT file. The BAT file is then executed, with the results saved in directory and then uploaded to the server.
Using PowerShell to evade detection is not unheard of in such attacks, and FireEye also observed that a customized version of Mimikatz, a publicly available tool that has been used in other campaigns too, was downloaded on compromised machines as well. The utility can be used by cybercriminals to recover plaintext passwords from memory.
In this specific attack, researchers say that the aforementioned BAT file was used to collect information from the compromised systems, including the currently logged on user, hostname, network configuration data, user and group accounts, local and domain administrator accounts, running processes, and other data.
The PowerShell script dns.ps1 dropped by the macro during the first step of infection is executed for data exfiltration via DNS queries, most probably because DNS is required for normal network operations and is unlikely to be blocked, thus allowing free communication out of the network, researchers say.
The script receives instructions from the command and control server, including an ID that is saved into the PowerShell script. The script uploads the gathered data to the DNS server by embedding file data into part of the subdomain, and it is invoked each time a scheduled task runs.
FireEye researchers note that the most interesting aspect of this attack was the use of different components to perform reconnaissance activities on a specific target, even if no zero-days or other advanced techniques were leveraged. Moreover, the attack proves that macro malware continues to be highly effective and that users should not enable Office macros for documents coming from unknown sources, even if these documents are from seemingly trusted sources.
Related: Macro Malware Makes Improvements on Hiding Malicious Code
Related: Macro Malware Dridex, Locky Using Forms to Hide Code