{ "id": "81ffc154-db8a-41c7-b906-06e0ab46c5f1", "created_at": "2026-04-06T00:22:23.82236Z", "updated_at": "2026-04-10T13:13:06.214677Z", "deleted_at": null, "sha1_hash": "b0d9ac430b105f93d6ef35eba3bc300ae508446d", "title": "Introducing LogPOS", "llm_title": "", "authors": "", "file_creation_date": "0001-01-01T00:00:00Z", "file_modification_date": "0001-01-01T00:00:00Z", "file_size": 311186, "plain_text": "Introducing LogPOS\r\nPublished: 2015-11-16 · Archived: 2026-04-05 15:02:00 UTC\r\nIntroduction\r\nThere has been an explosion in POS malware in the last year. At Morphick, Nick Hoffman and I found 2\r\nundiscovered families in 2014 and we just found our first new family of 2015. This new malware which we’re\r\ncalling LogPOS has several notable differences from recent POS malware.\r\nThe hash that we’ll be pulling apart in this post is af13e7583ed1b27c4ae219e344a37e2b .\r\nDiving In\r\nAlmost immediately when looking at this sample, a string jumped out - \\\\.\\mailslot\\LogCC .\r\nIn most POS variants, one process scrapes memory from other processes and writes discovered track data to a log.\r\nBecause LogPOS injects code into various processes and has each of them search their own memory, it can’t use a\r\nlog, since they can’t all open the same file with write access at once. Instead, it uses mailslots.\r\nUsing mailslots for communication/storage isn’t a new mechanism for malware, in FireEye’s report on APT28\r\nthere is mention of the group using a mailslot with a name of check_mes_v5555 . Mailslots are an IPC mechanism\r\nallowing multiple clients to send messages to a server. In this case, the main executable creates the mailslot and\r\nacts as the mailslot server, while the code injected into the various processes acts as a client, writing carved credit\r\ncard numbers to the mailslot for direct transmission to the C2.\r\nEarly in the execution of the program, there is a call to CreateMailslotA with an mailslot name of\r\n\\\\.\\mailslot\\LogCC .\r\nIf the mailslot fails to be created, the program will exit. If the mailslot succeeds the program will enter an infinite\r\nloop performing the following functions.\r\n Sleeping 500 milliseconds\r\n Iterating over processes\r\n Comparing against a whitelist\r\n Inject shellcode into the process (if not in whitelist)\r\n Scanning for credit card track information\r\n Validation using Luhn's\r\nhttps://securitykitten.github.io/2015/11/16/logpos-new-point-of-sale-malware-using-mailslots.html\r\nPage 1 of 7\n\nReading from the mailslot\r\n POST'ing out the data\r\nThe most interesting thing is the injected code, so we’ll look at that in more detail below.\r\nWhile iterating over the processes (as mentioned above) the malware will check the process name against a\r\nwhitelist containing the following names.\r\nwindbg.exe\r\nlogounui.exe\r\ntaskmgr.exe\r\nskype.exe\r\nthunderbird.exe\r\ndevenv.exe\r\nsteam.exe\r\nwinlogon.exe\r\nwininit.exe\r\ncsrss.exe\r\nsmss.exe\r\nsvchost.exe\r\nfirefox.exe\r\nchrome.exe\r\nexplorer.exe\r\npsi.exe\r\npidgin.exe\r\nSystem\r\nThe code to compare the strings can be seen below:\r\nhttps://securitykitten.github.io/2015/11/16/logpos-new-point-of-sale-malware-using-mailslots.html\r\nPage 2 of 7\n\nOnce a program that is not in the whitelist is found, code is injected into it’s memory space using\r\nWriteProcessMemory. The first thing that this shellcode does is crawl to find the base of kernel32, this is used to\r\nstart building imports. The method for finding kernel32 is a well documented one that has been discussed in many\r\nresearch blogs.\r\nOnce the base is found, the shellcode will begin to rebuild it’s imports via it’s own hashing technique. A list of\r\nsome of the hashes and their values are:\r\nhttps://securitykitten.github.io/2015/11/16/logpos-new-point-of-sale-malware-using-mailslots.html\r\nPage 3 of 7\n\nAfter building the imports, the malware will call CreateFileA with a filename of \\.\\mailslot\\LogCC to obtain a\r\nhandle for writing.\r\nhttps://securitykitten.github.io/2015/11/16/logpos-new-point-of-sale-malware-using-mailslots.html\r\nPage 4 of 7\n\nWhen scanning memory, the malware will use a custom search to find common sentinels for track information.\r\nInformation is passed to an implementation of Luhn’s algorithm for validation. Once hits are located, they are sent\r\nto the mailslot where the main program will read them. When a number is added (on a schedule) the malware will\r\nbuild a format string and post the information to a remote site. (Note, the site has been redacted, due to live\r\nnumbers currently being posted there)\r\nThe data is then sent to a remote site (via HTTP GET)\r\nhttps://securitykitten.github.io/2015/11/16/logpos-new-point-of-sale-malware-using-mailslots.html\r\nPage 5 of 7\n\nThe results are populated in a table (at the time of this writing the form is not password protected and the results\r\ncan be seen). A majority of the hits are in the process space of rdpclip and notepad leading us to believe that the\r\nauthor is currently testing their code. A screenshot of the panel with IP’s can be seen below:\r\nDetection\r\nLogPOS avoids a traditional detection mechanism of scanning files for unencrypted credit card information by\r\ninstead writing to a mailslot. However, using a tool like yara, it is easy to detect variants of this malware. The\r\nfollowing rule will assist in finding this malicious tool on your network.\r\nrule LogPOS\r\n{\r\n meta:\r\n author = \"Morphick Security\"\r\n description = \"Detects Versions of LogPOS\"\r\n md5 = \"af13e7583ed1b27c4ae219e344a37e2b\"\r\n strings:\r\n $mailslot = \"\\\\\\\\.\\\\mailslot\\\\LogCC\"\r\n $get = \"GET /%s?encoding=%c\u0026t=%c\u0026cc=%I64d\u0026process=\"\r\n //64A130000000 mov eax, dword ptr fs:[0x30]\r\n //8B400C mov eax, dword ptr [eax + 0xc]\r\n //8B401C mov eax, dword ptr [eax + 0x1c]\r\n //8B4008 mov eax, dword ptr [eax + 8]\r\n $sc = {64 A1 30 00 00 00 8B 40 0C 8B 40 1C 8B 40 08 }\r\n condition:\r\n $sc and 1 of ($mailslot,$get)\r\n}\r\nhttps://securitykitten.github.io/2015/11/16/logpos-new-point-of-sale-malware-using-mailslots.html\r\nPage 6 of 7\n\nIn addition to yara, this POS malware can be detected with its URI pattern. The following bro signature will detect\r\nthis malware from a network perspective.\r\nsignature LogPOS {\r\n #source: Morphick Security\r\n #version: 1\r\n #Ref: af13e7583ed1b27c4ae219e344a37e2b\r\n ip-proto == tcp\r\n dst-port == 80,443\r\n http-request /.*encoding\\=.*\\\u0026t\\=.*\\\u0026cc\\=.*\\\u0026process\\=.*\\\u0026track\\=/\r\n event \"LogPOS Credit Card GET Request Pattern\"\r\n}\r\nConclusion\r\nPOS malware has been getting attention on a lot of fronts. TrendMicro recently reported that there have been more\r\nnew POS variants discovered in the last 6 months than the last several years.\r\nFor example, earlier this year Josh Grunzweig uncovered a new variant of Alina (dubbed Eagle), and Trustwave\r\ndocumented another new version (dubbed Spark). While all this was going on, new families like Getmypass,\r\nLusyPOS, Daredevil, NewPOSThings, and Backoff were just starting to be discovered.\r\nDespite the ongoing efforts to curb POS malware from being successful, this seems to be an area where there is no\r\nslowing down.\r\nSource: https://securitykitten.github.io/2015/11/16/logpos-new-point-of-sale-malware-using-mailslots.html\r\nhttps://securitykitten.github.io/2015/11/16/logpos-new-point-of-sale-malware-using-mailslots.html\r\nPage 7 of 7", "extraction_quality": 1, "language": "EN", "sources": [ "ETDA", "Malpedia" ], "origins": [ "web" ], "references": [ "https://securitykitten.github.io/2015/11/16/logpos-new-point-of-sale-malware-using-mailslots.html" ], "report_names": [ "logpos-new-point-of-sale-malware-using-mailslots.html" ], "threat_actors": [ { "id": "730dfa6e-572d-473c-9267-ea1597d1a42b", "created_at": "2023-01-06T13:46:38.389985Z", "updated_at": "2026-04-10T02:00:02.954105Z", "deleted_at": null, "main_name": "APT28", "aliases": [ "Pawn Storm", "ATK5", "Fighting Ursa", "Blue Athena", "TA422", "T-APT-12", "APT-C-20", "UAC-0001", "IRON TWILIGHT", "SIG40", "UAC-0028", "Sofacy", "BlueDelta", "Fancy Bear", "GruesomeLarch", "Group 74", "ITG05", "FROZENLAKE", "Forest Blizzard", "FANCY BEAR", "Sednit", "SNAKEMACKEREL", "Tsar Team", "TG-4127", "STRONTIUM", "Grizzly Steppe", "G0007" ], "source_name": "MISPGALAXY:APT28", "tools": [], "source_id": "MISPGALAXY", "reports": null }, { "id": "e3767160-695d-4360-8b2e-d5274db3f7cd", "created_at": "2022-10-25T16:47:55.914348Z", "updated_at": "2026-04-10T02:00:03.610018Z", "deleted_at": null, "main_name": "IRON TWILIGHT", "aliases": [ "APT28 ", "ATK5 ", "Blue Athena ", "BlueDelta ", "FROZENLAKE ", "Fancy Bear ", "Fighting Ursa ", "Forest Blizzard ", "GRAPHITE ", "Group 74 ", "PawnStorm ", "STRONTIUM ", "Sednit ", "Snakemackerel ", "Sofacy ", "TA422 ", "TG-4127 ", "Tsar Team ", "UAC-0001 " ], "source_name": "Secureworks:IRON TWILIGHT", "tools": [ "Downdelph", "EVILTOSS", "SEDUPLOADER", "SHARPFRONT" ], "source_id": "Secureworks", "reports": null }, { "id": "ae320ed7-9a63-42ed-944b-44ada7313495", "created_at": "2022-10-25T15:50:23.671663Z", "updated_at": "2026-04-10T02:00:05.283292Z", "deleted_at": null, "main_name": "APT28", "aliases": [ "APT28", "IRON TWILIGHT", "SNAKEMACKEREL", "Group 74", "Sednit", "Sofacy", "Pawn Storm", "Fancy Bear", "STRONTIUM", "Tsar Team", "Threat Group-4127", "TG-4127", "Forest Blizzard", "FROZENLAKE", "GruesomeLarch" ], "source_name": "MITRE:APT28", "tools": [ "Wevtutil", "certutil", "Forfiles", "DealersChoice", "Mimikatz", "ADVSTORESHELL", "Komplex", "HIDEDRV", "JHUHUGIT", "Koadic", "Winexe", "cipher.exe", "XTunnel", "Drovorub", "CORESHELL", "OLDBAIT", "Downdelph", "XAgentOSX", "USBStealer", "Zebrocy", "reGeorg", "Fysbis", "LoJax" ], "source_id": "MITRE", "reports": null } ], "ts_created_at": 1775434943, "ts_updated_at": 1775826786, "ts_creation_date": 0, "ts_modification_date": 0, "files": { "pdf": "https://archive.orkl.eu/b0d9ac430b105f93d6ef35eba3bc300ae508446d.pdf", "text": "https://archive.orkl.eu/b0d9ac430b105f93d6ef35eba3bc300ae508446d.txt", "img": "https://archive.orkl.eu/b0d9ac430b105f93d6ef35eba3bc300ae508446d.jpg" } }