{
	"id": "df3f3538-c1d6-48cd-8f6d-28963f9a78f1",
	"created_at": "2026-04-06T01:29:17.987796Z",
	"updated_at": "2026-04-10T03:37:09.358466Z",
	"deleted_at": null,
	"sha1_hash": "64f711365690e360ebc0a36405a7a5e038ddddf5",
	"title": "LummaC2 stealer: Everything you need to know",
	"llm_title": "",
	"authors": "",
	"file_creation_date": "0001-01-01T00:00:00Z",
	"file_modification_date": "0001-01-01T00:00:00Z",
	"file_size": 1275075,
	"plain_text": "LummaC2 stealer: Everything you need to know\r\nBy Outpost24 Threat Intelligence Team Threat Intelligence Team, Outpost24\r\nPublished: 2023-04-05 · Archived: 2026-04-06 00:44:16 UTC\r\nResearch \u0026 Threat Intel Last updated: 10 Nov 2025\r\nWritten By\r\nOutpost24’s KrakenLabs team have taken a deep dive into the malware classified as LummaC2, an information\r\nstealer written in C language that has been sold in underground forums since December 2022. We assess\r\nLummaC2’s primary workflow, its different obfuscation techniques (like Windows API hashing and encoded\r\nstrings) and how to overcome them to effectively analyze the malware with ease. We’ve also analyzed how\r\nnetworking communications with the C2 work and summarizes LummaC2’s MITRE Adversarial Tactics,\r\nTechniques and Common Knowledge.\r\nWhat’s new with LummaC2 in 2025?\r\nRecent observations in 2025 indicate that LummaC2 continues to evolve, adapting its tactics to outsmart modern\r\ndefenses. Key updates include:\r\nAnti-sandbox technique: KrakenLabs researched looked into a new Anti-Sandbox technique LummaC2\r\nv4.0 stealer is using to avoid detonation if no human mouse activity is detected.\r\nEnhanced evasion techniques: Attackers have upgraded LummaC2 with more sophisticated obfuscation\r\nmethods and stealth capabilities. The malware now employs advanced memory injection and fileless\r\nexecution techniques, making it harder for traditional antivirus tools to detect its presence.\r\nModular and adaptive architecture: The newer iterations of LummaC2 have embraced a modular design\r\nthat allows attackers to swiftly add or modify capabilities. This flexibility means the malware can be\r\ntailored for specific targets or integrated as part of more complex, multi-stage attack campaigns.\r\nExploitation of recent vulnerabilities: New variants are taking advantage of vulnerabilities in up-to-date\r\nsoftware systems. Cybercriminals are specifically targeting areas where recent patches might have been\r\noverlooked, emphasizing the critical need for timely updates and robust patch management.\r\nIntegration with broader attack ecosystems: In the evolving threat landscape, LummaC2 is increasingly\r\nbeing used in conjunction with other malware and ransomware campaigns. This synergy not only enhances\r\nthe overall impact of attacks but also complicates detection and remediation efforts.\r\nLummaC2: Stealer for sale\r\nThe information stealer has been offered for sale in several underground forums and via the official shop\r\nlumma[.]site by the threat actor “Shamel” using the alias “Lumma”, who is also responsible for the sales of\r\nthe 7.62mm stealer. Outpost24 KrakenLabs analysts have also found advertisements in other forums by the alias\r\n“LummaStealer”, which is presumably a reseller of the stealer.\r\nhttps://outpost24.com/blog/everything-you-need-to-know-lummac2-stealer\r\nPage 1 of 31\n\nFigure 1. Dark Web Post for LummaC2 Stealer\r\nThis malware targets crypto wallets, browser extensions, two-factor authentication (2FA) and steals sensitive\r\ninformation from the victim’s machine.\r\nLummaC2 is offered at the following prices depending on the features offered:\r\nExperienced US$250;\r\nProfessional US$500;\r\nCorporate account US$1,000.\r\nAn earlier version of the website seen in a screenshot on Cyble’s article indicates that it was also possible to\r\npurchase the stealer and panel source code for a price of US$20,000.\r\nThe purchase of the stealer can be processed through the well-known cryptocurrency exchange Coinbase from a\r\nwide range of cryptocurrencies to choose from.\r\nFigure 2. Screenshot obtained from LummaC2 shop (information automatically translated from\r\nRussian to English).\r\nDe-obfuscating LummaC2\r\nhttps://outpost24.com/blog/everything-you-need-to-know-lummac2-stealer\r\nPage 2 of 31\n\nLummaC2 Windows API call obfuscation\r\nLummaC2 makes use of API hashing, which is a common technique seen in malware in order to hide their\r\nfunctionality from tools relying on static information and to obfuscate the code, which makes it harder for an\r\nanalyst to understand what the malware does.\r\nThe following picture shows an example of how Windows API calls are performed:\r\nFigure 3. Example of an obfuscated call to NtClose for LummaC2\r\nThe malware executes a function that receives a DLL name string in EDX register(e.g “ntdll.dll”) and an input\r\nhash (in ECX register). This function internally resolves kernel32!LoadLibraryA to load the desired .dll (in this\r\ncase “ntdll.dll”) and proceeds to parse its Export Table. It hashes each export name until it finds one that matches\r\nthe input hash. This way it is able to resolve any Windows API Call, saving the address found in EAX register as a\r\nresult. Then a call eax instruction will finally execute the desired Windows API call.\r\nhttps://outpost24.com/blog/everything-you-need-to-know-lummac2-stealer\r\nPage 3 of 31\n\nFigure 4. LummaC2 parsing Export Table and hashing with MurmurHash2 to resolve Windows API\r\ncalls\r\nThe hashing algorithm that LummaC2 uses to resolve Windows API calls is MurmurHash2 with 32 as seed\r\nvalue.\r\nFigure 5. Decompiled view (excerpt) of MurmurHash2 routine using 32 as seed value\r\nDefeating LummaC2 Windows API call obfuscation\r\nThe following lines are aimed at removing the call obfuscation scheme for LummaC2 now that we know how it\r\nresolves Windows API calls. The idea is to automatically resolve all Windows API calls used in the code so that\r\nwe have a better picture of the malware capabilities without the need of debugging and entering in every single\r\npath the malware can take to resolve all its possible calls.\r\nTo do so, we will generate a dictionary containing all the Windows API calls from a given set of Windows .dll\r\nfiles and their respective MurmurHash2. With this dictionary, we can then get every hash sent to the function\r\nresolving Windows Api calls and figure out which function is being resolved.\r\nPreparing Windows API call hash dictionary\r\nWe could try and find a public implementation or MurmurHash2 but it is possible that the algorithm the malware\r\nuses may be altered in the future so that the standard implementation does not work. For this reason, another good\r\napproach is to use Unicorn, as it allows us to emulate the exact instructions that the malware executes.\r\nUnicorn\r\nThe hashing routine is a “standalone” routine that we can extract easily from the binary and does not have any\r\ncalls or jumps to other locations apart from the hashing routine itself. Which means we can run this shellcode in\r\nan emulated environment without previous patching to ensure everything is linked properly (with the exception of\r\nthe last “return” instruction, which we should ignore for the emulation).\r\nhttps://outpost24.com/blog/everything-you-need-to-know-lummac2-stealer\r\nPage 4 of 31\n\nIn this scenario, the malware hashing algorithm expects to have the string with the Windows API call\r\nin ECX register and the result hash (which we will read) is finally stored in EAX register.\r\nFigure 6. Call graph view for LummaC2 MurmurHash2 implementation\r\nAs we now have all the data we need to emulate the binary, the last step for this part is to build the emulation\r\nenvironment for our code to run on. To accomplish this, we will use the open-source Unicorn Engine.\r\nThe first thing we want to do is initializing Unicorn for the architecture we want to emulate (x86 architecture), and\r\nmap some memory to use. Next, we will write our shellcode to our memory space and initialize ECX pointing to\r\nour Export Name string. With all this in place, we are ready to run emulation and read the resulting hash\r\nin EAX register afterwards.\r\nThe following Python function uses Unicorn to emulate the hashing algorithm LummaC2 uses to resolve\r\nWindows API Calls:\r\nimport unicorn\r\ndef emulate_murmurhash2(data, seed=32):\r\n code = \"\\x56\\x57\\x8B\\xF9\\x8B\\xD7\\x8D\\x4A\\x01\\x8A\\x02\\x42\\x84\\xC0\\x75\\xF9\\x2B\\xD1\\x8B\\xF2\\x83\\xF6\\\r\n CODE_OFFSET = 0x1000000\r\n mu = unicorn.Uc(unicorn.UC_ARCH_X86, unicorn.UC_MODE_32)\r\n mu.mem_map(CODE_OFFSET, 4*1024*1024)\r\n mu.mem_write(CODE_OFFSET, code)\r\n libname = 0x7000000\r\n mu.mem_map(libname, 4*1024*1024)\r\n mu.mem_write(libname, data)\r\nhttps://outpost24.com/blog/everything-you-need-to-know-lummac2-stealer\r\nPage 5 of 31\n\nstack_base = 0x00300000\r\n stack_size = 0x00100000\r\n mu.mem_map(stack_base, stack_size)\r\n mu.mem_write(stack_base, b\"\\x00\" * stack_size)\r\n mu.reg_write(unicorn.x86_const.UC_X86_REG_ESP, stack_base + 0x800)\r\n mu.reg_write(unicorn.x86_const.UC_X86_REG_EBP, stack_base + 0x1000)\r\n mu.reg_write(unicorn.x86_const.UC_X86_REG_ECX, libname)\r\n mu.emu_start(CODE_OFFSET, CODE_OFFSET + len(code))\r\n result = mu.reg_read(unicorn.x86_const.UC_X86_REG_EAX)\r\n return result\r\nWe can now easily write a script to walk through files inside a directory where we have Windows .dlls and, for\r\neach .dll, parse its Exports and calculate its MurmurHash2 using the previous function. This could be an example\r\nof the implementation using pefile:\r\n \r\nimport pefile\r\ndef dump_hash_dlls():\r\n '''\r\n This function uses pefile to get the export names from .dlls and apply the hashing\r\n algorithm to them.\r\n '''\r\n dlls_dir = 'dlls/'\r\n for (dirpath, dirnames, filenames) in os.walk(dlls_dir):\r\n for filename in filenames:\r\n if filename.endswith('.dll'):\r\n pe = pefile.PE('{}'.format(dlls_dir+filename))\r\n for exp in pe.DIRECTORY_ENTRY_EXPORT.symbols:\r\n export_name = exp.name\r\n if not export_name:\r\n \r\n continue\r\nhttps://outpost24.com/blog/everything-you-need-to-know-lummac2-stealer\r\nPage 6 of 31\n\ntry:\r\n export_hash = emulate_murmurhash2(export_name)\r\n except Exception as err:\r\n print 'Exception occurred while emulating murmurhash2 with export_name: {}. E\r\n continue\r\nThe results can then be saved as we prefer. In this case, we need a Python dictionary that we can use in IDA\r\nPython script when analyzing the malware. We can save the result dictionary in a .json file like the following one:\r\n \r\n{\r\n \"1002323769\": \"kernel32_MoveFileTransactedA\",\r\n \"1002333354\": \"ntdll_ZwSetTimer\",\r\n \"1003390208\": \"ntdll_memmove_s\",\r\n \"1003407985\": \"advapi32_LsaDelete\",\r\n \"1004879971\": \"ntdll_NtReadOnlyEnlistment\",\r\n \"100560003\": \"kernel32_GetThreadId\",\r\n \"1006629348\": \"kernel32_ReadConsoleOutputW\",\r\n \"1007338292\": \"kernel32_GetProcessPreferredUILanguages\",\r\n \"1007695856\": \"user32_GetClassInfoExW\",\r\n \"1008342899\": \"shell32_SHCreateStdEnumFmtEtc\",\r\n \"1008627276\": \"advapi32_QueryTraceW\",\r\n \"1008723271\": \"ntdll_NtDisableLastKnownGood\",\r\n \"1009340263\": \"advapi32_RegSaveKeyW\",\r\n \"1009496315\": \"kernel32_FlushViewOfFile\",\r\n \"1009939290\": \"shlwapi_PathFindSuffixArrayW\",\r\n \"101018728\": \"ntdll_ZwOpenTransactionManager\",\r\n \"1010305366\": \"user32_SetWindowLongA\",\r\n \"1010398495\": \"shlwapi_PathUnExpandEnvStringsW\",\r\n \"101074275\": \"kernel32_EnumDateFormatsExW\",\r\n \"1011639982\": \"user32_AppendMenuA\",\r\n \"1012134009\": \"user32_CharToOemBuffW\",\r\n \"1012436811\": \"ntdll_NtCreateNamedPipeFile\",\r\n \"1013083577\": \"shell32_ShellExec_RunDLL\",\r\n \"1014808818\": \"ntdll_NtUnmapViewOfSection\",\r\n \"1016118817\": \"ntdll_NtQueryInformationThread\",\r\n \"1017169715\": \"shell32_ILCloneFirst\",\r\n \"1017424400\": \"user32_ReleaseCapture\",\r\n(…)\r\nhttps://outpost24.com/blog/everything-you-need-to-know-lummac2-stealer\r\nPage 7 of 31\n\nResolving obfuscated Windows API calls\r\nNow that we have all the possible exports that the malware may use, it is time to create an IDA Python script to\r\nhelp us reverse engineer LummaC2.\r\nThis script is going to be divided in 2 parts. From one side, we are going to resolve every Windows API call\r\n(checking the hash set in ECX against our big dictionary) and create an IDA comment staying the final Windows\r\nAPI call being made. In the end, we will execute another script while debugging LummaC2 to patch all these\r\ncalls.\r\nThis will help us to easily understand how the malware operates and its capabilities to ease reverse engineering\r\nwithout the need of debugging and executing every possible path the malware can take.\r\nThe first thing to do is to place our .json file (the one with the big Python dictionary storing all the Windows API\r\ncalls and respective hashes) in our analysis VMs where IDA Python script is going to be executed. Then the script\r\nmust be able to read and save its contents for further analysis:\r\n \r\nimport json\r\nhashes_dict = {}\r\ndef setup(hashes_dict_file):\r\n global hashes_dict\r\n try:\r\n with open(hashes_dict_file, 'rb') as fd:\r\n hashes_dict = json.load(fd)\r\n except Exception as err:\r\n print 'Error while readning hashes dict. file: {}'.format(err)\r\nNow that we have our dictionary ready. Let’s examine the different patterns that are used when resolving a\r\nWindows API call. We know that ECX register must have the hash, but this can be achieved in the code through\r\ndifferent ways:\r\nhttps://outpost24.com/blog/everything-you-need-to-know-lummac2-stealer\r\nPage 8 of 31\n\nFigure 7. Example of different scenarios where Windows API call resolution is made\r\nAs we can see, in the end ECX always contains the hash to be resolved. However, the instruction that sets the\r\nspecified hash can move it into a different register before being in ECX. The last two patterns\r\nuse EDI and ESI registers respectively.\r\nWith this information, we should be able to go through all cross references to the call “ResolveApiByHash”,\r\nretrieve the hash being used and resolve the Windows API call using our big hash dictionary. The following\r\nPython function implements this. It only expects to receive the address of the call “ResolveApiByHash” as its only\r\nargument.\r\n \r\nimport idautils\r\nimport idc\r\ndef resolve_all_APIs(resolve_ea):\r\n patches = []\r\n total_apis_found = 0\r\n total_apis_resolved = 0\r\n global hashes_dict\r\n if resolve_ea is None:\r\n print('[!] Resolve failed.')\r\n return\r\n for ref in idautils.CodeRefsTo(resolve_ea, 1):\r\n total_apis_found += 1\r\n curr_ea = ref\r\n API_hash = 0\r\nhttps://outpost24.com/blog/everything-you-need-to-know-lummac2-stealer\r\nPage 9 of 31\n\nfor _ in range(30):\r\n prev_instruction_ea = idc.PrevHead(curr_ea)\r\n instruction = idc.GetDisasm(prev_instruction_ea)\r\n \r\n '''\r\n .text:0040214B B9 73 10 FF E8 mov ecx, 0E8FF1073h\r\n .text:00402150 E8 7E 61 00 00 call ResolveApiByHashWrapper\r\n or\r\n .text:004074F6 BF 29 A1 D3 5F mov edi, 5FD3A129h\r\n .text:004074FB BA C8 4B 42 00 mov edx, offset aWininet_dll\r\n .text:00407500 8B CF mov ecx, edi\r\n .text:00407502 E8 CC 0D 00 00 call ResolveApiByHashWrapper\r\n or\r\n .text:00407D8C BE 30 E2 95 3D mov esi, 3D95E230h\r\n .text:00407D91 8B D3 mov edx, ebx\r\n .text:00407D93 6A 00 push 0\r\n .text:00407D95 8B CE mov ecx, esi\r\n .text:00407D97 E8 37 05 00 00 call ResolveApiByHashWrapper\r\n '''\r\n instruction_cut = instruction.replace(' ', '')\r\n if 'movecx' in instruction_cut or 'movedi' in instruction_cut or 'movesi' in instruction_\r\n API_hash = idc.GetOperandValue(prev_instruction_ea, 1)\r\n if API_hash \u003c 0x10:\r\n \r\n curr_ea = prev_instruction_ea\r\n continue\r\n API_hash_idx = str(API_hash)\r\n if API_hash_idx in hashes_dict:\r\n print('API hash: {} {} {}'.format(hex(prev_instruction_ea), hex(API_hash), hashes\r\n apicall = hashes_dict[API_hash_idx].split('_')[-1]\r\n idc.MakeComm(ref, apicall)\r\n patch_info = (ref, hashes_dict[API_hash_idx])\r\nhttps://outpost24.com/blog/everything-you-need-to-know-lummac2-stealer\r\nPage 10 of 31\n\npatches.append(patch_info)\r\n total_apis_resolved += 1\r\n else:\r\n print(\"Hash not found!\")\r\n break\r\n curr_ea = prev_instruction_ea\r\n print('Total APIs found: {} Total APIs resolved: {}'.format(total_apis_found, total_apis_resolved\r\n return patches\r\nsetup(\"c:\\murmurhash2_hashes_dict.json\")\r\npatches = resolve_all_APIs(0x004082D3)\r\nThe return value is a list of tuples (addr, apicall) that we will use later to patch the binary. After executing the\r\nscript, we can see how now we have comments for every Windows API call resolution and have a better\r\nunderstanding of what the malware can do. We can also use xref view to quickly see all the Windows API calls\r\n(with their resolved name as a comment) the malware can use.\r\nhttps://outpost24.com/blog/everything-you-need-to-know-lummac2-stealer\r\nPage 11 of 31\n\nFigure 8. Example of result from executing the previous script. Windows API calls are commented\r\nnow\r\nFigure 9. Cross-Referencing the Windows API resolution routine can help identifying malware\r\ncapabilities now\r\nPatching the binary and removing obfuscation\r\nThe last part of this script would allow us to patch the binary to remove all of LummaC2 Windows API call\r\nobfuscation. This way we can focus only in the relevant instructions and help IDA decompiler to easily recognize\r\nthe arguments that are being passed to these functions.\r\nWith the current implementation, we can easily see which Windows API calls are being used (as we have\r\ncomments in every call that resolves a function). However, we still have many unnecessary instructions in the\r\ncode, and the call is still being done with the instruction “call eax”, which does not help us much with analysis,\r\ncross-referencing, etc.\r\nThe goal of the following Python function for IDA is to patch the “call ResolveApiByHash” for the real Windows\r\nAPI call that is going to be called after resolution. From the previous script, we have a list of tuples. Each element\r\nof the tuple consists of an address (where the call resolution is made) and the Windows API call that is going to be\r\ncalled.\r\n \r\nhttps://outpost24.com/blog/everything-you-need-to-know-lummac2-stealer\r\nPage 12 of 31\n\ndef patch_apicall_wrapper(patches):\r\n total_apis_patched = 0\r\n for item in patches:\r\n \r\n try:\r\n addr = item[0]\r\n apicall = item[1]\r\n success_patch = patch_apicall(addr, apicall)\r\n if success_patch:\r\n total_apis_patched += 1\r\n except Exception as err:\r\n print('Error patching call: {}'.format(err))\r\n print('Total APIs patched: {}'.format(total_apis_patched))\r\nThe function “patch_apicall” is going to be the responsible for retrieving the address of a Windows API call and\r\npatching the “call ResolveApiByHash” for the call to the expected export.\r\nOne drawback that we may find, is that we cannot resolve the address of an export from a Windows .dll that has\r\nnot been loaded in the address space from the debugged process yet. To overcome this issue, we can make use of\r\nIDA “Appcall” feature. With Appcall we can execute LoadLibraryA to load any missing .dll so that we can\r\nresolve all exports just from the Entry Point. (Otherwise, we would have to wait until the malware loads the\r\nlibrary for the first time; which would not allow us to automate everything from the Entry Point as we are doing\r\nnow).\r\nOnce we have the address, we need to get the relative offset and then we can use 0xE8 opcode with this relative\r\noffset to patch the call “ResolveApiByHash”. Finally, we append two nop instructions after to overwrite the\r\nproceeding “call eax”.\r\n \r\ndef patch_apicall(addr, apicall):\r\n '''\r\n If it cannot be resolved, it is possible that the malware has not loaded the library yet (for exa\r\n loadlib = Appcall.proto(\"kernel32_LoadLibraryA\", \"int __stdcall loadlib(const char *fn);\")\r\n hmod = loadlib(\"wininet.dll\")\r\n '''\r\nhttps://outpost24.com/blog/everything-you-need-to-know-lummac2-stealer\r\nPage 13 of 31\n\nloadlib = Appcall.proto(\"kernel32_LoadLibraryA\", \"int __stdcall loadlib(const char *fn);\")\r\n print('apicall: {}'.format(apicall))\r\n apiaddr = idc.LocByName(apicall)\r\n if apiaddr == 0xFFFFFFFF:\r\n hmod = loadlib('{}.dll'.format(apicall.split('_')[0]))\r\n apiaddr = idc.LocByName(apicall)\r\n if apiaddr == 0xFFFFFFFF:\r\n return False\r\n \r\n rel_offset = (apiaddr - addr - 5) \u0026 0xFFFFFFFF\r\n idc.PatchDword(addr+1, rel_offset)\r\n idc.PatchByte(addr+5, 0x90)\r\n idc.PatchByte(addr+6, 0x90)\r\n return\r\nsetup(\"c:\\murmurhash2_hashes_dict.json\")\r\npatches = resolve_all_APIs(0x004082D3)\r\npatch_apicall_wrapper(patches)\r\nWith this implementation, we have now patched all the calls to the real exports that the malware wants to use.\r\nHowever, IDA has now trouble identifying and displaying properly the arguments of the functions in the\r\ndecompiler view. An example of this can be seen in the following picture:\r\nFigure 10. Example before (left) and after (right) the script execution. Binary is patched to call the\r\nreal function\r\nhttps://outpost24.com/blog/everything-you-need-to-know-lummac2-stealer\r\nPage 14 of 31\n\nFigure 11. Example of how arguments cannot be easily recognized at first by IDA decompiler yet\r\nThe last thing to do here is to remove the instructions related with the Windows API call resolution (registry\r\noperations used to move the .dll string and the hash). This way the decompiler will show the arguments and\r\neverything as expected, while the code will look clean and show only the necessary instructions. This would be\r\nthe final implementation of the previous “patch_apicall” function:\r\n \r\ndef patch_apicall(addr, apicall):\r\n '''\r\n If it cannot be resolved, it is possible that the malware has not loaded the library yet (for exa\r\n loadlib = Appcall.proto(\"kernel32_LoadLibraryA\", \"int __stdcall loadlib(const char *fn);\")\r\n hmod = loadlib(\"wininet.dll\")\r\n '''\r\n loadlib = Appcall.proto(\"kernel32_LoadLibraryA\", \"int __stdcall loadlib(const char *fn);\")\r\n print('apicall: {}'.format(apicall))\r\n apiaddr = idc.LocByName(apicall)\r\n if apiaddr == 0xFFFFFFFF:\r\n hmod = loadlib('{}.dll'.format(apicall.split('_')[0]))\r\n apiaddr = idc.LocByName(apicall)\r\n if apiaddr == 0xFFFFFFFF:\r\n return False\r\n \r\n rel_offset = (apiaddr - addr - 5) \u0026 0xFFFFFFFF\r\n idc.PatchDword(addr+1, rel_offset)\r\n idc.PatchByte(addr+5, 0x90)\r\n idc.PatchByte(addr+6, 0x90)\r\n \r\n curr_ea = addr\r\n for _ in range(20):\r\n prev_instruction_ea = idc.PrevHead(curr_ea)\r\n instruction = idc.GetDisasm(prev_instruction_ea)\r\nhttps://outpost24.com/blog/everything-you-need-to-know-lummac2-stealer\r\nPage 15 of 31\n\ninstruction_cut = instruction.replace(' ', '')\r\n if 'movecx' in instruction_cut or \\\r\n 'movedx' in instruction_cut:\r\n operand_type = idc.GetOpType(prev_instruction_ea, 1)\r\n param = idc.GetOperandValue(prev_instruction_ea, 1)\r\n \r\n \r\n \r\n \r\n if operand_type not in [1, 2, 5]:\r\n curr_ea = prev_instruction_ea\r\n continue\r\n if param \u003c 0x10:\r\n if not 'eax' in instruction_cut:\r\n \r\n \r\n PatchNops(prev_instruction_ea, 2)\r\n else:\r\n \r\n PatchNops(prev_instruction_ea, 5)\r\n curr_ea = prev_instruction_ea\r\n return True\r\ndef PatchNops(addr, size):\r\n for i in range(size):\r\n print(\"Patching NOP at addr: {}\".format(hex(addr+i)))\r\n idc.PatchByte(addr+i, 0x90)\r\nsetup(\"c:\\murmurhash2_hashes_dict.json\")\r\npatches = resolve_all_APIs(0x004082D3)\r\npatch_apicall_wrapper(patches)\r\nhttps://outpost24.com/blog/everything-you-need-to-know-lummac2-stealer\r\nPage 16 of 31\n\nWith this in place, we can execute the script in a debugging session on Entry Point and remove most of the code\r\nrelated to Windows API call obfuscation while patching the binary to get an equivalent working sample easier to\r\nanalyze and reverse engineer.\r\nThe following figure shows the result of patching the binary with our script:\r\nFigure 12. Example of how instructions related to Windows API call obfuscation have been patched\r\nwith nops\r\nAs we can see, we only have relevant instructions in our disassembly (nop instructions have patched out Windows\r\nAPI call obfuscation scheme). And, as a result, it is easy for IDA decompiler now to understand and properly\r\ndisplay the arguments for our Windows API calls in the first attempt:\r\nFigure 13. Example before (up) and after (down) patching the binary with our last script.\r\nHere we have the main networking exfiltration routine before applying any of our scripts and after patching the\r\nbinary. As we can see, the result is a much clear and easy to understand routine:\r\nhttps://outpost24.com/blog/everything-you-need-to-know-lummac2-stealer\r\nPage 17 of 31\n\nFigure 14. Decompiled view of Network Exfiltration routine without patching the binary\r\nFigure 15. Decompiled view of Network Exfiltration routine after patching the binary with our\r\nscript\r\nLummaC2 strings obfuscation\r\nFigure 16. View of LummaC2 obfuscated strings in the binary\r\nhttps://outpost24.com/blog/everything-you-need-to-know-lummac2-stealer\r\nPage 18 of 31\n\nLummaC2 “obfuscates” most of the strings used in the malware in order to evade detection. By stripping every\r\noccurrence of “edx765” from a given string, we can easily get the original one. Most of these strings are used to\r\nwalk through sensitive files inside directories.\r\nAs it can be seen, the obfuscation method is very simple and for this reason, it is probable that we see changes in\r\nthis implementation in future versions of the malware.\r\nLummaC2 workflow\r\nThe following diagram shows LummaC2 main workflow. This malware goes straight to the point and only cares\r\nabout exfiltrating stolen information. No persistence mechanisms are used and there is no control on how many\r\nmalware instances can run at the same time. One difference regarding many information stealers is that this\r\nmalware family does not care about the machine being infected, while others avoid infecting machines coming\r\nfrom the Commonwealth of Independent States.\r\nhttps://outpost24.com/blog/everything-you-need-to-know-lummac2-stealer\r\nPage 19 of 31\n\nFigure 17. LummaC2 main workflow diagram\r\nHow LummaC2 gathers information\r\nLummaC2 gathers information from the victim system. This information is saved in a file named “System.txt”\r\nprior to zip compression and exfiltration. The information gathered from the infected machine includes the\r\nUsername, Hardware ID, Screen Resolution and more:\r\nhttps://outpost24.com/blog/everything-you-need-to-know-lummac2-stealer\r\nPage 20 of 31\n\nFigure 18. System Information gathered from LummaC2\r\nThis information is obtained using the following Windows API calls respectively:\r\nGetComputerNameA\r\nGetUserNameA\r\nGetCurrentHwProfileA\r\nGetSystemMetrics\r\nGetSystemDefaultLocaleName\r\ncpuid\r\nGetPhysicallyInstalledSystemMemory\r\nHow LummaC2 steals important files\r\nLummaC2 will also steal files from the victim machine and save them under “Important Files/Profile”. What\r\nhappens to be considered here an “important file” is actually every *.txt file under %userprofile%. This is done in\r\na recursive call that traverses %userprofile% with a maximum recursion depth of 2 directories.\r\nFigure 19. LummaC2 code responsible for gathering system information and important files\r\nTargeted software\r\nAfter gathering information from the infected machine and stealing important files, it proceeds to steal crypto\r\nwallets for Binance, Electrum and Ethereum (in this order). Once this is finished it exfiltrates data (ZIP\r\ncompressed) to the C2 and continues the stealing process.\r\nCrypto Wallets\r\nBinance\r\nhttps://outpost24.com/blog/everything-you-need-to-know-lummac2-stealer\r\nPage 21 of 31\n\nElectrum\r\nEthereum\r\nTable 1. LummaC2 targeted Crypto Wallets\r\nAfter the first exfiltration to the Command and Control server, LummaC2 proceeds to steal relevant Browsers\r\ninformation like Login Data, History, cookies, etc. Affected Browsers are:\r\nWeb Browsers\r\nChrome\r\nChromium\r\nEdge\r\nKometa\r\nVivaldi\r\nBrave-Browser\r\nOpera Stable\r\nOpera GX Stable\r\nOpera Neon\r\nMozilla Firefox\r\nTable 2. LummaC2 targeted Web Browsers\r\nhttps://outpost24.com/blog/everything-you-need-to-know-lummac2-stealer\r\nPage 22 of 31\n\nThe malware also targets Crypto Wallets and two-factor authentication (2FA) browser extensions that may have\r\nbeen installed in the system. The following figure shows LummaC2 searching for these elements:\r\nFigure 20. LummaC2 targeting Crypto Wallets and two-factor authentication (2FA) extensions\r\nThe following Crypto Wallets and two-factor authentication (2FA) extensions are targeted in LummaC2:\r\nCrypto Wallet Extensions\r\nMetamask BitApp Sollet Nash Extension\r\nTronLink iWlt Auro Hycon Lite Client\r\nRonnin Wallet Wombat Polymesh ZilPay\r\nBinance Chain Wallet MEW CX ICONex Coin98\r\nYoroi Guild Nabox Cyano\r\nNifty Saturn KHC Byone\r\nhttps://outpost24.com/blog/everything-you-need-to-know-lummac2-stealer\r\nPage 23 of 31\n\nMath NeoLine Temple OneKey\r\nCoinbase Clover TezBox Leaf\r\nGuarda Liquality DAppPlay\r\nEQUAL Terra Station BitClip\r\nJaxx Liberty Keplr Steem Keychain\r\nTable 3. LummaC2 targeted Crypto Wallet extensions\r\nTwo-Factor Authentication (2FA) Extensions\r\nAuthenticator\r\nAuthy\r\nEOS Authenticator\r\nGAuth Authenticator\r\nTrezor Password Manager\r\nTable 4. LummaC2 targeted two-factor authentication (2FA) extensions\r\nHow LummaC2 exfiltrates network data\r\nCommunication with the Command and Control server is one-way only. The malware does not expect any\r\nresponse from its C2. As we can see from LummaC2 workflow diagram, the malware contacts the C2 in different\r\nstealing phases. After each phase, stolen information is sent to the C2 ZIP compressed.\r\nhttps://outpost24.com/blog/everything-you-need-to-know-lummac2-stealer\r\nPage 24 of 31\n\nFigure 21. LummaC2 HTTP POST request headers\r\nLummaC2 exfiltrates stolen information via HTTP POST request. These requests are made to the resource\r\n“/c2sock” and use multipart/form-data (combines one or more sets of data into a single body, separated by\r\nboundaries) to upload a compressed ZIP file containing the stolen information along with more information (like\r\nthe hardware id, obtained previously with GetCurrentHwProfileA). The following figure shows the different set\r\nof data sent to the C2:\r\nFigure 22. LummaC2 multipart/form-data fields used when exfiltrating information\r\nFirst field (highlighted one) is the filed with name “file”. This includes the ZIP compressed file with sensitive\r\ninformation being exfiltrated.\r\nThe next field with name “hwid” contains the Hardware Id previously retrieved using GetCurrentHwProfileA\r\nThe field with name “pid” can be understood as “petition Id”. It is the number of the exfiltration attempt. As we\r\nsaw earlier in the workflow diagram, LummaC2 can exfiltrate up to 3 different times after each stealing phase.\r\nFrom the analyzed sample, we can only expect to see values 1, 2 or 3, which means that if we detect LummaC2\r\nnetworking activity with different “petition Id” we will be dealing with a newer/updated version of the malware.\r\nFinally, the last field with name “lid” comes with the hardcoded value “xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx”.\r\nThis is known as the “Lumma ID” and it can be understood as an identifier of the malware that may refer to the\r\nbuild or campaign id. This field is also used when gathering system information (in the creation of “System.txt”\r\nfile being exfiltrated).\r\nNetwork data being transmitted to the C2 can be recognized in the following figure, where an excerpt of the\r\nfirst HTTP POST exfiltration request (request with “pid” equals 1) using multipart/form-data is sending a ZIP\r\ncompressed file:\r\nhttps://outpost24.com/blog/everything-you-need-to-know-lummac2-stealer\r\nPage 25 of 31\n\nFigure 23. LummaC2 Hex view of HTTP POST request for exfiltration\r\nMITRE ATT\u0026CK matrix for LummaC2\r\nTactic Technique ID Technique\r\nDefense Evasion T1140 Deobfuscate/Decode Files or Information\r\nDefense Evasion T1027 Obfuscated Files or Information\r\nCredential Access T1539 Steal Web Session Cookie\r\nCredential Access T1555 Credentials from Password Stores\r\nCredential Access T1552 Unsecured Credentials\r\nDiscovery T1083 File and Directory Discovery\r\nDiscovery T1082 System Information Discovery\r\nDiscovery T1033 System Owner/User Discovery\r\nhttps://outpost24.com/blog/everything-you-need-to-know-lummac2-stealer\r\nPage 26 of 31\n\nCollection T1560 Archive Collected Data\r\nCollection T1119 Automated Collection\r\nCollection T1005 Data from Local System\r\nExfiltration T1041 Exfiltration over C2 Channel\r\nExfiltration T1020 Automated Exfiltration\r\nCommand and Control T1071 Application Layer Protocol\r\nCommand and Control T1132 Data Encoding\r\nTable 5. LummaC2 MITRE ATT\u0026CK matrix\r\nHow to remove LummaC2\r\nRemoving a sophisticated piece of malware like LummaC2 requires a systematic and cautious approach. The\r\nfollowing steps outline best practices for malware removal while emphasizing the importance of data integrity and\r\nsystem security.\r\n1. Isolate and assess the environment\r\nDisconnect from networks:\r\nImmediately isolate the affected computer from the internet and any local networks. This prevents further\r\ndata exfiltration and stops the potential spread of the malware across other systems in your environment.\r\nBackup critical data:\r\nBefore initiating any removal procedures, back up essential files. Use external storage or a cloud solution\r\nthat is not connected to the compromised system. This step ensures that you can recover key data if the\r\nremoval process necessitates more drastic measures, such as a system reinstallation.\r\nDocument signs of infection:\r\nRecord any unusual system behaviors, error logs, or file modifications that might help in the identification\r\nof malware components later. This information can be valuable when cross-referencing with technical\r\nindicators of compromise.\r\n2. Preliminary scanning and identification\r\nhttps://outpost24.com/blog/everything-you-need-to-know-lummac2-stealer\r\nPage 27 of 31\n\nUpdate your security software:\r\nEnsure that your antivirus or anti-malware tools (such as Malwarebytes, Kaspersky, or another reputable\r\nproduct) are fully updated. Modern detection tools have intelligence on the latest malware strains and can\r\noften recognize and neutralize sophisticated threats like LummaC2.\r\nPerform full system scans:\r\nRun a comprehensive scan using multiple reputable scanning tools. Keep in mind that some malware may\r\nevade detection on an active system, so consider using offline scanning tools or bootable rescue media\r\nwhich can scan without interference from the active OS.\r\n3. Removing the malware\r\nAutomated removal:\r\nIf your security software detects LummaC2, follow the software’s recommended procedures for quarantine\r\nand removal. Most contemporary anti-malware suites can safely remove malicious components without\r\nuser intervention.\r\nManual investigation:\r\nFor advanced users or in cases where automated tools fail to completely remove the malware, manual\r\nremoval may be necessary. This process typically involves:\r\nRegistry checks: Identify and remove suspicious entries in the Windows Registry that may have\r\nbeen modified by LummaC2. Exercise extreme caution to avoid removing legitimate system\r\nkeys.Scheduled tasks and startup items: Look for irregular scheduled tasks or startup entries.\r\nMalware often establishes persistence by configuring these system areas.File system cleanup:\r\nSearch for and remove any files known to be associated with LummaC2. This may include hidden\r\ndirectories or files with obscure names.\r\nNote: Manual removal is inherently risky. If you are not comfortable with deep system modifications,\r\nconsider seeking professional assistance.\r\n4. Post-removal steps\r\nReboot in safe mode:\r\nRebooting your computer in Safe Mode can help you confirm the removal of the malware and prevent any\r\nresidual components from executing. Run another series of full system scans in Safe Mode to verify that no\r\ntraces of the malware remain.\r\nSystem patching and updates:\r\nEnsure that your operating system and all installed applications are fully patched. Vulnerabilities in\r\noutdated software are a common gateway for malware infections, and regular updates can help prevent\r\nreinfection.\r\nChange credentials:\r\nSince LummaC2 is an information stealer, immediately change any passwords or security credentials that\r\nwere stored or accessed on the infected system. This includes email accounts, banking, and other sensitive\r\nonline services.\r\nMonitor for recurrence:\r\nAfter removal, continue to monitor your system closely. Utilize intrusion detection systems (IDS) or\r\nhttps://outpost24.com/blog/everything-you-need-to-know-lummac2-stealer\r\nPage 28 of 31\n\nendpoint security monitoring tools to alert you if the malware attempts to re-establish itself.\r\nEducate and harden:\r\nUse this experience as a prompt to enhance your cybersecurity posture. Consider employee training,\r\nenhanced network monitoring, and periodic security audits to help prevent similar incidents in the future.\r\n5. Consider professional support\r\nIf uncertainty persists regarding the full removal of LummaC2 or if there are complications during remediation, do\r\nnot hesitate to consult with cybersecurity professionals. Specialized incident response teams can provide deeper\r\nforensic analysis and ensure that every component of the infection is eradicated.\r\nStrengthen your cyber defenses with EASM\r\nAs it has been shown, LummaC2 behaves similar to other information stealers. By capturing sensitive data from\r\ninfected machines, including business credentials, it can do a lot of damage. For example, compromised\r\ncredentials can be used to achieve privilege escalation and lateral movement. Compromised business accounts can\r\nalso be used to send spam and further distribute the malware.\r\nThe fact the malware is being actively used in the wild indicates the professionalization in the development of\r\nthese products. Bad actors are willing to pay for these tools because they prefer quality, and more features. In\r\nreturn, they expect to see more profit from the exfiltrated data. Outpost24’s KrakenLabs will continue to analyze\r\nnew malware samples as part of our Threat Intelligence solution, which can retrieve compromised credentials in\r\nreal-time to prevent unauthorized access to your systems.\r\nDon’t let emerging threats catch you off guard. Upgrade your security posture with Outpost24’s Enterprise Attack\r\nSurface Management (EASM) solution. Designed to deliver real-time and deep visibility across your digital\r\nfootprint, Outpost2424’s EASM tool empowers you to:\r\nMonitor and mitigate risks:\r\nDetect vulnerabilities and assess threat vectors before they compromise your organization.\r\nStay ahead of evolving threats:\r\nLeverage threat intelligence modules to continuously adapt your defenses against sophisticated malware\r\nlike LummaC2.\r\nImprove incident response:\r\nIntegrate actionable insights into your security strategy, enabling faster and more accurate responses to\r\npotential breaches.\r\nBook your free attack surface analysis today.\r\nIOCs\r\nHash\r\nLummaC2 sample:\r\n277d7f450268aeb4e7fe942f70a9df63aa429d703e9400370f0621a438e918bf\r\nhttps://outpost24.com/blog/everything-you-need-to-know-lummac2-stealer\r\nPage 29 of 31\n\nC2\r\nLummaC2 Command and Control server:\r\n195[.]123[.]226[.]91\r\nReferences\r\n“LummaC2 Stealer: A Potent Threat to Crypto Users”, January, 2023. [Online].\r\nAvailable: https://blog.cyble.com/2023/01/06/lummac2-stealer-a-potent-threat-to-crypto-users/ [Accessed March\r\n20, 2023]\r\n“Popularity spikes for information stealer malware on the dark web”, December, 2022. [Online].\r\nAvailable: https://www.accenture.com/us-en/blogs/security/information-stealer-malware-on-dark-web [Accessed\r\nMarch 20, 2023]\r\nAbout the Author\r\nOutpost24’s Cyber Threat Intelligence team helps businesses stay ahead of malicious actors in the ever-evolving\r\nthreat landscape, helping you keep your assets and brand reputation safe. With a comprehensive threat hunting\r\nhttps://outpost24.com/blog/everything-you-need-to-know-lummac2-stealer\r\nPage 30 of 31\n\ninfrastructure, our Threat Intelligence solution covers a broad range of threats on the market to help your business\r\ndetect and deter external threats.\r\nSource: https://outpost24.com/blog/everything-you-need-to-know-lummac2-stealer\r\nhttps://outpost24.com/blog/everything-you-need-to-know-lummac2-stealer\r\nPage 31 of 31",
	"extraction_quality": 1,
	"language": "EN",
	"sources": [
		"Malpedia"
	],
	"references": [
		"https://outpost24.com/blog/everything-you-need-to-know-lummac2-stealer"
	],
	"report_names": [
		"everything-you-need-to-know-lummac2-stealer"
	],
	"threat_actors": [
		{
			"id": "9f101d9c-05ea-48b9-b6f1-168cd6d06d12",
			"created_at": "2023-01-06T13:46:39.396409Z",
			"updated_at": "2026-04-10T02:00:03.312816Z",
			"deleted_at": null,
			"main_name": "Earth Lusca",
			"aliases": [
				"CHROMIUM",
				"ControlX",
				"TAG-22",
				"BRONZE UNIVERSITY",
				"AQUATIC PANDA",
				"RedHotel",
				"Charcoal Typhoon",
				"Red Scylla",
				"Red Dev 10",
				"BountyGlad"
			],
			"source_name": "MISPGALAXY:Earth Lusca",
			"tools": [
				"RouterGod",
				"SprySOCKS",
				"ShadowPad",
				"POISONPLUG",
				"Barlaiy",
				"Spyder",
				"FunnySwitch"
			],
			"source_id": "MISPGALAXY",
			"reports": null
		},
		{
			"id": "8941e146-3e7f-4b4e-9b66-c2da052ee6df",
			"created_at": "2023-01-06T13:46:38.402513Z",
			"updated_at": "2026-04-10T02:00:02.959797Z",
			"deleted_at": null,
			"main_name": "Sandworm",
			"aliases": [
				"IRIDIUM",
				"Blue Echidna",
				"VOODOO BEAR",
				"FROZENBARENTS",
				"UAC-0113",
				"Seashell Blizzard",
				"UAC-0082",
				"APT44",
				"Quedagh",
				"TEMP.Noble",
				"IRON VIKING",
				"G0034",
				"ELECTRUM",
				"TeleBots"
			],
			"source_name": "MISPGALAXY:Sandworm",
			"tools": [],
			"source_id": "MISPGALAXY",
			"reports": null
		},
		{
			"id": "3a0be4ff-9074-4efd-98e4-47c6a62b14ad",
			"created_at": "2022-10-25T16:07:23.590051Z",
			"updated_at": "2026-04-10T02:00:04.679488Z",
			"deleted_at": null,
			"main_name": "Energetic Bear",
			"aliases": [
				"ATK 6",
				"Blue Kraken",
				"Crouching Yeti",
				"Dragonfly",
				"Electrum",
				"Energetic Bear",
				"G0035",
				"Ghost Blizzard",
				"Group 24",
				"ITG15",
				"Iron Liberty",
				"Koala Team",
				"TG-4192"
			],
			"source_name": "ETDA:Energetic Bear",
			"tools": [
				"Backdoor.Oldrea",
				"CRASHOVERRIDE",
				"Commix",
				"CrackMapExec",
				"CrashOverride",
				"Dirsearch",
				"Dorshel",
				"Fertger",
				"Fuerboos",
				"Goodor",
				"Havex",
				"Havex RAT",
				"Hello EK",
				"Heriplor",
				"Impacket",
				"Industroyer",
				"Karagany",
				"Karagny",
				"LightsOut 2.0",
				"LightsOut EK",
				"Listrix",
				"Oldrea",
				"PEACEPIPE",
				"PHPMailer",
				"PsExec",
				"SMBTrap",
				"Subbrute",
				"Sublist3r",
				"Sysmain",
				"Trojan.Karagany",
				"WSO",
				"Webshell by Orb",
				"Win32/Industroyer",
				"Wpscan",
				"nmap",
				"sqlmap",
				"xFrost"
			],
			"source_id": "ETDA",
			"reports": null
		},
		{
			"id": "a66438a8-ebf6-4397-9ad5-ed07f93330aa",
			"created_at": "2022-10-25T16:47:55.919702Z",
			"updated_at": "2026-04-10T02:00:03.618194Z",
			"deleted_at": null,
			"main_name": "IRON VIKING",
			"aliases": [
				"APT44 ",
				"ATK14 ",
				"BlackEnergy Group",
				"Blue Echidna ",
				"CTG-7263 ",
				"ELECTRUM ",
				"FROZENBARENTS ",
				"Hades/OlympicDestroyer ",
				"IRIDIUM ",
				"Qudedagh ",
				"Sandworm Team ",
				"Seashell Blizzard ",
				"TEMP.Noble ",
				"Telebots ",
				"Voodoo Bear "
			],
			"source_name": "Secureworks:IRON VIKING",
			"tools": [
				"BadRabbit",
				"BlackEnergy",
				"GCat",
				"NotPetya",
				"PSCrypt",
				"TeleBot",
				"TeleDoor",
				"xData"
			],
			"source_id": "Secureworks",
			"reports": null
		},
		{
			"id": "18a7b52d-a1cd-43a3-8982-7324e3e676b7",
			"created_at": "2025-08-07T02:03:24.688416Z",
			"updated_at": "2026-04-10T02:00:03.734754Z",
			"deleted_at": null,
			"main_name": "BRONZE UNIVERSITY",
			"aliases": [
				"Aquatic Panda",
				"Aquatic Panda ",
				"CHROMIUM",
				"CHROMIUM ",
				"Charcoal Typhoon",
				"Charcoal Typhoon ",
				"Earth Lusca",
				"Earth Lusca ",
				"FISHMONGER ",
				"Red Dev 10",
				"Red Dev 10 ",
				"Red Scylla",
				"Red Scylla ",
				"RedHotel",
				"RedHotel ",
				"Tag-22",
				"Tag-22 "
			],
			"source_name": "Secureworks:BRONZE UNIVERSITY",
			"tools": [
				"Cobalt Strike",
				"Fishmaster",
				"FunnySwitch",
				"Spyder",
				"njRAT"
			],
			"source_id": "Secureworks",
			"reports": null
		},
		{
			"id": "6abcc917-035c-4e9b-a53f-eaee636749c3",
			"created_at": "2022-10-25T16:07:23.565337Z",
			"updated_at": "2026-04-10T02:00:04.668393Z",
			"deleted_at": null,
			"main_name": "Earth Lusca",
			"aliases": [
				"Bronze University",
				"Charcoal Typhoon",
				"Chromium",
				"G1006",
				"Red Dev 10",
				"Red Scylla"
			],
			"source_name": "ETDA:Earth Lusca",
			"tools": [
				"Agentemis",
				"AntSword",
				"BIOPASS",
				"BIOPASS RAT",
				"BadPotato",
				"Behinder",
				"BleDoor",
				"Cobalt Strike",
				"CobaltStrike",
				"Doraemon",
				"FRP",
				"Fast Reverse Proxy",
				"FunnySwitch",
				"HUC Port Banner Scanner",
				"KTLVdoor",
				"Mimikatz",
				"NBTscan",
				"POISONPLUG.SHADOW",
				"PipeMon",
				"RbDoor",
				"RibDoor",
				"RouterGod",
				"SAMRID",
				"ShadowPad Winnti",
				"SprySOCKS",
				"WinRAR",
				"Winnti",
				"XShellGhost",
				"cobeacon",
				"fscan",
				"lcx",
				"nbtscan"
			],
			"source_id": "ETDA",
			"reports": null
		},
		{
			"id": "d53593c3-2819-4af3-bf16-0c39edc64920",
			"created_at": "2022-10-27T08:27:13.212301Z",
			"updated_at": "2026-04-10T02:00:05.272802Z",
			"deleted_at": null,
			"main_name": "Earth Lusca",
			"aliases": [
				"Earth Lusca",
				"TAG-22",
				"Charcoal Typhoon",
				"CHROMIUM",
				"ControlX"
			],
			"source_name": "MITRE:Earth Lusca",
			"tools": [
				"Mimikatz",
				"PowerSploit",
				"Tasklist",
				"certutil",
				"Cobalt Strike",
				"Winnti for Linux",
				"Nltest",
				"NBTscan",
				"ShadowPad"
			],
			"source_id": "MITRE",
			"reports": null
		},
		{
			"id": "b3e954e8-8bbb-46f3-84de-d6f12dc7e1a6",
			"created_at": "2022-10-25T15:50:23.339976Z",
			"updated_at": "2026-04-10T02:00:05.27483Z",
			"deleted_at": null,
			"main_name": "Sandworm Team",
			"aliases": [
				"Sandworm Team",
				"ELECTRUM",
				"Telebots",
				"IRON VIKING",
				"BlackEnergy (Group)",
				"Quedagh",
				"Voodoo Bear",
				"IRIDIUM",
				"Seashell Blizzard",
				"FROZENBARENTS",
				"APT44"
			],
			"source_name": "MITRE:Sandworm Team",
			"tools": [
				"Bad Rabbit",
				"Mimikatz",
				"Exaramel for Linux",
				"Exaramel for Windows",
				"GreyEnergy",
				"PsExec",
				"Prestige",
				"P.A.S. Webshell",
				"AcidPour",
				"VPNFilter",
				"Neo-reGeorg",
				"Cyclops Blink",
				"SDelete",
				"Kapeka",
				"AcidRain",
				"Industroyer",
				"Industroyer2",
				"BlackEnergy",
				"Cobalt Strike",
				"NotPetya",
				"KillDisk",
				"PoshC2",
				"Impacket",
				"Invoke-PSImage",
				"Olympic Destroyer"
			],
			"source_id": "MITRE",
			"reports": null
		}
	],
	"ts_created_at": 1775438957,
	"ts_updated_at": 1775792229,
	"ts_creation_date": 0,
	"ts_modification_date": 0,
	"files": {
		"pdf": "https://archive.orkl.eu/64f711365690e360ebc0a36405a7a5e038ddddf5.pdf",
		"text": "https://archive.orkl.eu/64f711365690e360ebc0a36405a7a5e038ddddf5.txt",
		"img": "https://archive.orkl.eu/64f711365690e360ebc0a36405a7a5e038ddddf5.jpg"
	}
}