Investigation of Turkish-Sourced EagleRAT and AsyncRAT Malware Activity

Nov 07, 2025

Executive Summary

Two closely related malware campaigns targeting Windows systems were identified, using batch droppers to deliver .NET-based remote access trojans (RATs) with sophisticated evasion, persistence, and command-and-control (C2) capabilities. Both campaigns employ advanced obfuscation, in-memory execution, and anti-analysis techniques, demonstrating a high level of technical skill. Analysis of the malware infrastructure and repository activity including Turkish-language scripts and accounts suggests that the threat actor is likely of Turkish origin. Linguistic cues in the scripts, such as Japanese-language elements, indicate a potential focus on Japanese users, highlighting a targeted approach within an otherwise internationally operable campaign. The campaigns show ongoing activity, underscoring the presence of a persistent and capable adversary.

Campaign 1 – Multi-stage Malware (3949.bat → Client.exe)

Stage 0 – Dropper (3949.bat):

Batch script masquerades as a legitimate Windows component using Japanese-language social engineering cues.
Writes a Base64-encoded payload to %TEMP%, decodes it using certutil, and executes the resulting ptr_x.bat.
Performs cleanup by deleting temporary files and clearing the console.
The decoded payload is a .NET PE, confirming the batch script functions solely as a loader/dropper.

Stage 1 – Payload (Client.exe):

Heavily obfuscated .NET assembly with tampered entry points and multiple layers of dynamic assembly loading.
Uses a custom AssemblyResolve handler to decompress and load embedded assemblies directly into memory (array1.bin and array2.bin).
Anti-analysis measures include runtime privilege checks, mutex-based instance control, and early-stage initialization routines hidden in .cctor.
Implements C2 communications, packet serialization/deserialization, and conditional dynamic method invocation.
Keylogging functionality exfiltrates user input via keyboard hooks.
Optional persistence mechanisms exist but are disabled in this sample.

Campaign Infrastructure:

GitHub repository activity suggests the campaign began in September 2025, with recent uploads as of November 1, 2025.
Repository hosts DDoS, packet-flooding, and botnet scripts, with CI workflows automating additional malware downloads (including Mirai variants and JavaScript files disguised as legitimate content).
Evidence links accounts (Paraloxd, iOnly699) to ongoing malware operations over at least a year.
Associated IPs overlap with AsyncRAT infrastructure, suggesting reuse of servers.

Threat Assessment:

Advanced in-memory execution and obfuscation make detection difficult.
Capabilities include remote command execution, keystroke logging, and potential DDoS participation.
High likelihood of continued activity based on repository updates and observed binaries.

Campaign 2 – AsyncRAT/VenomRat Variant

Stage 0 – Dropper / Loader:

Batch script downloads a .NET RAT executable (Client.exe) from a remote URL (https://curl.by/UVO_V/Client.exe).
Initial delay is implemented to evade automated detection.
Configuration settings (hosts, ports, mutex, PasteBin, BDOS, HWID, server certificates) are hardcoded, AES-encrypted, and Base64-encoded.
Anti-tamper verification exits execution if modification is detected.
Mutex prevents multiple instances from running simultaneously.

Anti-analysis Measures:

Environment checks: DetectManufacturer, DetectDebugger, DetectSandbox, IsSmallDisk, IsWindowsXP.
Elevates debug privileges, monitors system shutdown/logoff, and marks itself as a critical process to resist termination.

Persistence Mechanisms:

Scheduled Task for logon execution.
Registry modification under CurrentVersion\Run.

C2 Communication & Runtime Behavior:

Connects to C2 via SSL/TCP, with fallback to PasteBin for configuration.
Continuously listens asynchronously for server commands every 5 seconds.
Dynamically handles hosts and ports, enabling flexible remote control.

Threat Assessment:

Strong anti-analysis and persistence capabilities make removal difficult.
Provides full remote access, enabling exfiltration, command execution, and potential lateral movement.
Use of PasteBin and fallback mechanisms indicates resilience against takedown attempts.

Infection Chain

Key Findings

Multi-Stage Malware Deployment

Both campaigns utilize Windows batch scripts as droppers to deliver .NET-based RAT payloads (Client.exe).
Campaign 1 (3949.bat) writes a Base64-encoded payload to disk and decodes it using certutil, while Campaign 2 downloads the executable directly from a remote URL.
The droppers employ social engineering, masquerading as legitimate Windows components, with Japanese-language prompts suggesting potential targeting of Japanese users.

Obfuscation and Anti-Analysis Techniques

The .NET payloads are heavily obfuscated with modified entry points, packed data, and dynamic assembly loading.
Early-stage initialization (.cctor) routines execute unpacking and AssemblyResolve handlers before normal program execution.
Anti-analysis features include mutex-based instance control, privilege checks, sandbox/VM detection, and runtime environment checks.
Campaign 2 adds additional anti-analysis measures such as manufacturer checks, debug detection, disk size verification, and Windows XP detection.

Dynamic Payload Loading and Execution

Embedded assemblies are stored as byte arrays, decompressed directly in memory, and executed without being written to disk.
Array2.bin is protected by a ByteGuard-like protector, while array1.bin is a straightforward .NET assembly.
Campaign 2 includes encrypted and base64-encoded configuration settings for Hosts, Ports, MTX, PasteBin, Group, and other operational parameters.

Malicious Capabilities

Persistent keylogging via Windows keyboard hooks, with captured keystrokes exfiltrated to C2 servers.
TCP/SSL C2 communication for remote command execution and packet serialization/deserialization.
Optional persistence mechanisms include startup folder copying, registry modifications, scheduled tasks, and process protection (critical process marking in Campaign 2).
Anti-termination and session-monitoring routines prevent malware removal and maintain active execution.

Campaign Infrastructure

GitHub repositories host Turkish-language scripts for DDoS, botnet, and packet-flooding operations.
CI workflows automate downloading and executing additional malware, including Mirai variants and JavaScript payloads.
Threat actor accounts (Paraloxd, iOnly699) and repository activity suggest at least a year of ongoing operations.

Geographic and Actor Attribution

Analysis of repository content, script language, and operational patterns strongly suggests the threat actor is of Turkish origin.
Japanese-language cues in the malware indicate a likely targeting focus on users in Japan.
Associated IP addresses overlap with previous AsyncRAT infrastructure, showing reuse of servers and operational consistency.

Detection and Risk Assessment

VirusTotal detections vary: one embedded DLL shows 49/72 engines detecting it as malicious, while the second shows 2/71.
Obfuscation, in-memory execution, and advanced anti-analysis techniques make detection and removal challenging.
Active campaigns, ongoing repository uploads, and automated CI workflows indicate continued threat potential and a high likelihood of future attacks.

Technical Analysis Of Campaign-1

Stage 0: 3949.bat

An initial inspection of the submitted sample (3949.bat) revealed the following metadata:

File Type: Windows Batch Script (.bat)
File Size: 2,395 bytes
MIME Type: text/plain
Detection Signature: EagleRAT
SHA256: a28e27653070e97c1bff76407eecc9f40832f265ea4373babb30669854927b3a
MD5: 241897c4d6cacc347de98f3212ba72e1
First Seen: 2025-11-02 17:01:36 UTC

The batch script attempts to impersonate a legitimate Windows component (labeled “Windows System Integrity Component” with accompanying Japanese strings), likely to social-engineer victims into trusting the file. The script creates files in the %TEMP% directory from a large embedded Base64 blob, then decodes the blob using certutil -decode into ptr_x.bat and immediately calls that file. After calling the decoded payload the script performs cleanup routines: it deletes the temporary .tmp and .bat files, clears the console (using cls), and exits. A static inspection of the decoded payload shows a PE file targeting the .NET runtime, indicating the batch file functions as a dropper/loader for a .NET executable.

Stage 1: Client.exe

Static inspection with Detect It Easy shows the payload is a .NET PE (MSIL/C#) and reports multiple heuristic flags: Modified Entry Point, bad .cctor format, and compressed/packed data. Together these signs indicate the binary has been tampered with (entry point redirection) and likely uses an obfuscator/packer to conceal its real code and metadata.

On initial inspection the assembly is heavily obfuscated (many meaningless identifiers and mangled names); I used de4dot to remove obfuscation and recover more readable IL.

The .cctor (type or module static constructor) is executed during initialization and therefore runs early in the program lifecycle. Because of this, attackers often hide startup or unpacking routines in .cctor so their code executes before normal program logic. I inspected the sample’s .cctor to identify any early-stage unpacking, decryption, or persistence behavior.

The static constructor (.cctor) registers GClass1.smethod_1 as an AssemblyResolve handler (AppDomain.CurrentDomain.AssemblyResolve += GClass1.smethod_1), meaning the handler will be invoked when the runtime fails to locate an assembly we should inspect smethod_1 next to see how it resolves or materializes assemblies (commonly via embedded/decoded payloads).

The method contains two large byte arrays that are likely used as the payload source; the routine that follows constructs or loads an assembly from those arrays.

smethod_1 implements a conditional loader based on the requested assembly name:

if (e.Name.Contains("Packet"))
- The code creates a MemoryStream over array2, wraps it with a decompression stream DeflateStream , reads the decompressed bytes into a buffer, then calls Assembly.Load(byte[]) and returns the resulting Assembly.
if (e.Name.Contains("Off"))
- The handler returns null
else
- The handler builds a MemoryStream over array and runs a deflate/decompression routine, reads the result into a byte[] and invokes Assembly.Load(byte[]), returning the loaded assembly.

At runtime, the first AssemblyResolve event is triggered for Offline, Version=3.2.4.0, Culture=neutral, PublicKeyToken=null. Because the name contains Offline, the handler returns null, causing the process to proceed and subsequently decompress array, loading it as an assembly. A second event follows for PacketLib, Version=3.2.4.0, Culture=neutral, PublicKeyToken=null, which matches the "Packet" condition the loader then decompresses array2 and loads it as another assembly. This sequence results in both assemblies being dynamically decompressed and loaded directly into memory.

The second embedded payload is protected by a ByteGuard-like .NET protector, while array1.bin is a straightforward .NET assembly (unprotected).

A quick VirusTotal lookup of the first decompressed DLL shows 49 out of 72 detections, with multiple antivirus engines classifying it as malicious.

The second decompressed payload (array2.bin) shows significantly fewer detections on VirusTotal, with only 2 out of 71 engines flagging it as malicious.

After the execution of GClass1’s static constructor (.cctor), control passes to GClass0’s .cctor, which contains a large Base64-encoded string initialized with UTF-8 encoding.

Decoding the Base64 data reveals a configuration array (list_0) with three endpoint entries:

127.0.0.1:9875 (loopback),
0.0.0.0:9875 (bind to all interfaces), and
31.57.187.119:9875 (remote IPv4 address).

Additional decoded strings include string_0 = "123456789" , string_1 which represents the mutex used to enforce a single instance (displayed as %MUTEX% in the decompiled code), and string_2 which contains the CurrentDomain.FriendlyName

Analysis of `Main`

Privilege check (GClass1.smethod_3) — Verifies administrative rights; with bool_5 == false, the process exits if the check fails.
Instance control (GClass1.smethod_0) — Creates/checks a mutex to prevent multiple instances; exits if another instance is detected.
Dynamic call (GClass1.smethod_4) — Invokes a method loaded at runtime; contents could not be analyzed statically so moving onto dynamic analysis.

Inside smethod_4() the code calls Launch.Install(GClass0.method_0, GClass0.string_2). The Install routine checks the install method enum: if it equals Method.SHT_STARTUP_FOLDER it copies the executable into the Windows startup folder to achieve persistence. In this sample GClass0.method_0 is NONE, so the startup-copy branch is disabled and no persistence action is performed.

After the call to GClass1.smethod_4(), the sample executes GClass1.class1_0 = new Class1();.

We will analyze each method in turn; first up: Class1.smethod4.

Class1.smethod4 receives data over a socket connection and returns the received content.

Class1.smethod_6() deserializes an incoming packet and returns the resulting object using the hard-coded key 123456789.

Class1.smethod_1() opens a TCP socket to a configured remote IP and port. The method wraps the connect call in a try/catch; exceptions are caught but ignored. The routine returns a Boolean: true when the connection succeeds, otherwise false.

The Function Class1.smethod_9 is responsible for the following:

Serializes a packet (IPacket) into bytes.
Creates a small header (length + packet type).
Sends the header and then the data through a socket.
Uses thread safety (lock) and chunked sending for large packets.

Execution returns to the program's Main method. From there, the code calls GClass1.smethod_2().

Inside smethod_2(), the code checks GClass0.bool_0. If the flag is true, it spawns a new thread to execute GClass1.smethod_5() and then invokes the Launch.Start() function.

Analysis of GClass1.smethod_5() indicates that it functions as a persistent keylogger, continuously capturing and exfiltrating keystroke data to the command-and-control (C2) server. The following section examines the Launch class to clarify its role in the overall execution flow.

The Launch.Start() routine executes the Hook.StartHooking() routine which spawns a dedicated thread and installs a keyboard hook using SetWindowsHookEx, allowing the application to intercept and record keystrokes across the system.

Moving onto other method's under the Launch Class:

Launch.CurrentKeyStroke() exposes the contents of the captured keystroke buffer via Hook.stolen.ToString(). Launch.ClearKeyStroke() removes all entries from the captured-keystrokes buffer. Launch.StopHook() disables the installed keyboard hook and ends the associated background thread, stopping further keystroke interception.

Lastly, the Launch.ClientSender() method.

The ClientSender method establishes a socket connection asynchronously using ClientHandler.ConnectStart(). It waits in a loop until the connection is established before sending the specified packet asynchronously with SendPacket(). This design prevents blocking the keylogging process during network communication.

Control flow returns to the Main method.

The method populates GClass0.list_1 with IP addresses and ports, then invokes Class1.smethod_0, passing class1_0 as an argument.

The code sleeps for 125 milliseconds before invoking delegate3_0 asynchronously via Class1.delegate3_0.BeginInvoke(class1_0, new AsyncCallback(Class1.smethod_2), class1_0). As discussed earlier, these delegates handle connecting to the target address, and sending and receiving serialized packets.

Control flow returns to the Main method. Finally, a new thread is started with GClass1.smethod_6 as its entry point.

The method enters an indefinite sleep loop, ensuring that the process continues running indefinitely.

Investigating The Campaign

Examination of the GitHub profile shows that the account was newly created. The repository associated with the campaign was created on September 18, marking the likely start date of the operation.

The repository’s README file contains the text 'Deneme!', which translates to 'Attempt!'.

Current observations indicate that the campaign is ongoing. The binary Client.exe, analyzed as part of this investigation, was uploaded on November 1, 2025 around five days prior to this report. A secondary binary, Deneme.exe, was also identified, suggesting continued or parallel activity within the campaign

Repository review revealed multiple scripts authored in Turkish that implement DDoS, packet-flooding, and botnet capabilities. I identified several files of interest; do check it out and let me know if you found anything interesting!

Reviewing the .github/workflows directory revealed several noteworthy files and configurations of interest.

Multiple .yml workflow files in the repository orchestrate downloading binaries or scripts (from file hosts such as curly.by, GitHub, or direct IP addresses), setting execution permission, and running them. One workflow downloads a Mirai-variant from 158.94.209.209 and executes it.

The below workflow downloads a JavaScript file from files.catbox.moe, saving it as Minecraft.js to appear legitimate, and executes it via Node.js. A similar workflow targeting Discord was also identified.

The repository also appears to leverage a Python script authored by iOnly699, indicating the use of publicly available open-source scripts for exploitation purposes.

The Tekil.yml workflow references a GitHub URL associated with the user Paraloxd. Examination of this account shows a single folder containing one executable binary (tekpoyraz) without a README, along with numerous randomly named repositories. This pattern suggests the GitHub account is controlled by the threat actor. Notably, the binary was uploaded approximately one year ago, indicating that the actor has likely been active for at least a year.

Examining the associated IP addresses related to this campaign

Analysis of campaign-related IP addresses suggests that one or more of these hosts have recently been linked to AsyncRAT malware, indicating potential reuse of infrastructure by the threat actor.

Technical Analysis of Campaign-2

Stage 0 - c93c82fb-7a26-4a15-a1bc-53a5e2d194a9.bat

This comments on this sample indicate that its a component of the AsyncRAT, lets statically analyze this batch file

It is almost the same as our previous sample, but the base64 encoded var_x differ's this time its meant to download the executable from https[:]//curl.by/UVO_V/Client.exe this hash of this sample is c4a54035839b24b1961d3066bc8090d65a2b0742416e719fae0a6074bdc6e205 and can be found on virustotal

Stage 1: AsyncClient.exe

Detect It Easy indicates that the malware family is VenomRat but its AsyncRat

I would not be doing an Indepth Analysis in this blog as it would be too long, but i would uncover what its doing.

It has a delay at the start hardcoded it would sleep for a few seconds
It has initialization settings where stuff like Hosts, Ports, Version, MTX, PasteBin ,BDOS, Group, Hwid, ServerSignature, ServerCertificate is hardcoded, but its aes encrypted + base64 encoded so first it gets the key to decrypt by base64 decoding a hardcoded value and then using it, it aes decrypts the configuration which is earlier base64 decoded then passed to decrypt, then it would verify a hash too , to check if its been modified; If its modified it exits.
Creates a mutex so that if a instance is already running this instance would exit
Anti Analysis includes : - DetectManufacturer - DetectDebugger - DetectSandbox - IsSmallDisk - IsWindowsXP
Persistence Mechanism Includes: - Creating a Scheduled Task To Run OnLogon - Registry Modification the classic CurrentVersion/Run Persistence
Next it does the following to not be killed:
- Subscribes to session-ending events – It tries to monitor or interfere with Windows shutdown/logoff to stay active or execute final actions.
- Gains debug privileges – It escalates its permissions so it can manipulate other processes, bypass restrictions, or access protected system resources.
- Marks itself as a critical process – If someone tries to terminate it, Windows will crash (blue screen), making it very hard to stop.
Next It Checks if the client is connected to the C2
- If its not then it initializes SSL/TCP
And In the end it does the following:
- Checks if the pastebin is empty
  - If it's empty its gets the Hosts and Port from Settings.Hosts and Settings.Port and connects to the client
- If its not empty then it download's the content from pastebin, stores it in an array Array[0] = Host Array[1] = Port
- Then connects to the client
At the end it Begins listening asynchronously for commands from the server with a interval of 5 seconds i.e sleeps every 5 seconds

IOC's

Indicator

Value

3949.bat

a28e27653070e97c1bff76407eecc9f40832f265ea4373babb30669854927b3a

Client.exe

17a124ee50a192fb6c92263034af0a1cc99de85920be9d4ed4359c040fd0c247

Offline.dll

7ef97f7b90bde9fc6aafc1d7acde3901554cd7a72d03fd33e23b4fdb25165f0a

PacketLib.dll

39dc2885c042dcf15512fd5d87e4cb0e18ca88e068511d7bef028a18fd1bea37

c93c82fb-7a26-4a15-a1bc-53a5e2d194a9.bat

963d036682fc67d7afa813a0b18c78952bd39c7b9fde530288b61b498debc7a9

AsyncClient.exe

c4a54035839b24b1961d3066bc8090d65a2b0742416e719fae0a6074bdc6e205

Client.exe(EagleRat) Download Url

https[:]//github.com/AhmetKesser/Deneme/raw/refs/heads/main/Client.exe

Command And Control Address

31.57.187.119:9875

Command And Control Address

31.57.187.119:8808

Command And Control Address

31.57.187.119:7707

Command And Control Address

31.57.187.119:6606

Threat Actor Github Folder

https[:]//github.com/AhmetKesser/Deneme/

Malicious File Hosting IP

158.94.209.209

AsyncRat Download Url

https[:]//curl.by/UVO_V/Client.exe

https://www.linkedin.com/in/nitin-mithbavkarwww.linkedin.com

PreviousBraodo Analysis NextTechnical Analysis of a Multi‑Stage Batch Loader Delivering QuasarRAT

Last updated 1 month ago

Executive Summary

Campaign 1 – Multi-stage Malware (3949.bat → Client.exe)

Campaign 2 – AsyncRAT/VenomRat Variant

Infection Chain

Key Findings

Technical Analysis Of Campaign-1

Stage 0: 3949.bat

Stage 1: Client.exe

Analysis of Main

Investigating The Campaign

Technical Analysis of Campaign-2

Stage 0 - c93c82fb-7a26-4a15-a1bc-53a5e2d194a9.bat

Stage 1: AsyncClient.exe

IOC's

Analysis of `Main`