{
	"id": "79bedfb1-63a4-46f6-80ae-663b2b31f63c",
	"created_at": "2026-04-06T00:20:21.189453Z",
	"updated_at": "2026-04-10T03:36:13.642075Z",
	"deleted_at": null,
	"sha1_hash": "143bc76ad269484e7de09963e43f2538e33850b1",
	"title": "The Crypto Game of Lazarus APT: Investors vs. Zero-days",
	"llm_title": "",
	"authors": "",
	"file_creation_date": "0001-01-01T00:00:00Z",
	"file_modification_date": "0001-01-01T00:00:00Z",
	"file_size": 8005777,
	"plain_text": "The Crypto Game of Lazarus APT: Investors vs. Zero-days\r\nBy Boris Larin\r\nPublished: 2024-10-23 · Archived: 2026-04-05 17:38:24 UTC\r\nIntroduction\r\nLazarus APT and its BlueNoroff subgroup are a highly sophisticated and multifaceted Korean-speaking threat\r\nactor. We closely monitor their activities and quite often see them using their signature malware in their attacks —\r\na full-feature backdoor called Manuscrypt. According to our research, Lazarus has been employing this malware\r\nsince at least 2013 and we’ve documented its usage in 50+ unique campaigns targeting governments, diplomatic\r\nentities, financial institutions, military and defense contractors, cryptocurrency platforms, IT and\r\ntelecommunication operators, gaming companies, media outlets, casinos, universities, and even security\r\nresearchers — the list goes on.\r\nOn May 13, 2024, our consumer-grade product Kaspersky Total Security detected a new Manuscrypt infection on\r\nthe personal computer of a person living in Russia. Since Lazarus rarely attacks individuals, this piqued our\r\ninterest and we decided to take a closer look. We discovered that prior to the detection of Manuscrypt, our\r\ntechnologies also detected exploitation of the Google Chrome web browser originating from the website\r\ndetankzone[.]com. On the surface, this website resembled a professionally designed product page for a\r\ndecentralized finance (DeFi) NFT-based (non-fungible token) multiplayer online battle arena (MOBA) tank game,\r\ninviting users to download a trial version. But that was just a disguise. Under the hood, this website had a hidden\r\nscript that ran in the user’s Google Chrome browser, launching a zero-day exploit and giving the attackers\r\ncomplete control over the victim’s PC. Visiting the website was all it took to get infected — the game was just a\r\ndistraction.\r\nWe were able to extract the first stage of the attack — an exploit that performs remote code execution in the\r\nGoogle Chrome process. After confirming that the exploit was based on a zero-day vulnerability targeting the\r\nlatest version of Google Chrome, we reported our findings to Google the same day. Two days later, Google\r\nreleased an update and thanked us for discovering this attack.\r\nAcknowledgement for finding CVE-2024-4947 (excerpt from the security fixes included into Chrome\r\n125.0.6422.60)\r\nHaving notified Google about the discovered vulnerability, we followed responsible vulnerability disclosure\r\npolicy and refrained from sharing specific details in public, giving users sufficient time to apply the patch. This\r\napproach is also intended to prevent further exploitation by threat actors. Google took additional steps by blocking\r\ndetankzone[.]com and other websites linked to this campaign, ensuring that anyone attempting to access these\r\nsites — even without our products — would be warned of their malicious nature.\r\nhttps://securelist.com/lazarus-apt-steals-crypto-with-a-tank-game/114282/\r\nPage 1 of 16\n\nWhile we respected Google’s request for a set disclosure period, on May 28, 2024, Microsoft published a blog\r\npost titled “Moonstone Sleet emerges as new North Korean threat actor with new bag of tricks,” which partially\r\nrevealed our findings. According to the blog, Microsoft had also been tracking the campaign and associated\r\nwebsites since February 2024. However, their analysis overlooked a key point in the malicious campaign: the\r\npresence of the browser exploit and the fact that it was a high-severity issue — a zero-day. In this report, we\r\nexplore in great detail the vulnerabilities exploited by the attackers and the game they used as bait (spoiler alert:\r\nwe had to develop our own server for this online game).\r\nThe exploit\r\nThe website used by the attackers as a cover for their campaign was developed in TypeScript/React, and one of its\r\nindex.tsx files contained a small piece of code that loads and executes the Google Chrome exploit.\r\nWebsite facade and the hidden exploit loader\r\nThe exploit contains code for two vulnerabilities: the first is used to gain the ability to read and write Chrome\r\nprocess memory from the JavaScript, and the second is used to bypass the recently introduced V8 sandbox.\r\nFirst vulnerability (CVE-2024-4947)\r\nThe heart of every web browser is its JavaScript engine. The JavaScript engine of Google Chrome is called V8 —\r\nGoogle’s own open-source JavaScript engine. For lower memory consumption and maximum speed, V8 uses a\r\nfairly complex JavaScript compilation pipeline, currently consisting of one interpreter and three JIT compilers.\r\nhttps://securelist.com/lazarus-apt-steals-crypto-with-a-tank-game/114282/\r\nPage 2 of 16\n\nV8’s JavaScript compilation pipeline\r\nWhen V8 starts to execute JavaScript, it first compiles the script into bytecode and executes it using the interpreter\r\ncalled Ignition. Ignition is a register-based machine with several hundred instructions. While executing bytecode,\r\nV8 monitors the program’s behavior, and may JIT-compile some functions for better performance. The best and\r\nfastest code is produced by TurboFan, a highly optimizing compiler with one drawback — the code generation\r\ntakes too much time. Still, the difference in performance between Ignition and TurboFan was so significant that a\r\nnew non-optimizing JIT compiler was introduced in 2021 called Sparkplug, which compiles bytecode into\r\nequivalent machine code almost instantly. Sparkplug-generated code runs faster than the interpreter, but the\r\nperformance gap between Sparkplug- and TurboFan-generated code was still big. Because of this, in Chrome 117\r\n(released in Q4 2023), the developers introduced a new optimizing compiler, Maglev, whose goal is to generate\r\ngood enough code fast enough by performing optimizations based solely on feedback from the interpreter. CVE-2024-4947 (issue 340221135) is the vulnerability in this new compiler.\r\nTo understand this vulnerability and how it was exploited, let’s take a look at the code the attackers used to trigger\r\nit.\r\n1\r\n2\r\n3\r\n4\r\n5\r\nimport * as moduleImport from 'export var exportedVar = 23;';\r\nfunction trigger() {\r\n  moduleImport.exportedVar;\r\n  const emptyArray = [1, 2];\r\n  emptyArray.pop();\r\nhttps://securelist.com/lazarus-apt-steals-crypto-with-a-tank-game/114282/\r\nPage 3 of 16\n\n6\r\n7\r\n8\r\n9\r\n10\r\n11\r\n12\r\n13\r\n14\r\n15\r\n16\r\n17\r\n18\r\n19\r\n20\r\n21\r\n  emptyArray.pop();\r\n  const arrHolder = {xxarr: doubleArray, xxab: fakeArrayBuffer};\r\n  function f() {\r\n    try {\r\n      moduleImport.exportedVar = 3.79837e-312;\r\n    } catch (e) { return false;  }\r\n    return true;\r\n  }\r\n  while (!f()) { }\r\n  weakRef = new WeakRef(moduleImport);\r\n  return {emptyArray, arrHolder};\r\n}\r\nCode used by the attackers to trigger CVE-2024-4947\r\nWe can see in this code that it first accesses the exported variable exportedVar of the moduleImport module and\r\nthen creates the emptyArray array and the arrHolder dictionary. However, it seems that no real work is done with\r\nthem, they are just returned by the function trigger. And then something interesting happens – the f function is\r\nexecuted until it returns “true”. However, this function returns “true” only if it can set the exported variable\r\nmoduleImport.exportedVar to the “3.79837e-312” value, and if an exception occurs because of this, the f function\r\nreturns “false”. How could it be that executing the same expression moduleImport.exportedVar = 3.79837e-312;\r\nshould always return “false” until it returns “true”?\r\nLdaImmutableCurrentContextSlot [53]\r\nStar1\r\nLdaConstant [0]\r\nhttps://securelist.com/lazarus-apt-steals-crypto-with-a-tank-game/114282/\r\nPage 4 of 16\n\nSetNamedProperty r1, [1], [0] // moduleImport.exportedVar = 3.79837e-312;\r\nBytecode produced by the Ignition interpreter for “moduleImport.exportedVar = 3.79837e-312;”\r\nIf we take a look at the bytecode produced for this expression by Ignition and at the code of the\r\nSetNamedProperty instruction handler, which is supposed to set this variable to the “3.79837e-312” value, we can\r\nsee that it will always throw an exception — according to the ECMAScript specification, storing in a module\r\nobject is always an error in JavaScript.\r\nmov     rax, 309000D616Dh // JS object ptr for \"moduleImport\"\r\nmov     edi, [rax+3]    \r\nadd     rdi, r14        \r\nmov     rax, 309001870B5h // JS object ptr for \"3.79837e-312\"\r\nmov     [rdi-1], eax\r\nJIT code produced by Maglev for “moduleImport.exportedVar = 3.79837e-312;”\r\nBut if we wait until this bytecode has been executed enough times and V8 decides to compile it using the Maglev\r\ncompiler, we’ll see that the resulting machine code doesn’t throw an exception, but actually sets this property\r\nsomewhere in the moduleImport object. This happens due to a missing check for storing to module exports —\r\nwhich is the CVE-2024-4947 vulnerability (you can find the fix here). How do attackers exploit it? To answer this,\r\nwe need to understand how JavaScript objects are represented in memory.\r\nStructure of JS objects\r\nhttps://securelist.com/lazarus-apt-steals-crypto-with-a-tank-game/114282/\r\nPage 5 of 16\n\nAll JS objects begin with a pointer to a special object called Map (also known as HiddenClass) which stores meta\r\ninformation about the object and describes its structure. It contains the object’s type (stored at a +8 offset), number\r\nof properties, and so on.\r\nStructure of the “moduleImport” JS object\r\nThe moduleImport module is represented in memory as a JSReceiver object, which is the most generic JS object\r\nand is used for types for which properties can be defined. It includes a pointer to the array of properties (\r\nPropertyArray) which is basically a regular JS object of the FixedArray type with its own Map. If in the\r\nexpression moduleImport.exportedVar = 3.79837e-312; moduleImport was not a module but a regular object, the\r\ncode would set the property #0 in that array, writing at a +8 offset; however, since it is a module and there is a\r\nbug, the code sets this property, writing at a +0 offset, overwriting the Map object with the provided object.\r\nStructure of the “3.79837e-312” number JS object\r\nSince 3.79837e-312 is a floating-point number, it is converted to a 64-bit value (according to the IEEE 754\r\nstandard) and stored in a HeapNumber JS object at a +4 offset. This allows the attackers to set their own type for\r\nthe PropertyArray object and cause a type confusion. Setting the type to 0xB2 causes V8 to treat the\r\nPropertyArray as a PropertyDictionary, which results in memory corruption because the PropertyArray and\r\nhttps://securelist.com/lazarus-apt-steals-crypto-with-a-tank-game/114282/\r\nPage 6 of 16\n\nPropertyDictionary objects are of different sizes and the kLengthAndHashOffset field of the PropertyDictionary\r\nfalls outside the bounds of the PropertyArray.\r\nNow the attackers need to get the right memory layout and corrupt something useful. They defragment the heap\r\nand perform the actions that you can see in the trigger function.\r\nMemory layout created by the “trigger” function\r\nWhat happens in this function is the following:\r\n1. 1 It accesses the exported module variable moduleImport.exportedVar to allocate moduleImport’s\r\nPropertyArray.\r\n2. 2 It creates an emptyArray with two elements.\r\n3. 3 Removing elements from this array reallocates the object that is used for storing the elements and sets\r\nemptyArray’s length to 0. This is an important step because in order to overwrite emptyArray’s length with\r\nPropertyDictionary’s hash, the length/hash must be equal to 0.\r\n4. 4 The trigger function creates the arrHolder dictionary with two objects. This step follows the creation of\r\nthe emptyArray to allow the pointers of these two objects to be accessed and overwritten when the length\r\nof emptyArray is corrupted. The first object, xxarr: doubleArray is used to construct a primitive for getting\r\nthe addresses of JS objects. The second object, xxab: fakeArrayBuffer is used to construct a primitive for\r\ngetting read/write access to the whole address space of the Chrome process.\r\n5. 5 Next, the trigger function executes the f function until it is compiled by Maglev, and overwrites the type\r\nof the PropertyArray so it is treated as a PropertyDictionary object.\r\n6. 6 Executing new WeakRef(moduleImport) triggers the calculation of PropertyDictionary’s hash, and the\r\nlength of emptyArray is overwritten with the hash value.\r\n7. 7 The trigger function returns emptyArray and arrHolder containing objects that can be overwritten with\r\nemptyArray.\r\nAfter this, the exploit again abuses Maglev, or rather the fact that it optimizes the code based on the feedback\r\ncollected by the interpreter. The exploit uses Maglev to compile a function that loads a double value from an array\r\nobtained using arrHolder.xxarr. When this function is compiled, the attackers can overwrite the pointer to an array\r\nobtained using arrHolder.xxarr via emptyArray[5] and use this function to get the addresses of JS objects.\r\nSimilarly, the attackers use arrHolder.xxab to compile a function that sets specific properties and overwrites the\r\nhttps://securelist.com/lazarus-apt-steals-crypto-with-a-tank-game/114282/\r\nPage 7 of 16\n\nlength of another ArrayBuffer-type object along with the pointer to its data (backing_store_ptr). This becomes\r\npossible when the pointer to the object accessible via arrHolder.xxab is replaced via emptyArray[6] with a pointer\r\nto the ArrayBuffer. This gives the attackers read and write access to the entire address space of the Chrome\r\nprocess.\r\nSecond vulnerability (V8 sandbox bypass)\r\nAt this point, the attackers can read and write memory from JavaScript, but they need an additional vulnerability\r\nto bypass the newly introduced V8 (heap) sandbox. This sandbox is purely software-based and its main function is\r\nto isolate the V8 memory (heap) in such a way that attackers cannot access other parts of the memory and execute\r\ncode. How does it do this? You may have noticed that all the pointers in the previous section are 32 bits long. This\r\nis not because we’re talking about a 32-bit process. It’s a 64-bit process, but the pointers are 32 bits long because\r\nV8 uses something called pointer compression. The pointers are not stored in full, but just as their lower parts, or\r\nthey could also be seen as a 32-bit offset from some “base” address. The upper part (the “base” address) is stored\r\nin CPU registers and added by the code. In this case, attackers should not be able to obtain real pointers from the\r\nisolated memory and have no way to obtain addresses for the stack and JIT-code pages.\r\nTo bypass the V8 sandbox, the attackers used an interesting but very common vulnerability associated with\r\ninterpreters — we have previously seen variations of this vulnerability in multiple virtual machine\r\nimplementations. In V8, regular expressions are implemented using its own interpreter, Irregexp, with its own set\r\nof opcodes. The Irregexp VM is completely different from Ignition, but it is also a register-based VM.\r\nhttps://securelist.com/lazarus-apt-steals-crypto-with-a-tank-game/114282/\r\nPage 8 of 16\n\nRegisterT\u0026 operator[](size_t index) { return registers_[index]; }\r\nBYTECODE(PUSH_REGISTER) {\r\n     ADVANCE(PUSH_REGISTER);\r\n     if (!backtrack_stack.push(registers[LoadPacked24Unsigned(insn)])) {\r\n       return MaybeThrowStackOverflow(isolate, call_origin);\r\n     }\r\n     DISPATCH();\r\n}\r\nBYTECODE(SET_REGISTER) {\r\n     ADVANCE(SET_REGISTER);\r\n     registers[LoadPacked24Unsigned(insn)] = Load32Aligned(pc + 4);\r\n     DISPATCH();\r\n}\r\nExamples of vulnerable code in Irregexp VM instruction handlers\r\nThe vulnerability is that the virtual machine has a fixed number of registers and a dedicated array for storing them,\r\nbut the register indexes are decoded from the instruction bodies and are not checked. This allows attackers to\r\naccess the memory outside the bounds of the register array.\r\nPUSH_REGISTER r(REGISTERS_COUNT + idx)\r\nPOP_REGISTER  r(0)\r\nPUSH_REGISTER r(REGISTERS_COUNT + idx + 1)\r\nPOP_REGISTER  r(1)\r\n// Overwrite \"output_registers\" ptr\r\nSET_REGISTER  r(REGISTERS_COUNT), holderAddressLow\r\nSET_REGISTER  r(REGISTERS_COUNT + 1), holderAddressHigh\r\n// Overwrite \"output_register_count\"\r\nhttps://securelist.com/lazarus-apt-steals-crypto-with-a-tank-game/114282/\r\nPage 9 of 16\n\nSET_REGISTER  r(REGISTERS_COUNT + 2), 2\r\n// MemCopy(output_registers_, registers_.data(), output_register_count_ * sizeof(RegisterT));\r\nSUCCEED\r\nMalicious Irregexp VM bytecode for reading the memory outside of the register array bounds\r\nCoincidentally, the pointers to output_registers and output_register_count are located right next to the register\r\narray. This allows the attackers to read and write the memory outside of the V8 sandbox with the help of the\r\nSUCCEED opcode. Attackers use this to overwrite JIT’ed code with shellcode and execute it.\r\nThis issue (330404819) was submitted and fixed in March 2024. It is unknown whether it was a bug collision and\r\nthe attackers discovered it first and initially exploited it as a 0-day vulnerability, or if it was initially exploited as a\r\n1-day vulnerability.\r\nShellcode\r\nAt this point, the attackers need additional vulnerabilities to escape the Chrome process and gain full access to the\r\nsystem. In the best practices of sophisticated attackers, they run a validator in the form of a shellcode that collects\r\nas much information as possible and sends it to the server to decide whether to provide the next stage (another\r\nexploit) or not. This decision is made based on the following information: CPUID information (vendor, processor\r\nname, etc), whether it’s running on a VM or not, OS version and build, number of processors, tick count, OS\r\nproduct type, whether it’s being debugged or not, process path, file version info of system modules, file version\r\ninfo of process executable, and SMBIOS firmware table.\r\nBy the time we analyzed the attack, the attackers had already removed the exploit from the decoy website,\r\npreventing us from easily obtaining the next stage of the attack. At Kaspersky, we possess technologies that have\r\nallowed us to discover and help to fix a huge number of 0-day privilege escalation vulnerabilities exploited by\r\nsophisticated attackers in various malware campaigns over the years; however, in this particular case we would\r\nhave to wait for the next attack in order to extract its next stage. We’ve decided to not wait, preferring to let\r\nGoogle fix the initial exploit used to perform the remote code execution in Google Chrome.\r\nhttps://securelist.com/lazarus-apt-steals-crypto-with-a-tank-game/114282/\r\nPage 10 of 16\n\nList of in-the-wild 0-days caught and reported by Kaspersky over the past 10 years\r\nWhat never ceases to impress us is how much effort Lazarus APT puts into their social engineering campaigns.\r\nFor several months, the attackers were building their social media presence, regularly making posts on X\r\n(formerly Twitter) from multiple accounts and promoting their game with content produced by generative AI and\r\ngraphic designers.\r\nAttackers’ accounts on X\r\nhttps://securelist.com/lazarus-apt-steals-crypto-with-a-tank-game/114282/\r\nPage 11 of 16\n\nOne of the tactics used by the attackers was to contact influential figures in the cryptocurrency space to get them\r\nto promote their malicious website and most likely to also compromise them.\r\nAttackers’ attempts to contact crypto-influencers\r\nThe attackers’ activity was not limited to X — they also used professionally designed websites with additional\r\nmalware, premium accounts on LinkedIn, and spear phishing through email.\r\nThe game\r\nMalicious website offering to download a beta version of the game\r\nhttps://securelist.com/lazarus-apt-steals-crypto-with-a-tank-game/114282/\r\nPage 12 of 16\n\nWhat particularly caught our attention in this attack was that the malicious website attacking its visitors using a\r\nGoogle Chrome zero-day was inviting them to download and try a beta version of a computer game. As big\r\ncomputer games fans ourselves, we immediately wanted to try it. Could the attackers have developed a real game\r\nfor this campaign? Could this be the first computer game ever developed by a threat actor? We downloaded\r\ndetankzone.zip and it looked legit: the 400 MB-archive contained a valid file structure of a game developed in\r\nUnity. We unpacked the game’s resources and found “DeTankZone” logos, HUD elements, and 3D model\r\ntextures. Debugging artifacts indicated that the game had been compiled by the attackers. We decided to give it a\r\nspin.\r\nStart menu of the DeTankZone game\r\nAfter an intro with the game’s logo, we are greeted with a typical online gaming start menu, asking us to enter\r\nvalid account credentials to access the game. We tried to log in using some common account names and\r\npasswords, and then tried to register our own account through the game and the website — but nothing worked.\r\nIs that really all this game has to offer? We started reverse engineering the game’s code and discovered that there\r\nwas more content available beyond this start menu. We found the code responsible for communication with the\r\ngame server and started reverse engineering that as well. The game was hardcoded to use the server running at\r\n“api.detankzone[.]com,” which clearly wasn’t working. But we really wanted to check this game out! What to do?\r\nWe decided to develop our own game server, of course.\r\nFirst, we discovered that the game uses the Socket.IO protocol to communicate with the server, so we chose the\r\npython-socketio library to develop our own server. We then found a function with a list of all supported command\r\nnames (event names) and reverse engineered how they are obfuscated. After that, we reverse engineered how the\r\ndata was encoded: it turned out to be a JSON encrypted with AES256 and encoded with Base64. For the AES key\r\nit uses the string “Full Stack IT Service 198703Game”, while the string “MatGoGameProject” is used for the IV.\r\nWe hoped that this information might reveal the identities of the game’s developers, but a Google search yielded\r\nhttps://securelist.com/lazarus-apt-steals-crypto-with-a-tank-game/114282/\r\nPage 13 of 16\n\nno results. Finally, we reverse engineered the data format for a couple of commands, implemented them on our\r\nserver, and replaced the server URL with the address of our own server. Success! After all this we were able to log\r\ninto the game and play with the bots!\r\nScreenshot from the game running with our custom server\r\nYes, it turned out to be a real game! We played it for a bit and it was fun — it reminded us of some shareware\r\ngames from the early 2000s. Definitely worth the effort. The textures look a little tacky and the game itself closely\r\nresembles a popular Unity tutorial, but if Lazarus had developed this game themselves, it would have set a new\r\nbar for attack preparation. But no — Lazarus stayed true to themselves. It turns out that the source code for this\r\ngame was stolen from its original developers.\r\nThe original game\r\nhttps://securelist.com/lazarus-apt-steals-crypto-with-a-tank-game/114282/\r\nPage 14 of 16\n\nDeFiTankLand (DFTL) – the original game\r\nWe found a legitimate game that served as a prototype for the attacker’s version – it’s called DeFiTankLand\r\n(DFTL). Studying the developers’ Telegram chat helped us build a timeline of the attack. On February 20, 2024,\r\nthe attackers began their campaign, advertising their game on X. Two weeks later, on March 2, 2024, the price of\r\nthe DeFiTankLand’s currency, DFTL2 coin, dropped, and the game’s developers announced on their Telegram that\r\ntheir cold wallet had been hacked and $20,000 worth of DFTL2 coins had been stolen. The developers blamed an\r\ninsider for this. Insider or not, we suspect that this was the work of Lazarus, and that before stealing the coins they\r\nfirst stole the game’s source code, modified all the logos and references to DeFiTankLand, and used it to make\r\ntheir campaign more credible.\r\nConclusions\r\nLazarus is one of the most active and sophisticated APT actors, and financial gain remains one of their top\r\nmotivations. Over the years, we have uncovered many of their attacks on the cryptocurrency industry, and one\r\nthing is certain: these attacks are not going away. The attackers’ tactics are evolving and they’re constantly coming\r\nup with new, complex social engineering schemes. Lazarus has already successfully started using generative AI,\r\nand we predict that they will come up with even more elaborate attacks using it. What makes Lazarus’s attacks\r\nparticularly dangerous is their frequent use of zero-day exploits. Simply clicking a link on a social network or in\r\nan email can lead to the complete compromise of a personal computer or corporate network.\r\nHistorically, half of the bugs discovered or exploited in Google Chrome and other web browsers have affected its\r\ncompilers. Huge changes in the code base of the web browser and the introduction of new JIT compilers\r\ninevitably lead to a large number of new vulnerabilities. What can end users do about this? While Google Chrome\r\ncontinues to add new JIT compilers, there is also Microsoft Edge, which can run without JIT at all. But it’s also\r\nfair to say that the newly introduced V8 sandbox might be very successful at stopping bugs exploitation in\r\ncompilers. Once it becomes more mature, exploiting Google Chrome with JIT may be as difficult as exploiting\r\nMicrosoft Edge without it.\r\nhttps://securelist.com/lazarus-apt-steals-crypto-with-a-tank-game/114282/\r\nPage 15 of 16\n\nIndicators of Compromise\r\nExploit\r\nB2DC7AEC2C6D2FFA28219AC288E4750C\r\nE5DA4AB6366C5690DFD1BB386C7FE0C78F6ED54F\r\n7353AB9670133468081305BD442F7691CF2F2C1136F09D9508400546C417833A\r\nGame\r\n8312E556C4EEC999204368D69BA91BF4\r\n7F28AD5EE9966410B15CA85B7FACB70088A17C5F\r\n59A37D7D2BF4CFFE31407EDD286A811D9600B68FE757829E30DA4394AB65A4CC\r\nDomains\r\ndetankzone[.]com\r\nccwaterfall[.]com\r\nSource: https://securelist.com/lazarus-apt-steals-crypto-with-a-tank-game/114282/\r\nhttps://securelist.com/lazarus-apt-steals-crypto-with-a-tank-game/114282/\r\nPage 16 of 16",
	"extraction_quality": 1,
	"language": "EN",
	"sources": [
		"ETDA"
	],
	"references": [
		"https://securelist.com/lazarus-apt-steals-crypto-with-a-tank-game/114282/"
	],
	"report_names": [
		"114282"
	],
	"threat_actors": [
		{
			"id": "f8dddd06-da24-4184-9e24-4c22bdd1cbbf",
			"created_at": "2023-01-06T13:46:38.626906Z",
			"updated_at": "2026-04-10T02:00:03.043681Z",
			"deleted_at": null,
			"main_name": "Tick",
			"aliases": [
				"G0060",
				"Stalker Taurus",
				"PLA Unit 61419",
				"Swirl Typhoon",
				"Nian",
				"BRONZE BUTLER",
				"REDBALDKNIGHT",
				"STALKER PANDA"
			],
			"source_name": "MISPGALAXY:Tick",
			"tools": [],
			"source_id": "MISPGALAXY",
			"reports": null
		},
		{
			"id": "45e6e2b3-43fe-44cd-8025-aea18a7f488f",
			"created_at": "2024-06-20T02:02:09.897489Z",
			"updated_at": "2026-04-10T02:00:04.769917Z",
			"deleted_at": null,
			"main_name": "Moonstone Sleet",
			"aliases": [
				"Storm-1789",
				"Stressed Pungsan"
			],
			"source_name": "ETDA:Moonstone Sleet",
			"tools": [],
			"source_id": "ETDA",
			"reports": null
		},
		{
			"id": "28523c53-1944-4ff0-bbdc-89b06e4e3c84",
			"created_at": "2024-11-01T02:00:52.752463Z",
			"updated_at": "2026-04-10T02:00:05.359782Z",
			"deleted_at": null,
			"main_name": "Moonstone Sleet",
			"aliases": [
				"Moonstone Sleet",
				"Storm-1789"
			],
			"source_name": "MITRE:Moonstone Sleet",
			"tools": [
				"Qilin"
			],
			"source_id": "MITRE",
			"reports": null
		},
		{
			"id": "732597b1-40a8-474c-88cc-eb8a421c29f1",
			"created_at": "2025-08-07T02:03:25.087732Z",
			"updated_at": "2026-04-10T02:00:03.776007Z",
			"deleted_at": null,
			"main_name": "NICKEL GLADSTONE",
			"aliases": [
				"APT38 ",
				"ATK 117 ",
				"Alluring Pisces ",
				"Black Alicanto ",
				"Bluenoroff ",
				"CTG-6459 ",
				"Citrine Sleet ",
				"HIDDEN COBRA ",
				"Lazarus Group",
				"Sapphire Sleet ",
				"Selective Pisces ",
				"Stardust Chollima ",
				"T-APT-15 ",
				"TA444 ",
				"TAG-71 "
			],
			"source_name": "Secureworks:NICKEL GLADSTONE",
			"tools": [
				"AlphaNC",
				"Bankshot",
				"CCGC_Proxy",
				"Ratankba",
				"RustBucket",
				"SUGARLOADER",
				"SwiftLoader",
				"Wcry"
			],
			"source_id": "Secureworks",
			"reports": null
		},
		{
			"id": "54e55585-1025-49d2-9de8-90fc7a631f45",
			"created_at": "2025-08-07T02:03:24.563488Z",
			"updated_at": "2026-04-10T02:00:03.715427Z",
			"deleted_at": null,
			"main_name": "BRONZE BUTLER",
			"aliases": [
				"CTG-2006 ",
				"Daserf",
				"Stalker Panda ",
				"Swirl Typhoon ",
				"Tick "
			],
			"source_name": "Secureworks:BRONZE BUTLER",
			"tools": [
				"ABK",
				"BBK",
				"Casper",
				"DGet",
				"Daserf",
				"Datper",
				"Ghostdown",
				"Gofarer",
				"MSGet",
				"Mimikatz",
				"Netboy",
				"RarStar",
				"Screen Capture Tool",
				"ShadowPad",
				"ShadowPy",
				"T-SMB",
				"down_new",
				"gsecdump"
			],
			"source_id": "Secureworks",
			"reports": null
		},
		{
			"id": "a2b92056-9378-4749-926b-7e10c4500dac",
			"created_at": "2023-01-06T13:46:38.430595Z",
			"updated_at": "2026-04-10T02:00:02.971571Z",
			"deleted_at": null,
			"main_name": "Lazarus Group",
			"aliases": [
				"Operation DarkSeoul",
				"Bureau 121",
				"Group 77",
				"APT38",
				"NICKEL GLADSTONE",
				"G0082",
				"COPERNICIUM",
				"Moonstone Sleet",
				"Operation GhostSecret",
				"APT 38",
				"Appleworm",
				"Unit 121",
				"ATK3",
				"G0032",
				"ATK117",
				"NewRomanic Cyber Army Team",
				"Nickel Academy",
				"Sapphire Sleet",
				"Lazarus group",
				"Hastati Group",
				"Subgroup: Bluenoroff",
				"Operation Troy",
				"Black Artemis",
				"Dark Seoul",
				"Andariel",
				"Labyrinth Chollima",
				"Operation AppleJeus",
				"COVELLITE",
				"Citrine Sleet",
				"DEV-0139",
				"DEV-1222",
				"Hidden Cobra",
				"Bluenoroff",
				"Stardust Chollima",
				"Whois Hacking Team",
				"Diamond Sleet",
				"TA404",
				"BeagleBoyz",
				"APT-C-26"
			],
			"source_name": "MISPGALAXY:Lazarus Group",
			"tools": [],
			"source_id": "MISPGALAXY",
			"reports": null
		},
		{
			"id": "f426f0a0-faef-4c0e-bcf8-88974116c9d0",
			"created_at": "2022-10-25T15:50:23.240383Z",
			"updated_at": "2026-04-10T02:00:05.299433Z",
			"deleted_at": null,
			"main_name": "APT38",
			"aliases": [
				"APT38",
				"NICKEL GLADSTONE",
				"BeagleBoyz",
				"Bluenoroff",
				"Stardust Chollima",
				"Sapphire Sleet",
				"COPERNICIUM"
			],
			"source_name": "MITRE:APT38",
			"tools": [
				"ECCENTRICBANDWAGON",
				"HOPLIGHT",
				"Mimikatz",
				"KillDisk",
				"DarkComet"
			],
			"source_id": "MITRE",
			"reports": null
		},
		{
			"id": "1bdb91cf-f1a6-4bed-8cfa-c7ea1b635ebd",
			"created_at": "2022-10-25T16:07:23.766784Z",
			"updated_at": "2026-04-10T02:00:04.7432Z",
			"deleted_at": null,
			"main_name": "Bluenoroff",
			"aliases": [
				"APT 38",
				"ATK 117",
				"Alluring Pisces",
				"Black Alicanto",
				"Bluenoroff",
				"CTG-6459",
				"Copernicium",
				"G0082",
				"Nickel Gladstone",
				"Sapphire Sleet",
				"Selective Pisces",
				"Stardust Chollima",
				"T-APT-15",
				"TA444",
				"TAG-71",
				"TEMP.Hermit"
			],
			"source_name": "ETDA:Bluenoroff",
			"tools": [],
			"source_id": "ETDA",
			"reports": null
		},
		{
			"id": "d4e7cd9a-2290-4f89-a645-85b9a46d004b",
			"created_at": "2022-10-25T16:07:23.419513Z",
			"updated_at": "2026-04-10T02:00:04.591062Z",
			"deleted_at": null,
			"main_name": "Bronze Butler",
			"aliases": [
				"Bronze Butler",
				"CTG-2006",
				"G0060",
				"Operation ENDTRADE",
				"RedBaldNight",
				"Stalker Panda",
				"Stalker Taurus",
				"Swirl Typhoon",
				"TEMP.Tick",
				"Tick"
			],
			"source_name": "ETDA:Bronze Butler",
			"tools": [
				"8.t Dropper",
				"8.t RTF exploit builder",
				"8t_dropper",
				"9002 RAT",
				"AngryRebel",
				"Blogspot",
				"Daserf",
				"Datper",
				"Elirks",
				"Farfli",
				"Gh0st RAT",
				"Ghost RAT",
				"HOMEUNIX",
				"HidraQ",
				"HomamDownloader",
				"Homux",
				"Hydraq",
				"Lilith",
				"Lilith RAT",
				"McRAT",
				"MdmBot",
				"Mimikatz",
				"Minzen",
				"Moudour",
				"Muirim",
				"Mydoor",
				"Nioupale",
				"PCRat",
				"POISONPLUG.SHADOW",
				"Roarur",
				"RoyalRoad",
				"ShadowPad Winnti",
				"ShadowWali",
				"ShadowWalker",
				"SymonLoader",
				"WCE",
				"Wali",
				"Windows Credential Editor",
				"Windows Credentials Editor",
				"XShellGhost",
				"XXMM",
				"gsecdump",
				"rarstar"
			],
			"source_id": "ETDA",
			"reports": null
		}
	],
	"ts_created_at": 1775434821,
	"ts_updated_at": 1775792173,
	"ts_creation_date": 0,
	"ts_modification_date": 0,
	"files": {
		"pdf": "https://archive.orkl.eu/143bc76ad269484e7de09963e43f2538e33850b1.pdf",
		"text": "https://archive.orkl.eu/143bc76ad269484e7de09963e43f2538e33850b1.txt",
		"img": "https://archive.orkl.eu/143bc76ad269484e7de09963e43f2538e33850b1.jpg"
	}
}