{
	"id": "709bda1c-fa69-4a2b-bbd1-89a93cfc5220",
	"created_at": "2026-04-06T00:12:54.524206Z",
	"updated_at": "2026-04-10T03:20:32.169867Z",
	"deleted_at": null,
	"sha1_hash": "f930f74f493b8dff159d11e224f71ae6a3bd7018",
	"title": "UDPoS - exfiltrating credit card data via DNS",
	"llm_title": "",
	"authors": "",
	"file_creation_date": "0001-01-01T00:00:00Z",
	"file_modification_date": "0001-01-01T00:00:00Z",
	"file_size": 569758,
	"plain_text": "UDPoS - exfiltrating credit card data via DNS\r\nPublished: 2018-02-08 · Archived: 2026-04-05 19:38:24 UTC\r\nPoint of Sale malware has been around for some time and has been deployed against a broad range of businesses\r\nfrom retailers to hotel groups. However, this appears to be a new family which we are currently calling 'UDPoS'\r\nowing to its heavy use of UDP-based DNS traffic. At the time of writing, it's unclear whether the malware is\r\ncurrently being used in campaigns in the wild, although the coordinated use of LogMeIn-themed filenames and C2\r\nURLs, coupled with evidence of an earlier Intel-themed variant, suggest that it may well be.\r\nNote: We have been in contact with LogMeIn throughout this investigation to help determine whether their\r\nservices or products may have been abused as part of the malware deployment process. No evidence of this was\r\nfound and it appears that the use of LogMeIn-themed filenames and C2 domain by the actors behind the malware\r\nis a simple ‘camouflage’ technique.\r\nUpdate: LogMeIn have published an advisory notice to their customers re-iterating the above.\r\nA set of two - service \u0026 monitor\r\nBehavioural analysis of the initial sample we discovered, a file named logmeinumon.exe, showed it contacting a\r\nsimilarly LogMeIn-themed C2 server hosted by a Swiss-based VPS provider (details below - note the use of an ‘L’\r\nrather than an ‘I’ in the spelling of logmeln).\r\nInvestigation of the C2 revealed it also to be hosting the original dropper file, update.exe. This file is a 7-Zip self-extracting archive containing LogmeinServicePack_5.115.22.001.exe and logmeinumon.exe. Details of these files\r\nare in the table below. \r\nBoth of the LogMeIn-themed files have a compilation timestamp of 25 October 2017, suggesting that this is a\r\nrelatively recent campaign.\r\nUpon executing update.exe, its content is extracted to the %TEMP% directory and\r\nLogmeinServicePack_5.115.22.001.exe automatically launched using 7-Zip's built in RunProgram feature.\r\nLogmeinServicePackLogmeinServicePack_5.115.22.001.exe – which we have called the service component – is\r\nresponsible for setting up the malware by placing files into the System32\\LogMeInUpdService directory and\r\ncreating a new system service for persistence. It does this via a batch file with a semi-random filename embedding\r\nhttps://www.forcepoint.com/blog/x-labs/udpos-exfiltrating-credit-card-data-dns\r\nPage 1 of 7\n\nstandard Windows commands for file and service operations. Once finished it passes over execution to the\r\nmonitoring component by launching logmeinumon.exe. \r\nThis monitoring component has an almost identical structure to the service component. It's compiled by the same\r\nVisual Studio build and uses the same string encoding technique: both executables contain only a few identifiable\r\nplain-text strings, and instead use a basic encryption and encoding method to hide strings such as the C2 server,\r\nfilenames, and hard-coded process names.\r\nEvasive manoeuvres\r\nDespite maintaining a small footprint – only 88kb in size – the monitor component is a multi-threaded application\r\nwhich creates five different threads after its initialisation code is completed. This initialisation code is mainly\r\nresponsible for decrypting and decoding the malware's internal strings, attempting to carry out an anti-AV/VM\r\ncheck, and either creating or loading an existing ‘Machine ID’ stored in a file called hdwid.dat in the same\r\ndirectory where the executables are deployed. This randomly generated identifier is used as {Machine ID} in all of\r\nthe DNS queries detailed within this blog.\r\nFor the anti-AV and anti-VM solution, there are four DLL and three Named Pipe identifiers stored in both service\r\nand monitor components:\r\nHowever, only the monitor component makes use of these and, moreover, the code responsible for opening\r\nmodule handles is flawed: it will only try to open cmdvrt32.dll – a library related to Comodo security products –\r\nhttps://www.forcepoint.com/blog/x-labs/udpos-exfiltrating-credit-card-data-dns\r\nPage 2 of 7\n\nand nothing else.\r\nIt is unclear at present whether this is a reflection of the malware still being in a relatively early stage of\r\ndevelopment/testing or a straightforward error on the part of the developers.\r\nInitialisation \u0026 evasion\r\nAfter initialisation, including after reboots, the monitor component performs a DNS query on the embedded C2\r\naddress and retrieves the external IP address of the infected machine via an HTTP GET request:\r\n{C2URL}/index.php/?udpool={Machine ID}\r\nThe first time the malware is run, it also generates a batch file called infobat.bat which is similar in structure to the\r\none examined for the service component. Again, this file uses a number of standard Windows commands to create\r\na comprehensive fingerprint of the infected machine containing network, system, route, and process related\r\ninformation. This data is written to a local file called PCi.jpg and sent to the C2 server via DNS. Once complete, a\r\nflag is set in hdwid.dat.\r\nWhether this is intended for use later for lateral movement is unclear, but this information alone would be\r\nsufficient to treat this executable as malicious: the network map, list of running processes and list of installed\r\nsecurity updates is highly valuable information.\r\nDNS comms \u0026 post setup functionality\r\nhttps://www.forcepoint.com/blog/x-labs/udpos-exfiltrating-credit-card-data-dns\r\nPage 3 of 7\n\nAfter the initial HTTP request to determine its external IP address, the monitor component appears to\r\ncommunicate exclusively via fake DNS requests, all of which follow the format\r\n{Machine ID}.{Message Type}.xxxx.xxxx.xxxx.xxxx\r\nwhere {Machine ID} is always 15 characters long, {Message Type} is taken from a set of pre-defined strings, and\r\nthe actual message components 'xxxx' can vary in length, but never exceed 31 characters.\r\nOur analysis identified five possible values for the {Message Type} field: bin, info, ping, trp, and note.\r\nThe bin messages are used to transmit the initial burst of data gathered into PCi.jpg by the infobat.bat process,\r\nwhile ping is a heartbeat message sent to the C2 every 60 minutes. \r\nInfo messages - as the name suggests - are purely informational and are despatched alongside ping messages:\r\n{PCNAME}; {USERNAME}; [NS:IP {C2URL}:{C2IP}]\r\nThe note and trp message types required further analysis and relate to the core functionality of the malware.\r\nInvestigating the functionality spread across the additional threads revealed a process designed to collect Track 1\r\nand Track 2 payment card data by scraping the memory of running processes. These processes are checked against\r\nan embedded and pre-defined blacklist of common system process and browser names with only ones not present\r\non the list being scanned.\r\nIf Track 1/2 data is found in memory it will be extracted as is, converted to and sent as a trp message. A\r\nnote message will be also generated and transmitted with the following content:\r\nhttps://www.forcepoint.com/blog/x-labs/udpos-exfiltrating-credit-card-data-dns\r\nPage 4 of 7\n\n[IP : {ipaddr} ] - String found in: {processname} -\r\nThe malware further logs this process name to a file called sinf.dat, the number of total processes with successful\r\nextraction to hdwid.dat and saves a hash of the trp message to udwupd.kdl, presumably for the purpose of keeping\r\ntrack of what has already been submitted to the C2 server.\r\nAll five message types are logged to the {Machine ID}.dat file prior to transmission.\r\nTimelines\r\nAs the underlying intent of the malware became clear to us, we attempted to identify further samples from the\r\nsame family to determine whether this was something new (and possibly still being tested before deployment) or\r\npart of an ongoing campaign. \r\nThese efforts revealed another service component, but unfortunately not the corresponding monitor nor the parent\r\n7-Zip SFX archive. Interestingly, this second service component was named ‘Intel Upgrade Services’ and\r\napparently intended to masquerade as an Intel update as opposed to a LogMeIn update.\r\nBased on the compilation dates of the executables, the Intel-themed sample was created two weeks prior to the\r\nLogMeIn-themed one on 11 October 2017. Whether this is a sign that authors of the malware were not successful\r\nin deploying it at first or whether these are two different campaigns cannot be fully determined at this time due to\r\nthe lack of additional executables.\r\nDesign decisions and detection rate\r\nThe coding style and techniques seen within the malware can hardly be described as outstanding. Beyond the\r\nfaulty evasion code noted above, using data files written to disk instead of working predominantly in memory –\r\nbesides leaving unnecessary trails – is rarely the trademark of bleeding edge malware and, equally, there are more\r\nadvanced ways of fingerprinting a PC and generating a report. That said, the method used in this sample does\r\nappear to get the job done.\r\nOn the other hand, DNS-based communication and data exfiltration is genuinely unusual – although not unique –\r\nand can be quite effective. Nearly all companies have firewalls and other protections in place to monitor and filter\r\nhttps://www.forcepoint.com/blog/x-labs/udpos-exfiltrating-credit-card-data-dns\r\nPage 5 of 7\n\nTCP- and UDP-based communications, however DNS is still often treated differently providing a golden\r\nopportunity to leak data. \r\nThe overall impression is of a piece of malware inspired by the success of (and some of the better ideas and\r\ntechniques employed by) its predecessors.\r\nDetection rates for the malware are still very low for the monitor component at the time of writing. Visibility is\r\nalways an issue when it comes to non-traditional malware: samples which do not target standard endpoints or\r\nservers can quite easily be missed because of the lack of focus on protecting these sorts of systems.\r\nConclusion\r\nDiscovering a unique piece of malware is a rare event these days and UDPoS, while unusual, is not a new concept.\r\nThere have been several Point of Sale malware families identified over the past few years, all with the same goal:\r\nharvesting credit card data on a large scale – consider how many different cards may be used in stores, bars, or\r\nrestaurants across the course of a day, let alone weeks or months.\r\nFrom a consumer standpoint, protecting oneself against this sort of threat can be a tricky proposition for\r\nindividuals: a PoS terminal could conceivably remain infected for significant lengths of time. However, enabling\r\nreporting on your credit card activity (many banks offer SMS, Push, and email alerts) can greatly reduce the time\r\nof discovery – and therefore recovery – if abuse does occur.\r\nFor many businesses, the situation may not be much better: legacy PoS systems are often based on variations of\r\nthe Windows XP kernel and, in large retailers, may be present on hundreds or even thousands of devices. While\r\nWindows POSReady is in extended support until January 2019, it is still fundamentally an operating system which\r\nis seventeen years old this year.\r\nAs UDPoS highlights, exfiltrating stolen credit card data can and will result in unusual patterns of activity on the\r\nmachines (DNS traffic in this case). By identifying and reacting to these patterns, businesses – both PoS terminal\r\nowners and suppliers - can close down this sort of attack sooner.\r\nProtection statement\r\nForcepoint customers are protected against this threat at the following stages of attack:\r\nStage 5 (Dropper File) - Malicious files are prevented from being downloaded.\r\nStage 6 (Call Home) - Attempts to contact the C2 server are blocked.\r\nIndicators of Compromise\r\nC2 Server\r\nhxxp://service-logmeln[.]network/10/update.exe\r\nservice-logmeln.network\r\nhttps://www.forcepoint.com/blog/x-labs/udpos-exfiltrating-credit-card-data-dns\r\nPage 6 of 7\n\nSHA1 File Hashes\r\n195453b2dc788d393670db611116dcbc3994a1b4\r\nba3dc114f848a60f7af83533580b08c682d6f280\r\nd9f58b3c17a2a7b689bb3ed42bce6a5eb7855569\r\naab16598debb234a9a3732e45d1d1ef369da27d1\r\nSource: https://www.forcepoint.com/blog/x-labs/udpos-exfiltrating-credit-card-data-dns\r\nhttps://www.forcepoint.com/blog/x-labs/udpos-exfiltrating-credit-card-data-dns\r\nPage 7 of 7",
	"extraction_quality": 1,
	"language": "EN",
	"sources": [
		"ETDA",
		"Malpedia"
	],
	"references": [
		"https://www.forcepoint.com/blog/x-labs/udpos-exfiltrating-credit-card-data-dns"
	],
	"report_names": [
		"udpos-exfiltrating-credit-card-data-dns"
	],
	"threat_actors": [],
	"ts_created_at": 1775434374,
	"ts_updated_at": 1775791232,
	"ts_creation_date": 0,
	"ts_modification_date": 0,
	"files": {
		"pdf": "https://archive.orkl.eu/f930f74f493b8dff159d11e224f71ae6a3bd7018.pdf",
		"text": "https://archive.orkl.eu/f930f74f493b8dff159d11e224f71ae6a3bd7018.txt",
		"img": "https://archive.orkl.eu/f930f74f493b8dff159d11e224f71ae6a3bd7018.jpg"
	}
}