AsyncRAT Detection Guide

Behavioral Indicators

AsyncRAT exhibits several distinct runtime behaviors that can be detected through process monitoring and API hooking. The malware typically injects its core payload into a legitimate system process, commonly targeting explorer.exe, svchost.exe, or msiexec.exe. Monitor for process hollowing where a legitimate process is spawned in a suspended state, its memory is unmapped and replaced with malicious code, and then resumed. The injection chain often originates from a dropper executable or a decoy document.

Key API calls to monitor include VirtualAllocEx and WriteProcessMemory for code injection, CreateRemoteThread for executing the injected code within the target process, and RegSetValueEx for establishing persistence. For credential access, AsyncRAT uses Windows Credential Manager API calls such as CredEnumerateW and CredReadW to harvest stored credentials. It also performs keylogging by setting low-level keyboard hooks via SetWindowsHookEx with the WH_KEYBOARD_LL identifier. The malware exhibits reconnaissance behavior by querying system information using GetSystemInfo, GetComputerNameW, and GetUserNameW. Process creation chains often show a parent process (like a document reader) spawning cmd.exe or powershell.exe to execute a series of commands that ultimately download and execute the AsyncRAT payload.

Network Indicators

AsyncRAT communicates with its command-and-control (C2) server primarily over TCP, though variants may use HTTP or HTTPS for blending with normal traffic. The C2 protocol is custom but typically involves an initial beacon containing system information (hostname, username, OS version) followed by a persistent socket waiting for commands. Beaconing intervals are often configurable but commonly range from 10 to 60 seconds. The initial beacon is usually a small packet (under 1KB) with a base64-encoded or XOR-obfuscated payload.

DNS queries may reveal suspicious domain names often generated by Domain Generation Algorithms (DGAs) or using subdomains of free dynamic DNS services. Look for domains with random alphanumeric strings or common misspellings of popular sites. In HTTPS variants, the malware may use a hardcoded server certificate or ignore certificate validation errors. Data exfiltration occurs over the established C2 channel, often with traffic showing irregular patterns-small, periodic outbound packets (beacons) followed by larger bursts of data when commands are executed or files are uploaded. Use a SIEM platform or network monitoring tool to detect these patterns: consistent outgoing connections to uncommon ports (e.g., 6606, 4782, 5555) and failed connection attempts to known-bad IPs from the IOCs list.

File System Artifacts

AsyncRAT drops several files to maintain operation and persistence. The initial dropper is often a downloaded executable with a generic name like update.exe, installer.exe, or disguised as a document (e.g., invoice.pdf.exe). After execution, it typically extracts the core RAT component to a temporary directory or the user’s AppData folder.

Common file paths include:

• %AppData%\Microsoft\Windows\Start Menu\Programs\Startup\ for user-level persistence.
• %AppData%\Roaming\ with folders named after legitimate software (e.g., Google\Chrome\).
• %Temp%\ with randomly named executables (e.g., tmp3A2.tmp.exe).
• %SystemRoot%\System32\ or %SystemRoot%\SysWOW64\ for system-level drops (requires admin privileges).

File naming conventions often involve misspellings of system files (e.g., scvhost.exe, expl0rer.exe) or use of spaces to mimic document names (e.g., document .exe). The core AsyncRAT payload is typically a .NET executable, so file sizes often range from 100KB to 500KB. Timestamps may be inconsistent with other files in the directory, showing recent creation dates but older modification dates due to timestomping. Check for executable files with low prevalence scores or files that have been recently created in startup locations.

Registry and Persistence Mechanisms

AsyncRAT employs multiple persistence mechanisms to survive reboots. The most common method is via the Windows Registry Run keys.

Monitor these registry keys for suspicious entries:

• HKCU\Software\Microsoft\Windows\CurrentVersion\Run
• HKLM\Software\Microsoft\Windows\CurrentVersion\Run
• HKCU\Software\Microsoft\Windows\CurrentVersion\RunOnce
• HKLM\Software\Microsoft\Windows\CurrentVersion\RunOnce

Entries typically point to the dropped executable in AppData or Temp directories. The malware may also use file extension hijacking by modifying the HKCU\Software\Classes\<filetype>\shell\open\command key to intercept execution of specific file types.

Scheduled tasks are another common persistence vector. Look for tasks created with random names or names mimicking system tasks (e.g., “GoogleUpdateTaskMachine”). Tasks are often configured to run at user logon or at specific intervals, triggering the RAT executable. Use the built-in Task Scheduler or command-line tools to list and inspect tasks for suspicious actions pointing to AsyncRAT file paths.

For elevated privileges, AsyncRAT may create a Windows Service, adding an entry under HKLM\System\CurrentControlSet\Services\. Service names often resemble legitimate ones, such as “WinDefendSvc” or “NetSvc”. Additionally, check for WMI event subscriptions (root\Subscription) that can be used for persistence by triggering the malware based on system events.

YARA Rule Guidance

When crafting YARA rules for AsyncRAT, focus on the unique strings and byte patterns present in its .NET-based payloads. The malware often contains hardcoded strings related to its functionality and C2 communication.

Target these key strings:

• C2 server addresses or IPs in plaintext or simple obfuscation (base64, XOR).
• Command identifiers like “remoteview”, “keylog”, “download”, “upload”, “cmd”.
• Configuration strings such as “mutex”, “install”, “persistence”, “startup”.
• Error messages or debug strings that may be left in the binary.
• Class and method names common in AsyncRAT variants, like “ClientSocket”, “PacketHandler”, “Recovery”.

Look for structural characteristics: AsyncRAT is typically compiled for the .NET framework, so rule conditions should include checks for the .NET assembly metadata (e.g., pe.characteristics & 0x2000 for DLL, or presence of the .text section with .NET opcodes). The malware often uses simple XOR encryption with a single-byte key for strings; consider including patterns of XOR-encoded strings followed by their decryption routines. Also, target the unique mutex names AsyncRAT creates, which often follow patterns like “AsyncMutex” followed by random characters.

For byte patterns, examine the initial network packet structure. The first few bytes of the network module may contain specific sequences for socket initialization. Use the samples provided to extract these opcode sequences or constant values used in the C2 protocol handshake.

Remember to combine these elements with conditions on file size and entropy to reduce false positives. Always test rules against the latest samples from the provided link to ensure they catch new variants while avoiding legitimate software.