ModPipe POS Malware: New Hooking Targets Extract Card Data

Kroll’s incident responders have seen threat actor groups becoming increasingly sophisticated and elusive in the tactics, techniques and procedures they employ to steal payment card data. One common method is to “scrape” the Track 1 or Track 2 data stored on the card’s magnetic stripe, which provides the cardholder account and personal information criminals need to make fraudulent “card-not-present” (CNP) transactions. This no longer requires physical access to a card or using a rogue device near an ATM to skim and store card data. The ongoing migration of point of sale (POS) management systems to the cloud provides actors with a rapidly expanding attack surface that is rife with opportunities for exploitation.

The Kroll Malware Analysis and Reverse Engineering team has observed recent ModPipe malware activity targeting payment card information. ModPipe continues to use the JHook hooking module to steal card information when it is encrypted or decrypted on card processing servers. Kroll analyzed a recent sample that hooked the memcpy function within rsaenh.dll, a Microsoft cryptographic library. Previous reporting had identified memcpy as a possible hooking target for ModPipe. Included in the analysis is a Ghidra script created by Kroll analysts to quickly map process memory into the correct virtual address space using Volatility 3.

ModPipe Analysis

ModPipe Background

As first reported in November 2020, ModPipe is a modular backdoor that runs within system processes and uses named pipes to communicate between modules. ModPipe has historically targeted devices running ORACLE MICROS Restaurant Enterprise Series (RES) 3700 POS, but the capabilities it employs could be used to target other systems. The persistent loader is an executable that unpacks an inner payload before injecting the core ModPipe module into a system process. In Kroll’s analysis, this process was typically lsass.exe, though wininit.exe and services.exe have also been identified as additional targets.

Once injected, it has been noted that the unpacked core module will attempt to connect to legitimate URLs to confirm network connectivity before establishing command-and-control (C2) connections and then downloading and executing additional modules from a remote, actor-controlled server. Along with the C2 and injection modules, the following modules have been previously identified:

• GetMicInfo – A module to steal database passwords and sensitive information related to MicrosPOS software
• ModScan – A module designed to scan IP addresses
• ProcList – Gets a list of running processes and loaded modules

At the time of initial analysis, analysts believed that additional modules most likely exist, but the modules had not yet been seen in the wild.

JHook Module Background

In April 2021, researchers reported that they had identified two additional modules used by ModPipe malware, including the JHook module. The JHook module is designed to replace legitimate function calls within a process with malicious JHook functions that are designed to target two legitimate functions for scraping:

• CryptDecrypt – a decryption function within the advapi32.dll library
• memcpy – a common C function to copy data from one memory location to another

When the JHook module is run, these functions can be replaced by scraping functions which call the original legitimate function after reviewing the data and looking for Track 1 and Track 2 card data. Once the target data is located, the JHook scraping function copies the identified track data to a buffer before sending the data to the core module for exfiltration.

The researchers reported that the configuration they had identified targeted the CryptDecrypt function within dbsecurity2.dll using the format provided in Figure 1.

Figure 1 – JHook format used to target “CryptDecrypt” function within dbsecurity2.dll

Our Findings

We have analyzed an instance of ModPipe that was configured to hook the memcpy function within rsaenh.dll, a Microsoft cryptographic library, in the CCS.exe process of a Micros RES POS system. The configured hook is provided in Figure 2.

Figure 2 – JHook Format Identified by Kroll to Hook “memcpy” Function within “rsaenh.dll”

The module is configured to hook the memcpy function of ntdll.dll within rsaenh.dll. Interestingly, Kroll has not yet identified why or where the rsaenh.dll library is used within the MicroPOS CCS.exe process. Dependency analysis of the CCS.exe executable did not identify any locations where the executable or its libraries listed a function from rsaenh.dll. Further analysis is underway to identify the specific use of rsaenh.dll within the MicroPOS CCS.exe process. However, as the library provides cryptographic functionality, it is reasonable to assume that some portion of the library is used for encrypting or decrypting track data. Kroll identified stolen track data within memory to confirm that despite the unclear origin of rsaenh.dll, the module had found some success in stealing track data previously.

To hook the memcpy function, the malware replaces the entry for the function within the Import Address Table (IAT) of rsaenh.dll with the address of a trampoline function created by the module in a new section of readable/writeable/executable memory (Figure 3).

Figure 3 – The Trampoline Function

When called, the scraping function checks to ensure that the count argument of memcpy is at least 10 and that a src argument has been provided before inserting an exception handler into the exception handler’s chain (Figure 4).

Figure 4 – The Beginning of the “JHook_memcpy” Function

The exception handler increments a counter before setting the instruction counter to be near the end of the function. This effectively catches and ignores any errors from the scraping routine (Figure 5).

Figure 5 – The Registered Exception Handler

As the earlier researchers noted, after copying the identified data to an internal buffer, the scraping function increments a counter common to both the JHook_memcpy and JHook_CryptDecrypt functions. At the time of this writing, the internal buffer within memory had tracked approximately double the number of cards identified in the initial Common Point of Purchase notification.

Mapping Memory within Ghidra

As part of Kroll’s analysis, analysts reviewed a memory dump of a system with ModPipe and the JHook module active. To facilitate the reverse engineering of the module, Kroll developed a short Ghidra script to take the output of the Volatility 3 vadinfo module and quickly map the memory to the correct locations within the Ghidra CodeBrowser.

When a process of interest has been identified, all the process memory can be dumped using the Volatility 3 vadinfo module to a directory, with the standard output of the module written to a text file. The module includes the VPN start and end for each memory section, source file when available and the memory protection (Figure 6).

Figure 6 – Command to dump memory using the vadinfo module

After opening a section of memory and setting the language for the CodeBrowser, the Ghidra script can be run, prompting for the output directory (644_vadinfo) and output file (vadinfo.out). The script will then create the appropriate memory map for all available dump files (Figure 7).

Figure 7 – Memory Map After Running the Script

This enables analysts to easily cross-reference code from different sections of memory, such as the JHook trampoline, the JHook memcpy function and the modified IAT within rsaenh.dll (Figure 8).

Figure 8 – Trampoline function showing references to different sections of memory mapped by the script

Detection and Mitigation

As of this publication, ModPipe is considered advanced, but not commonly used. There has been limited research on the malware, with no proof of a parent group or what threat actors are doing with the stolen data after exfiltration. ModPipe relies on elevated privileges and would generally fall within the actions-on-objectives within the Kroll Intrusion Lifecycle.

Hardening steps like network segmentation, enabling multifactor authentication and utilizing endpoint detection and monitoring that can identify malware such as ModPipe can help prevent threat actors from achieving the necessary level of access to deploy ModPipe. Endpoint detection can also be configured to look for unusual network communications from system processes.

Ensuring your organization has good overall cybersecurity hygiene can prevent a threat actor from gaining access to your network, thus preventing malware from being placed on your server. These 10 essential cybersecurity controls can help improve your security posture and increase your cyber resilience. For more information, contact us via our 24x7 cyber incident response hotlines or connect with us through our Contact Us page.

Indicators of Compromise