{ "id": "9e62d1f7-dc3e-45c2-b8da-46d418db6e2b", "created_at": "2026-04-06T00:10:23.986002Z", "updated_at": "2026-04-10T13:11:41.57747Z", "deleted_at": null, "sha1_hash": "4a34931f8947947a21622b9e09e804675e88c5c3", "title": "Defeating AuraStealer: Practical Deobfuscation Workflows for Modern Infostealers", "llm_title": "", "authors": "", "file_creation_date": "0001-01-01T00:00:00Z", "file_modification_date": "0001-01-01T00:00:00Z", "file_size": 8773385, "plain_text": "Defeating AuraStealer: Practical Deobfuscation Workflows for\r\nModern Infostealers\r\nBy Vojtěch KrejsaThreat Researcher at Gen\r\nArchived: 2026-04-05 13:00:23 UTC\r\nKey points\r\nAuraStealer is an emerging malware-as-a-service (MaaS) infostealer observed in recent Scam-Yourself\r\ncampaigns.\r\nTo hinder both static and dynamic analysis, AuraStealer employs a wide range of anti-analysis and\r\nobfuscation techniques, including indirect control flow obfuscation and exception-driven API hashing.\r\nIn this technical blog post, we provide a deep dive into the malware’s execution flow and functionality and\r\nprovide practical tips and workflows for defeating its obfuscation.\r\nTo support the defense community, Gen Threat Labs provides multiple scripts to assist defenders in\r\nanalyzing AuraStealer, including a string decryption script and a dedicated configuration extractor.\r\nIntroduction\r\nAuraStealer is a rapidly growing infostealer-as-a-service, actively promoted across multiple underground forums\r\nsince July 2025. The stealer is developed in C++ with a build size of ~500-700 kB and targets Windows systems\r\nfrom Windows 7 to Windows 11. It is marketed as a supposedly highly efficient, low-footprint stealer capable of\r\nstealing data from more than 110 browsers, 70 applications (including wallets and 2FA tools), as well as over 250\r\nbrowser extensions, with the ability to further expand its collection scope through a customizable configuration.\r\nContrary to the advertised claims, AuraStealer still contains multiple flaws that undermine its stealth and evasion\r\ncapabilities, offering clear detection opportunities for defenders.\r\nFigure 1: AuraStealer promoted on an underground forum.\r\nThe infostealer is offered through a tiered subscription model, with the Basic plan priced at $295/month and the\r\nAdvanced plan at $585/month. The tiers differ primarily in terms of configuration flexibility, data filtering, and\r\noperational scalability. A third tier, Team plan, is currently under development and is expected to introduce\r\nhttps://www.gendigital.com/blog/insights/research/defeating-aurastealer-obfuscation\r\nPage 1 of 28\n\nfeatures tailored for collaborative use. Additionally, a temporary Trial tier was also offered, priced at $165 for a\r\ntwo-week subscription, which included all the features of the Basic plan. The Trial tier was available for\r\npurchase only during a 30-day window, aiming to attract new users before they committed to a full subscription.\r\nThe subscriptions include access to a dedicated web panel for managing and viewing stolen data, built on the\r\nTabler template. Given that both the panel and the stealer were originally offered exclusively in Russian, it is\r\nreasonable to assume the developers operate within Russian‑speaking cybercriminal communities. However, this\r\ndoes not necessarily indicate their precise origin. The panel has since been updated and now supports both Russian\r\nand English.\r\nFigure 2: AuraStealer’s web panel overview.\r\nFigure 3: AuraStealer’s web panel with its log‑management interface, including filtering options and a detailed list\r\nof stolen records.\r\nLandscape\r\nAuraStealer primarily spreads through Scam-Yourself campaigns, with TikTok videos disguised as product\r\nactivation guides being one of them. In these videos, victims are lured by an apparently easy tutorial promising\r\nfree activation of otherwise paid software. Viewers are instructed to manually retype and run a displayed\r\ncommand in an administrative PowerShell, which, however, instead of activating the software, quietly downloads\r\nand executes the malicious payload. Concrete examples of these videos, along with the full execution chain and\r\nadditional IoCs, can be found here. \r\nApart from TikTok Scam-Yourself campaigns, AuraStealer is also distributed through supposedly cracked games\r\nor software, with delivery chains of varying complexity. In the simplest cases, only a UPX-packed version of\r\nAuraStealer is executed, without additional stages, whereas the more elaborate campaigns employ multi-stage\r\nexecution flows, involving custom loaders, DLL sideloading, injection into legitimate processes, or other\r\nintermediary steps. We have also observed AuraStealer being delivered together with GlassWorm via a malicious\r\nhttps://www.gendigital.com/blog/insights/research/defeating-aurastealer-obfuscation\r\nPage 2 of 28\n\nVS Code extension. Taken together, these observations indicate that AuraStealer is sold purely as the stealer itself,\r\nwithout a loader layer or additional delivery mechanisms.\r\nDetermining the exact scope of the AuraStealer threat is challenging, as we often block its delivery chains at\r\nearlier stages before the final payload can be executed. While the proactive defense is crucial for keeping our\r\nusers safe, it also results in many AuraStealer payloads never reaching the system. As a result, it becomes\r\ninherently difficult not only to observe and quantify the full scope of the threat, but also to determine with\r\ncertainty whether the blocked payloads were indeed intended to deliver AuraStealer.\r\nShould it, for example, be delivered through ClickFix, one of the most widely adopted delivery techniques lately,\r\nwe would proactively defend against those attacks right at the clipboard stage with our Clipboard protection\r\nfeature. ClickFix typically refers to a technique in which users are presented with artificially generated errors or\r\nproblems that must be resolved to continue, while simultaneously being provided with step-by-step instructions to\r\naddress the issue. The steps usually include copying a command and running it via the Windows Run dialog or\r\nanother system prompt, which, however, rather than resolving the issue, silently retrieves and executes the\r\nmalicious payload.\r\nTo summarize, AuraStealer is not yet as widespread and popular as the more established infostealer families\r\ncurrently dominating the threat landscape, such as Lumma Stealer, StealC or Vidar. However, according to\r\nan interview conducted by g0njxa with the AuraStealer developers, the malware is backed by a committed team\r\nthat continuously improves and evolves its functionality, aiming to become the number one in the infostealer\r\nmarket. This suggests that AuraStealer could become a more significant player in the future.\r\nAuraStealer Obfuscation\r\nAuraStealer incorporates a wide range of techniques designed to hinder both static and dynamic analysis. These\r\ninclude control flow obfuscation, string encryption, constant obfuscation, as well as standard anti-debug, anti-tamper, and anti-VM checks. It further employs advanced techniques such as exception-driven API-hashing,\r\nleveraging the Heaven’s Gate for suspicious NTDLL calls, and performing checks to detect breakpoints on return\r\naddresses.\r\nIndirect Control Flow Obfuscation\r\nThe first obfuscation technique an analyst is likely to encounter when opening AuraStealer in a disassembler, such\r\nas IDA Pro, is its indirect control flow obfuscation. The obfuscation is not only immediately noticeable, but also\r\none of the most troublesome obstacles that must be overcome to properly analyze the stealer. The obfuscation is\r\nbased on systematically replacing direct jumps and calls with indirect ones, where the actual target address is\r\ncomputed only at runtime. This method effectively disrupts static analysis, as the disassemblers are left with a set\r\nof seemingly unrelated basic blocks, effectively breaking any control-flow graph analysis or decompilation. \r\nTo demonstrate how this obfuscation works in practice, and how it can be defeated, we focus on the  WinMain\r\nfunction, which is both the longest and the most complex function of the stealer. Several examples illustrating the\r\nobfuscation mechanism at the assembly level are shown in Figure 4 below, with the instructions relevant to\r\ncomputing each target address highlighted in a distinct color. Notably, the screenshot also illustrates that the\r\nhttps://www.gendigital.com/blog/insights/research/defeating-aurastealer-obfuscation\r\nPage 3 of 28\n\nobfuscation successfully confused IDA, causing it to misinterpret the entire  WinMain  function as a single basic\r\nblock.\r\nFigure 4: Disassembled code of the WinMain function, obfuscated with indirect control flow obfuscation.\r\nDifferent colors are used to mark instructions that affect a specific indirect jmp/call.\r\nAs illustrated, the target addresses are computed in several different ways depending on the branching context,\r\nranging from simple arithmetic sum of two values (highlighted in green, blue, and red) to more complex ones,\r\nwhere the resulting target address may take multiple possible forms, with the final choice determined by a\r\nconditional instruction such as cmovz  (highlighted in pink).\r\nAt that point, a reader could easily conclude that a bit of pattern matching, emulation, and patching would be\r\nenough to remove the obfuscation – and that was our initial assumption as well. However, it turned out that\r\nAuraStealer uses multiple variations of these indirect control flow obfuscation schemes, some of which employ\r\nfar more elaborate patterns. For example, the target address may even depend on the return values of multiple\r\npreceding function calls, since its computation involves conditional instructions driven by those results (see Figure\r\n5). \r\nhttps://www.gendigital.com/blog/insights/research/defeating-aurastealer-obfuscation\r\nPage 4 of 28\n\nFigure 5: Example of a more complex obfuscation variant used to compute the target address of an indirect\r\nconditional jump.\r\nNonetheless, despite the diversity and potential complexity of these obfuscation schemes, there are still ways to\r\ndeal with them and reconstruct the original control flow. First, the most basic scheme used to obfuscate function\r\ncalls, which relies solely on the sum of two values can be resolved with a simple trick in IDA Pro. In these cases,\r\nit is sufficient to hint to IDA that the offsets contributing to the sum operation are in fact constant. Once treated as\r\nconstant operands, IDA can evaluate the arithmetic on its own and optimize it accordingly, allowing the\r\ndecompiler to reveal the actual call’s target address.\r\nFigure 6: Marking an offset as constant using the “Set type” command (shortcut Y) in IDA Pro.\r\nFigures 7 and 8 illustrate the effect of this trick and the resulting difference in the decompiled output. As can be\r\nseen, even such a minor adjustment can substantially improve the analysis, as it replaces these otherwise\r\nmeaningless offset sum calculations with direct references to the actual target functions. \r\nhttps://www.gendigital.com/blog/insights/research/defeating-aurastealer-obfuscation\r\nPage 5 of 28\n\nFigure 7: The decompiled code of the WinMain function before marking the offsets as constants.\r\nFigure 8: The decompiled code of the WinMain function after marking the offsets as constants.\r\nSince these offset references often appear in consecutive blocks (Figure 9), it is practical to automate their\r\nprocessing, for which the IDA Python snippet shown in Figure 10 is particularly useful. \r\nFigure 9: Long sequences of offsets used for indirect jmp/call computation.\r\nFigure 10: IDA Python snippet to mark multiple offset references as constant.\r\nUnfortunately, this trick alone is insufficient to address the conditional jumps and other schemes of AuraStealer's\r\nindirect control flow obfuscation. Nonetheless, given how many calls are obfuscated with this simple scheme,\r\napplying it still provides meaningful progress and can serve as a solid starting point for further deobfuscation.\r\nMoreover, AuraStealer applies the same obfuscation scheme to hide certain function arguments as well, making it\r\napplicable for those cases as well. \r\nTo tackle the more sophisticated patterns, backward slicing proved to be the most effective approach. For those\r\ninterested in a more detailed explanation of how this technique works, the articles LummaC2: Obfuscation\r\nhttps://www.gendigital.com/blog/insights/research/defeating-aurastealer-obfuscation\r\nPage 6 of 28\n\nThrough Indirect Control Flow by Nino Isakovic and Chuong Dong, and Rhadamanthys Loader Deobfuscation by\r\nMelissa Eckardt provide excellent explanations and are definitely worth reading. \r\nIn short, backward slicing is a program analysis technique that identifies instructions that may influence a specific\r\nregister or memory address at a specific program point by following data and control dependencies. The resulting\r\nset of instructions (also referred to as “slice”) can then be used for further analysis, such as emulation or symbolic\r\nexecution, to recover the value of the targeted register or memory location.\r\nIn our case, we employed a heuristic heavily inspired by backward slicing but simplified and tailored specifically\r\nfor AuraStealer. The heuristic can be summarized in the following steps:\r\n1. Locate the indirect jmp/call instruction.\r\n2. Add the register used as the target operand of this indirect jmp/call instruction to the tracked_regs  set.\r\n3. Iterate through instructions in reverse (from the indirect jmp/call towards lower addresses), analyzing\r\neach instruction whether it affects any of the tracked registers.\r\n1. If an instruction modifies a tracked register, mark it as relevant.\r\n2. For a relevant instruction, determine if it completely overwrites a tracked register (e.g., MOV reg,\r\nimm , XOR reg, reg , etc.), and if so, remove that register from tracked_reg , ending its\r\ndependency chain.\r\n3. Otherwise, identify all source registers of that relevant instruction and add them to the\r\ntracked_reg  set to propagate the dependency further back.\r\n4. Stop the process if any of these conditions occur:\r\n1. The tracked_regs  set is empty (all dependencies have been resolved).\r\n2. A control-flow instruction is encountered ( call , jmp , ret ), indicating a basic block boundary.\r\n3. A maximum instruction limit is reached (fail-safe).\r\n5. Finally, return the address of the earliest (lowest address) relevant instruction found, marking the start of\r\nthe slice.\r\nFor clarity, this heuristic is not meant to implement complete backward slicing. It deliberately omits\r\nmemory‑write tracking and focuses solely on register flows. However, it is important to note that this limitation is\r\nintentional, as register-level analysis is sufficient for the deobfuscation of the indirect control flow obfuscation\r\nemployed by AuraStealer. We use the heuristic solely to identify the slice’s starting address, from which we then\r\nperform symbolic execution with Angr to compute the target address(es). That said, if AuraStealer’s obfuscation\r\nwere to change, the heuristic could be readily extended to also account for memory interactions.\r\nThe reason we chose symbolic execution over emulation is that symbolic execution is inherently designed to\r\nexplore all possible execution paths, making it easier to implement. In terms of computational requirements, it\r\nremains feasible since we only symbolically execute small code chunks.\r\nAttentive readers may have noticed that this approach has a minor imperfection. The heuristic terminates upon\r\nencountering a call instruction. However, as shown in Figure 5, the target address of some jmps can depend\r\non the results of previous function calls, which may lead to an incorrectly identified slice start. To handle such\r\ncases, whenever a register is unconstrained, we assign it a symbolic boolean value (0 or 1), under the assumption\r\nthat any function influencing such jumps returns a boolean value. Such cases, however, are relatively rare. \r\nhttps://www.gendigital.com/blog/insights/research/defeating-aurastealer-obfuscation\r\nPage 7 of 28\n\nThe whole process can be automated with a bit of scripting and the recovered target addresses can be pushed back\r\ninto IDA as comments, which already gives a good baseline for navigating the code. \r\nFigure 11: Recovered target addresses set as comments in IDA Pro.\r\nHowever, we can go further – our real goal is to make IDA reconstruct the original control flow graph, not just\r\nannotate it. Once the target addresses of the indirect jmps/calls are retrieved, there are several ways to proceed.\r\nOne option would be to patch the binary. However, due to the variability of the patterns involved and the presence\r\nof an anti‑tamper protection in AuraStealer, we have opted for a different approach. \r\nInstead of patching the binary, which is destructive and easily detectable by malware, we leveraged the IDA SDK\r\nto hook directly into the instruction analysis process. The idea is simple – rather than letting IDA analyze the\r\ninstructions on its own, we intervene in the analysis process and modify how the instructions are decoded. For this\r\npurpose, IDA provides post_event_visitor_t , a class that allows listening and reacting to specific events in\r\nIDA by overriding the virtual function handle_post_event . \r\nFigure 12: The declaration of the handle_post_event virtual function.\r\nAmong all the possible event codes, the interesting one is the processor_t::ev_ana_insn  (analyze instruction),\r\nwhich is triggered right after IDA calls the processor module’s instruction decoder, but before the resulting\r\ninsn_t structure is finalized and committed to the database. At that point, we can inspect, or even modify, the\r\ndecoded instruction. In other words, we can alter IDA’s perception of the code without ever touching the\r\nunderlying binary.\r\nAt this point, several observations are worth highlighting:\r\nThe indirect calls almost always have a single target.\r\nMany conditional jumps have only two targets, one of which is the immediately following instruction.\r\nResolving the indirect call obfuscation is therefore straightforward. Whenever we intercept the\r\nprocessor_t::ev_ana_insn event, we check whether the analyzed instruction is an indirect call ( call reg ). If\r\nhttps://www.gendigital.com/blog/insights/research/defeating-aurastealer-obfuscation\r\nPage 8 of 28\n\nthe target address is known and it is the only possible target, we replace the call reg instruction with call\r\n\u003ccalculated_target_address\u003e .\r\nFor indirect conditional jumps, it would, in principle, be possible to determine the exact branch type by analyzing\r\nthe conditional move used to compute the target address and replacing the jmp instruction with the\r\ncorresponding conditional jump instruction. However, we opted for a much simpler and more pragmatic strategy.\r\nMany of these indirect jumps are, in fact, only obfuscated loops or if-then/if-then-else constructs with one of\r\nthe target address pointing to the immediately following instruction. So, whenever we encounter an indirect jmp\r\ninstruction with precisely two possible targets, one of which is the fall-through address, we replace the jmp\r\ninstruction with jnz (jump if not zero) pointing to the non-fall-through target address.\r\nThis transformation does not yield a perfectly accurate decompilation. However, if we accept the fact that some\r\ncomparisons may appear as  condition != 0 rather than their exact form, we end up with a control flow that is\r\nalready much easier to follow. Moreover, whenever the precise condition semantics matter, the original condition\r\ncan always be examined directly in the disassembly. Although it would be possible to reconstruct and substitute\r\nthe exact conditional jump for every case, we do not believe it is worth the effort.\r\nFigure 13: Demonstration of the replacement of a jmp instruction with a jnz instruction.\r\nRegarding indirect jumps with multiple possible targets, or those for which none of the targets is the immediately\r\nfollowing instruction, we simply add user-defined cross-references in IDA.\r\nUsing these steps, we managed to fully recover the AuraStealer’s control flow.\r\nhttps://www.gendigital.com/blog/insights/research/defeating-aurastealer-obfuscation\r\nPage 9 of 28\n\nFigure 14: Recovered control flow graph of the WinMain function after deobfuscation.\r\nNote that due to the heavy control flow obfuscation with many references to code locations, IDA often struggles to\r\nrecognize proper function boundaries. It is thus often necessary to manually adjust where the function begins and\r\nends to ensure IDA analyses the whole function.\r\nException-Driven API Hashing\r\nhttps://www.gendigital.com/blog/insights/research/defeating-aurastealer-obfuscation\r\nPage 10 of 28\n\nTo obfuscate its usage of WinAPI functions, AuraStealer employs the API hashing technique. For these purposes,\r\nit first resolves all the functions required by the binary via PEB-walking and builds two hash-based lookup tables\r\nthat maps hashes to XOR-masked addresses. \r\nThe reason for maintaining two tables is that AuraStealer does not invoke these function directly. Instead, it\r\ndeliberately triggers an exception, which, however, is intercepted by a custom exception handler. The handler\r\ninspects the address from which the exception originates and uses that information to dispatch the appropriate\r\nfunction address.\r\nTo resolve a specific function, AuraStealer takes the precomputed MurmurHash3 value (seeded with\r\n0xDEADBEEF ) of the function’s name, re-hashes it with FNV-1a , and uses both values to query the first\r\nprecomputed lookup table. The query returns the XOR-masked address from which the exception is to be thrown,\r\ntogether with the mask used to protect it. AuraStealer then unmasks the address and makes a call to it,\r\nintentionally throwing an EXCEPTION_ACCESS_VIOLATION , which is intercepted by the custom exception handler. \r\nThe exception handler rehashes the originating address using FNV-1a and uses both values to query the second\r\nprecomputed lookup table. This query returns the XOR-masked address of the actual target function, again along\r\nwith the mask. The two values are XORed together and the resulting address is loaded into the EIP register,\r\neffectively invoking the requested WinAPI function.\r\nFigure 15: Visualized exception-driven API hashing.\r\nThe MurmurHash3 values of the target functions are further obfuscated using an XOR mask (see Figure 16). In\r\nthis example, 0x130B0F3C ^ 0x25A36E25 = 0x36A86119 , which is equal to the value returned by\r\nMurmurHash3(“GetModuleHandleA”, seed: 0xDEADBEEF ). Since the result value is produced only by a XOR of two\r\nconstants, IDA’s decompiler can optimize the expression and directly display the deobfuscated value (see Figure\r\n17). \r\nThis allows us to precompute the hashes for all API-hashed functions and replace the decompiler-computed\r\nconstants with the corresponding function names. However, it is important to note that this approach relies on\r\nIDA’s decompiler, which may produce incomplete results if the control flow is not fully deobfuscated. That said,\r\nhttps://www.gendigital.com/blog/insights/research/defeating-aurastealer-obfuscation\r\nPage 11 of 28\n\nthe constants could also be recovered by combining backward slicing to isolate the instructions that influence the\r\nfinal constant value, and emulating them with an emulation framework (for example, Unicorn). In this case,\r\nremoving the obfuscation would be considerably easier than for the indirect control flow obfuscation, as the\r\nconstant obfuscation is merely an XOR, requiring emulation of only a few instructions. Moreover, these\r\ninstructions are consistently located in the same basic block where the deobfuscated constant is used.\r\nFigure 16: Constant obfuscation of the function name’s MurmurHash3 value.\r\nFigure 17: An example of an API-hashed function invocation in practice.\r\nFigure 18: AuraStealer’s custom exception handler implementation.\r\nThe exception handler is installed within the initterm routines, i.e., before the program reaches WinMain , making\r\nits presence easy to overlook. As part of this setup, AuraStealer not only registers the exception handler itself but\r\nalso allocates a memory blob via VirtualAlloc , which is later used to build the lookup tables and as a memory\r\nregion from which the exceptions are triggered.  \r\nFigure 19: AuraStealer’s initterm routines.\r\nhttps://www.gendigital.com/blog/insights/research/defeating-aurastealer-obfuscation\r\nPage 12 of 28\n\nFigure 20: Exception handler installation.\r\nThis mechanism effectively adds another layer of obfuscation.  Although the custom handler ultimately processes\r\nthe deliberately triggered exceptions, a debugger intercepts them first. Consequently, anyone analyzing\r\nAuraStealer in a debugger is flooded with EXCEPTION_ACCESS_VIOLATION , making the program appear unstable\r\nand obscuring its real behavior. This can easily lead the analyst to disable exception notifications only to make the\r\nprogram run. However, by doing so, they deliberately hide the malware’s custom exception handler in the process,\r\ncausing an important part of its logic to go unnoticed. Additionally, the exception spam also serves as an\r\nanti‑debugging technique, as the overwhelming stream of exceptions disrupts the debugging workflow.\r\nString Obfuscation\r\nAlthough most strings in AuraStealer are obfuscated, the names of the functions that are dynamically resolved and\r\nintended to be hidden via API-hashing remain in plaintext.\r\nFigure 21: Plaintext function names in the AuraStealer binary.\r\nTheir addresses, however, are obfuscated using the same arithmetic-based obfuscation used to obfuscate the target\r\naddresses of indirect calls (Figure 22).\r\nhttps://www.gendigital.com/blog/insights/research/defeating-aurastealer-obfuscation\r\nPage 13 of 28\n\nFigure 22: AuraStealer hiding function arguments.\r\nStill, since the computation relies solely on constant values, it is possible to use the same trick presented above –\r\nmarking the variable used in the computation as constant – to let IDA’s decompiler to compute the target address.\r\nThis is another excellent example of how this trick can significantly accelerate the analysis. Instead of\r\nmeaningless offsets, the decompiled code directly reveals the function name being referenced (see Figure 23).\r\nFigure 23: The decompiled code, after applying the trick with marking the offset as constant.\r\nThe remaining strings are encrypted using a stack-based XOR obfuscation. The encrypted string and its\r\ncorresponding XOR key are first concatenated in memory from constant values, XORed together, and stored in\r\nmemory. An example of how such a decryption routine looks at the assembly level is shown in Figure 24.\r\nFigure 24: AuraStealer’s string decryption at the assembly level.\r\nThese decryption routines generally follow the same logic but include slight variations, and their length varies\r\ndepending on the length of the decrypted string. The main challenge is that emulating instructions withing isolated\r\nbasic blocks and reading the strings from memory once the decryption is finished is not sufficient to recover all\r\nstrings, as many of the constants involved in the string-decryption logic are reused throughout the function.\r\nTherefore, the necessary context is distributed across the entire function. As a result, recovering all strings requires\r\nemulating much larger code regions to preserve the full context, a task that can quickly become error-prone and\r\ntime-consuming. \r\nTherefore, to decrypt AuraStealer strings, we implemented a simplified form of function emulation using the\r\nUnicorn emulation framework. Rather than emulating the entire function, we selectively step through its\r\ninstruction, while skipping call instructions and loops. When reaching conditional branches (e.g., if  or switch\r\nconstructs), we fork the execution to explore and cover all relevant paths. This streamlined approach was\r\nsufficient to recover most of the obfuscated strings without resorting to full, heavyweight emulation. \r\nhttps://www.gendigital.com/blog/insights/research/defeating-aurastealer-obfuscation\r\nPage 14 of 28\n\nFigure 25: Example of recovered strings (from a single function).\r\nA reference script implementing the decryption workflow is available on our GitHub. The script is intended to be\r\nrun from IDA Pro.  \r\nAnti-Analysis Execution Chain\r\nDuring its execution, AuraStealer performs multiple anti-analysis checks, ranging from basic to more\r\nsophisticated techniques. Some of these checks are executed unconditionally, while others depend on\r\nconfiguration parameters specific to the particular infostealer build. The execution flow is displayed in Figure 26.\r\nFigure 26: AuraStealer's anti-analysis execution flow.\r\nRunning Protected Check\r\nhttps://www.gendigital.com/blog/insights/research/defeating-aurastealer-obfuscation\r\nPage 15 of 28\n\nAuraStealer’s anti-analysis chain begins by checking whether the binary is executed from a protective layer such\r\nas a loader, packer, or crypter. Depending on that outcome, it either performs or skips additional checks, which\r\ninclude an anti-tampering check and a dialog box check. \r\nAnti-Tampering Check\r\nThe anti-tampering check is done using the MapFileAndCheckSumW WinAPI function, which computes the file’s\r\nchecksum and compares it against the value stored in the PE header. If those values differ, AuraStealer stops its\r\nexecution.\r\nThe purpose of this check is to prevent analysts from patching or otherwise altering the executable. With that in\r\nmind, analysts should be cautious about any changes made to the binary (including software breakpoints) and\r\nremain vigilant during dynamic analysis, as the malware may deliberately exhibit misleading behavior if\r\ntampering is detected. \r\nDialog Box Check\r\nSimilar to what Lumma, and more recently also Rhadamanthys, does, if AuraStealer detects that it is being run\r\nunprotected, it displays a dialog box prompting the user to enter a code to continue. Unlike Lumma and\r\nRhadamanthys, it requires the user not only to click the OK button but also to correctly enter the displayed code.\r\nOn the other hand, it does not display any warning message that malware is to be run, which is what both Lumma\r\nand Rhadamanthys display in the message box.\r\nFigure 27: The AuraStealer’s dialog box displayed when running unprotected.\r\nThis mechanism halts AuraStealer’s execution until the correct value is provided and is aimed at forcing the\r\nmalware distributors to deliver the stealer with an additional protective layer. Additionally, it also serves as an\r\nanti-sandbox protection since automated sandboxes would hardly ever perform OCR over that text and try to paste\r\nit. Both the window title and the code to be entered are randomly generated at runtime, based on the Mersenne-Twister pseudorandom number generator. \r\nGeolocation Check\r\nTo avoid execution in specific countries, AuraStealer performs a geolocation check by retrieving the system and\r\nuser language settings using the WinAPI functions GetUserDefaultLCID and GetSystemDefaultLCID , and\r\nhttps://www.gendigital.com/blog/insights/research/defeating-aurastealer-obfuscation\r\nPage 16 of 28\n\nobtains the country code through GetLocaleInfoA . The retrieved country codes are then compared against a\r\npredefined blacklist, and if any match is found, the malware terminates its execution.\r\nFigure 28: AuraStealer's list of blacklisted countries.\r\nNotably, in addition to avoiding execution in CIS countries, the stealer also omits the Baltic states (Lithuania,\r\nLatvia, and Estonia).   \r\nAccording to the AuraStealer developers, an extra IP check is allegedly performed on the server side. However,\r\nwe were unable to confirm that claim.\r\nAnti-Sandbox Checks\r\nIf all previous checks pass, the process continues to the anti-sandbox stage, which comprises three primary\r\nchecks.\r\nFirst, AuraStealer evaluates whether the Sleep  function has been hooked or modified. To do so, it records the\r\nsystem time using GetSystemTimePreciseAsFileTime , invokes Sleep(1000 ms) , and queries the system time\r\nagain. If the measured delay is less than 900 ms, the stealer assumes that the Sleep function has been tampered\r\nwith.\r\nNext, it performs a Microsoft Defender emulation check by comparing the values returned by GetUserNameW and\r\nGetComputerNameW against the well-known emulator artifacts JohnDoe and HAL9TH . \r\nFinally, AuraStealer inspects the list of currently loaded modules and compares them against the following list of\r\nblacklisted DLLs:\r\nhttps://www.gendigital.com/blog/insights/research/defeating-aurastealer-obfuscation\r\nPage 17 of 28\n\nFigure 29: AuraStealer’s list of blacklisted DLLs.\r\nConfiguration Extraction\r\nThe configuration for each AuraStealer build is embedded directly in the binary and is protected with AES-CBC\r\nencryption. The encrypted configuration is stored as a single contiguous block, with a linear, serialized layout. The\r\nencrypted configuration structure is as follows:\r\nFigure 30: AuraStealer’s configuration structure.\r\nSince all information required to decrypt the configuration is contained within the binary, it is possible to decrypt\r\nthe content and extract the malware configuration.\r\nhttps://www.gendigital.com/blog/insights/research/defeating-aurastealer-obfuscation\r\nPage 18 of 28\n\nFigure 31: An example of an extracted AuraStealer configuration.\r\nBased on the configuration, AuraStealer performs additional anti-analysis checks. If all checks pass, it attempts to\r\nestablish connection with the C2 servers listed in the configuration and initiates the data-stealing process. The\r\nconfiguration also allows setting custom user agents, defining a start delay, and choosing whether the malware\r\nshould delete itself after completing the stealing process. Interestingly, although anti‑debugging appears as a\r\nconfigurable option in the configuration, it cannot be disabled from the panel. Furthermore, even though proxy\r\nsupport is not explicitly listed in the configuration, AuraStealer is expected to handle proxy usage. This is\r\nindicated by both the available build options in the AuraStealer panel and the strings observed in the\r\nconfiguration-parsing logic within the binary.\r\nFigure 32: AuraStealer’s build settings options (panel).\r\nFigure 33: Decrypted string “proxies” within the AuraStealer’s configuration parsing function.\r\nTo streamline the process of retrieving build configuration data from AuraStealer samples, we provide a\r\nconfiguration extraction script. The script is publicly accessible on our GitHub.\r\nHuman Checks\r\nhttps://www.gendigital.com/blog/insights/research/defeating-aurastealer-obfuscation\r\nPage 19 of 28\n\nThe human check comprises two subchecks, both implemented as infinite loops. \r\nThe first check monitors whether the user input changes over time. It begins by measuring the number of ticks\r\nbetween two GetTickCount calls with a Sleep(1000 ms) in between. A while loop then repeatedly performs a\r\nSleep(500 ms) followed by a call to GetLastInputInfo , which returns a LASTINPUTINFO structure. This\r\nstructure contains a variable, dwTime , representing the tick count at which the last input event occurred. Then,\r\nanother call to GetTickCount is made, and dwTime is subtracted from it. If the result is less than the previously\r\nmeasured number of ticks measured by the one-second Sleep , the check passes. Otherwise, the loop repeats\r\nuntil the check passes. \r\nThe second check begins by a call to GetForegroundWindow , which returns a handle to the current foreground\r\nwindow. A while loop then repeatedly calls Sleep(500 ms) and checks GetForegroundWindow again. If the\r\nreturned handle differs from the initial one, the check passes. Otherwise, the loop continues until the foreground\r\nwindow changes. \r\nAnti-VM Checks\r\nThe Anti‑VM check consists of multiple subchecks. First, the presence of a hypervisor is checked using the\r\ncpuid instruction. When cpuid is executed with EAX = 1 , the 31st bit of ECX indicates the environment – it\r\nis 0 on a physical machine and 1 on a virtual machine.\r\nNext, a combination of the WinAPI functions GetDesktopWindow and GetWindowRect is used to obtain the\r\nright variable from the resulting RECT structure, which is then compared against 1024 (it is expected to be\r\ngreater). Finally, GlobalMemoryStatusEx is called, and the ullTotalPhys variable of the returned\r\nMEMORYSTATUSEX structure is checked to ensure it is not 0 .\r\nIf all of these checks pass, AuraStealer calls GetSystemInfo and inspects the returned SYSTEM_INFO structure to\r\nverify that dwNumberOfProcessors is not less than four. If the system has four or more processors, the Anti‑VM\r\ncheck is considered passed. If the processor count is below this threshold, the malware performs one additional\r\nverification using EnumProcesses to retrieve the list of running processes. It then checks whether the total\r\nnumber of running processes is at least 200 , which is assumed to be typical for a real, non‑virtualized system.\r\nFigure 34: Anti-VM check – decompiled code.\r\nhttps://www.gendigital.com/blog/insights/research/defeating-aurastealer-obfuscation\r\nPage 20 of 28\n\nFigure 35: AntiVM cpuid bit check.\r\nAnti-Debug Checks\r\nThe anti-debug check comprises several subchecks, beginning with inspecting well-known debug flags in the\r\nPEB , including BeingDebugged and NtGlobalFlag , as well as the KUSER_SHARED_DATA structure. A detailed\r\nexplanation of how these flags can be used to detect a debugger can be found here.\r\nFigure 36: Anti-Debug check – decompiled code.\r\nFigure 37: PEB!BeingDebugged flag check.\r\nFigure 38: PEB!NtGlobalFlag flag check.\r\nFigure 39: KUSER_SHARED_DATA structure check.\r\nIf all previous check pass, AuraStealer creates a new debug object using NtCreateDebugObject and makes a\r\nsubsequent call to NtQueryObject . Since the object was just created, there should exist only a single handle to it\r\n– the one held by the program itself. However, if a debugger or other monitoring tool is attached (which often\r\nhooks these functions or duplicates handles for analysis), the HandleCount may be greater than one. In that case,\r\nhttps://www.gendigital.com/blog/insights/research/defeating-aurastealer-obfuscation\r\nPage 21 of 28\n\nAuraStealer proceeds to compare the names of all running processes against a hardcoded blacklist, and if any\r\nmatch is found, it terminates its execution.\r\nFigure 40: AuraStealer’s list of blacklisted processes.\r\nNotably, as careful readers may notice in the decompiled anti-debug and anti-VM check functions, AuraStealer\r\nemploys an additional anti-debugging technique that is utilized across various functions within its codebase. The\r\ntechnique works by inspecting the opcodes located at the function’s return address. If a breakpoint instruction\r\n( INT3 or INT3 ) or a UD2  instruction (commonly used for hooking) is detected, a random value between 64\r\nand 127 is generated and added to a stack variable at offset −4 from the return address. The intent behind this\r\ntechnique is not to crash the program immediately, but to plant a subtle corruption that only results in a crash later\r\nduring execution, making it very hard to determine the crash origin.\r\nFigure 41: Disassembled view of the return address anti-debug technique.\r\nAuraStealer Execution Flow\r\nThe high-level execution flow of AuraStealer can be summarized as follows. First, the malware installs the custom\r\nexception handler and creates the two lookup hash tables used for its exception-driven API hashing. Next, it\r\nperforms multiple anti-analysis checks described above and decrypts its embedded configuration. If all checks\r\npass, it proceeds with mutex creation. \r\nhttps://www.gendigital.com/blog/insights/research/defeating-aurastealer-obfuscation\r\nPage 22 of 28\n\nBased on the hosts specified in the configuration, it attempts to establish a connection with its C2 servers, which\r\nrespond with additional configuration specifying what information and files should be collected. Finally, the\r\nmalware begins collecting the targeted data and exfiltrating it to its remote infrastructure. \r\nFigure 42: AuraStealer’s execution flow.\r\nAs for the AuraStealer’s capabilities, it targets nearly every aspect of the user’s digital life. Specifically, it is\r\ncapable of collecting:\r\nSensitive data from both Chromium-based and Gecko-based browsers\r\nCryptocurrency wallets from desktop applications and browser extensions\r\nActive session tokens (Discord, Telegram, Steam)\r\n2FA tokens (Authenticator)\r\nRecovery data (recovery seeds, private keys, and mnemonic phrases)\r\nCredentials and API keys\r\nRemote access and FTP configurations (AnyDesk configurations, FileZilla credentials)\r\nPassword manager databases (KeePass, Bitwarden, 1Password, LastPass)\r\nVPN configurations (OpenVPN, NordVPN, ProtonVPN)\r\nClipboard contents\r\nScreenshots of the victim’s device\r\nA list of running processes, along with general system fingerprinting data\r\nHowever, this is not an exhaustive list as AuraStealer allows to include additional custom configuration modules\r\nfor specific builds (including wildcard-based file search with configurable masks, paths, and recursion),\r\neffectively enabling the theft of virtually any file of interest.\r\nhttps://www.gendigital.com/blog/insights/research/defeating-aurastealer-obfuscation\r\nPage 23 of 28\n\nBeyond data theft, AuraStealer is also capable of executing additional payloads. \r\nFigure 43: Decrypted strings related to the execution of additional payloads.\r\nFigure 44: Payload execution via ShellExecuteExW.\r\nDynamically Generated Mutex\r\nTo prevent multiple instances from running simultaneously, AuraStealer utilizes dynamically generated mutexes\r\nbased on build-specific and time-dependent values. The malware first loads the build_id value from its\r\nconfiguration (for example, a0858933-16a7-433f-a9cc-68490ace0576 ) and computes a djb2 hash over it. The\r\nhash is then added to the result of an integer division _Xtime_get_ticks()/36000000000 , which effectively\r\nproduces a value that changes once per hour. The final sum serves as a seed for a Mersenne-Twister\r\npseudorandom number generator, which is used to generate a random alphanumeric string between 16 and 32\r\ncharacters in length. The generated string is prepended with Global\\ , forming the final mutex name. \r\nFigure 45: AuraStealer's mutex creation (decompiled code).\r\nThe fact that the mutex changes every hour highlights that the stealer is designed to run only for a short period of\r\ntime – a trend that has become increasingly common among modern infostealers. The goal is to execute briefly,\r\nsteal as much data as possible, and, preferably, remove all traces of its presence.\r\nApplication-Bound Encryption Bypass\r\nhttps://www.gendigital.com/blog/insights/research/defeating-aurastealer-obfuscation\r\nPage 24 of 28\n\nTo extract sensitive data from Chromium-based browsers, AuraStealer must first overcome Application-Bound\r\nEncryption (ABE), which it achieves by spawning the target browser in headless mode using CreateProcessW ,\r\nwith the process created in a suspended state, followed by a code injection. From within the injected context, the\r\nmalware invokes IElevator::Decrypt to decrypt the app_bound_encrypted_key , which enables the decryption\r\nof any ABE-protected data, including passwords and cookies.\r\nFigure 46: AuraStealer’s ABE bypass.\r\nThe injection itself is implemented by creating a shared section via NtCreateSection and mapping it into the\r\ntarget browser process using NtMapViewOfSection , after which the injected payload is executed using\r\nNtCreateThreadEx . All of the NTDLL calls involved in the injection are executed through Heaven’s Gate, a\r\ntechnique that allows 64-bit code to be executed from a 32-bit process on a 64-bit OS. This ensures both\r\ncompatibility with 64-bit browsers and also helps evade detection.\r\nFigure 47: AuraStealer’s usage of Heaven's Gate.\r\nThe injected payload is a position-independent shellcode, slightly modified at runtime for each target browser\r\nprocess. At predefined offsets within the shellcode, AuraStealer fills two randomly generated file names with the\r\npaths of the form\r\nC:\\Users\\\u003cuser\u003e\\AppData\\Local\\Temp\\\u003crandom_alphanumeric_string_len_16_to_32\u003e ,\r\nalong with a value identifying the browser type, which is later used to select the appropriate CLSID and IID for\r\nthe CoCreateInstance invocation. These two files serve as an inter-process communication mechanism between\r\nAuraStealer and the injected shellcode. The first file is used to pass the encrypted app_bound_encrypted_key to\r\nthe injected shellcode, while the second file is used by the shellcode to write back the decrypted key for retrieval\r\nby the stealer.\r\nAlthough AuraStealer is capable of decrypting the app_bound_encrypted key, required to decrypt appbound-encrypted data, from certain Chromium-based browsers, it still does not work reliably across all of them,\r\nsuggesting that the product has not yet reached a fully polished state.\r\nNetwork Traffic\r\nAuraStealer’s network traffic can be divided into four stages. The stealer first verifies internet connectivity by\r\nchecking the reachability of 1.1.1.1:53 (Cloudflare). Upon success, it attempts to establish communication with\r\nits C2 infrastructure by querying the /api/live endpoint and expecting a response true . If any of the servers\r\nhttps://www.gendigital.com/blog/insights/research/defeating-aurastealer-obfuscation\r\nPage 25 of 28\n\nare reachable, it then requests /api/conf , together with its build_id , to retrieve a build-specific configuration\r\ndefining the data to be collected (a sample configuration is publicly available on our GitHub repository). Finally,\r\nthe collected files are split into smaller archives and sent in parts as they are collected via the /api/send\r\nendpoint.\r\nFigure 48: Captured AuraStealer’s network traffic.\r\nAll network traffic is encrypted using AES-CBC in a manner very similar to the configuration encryption, with the\r\ndifference that the encrypted data is additionally Base64‑encoded. The encryption keys and initialization vectors\r\nare generated randomly at runtime. \r\nFigure 49: Structure of encrypted data transmitted over the network.\r\nFigure 50: Example of exfiltrated data.\r\nKey Takeaways and Defensive Measures\r\nAuraStealer is a rapidly growing infostealer that employs a wide range of obfuscation and anti-analysis techniques\r\nto evade both static and dynamic detection. Apart from targeting nearly every aspect of users’ digital life, it also\r\nallows for the inclusion of additional custom configurations with configurable masks, paths, and recursion,\r\neffectively enabling the theft of virtually any file of interest.\r\nWhat You Can Do:\r\nUse reputable security software with real-time protection. Products from Norton, Avast, AVG, and Avira\r\nautomatically protect users against the attacks and threats described in this analysis.\r\nAvoid copying and pasting commands from unknown or suspicious sources into system dialogs like\r\nWindows Run or PowerShell.\r\nVerify software sources – avoid downloading cracked games, software activators, or suspicious\r\nbrowser/IDE extensions.\r\nhttps://www.gendigital.com/blog/insights/research/defeating-aurastealer-obfuscation\r\nPage 26 of 28\n\nIoCs\r\n0223E39D9C26F065FABB1BCB8A1A03FE439BB18B8D14816646D8D236A6FD46A3 (AuraStealer 1.0.0)\r\n01E67139B59EED0FE1FCB4C66A9E88AD20DD8B55648C077AEC7FA2AE3431EA5F (AuraStealer 1.1.0)\r\n9A46C8D884F4C59701D3AF7BEAD1E099E3DDEB1E2B75F98756CC5403D88BD370 (AuraStealer 1.1.1)\r\nFD3875225C1AB60E6DC52FC8F94B4D389624592B7E7B57EE86E54CEBE5D3EB6A (AuraStealer 1.1.2)\r\nEC7BA08B1655963D6C9F7D996F3559C58893769A2C803DA1F99610A0AAA1224A (AuraStealer 1.2.0)\r\n0F691762DA02ABBD94046381ECEDFD8B31CCBB835DED6049E9D6CD2AFDD3F551 (AuraStealer 1.2.1)\r\nF6E7341AB412EF16076901EA5835F61FBC3E94D0B9F2813355576BAD57376F29 (AuraStealer 1.2.3)\r\nD19274A14B905679DBD43FFB374CA0E11F9DC66FDB9E17236829A9A56F3E7D31 (AuraStealer 1.3.0)\r\nF0F7AE1FC2D569B8B9267D2EC81F7E539DB4BEAF275BCA41962C27ECFA5361BF (AuraStealer 1.4.0)\r\n158369AD66EA4BACEEE19051425C21F657FFC1B3483EA812323816B612F324BD (AuraStealer 1.5.0)\r\nF816558972F62D206757BAD4A95EE75290615F520F3B24D814FFBCDFC6998C6C (AuraStealer 1.5.1)\r\nF7D0F099D042DE83AA2D0A13100640BEA49D28C77C2EB3087C0FB43EC0CD83D7 (AuraStealer 1.5.2)\r\napachesrv[.]cfd (C2)\r\nargametop[.]cfd (C2)\r\narmydevice[.]shop (C2)\r\nbrowsertools[.]shop (C2)\r\ncalibrated[.]cfd (C2)\r\nchicagocigars[.]shop (C2) \r\nclocktok[.]cfd (C2)\r\nconnupdate[.]cfd (C2)\r\ncoralpoint[.]cfd (C2)\r\ncybertool[.]shop (C2)\r\ngamedb[.]shop (C2)\r\nglossmagazine[.]shop (C2)\r\ngoldenring[.]cfd (C2)\r\ngreenapi[.]cfd (C2)\r\nmagicupdate[.]cfd (C2)\r\nmscloud[.]cfd (C2)\r\nmushub[.]cfd (C2)\r\nopencamping[.]shop (C2)\r\nprivateconnect[.]cfd (C2)\r\nsearchagent[.]cfd (C2)\r\nsearchservice[.]cfd (C2)\r\nhttps://www.gendigital.com/blog/insights/research/defeating-aurastealer-obfuscation\r\nPage 27 of 28\n\nsoftytoys[.]shop (C2)\r\nstmservice[.]cfd (C2)\r\nsysrequest[.]cfd (C2)\r\nsystemupdate[.]cfd (C2)\r\nunknowntool[.]shop (C2)\r\nupdservice[.]cfd (C2)\r\nSource: https://www.gendigital.com/blog/insights/research/defeating-aurastealer-obfuscation\r\nhttps://www.gendigital.com/blog/insights/research/defeating-aurastealer-obfuscation\r\nPage 28 of 28", "extraction_quality": 1, "language": "EN", "sources": [ "Malpedia" ], "origins": [ "web" ], "references": [ "https://www.gendigital.com/blog/insights/research/defeating-aurastealer-obfuscation" ], "report_names": [ "defeating-aurastealer-obfuscation" ], "threat_actors": [ { "id": "67bf0462-41a3-4da5-b876-187e9ef7c375", "created_at": "2022-10-25T16:07:23.44832Z", "updated_at": "2026-04-10T02:00:04.607111Z", "deleted_at": null, "main_name": "Careto", "aliases": [ "Careto", "The Mask", "Ugly Face" ], "source_name": "ETDA:Careto", "tools": [ "Careto" ], "source_id": "ETDA", "reports": null }, { "id": "2864e40a-f233-4618-ac61-b03760a41cbb", "created_at": "2023-12-01T02:02:34.272108Z", "updated_at": "2026-04-10T02:00:04.97558Z", "deleted_at": null, "main_name": "WildCard", "aliases": [], "source_name": "ETDA:WildCard", "tools": [ "RustDown", "SysJoker" ], "source_id": "ETDA", "reports": null }, { "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": "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": "f5bf6853-3f6e-452c-a7b7-8f81c9a27476", "created_at": "2023-01-06T13:46:38.677391Z", "updated_at": "2026-04-10T02:00:03.064818Z", "deleted_at": null, "main_name": "Careto", "aliases": [ "The Mask", "Ugly Face" ], "source_name": "MISPGALAXY:Careto", "tools": [], "source_id": "MISPGALAXY", "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": "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": "256a6a2d-e8a2-4497-b399-628a7fad4b3e", "created_at": "2023-11-30T02:00:07.299845Z", "updated_at": "2026-04-10T02:00:03.484788Z", "deleted_at": null, "main_name": "WildCard", "aliases": [], "source_name": "MISPGALAXY:WildCard", "tools": [], "source_id": "MISPGALAXY", "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 }, { "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 } ], "ts_created_at": 1775434223, "ts_updated_at": 1775826701, "ts_creation_date": 0, "ts_modification_date": 0, "files": { "pdf": "https://archive.orkl.eu/4a34931f8947947a21622b9e09e804675e88c5c3.pdf", "text": "https://archive.orkl.eu/4a34931f8947947a21622b9e09e804675e88c5c3.txt", "img": "https://archive.orkl.eu/4a34931f8947947a21622b9e09e804675e88c5c3.jpg" } }