Our team invests countless hours in the exploration, discovery and investigation of emerging trends such as AI and futuristic technology. Stay informed about the evolving landscape of cyberthreats through our diligent efforts and insights.

Threat Researcher at Gen

Research

<h2>Key points</h2><ul><li>AuraStealer is an emerging malware-as-a-service (MaaS) infostealer observed in recent Scam-Yourself campaigns.</li><li>To hinder both static and dynamic analysis, AuraStealer employs a wide range of anti-analysis and obfuscation techniques, including indirect control flow obfuscation and exception-driven API hashing.</li><li>In this technical blog post, we provide a deep dive into the malware’s execution flow and functionality and provide practical tips and workflows for defeating its obfuscation.</li><li>To support the defense community, Gen Threat Labs provides multiple scripts to assist defenders in analyzing AuraStealer, including a string decryption script and a dedicated configuration extractor.</li></ul><h2>Introduction</h2>AuraStealer is a rapidly growing infostealer-as-a-service, actively promoted across multiple underground forums since July 2025. The stealer is developed in C++ with a build size of ~500-700 kB and targets Windows systems from Windows 7 to Windows 11. It is marketed as a supposedly highly efficient, low-footprint stealer capable of stealing data from more than 110 browsers, 70 applications (including wallets and 2FA tools), as well as over 250 browser extensions, with the ability to further expand its collection scope through a customizable configuration. Contrary to the advertised claims, AuraStealer still contains multiple flaws that undermine its stealth and evasion capabilities, offering clear detection opportunities for defenders.

The infostealer is offered through a tiered subscription model, with the Basic plan priced at $295/month and the Advanced plan at $585/month. The tiers differ primarily in terms of configuration flexibility, data filtering, and operational scalability. A third tier, Team plan, is currently under development and is expected to introduce features tailored for collaborative use. Additionally, a temporary Trial tier was also offered, priced at $165 for a two-week subscription, which included all the features of the Basic plan. The Trial tier was available for purchase only during a 30-day window, aiming to attract new users before they committed to a full subscription.The subscriptions include access to a dedicated web panel for managing and viewing stolen data, built on the Tabler template. Given that both the panel and the stealer were originally offered exclusively in Russian, it is reasonable to assume the developers operate within Russian‑speaking cybercriminal communities. However, this does not necessarily indicate their precise origin. The panel has since been updated and now supports both Russian and English.

<h2>Landscape</h2>AuraStealer primarily spreads through Scam-Yourself campaigns, with&nbsp;<a href="https://undercodenews.com/tiktoks-dark-trick-aura-stealer-malware-masquerades-as-product-activation-guides/" target="_blank">TikTok videos</a> disguised as product activation guides being one of them. In these videos, victims are lured by an apparently easy tutorial promising free activation of otherwise paid software. Viewers are instructed to manually retype and run a displayed command in an administrative PowerShell, which, however, instead of activating the software, quietly downloads and executes the malicious payload. Concrete examples of these videos, along with the full execution chain and additional IoCs, can be found&nbsp;<a href="https://isc.sans.edu/diary/32380" target="_blank">here</a>.&nbsp;Apart from TikTok Scam-Yourself campaigns, AuraStealer is also distributed through supposedly cracked games or software, with delivery chains of varying complexity. In the simplest cases, only a UPX-packed version of AuraStealer is executed, without additional stages, whereas the more elaborate campaigns employ multi-stage execution flows, involving custom loaders, DLL sideloading, injection into legitimate processes, or other intermediary steps. We have also observed AuraStealer being delivered together with GlassWorm via a malicious VS Code extension. Taken together, these observations indicate that AuraStealer is sold purely as the stealer itself, without a loader layer or additional delivery mechanisms.Determining the exact scope of the AuraStealer threat is challenging, as we often block its delivery chains at earlier stages before the final payload can be executed. While the proactive defense is crucial for keeping our users safe, it also results in many AuraStealer payloads never reaching the system. As a result, it becomes inherently difficult not only to observe and quantify the full scope of the threat, but also to determine with certainty whether the blocked payloads were indeed intended to deliver AuraStealer.Should it, for example, be delivered through ClickFix, one of the most widely adopted delivery techniques lately, we would proactively defend against those attacks right at the clipboard stage with our&nbsp;<a href="https://www.gendigital.com/blog/news/family-of-brands/clipboard-protection" target="_blank">Clipboard protection</a> feature. ClickFix typically refers to a technique in which users are presented with artificially generated errors or problems that must be resolved to continue, while simultaneously being provided with step-by-step instructions to address the issue. The steps usually include copying a command and running it via the Windows Run dialog or another system prompt, which, however, rather than resolving the issue, silently retrieves and executes the malicious payload.To summarize, AuraStealer is not yet as widespread and popular as the more established infostealer families currently dominating the threat landscape, such as Lumma Stealer, StealC or Vidar. However, according to an&nbsp;<a href="https://g0njxa.medium.com/approaching-stealers-devs-a-brief-interview-with-aura-9b513369e117" target="_blank">interview</a> conducted by&nbsp;<a href="https://x.com/g0njxa" target="_blank">g0njxa</a> with the AuraStealer developers, the malware is backed by a committed team that continuously improves and evolves its functionality, aiming to become the number one in the infostealer market. This suggests that AuraStealer could become a more significant player in the future.<h2>AuraStealer Obfuscation</h2>AuraStealer incorporates a wide range of techniques designed to hinder both static and dynamic analysis. These include 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, leveraging the Heaven’s Gate for suspicious NTDLL calls, and performing checks to detect breakpoints on return addresses.<h3>Indirect Control Flow Obfuscation</h3>The first obfuscation technique an analyst is likely to encounter when opening AuraStealer in a disassembler, such as IDA Pro, is its indirect control flow obfuscation. The obfuscation is not only immediately noticeable, but also one of the most troublesome obstacles that must be overcome to properly analyze the stealer. The obfuscation is based on systematically replacing direct jumps and calls with indirect ones, where the actual target address is computed only at runtime. This method effectively disrupts static analysis, as the disassemblers are left with a set of seemingly unrelated basic blocks, effectively breaking any control-flow graph analysis or decompilation.&nbsp;To demonstrate how this obfuscation works in practice, and how it can be defeated, we focus on the&nbsp;<code>WinMain</code> function, which is both the longest and the most complex function of the stealer. Several examples illustrating the obfuscation mechanism at the assembly level are shown in Figure 4 below, with the instructions relevant to computing each target address highlighted in a distinct color. Notably, the screenshot also illustrates that the obfuscation successfully confused IDA, causing it to misinterpret the entire&nbsp;<code>WinMain</code>&nbsp;function as a single basic block.

As illustrated, the target addresses are computed in several different ways depending on the branching context, ranging from simple arithmetic sum of two values (highlighted in green, blue, and red) to more complex ones, where the resulting target address may take multiple possible forms, with the final choice determined by a conditional instruction such as <code>cmovz</code>&nbsp;(highlighted in pink).At that point, a reader could easily conclude that a bit of pattern matching, emulation, and patching would be enough to remove the obfuscation – and that was our initial assumption as well. However, it turned out that AuraStealer uses multiple variations of these indirect control flow obfuscation schemes, some of which employ far more elaborate patterns. For example, the target address may even depend on the return values of multiple preceding function calls, since its computation involves conditional instructions driven by those results (see Figure 5).&nbsp;

Nonetheless, despite the diversity and potential complexity of these obfuscation schemes, there are still ways to deal with them and reconstruct the original control flow. First, the most basic scheme used to obfuscate function calls, which relies solely on the sum of two values can be resolved with a simple trick in IDA Pro. In these cases, it is sufficient to hint to IDA that the offsets contributing to the sum operation are in fact constant. Once treated as constant operands, IDA can evaluate the arithmetic on its own and optimize it accordingly, allowing the decompiler to reveal the actual call’s target address.

Figures 7 and 8 illustrate the effect of this trick and the resulting difference in the decompiled output. As can be seen, even such a minor adjustment can substantially improve the analysis, as it replaces these otherwise meaningless offset sum calculations with direct references to the actual target functions.&nbsp;

Since these offset references often appear in consecutive blocks (Figure 9), it is practical to automate their processing, for which the IDA Python snippet shown in Figure 10 is particularly useful.&nbsp;

Unfortunately, this trick alone is insufficient to address the conditional jumps and other schemes of AuraStealer's indirect control flow obfuscation. Nonetheless, given how many calls are obfuscated with this simple scheme, applying it still provides meaningful progress and can serve as a solid starting point for further deobfuscation. Moreover, AuraStealer applies the same obfuscation scheme to hide certain function arguments as well, making it applicable for those cases as well.&nbsp;To tackle the more sophisticated patterns, backward slicing proved to be the most effective approach. For those interested in a more detailed explanation of how this technique works, the articles <a href="https://cloud.google.com/blog/topics/threat-intelligence/lummac2-obfuscation-through-indirect-control-flow" target="_blank">LummaC2: Obfuscation Through Indirect Control Flow</a> by Nino Isakovic and Chuong Dong, and <a href="https://cyber.wtf/2025/11/19/rhadamanthys-loader-deobfuscation/" target="_blank">Rhadamanthys Loader Deobfuscation</a> by Melissa Eckardt provide excellent explanations and are definitely worth reading.&nbsp;In short, backward slicing is a program analysis technique that identifies instructions that may influence a specific register or memory address at a specific program point by following data and control dependencies. The resulting set of instructions (also referred to as “slice”) can then be used for further analysis, such as emulation or symbolic execution, to recover the value of the targeted register or memory location.In our case, we employed a heuristic heavily inspired by backward slicing but simplified and tailored specifically for AuraStealer. The heuristic can be summarized in the following steps:<ol><li>Locate the indirect <code>jmp/call</code> instruction. </li><li>Add the register used as the target operand of this indirect <code>jmp/call</code> instruction to the <code>tracked_regs</code>&nbsp;set.</li><li>Iterate through instructions in reverse (from the indirect <code>jmp/call</code> towards lower addresses), analyzing each instruction whether it affects any of the tracked registers.<ol><li>If an instruction modifies a tracked register, mark it as relevant.</li><li>For a relevant instruction, determine if it completely overwrites a tracked register (e.g., <code>MOV reg, imm</code>, <code>XOR reg, reg</code>,&nbsp;etc.), and if so, remove that register from <code>tracked_reg</code>, ending its dependency chain.</li><li>Otherwise, identify all source registers of that relevant instruction and add them to the <code>tracked_reg</code>&nbsp;set to propagate the dependency further back.</li></ol></li><li>Stop the process if any of these conditions occur:<ol><li>The <code>tracked_regs</code>&nbsp;set is empty (all dependencies have been resolved).</li><li>A control-flow instruction is encountered (<code>call</code>, <code>jmp</code>, <code>ret</code>), indicating a basic block boundary.</li><li>A maximum instruction limit is reached (fail-safe).</li></ol></li><li>Finally, return the address of the earliest (lowest address) relevant instruction found, marking the start of the slice.</li></ol>For clarity, this heuristic is not meant to implement complete backward slicing. It deliberately omits memory‑write tracking and focuses solely on register flows. However, it is important to note that this limitation is intentional, as register-level analysis is sufficient for the deobfuscation of the indirect control flow obfuscation employed by AuraStealer. We use the heuristic solely to identify the slice’s starting address, from which we then perform symbolic execution with Angr to compute the target address(es). That said, if AuraStealer’s obfuscation were to change, the heuristic could be readily extended to also account for memory interactions.The reason we chose symbolic execution over emulation is that symbolic execution is inherently designed to explore all possible execution paths, making it easier to implement. In terms of computational requirements, it remains feasible since we only symbolically execute small code chunks.Attentive readers may have noticed that this approach has a minor imperfection. The heuristic terminates upon encountering a <code>call</code> instruction. However, as shown in Figure 5, the target address of some <code>jmps</code> can depend on the results of previous function calls, which may lead to an incorrectly identified slice start. To handle such cases, whenever a register is unconstrained, we assign it a symbolic boolean value (0 or 1), under the assumption that any function influencing such jumps returns a boolean value. Such cases, however, are relatively rare.&nbsp;The whole process can be automated with a bit of scripting and the recovered target addresses can be pushed back into IDA as comments, which already gives a good baseline for navigating the code.&nbsp;

However, we can go further – our real goal is to make IDA reconstruct the original control flow graph, not just annotate it. Once the target addresses of the indirect <code>jmps/calls</code> are retrieved, there are several ways to proceed. One option would be to patch the binary. However, due to the variability of the patterns involved and the presence of an anti‑tamper protection in AuraStealer, we have opted for a different approach.&nbsp;Instead of patching the binary, which is destructive and easily detectable by malware, we leveraged the IDA SDK to hook directly into the instruction analysis process. The idea is simple – rather than letting IDA analyze the instructions on its own, we intervene in the analysis process and modify how the instructions are decoded. For this purpose, IDA provides <a href="https://cpp.docs.hex-rays.com/structpost__event__visitor__t.html" target="_blank"><code>post_event_visitor_t</code></a>, a class that allows listening and reacting to specific events in IDA by overriding the virtual function <code>handle_post_event</code>.&nbsp;

Among all the possible event codes, the interesting one is the <code>processor_t::ev_ana_insn</code>&nbsp;(analyze instruction), which is triggered right after IDA calls the processor module’s instruction decoder, but before the resulting <code>insn_t</code> structure is finalized and committed to the database. At that point, we can inspect, or even modify, the decoded instruction. In other words, we can alter IDA’s perception of the code without ever touching the underlying binary.At this point, several observations are worth highlighting:<ul><li>The indirect calls almost always have a single target.</li><li>Many conditional jumps have only two targets, one of which is the immediately following instruction.</li></ul>Resolving the indirect call obfuscation is therefore straightforward. Whenever we intercept the <code>processor_t::ev_ana_insn</code> event, we check whether the analyzed instruction is an indirect call (<code>call reg</code>). If the target address is known and it is the only possible target, we replace the <code>call reg</code> instruction with <code>call &lt;calculated_target_address&gt;</code>.For indirect conditional jumps, it would, in principle, be possible to determine the exact branch type by analyzing the conditional move used to compute the target address and replacing the <code>jmp</code> instruction with the corresponding conditional jump instruction. However, we opted for a much simpler and more pragmatic strategy. Many of these indirect jumps are, in fact, only obfuscated loops or <code>if-then/if-then-else</code> constructs with one of the target address pointing to the immediately following instruction. So, whenever we encounter an indirect <code>jmp</code> instruction with precisely two possible targets, one of which is the fall-through address, we replace the <code>jmp</code> instruction with <code>jnz</code> (jump if not zero) pointing to the non-fall-through target address.This transformation does not yield a perfectly accurate decompilation. However, if we accept the fact that some comparisons may appear as&nbsp;<code>condition != 0</code> rather than their exact form, we end up with a control flow that is already much easier to follow. Moreover, whenever the precise condition semantics matter, the original condition can always be examined directly in the disassembly. Although it would be possible to reconstruct and substitute the exact conditional jump for every case, we do not believe it is worth the effort.

Regarding indirect jumps with multiple possible targets, or those for which none of the targets is the immediately following instruction, we simply add user-defined cross-references in IDA.Using these steps, we managed to fully recover the AuraStealer’s control flow.

Note that due to the heavy control&nbsp;flow obfuscation with many references to code locations, IDA often struggles to recognize proper function boundaries. It is thus often necessary to manually adjust where the function begins and ends to ensure IDA analyses the whole function.<h3>Exception-Driven API Hashing</h3>To obfuscate its usage of WinAPI functions, AuraStealer employs the API hashing technique. For these purposes, it first resolves all the functions required by the binary via PEB-walking and builds two hash-based lookup tables that maps hashes to XOR-masked addresses.&nbsp;The reason for maintaining two tables is that AuraStealer does not invoke these function directly. Instead, it deliberately triggers an exception, which, however, is intercepted by a custom exception handler. The handler inspects the address from which the exception originates and uses that information to dispatch the appropriate function address.To resolve a specific function, AuraStealer takes the precomputed <code>MurmurHash3</code> value (seeded with <code>0xDEADBEEF</code>) of the function’s name, re-hashes it with <code>FNV-1a</code>, and uses both values to query the first precomputed lookup table. The query returns the XOR-masked address from which the exception is to be thrown, together with the mask used to protect it. AuraStealer then unmasks the address and makes a call to it, intentionally throwing an <code>EXCEPTION_ACCESS_VIOLATION</code>, which is intercepted by the custom exception handler.&nbsp;The exception handler rehashes the originating address using <code>FNV-1a</code> and uses both values to query the second precomputed lookup table. This query returns the XOR-masked address of the actual target function, again along with the mask. The two values are XORed together and the resulting address is loaded into the <code>EIP</code> register, effectively invoking the requested WinAPI function.

The MurmurHash3 values of the target functions are further obfuscated using an XOR mask (see Figure 16). In this example, <code>0x130B0F3C ^ 0x25A36E25 = 0x36A86119</code>, which is equal to the value returned by <code>MurmurHash3(“GetModuleHandleA”, seed: 0xDEADBEEF</code>).&nbsp;Since the result value is produced only by a XOR of two constants, IDA’s decompiler can optimize the expression and directly display the deobfuscated value (see Figure 17).&nbsp;This allows us to precompute the hashes for all API-hashed functions and replace the decompiler-computed constants with the corresponding function names. However, it is important to note that this approach relies on IDA’s decompiler, which may produce incomplete results if the control flow is not fully deobfuscated. That said, the constants could also be recovered by combining backward slicing to isolate the instructions that influence the final constant value, and emulating them with an emulation framework (for example, Unicorn). In this case, removing the obfuscation would be considerably easier than for the indirect control flow obfuscation, as the constant obfuscation is merely an XOR, requiring emulation of only a few instructions. Moreover, these instructions are consistently located in the same basic block where the deobfuscated constant is used.

The exception handler is installed within the initterm routines, i.e., before the program reaches <code>WinMain</code>, making its presence easy to overlook. As part of this setup, AuraStealer not only registers the exception handler itself but also allocates a memory blob via <code>VirtualAlloc</code>, which is later used to build the lookup tables and as a memory region from which the exceptions are triggered. &nbsp;

This mechanism effectively adds another layer of obfuscation. &nbsp;Although the custom handler ultimately processes the deliberately triggered exceptions, a debugger intercepts them first. Consequently, anyone analyzing AuraStealer in a debugger is flooded with <code>EXCEPTION_ACCESS_VIOLATION</code>, making the program appear unstable and obscuring its real behavior. This can easily lead the analyst to disable exception notifications only to make the program run. However, by doing so, they deliberately hide the malware’s custom exception handler in the process, causing an important part of its logic to go unnoticed. Additionally, the exception spam also serves as an anti‑debugging technique, as the overwhelming stream of exceptions disrupts the debugging workflow.<h3>String Obfuscation</h3>Although most strings in AuraStealer are obfuscated, the names of the functions that are dynamically resolved and intended to be hidden via API-hashing remain in plaintext.

Their addresses, however, are obfuscated using the same arithmetic-based obfuscation used to obfuscate the target addresses of indirect calls (Figure 22).

Still, since the computation relies solely on constant values, it is possible to use the same trick presented above – marking the variable used in the computation as constant – to let IDA’s decompiler to compute the target address. This is another excellent example of how this trick can significantly accelerate the analysis. Instead of meaningless offsets, the decompiled code directly reveals the function name being referenced (see Figure 23).

The remaining strings are encrypted using a stack-based XOR obfuscation. The encrypted string and its corresponding XOR key are first concatenated in memory from constant values, XORed together, and stored in memory. An example of how such a decryption routine looks at the assembly level is shown in Figure 24.

These decryption routines generally follow the same logic but include slight variations, and their length varies depending on the length of the decrypted string. The main challenge is that emulating instructions withing isolated basic blocks and reading the strings from memory once the decryption is finished is not sufficient to recover all strings, as many of the constants involved in the string-decryption logic are reused throughout the function. Therefore, the necessary context is distributed across the entire function. As a result, recovering all strings requires emulating much larger code regions to preserve the full context, a task that can quickly become error-prone and time-consuming.&nbsp;Therefore, to decrypt AuraStealer strings, we implemented a simplified form of function emulation using the Unicorn emulation framework. Rather than emulating the entire function, we selectively step through its instruction, while skipping call instructions and loops. When reaching conditional branches (e.g., <code>if</code>&nbsp;or <code>switch</code> constructs), we fork the execution to explore and cover all relevant paths. This streamlined approach was sufficient to recover most of the obfuscated strings without resorting to full, heavyweight emulation.&nbsp;

A <a href="https://github.com/avast/ioc/blob/master/AuraStealer/extras/aurastealer_decrypt_strings.py" target="_blank">reference script</a> implementing the decryption workflow is available on our GitHub. The script is intended to be run from IDA Pro. &nbsp;<h2>Anti-Analysis Execution Chain</h2>During its execution, AuraStealer performs multiple anti-analysis checks, ranging from basic to more sophisticated techniques. Some of these checks are executed unconditionally, while others depend on configuration parameters specific to the particular infostealer build. The execution flow is displayed in Figure 26.

<h3>Running Protected Check</h3>AuraStealer’s anti-analysis chain begins by checking whether the binary is executed from a protective layer such as a loader, packer, or crypter. Depending on that outcome, it either performs or skips additional checks, which include an anti-tampering check and a dialog box check.&nbsp;<h3>Anti-Tampering Check</h3>The anti-tampering check is done using the <code>MapFileAndCheckSumW</code> WinAPI function, which computes the file’s checksum and compares it against the value stored in the PE header. If those values differ, AuraStealer stops its execution.The purpose of this check is to prevent analysts from patching or otherwise altering the executable. With that in mind, analysts should be cautious about any changes made to the binary (including software breakpoints) and remain vigilant during dynamic analysis, as the malware may deliberately exhibit misleading behavior if tampering is detected.&nbsp;<h3>Dialog Box Check</h3>Similar to what <a href="https://outpost24.com/blog/lummac2-anti-sandbox-technique-trigonometry-human-detection/" target="_blank">Lumma</a>, and more recently also <a href="https://research.checkpoint.com/2025/rhadamanthys-0-9-x-walk-through-the-updates/" target="_blank">Rhadamanthys</a>, does, if AuraStealer detects that it is being run unprotected, it displays a dialog box prompting the user to enter a code to continue. Unlike Lumma and Rhadamanthys, it requires the user not only to click the OK button but also to correctly enter the displayed code. On the other hand, it does not display any warning message that malware is to be run, which is what both Lumma and Rhadamanthys display in the message box.

This mechanism halts AuraStealer’s execution until the correct value is provided and is aimed at forcing the malware distributors to deliver the stealer with an additional protective layer. Additionally, it also serves as an anti-sandbox protection since automated sandboxes would hardly ever perform OCR over that text and try to paste it. Both the window title and the code to be entered are randomly generated at runtime, based on the Mersenne-Twister pseudorandom number generator.&nbsp;<h3>Geolocation Check</h3>To avoid execution in specific countries, AuraStealer performs a geolocation check by retrieving the system and user language settings using the WinAPI functions <code>GetUserDefaultLCID</code> and <code>GetSystemDefaultLCID</code>, and obtains the country code through <code>GetLocaleInfoA</code>. The retrieved country codes are then compared against a predefined blacklist, and if any match is found, the malware terminates its execution.

Notably, in addition to avoiding execution in CIS countries, the stealer also omits the Baltic states (Lithuania, Latvia, and Estonia). &nbsp;&nbsp;According to the AuraStealer developers, an extra IP check is allegedly performed on the server side. However, we were unable to confirm that claim.<h3>Anti-Sandbox Checks</h3>If all previous checks pass, the process continues to the anti-sandbox stage, which comprises three primary checks.First, AuraStealer evaluates whether the <code>Sleep</code>&nbsp;function has been hooked or modified. To do so, it records the system time using <code>GetSystemTimePreciseAsFileTime</code>, invokes <code>Sleep(1000 ms)</code>, and queries the system time again. If the measured delay is less than 900 ms, the stealer assumes that the <code>Sleep</code> function has been tampered with.Next, it performs a Microsoft Defender emulation check by comparing the values returned by <code>GetUserNameW</code> and <code>GetComputerNameW</code> against the well-known emulator artifacts <code>JohnDoe</code> and <code>HAL9TH</code>.&nbsp;Finally, AuraStealer inspects the list of currently loaded modules and compares them against the following list of blacklisted DLLs:

<h3>Configuration Extraction</h3>The configuration for each AuraStealer build is embedded directly in the binary and is protected with AES-CBC encryption. The encrypted configuration is stored as a single contiguous block, with a linear, serialized layout. The encrypted configuration structure is as follows:

Since all information required to decrypt the configuration is contained within the binary, it is possible to decrypt the content and extract the malware configuration.

Based on the configuration, AuraStealer performs additional anti-analysis checks. If all checks pass, it attempts to establish connection with the C2 servers listed in the configuration and initiates the data-stealing process. The configuration also allows setting custom user agents, defining a start delay, and choosing whether the malware should delete itself after completing the stealing process. Interestingly, although anti‑debugging appears as a configurable option in the configuration, it cannot be disabled from the panel. Furthermore, even though proxy support is not explicitly listed in the configuration, AuraStealer is expected to handle proxy usage. This is indicated by both the available build options in the AuraStealer panel and the strings observed in the configuration-parsing logic within the binary.

To streamline the process of retrieving build configuration data from AuraStealer samples, we provide a <a href="https://github.com/avast/ioc/blob/master/AuraStealer/extras/aurastealer_config_extractor.py">configuration extraction script</a>. The script is publicly accessible on our GitHub.<h3>Human Checks</h3>The human check comprises two subchecks, both implemented as infinite loops.&nbsp;The first check monitors whether the user input changes over time. It begins by measuring the number of ticks between two <code>GetTickCount</code> calls with a <code>Sleep(1000 ms)</code> in between. A while loop then repeatedly performs a <code>Sleep(500 ms)</code> followed by a call to <code>GetLastInputInfo</code>, which returns a <code>LASTINPUTINFO</code> structure. This structure contains a variable, <code>dwTime</code>, representing the tick count at which the last input event occurred. Then, another call to <code>GetTickCount</code> is made, and <code>dwTime</code> is subtracted from it. If the result is less than the previously measured number of ticks measured by the one-second <code>Sleep</code>, the check passes. Otherwise, the loop repeats until the check passes.&nbsp;The second check begins by a call to <code>GetForegroundWindow</code>, which returns a handle to the current foreground window. A while loop then repeatedly calls <code>Sleep(500 ms)</code> and checks <code>GetForegroundWindow</code> again. If the returned handle differs from the initial one, the check passes. Otherwise, the loop continues until the foreground window changes.&nbsp;<h3>Anti-VM Checks</h3>The Anti‑VM check consists of multiple subchecks. First, the presence of a hypervisor is checked using the <code>cpuid</code> instruction. When <code>cpuid</code> is executed with <code>EAX = 1</code>, the 31st bit of <code>ECX</code> indicates the environment – it is <code>0</code> on a physical machine and <code>1</code> on a virtual machine.Next, a combination of the WinAPI functions <code>GetDesktopWindow</code> and <code>GetWindowRect</code> is used to obtain the <code>right</code> variable from the resulting <code>RECT</code> structure, which is then compared against <code>1024</code> (it is expected to be greater). Finally, <code>GlobalMemoryStatusEx</code> is called, and the <code>ullTotalPhys</code> variable of the returned <code>MEMORYSTATUSEX</code> structure is checked to ensure it is not <code>0</code>.If all of these checks pass, AuraStealer calls <code>GetSystemInfo</code> and inspects the returned <code>SYSTEM_INFO</code> structure to verify that <code>dwNumberOfProcessors</code> is not less than four. If the system has four or more processors, the Anti‑VM check is considered passed. If the processor count is below this threshold, the malware performs one additional verification using <code>EnumProcesses</code> to retrieve the list of running processes. It then checks whether the total number of running processes is at least <code>200</code>, which is assumed to be typical for a real, non‑virtualized system.

<h3>Anti-Debug Checks</h3>The anti-debug check comprises several subchecks, beginning with inspecting well-known debug flags in the <code>PEB</code>, including <code>BeingDebugged</code> and <code>NtGlobalFlag</code>, as well as the <code>KUSER_SHARED_DATA</code> structure. A detailed explanation of how these flags can be used to detect a debugger can be found <a href="https://anti-debug.checkpoint.com/techniques/debug-flags.html">here</a>.

If all previous check pass, AuraStealer creates a new debug object using <code>NtCreateDebugObject</code> and makes a subsequent call to <code>NtQueryObject</code>. Since the object was just created, there should exist only a single handle to it – the one held by the program itself. However, if a debugger or other monitoring tool is attached (which often hooks these functions or duplicates handles for analysis), the <code>HandleCount</code> may be greater than one. In that case, AuraStealer proceeds to compare the names of all running processes against a hardcoded blacklist, and if any match is found, it terminates its execution.

Notably, as careful readers may notice in the decompiled anti-debug and anti-VM check functions, AuraStealer employs an additional anti-debugging technique that is utilized across various functions within its codebase. The technique works by inspecting the opcodes located at the function’s return address. If a breakpoint instruction (<code>INT3</code> or <code>INT&nbsp;3</code>) or a <code>UD2</code>&nbsp;instruction (commonly used for hooking) is detected, a random value between 64 and 127 is generated and added to a stack variable at offset <code>−4</code> from the return address. The intent behind this technique is not to crash the program immediately, but to plant a subtle corruption that only results in a crash later during execution, making it very hard to determine the crash origin.

<h2>AuraStealer Execution Flow</h2>The high-level execution flow of AuraStealer can be summarized as follows. First, the malware installs the custom exception handler and creates the two lookup hash tables used for its exception-driven API hashing. Next, it performs multiple anti-analysis checks described above and decrypts its embedded configuration. If all checks pass, it proceeds with mutex creation.&nbsp;Based on the hosts specified in the configuration, it attempts to establish a connection with its C2 servers, which respond with additional configuration specifying what information and files should be collected. Finally, the malware begins collecting the targeted data and exfiltrating it to its remote infrastructure.&nbsp;

As for the AuraStealer’s capabilities, it targets nearly every aspect of the user’s digital life. Specifically, it is capable of collecting:<ul><li>Sensitive data from both Chromium-based and Gecko-based browsers</li><li>Cryptocurrency wallets from desktop applications and browser extensions</li><li>Active session tokens (Discord, Telegram, Steam)</li><li>2FA tokens (Authenticator)</li><li>Recovery data (recovery seeds, private keys, and mnemonic phrases)</li><li>Credentials and API keys</li><li>Remote access and FTP configurations (AnyDesk configurations, FileZilla credentials)</li><li>Password manager databases (KeePass, Bitwarden,&nbsp;1Password,&nbsp;LastPass)</li><li>VPN configurations (OpenVPN, NordVPN, ProtonVPN)</li><li>Clipboard contents</li><li>Screenshots of the victim’s device</li><li>A list of running processes, along with general system fingerprinting data</li></ul>However, this is not an exhaustive list as AuraStealer allows to include additional custom configuration modules for specific builds (including wildcard-based file search with configurable masks, paths, and recursion), effectively enabling the theft of virtually any file of interest.Beyond data theft, AuraStealer is also capable of executing additional payloads.&nbsp;

<h3>Dynamically Generated Mutex</h3>To prevent multiple instances from running simultaneously, AuraStealer utilizes dynamically generated mutexes based on build-specific and time-dependent values. The malware first loads the <code>build_id</code> value from its configuration (for example, <code>a0858933-16a7-433f-a9cc-68490ace0576</code>) and computes a <code>djb2</code> hash over it. The hash is then added to the result of an integer division <code>_Xtime_get_ticks()/36000000000</code>, which effectively produces a value that changes once per hour. The final sum serves as a seed for a Mersenne-Twister pseudorandom number generator, which is used to generate a random alphanumeric string between 16 and 32 characters in length. The generated string is prepended with <code>Global\</code>, forming the final mutex name.&nbsp;

The fact that the mutex changes every hour highlights that the stealer is designed to run only for a short period of time – a trend that has become increasingly common among modern infostealers. The goal is to execute briefly, steal as much data as possible, and, preferably, remove all traces of its presence.<h2>Application-Bound Encryption Bypass</h2>To extract sensitive data from Chromium-based browsers, AuraStealer must first overcome Application-Bound Encryption (ABE), which it achieves by spawning the target browser in headless mode using <code>CreateProcessW</code>, with the process created in a suspended state, followed by a code injection. From within the injected context, the malware invokes <code>IElevator::Decrypt</code> to decrypt the <code>app_bound_encrypted_key</code>, which enables the decryption of any ABE-protected data, including passwords and cookies.

The injection itself is implemented by creating a shared section via <code>NtCreateSection</code> and mapping it into the target browser process using <code>NtMapViewOfSection</code>, after which the injected payload is executed using <code>NtCreateThreadEx</code>. All of the NTDLL calls involved in the injection are executed through Heaven’s Gate, a technique that allows 64-bit code to be executed from a 32-bit process on a 64-bit OS. This ensures both compatibility with 64-bit browsers and also helps evade detection.

The injected payload is a position-independent shellcode, slightly modified at runtime for each target browser process. At predefined offsets within the shellcode, AuraStealer fills two randomly generated file names with the paths of the form <code>C:\Users\&lt;user&gt;\AppData\Local\Temp\&lt;random_alphanumeric_string_len_16_to_32&gt;</code>, along with a value identifying the browser type, which is later used to select the appropriate CLSID and IID for the <code>CoCreateInstance</code> invocation. These two files serve as an inter-process communication mechanism between AuraStealer and the injected shellcode. The first file is used to pass the encrypted <code>app_bound_encrypted_key</code> to the injected shellcode, while the second file is used by the shellcode to write back the decrypted key for retrieval by the stealer.Although AuraStealer is capable of decrypting the <code>app_bound_encrypted</code> key, required to decrypt appbound-encrypted data, from certain Chromium-based browsers, it still does not work reliably across all of them, suggesting that the product has not yet reached a fully polished state.<h2>Network Traffic</h2>AuraStealer’s network traffic can be divided into four stages. The stealer first verifies internet connectivity by checking the reachability of <code>1.1.1.1:53</code> (Cloudflare). Upon success, it attempts to establish communication with its C2 infrastructure by querying the <code>/api/live</code> endpoint and expecting a response<code> true</code>. If any of the servers are reachable, it then requests <code>/api/conf</code>, together with its <code>build_id</code>, to retrieve a build-specific configuration defining the data to be collected (a <a href="https://github.com/avast/ioc/blob/master/AuraStealer/extras/aurastealer_config.json">sample configuration</a> is publicly available on our GitHub repository). Finally, the collected files are split into smaller archives and sent in parts as they are collected via the <code>/api/send</code> endpoint.

All network traffic is encrypted using AES-CBC in a manner very similar to the configuration encryption, with the difference that the encrypted data is additionally Base64‑encoded. The encryption keys and initialization vectors are generated randomly at runtime.&nbsp;

<h2>Key Takeaways and Defensive Measures</h2>AuraStealer&nbsp;is a rapidly growing infostealer that employs a wide range of obfuscation and&nbsp;anti-analysis techniques to evade both static and dynamic detection. Apart from targeting nearly every aspect of users’ digital life, it also allows for the inclusion of additional custom configurations with configurable masks, paths, and recursion, effectively enabling the theft of virtually any file of interest.What You Can Do:<ul><li>Use reputable security software&nbsp;with real-time protection. Products from Norton, Avast, AVG, and Avira automatically protect users against the attacks and threats described in this analysis.</li><li>Avoid copying and pasting commands&nbsp;from unknown or suspicious sources into system dialogs like Windows Run or PowerShell.</li><li>Verify software sources&nbsp;– avoid downloading cracked games, software activators, or suspicious browser/IDE extensions.</li></ul><h3>IoCs</h3>0223E39D9C26F065FABB1BCB8A1A03FE439BB18B8D14816646D8D236A6FD46A3 (AuraStealer 1.0.0)01E67139B59EED0FE1FCB4C66A9E88AD20DD8B55648C077AEC7FA2AE3431EA5F (AuraStealer 1.1.0)9A46C8D884F4C59701D3AF7BEAD1E099E3DDEB1E2B75F98756CC5403D88BD370 (AuraStealer 1.1.1)FD3875225C1AB60E6DC52FC8F94B4D389624592B7E7B57EE86E54CEBE5D3EB6A (AuraStealer 1.1.2)EC7BA08B1655963D6C9F7D996F3559C58893769A2C803DA1F99610A0AAA1224A (AuraStealer 1.2.0)0F691762DA02ABBD94046381ECEDFD8B31CCBB835DED6049E9D6CD2AFDD3F551 (AuraStealer 1.2.1)F6E7341AB412EF16076901EA5835F61FBC3E94D0B9F2813355576BAD57376F29 (AuraStealer 1.2.3)D19274A14B905679DBD43FFB374CA0E11F9DC66FDB9E17236829A9A56F3E7D31 (AuraStealer 1.3.0)F0F7AE1FC2D569B8B9267D2EC81F7E539DB4BEAF275BCA41962C27ECFA5361BF (AuraStealer 1.4.0)158369AD66EA4BACEEE19051425C21F657FFC1B3483EA812323816B612F324BD (AuraStealer 1.5.0)F816558972F62D206757BAD4A95EE75290615F520F3B24D814FFBCDFC6998C6C (AuraStealer 1.5.1)F7D0F099D042DE83AA2D0A13100640BEA49D28C77C2EB3087C0FB43EC0CD83D7 (AuraStealer 1.5.2)apachesrv[.]cfd (C2) argametop[.]cfd (C2) armydevice[.]shop (C2) browsertools[.]shop (C2) calibrated[.]cfd (C2) chicagocigars[.]shop (C2)&nbsp; clocktok[.]cfd (C2) connupdate[.]cfd (C2) coralpoint[.]cfd (C2) cybertool[.]shop (C2) gamedb[.]shop (C2) glossmagazine[.]shop (C2) goldenring[.]cfd (C2) greenapi[.]cfd (C2) magicupdate[.]cfd (C2) mscloud[.]cfd (C2) mushub[.]cfd (C2) opencamping[.]shop (C2) privateconnect[.]cfd (C2) searchagent[.]cfd (C2) searchservice[.]cfd (C2) softytoys[.]shop (C2) stmservice[.]cfd (C2) sysrequest[.]cfd (C2) systemupdate[.]cfd (C2) unknowntool[.]shop (C2) updservice[.]cfd (C2)

A technical walkthrough of obfuscation, anti-analysis and data theft capabilities

Defeating AuraStealer: Practical Deobfuscation Workflows for Modern Infostealers

Security Evangelist at Gen

Malware Researcher

Gen has discovered a novel WhatsApp account takeover campaign that we refer to as GhostPairing Attack. On the surface it looks very simple. Victims receive a message from one of their contacts, usually something along the lines of:“Hey, I just found your photo!”

The message includes a link that appears as a Facebook style preview. When users open it, they see a page that imitates a Facebook viewer and asks them to “verify” before they can see the content.What follows is a small sequence of steps that many people complete without thinking. At the end of that sequence, an attacker has full access to the victim’s WhatsApp account without stealing a single password.This article explains what we observed, how the attack works in practice, which infrastructure is involved, and what users can do to protect themselves.We use the term GhostPairing Attack because the victim is tricked into completing WhatsApp’s own device pairing flow, adding the attacker’s browser as an invisible extra device on their account. There is no password theft or SIM swap – instead, the user approves the attacker themselves by entering a pairing code that looks like normal verification.&nbsp;<h3>What we observed in the wild</h3>The campaign was first noticed in Czechia, where compromised accounts started sending short, informal messages to local contacts. The wording varied slightly, but the structure remained the same. The messages were brief, usually mentioning a photo, and included a link that rendered as a Facebook element inside WhatsApp.

The domains behind these links were not Facebook at all. Instead, they belonged to a cluster of lookalike sites with names related to photos or posts, for example:<ul><li>photobox[.]life</li><li>postsphoto[.]life</li><li>yourphoto[.]life</li><li>photopost[.]live</li><li>yourphoto[.]world</li><li>top-foto[.]life</li><li>fotoface[.]top</li></ul>Paths often included strings like /login/post.com or /login/facepost.com, which helped maintain the illusion that the user was dealing with some kind of Facebook login or content viewer.Although our earliest sightings are in<a> Czech</a>, nothing in the attack depends on the language. The same template can be reused for any country simply by changing the text of the lure.<h3>The fake viewer that is not about Facebook at all</h3>When a user clicks the link within the WhatsApp message, they land on a very minimal page. It usually carries the Facebook logo and colors, a stripped down layout and a button that invites them to continue or verify before they can see the photo.This page has two purposes.&nbsp;First, it creates a sense of familiarity that encourages the user to trust the page. People expect Facebook to ask for some kind of confirmation from time to time. Seeing a login button or a verification step feels normal.Second, it acts as the attacker’s control panel. The page is not connecting with Facebook but rather mediating between the victim and the legitimate WhatsApp Web infrastructure that the attacker is abusing.Depending on the variant, the next screen either:<ul><li>shows a QR code and tells the user to scan it with WhatsApp, or</li><li>shows a numeric code and tells the user to enter it into WhatsApp to confirm a login.</li></ul>Both flows lead to the same outcome, but later we’ll show why the QR code is rarely used in favor of the numeric code. The attacker gets their browser registered as a linked device on the victim’s WhatsApp account, where they have complete control over personal messages, photos and everything else a person does on the WhatsApp platform.<h3>A quick primer on WhatsApp device linking/pairing</h3>To understand the abuse, it helps to look briefly at how device linking in WhatsApp is supposed to work.When people use WhatsApp Web or the desktop client, they are not creating a separate account. They are linking a new device to their existing account. WhatsApp offers more than one way to do this:<ol><li>The one most people know: open WhatsApp, scan a QR code shown on the desktop or browser, and approve the new session.</li><li>A less visible option: link a device using the account’s phone number and a numeric pairing code that the user has to confirm in the app.</li></ol>Both are legitimate features, and both are meant to make it easier to connect a new laptop or browser without constantly re-entering credentials. Additionally, both can be repurposed if someone convinces the account owner to cooperate.The campaign we analyzed does exactly that.<h3>QR based <a>linking</a> – possible, but a fringe scenario</h3>On paper, attackers could run the same scam using WhatsApp’s QR based device linking. In our tests, this works technically, but it is much less practical for real victims.To abuse this flow, an attacker would open WhatsApp Web in their own browser, capture the QR code shown there and embed it into the fake Facebook viewer page. The victim would then be told to open WhatsApp, go to Linked devices and scan that QR in order to “view the photo”. From WhatsApp’s perspective, the account owner has just approved a new linked device, and the attacker’s browser receives a fully authorized session.In practice, however, there is a big usability problem. Most people run both WhatsApp and the browser on the same phone. Scanning a QR that is displayed on the very device you are using is awkward at best, and often impossible without a second screen, another phone or a tablet. We have all seen edge cases where this happens in legitimate contexts, but it is not something you would build a mass scam around.That is why, in the activity we have observed, attackers rely on the phone number and pairing code flow instead. It produces the same end result but feels like a normal two step verification process and can be completed entirely on a single device, which makes it far more attractive for large scale abuse.<h3>Abusing phone number and pairing codes</h3>The numeric code variant is slightly more complex and arguably more dangerous, because it resembles two factor authentication even more closely. It is also the most common way the scam plays out.Here, the fake page encourages the user to enter their phone number. It then acts as a proxy to the real WhatsApp device linking endpoint.The behind-the-scenes sequence looks like this:<ol><li>The victim types their phone number on the fake page.</li><li>The page forwards that number to WhatsApp’s legitimate “link device via phone number” feature.</li><li>WhatsApp generates a pairing code that is meant to be seen only by the account owner.</li><li>The attacker’s site takes that code and displays it back to the victim with text that suggests they should “enter this in WhatsApp to confirm the login and see the photo.”</li><li>The victim opens WhatsApp, sees the pairing prompt and enters the code, believing they are completing a security check.</li></ol>From the victim’s point of view, this feels like a standard verification process. They have seen similar flows in many other services.From WhatsApp’s point of view, the owner of the account has just approved a new linked device using the correct code.Again, the end result is that the attacker’s browser becomes a trusted device for that account.

<h3>What the attacker can do once linked</h3>After their device is linked, the attacker does not need to exploit anything else. They have the same capabilities that any user has when connecting WhatsApp Web on their own computer.In practice, this includes:<ul><li>Reading historical conversations, subject to what has been synced.</li><li>Receiving new messages in real time.</li><li>Viewing and downloading media such as photos, videos and voice notes.</li><li>Collecting sensitive information shared between friends: addresses, email addresses, codes, links, which can later be misused or resold.</li><li>sending messages to individuals and groups as if they were the victim.</li><li>forwarding the same lure to many contacts with very little effort.</li></ul>This is not traditional account hijacking in the sense of changing passwords or locking the owner out. The phone continues to work normally. Many victims are unaware that a second device has been added in the background, which is what makes the scam even more dangerous – criminals are hiding in your account, watching your every conversation without you even knowing it.In our observations, that restriction does not consistently clear the linked session. Unless the victim goes into Settings and removes unknown devices, the attacker may retain access.<h3>How victims then become GhostPairing attackers</h3>The propagation mechanism is simple and effective because it is rooted in real relationships.Once an attacker has access to one account, they can use it to distribute the lure text that we mentioned previously to that person’s contacts and groups. Family chats, school groups, sports teams and work-related conversations are all opportunities.Recipients see a very short, informal message coming from someone they know. There is no unfamiliar phone number, no obvious formatting errors, no long explanation. This minimal style typically avoids suspicion.Some recipients click, some do not. Those who do and complete the linking step become new compromised accounts. They, in turn, can be used to reach fresh sets of contacts that the original attacker did not know existed – the attack expands like a snowball.This is what makes the campaign efficient. It does not rely on cold spam. It rides existing trust.<h3>Why this approach is concerning</h3>Several aspects of this technique are worth highlighting.First, it does not rely on stealing secrets. There is no password phish, no SMS interception, no direct authentication bypass. Everything happens inside the boundaries of the feature set that WhatsApp intended.Second, the lure is highly plausible. For many users, the idea that “Facebook wants you to confirm something in WhatsApp” does not sound obviously wrong. Codes and QR scans have become part of everyday online life, especially on mobile.Third, it creates persistent access. Linked devices do not disappear when the user closes a tab. They remain active until manually revoked. If there is no habit of checking the list of connected WhatsApp devices, an attacker can remain connected for a long time.Finally, it opens the door to more than just simple spam. With access to full conversations and media, an attacker can learn how people talk, who is important to them, and what they might respond to. Voice notes and photos can later be reused in fraud attempts and impersonation, including deepfake enhanced scams, or extortion.&nbsp;In other words, this is a clear example of how social engineering and legitimate infrastructure can combine into a very effective compromise method.<h3>Infrastructure and kit-like behavior</h3>Looking at the domains and templates involved, there are strong signals that the GhostPairing Attack is driven by a reusable kit that attackers can buy and distribute rather than a one-off project.The same layout appears across multiple domains. The same idea of a Facebook viewer repeats, with minimal changes. Domain names follow a similar pattern around photos and posts, with a mix of generic TLDs.From an operational point of view, this is convenient. If one domain is blocked or reported, it can be discarded and replaced with another one using the same files. A buyer of such a kit can plug in their own configuration – for example text targeting a specific region or, as the scam propagates, text specific to an individual –&nbsp;and start sending lures.<h3>What people can do to protect themselves</h3>For individuals, the most important actions are simple and do not require technical knowledge.First, it is worth checking which devices are currently linked:<ul><li>Open WhatsApp.</li><li>Go to Settings → Linked Devices.</li><li>Review the list of active sessions and log out of anything you do not recognise.</li></ul>Doing this once will remove any sessions already created by this sort of scam. Doing it periodically helps catch future problems earlier.

Second, treat any request to scan a WhatsApp QR code or enter a numeric code from a webpage as suspicious. WhatsApp linking should happen from inside the app and in response to a deliberate action, not because some external site tells you that it is required to view a file.Third, enabling Two Step Verification in WhatsApp adds an additional barrier to other kinds of account abuse. It is not a complete solution, but it reduces the range of what attackers can do once they are in.Finally, sharing information about this kind of scam with family members and group chats is surprisingly effective. Many victims click because they have never heard of anything like this. Once people know that “I found your photo” messages can hide an account linking trick, they are less likely to follow the script.<h3>What platforms could improve</h3>While user awareness is essential, there are also changes that platforms can consider.Clearer messaging around device linking would help. If users saw large, unavoidable text explaining that they are about to give a new device full access to all messages and media, some would hesitate.Better context on linking and pairing events would also be useful. Showing device type, browser, approximate location, and the fact that the request originated from a website, not from the app, could nudge users to cancel when something feels off.Rate limiting device linking attempts, especially those that involve many different phone numbers from the same infrastructure, would raise the cost for attackers. Auto revoking recent linked sessions when spam or abuse is confirmed on an account would shorten the window of exploitation.None of these measures alone would eliminate such attacks, but together they would make them less attractive.<h3>Beyond WhatsApp: pairing as a broader attack surface</h3>GhostPairing is not just a quirky one off trick in a single app. It is a case study in what happens when a pairing flow is abused at scale. WhatsApp is a natural target, with billions of users and a growing role in everyday and business communication, but the pattern behind GhostPairing is more general.Conceptually, the same risk exists anywhere you have:<ol><li>A QR code, code entry screen, or approval prompt that lets a new device connect to an existing account.</li><li>A trusted primary device that scans or approves that request.</li><li>A resulting session that is long lived and largely invisible to the user.</li></ol>If those three conditions line up, an attacker who can control the QR code or pairing prompt, and convince the victim to interact with it, has a realistic path to creating their own ghost device.Many modern services follow this pattern in one form or another, from messaging apps with web or desktop clients, to collaboration tools, social platforms and account ecosystems that rely on “approve on your phone” prompts. Most of them add extra checks, such as device details, locations, or number matching, which makes abuse harder but does not change the basic dependency: a single distracted click or code entry on the primary device can grant an unknown session elsewhere.We are not claiming that GhostPairing style campaigns are already running across all these ecosystems. What we can say is:<ul><li>The design pattern that made GhostPairing possible is not unique to WhatsApp.</li><li>Any platform that combines very easy pairing with low visibility of linked devices gives attackers something to work with.</li></ul>In that sense, GhostPairing should be read as a warning, not just a WhatsApp incident. The more our digital lives depend on quick QR scans and “approve on your phone” flows, the more important it becomes to design these steps so that a single moment of inattention does not quietly create a ghost device that lives in the background for months.<h3>Conclusion</h3>The campaign described here illustrates a subtle shift in how some attackers operate. Instead of breaking cryptography or circumventing authentication, they use the product as designed and persuade users to cooperate at just the right moment.By abusing WhatsApp’s device linking features and wrapping them in a familiar looking flow, they achieve a clean and persistent account compromise with minimal technical work.The technique is not limited to one country or one platform. Any service that allows device pairing through QR codes or numeric codes is a potential candidate for similar abuse.GhostPairing Attacks are a good example of how social engineering and legitimate features combine into very effective compromises. The attacker never breaks encryption, they simply convince the user to invite them in as a linked device.The good news is that the defense is well within reach. <a>A combination of user awareness, simple hygiene checks and modest platform changes can significantly reduce the impact of this type of scam.</a>

When “verification codes” quietly hijack your account

GhostPairing Attacks: from phone number to full access in WhatsApp

Threat Analysis Engineer

Black Friday and the holiday shopping season are the busiest times of the year for online shopping, and unfortunately, for online scams too. In October alone, we observed a significant spike in blocked fake shop (e-shop scams) attacks in the United States. Blocked attacks were up 185% compared with the January to September average, and the number of users targeted rose by 126% over the same period.&nbsp;&nbsp;Throughout most of 2025, the share of users running into fake shop scams stayed relatively low. From late spring, it started to creep up, then shot up sharply in October as holiday campaigns kicked in. The chart below shows this “risk ratio”, that is, the percentage of active users who have been protected from fake shops on any given day.&nbsp;

That is not a coincidence. When people are hunting for bargains, feeling rushed, and bombarded with ads, they are more likely to click before they think. Scammers know this and flood the internet with convincing fake shops that look like the real thing. &nbsp;This blog walks through what we are seeing and what you can do to stay safe while you shop.&nbsp;<h2>What we are seeing this shopping season&nbsp;</h2>When we looked at the domains behind these fake shops, a clear pattern appeared:&nbsp;Many scam sites run on legitimate platforms such as Shopify, MyShopline, Shoplazza, and Chinese frameworks such as Shopage.org. These services are designed to help small businesses get online quickly, but they also give fraudsters an easy way to launch professional-looking stores at speed.&nbsp;Most of the fake shops we saw are wrapped in seasonal themes. Right now, many are covered in festive banners and countdown timers. Some have already switched to Christmas layouts and “holiday sale” branding to catch early gift shoppers.&nbsp;

The way victims arrive at these sites is also telling. Rather than relying on spam email, scammers are buying placement in Facebook Ads and TikTok Ads. These ads can be highly targeted, so a fake offer for designer glasses, sneakers or kitchen gadgets can be shown directly to the people most likely to be interested. Fake shops are not a problem just in the United States. In fact, during October and November alone, we blocked almost 260 000 fake e-shop domains worldwide, which is around four times higher than the same shopping season last year. The map below shows the share of users we protected from fake shop scams in each country in 2025. Darker colors mean a higher proportion of people in that country ran into at least one blocked fake shop, with clear hotspots in North America, much of Europe and Australia, but activity almost everywhere.&nbsp;

<h2>Copy-paste shops and the role of AI tools&nbsp;</h2>We also saw multiple "single product" fake shops that look almost identical. One example promoted "intelligent reading glasses" with bold claims about advanced optics and a big 50 percent discount. Another pushed a "designer wine glass" using the same layout, the same type of trust badges, and nearly the same urgency-driven messages.&nbsp;You can think of these as copy-paste shops. Once a scammer has a template that works, they can quickly clone it and swap in a new product, image and price.&nbsp;While we did not confirm AI built stores in this particular dataset, the tools to automate this already exist. AI store builders for Shopify and AI powered marketing tools promise to create product pages, write copy, and generate ad campaigns in a few clicks. In the wrong hands, that makes it easier for fraudsters to launch more fake shops faster and to test which lures work best.&nbsp;

<h2>How fake shops fake trust&nbsp;</h2>Modern fake shops are not just about flashy discounts. They are designed to look legitimate at a glance.&nbsp;Many use polished templates and SSL certificates, so the little padlock icon appears in the browser. That padlock only means the connection is encrypted, not that the site is honest, but scammers know people trust it.&nbsp;Some fake shops seed third party review platforms with positive reviews to boost their scores. In our analysis we saw cases where those reviews were later removed by the platform for breaking guidelines, a strong sign they were fake. In at least one case, the scam site ran on a subdomain of an older, existing site and showed Black Friday deals alongside those disputed reviews. Piggybacking on an established domain is another way to look more credible.&nbsp;On social media, scammers run ads that look like any other promotion in your feed. They often target specific demographics, interests or locations, and in some cases even reply to comments or reviews to keep up the illusion of a real business.&nbsp;

<h2>How to Spot a Fake Online Shop&nbsp;</h2>There is no single trick that catches every scam, but a few simple habits can dramatically lower the risk:&nbsp;<ol><li>Check the address bar, not just the logo. Look closely at the URL. Watch out for strange spellings, extra words, or domains that do not match the brand name you expect.</li><li>Be skeptical of “too good to be true” discounts. Genuine retailers do run big Black Friday sales, but if a high demand product is half the usual price, treat it as suspicious.</li><li>Verify reviews. Do not rely only on the testimonials shown on the shop itself. Search the store name together with words like "reviews", "scam" or "complaints". Be wary if you only find a handful of overly positive comments.</li><li>Check contact and return information. Legitimate shops make it easy to see who they are and how to reach them, for example a physical address, company name, clear return policy, and real customer service options. Vague contact details or only a web form are warning signs.</li><li>Use security tools and safer payment methods. Enable browser protection and make sure your security solutions are on so known scam domains are blocked before you land on them. When you pay, prefer options that offer buyer protection, such as credit card or trusted payment service, and avoid bank transfers, gift cards or cryptocurrency for online purchases.&nbsp;</li></ol>Scammers treat Black Friday, Cyber Monday and the entire holiday shopping season as a business opportunity. They use the same tools, platforms and marketing channels as legitimate stores, just with a very different goal.&nbsp;The good news is that you do not need to stop shopping online to stay safe. A bit of skepticism, a habit of checking before you click, and the right security tools in the background will go a long way to keep your money and data out of their hands.&nbsp;

Fake online shops surged during Black Friday and the holiday season, up 185% this year. Here’s what scammers are doing.

Holiday scams: How fraudsters exploit the shopping season and how to stay safe 

Threat Research Team

State-sponsored hacking groups typically operate in isolation, each advancing its own nation’s goals. That’s why any sign of collaboration between them is cause for concern. Yet new evidence uncovered by Gen researchers suggests that two of the world’s most aggressive advanced persistent threat (APT) actors, Russia-aligned Gamaredon and North Korea’s Lazarus, may be operating on shared infrastructure.&nbsp;&nbsp;This discovery hints at something much bigger than mere technical overlap. It points to a possible new stage in cyber conflict, where geopolitical alliances are mirrored in shared digital operations.&nbsp;&nbsp;<h2>From allies on the battlefield to partners online&nbsp;</h2>Russia and North Korea have maintained a long-standing partnership rooted in shared political and military interests. Moscow backed Pyongyang during and after the Korean War, and in 2024 both nations renewed that alliance through a Comprehensive Strategic Partnership that includes mutual defense commitments.&nbsp;Since 2022, Pyongyang has stepped up its support for Moscow, formally recognizing Russian-claimed territories in Ukraine and reportedly supplying munitions and troops. In 2024, Reuters reported that North Korean soldiers had been deployed to fight alongside Russian forces in Ukraine, a striking example of the two countries’ deepening cooperation.&nbsp;Now, we may be witnessing a digital extension of that alliance. On July 28, 2025, Gen’s internal monitoring systems detected a suspicious event linking Gamaredon and Lazarus activity through a shared IP address. The implications are significant: two state-backed actors from different countries may be coordinating at an operational level.&nbsp;This development aligns with broader patterns highlighted in the <a href="https://www.gendigital.com/blog/insights/reports/threat-report-q3-2025" target="_blank" rel="noreferrer noopener">Q3/2025 Threat Report</a>, where state sponsored operations showed increasing sophistication, coordination, and diversification of infrastructure. While those observations were confined within national ecosystems, the Gamaredon–Lazarus overlap suggests that similar dynamics may now be emerging across national boundaries.&nbsp;<h2>Background&nbsp;</h2><h3>Gamaredon&nbsp;</h3>Gamaredon is a Russian-aligned APT active since at least 2013, primarily focused on cyber espionage. In 2021, the Security Service of Ukraine issued a <a href="https://ssu.gov.ua/en/novyny/sbu-vstanovyla-khakeriv-fsb-yaki-zdiisnyly-ponad-5-tys-kiberatak-na-derzhavni-orhany-ukrainy" target="_blank" rel="noreferrer noopener">press release</a>, attributing several members of the group as part of Russia's Federal Security Service (FSB) 18th Information Security Center. Since its official inception, the group is believed to have conducted more than 5000 cyber-attacks, most of which targeted Ukrainian government agencies. However, with the onset of war in Ukraine, ESET <a href="https://www.welivesecurity.com/en/eset-research/cyberespionage-gamaredon-way-analysis-toolset-used-spy-ukraine-2022-2023/" target="_blank" rel="noreferrer noopener">reported</a> that Gamaredon expanded its operations to include NATO member states, likely aiming to disrupt military aid to Ukraine, underscoring the group’s prioritization of hybrid warfare.&nbsp;<h3>Lazarus&nbsp;</h3>Lazarus is a state-sponsored threat actor active since 2009 and widely believed to operate under North Korea’s government. Initially focused on cyber espionage and destructive attacks, Lazarus later shifted toward financially motivated operations to fund future campaigns. In 2021, the United States Department of Justice <a href="https://www.justice.gov/archives/opa/pr/north-korean-regime-backed-programmer-charged-conspiracy-conduct-multiple-cyber-attacks-and" target="_blank" rel="noreferrer noopener">indicted</a> three members believed to be part of the Lazarus group, connecting them to North Korea’s Reconnaissance General Bureau (RGB), the country’s primary intelligence agency. With the rise of cryptocurrency, Lazarus increasingly targeted digital assets, as evidenced by high-profile breaches such as <a href="https://www.fbi.gov/news/press-releases/fbi-identifies-lazarus-group-cyber-actors-as-responsible-for-theft-of-41-million-from-stakecom" target="_blank" rel="noreferrer noopener">Stake.com</a> ($41 million), <a href="https://www.fbi.gov/news/press-releases/fbi-identifies-cryptocurrency-funds-stolen-by-dprk" target="_blank" rel="noreferrer noopener">AtomicWallet</a> ($100 million), <a href="https://www.businesstoday.in/technology/news/story/wazirx-hacked-north-korean-hackers-behind-235-million-theft-from-indian-investors-report-reveals-439240-2024-07-29" target="_blank" rel="noreferrer noopener">WazirX</a> ($235 million), and <a href="https://neobanque.ch/blog/bybit-1-4-billion-hack-lazarus-group-2025/" target="_blank" rel="noreferrer noopener">Bybit</a> ($1.4 billion).&nbsp;Where Gamaredon spies, Lazarus steals, but both ultimately serve their governments’ strategic interests.&nbsp;<h3>The discovery: a shared digital footprint&nbsp;</h3>Just one day after the <a href="https://www.reuters.com/business/aerospace-defense/russia-starts-first-moscow-pyongyang-passenger-flights-decades-2025-07-27/" target="_blank" rel="noreferrer noopener">announcement</a> of new direct flights between Moscow and Pyongyang, Gen identified indicators of a potential collaboration between the Gamaredon and Lazarus APTs. On July 24, 2025, our system tracking Gamaredon’s Command-and-Control (C2) servers via known Telegram and Telegraph channels blocked an IP address:&nbsp;144[.]172[.]112[.]106&nbsp;

Four days later, during a routine check, the same server was found hosting an obfuscated version of InvisibleFerret (SHA256: `128da948f7c3a6c052e782acfee503383bf05d953f3db5c603e4d386e2cf4b4d`), a malware strain attributed to Lazarus. The payload matched Lazarus’ tooling and was delivered through an identical server structure (URL: `http[://]144[.]172[.]112[.]106/payload/99/81`) previously seen in ContagiousInterview, a Lazarus campaign that targeted job seekers with fake recruitment messages. While the IP could represent a proxy or VPN endpoint, the temporal proximity of both groups’ activity and the shared hosting pattern indicate probable infrastructure reuse, with moderate confidence of operational collaboration. Whether Lazarus leveraged a Gamaredon-controlled server or both actors shared the same client instance remains unclear, but the overlap is too close to ignore.&nbsp;&nbsp;<h2>Implications for the global threat landscape&nbsp;</h2>Cross-country collaborations in the APT ecosystem remain exceptionally rare. The last widely acknowledged example dates back to 2014 with the <a href="https://theintercept.com/2014/11/24/secret-regin-malware-belgacom-nsa-gchq/" target="_blank" rel="noreferrer noopener">Regin</a> malware, reportedly co-developed by the U.S. National Security Agency (NSA) and the U.K.’s Government Communications Headquarters (GCHQ).&nbsp;If confirmed, the Gamaredon–Lazarus overlap would represent the first known case of Russian–North Korean cyber collaboration in the wild.&nbsp;Such a partnership could have wide-ranging implications:&nbsp;<ul><li>Operational synergy: Lazarus’s expertise in monetizing cyberattacks through cryptocurrency theft could help Gamaredon fund or conceal future operations.</li><li>Strategic alignment: Russia, facing mounting economic and military pressure, could benefit from North Korea’s established infrastructure for covert financial operations.</li><li>Escalation potential: This kind of collaboration blurs the line between espionage, sabotage, and organized cybercrime, expanding both nations’ offensive reach.&nbsp;</li></ul><h2>Not an isolated case: national ecosystems are merging&nbsp;</h2>While cross-border APT collaboration is rare, cooperation within national ecosystems has become increasingly common.&nbsp;<h3>Lazarus x Kimsuky&nbsp;</h3>Kimsuky is another North Korean APT group. It has been active since around 2012 and assessed by <a href="https://cloud.google.com/blog/topics/threat-intelligence/mapping-dprk-groups-to-government" target="_blank" rel="noreferrer noopener">Mandiant</a> to operate under the RGB. The group specializes in advanced cyber-espionage campaigns, primarily targeting government entities and consumer-facing organizations.&nbsp;During analysis of Lazarus’ ContagiousInterview payloads, Gen researchers found that an IP address (216[.]219[.]87[.]41) later reappeared in Kimsuky-linked payloads (e.g., cce27340fd6f32d96c65b7b1034c65d5026d7d0b96c80bcf31e40ab4b8834bcd). This suggests infrastructure reuse or coordination between RGB units, evidence of alignment at North Korea’s national level.&nbsp;<h3>DoNot x SideWinder&nbsp;</h3><a href="https://www.amnesty.org/en/latest/news/2021/10/togo-activist-targeted-with-spyware-by-notorious-hacker-group/" target="_blank" rel="noreferrer noopener">DoNot</a> and <a href="https://cdn-cybersecurity.att.com/docs/global-perspective-of-the-sidewinder-apt.pdf" target="_blank" rel="noreferrer noopener">SideWinder</a> are state-sponsored APT groups believed to have been active since 2013 and 2012, respectively, both with ties to the Indian government and a primary focus on cyber espionage.&nbsp;Gen identified a DoNot-attributed payload (8bb089d763d5d4b4f96ae59eb9d8f919e6a49611c183f636bfd5c01696447938) that later executed a known SideWinder loader (f4d10604980f8f556440460adc71883f04e24231d0a9a3a323a86651405bedfb). The victim was located in Pakistan, consistent with the typical targeting profile of both groups. This cooperation resembles the previously observed <a href="https://www.eset.com/us/about/newsroom/research/eset-research-gamaredon-and-turla-target-high-profile-ukrainian-entities/" target="_blank" rel="noreferrer noopener">Gamaredon x Turla collaboration</a>, indicating that intra-country partnerships are becoming a tactical norm.&nbsp;&nbsp;

<h2>A new phase in cyber geopolitics&nbsp;</h2>The evidence of infrastructure overlap between Lazarus and Gamaredon represents a significant development in the global threat landscape. Historically, cross-country APT collaborations have been exceedingly rare, with only a handful of confirmed cases such as Stuxnet and Regin. This potential partnership signals a shift toward more complex and unpredictable alliances, where geopolitical interests may drive operational convergence.&nbsp;While the Lazarus–Gamaredon case stands out for its strategic implications, the observed intranational collaborations, such as Lazarus with Kimsuky and DoNot with SideWinder, are equally important. These partnerships demonstrate a growing trend of resource sharing and tactical alignment within national ecosystems, amplifying the reach and resilience of state-sponsored campaigns.&nbsp;For defenders, these findings underscore an urgent need to adapt detection strategies beyond single-actor attribution. Shared infrastructure, overlapping TTPs, and modular malware frameworks mean that traditional attribution models may fail to capture the full scope of risk. Security teams must:&nbsp;<ul><li>Enhance infrastructure correlation analysis to detect cross-group overlaps early. </li><li>Prioritize intelligence sharing across organizations and sectors to identify emerging alliances. </li><li>Implement layered defenses capable of mitigating diverse tactics from multiple threat actors leveraging common resources.&nbsp;</li></ul>The era of isolated APT operations is fading. As adversaries evolve through collaboration, defenders must respond with equal agility and cooperation to safeguard critical assets.

Gen Threat Labs uncover evidence of rare cross-country coordination between Russia’s Gamaredon and North Korea’s Lazarus

Alliances of convenience: How APTs are beginning to work together 

In recent weeks, our Threat Labs researchers have uncovered two new toolsets that show just how adaptive the DPRK’s operations have become. Kimsuky, known for its espionage-style campaigns, deployed a new backdoor we’ve named HttpTroy, while Lazarus introduced an upgraded version of its BLINDINGCAN remote access tool.&nbsp;Both attacks reveal the same underlying pattern: stealthy code and layered obfuscation. In this post, we’ll break down how these tools work, what they target and what defenders can learn from the latest moves inside the DPRK playbook.&nbsp;<h2>Inside DPRK’s Latest Campaigns: How Kimsuky and Lazarus Refine Their Playbook&nbsp;</h2>The Kimsuky attack targeted a single victim in KR and started with a ZIP file that looked like a VPN invoice, then quietly installed tools that let attackers move files, take screenshots and run commands. The chain has three steps: a small dropper, a loader called MemLoad, and the final backdoor, named “HttpTroy”. We see several signs that possibly tie this activity to Kimsuky: the Korean language lure, an AhnLab-style scheduled task name and command patterns seen in past Kimsuky work.&nbsp;&nbsp;The Lazarus attack targeted two victims in CA and was caught in the middle of the attack chain, where we observed a new version of the Comebacker malware leading to a new variant of their BLINDINGCAN remote access tool.&nbsp;&nbsp;We’ll explain how these attacks work in plain terms, why North Korea-aligned groups use these tricks, and simple steps you can take to avoid similar threats.&nbsp;Quick takeaways for readers: do not open any attachments you did not expect, treat .scr files as programs not documents and keep your security software on and updated.&nbsp;<h2>Diving into the Kimsuky attack: MemLoad and HttpTroy&nbsp;</h2><h3>The Initial dropper&nbsp;</h3>While the exact delivery mechanism remains unknown, telemetry indicates that the samples was obtained via an internet download, packaged within a ZIP archive named “250908_A_HK이노션_SecuwaySSL VPN Manager U100S 100user_견적서”. Given the nature of the filename, it is highly probable that the archive was distributed through a phishing email.&nbsp;Contained within the archive is a “.scr” file bearing the same name. Execution of this file initiates the entire infection chain.&nbsp;This initial sample is a lightweight GO binary containing 3 embedded files. These files are decrypted using a simple XOR operation with the key “0x39”, then written to disk and executed. To maintain user deception, the binary displays a PDF document as a decoy, displaying a fake bill for VPN services, while simultaneously registering the next stage backdoor as a COM server using “regsvr32.exe”. See below an image of the decoy PDF and the decompiled code that decrypts it.&nbsp;

<h3>Stage 1 backdoor: Memload_V3&nbsp;</h3>The first backdoor, internally identified as Memload_V3 (“Memload_V3.dll”), performs 2 primary functions:&nbsp;

<ol><li>Re-registering the “AhnlabUpdate” scheduled task&nbsp;</li></ol>Using COM interfaces instantiated via the Windows API “CoCreateInstance”, the backdoor re-creates a scheduled task named “AhnlabUpdate”, targeting one of the more prevalent anti-virus software in the Korean region to avoid suspicions. This task is configured to execute the current DLL silently using the command “regsvr32.exe /s &lt;CURRENT_FILENAME&gt;”. The task is then set to repeat every minute, using the “PT1M” repetition pattern.&nbsp;

2. Decrypting and executing the final payload&nbsp;After establishing persistence, Memload_V3 proceeds to decrypt the third file dropped by the initial sample. The decryption algorithm used is RC4, and once decrypted, the payload is loaded directly into memory. Execution is then triggered via its exported function named “hello”.

<h3>Final payload: HttpTroy backdoor&nbsp;</h3>The final stage of the attack chain is a highly obfuscated backdoor, internally named HttpTroy (“httptroy_dll.dll”). This component grants the attackers full control over the compromised system, offering a wide range of capabilities:&nbsp;<ul><li>File upload and download</li><li>Screenshot capture and exfiltration</li><li>Command execution with elevated privileges</li><li>Loading an executable in memory</li><li>Reverse shell</li><li>Process termination and trace removal&nbsp;</li></ul>HttpTroy employs multiple layers of obfuscation to hinder analysis and detection. API calls are concealed using custom hashing techniques, while strings are obfuscated through a combination of XOR operations and SIMD instructions.&nbsp;Notably, the backdoor avoids reusing API hashes and strings. Instead, it dynamically reconstructs them during runtime using varied combinations of arithmetic and logical operations, further complicating static analysis.&nbsp;&nbsp;

The HttpTroy backdoor communicates with its command-and-control server exclusively via HTTP POST requests. All transmitted data (both commands and responses) is obfuscated using a two-step process: XOR encryption with the key 0x56, followed by Base64 encoding. Each query to the C2 has a specific ID and is followed by buffers of interest, all formatted in a single special string. Commands received from the server follow a simple structure: “&lt;command&gt; &lt;parameters&gt;”.&nbsp;

After executing a command, the backdoor reports the result to the C2 using ID 2:&nbsp;<ul><li>ok - Successful execution</li><li>fail - Execution failed</li><li>connect ok - Successful reverse shell connection&nbsp;</li></ul>To request a new command from the C2, the backdoor sends a query with ID 1.&nbsp;Below, you can see an example flow of a command in decompiled code, together with the decryption flow of a response from the server for the “down” command:&nbsp;

<h3>Indicators of compromise&nbsp;</h3>SCR file: e19ce3bd1cbd980082d3c55a4ac1eb3af4d9e7adf108afb1861372f9c7fe0b76&nbsp;Memload_V3: 20e0db1d2ad90bc46c7074c2cc116c2c08a8183f3ac6f357e7ebee0c7cc02596&nbsp;HttpTroy: 10c3b3ab2e9cb618fc938028c9295ad5bdb1d836b8f07d65c0d3036dbc18bbb4&nbsp;C2: hxxp[://]load[.]auraria[.]org/index[.]php&nbsp;User-agent (wide-string): Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/79.0.3945.130 Safari/537.36&nbsp;Mutexes:&nbsp;a:fnjiuygredfgbbgfcvhutrv&nbsp;u:fnjiuygredfgbbgfcvhutrv&nbsp;<h2>Analysis of the Lazarus Attack: the comeback of Comebacker and the new BLINDINGCAN variant&nbsp;</h2><h3>Comebacker, yet again&nbsp;</h3>During routine threat monitoring, our team identified a sample indicative of a new variant of the previously documented Comebacker malware, which is attributed to the Lazarus APT group. While our telemetry captures the infection chain from this stage onward, the initial access vector remains unclear. However, based on the absence of any exploited vulnerabilities, we assess with moderate confidence that the initial compromise likely originated from a phishing email.&nbsp;We observed two closely related instances of the Comebacker malware:&nbsp;<ul><li>A DLL variant located at “C:\ProgramData\comms.bin” (internally named “NetSvcInst_v1_Rundll32.dll”, using the exported function “InfoHook”)</li><li>An EXE variant located at “C:\ProgramData\Comms\ssh.bin”&nbsp;</li></ul>The DLL sample appears to have been executed via a Windows service, whereas the EXE variant was launched through cmd.exe, suggesting a different execution context.&nbsp;Despite their differing formats, both variants share identical functionality. Their primary objectives include:&nbsp;<ul><li>Validating execution via a specific command-line parameter</li><li>Decrypting embedded payloads</li><li>Configuring registry entries</li><li>Deploying the next-stage payload as a service&nbsp;</li></ul>The dropper's behavior can be summarized in the following stages:&nbsp;<ol><li>Dynamic function resolution&nbsp;</li></ol>Prior to payload execution, the malware dynamically resolves API functions from system DLLs. This is achieved by XOR-decrypting hardcoded strings using a PRNG-like stream.

<ol start="2"><li>Parameter validation&nbsp;</li></ol>Execution is gated by the presence of specific command-line arguments. The DLL variant expects "up45V3FR9ee9", while the EXE variant requires "760H33ls9L5S". If the parameters are incorrect, the malware terminates.&nbsp;<ol start="3"><li>Service name selection&nbsp;</li></ol>The malware enumerates the “REG_MULTI_SZ” entries under “HKLM\ SOFTWARE\Microsoft\Windows NT\CurrentVersion\Svchost\netsvcs”, identifying service names that are listed but not yet registered under “HKLM\ SYSTEM\CurrentControlSet\Services”. A random candidate is then selected and reused as both the service name and the name of the service DLL.&nbsp;

For some of the string decryption processes, it uses the HC256 stream cipher, while for others it uses RC4.&nbsp;

<ol start="4"><li>Timestamp logging&nbsp;</li></ol>The malware writes the current local time to “C:\Windows\system32\AppxProvision.xml” using the format “[%04d-%02d-%02d %02d:%02d:%02d] %s\n”, appending the chosen service name. It then modifies the file’s attributes to mimic those of win32k.sys.

<ol start="5"><li>Payload deployment and configuration&nbsp;</li></ol>The embedded PE file is decrypted using HC256, then decompressed via zlib, and written into a decoy file in the current directory named “kjepl.xml”. To obfuscate its true size, random data is appended at the end. The file is then moved via “cmd.exe” to “C:\Windows\system32\&lt;SERVICE_NAME&gt;.dll”, and its attributes are altered similarly to the timestamp file, but this time it mimics “cmd.exe”.&nbsp;

Subsequently, the embedded configuration is decrypted using HC256, re-encrypted using RC4 and stored as a binary blob in the registry under&nbsp; “HKLM\SYSTEM\ControlSet001\Services\kbddes\GUID”. The configuration includes potential C2 addresses, the path to cmd.exe, the path to the dropped DLL, %TEMP%, and a special integrity-check value.&nbsp;

<ol start="6"><li>Service execution&nbsp;</li></ol>Finally, the malware registers and starts a service using the randomly selected name, thereby initiating the next stage of the attack.&nbsp;

<h3>Second stage: Compcat_v1.dll&nbsp;</h3>Both observed variants of the Comebacker dropper deploy the same service binary, internally named “Compcat_v1.dll”. This component serves a singular purpose: it acts as a wrapper for the final payload.&nbsp;Upon execution, it decrypts an embedded PE file using the HC256 stream cipher. The decrypted data is then decompressed using the miniz library, a lightweight zlib-compatible implementation. The resulting PE is loaded directly into memory, employing a technique similar to that used by the aforementioned MemLoad sample.&nbsp;Once the payload is successfully mapped into memory, the malware invokes the exported function “OPENSLL_NONPIC”, thereby initiating the execution of the final stage.&nbsp;

<h3>Final payload: new variant of BLINDINGCAN&nbsp;</h3>As the final payload, the attackers employed a new variant of their BLINDINGCAN remote access tool, improved with additional cryptographic elements and more capabilities. Internally named “T_DLL64.dll”, it acts as a complete suite for attackers, offering them the possibility to perform any action they desire.&nbsp;The backdoor has 2 operating modes, which are dictated by the parameter passed to the main function:&nbsp;<ul><li>13398 – config stored in a file</li><li>13399 – config stored in registry&nbsp;</li></ul>Apart from the “OPENSSL_NONPIC” export, this sample exports another function, called “MemLoad”, which uses the other operating mode (13398).&nbsp;The malware’s execution begins by dynamically loading APIs, using the same techniques as in the previous cases. It then moves on to loading the configuration, picking a C2 at random and attempting to connect to it.&nbsp;Next, it attempts to authenticate itself within the chosen C2 by sending a “GET” request with the integrity-check value from the config, followed by 4 random uppercase letters. This newly obtained value is then shifted with a random offset between 0 and 9 (which is appended at the end of the buffer), XOR-encrypted with 0xC6 and Base64-encoded before being sent. To add to the authenticity of the request, the malware also sends additional buffers of key-value pairs filled with random values.&nbsp;If the authentication succeeds, it proceeds to generate RSA-2048 keys for encryption. The public key is then sent to the C2 in a similar fashion. The same operations regarding the config integrity-check value are performed, and their value represents the beginning of the data. Following that, the values 23, 0, and the size of the public key are appended before the public key (separated by spaces), then encrypted with HC256 and the same XOR + Base64 combo as before. Similar randomness is added after, and the request is sent as such.&nbsp;

From the response, the malware obtains some RSA-encrypted values, that are then decrypted and will serve in future communications as key and IV for encryption via the EVP interface.&nbsp;

Due to the functions used in the structure that contains the “evp_cipher_st” struct for the encryption functions, we conclude that the encryption used is AES-128-CBC.&nbsp;Subsequently, the malware enters its main command loop, constantly communicating with the C2 and executing the commands of the attackers.&nbsp;The communication pattern to the C2 is now as follows:&nbsp;<ol><li>Join by space 2 per-command specific values and the size of the data to be sent</li><li>First parameter is the command ID</li><li>Second parameter represents the status of the command1 – Success sending regular chunk (for streamed buffers – typically 100KB chunks)2 – Error3 – Success sending end chunk (if the buffers are not streamed, this value is used)</li><li>Append the data and AES-128-CBC encrypt everything</li><li>String-shift the same config token + 4 random letters by a random value (0-9) appended at the end, then XOR+Base64 encode it</li><li>Compute MD5 of the encrypted payload and append the encrypted data after the hash, then XOR+Base64 encode it</li><li>Build the base request data as “&lt;RANDOM_2_LETTERS&gt;=&lt;XOR+BASE64(SHIFTED_TOKEN || 4_RANDOM_LETTERS) || SHIFT_OFFSET&gt;&amp;&lt;RANDOM_4_LETTERS&gt;=&lt;RANDOM_4_OR_5_LETTERS&gt;&amp;&lt;RANDOM_5_LETTERS&gt;=&lt;XOR+BASE64(MD5 || ENCRYPTED_DATA)&gt;”</li><li>Append a random amount of random key-value pairs after the base data&nbsp;</li></ol>

In similar fashion, responses are XOR + Base64 decoded, integrity-checked using MD5, and AES-128-CBC decrypted in case of a match.&nbsp;Continuing, we will describe the functionalities of the RAT:&nbsp;<ul><li>Command ID 1<ul><li>Exfiltrate file, starting from an offset and compressing it</li><li>Input: &lt;SRC_PATH&gt;|&lt;OFFSET&gt;</li><li>Chunked</li></ul></li><li>Command ID 2<ul><li>Downloads a file from the C2</li><li>Input: &lt;DEST_PATH&gt;|&lt;SIZE_OF_DATA_BLOCK&gt;|&lt;BYTES_TO_WRITE</li><li>Chunked</li></ul></li><li>Command ID 3<ul><li>Copies a file to %TEMP% and exfiltrates it from there</li><li>Input: &lt;SRC_PATH&gt;|&lt;OFFSET&gt;</li><li>Chunked</li></ul></li><li>Command ID 4<ul><li>Securely delete a file by overwriting it and renaming it multiple times</li><li>Input: &lt;FILE_PATH&gt;</li><li>Not chunked</li></ul></li><li>Command ID 5<ul><li>Changes a file’s attributes to mimic another file</li><li>&lt;DEST_PATH&gt;|&lt;SRC_PATH&gt;</li><li>Not chunked</li></ul></li><li>Command ID 6<ul><li>Recursively traverses all sub-directories and files from a given path, also reporting their size</li><li>Input: &lt;SRC_DIR_PATH&gt;</li><li>Not chunked</li></ul></li><li>Command ID 7<ul><li>Traverses the entire file system, listing the empty space from drives, files and their attributes</li><li>Chunked</li></ul></li><li>Command ID 8<ul><li>Gathers data from the victim computer, such as locale info, computer name, OS version, MAC address, network adapters, CPU architecture, OEM code page</li><li>Not chunked</li></ul></li><li>Command ID 9<ul><li>Runs a command-line via CreateProcessW</li><li>Input: &lt;CMDLINE&gt;</li><li>Not chunked</li></ul></li><li>Command ID 10<ul><li>Runs a command-line in a given session via CreateProcessAsUserW</li><li>Input: &lt;CMDLINE&gt;|&lt;SESSION_ID&gt;</li><li>Not chunked</li></ul></li><li>Command ID 11<ul><li>Lists active processes (provides EXE name, full image path, PID, PPID, SID, user and creation time)</li><li>Chunked</li></ul></li><li>Command ID 12<ul><li>Kills a process</li><li>Input: &lt;PROCESS_ID&gt;</li><li>Not chunked</li></ul></li><li>Command ID 13<ul><li>Keep alive request</li><li>Not chunked</li></ul></li><li>Command ID 14<ul><li>Sleeps for a given period, checking for early wake conditions such as new drives or sessions every 5 seconds</li><li>Input: &lt;SLEEP_DURATION&gt;</li><li>Not chunked</li></ul></li><li>Command ID 15<ul><li>Hibernate for a given period, checking for early wake conditions every minute</li><li>Input: &lt;HIBERNATION_DURATION&gt;</li><li>Not chunked</li></ul></li><li>Command ID 16<ul><li>Updates the config from the binary’s current config</li><li>Not chunked</li></ul></li><li>Command ID 17<ul><li>Send the current config from the binary to the C2</li><li>Not chunked</li></ul></li><li>Command ID 18<ul><li>Removes traces, securely deletes itself and terminates itself</li><li>Not chunked</li></ul></li><li>Command ID 19<ul><li>Test TCP connection to a given IP address</li><li>Input: &lt;IP&gt;:&lt;PORT&gt; &lt;TIMEOUT&gt;</li><li>Not chunked</li></ul></li><li>Command ID 20<ul><li>Runs cmd.exe with the provided command line and reports back the output</li><li>Input: &lt;COMMAND_LINE&gt;</li><li>Chunked</li></ul></li><li>Command ID 21<ul><li>Changes the current working directory</li><li>Input: &lt;DIR_PATH&gt;</li><li>Not chunked</li></ul></li><li>Command ID 22<ul><li>Obtains the current working directory</li><li>Not chunked</li></ul></li><li>Command ID 23<ul><li>Updates encryption keys with new values</li><li>Not chunked</li></ul></li><li>Command ID 24<ul><li>Takes a screenshot and sends it to the C2</li><li>Chunked</li></ul></li><li>Command ID 25<ul><li>Enumerate or take a photo from the available video capture devices using COM interfaces; in the case of GETPIC, the resulting buffer is compressed</li><li>Input: &lt;GETLIST&gt; or &lt;GETPIC&gt; &lt;INDEX&gt;</li><li>Not chunked</li></ul></li><li>Command ID 26<ul><li>Runs a PE file in memory</li><li>Input: &lt;SIZE&gt;|&lt;EXPORT_NAME&gt;|&lt;ARGUMENT&gt;|&lt;MD5_OF_PE&gt;</li><li>Chunked</li></ul></li><li>Command ID 27<ul><li>Updates the config with data from the C2</li><li>Input: &lt;NEW_CONFIG_BYTES&gt;</li><li>Not chunked&nbsp;</li></ul></li></ul><h3>Indicators of compromise&nbsp;</h3>new Comebacker variants: 509fb00b9d6eaa74f54a3d1f092a161a095e5132d80cc9cc95c184d4e258525b&nbsp;&nbsp;b5eae8de6f5445e06b99eb8b0927f9abb9031519d772969bd13a7a0fb43ec067&nbsp;&nbsp;&nbsp;Service binary: 368769df7d319371073f33c29ad0097fbe48e805630cf961b6f00ab2ccddbb4c&nbsp;&nbsp;new BLINDINGCAN: c60587964a93b650f3442589b05e9010a262b927d9b60065afd8091ada7799fe&nbsp;C2s:&nbsp;&nbsp;hxxp[://]166[.]88[.]11[.]10/upload/check.asp&nbsp;hxxps[://]tronracing[.]com/upload/check.asp&nbsp;hxxp[://]23[.]27[.]140[.]49/Onenote/index.asp&nbsp;<h2>Conclusion&nbsp;</h2>Kimsuky and Lazarus continue to sharpen their tools, showing that DPRK-linked actors aren’t just maintaining their arsenals, they’re reinventing them. These campaigns demonstrate a well-structured and multi-stage infection chain, leveraging obfuscated payloads and stealthy persistence mechanisms. From the initial stages to the final backdoors, each component is designed to evade detection, maintain access and provide extensive control over the compromised system. The use of custom encryption, dynamic API resolution and COM-based task registration/services exploitation highlights the groups’ continued evolution and technical sophistication. Monitoring for these indicators and behaviors is essential for early detection and mitigation of such threats.&nbsp;By tracking every line of code and every new variant, we help surface the patterns that keep defenders one step ahead. Awareness, collaboration, and constant vigilance are what turn technical insights into real-world protection — and that’s where Gen Threat Labs and our global intelligence network can make a difference.&nbsp;&nbsp;

Technical walkthroughs of two DPRK intrusions: Kimsuky’s invoice-themed dropper to HttpTroy, and Lazarus’s Comebacker to BLINDINGCAN plus IOCs, TTPs, and mitigation steps 

DPRK’s Playbook: Kimsuky’s HttpTroy and Lazarus’s New BLINDINGCAN Variant 

Threat Research Team Lead

Sr Threat Analysis Engineer

Junior Threat Analyst Intern

Welcome to the era of VibeScams, where creating a phishing site takes just a few clicks. Using simple prompts, scammers can create nearly any type of website almost instantly, without any prior knowledge. Some web-building platforms recreate an entire site from a screenshot provided by the scammer – from a home page to a shopping cart. They typically also allow perfect language localization, letting scammers instantly clone a legitimate site’s look and feel in multiple languages.&nbsp;This new wave of AI-driven web building tools has dramatically lowered the barrier to entry for cybercriminals, democratizing access to sophisticated site cloning and scam operations. No longer limited to those with knowledge of HTML, CSS, and JavaScript, these platforms allow anyone with an internet connection to replicate trusted brands, banking portals, or exchange interfaces with alarming fidelity. The ease and speed of this process not only accelerate the proliferation of fraudulent websites but also makes it increasingly difficult for users to distinguish between genuine and malicious websites.&nbsp;&nbsp;<h2>A new kind of phishing — VibeScams&nbsp;</h2>We call them VibeScams because the trick isn’t in the code alone — it’s in the feeling. These pages pass the “vibe check”: the right colors, spacing, logo placement, and tiny footer links people trust at a glance. Because AI web builders can recreate that look from a single prompt or screenshot, attackers don’t need coding skills — they only need to get the vibe right. That’s enough to trick people into handing over credentials or cash, and it’s why this wave of scams spreads so fast.&nbsp;

As part of our research for this article, we contacted the web builders which attackers leverage more prevalently, according to our detections. We would like to share our appreciation for those companies, including Lovable, Elementor, Flazio, Softr, Webflow, WebWave, among others, for their fast reactions, quick banning of the websites, and overall cooperation. We would like to encourage anyone who stumbles upon suspicious or malicious websites to also report them to the specific providers. It matters and makes a difference.&nbsp;<h2>VibeScams as an Evolution of Phishing&nbsp;</h2>AI-powered web builders make it easy for anyone—even without coding or design skills—to create professional-looking websites quickly and cheaply. By automating templates, layouts, and even content, these tools lower barriers and speed up development, but they also give attackers the same advantages, enabling scams and phishing campaigns with minimal effort. The process of using such a web builder is so intuitive and user-friendly, it’s familiar to almost everyone. Individuals are typically presented with a simple screen containing a textbox, prompting users to immediately fill in a few lines of instructions to build their dream website. Below, you can find an example of a prompt screen from Lovable, one of the popular AI web building platforms:&nbsp;

AI chatbots always have been constrained in the space what the chatbot allows the user to prompt for. These security mechanisms, which are called “guardrails,” serve as a control system to detect malicious, harmful, or otherwise inappropriate prompts and block the associated responses. However, as we will see in the below examples of impersonating reputable brands, these mechanisms are frequently insufficient.&nbsp;As is typical with phishing and scams, attackers tend to focus on brands, topics or products that are already popular. Typical scam sites include cryptocurrency exchanges, investment portals, banking sites, social media platforms, delivery services, shopping sites and much more.&nbsp;Below, you can find a couple of examples of scam and phishing sites we observed hosted on many of these platforms, all AI generated. Other examples we discovered included MetaMask, DHL and AT&amp;T, among many others.&nbsp;&nbsp;

From cryptocurrency exchanges to fake e-shops and login pages, we’ve also seen other typical types of scams&nbsp; – such as tech-support scams. As can be seen below, in this case, it was recreated using an AI web builder and even localized into German. The attacker likely just uploaded a screenshot of a traditional scam page and asked the AI to rebuild and host it, making the whole process effortless.&nbsp;

While talking about brand impersonation, which is an attempt to mimic the design, logos, content, and URL of a well-known and respected brand, we’ve observed multitude of additional cases using AI web builders. This way the user is easily tricked into believing the website they visited is the official website of the brand. A few examples of brand impersonation of well-known crypto exchange platforms can be found below. Note that none of these are legitimate websites of known cryptocurrency exchanges or login sites for that matter, all of them are either phishing or otherwise scam websites:&nbsp;<ul><li>auth-binance.webflow[.]io</li><li>binance-cdn-auth.webflow[.]io</li><li>coinbase-wallet-verify.replit[.]app</li><li>coinbase-wallet.squarespace[.]com</li><li>auth-coinbase-login.typedream[.]app</li><li>chrome-coinbase-extension.typedream[.]app</li><li>wallet-coinbase.typedream[.]app</li><li>microsoft-teams-login.elementor[.]cloud</li><li>microsoft-outlookserver.odoo[.]com</li><li>cz-microsoft.webflow[.]io</li><li>updateaccount-microsoft.webflow[.]io&nbsp;</li></ul>

Typosquatting is very typical as well. This means the attackers are choosing similarly looking names, with one or more changed characters in the URL:&nbsp;<ul><li>app—trrezor-wallet.webflow[.]io</li><li>app-atomiic-wallet.webflow[.]io</li><li>coiinbase-com-wallet.typedream[.]app</li><li>connect-metamesk-wallet.typedream[.]app&nbsp;</li></ul>A broader list of IoCs can be found in our <a href="https://github.com/avast/ioc/tree/master/VibeScams" target="_blank" rel="noreferrer noopener">GitHub</a>.&nbsp;<h2>Scam Types – Breakdown&nbsp;</h2>Nearly half of the detected websites were traditional phishing pages impersonating familiar login portals like Microsoft, Gmail, or Amazon. About a quarter targeted the cryptocurrency space—either by mimicking popular exchanges such as Coinbase, Binance, and MetaMask, or by promoting cryptocurrency-based investment scams. The remainder included more general scams and other malicious pages.&nbsp;

<h2>Our Testing&nbsp;</h2>During our research, we took this opportunity to try a few web builders ourselves, to see how easy it actually is to create a website resembling known brands. We also used only free versions of the web builders to see what the baseline looks like.&nbsp;You can see our results in a few examples below:&nbsp;

In our opinion, the AI generated testing websites look fairly convincing and they took no money and almost zero effort to create. That’s because we didn’t want to kill the vibe, so we also created all the testing prompts using AI and simply copy and pasted them into the AI web builders. In most cases, we didn’t need any further prompting or tweaking.&nbsp;Note that what we generated here are only the designs. For phishing and scam sites to work properly, there also needs to be some functionality provided, for example credentials exfiltration. Additional functionality like this is commonly offered in paid subscriptions of the web builders, or the attacker can use once again other LLMs to implement this directly into the code because in a lot of cases they can download the design locally and continue the work from there.&nbsp;This demonstration directly showed us the core of why the attackers are using this – they don’t need to understand web at all to create highly believable websites for free (we only used free versions of the web builders).&nbsp;<h2>Pricing models&nbsp;</h2>In general, we consider these services to be cheap since there is quite a bit of competition and the user/attacker has plenty of choices to try, even for free. The fact that the attacker requires almost no skill to create a scam or phishing website highly outweighs the costs here.&nbsp;The range of paid offers is vast, spanning from $0.5 per month to $500 per month, with a variety of free tiers and/or trial periods. Some of the providers also offer lifetime deals for $249 or $599.&nbsp;Many of these subscriptions use a relatively common credits-based model where the customer receives credits which they can use for the AI prompts. Additional aspects, since many of the web builders also offer hosting for the generated webpages, are the website limit, subdomain name selection and the ability to change the subdomain name in the future.&nbsp;Finally, some of the web builders also offer APIs that can be used for streamlining the webpage creation, making the whole process more automatic.&nbsp;<h2>The Impact&nbsp;</h2>It’s important for defenders and analysts to recognize just how accessible and varied these platforms have become. Because the barrier to entry is so low and payment models are flexible, we’re seeing a rapid growth in the number of AI-generated scam and phishing websites. This massive availability means the attackers can quickly spin up new designs and relaunch new scams almost instantly.&nbsp;In total, we were investigating 40 different AI web builders, 12 of which we directly contacted due to a high volume of identified malicious websites. In total, from the beginning of 2025 to the end of August, we blocked approximately 140,000 different AI-generated websites during this time, which makes roughly 580 new malicious generated websites every day, on average.&nbsp;Since January 2025 alone, we protected nearly 190,000 our users, with the U.S., France, Brazil, Germany, and Japan among the most affected. This shows that misuse of AI web builders is a world-wide problem, and we can only expect the threat landscape to grow.&nbsp;

<h2>Conclusion&nbsp;</h2>During our research, we investigated various AI web builders which are being misused by attackers for performing what we call VibeScams – a creation of scam or phishing pages without the need of any knowledge of coding or web creation.&nbsp;AI web builders provide support for individuals who are not technically invested in creating websites, where a simple prompt can suffice for building a new website from scratch. This results in a double-edged sword where it is very useful for both regular users as well as for attackers, which is rather typical with other various AI tools, too.&nbsp;Many of the malicious webpages follow the expected pattern of brand impersonation for phishing attempts and scams, which our research has seen daily for many years. The difference is that with the AI web builders, the attackers need to invest little to no effort or knowledge into creating them. As the AI web builder ecosystem evolves, it’s clear that new features and easier integrations will fuel even more sophisticated phishing campaigns in the future.&nbsp;How to protect yourself:&nbsp;<ul><li>Always watch out for too good to be true offers or investment opportunities</li><li>When dealing with a known brand, always verify whether this is the official website</li><li>Look out for any deviations from the designs you are already familiar with</li><li>Use unique passwords and MFA everywhere, preferably along with a reputable password manager</li><li>Use a reputable AV solution to be proactively protected against phishing and scam attempts</li><li>When in doubt, use products like Norton 360 with AI-powered scam protection to consult the security of links and web pages&nbsp;</li></ul><h3>Indicators of Compromise (IoCs)&nbsp;</h3>A broader list of IoCs can be found on our <a href="https://github.com/avast/ioc/tree/master/VibeScams" target="_blank" rel="noreferrer noopener">GitHub</a>.&nbsp;auth-binance.webflow[.]io&nbsp; binance-cdn-auth.webflow[.]io&nbsp; coinbase-wallet-verify.replit[.]app&nbsp; coinbase-wallet.squarespace[.]com&nbsp; auth-coinbase-login.typedream[.]app&nbsp; chrome-coinbase-extension.typedream[.]app&nbsp; wallet-coinbase.typedream[.]app&nbsp; microsoft-teams-login.elementor[.]cloud&nbsp; microsoft-outlookserver.odoo[.]com&nbsp; cz-microsoft.webflow[.]io&nbsp; updateaccount-microsoft.webflow[.]io&nbsp; app—trrezor-wallet.webflow[.]io&nbsp; app-atomiic-wallet.webflow[.]io&nbsp; coiinbase-com-wallet.typedream[.]app&nbsp; connect-metamesk-wallet.typedream[.]app&nbsp;

AI web builders are fueling a surge in realistic phishing sites that anyone can make

VibeScams: How AI website builders are shaping the internet 

Malware Analyst at Gen

In the ever-evolving landscape of cyber threats, a new ransomware strain known as Midnight has emerged, echoing the notorious tactics of its predecessor, Babuk. First detected by Gen researchers, Midnight blends familiar ransomware mechanics with novel cryptographic modifications – some of which unintentionally open the door to file recovery. This blog dives into the technical anatomy of Midnight, its lineage from Babuk, and the critical indicators of infection. Most importantly, it offers a practical guide to decrypting affected files, empowering victims with a rare opportunity to reclaim their data without paying a ransom.

<h2>Midnight’s Discovery and Roots&nbsp;</h2>Gen researchers have identified a new ransomware strain, internally dubbed Midnight. It shows clear signs of being inspired by the Babuk ransomware family, which first appeared in early 2021 and quickly gained a reputation for its aggressive tactics and advanced technical aspects. Babuk operated as a Ransomware-as-a-Service (RaaS), targeting large organizations across healthcare, finance, government, and other critical infrastructure. The ransomware used strong encryption (HC256 and ECDH) and intermittent file encryption to maximize damage while maintaining speed.&nbsp;In mid-2021, Babuk's operators abruptly shut down and leaked their full source code, including builders for Windows, ESXI and NAS variants. This leak led to a wave of inspired ransomware families, each modifying Babuk's original design to suit their own goals.&nbsp;Midnight is one such evolution. While it retains much of Babuk's core structure, its authors introduced several changes - most notably in the cryptographic scheme used for file encryption. These changes, while likely intended to improve the ransomware's effectiveness, inadvertently introduced weaknesses that make file decryption possible under certain conditions.&nbsp;<h2>How to Recognize Midnight Ransomware&nbsp;</h2>Midnight ransomware typically appends the .Midnight or .endpoint extension to encrypted files. In some cases, the ransomware is configured not to modify the file names. Instead, it appends the extension string directly to the end of the file content. This behavior can be observed in hex dumps and may affect file parsing.&nbsp;

A ransom note named How To Restore Your Files.txt is dropped in the affected directories. It may look similar as on the following screenshots:&nbsp;

Additional indicators include the creation of a mutex named Mutexisfunnylocal, which is used to prevent multiple instances of the ransomware from running simultaneously. Some samples also drop a debug log on the infected system, depending on the configuration. Known variants have been observed creating either Report.Midnight or debug.endpoint as log files.&nbsp;A full list of discovered samples is available in the IoCs section at the end of this article.&nbsp;<h3>Cryptographic Design and Flaws&nbsp;</h3>While Midnight's core structure and execution flow is largely inherited from Babuk, its cryptographic implementation has been significantly reworked. These changes introduced flaws that make file decryption possible, which we leveraged to develop a working decryptor.&nbsp;Midnight uses ChaCha20 for encrypting file contents and RSA for encrypting the ChaCha20 key. The RSA-encrypted key, along with its SHA256 hash, is appended to the end of each encrypted file. This format is consistent across known samples.&nbsp;To improve performance, Midnight employs intermittent encryption, a technique also used by Babuk. However, Midnight refines this approach by applying a more granular file size-based logic to determine which portions of file to encrypt. This allows it to process large files faster while still rendering them unusable.&nbsp;The ransomware accepts several command-line arguments to control its behavior:&nbsp;<ul><li>/e appends the extension string (e.g. .Midnight) directly to the file content instead of modifying the filename.</li><li>/n enables encryption of network-mounted volumes.</li><li>--paths=PATHS targets specific directories for encryption.&nbsp;</li></ul>Earlier samples of Midnight primarily targeted high-value files such as databases, backups, and archives. These included the following extensions:&nbsp;.mdf .ndf .bak .dbf .dmp .rman .frm &nbsp; .ibd .myd .myi .sql .xbk .ldf .vbi &nbsp; .vbk .ibdata .rar .md5 and .bitmap&nbsp; &nbsp;More recent variants have broadened their scope and now encrypt nearly all file types, with the exception of executables such as .exe, .dll, and .msi.&nbsp;<h2>How to Use the Ransomware Decryptor&nbsp;</h2><ol><li>Download the decryptor <a href="https://files.avast.com/files/decryptor/norton/norton_decryptor_midnight64.exe" target="_blank" rel="noreferrer noopener">here</a>. If you still use 32-bit Windows, you can also get the 32-bit version of the decryptor <a href="https://files.avast.com/files/decryptor/norton/norton_decryptor_midnight.exe" target="_blank" rel="noreferrer noopener">here</a>.</li><li>Run the decryptor, preferably as an administrator. It starts as a wizard, leading you through the configuration of the decryption process.</li><li>On the initial page, we have a link to the license information. Click the Next button when you are ready to start.</li></ol>

4. &nbsp; &nbsp; On the next page, the user is asked to provide a list of locations (drives, folders, files) that are to be decrypted. &nbsp; &nbsp; &nbsp; &nbsp; By default, the decryptor provides a list of all local disk drives.

5. &nbsp; &nbsp; On the final page, you can opt-in to back up your encrypted files. These backups may help if anything goes wrong during the decryption process. This option is selected by default, which we recommend. After clicking Decrypt, the decryption process begins. Let the decryptor work and wait until it finishes decrypting all of your files.

For questions or comments about the Norton decryptor, email <a href="mailto:decryptors@avast.com" target="_blank" rel="noreferrer noopener">decryptors@avast.com</a>.&nbsp;<h3>IoCs: Ransomware Samples&nbsp;</h3>dd9de77c6e17093b0b2150b3f0c66e8526369ba68fb7b9a5758ff9274d85342e&nbsp; 3d9a71cfec82fef531227465f40d9106e671ef162fa3ab21119e2ee08612e0aa&nbsp; 300c46bf17e8bd0cd5ac800a33e1d27ef9001aecef1f98965414bf9c33af19e0&nbsp; 1e58448808006de410ddb31a4d6ff8292aa70168f69f2b7e08144d6090d5084d&nbsp; aa8a043fd3d64fc96864cf5361bbb82012cc4b2e1a909c747038edcf2b4369e7&nbsp;&nbsp;

Midnight ransomware echoes Babuk’s tactics but stumbles in its code. Gen researchers explain how those mistakes make decryption and recovery possible

Decrypted: Midnight Ransomware 

Malware Researcher at Gen

Researchers at Avast developed a decryptor for the FunkSec ransomware. We have been cooperating with law-enforcement agencies to help victims decrypt files for free. Because the ransomware is now considered dead, we released the decryptor for public download.&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<a href="https://files.avast.com/files/decryptor/avast_decryptor_funksec64.exe" target="_blank" title="Download the Decryptor">Skip directly to the decryptor download</a>&nbsp;We counted 113 victims of the ransomware in total (based on the ransomware leak site). Because the first victim appeared earlier than the initial source, we assume that the FunkSec gang only did data exfiltration and subsequent extortion from the beginning, and then also added data encryption. Here’s a simple timeline of the ransomware operations:&nbsp;<ul><li>04-Dec-2024: The first victims appeared on the ransomware gang’s leak site&nbsp;</li><li>15-Dec-2024: The initial source file was uploaded to Virus Total&nbsp;</li><li>31-Dec-2024: The first known ransomware sample was uploaded to Virus Total&nbsp;</li><li>15-Mar-2025: The latest known victim&nbsp;</li></ul><h2 class="text-align-justify">AI-Powered Ransomware&nbsp;</h2><a href="https://www.ransomlook.io/groups#Funksec" target="_blank" rel="noreferrer noopener">Sources</a> report that AI was used to assist in writing this ransomware. Notably, the authors used AI to create tools and phishing templates, though they emphasize that AI contributes to only about 20% of their operations.&nbsp;Overall, samples of the ransomware mostly fail to work. Some of them depend on external image (supposed to become a desktop wallpaper) downloaded from <a href="https://imgur.com/" target="_blank" rel="noreferrer noopener">Imgur</a>:&nbsp;<ul><li>hxxps[:]//i.imgur.com/HCYQoVR.jpeg</li><li>hxxps[:]//i.imgur.com/mlUvWYT.jpeg&nbsp;</li></ul><h2>How to Recognize FunkSec Ransomware&nbsp;</h2>Files encrypted with FunkSec ransomware have the “.funksec” extension:&nbsp;

Also, a ransom note file called “README-{random}.md” is dropped to every folder.

<h2>FunkSec Ransomware Analysis</h2>Ransomware is written in Rust programming language. For cryptographic operations, it uses orion-rs library, <a href="https://github.com/orion-rs/orion/releases/tag/0.17.7">version 0.17.7</a>. Files are encrypted using Chacha20 with the help of <a href="https://github.com/openssl/openssl/blob/master/crypto/poly1305/poly1305.c">Poly1305 MAC</a>. This hash-based method ensures integrity of encryption parameters: the encryption key, n-once, block lengths, and encrypted data itself.Files are encrypted per-blocks of 128 bytes, adding 48 bytes of extra metadata to each block, which means that encrypted files are about 37% bigger than the originals.When executed, the ransomware searches all local drives (by drive letter) and encrypts all files, except the ones with these extensions:<table class="table"><tbody><tr><td>&nbsp;.7z&nbsp; &nbsp; &nbsp; .aac&nbsp; &nbsp; &nbsp;.ai&nbsp; &nbsp; &nbsp; .apk&nbsp; &nbsp; &nbsp;.avi&nbsp; &nbsp; &nbsp;.avro&nbsp; &nbsp; .azw3&nbsp; &nbsp; .bak&nbsp; &nbsp; &nbsp;.bat.bib&nbsp; &nbsp; &nbsp;.bin&nbsp; &nbsp; &nbsp;.bkp&nbsp; &nbsp; &nbsp;.c&nbsp; &nbsp; &nbsp; &nbsp;.cer&nbsp; &nbsp; &nbsp;.chm&nbsp; &nbsp; &nbsp;.cpp&nbsp; &nbsp; &nbsp;.csr&nbsp; &nbsp; &nbsp;.css.csv&nbsp; &nbsp; &nbsp;.cue&nbsp; &nbsp; &nbsp;.dat&nbsp; &nbsp; &nbsp;.db&nbsp; &nbsp; &nbsp; .dbf&nbsp; &nbsp; &nbsp;.deb&nbsp; &nbsp; &nbsp;.djvu&nbsp; &nbsp; .dll&nbsp; &nbsp; &nbsp;.dmg.docx&nbsp; &nbsp; .dwg&nbsp; &nbsp; &nbsp;.dxf&nbsp; &nbsp; &nbsp;.ear&nbsp; &nbsp; &nbsp;.eml&nbsp; &nbsp; &nbsp;.eps&nbsp; &nbsp; &nbsp;.epub&nbsp; &nbsp; .etl&nbsp; &nbsp; &nbsp;.exe.fb2&nbsp; &nbsp; &nbsp;.fla&nbsp; &nbsp; &nbsp;.flac&nbsp; &nbsp; .flv&nbsp; &nbsp; &nbsp;.git&nbsp; &nbsp; &nbsp;.gpg&nbsp; &nbsp; &nbsp;.hdf5&nbsp; &nbsp; .html&nbsp; &nbsp; .indd.ini&nbsp; &nbsp; &nbsp;.ipa&nbsp; &nbsp; &nbsp;.iso&nbsp; &nbsp; &nbsp;.jar&nbsp; &nbsp; &nbsp;.java&nbsp; &nbsp; .js&nbsp; &nbsp; &nbsp; .json&nbsp; &nbsp; .jsx&nbsp; &nbsp; &nbsp;.kdbx.key&nbsp; &nbsp; &nbsp;.log&nbsp; &nbsp; &nbsp;.lst&nbsp; &nbsp; &nbsp;.m3u&nbsp; &nbsp; &nbsp;.md&nbsp; &nbsp; &nbsp; .mdb&nbsp; &nbsp; &nbsp;.midi&nbsp; &nbsp; .mkv&nbsp; &nbsp; &nbsp;.mov.mp3&nbsp; &nbsp; &nbsp;.mp4&nbsp; &nbsp; &nbsp;.msg&nbsp; &nbsp; &nbsp;.msi&nbsp; &nbsp; &nbsp;.nfs&nbsp; &nbsp; &nbsp;.odp&nbsp; &nbsp; &nbsp;.ods&nbsp; &nbsp; &nbsp;.odt&nbsp; &nbsp; &nbsp;.ogg.opf&nbsp; &nbsp; &nbsp;.parquet .pdb&nbsp; &nbsp; &nbsp;.pdf&nbsp; &nbsp; &nbsp;.pem&nbsp; &nbsp; &nbsp;.pfx&nbsp; &nbsp; &nbsp;.pgp&nbsp; &nbsp; &nbsp;.php&nbsp; &nbsp; &nbsp;.pptx.ps&nbsp; &nbsp; &nbsp; .psd&nbsp; &nbsp; &nbsp;.py&nbsp; &nbsp; &nbsp; .rar&nbsp; &nbsp; &nbsp;.raw&nbsp; &nbsp; &nbsp;.rpm&nbsp; &nbsp; &nbsp;.rtf&nbsp; &nbsp; &nbsp;.sh&nbsp; &nbsp; &nbsp; .sql.sqlite&nbsp; .svg&nbsp; &nbsp; &nbsp;.svn&nbsp; &nbsp; &nbsp;.tar&nbsp; &nbsp; &nbsp;.tar.gz&nbsp; .tex&nbsp; &nbsp; &nbsp;.tgz&nbsp; &nbsp; &nbsp;.tiff&nbsp; &nbsp; .ts.tsx&nbsp; &nbsp; &nbsp;.txt&nbsp; &nbsp; &nbsp;.vcs&nbsp; &nbsp; &nbsp;.vhd&nbsp; &nbsp; &nbsp;.vmdk&nbsp; &nbsp; .war&nbsp; &nbsp; &nbsp;.wav&nbsp; &nbsp; &nbsp;.webm&nbsp; &nbsp; .wma.xlsx&nbsp; &nbsp; .xml&nbsp; &nbsp; &nbsp;.xps&nbsp; &nbsp; &nbsp;.xz&nbsp; &nbsp; &nbsp; .yaml&nbsp; &nbsp; .zip&nbsp;</td></tr></tbody></table>

The following processes and services are killed before the ransomware starts the file encryption:<table class="table"><tbody><tr><td>&nbsp;chrome.exe&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; firefox.exe&nbsp; &nbsp; &nbsp;&nbsp; &nbsp; msedge.exe&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; explorer.exeoutlook.exe&nbsp; &nbsp; &nbsp;&nbsp; &nbsp; vlc.exe&nbsp; &nbsp; &nbsp; &nbsp; &nbsp;&nbsp; &nbsp; spotify.exe&nbsp; &nbsp; &nbsp;&nbsp; &nbsp; skype.exediscord.exe&nbsp; &nbsp; &nbsp;&nbsp; &nbsp; steam.exe&nbsp; &nbsp; &nbsp; &nbsp;&nbsp; &nbsp; java.exe&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; python.exenode.exe&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; cmd.exe&nbsp; &nbsp; &nbsp; &nbsp; &nbsp;&nbsp; &nbsp; powershell.exe&nbsp; &nbsp; &nbsp; taskmgr.exewmplayer.exe&nbsp; &nbsp; &nbsp; &nbsp; tscon.exe&nbsp; &nbsp; &nbsp; &nbsp;&nbsp; &nbsp; notepad.exe&nbsp;</td></tr><tr><td>spooler&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;bits&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; dnsclient&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; lanmanworkstationwinmgmt&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;netsh&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;iphlpsvc&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;servicesRemoteAccess&nbsp; &nbsp; &nbsp; &nbsp; ShellHWDetection&nbsp; &nbsp; SCardSvr&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;TrkWkswscsvc&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; CryptSvc&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; msiserver&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; MpsSvcdefragsvc&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;upnphost&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; WindowsUpdate&nbsp; &nbsp; &nbsp; &nbsp; srservicewsmprovhost&nbsp; &nbsp; &nbsp; &nbsp; &nbsp;AppIDSvc&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; AudioEndpointBuilder Scheduleeventlog&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; PlugPlay&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; Netman&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;bthservShellExperienceHost SMB&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;WinDefend&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; wuauserv&nbsp;</td></tr></tbody></table>

<h2>How to Use the Ransomware Decryptor</h2><ol><li>The first step is to download the decryptor binary. Avast provides a <a href="https://files.avast.com/files/decryptor/avast_decryptor_funksec64.exe">64-bit decryptor</a>, as the ransomware is also 64-bit and can’t run on 32-bit Windows. If you have no choice but to use 32-bit applications, you may download a 32-bit decryptor <a href="https://files.avast.com/files/decryptor/avast_decryptor_funksec.exe">here</a>.</li><li>Run the executable file, preferably as administrator. It starts as a wizard, leading you through the decryption process.</li><li>On the initial page, we have a link to the license information. Click the Next button when you are ready to start. &nbsp;</li></ol>

4. On the next page, select the list of locations you want to be searched for and decrypted. By default, it has a list of all local drives, but you can pick a different list, such as a directory with important documents:

5. On the final page, you can opt-in to back up your encrypted files. These backups may help if anything goes wrong during the decryption process. This choice is selected by default, which we recommend. After clicking Decrypt, the decryption process begins. Let the decryptor work and wait until it finishes decrypting all your files.

For questions or comments about the Avast decryptor, email <a href="mailto:decryptors@avast.com">decryptors@avast.com</a>.<h2>IOCs</h2>Ransomware samplec233aec7917cf34294c19dd60ff79a6e0fac5ed6f0cb57af98013c08201a7a1c &nbsp;Initial source code7e223a685d5324491bcacf3127869f9f3ec5d5100c5e7cb5af45a227e6ab4603&nbsp;

Avast releases free decryptor for AI-assisted FunkSec ransomware

Decrypted: FunkSec Ransomware 

A recent investigation into Neptune RAT unexpectedly uncovered notable overlaps with the notorious remote access trojan, XWORM. Given XWORM’s recent surge in popularity, this discovery prompted a deeper analysis, revealing several intriguing connections between the two malware families. This similarity was also reflected in various OSINT sources, where samples of Neptune RAT triggered detections originally developed for XWORM.

<h2>Neptune RAT</h2>Based on research from <a href="https://www.cyfirma.com/research/neptune-rat-an-advanced-windows-rat-with-system-destruction-capabilities-and-password-exfiltration-from-270-applications/">Cyfima</a>, we identified several GitHub repositories that helped us partially reconstruct the development history of Neptune RAT. Currently, there are at least two major distinct versions. The older version, which we’ll refer to as V1, has been linked to the campaign under investigation.<h3>Neptune RAT V1</h3>We discovered a GitHub repository that appears to be a fork of the original builder for Neptune RAT. Because the original repository is named MasonGroup/NeptuneRatV1, we’ll designate this version as V1. The repository contains commits exclusively from a user named "Freemasonry," with the initial commit and most activity dating back to early December 2024, before activity abruptly ceased. Additionally, the repository references a Discord server called FreemasonryTM.Notably, the builder’s user interface differs significantly from the typical UI seen in XWORM’s builder:

Despite the obvious differences in design and appearance, the codebases reveal a striking similarity. Both XWORM and Neptune RAT share a similar approach to initialization: they load all configuration settings at the start of their respective main functions and then launch executor threads to carry out their tasks.

These values are stored in a single class containing static strings. Except for the mutex, all strings are AES-encrypted and Base64-encoded, a common practice among .NET RATs. What’s unusual, however, is that both XWORM and Neptune RAT V1 use the exact same encryption routine: the mutex is hashed using MD5, and the hash is duplicated to form a 32-byte key used for AES encryption running in the insecure ECB mode. Because of this shared method, Neptune RAT V1 configurations were mistakenly conflated with XWORM’s configurations in our tracking systems.The similarities don’t end there. Both malware families implement persistence using three methods: Task Scheduler, registry entries and the startup folder. The resemblance is especially striking in the first and third approaches:

These similarities extend to their scope as well. Both malware families use identical regular expressions and target the same cryptocurrencies: BTC, ETH and TRC. Notably, although Neptune RAT V1 appears to be a recent variant, it only targets legacy Bitcoin addresses and largely ignores newer standards like Bech32 (BIP-0173, introduced in 2017). The reuse of identical regular expressions and wallet-targeting patterns further reinforces the likelihood that Neptune RAT V1 is derived from XWORM rather than being developed independently.We also examined other popular RATs such as njRAT and AsyncRAT. Their initialization processes and workflows differ significantly, and their structures and implementations do not share these specific patterns. Based on this, we conclude that the similarities between Neptune RAT V1 and XWORM are unlikely coincidental, Neptune RAT V1 is most likely a derivative of XWORM.

<h3>Neptune RAT V2</h3>We also identified another repository, forked from MasonGroup/NeptuneRAT and named NeptuneRatV2, which contains a trial version of a new builder that we’ll refer to as V2. Its initial commit dates to February 22, 2025, with GitHub showing ongoing development in the original, now-private repository. While the V2 builder’s UI appears to be a reskinned and more polished version of V1, the underlying code has undergone significant changes, suggesting either a complete rewrite or an extensive refactoring.

Neptune RAT V2 shows a drastic departure from V1. While V1 completed configuration initialization within the main function, V2 follows a completely different code flow. Unlike V1, variable names in V2 are not obfuscated, and the configuration data is stored as plain strings in the Settings class rather than being AES-encrypted. This unencrypted approach is consistent across both trial and production builds.

<h2>Conclusion</h2>We identified Neptune RAT configurations within our historical XWORM tracking data, which prompted the hypothesis that these two malware strains might be linked. OSINT investigations uncovered some tentative connections, including forks of the MasonGroup/NeptuneRatV1 repository. Although the original repository is no longer accessible, these forks contained code heavily overlapping with XWORM. Notably, the current Neptune RAT builder references the Freemasonry group, aligning with the Discord server identified in our research.Reverse engineering Neptune RAT V1 revealed further compelling similarities. While the shared resource structure might be dismissed as a coincidence, given that many .NET RATs use similar frameworks, the resource encryption scheme is essentially identical in both: AES encryption in insecure ECB mode combined with the same key-derivation method using a hard-coded mutex. Their persistence mechanisms are also functionally and structurally alike. Additionally, the clipper functionality employs the same regular expressions and targets the same cryptocurrencies. Although these expressions focus on legacy Bitcoin addresses rather than newer standards like Bech32, this link is somewhat weak given the widespread use of these expressions in malware.The strong similarities between XWORM and Neptune RAT V1, contrasted with their clear divergence from other open-source RATs, strongly suggest that Neptune RAT V1 is related to XWORM. However, these parallels do not extend to Neptune RAT V2, whose trial version, while functionally similar to V1, appears to be a complete code rewrite.<h2>List of SHA256S&nbsp;</h2><h3>XWORM:&nbsp;</h3>8dd992c363c594b80d10cbc9bc2b26ca8211f88bb12636f98a82627b847cbdae&nbsp;d3ad9240d2abdb9c43e37f546b2420f0a3890742133453650de1b012b4f4a11&nbsp;3283c0031175ae5d68e7cb81d069b40e9c028fa680d19fd34019daad3b2d4828&nbsp;<h3>Neptune V1 RAT&nbsp;</h3>f2c0ee24b7eb590e8caca3abeccd2cf73cdb4cc719e0828062ea50d9484303d5&nbsp;5b27e4bc78e05c098cd97da75f4d4df100039bdb71f6f16da99ae6b9e60a878c&nbsp;<h3>Neptune V2 RAT&nbsp;</h3>be1e0ca3b58139a64fd3cb0127a63b21ffd76721800a55f8ff16479303e8e4a2&nbsp;eac5e8915cd2be4629a5eb02cce0c26c0dd224a3cdef8bcd27b7c28b3fb36dd1&nbsp;3ff3722127d97b03fb866ee6f6c4ca9782b6cc162bd8684cec08425f56d5507f&nbsp;

A closer look at Neptune RAT V1 reveals shared code, persistence methods and encryption patterns with XWORM, suggesting a common origin

Neptune and the legacy of XWORM

Principal Research Engineer

Large language models (LLMs) are everywhere. Since OpenAI’s ChatGPT burst onto the scene a few years ago, these tools have completely reshaped how we search, ask questions and navigate the web. They have quickly woven themselves into our daily routines, helping us build grocery lists, find restaurant recommendations and even plan entire vacations.&nbsp;And all of this? It seems to come at no cost. Just create an account and start using platforms like ChatGPT (OpenAI), Gemini (Google) or DeepSeek. But that leads us to an important question: are these tools truly free? And if not, what is the real price we are paying?&nbsp;To find out, we dug into the privacy policies of the top AI platforms, so you do not have to. Here is what we uncovered about the actual cost of using today’s most popular LLMs.&nbsp;<h2>Privacy by design, and other nice stories&nbsp;</h2>Let’s walk through a familiar scenario: planning your next vacation. Like many of us, you want the perfect destination, at the perfect time, all within a specific budget. That means searching for cheap flights, affordable hotels and ideally, something close to the city center that still feels like a getaway.&nbsp;In the past, you might have spent hours, or days, browsing search engines, comparing options, reading reviews and hunting for deals. It is time-consuming and, frankly, a bit overwhelming.&nbsp;But now? Who has time for all that? More importantly – why bother when your friendly AI assistant can handle it for you? All you need to do is head to your favorite large language model and type in a well-crafted prompt:&nbsp;“Hello, I want to go for vacation on august somewhere sunny. I would like a beautiful island somewhere in the Mediterranean Sea with plenty of activities and tasty food. I do not want it to be too crowded and not extremely expensive. Find me also flights from Oslo to this destination that are cheap or tell me which dates I should look for. Finally, find me a nice hotel 3 stars and above with a room for 2 adults and 2 kids. Find something that is bellow 150 euros per day with availability for 6 days, please.”&nbsp;With a prompt like that, the model gets to work. Within seconds, it returns tailored recommendations that check all your boxes. Even better? It might offer to book the flights and hotel for you – asking for your credit card and passport details so you don’t have to lift a finger. Just sit back, relax and dream of sun-drenched beaches.&nbsp;You may even notice a few quick notifications as the system says things like “memory updated”, but nothing else seems to change, so no need to worry… right?&nbsp;Let’s take a moment to unpack what happened behind the scenes.&nbsp;When we typed our prompt, the model did not just give us a list of results – it broke down our request into smaller, more specific queries. It recognized that we are planning a vacation, live in Oslo, have a partner and two kids, prefer nice hotels, and are working with a budget of €150 per night. Piece by piece, it started building a profile of who we are and what we like.&nbsp;That profile does not just disappear. It is often stored, somewhere.&nbsp;&nbsp;And if we take a closer look at the privacy policies of major AI providers, we start to see how that information can be used. So, let’s break it down: what exactly is being collected, and how is it being used?&nbsp;<h2>ChatGPT by OpenAI&nbsp;</h2>Let’s start with the elephant in the room: OpenAI, the most popular and widely used large language model provider.&nbsp;According to its privacy policy, OpenAI collects a wide range of personal data. This includes:&nbsp;<ul><li>Account information&nbsp;</li><li>User content (everything you type)&nbsp;</li><li>Communication details&nbsp;</li><li>Other information you voluntarily provide&nbsp;</li><li>Log data and usage patterns&nbsp;</li><li>Device and location data&nbsp;</li><li>Cookies and similar tracking technologies&nbsp;</li><li>Information received from third-party sources&nbsp;</li></ul>In short: it is not just your prompts that are being collected. It is your device, your location, how you interact with the model and even data that can be bought or received from other sources.&nbsp;But what is even more important than what is collected is how it is used. OpenAI states that this data helps them “provide, analyze and maintain” their services, “improve and develop” new features, “communicate with users” and “prevent misuse or fraud.” All of which sound standard, until you read the fine print about data sharing.&nbsp;&nbsp;According to the policy, OpenAI may share your information, with broad discretion, for purposes such as:&nbsp;<ul><li>Strategic transactions (e.g., mergers or acquisitions)&nbsp;</li><li>Business operations&nbsp;</li><li>Legal compliance&nbsp;</li><li>And more vaguely, with “affiliates”&nbsp;</li></ul>So, what does this mean in practice?&nbsp;Once you provide your data, it is no longer truly yours. It can be used to train future models, shared with business partners or even leveraged in a corporate acquisition. And the kicker? This applies whether you are a free user or a paying subscriber.&nbsp;&nbsp;Your data powers the system, but it does not belong to you anymore.&nbsp;<h2>Gemini by Google&nbsp;</h2>Next, let’s look at how the most popular search engine’s AI model, Gemini by Google, handles user privacy. Unsurprisingly, the situation is very similar to what we saw with OpenAI.&nbsp;Gemini collects not just your chats and interactions, but also any files, images or browser page content you share. It logs your location, IP address, submitted feedback and even physical addresses, like home or work, if they are part of your input.&nbsp;When it comes to how this data is used, the language is broad and vague. Google states that your data helps them “provide, improve, develop and personalize” their services and machine learning technologies. But if you dig deeper into their multi-layered privacy policy, a clearer picture emerges: your personal information can also be used for targeted advertising and to make recommendations for other Google products.&nbsp;And it gets more concerning.&nbsp;Google explicitly warns users not to share personal or confidential data in Gemini chats. Why? Because human reviewers, known as annotators, may read your conversations, access your files and use that data to improve future model performance. So, not only does your data no longer belong to you; it may also be read and evaluated by actual people.&nbsp;&nbsp;Once again, it does not matter whether you are a free user or a paid subscriber. The privacy terms apply across the board. From the moment you interact with Gemini, your data becomes part of its ecosystem.&nbsp;<h2>DeepSeek: The new kid on the block&nbsp;</h2>Finally, we reviewed the privacy policy of DeepSeek, a platform that gained major traction last year after claiming OpenAI-level performance with just a fraction of the resources. It quickly rose in popularity, eventually topping Apple’s App Store charts.&nbsp;DeepSeek’s privacy policy appears standard. They collect personal data associated with your account, your input and any details you provide when contacting them. But as with the other major players, a deeper dive reveals a long list of data points they track device model, IP address, identifiers, location, cookies, payment details, text inputs, uploaded files, chat history, user age, contact information and more.&nbsp;Where things get even more concerning is where your data goes.&nbsp;Unlike OpenAI or Google, DeepSeek transfers user data from Europe and the U.S. to servers in China, placing it under Chinese authority. This means your information is no longer protected by EU or U.S. privacy laws. According to Chinese regulations, the government may access or request user data at any time, for any reason – with little transparency or recourse.&nbsp;As for how the data is used, the story remains familiar. DeepSeek claims your information helps them improve, develop and train their models, whether by feeding prompts directly into training datasets or by analyzing usage patterns. They also cite compliance with legal obligations and protecting the “interests of users and others”, though who those “others” are is never clearly defined.&nbsp;&nbsp;And, of course, they reserve the right to share your personal data with third-party partners who help operate or develop their services.&nbsp;The bottom line? No matter which platform you choose, your data stops being just yours the moment you use the service.&nbsp;<h2>How privacy has changed&nbsp;</h2>Some might argue that privacy concerns are not new, we have been sharing data online long before large language models (LLMs) took over. After all, even planning a vacation used to involve multiple search queries typed into our favorite search engine. So, what is the difference?&nbsp;That argument seems fair. But there is a key distinction.&nbsp;Before LLMs, we were in control. Searching for cheap flights or hotel deals meant navigating between websites of our choosing. We could decide which platforms to interact with, and, at least to some extent, who saw our data. Tools like <a href="https://us.norton.com/products/norton-antitrack" target="_blank" rel="noreferrer noopener">Norton AntiTrack</a> made it possible to keep trackers at bay, allowing us to interact directly with service providers while limiting what the search engine itself could collect.&nbsp;Now, that dynamic has shifted.&nbsp;When we use LLMs, the model is not just answering a question, it is becoming the gateway to everything. It decides which services to show, which sources to pull from and how to summarize or filter the information. You no longer browse freely; you are handed a curated response. And in the process, the LLM provider sees everything, from your preferences and prompts to your files, location and interactions.&nbsp;Even more troubling? You cannot always tell which sources were used or whether the results are truly in your best interest.&nbsp;So, does this mean privacy is a lost game in the age of LLMs?&nbsp;The answer is not simple.&nbsp;<h2>Countermeasures&nbsp;</h2>Unfortunately, there is no silver bullet when it comes to protecting your privacy while using large language models. But that does not mean you are completely powerless; there are a few settings and habits that can help minimize your data exposure. Let’s take a closer look at what is possible, starting with the most popular platform:<h3>ChatGPT by OpenAI&nbsp;</h3>In OpenAI’s ChatGPT, privacy-conscious users can adjust a few settings to gain more control over how their data is used. To access them, click on your avatar in the top right corner and open Settings. From there, navigate to the Data Controls tab, where you can toggle off “Improve the model for everyone.” This setting tells OpenAI not to use your chats to train future models.&nbsp;You can also visit the Personalization tab and disable memory features to stop the model from saving and recalling information about you. If you are curious about what the model has already learned, click “Manage Memories” to review and delete anything it has inferred.&nbsp;Keep in mind, disabling memory means a less personalized experience, so you may receive less accurate or relevant responses to your prompts. And unfortunately, this does not mean you are fully in the clear: even with all settings turned off, the personal and sensitive information you share may still be collected and stored by OpenAI.&nbsp;Bottom line: these settings offer a degree of control, but not full privacy.&nbsp;<h3>Gemini by Google&nbsp;</h3>With Gemini, your options to control privacy are a bit more limited. The main setting available is found by clicking on Activity in the bottom left panel, where you can disable it. However, this does not mean your data will not be stored or processed, it only means that human reviewers will not inspect the information you share.&nbsp;Gemini’s privacy policy does not explicitly say whether your data is still used to train models without human review, so it remains unclear if your chats contribute to future model training behind the scenes.&nbsp;Unlike ChatGPT, Gemini does not automatically infer information about you. Instead, the model only learns personal details if you explicitly provide them. If you want to delete stored information, you can either switch off Activity altogether or delete entries individually within the same tab.&nbsp;Still, there is no true way to avoid sharing data with Google, and once you share your information, it no longer belongs to you.&nbsp;<h3>DeepSeek&nbsp;</h3>The situation with DeepSeek is a bit grimmer. If you click the bottom left corner and then go to Settings, you will find the Profile tab. Here, the only privacy control available is the option to switch off “Improve model for everyone.”&nbsp;DeepSeek claims that they do not use your content to train their models if you disable this setting, but beyond that, their policy is vague and unclear. What is clear, however, is that once you share your data, it no longer truly belongs to you.&nbsp;<h2>What does the future bring?&nbsp;</h2>AI-powered services like these are here to stay, and they simply cannot operate without the vast amounts of data generated by their users. For now, there are few regulations or safeguards to limit how this data is collected, stored or used, which means privacy is taking a backseat.&nbsp;Until stronger protections are put in place, the responsibility falls on users to safeguard their own sensitive information. That means sharing as little personal data as possible, especially when planning something like a vacation. Otherwise, you might just find your itinerary showing up in someone else’s AI-generated recommendations in the next version of the model you use.&nbsp;The future of privacy in AI is not set in stone yet. But one thing is certain: staying informed and cautious is your best defence.&nbsp;

We dug into the fine print, so you do not have to – here is what ChatGPT, Gemini and DeepSeek are really doing with your prompts

I know what you are doing this summer: What AI knows about you

While conducting routine clipboard monitoring, our team uncovered a sophisticated attack chain masquerading as an official NVIDIA-related update. What initially appeared to be a hiring assessment challenge quickly revealed itself to be a cleverly disguised lure.&nbsp;<h2>The deceptive journey&nbsp;</h2>The attack begins with a prompt to complete a mock interview form, followed by a page instructing users to set up their camera. This page falsely claims there are issues with the user's webcam or microphone, adding a layer of urgency and credibility to the ruse.

A pop-up then urges users to “Request camera access,” which triggers a seemingly legitimate update command using an NVIDIA domain, to help the user fix his issues.

However, once copied, the command morphs into a malicious payload.&nbsp;

<h2>The attack chain&nbsp;</h2>Executing the command initiates a multi-stage attack:&nbsp;<ul><li>A malicious archive is downloaded and automatically extracted.</li><li>The VBS script launches a Python environment embedded within the archive, posing as a legitimate driver update process. It displays verbose output to further trick the user.</li><li>The Python script itself is heavily obfuscated and aligns with known tactics used by the Lazarus APT group.&nbsp;</li></ul>

Upon deobfuscation, the script reveals five major functionalities:&nbsp;<ol><li>Credential Theft: WebBrowserPassView is downloaded, decrypted and executed to extract browser-related credentials. Those credentials, together with system information, are exfiltrated to the command-and-control (C2) server.</li><li>Credential Theft: MailPassView is downloaded, decrypted and run to harvest email credentials, which are also sent to the C2.</li><li>Remote Access: An instance of MeshAgent is silently installed, providing the attackers with persistent remote control over the infected system.</li><li>Advanced Data Theft and Remote Access: A PyInstaller EXE enables file and secret extraction via FTP. Persistence is achieved through a scheduled task disguised as ChromeUpdate.exe, placed within the legitimate Chrome directory to avoid suspicion.</li><li>Cryptocurrency Targeting: Browser extensions and local folders related to cryptocurrencies are harvested and sent to the C2.&nbsp;</li></ol><h2>Attribution and implications&nbsp;</h2>The attack’s complexity and methodology, paired with the initial lure and code similarities throughout the Python scripts, strongly suggest Lazarus’ involvement. This campaign reflects the group’s evolving tactics under the DeceptiveDevelopment umbrella, combining psychological manipulation with technical sophistication to bypass defenses and exploit trust.&nbsp;<h2>Indicators of Compromise (IoCs)&nbsp;</h2>Assessment URL: hxxps[://]assessdome[.]com/invite/7e462f3c/8002565804&nbsp;C2: metakenproxy[.]com:81&nbsp;Initial VBS script (SHA256): 7013822c0a794712c5fe8f62c126e5992dca4a744882a039040569ae4ec1a868&nbsp;Initial Python script (SHA256): 03ad194456951695eb4d4ceb40d9e52aaadbc9a4f4b8b1d020077115103e5359&nbsp;WebBrowserPassView (SHA256): 36541fad68e79cdedb965b1afcdc45385646611aa72903ddbe9d4d064d7bffb9&nbsp;MailPassView (SHA256): bc7bd27e94e24a301edb3d3e7fad982225ac59430fc476bda4e1459faa1c1647&nbsp;MeshAgent (SHA256): 9757780860ec5637c412a8756f25c56f7d1d89358e447782164ba418def1c64e&nbsp;ChromeUpdate.exe (SHA256): 00bef70cd031a830f2ee1ec4ce750947a9c8838995289ecbb253426cca53d046&nbsp;

We traced a deceptive hiring assessment scam back to Lazarus, and here’s how they use psychology and obfuscation to bypass defenses

Lazarus’ latest tactics: Deceptive development and ClickFix

Ransomware isn't what it used to be, it’s gotten a corporate makeover. What began as a work of lone hackers, has evolved into a sophisticated business model known as Ransomware-as-a-Service (RaaS). In this setup, ransomware developers and a network of affiliates collaborate like any legitimate enterprise (minus the part where they extort people).&nbsp;Unlike traditional companies, ransomware groups don't publish earning reports or financial disclosures. Their operations are covered in shadows - until something goes wrong. Occasionally, these groups become targets themselves, and when they do, we get a rare glimpse behind the curtain.&nbsp;This article explores one such moment. On May 7th 2025, arguably the most notorious ransomware group, LockBit, had its panel defaced, exposing a link to a dump of its internal database. The data revealed that the panel had been in operation since at least December 18th, 2024, based on early test entries in the database. While the leak has drawn attention for its technical and operational revelations, this analysis takes a different approach: it focuses on the economic structure behind LockBit's operations. How LockBit recruits affiliates, manages operations, and generates profit. In doing so, we aim to shed light on the inner workings of the underground economy of cybercrime.&nbsp;<h2>Inside the LockBit Panel&nbsp;</h2>The leaked database revealed a sophisticated backend system - basically, a control panel for managing a global extortion operation. It included everything from user accounts and victim profiles to ransomware build information and chat messages exchanged between affiliates and victims.&nbsp;Through this panel, affiliates had access to generate customized ransomware payloads for different environments such as Windows, Linux, and ESXi. The system also stored detailed information about LockBit's victims (or "clients" as they are called internally). Each victim had an assigned public key, responsible affiliate, a payment status, and a complete chat history with the affiliate including features like message read receipts.&nbsp;&nbsp;One particularly eyebrow-rasing detail: affiliate passwords were stored in plaintext. A surprising move for a group that claims to be all about operational control. But hey, even cybercrime syndicates cut corners on cybersecurity.&nbsp;Essentially, we got a preview of a modern CMR (Customer Relationship Management) system - this time not for selling products or services, but rather for extortion.&nbsp;

<h2>A Day in the Life of a LockBit Affiliate</h2>Affiliates are individuals enrolled in the LockBit's affiliate program, think of them as franchises in the ransomware world. After gaining access to the panel, they are granted permissions to build specific versions of the LockBit ransomware. These builds are then deployed to victim systems, either through self-obtained access or via third-party brokers.When a victim is compromised, they are directed to LockBit's infrastructure, where they land in a private chatroom assigned to the affiliate who infected them. This is where real business begins: negotiation, manipulation and psychological warfare.While affiliates often present themselves as cold and transactional, the chat logs reveal a more manipulative side. Affiliates frequently use everything, from manufactured urgency to subtle threats, designed to wear victims down and push them towards payment.&nbsp;

When a ransom is agreed upon, the affiliate generates a new Bitcoin wallet (for our case, we will call it a ransom wallet) to receive the payment. Those wallets are created and controlled by the affiliate, and thus not directly stored in the LockBit panel database. They can be found in the negotiation chats.After receiving the ransom, the affiliate is expected to send 20% of the ransom to a commission wallet (a wallet address that is pre-generated and stored in the panel for each affiliate-victim pair). These commission wallets are under LockBit's control and serve as the group's cut of the ransom payments.The affiliates' share (80%) is usually moved quickly through additional wallets or cryptomixers (services designed to obscure origin of funds), the commission wallets remain largely untouched. The funds sit dormant, likely waiting for a time when they can be withdrawn without drawing the attention of the law enforcement.

<h2>Recruiting New Criminals: The Affiliate Onboarding Funnel</h2>LockBit curates a list of invitations in their panel, each with a specific Bitcoin or Monero wallet and an amount to be paid. The fee for aspiring affiliates ranges from around $700 to $810. After transferring this fee, LockBit creates a new user in the database and sets them the role of newbie. Then, the affiliate officially gets access to the panel and is able to deploy LockBit ransomware and use their infrastructure for ransom negotiations. Startup costs, criminal edition.The dump contained more than 3,600 invitations, with wallets designed to pay the fee either through Bitcoin or Monero. Because of the difficult traceability of the Monero wallets, we cannot say for sure the total number of panel fee payments. But among the invitations that used Bitcoin, only 12 users actually paid the invitation fee during the operation of the panel.<h3>The Revenue Picture</h3>Every LockBit client has an entry in the panel's table. The group collects data about the victim's website, their expected revenue, whether they are an important client or no or their assigned master public key (the tables in the database also show column for private key, however, it is empty for every victim). Since December 2024, the database contained in total of 246 victims with 208 that actually connected to the dedicated chat and started with the negotations. However, from examining the commission and ransom wallets, only 19 paid the ransom payment. The total amount of ransom extorted was 24.8 BTC ($2,660,484 by June 26th, 2025), from which 20% went to the LockBit operators and 80% to the affiliates.The following figures describe the timeline with the amount of LockBit's commissions (20% commission part that went to LockBit) and number of successfully attacked victims with ransom being paid.

In total, there were 40 active affiliates registered in the panel. Ten of them registered by paying the invitation fee, while the rest got the job of affiliate by unknown means - they were either probably affiliates even before the panel was created or registered in another way. Of all the affiliates enrolled, 35 of them started with negotiations, but only 10 of them made some profit. In the following plots, we can see those top 10 affiliates and how successful they were (80% of the ransom extorted), as well as how many messages they exchanged with the victims.

<h2>Final Thoughts: Crime as Business</h2>LockBit’s panel leak is one of the clearest examples we’ve seen on Ransomware-as-a-Service functioning like a tech startup, except its “value proposition” is fear, pressure and extortion.The business was powered by a surprisingly systematic affiliate model, built-in infrastructure, and financial incentives. Despite the flood of invitations and flashy promises, the majority of affiliates never got paid. Of the 246 victims listed, just 19 were paid, suggesting most people either lacked the funds or simply refused to play along. If this all sounds like a parody of a VC-backed startup pitch, it kind of is. But the impact is real, and the profits (while smaller than the headlines suggest) are still enough to fund the next wave of extortion innovation.For readers interested in a more technical breakdown of the LockBit panel and its components, Trellix published an in-depth reverse engineering analysis available <a href="https://www.trellix.com/blogs/research/inside-the-lockbits-admin-panel-leak-affiliates-victims-and-millions-in-crypto/" target="_blank">here</a>. &nbsp;

A rare leak reveals how LockBit operates like a startup — complete with affiliates, onboarding and profit-sharing — offering a glimpse into the business behind one of the world’s top ransomware gangs