Thank you for joining us for another week of Triage Thursday updates. The focus today is on some new functionality around the handling of Microsoft Office files, including automated decryption and better XLM macro parsing. We also of course have a bunch of family detection additions and updates to introduce, so let’s dive straight in!
- Added support for decryption of Office files, and improvements to our emulator for XLM macros
- Added detections for HermeticWiper and related payloads
- Updated detections for AgentTesla to cover some recent samples
- Updated detections for Jupyter stealer to support new string encryption
- Minor tweaks for Prometheus’s ransomnote
As always if you find any problems with the Triage platform or the detections in it, please do let us know. Community input is a vital part of tracking and keeping up to date with the rapidly evolving malware landscape and is extremely helpful in making these updates possible. You can reach us directly through the website, on Twitter, or using the Feedback option on an analysis report page.
Not signed up yet? Head over to tria.ge to register for a free account!
Office File Updates
We’re always looking for ways to improve and add to our detection capabilities beyond the standard signatures and configuration extractors that form the bulk of Triage. Over recent weeks we have been working on some improvements to the way we handle various Office files to improve both our static and behavioural analysis of these, and to make sure we can pull as much information from them as possible.
There are 2 main updates we want to talk about briefly today, and we hope to have more news for you on this front in the future.
1. Decryption of password-protected Office files
As you’ll almost certainly be aware, Office software includes its own encryption method for files to allow users to password protect their documents from within these applications. For obvious reasons these cause problems when running in an automated environment, so can often be exploited as an anti-sandbox technique malicious files as well as being present in many non-malicious documents and worksheets which users may want to scan.
Previously if you wanted these files to run they would have to be decrypted before submission to Triage. To simplify this process and better support automated pipelines we have now added support for their decryption to the platform directly. For now this is mainly a framework for future additions in this regard rather than a complete solution, but it opens the doors for us to add some new approaches to handle these and similar files. The main difference you will see currently is just that some additional documents will now be able to run within Triage - for example any samples using the well known VelvetSweatshop default password in Excel can now be handled fully automatically.
Among other things in future updates we will be adding frontend support for defining specific passwords for this at submission time, as well as more variations for automated decryption.
2. XLM emulator updates
Back in 2020 we added some functionality to Triage which enabled us to do detailed static analysis of Office files containing XLM macros. You can find detailed blogposts about that capability here: part 1 and part 2. The tl;dr is that we implemented tooling - including a custom emulator - which can dump, parse and in most cases deobfuscate XLM code present in worksheets at the static analysis phase. This enables us to provide a clear printout of these scripts and associated IoCs, as well as flagging up unusual requirements like specific macro triggers which may pose an issue in an automated behavioural environment.
However as with most things in the cyber space, 18 months is a long time and we’ve increasingly been aware that our system had some limitations which needed addressing. As such we have been revisiting that the last few weeks and making changes and improvements to better support the new techniques being used in malicious XLM macros. The changes are, briefly, as follows:
- The emulator can now follow cross-sheet references, allowing us to support XLM macros which are spread across multiple worksheets of an Excel document.
- Triage can now take account of the data stored in the workbook section
definedNames, which can provide aliasing to cell references within formulas. This effectively allows us to bypass another layer of obfuscation where cells are referred to by defined strings instead of the standard row/column definitions. - Handling of nested branches within the scripts has been improved. This helps with processing some of the more complex scripts.
- The parser has been updated to understand a wider variety of formula notations, because as usual Office products can’t just stick with one format.
- The parser/emulator can now also take into account the
sharedStringTable, a data structure used for optimisation in Excel which stores some strings from the document.
The overall effect of these changes is to greatly improve our support for the wide range of maldoc-based attacks relying on XLM macros. Triage can now perform static dumping of almost all XLM documents we’ve seen on Triage, and as above over the coming weeks and months we will continue to build and expand on this to make it as robust as possible.
Note that Triage applies tags to XLM documents, so you can find example using the tag:xlm search parameter.
Hermetic Family
In the lead up to Russia’s invasion of Ukraine a wave of cyber attacks were carried out against Ukrainian digital infrastructure, especially that related to government institutions and major companies like banks. There have been many reports on these campaigns in the weeks since, but among the earliest was this ESET blogpost which broke down a number of different payloads which all seemed to be related:
- HermeticWiper: The ‘main’ payload seen, which as the name suggests is a destructive wiper which aims to effectively brick computer systems. It does this by using the Windows
CryptGenRandomAPI function to overwrite the following data on an infected machine with random bytes:- Master Boot Record (MBR)
- Master File Table (MFT)
$Bitmapand$LogFile, files used by NTFS file systems to store metadata aimed at helping with file recovery- Registry hive files
- Windows logs stored under
C:\Windows\System32\winevt\Logs
- HermeticRansom: A related ransomware seen targeting many of the same types of organisations from the same attacker infrastructure - for example, the wiper and ransomware both share the same code-signing certificate. It is written in Golang, and saw a much more limited distribution than HermeticWiper although they are clearly related.
- HermeticWizard: A loader and worm which just serves as the delivery mechanism for HermeticWiper. It can spread the infection across local networks via WMI and SMB. Each sample contains 3 encrypted PE files embedded within them: a copy of HermeticWiper, and 2 DLLs which provide the SMB and WMI spreading capabilities.
The names for these payloads come from the aforementioned code-signing certificate, which is registered to a Cypriot company called Hermetica Digital Ltd. According to the ESET report this certificate was not stolen, but instead likely obtained by impersonating the company to DigiCert. Although no attribution has been made based on the code itself, it is pretty clear from usage that these families are being deployed by Russian nation-state actors with significant resources behind them. Related to this is ESET’s assertion that many of the affected organisations had likely been compromised long in advance of the deployment of these payloads, based on facts like deployment via group policy configurations and PE compilation timestamps.
In addition to the Hermetic family described above, ESET and others have also observed an additional wiper being used against Ukrainian organisations at around the same time. This has been dubbed IsaacWiper, and although it shows no code similarity with HermeticWiper the method of its use strongly suggests a similar origin. Based on compilation timestamps it is slightly older and less complex, but still capable of being quite destructive. Due to the close similarity in function and usage we are currently including it as part of the same grouping for simplicity.
Much more detailed writeups for the above can be found in ESET’s blogpost, as well as in works from other companies over the last few weeks. We have been reviewing these as they have been made available, and have implemented various detections for the different payloads. We’ll be continuing to monitor news about them in the future and will update our support as necessary.
Analyses:
HermeticWiper
HermeticRansom
HermeticWizard
IsaacWiper
AgentTesla
AgentTesla probably doesn’t need too much introduction at this point. It has appeared on this blog quite a few times over the last couple of years, and is likely familiar to anyone doing malware analysis regularly. Very briefly, it is an infostealer which targets various bits of data held locally such as browser passwords, FTP and email credentials, cryptocurrency wallets, etc. Some versions use SMTP and/or FTP for data exfiltration.
The family was one of the earliest supported by Triage and in the time since we have made many updates to account for new versions, most recently to add support for the email_to field to our configuration extractor at the start of the year. Today we are revisiting the family to make some tweaks, including support for recent samples/versions observed on Triage and more general improvements to our dumping of SMTP credentials hardcoded into them.
Analyses:
Jupyter Stealer
Jupyter was first reported in late 2020 in a blogpost by Morphisec. It is a relatively straightforward infostealer which targets data stored by the common Chromium, Firefox, and Google Chrome browsers. It also includes the ability to open a remote backdoor into an infected system giving operators the option of manual intervention if desired.
The family makes significant use of MSI packages which pretend to be for legitimate programs, in many cases even installing a copy of the legitimate software as a decoy.
We added detections and a configuration extractor for the family in September 2021, but we have recently observed some samples appearing which encrypt their strings and prevent extraction. We have done some reverse engineering and updated our extractor to be able to handle this, using the available data to decrypt the configuration and present it as before. This has been deployed, and as usual we’ll keep an eye on the family to see if more changes are made.
Analyses:
Prometheus Ransomware
Prometheus was first observed in the wild in early 2021, and has been identified as a new variant of the Thanos ransomware family which appeared during 2020. Recently SentinelOne has reported that a new family, called Spook, has popped up which appears to be a derivative of Prometheus and has been active since around September 2021. Both Prometheus and now Spook appear to have had a decent amount of success at attacking organisations since they appeared last year.
We added support for the family in the middle of last year, but while looking into Spook we noticed a few samples of Prometheus itself which were not being properly handled by Triage - our ransomnote dumping was not making that data available as it should. We’ve reviewed these and made a couple of minor tweaks to ensure those are covered. The relevant samples are listed below.
Analyses: