Tip: Measures against Emotet

Spam filters are sometimes easy to bypass, as I already mentioned here. a possible way are shown. It is usually difficult for users to recognize whether it is a valid and harmless email or whether all hell will break loose in the form of the Emotet malware with the next click.

In many environments, just a few clicks by a user may be enough to infect the entire network with malware. This is what happened, for example, with the Berlin Court of Appeal.

Currently, things have gotten even worse: Emotet is known to reload the malware Trickbot. Trickbot now has a module on board that enables it to transfer the Active Directory database "ntds.dit" to the attacker.

• TrickBot Now Steals Windows Active Directory Credentials

Emotet is usually the beginning of the horror for admins, sometimes very well crafted spam mails with reference to actual conversations and a fairly intelligent malware, which has a modular structure and is able to hijack a network in a variety of ways. Last but not least, the Ryuk malware encrypts data on servers and clients.

However, there are a few countermeasures that at least make it more difficult for Emotet, which I will summarize here as far as possible.

Deactivate Office macros

Office macros should be completely deactivated. This is best implemented using GPOs so that the user has no way of changing this again. Wolfgang Sommergut has described in detail here how macros can be deactivated via GPO:

• Restrict or block macros in Office 2016 / 2019 with group policies

Macros have long been considered a gateway for malware, so no exceptions should be made here. Only signed markos from your own company could still be allowed, but nothing more.

Block DOC files

One of the main distribution channels for Emotet is currently DOC (Word) files. Currently, the old Word format (.DOC) is used for distribution, but not the current DOCX format. It therefore makes sense to block all emails with a DOC file attached, or at least to place them in quarantine for manual checking. Blocking DOC files also sounds like a drastic measure, but you have to remember that DOCX was introduced with Word 2007, a good 13 years ago. So anyone who still sends DOC files today is already making themselves suspicious.

Some AntiSpam solutions offer the option of converting certain file formats first. For example, a DOC document could first be converted to PDF. Harmful markers are thus rendered harmless and the user receives a "harmless" PDF. If the user then still needs the original document, it can usually be retrieved from quarantine, of course only after careful checking.

Of course, all other executable files should also be blocked by the spam filter, even if they are in archives. The following applies to password-protected files in particular: Anything that cannot be scanned remains in quarantine or is blocked.

Mark external mails

More and more companies are labeling emails that have been received externally, especially in the case of spam emails sent via Emotet, which makes sense in my opinion. The recipient is shown that the mail is not an internal mail, but has been received from the Internet. This measure is easy to implement on Exchange servers and can help to sensitize users. A message could look something like this:

The warning is of course also included in the replies to a valid email. When replying to a valid email, the partner also sees this warning in the course of the email. The reactions here range from "Hey, they take IT security seriously" to "He doesn't trust me at all". A possible response to an inquiry to the sender could be: "Both, we don't trust emails and we take IT security seriously."

If anyone would like to implement this measure, the script can be downloaded here:

Sensitize users

Not every user is able to recognize dangerous e-mails, and in stressful situations many an admin has certainly clicked the wrong button. From the admin's point of view, it is easy to "blame the user" for not recognizing a dangerous email. However, the colleague from the finance department could just as easily berate the admin who did not immediately recognize a discrepancy on an invoice. Training and sensitization can help here. To get started, you can try the Google Phishing Quiz:

• Do you recognize phishing?

Internal training measures or a "safety newsletter" for employees can also be helpful.

Offer users the opportunity to report suspicious activity

A common problem in companies is that users are often not given the opportunity to report suspicious attachments or other anomalies and have them checked. All awareness-raising measures for users come to nothing if users do not feel that they are being taken seriously and have no easy way of reporting suspicious activity. An easy way must be created for users to obtain a quick and uncomplicated assessment of the situation. One possible solution could be, for example, a special mailbox to which users can report suspicious emails or activities.

This is particularly easy with Outlook QuickStep, for example:

The Quickstep forwards a mail as an attachment to a defined address (so the headers of the mail are retained). The suspicious mail is then first moved to the "Junk mail" folder. If it is a dangerous mail, the mail is already in good hands there; if it is a false alarm, the user can find the mail again directly in the folder.

Of course, mails to the mailbox must also be responded to quickly and the user must be given feedback. Now that the original mail is available, the rules of the spam filter can be adjusted if necessary. Suspicious attachments can be uploaded to VirusTotal for evaluation:

https://www.virustotal.com/gui/home/upload

In addition, the Cuckoo Sandbox to analyze the behavior. Cuckoo can be installed by the user or used online:

https://cuckoo.cert.ee/

Hyperlinks in e-mails

Hyperlinks in emails can hardly be prevented effectively. To prevent links in emails from being directly clickable, you could only allow emails in text format or convert emails in HTML format into text emails. However, users will very quickly rebel here; even I find text-only emails horrible. In text e-mails, however, links can no longer be clicked on, but have to be copied from the e-mail into the browser. Since the link is directly visible in text emails but cannot be clicked on, the malware email has to be pretty well made for the recipient to copy the link into the browser.

However, if HTML emails are displayed as text emails, almost all formatting is lost. It usually becomes quite difficult to read the emails and embedded images are displayed as attachments. This is very annoying, for example, if you frequently receive emails with images or screenshots, and if there are also images in the sender's signature, the emails are barely legible and the information can hardly be analyzed.

I would therefore not recommend displaying e-mails only as text e-mails, as this will only annoy users.

However, you can try to disarm the hyperlinks themselves. For example, some spam filters can rewrite links in emails, the idea being as follows:

The original link (e.g. https://www.frankysweb.de) in an email is replaced by the spam filter (e.g. https://spamfilter.frankysweb.de/linkid=123). The spam filter therefore maintains a list of original links and rewritten links. This helps, for example, if malware is only offered for download under the original link from the email after some delay. When the user clicks on the rewritten link, the spam filter has the opportunity to check the link again before the user is redirected to the original link. However, the spam filters seem to differ greatly in the way they work. Some spam filters rewrite the links, but then fail the second check (when the user clicks on the link). According to my small test, however, this is strongly product-dependent.

A more practical option is to block links to known malicious domains. Of course, you need to know under which domains malware is currently being distributed so that you can block them at the firewall, for example. It is even easier to prevent malicious domains from being resolved by the DNS server and thus allow malware links to simply go nowhere. The following are suitable for this purpose Pi-hole quite outstanding. Pi-hole is actually intended to block advertising domains, with an appropriate configuration and the RPN of, for example abuse.ch can also be used to block all kinds of known malware domains. Integration into an existing Windows network is extremely simple: the domain controller, which is usually the DNS server for the clients, can simply forward DNS queries to Pi-Hole. If a client then attempts to resolve a malicious domain, it will not be resolved by Pi-Hole:

Pi-hole even provides some nice statistics and does not necessarily have to run on a Raspberry Pi. A computer or VM with Linux also works perfectly:

For the sake of completeness, here is an example configuration with the abuse.ch URLhouse List:

Blocking (or "not resolving") malicious domains can therefore help to prevent an infection. Of course, all malicious domains will never be reached / listed here. But it is always better than nothing.

Proxies or firewalls that first scan downloads for viruses and malware are also helpful, but since malware downloads are also processed via encrypted connections (https), a system that is capable of SSL inspection must be used here (OPNSense only as an example, as it is open source). SSL inspection is not without risk, especially in companies, and should therefore be checked accordingly before use.

Secure Active Directory

There are a few quite simple measures to increase security in the Active Directory, I had already started to publish these in a series of articles:

• Active Directory: Simple measures for more security (Part 1)

There are already more parts, which can be found using the search function on this page. Further articles on this topic will follow. However, you can already start with the implementation now. In particular, the article on LAPS should be implemented for clients and servers:

• Simple measures for more safety in AD (Part 3): LAPS

Central log files / event logs

In the standard configuration, every server and every client saves its log files locally, so it is hardly possible to detect irregularities or even an infection of a computer based on the logs or Windows event logs. It is therefore advisable to send the log files to a central system and evaluate them there.

Without special log analysis software that is able to detect anomalies, it is of course very difficult to detect an infection on a client or server manually using the event logs. However, especially with regard to Emotet, there are a few important events that should definitely be monitored:

• Service install
  • New service on a client? A user should not be able to install a new service on a client, this event indicates an infection.
• Task Scheduler task creation and delete
  • New scheduled task on a client? This event also indicates an infection.
• A user was added or removed from the local Administrators security group.
  • If this event occurs on a client, something is definitely going wrong.

Here you can find more information on this topic (including how to access the logs):

• Use Windows Event Forwarding to help with intrusion detection

If you limit yourself to at least the three events mentioned above, you will notice suspicious behavior quite quickly. You then only need to think about how to be notified or alerted when the events occur.

Hardening clients and servers

The "Microsoft Security Compliance Toolkit" is available for Windows servers and clients. The toolkit contains ready-made group policies for Windows clients and Windows servers to harden the operating system. The security settings can simply be rolled out via GPO or integrated directly into an image for installation as a local policy.

However, not all guidelines are suitable for practical use, so the security baseline should be tested extensively. If necessary, individual settings can be adapted to your own requirements.

The templates can be downloaded here:

• Microsoft Security Compliance Toolkit 1.0

Open communication

Even if you don't like to admit it, open communication of a malware attack can help. Business partners should be informed, especially if the network has been infected by Emotet. Emotet is able to use the Outlook data to of an infected computer to send fairly genuine-looking spam mails to the e-mail addresses of business partners. So if your own computer has been infected, it is more than likely that a flood of spam will start being sent to your contacts under your own name. The mails are sent with fake display names, but refer to actual conversations. The e-mail addresses, the subject and a few lines of the conversation were captured from the Outlook profile of the infected computer.

As soon as an infection has been detected, it is therefore necessary to play with open cards. The business partners will receive SPAM mails in your name with Emotet in them, so it is only serious to warn the partners. Nobody benefits if the business partner is also infected. This way you can at least try to stop further spread.

Self-evident measures against Emotet

Of course, the following self-evident measures should not be missing:

• NO user is surfing or working with administrator authorizations
• Virus scanner and its signatures must be up to date
• Backups save lives
• Segmentation of the network and use of firewalls between the network segments
• The Windows Firewall is never deactivated, NEVER.
• Operating system and all other software must be up to date
• Windows UAC is set to "Always notify" mode on all clients and servers

In my view, these measures leave no room for discussion; the first point in particular is, as they say, without alternative. A separate account must always be used for administrative activities, and company administrators are not exempt from this rule.

Although the above measures cannot completely prevent infection with Emotet, they do at least make it more difficult.

I would be happy to include further measures here, suggestions can be left in the comments.

Current example

Today a fresh example slipped through the spam filter:

A ZIP is attached containing a VBS file which only 10 out of 60 virus scanners recognize as a virus:

The analysis with Cuckoo is more informative:

This is just a quick example.