For the first time ever, Cofense Intelligence™ recently observed a phishing campaign distributing the infamous Hermes ransomware. The low-volume campaign delivered .doc files, weaponized with heavily obfuscated macros. These macros reached out to an attacker-controlled server to download and execute a copy of Hermes.
This Hermes campaign bears many striking resemblances, as detailed below, to those observed distributing both GandCrab and Sigma. The correlations suggest the actors actively distributing the aforementioned ransomware may be branching out and testing other software, although we have no evidence beyond the observed correlations, to support this possibility.
Additionally, Hermes demonstrates some unique behaviors, such as not altering extensions of the files after they’re encrypted and storing both the victim-specific public and private keys on the infected machine. Finally, Hermes provides the victim with a very novel musical surprise, after its ransom note is opened.
The narrative used within this campaign is extremely similar to those used by the actors distributing both GandCrab and Sigma. Figures 1 and 2 detail the similarities in structure, language, and grammar.
Figure 1: An example message from the campaign distributing Hermes
Figure 2: An example message used to deliver Sigma Ransomware
Clear similarities can be observed between the two campaigns:
- The resume theme, albeit lacking the hallmark password protection, is highly favored by the Sigma and GandCrab-distributing actors.
- As addressed in a later section, the URL structure is also identical to the aforementioned actors: a plain IPv4 host with a single digit executable filename.
- The use and placement of exclamation marks, the filenames, and overall structure are also comparable.
However, two very clear divergences are the references to a password and the sheer size of the attached file – the Hermes campaign attachment is some 174% bigger than that which delivered Sigma.
Despite these discrepancies, the overall structure provides ostensible correlation between the campaigns. Figure 3 exposes the raw message; the MIME structure of these messages is also extremely consistent with those of previous ransomware campaigns – three MIME parts: plaintext, HTML and MSWord. The sole use of <br> elements in the HTML mimepart is identical to those observed in the aforementioned campaigns.
Figure 3: The raw content of a message
The attached file is a .docm file, although it is distributed with a .doc extension. This is typical of threat actors distributing files via email. The document contains three macros: two with arbitrary, nonsensical names; one with a coherent name but containing no code. The macro structure is detailed in Figure 4.
Figure 4: Macros extracted using officeparser.py
The macros are heavily obfuscated with junk instructions. Examples of the junk code can be observed in Figure 5.
Figure 5: Obfuscated Visual Basic code achieved by way of junk code injection
De-obfuscating such messy code is an extremely trivial, albeit laborious process. Such obfuscation exists for two reasons:
- To function as a ‘hashbuster’ – arbitrary changes to the macros modify the filehash.
- To slow down, or outright stymy, manual analysis.
By removing the junk instructions, clear execution flow emerges, as seen in Figure 6. Although the code would be non-functional if it were executed, it functions perfectly as pseudocode.
Figure 6: Two macros relieved of junk code
Once tidied, the code can be easily understood, despite the semantically null variable names: When the document opens, some properties from the second macro (G9b4Gjelvo.frm) are retrieved and Base64 decoded, before being XOR’d. The decoded strings are then passed into a function, again held in the second macro. By looking at the native functions that are called and the arguments that are passed to them, it’s easy to infer that the decoded strings are a URL, a filename [to be written to disk]. An interpretation of the function can be seen in Figure 7.
Figure 7: An interpretation of the key macro function
Detonating the sample confirms the supposition in revealing not only the URL, but also the filename. Figures 8 and 9 detail the download and execution of the payload.
Figure 8: The hostile macro retrieves its payload from hxxp://205[.]185[.]121[.]209/1[.]exe
Figure 9: The macro writes and executes the payload
Just as its namesake Greek deity was revered for prodigious speed, Hermes encrypts its victims’ files in as expeditious a manner as possible. The sample used in this campaign is packed with a Visual Basic packer yet has no observable anti-analysis techniques, which is somewhat surprising for modern code. The packer launches a copy of the executable, before decrypting and injecting code into the child process – after unpacking, file artifacts suggest it is written in C++.
After unpacking and passing control to the decrypted child process, Hermes first attempts to determine the regional location of the victim’s machine. It achieves this by simply querying the HKLM\SYSTEM\CONTROLSET001\CONTROL\NLS\LOCALE\InstallLanguage registry key. Although not directly observed in this iteration, other versions of Hermes have terminated execution when believed to be running on machines located in either Russian or certain other Eastern European countries. Hermes then proceeds to drop a copy of itself to the current user’s %temp% directory. It should be noted that during repeated analysis of the sample, a consistent filename of ‘svchosta.exe’ was used.
Hermes enumerates the files not only on the primary disk (%SYSTEMDRIVE%), but on any storage media it finds attached to the victim machine – this includes network drives and USB devices, but omits attached CD-ROM devices. Adhering to the Ransomware playbook, Hermes then encrypts all files on disk, provided they meet two criteria:
- The file is not inside a ‘whitelisted’ directory
- The file extension is in its targeted scope
Unlike certain, perhaps more advanced, ransomware, Hermes does not appear to alter its encryption behavior based on file size – some ransomware will omit files above a certain size, whereas other will simply encrypt the first N bytes of a large file. Further, this iteration of Hermes does not append new file extensions to encrypted files; previous versions have used the extension ‘.hrm’. It is unclear as to why Hermes omits such a fundamental function.
Hermes encrypts files in what has become the standard fashion:
- A unique AES key is generated per file
- The file is encrypted with AES
- The AES key is encrypted with an RSA 2048 key
- A blob of data, including the AES key, is appended to the file
Hermes differs from most modern ransomware by storing both the Public and Private key files on the local file system, and never contacting a Command and Control server. These files are dropped to %userprofile%\public\PUBLIC and %userprofile%\public\UNIQUE_ID_DO_NOT_REMOVE. To ensure the integrity of the private half of the keypair left on the victim machine, Hermes comes shipped with the public half of an attacker-generated keypair. Hermes uses this public key to encrypt the ‘UNIQUE_ID_DO_NOT_REMOVE’ file, which simply contains the victim’s private key. Of course, this means the encrypted file can only be decrypted by the attacker-controlled private key.
If Hermes encrypts even a single file inside a directory, it will drop a ransom note named ‘DECRYPT_INFORMATION.html’ to that same directory. Naturally, this process results in potentially thousands of duplicate files dropped throughout the filesystem. Figure 10 shows a redacted ransom note. An interesting modification seen in this variant is the addition of a language selection navbar, providing decryption information in English (default), German, French, Italian, and Spanish. Although this change offers no conclusive evidence about which demographics may be targeted, the omission of such huge language centers such as Cyrillic or Han-like characters leaves much room for speculation about who is not being directly targeted.
Figure 10: The ransom note. Of interest are the inclusion of the language bar and the second payment address
The HTML of the document can be seen in Figures 11 and 12. Although far from a unique communication method, Hermes chooses to leverage encrypted email services, rather than TOR, to facilitate victim-attacker communications. The missing price and the nebulous statement “and other cryptocurrencies” suggests the attacker behind this campaign is expecting to negotiate and will likely tailor prices according to the victim’s position and stance.
Figure 11: Part of the ransom note. The language selection navbar and the if block show language options for the first part of the text
Figure 12: The main body text present in the note. Included are the email addresses, victim ID, and various languages.
Readers familiar with HTML may have noticed the absence of the closing ‘body’ and ‘html’ elements.
Figure 13 details the last section of the ransom note.
Figure 13: The ransom note includes an externally-hosted audio file
Inexplicably, Hermes embeds an audio file from a remote host into the ransom note. Although this kind of technique of embedding what appears to be an innocuous callout to a host for benign content is not new, it is an effective way for threat actors to track how frequently an object is accessed. However, this is no such scenario. Here the embedded file is a full-length version of Vivaldi’s Four Seasons: Spring.
While the victim is contemplating their response and enjoying the soothing concerto, Hermes launches a final assault against the victim’s machine. Most ransomware will attempt to disable and neuter the system’s Volume Shadow Copy service, thus preventing the restoration of files using native system functionality. In this regard, Hermes is no different, albeit with a few twists and turns.
Hermes drops a batch file to handle not only the necessary VSS (Volume Shadow Service) modifications, but also attempts to guess at the location of backup files, in order to delete them. Figure 14 shows the batch file in its entirety.
Figure 14: The batch file dropped and launched by Hermes
This batch file is a paradox of beautiful efficiency and untampered sloppiness. The first line of the script silently deletes all shadow copies available to vssadmin within the context of the current user. Lines 2 through 13 are significantly more intricate than they first appear. Line 2 reduces the size of the C: volume shadow to 401MB. This action has two consequences: it limits the amount of data available to System Restore (which is powered by volume shadows), and it effectively deletes all old restore points on C:, simultaneously disabling System Restore.
Line 3 reverses line 2, setting the size limitations on C: to ‘unbounded’, which removes any size limitations and allows volume shadows to grow, indefinitely. By reversing this process, the VSS and System Restore are again able to function fully. When subsequent automated backups (shadow copies) are taken, they will be of the encrypted files. Just two lines of code are needed to destroy current, historical, and future backups. The batch script will then repeat the process for storage devices D, E, F, G, and H; the script has no conditional checking and will run even if those devices are not mapped to the host.
Lines 15 to 20 are as haphazard as they are surprising. For each device ranging from C: through to H:, the batch file will attempt to delete the following files:
- Any file ending with an extension of:
- Any file within a folder named ‘backup’
Not only does this batch script make assumptions about the location and naming convention of the backup software/methodology being employed, it also details limited knowledge of the Windows subsystem. For example: it references both ‘<drive>:\Backup*.*’ and ‘<drive>:\backup*.*’, despite Windows being a case insensitive operating system.
Line 21 simply deletes the batch file itself – %0 is the syntax to reference the file being called from the command line, which in this case is windows.bat (itself).
Staying true to the God of mischief, Hermes has one more trick up its sleeve: its persistence flow. As part of its infection process, Hermes drops a tiny byte batch file (see Figure 15) to the Windows startup folder. The batch script simply executes the svchosta.exe binary dropped at the start of the execution process. An interesting caveat to this persistence mechanism is that it simply does not work on Windows 10 nor, presumably, Windows 8 (although this was not tested explicitly). The batch script is never written to the startup directory. Quite why this occurs is unclear at this time. If an infected Windows 7 machine reboots and the persistence mechanism is triggered, Hermes will initiate its entire encryption sequence again. It will not re-encrypt files that have already been handled, but it will encrypt any new files added to the system since the last encryption cycle. Persistence mechanisms for ransomware are extremely rare. Having the capacity to encrypt new files on system start up is utterly unique. This behavior also explains why it is necessary for the ransomware to keep a copy of the local key on disk and easily accessible.
Figure 15: The batch file dropped to the startup folder
Hermes operates mostly within the confines of the generalized ransomware MO, but diverges in some very unique, and sometimes confusing, ways. Despite the steps taken to avoid detection – heavy packing, absence of any network communications, and use of native commands and functions – Hermes can still be as easy to heuristically identify as most other ransomware.
The recently observed campaign once again reaffirms what we have come to know—we cannot grow too accustomed to TTPs associated with a specific malware family, as the malware can and often will evolve, become acquired by new threat actors, or become appropriated for new purposes. Changes in those TTPs can make it more difficult to identify malware campaigns. Thus, maintaining educational awareness of the evolving threat landscape, using verifiable threat intelligence to direct a dynamic defense strategy, and educating your users to identify different infection vectors, such as phishing, is critical.
To stay on top of emerging phishing and malware threats, sign up for free Cofense Threat Alerts.
Campaign Indicators of Compromise
All third-party trademarks referenced by Cofense whether in logo form, name form or product form, or otherwise, remain the property of their respective holders, and use of these trademarks in no way indicates any relationship between Cofense and the holders of the trademarks.