{
	"id": "a09b5ae6-5946-446e-81cd-8338ea5a832a",
	"created_at": "2026-04-29T02:21:29.543461Z",
	"updated_at": "2026-04-29T08:21:41.830076Z",
	"deleted_at": null,
	"sha1_hash": "08b46b317a641efe59dbff437bdfc3c098d6f005",
	"title": "Crypted Hearts: Exposing the HeartCrypt Packer-as-a-Service Operation",
	"llm_title": "",
	"authors": "",
	"file_creation_date": "0001-01-01T00:00:00Z",
	"file_modification_date": "0001-01-01T00:00:00Z",
	"file_size": 2439892,
	"plain_text": "Crypted Hearts: Exposing the HeartCrypt Packer-as-a-Service\r\nOperation\r\nBy Jerome Tujague, Daniel Bunce\r\nPublished: 2024-12-13 · Archived: 2026-04-29 02:14:00 UTC\r\nExecutive Summary\r\nThis article analyzes a new packer-as-a-service (PaaS) called HeartCrypt, which is used to protect malware. It has\r\nbeen in development since July 2023 and began sales in February 2024. We have identified examples of malware\r\nsamples created by this service based on strings found in several development samples the operators used to test\r\ntheir work.\r\nThe operator of this service has advertised it through underground forums and Telegram. Its operators charge $20\r\nper file to pack, supporting both Windows x86 and .NET payloads.\r\nThe majority of HeartCrypt customers are malware operators using families such as LummaStealer, Remcos and\r\nRhadamanthys. However, we’ve also observed payloads from a wide variety of other crimeware families.\r\nHeartCrypt packs malicious code into otherwise legitimate binaries. We have discovered binaries packed with\r\nHeartCrypt from both external and internal telemetry.\r\nWe have successfully extracted malicious code for payloads from thousands of HeartCrypt samples. A majority of\r\nthe unpacked payloads contain configuration data, which we have used to cluster samples and identify malicious\r\ncampaigns targeting various industries and regions.\r\nPalo Alto Networks customers are better protected from the threats discussed in this article through the following\r\nproducts and services:\r\nCortex XDR and XSIAM\r\nAdvanced WildFire\r\nIf you think you might have been compromised or have an urgent matter, contact the Unit 42 Incident Response\r\nteam.\r\nRelated Unit 42 Topics LummaStealer, Quasar RAT, RedLine Stealer, Remcos RAT, Cybercrime\r\nHeartCrypt Background\r\nHeartCrypt was originally discovered through underground forums and reported by security researchers in\r\nFebruary and March 2024. During HeartCrypt's eight months of operation, it has been used to pack over 2,000\r\nmalicious payloads, involving roughly 45 different malware families.\r\nhttps://unit42.paloaltonetworks.com/packer-as-a-service-heartcrypt-malware/\r\nPage 1 of 16\n\nWe found HeartCrypt used in recent LummaStealer campaigns, including one impersonating legitimate software\r\nvendors and another using fake CAPTCHAs. We have also observed cybercrime activity targeting Latin American\r\ncountries, with Remcos and XWorm using the HeartCrypt packer.\r\nWe first observed HeartCrypt during routine investigations in late June 2024 and initially categorized it as an\r\nunnamed, custom packer. Over the next several weeks, we continued to find more malware families using this\r\npacker and decided to investigate further.\r\nUsing unique byte patterns found within the packed samples, we created hunting rules and identified thousands of\r\nsamples dating back to mid-2023. After implementing processes to parse these samples at scale, we made several\r\nnotable discoveries.\r\nOur first discovery was that development appears to have begun in July 2023, with the PaaS launching around\r\nFeb. 17, 2024. Nearly 1,000 samples from this period contained either no payload or a test payload.\r\nSecond, the packed payload was consistently added as a resource to a legitimate binary, often with a random\r\nname, though early versions sometimes used names containing HeartCrypt. This led us to our third discovery, the\r\nidentification of the packer’s distributor.\r\nThe distributor of HeartCrypt marketed the PaaS across multiple platforms, including:\r\nTelegram\r\nBlackHatForums\r\nXSS.is\r\nExploit.in\r\nAdvertisements state HeartCrypt supports 32-bit Windows payloads at $20 per crypt. Figure 1 shows an ad in a\r\nTelegram post and Figure 2 shows an ad in an XSS.is post.\r\nhttps://unit42.paloaltonetworks.com/packer-as-a-service-heartcrypt-malware/\r\nPage 2 of 16\n\nFigure 1. Post in the HeartCrypt Telegram channel.\r\nFigure 2. HeartCrypt XSS advertisement.\r\nIn HeartCrypt’s PaaS model, customers submit their malware via Telegram or other private messaging services,\r\nwhere the operator then packs and returns it as a new binary. As we detail in the next section, the packing process\r\nhttps://unit42.paloaltonetworks.com/packer-as-a-service-heartcrypt-malware/\r\nPage 3 of 16\n\nexemplifies how when even basic techniques are combined, it can create a challenge for reverse engineers.\r\nHeartCrypt Technical Analysis\r\nCreating the HeartCrypt Stub\r\nThe packing process begins by injecting malicious code into an otherwise legitimate executable file. This does not\r\nappear to be a random process. Our analysis reveals client-side customization.\r\nWe've identified over 300 distinct legitimate binaries its operators used as carriers for the malicious payload,\r\nwhich suggests a degree of client-side control. We theorize that the HeartCrypt service allows clients to select a\r\nspecific binary for injection, tailoring the final payload to its intended target.\r\nFor example, a threat actor running a malware campaign based on a lure including an installer for a legitimate\r\nWindows application could request injection into a genuine but outdated installer. Distributed through a site\r\nimpersonating the software vendor, the resulting packed malware would appear far more legitimate to a less-technical user, potentially increasing the likelihood of successful detonation.\r\nThe modification of the legitimate binary occurs in three key steps:\r\n1. A contiguous block of code is added to the binary's .text section.\r\n2. The control flow within the original binary is hijacked.\r\n3. Several resources are added to the binary.\r\nFirst, HeartCrypt adds a contiguous block of code to the binary's .text section. This code block is designed as\r\nposition-independent code (PIC), a programming construct where the code's location in memory doesn't affect its\r\nexecution. This allows the malicious code to run regardless of where it is loaded into memory by the operating\r\nsystem.\r\nSecondly, HeartCrypt hijacks the control flow within the original binary. This is most often achieved by altering\r\nthe start() function, the entry point for many executables. The modification typically involves adding a call or jmp\r\ninstruction which redirects execution to the newly added PIC. Figure 3 shows a section of disassembled code from\r\na HeartCrypt sample with an example of an added jmp instruction.\r\nhttps://unit42.paloaltonetworks.com/packer-as-a-service-heartcrypt-malware/\r\nPage 4 of 16\n\nFigure 3. HeartCrypt start() function modification.\r\nThe injected PIC leverages multiple control flow obfuscation methods to hinder analysis. These include:\r\nStack strings\r\nDynamic API resolution\r\nHundreds of direct jmp instructions\r\nNon-returning functions\r\nArithmetic operations that have no effect on program execution\r\nJunk bytes after jmp and call instructions, impeding disassembly and decompilation\r\nThe combination of these techniques makes both static and dynamic analysis extremely tedious.\r\nWith some effort, our analysis revealed that the initial PIC consists of two layers: an encoded block wrapped with\r\na small decryption routine. The first layer uses specific byte patterns to identify the start and end of the encoded\r\nblock. Figures 4 and 5 below show this as disassembled code from IDA Pro.\r\nhttps://unit42.paloaltonetworks.com/packer-as-a-service-heartcrypt-malware/\r\nPage 5 of 16\n\nFigure 4. Byte pattern built on the stack, indicating the start of the encrypted block.\r\nFigure 5. Byte pattern built on the stack, indicating the end of the encrypted block.\r\nAfter locating the encoded block, the PIC performs a substitution operation on each byte, and execution passes\r\ndirectly to the decrypted block. The value used for substitution is chosen at random and is always in the range of\r\none to nine.\r\nThe decrypted block uses the same obfuscation techniques as the first layer, again rendering static analysis\r\ninfeasible. This second layer of the PIC iterates through the resources added to the binary and executes code\r\nwithin each in turn. Each iteration is performed in three steps.\r\nThe PIC first creates a stack string containing the resource name. Next, it leverages the FindResourceW,\r\nLoadResource and LockResource Windows APIs to acquire a pointer to the corresponding resource.\r\nFinally, it uses VirtualProtect to modify the resource's memory protection attributes, enabling code execution.\r\nExecution is transferred directly to the resource, and upon completion, control is returned to the original PIC that\r\nrestores the resource’s original memory protection using VirtualProtect. Figure 6 below provides a visual outline\r\nof the execution flow thus far.\r\nhttps://unit42.paloaltonetworks.com/packer-as-a-service-heartcrypt-malware/\r\nPage 6 of 16\n\nFigure 6. HeartCrypt’s injected PIC executing code within each resource.\r\nAfter hijacking the control flow, HeartCrypt adds several resources to the binary, each playing a key role in the\r\npacker's functionality and employing similar obfuscation across each layer. We now analyze each resource in\r\ndetail, uncovering their individual functionalities and their collective contribution to the functionality of the\r\npacker.\r\nUnraveling the Shellcode Resources\r\nEach resource embedded in the binary contains PIC disguised as a bitmap (BMP) image file. This begins with a\r\nstandard BMP header followed by a repeating hexadecimal pattern for padding.\r\nFigure 7 shows an example of a resource PIC in a hex editor where you can see the first 2 bytes as the ASCII\r\ncharacters BM and the repeating hexadecimal pattern as 0x09.\r\nhttps://unit42.paloaltonetworks.com/packer-as-a-service-heartcrypt-malware/\r\nPage 7 of 16\n\nFigure 7. HeartCrypt resource PIC using a BMP header and padding bytes.\r\nAfter the repeating hexadecimal pattern, the resource marks the start of its PIC with a sequence of bytes directly\r\nbefore the PIC's entry point. After identifying this sequence of bytes, the primary PIC transfers execution to the\r\nresource PIC.\r\nFigure 8 shows this sequence of bytes later in the resource PIC as 0x13371337, just before the entry point.\r\nFigure 8. Start of PIC in resource.\r\nThe resource PIC mirrors the structure of the initial PIC block in the legitimate binary, consisting of two layers\r\nwith the same obfuscation techniques discussed previously. Each resource performs a different core function, with\r\nall observed HeartCrypt samples following the same pattern.\r\nResource 1: Anti-Dependency Emulation\r\nThe first resource appears designed to detect dependency emulation within a sandbox environment. It purposefully\r\nattempts to load non-existent DLLs via LoadLibraryW, specifically k7rn7l32.dll and ntd3ll.dll.\r\nIf the sandbox responds by generating a dummy DLL to prevent the program from crashing, HeartCrypt will call\r\nExitProcess and terminate the execution. This is a rudimentary and unreliable method of sandbox detection, as\r\nmodern sandboxes will typically return a controlled error code rather than creating a fake DLL. Further evidence\r\nof this functionality appeared in early development samples, where the author paired the stack-string\r\nCheckLibraryEmulated with MessageBoxW, likely for testing purposes.\r\nResource 2: Sandbox Loop Emulation Check\r\nhttps://unit42.paloaltonetworks.com/packer-as-a-service-heartcrypt-malware/\r\nPage 8 of 16\n\nEarlier versions of the second resource (as with many of the other resources), provided useful insight into the\r\nfunctionality through debug strings. In this resource, the string CheckLoopEmulated, as well as the lack of timing-related API, allowed us to quickly identify what this resource could be responsible for.\r\nThe resource enters a while loop that performs a large number of mathematical calculations on an initial hard-coded value, similar to a hashing algorithm. The resulting hash is checked against an expected value.\r\nIf the two values match, the sample will set a flag value within memory to indicate the loop was not emulated or\r\nmodified in any way. If this flag is not set, the process will call ExitProcess.\r\nResource 3: Windows Defender Evasion\r\nThe third resource provides anti-sandbox capabilities for evading Windows Defender. It leverages virtual DLLs\r\n(VDLLs), which are specialized versions of Windows DLLs within Defender's emulator, as described by Alexei\r\nBulazel at BlackHat 2018 [PDF].\r\nFor example, within the emulator kernel32.dll has additional APIs such as MpReportEvent and\r\nMpAddToScanQueue. If HeartCrypt can load this API from kernel32, it can assume the sample is running within\r\nthe Defender emulator.\r\nThis anti-sandbox technique was first reported in early April 2024 by Harfang Lab, in RaspberryRobin malware. It\r\nwas adopted by the authors of HeartCrypt in the third resource just 15 days later.\r\nBefore adopting the Defender evasion technique, HeartCrypt included a different anti-sandbox technique that\r\nattempted to load d3d9::Direct3DCreate9. From our analysis, we believe this lines up with an anti-sandbox/anti-VM technique found within the InviZzzible virtual environment assessor, developed by Check Point Research.\r\nThe technique involves using the GetAdapterIdentifier function within an IDirect3D9 object to see if the vendor\r\nID aligns with known VM providers. Alternatively, HeartCrypt’s authors could also have implemented this\r\ntechnique under the assumption that a sandbox would be unlikely to provide Direct3D functionality. For example,\r\nif the sample failed to load the d3d9 library, it would terminate.\r\nResource 4: Final Payload Execution\r\nThe fourth resource decrypts and injects the final payload by accessing another embedded resource that holds the\r\nencoded payload. This resource masquerades as a BMP file but does not have the additional padding bytes or PIC.\r\nInstead, the BMP header is simply appended to the encoded payload.\r\nThe payload is a Windows executable binary encoded via a single-byte XOR operation rotating over a key hard-coded in the resource PIC as a stack string. We’ve identified over 50 distinct XOR keys across all HeartCrypt\r\nsamples, with no discernable pattern. It is possible that the customer provides the key, but at this time we have no\r\nway to validate this theory.\r\nAfter decryption, the PIC parses the decoded PE header to determine if the final payload is a .NET assembly or a\r\nnatively compiled executable. If the packed sample is .NET, HeartCrypt will attempt to launch csc.exe (or in some\r\nhttps://unit42.paloaltonetworks.com/packer-as-a-service-heartcrypt-malware/\r\nPage 9 of 16\n\ncases AppLaunch.exe) from the Microsoft .NET Framework directory. It then performs process hollowing on the\r\nspawned process, injecting and executing the final payload within it.\r\nIf the sample is not a .NET assembly, HeartCrypt spawns a copy of itself and injects the final payload using a\r\nsimilar process hollowing technique. While process hollowing is the primary method of injection, we have\r\nidentified a sample that references NtQueueApcThread, suggesting that the developer has invested effort into\r\ndiversifying the injection methods.\r\nResource 5: HeartCrypt Persistence\r\nThe fifth resource appears to be optional, as it isn’t present in every sample we’ve identified. Its purpose is to\r\nestablish persistence on the system using the HKCU\\Software\\Microsoft\\Windows\\CurrentVersion\\Run registry\r\nkey.\r\nHeartCrypt drops an inflated version of itself onto the file system, adding several hundred thousand kilobytes of\r\nnull padding before saving it to a hard-coded file path. It then sets the CurrentVersion\\Run key to point to this file.\r\nTo modify the registry, HeartCrypt uses either Windows API functions or the reg add command via cmd.exe.\r\nFigure 9 below provides a visual representation of the HeartCrypt execution flow in its entirety.\r\nFigure 9. HeartCrypt execution flow.\r\nExtracting HeartCrypt Payloads\r\nhttps://unit42.paloaltonetworks.com/packer-as-a-service-heartcrypt-malware/\r\nPage 10 of 16\n\nHaving detailed the individual functions of each embedded resource within the HeartCrypt packer, our next step\r\nwas to automate the process of extracting payloads for further analysis. This involved developing a script capable\r\nof identifying the XOR key within the BMP-disguised resources.\r\nAlthough HeartCrypt’s obfuscation greatly hinders static analysis efforts, extracting key information is relatively\r\ntrivial. The encoded payload is always a single-byte XORed Windows binary, so we can use a few basic methods\r\nto brute-force the key.\r\nThe first step is to locate the start of the encoded payload within the resource, which is always at the same offset.\r\nWe can assume the first 2 bytes of the encoded payload will decode to MZ (0x4D5A), the Windows PE magic\r\nbytes found at the start of all executable files. As XOR operations are reversible, we can XOR the encoded bytes\r\nwith 0x4D5A, resulting in the first 2 bytes of the XOR key.\r\nUnencoded Windows executable files always contain multiple blocks of null bytes—for example, right after the\r\nsection headers and just before the .text section. When a null byte is used in a single-byte XOR operation, the\r\nresult is the byte used to perform the XOR. Therefore, we know that when the payload is encoded, the XOR key\r\nwill be exposed in these blocks.\r\nOnce we’ve identified the initial bytes of the XOR key, we can search the entire binary for sequences beginning\r\nwith these 2 bytes, resulting in a list of possible keys. We then attempt to decode the payload using each possible\r\nkey, and if the resulting data is a valid PE file, we can assume we’ve identified the correct key.\r\nWhile the brute-force method worked successfully for every sample of HeartCrypt we encountered, we updated\r\nour method to take a more efficient approach.\r\nAs we discussed earlier, each HeartCrypt resource includes a PIC block structured in two layers: the first layer\r\napplies a single-byte substitution operation to decode the second. By using frequency analysis, we can quickly\r\nidentify the substitution key.\r\nIn our manual analysis of a decoded second-layer HeartCrypt resource PIC, we observed that the bytes 0x00 and\r\n0xFF appeared most frequently. We know the encoding process involves adding a fixed value to each byte. Given\r\nthat 0x00 is the most common value in the decoded PIC, the most common byte in the encoded PIC will indicate\r\nthe substitution key. We implemented this logic into our script, and it was successful in decoding the first two\r\nlayers of PIC resource blocks in all HeartCrypt samples.\r\nThe fourth HeartCrypt resource contains the XOR key stored as a stack string in the second layer PIC. Once we\r\nautomated the process of decoding the PIC, we implemented a simple regex to extract all stack strings, allowing\r\nus to identify the XOR key for each sample without relying on brute force.\r\nUltimately, we were able to extract final payloads from all samples of HeartCrypt and perform further processing\r\nsuch as configuration extraction, when applicable.\r\nMalicious Campaigns Using HeartCrypt\r\nAnalyzing the data gathered from our internal telemetry, we were able to get a better understanding of HeartCrypt\r\nactivity. Our analysis shows there are just under 10 new samples of HeartCrypt found on average each day, with\r\nhttps://unit42.paloaltonetworks.com/packer-as-a-service-heartcrypt-malware/\r\nPage 11 of 16\n\noccasional peaks of 60 samples as shown in Figure 10.\r\nFigure 10. HeartCrypt samples identified over time from our internal telemetry.\r\nSome of these peaks occurred during the developmental phase, between June 2023 and mid-February 2024. These\r\nsamples had no payloads or test payloads using 127.0.0.1 as the C2 address, and many contained debug strings\r\nwithin PIC layers.\r\nOur analysis indicates that the payload XOR keys appear to have some level of client-side customization. Across\r\nall samples, we found approximately 55 XOR keys consisting of distinct ASCII strings with different themes.\r\nThese themes include months indicating the campaign, EDR/AV software company names, as well as random\r\nstrings as shown in Figure 11 below.\r\nFigure 11. HeartCrypt XOR key usage across identified samples.\r\nAutomatic extraction of the payloads allowed us to cluster samples according to the identified malware family, as\r\nshown below in Figure 12.\r\nhttps://unit42.paloaltonetworks.com/packer-as-a-service-heartcrypt-malware/\r\nPage 12 of 16\n\nFigure 12. Malware families extracted from HeartCrypt samples.\r\nRemcos is the payload most frequently seen across all HeartCrypt samples, because HeartCrypt’s developers often\r\nused it during their development cycle as a test payload. We have also observed several clusters of Remcos\r\ntargeting Latin American countries in recent months. For further details, see the Indicators of Compromise section\r\nof this article.\r\nLumma Steal is another payload frequently deployed by HeartCrypt packed samples. We have recently identified\r\nHeartCrypt samples from a previously reported LummaStealer campaign impersonating software vendors we\r\noriginally posted about in October 2024.\r\nWe have also discovered HeartCrypt packed LummaStealer samples from a campaign using fake CAPTCHAs and\r\ncopy/paste PowerShell script similar to one we originally reported on in August 2024. These campaigns have\r\nremained active since then.\r\nConclusion\r\nOur analysis of HeartCrypt – a PaaS actively used by various threat actors – reveals what its samples look like in\r\nthe wild, including extracting payloads for grouping. We documented HeartCrypt's evolution from its initial\r\ndevelopment in July 2023 to its February 2024 launch, tracking its use in over 2,000 malicious payloads across 45\r\nmalware families.\r\nThe packer’s obfuscation techniques combine PIC, multiple layers of encoding and resource-based execution to\r\nsignificantly hinder analysis. Marketed on various underground forums, HeartCrypt’s PaaS model lowers the\r\nbarrier to entry for malware operators, increasing the volume and success of infections.\r\nThis lowered barrier to entry highlights the need for defenders to practice proactive threat hunting, focusing on\r\nidentifying unique byte patterns and packer characteristics to detect obfuscated malware. Furthermore, the ease\r\nwith which threat actors can leverage services like HeartCrypt showcases the continuous commoditization of\r\nmalware development.\r\nhttps://unit42.paloaltonetworks.com/packer-as-a-service-heartcrypt-malware/\r\nPage 13 of 16\n\nPalo Alto Networks customers are better protected from the threats discussed in this article through the following\nproducts and services:\nCortex XDR and XSIAM\nAdvanced WildFire\nIf you think you may have been compromised or have an urgent matter, get in touch with the Unit 42 Incident\nResponse team or call:\nNorth America Toll-Free: 866.486.4842 (866.4.UNIT42)\nEMEA: +31.20.299.3130\nAPAC: +65.6983.8730\nJapan: +81.50.1790.0200\nPalo Alto Networks has shared these findings with our fellow Cyber Threat Alliance (CTA) members. CTA\nmembers use this intelligence to rapidly deploy protections to their customers and to systematically disrupt\nmalicious cyber actors. Learn more about the Cyber Threat Alliance.\nHeartCrypt YARA Rule\n1\n2\n3\n4\n5\n6\n7\n8\n9\n10\n11\n12\n13\n14rule u42_crime_win_heartcrypt {\nmeta:\nauthor = \"Unit 42 Threat Intelligence\"\ndate = \"2024-11-30\"\ndescription = \"HeartCrypt PaaS hunting rule.\"\nhash = \"7f4d6a371e872d8b4999d415401589c32adcfc6cfc26892cfa3316e4fccec270\"\nstrings:\n$a = {E8 08 00 00 00 00 ?? ?? ?? ?? ?? ?? ?? 83 C4 04 81}\n$b = {\nB8 4D 00 00 00\n66 89 85 ?? ?? ?? ??\nB9 42 00 00 00\n66 89 8D ?? ?? ?? ??\nhttps://unit42.paloaltonetworks.com/packer-as-a-service-heartcrypt-malware/\nPage 14 of 16\n\n15\r\n16\r\n17\r\n18\r\n19\r\n20\r\n21\r\n22\r\n23\r\n24\r\n25\r\n26\r\n27\r\n28\r\n29\r\n30\r\n31\r\n32\r\n33\r\n34\r\n35\r\n36\r\n37\r\n38\r\n39\r\n40\r\nBA 53 00 00 00\r\n66 89 95 ?? ?? ?? ??\r\nB8 65 00 00 00\r\n66 89 85 ?? ?? ?? ??\r\nB9 72 00 00 00\r\n66 89 8D ?? ?? ?? ??\r\nBA 76 00 00 00\r\n66 89 95 ?? ?? ?? ??\r\nB8 69 00 00 00\r\n66 89 85 ?? ?? ?? ??\r\nB9 63 00 00 00\r\n66 89 8D ?? ?? ?? ??\r\nBA 65 00 00 00\r\n66 89 95 ?? ?? ?? ??\r\nB8 2E 00 00 00\r\n66 89 85 ?? ?? ?? ??\r\nB9 65 00 00 00\r\n66 89 8D ?? ?? ?? ??\r\nBA 78 00 00 00\r\n66 89 95 ?? ?? ?? ??\r\nB8 65 00 00 00\r\n66 89 85 ?? ?? ?? ??\r\n33 C9\r\n66 89 8D ?? ?? ?? ??\r\n}\r\ncondition:\r\nhttps://unit42.paloaltonetworks.com/packer-as-a-service-heartcrypt-malware/\r\nPage 15 of 16\n\n41\r\n42\r\n$a or $b\r\n}\r\nIndicators of Compromise\r\nA text-based CSV spreadsheet for the HeartCrypt samples we have identified so far is available at a link from our\r\nGitHub repository.\r\nSource: https://unit42.paloaltonetworks.com/packer-as-a-service-heartcrypt-malware/\r\nhttps://unit42.paloaltonetworks.com/packer-as-a-service-heartcrypt-malware/\r\nPage 16 of 16",
	"extraction_quality": 1,
	"language": "EN",
	"sources": [
		"MITRE"
	],
	"origins": [
		"web"
	],
	"references": [
		"https://unit42.paloaltonetworks.com/packer-as-a-service-heartcrypt-malware/"
	],
	"report_names": [
		"packer-as-a-service-heartcrypt-malware"
	],
	"threat_actors": [
		{
			"id": "08c8f238-1df5-4e75-b4d8-276ebead502d",
			"created_at": "2023-01-06T13:46:39.344081Z",
			"updated_at": "2026-04-29T06:58:56.521699Z",
			"deleted_at": null,
			"main_name": "Copy-Paste",
			"aliases": [],
			"source_name": "MISPGALAXY:Copy-Paste",
			"tools": [],
			"source_id": "MISPGALAXY",
			"reports": null
		}
	],
	"ts_created_at": 1777429289,
	"ts_updated_at": 1777450901,
	"ts_creation_date": 0,
	"ts_modification_date": 0,
	"files": {
		"pdf": "https://archive.orkl.eu/08b46b317a641efe59dbff437bdfc3c098d6f005.pdf",
		"text": "https://archive.orkl.eu/08b46b317a641efe59dbff437bdfc3c098d6f005.txt",
		"img": "https://archive.orkl.eu/08b46b317a641efe59dbff437bdfc3c098d6f005.jpg"
	}
}