AsyncRAT, WebDAV, and Bad OpSec Walk into an Israeli Bar

AsyncRAT, WebDAV, and Bad OpSec Walk into an Israeli Bar

In March 2025, an advanced threat actor group decided to target Israel with an AsyncRAT / PureLogs campaign, deployed via an interesting “soft point” in windows security, the WebDAV.

AsyncRAT is a known malware family designed to remotely monitor and control other computers through a secure encrypted connection.

PureLogs is an infostealer malware from the Pure family.

WebDAV is an old-school protocol that lets you remotely edit and manage files over HTTP, basically turning a server into a shared drive.

In this article, we will go through the highly sophisticated multi-stage malware.

Starting from a phishing URL which loads a WebDAV and urging the user to click on a file.

That file is a highly sophisticated multi-stage malware that will eventually steal sensitive data from your computer. Pretty basic stuff, right?

Join us as we break down the details of this advanced malware campaign. The investigation led to findings so unusual that we had to verify we were not analyzing a controlled CTF environment.

Let’s just say it involved some seriously bad OpSec.

OpSec is the practice of protecting critical information by controlling what you reveal and how you act.

Social Engineering, JavaScript, and Encoding

It all starts with one line of JavaScript code:

Classic pattern. Fetch a remote string, decode it from base64, and run it blindly with eval(). No signature evasion, no complicated loaders, just a straight-up trust fall into unverified code from the “wel.php” endpoint.

And yes, that domain will come up again later. Let’s just say it holds more than just a base64 string.

Once the base64 is decoded and executed, the victim is greeted with a full-screen phishing prompt, styled to look like a legitimate system alert, claiming “You are unable to access this site due to missing files on your device.”

Urging the victim to

1. “Open Windows Explorer” (which loads the WebDAV)
2. wait a minute…
3. Then finally click on the file.

And how does it do that?

This following line of JavaScript code does the trick:

It abuses the search: URI scheme to force the system into mounting a remote WebDAV share hosted on an attacker-controlled IP. The share is dressed up to look like a folder named “Documents,” containing the “Readme” the victim was lured in to open.

No exploits, no popups blocked by browsers, just some social engineering, and bit of Windows jank.

Click, mount, execute -> AsyncRAT.

What’s in the WebDAV?

Once mounted, the WebDAV share doesn’t exactly overwhelm you with options. It serves up just two files:

• Readme.url
• missing.bat

You don’t even need to open the .bat file directly. Here’s the full content of Readme.url:

When the victim clicks on “Readme.url”, Windows interprets it as a shortcut and follows the file:// path into executing “missing.bat”, the actual malware dropper.

It even uses the Microsoft Edge icon to make it look even more safe. Classic.

Understanding the BAT File: Layers of Obfuscation, Encoding, and Encryption

And it’s wrapped in enough layers of obfuscation to make even seasoned analysts sigh audibly.

This batch file is heavily obfuscated, uses base64 encoding, commands split across variables, encryption, and then more obfuscation.

Post-BAT Obfuscation: PowerShell, Base64, and one dwm.bat file

Once we peeled away the batch file’s outer crust of obfuscation, we landed on a PowerShell script. The decoded payload reveals a multi-stage execution chain, complete with file checks, encoded blobs, AES decryption, and dynamic .NET assembly loading.

PowerShell Breakdown

If it finds it, the script reads it line-by-line, looking specifically for two lines that matter

• Lines that start with ::: → contain base64-encoded PowerShell scripts
• Lines that start with :: → contain base64-encoded fileless .NET payloads, executed entirely in memory

The Triple-Colon (:::) Payload: Memory Patching 101

The decoded payload contains a long PowerShell function named “Invoke-SysRoutine”, which sounds like a basic PowerShell function, possibly to cause confusion and avoid detection.

At a high level, here’s what it does:

· Stealth-grab the Windows APIs it needs: At runtime it quietly finds GetProcAddress, VirtualProtect, etc., without declaring any P/Invoke signatures.

· Wrap those APIs so PowerShell can call them: It builds throw-away .NET delegates in memory that behave like normal methods.

· Hide every sensitive string until the last second: Names like “GetProcAddress” or “AmsiInitialize” live in the script only as byte arrays, then get decoded right before use.

· Flip page permissions, patch, and restore: With VirtualProtect it makes code pages writable just long enough to drop tiny “return-success” stubs over security hooks, then locks them back down.

· Blind the sensors that catch malicious scripts: It null-routes AMSI’s scan functions for every provider—and, if -DisableSvc is passed, stubs out EtwEventWrite too—leaving Defender and most EDR telemetry deaf for the rest of the process.

This PowerShell payload isn’t dropping the RAT. It’s preparing the system for stealthy post-exploitation activity by neutering telemetry at the kernel level using PowerShell.

To recap our analysis so far:

· We started with one line of JS.

· That led to a phishing page.

· That led to a .url shortcut.

· That led to a batch file.

· That unpacked a PowerShell loader.

The Double-Colon (::): Fileless Payload Delivery

Lines beginning with double colons aren’t PowerShell. They’re the launchpad for fileless .NET assembly execution.

Here’s what happens:

1. The line is split by backslashes (\), resulting in two AES+GZip+base64 blobs.
2. Each is:
   • Base64-decoded
   • Decrypted using hardcoded AES keys
   • Decompressed using GZip
3. The result? Two raw .NET assemblies.
4. They’re then loaded and executed in memory using reflection ([System.Reflection.Assembly]::Load()), invoking their EntryPoint methods:
   • One with no arguments
   • One with fake CLI args ("% * ")

No disk writes. No external binaries. Just in-memory execution.

To summarize:

• ::: = obfuscated PowerShell loader
• :: = obfuscated .NET payload(s)
• Combined? A fully fileless infection chain that can dodge most signature-based detection and sandboxing

Fileless Payload Delivery

After breaking down the missing.bat file and the PowerShell payloads inside, we decrypted and unpacked the two DLLs from the double-colon lines, which are fileless and memory-loaded.

We then analyse the DLL’s using dnSpy.

DLL #1: ehsmvnbpsn.tmp

TL;DR: it’s not a temp file, it’s a “trap” file.

• Assembly Name: ehsmvnbpsn.tmp
• Namespace/Class: PHANTOM.Program
• Entry Point: PHANTOM.Program.Main()

While examining the Main() we found Nothing.

Empty. Not even a Console.WriteLine("hi").

DLL #2: vxdjvdqdgx.tmp

• Assembly Name: vxdjvdqdgx.tmp
• Namespace/Class: vgjshsmzby.pcagbcueur
• Entry Point: vgjshsmzby.pcagbcueur.Main()

The DLL class pcagbcueur actions:

• Patches ETW to blind defenders
• Loads the embedded .exe resource
• Decrypts and decompresses it
• Reflectively executes more .NET assemblies
• Cleans up after itself.

ETW Patch:

Right at the start, this thing disables EtwEventWrite, which helps avoiding detection by blocking or neutralizing the program’s ability to write telemetry data into the ETW pipeline .

Embedded Resources:

Upon initial inspection, the embedded resource logic suggested a standard executable, exhibiting typical Assembly.Load() behavior. However, a closer examination revealed the following:

This obfuscated logic actually:

1. Loop through every embedded resource
2. Ignore the one called xxxxxxxxxxxxxxxxxxxxxxxxxxxx.exe
3. If the resource ends with .exe or .bat…

· Write it to disk

· Mark it as Hidden + System

· Launch it in a new thread

· Wait for it to exit

· Delete it like it never happened

To summarize:

• The main payload (xxxxxxxxxxxxxxxxxxxxxxxxxxxx.exe) is not even executed yet.
• The resources that do get executed are helper EXEs or batch scripts, maybe:
  • Environment recon
  • Defender bypass
  • Plugin loaders
  • Or just distractions (e.g., a decoy batch file)

And it all happens from memory, in a new thread, with cleanup.

Immediately after the loop, the code handles that resource separately, this is a simplified version of what’s inside the DLL:

· It does execute the payload,

· but it never lands on disk or gets started via Process.Start. Instead, it is decrypted, decompressed, and loaded straight into the current process with Assembly.Load, then its Main method is called reflectively.

Summary

· The if (!(name == text) …) check excludes the primary payload from the drop-and-run routine.

· The main resource is executed in-memory right afterwards.

· Any other embedded .exe or .bat files are dropped, hidden, run in a background thread, and cleaned up when they finish.

Decrypting And Decompressing The Resource

The decrypted exe file is the PureLogs loader and yes, It’s a .NET Assembly, Again.

PureLogs Loader

The loader loads an AES encrypted and compressed byte stream to a DLL library and calls a specific method inside it:

In this function there is a very long byte stream encrypted with hard coded AES Key + IV.

The next function it compresses it using GZIP.

The main function loads the compressed + encrypted stream of bytes and gets a specific function from it.

This time, instead of writing a script to load, encrypt, compress / decompress the payload. We patched the loader to drop the DLL by adding a simple line, to drop the library to C:\Users\Public

Yet Another Loader

So, at this point we were 100% sure we finally got to the infostealer source code but guess what...

We began by performing a lookup for the executable’s ImpHash on Malware Bazaar, and it quickly became clear that this library has notable ties to AsyncRAT.

ImpHash (Import Hash) is a hash over the imported functions by PE file. It is often used in malware analysis to identify malware binaries that belong to the same family.

A basic examination with Exeinfo PE reveals that the file is obfuscated. We can use NETReactorSlayer to unpack it.

We made sure during the unpacking that the methods name will stay the same, because the xxxxxxxxxxxxxxxxxxxxxxxxxxxx.exe file calls a specific method in the library (pJe27bYBMNbEKKrKbS.b7Ao4YDWNUqQ8JDv8o).

Now that we have de-obfuscated the library, let’s open it in dnSpy and take a closer look at the method being called.

Upon inspection, we identified a Base64-encoded string. After decoding it, we found that it contains the C2 configuration.

· jojo.ath[.]cx - the c2 server DNS

· 80124d74566295d3 - probably the campaign ID

But what’s important about this base64 string, that the AsyncRAT uses its md5 value as the key to decrypt the messages to the c2 server.

Enter PureLogs

The flow of the AsyncRAT / Purelogger loader looks like this:

· The Loader sends the campaign ID to the C2 server (encrypted with 3DES and compressed using gzip)

· The C2 server returns the PureLogs library (encrypted with 3DES and compressed using gzip), but adds a twist

· The returned library is also serialized and reversed.

**Taken from anyrun purelogs analysis**

To extract the 3DES key, we used a simple Python script to md5 hash the provided Base64 string just like the DLL library.

Now that we have obtained the key, we can proceed with testing. We will extract the first message sent to the C2 server during dynamic analysis, remove the first four bytes, and then attempt to decrypt and decompress the data.

The decrypted first message confirms it contains the campaign ID. With this step completed, we can now move on to the next phase: analyzing the received DLL. This will involve serialization, reversing, and further examination.

Now let’s take the message received from the C2 server decrypt and decompress it using cyber chef.

The output is still unreadable. We will save it to a file and use the next C# program to deserialize it, using the structure defined in the loader DLL as a reference.

Now that we have obtained “payload_dump.bin” which at this stage appears to be raw, unstructured data, we will repeat the process: decryption, decompression, and, this time, reversing the byte order.

Upon completing these steps, the result is clear: we have successfully extracted the PureLogs library.

The PureLogs Core Library

As expected, the PureLogs library is obfuscated using .NET Reactor.

After this lengthy process, we are finally able to examine the PureLogs library — and it quickly becomes clear that it is both highly aggressive and designed to collect an extensive amount of data.

Rather than asking what the PureLogs library steals, it would be more accurate to ask what it doesn’t steal. It targets a wide range of data, including:

· Browser passwords

· Browser history

· Cookies

· Cryptocurrency wallets

· Basic user and machine information

In addition to these common targets, we also identified less typical data theft attempts, such as VPN profiles. For example, the stealer actively searches for and attempts to exfiltrate OpenVPN configuration files.

Discord tokens are also targeted and extracted, highlighting the stealer’s broad reach across user credentials and session data.

Even WinSCP credentials are not spared, as the stealer actively targets and extracts them as well.

It is evident that this highly obfuscated and stealthy malware demonstrates a persistent and wide-ranging appetite for data exfiltration.

Now Let’s Speak About Bad OpSec

Based on the sophistication and deep knowledge demonstrated by the operators, one would expect top-tier operational security (OpSec) practices to be in place. However, that assumption did not hold.

During analysis, the domain directfilesjo[.]com, used by the initial JavaScript to fetch additional scripts, immediately raised suspicion. Further investigation revealed that the domain was hosting a file manager platform, protected only by basic username and password authentication.

A critical OpSec oversight that exposed part of the attackers’ infrastructure.

At that point, accessing the platform felt almost instinctive. Using the common default credentials “admin” as both the username and password, access was immediately granted.

The file manager revealed a large repository of files, exposed and readily accessible, representing a significant lapse in the threat actors’ operational security.

It had pieces of malware in there, VBS scripts, DLL files, executables and bat scripts.

Following a thorough analysis of the files retrieved, it became clear that the majority were of a similar nature: heavily obfuscated droppers and loaders, including PowerShell scripts, batch files, DLLs, and executable files. All ultimately designed to deliver malware from the “Pure” malware family.

Whether this was the core infrastructure of a specific threat-actor group or a shared repository used by multiple actors remains uncertain. Time and further investigation will provide clarity.

However, one critical lesson is already clear: Even the most sophisticated and technically advanced cybercriminal groups are vulnerable to simple human errors.

Just like major technology companies, a single lapse in operational security (OpSec) can expose and compromise an entire operation.

IOCs

WebDav to PureLogs IOCs Table

Files Found on Threat Actor Malware Deployment Server IOCs

Threat Actor Malware Deployment Server Iocs