Emotet is currently one of the prevalent threats on the Internet. The former banking trojan is now known to steal passwords and to drop other malware like Dridex on its infected machines. We recently found Emotet spreading Zeus Panda, which presented us with an opportunity to link some of our research on Emotet with our analysis of ZeuS Panda. The Zeus Panda sample used in this wave is rolled out through Emotet in german-speaking countries and targets online banking users in Germany and Austria.
The Emotet C2 server drops additional malware to infected system. Whether a system receives such a package seems to be based on the geographical location of the infected system in question. After the additional malware is downloaded from the C2 server, it is written to a file in %ALLUSERSPROFILE% (C:\ProgramData in recent Windows versions) with a random name of 4 to 19 characters length and the file extension “.exe”. Emotet is capable of executing this binary in two different ways, either of which is chosen by the C2 server. The first mode executes the malware in the same context that Emotet is running in, the second mode executes the malware in the context of the currently logged-on user.
As stated above, the current wave downloads and executes the well-known ZeuS Panda banking trojan. To know which banking sites it should attack and how to modify the site’s content, the trojan needs so-called webinjects. From the URL masks of the webinjects this sample uses, we can tell that it currently targets online banking customers in Germany and Austria. All injects write a single script reference into the targeted websites. When the targeted site is loaded, the browser loads the referenced script, which is then executed in the context of the banking website. The only difference between the webinjects is the last number in the URL of the script source. This number seems to define the targeted website, which allows the server to deliver a target-specific script. The script actually downloaded is obfuscated by a simple string encryption. The actual script is part of an Automated Transfer System (ATS) which tries to persuade the user into transferring money to an account the attacker specifies.
The above screenshots show an exemplary representation on the modification of the banking websites. They show two different attack scenarios: The first script tries to trick the user into performing an transaction in the guise of a security check. The attackers “inform” the customer of newly installed security measures on the banking website, coercing the user to complete a training using a demo account, before they are able to access their account again. During this training, a real transaction is made in the background to an account that the attacker specifies. The phrasing in the text is lousy and should raise suspicion with most customers.
The second script tries to persuade the user that an erroneous transfer was made to their account. It suggests to go to a bank branch or make the return transfer online. Additionally, the script blocks access to the banking account until the return transfer has been completed. The phrasing in the text is better than in the first script and may not raise suspicion at first glance.
The first script resembles word by word the webinject Kaspersky identified during their analysis of Emotet in 2015. At this time Emotet contained its own banking trojan capability and delivered the webinjects directly into the browser. As ZeuS Panda uses the same webinject format as the old Emotet, we can speculate about the reasons:
The webinject is acquired from the same creator
The group behind Emotet has dropped developing their own banking trojan and acquires such trojans from other malware authors
The group behind Emotet developed multiple banking trojans for its own use and for sale
It seems Emotet is not only used to sell distribution of malware, but also used by its owners. It is also possible that the group behind Emotet uses the slim downloader as an entry point for targeted attacks. In this case the group can spread Emotet worldwide and distribute specific malware to each target. As the real malicious payload is only downloaded after some time and only to specific targets, analysts can not directly draw conclusions on the real intention of an infection.
The original German blog post can be found on the G DATA Blog.
Emotet has been known as a trojan for years. Former versions focused on attacking online banking users, however the current Emotet was transformed into a downloader and information stealer. The first reports of this new variant were published by CERT Polska in April 2017. Since then, Emotet has been spreading through spam phishing mails containing a link to a Microsoft Word document that acts as dropper for the Emotet binary.
Recently, CERT-Bund again warned about the spam mails which spread Emotet. The sender address of these emails is spoofed to appear as a sender known to the recipient. This strengthens the trust in the mail and increases the probability that the recipient opens the attachment or link without further consideration.
For this to work, the entities spreading Emotet need to have at least superficial knowledge of the social network a target interacts with via email. Acting opportunistically Emotet delivers a specific module to infected systems to harvest all emails in Microsoft Outlook accounts of the current user, allowing it to extract the relations between sender and receiver.
To obtain the information from Outlook, the module takes advantage of the standardized interface MAPI. The picture above shows the loading of the MAPI-DLL and the retrieval of the needed functions. Utilizing this interface, the module iterates through all Outlook profiles it can access on the computer. It extracts all E-Mail-Account Names and E-Mail-Addresses from each profile. Afterwards it searches for emails recursively in each folder in the profile. From each mail found it extracts the sender (displayed name and mail address) and all recipients (displayed names and mail addresses) inclusive the recipients in the CC- and BCC-fields and saves them in relation to each other. The picture below shows the extracted fields from the emails. In case a field only contains a reference to an address book entry, the module extracts the name and email address from the address book. In this process only the mail header is evaluated, the content of the mails is not analyzed.
After the Emotet module has searched all profiles, folders, and emails, it writes the data it has retrieved in a temporary file in the directory %PROGRAMDATA%. The email addresses are sorted descending by how often they occur. Each address is extended with all contacts, that are in relation to it. However, two cases are distinguished:
if the referenced contact is the sender of the mail, it is extended with all recipients
if the referenced contact is the recipient of the mail, it is only extended with the sender
Example (Mailbox of A):
Mail 1: A sends to B and C
Mail 2: D sends to A
Mail 3: C sends to A , D, and E
A is referenced three times and therefore is placed on top of the list. A has a relation to B and C through mail 1, thus B and C get connected with A. Mail 2 shows a connection from D to A, thus D gets connected with A too. The relation from C to A in mail 3 is ignored, because it is already captured in mail 1 (A→C). Mail 3 contains the additional relations C→D and C→E. As no relations between C↔D and C↔E are already in the list, the contacts D and E get assigned to the contact C and are appended to the list.
The complete list, which gets transferred to the attacker, looks like this:
Afterwards the module encrypts the file, transfers it to the attacker and removes it from disk.
This allows the attacker to get a condensed but comprehensive overview of the social network graph behind a victims email communications. With such a list, an attacker has knowledge of the relation between persons and can send spam mails with suitable sender header without great afford. Additionally, an attacker learns relations between contacts whose computers are not yet infected.
To deliver the spam mails to the suitable recipients, the attacker needs valid E-Mail accounts. For this task, they use an additional module that is able to extract the credentials from mail programs and transfer them to the attackers. To extract the credentials from all common mail programs, such as Microsoft Outlook, Mozilla Thunderbird, and Windows Mail, this module utilizes an integrated copy of the application Mail PassViewfrom the company NirSoft. It writes this information to a temporary file, which is then encrypted and transfered to the attacker. Once transfered the temporary file is deleted.
On Wednesday, Feb. 22. 2017, a collective of 20 journalists from eleven countries published their recherches on the European security industry. The article, Security for Sale, published at The Correspondent, mostly seems to revolve around the question of how the funding several players in the field received from Horizon 2020 (H2020) and FP7 framework programmes are put to use for the European people. H2020 is the European Commission’s current funding initiative for research and innovation. Here is the commission’s own explanation.
Simplified, the authors of Security for Sale conclude that the benefit of funding security research for the Europe as a whole is limited, but that the funding works pretty well as hidden subsidies for the industry itself. Their wording is more lenient than mine, but nevertheless I feel that the picture the authors draw is incomplete and I’d like to add another perspective. I can only assume that the data for this article stems from the Secure Societies line of funding, as its core topics are emphasized in the article and some of the articles it links to refer to that – the article does regrettably not contain any straightforward references to its sources. And in my opinion, the Secure Societies line of funding does indeed sometimes yields research results that are scary to everyone who did not answer the question of ‘how do we want to live?’ with ‘I liked the setting depicted in Minority Report quite a bit, but it’s missing the effectiveness of Judge Dredd’.
The authors describe the landscape in the security sector roughly as 1) the big players, where kinetic and digital technology converge, 2) research organizations, 3) universities, and 4) small and medium enterprises (SMEs). Our sector, of Ze Great Cybers, primarily hides in 4) and to some extent increasingly in 1). The article does not explicitly touch the field of information security and neither do many calls in the Secure Societies context, however, most of the projects need to touch the digital domain at some point or other, making it clear that a division of information security and all the other potential flavors of security is merely artificial, given our current state of technology. As the authors observe, this is also reflected by the upcoming funding opportunities:
“similar programs are being set up for cybersecurity and military research”
The EU and some of it’s member states are late to the game and I’m aware that not everybody hacking at computers likes the notion that InfoSec and defense converge. I also dislike the idea and I somehow liked the Internet better when it was still a lot emptier, or as Halvar Flake once put it:
Sometimes I look at the internet and think: "Mommy, mommy, they bulldozed my playground and built a … mall … on it."
However, I came to enjoy civilization and as most people, I rely on the critical infrastructures that make our societies tick. I’ve been leading incident response assignments in hospitals more than once in the last year and as a human, who may suddenly require the services of a hospital at some point or another, I am very grateful for the effort and dedication my colleagues and the clients’ staff put into resolving the respective incidents. If this means I’m working in defense now, then I still dislike the notion, but I see that the work is necessary and also that we need to think more on the European scale when we want to protect the integrity of our societies. Packets only stop at borders of oppressive societies and that shouldn’t be us.
Now let’s have a look at where the EU’s security research funds go to, according to the article. The authors state
“Companies received by far the most money. That’s not particularly surprising; these same companies were the ones influencing funding policy.”
and illustrate it with the following figure:
Figure 1: Security research funding distribution. Illustration by The Correspondent.
In 2015, I was directly responsible for four H2020 grant applications and consulted on several other applications for nationally or regionally managed funding opportunities. Security in its various flavors is a tiny part of the picture. I’m happy to state that we had an above the average success rate. The illustration in the article struck me as familiar: to me, Figure 1 simply shows a typical distribution of funding within the majority of grant applications I’ve worked on. So it is hardly surprising that the global distribution of funding within technology sector of the programme looks very similar. There is nothing much sinister to that.
Larger corporations do have more opportunities to influence policy, as they can afford the time/resources to lobby. But the main reason for the distribution is salaries on the one hand and grant policy on the other. An engineer working at a large corporation will be more expensive by factor 1.2 to 2.3 than a PhD student, depending on country and the respective corporation. A factor of ~1.9, as in the figure, does not look unreasonable, given that the figure accounts for accumulated costs, not just personnel and that it is more likely that a corporation or a research institute will take the effort of building a demonstrator or pilot installations of a technology, as universities regrettably tend to lack monetization strategies for research results.
Government entities, as the next in line, tend to have very limited personnel resources for research projects and do not have a lot of wiggle room when in comes to contributions. With a funding scope that aims at technological advances, funding for advisories is often politically limited, and rightly so. As the figures are very much aggregated, I can only assume that the complete sum also contains Coordination and Support Actions (CSAs), which are rather limited funding schemes, financially speaking, that aim at connecting related projects and generally at the systematization of knowledge to avoid arriving at one insight at twice of thrice the funding. This work is sometimes done by entities that could classify as advisories. ‘Other’ can be translated to network and dissemination partners, or dedicated project management (which makes a lot of sense, H2020 projects can be large in terms of the number of partners).
Now let’s not talk militarizing corporations enriching themselves, as the article’s authors suggest, let’s talk research funding effectiveness. I my conversations with the granting side of research funding, it is a constant pain that there is a significant amount of research projects being funded that do not amount to a product. I have seen quite a few projects where I would judge without hesitation that the project was a WoMBaT (i.e., Waste of Money, Brains, and Time) and did primarily serve to compensate for the lack of public funding towards universities.
But that is only a small part of the picture. Another part is that there is a very expensive zone between ‘things you can publish’ and ‘things you can actually use’. Simplifying, technological progress has a tendency to increase complexity. To specify their expectations regarding the results of a funding measure, the European Commission adopted NASA’s Technology Readiness Levels (TRL). In the rather broad field of engineering, we often see the requirement for a validation under lab conditions (TRL 4), to the extent of a working prototype under field conditions (TRL 7), depending on the class of funding action. The funding of a given project often ends at that point.
Using my terminology from above, in the best case you then have something you can publish and/or show off, i.e., an interesting approach that has been shown to be feasible. Between that and monetization are the roughly two to seven years you’ll often need in engineering to go from a prototype to a product. And strictly speaking, research funding ends here, because research ends here. There are almost no publicly funded actions that will allow you to go towards product development, although piloting of a technology in the field can be funded (TRL 9). Nevertheless, either a company is now able to fund the continued development towards a product, or not. This is still a limited view, as I don’t need a new product to monetize research results. It is just as desirable to to improve an existing set of products and services, based on new research results. It is, however, by far not as visible.
Now why more so much funding for the big players? Research grants tends to have a bias towards those applicants, who were able to successfully complete a project, presented impressively in the past and are generally held in good standing. Sounds familiar? Yep,sounds like selecting talks for Black Hat or any other non-academic security conference, where the process is single-blind and the committee needs to judge based only on an abstract, not a full paper with a proper evaluation section and extensive related work. If the data is relatively poor, judgment needs to rely on the applicants reputation and previous work to some extend. And in comparison to a well-backed research paper, grant applications are in their nature always speculative, although very much more detailed than the abstract of a conference submission. If one knew how something was done in the first place, there’d be no need to call it research and there’d be no reason for a grant. The important point is not to fail, if one wants to continue receiving grants (cf. bias, above).
And that still does not fully account for the observation that big players are doing very well in grant applications. A H2020 application is a lot of work, it’s often a hundred pages just for sections 1 to 3, which can easily amount to 100 person days for the coordinator until everything is properly polished. The acceptance rate for Research and Innovation Actions can be as low as 6%. Academic Tier-1 conferences are relaxed in comparison. A small company may simply be unable to compete, economically, i.e., it cannot accept the realistic risk of putting a lot of effort into naught. It’s not as hard in other types of actions, but the risk is still significant and acceptance rates have been getting worse, not better.
“Our investigation reveals that EU security policy emphasizes technology: a high-tech solution is being sought for a societal problem.”
From an outside position I feel that I’m unable to judge the intention and the mindset of the various individuals responsible for the actual wording of the H2020 calls. The persons from this context I’ve met in the past did, however, not leave an impression of exceptional naivety. I genuinely believe that it is in the best interest of European countries and the EU to fund security research, without denying that there may be recipients of funds with a questionable ethical standard. As Europeans, we need to address these issues. I do not want to live in a militarized society and I don’t believe in solving societal problems purely through technology. However, I see a significant amount of opportunities, where usable, efficient technology can enable solutions for societal problems. Given my socialization, I may have a bias towards the security spectrum of research, but that said, I see quite a few things that can and should be done to positively impact the security of our societies. In a changing political climate, Europe needs to step up its security game, also and especially in the digital domain.
And now excuse me, I need to continue that research grant proposal. I’m not doing that for kicks and neither in pure self-interest.
The above screenshots show an exemplary representation on the modification of the banking websites. They show two different attack scenarios: The first script tries to trick the user into performing an transaction in the guise of a security check. The attackers “inform” the customer of newly installed security measures on the banking website, coercing the user to complete a training using a demo account, before they are able to access their account again. During this training, a real transaction is made in the background to an account that the attacker specifies. The phrasing in the text is lousy and should raise suspicion with most customers.
cyber.wtf 
You must be logged in to post a comment.