What is a DLL

A DLL is a file that contains code or data that can be executed by other applications to assist in their function. These DLLs can also be used by multiple applications simultaneously, increasing efficiency in regard to memory and disk space usage. Instead of including the same block of code in 5 different applications, each application can just import 1 DLL that contains that block of code.

How DLL injection Works

For a threat actor to inject their malicious DLL into a legitimate running process a couple things have to happen.

1. The malicious DLL has to be somewhere accessible on the disk.
2. The target process has to be running at the time.
3. The user that triggered the execution of the DLL must have adequate permissions to the target process.

With all of the above true a malicious DLL can coerce a legitimate process into executing its code. This is achievable via a few WinAPIs namely VirtualAllocEx, WriteProcessMemory, and CreateRemoteProcess. VirtualAllocEx  - Is similar to VirtualAlloc except it allocates memory in a remote process. WriteProcessMemory  - Writes the DLLs to the remote process. CreateRemoteThread - Creates a thread in a remote process.

Before all this can happen a target process needs to be found. To figure out what is running on a victims machine its processes have to be enumerated. Microsoft actually provides a way of enumerating processes within their own documentation. The functions that stick out are the CreateToolhelp32Snapshot, Process32First, and Process32Next. These functions are vital to process injection, because without them the malware would be shooting in the dark and most likely fail. CreateToolhelp32Snapshot - Creates a snapshot of the running processes on a system. Process32First - Grabs the info on the first process in a snapshot. Process32Next - Grabs, well you guessed it, the next one.

Now loading the DLL into the target process can almost be achieved. I say almost because the target process will need to execute LoadLibraryW locally targeting the malicious DLL. The question is how would you get the target process to do something that can only be executed locally? Well because LoadLibraryW is a WinAPI its address is the same regardless of what is running, this way it can be called by multiple processes. This means the address for LoadLibraryW can be stored in something like pLoadLibrary and used in a thread remotely created in the target process.

pLoadLibrary = GetProcAddress(GetModuleHandle(L"kernel32.dll"), "LoadLibraryW");

Finally with everything above successfully executed the malicious DLL can not only be called by the target process but has the allocated space to be executed.

The Reverse

Now that I know what is required for a DLL to be injected into another process. I can run a (very simply built) program that will perform this type of injection and know what to look for in a debugger.

First off the malware will need to look for a commonly used process running on the machine. As the above has stated finding this will more than likely be a comparison of whats running with what is being targeted. In the wild the target process would probably be something like svchost.exe. notepad.exe is just part of my example.

With this in mind I want to set a breakpoint at Process32First to see if it is being compared to a process name. Since Process32First is a WinAPI I can easily find it in the malware’s “Symbols” tab. From here select your malicious exe, sort by type import, find Process32First, and set your breakpoint.

Before running the debugger though I wanted to also set a breakpoint at VirtualAllocEX, this will tell me what it is trying to be inject since it needs to allocate space for it.

With these two set we can run the debugger and see what we get. The first breakpoint we set gets hit and as expected we see the targeted process being held in a general register R14 and that target is notepad.exe!

Now on to the VirtualAllocEx breakpoint to see what is trying to be injected into notepad. Nice we have the malicious DLL location!

With this information we can stop the debugger (if this was malware you wouldn’t want to let it run) go find that malicious DLL and start the reverse engineering process all over again.

Conclusion

I looked further into why R14 was being used and found out that R14 itself is pretty arbitrary, but the use for general registers like this is to hold data while multiple functions are being called. This is so that the stack isn’t unnecessarily manipulated, and at the same time saving the data for later use by the function initially called. This one was really interesting to me as DLL injection was a big deal for awhile, I think now Reflective DLL Injection is more widely used but I haven’t gotten there yet. Till next time…

What is XOR

XOR is a type of symmetrical encryption. This means that by using a single key it is encrypted the same way it’s decrypted. The way XOR works is basically it asks “is it different than the key”, in which case the answer is either yes(True: 1) or no(False: 0).

Because XOR is a bitwise operator it’s applied to each individual bit. XOR: Payload: 7 = 0111 Key: 2 = 0010

XOR takes the payload and the key and performs its exclusive OR operation on it (the “is this different” question). Note if the key is smaller than the payload it just wraps around.

XOR POC

Below is a super simple proof of concept for shellcode encryption and decryption that I made as part of an exercise.

Once ran it will encrypt the shellcode and then decrypt it.

The Reverse

Ok now I had to figure out if I came across this in the wild how would I find not only the payload, but the key to decrypt it as well. To do this I threw it in Ghidra and went digging. I am treating the code as if I have never seen it before and ignoring the naming of the variables/functions on purpose By jumping to the main function under the symbol tree on the lefthand side, I poked around the functions in the decompiled section of Ghidra and found one performing a loop that includes an XOR operation ^.

Main Function: Found Function:

Double clicking on the function takes me to its code where it was performing an XOR operation on a single parameter, which I am assuming is its key. Below you can see the xor operation in assembly and in C ^ being performed, along with the for loop to XOR each byte (the JMP jumps back to its own address if a condition is not met AKA a for loop).

I have found an interesting piece of code that encrypts something. Now I need to get its key and payload so I can decrypt it. This is where x64dbg comes in. Before I could find the function in x64dbg I will have to rebase Ghidra to match x64dbg address space. This is done by getting the base address in x64dbg (memory map > name of .exe > right click copy address) and rebasing Ghidra (Window > Memory > House Icon > Paste). After this is done you have to find your function again and then copy its address and in x64dbg enter the comand bp addressoffunction.

Once you have your breakpoint set hit run. It will pause at the entry point at first because that is default in x64dbg, after that initial breakpoint hit run again and you should land on your breakpoint you set.

Once at your breakpoint step over until you hit the XOR. In the picture above the registers rax and rcx are being XOR’d, if you look at these registers in the FPU window on the right hand side you can see what is currently in them at that time. Knowing that one of these holds the key and looking at the assembly you can see that rcx is the source register (its on the right), so double clicking it gives me the key.

Now that I have the key I just need to pull the payload from the .data section (my payload was a global hardcoded variable and may not always be the case in real world malware). Also notice that the bKey is { even though it is hardcoded as well, you still can’t get the key without debugging.

Conclusion

This was the first time I was able to open up a portable executable and understand it enough to accomplish my goal and it was exhilarating. Not only was I able to code something in a language I am just now starting to learn, but I was also able to reverse engineer what I made! I look forward to doing more of these posts as I learn to develop malware.

Even after learning assembly I still struggled with jumping into some malware and understanding what the hell was going on. That was when I came to the realization that I need to learn this stuff inside and out to understand it. Having heard nothing but good things about MalDev Academy and the fact that they were having a 25% off sale at the time, I enrolled. This put me in a win win situation. While learning to develop malware I could reverse engineer what I’m taught. This way I gain a better understanding as to why and how threat actors build malware the way they do and I will know what to look for when reversing live samples.

Looking over the syllabus and with me not knowing much C and reversing what’s taught throughout I knew this was going to take a long time. This was going to leave a huge gap in my blog posts and when I did post again there would be a recognizable leap in knowledge. Then it dawned on me. I could post about what I learn when reversing my own code, it would help solidify my learning and hopefully help out anyone reading that wants to get into reverse engineering.

With all that said, I am starting a new category in my blog site dedicated to learning. With this new section the goal is as I learn hopefully someone else can learn with me, making their journey to reverse engineering and malware analysis a little bit easier.

As you can see this malware tries to deceive its victim right off the bat with a filename ending in .jpeg.exe.

Pro Tip

I know you’re thinking, “well it says its an exe plain as day”, and your not wrong. The full filename clearly shows that it is an executable, however, most operating systems don’t show extensions by default, so this would look like a normal .jpeg file which most people wouldn’t second guess was anything but a picture.

Let me show you with a file I just made.

Show extensions on: Show extensions off:

As you can see from the second image above the file is able to masquerade its self as a normal .jpeg by simply changing its name.

You can usually make this change yourself in your file explorers view settings.

Initial look

Lets get this thing over to FlareVM and see what it’s trying to do. Detect It Easy (DIE) shows that this file is actually a Self Extracting Archive (SFX).

Before possibly getting myself infected by just unzipping it, I decided to do a bit of research into SFXs. An SFX is an executable program that both contains the compressed data and decompresses it. When double clicked It executes a stub that will carry out the decompression and can be further configured to continue with installation instructions; in this case run a malicious executable. Come to find out the safest way to handle one of these is to treat it like a normal zip file and extract it yourself, not allowing the SFX to do it for you and executing the malware.

And there it is, the malicious executable named loader.exe.

Accompanied with a cheeky little message from mister skiddie themself.

Running the executable through DIE it tells me that it is a .net application, its obfuscated, and has anti analysis!

The Analysis

Time to throw this thing into dnSpy and start tearing it apart. As usual our launching point is the entry point.

That led me straight to what I recognized as the configuration that needs to be resolved before anything is carried out. I set a break point right before the exception, which would have exited the program if I would have set it any lower.

And just like that we have the configuration settings: C2 host, port, install location, and more.

This time around I am renaming the fields so it will be easier for me to understand the flow of the malware. This way while looking around my naming scheme will jump out to me.

With the config completely renamed, lets move on to what exactly this thing is capable of.

Right after setting up its settings the malware does a check for its mutex to make sure it isn’t already running, runs through an anti analysis method, and sets Microsoft defender exclusions.

The anti analysis method checks for both Virtual Box , Sandboxie, and VmWare virtual environments. The checks include whether it’s being debugged, if the operating system is windows xp or not, then finally checks the geo location of the victim.

The malware then goes on to set Microsoft defender exclusions using powershell. It sets exclusions for the original file location, its current process, the install path, and the the malicious process itself svchost.exe.

After the exclusions are set it then moves on to create persistence within the system by creating a scheduled task that will run every minute whether or not the user is an administrator and a startup registry key entry.

Once all that is set up it starts conducting its nefarious deeds, such as starting up its keylogger and crypto clipper.

I was curious about what crypto clipper was so I did some research on it. After some digging I found that since crypto wallets are very long and hard to type most people will copy and paste them when doing transactions. This is where crypto clippers come in; it will monitor the victims clipboard for a wallet address and replace it with the threat actors.

The picture that came with this malware also mentioned the ability to blue screen the victims computer, so I looked into just how they were accomplishing that as well. From what I could find it will set the process as a critical process using RtlSetProcessIsCritical and then terminate it causing a stop error code CRITICAL_PROCESS_DIED (0xEF).

Digging further down I also found command and control (C2) functionality. Commands like shutdown, restart, and shell interaction. It also has the capability to use the victims machine as part of DDOS attacks. Not included in the screenshot, there seemed to be ways to load plugins to expand its C2 capabilities further.

The DDOS function basically turns the victim into a bot used to target websites; shown below hosts, ports, and a duration(num) are accepted as arguments. This gets sent to a while loop that will connect to the site specified by host over and over for the duration that is specified via the timeSpan and stopwatch comparison.

There was also a cleanup method that would delete itself, its registry key entry, scheduled task, and then move into the BSOD method. Meaning that once the attacker is done using your computer they leave you with a blue screen.

Some CTI

Shodan shows that the IP address of the host is based out of France with a decent amount of ports open, although none match what was found in the sample.

Only 16 out of 94 vendors have reported this host malicious to Virus Total with similar results for the ip address. I voted and left comments for both the hostname and ip address.

According to Microsoft Xworm is linked to the ClickFix campaign that has been extremely prevalent in 2026.

From Cat pics to Takeovers

If nothing else, this post goes to show just how volatile the internet can be. One minute your browsing cat pics and the next some loser is in your computer. All in all, analyzing this sample of Xworm was really fun. Going through and renaming everything sent me from one “aha” moment to the next, granting me just the right amount of dopamine along the way. Now with my distractions out of the way it’s back to learning assembly, and hopefully posting my first analysis of a malware sample not built with .net soon.

IOC

MITRE ATT&CK and Malware Behavior Catalog

brought to you by Mandiant Capa

Hashes:

According to an article by Huntress Quasar RAT was used by APT10, a state sponsored group based out of China. The article goes on to explain that parts of APT10 ended up being indicted in 2018 by the U.S. Department of Justice. This made me interested in who or why is still using it today and possibly exposing their infrastructure, lets see what we can find out.

Finding the sample

As usual getting malware from the internet is never difficult. By using MalwareBazaar’s search syntax signature:QuasarRAT I pulled up all the posted malware with the QuasarRAT signature. The results were sorted by most recently posted so I decided to choose the first one that showed up and just go for it.

Take Caution When Downloading From Any Site That Hosts Malware as These Are Live Samples

An Initial look

Detect It Easy (DIE) confirms that it is a .net application, and mentions that the data is packed with high entropy (randomness) in the initial scan.

DIE will also provides a visualization of just how packed or obfuscated an application is via a graph for entropy ranging from 0-8 and packing percentage near the top.

93%! Well, I did say I wanted something more obfuscated and complex.

Lets take a look at PEStudio to see if some of the imports can tell me anything.

…5. There are only 5 flagged imports. And they don’t seem to be anything that outstanding. I mean, GetCurrentThread could possibly be something, but not likely on its own. I looked up the MiniDump api and it could be used for credential theft or information gathering, but the low amount of imports definitely means heavy obfuscation or that import calls are built during runtime.

Diving in

Ok, lets throw this thing into dnSpy and see just how complicated this thing is.

It’s not just obfuscated but also in Chinese…

I wanted to find something that can deobfuscate this for me so I can at least start figuring things out. I have heard of De4dot for deobfuscation and found that it was already part of FlareVM so decided to have De4dot take a look.

De4dot came back with “Detected Unknown Obfuscator”, but this may be due to the use of Chinese.

I did some more research into other .net deobfuscation tools and came across another .net deobfuscator and unpacker NETReactorSlayer. After checking for NETReactorSlayer I saw it was already installed! I really need to go through all the installed tools on FlareVM, but honestly who has the time for that.

Alright lets see what this thing can do, I checked all options and threw in the malware because why not.

Once NETReactorSlayer was done it produced a deobfuscated version of the exe with _Slayed appended to it(I renamed that one to just _QuasarRat_slayed.exe). It also unpacked a slew of dlls it must use at runtime which explains the low amount of imports seen earlier in PeStudio.

Looking at the sample again in dnSpy it is no longer in Chinese, but still obfuscated.

I wondered why the namespaces and classes were still gibberish after NetReactorSlayer had deobfuscated and unpacked it. Potentially code virtualization? Basically code virtualization converts your code into randomized instructions that are interpreted at runtime. This technique seems to be extremely difficult to reverse and most people just go with the crazy names or change them as they come across them.

If you want to know more about code virtualization you can look here.

As you may have noticed in one of the earlier screenshots there are a lot of namespaces in this application.

Luckily, I know just were to start: the entry point.

Now based off of my previous experiences with malware I knew that early on it needs to decrypt its configuration so it can act on them and continue functioning. Although I couldn’t really read what the names of the classes were, I did what I would call “walking”. I simply went down the entry point class by class until one led me to a list of items being decrypted. And thats exactly where class e4VF3YgDwO0iB led me.

I have been in this situation before and knew exactly what to do, set a break point.

With the breakpoint set I hit debug(F5), opened the static fields window, and there it was. Instantly what looks like a C2 IP with port number, the name and location of where the malware runs from once executed, along with other configuration settings.

We will see what all we can do with this info soon, but now I want to move on to see what all this thing is trying to do. After running up to the break point all the unpacked dlls are also loaded. One that stuck out to me was called Pulsar.Common.dll. Once expanded, it looks like all the malicious functions of this malware come from this single dll.

Looking at these namespaces you can clearly see that this thing is capable of just about everything in the book. It’s gathering info, changing registry keys, and doing what looks like possible ransomware tactics in Pulsar.Common.Messages.FunStuff.

Pulsar

I was interested in why this Quasar RAT was exclusively using this Pulsar dll to perform just about any and everything that you can think of when it comes to malware. I did some digging and found out that Pulsar RAT belongs to the Quasar RAT family and first appeared in early 2025; meaning the sample I found is a fairly newly crafted RAT! While I was poking around on the internet for more info I came across this gem of an article where researchers at ThreatMon got ahold of a PulsarRAT builder. Based off what they found what I am dealing with has got to be a Pulsar RAT.

Some of the mentioned functions of the Pulsar RAT match the namespaces in my Pulsar dll.

Also the client tag during configuration and the scheme of the mutex confirms what I found was also the mutex.

Seems like the wallpaper change and hiding the taskbar was not part of a ransomware function, just to cause distraction and confusion.

Some CTI

Now lets see just where this C2 is going and if we can cause them some issues. Using good ole Shodan it looks like the IP address points to a VPS hosting service so, most likely the threat actor isn’t actually located in St. Louis.

Searching the C2s IP in virus total shows only 13 out of 94 vendors have marked it malicious with only one comment mentioning Quasar RAT.

I also voted and commented on Virus Total so hopefully it will bring a little more awareness to the C2 infrastructure.

They grow up so fast

From initially thinking this was old malware being reborn to finding out that it was a much younger variant of its predecessor,malware continues to keep me on my toes. You think, “oh this is a run of the mill RAT resurfacing” and then it ends up being something new built from something old. From the heavy obfuscation to the use of Chinese I thought this was going to be a Quasar RAT through and through. Especially with the earlier references to the Chinese APT group. I get it unpacked and BAM! A recently built variant of Quasar RAT that is probably keeping the Quasar family trending to this day.

My next adventure may be another .Net app or a generic PE I am not sure yet as I am still learning assembly and how to properly analyze generic PE malware. If I go with another .Net app I will do more with renaming namespaces and classes for better readability as I feel like this is something I need to form a habit around.

IOCs

MITRE ATT&CK and Malware Behavior Catalog

brought to you by Mandiant Capa

Hashes:

So without further delay, let me introduce you to just that, my go at a deeper analysis of the AsyncRAT (which turns out to have a bit of a twist and a small victory in the end!).

The setup

If I am going to download and dismantle software that is built to ruin peoples day I need a safe to place to do it, and since this is my first time doing this, the appropriate tool. Conveniently enough I had a Linux machine I could run a windows (I chose windows because it’s the most targeted OS) virtual machine on. I figured this was the safest bet— having the guest and the host running two different operating systems in case of any kind of breakout. Now I had to find the tools that analysts use. I have heard of a few pre-built OSs that would be a great place to get started, namely, REMnux and FlareVM. REMnux is linux based so FlareVM it was.

FlareVM is technically not a OS in the sense that REMnux is a linux distro. FlareVM is a collection of software installation scripts for Windows.

Setting up FlareVm was very simple and Mandiant provides really clear instructions on their GitHub page which appears to be pretty well maintained.

Finding the RAT

Surprisingly, finding malware on the internet is fairly easy; it’s as simple as going to the store or in this case the bazaar. The Malware Bazaar is just that place. I searched for the AsyncRAT signature and found a lot, and they were even posted that same day! I settled on the one pictured below, downloaded it, and…….Immediately disconnected my VM from the internet.

Take Caution When Downloading From Any Site That Hosts Malware These Are Live Samples

The Analysis

Strings

Before diving into the code with a decompiler I figured I would look at it from a very high point of view via Strings.

During my search through the malware’s strings some very interesting things jumped out to me. Most notably, the strings TelegramToken and TelegramChatID. I knew that the sample of AsyncRAT I found would be different than the one found in this post, (which was what made me want to look further into AsyncRAT), but the mention of a telegram ID was a big surprise!

PEStudio

I needed to know what this thing was built with so I can dissect it using the proper tool.

In comes PEStudio! It can identify a multitude of things for initial static malware analysis, but I just needed it to identify what my sample was built with.

Ok a 32bit executable written in C#

dnSpy

This is where we really get into things. dnSpy is a debugger, decompiler, and a .NET/Unity assembly editor. Perfect for diving into this malware.

Initially, getting into dnSpy is pretty overwhelming and took some research on where I should look first.

Welp, it was pretty straightforward actually. Seems like the best place to start was called the Entry Point.

The Entry Point is the very first instruction that executes in a process. This is where the Operating System gives control to the application so it can start performing these instructions that the Entry Point points to.

This led to the Client namespace which contained the Settings class. Here I noticed something that was in the original blog post I referenced earlier.

Within the Settings class there is a method called InitializeSettings(), this basically contains the hardcoded config for the malware which is encrypted before execution to avoid detection via static analysis.

The use of the InitializeSettings method is a somewhat ingenious technique. It serves two purposes: the first is that it doesn’t require the process to rely on an external .config file which makes its footprint smaller, and the second is to decrypt these configs the malware would have to be executed.

Looking further down the assembly explorer I noticed some very interesting namespaces: Clients.Modules.Passwords.Targets, Clients.Modules.Passwords.Targets.Browsers, Clients.Modules.Passwords.Targets.Messengers, and Clients.Modules.Passwords.Targets.System. LBased on the namespaces it seems like this RAT has been modified to be an infostealer targeting a wide range of data such as: passwords and credit cards stored in browsers, Crypto wallets, Discord and Telegram tokens, keystrokes, and the ability to take screenshots of the victims Webcam.

Browser Information Stealing:

Stealing Crypto Wallets:

Discord and Telegram token theft:

Sending Keylogger logs to Telegram:

Ok, so now I am 100% sure this is an infostealer and I noticed in the InitializeSettings method there were two fields that referenced Telegram: TelegramChatID and TelegramToken. It seems pretty clear that this modified AsyncRAT is an infostealer that reports its stolen data to a Telegram channel via a bot. However the variables are encrypted which means I would need to run the malware to see the decrypted data.

In comes dnSpy once again to save the day. I can “partially” run the malware in dnSpy by setting a breakpoint and view what the process has done up until that point in memory. I set the breakpoint to the return at the very bottom of the InitializeSettings method, then run the debugger.

Setting the Breakpoint:

Once the debugger has ran the process up to my breakpoint I check the static fields in memory. And there they are. All the variables in cleartext!

Decrypted malware config variables:

There is some very juicy info here, but we will keep moving and look more into the malware sample. One thing I did notice in the decrypted settings is that the Anti field is false (which would have made this analysis a lot more difficult). This was the anti analysis method that is seen in other AsyncRAT samples. Even though this is a modified version of AsyncRAT it still contained the AntiAnalysis method which I took an interest in and thought it should at least be brought up here. It checks for a multitude of things such as static analysis tools, wether it is sand boxed or not, and if it’s being ran in a hypervisor such as VirtualBox or VMware.

If any of these return true the process proceeds to a method called FakeErrorMessage() which pops up a message box with a fake error message then executes SelfDestruct.Melt(). This method deletes the .bat file, kills the malware’s process, deletes the malware’s current working path, and deletes the DotNetZip.dll. The .bat file and the .dll are typically wrappers for malware and what this is doing is scrubbing the place clean so there aren’t any artifacts left behind.

Self Destruction:

A little Counter Intelligence

Take Caution when interacting with threat actor environments it is very easy to leak your IP

You may have noticed that two of the hardcoded variables for the settings in this malware sample were related to Telegram: TelegramToken and TelegramChatID. Because this sample was so recently posted I was betting that their Telegram channel was still active and if so, could I disrupt their little infostealing operation?

But how do I interact with a Telegram channel with just the info I have? Well in my searching for how I could use the Telegram Token and Chat ID to gain access to this bot and channel I discovered someone had already made software for just that reason. TeleTracker, super easy to setup. Just follow the install on the github page and your off!

I was right! Their channel was still active! Below is the bots name, username, channel access, and the name of the group.

From its name (ONE FOR ALL) I can discern that this bot may be used by multiple threat actors, with this group channel (XWorm up) being a repository to gather and share stolen data.

I was also able to find the chats administrator.

I was able to pull the number of messages that were in the group chat and it was over 6000 messages. Based on the permissions of the bot I couldn’t read any messages, but I was able to delete quite a few and felt good doing it. Hopefully it at least put a kink in their operation.

The WorldWind

In some of the screen shots you may have noticed the name WorldWind come up a few times. I decided to look into it as well. I Found out that the WorldWind Stealer is indeed an infostealer. It’s basically built with code copy and pasted from AsyncRAT (RAT) and StormKitty (Infostealer). There have been a few infostealers made in the exact same way. Most notably are WorldWind Stealer (this one), DarkEye, and Prynt Stealer. In fact there was an article referencing all three in a “no honor among thieves” scenario where presumably, whomever is handing out the infostealers was stealing the stolen data from them. ZScaler Article on the stealers

Naturally I had to check my sample for this. And wouldn’t you know it! There it was, the info from my stealer was being sent to another Telegram chat ID. The only difference in mine is the Telegram Token was being hosted on pastebin.

Unfortunately, I was unable to cause any disruption to this one. I received 401 unauthorized codes for everything.

What a wild ride

We went from remote access trojan to infostealer to the stolen data being exfiltrated via a backdoor within the malware!

All in all I learned a lot, and from where I am standing it only gets better from here. I want to dig into more malware samples. Possibly tackle something obfuscated? Oh, and I want to eventually get into dynamic analysis which I know can be a lot more dangerous since you’re purposely launching malware.

AsyncRAT

First things first, where can I find some malware that has already been looked into and get juicy info on it? My first go to was AnyRun. I looked through “Top Today” in AnyRuns Threat Intelligence page and came across a malware named AsyncRAT, it was top 5 in their malware trends tracker with 61 daily activities as of February 3rd 2026.

History

AsyncRAT started as a legitimate open source remote access tool that was released via GitHub in 2019 by a user known as “NYAN CAT”. AsyncRAT seems to have expanded far beyond its predecessor Quasar RAT introducing stealth and modulability. Site

What I know

As its name suggest AsyncRAT is a Remote Access Trojan (RAT), so when looking through these submissions I should be looking for the execution of a program and network communication for the initiation of commands possibly coming to and from a Command and Control software(C2).

I was able to find a plethora of public submissions with the AsyncRAT tag within AnyRun, some of which were not even a day old!

Analysis of an Analysis

The sample: Sample1 An executable (Ubuntu11.exe) Reads system information from registry such as Computer name and supported languages. Checks to see if the machine has already been compromised via MUTEX. Drops 2 files: "C:\Users\admin\AppData\Roaming\Ubuntu11.exe" "C:\Users\admin\AppData\Local\Temp\tmp69E3.tmp.bat" Alters the windows startup registry (HKEY_CURRENT_USER\SOFTWARE\Microsoft\Windows\CurrentVersion\Run) key making it run the executable it dropped at startup Value: "C:\Users\admin\AppData\Roaming\Ubuntu11.exe" The bat file runs timeout 3 this may be to delay execution as to not look suspicious?

The executable dropped in the users AppData was the true malware it contained configurations for communication with 5 different C2 addresses over 2 ports. It confirmed the ability to run on startup which was seen being executed by the initial exe.

Running the C2 IP addresses through virus total gave me a bit of insight on the threat actors, almost all of their C2 communications were going through Cloudflare redirectors. One of the locations of the IPs was Vientiane, Laos. In recent news AsyncRAT has not only been using Cloudflare’s redirector services but also taking advantage of TryCloudflare Cloudflare’s free tunneling service for multistage delivery. Cyberpress Darkreading link

Impact

AsyncRAT is widely used by threat actors all over the globe targeting multiple infrastructures and since its creation in 2019 it has done nothing but grow in use. a recent report

A look at a deeper dive

I found a technical analysis of AsyncRAT in VXUnderground that dives into the code of AsyncRAT. It is really well done and an easy read, THIS is the stuff I want to end up getting into once I figure out the best way to do these types of analysis it will become a big part of this blog. From what I understood in this writeup AsyncRAT can be very stealthy checking for Antivirus, Sandboxing, and even Disc space. It also has a neat admin checking bat file that will run every time someone logs in checks if they are admin and then deletes its self. There were some tell tell signs from what I found that was also in the writeup like the location of the bat file, the executable, and the edit of the registry key value.

Future

This was really fun and it really left me with wanting to do more. Like I said once I figure out how to safely do these deeper types of analysis I definitely want to take a stab at it. It was cool learning about malwares use of MUTEX to check if a machine has already been compromised and seeing just how stealthy AsyncRAT can be via the deep dive I found.