{
	"id": "ba01aab0-b85f-48f1-9935-4ecef961adc1",
	"created_at": "2026-04-06T01:29:25.085382Z",
	"updated_at": "2026-04-10T03:35:21.475735Z",
	"deleted_at": null,
	"sha1_hash": "c2eea6a82cdc7220b159fad9af1a709a175d4723",
	"title": "SafePay: The new kid on the block",
	"llm_title": "",
	"authors": "",
	"file_creation_date": "0001-01-01T00:00:00Z",
	"file_modification_date": "0001-01-01T00:00:00Z",
	"file_size": 1026515,
	"plain_text": "SafePay: The new kid on the block\r\nBy DCSO CyTec Blog\r\nPublished: 2025-05-27 · Archived: 2026-04-06 01:00:05 UTC\r\n12 min read\r\nMay 27, 2025\r\nEarlier this year, DCSO was made aware of a security incident at one of our clients that was part of a ransomware\r\ncampaign by the actor SafePay. While there is limited reporting on the group available, DCSO uncovered\r\nadditional new information on the ransomware variant in the incident response case.\r\nExecutive summary:\r\nSafePay focusing on Germany and US, utilizing the double-extortion scheme (data theft and encryption)\r\nThe ransomware does not shy away from contacting victims directly (e.g. via phone calls) to increase\r\npressure\r\nSafePay ransomware shares similarities with other ransomware strains, however, we believe that this is due\r\nto inspiration not because of same origin\r\nWe provide tooling for configuration extraction, aiding the analysis of the ransomware characteristics\r\nPress enter or click to view image in full size\r\nSafePay Leak Site\r\nBlog post authored by Johann Aydinbas, Bennet Conrads, Moaath Oudeh and Denis Szadkowski\r\nBackground\r\nhttps://medium.com/@DCSO_CyTec/safepay-the-new-kid-on-the-block-4141188a626d\r\nPage 1 of 11\n\nThe SafePay ransomware group is a relatively new group, first appearing on our radar in November 2024. During\r\nthat period, the group was first reported on by researchers at Huntress. The group follows a double-extortion\r\nscheme, both exfiltrating data and encrypting it on victim machines using their own SafePay ransomware.\r\nRecent focus of SafePay group on Germany and the US — Source: ecrime.ch\r\nAt the time of writing, SafePay lists 169 victims on their leak site, with the targets predominantly based in Central\r\nEurope and North America, and a low number of targets located in Asia. The main focus of the group appears to\r\nbe Germany and the United States, with Germany having seen multiple batches of victims listed recently and\r\ncurrently making up almost 18% of the victims, taking up the spot of most targeted in recent additions. The\r\nleak site has been updated in early May 2025 with the latest data for download having been posted on April 24th,\r\nshowing fairly recent activity of the group.\r\nPress enter or click to view image in full size\r\nVictim country distribution of SafePay group — Source: ecrime.ch\r\nTheir leak site features a headline stating that “SafePay Ransomware has never and does not provide the RaaS”.\r\nRaaS (ransomware as a service) systems usually delegate some tasks or compromises to partners of affiliates\r\neither for a monthly subscription or one-time fee to use the ransomware. Other variants of the RaaS revenue\r\nmodel include affiliate programs in which affiliates who compromise networks share profits from the extortion\r\nwith the developers of the ransomware.\r\nSafePay ransomware\r\nTo encrypt victim data, SafePay employs a custom ransomware strain of the same name. Encrypted files exhibit\r\nthe characteristic “.safepay” extension while the ransom note is named “readme_safepay.txt” correspondingly.\r\nhttps://medium.com/@DCSO_CyTec/safepay-the-new-kid-on-the-block-4141188a626d\r\nPage 2 of 11\n\nCompared to earlier reporting, the SafePay ransomware introduced a victim ID which is provided in their updated\r\nransom note and used to log in to their portal to initiate contact.\r\nPress enter or click to view image in full size\r\nUpdated ransom note with victim ID in blue\r\nThe ransom note appears to be original and not taken or copied from other ransomware incidents as it features\r\nunique wording. An interesting statement in the note is the group stating that they “[…] are not a politically\r\nmotivated group and want nothing more than money”. Groups, e.g. LockBit, have insisted on being apolitical,\r\nwhile other ransomware groups have explicitly announced political objectives or official support of government\r\ngoals as was the case with the Conti ransomware group announcing their “full support” for the Russian\r\ngovernment in 2022.\r\nA detailed analysis of the SafePay ransomware follows below.\r\nField Observations\r\nDuring the IR engagement earlier this year, DCSO’s Incident Response Team (D.I.R.T.) observed several notable\r\nfindings, related to SafePay ransomware TTPs:\r\nThe SafePay ransomware group tried to increase pressure on the affected client by making direct phone\r\ncalls after encrypting the environment, aiming to coerce a faster response or payment.\r\nThere was a 25-day gap between the initial access — achieved through password spraying against the VPN\r\ngateway — and the first discovery activities, which may suggest that the ransomware group was either\r\npreoccupied with other operations, operating with limited resources or relying on initial access brokers.\r\nhttps://medium.com/@DCSO_CyTec/safepay-the-new-kid-on-the-block-4141188a626d\r\nPage 3 of 11\n\nThe remote workstation “WIN-3IUUOFVTQAR” used by the attackers to access the environment matches\r\nthe one identified in the intrusion investigated by Huntress, which indicates bad operational security\r\n(opsec) practices by the attackers.\r\nThe collection activities were conducted in a targeted manner, focusing on critical business data; the\r\nattackers used SharpShares to identify accessible file shares, employed WinRAR to compress the collected\r\ndata, and successfully exfiltrated 450 GB of data by unknown means.\r\nThe attackers actively searched for backup solutions in the affected environment and encrypted them, in\r\naddition to deleting Volume Shadow Copies (VSC), all in an effort to inhibit recovery activities and\r\nmaximize the impact of the attack.\r\nAll encryption activities happened within virtual machines (VMs), although the attackers were in the\r\npossession of the necessary privileges to perform encryption of the VMs on the hypervisor level. This\r\ncould indicate that the SafePay ransomware group at the time of writing was not in the possession of a\r\nransomware variant compatible with hypervisors such as VMware ESXi.\r\nIt took the SafePay ransomware group 26 days from initial access to obtain Domain Admin privileges, with\r\nminimal observable activity during the first 25 days post-compromise; once Domain Admin was achieved,\r\nthey completed data collection, exfiltration, and encryption within just two days.\r\nAll in all, D.I.R.T. rates the overall level of sophistication of the SafePay ransomware group as intermediate, given\r\nthe extended periods of inactivity post-compromise, reliance on publicly available tools, lack of advanced evasion\r\ntechniques, bad opsec practices, and the apparent unavailability of a VMware ESXi ransomware variant to encrypt\r\nVMs directly from the hypervisor.\r\nIn-Depth Analysis of SafePay Ransomware\r\nThe SafePay ransomware is written in C and built around Overlapped I/O, which is the Windows solution for\r\nasynchronous I/O. Files are enumerated and encrypted using multiple separate threads, the specific number\r\ndepending on the processor count.\r\nSuccessful execution of the ransomware requires passing the victim ID as key phrase via command line argument\r\n-pass . It is used to decrypt the internal configuration data, such as what processes to kill or directories to skip.\r\nWe have written a config extraction tool which is described below in more detail.\r\nFile encryption uses a symmetric cipher to encrypt an alternating stream of 1MB chunks, while Elliptic Curves are\r\nused to encrypt the key material. The exact number of chunks encrypted/skipped is controlled by specifying an\r\nencryption level via the -enc \u003c1-10\u003e command line switch, providing a way to perform so-called partial\r\nencryption of files for the purpose of speed.\r\nPress enter or click to view image in full size\r\nhttps://medium.com/@DCSO_CyTec/safepay-the-new-kid-on-the-block-4141188a626d\r\nPage 4 of 11\n\nSafePay choosing the symmetric cipher at runtime\r\nThe choice of symmetric cipher depends on the availability of AES-NI — if the CPU supports AES instructions,\r\nSafePay will pick AES-CBC, otherwise ChaCha20 is used to encrypt files. This appears to be an upgrade\r\ncompared to previous reporting by Huntress. In addition, we noticed SafePay no longer has a Cyrillic language\r\nkillswitch as documented by Huntress.\r\nSafePay encrypts every file using a separate key which is generated using RtlGenRandom (aka\r\nSystemFunction036 ). An 80 byte meta data blob is attached to each encrypted file with the following format:\r\n[8 byte file size]\r\n[32 byte ECC master public key]\r\n[32 byte file ECC public key]\r\n[1 byte encryption level]\r\n[1 byte is ChaCha used?]\r\n[6 byte unused]\r\nFor research purposes and testing we have reimplemented the decryption algorithm for a modified ECC master\r\nkey. You can find the Python script on our GitHub.\r\nComparison to other ransomware\r\nThe SafePay ransomware has similarities to a multitude of other ransomware families. Notable is the architectural\r\nsimilarity to LockBit3 (LockBit Black), with both ransomware strains using Overlapped I/O, a very similar state\r\nmachine to encrypt files, and similar import resolution structure and data structures used to manage files to\r\nencrypt.\r\nHowever, based on our research, we believe SafePay to be independently developed, but likely influenced by\r\nexisting ransomware.\r\nDuring our analysis, we have extracted SafePay’s cryptographic primitives and used the most excellent\r\nransomware tooling repository by rivitna to compare it to other ransomware:\r\nhttps://medium.com/@DCSO_CyTec/safepay-the-new-kid-on-the-block-4141188a626d\r\nPage 5 of 11\n\nSafePay uses SHA512 as its key derivation function. This is a rare occurrence and only shared with Hive,\r\nDarkBit and Inc. ransomware\r\nSafePay uses a specific CRC32 polynomial 0x4c11db7 for import resolution — the same specific\r\npolynomial is used in Proxima and Babuk, though both use a differing starting value (SafePay: 0xFF,\r\nProxima/Babuk: 0xFFFFFFFF)\r\nSafePay uses MurmurHash, also used by Conti\r\nFor ECC, SafePay uses Curve25519 which is not uncommon, same as the usage of ChaCha20 and AES-CBC\r\nLockBit3 (LockBit Black) uses ChaCha20 as well, but employs RSA instead of ECC\r\nBased on this we believe SafePay might have been developed independently from any source or builder leak but\r\nlikely may have taken inspiration from other ransomware strains.\r\nReversing Obfuscated Stack Strings with Ghidra\r\nWhile analyzing the binary, we encountered a common obfuscation technique known as stack strings. These are\r\nstrings constructed on the stack at runtime to evade static detection. We decided to try out Ghidra’s recently\r\nimproved Python scripting add-on (PyGhidra) to automate the decoding.\r\nWhat are stack strings?\r\nStack strings are strings constructed at runtime by placing individual bytes directly onto the stack, rather than\r\ndefining them as static string literals. This technique is often used by malware authors to evade detection and\r\nhinder static analysis.\r\nFigure 1 — Example stack string deobfuscation\r\nFigure 1 illustrates an example of this type of string obfuscation. In this case, the string is initialized using raw\r\nbyte values, which are later resolved through a while loop. The loop performs the following steps for each byte:\r\nXORs the byte with its index in the array.\r\nhttps://medium.com/@DCSO_CyTec/safepay-the-new-kid-on-the-block-4141188a626d\r\nPage 6 of 11\n\nThen XORs the result with the first character of the kernel32.dll header (which is “M”, since Windows PE\r\nfiles begin with “MZ”).\r\nFinally, XORs the result with a constant byte specific to the string (in this case, 0x37).\r\nAfter deobfuscation, the resulting string is revealed to be “advapi32.dll”, which is then stored in the obf_str\r\nvariable.\r\nHow to find the stack strings via pattern matching\r\nSince the binary uses XOR operations to obfuscate strings, one effective method of detection is to look for\r\nrecognizable instruction patterns.\r\nFigure 2 —\r\nIn Ghidra, you can search for specific byte patterns in the disassembly. Wildcard bytes can be represented using\r\n??, allowing for more flexible matching. For example, the pattern 32 ?? 32 ?? 34 ?? proved useful in identifying\r\nthe XOR-based obfuscation sequences across the binary.\r\nFigure 3 —\r\nBy reviewing the results, we noticed a recurring instruction pattern surrounding the obfuscated strings. Typically,\r\nthese sequences began with:\r\nMOV EDX, dword ptr [0x10015ff8]\r\nAnd ended with a conditional jump instruction, such as:\r\nJC \u003cVALUE\u003e\r\nhttps://medium.com/@DCSO_CyTec/safepay-the-new-kid-on-the-block-4141188a626d\r\nPage 7 of 11\n\nUpon further analysis, we discovered two additional variants of the starting instruction:\r\nMOV EAX, [0x10015ff8]\r\nMOV ECX, dword ptr [0x10015ff8]\r\nAutomating the task\r\nWhile analyzing the binary, it quickly became evident that there were over a hundred obfuscated stack strings.\r\nManually resolving each one would be extremely time-consuming and inefficient, so we decided to automate it.\r\nGet DCSO CyTec Blog’s stories in your inbox\r\nJoin Medium for free to get updates from this writer.\r\nRemember me for faster sign in\r\nSince our analysis was being conducted in Ghidra, we leveraged a relatively new feature called PyGhidra. Unlike\r\nearlier versions that only supported Java or Jython, PyGhidra allows you to write and run Ghidra scripts using\r\nstandard Python — making scripting more accessible and flexible.\r\nOn a high level, the script works like this:\r\nTraverse the binary and identify all stack strings based on known instruction patterns.\r\nSimulate each snippet and resolve the obfuscated strings\r\nSave the decoded results for further analysis\r\nTo locate stack strings using above identified patterns, we used Ghidra’s built-in APIs. For emulating and\r\nexecuting the snippets, we used Unicorn, a lightweight, multi-platform CPU emulator based on QEMU. It\r\nallowed us to simulate execution of individual instructions in isolation without running the actual binary.\r\nFinally, the script was executed using Ghidra’s headless mode via PyGhidra.\r\nFigure 4 — Example output\r\nResults\r\nhttps://medium.com/@DCSO_CyTec/safepay-the-new-kid-on-the-block-4141188a626d\r\nPage 8 of 11\n\nThe script successfully identified 117 unique stack strings and resolved 116 of them. One string failed during\r\nemulation due to a more complex instruction sequence that Unicorn couldn’t handle out-of-the-box.\r\nHandling emulation constraints\r\nSince Unicorn doesn’t have access to Ghidra’s memory layout, it couldn’t resolve the address 0x10015FF8 (which\r\npoints to the kernel32.dll during runtime) during emulation. To work around this, we patched the instruction to\r\nload the expected value — ‘M’ (the first character of the “MZ” header) — directly into the register. This allowed\r\nthe emulation to continue and the string to be resolved correctly.\r\nYou can find the full script on our GitHub repository, including instructions on how to run it in headless PyGhidra\r\nand configure Unicorn.\r\nExtracting the config:\r\nThe SafePay binary contains a built-in configuration that guides its behavior — such as which files or directories\r\nto encrypt, which system locations to avoid as well as the ransom note.\r\nHowever, this configuration isn’t stored in plaintext. Instead, it’s encrypted within the binary, making it invisible\r\nduring inspection.\r\nAfter analyzing the binary’s decryption logic, we were able to reverse-engineer how the config is retrieved at\r\nruntime. Using this understanding, we developed a script that extracts and decrypts the config directly from the\r\nbinary, without needing to execute it.\r\nThe script relies on two inputs:\r\n1. The pass key (aka victim ID):\r\nThis key can be found in the ransom note and is used by the victim to login into the portal. It is also\r\nspecified as the -pass parameter, which is provided to the malware at runtime by the attacker.\r\n2. The corresponding binary:\r\nThis needs to be the binary that generated the ransom note.\r\nThe script locates the encrypted blob, applies the correct decryption algorithm, and outputs the configuration\r\ncomponents in a readable format.\r\nLayout of the config data:\r\nThe encrypted configuration is stored in its own dedicated section within the binary. In our sample, this section\r\nwas named .debug\r\nThe layout of the section is as follows:\r\nFirst 4 bytes: A MurmurHash checksum. This hash is used to verify if the data was decrypted\r\nsuccessfully.\r\nNext 4 bytes: A length field indicating the size of the encrypted config payload. This length usually\r\nmatches the number of remaining bytes in the section.\r\nhttps://medium.com/@DCSO_CyTec/safepay-the-new-kid-on-the-block-4141188a626d\r\nPage 9 of 11\n\nRemaining bytes: The encrypted config data itself.\r\nNote to IDA users: Likely due to the name .debug, IDA doesn’t load the section into memory by default which can\r\nlead to confusion analyzing the binary as the entire section will be missing and memory references point to non-existing data. This can be fixed by checking “manual load” when first loading the binary, followed by confirming\r\nloading of the .debug section:\r\nManual load popup for the .debug section\r\nDecrypting the config\r\nThe malware uses a combination of cryptographic and hashing algorithms to decrypt the data. These include:\r\nSHA-512 — to derive the encryption key and nonce\r\nChaCha20 — the stream cipher used to encrypt/decrypt the data\r\nMurmurHash — to validate the integrity of the decrypted config\r\nTo decrypt the config, the malware follows a specific sequence:\r\nHash the pass key using SHA-512.\r\nTake the first 56 bytes of the SHA-512 hash:\r\nThe first 32 bytes are used as the ChaCha20 key.\r\nThe remaining 24 bytes serve as the nonce.\r\nInitialize the ChaCha20 cipher with the key and nonce.\r\nDecrypt the payload using the cipher.\r\nVerify the result by comparing its MurmurHash (seed: 0xFFFFFFFF, result must be unsigned) to the\r\nhash stored at the beginning of the config section.\r\nWhat’s inside the config?\r\nOnce decrypted, the configuration reveals various parameters used by the ransomware to control its behavior:\r\nDefault mutex\r\nRansom file extension\r\nIgnored extensions\r\nIgnored files\r\nIgnored directories\r\nProcesses to terminate\r\nhttps://medium.com/@DCSO_CyTec/safepay-the-new-kid-on-the-block-4141188a626d\r\nPage 10 of 11\n\nServices to terminate\r\nThe ransom note\r\nYou can find the config decryptor on our GitHub repository, including instructions on how to run it.\r\nConclusion\r\nSafePay is a relatively new ransomware actor that appeared around October 2024. They use a custom ransomware\r\nthat we believe is independently developed but possibly influenced by other existing ransomware families.\r\nRecently, they seem to focus their attacks on Germany and the United States.\r\nWe analyzed the ransomware in detail, extracted the cryptographic primitives in use and wrote tooling that aid in\r\nunderstanding the ransomware, which we want to share with the community.\r\nSource: https://medium.com/@DCSO_CyTec/safepay-the-new-kid-on-the-block-4141188a626d\r\nhttps://medium.com/@DCSO_CyTec/safepay-the-new-kid-on-the-block-4141188a626d\r\nPage 11 of 11",
	"extraction_quality": 1,
	"language": "EN",
	"sources": [
		"Malpedia"
	],
	"references": [
		"https://medium.com/@DCSO_CyTec/safepay-the-new-kid-on-the-block-4141188a626d"
	],
	"report_names": [
		"safepay-the-new-kid-on-the-block-4141188a626d"
	],
	"threat_actors": [
		{
			"id": "8e1bae2f-2a21-4ba8-a6f1-42155f96aec8",
			"created_at": "2022-10-25T16:07:23.645758Z",
			"updated_at": "2026-04-10T02:00:04.700158Z",
			"deleted_at": null,
			"main_name": "Flying Kitten",
			"aliases": [
				"Ajax Security Team",
				"Flying Kitten",
				"G0130",
				"Group 26",
				"Operation Saffron Rose"
			],
			"source_name": "ETDA:Flying Kitten",
			"tools": [
				"Stealer"
			],
			"source_id": "ETDA",
			"reports": null
		},
		{
			"id": "2864e40a-f233-4618-ac61-b03760a41cbb",
			"created_at": "2023-12-01T02:02:34.272108Z",
			"updated_at": "2026-04-10T02:00:04.97558Z",
			"deleted_at": null,
			"main_name": "WildCard",
			"aliases": [],
			"source_name": "ETDA:WildCard",
			"tools": [
				"RustDown",
				"SysJoker"
			],
			"source_id": "ETDA",
			"reports": null
		},
		{
			"id": "f4d7cba1-dbdd-42a9-88c5-4d0c81659ee0",
			"created_at": "2023-01-06T13:46:38.357581Z",
			"updated_at": "2026-04-10T02:00:02.941254Z",
			"deleted_at": null,
			"main_name": "Flying Kitten",
			"aliases": [
				"Saffron Rose",
				"AjaxSecurityTeam",
				"Ajax Security Team",
				"Group 26",
				"Sayad",
				"SaffronRose"
			],
			"source_name": "MISPGALAXY:Flying Kitten",
			"tools": [],
			"source_id": "MISPGALAXY",
			"reports": null
		},
		{
			"id": "256a6a2d-e8a2-4497-b399-628a7fad4b3e",
			"created_at": "2023-11-30T02:00:07.299845Z",
			"updated_at": "2026-04-10T02:00:03.484788Z",
			"deleted_at": null,
			"main_name": "WildCard",
			"aliases": [],
			"source_name": "MISPGALAXY:WildCard",
			"tools": [],
			"source_id": "MISPGALAXY",
			"reports": null
		}
	],
	"ts_created_at": 1775438965,
	"ts_updated_at": 1775792121,
	"ts_creation_date": 0,
	"ts_modification_date": 0,
	"files": {
		"pdf": "https://archive.orkl.eu/c2eea6a82cdc7220b159fad9af1a709a175d4723.pdf",
		"text": "https://archive.orkl.eu/c2eea6a82cdc7220b159fad9af1a709a175d4723.txt",
		"img": "https://archive.orkl.eu/c2eea6a82cdc7220b159fad9af1a709a175d4723.jpg"
	}
}