Ramsay: A cyber-espionage toolkit tailored for air-gapped networks

ESET researchers have discovered a previously unreported cyber-espionage framework that we named Ramsay and that is tailored for collection and exfiltration of sensitive documents and is capable of operating within air‑gapped networks.

We initially found an instance of Ramsay in VirusTotal. That sample was uploaded from Japan and led us to the discovery of further components and versions of the framework, along with substantial evidence to conclude that this framework is at a developmental stage, with its delivery vectors still undergoing fine-tuning.

The current visibility of targets is low; based on ESET’s telemetry, few victims have been discovered to date. We believe this scarcity of victims reinforces the hypothesis that this framework is under an ongoing development process, although the low visibility of victims could also be due to the nature of targeted systems being in air‑gapped networks.

Shared artifacts were found alongside the Retro backdoor. This malware has been associated with Darkhotel, a notorious APT group known to have conducted cyber-espionage operations since at least 2004, having targeted government entities in China and Japan in the past.

Attack vectors

Along with the discovery of the different instances of Ramsay, we found they were leveraged using a series of attack vectors. These are:

Figure 1. Overview of discovered Ramsay versions

Malicious documents dropping Ramsay version 1

This attack vector consists of malicious documents exploiting CVE-2017-0199 intended to drop an older version of Ramsay.  

This document delivers an initial Visual Basic Script, shown in the screenshot below as OfficeTemporary.sct, that will extract within the document’s body the Ramsay agent, masquerading as a JPG image by having a base64-encoded PE under a JPG header.

Table 1. OLE object layout contained within Ramsay version 1 RTF file as seen by oletools

We noticed that the specific Ramsay instance dropped by these documents showed low complexity in its implementation and lacked many of the more advanced features seen leveraged by later Ramsay versions.

Several instances of these same malicious documents were found uploaded to public sandbox engines, labeled as testing artifacts such as ‘access_test.docx’ or ‘Test.docx’ denoting an ongoing effort for trial of this specific attack vector.

Based on the low complexity of the Ramsay agent delivered, the threat actors may be embedding this specific instance within these malicious documents for evaluation purposes.

Decoy installer dropping Ramsay version 2.a

We found one instance uploaded to VirusTotal of Ramsay masquerading as a 7zip installer.

The reason we named this malware Ramsay was due to some of the strings contained in this binary, such as the following:

Figure 2. Strings containing "Ramsay"

This version of Ramsay shows a clear refinement of its evasion and persistence tactics along with the introduction of new features such as a Spreader component and a rootkit; the Spreader component is documented more thoroughly in this part of the Capabilities section.

Malicious documents dropping Ramsay version 2.b

This attack vector consists of the delivery of a different malicious document abusing  CVE-2017-11882. This document will drop a Ramsay Installer named lmsch.exe as shown in Table 2.

Table 2. OLE object layout contained within Ramsay version 2.b RTF file as seen by oletools

The Ramsay version leveraged by this document is a slightly modified version of Ramsay version 2.a, with the main difference of not leveraging the spreader component. The functionality of the remaining components is the same in regard to Ramsay version 2.a.

Client Execution of Infected Files

As previously mentioned, Ramsay Version 2.a delivers a Spreader component that will behave as a file infector, changing the structure of benign PE executable files held within removable and network shared drives in order to embed malicious Ramsay artifacts triggered on host file execution.

The Spreader is highly aggressive in its propagation mechanism and any PE executables residing in the targeted drives would be candidates for infection.

Based on compilation timestamps among the components of the various versions of Ramsay found, we can estimate the following development timeline of this framework:

Figure 3. Estimation of Ramsay’s development timeline

The analysis of the different compilation timestamps found across different components implies that this framework has been under development since late 2019, with the possibility of currently having two maintained versions tailored based on the configuration of different targets.

Persistence mechanisms

Based on its version, Ramsay implements various persistence mechanisms of different complexity. Some of these persistence mechanisms are the following:

• AppInit DLL registry key

The Windows operating system provides the functionality to allow custom DLLs to be loaded into the address space of almost all application processes via AppInit DLL registry key. This technique is not particularly complex; it is implemented in early Ramsay versions and is common in other malware families.

• Scheduled Task via COM API

Scheduled tasks enable administrators to run tasks or “jobs” at designated times rather than every time the system is booted or the user logs in. This feature can be implemented via the Windows COM API, which the first versions of Ramsay have tailored. Based on the high ratio of similarity with Carberp’s implementation, it's highly probable that Ramsay's implementation was adapted from Carberp's publicly available source code.

• Phantom DLL Hijacking

More mature versions of Ramsay denote an increase in complexity of its persistence techniques, which include a technique sometimes referred to as “Phantom DLL Hijacking”.

Phantom DLL Hijacking abuses the fact that many Windows applications use outdated dependencies not strictly necessary for the functionality of the application itself, allowing the possibility of leveraging malicious versions of these dependencies.

Two services will be targeted in order to enforce this technique. These are:

• WSearch (Windows Search) hijacking msfte.dll:

Figure 4. Hijacking of Microsoft Search Service msfte.dll

• MSDTC (Microsoft Distributed Transaction Coordinator) service hijacking an oracle dependency seen below as oci.dll:

Figure 5. Hijacking of MSDTC service dependency oci.dll

This persistence technique is highly versatile, enabling Ramsay agents delivered as DLLs to fragment their logic into separated sections, implementing different functionality tailored for the subject processes where the agent will be loaded. In addition, the use of this technique makes detection more difficult since the loading of these DLLs into their respective processes/services won't necessarily trigger an alert.

Capabilities

Ramsay's architecture provides a series of capabilities monitored via a logging mechanism intended to assist operators by supplying a feed of actionable intelligence to conduct exfiltration, control, and lateral movement actions, as well as providing overall behavioral and system statistics of each compromised system. The realization of these actions is possible due to the following capabilities:

• File collection and covert storage

The primary goal of this framework is to collect all existing Microsoft Word documents within the target's filesystem. The overall collection stages are shown in Figure 6:

Figure 6. Mechanism of document collection

Word documents will first be collected and stored in a preliminary collection directory. The location of this directory may vary depending on the Ramsay version. Two of the directories we observed being used for this purpose were %APPDATA%\Microsoft\UserSetting and %APPDATA%\Microsoft\UserSetting\MediaCache.

Depending on the Ramsay version, file collection won't be restricted to the local system drive, but also will search additional drives such as network or removable drives:

Figure 7. Hex-Rays output of procedure to scan removable drives for collection

Figure 8. Hex-Rays output of procedure to scan network drives for collection

Collected documents are encrypted using the RC4 Stream Cipher Algorithm.

The RC4 key used to encrypt each file will be a computed MD5 hash of a randomly generated sequence of 16 bytes, salted with 16 bytes hardcoded in the malware sample. The first 16 bytes of the buffer where the encrypted file will be held will correspond to the actual RC4 key used:

Figure 9. Hex-Rays output of RC4 key generation and storage

Collected files under the preliminary collection directory will be compressed using a WinRAR instance that the Ramsay Installer drops. This compressed archive will be saved within the preliminary collection directory and then generate a Ramsay container artifact:

Figure 10. Hex-Rays output of Ramsay container generation

As shown in the previous screenshot, these Ramsay containers contain a magic value at the beginning of the file, along with a Hardware Profile GUID denoting an identifier of the victim's machine; an additional XOR-based encryption layer will be applied to the generated compressed archive. The following diagram shows the structure of these artifacts:

Figure 11. Ramsay Container Structure<{i>

Ramsay implements a decentralized way of storing these artifacts among the victim's file system by using inline hooks applied on two Windows API functions, WriteFile and CloseHandle.

The hooked WriteFile procedure's main purpose is to save the file handle of the subject file to write and install another hook in the CloseHandle API function. The CloseHandle hooked procedure will then check whether the subject file name has a .doc extension; if that's the case, it will then append at the end of the subject document the Ramsay container artifact followed by a stream of 1024 bytes denoting a Microsoft Word document footer.

This is done as an evasion measure in order to provide a means to hide the embedded artifact within the subject document from the naked eye:

Figure 12. Hex-Rays output of code for appending Word document footer at the end of the target document

Ramsay containers appended to Word documents will be marked in order to avoid redundant artifacts being appended to already affected documents and the preliminary storage directory will be cleared in order to generate a brand-new Ramsay artifact in intervals.

Even though affected documents will be modified, it won't impact their integrity; each affected Word document remains fully operational after artifact appending has taken place.

Exfiltration of these artifacts is done via an external component that we haven't been able to retrieve. However, based on the decentralized methodology Ramsay implements for storage of collected artifacts, we believe this component would scan the victim's file system in search for the Ramsay container's magic values, in order to identify the location of artifacts to exfiltrate.

• Command execution

Unlike most conventional malware, Ramsay does not have a network-based C&C communication protocol nor does it make any attempt to connect to a remote host for communication purposes. Ramsay's control protocol follows the same decentralized philosophy implemented for collected artifact storage.

Ramsay will scan all the network shares and removable drives (excluding A: and B: drives usually reserved for floppy disks) for potential control files. First, Ramsay looks for Word documents and also, in more recent versions, for PDFs and ZIP archives:

Figure 13. Hex-Rays output of Ramsay Scan procedure for Control File retrieval

These files are parsed for the presence of a magic marker specific to the control file format. More specifically, Ramsay looks for any of two given encoded Hardware Profile GUIDs. One of these GUIDs is hardcoded as shown in Figure 14, while the other is dynamically generated based on the compromised victim’s machine. If any of the subject identifiers are found, parsing for a command signature will be attempted.

Figure 14. Hex-Rays output of Ramsay Control File Parsing

The search for these two GUID instances implies that Ramsay’s control documents can be deliberately crafted to be “victim agnostic”, capable of deploying the same control document instance across a number of victims by leveraging a “global” GUID within control documents. On the other hand, control documents can be crafted by embedding a specific GUID intended to be delivered exclusively on a single victim’s machine. This indicator of Ramsay's control protocol implementation implies that its backend counterpart may be somewhat automated.

Ramsay control protocol supports three different commands:

Table 3. Ramsay’s control commands

After a given command signature is retrieved, the contained artifact to execute will be extracted within the control document’s body to then be restored, modifying the subject control document to its original form after command execution.

• Spreading

Among the different files dropped by the latest versions of Ramsay we find a Spreader component. This executable will attempt to scan for network shares and removable drives excluding A: and B: drives:

Figure 15. Hex-Rays output of spreader scanning routines

It is important to notice that there is a correlation between the target drives Ramsay scans for propagation and control document retrieval. This assesses the relationship between Ramsay’s spreading and control capabilities showing how Ramsay’s operators leverage the framework for lateral movement, denoting the likelihood that this framework has been designed to operate within air-gapped networks.

The propagation technique mainly consists of file infection much like a prepender file infector in order to generate executables similar in structure to Ramsay’s decoy installers for every accessible PE file within the aforementioned targeted drives. The following diagram illustrates the changes applied to targeted executables after infection has taken place and how these components interact on execution:

Figure 16. File structure changes during an infection and execution

All of the different artifacts involved in the infection stage are either within the context of the spreader or dropped previously by another Ramsay component. Some of the artifacts are parsed for the following tokens:

Figure 17. Hex-Rays output of tokens to search for different artifacts within the spreader context

After a given file has been infected, it will be marked by writing a specific token at the end of it in order to provide the spreader an identifier to prevent redundant infection.

In addition, some components of Ramsay have implemented a network scanner intended for the discovery of machines within the compromised host’s subnet that are susceptible to the EternalBlue SMBv1 vulnerability. This information will be contained within all logged information Ramsay collects and may be leveraged by operators in order to do further lateral movement over the network in a later stage via a different channel.

Further remarks

Ramsay’s version 2.a Spreader component was found to have reused a series of tokens seen before in Darkhotel’s Retro Backdoor. These tokens are the following:

Figure 18. Hex-Rays output of Token Reuse with Retro

Figure 19. Token Reuse on Retro URL Crafting

Ramsay serializes victims using the GetCurrentHwProfile API to then retrieve a GUID for the specific victim’s machine. This is also seen implemented in Retro. They both use the same default GUID in case the API call fails:

Figure 20. Ramsay and Retro GUID generation

Both Ramsay and Retro share the same encoding algorithm to encode the retrieved GUID.

Figure 21. Ramsay and Retro GUID encoding scheme

The GUID retrieved by GetCurrentHwProfile is specific for the system’s hardware but not for the user or PC instance. Therefore, it is likely that by just leveraging this GUID operators may encounter duplicates intended to serialize different victims.

The purpose of this scheme is to generate a GUID that is less likely to be duplicate-prone by ‘salting’ it with the machine’s ethernet adapter address. This implies that Retro and Ramsay share the same scheme to generate unique identifiers.

We also found similarities in the way Ramsay and Retro saved some of their log files, sharing a similar filename convention:

Figure 22. Some of Ramsay and Retro filename convention

Is important to highlight that among Retro’s documented techniques, it leverages malicious instances of msfte.dll, oci.dll and lame_enc.dll, and via Phantom DLL Hijacking. As previously documented, Ramsay also uses this technique in some of its versions also using msfte.dll and oci.dll.

In addition, we also observed similarities among Ramsay and Retro in regard to the open-source tools used among their toolsets, such as leveraging UACMe for privilege escalation and ImprovedReflectiveDLLInjection for deploying some of their components.

Finally, we noticed Korean language metadata within the malicious documents leveraged by Ramsay, denoting the use of Korean-based templates.

Figure 23. Malicious document metadata showing the Korean word “title”

Conclusion

Based on the different instances of the framework found, Ramsay has gone through various development stages, denoting an increasing progression in the number and complexity of its capabilities.

Developers in charge of attack vectors seem to be trying various approaches such as old exploits for Word vulnerabilities from 2017 as well as deploying trojanized applications.

We interpret this as that developers have a prior understanding of the victims’ environment and are tailoring attack vectors that would successfully intrude into targeted systems without the need to waste unnecessary resources.

Some stages of Ramsay’s framework are still under evaluation, which could explain the current low visibility of victims, having in mind that Ramsay’s intended targets may be under air-gapped networks, which would also impact victim visibility.

We will continue monitoring new Ramsay activities and will publish relevant information on our blog. For any inquiries, contact us as [email protected]. Indicators of Compromise can also be found in our GitHub repository.

Indicators of Compromise (IoCs)

MITRE ATT&CK techniques