{
	"id": "beaa7380-aeb7-42cf-8c94-dc8867fcabbc",
	"created_at": "2026-04-10T03:21:22.418086Z",
	"updated_at": "2026-04-10T13:11:18.281853Z",
	"deleted_at": null,
	"sha1_hash": "799321594e209168b177b24890f8d4795a4e055b",
	"title": "securitykitten.github.io/_posts/2015-01-11-the-mozart-ram-scraper.md at master · malware-kitten/securitykitten.github.io",
	"llm_title": "",
	"authors": "",
	"file_creation_date": "0001-01-01T00:00:00Z",
	"file_modification_date": "0001-01-01T00:00:00Z",
	"file_size": 203747,
	"plain_text": "securitykitten.github.io/_posts/2015-01-11-the-mozart-ram-scraper.md at\r\nmaster · malware-kitten/securitykitten.github.io\r\nBy Nick Hoffman\r\nArchived: 2026-04-10 02:28:44 UTC\r\nlayout category-post\r\ntitle The Mozart RAM Scraper\r\nexcerpt The Elusive POS Malware\r\ndate 2015-01-11 17:51:53 -0500\r\nAs a reverse engineer on the CBTS Advanced Cyber Security team, I spend a large part of my time pulling apart and\r\nprofiling the latest and greatest malware. The Mozart malware was hidden from the public for some time. I hope to shed\r\nsome light on it in this post.\r\nIntroduction\r\nThe Home Depot breach was a very high profile case this year, which brought the security of point of sale machines into the\r\nspotlight. After some mumblings and a bunch of misinformation about who/what and how the attack came about, little\r\npieces of information started to make their way to the surface. Several of which were reports a new malware dubbed\r\n\"Mozart.\"\r\nWhen I heard of the initial reports behind Mozart, I was eager to get my hands on it. There were very few copies floating\r\naround, and the copies available were not being shared. So as you can imagine, I was thrilled when I saw this\r\nhttp://totalhash.com/analysis/1b96a74d8a649dfde269ce2f322732d760c97049.\r\nAll the reports out there didn't have much information on this tool and the deepest level of analysis that I could find was a\r\nstrings dump of the malware. Not interesting. The purpose of this post is to dig deeper into this elusive tool and talk about\r\nhow it works so that we can collectively learn and understand.\r\nDiving In\r\nThe first thing that this malware does is sets itself up as a service for persistence. It uses a legit looking service name \"NCR\r\nSelfServ Platform Remote Monitor\" with the short name of \"NCR_RemoteMonitor\". For those unfamiliar, NCR is a\r\ncompany that specializes in retail point of sale machines. To the untrained eye, these services would look benign. When\r\nrunning the malware for the first time, it'll pop up a command window with the following text:\r\nOnce the service is set up, it will grab the host name of the system:\r\nThe malware will build the string java.exe (manually from bytes) and then store it. It will later focus on dumping processes\r\nnamed java.exe.\r\nhttps://github.com/malware-kitten/securitykitten.github.io/blob/master/_posts/2015-01-11-the-mozart-ram-scraper.md\r\nPage 1 of 5\n\nThe malware will also grab the current working directory and use that to store \"garbage.tmp\". This will be the file where the\r\nscraped credit card numbers are staged.\r\nThe malware uses a pretty typical combination of GetCurrentProcessId -\u003e EnumProcesses -\u003e OpenProcess -\u003e\r\nVirtualQueryEx -\u003e ReadProcessMemory to peer into process memory space to capture unencrypted credit card information\r\nthat is sitting in RAM.\r\nChunks of memory are then passed to a function that is responsible for parsing out the track information. The function will\r\nlook for common sentinels and be responsible for identifying track 1 and track 2 data.\r\nSetting a breakpoint within the function will allow us to see the data being passed around in a buffer.\r\nhttps://github.com/malware-kitten/securitykitten.github.io/blob/master/_posts/2015-01-11-the-mozart-ram-scraper.md\r\nPage 2 of 5\n\nAll results are then passed to a function that will use Luhn's algorithm to validate the code (utilizing a lookup table). This is\r\nthe defacto algorithm for credit card validation and is a common component in many credit card scraping utilities. A\r\nscreenshot of Luhn's pseudocode can be seen below:\r\nOnce the data is validated, it is passed to an encoding function that is responsible for doing an ADD and base64 to encode\r\nthe data and output it to a file. The key that is used for the ADD operation is the string \"java.exe\". The encoded information\r\nis then stored in garbage.tmp and multiple entries are delimited by '|'\r\nA decoder can be written for the data in garbage.tmp using ruby. The following script will decode track information.\r\n{% highlight ruby %} {% raw %}\r\n#!/usr/bin/ruby\r\nrequire 'base64'\r\nencoded =\r\n\"npmumWSVq5ahkayRZZerncippbGMla2Vn5Kmkl6VqJWakaaRXpWpl5qUp5pfnaiam5qnkV6VqJWa|npmumWSVq5ahkayRZZernaeRq5FjlqiWm5O\r\nitems = encoded.split('|') items.each do |elem| decoded = Base64.decode64(elem) key = (\"java.exe\"*10).split(//).map {|x|\r\nx.ord} count = 0\r\ndecoded.each_byte do |char|\r\nprint \"#{(char - key[count]).chr}\"\r\ncount += 1\r\nend\r\nputs\r\nend\r\n{% endraw %} {% endhighlight %}\r\nWhich when ran, will echo back our track data\r\n{% highlight bash %} {% raw %}\r\nhttps://github.com/malware-kitten/securitykitten.github.io/blob/master/_posts/2015-01-11-the-mozart-ram-scraper.md\r\nPage 3 of 5\n\nruby ./decode.rb 4888603170607238^H/P^050510100000000001203191805191000000\r\n4888603170607238=05051011203191805191\r\n{% endraw %} {% endhighlight %}\r\nThe data that is stored in garbage.tmp will be appended to the file at the hardcoded path\r\n\"\\STWISM\\DeviceUpdates\\500\\athena.dll\". This is particularly interesting as it appears STWISM is the internal name of a\r\nserver. By having the POS systems dump data to a single location, the attackers needed to retrieve data only from a single\r\nspot rather than re-visiting each point of sale machine.\r\nThis is done on a random time schedule that is seen (in pseudo code) below, where the malware will check the local time\r\nand compare it with the random value. When the backup function is finished, a new value is generated. The numbers that are\r\ngenerated correspond to regular working hours between 09:00 and 18:00.\r\nOddities\r\nSimilar to FrameworkPOS, Mozart contains anti-American messages, including two links to the following sites:\r\nhttp://www.the-philosopher.co.uk/whocares/popups/warcrimes.htm\r\nhttp://academic.evergreen.edu/g/grossmaz/interventions.html\r\nAnd a message of \"America's Deadliest Export: Democracy\". These aren't referenced by code or used in anyway. This is the\r\nassumed mechanism the author is using to let the analyst known his/her sentiments.\r\nAnother oddity that could give away information about the author is the name of the PDB (debugging symbols) that was\r\nused when they were building this file.\r\nz:\\Slender\\mozart\\mozart\\Release\\mozart.pdb\r\nThere have been plenty of reports speculating information about the Slender persona, so it would be redundant information\r\nto dive into that here.\r\nDetection\r\nWhile this is an older piece of malware, detecting it is still important. At the time of this writing it's scoring 34/56 on\r\nVirustotal. In earlier December it was scoring much more poorly with a total of 5/56. While sharing malware may not be in\r\nthe interest of the customer, this goes to show that even the AV vendors were not in the loop.\r\nThe following yara rule will detect this variant of Mozart:\r\nrule Mozart\r\n{\r\n meta:\r\n author = \"Nick Hoffman\"\r\n description = \"Detects samples of the Mozart POS RAM scraping utility\"\r\n strings:\r\n $pdb = \"z:\\\\Slender\\\\mozart\\\\mozart\\\\Release\\\\mozart.pdb\" nocase wide ascii\r\n $output = {67 61 72 62 61 67 65 2E 74 6D 70 00}\r\n $service_name = \"NCR SelfServ Platform Remote Monitor\" nocase wide ascii\r\n $service_name_short = \"NCR_RemoteMonitor\"\r\n $encode_data = {B8 08 10 00 00 E8 ?? ?? ?? ?? A1 ?? ?? ?? ?? 53 55 8B AC 24 14 10 00 00 89 84 24 0C 10 00 00 56 8B\r\n condition:\r\n any of ($pdb, $output, $encode_data) or\r\n all of ($service*)\r\n}\r\nhttps://github.com/malware-kitten/securitykitten.github.io/blob/master/_posts/2015-01-11-the-mozart-ram-scraper.md\r\nPage 4 of 5\n\nThe signature will look for the service names, the filename garbage.tmp, the build path and the encoding routine used to\r\nobfuscate credit card numbers.\r\nConclusion\r\nThe malware was compiled on 2014:04:10 18:12:41-04:00. The first rumors of (in the public space) the Home Depot breach\r\nwas in September. This gives an idea of potentially how long this malware had access to credit card numbers before being\r\ndiscovered.\r\nTo me, one of the most surprising things about this malware is how long it was hidden from the malware analyst community.\r\nThere was a high profile hack, and in the interest of non-disclosure, samples were not shared. It should be an obvious\r\nstatement that this does not enable the security community and the clients they are protecting, but rather leaves them\r\ndefenseless as they can't guard against what they don't know.\r\nIn terms of the malware, this uses fairly common techniques and employs simple protections to prevent itself from being\r\ncaught. The malware does not utilize a packer and it'll hide in plainsight by using a service name that looks legitimate.\r\nUnlike Dexter, the malware doesn't use process injection that could potentially set off anti-virus engines. A combination of\r\nusing Windows networking and only transferring files during work hours, this malware was able to remain undetected for\r\nquite some time, proving simplicity is the ultimate sophistication.\r\nSource: https://github.com/malware-kitten/securitykitten.github.io/blob/master/_posts/2015-01-11-the-mozart-ram-scraper.md\r\nhttps://github.com/malware-kitten/securitykitten.github.io/blob/master/_posts/2015-01-11-the-mozart-ram-scraper.md\r\nPage 5 of 5",
	"extraction_quality": 1,
	"language": "EN",
	"sources": [
		"Malpedia"
	],
	"origins": [
		"web"
	],
	"references": [
		"https://github.com/malware-kitten/securitykitten.github.io/blob/master/_posts/2015-01-11-the-mozart-ram-scraper.md"
	],
	"report_names": [
		"2015-01-11-the-mozart-ram-scraper.md"
	],
	"threat_actors": [],
	"ts_created_at": 1775791282,
	"ts_updated_at": 1775826678,
	"ts_creation_date": 0,
	"ts_modification_date": 0,
	"files": {
		"pdf": "https://archive.orkl.eu/799321594e209168b177b24890f8d4795a4e055b.pdf",
		"text": "https://archive.orkl.eu/799321594e209168b177b24890f8d4795a4e055b.txt",
		"img": "https://archive.orkl.eu/799321594e209168b177b24890f8d4795a4e055b.jpg"
	}
}