{ "id": "6bf9fabb-39b5-4eca-a27c-defced825c79", "created_at": "2026-04-06T00:09:59.492536Z", "updated_at": "2026-04-10T03:35:42.359145Z", "deleted_at": null, "sha1_hash": "034317ce9823e8b71a0f0c35bd4ef664d84f7e71", "title": "When Threat Actors Fly Under the Radar: Vatet, PyXie and Defray777", "llm_title": "", "authors": "", "file_creation_date": "0001-01-01T00:00:00Z", "file_modification_date": "0001-01-01T00:00:00Z", "file_size": 869188, "plain_text": "When Threat Actors Fly Under the Radar: Vatet, PyXie and\r\nDefray777\r\nBy Ryan Tracey, Drew Schmitt\r\nPublished: 2020-11-07 · Archived: 2026-04-05 12:44:35 UTC\r\nExecutive Summary\r\nAs security practitioners, we spend a lot of time focusing on the threat actors and malware families that leverage\r\nthe most impactful exploits or affect the highest number of victims. But what happens when a threat actor goes\r\n“low and slow” to fly under the radar? One could argue that, in that situation, the threat actor may end up having\r\nmore impact than some of the more prolific threat groups.\r\nWe first noticed that there may be a relationship between the Vatet loader, PyXie Remote Access Tool (RAT) and\r\nDefray777 ransomware when there were remnants and/or detections of all three in various Incident Response and\r\nManaged Threat Hunting engagements. After digging deep into each malware family, it became apparent that\r\nVatet, PyXie and Defray777 are all associated with the same financially motivated threat group that has been\r\noperating since as early as 2018.\r\nThat threat group, sometimes referred to as PyXie by BlackBerry Cylance and GOLD DUPONT by SecureWorks,\r\nhas been actively conducting successful ransomware operations that have impacted organizations in a number of\r\nsectors including healthcare, education, government and technology while remaining under the radar. This blog\r\naims to shed light on this threat group and to disrupt their operations through awareness of their malware families\r\nand operating methodologies. In essence, we want to get them on the radar.\r\nDuring our research, we discovered that this threat group has developed and maintained the Vatet loader. This\r\nloader has evolved as this threat group has taken advantage of multiple open source tools by altering the original\r\napplication to execute payloads such as PyXie and/or Cobalt Strike. Next, the threat group uses a tailored version\r\nof PyXie, which we call PyXie Lite, to conduct reconnaissance and to find and exfiltrate files that are likely\r\nsensitive to the victim organization. In a number of incidents we investigated, the actors established an initial\r\nfoothold into the victim's network through common banking trojans such as IcedID or Trickbot. From there, they\r\ndeployed Vatet, PyXie and Cobalt Strike before executing Defray777 ransomware entirely in memory. This results\r\nin encrypted files on local drives and file shares before exiting. Additionally, the ransomware leaves no evidence\r\nof execution except for the encrypted files and ransom notes. In regard to Defray777, the group behind this\r\nmalware has also ported their ransomware from Windows to Linux, something that, before Defray777, has yet to\r\nbe seen in the targeted ransomware space. Before this discovery, ransomware that had the ability to impact both\r\nWindows and Linux systems was limited to cross-functional ransomware written in Java or scripting languages\r\nsuch as Python. With the port to Linux, Defray777 ransomware has become the first ransomware variant to have\r\nstandalone executables for Windows and Linux.\r\nhttps://unit42.paloaltonetworks.com/vatet-pyxie-defray777/\r\nPage 1 of 9\n\nWith three different malware families to cover, we realize there is a lot of content to digest. We have a lot of great\r\ndetails on each of these, but we also realize that you may be interested in one malware family over the others, or\r\nyou may just prefer to choose your own adventure. If desired, use the links below to skip to the malware family\r\nthat interests you most, or to get right to the IOCs that will get you hunting for, and detecting, this threat group in\r\naction.\r\nTable of Contents\r\nFirst Up: Vatet Loader\r\nNext Up: PyXie Lite\r\nLast, but Not Least: Defray777\r\nLinking Vatet, PyXie and Defray777\r\nIndicators of Compromise (IOCs)\r\nFirst Up: Vatet Loader\r\nVatet is a custom loader that executes XOR encoded shellcode from the local disk or a network share. The loaders\r\nare typically open source applications found on GitHub, or other repositories, that the actors modify to load their\r\nshellcode. In most cases, the payload winds up being Cobalt Strike beacons and/or stagers, but some of the more\r\nrecent payloads have been an updated version of the PyXie RAT. Vatet is often a precursor to enterprise-wide\r\nransomware attacks.\r\nMicrosoft wrote about the Vatet loader in April 2020 and said the loader had been in use as early as November\r\n2018 for the purpose of loading Cobalt Strike into memory for execution. This loader continues to be seen in the\r\nwild using multiple versions of open source applications to load shellcode including:\r\nVersion First Seen\r\nRecompiled Tetris game 2019-06-28\r\nRecompiled Notepad 2020-05-03\r\nRecompiled desktop customization app, Rainmeter 2020-06-24\r\nRecompiled Notepad++ 2020-09-24\r\nTable 1. Vatet versions.\r\nIn our research, we have seen Vatet samples with compile times as early as 2019, although this variant has\r\nimplemented several variations since then.\r\nIn the earliest versions of Vatet that we analyzed, the malicious payload was loaded via a network share using a\r\npath with the following format: \\\\{IP}\\{EPOCHTIME}\\{PAYLOAD}.dat. However, in the latest samples\r\nanalyzed, the malicious payload was loaded locally from disk. Additionally, we have seen variations in the XOR\r\nkeys used to decode the payload during execution time. Our research also determined that the Vatet loader has\r\nexpanded its payload capabilities to load PyXie in addition to the previously seen Cobalt Strike beacons and\r\nhttps://unit42.paloaltonetworks.com/vatet-pyxie-defray777/\r\nPage 2 of 9\n\nstagers. Finally, the Vatet loaders we analyzed have evolved and begun taking steps to improve their anti-forensics\r\ncapabilities by deleting malicious payloads after they have been loaded into memory for execution.\r\nFigure 1. Vatet execution flow.\r\nLet’s take a deeper look at Vatet using a malicious version of Rainmeter.\r\nInner Workings of the Vatet Loader: A Rainmeter Review\r\nRainmeter is a desktop customization tool that allows users to customize their desktops through the use of “skins.”\r\nDuring a legitimate installation, Rainmeter creates an executable, rainmeter.exe, and a corresponding DLL,\r\nrainmeter.dll. Under normal conditions, rainmeter.dll is responsible for reading configuration files and facilitating\r\na customized desktop. Under the observed circumstances, a signed, legitimate version of rainmeter.exe and a\r\nmalicious version of rainmeter.dll could be simply copied onto the victim system, then used to load and execute a\r\nCobalt Strike beacon in memory under the context of a signed, legitimate executable.\r\nTaking a Look at the Static Properties\r\nWe first reviewed the suspicious rainmeter.exe and rainmeter.dll files and compared them to versions that would\r\nbe installed on a system through the official September 2019 release of the Rainmeter installer, which can be\r\nfound on its public GitHub page.\r\nReviewing rainmeter.exe did not produce many interesting findings. Examining both executables in PEStudio\r\nconfirmed that the sample recovered during a ransomware scenario was the same executable generated by the\r\nstandard Rainmeter installer, based on the SHA256 hash. We also verified that both executables had the same\r\nvalid digital signature.\r\nhttps://unit42.paloaltonetworks.com/vatet-pyxie-defray777/\r\nPage 3 of 9\n\nFigure 2. Initial comparison of static properties of “rainmeter.exe”.\r\nComparing the rainmeter.dll samples provided more interesting findings. Initially, it was obvious that the two\r\nsamples were not the same, since the hashes did not line up. The sizes of the files were significantly different from\r\none another and the compile dates were also quite different. Additionally, there was some variability in the\r\nimports, exports, strings and other properties. Further, the suspected malicious DLL was not digitally signed and\r\nhad additional sections not present in the legitimate Rainmeter DLL.\r\nFigure 3. Comparing the two versions of “rainmeter.dll”.\r\nFigure 4. Comparing sections between “rainmeter.dll” samples.\r\nIt is important to note that the code base for Rainmeter is publicly available on GitHub under the GNU General\r\nPublic License v2.0. This would have allowed the threat actor to openly review/modify the existing rainmeter.dll\r\nfile contents and compile it into the suspected malicious DLL we saw during our investigation.\r\nhttps://unit42.paloaltonetworks.com/vatet-pyxie-defray777/\r\nPage 4 of 9\n\nAfter completing these comparisons to confirm that the Rainmeter DLL was likely malicious, it was time for a\r\ndeeper and more focused look at the samples using a debugger for dynamic analysis.\r\nDynamic Analysis of the Malicious Rainmeter Sample\r\nNow that we had identified samples for deeper inspection, we stopped the comparisons to the legitimate\r\nRainmeter application and focused on the analysis of the suspicious samples recovered. We placed the samples of\r\nrainmeter.exe and rainmeter.dll recovered from the investigation into our analysis environment and began\r\ndebugging Rainmeter. Shortly after starting analysis, rainmeter.exe loaded rainmeter.dll as expected, and\r\nsubsequently called its ordinal 1 exported function. Continuing the execution, there were calls to CreateFileA,\r\nwhere the sample was looking for the hardcoded path C:\\Windows\\help\\options.dat.\r\nFigure 5. Call to “CreateFileA” for a hardcoded path.\r\nAfter the call to CreateFileA, there is a comparison of the result of the call to CreateFileA to FFFFFFFF to\r\ndetermine if it has a valid handle to the file or not. If there is no valid handle, the program exits.\r\nOriginally it was not obvious that options.dat was necessary for the analysis of the malicious Rainmeter sample as\r\n.dat files are not part of the normal Rainmeter application. However, a version of options.dat was recovered in\r\norder to continue analysis. Once the “dat” file was placed in the expected location, the program then allocated\r\nspace on the heap and read the contents of options.dat into memory. After the contents of options.dat were read\r\ninto memory, the sample performed a first-level decoding of the contents by XOR-ing the contents with the value\r\nFE.\r\nFigure 6. Initial XOR decoding loop.\r\nOnce the first decoding routine is completed, the malicious Rainmeter application closes the handle to options.dat.\r\nWhen the program closes the handle to options.dat, it is removed from the file system. This is a built-in anti-analysis technique employed to hinder recovery of the .dat file for analysis. At this point, the data read into the\r\nprogram was still a blob of unrecognizable code. However, at the end of the XOR decoding routine, there is a\r\nCALL EBX instruction that transfers execution to the recently decoded data. Following EBX in the disassembled\r\nview shows that this is valid code. At this stage of analysis, Rainmeter has decoded its options.dat payload, loaded\r\nit into memory and executed it. Future analysis confirmed that this was the end of the Vatet loader routine, and\r\nexecution was passed to the Cobalt Strike shellcode loader.\r\nhttps://unit42.paloaltonetworks.com/vatet-pyxie-defray777/\r\nPage 5 of 9\n\nFigure 7. Transfer of execution to valid code after XOR decoding.\r\nBy this point, we realized that the Vatet loading mechanism was completed, but we wanted to validate the identity\r\nof the final payload, so we pressed on. Further along in the execution, there is a second decoding routine where an\r\nadditional dynamic XOR loop is used to decode and rewrite the contents of the executable code. If this routine\r\nlooks familiar, it’s probably because you are noticing the Cobalt Strike decoding mechanism. This routine begins\r\nby obtaining a pointer to the first four bytes of the imported executable code and setting it as the starting XOR\r\nkey. The code then executes a loop acting on four bytes at a time, XORing the imported code with the starting\r\nXOR key. Next, the loop writes the XOR’d value back into the data segment, followed by setting a new XOR key.\r\nThe new XOR key is determined by XOR’ing the current XOR key with the value decoded by the current key.\r\nOnce this loop is finished, the sample then uses JMP ECX to transfer execution to the recently decoded executable\r\ncontents.\r\nhttps://unit42.paloaltonetworks.com/vatet-pyxie-defray777/\r\nPage 6 of 9\n\nFigure 8. Entering into the second decoding loop. Note the memory space in Dump 1.\r\nFigure 9. After the completion of the second decoding routine, note the executable contents now\r\ndecoded in Dump 2.\r\nAt this stage of analysis, we confirmed the content included in options.dat was shellcode that was later decoded\r\nvia a dynamic XOR routine to create executable code in Rainmeter’s process memory.\r\nNow that we had the executable contents of the XOR’d executable code from options.dat available in memory, we\r\ndumped the contents from the memory map section in x64bdg for additional analysis to determine this code’s\r\npotential functionality.\r\nMoving to our dumped sample of the executable code, we conducted an analysis of the strings to determine if\r\nthere was anything obvious to correlate dynamic analysis findings. In doing this, we identified a reference to\r\nbeacon.dll, which is most often associated with the DLL version of Cobalt Strike’s beacon. Additionally, loading\r\nthe isolated PE into PeStudio showed the following references to an exported function _ReflectiveLoader@4,\r\nwhich is a known exported function of Cobalt Strike.\r\nhttps://unit42.paloaltonetworks.com/vatet-pyxie-defray777/\r\nPage 7 of 9\n\nFigure 10. Extracted PE analysis in PeStudio.\r\nTo confirm whether the extracted payload was a Cobalt Strike beacon or not, we utilized a Cobalt Strike beacon\r\nparser, which dumped the beacon’s decoded configuration.\r\nFigure 11. Cobalt Strike beacon configuration.\r\nThe confirmed Cobalt Strike beacon shows a typical implementation of Cobalt Strike’s HTTPS beacon using\r\nmalleable C2 profiles. Specifically, the Amazon browsing traffic profile created by harmjoy was used in this\r\nhttps://unit42.paloaltonetworks.com/vatet-pyxie-defray777/\r\nPage 8 of 9\n\nbeacon.\r\nContinue reading: Next Up: \"PyXie Lite\"\r\nSource: https://unit42.paloaltonetworks.com/vatet-pyxie-defray777/\r\nhttps://unit42.paloaltonetworks.com/vatet-pyxie-defray777/\r\nPage 9 of 9", "extraction_quality": 1, "language": "EN", "sources": [ "ETDA", "Malpedia" ], "references": [ "https://unit42.paloaltonetworks.com/vatet-pyxie-defray777/" ], "report_names": [ "vatet-pyxie-defray777" ], "threat_actors": [ { "id": "27e51b73-410e-4a33-93a1-49cf8a743cf7", "created_at": "2023-01-06T13:46:39.210675Z", "updated_at": "2026-04-10T02:00:03.247656Z", "deleted_at": null, "main_name": "GOLD DUPONT", "aliases": [ "SPRITE SPIDER" ], "source_name": "MISPGALAXY:GOLD DUPONT", "tools": [], "source_id": "MISPGALAXY", "reports": null }, { "id": "7268a08d-d4d0-4ebc-bffe-3d35b3ead368", "created_at": "2022-10-25T16:07:24.225216Z", "updated_at": "2026-04-10T02:00:04.904162Z", "deleted_at": null, "main_name": "Sprite Spider", "aliases": [ "Gold Dupont", "Sprite Spider" ], "source_name": "ETDA:Sprite Spider", "tools": [ "Agentemis", "Cobalt Strike", "CobaltStrike", "Coroxy", "Defray 2018", "Defray777", "DroxiDat", "Glushkov", "LaZagne", "Metasploit", "PyXie", "PyXie RAT", "Ransom X", "RansomExx", "SharpHound", "Shifu", "SystemBC", "Target777", "Vatet", "cobeacon" ], "source_id": "ETDA", "reports": null }, { "id": "07775b09-acd9-498e-895f-f10063115629", "created_at": "2024-06-04T02:03:07.817613Z", "updated_at": "2026-04-10T02:00:03.650268Z", "deleted_at": null, "main_name": "GOLD DUPONT", "aliases": [ "Sprite Spider ", "Storm-2460 " ], "source_name": "Secureworks:GOLD DUPONT", "tools": [ "777", "ArtifactExx", "Cobalt Strike", "Defray", "Metasploit", "PipeMagic", "PyXie", "Shifu", "SystemBC", "Vatet" ], "source_id": "Secureworks", "reports": null } ], "ts_created_at": 1775434199, "ts_updated_at": 1775792142, "ts_creation_date": 0, "ts_modification_date": 0, "files": { "pdf": "https://archive.orkl.eu/034317ce9823e8b71a0f0c35bd4ef664d84f7e71.pdf", "text": "https://archive.orkl.eu/034317ce9823e8b71a0f0c35bd4ef664d84f7e71.txt", "img": "https://archive.orkl.eu/034317ce9823e8b71a0f0c35bd4ef664d84f7e71.jpg" } }