{
	"id": "9c0c10e6-d4f4-402a-96d0-a35891846010",
	"created_at": "2026-04-06T00:14:19.000003Z",
	"updated_at": "2026-04-10T03:29:40.163189Z",
	"deleted_at": null,
	"sha1_hash": "9d1290f611907c2228a753ac20bb4f26b1c9c812",
	"title": "It’s Not Safe To Pay SafePa | Huntress",
	"llm_title": "",
	"authors": "",
	"file_creation_date": "0001-01-01T00:00:00Z",
	"file_modification_date": "0001-01-01T00:00:00Z",
	"file_size": 3074516,
	"plain_text": "It’s Not Safe To Pay SafePa | Huntress\r\nArchived: 2026-04-05 18:13:35 UTC\r\nBackground\r\nDuring October 2024, Huntress analysts observed two incidents involving the deployment of SafePay ransomware\r\nacross disparate customer infrastructures separated by business vertical and geography. In both incidents, the\r\nencrypted file extension was .safepay, and the name of the ransom note was readme_safepay.txt, something that\r\nHuntress analysts had not previously observed. Further, following the first incident, analysts were unable to locate\r\nany open reporting on this particular ransomware variant.\r\nDark Web Presence\r\nThe SafePay ransomware group is a more obscure cybercrime gang than others, and for that reason, there is not\r\nmuch discussion surrounding SafePay on illicit forums or chat rooms.\r\nThey do include a V3 onion link to their leak site in their ransom note, however, as well as a less common link to\r\na “TON” site—apparently, “The Open Network” which claims to be a \"decentralized and open internet, created by\r\nthe community using a technology designed by Telegram.\"\r\nTheir Tor leak site simply lists past victims to be clicked on and expanded for more details.\r\nFigure 1: The SafePay ransomware leak site\r\nAt the time of writing, there are 22 victims listed. Clicking on their name opens a modal to either download a text\r\nfile that lists the filenames and folder structure for the stolen data, or the data itself if it is available. Their\r\ndownload folder is susceptible to directory indexing:\r\nhttps://www.huntress.com/blog/its-not-safe-to-pay-safepay\r\nPage 1 of 14\n\nFigure 2: Directory listing of the leak site’s download folder\r\nAdditionally, the Apache server status endpoint is still accessible and exposes some further details about the\r\nbackend server.\r\nFigure 3: Apache server status\r\nIncident 1\r\nhttps://www.huntress.com/blog/its-not-safe-to-pay-safepay\r\nPage 2 of 14\n\nDuring incident 1, the first observed indication of the threat actor’s activity was an attempt to run\r\nShareFinder.ps1, which was detected and blocked by Windows Defender. The threat actor had accessed the\r\nendpoint via the Remote Desktop Protocol (RDP), and as such, disabled Windows Defender using the same\r\nsequence of LOLBin commands observed during an INC ransomware deployment incident earlier this year and\r\nwas then able to run the ShareFinder.ps1 PowerShell script.\r\nAbout 40 minutes later, the same user archived files from the host with WinRAR.exe. An example command line\r\nof the attacker archiving files can be seen as follows:\r\nWinRAR.exe  a -v5g -ed -r -tn1000d -m0 -mt5 -x*.rar -x*.JPEG -x*.RAW\r\n-x*.PSD -x*.TIFF -x*.BMP -x*.GIF -x*.JPG -x*.MOV -x*.pst -x*.FIT\r\n-x*.FIL -x*.mp4 -x*.avi -x*.mov -x*.mdb -x*.iso -x*.exe -x*.dll\r\n-x*.bak -x*.msg -x*.png -x*.zip -x*.ai -x*.7z -x*.DPM -x*.log -x*.dxf\r\n-x*.insp -x*.upd -x*.db -x*.dwg -x*.nc1 -x*.metadata -x*.dg -x*.inp\r\n-x*.dat -x*.TIFF -x*.tiger -x*.pcp -x*.rvt -x*.rws -x*.nwc -x*.tif\r\n-x*.frx -x*.dyf -x*.rcs -x*.diff C:\\[redacted].rar\r\n\\\\[redacted]\\C$\\Users\\\r\nThis was observed across three different hosts (remotely archiving files from user directories on other hosts).\r\nA short time after that, FileZilla was installed using FileZilla_3.67.1_win64_sponsored-setup.exe, and\r\nfilezilla.exe and fzsftp.exe both executed after that. They were quickly uninstalled as well.\r\nFigure 4: Process tree of uninstalling WinRAR\r\nFigure 5: Process tree of uninstalling FileZilla\r\nThe following day, this process repeated (WinRAR and FileZilla installed, executed, and uninstalled). \r\nhttps://www.huntress.com/blog/its-not-safe-to-pay-safepay\r\nPage 3 of 14\n\nThis activity looks like potential Data Exfiltration from the network—collected and archived with WinRAR and\r\nthen possibly exfiltrated out using FTP (no network evidence of this activity was collected).\r\nFinally, on the second day following the use of the PowerShell script, the threat actor returned, logging in via\r\nRDP, and within approximately 15 minutes, began executing several commands that deployed file encryption via\r\npreviously identified network shares. An example of one of those commands appeared as follows:\r\n\"C:\\Windows\\SysWOW64\\regsvr32.exe\" /n \"/i:-pass=[REDACTED] -enc=3 -uac -path=\\\\[REDACTED]\\\r\n[SHARE]\\  -uac=[REDACTED]\" C:\\locker.dll\r\nThe Huntress platform generated alerts for this activity, as illustrated in Figure 6.\r\nFigure 6: Ransomware Deployment Alerts\r\nFollowing these alerts, the following commands were observed as part of the ransomware execution:\r\nbcdedit / set{default} recoveryenabled no\r\nwmic shadowcopy delete\r\nBoth of these commands were detected and alerted via the Huntress platform, but by that point, the file encryption\r\nprocess was already underway.\r\nIncident 2\r\nWhile investigating incident 2, analysts determined that the Huntress agent deployment was extremely limited,\r\ninhibiting visibility, detection, and response.\r\nHuntress analysts did note that there was an initial successful network login to the Administrator account,\r\noriginating from the threat actor workstation WIN-3IUUOFVTQAR, which was then followed by multiple failed\r\nlogin attempts to the non-existent Work user account, from the same workstation. Following this activity, the\r\nAdministrator account was used to successfully log in via the Remote Desktop Protocol (RDP).\r\nHuntress analysts were not able to recover a copy of the ransomware executable during this incident due to the\r\nfact that the file encryption deployment likely occurred from another endpoint that did not have an agent installed.\r\nThis is supported by the fact that during incident 1, the ransomware was deployed via UNC paths.\r\nAlso during this incident, there was no indication that the threat actor attempted to disable Windows Defender.\r\nRather, in this instance, Windows Defender did detect the ransomware process, but recorded a Microsoft-Windows-Windows Defender/1119 failure event, as illustrated in Figure 7.\r\nhttps://www.huntress.com/blog/its-not-safe-to-pay-safepay\r\nPage 4 of 14\n\nFigure 7: Windows Defender Error Message\r\nUnfortunately, the ransomware execution was not prevented, and as with the first incident, ransomware canary\r\nfiles were modified, prompting additional reporting from the Huntress SOC.\r\nReverse Engineering\r\nDuring our analysis of the ransomware binary, we began to notice a large number of similarities to the extensively\r\nanalyzed Lockbit samples from the end of 2022. This isn’t particularly surprising given that the source for Lockbit\r\nhas been leaked several times.\r\nUsage\r\nThe ransomware is run via regsrv32.exe and accepts the following flags:\r\n                                                                                                           \r\nFlag Usage\r\n-uac UAC bypass flag\r\n-selfdelete Enable self-delete flag\r\n-network Network propogation\r\n-logging Enable logging\r\n-pass Password\r\nhttps://www.huntress.com/blog/its-not-safe-to-pay-safepay\r\nPage 5 of 14\n\n-netdrive Network drive flag\r\n-path Path for files to encrypt\r\n-enc Encryption level\r\nCyrillic Language Killswitch\r\nAs is relatively common for ransomware, before executing encryption on a host, the malware attempts to verify\r\nthat it isn’t running in any Eastern European countries. It does this by calling GetSystemDefaultUILanguage and\r\nchecking that the resulting language ID is greater than the Cyrillic language IDs, as seen in Figure 8.\r\nFigure 8: Code showing a Russian language check\r\nString Encryption\r\nMost of the strings throughout the binary are obfuscated with a simple three-step XOR loop consisting of a\r\nrandom single-byte key, the index of the character, and the first byte of kernel32.dll (‘M’).\r\ndef xor_decrypt(enc: str, key: int) -\u003e str:\r\nenc_bytes = bytes.fromhex(enc)\r\ndecrypted = []\r\nfor idx, val in enumerate(enc_bytes):\r\nval ^= idx\r\nval ^= ord(\"M\")\r\nval ^= key\r\ndecrypted.append(val)\r\nhttps://www.huntress.com/blog/its-not-safe-to-pay-safepay\r\nPage 6 of 14\n\nreturn \"\".join([chr(i) for i in decrypted if i != 0])\r\nProcess Termination\r\nMalware attempts to stop certain processes that are running via ZwTerminateaProcess. Below is the list of\r\nprocesses that are attempted to stop: \r\nsql\r\noracle\r\nocssd\r\ndbsnmp\r\nsynctime\r\nagntsvc\r\nisqlplussvc\r\nxfssvccon\r\nmydesktopservice\r\nocautoupds\r\nencsvc\r\nfirefox\r\ntbirdconfig\r\nmydesktopqos\r\nocomm\r\ndbeng50\r\nsqbcoreservice\r\nexcel\r\ninfopath\r\nmsaccess\r\nmspub\r\nfar\r\nonenote\r\noutlook\r\npowerpnt\r\nsteam\r\nthebat\r\nthunderbird\r\nvisio\r\nwinword\r\nwordpad\r\nnotepad\r\nwuauclt\r\nonedrive\r\nsqlmangr\r\nhttps://www.huntress.com/blog/its-not-safe-to-pay-safepay\r\nPage 7 of 14\n\nService Termination\r\nRansomware attempts to stop services that are running via ControlService. Below are services it attempts to\r\nstop: \r\nvss\r\nsqlsvc\r\nmemtas\r\nmepocs\r\nmsexchange\r\nSophos\r\nVeeam\r\nbackup\r\nGxVss\r\nGxBlr\r\nGxFWD\r\nGxCVD\r\nGxCIMgr\r\nPrivilege Adjusting\r\nThis malware goes through the appropriate steps to enable SeDebugPrivilege for their current running token. This\r\nis done by the following APIs: ZwOpenProcessToken, LookupPrivilegeValueA, PrivilegeCheck, and\r\nAdjustTokenPrivileges. This is very common within malware, as setting SeDebugPrivilege circumvents certain\r\naccess checks to Windows objects. If you are curious about this, you can read more about this here.\r\nToken Impersonation\r\nOne of the ways that this malware likes to privilege escalate is through token impersonation. The way they are\r\nimplementing this is by calling DuplicateToken to obtain an impersonation (thread) token from a primary\r\n(process) token. We can see this in the code snippet below:\r\nBOOL result = DuplicateToken(ExistingTokenHandle: hProcessToken, ImpersonationLevel:\r\nSecurityImpersonation, DuplicateTokenHandle: \u0026g_duplicate_token_handle)\r\nHANDLE duplicate_token_handle = g_duplicate_token_handle\r\nAfter this token handle is set to a global variable, it is then used in another function that calls\r\nZwSetThreadInformation. Let’s take a look at how this is called:\r\nhThread = CreateThread(lpThreadAttributes: nullptr, dwStackSize: 0, lpStartAddress:\r\nnetwork_drive_parser, lpParameter: nullptr, dwCreationFlags: 4, lpThreadId: nullptr)\r\nhttps://www.huntress.com/blog/its-not-safe-to-pay-safepay\r\nPage 8 of 14\n\nif (hThread != 0)\r\nZwSetInformationThread(ThreadHandle: hThread, ThreadInformationClass: ThreadHideFromDebugger,\r\nThreadInformation: nullptr, ThreadInformationLength: 0)\r\nif (g_duplicate_token_handle != 0)\r\nZwSetInformationThread(ThreadHandle: hThread, ThreadInformationClass: ThreadImpersonationToken,\r\nThreadInformation: \u0026g_duplicate_token_handle, ThreadInformationLength: 4)\r\nNtResumeThread(ThreadHandle: hThread, SuspendCount: nullptr)\r\nWhat we can see above is that a thread is created in a suspended state via CreateThread, passing in\r\nCREATE_SUSPENDED in dwCreationFlags. The purpose of this thread is to enumerate and parse network\r\ndrives. If the thread is created successfully then the ThreadHideFromDebugger flag is set on the thread, which\r\nallows the thread to run without a debugger being able to trace the execution. Next, the duplicated token is set to\r\nthe thread via ZwSetInformationThread. Lastly, the thread is able to execute via NtResumeThread.\r\nThread Creation \u0026 Management\r\nIn order to increase the performance of the ransomware, SafePay (or Lockbit really) create a number of worker\r\nthreads for both encryption and network enumeration. The way they do this is interesting because in lieu of just a\r\nstandard CreateThread, they use a custom implementation that provides better anti-analysis capabilities.\r\nFigure 9: Decompilation of function that creates worker encryption threads\r\nIf logging is enabled it will return how many threads were created to the logfile. Finally, they clean up by freeing\r\nthe memory allocated for the thread pool, close the completion port, and release the crypto context. The cleanup\r\ncode can be seen in Figure 10.\r\nhttps://www.huntress.com/blog/its-not-safe-to-pay-safepay\r\nPage 9 of 14\n\nFigure 10: Cleanup code\r\nDetection Opportunities \r\nDefense Evasion\r\nWe observed the threat actor disabling some Windows Defender settings using the systemsettingsadminflows.exe\r\nbinary. In this case, the parent process of SystemSettings.exe shows that the changes were made using the\r\nWindows Settings GUI, typically accessed through the Menu. This indicates the threat actor was moving around\r\non the desktop interactively. While a user may do this occasionally as well, it is unlikely that most users would\r\nchange Windows Defender Virus \u0026 Threat Protection settings very often. These are settings such as Automatic\r\nFile Submission and Real-Time Threat Protection.\r\nhttps://www.huntress.com/blog/its-not-safe-to-pay-safepay\r\nPage 10 of 14\n\nFigure 11: Screenshot of Windows Defender settings\r\nNormally, these settings are set by Group Policy, Local Security Policies, or by custom configurations during\r\ninitial setup of the system. Changes made by Administrators will typically be made through PowerShell, direct\r\nregistry changes, or updates to Security Policies (not by clicking on toggle switches in the GUI). For many\r\nenvironments, this may be unusual enough to alert on every time it happens. We have provided the following\r\nSigma rules to detect this behavior:\r\nWindows Defender Threat Protection Settings Disabled via GUI\r\nWindows Defender Threat Protection Settings Disabled\r\nMany changes to Defender can be detected with Windows Event logs as well, with events like Microsoft-Windows-Windows Defender/5001 (Defender RTP Disabled) and Microsoft-Windows-Windows\r\nDefender/5007 (Defender Malware Protection Configuration Change). The following are Sigma detectors that are\r\navailable from the SigmaHQ repository that detect these changes:\r\nhttps://www.huntress.com/blog/its-not-safe-to-pay-safepay\r\nPage 11 of 14\n\nSigmaHQ rule for Disabling RTP\r\nSigmaHQ Windows Event Log rule for Malware Protection Configuration Change\r\nSigmaHQ Windows Event rule for Defender Configuration Change - Sample Submission\r\nPrivilege Escalation\r\nThe adversary likely used a well-known UAC Bypass Privilege Escalation technique, often utilized by several\r\nother ransomware groups such as Lockbit and BlackCat/ALPHV. This technique results in an elevated process\r\ncreated by a specified COM Object that can be used to execute malicious commands or binaries. When this\r\ntechnique is used, the parent process is DllHost.exe with the CLSID of the COM Object that is used\r\n(CMSTPLUA in this case) present in the command line. While this may happen legitimately at times, it should\r\ngenerally not happen often, especially with unsigned binaries, system binaries that can be used for proxy\r\nexecution, or scripting interpreters as the child process executed.\r\nElastic has a good example rule for the general activity—UAC Bypass via ICMLuaUtil Elevated COM Interface,\r\nand a Sigma version can be found here. To look even more specifically, you can detect using the same logic, but\r\nlooking only for child processes that:\r\n1. Have invalid signatures (malicious binaries)\r\n2. Are scripting interpreters (CMD, PowerShell, etc).\r\n3. Can be used for System Binary Proxy Execution\r\nThese methods can be used to find signs of potential privilege escalation using this COM Object UAC Bypass\r\nmethod.\r\nWe created a couple of new Sigma rules to detect some of these more interesting behaviors:\r\nSystem Binary Proxy Execution Using CMSTPLUA COM Interface\r\nScripting Interpreter Execution Using CMSTPLUA COM Interface\r\nData Collection\r\nThe adversary used WinRAR to archive data before exfiltration. This is a common and well-known tool used for\r\nthis purpose. There were a number of interesting things happening in the commands used. Here are a couple of\r\nSigma rules we created to detect some of this behavior that is often used maliciously and is less common during\r\ntypical WinRAR use in many environments.\r\nCreate WinRAR Archive - Recurse Subfolders\r\nCreate WinRAR Archive - Specify Volume Size\r\nConclusion\r\nIn both incidents, the threat actor’s activity was found to originate from a VPN gateway or portal, as all observed\r\nIP addresses assigned to threat actor workstations were within the internal range. The threat actor was able to use\r\nhttps://www.huntress.com/blog/its-not-safe-to-pay-safepay\r\nPage 12 of 14\n\nvalid credentials to access customer endpoints, and was not observed enabling RDP, nor creating new user\r\naccounts, nor creating any other persistence. During incident 1, the threat actor was observed using a freely\r\navailable PowerShell script to map accessible shares, which were then fed to the file encryption process. Across\r\nboth incidents, the ransom note left as a result of the file encryption process starts with the words, “Greetings!\r\nYour corporate network was attacked by SafePay team,” and goes on to state that “important” data was stolen,\r\nas well as providing contact instructions. \r\nIOCs\r\nIn addition to the use of known credentials and access via RDP, the following IOCs were observed:\r\nMITRE ATT\u0026CK Mapping\r\n                                                                                                                                                                                       \r\n                                     \r\nTactic\r\nTechnique\r\nID\r\nTechnique Name Description\r\nExecution\r\nT1059\r\nCommand and Scripting\r\nInterpreter\r\nPowershell used to download  and\r\nexecute payload, collect and archive files,\r\nand exfiltrate data\r\nT1059.001 Powershell Executed sharefinder.ps1\r\nT1059.003 Windows Command Shell Launched malicious dll\r\nPrivilege\r\nEscalation\r\nT1548.002\r\nAbuse Elevation Control\r\nMechanism: Bypass User\r\nAccount Control\r\nUAC Bypass Using Elevated COM\r\nInterface to execute malicious dll\r\nDefense\r\nEvasion\r\nT1202\r\nSystem Binary Proxy\r\nExecution\r\nUsed regsvr32.exe to execute malicious\r\ndll\r\nT1070.004 File Removal\r\nRemoved zip file that was downloaded\r\nwith powershell\r\nRemoved files after archiving them using\r\n7zip\r\nT1562.001\r\nImpair Defenses: Disable or\r\nModify Tools\r\nDisabled Windows Defender Settings\r\nDiscovery T1135 Network Share Discovery Used ShareFinder.ps1 script\r\nCollection T1560.001\r\nArchive Collected Data:\r\nArchive via Utility\r\nUsed WinRAR to archive files\r\nhttps://www.huntress.com/blog/its-not-safe-to-pay-safepay\r\nPage 13 of 14\n\nExfiltration T1048\r\nExfiltration Over Alternative\r\nProtocol\r\nExfiltration using FTP\r\nImpact\r\nT1486 Data Encrypted for Impact File encryption\r\nT1490 Inhibit System Recovery\r\nDeleted Volume Shadow Copies,\r\nDisabled Windows Recovery in Boot\r\nConfiguration\r\nSpecial thanks to Alden Schmidt, Jonathan Johnson, Matt Anderson, Jamie Levy, John Hammond, and others for\r\ntheir tireless efforts and contributions to this investigation and write-up.\r\nSource: https://www.huntress.com/blog/its-not-safe-to-pay-safepay\r\nhttps://www.huntress.com/blog/its-not-safe-to-pay-safepay\r\nPage 14 of 14",
	"extraction_quality": 1,
	"language": "EN",
	"sources": [
		"Malpedia"
	],
	"references": [
		"https://www.huntress.com/blog/its-not-safe-to-pay-safepay"
	],
	"report_names": [
		"its-not-safe-to-pay-safepay"
	],
	"threat_actors": [
		{
			"id": "aa73cd6a-868c-4ae4-a5b2-7cb2c5ad1e9d",
			"created_at": "2022-10-25T16:07:24.139848Z",
			"updated_at": "2026-04-10T02:00:04.878798Z",
			"deleted_at": null,
			"main_name": "Safe",
			"aliases": [],
			"source_name": "ETDA:Safe",
			"tools": [
				"DebugView",
				"LZ77",
				"OpenDoc",
				"SafeDisk",
				"TypeConfig",
				"UPXShell",
				"UsbDoc",
				"UsbExe"
			],
			"source_id": "ETDA",
			"reports": null
		},
		{
			"id": "6e23ce43-e1ab-46e3-9f80-76fccf77682b",
			"created_at": "2022-10-25T16:07:23.303713Z",
			"updated_at": "2026-04-10T02:00:04.530417Z",
			"deleted_at": null,
			"main_name": "ALPHV",
			"aliases": [
				"ALPHV",
				"ALPHVM",
				"Ambitious Scorpius",
				"BlackCat Gang",
				"UNC4466"
			],
			"source_name": "ETDA:ALPHV",
			"tools": [
				"ALPHV",
				"ALPHVM",
				"BlackCat",
				"GO Simple Tunnel",
				"GOST",
				"Impacket",
				"LaZagne",
				"MEGAsync",
				"Mimikatz",
				"Munchkin",
				"Noberus",
				"PsExec",
				"Remcom",
				"RemoteCommandExecution",
				"WebBrowserPassView"
			],
			"source_id": "ETDA",
			"reports": null
		}
	],
	"ts_created_at": 1775434459,
	"ts_updated_at": 1775791780,
	"ts_creation_date": 0,
	"ts_modification_date": 0,
	"files": {
		"pdf": "https://archive.orkl.eu/9d1290f611907c2228a753ac20bb4f26b1c9c812.pdf",
		"text": "https://archive.orkl.eu/9d1290f611907c2228a753ac20bb4f26b1c9c812.txt",
		"img": "https://archive.orkl.eu/9d1290f611907c2228a753ac20bb4f26b1c9c812.jpg"
	}
}