{
	"id": "49152ed0-a2b6-4873-8653-a8a62cc02839",
	"created_at": "2026-04-06T00:20:09.10471Z",
	"updated_at": "2026-04-10T13:11:31.882198Z",
	"deleted_at": null,
	"sha1_hash": "d710405c3a7e5d9b721c9b26f2ebe4a2e1425b94",
	"title": "Exploit Developer Spotlight: The Story of PlayBit - Check Point Research",
	"llm_title": "",
	"authors": "",
	"file_creation_date": "0001-01-01T00:00:00Z",
	"file_modification_date": "0001-01-01T00:00:00Z",
	"file_size": 132208,
	"plain_text": "Exploit Developer Spotlight: The Story of PlayBit - Check Point\r\nResearch\r\nBy Eyal Itkin\r\nPublished: 2020-10-26 · Archived: 2026-04-05 19:21:59 UTC\r\nResearch By: Eyal Itkin and Itay Cohen\r\nIntroduction\r\nExploits have always been an important and integral part of malicious attacks. They allow attackers to gain\r\ncapabilities that are not easy to achieve otherwise. Whether attackers strive to gain higher privileges on a given\r\ncomputer, or laterally move inside a network, exploits often play a key role in their plan. While in-the-wild\r\nexploits are used by many malware families, the malware authors get most of the attention, and the exploit\r\ndevelopers remain out of the spotlight.\r\nAs part of our effort to focus on the exploit developers themselves, we previously shared our methodology and\r\ntechnique of fingerprinting and tracking exploit developers. In our earlier publication, we thoroughly explained\r\nour methodology and focused on Volodya, a prominent exploit developer we tracked using the unique fingerprints\r\nleft in their exploits. Now our focus is on another exploit developer known as PlayBit or luxor2008.\r\nInitial Sample – CVE-2018-8453\r\nAs our research technique of fingerprinting exploit writers exceeded our initial expectations, we were on the\r\nlookout for more exploits to investigate. Soon enough, we came across this blog post from Kaspersky detailing\r\nhow Sodin (a.k.a Sodinokibi, or REvil), an infamous ransomware, is using a 1-Day exploit for CVE-2018-8453.\r\nCVE-2018-8453 is an interesting case, as it was formerly caught in the wild by Kaspersky when used by\r\nFruityArmor. From their report, it was clear that this exploit was reimplemented by another actor. While we\r\nwould prefer to investigate an exploit developed by the actor behind the 0-Day exploit, we had to settle for the\r\nexploit used in REvil.\r\nEven from this one sample, it was clear that this new actor uses a totally different exploit template than the one\r\nused by Volodya. Luckily for us, the actor chose to implement new features that weren’t in Volodya’s exploit\r\ntemplate, which gave us a wider choice of artifacts to hunt for. After we created a few hunting rules, we set out to\r\npursue our quarry.\r\nOur actor’s exploits\r\nAll of the exploits that we found related to this actor were 1-Day exploits for Local Privilege Escalation (LPE)\r\nvulnerabilities in Windows. This list of 5 different CVEs that were exploited eventually led us to our actor’s\r\nhttps://research.checkpoint.com/2020/graphology-of-an-exploit-playbit/\r\nPage 1 of 16\n\nidentity: PlayBit (a.k.a luxor2008). A full profile of the actor can be found later on in this blog post, under the\r\n“Intelligence Report” section.\r\nCVE-2013-3660\r\nClassification: 1-Day\r\nBasic Description: Uninitialized kernel pointer in EPATHOBJ::pprFlattenRec\r\nUsed by the following malware families: Dyre, Ramnit\r\nBackground on this vulnerability:\r\nThis vulnerability was originally found by Google’s Tavis Ormandy, and made headlines due to an unusual\r\ndisclosure process as Microsoft was not notified about the vulnerability before the full disclosure.\r\nFigure 1: Decompiled code showing PlayBit’s exploit banner, as seen in IDA Pro.\r\nCVE-2015-0057\r\nClassification: 1-Day\r\nBasic Description: Use-After-Free in win32k!xxxEnableWndSBArrows\r\nUsed by the following malware families: Dyre, Evotob\r\nBackground on this vulnerability:\r\nAlso known as MS15-010, this vulnerability was found by Udi Yavo, the CTO of enSilo. The public disclosure of\r\nthe vulnerability included a technical explanation of the vulnerability as well as the exploitation plan. In addition,\r\nthe authors specifically mentioned they were able to exploit this vulnerability on all Windows versions, and even\r\nsupplied a demo video.\r\nEven though the disclosure didn’t share any exploit code, it was enough to draw our actor’s attention. Three\r\nmonths after the patch, PlayBit already had a working exploit, and a month later this exploit was used by the Dyre\r\nBanking Trojan. The exceptional case behind this vulnerability is described in more detail in FireEye’s Black Hat\r\npresentation on CVE-2015-0057.\r\nCVE-2015-1701\r\nClassification: 1-Day\r\nBasic Description: CreateWindow callback validation error\r\nhttps://research.checkpoint.com/2020/graphology-of-an-exploit-playbit/\r\nPage 2 of 16\n\nUsed by the following malware families: Locky\r\nBackground on this vulnerability:\r\nAlso known as MS15-051, this vulnerability was originally exploited as a 0-Day in an operation attributed to\r\nAPT28.\r\nCVE-2016-7255\r\nClassification: 1-Day\r\nBasic Description: Memory corruption in NtUserSetWindowLongPtr\r\nUsed by the following malware families: LockCrypt\r\nBackground on this vulnerability:\r\nOriginally exploited as a 0-Day, once again attributed to APT28. This 0-Day was found and exploited by Volodya,\r\nlater to be exploited again and sold by PlayBit.\r\nCVE-2018-8453\r\nClassification: 1-Day\r\nBasic Description: Use-after-free in win32kfull!xxxDestroyWindow\r\nUsed by the following malware families: REvil (Sodinokibi), Maze, Neshta\r\nBackground on this vulnerability:\r\nOriginally exploited as a 0-Day, and attributed to FruityArmor.\r\nAs bitdefender reported, Maze ransomware uses two different LPE exploits: CVE-2016-7255, and CVE-2018-\r\n8453. What’s interesting is that they use Volodya’s exploit for CVE-2016-7255 (like GandCrab, and many other\r\nmalware families), while transitioning to using PlayBit’s exploit for CVE-2018-8453. Not only do we see both\r\nVolodya and PlayBit selling their exploits to the same malware actor, we can take this opportunity to learn about\r\nthe dynamics involved. While PlayBit sells their own exploit for CVE-2016-7255, Maze chose to use Volodya’s\r\nexploit even though they also purchased an exploit from PlayBit (CVE-2018-8453).\r\nIt seems a bit unusual that when purchasing their LPE exploits, the actors behind Maze decided to buy from two\r\ndifferent sellers, especially as PlayBit sells both of these exploits. However, an important fact to remember is that\r\nMaze ransomware was first discovered in 2019. Therefore, our theory is that at least in some campaigns, the\r\noperators behind Maze simply “inherited” the first exploit, later purchasing another one to target more victims.\r\nMindset of a 1-Day exploit seller\r\nWhen going over the list of CVEs that were exploited by PlayBit, we found a unique pattern that they all share:\r\nAll of the vulnerabilities were already “famous” before PlayBit decided to implement an exploit for them.\r\nCVE-2013-3660 – Made headlines due to an unusual disclosure process.\r\nCVE-2015-0057 – The public disclosure of the vulnerability included a detailed explanation of the\r\nvulnerability and the exploitation plan, and to this day is still highly regarded as a novel exploitation\r\ntechnique.\r\nCVE-2015-1701 – Originally exploited as a 0-Day.\r\nCVE-2016-7255 – Originally exploited as a 0-Day.\r\nhttps://research.checkpoint.com/2020/graphology-of-an-exploit-playbit/\r\nPage 3 of 16\n\nCVE-2018-8453 – Originally exploited as a 0-Day.\r\nAs we can see, all of the CVEs that our actor chose to exploit as 1-Days were already well known. While we\r\ndidn’t find a similar tactic for Volodya when choosing which 1-Day vulnerabilities to exploit, it does seem that\r\nthis helped PlayBit advertise their exploits in underground forums.\r\nOne more characteristic that we found in all of PlayBit’s exploits that were lacking in Volodya’s, is the\r\nexploitability check. PlayBit supplies the customer with a thin wrapper around the exploit, which checks whether\r\nthe target computer is indeed vulnerable. Although the check varies a bit between different exploits and versions,\r\nthe basics are the same: the modification date of the vulnerable win32k driver is checked, to detect if a patch was\r\ninstalled.\r\nFigure 2: Checking if win32k.sys was modified after February 10, 2015 (CVE-2015-0057). Screenshot from\r\nCutter.\r\nThis operational decision was very useful from our perspective, as the exploit effectively tells us in which Patch\r\nTuesday the exploited vulnerability was fixed:\r\nCVE-2013-3660 – The first sample of this exploit didn’t yet contain such a check.\r\nCVE-2015-0057 – win32k.sys checked for a modification date of February 10, 2015.\r\nCVE-2015-1701 – win32k.sys  checked for a modification date of May 13, 2015.\r\nCVE-2016-7255 – win32k.sys  checked for a modification date of November 8, 2016.\r\nCVE-2018-8453 – win32k.sys / win32kfull.sys are checked for a modification date of September 11,\r\n2018.\r\nThe author’s fingerprints\r\nNow that we found 5 different exploits from PlayBit, we can review them in greater detail and familiarize\r\nourselves with the actor’s work habits. As was the case with Volodya, it was clear to us from the beginning that\r\nPlayBit probably has a simple template to deploy for the different exploits.\r\nhttps://research.checkpoint.com/2020/graphology-of-an-exploit-playbit/\r\nPage 4 of 16\n\nAs some of the actor’s characteristics were already used in the previous comparison to Volodya, we chose to focus\r\ninstead on other implementation decisions, some of which aren’t even included in Volodya’s exploits.\r\nHash-Based Imports\r\nIn every exploit, PlayBit picks a handful of important functions and obfuscates their use. Instead of just importing\r\nthese functions in the PE level, or using their cleartext strings and importing them using GetProcAddress() ,\r\nPlayBit devised their own import technique.\r\nFigure 3: Loading the addresses of Ps*\r\nsymbols based on their hash/CRC.\r\nHere is a short Python snippet that performs this “hash” calculation (more like a checksum / CRC):\r\ndef calc_hash(export_str):\r\n# convert lower case back to upper case\r\nif cur_value \u003e= ord('a'):\r\ncur_value -= 0x20 # 'a' - 'A' = 0x20\r\ncrc_value = ror(crc_value, 13) + cur_value\r\nfrom malduck import ror def calc_hash(export_str): crc_value = 0 for c in export_str: cur_value = ord(c) # convert\r\nlower case back to upper case if cur_value \u003e= ord('a'): cur_value -= 0x20 # 'a' - 'A' = 0x20 crc_value =\r\nror(crc_value, 13) + cur_value return crc_value\r\nhttps://research.checkpoint.com/2020/graphology-of-an-exploit-playbit/\r\nPage 5 of 16\n\nfrom malduck import ror\r\ndef calc_hash(export_str):\r\n crc_value = 0\r\n for c in export_str:\r\n cur_value = ord(c)\r\n # convert lower case back to upper case\r\n if cur_value \u003e= ord('a'):\r\n cur_value -= 0x20 # 'a' - 'A' = 0x20\r\n crc_value = ror(crc_value, 13) + cur_value\r\n return crc_value\r\nNot only is this hash-based import technique used in all of the actor’s exploits, we were also able to find it in other\r\ntools they sold over the years, going back to 2012.\r\nWhen examining the functions imported using this mechanism, we found out they all have a common trait. All of\r\nthese functions are used by the “shellcode”, the exploitation part that is executed with high privileges and is\r\nresponsible for elevating the permissions of the target process. This also means that it is relatively easy to locate\r\nthe shellcode in each of the exploits, as it references the global variables that store the addresses of the specially\r\nimported functions.\r\nOS Fingerprinting\r\nLike any other experienced exploit developer attempting to target as many OS versions as possible, our actor\r\nneeds to fingerprint the exact version of the immediate target. This means that the exploit identifies and calibrates\r\nitself to the target’s Windows version. In contrast to Volodya, it seems that PlayBit is interested in everything they\r\ncan learn about the target:\r\nOS major number\r\nOS minor number\r\nService pack\r\nServer or a standalone computer\r\nWindows 10 build number\r\nhttps://research.checkpoint.com/2020/graphology-of-an-exploit-playbit/\r\nPage 6 of 16\n\nFigure 4: Querying for the exact OS version, as can be seen in Cutter.\r\nGetVersionEx()\r\nWhile this API call is used in all of the exploits, it was used exclusively only in the exploit of CVE-2013-3660. As\r\nthis API became deprecated, the exploits from 2015 and later only use it when querying for the service pack and\r\nthe OS type. Both the major number and minor number of the Windows OS are now queried using a different\r\ntechnique.\r\nAccessing the PEB\r\nSwitching from the now deprecated GetVersionEx() , PlayBit chose to query the Process-Environment-Block\r\n(PEB).\r\nFigure 5: Extracting the major and\r\nminor versions from the PEB, as can be seen in Cutter.\r\nThis is a clear difference in the modus operandi of PlayBit as compared to Volodya. Not only do they extract the\r\nsame information in different ways, but Volodya is also interested in far less information than PlayBit, even when\r\nthey both exploit the same vulnerability (CVE-2016-7255).\r\nhttps://research.checkpoint.com/2020/graphology-of-an-exploit-playbit/\r\nPage 7 of 16\n\nIn general, both actors hold detailed version-specific configurations from which they load the relevant information\r\nonce the OS version is determined. The main difference between the two is that the code flow in Volodya’s\r\nexploits rarely depends on the OS version, while PlayBit incorporates multiple twists and turns using various if-checks that depend on the OS version.\r\nLeaking Kernel Addresses\r\nIn contrast to what we initially thought, a closer examination of PlayBit’s exploits showed that they do indeed\r\ncontain a kernel-pointer-leak primitive. Not only do the exploits contain such a leak, the chosen leak primitive\r\nhints at a high level of understanding of the internals of Windows. PlayBit directly accesses the Desktop Heap\r\nstored in user-mode, via the Win32ClientInfo field stored in the Thread-Environment-Block (TEB).\r\nFigure 6: Extracting information on the Desktop Heap, using TEB’s Win32ClientInfo.\r\nAs Microsoft gradually fixed the design issue that allowed for this pointer-leak, PlayBit had to implement some\r\nupdates along the way to allow this technique to continue to work. For instance, Creators Update removed the\r\nulClientDelta field from Win32ClientInfo , mandating that the exploit for CVE-2018-8453 calculate it\r\nmanually. This technique was finally patched by Microsoft in Windows 10 RS4.\r\nThe leak primitive enables PlayBit to learn the kernel addresses of the windows created during the exploitation. In\r\nturn, this information is used in several phases during the exploitation:\r\nThe addresses are used for pointing to / creating fake kernel objects.\r\nThe kernel memory shaping is measured by the distance between the leaked addresses.\r\nThe exploits usually invoke a kernel shellcode, and we need to know where it is stored.\r\nThe last point is explained in more detail in the next section.\r\nSMEP Bypass\r\nGeneration 0 – No Bypass\r\nIn the initial versions of the earlier exploits, such as the exploit for CVE-2013-3660 and some versions of CVE-2015-0057, the exploit caused the kernel to execute a token-swapping shellcode stored in user-mode.\r\nhttps://research.checkpoint.com/2020/graphology-of-an-exploit-playbit/\r\nPage 8 of 16\n\nFigure 7: PlayBit exploit scanning the EPROCESS in search for the token, as can be seen in Cutter.\r\nThe downside of this form of privilege-elevation is that SMEP prohibits the kernel from executing code that is\r\nstored in user-mode. Instead of changing the way the token-swap is performed, PlayBit decided to add an\r\nadditional layer that turns off SMEP. This way, the problem is reduced to the same token-swap problem that\r\nearlier exploits already solved. A classic academic solution.\r\nGeneration 1 – Kernel shellcode\r\nIn this set of exploits, an additional kernel shellcode was added. This bootloader code is copied to kernel-space\r\nand stored as the “window name” of one of the windows corrupted by the exploit. Upon execution, the code\r\nmodifies CR4 to disable the SMEP support, and then jumps back to the original user-mode payload.\r\nFigure 8: Checking for kernel-mode, and masking out the SMEP-related bit out of CR4.\r\nThe exploit copies the payload to the kernel using the NtUserDefSetText syscall, which explains why this syscall\r\nis included in the per-version configuration of all of the relevant exploits.\r\nNote that this SMEP bypass is based on the fact that the above code snippet can be executed, in kernel-mode, even\r\nthough it should have been a window name. The fact that memory pools were flagged as “executable” (or more\r\nspecifically, weren’t flagged as “non-executable”), was used by many attackers. Eventually, Microsoft noticed this\r\ndesign flaw in the kernel’s memory and introduced Non-eXecutable (NX) pools to the kernel.\r\nhttps://research.checkpoint.com/2020/graphology-of-an-exploit-playbit/\r\nPage 9 of 16\n\nOnce again, PlayBit decided to overcome this added restriction using yet another reduction, implemented in the\r\nexploit for CVE-2018-8453.\r\nGeneration 2 – Disabling the NX bit from the kernel shellcode\r\nThis additional change was more complicated than the previous one, as it also demanded the use of Arbitrary-Read and Arbitrary-Write kernel primitives. While the use of these primitives allows for a cleaner exploit to begin\r\nwith, as Volodya was doing since 2015, PlayBit only added it as an additional step in the reduction to the basic\r\nuser-mode token-swap payload.\r\nDuring this step, the page table entries are traversed in search of the entry associated with the kernel shellcode.\r\nOnce found, the entry is masked-out of the XD (eXecute Disable) bit, and stored back in the table. From this point\r\non, the memory page containing the kernel shellcode is executable, and thus the privilege-escalation chain can\r\nstart.\r\nFigure 9: Traversing the Page Table and removing the XD bit from the record of the kernel shellcode.\r\nAn exploit framework\r\nAfter finding enough samples that adhere to PlayBit’s exploit template for Windows memory corruption LPEs, we\r\ndecided to perform one more check. Using exploit-specific artifacts from each of the exploits, we created an\r\nadditional set of hunting rules and did one more search.\r\nIn this additional search, we found Ramnit samples which contain an exploit for CVE-2013-3660, but with some\r\nchanges:\r\nWhen checking if the target is vulnerable or patched, instead of looking for the driver’s modification date,\r\nthe exploit searches for a specific patch id in the registry, as can be seen in Figure 10 below.\r\nPlayBit’s hash-based imported functions are no longer used; GetProcAddress() is used instead.\r\nhttps://research.checkpoint.com/2020/graphology-of-an-exploit-playbit/\r\nPage 10 of 16\n\nFigure 10: A check for KB2850851 before exploiting CVE-2013-3660.\r\nOur Ramnit sample exploits both CVE-2013-3660 (by PlayBit) and CVE-2014-4113 (using the same exploit code\r\noriginally found as a 0-Day). The original exploit for CVE-2014-4113 was part of an exploit framework in which\r\nthe API passes a command-line argument, and that command is executed as SYSTEM. As that wasn’t the original\r\nAPI for PlayBit’s exploit, some adjustments were made and PlayBit’s exploits were re-adjusted to receive a\r\ncommand-line argument to be executed once elevated.\r\nWhen further investigating this new framework, we saw that it matched FireEye’s report on the Dyre Banking\r\nTrojan. As Dyre exploited CVE-2013-3660 and CVE-2015-0057, both of which were written by PlayBit, this\r\nmeans that during the lifetime of this exploit framework, it included at least the following 3 exploits:\r\nhttps://research.checkpoint.com/2020/graphology-of-an-exploit-playbit/\r\nPage 11 of 16\n\nCVE-2013-3660 – PlayBit.\r\nCVE-2014-4113 – 1-Day use of the original 0-Day exploit. Unknown author.\r\nCVE-2015-0057 – PlayBit.\r\nAside from connecting PlayBit to this now defunct exploit framework, we can deduce additional conclusions\r\nregarding our exploit-based hunting technique:\r\nOur hunting is mainly based on an actor’s given exploit template.\r\nWhen working with other associates, and collaborating on a given exploitation framework, this template is\r\nreplaced with the agreed-upon design modifications.\r\nGiven an initial exploitation framework sample, it is easier to find similar framework-related samples, than\r\nit is to find independent exploits of one of the authors who contributed to this framework.\r\nEssentially, both the attribution and the hunting are more complicated as the exploit framework masks many\r\ntelltale-signs of the individual exploit developer.\r\nIntelligence Report\r\nIn contrast to the previous blog post on Volodya, we decided this time to perform an additional “Background\r\nCheck” on PlayBit. Being unfamiliar with this actor, we thought it would be a good chance to better understand\r\nhow they work. In addition, we could test how well our exploit-based hunting technique works by comparing the\r\nfound list of advertisements to the actual samples we caught.\r\nPlayBit (a.k.a luxor2008)\r\nFunnily enough, attributing the exploits to our exploit writer was quite simple. It turns out that alongside the use\r\nof numerous underground forums, there are also public YouTube channels advertising the actor’s exploits.\r\nFigure 11: A screenshot from one of PlayBit’s YouTube channels.\r\nhttps://research.checkpoint.com/2020/graphology-of-an-exploit-playbit/\r\nPage 12 of 16\n\nFor some unknown reason, there are actually two YouTube channels: one for earlier exploits, and another one (still\r\nactive) for more recent exploits. As the videos publicly state which CVE is being exploited, the attribution process\r\nwas very short.\r\nWhen trying to learn more about this actor, we only found a single slim report. Therefore, we decided to include a\r\ndetailed profile of the actor in this blog post.\r\nThe Actor’s Advertisements\r\nAside from the YouTube channels we mentioned earlier, the actor used multiple platforms to advertise the\r\nvulnerabilities.\r\nFigure 12: Forum advertisement for CVE-2019-1069.\r\nWhether the ads were placed on underground forums, YouTube, or even Pastebin, they all shared a common\r\ntemplate:\r\n“\r\nRing0 LPE Exploit CVE-2015-0057 [All win versions]\r\nVulnerability: CVE-2015-0057 (Published: February 10, 2015)\r\nSupported versions: XP/2003/Vista/2008/W7/W8/2012/W8.1/2012R2/W10TP\r\nSupported architecture: x86/x64\r\nDevelopment stage: v1.1.1900 (stable)\r\nShellcode size x86: 13Kb\r\nShellcode size x64: 16Kb\r\nBypass all possible Windows security defences:\r\nSMEP\r\nKernel DEP\r\nhttps://research.checkpoint.com/2020/graphology-of-an-exploit-playbit/\r\nPage 13 of 16\n\nKASLR\r\nIntegrity Level (escape from Low)\r\nNULL Dereference Protection\r\nUAC\r\nThere are no public POCs on this vulnerability. Shellcode has ready for immediate use in your projects. The test\r\ndemo sources are supplied. Exploit is extremely stable, no bsods or error messages. Can be run under Guest\r\naccount from Low Integrity Level.\r\nSuccessfully bypasses proactive defences of:\r\nKIS 2015\r\nAvast IS 2015\r\nESET Smart Security 8\r\n“\r\nThese extensive ads emphasize the fact the exploit isn’t detected by AV vendors, and that public POCs do not exist\r\nor are of poor quality when compared to the exploit. The wide range of supported Windows versions is also\r\nevident: If a given Windows version is vulnerable to the exploited vulnerability, you can be sure that PlayBit’s\r\nexploit supports it.\r\nYears of activity\r\nWe successfully traced PlayBit to various exploits and tools going as far back as 2012. On average, the actor sells\r\na single Windows LPE 1-Day exploit per year, and that includes recent exploits for both CVE-2019-1069 (a\r\nSandboxEscaper vulnerability) and CVE-2020-0787 (yet another logical vulnerability).\r\nTransition to exploit logical vulnerabilities\r\nWhile we caught samples of 5 memory-corruption Windows LPE vulnerabilities, the ads show that in the last year\r\nor so the actor shifted their interest. Both of the recently sold exploits are now more logical in nature, and may\r\nindicate a trend in the exploitation market. Knowing that PlayBit’s previous exploits relied on a design flaw that\r\nwas fixed by Microsoft in Windows 10 RS 4 (released on April 30, 2018), it could be that Microsoft’s mitigations\r\nare one reason behind this shift in focus.\r\nPricing\r\nAs previously reported by Kaspersky, Volodya sold 0-Day exploits at prices ranging from $85,000 (exploit from\r\n2016) up to $200,000. While we don’t know what the selling price was for 1-Day exploits, we expected prices\r\nroughly in the same neighborhood. However, when going over the different ads published by PlayBit, we saw a\r\nwide pricing gap when compared to Volodya.\r\nAll Windows LPE exploits were advertised with a price tag ranging between $5,000 and $10,000. We even found\r\nthe actor using a fake nickname and claiming to sell a 0-Day exploit, which was in fact the 1-Day exploit for\r\nCVE-2016-7255. The asking price for this “0-Day” was still $35,000, way below the $85,000 for which Volodya\r\nhttps://research.checkpoint.com/2020/graphology-of-an-exploit-playbit/\r\nPage 14 of 16\n\nsold the real 0-Day exploit of the same vulnerability. In addition, we couldn’t find any pricing trend for the\r\ndifferent exploits, as all pretty much sold for the same price from 2015 to 2020.\r\nIntelligence Report Wrap-up\r\nAlthough not intuitive at first, the fact that we didn’t see ads for other CVEs (of the same exploitation template) is\r\nactually good news. It means that our technique worked better than expected: A fully technical hunt for PlayBit’s\r\nexploits, without any intelligence, still managed to cover all of their exploits that originated from the exploit\r\ntemplate with which we initially started.\r\nAside from Windows LPEs, we found two more interesting tools that PlayBit is developing/collaborating with.\r\nAvatar Rootkit\r\nESET mentioned this in 2013.\r\nUses the same hash-based imports that is still a feature of PlayBit today: get_module_by_hash() /\r\nget_func_by_hash() .\r\nThis Pastebin ad specifically mentions PlayBit as an associate.\r\nEternalBlack\r\nSelf-implemented EternalRomance\r\nAgain, uses features seen in all of the rest of the samples.\r\nFigure 13: Message printed when executing EternalBlack, developed by PlayBit.\r\nThe Customers\r\nThe “customers” i.e. malware who use PlayBit’s exploit, either directly or by using an exploit framework, are all\r\ncrimeware. Most prominent are the popular ransomware that use PlayBit’s exploits to escalate their privileges\r\nbefore encrypting the victim’s disk. These ransomware include Maze, Locky, LockCrypt, and REvil (Sodin,\r\nSodinokibi). Other malware are popular Trojans like Ramnit and Dyre.\r\nConclusion\r\nhttps://research.checkpoint.com/2020/graphology-of-an-exploit-playbit/\r\nPage 15 of 16\n\nIn this article, we demonstrated another case in which we were able to fingerprint an exploit developer, without\r\nprior knowledge about the developer or any public profiles. All we started with was a single sample. We showed\r\nhow PlayBit, similar to Volodya, has a unique set of choices, approaches, methodologies and combinations of\r\nimplementation decisions. By gathering all the pieces, we managed to understand and profile PlayBit, as well as\r\nattribute samples to the actor. We also took the opportunity to compare PlayBit to Volodya, and highlight the\r\ndifferences between their coding styles and preferences.\r\nAside from the technical aspects, this is the first time that PlayBit has been thoroughly described by researchers.\r\nWe took a look at the exploit market, the advertisements, YouTube channels and collaborations between exploit\r\ndevelopers and malware authors. Developing an exploit is just the beginning. The next step is to monetize the\r\n“product” and sell the customers a high-quality piece of software that is relatively stable and supports as many\r\nversions as possible.\r\nFollowing our success with profiling both PlayBit and Volodya, we believe that our research methodology can be\r\nused to identify additional exploit writers as well. We therefore recommend that other researchers try our approach\r\nand add it to their toolbox.\r\nRecommendation for Protection\r\nCheck Point Threat Emulation provides protection against this threat:\r\nWins.Generic.G\r\nAppendix – IOC Table\r\nCVE-2013-3660: 9f1a235eb38291cef296829be4b4d03618cd21e0b4f343f75a460c31a0ad62d3\r\nCVE-2015-0057: 1b3524fd57e4e836778d4af4579b6d986e7475ee6a1a7818ead0fc59efbdc2ac\r\nCVE-2015-1701 (Also contains an exploit for CVE-2015-0057):\r\n8869e0df9b5f4a894216c76aa5689686395c16296761716abece00a0b4234d87\r\nCVE-2016-7255: 5c27e05b788ba3b997a70df674d410322c3fa5e97079a7bf3aec369a0d397164\r\nCVE-2018-8453: 50da0183466a9852590de0d9e58bbe64f22ff8fc20a9ccc68ed0e50b367d7043\r\nAvatar Rootkit: d1a8d74aadb10bff4bfda144e68db3e087ec4fee82cd22df22839fd5435d0d37\r\nEternalBlack: effa8e38838ba7d2c58b2731c086ac72d639f9d2ab8184bc8cf05d72c5444dd1\r\nSource: https://research.checkpoint.com/2020/graphology-of-an-exploit-playbit/\r\nhttps://research.checkpoint.com/2020/graphology-of-an-exploit-playbit/\r\nPage 16 of 16\n\nAll Windows LPE the actor using a fake exploits were advertised nickname and with claiming to a price tag ranging sell a 0-Day between exploit, which was $5,000 and $10,000. in fact the 1-Day We even found exploit for\nCVe-2016-7255. The asking price for this “0-Day” was still $35,000, way below the $85,000 for which Volodya\n   Page 14 of 16",
	"extraction_quality": 1,
	"language": "EN",
	"sources": [
		"Malpedia"
	],
	"origins": [
		"web"
	],
	"references": [
		"https://research.checkpoint.com/2020/graphology-of-an-exploit-playbit/"
	],
	"report_names": [
		"graphology-of-an-exploit-playbit"
	],
	"threat_actors": [
		{
			"id": "0f47a6f3-a181-4e15-9261-50eef5f03a3a",
			"created_at": "2022-10-25T16:07:24.228663Z",
			"updated_at": "2026-04-10T02:00:04.905195Z",
			"deleted_at": null,
			"main_name": "Stealth Falcon",
			"aliases": [
				"FruityArmor",
				"G0038",
				"Project Raven",
				"Stealth Falcon"
			],
			"source_name": "ETDA:Stealth Falcon",
			"tools": [
				"Deadglyph",
				"StealthFalcon"
			],
			"source_id": "ETDA",
			"reports": null
		},
		{
			"id": "77aedfa3-e52b-4168-8269-55ccec0946f7",
			"created_at": "2023-01-06T13:46:38.453791Z",
			"updated_at": "2026-04-10T02:00:02.981559Z",
			"deleted_at": null,
			"main_name": "Stealth Falcon",
			"aliases": [
				"FruityArmor",
				"G0038"
			],
			"source_name": "MISPGALAXY:Stealth Falcon",
			"tools": [],
			"source_id": "MISPGALAXY",
			"reports": null
		},
		{
			"id": "75108fc1-7f6a-450e-b024-10284f3f62bb",
			"created_at": "2024-11-01T02:00:52.756877Z",
			"updated_at": "2026-04-10T02:00:05.273746Z",
			"deleted_at": null,
			"main_name": "Play",
			"aliases": null,
			"source_name": "MITRE:Play",
			"tools": [
				"Nltest",
				"AdFind",
				"PsExec",
				"Wevtutil",
				"Cobalt Strike",
				"Playcrypt",
				"Mimikatz"
			],
			"source_id": "MITRE",
			"reports": null
		},
		{
			"id": "730dfa6e-572d-473c-9267-ea1597d1a42b",
			"created_at": "2023-01-06T13:46:38.389985Z",
			"updated_at": "2026-04-10T02:00:02.954105Z",
			"deleted_at": null,
			"main_name": "APT28",
			"aliases": [
				"Pawn Storm",
				"ATK5",
				"Fighting Ursa",
				"Blue Athena",
				"TA422",
				"T-APT-12",
				"APT-C-20",
				"UAC-0001",
				"IRON TWILIGHT",
				"SIG40",
				"UAC-0028",
				"Sofacy",
				"BlueDelta",
				"Fancy Bear",
				"GruesomeLarch",
				"Group 74",
				"ITG05",
				"FROZENLAKE",
				"Forest Blizzard",
				"FANCY BEAR",
				"Sednit",
				"SNAKEMACKEREL",
				"Tsar Team",
				"TG-4127",
				"STRONTIUM",
				"Grizzly Steppe",
				"G0007"
			],
			"source_name": "MISPGALAXY:APT28",
			"tools": [],
			"source_id": "MISPGALAXY",
			"reports": null
		},
		{
			"id": "e3767160-695d-4360-8b2e-d5274db3f7cd",
			"created_at": "2022-10-25T16:47:55.914348Z",
			"updated_at": "2026-04-10T02:00:03.610018Z",
			"deleted_at": null,
			"main_name": "IRON TWILIGHT",
			"aliases": [
				"APT28 ",
				"ATK5 ",
				"Blue Athena ",
				"BlueDelta ",
				"FROZENLAKE ",
				"Fancy Bear ",
				"Fighting Ursa ",
				"Forest Blizzard ",
				"GRAPHITE ",
				"Group 74 ",
				"PawnStorm ",
				"STRONTIUM ",
				"Sednit ",
				"Snakemackerel ",
				"Sofacy ",
				"TA422 ",
				"TG-4127 ",
				"Tsar Team ",
				"UAC-0001 "
			],
			"source_name": "Secureworks:IRON TWILIGHT",
			"tools": [
				"Downdelph",
				"EVILTOSS",
				"SEDUPLOADER",
				"SHARPFRONT"
			],
			"source_id": "Secureworks",
			"reports": null
		},
		{
			"id": "ae320ed7-9a63-42ed-944b-44ada7313495",
			"created_at": "2022-10-25T15:50:23.671663Z",
			"updated_at": "2026-04-10T02:00:05.283292Z",
			"deleted_at": null,
			"main_name": "APT28",
			"aliases": [
				"APT28",
				"IRON TWILIGHT",
				"SNAKEMACKEREL",
				"Group 74",
				"Sednit",
				"Sofacy",
				"Pawn Storm",
				"Fancy Bear",
				"STRONTIUM",
				"Tsar Team",
				"Threat Group-4127",
				"TG-4127",
				"Forest Blizzard",
				"FROZENLAKE",
				"GruesomeLarch"
			],
			"source_name": "MITRE:APT28",
			"tools": [
				"Wevtutil",
				"certutil",
				"Forfiles",
				"DealersChoice",
				"Mimikatz",
				"ADVSTORESHELL",
				"Komplex",
				"HIDEDRV",
				"JHUHUGIT",
				"Koadic",
				"Winexe",
				"cipher.exe",
				"XTunnel",
				"Drovorub",
				"CORESHELL",
				"OLDBAIT",
				"Downdelph",
				"XAgentOSX",
				"USBStealer",
				"Zebrocy",
				"reGeorg",
				"Fysbis",
				"LoJax"
			],
			"source_id": "MITRE",
			"reports": null
		}
	],
	"ts_created_at": 1775434809,
	"ts_updated_at": 1775826691,
	"ts_creation_date": 0,
	"ts_modification_date": 0,
	"files": {
		"pdf": "https://archive.orkl.eu/d710405c3a7e5d9b721c9b26f2ebe4a2e1425b94.pdf",
		"text": "https://archive.orkl.eu/d710405c3a7e5d9b721c9b26f2ebe4a2e1425b94.txt",
		"img": "https://archive.orkl.eu/d710405c3a7e5d9b721c9b26f2ebe4a2e1425b94.jpg"
	}
}