Malware RSS Feed
One of the most active APT groups in Asia, and especially around the South China Sea area is "Naikon". Naikon plays a key part in our story, but the focus of this report is on another threat actor entirely; one who came to our attention when they hit back at a Naikon attack.
Naikon is known for its custom backdoor, called RARSTONE, which our colleagues at Trend Micro have described in detail. The name Naikon comes from a custom user agent string, "NOKIAN95/WEB", located within the backdoor:
NOKIAN string in Naikon backdoor
The Naikon group is mostly active in countries such as the Philippines, Malaysia, Cambodia, Indonesia, Vietnam, Myanmar, Singapore, and Nepal, hitting a variety of targets in a very opportunistic way. What was perhaps one of the biggest operations of the Naikon group was launched in March 2014, in the wake of the MH370 tragedy that took place on March 8th. By March 11th, the Naikon group was actively hitting most of the nations involved in the search for MH370. The targets were extremely wide-ranging but included institutions with access to information related to the disappearance of MH370, such as:
- Office of the President
- Armed Forces
- Office of the Cabinet Secretary
- National Security Council(s)
- Office of the Solicitor General
- National Intelligence Coordinating Agency
- Civil Aviation Authority
- Department of Justice
- National Police
- Presidential Management Staff
The Naikon group used mostly spear-phished documents for the attacks, with CVE-2012-0158 exploits that dropped the group's signature backdoor.
While many of these attacks were successful, at least one of the targets didn't seem to like being hit, and instead of opening the documents, decided on a very different course of action.The empire strikes back
Here's a question - what should you do when you receiving a suspicious document from somebody you don't know, or know very little? Choose one:
- Open the document
- Don't open the document
- Open the document on a Mac (everybody knows Mac's don't get viruses)
- Open the document in a virtual machine with Linux
Based on our experience, most people would say 2, 3 or 4. Very few would open the document and even fewer would actually decide to test the attacker and verify its story.
But this is exactly what happened when one of the Naikon spear-phishing targets received a suspicious email. Instead of opening the document or choosing to open it on an exotic platform, they decided to check the story with the sender:
Naikon target asks for confirmation of the email
In the email above, we can see the target questioning the authenticity of the Naikon spear-phishing. They ask the sender if it was their intention to email this document.
The attacker was, of course, not confused in the slightest, and being very familiar with the internal structure of the target's government agency, replied claiming that they work for the secretariat division and were instructed to send it by the organization's management:
Naikon attacker replies to the target
The reply is written in poor English and indicates that the attacker is probably not as proficient in the language as the intended victim. Seeing the reply, the target obviously decided not to open the document. Moreover, they decided to go a bit further and try to learn more about the attacker.
Not long after the first exchange, the following email was sent to the attacker by the target:
The attachment is a RAR archive with password, which allows it to safely bypass malware scanners associated with the free email account used by the attackers. Inside the archive we find two decode PDF files and one SCR file:
Much to our surprise, the "SCR" file turned out to be a backdoor prepared especially for the Naikon fraudsters.
The file "Directory of ... Mar 31, 2014.scr" (md5: 198fc1af5cd278091f36645a77c18ffa) drops a blank document containing the error message and a backdoor module (md5: 588f41b1f34b29529bc117346355113f). The backdoor connects to the command server located at philippinenews[.]mooo[.]com.
The backdoor can perform the following actions:
- download files
- upload files
- update itself
- uninstall itself
We were amazed to see this course of action and decided to investigate the "Empire Strikes Back"-door further; naming the actor "Hellsing" (explained later).
The malware used by the intended victim appears to have the following geographical distribution, according to KSN data:
- Malaysia – government networks
- Philippines – government networks
- Indonesia – government networks
- USA - diplomatic agencies
- India (old versions of malware)
In addition, we've observed the targeting of ASEAN-related entities.
Victims of Hellsing attacks
The actor targets its intended victims using spear-phishing emails with archives containing malware, similar to the one it used against the Naikon group. Some of the attachment names we observed include:
- 2013 Mid-Year IAG Meeting Admin Circular FINAL.7z
- HSG FOLG ITEMS FOR USE OF NEWLY PROMOTED YNC FEDERICO P AMORADA 798085 PN CLN.zip
- Home Office Directory as of May 2012.Please find attached here the latest DFA directory and key position officials for your referenece.scr
- LOI Nr 135-12 re 2nd Quarter.Scr
- Letter from Paquito Ochoa to Albert Del Rosario,the Current Secretary of Foreign Affairs of the Philippines.7z
- Letter to SND_Office Call and Visit to Commander, United States Pacific Command (USPACOM) VER 4.0.zip
- PAF-ACES Fellowship Program.scr
- RAND Analytic Architecture for Capabilities Based Planning, Mission System Analysis, and Transformation.scr
- Update Attachments_Interaction of Military Personnel with the President _2012_06_28.rar
- Update SND Meeting with the President re Hasahasa Shoal Incident.scr
- Washington DC Directory November 2012-EMBASSY OF THE PHILIPPINES.zip
We've observed RAR, ZIP and 7ZIP archives in the attacks - the 7ZIP archives with passwords were probably introduced as a way to bypass the recent security features on Gmail, which block password-protected archives with executables inside.
Each backdoor has a command and control server inside as well as a version number and a campaign or victim identifier. Some examples include:MD5 Date C&C Campaign identifier 2682a1246199a18967c98cb32191230c Mar 31 2014 freebsd.extrimtur[.]com 1.6.1_MOTAC 31b3cc60dbecb653ae972db9e57e14ec Mar 31 2014 freebsd.extrimtur[.]com 1.6.1_MOTAC 4dbfd37fd851daebdae7f009adec3cbd Nov 08 2013 articles.whynotad[.]com 1.5_articles.whynotad.com-nsc 015915bbfcda1b2b884db87262970a11 Feb 19 2014 guaranteed9.strangled[.]net 1.5_guaranteed9-nsc 3a40e0deb14f821516eadaed24301335 Mar 31 2014 hosts.mysaol[.]com 1.6.1_imi;simple 73396bacd33cde4c8cb699bcf11d9f56 Nov 08 2013 web01.crabdance[.]com 1.5_op_laptop 7c0be4e6aee5bc5960baa57c6a93f420 Nov 08 2013 hosts.mysaol[.]com 1.5_MMEA bff9c356e20a49bbcb12547c8d483352 Apr 02 2014 imgs09.homenet[.]org 1.6.1_It c0e85b34697c8561452a149a0b123435 Apr 02 2014 imgs09.homenet[.]org 1.6.1_It f13deac7d2c1a971f98c9365b071db92 Nov 08 2013 hosts.mysaol[.]com 1.5_MMEA f74ccb013edd82b25fd1726b17b670e5 May 12 2014 second.photo-frame[.]com 1.6.2s_Ab
The campaign identifiers could be related to the organizations targeted by the specific builds of this APT. Some possible descriptions for these initials could be:
- MOTAC - Ministry of Tourism and Culture, Malaysia - http://www.motac.gov.my/en/
- NSC - http://www.nsc.gov.my/
- MMEA - Malaysian Maritime Enforcement Agency - http://www.mmea.gov.my
Interestingly, some of the infrastructure used by the attackers appears to overlap (although around a year apart) with a group tracked internally at Kaspersky Lab as PlayfullDragon (also known as "GREF"); while other aspects of the infrastructure overlap with a group known as Mirage or Vixen Panda.
For instance, one of the PlayfullDragon's Xslcmd backdoors described by our colleagues from FireEye (md5: 6c3be96b65a7db4662ccaae34d6e72cc) beams to cdi.indiadigest[.]in:53. One of the Hellsing samples we analysed (md5: 0cbefd8cd4b9a36c791d926f84f10b7b) connects to the C&C server at webmm[.]indiadigest[.]in. Although the hostname is not the same, the top level domain suggests some kind of connection between the groups. Several other C&C subdomains on "indiadigest[.]in" include:
Another overlap we observed is with an APT known as Cycldek or Goblin Panda. Some of the Hellsing samples we analysed in this operation (e.g. md5: a91c9a2b1bc4020514c6c49c5ff84298) communicate with the server webb[.]huntingtomingalls[.]com, using a protocol specific to the Cycldek backdoors (binup.asp/textup.asp/online.asp).
It appears that the Hellsing developer started with the Cycldek sources and worked together with the operators from other APT groups. Nevertheless, it is sufficiently different to warrant classification as a stand-alone operation.
So, where does the Hellsing name come from? One of the samples we analysed (md5: 036e021e1b7f61cddfd294f791de7ea2) appears to have been compiled in a rush and the attacker forgot to remove the debug information. One can see the project name is Hellsing and the malware is called "msger":
Of course, Hellsing can have many different meanings, including the famous doctor from Bram Stoker's Dracula. However, according to Wikipedia, "Hellsing (ヘルシング Herushingu) is also a Japanese manga series written and illustrated by Kouta Hirano. It first premiered in Young King Ours in 1997 and ended in September 2008".
The Hellsing series chronicles the efforts of the mysterious and secret Hellsing Organization, as it combats vampires, ghouls, and other supernatural foes; which makes it perhaps an appropriate name for our group.
In addition to the Hellsing/msger malware, we've identified a second generation of Trojan samples which appear to be called "xweber" by the attackers:
"Xweber" seems to be the more recent Trojan, taking into account compilation timestamps. All the "msger" samples we have seen appear to have been compiled in 2012. The "Xweber" samples are from 2013 and from 2014, indicating that at some point during 2013 the "msger" malware project was renamed and/or integrated into "Xweber".
During our investigation we've observed the Hellsing APT using both the "Xweber" and "msger" backdoors in their attacks, as well as other tools named "xrat", "clare", "irene" and "xKat".Other tools
Once the Hellsing attackers compromise a computer, they deploy other tools which can be used for gathering further information about the victim or doing lateral movement. One such tool is "test.exe":Name test.exe Size 45,568 bytes MD5 14309b52f5a3df8cb0eb5b6dae9ce4da Type Win32 PE i386 executable
This tool is used to gather information and test available proxies. Interestingly, it also contains the Hellsing debug path:
Another attack tool deployed in a victim's environment was a file system driver, named "diskfilter.sys", although internally it claims to be named "xrat.sys". The driver is unsigned and compiled for 32-bit Windows. It was used briefly in 2013, before being abandoned by the attackers, possibly due to Windows 7 driver signing requirements:
Another tool used by the attackers is called "xKat":Name xkat.exe Size 78,848 bytes MD5 621e4c293313e8638fb8f725c0ae9d0f Type Win32 PE i386 executable
This is a powerful file deletion and process killer which uses a driver (Dbgv.sys) to perform the operations. We've seen it being used by the attackers to kill and delete malware belonging to their competitors.
Some of the debug paths found in the binaries include:
In general, the attribution of APTs is a very tricky task which is why we prefer to publish technical details and allow others to draw their own conclusions.
The Hellsing-related samples appear to have been compiled around the following times:
Assuming normal work starts at around 9 am, the attacker seems to be most active in a time-zone of GMT+8 or +9, considering a work program of 9/10 am to 6/7pm.Conclusions
The Hellsing APT group is currently active in the APAC region, hitting targets mainly in the South China Sea area, with a focus on Malaysia, the Philippines and Indonesia. The group has a relatively small footprint compared to massive operations such as "Equation". Smaller groups can have the advantage of being able to stay under the radar for longer periods of time, which is what happened here.
The targeting of the Naikon group by the Hellsing APT is perhaps the most interesting part. In the past, we've seen APT groups accidentally hitting each other while stealing address books from victims and then mass-mailing everyone on each of these lists. But, considering the timing and origin of the attack, the current case seems more likely to be an APT-on-APT attack.
To protect against a Hellsing attack, we recommend that organisations follow basic security best practices:
- Don't open attachments from people you don't know
- Beware of password-protected archives which contain SCR or other executable files inside
- If you are unsure about the attachment, try to open it in a sandbox
- Make sure you have a modern operating system with all patches installed
- Update all third party applications such as Microsoft Office, Java, Adobe Flash Player and Adobe Reader
Kaspersky Lab products detect the backdoors used by the Hellsing attacker as: HEUR:Trojan.Win32.Generic, Trojan-Dropper.Win32.Agent.kbuj, Trojan-Dropper.Win32.Agent.kzqq.Appendix:
Microsoft releases 11 Security Bulletins (MS15-032 through MS15-042) today, addressing a list of over 25 CVE-identified vulnerabilities for April of 2015. Critical vulnerabilities are fixed in Internet Explorer, Microsoft Office, and the network and graphics stacks. Most of the critical remote code execution (RCE) vulnerabilities reside in the IE memory corruption bugs for all versions of Internet Explorer (6-11) and the Microsoft Office use-after-free, however, they appear to all be result of private discoveries.
The Microsoft Office CVE-2015-1649 use-after free is a critical RCE impacting a variety of software and scenarios. The vulnerable code exists across desktop versions Word 2007, 2010, the Word Viewer and Office Compatibility apps, but not Word 2013 or Word for Mac. It's also critical RCE on the server-side in Word Automation Services on Sharepoint 2010 and Microsoft Office Web Apps Server 2010, but not SharePoint 2013 or Web Apps 2013.
As the new Verizon Data Breach 2015 report highlighted today, many exploits currently effective against targets are exploiting vulnerabilities patched long ago. According to their figures, many of the exploited CVE used on compromised hosts were published over a year prior. Microsoft provides Windows Update to easily keep your software updated, and Kaspersky products provide vulnerability scanners to help keep all of your software up-to-date, including Microsoft's. Please patch asap.
From the heap of vulnerabilities and fixes rated "Important", the Hyper-V DoS issue effects the newest Microsoft platform code: Windows 8.1 64-bit and Windows Server 2012 R2 (including the Server Core installation, which is fairly unusual). While the flawed code has not been found to enable EoP on other VMs within the Hyper-V host, attacked Hyper-V systems may lose management of all VMs in the Virtual Machine Manager.
Oh, how procrastination gets all of us! April 15th is the U.S. tax deadline and it looks like most of us will be coming down to the wire on declaring our taxes and holding our collective breath in expectation of that sweet, sweet refund. Sadly, our malware writing friends are aware of this and their discipline has proven far superior. Knowing that many are on the lookout for emails from the Internal Revenue Service concerning pending refunds, criminals have crafted some of their own:
The attachment is actually a Trojan-Downloader.MsWord.Agent malware, built by the same group behind the recent LogMeIn malicious campaign described here.
The infection scheme is very similar to the aforementioned, however, the threat actor has moved on from abusing Pastebin entries and has instead hacked a Web server in China to host the instructions script file. This file as well as the download URL are also encoded in Base64 and the resulting payload is actually ransomware.
URLs embedded in the malicious macros leading to a Base64 encoded instructions script file and the payload URL below
Instructions files with the URL to the ransomware payload
The malicious ransomware payload is detected by Kaspersky Anti-Virus as Trojan-Ransom.Win32.Foreign.mfbg
Due to the reliance on the IRS branding, this particular malicious campaign is mostly focused on US citizens and permanent residents of the USA.
Some months ago we wrote a blog post about CoinVault. In that post we explained how we tore the malware apart in order to get to its original code and not the obfuscated one.
So when were contacted recently by the National High Tech Crime Unit (NHTCU) of the Netherlands' police and the Netherlands' National Prosecutors Office, who had obtained a database from a CoinVault command & control server (containing IVs, Keys and private Bitcoin wallets), we were able to put our accumulated insight to good use and accelerate the creation of a decryption tool.
We also created a website and started a communications campaign to notify victims that it might be possible to get their data back without paying.
To build the decryption tool we needed to know the following:
- Which encryption algorithm was being used?
- Which block cipher mode was being used?
- And, most importantly, what malware are dealing with?
There was obviously no time for "hardcore" reverse engineering, so the first thing we did was run the malware sample to see what it was doing. And indeed, just as we thought, it was another CoinVault sample. The next thing we did was open the executable in a decompiler, where we saw that the same obfuscation method was used as described in the post. So CoinVault it is. However, we still didn't know which encryption algorithm and block cipher mode it was using.
But luckily we have a sandbox! The nice thing about the sandbox is that it executes the malware, but also has the ability to trace virtually anything. We can dump files and registry changes but in this case the memory dumps were the most interesting. We knew from the previous CoinVault samples that the malware was using the RijndaelManaged class, so all we had to do was search in the memory dump for this string.
And here it is. We see that it still uses AES, although not the 128-bit block size anymore, but the 256-bit one. Also the block cipher mode has changed from CBC to CFB. This was all the information we needed to write our decryption tool (link to decryption tool).
To see if you can decrypt your files for free, please go to https://noransom.kaspersky.com
On 9 April, 2015 Kaspersky Lab was recently involved in the synchronized Simda botnet takedown operation coordinated by INTERPOL Global Complex for Innovation. In this case the investigation was initially started by Microsoft and expanded to involve a larger circle of participants including TrendMicro, the Cyber Defense Institute, officers from the Dutch National High Tech Crime Unit (NHTCU), the FBI, the Police Grand-Ducale Section Nouvelles Technologies in Luxembourg, and the Russian Ministry of the Interior's Cybercrime Department "K" supported by the INTERPOL National Central Bureau in Moscow.
As a result of this takedown of 14 C&C servers in the Netherlands, USA, Luxembourg, Poland and Russia. Preliminary analysis of some of the sinkholed server logs revealed a list of 190 countries affected by the Simda botnet.
Simba character, courtesy of Walt Disney Productions, has nothing to do with Simda botnet
Simda is a mysterious botnet used for cybercriminal purposes, such as the dissemination of potentially unwanted and malicious software. This bot is mysterious because it rarely appears on our KSN radars despite compromising a large number of hosts every day. This is partly due to detection of emulation, security tools and virtual machines. It has a number of methods to detect research sandbox environments with a view to tricking researchers by consuming all CPU resources or notifying the botnet owner about the external IP address of the research network. Another reason is a server-side polymorphism and the limited lifetime of the bots.
Simda is distributed by a number of infected websites that redirect to exploit kits. The bot uses hardcoded IP addresses to notifying the master about various stages of execution process. It downloads and runs additional components from its own update servers and can modify the system hosts file. The latter is quite an interesting technique, even if it seems deceptively obvious at first glance.
Normally malware authors modify host files to tamper with search engine results or blacklist certain security software websites, but the Simda bot adds unexpected records for google-analytics.com and connect.facebook.net to point to malicious IPs.
KL detected the #Simda #bot as Backdoor.Win32.Simda, it affected hundreds thousands victims worldwideTweet
Why is that, one might ask? We don't know, but we believe that the answer is connected with Simda's core purpose – the distribution of other malware. This criminal business model opens up the possibility of exclusive malware distribution. This means that the distributors can guarantee that only the client's malware is installed on infected machines. And that becomes the case when Simda interprets a response from the C&C server - it can deactivate itself by preventing the bot to start after next reboot, instantly exiting. This deactivation coincides with the modification of the system hosts file. As a farewell touch, Simda replaces the original hosts file with a new one from its own body.
Now, curious mind may ask: how does it help them? Those domains are no longer used to generate search results, but machines infected by Simda in the past might occasionally continue to send out HTTP requests to malicious servers from time to time, even in when exclusive 3rd-party malware is supposed to have been installed.
We need to remember that these machines were initially infected by an exploit kit using a vulnerability in unpatched software. It's highly likely that 3rd-party malware will be removed over time, but a careless user may never get round to updating vulnerable software.
In this investigation Microsoft and various law enforcement bodies completed the sinkholing process and Kaspersky Lab willingly contributed to the preparations for the takedown. That work included technical analysis of malware, collecting infection statistics, advising on botnet takedown strategy and consulting our INTERPOL partners.
Kaspersky Lab detected the Simda bot as Backdoor.Win32.Simda and according to our estimations based on KSN statistics and telemetry from our partners it affected hundreds thousands victims worldwide.
Simda is automatically generated on demand and this is confirmed by the absence of any order in compilation link times. Below is a chart generated from a small subset of about 70 random Simda samples:
Samples link times in UTC timezone
The increase in link times is most likely related to the activity of the majority of Simda victims located somewhere between UTC-9 and UTC-5 timezones, which includes United States.
Thanks to the sinkhole operation and data sharing between partners we have put up a page where you can check if your IP has connected to Simda C&C servers in the past. If you suspect your computer was compromised you can use one of our free or trial solutions to scan your whole hard drive or install Kaspersky Internet Security for long-term protection.
Kaspersky Lab products currently detect hundreds of thousands of modifications of the Simda together with many different 3rd-party malware distributed during the Simda campaign.
In December 2014 we discovered a very interesting vulnerability in the Darwin kernel, which is an open source part of Apple's two operating systems: OS X and iOS. As a result, OS X 10.10 and iOS 8 are also at risk. This vulnerability is connected with the processing of an IP packet that has a specific size and invalid IP options. As a result, remote attackers can cause DoS (denial of service) of a device with OS X 10.10 or iOS 8 installed. It means that attackers can send just one incorrect network packet to the victim and the victim's system will crash.
OS X 10.10 crash after invalid network packet processing
Using vulnerability in the Darwin kernel attackers can cause DoS of a device with OS X 10.10 or iOS 8 installedTweet
While analyzing this vulnerability we've discovered that the following devices with 64-bit processors and iOS 8 installed are affected by this threat:
- iPhone 5s and later models
- iPad Air and later models
- iPad mini 2 and later models
To understand the nature of this bug let's look at a crash dump:
Kernel stack trace
You can see from this trace that something went wrong in the icmp_error() function and it calls the panic function. This function tries to construct a new ICMP error message and resend it. This screenshot shows that the icmp_error was called after parsing packet options. The problem lies in this piece of code:
The cause of the problem
When the conditions laid down in the code are met, the panic function is engaged and the system is shut down in emergency mode. This happens because the internal kernel structures have been changed and the new buffer size is insufficient to store a newly-generated ICMP packet. To cause this, the IP packet must satisfy the following criteria:
- The size of the IP header should be 60 bytes.
- The size of the IP payload should be at least 65 bytes
- There should be errors in the IP options (invalid size of option, class, etc.)
Example of packet that cause a crash
At first glance it is not obvious how this bug could be exploited effectively. However, a true professional can easily use it to break down a user's device or even interrupt the work of a corporate network. Usually this kind of incorrect packet would be dropped by routers or firewalls but we discovered several combinations of incorrect IP options that can pass through the Internet routers.
This vulnerability no longer exists in OS X 10.10.3 and iOS 8.3. In addition, users of Kaspersky Lab's products are secured against this vulnerability in OS X 10.10 by the Network Attack Blocker feature. Starting from Kaspersky Internet Security for Mac 15.0, this threat is detected as DoS.OSX.Yosemite.ICMP.Error.exploit.
In the summer of 2014, the company Trend Micro announced the detection of a new threat - the banking Trojan Emotet. The description indicated that the malware could steal bank account details by intercepting traffic. We call this modification version 1.
In the autumn of that year a new version of Emotet was found. It caught our attention for the following reasons:
- The developers of this Trojan had begun to use technology that stole money automatically from victims' bank accounts - so called "Automatic Transfer System (ATS)".
- The Trojan had a modular structure: it contained its own installation module, a banking module, a spam bot module, a module for stealing address books from MS Outlook and a module for organizing DDoS attacks (Nitol DDoS bot).
- The creators made a significant effort to remain unnoticed: they didn't attack users in the RU zone but targeted the clients of a small number of German and Austrian banks (other well-known banking Trojans are less discerning in their choice of target),and the domain name of the ATS server changed frequently (once or several times a day).
We are going to refer to this modification as Emotet version 2. The bot contains and transfers the numbers one and seven to the command and control center (C&C), which suggests that the Trojan's authors considers this variant to be version 1.7.
Both versions of the Trojan attacked clients of German and Austrian banks.
#Trojan #Emotet targeted the clients of a small number of German, Austrian and Swiss banksTweet
We closely monitored Emotet version 2. In December 2014 it ceased activity and the command servers stopped responding to infected computers. We recorded the last command sent from the command centers on 10/12/2014, at 11:33:43 Moscow time.
However, the thoroughness with which the authors had approached the development of this Trojan and the high level of automation in its operation, left little doubt that this was not the end of the story. And so it turned out - after a short break in January 2015, Emotet reappeared! We are calling this modification version 3 (the bot contains and transfers the numbers one and 16 to the C&C, which we assume means that the authors consider this variant to be version 1.16).
In essence, Emotet version 3 is not that different to version 2 - the main differences are designed to make the Trojan less visible. Of the changes we noted, we would like to highlight the following:
- The Trojan has a new built-in public RSA key and, although the communication protocols with the command center are identical for Emotet versions 2 and 3, if the old key is used the bot does not receive the correct answer from the command center.
- The ATS scripts are partially cleaned of debugging information and comments.
- New targets! Emotet is now also targeting clients of Swiss banks.
- There has been a slight change in the technology used to inject code into the address space of explorer.exe. Version 2 used a classic model for code injection: OpenProcess+WriteProcessMemeory+CreateRemoteThread. Version 3 uses only two stages of the previous model:OpenProcess+WriteProcessMemory; and the injected code is initiated with the help of modified code of the ZwClose function in the address space of the explorer.exe process, which is also achieved using WriteProcessMemory.
- Emotet version 3 resists investigation: if the Trojan detects that it has been started in a virtual machine it functions as usual but uses a different address list for the command centers. However, all these addresses are false and are used only to mislead investigators.
- The Trojan contains very few lines of text: all lines that could warn investigators are encrypted using RC4 and are decrypted in allocated memory directly before use and deleted after use.
On the whole, we formed the impression that the main techniques used in version 3 of the banking Trojan were developed "in the field" using version 2 as a basis, and with the addition of improved stealth techniques.
Kaspersky Lab products detect all versions of this Trojan as Trojan-Banker.Win32.Emotet. We also detect the following modulesof Emotet:
- Module for modifying HTTP(S) traffic - Trojan-Banker.Win32.Emotet.
- Spam module - Trojan.Win32.Emospam.
- Module for the collection of email addresses - Trojan.Win32.Emograbber.
- Module for stealing email account data - Trojan-PSW.Win32.Emostealer.
- Module designed for organising DDoS attacks — Trojan.Win32.ServStart.
We have seen the last module used with other malware and assume that it was added to Emotet by a cryptor. It is quite possible that Emotet's authors are totally unaware of the presence of this module in their malware. Whatever the case may be, the command centers of this module do not respond and the module has not been updated (its compilation date is 19 October 2014).Infection
We currently know of only one method of distribution for the Emotet banking Trojan: distribution of spam mailings that include malicious attachments or links.
The attached files are usually ZIP archives containing the Emotet loader. The files in the archives have long names, e.g. rechnung_november_2014_11_0029302375471_03_44_0039938289.exe. This is done on purpose: a user opening the archive in a standard Windows panel might not see the extension .exe, as the end of the file name might not be displayed. Sometimes there is no attachment and the text in the main body of the email contains a link to a malicious executable file or archive.
#Emotet banking #Trojan is distributed of spam mailings that include malicious attachments or linksTweet
Examples of emails used to spread Emotet are given below.
Version 2 (link to malware):
Version 2 (attached archive):
Version 3 (link to malware):
The emails we found are almost identical to ones from well-known companies – for example Deutsche Telekom AG and DHL International GmbH. Even the images contained in the messages are loaded from the official servers telekom.de and dhl.com, respectively.
When the email contains a link to malware, it downloads it from the addresses of compromised legitimate sites:
hxxp://*******/82nBRaLiv (for version 2)
or from the addresses
hxxp://*******/dhl_paket_de_DE and hxxp://*******/dhl_paket_de_DE (for version 3).
In Emotet version 3, when addresses are contacted with the form hxxp://*/dhl_paket_de_DE, the user receives a ZIP archive of the following form hxxp://*/dhl_paket_de_DE_26401756290104624513.zip.
The archive contains an exe-file with a long name (to hide the extension) and a PDF document icon.Loading the Trojan
The Trojan file is packed by a cryptor, the main purpose of which is to avoid detection by anti-virus programs. After being started and processed by the cryptor, control is passed to the main Emotet module - the loader. This has to embed itself in the system, link with the command server, download additional modules and then run them.
Consolidation in the system is fairly standard — Emotet version 2 saves itself in %APPDATA%\Identities with a random name of eight characters (for example — wlyqvago.exe); adds itself to the autoloader (HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Run) and then deletes its source file with the help of a launched bat-file that is created in %APPDATA% with the name "ms[7_random_numbers].bat.
Emotet version 3 saves itself in %APPDATA%\Microsoft\ with a name in the format msdb%x.exe" (for example – C:\Documents and Settings\Administrator\Application Data\Microsoft\msdbfe1b033.exe); adds itself to the autoloader (HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Run) and then deletes itself with the help of a launched bat-file (which is created in %APPDATA%\del%x.bat).
After consolidating itself in the system, Emotet obtains a list of the names of all processes running and calculates a hash from the name of every function, comparing the resulting value with the hardcoded 0xB316A779 (this hash corresponds to the process explorer.exe). In this way, Emotet locates the process into which to inject itself. Further, the Trojan unpacks its main code and injects it into the process explorer.exe.Communication with the command center
The main module of the Trojan, the loader, communicates with the C&C using RC4 encryption.
The port used by the loader is hardcoded into it - 8080.Command center addresses
The IP addresses of Emotet's command-and-control servers are hardcoded into the bot. There are several of these – one of the version 2 samples that we analyzed included 30 (note that 3 addresses on the list below belong to well-known legitimate resources):
In the sample of version 3 we investigated there were 19 command centers:
Emotet version 3 contains another list of "command center" addresses, as given below:
The Trojan tries to contact these addresses if it detects that it is being run in a virtual machine. But none of the addresses correspond to the bot's command centers, and the bot is therefore unsuccessful in trying to establish contact with them. This is probably done to confuse any investigators and give them the impression that the Trojan command centers are dead. A similar approach was used previously in the high-profile banking Trojan, Citadel.
#Trojan #Emotet tries to contact the wrong addresses of the C&C if it is being run in a virtual machineTweet
The detection of a virtual machine is organized quite simply — by the names of processes that are usual for various virtual machines. The following algorithm is used to calculate a hash value from the name of every process in the system:
Algorithm for calculation of a hash value from a process name
The resulting hash value is then compared with a list of values hardcoded into the Trojan:
Hashes from the names of processes used for the detection of virtual machines
We derived the names of the processes for several hashes. For example, hash 0xBCF398B5 corresponds to the process vboxservice.exe, hash 0x2C967737 to the process vmacthlp.exe, hash 0xE3EBFE44 to the process vmtoolsd.exe, and 0x61F15513 to the process vboxtray.exe.Data transferred
A request to the command center appears in the traffic as follows (the example given is from version 2, but a version 3 request looks the same):
Dialogue between the Emotet bot and its command center
The URL-path that the bot communicates with appears as follows: /722ffc5e/355c7a0a/, where 722ffc5e is a number calculated on the basis of information from the access marker of the user, and 0x355c7a0a = 0x722ffc5e xor 0x47738654 (the value 0x47738654 is hardcoded into the bot).
The data sent by the bot and the command center are encrypted using RC4 and the answers received from the command center are signed with a digital signature. Probably this is done to make it difficult to seize control over the botnet: in order for the bot to accept a packet it must be signed and for that it is necessary to know the secret key.
There is a public RSA key in the body of the bot. In PEM format for version 2 it appears as follows:
PEM representation of the open RSA key coded into the bot in version 2
As noted above, in version 3 the key changed. In PEM format it looks like this:
PEM representation of the open RSA key coded into the bot in version 3
A packet sent to the server is made up as follows:
- A request is generated containing the identifier of the infected computer, a value presumably indicating the version of the bot; information about the system (OS version, service pack version, product type); a hardcoded dword (value in the investigated sample — seven); control sums for the banker module; and information about the web-injects. Information about the web-injects contains: a page address (with jokers), into which the injection is needed; data coming before the injected data; data coming after injected data; and injected data.
- An SHA1 hash is calculated from the generated request.
- The request is encrypted with a randomly generated 128 bit RC4 key.
- The generated RC4 key is encrypted using the public RSA key.
- The total packet is the concatenation of the results obtained at steps 4, 2 and 3.
The request packet can be represented by the following diagram:
Structure of a request from the bot to the server
In response the server sends a packet with the following structure:
Structure of the server's answer to the bot
The answer can contain information about the Emotet web-injects, Emotet modules and links for loading external modules (for example a spam bot or an updated loader).Modules
Like most modern banking Trojans, Emotet has a modular structure. To date we have detected the following modules:Name Description Method of delivery to infected system loader loader In spam emails or by downloading via a link from a compromised site (for updates). nitol-like-ddos-module DDoS-bot mss Spam module Downloaded from compromised sites by the loader module. email_accounts_grabber Email account grabber, uses Mail PassView – a legitimate program designed for recovering forgotten passwords and mail accounts Received by the loader module in the answer packet from the command center. banker Module for modifying HTTP(S)-traffic Received by the loader module in the answer packet from the command center. outlook_grabber Outlook address book grabber Received by the loader module in the answer packet from the command center.
Several modules can work independently of the loader module, as they don't need to import anything from it.
The whole arrangement of the bot is evidence of a high level of automation: new email addresses are collected automatically from the victims' address books, spam with the Emotet loader is sent automatically, and money is transferred automatically from the user. Operator participation is kept to a minimum.
As an example, here is the report of the outlook_grabber module sent to the attacker (from Emotet version 2) with a stolen Outlook address book:
A stolen Outlook address book, transferred to the criminals' server
One positive note is that when trying to contact one of the attackers' servers an answer is obtained containing "X-Sinkhole: Malware sinkhole", meaning that the stolen data will not reach the criminals — this domain, which is used by Emotet version 2, is no longer controlled by the authors of the Trojan.
However, for version 3 things are different. This is how the report of the email_accounts_grabber module appears for Emotet version 3:
Report containing data about the user's email accounts
It is clear that the server answers "200 OK". This means that the criminals have successfully received the data.Stand and Deliver!
Information about the data for injection into the page that is received by Emotet after unpacking appears as follows:
Decrypted data on the web-injects of Emotet version 2
Decrypted data in the web-injects of Emotet version 3
The significant difference in data on injects between the two versions is as follows: Emotet version 3 is aimed at the clients of Swiss credit organizations. To date we have not seen scripts for the automatic stealing of money from clients' accounts in these credit organizations but we are certain that such scripts will be written soon.
Although individual fragments of HTML code in the decrypted packet can be read easily, understanding the rules for use of the web-injects from the deciphered data is difficult. Below, in JSON format, several web-inject rules are given for one target — the site of a German bank (Emotet version 2).
The web-inject rules for the site of a German bank (Emotet version 2)
The use of this web-inject leads to the creation of a new element of type 'div', which will have the size of the whole visible page, and to the addition of a new script in the HTML document. In the example given the script is loaded from the address hxxps://*******.eu/birten/luck.php?lnk=js&id=44.
And an analogous view of several inject rules for a new target — the site of a large Austrian bank (Emotet version 3).
The web-inject rules for the site of an Austrian bank (Emotet version 3)
It is clear that the configuration file with the web-injects has a classic structure, using fields conventionally called data_before, data_after and data_inject.
It should be noted that the address of the host on which the file luck.php (for version 2) and a_00.php (for version 3) is located is changed frequently. The rest of the address of the script is constant.
If the investigator tries the script directly, only an error message is received. However, in a real attack when the line
is added to the real bank page, the script loads successfully.
This happens because the criminals' server checks the "Referer" field of the header of the HTTP request and sends the script only if the request came from a page of one of the banks attacked by Emotet.
Having supplied the necessary Referrer one can easily obtain the script code.
At Kaspersky Lab we obtained scripts designed for injection into the pages of the attacked banks.
Table 1. Targets of Emotet version 2, types of attacks and the identification numbers of scripts loaded for carrying out these attacks.
Table 2. Targets of Emotet version 3, types of attacks and the identification numbers of scripts loaded for carrying out these attacks.
In one of the scripts of Emotet version 2 that was used to attack a German bank the comments contain the following line:
Artifact from the script for an attack on a German bank (Emotet version 2)
Clearly the script developers speak Russian.Getting round two-factor authentication
The main purpose of the scripts looked at above is to carry out the illicit transfer of money from the user's account. However the bot cannot independently get round the system of two-factor authentication (Chip TAN or SMS TAN), it needs the user's help. To mislead the potential victim, social engineering techniques are used: the message injected into the webpage using the script informs the user that the site is introducing a new security system and normal operations cannot be continued until the user has tested it in the demo-regime.
False message about new security system
This is followed by a request to enter real data from the Chip TAN or SMS TAN to carry out a "test transfer":
And finally - congratulations that the task has been completed successfully:
In fact, instead of a test transfer the malicious script carries out a real transfer of money from the victim's account to the account of a nominated person — the so-called "drop", and the user themselves confirms this transfer using the Chip TAN or SMS TAN.
Details of the accounts for the transfer of the stolen money are not initially indicated in the script, but are received from the command server of the criminals using a special request. In reply the command server returns a line with information about the "drop" for each specific transaction. In the comments in one script we found the following line:
Clearly the criminals tested this script with a transfer of 1500.9 EUR to a test account.
In addition, this script contained the following information about the drop:
In the corresponding script in Emotet version 3, designed to attack the same bank, we also found information on the drop, but this time another one:
Let's compare the fields JSON __DropParam and the fields in the legitimate form from a demo-access to the online system of the attacked bank.
Online banking form for transfer of money within Germany or in the SEPA zone
Table 3. Relationship between the drop data and the fields in the form for transfer of money and explanations of these fieldsName of fields in the __DropParam JSON Name of corresponding field in the form Translation Field contents name Empfängername Name of recipient Real name of drop who will receive the stolen money ibanorkonto IBAN/Konto-Nr. International bank account number/ account number Account number, international or local, to which money will be transferred bicorblz BIC/BLZ BIC or BLZ code International bank identification code or identification code used by German and Austrian banks (Bankleitzahl) description Verwendungszweck Purpose Purpose of payment amount Betrag Amount Transferred amount
The JSON __DropParam fields correspond to the fields in the form.
In this way the bot receives all the necessary information about the drop from its server and draws up a transfer to it, and the misled user confirms the transfer using the Chip TAN or SMS TAN and waves goodbye to their money.Conclusion
The Emotet Trojan is a highly automated and developing, territorially-targeted bank threat. Its small size, the dispersal methods used and the modular architecture, all make Emotet a very effective weapon for the cyber-criminal.
The #Emotet #Trojan is a highly automated and developing, territorially-targeted bank threatTweet
However this banking Trojan doesn't incorporate conceptually new technology and so the use of a modern anti-virus program can provide an effective defense against the threat.
Furthermore, the Trojan cannot function effectively without the participation of the user — the Emotet creators have actively used social engineering techniques to achieve their criminal ends.
And so the alertness and technical awareness of the user, together with the use of a modern anti-virus program can provide reliable protection against not only Emotet but other` new banking threats working in a similar way.Some MD5 hashes
Emotet version 2:
Emotet version 3:
The author would like to express his thanks to Vladimir Kuskov, Oleg Kupreev and Yury Namestnikov for their assistance in the preparation of this article.
In the middle of last year, my colleagues published a blogpost about a new generation of ransomware programs based on encryptor Trojans, and used the example of the Onion family (also known as CTB-Locker) to analyze how these programs work.
Last autumn, we discovered the first sample of an interesting new encryptor, TorLocker (this is the original name given by the creator); later on, TorLocker was used to launch an attack on Japanese users. When it was discovered on 24 October, 2014, the proactive components in Kaspersky Lab's products already detected this piece of malware; later on, it was assigned the verdict 'Trojan-Ransom.Win32.Scraper'.
Trojan-Ransom.Win32.Scraper encrypts the victim's documents and demands a ransom ($300 or greater) to decrypt themTweet
All the TorLocker samples that we have obtained belong to one of two versions: 1.0.1 (in English) or 2.0 (in English and Japanese.) There are only slight differences between them: 1) in the method employed to obfuscate code, and 2) in the sources used for additional modules: in the first version, the additional modules are extracted from the data section, while in the second version, they are downloaded from the Internet (from file hosting services or from compromised sites). Also in the second version, some strings were relocated from the data section into the code section, and dangling (redundant, not used) bytes emerged. The file encryption algorithm is the same in both versions.Common features and peculiarities of this malware family
Our analysis has shown that Trojan-Ransom.Win32.Scraper was presumably written in assembler, which is unusual for this type of malware. The Trojan uses the Tor network to contact its "owners" – something that is apparently becoming a norm for the new generation of ransomware – and the proxy server polipo. This piece of malware often lands on users' computers via the Andromeda botnet.
Trojan-Ransom.Win32.Scraper encrypts the victim's documents and demands a ransom ($300 or greater) to decrypt them. If the malware gets deleted by a security product after the files are encrypted, the Trojan installs bright red wallpaper on the Desktop, containing a link to its executable file. Thus, users have a chance to re-install the Trojan and report to its owners that they have paid the ransom: to do so, users need to enter payment details in a dedicated TorLocker window. This data will be sent to the C&C server which will either reply with a private RSA key or notify that there was no payment.
This typical representative of the Scraper family is packed with UPX. The data section is additionally encrypted with AES with a 256-bit key. In the code section, between the assembler instructions, there are a large number of redundant bytes that are not used in any way.
The redundant bytes in the encryptor's body
The method of submitting string arguments to functions is just as unusual. The strings are located directly in the code section; in order to submit a string as an argument to a function, the pointer to that string is placed into the stack by way of calling (using the 'call' instruction) the instruction following the string. As a result, the return address (which is identical to the pointer to the string) is placed into the stack:
Handling string constants as arguments to functionsOperating principles
Once launched, the Trojan starts by decrypting its data section with a 256-bit AES key. The first 4 bytes of this key are used as a sample ID, added to the end of the encrypted files. Then the Trojan is copied to a temporary folder, and a registry key for that copy's autorun is created in the following registry section:[HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Run]
Next the Trojan creates several threads to do the following:
- Search for and terminate the taskmgr.exe, regedit.exe, procexp.exe, procexp64.exe processes.
- Delete all system recovery points.
- Encrypt the user's office documents, video and audio files, images, archives, databases, backup copies, virtual machines encryption keys, certificates and other files on all hard and network drives, except files located in the folders %windir%, %temp%. The names and extensions of encrypted files remain unchanged.
Here is the complete list of file extensions that are encrypted:
.3gp .7z .accdb .ai .aiff .arw .avi .backup .bay .bin .blend .cdr .cer .cr2 .crt .crw .dat .dbf .dcr .der .dit .dng .doc .docm .docx .dwg .dxf .dxg .edb .eps .erf .flac .gif .hdd .indd .jpe .jpg .jpeg .kdc .kwm .log .m2ts .m4p .mdb .mdf .mef .mkv .mov .mp3 .mp4 .mpg .mpeg .mrw .ndf .nef .nrw .nvram .odb .odm .odp .ods .odt .ogg .orf .p12 .p7b .p7c .pdd .pdf .pef .pem .pfx .pif .png .ppt .pptm .pptx .psd .pst .ptx .pwm .qcow .qcow2 .qed .r3d .raf .rar .raw .rtf .rvt .rw2 .rwl .sav .sql .srf .srw .stm .txt .vbox .vdi .vhd .vhdx .vmdk .vmsd .vmx .vmxf .vob .wav .wb2 .wma .wmv .wpd .wps .xlk .xls .xlsb .xlsm .xlsx .zip
- Extract a BMP image, save it to a temporary folder and then set it as desktop wallpaper:
- Download tor.exe and polipo.exe, the files required to communicate with C&C servers, from the links specified in the Trojan's configuration (in the case of TorLocker 2.0) or extract them from the data section (in case of TorLocker 1.0). Then tor.exe is launched with the following arguments:
tor.exe -SOCKSPort 9150 -AvoidDiskWrites 1 -ExcludeSingleHopRelays 0 -FascistFirewall 1 -DirReqStatistics 0
polipo.exe is launched in the following configuration:127.0.0.1:57223 proxyPort = 57223 socksParentProxy = 127.0.0.1:9150 socksProxyType = socks5
- Create a GUI window demanding that the victim pays the creators of Trojan-Ransom.Win32.Scraper and display the window in the top left corner of the screen. It supports payment via BitCoin, UKash and PaySafeCard.
To encourage the user to pay the ransom to the Trojan's owners faster, the Trojan threatens to delete the private key required to decrypt the files if the user fails to send the money within a certain time period. In reality, the RSA keys are not deleted. They are associated with the malware sample rather than with a specific user, so the same RSA key is used for several users at the same time.
- The IP address of the victim computer is determined using www.iplocation.net, www.seuip.com.br, whatismyipaddress.com, or checkip.dyndns.org.
- Establish a connection to the C&C server in the onion domain via the proxy server polipo 127.0.0.1:57223. If the victim user has paid the ransom to the extorters, then, after contacting the C&C server and sending the information about the client (the selected RSA key, the number of encrypted files, the client's IP address and ID, the selected method of payment and the number of the bank card), the Trojan then receives the private RSA key with which to decrypt the files – in this case, a file decryption thread is created. Otherwise, a message is sent that the payment has not been effected yet. In each sample of Trojan-Ransom.Win32.Scraper?, a few dozens C&C domain names are hardcoded; they are not updated and may lead to the same C&C server.
When launching, Trojan-Ransom.Win32.Scraper chooses one of the 128 public RSA keys hardcoded in it, depending on the victim computer's name and the serial number of the logical drive. The number (n) of the public RSA key is calculated as following:n = (VolumeSerialNumber * strlen(ComputerName)) mod 128,
where strlen(ComputerName) is the length of the computer's name, and VolumeSerialNumber is the serial number of the logical drive on which Winsow is installed.
Each sample contains its own set of public keys.
The user's files are encrypted with AES-256 with a randomly generated one-time key; an individual encryption key is created for each file. Then, a 512-byte service section is added to the end of each file, which consists of 32 bytes of padding, 4 bytes of the Trojan's identifier, and 476 bytes of the employed AES key encrypted with RSA-2048.
If the file size is greater than 512 MB + 1 byte, then of the first 512 MB of the file get encrypted. The encrypted data is written on top of the original, non-encrypted data; no new file is created, and the old file is not deleted.
The Structure of an encrypted file
The Trojan does not need Internet access to encrypt the files.Packing
In order to obstruct the analysis, some of the detected samples of Trojan-Ransom.Win32.Scraper were additionally packed with the KazyLoader and KazyRootkit protectors along with UPX.
KazyLoader is a two-stage protector of executable files, written in .NET Framework. The protected executable is encrypted with AES, and then placed into the protector's assets section as a color palette of a BMP image.
The image decryption module is encrypted by XORing with one byte, then divided into parts and also placed into the protector assets section in the form of strings LOADER0, LOADER1, … LOADER272.
The KazyRootkit protector is also written in .NET Framework and has a feature that can conceal processes in the Task Manager (taskmgr.exe) and conceal registry keys in the Registry Editor (regedit.exe) by deleting strings from ListView GUI elements with the help of WinAPI. Depending on its configuration, the protector may shut down without unpacking the file embedded in it, if it detects any of Sandboxie, Wireshark, WPE PRO or a code emulator.
Although Scraper (TorLocker) encrypts all files with AES-256 + RSA-2048, in 70%+ cases they can be decryptedTweet
The file to be protected is encrypted by XORing with a certain key, and then injected into the protector's process. A large array of random bytes is stored in the protector's overlay.Partnership program
Trojan-Ransom.Win32.Scraper's builder (i.e. the program with which to create new samples of the Trojan with specified configuration) is distributed via a partnership program and sold for a few bitcoins. We found two posts about selling the builder for TorLocker 2.0 in the 'Evolution' (now taken down) underground online store:
The published screenshot of the builder suggests that the cybercriminal can change some of the encryptor's settings, as follows:
- Allow or block the launch of Task Manager or Process Explorer after infection;
- Allow or block the use of payment systems like BitCoin, PaySafeCard and Ukash to pay the ransom;
- Allow or block the removal of Windows recovery points;
- Modify the links from which to download tor.exe and polipo.exe; modify the names of these files after they are downloaded.
A screenshot of the builder's window
On the underground e-store's website, there are 11 reviews of the vendor of the Trojan-Ransom.Win32.Scraper builder, posted between 8 May 2014 and 17 January 2015.
By way of advertisement, news links are published about successful attacks performed using Trojan-Ransom.Win32.Scraper.
A brief description of TorLocker's operating principles and a comparison with CryptoLocker is also provided.Decryption
At the decryption stage, when the ransom payment is received, Trojan-Ransom.Win32.Scraper contacts the cybercriminals' C&C servers via the Tor network and the polipo proxy server, to receive a private RSA key. With this key, the Trojan decrypts the AES key for each encrypted file, and then decrypts the files.
Although Trojan-Ransom.Win32.Scraper encrypts all files with AES-256 + RSA-2048, in 70%+ cases they can be decrypted because of the errors made during the implementation of cryptography algorithms. To restore the original files, Kaspersky Lab has developed the ScraperDecryptor utility, which can be downloaded from Kaspersky Lab's technical support website.
Kaspersky Lab and INTERPOL recently presented research on how blockchain-based cryptocurrencies could be abused through the pollution of public decentralized databases with arbitrary data. During our presentation at the BlackHat Asia conference in Singapore, we demonstrated the proof-of-concept using the Bitcoin network, but it's important to understand that any cryptocurrency that relies on blockchain technology can be abused in this way.
Blockchain-based cryptocurrencies could be abused through the pollution of p2p databases with arbitrary dataTweet
Some believe that security researchers, especially those from the anti-malware industry, generally only publish threat reports after the discovery of a threat in the wild. However, this is not always true. Our current research focuses on potential future threats that could be prevented before cryptocurrencies are fully adopted and standardized. While we generally support the idea of blockchain-based innovations, we think that, as part of the security community, it is our duty to help developers make such technologies fit-for-purpose and sustainable.
Blockchainware, short for blockchain-based software, stores some of its executable code in the decentralized databases of cryptocurrency transactions. It is based on the idea of establishing a connection to the P2P networks of cryptocurrency enthusiasts, fetching information from transaction records and running it as code. Depending on the payload fetched from the network, it can be either benign or malicious.
The proof-of-concept code we demonstrated was a benign piece of softwareTweet
To ensure the accurate interpretation of our research, we would like to point out that in the anti-malware industry, there is a clear definition of what constitutes malware, and there are extremely strict policies in place that forbid any attempts to create or distribute malware. The proof-of-concept code we demonstrated was a benign piece of software that opened the Notepad application after getting a confirmation from the user.
So, what exactly did we demonstrate at BlackHat Asia? See for yourself at: https://www.youtube.com/watch?v=FNsqXHbeMco
As we pointed out during our presentation, possible solutions can be introduced at different layers. From the perspective of a company developing endpoint security solutions, we don't believe it's too much trouble to blacklist applications that load unpredictable external payload from a P2P network.
We believe that the value of solution development lies in its neutrality and decentralized decision-makingTweet
However, from the perspective of the cryptocurrency network, it's still an open question. We are not the experts in this field, and are therefore not best placed to propose effective solutions. We also don't want to promote any specific solution as we believe that the value of solution development (as in the case of Bitcoin) lies in its neutrality and decentralized decision-making.
That's why we suggest this is a project for the cryptocurrency community.
We don't promote any specific solution. We suggest this is a project for the cryptocurrency communityTweet
As a starting point for opening a discussion in the community, we suggest looking for an opportunity to implement a network consensus/negotiation algorithm that will sustain the clean state of the blockchain.
It's getting dark outside and our favorite mail client beeps with excitement for a new missive in our inbox, something interesting perhaps? A rapid glimpse at the contents of the message should indicate that a malicious campaign will play the starring role in what follows. An included attachment reveals itself as a malicious document with password-protected embedded macros. Moreover, a quick analysis of the file shows that it's dropping an executable payload to the system, which further piques our interest in this devious sample:
After opening the file, and only once the victim has been lured into enabling macros, a seemingly innocuous Word document is shown.
File metadata betrays the developer's rush in crafting this file, using the Russian language letters "фыв" to fill the tags section:
"фыв" corresponds to the "asd" letter combination on Latin keyboards so often used as mindless filler.Delving into the code
The second stage malicious script containing the instructions is downloaded from a public entry hosted on Pastebin in base64 encoding mode.
The full instruction set is 101 lines long and at the time of writing it counts with more than 5k reads. So this seems like a reliable indicator of the number of potential infections by this malware.
It is important to mention that upon discovery of the initial malicious document, Virustotal showed a null detection rate (however, the executable payload itself was detected by Kaspersky as Trojan-Ransom.Win32.Foreign.mdst)
The decoded script looks like this:
The decoded base64 payload downloaded from Pastebin fetches a file that includes several tokens to be used by the beckoning VBS script. Each token represents a section of the code that needs to be called in a specific order to achieve infection. The sections are named using a generic convention such as 'text20', 'text21', 'stext1', etc. Using the 'Tort' function implemented in the VBS script module, the instructions are deobfuscated and then outputted for execution.
The payload Trojan-Ransom.Win32.Foreign.mdst connects to an onion-based domain via the Tor2Web serviceTweet
In the case of the ' ' section, we can find a PowerShell script being called using the '-noexit' option, which according to Microsoft's Technet documentation is commonly used when running scripts via the command prompt (cmd.exe) so as to avoid exiting after execution. It's worth mentioning the second parameter, which sets the execution policy to bypass mode. Interestingly, by using a simple command line option this malicious creation is able to bypass the PowerShell execution policy configured in the system.
The file set for execution by PowerShell is also set by the original VBS script. A simple yet annoying obfuscation is in charge of getting the final string to be passed as a parameter.
As per the instructions above, the 'currentFile' variable will be replaced by the value of Chr(34) or a quotation mark, and the value of the variables PH2, FL2 and another static text value. Both PH2 and FL2 variables are set at the beginning of the execution of the script, FL2 being the random text used to name several files inside a temporary location set by PH2.
Even though the mechanism is not very complex, we can see that the malware writers took any measures available to slow down analysis and hide the real purpose of their code, even if by virtue of being a script it should be human readable.
We already reported the abusive Pastebin URL.Payload
The payload is a binary PE file (self-extracting archive or SFX) named "file.exe". Upon execution, "file.exe" is copied to "C:\Windows\System32\WinSrv32.exe" and deleted from its original calling location. Persistence in the infected system is obtained via a registry key written in the following branch "HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Run".
This payload connects to an onion-based domain via the Tor2Web service.
The mention of a hostname refers to the front-facing side of the um6fsdil5ecma5kf.onion domain that serves as a C2 of the payload malware.Detection names for malware 239d4f67692a5883574e3c496d88979c logmein_coupon.doc Trojan-Downloader.MsWord.Agent.hz 41d605b3981f330bd893b2dfd6e1d890 file.exe Trojan-Ransom.Win32.Foreign.mdst