Increase in cybercrime in the pre-Christmas season

Increase in cybercrime in the pre-Christmas season

New Infopaper gives tips on how to best protect your business

The year is coming to an end, and the earliest shoppers are thinking about what to give their loved ones for Christmas. Online stores and local businesses in turn are preparing for the high-volume, pre-Christmas business.

The last November weekend officially kicks off the season— with Black Friday and Cyber Monday. Many companies will offer special promotions for their customers on these days, in order to lure the deal hunters. But this season is not only extremely lucrative for companies, cybercriminals also look to collect a decent Christmas bonus. Again this year, the Hornetsecurity Security Lab is therefore preparing for a significant increase in cyberattacks on companies.

With the new paper “Cybercriminals in the run-up to Christmas – 5 tips on how to best protect your company”, the IT security experts provide helpful advice to ensure that the Christmas season does not spell trouble for businesses.

Bargain hunters watch out: Cybercriminals want to cash in

Since the advent of the coronavirus, it should be clear to everyone that cybercriminals like to leverage current events and hot news for their own purposes.

Black Friday, Cyber Monday and Christmas are also events that attract public attention. They lure with discounts and promotions and appeal to our inner bargain hunters. It should come as no surprise that phishing e-mails in the name of major brands such as Amazon are particularly common. Last year, the Hornetsecurity Security Lab observed an increase in phishing e-mails in the name of Amazon between November and December:

nicht autorisierte Nutzug von Amazon-Domains beim E-Mail-Versand

Companies are particularly vulnerable during the Christmas season

It can be assumed that companies in particular will not only have to prepare for an increase in phishing attacks via e-mail. After all, the repertoire of cybercriminals includes many more methods—such as DDoS attacks, where hackers use a flood of server requests to force the providers’ systems to its knees, which means some sales opportunities are lost.

In the following Infopaper, we explain the attacks that companies must increasingly expect and why they are becoming ever more dangerous.

Protect yourself now:

Email Conversation Thread Hijacking

Email Conversation Thread Hijacking

Summary

“You should only open email attachments and links from senders you know” is a common piece of advice when it comes to preventing email-based malware and phishing attacks. However, in this article we outline an attack technique called email conversation thread hijacking, which uses existing email conversations of its victims and thus trust relationships to spread to new victims. Against this attack the previous advice will not help. We explain how email conversation thread hijacking is used by attackers, and why it dramatically increases the likelihood for victims to open malicious links or malicious attachments.

 

Background

Malicious actors try to get victims to open malicious links or malicious attachments. To this end, they often mimic genuine emails, such as invoices. However, if a victim is not customer of a particular company or service they will likely not open invoices claiming to be from those companies or services, especially knowing that this is the most common scheme for malicious actors to lure victims into executing their malware. Malicious actors are thus also often using current events to spark an interest in victims to open their malicious links or malicious attachments. Examples of such events are Christmas, Black Friday, Halloween, Valentines Day, but also currently the SARS-CoV-2 pandemic. However, users are often also aware of these schemes and do not open any malicious links or malicious attachments, especially when they come out of the blue without any context.

Hence, more and more attackers are leveraging a technique called email conversation thread hijacking, also known as email reply chain attack or email thread hijacking. In this technique, an attacker uses existing email conversations of victims to spread to new victims. Previously attackers only used the email addresses listed in victims address books. Email conversation thread hijacking uses also victim’s past existing email conversation threads to spread to new victims. To this end, the attackers will reply to the conversations the victim has in his mailbox.

 

How does email conversation thread hijacking work?

An email thread hijacking attack begins when a first victim is compromised. Next, their emails and often email login credentials are stolen. The attackers will then reply to the victim’s emails with their malicious messages.

In the following example, the “From” field contains the victim’s email address. The “To” field contains the email address of the targeted user, with which the victim had an email conversation previously. The “Subject” contains the original subject of the email conversation but is prepended with a “Re: “. The quote below the message contains the entire email conversation the two parties had.

Email conversation thread hijacking example

Good attackers also adapt the reply language to that of the hijacked email conversation, e.g., the following example uses a German language reply:

Email conversation thread hijacking example

While in the previous examples the malicious reply email contained a malicious link, these emails can also use malicious attachments:

Email conversation thread hijacking example

 

How effective is email conversation thread hijacking?

To demonstrate how effective email conversation thread hijacking is, we recreated a real email exchange that we observed during a routine false-positive email inspection:

Email conversation thread hijacking example

In this example, the attackers compromised Joe Schmoe’s email account and replied to an email that Joe has previously received from Alice. They replied with a malicious link (OPEN THE DOCUMENT) and some generic text. Alice released the email from quarantine and tried to open the malicious link, but her browser saved her from getting infected. She subsequently replied to Joe’s compromised email account that she can’t open “the file” and asked if “the file” could be sent in a different format. The attackers then send Alice another malicious link. While we are certain the attackers hijacking a previous hijacked email conversation thread again was coincidence, this example clearly shows how effective email conversation thread hijacking can be.

Fortunately, no attacker tailors their reply emails to fit into the hijacked conversation (yet). However, since threat actors have highly automated email conversation thread hijacking attack tools, the chances that the hijacked conversation involves documents that are shared back and forth is high. And even if it does not, who wouldn’t open a document sent by a known contact within an existing email conversation?

 

Who uses email conversation thread hijacking?

The number of threat actors using email reply chain attacks keeps increasing. While first observed in May 2017 in a limited targeted spearphishing campaign, many commodity threat actors adopted the technique in 2018.

In 2019, also Emotet adopted email conversation thread hijacking. To this end, they added an email-stealing module. The module steals emails and login credentials from victims and sends them to Emotet’s C2 servers, which distribute them to the systems of other victims infected with Emotet’s spam module, where they are used in attacks against new victims. Recently, Emotet has enhanced its email reply hijacking technique by also stealing attachments from victims and placing its malicious attachment among stolen benign attachments in order for the email to appear even more legitimate.

QakBot is also frequently distributed via replies to existing email conversation threads. In 2020, the Valek malware started to be distributed via email thread hijacking, too.

Hornetsecurity has observed an increase in compromised accounts being used to send malicious emails. While some do not (yet) use email conversation thread hijacking and simply misuse victims’ email accounts to send emails, with access to victims’ email accounts it is trivial to perform email reply chain attacks. A threat actor simply has to reply to emails received by his victims. We are therefore certain that the trend towards email thread hijacking attacks will continue. Therfore, users can no longer rely on a known trusted sender when deciding whether it is safe to open attachments or links.

 

Conclusion and Countermeasure

The advice to only open email attachments and links from known senders is outdated. With email conversation thread hijacking, even commodity threat actors can automate highly sophisticated and effective spearphishing emails. Often victims are not aware that they are compromised. In such cases it is important to inform victims that they are spreading malicious content via email so they can take measures against the compromise. Immediate actions should be to change the email login credentials. Secondary steps would be to determine how the attackers gained access to the email account in the first place to prevent such incidents in the future.

For humans it is very difficult, if not impossible, to spot email conversation threat hijacking because, by being sent from a legitimate but compromised account, the emails are – apart from the writing style – indistinguishable from real legitimate emails. However, email filters that inspect the attachments or links in emails can detect malicious content regardless.

Hornetsecurity’s Spam and Malware Protection, with the highest detection rates on the market, detects and quarantines threats regardless of whether they use email reply chain attacks or not. Also Hornetsecurity’s Advanced Threat Protection is not affected by email conversation thread hijacking and will inspect email contents regardless of whether it was sent from a compromised account or not. Hornetsecurity’s malware, phishing and ATP filters take precedence over sender allow lists. This way even if a allow-listed sender gets compromised and his email account is misused to send malicious emails, Hornetsecurity customers are protected.

Emotet Update increases Downloads

Emotet Update increases Downloads

Summary

The Hornetsecurity Security Lab observed a 1000 % increase in downloads of the Emotet loader. The increase in Emotet loader downloads is linked to a change in Emotet’s packer, which causes the loader to be less frequently detected by AV software. The data we have gathered suggests that the increase in Emotet loader downloads stems from the fact that it’s less frequently being detected. This makes security mechanisms to less likely to block its download URLs. Our data, however, also suggests that AV vendors are already closing the gap in detection, so the detection rates for the Emotet loader should increase, and the amount of downloads should decrease again. This analysis shows the impact of the changes made to the packer of the Emotet loader.

Background

The malware now commonly known as Emotet was first observed in 2014. Back then, it was a banking trojan stealing banking details and login credentials from its victims. Later, however, it pivoted to a malware-as-a-service (MaaS) operation providing malware distribution services to other cybercriminals.

We have already reported on Emotet multiple times in previous blogposts. The following timeline shows its recent developments:

Emotet event timeline

On 2020-08-18, changes to Emotet’s loader were observed. The Emotet loader is now packed with a different packer. Various researchers have observed that this packer change has led to a lower detection rate of the Emotet loader by AV software1. The unpacked loader has also received updates previously, but these have not caused any considerable impact on Emotet loader downloads. The changes performed on 2020-08-07 in order to fix a buffer overflow problem exploited by an Emotet “vaccine” called EmoCrash had no impact on the presented Emotet loader download statistics, since the “vaccine” only comes into effect after the Emotet loader has been downloaded.

Technical Analysis

We gathered download statistics from the Emotet download URLs by the methods outlined in our previous article about Emotet webshells2. For those that have not read our previous article, the PHP code Emotet uses to facilitate its downloads returns a JSON output stating the number of downloads of the Emotet payloads on that particular domain. We did not change our acquisition or analysis methods from the previous article to ensure our results are directly comparable and any observed changes are caused by the distribution operation of Emotet and not a collection of analysis artifacts caused by methodological changes.

There are two types of Emotet download URLs: those pointing to an Emotet maldoc and those pointing to the Emotet loader. The Emotet maldocs, which can be sent by email, contain download URLs. A VBA macro code uses them to download the Emotet loader, the actual Emotet malware that installs itself on the victim’s computer.

In our previous analysis, the share of download URLs pointing to the Emotet loader was of 15 %. Now, on 2020-08-19, its share is of 20 %. This is due to the fact that Emotet maldocs now use 6 or sometimes even 7 Emoter loader download URLs instead of the “classic” 5, as can be seen from this decoded PowerShell command issued by a recently released Emotet maldoc:

Emotet using 6 download URLs

However, the number of downloads of the Emotet loader we have gathered from hidden statistic pages on compromised websites has increased more than 5 %.

The Emotet download statistics from 2020-07-29 indicated that the Emotet loader was downloaded at a rate of around 2500 times per hour in average. The following plot shows the ratio between loader and maldoc downloads as well as their volume for 2020-07-29:

Old Emotet download statistics

Two days after the packer change, on 2020-08-19, the Emotet download statistics indicate that the Emotet loader was downloaded at a rate of around 25000 times per hour on average, a 1000 % increase. The following plot shows the ratio between Emotet loader and Emotet maldoc downloads as well as their volume for 2020-08-19:

New Emotet download statistics

We attribute this increase to the recent changes to the Emotet packer. The new packer is not detected very well by AV vendors yet. So, most of the new download URLs after the Emotet packer change were not detected by any vendors listed on VirusTotal:

Emotet loader download URL undetected on VirusTotal

Emotet loader download URL undetected on VirusTotal

While VirusTotal results do not represent the true dynamic detection of AV software of Emotet, the lower detection rates, especially when analyzing the download URLs for the Emotet loader, clearly suggest that the updates to the Emotet packer has indeed decreased the detection likelihood. Since many of the Emotet loader download URLs used to be flagged as malicious immediately, many security products were likely to block downloads by potential victims, thus leading to very few downloads of the Emotet loader overall.

On 2020-08-20, the Emotet loader downloads dropped to 7500 per hour, which constitutes a decrease of 70 % compared to 2020-08-19:

Download statistics with improved Emotet detection

This is likely because AV vendors are now starting to improve the detection of the new Emotet packer. At least, VirusTotal detections of new Emotet loader download URLs have started to be flagged again by AV vendors:

Emotet loader download URL detected again on VirusTotal

This further supports our hypothesis that the increase in Emotet loader downloads was caused by the new packer and, to a lesser extent, by the increase of Emotet loader download URLs inside the Emotet maldocs.

Conclusion and Countermeasure

Our analysis has shown the impact caused by the changes to the Emotet packer. We observed a 1000 % increase in Emotet loader downloads which was closely related to the detections of the Emotet loader download URLs by AV vendors.

To protect against Emotet the US CERT recommends to “implement filters at the email gateway to filter out emails with known malspam indicators”3.

Hornetsecurity’s Spam and Malware Protection, with the highest detection rates on the market, is not impacted by the updates to the Emotet packer (as the packer is never sent directly via emails) and will thus continue to block all Emotet malspam indicators, such as macro documents used for infection as well as known Emotet download URLs. Hornetsecurity’s Advanced Threat Protection extends this protection by also detecting still unknown malicious links by dynamically downloading and executing the potentially malicious content in a monitored and sandboxed environment. Thus, even in the event the Emotet loader changes is accompanied by a change in delivery tactics, Hornetsecurity will be prepared.

In addition to blocking the incoming Emotet emails, defenders should use the publicly available information by the Cryptolaemus team, a voluntary group of IT security people banding together to fight Emotet. They provide new information daily on their website4. There you can obtain the latest C2 IP list for finding and/or blocking C2 traffic. For real-time updates, you can follow their Twitter account5.

References

The Hornetsecurity Security Lab publishes new figures: about 70% of all emails are unwanted

The Hornetsecurity Security Lab publishes new figures: about 70% of all emails are unwanted

Around 300 billion e-mails are sent every day – the number of e-mails sent and received for private and business purposes is forecast to rise to 361.6 billion by 2024. However, not all e-mails that end up in users’ inboxes are wanted, and unwanted e-mails not only contain questionable advertising, but often also harmful attachments and links.

The experts of the Hornetsecurity Security Labs have analyzed how many e-mails are actually wanted by users and what dangers can lurk in their inboxes based on the e-mails received in the system for the year 2020 and have come to interesting results: Only 28% of the e-mails could be classified as “clean”, i.e. harmless by the Hornetsecurity filters – thus more than 70% of all addressed e-mails were unwanted by the recipient.

Which emails are already blocked in advance?

A total of 67% of incoming e-mails are blocked in advance by Hornetsecurity’s filter mechanisms: this means that these e-mails have not even been classified as harmful or unwanted due to various factors. In June 2020, the Security Lab analyzed the reasons for blocking incoming emails. Below we take a look at the most important ones. 

In first place with almost 58%, are e-mails that could be classified as spam in advance using a real-time blackhole list.

In second place with 12%, are emails that try to use Hornetsecurity’s mail servers as open relay. Open relay is the process by which an email server delivers emails for which it is not responsible. For example, if example.com has an email server, it should only accept email for mustermann@example.com. An open relay server would also accept mail for other domains, such as @test.com. These open relays are often misused to send spam with fake sender addresses.

In 5.9% of the e-mails blocked by Hornetsecurity, no correct sender address could be found. This is important because cyber criminals try to hide their identity or pretend to be someone else. For example: In the case of mustermann@example.com, if the domain example.com does not exist, the email is blocked.

In 5.3% of blocked e-mails, harmful content was found. Malicious content includes attachments such as *.xls, *.doc, *.pdf that contain malware, but also links that lead to malicious or compromised web pages.

What threats are found in the emails that were not blocked in advance?

The proportion of spam, malware and other threats in the non-blocked emails is also interesting. For this evaluation, the security experts checked the total number of incoming emails minus the blocked emails.

About 10% of these analyzed e-mails were spam and about 3% were info mails. The Security Lab experts were also able to find malware in about 1% of all incoming e-mails, and just under 0.1% were even detected by Hornetsecury’s Advanced Threat Protection. These are attacks such as CEO fraud, spearphishing, or attacks that use new types of malware, which were only detected by the Hornetsecurity ATP Sandbox and not by classic filters. Conversely, this means that more than 10% of the e-mails that are not blocked in advance contain spam or attachments and content that are harmful to the user.

Although the majority of harmful e-mails can be blocked, companies should not yet sit back and relax. Cybercriminals are constantly finding new ways to send malicious emails to users and their attacks are still often successful.

The webshells powering Emotet

The webshells powering Emotet

Summary

The Hornetsecurity Security Lab presents details on the webshells behind the Emotet distribution operation, including insights into payload downloads and how from 2020-07-22 to 2020-07-24 Emotet payloads on Emotet download URLs were replaced with HTML code displaying GIFs. The analysis shows that the number of downloads of the malicious content behind the Emotet download URLs is significant and has been observed peaking at 50,000 downloads per hour. Highlighting that Emotet emails do get clicked. The analysis further shows that compromised websites are not just compromised once but multiple times by different actors and cleanup efforts by the website administrators are often insufficient leading to re-enabling of the malicious Emotet downloads.

Background

Emotet is one of the most prolific malspam actors. They distribute their malware via malspam emails with either a malicious document attachment containing VBA macros or download links to those malicious documents. These malicious documents will then download the Emotet loader from the Emotet download URLs. These downloads are hosted on compromised websites. To this end, the actors behind Emotet use webshell malware on the compromised websites. These webshells are used to place new payloads, either malicious documents distributed via malicious links in emails, or the Emotet loader, on the compromised websites. Because compromised websites get blacklisted or the Emotet malware gets cleaned the actors use up around 300 to 400 URLs a day.

Technical Analysis

In this analysis we take a look at the Emotet webshells.

S.A.P. webshell

If you have access to the filesystem of a website compromised by Emotet getting the webshell used by Emotet is very simple. However, with a bit of luck, relying on misconfigurations in the compromised websites, and relying on another actor in the webshell realm, everyone Emotet webshell samples can be obtained without access to the compromised webservers.

First, the Emotet webshells reside in the directory one level below the directory containing the Emotet download, i.e., either an Emotet maldoc, or the Emotet loader executable download. So if the Emotet download URL is https://www.example.com/wp-includes/LYnUiE/, the webshell will usually reside in https://www.example.com/wp-includes/. However, we also have seen webshells in other directories. Next, we can hope for misconfigurations in the compromised websites and hope the directory containing the webshell is an open directory, i.e., it will list the directory contents as in the following example:

Emotet open directory

In this example, import.php is the Emotet webshell and lpyc42 is the directory that will deliver the Emotet payload. Known filenames of Emotet webshells are user.php, common.php, import.php, update.php, link.php, license.php, menu.php, image.php, options.php, tools.php, core.php, edit.php, functions.php, config.php, and wp-list.php.

Obviously, access to the webshell is protected, i.e., when requesting the import.php file, the PHP code is executed by the webserver and only its output is served. However, on some servers we observed PHP files that had been renamed by adding an additional .suspected extension to the file.

Emotet open directory with renamed webshell (just ignore all the other webshells in that directory :D)

This renaming was actually most likely done by a different malware named Vigilante Malware Cleaner. Information about Vigilante Malware Cleaner was first discovered and documented by Bruce Ediger in 2019 [VigilanteMalwareCleaner]. Existence of this renaming dates back to at least 2015. The Vigilante Malware Cleaner malware seems to compromise already compromised websites, then searches existing PHP files for suspected malware, and disabling suspected malicious PHP scripts by appending .suspected to their filenames and thus excluding the files from the list of files the server will execute as PHP code. This will cause the server to serve the file contents, i.e., the PHP source code of the webshell, directly instead. Using this we can download the PHP code of the Emotet webshell. Before being able to access the webshell the code queries a parameter f_pp, which is used to decode the webshell:

Encoded Emotet webshell

This f_pp parameter functions as a password to the webshell. Via OSINT research we found that the encoded webshell is identical to one found and decoded by another researcher in January [EmotetWebshellSamples].

To illustrate to the reader what someone logging into the this webshell with the correct f_pp parameter would see, we ran the decoded PHP code on a test system:

Emotet S.A.P. v.2.1 webshell

The webshell identifies itself as S.A.P. webshell with version v.2.1. The webshell allows an attacker to search, upload, and download files. It allows to execute arbitrary commands. It further offers convenient tools to dump SQL databases from the server, perform network scans, and/or brute force passwords.

The fact that the decoding processes relies on the f_pp parameter as password and we found multiple instances of the identical encoded webshell code dating back to January strongly suggests that Emotet reuses passwords for their webshells.

GIF hijacking

Even though we do not have logs or other forensic artifacts of the systems in question, we, based on our previous outlined findings, agree with the opinion stated by other researchers that the recent incident in which Emotet downloads were replaced with HTML code displaying GIFs is a result of insufficient security of the Emotet webshells. This hypothesis is supported by the fact that Emotet seems to have changed their webshell on 2020-07-27 and the GIF hijacks stopped. But indications of new GIF hijackings emerged on 2020-07-31. This could be the time it took the GIF replacement actor to figure out the new password. However, new GIF hijackings are not wide spread, which could indicate whatever Emotet is doing to defend itself against the GIF hijackings is working. The used GIFs can be interpreted as a statement towards the actors behind Emotet that the actors behind the GIF replacements are still watching and determined to continue the disruption of the Emotet operation:

Emotet is being watched GIF

Emotet is being watched GIF

On later Emotet compromised websites we also multiple times found variations of the following webshell:

Possible new Emotet webshell

We are, however, not certain this is the new Emotet webshell, but would like to point out that the webshell realm is a very crowded space, e.g. we observed one webserver that had two GIF hijackings, two (presumably) by Vigilante Malware Cleaner to .suspected renamed webshells, as well as, as a new active Emotet download – in just one directory (other parts of the server contained even more webshells):

Emotet opendir with 2 GIF hijackings

This means the website was not once, or twice, but at least three times used as a download for Emotet (2020-07-23 and 2020-07-28). The website would likely still server Emotet payloads but luckily its bandwidth limit was exceeded.

Emotet download stopped working due to exceeded bandwidth limit

So there is a possibility that the actors placing the GIFs are gaining access via a vulnerability of the website itself, or are even affiliated with the Vigilante Malware Cleaner malware. But we are a email security provider and hence do not have enough visibility into the website compromise landscape to make any definit statements.

Download statistics

Talking about download quotas, there is a way to externally monitor Emotet payload download statistics. Emotet uses a PHP script to collect download statistics grouped by operating systems given in the downloader’s User-Agent string. These statistics are delivered as an JSON object in a subdirectory of the Emotet payload download directory named as $path , '/.' . sha1(basename($path)):

Emotet download stats

So the statistics for https://www.example.com/wp-includes/LYnUiE/ could be queried from https://www.example.com/wp-includes/LYnUiE/.a2dd7d055bb668528c29e16f789755fb3aae277b.

Going again by previously shared Emotet webshell code [EmotetWebshellSamples] the numbers correspond to Windows (4), Linux (3), Apple (2), Android (1) and unknown (0) operating systems found in the downloader’s User-Agent string:

Emotet statistic PHP code

We proceeded to scrape these statistics. The counters are reset every time the Emotet Tier 2 servers push updated maldocs and loader executables to the compromised websites via the webshells. Hence, when a new count was higher than a previous count, we took the difference as the number of downloads happening between scrapes. But in case the count is lower then a previous count, we assume the count was reset and take the new count as number of downloads since our last scrape. This way we also nullify stuck download statistics, i.e., download statistics that do not get reset anymore. We scraped with a frequency of 1 minute. Emotet updated the documents with a frequency of around 10 minutes. Because Emotet targets the Windows operating system we only consider the download statistics for the Windows operating system. For 12 hours of 2020-07-29 the obtained statistics of 739 Emotet download URLs (533 of which registered active downloads in the presented time frame) can be visualized as follows:

Emotet downloads on 2020-07-29

This is a stacked plot, i.e., each URLs download number is plotted individually but their total shows the cumulative number of all download URLs. Each different color represents a different Emotet download URL. These figures obviously include downloads by security researchers and automated security systems such as sandboxes. We also miss any downloads that happen between one of our scraping runs and Emotet resetting the download counter. However, the figures still give an interesting insight into Emotet downloads and hence the click rate of Emotet. In our observation the cumulative number of Emotet downloads peaked at 50,000 downloads per hour.

Separating the download URLs by their served payloads (based on MIME type analysis) we can see that most downloads are for the Emotet maldoc. The Emotet loader is downloaded far less often:

Emotet downloads on 2020-07-29

If we plot the download numbers according to time after the URL was first observed we see that each URL’s download numbers peak within the first hour the URL was first observed. At that time each observed Emotet URL got around 200 downloads per hour. However, URLs keep getting downloads even 12 hours after the URL was first observed. Hence, every download URL blocked or taken down is potentially one Emotet victim less, even if the blocking or take down happens 12 hours too late.

The following line plot illustrates individual URL download performance:

Emotet downloads aligned by time URL was first observed

Stacking download figures for URLs the falloff trend can clearly be observed. After 9 hours the number of downloads drops to 1/3 of the downloads observed right after the URL was newly observed:

Emotet downloads aligned by time URL was first observed as stacked plot

We think a proportion of the initial peak can be attributed to automated security systems scanning the Emotet malspam and thus downloading the Emotet maldocs from the Emotet download URLs. This is confirmed by again separating the data in URLs serving the Emotet maldocs and URLs serving the Emotet loader:

Emotet downloads aligned by time URL was first observed

The number of downloads of the Emotet loader has a slower rise to the peak then the downloads of the Emotet maldoc, supporting our hypothesis. Further, there is no steep falloff in Emotet loader downloads.

On average the Emotet loader was downloaded at a rate of around 1500 per hour, while the Emotet maldocs were downloaded at a rate of around 7500 per hour.

Failed cleanup attempts

During monitoring the Emotet download URLs more closely we also witnessed failed cleanup attempts multiple times. Often site administrators delete the directory containing the Emotet download. However, they miss cleaning all the webshells. The actors behind Emotet then simply regenerate the deleted files with their next payload update. We also observed Emotet using a previous compromised website again.

Other observed mistakes

Being such a large operation it is inevitable that the actors behind Emotet make mistakes. While allowing another actor to hijack their payload downloads is one mistake, other mistakes include (but are not limited to) messing up the replacement regular expression, so we could observe download URLs delivering Emotet maldocs with broken filenames, such as InvJP0732{:REGEX:.doc, INVOICE-Q84{:REGEX:.doc, invoice-UBO7631{:REGEX:.doc, etc. We are certain the {:REGEX: part should be {:REGEX:[0-9]{3,6} (or something like that), a special syntax used by the Emotet generation processes to expand the filename base on a random but character restrained pattern. These {:REGEX:[...] patterns have also previously leaked in attachment filenames and are part of Emotets automation process. Please note that depending on your Browser the : in the filenames may be replaced with _ because : is not a valid character on the Windows operating system. Monitoring the Emotet operation very closely reveals a lot of such mistakes overtime and the insights gained can be used to strengthen our own defenses against Emotet.

Conclusion and Countermeasure

As this analysis by the Hornetsecurity Security Lab shows Emotet is not just sent in large volume but its malicious content is also downloaded in significant large numbers.

On the network you should block known Emotet URLs. In case browsing to random websites is not an activity necessary to fulfill your business, you can block the domains and not just the specific URLs. This provides better protection because, as has been shown, Emotet and potentially other actors can misuse the compromised website again, either by regaining access via left behind webshells, or by reinfecting the website via the initial access vector, e.g., a WordPress vulnerability or weak password. The block should be kept even if the Emotet download is gone, as the site may still be compromised. It is highly likely that you will never actually need to visit any of these websites at all, thus keeping the websites blocked shouldn’t cause negativ effects.

Hornetsecurity’s Spam and Malware Protection, with the highest detection rates on the market, already detects and blocks Emotet emails based on known indicators. Hornetsecurity’s Advanced Threat Protection extends this protection by also detecting yet unknown threats.

 

References

Privacy Shield: The end of transatlantic data exchange?

Privacy Shield: The end of transatlantic data exchange?

+++ INFORMATION +++

Currently, it is recommended that affected data flows be identified and switched to alternatives that meet the required level of protection under GDPR. We would therefore like to assure you that Hornetsecurity’s cloud email security services are not affected by the invalidation of Privacy Shield and can continue to be used as usual.

+++

On 16.07.20 the European Court of Justice (ECJ) overturned the data protection framework between the USA and Europe. Although this does not immediately mean the end of data transfer between the two continents, it does have far-reaching consequences. Let’s take a quick look at it.

Privacy Shield – What does it contain?

The Data Agreement came into force at the beginning of 2016 as the successor to the Safe Harbour Agreement. The aim of the Privacy Shield, according to its creators, was to provide legal certainty not only for a higher level of protection for citizens, but also for European companies that exchange data with the USA. US companies would thus be obliged to store the data of EU citizens for only as long as it was used for the original purpose. Data protection experts criticised this agreement from the very beginning, as they suspected that it would not offer any significant changes compared to the previous safe harbour agreement.
For example, the Privacy Shield offered approaches for better data protection, but this was still far from reaching the European standard. In particular, US secret services were able to access data of EU citizens without any restrictions. This fact prompted the ECJ to declare the Privacy Shield invalid.

Out with the Privacy Shield – and now what?

Can data still flow between the USA and Europe? It is clear that the removal of the Privacy Shield agreement creates confusion. First of all, it is important to realize that a distinction must be made between private individuals and companies. Private individuals can still send private emails to the US or make a booking on a US website. The situation is different for companies.
Around 5,000 companies are directly affected by the ECJ’s decision, as they invoke the Privacy Shield when transferring data to the USA. These include companies such as Facebook, Microsoft and Amazon. In order to initially continue to ensure legal data exchange to the USA, companies can alternatively invoke the standard contract clauses that have been practicable to date. But here, too, the question is: Can these still be valid, even if they cannot exclude access by secret services?
German data protection experts, in particular, are beginning to talk about Europe’s digital independence. The Berlin data protection expert Maja Smoltczyk, for example, calls on those responsible for transferring personal data to the USA to switch to service providers in the EU in order to ensure an adequate level of data protection.
It can therefore be assumed that there will be no ‘go ahead’ in the data protection debate to overcome legal uncertainty.

What does this mean for Hornetsecurity customers?

In principle, Hornetsecurity provides its core service in Germany within secure data centers there. There is no data exchange with the USA and Hornetsecurity is therefore not directly affected by this decision.
All subcontractors in a third country commissioned by Hornetsecurity, who have named the Privacy Shield as the basis for data transmission, also have alternative legal bases, so that if one legal basis is no longer applicable, one of the other possibilities will take over. The two other variants for the transfer of data from the European Economic Area to other countries, especially the USA, are Binding Corporate Rules / binding internal data protection regulations and EU standard contractual clauses/EU standard contractual clauses. Our customers will find the exact information about our subcontractors in the Order Processing Agreement in Annex 3.

Perhaps also of interest to you