Here are a few things you can do to defend against Emotet:
Block macros from running in Word files from the Internet. I can’t say this enough, if you are going to pick only one or two of these strategies to implement, do this one. A Group Policy Object (GPO) can be created to block macros from running in Word files from the Internet. Here is a great article that explains the capability microsoft.com. Emotet may start using other delivery methods such as Excel or PDFs but for now this pays big dividends. After implementing this policy, look at implementing the same thing across other Office apps.
All documents sent within your tenant and on OneDrive are considered trusted and will be allowed to run. Word documents that contain a macro that are downloaded from the internet or from external email will be blocked at run time unless there is an exception.
Exceptions can be created for the location the macro enabled Word document comes from. An easy way to cover most of your apps or business processes would be to put in an exception for your domain, for example contoso.local. Once you locate the download path, or url, you can put this into a GPO under Office Trusted Locations and the macros will run when opened. I’m familiar with an environment that has around 60,000 users who blocked Word macros and only 1 application/business process had issues, which only affected around 100 people.
Another way to get around the macro block is to save the Word document locally, close the document, reopen the document, then run the macro. At that point the document is considered trusted because it came from your machine. Most users don’t know about this but they do have the ability, which is why I recommend all 3 options.
Block Emotet URLs
Follow @Cryptolaemus1 on Twitter for new Emotet urls as they come out. You can feed these URLs into your IPS/Proxy/NGFW/EDR/etc as a block list. If you block the URLs before the macro runs, when it does the URL will be blocked, so Emotet will not download. This is a great way to get ahead of any users who might have slipped through the above option, or if that seemed too aggressive. If you do implement this, realize you may have to block the domain instead of the URL, unless you are doing SSL inspection or running on the host. This option should be automated if at all possible, search google for options.
Implement Botnet C2 Block List
After running quite a few samples there was one block list that seemed to pick up more activity than the rest, the Botnet C2 IP Blocklist by the Feodo Tracker. This was and has been implemented as a block list in a large enterprise for quite sometime without issue. If you would like to detect or prevent known C2 IPs for Emotet, TrickBot, and Dridex, add this list to your IPS/Proxy/NGFW/EDR/etc.
Implementing the 3 options above pay huge dividends, especially number 1. As well as doing those, I recommend monitoring PowerShell on endpoints and using an EDR product and/or Sysmon. Emotet moves quickly and can be easily seen going from a macro to an executable, running on the system via a new service to TrickBot running via a scheduled task in minutes. Having Sysmon and/or EDR visibility makes a world of difference. I recommend implementing this rule from Sigma into your Sysmon/EDR. I also recommend implementing application whitelisting in detection mode and then moving to enforcement mode over some period of time.
Thanks for reading.