Remcos RAT - How to Detect

Last updated: 2026-04-01

Remcos RAT Detection Guide

Behavioral Indicators

Remcos RAT exhibits several distinct runtime behaviors that can be detected through process monitoring and API hooking. Upon execution, the malware typically spawns a child process, often a legitimate system binary like rundll32.exe, regsvr32.exe, or a spawned cmd.exe, to inject its core payload and evade simple parent-process analysis. This process hollowing or DLL side-loading technique creates a suspicious process chain where a short-lived initial dropper launches a trusted process that then performs anomalous network and system activities.

Key API calls to monitor include the use of CreateProcessInternalW for process creation, VirtualAllocEx and WriteProcessMemory for code injection, and SetWindowsHookEx for keystroke logging. Remcos frequently uses the WinHttp or WinINet libraries for C2 communication, so calls to WinHttpConnect or InternetConnectA/W to non-standard ports (often 80, 443, or high random ports) from a process like explorer.exe or a system utility are highly suspicious. For credential access, Remcos uses API calls like CredEnumerateW to enumerate stored credentials and may attempt to dump LSASS process memory using MiniDumpWriteDump or direct PSSetSnapshot APIs, often from an unexpected process context.

Look for processes that rapidly perform a combination of these actions: establishing a network connection, setting registry auto-run keys, creating mutexes (often with names like “Remcos” or “RC*”), and initiating keystroke logging or screen capture threads. The malware also commonly disables Windows Defender and other security tools using registry modifications (SOFTWARE\Microsoft\Windows Defender) or sc command execution, which creates a clear behavioral signature.

Network Indicators

Remcos RAT communicates with its command-and-control (C2) server using a custom binary protocol over TCP. While earlier versions used plain TCP, recent variants almost exclusively use TLS-encrypted channels on ports 443 or 8443 to blend with normal HTTPS traffic. Despite encryption, the communication pattern shows identifiable beaconing. Beacons are sent at regular intervals, typically between 30 seconds and 5 minutes, with the initial beacon occurring shortly after infection. The beacon packet usually contains a fixed-size header (often 8-16 bytes) followed by encrypted system information.

DNS queries often precede the TCP connection. Look for DNS requests to recently registered domains (checkable via WHOIS age) or domains with algorithmically generated names (e.g., abckl123[.]com, xqwe90p[.]net). These domains may have short TTL values (300 seconds or less) to facilitate fast flux. The User-Agent string in the TLS handshake or HTTP layer (if used) is sometimes generic (e.g., “Mozilla/5.0”) or may contain a hard-coded identifier like “Remcos”.

Data exfiltration occurs in bursts following C2 commands. Traffic patterns show small, periodic outbound packets (beacons) with occasional larger outbound transfers (captured files, keystrokes) and small inbound packets (commands). Use network monitoring to detect these consistent, low-volume data flows to external IPs on standard web ports from non-browser processes. The C2 response is typically very small (a few bytes to a few hundred bytes), containing encoded commands.

File System Artifacts

Remcos drops several files in predictable locations. The initial dropper is often a small executable delivered via phishing email or downloader, with names mimicking legitimate files (e.g., invoice.exe, document.pdf.exe). After execution, it extracts and installs the main payload. Common installation directories include:

  • %AppData%\Microsoft\
  • %AppData%\Microsoft\Windows\
  • %LocalAppData%\Temp\
  • %ProgramData%\
  • %Public%\

The main payload DLL or EXE frequently uses names like mscoree.dll, winlogui.exe, or svchost.exe placed in these user-writeable paths to avoid system-protected locations. File sizes vary by version but often range from 300KB to 800KB for the core payload. Configuration files or log files (e.g., for keylogs) may be created with names like log.dat, config.bin, or tmp.tmp in the same directory.

Timestamps can be a tell; the dropped files often have creation times very close to the initial infection time, while the modified time may be updated as the malware writes logs. Some versions create a hidden file or directory. Also check for recently created executable files in the above paths that have low prevalence on your network.

Registry and Persistence Mechanisms

Remcos achieves persistence through multiple registry autostart entries. The most common is the Run key in either HKEY_CURRENT_USER or HKEY_LOCAL_MACHINE:

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

The value name often mimics legitimate software (e.g., “Windows Defender”, “Java Update”) and points to the path of the dropped executable or a DLL to be loaded via rundll32. Another common method is using the RunOnce key or the Policies\Explorer\Run key.

Scheduled tasks are also frequently used for persistence and evasion. Tasks are created with names like “GoogleUpdateTask”, “OneDriveSync”, or “SystemCheck” using the Windows Task Scheduler (schtasks). The action typically runs the payload directly or executes a script that loads it. The task is often configured to run at user logon or at frequent intervals (e.g., every hour).

Additionally, Remcos may set file type associations (e.g., HKCU\Software\Classes\.txt\shell\open\command) or use DLL search order hijacking by placing its DLL in a directory alongside a legitimate application. Some variants install a Windows service, especially if running with administrative privileges, by creating entries under HKLM\System\CurrentControlSet\Services. Always cross-reference these persistence entries with the file system artifacts mentioned above.

YARA Rule Guidance

When crafting YARA rules for Remcos, focus on both plain-text strings and unique byte patterns from unpacked samples. Key strings to include are the mutex names, which often contain “Remcos”, “RAT”, “Client”, or “Server” (e.g., “RemcosMutex”, “RATClient*”). Also look for hard-coded C2 domain fragments, path strings like \Microsoft\ in user AppData, and debug strings that may be left in the binary, such as “Remcos Professional” or “Connection established”.

For byte patterns, analyze the network protocol structure. The initial beacon packet often has a consistent magic byte header - in some versions, it’s the bytes 52 43 54 (“RCT” in hex). Look for sequences of API function names used by the malware, like WinHttpConnect, CreateRemoteThread, and SetWindowsHookExA, which are often imported or resolved dynamically. The code section may contain distinctive sequences of instructions used for process injection or anti-debugging checks.

Consider the overall structure: Remcos payloads often have a large resource section (RT_RCDATA) containing an encrypted configuration or additional module. Rules can check for the presence of a large resource with a specific name or type. Since Remcos is frequently packed with commercial packers like VMProtect or custom obfuscation, aim to write rules for the unpacked payload in memory or use static signatures that target the unpacking stub’s unique characteristics, such as specific sequence of push/pop instructions or entropy thresholds in certain sections.