{
	"id": "b99adc33-dcd5-4391-9a4a-16a8dd0849aa",
	"created_at": "2026-04-06T00:11:10.013032Z",
	"updated_at": "2026-04-10T03:21:55.038346Z",
	"deleted_at": null,
	"sha1_hash": "68236bcbc19a614a6351c454cf17b47da0bebc80",
	"title": "ModPipe POS Malware: New Hooking Targets Extract Card Data",
	"llm_title": "",
	"authors": "",
	"file_creation_date": "0001-01-01T00:00:00Z",
	"file_modification_date": "0001-01-01T00:00:00Z",
	"file_size": 498726,
	"plain_text": "ModPipe POS Malware: New Hooking Targets Extract Card Data\r\nBy Sean Straw\r\nPublished: 2022-06-02 · Archived: 2026-04-02 11:50:07 UTC\r\nKroll’s incident responders have seen threat actor groups becoming increasingly sophisticated and elusive in the\r\ntactics, techniques and procedures they employ to steal payment card data. One common method is to “scrape” the\r\nTrack 1 or Track 2 data stored on the card’s magnetic stripe, which provides the cardholder account and personal\r\ninformation criminals need to make fraudulent “card-not-present” (CNP) transactions. This no longer requires\r\nphysical access to a card or using a rogue device near an ATM to skim and store card data. The ongoing migration\r\nof point of sale (POS) management systems to the cloud provides actors with a rapidly expanding attack surface\r\nthat is rife with opportunities for exploitation.\r\nThe Kroll Malware Analysis and Reverse Engineering team has observed recent ModPipe malware activity\r\ntargeting payment card information. ModPipe continues to use the JHook hooking module to steal card\r\ninformation when it is encrypted or decrypted on card processing servers. Kroll analyzed a recent sample that\r\nhooked the memcpy function within rsaenh.dll, a Microsoft cryptographic library. Previous reporting had\r\nidentified memcpy as a possible hooking target for ModPipe. Included in the analysis is a Ghidra script created by\r\nKroll analysts to quickly map process memory into the correct virtual address space using Volatility 3.\r\nModPipe Analysis\r\nModPipe Background\r\nAs first reported in November 2020, ModPipe is a modular backdoor that runs within system processes and uses\r\nnamed pipes to communicate between modules. ModPipe has historically targeted devices running ORACLE\r\nMICROS Restaurant Enterprise Series (RES) 3700 POS, but the capabilities it employs could be used to target\r\nother systems. The persistent loader is an executable that unpacks an inner payload before injecting the core\r\nModPipe module into a system process. In Kroll’s analysis, this process was typically lsass.exe, though\r\nwininit.exe and services.exe have also been identified as additional targets.\r\nOnce injected, it has been noted that the unpacked core module will attempt to connect to legitimate URLs to\r\nconfirm network connectivity before establishing command-and-control (C2) connections and then downloading\r\nand executing additional modules from a remote, actor-controlled server. Along with the C2 and injection\r\nmodules, the following modules have been previously identified:\r\nGetMicInfo – A module to steal database passwords and sensitive information related to MicrosPOS\r\nsoftware\r\nModScan – A module designed to scan IP addresses\r\nProcList – Gets a list of running processes and loaded modules\r\nAt the time of initial analysis, analysts believed that additional modules most likely exist, but the modules had not\r\nyet been seen in the wild.\r\nhttps://www.kroll.com/en/insights/publications/cyber/modpipe-pos-malware-new-hooking-targets-extract-card-data\r\nPage 1 of 7\n\nJHook Module Background\r\nIn April 2021, researchers reported that they had identified two additional modules used by ModPipe malware,\r\nincluding the JHook module. The JHook module is designed to replace legitimate function calls within a process\r\nwith malicious JHook functions that are designed to target two legitimate functions for scraping:\r\nCryptDecrypt – a decryption function within the advapi32.dll library\r\nmemcpy – a common C function to copy data from one memory location to another\r\nWhen the JHook module is run, these functions can be replaced by scraping functions which call the original\r\nlegitimate function after reviewing the data and looking for Track 1 and Track 2 card data. Once the target data is\r\nlocated, the JHook scraping function copies the identified track data to a buffer before sending the data to the core\r\nmodule for exfiltration.\r\nThe researchers reported that the configuration they had identified targeted the CryptDecrypt function within\r\ndbsecurity2.dll using the format provided in Figure 1.\r\n\u003cHOOK_TYPE\u003e{\r\n\u003cTARGET_MODULE\u003e|\u003cHOOK_TARGET_DLL\u003e\r\n:\u003cHOOK_TARGET_FUNC\u003e:\u003cHOOK_FUNC\u003e\r\nFigure 1 – JHook format used to target “CryptDecrypt” function within dbsecurity2.dll\r\nOur Findings\r\nWe have analyzed an instance of ModPipe that was configured to hook the memcpy function within rsaenh.dll, a\r\nMicrosoft cryptographic library, in the CCS.exe process of a Micros RES POS system. The configured hook is\r\nprovided in Figure 2.\r\nHookImport{\r\n\\rsaenh.dll|ntdll.dll:memcpy:JHook_memcpy\r\nHookImport{\r\n\\rsaenh.dll|ntdll.dll:memcpy:\r\nJHook_memcpy\r\nFigure 2 – JHook Format Identified by Kroll to Hook “memcpy” Function within “rsaenh.dll”\r\nThe module is configured to hook the memcpy function of ntdll.dll within rsaenh.dll. Interestingly, Kroll has not\r\nyet identified why or where the rsaenh.dll library is used within the MicroPOS CCS.exe process. Dependency\r\nanalysis of the CCS.exe executable did not identify any locations where the executable or its libraries listed a\r\nfunction from rsaenh.dll. Further analysis is underway to identify the specific use of rsaenh.dll within the\r\nMicroPOS CCS.exe process. However, as the library provides cryptographic functionality, it is reasonable to\r\nassume that some portion of the library is used for encrypting or decrypting track data. Kroll identified stolen\r\ntrack data within memory to confirm that despite the unclear origin of rsaenh.dll, the module had found some\r\nsuccess in stealing track data previously.\r\nhttps://www.kroll.com/en/insights/publications/cyber/modpipe-pos-malware-new-hooking-targets-extract-card-data\r\nPage 2 of 7\n\nTo hook the memcpy function, the malware replaces the entry for the function within the Import Address Table\r\n(IAT) of rsaenh.dll with the address of a trampoline function created by the module in a new section of\r\nreadable/writeable/executable memory (Figure 3).\r\nFigure 3 – The Trampoline Function\r\nWhen called, the scraping function checks to ensure that the count argument of memcpy is at least 10 and that a\r\nsrc argument has been provided before inserting an exception handler into the exception handler’s chain (Figure\r\n4).\r\nhttps://www.kroll.com/en/insights/publications/cyber/modpipe-pos-malware-new-hooking-targets-extract-card-data\r\nPage 3 of 7\n\nFigure 4 – The Beginning of the “JHook_memcpy” Function\r\nThe exception handler increments a counter before setting the instruction counter to be near the end of the\r\nfunction. This effectively catches and ignores any errors from the scraping routine (Figure 5).\r\nFigure 5 – The Registered Exception Handler\r\nAs the earlier researchers noted, after copying the identified data to an internal buffer, the scraping function\r\nincrements a counter common to both the JHook_memcpy and JHook_CryptDecrypt functions. At the time of\r\nthis writing, the internal buffer within memory had tracked approximately double the number of cards identified in\r\nthe initial Common Point of Purchase notification.\r\nMapping Memory within Ghidra\r\nhttps://www.kroll.com/en/insights/publications/cyber/modpipe-pos-malware-new-hooking-targets-extract-card-data\r\nPage 4 of 7\n\nAs part of Kroll’s analysis, analysts reviewed a memory dump of a system with ModPipe and the JHook module\r\nactive. To facilitate the reverse engineering of the module, Kroll developed a short Ghidra script to take the output\r\nof the Volatility 3 vadinfo module and quickly map the memory to the correct locations within the Ghidra\r\nCodeBrowser.\r\nWhen a process of interest has been identified, all the process memory can be dumped using the Volatility 3\r\nvadinfo module to a directory, with the standard output of the module written to a text file. The module includes\r\nthe VPN start and end for each memory section, source file when available and the memory protection (Figure 6).\r\npy E:\\tools\\volatility3\\vol.py -f\r\n.\\memory_dump -o 644_vadinfo\r\nwindows.vadinfo --pid 644 --dump\u003e\r\nvadinfo.out\r\nFigure 6 – Command to dump memory using the vadinfo module\r\nAfter opening a section of memory and setting the language for the CodeBrowser, the Ghidra script can be run,\r\nprompting for the output directory (644_vadinfo) and output file (vadinfo.out). The script will then create the\r\nappropriate memory map for all available dump files (Figure 7).\r\nFigure 7 – Memory Map After Running the Script\r\nThis enables analysts to easily cross-reference code from different sections of memory, such as the JHook\r\ntrampoline, the JHook memcpy function and the modified IAT within rsaenh.dll (Figure 8).\r\nhttps://www.kroll.com/en/insights/publications/cyber/modpipe-pos-malware-new-hooking-targets-extract-card-data\r\nPage 5 of 7\n\nFigure 8 – Trampoline function showing references to different sections of memory mapped by the script\r\nDetection and Mitigation\r\nAs of this publication, ModPipe is considered advanced, but not commonly used. There has been limited research\r\non the malware, with no proof of a parent group or what threat actors are doing with the stolen data after\r\nexfiltration. ModPipe relies on elevated privileges and would generally fall within the actions-on-objectives\r\nwithin the Kroll Intrusion Lifecycle.\r\nHardening steps like network segmentation, enabling multifactor authentication and utilizing endpoint detection\r\nand monitoring that can identify malware such as ModPipe can help prevent threat actors from achieving the\r\nnecessary level of access to deploy ModPipe. Endpoint detection can also be configured to look for unusual\r\nnetwork communications from system processes.\r\nEnsuring your organization has good overall cybersecurity hygiene can prevent a threat actor from gaining access\r\nto your network, thus preventing malware from being placed on your server. These 10 essential cybersecurity\r\ncontrols can help improve your security posture and increase your cyber resilience. For more information, contact\r\nus via our 24x7 cyber incident response hotlines or connect with us through our Contact Us page.\r\nIndicators of Compromise\r\nType Value\r\nFilename Mljpmi.exe\r\nMD5 34d03f1900e759e2a670c42d7af14a3d\r\nSHA1 10ea1722991a787fef9a3a2545f7bcc7d0b4f42c\r\nhttps://www.kroll.com/en/insights/publications/cyber/modpipe-pos-malware-new-hooking-targets-extract-card-data\r\nPage 6 of 7\n\nSHA256 74fd2d70b085d70bd883854ae9ebd1684f3de824995acd4df1993d3d469c62ec\r\nURL ouidji12345.ddns[.]net/gettime.html\r\nIP Address 185.206.147.15\r\nIP Address 89.163.246.135\r\nSource: https://www.kroll.com/en/insights/publications/cyber/modpipe-pos-malware-new-hooking-targets-extract-card-data\r\nhttps://www.kroll.com/en/insights/publications/cyber/modpipe-pos-malware-new-hooking-targets-extract-card-data\r\nPage 7 of 7",
	"extraction_quality": 1,
	"language": "EN",
	"sources": [
		"Malpedia"
	],
	"references": [
		"https://www.kroll.com/en/insights/publications/cyber/modpipe-pos-malware-new-hooking-targets-extract-card-data"
	],
	"report_names": [
		"modpipe-pos-malware-new-hooking-targets-extract-card-data"
	],
	"threat_actors": [],
	"ts_created_at": 1775434270,
	"ts_updated_at": 1775791315,
	"ts_creation_date": 0,
	"ts_modification_date": 0,
	"files": {
		"pdf": "https://archive.orkl.eu/68236bcbc19a614a6351c454cf17b47da0bebc80.pdf",
		"text": "https://archive.orkl.eu/68236bcbc19a614a6351c454cf17b47da0bebc80.txt",
		"img": "https://archive.orkl.eu/68236bcbc19a614a6351c454cf17b47da0bebc80.jpg"
	}
}