In the first technical blog post from the Security Team, we're going to take a look at the latest wave of Emotet from a specific angle: the downloader document (or maldoc).
Distributed as an attachment via malspam, the operators tend to play it fairly safely with the range of lures they employ in emails - however they are still fairly advanced when compared to other large scale campaigns. Over the past week we've observed a fairly even spread of generic templates (e.g. shipping, invoices, scanned documents) and reply-to messages, with more effort seemingly being made to appear more geographically relevant. Messages almost always leverage the names of legitimate organisations and employees from the same region. In the case of reply-to messages, email exfiltrated in past (or current) compromise is responded to via another compromised account with a standard request to open the attachment - though it's not uncommon to encounter messages that only have a signature.The latest document template, dubbed "Red Dawn", was first seen on 26th August NZT. It was at about this time that we also saw the volume of Emotet mail hitting NZ customers significantly ramp up. Emotet consists of three botnets known as Epoch 1, 2 and 3. In the most recent wave, we have only observed NZ targeted by Epoch 1 and 2. While there are no notable differences in documents between the 3, email templates can vary depending on which botnet they come from and post-compromise behavior also differs.
As seen above, the document requests for editing and content to be enabled to permit the macro to execute. Upon execution, the Document_load() function is invoked, which calls a function in a custom form.
At first glance the function appears to be rather complex, however after following the code it becomes apparent that klEP6Sq and duFdpjP83 do absolutely nothing other than fill space. After each pairing of these variable declarations are commands that serve as the functional portion of the script (highlighted with breakpoints). For example, here an obfuscated string is declared as the variable that begins with "Jcu" which is then passed to the deobfuscation function (more on that in a moment). This is used to define the Win32 Process object that will later be used to launch PowerShell.
Similar to the above, another function takes the value of the Control Tip for a tab on the form and passes it to the same deobfuscation function. It is the output of this function that forms the PowerShell command that retrieves and executes the Emotet payload.
The deobfuscation function turns out to be fairly basic:
- Takes the input string and saves it as a variable.
- Splits the string into an array, defining a series of alphanumeric characters and parentheses as the separator.
- Re-joins the output of the array to form the output of the function.
While basic, doing this by hand would be time consuming, so let's automate it with Python. olevba is used to extract the ControlTip text, from which the separator string is determined:
The deobfuscated string is of the format "powersheLL -e <base64 blob>". We only want the blob, so that's pulled off:
Naturally, the base64 is decoded and presents what looks a little more like a PowerShell script:
Obfuscation is removed, leaving a clean string that URLs can be extracted from:
The same script works just fine for other recent samples, too:
It's a commonly observed mistake for analysts to throw Emotet maldocs into sandboxes and assume that the first URL that gets requested is the only one for the document, where there should always be 5 or 7. Where one request fails, the next URL from the list will be requested.
As has been illustrated, with a little work you can develop safer, faster and reusable analytical methods. While there are methods also known for extracting the full URL set through dynamic analysis (and the same works for discovering the C2 set of the payload), static analysis is always going to be the safer approach as you're not having to touch adversary infrastructure. While the above method is only valid so long as the script used to generate the macros doesn't change, it still serves as a reliable template for an approach and requires little work to adapt to changing conditions.
To keep up to date with Emotet developments, we recommend following @Cryptolaemus1 on Twitter. Abuse.ch also provide an excellent feed of Emotet indicators that can be ingested in a variety of formats:
All IndeSIEM customers benefit from these detections via integration with LogRhythm. We will also be continuing frequent testing of samples to ensure IndeEDR customers have full coverage.
Those with an ANY.RUN account can download the sample described in this post here.
If you'd like to find out more about how Inde can help detect these security threats, you can contact us here.