Remote Access Trojan Detection

In this page

Threat snapshot

A remote access trojan (RAT) gives an attacker the ability to silently control an infected endpoint as if they were physically sitting in front of it. NetWire, one of the most widely deployed RAT families, is sold on underground markets and used by both cybercriminal groups and state-sponsored actors. Once installed, it enables keystroke logging, credential harvesting, screen capture, file transfer, and persistent access, all through an encrypted command-and-control (C2) channel that blends with normal outbound traffic.

For a business, a single undetected RAT infection can be the starting point for a full breach: intellectual property theft, credential compromise across every system the user touches, or ransomware deployment. Log360 detects RAT activity through its NetWire RAT Execution rule, correlating process creation events, network behavior, and endpoint telemetry to catch infections early, before the attacker pivots deeper into the environment.

At a glance:

Category Endpoint threat
SOC maturity level L2 - Investigation
MITRE ATT&CK® tactic Command and Control (TA0011)
MITRE ATT&CK technique T1219 | Remote Access Software
Severity High
Affected platforms Windows
Detection rule NetWire RAT Execution
Compliance mapping PCI-DSS 10.6, NIST SP 800-53 SI-3, ISO 27001 A.12.2, HIPAA §164.312(b)

How this attack works

NetWire RAT is a commercially available remote access tool that has been repurposed by threat actors for malicious campaigns since at least 2012. It is typically delivered via phishing emails containing malicious attachments (like weaponized Microsoft 365 documents, ISO files, or LNK shortcuts) or through drive-by download sites.

Once executed, NetWire establishes a persistent foothold in the victim's machine and connects to an attacker-controlled C2 server. The attacker can then issue commands remotely: Log every keystroke the victim types, capture screenshots at intervals, browse and exfiltrate files, harvest stored passwords from browsers and email clients, and even activate the webcam or microphone.

What makes RATs particularly dangerous is their ability to impersonate legitimate processes and use encrypted traffic, making them difficult to distinguish from normal application behavior without dedicated detection logic. Attackers also frequently customize the RAT's configuration by changing the executable name, C2 domain, and port to evade static signature-based detection.

Attack chain

The table below maps each stage of a NetWire RAT attack to the corresponding MITRE ATT&CK technique, showing how the threat progresses from initial delivery through to data theft.

Stage What happens MITRE ID
Initial access A phishing email with a malicious attachment or link delivers the NetWire RAT dropper to the victim. T1566
Execution The victim opens the attachment; the dropper runs and installs the NetWire RAT binary on the endpoint. T1204
Persistence The RAT writes registry run keys or scheduled tasks to ensure it restarts after reboot. T1547
Defense evasion The RAT masquerades as a legitimate process, uses obfuscated traffic, or disables endpoint security tools. T1036 / T1562
C2 The RAT beacons out to the attacker C2 server over TCP or HTTP(S); the attacker gains full remote control of the system. T1219
Collection and exfiltration The attacker harvests credentials, keystrokes, screenshots, and sensitive files; data is exfiltrated via the C2 channel. T1056 / T1041

Real-world scenario

A employee in the Finance department at a mid-sized manufacturing company receives an email appearing to come from a known logistics partner. The email contains an invoice attachment: a ZIP file with a disguised executable inside. The employee opens the file and sees nothing happen; the file appears broken. In the background, the NetWire RAT silently installs itself into the %AppData%\Microsoft folder under the filename msupdate.exe and creates a registry run key to ensure it persists across reboots.

Within minutes, the RAT beacons out to a C2 server on port 1177 over TCP. The attacker begins recording keystrokes and captures the employee's credentials for the company's ERP system, cloud file storage, and VPN. Over the next 72 hours, the attacker uses these credentials to log in from an external IP, download financial records, and map the internal network, all while the original RAT on the finance machine continues to operate undetected.

Why this happens

The attack succeeds because the employee had no reason to distrust the sender, the attachment bypassed email filtering due to a clean ZIP container, the RAT's process name and location mimicked a legitimate Windows update component, and outbound traffic to the C2 server on port 1177 was not blocked. Without visibility into process creation events and outbound connection patterns, the infection goes unnoticed for days.

Business impact: What can go wrong

If a RAT infection is not detected and contained promptly, the consequences escalate rapidly:

  • Credential compromise: Every username and password typed on the infected machine is captured, giving the attacker access to email, ERP, cloud storage, banking portals, and VPNs.
  • Data exfiltration: Sensitive business files, financial records, customer data, and intellectual property are copied to the attacker's infrastructure.
  • Lateral movement: With harvested credentials, the attacker pivots to other systems across the network, widening the breach.
  • Ransomware deployment: RATs are frequently used as a staging tool to deliver ransomware once the attacker has mapped the environment.
  • Regulatory exposure: If personal or payment data is exfiltrated, the organization may face breach notification obligations under the GDPR, HIPAA, or the PCI DSS.
  • Reputational damage: Customer trust and business relationships can be severely impacted, particularly if the attacker uses the compromised account to send further phishing emails to partners or customers.

Indicators of compromise and detection signals

Signal type What to look for
Process name netwire.exe, update.exe, svchost32.exe, or any process with randomized or lookalike names in unexpected paths
File paths Binaries dropped in %AppData%, %Temp%, %ProgramData%, or inside user profile directories
Registry keys HKCU\Software\Microsoft\Windows\CurrentVersion\Run or HKLM Run keys pointing to newly created binaries
Network indicators Outbound TCP connections to non-standard ports (e.g. 1177, 3388, or 4000); C2 beacon traffic with regular intervals
Event IDs 4688 (Process Creation), 7045 (Service Install), 1 (Sysmon Process Create), and 3 (Sysmon Network Connection)
Behavioral anomaly Process spawned by an email client (Outlook) or browser; keylogging or screenshot capture APIs called
Persistence mechanism Task Scheduler entries (event 4698) or Run key modifications created shortly after an unusual binary is written to disk

Prerequisites for detection using Log360

Before the NetWire RAT Execution rule can fire reliably, ensure the following are in place:

  • Windows security auditing is enabled on endpoints, specifically process creation auditing (so event ID 4688 is generated with full command-line logging).
  • Sysmon is deployed on endpoints for enriched process, network, and file telemetry (event IDs 1, 3, 7, and 11), which significantly improves detection fidelity.
  • Endpoint agents or Windows Event Forwarding are configured to forward security logs to Log360 in near-real-time.
  • Network logs (DNS, proxy, or firewall) are ingested into Log360 so outbound C2 connections can be correlated with process events.
  • A process baseline has been established for the endpoints being monitored, so anomalous new processes in unexpected paths stand out.

Note:

If process creation auditing is not enabled or command-line logging is absent from event ID 4688, the rule's effectiveness will be limited. Enabling Sysmon alongside Windows native auditing is strongly recommended for the best detection coverage.

Detecting RAT activity using Log360

Once log collection is configured, follow these steps to enable and tune RAT detection in Log360:

Step 1: Enable the detection rule

Navigate to Security > Manage Rules > Rule Library in the Log360 console. Search for NetWire and enable the NetWire RAT Execution rule. This rule triggers when process creation events match known NetWire RAT execution patterns, including specific binary names, file path signatures, and parent process relationships.

Step 2: Tune the rule for your environment

After enabling the rule, open its configuration and adjust the following:

  • Allow any legitimate administrative tools that match similar naming patterns in your environment.
  • Define the expected directory scope: Flag processes running from %AppData%, %Temp%, %ProgramData%, or user home directories as higher priority.

Step 3: Read the alert

When the rule fires, the alert will display the process name and path, the parent process that spawned it, the user account context, the host it ran on, and the timestamp. Pay close attention to parent processes. A RAT spawned by Outlook.exe, Chrome.exe, or WScript.exe is a strong indicator of a phishing-delivered infection.

Investigating an alert

When a NetWire RAT alert fires, an L2 analyst should work through the following investigation steps before declaring a confirmed incident:

  • Confirm the process: Verify the binary's file path, hash, and digital signature. Legitimate system processes will be signed by Microsoft and reside in expected directories.
  • Check the parent process: Identify what launched the suspicious binary. A browser, email client, or script interpreter as a parent process strongly indicates a phishing delivery vector.
  • Correlate network activity: Use Log360 to check whether the endpoint made outbound connections on uncommon ports (e.g. 1177, 3388, or 4000) or to newly registered domains around the time of execution.
  • Check persistence mechanisms: Look for registry Run key changes (event 4657) or new scheduled tasks (event 4698) created in the same time window as the suspicious process.
  • Review user activity: Check recent logins for the affected account, including VPN and cloud service access, to determine whether stolen credentials may already have been used.
  • Scope the infection: Search across all endpoints for the same binary hash, file path pattern, or C2 IP or domain to determine whether the infection is isolated or has spread.

Escalation trigger

If you confirm outbound C2 connectivity, registry persistence, or evidence of credential harvesting activity, escalate immediately to L3 incident response. Time is critical: The longer the RAT operates, the broader the credential and data exposure.

Responding and remediating

Immediate containment

  • Isolate the infected endpoint from the network immediately, either via EDR network isolation or by disabling its network interface.
  • Disable the affected user account and force password reset for all accounts the user had access to, particularly privileged ones.
  • Block the identified C2 IP addresses and domains at the firewall and DNS layer.

Forensic preservation

  • Capture a memory image of the infected endpoint before rebooting or wiping, as the RAT and its configuration may be loaded only in memory.
  • Preserve event logs, Sysmon logs, and network flow records covering the period from suspected infection to containment.
  • Extract the RAT binary and submit it to a sandbox (e.g. Any.run or Hybrid Analysis) for full behavioral analysis and indicator of compromise (IoC) extraction.

Eradication and recovery

  • Remove the RAT binary and all associated files identified during investigation.
  • Delete persistence mechanisms: Remove malicious registry run keys and scheduled tasks.
  • Rebuild the endpoint from a clean image if memory forensics indicates deep system compromise.
  • Rotate all credentials that may have been exposed, including service accounts, VPN credentials, and cloud access keys.
  • Verify eradication by running a targeted threat hunt across the environment for the same IoCs before returning the endpoint to service.

False positive guidance

The following legitimate activities may occasionally trigger the NetWire RAT Execution rule. Use these criteria to quickly rule them out before escalating:

  • Remote administration tools: Legitimate tools such as TeamViewer, AnyDesk, or remote support agents used by IT may share behavioral characteristics with RATs. Verify that the tool is in the approved software list and was installed through an authorized process.
  • Software updates: Update agents for third-party software sometimes run from temporary or application data directories. Confirm the binary is signed and originates from a known vendor.
  • Developer or pentest activity: Security teams running authorized red team exercises or developers testing remote access functionality may trigger this rule. Cross-reference with the change management register.
  • Newly deployed applications: Freshly installed, legitimate software may match path-based heuristics before it is added to the baseline. Verify the installation source and allowlist after confirmation.

Key differentiator

A genuine RAT will almost always show outbound network connections to external IPs shortly after process creation. If the suspicious process has no outbound network activity and is signed by a known vendor, it is very likely a false positive. Network correlation is your most reliable triage filter.

Hardening and prevention

Detection is most effective when paired with a reduced attack surface. The following controls make it significantly harder for a RAT to be delivered, installed, or operate undetected:

  • Email filtering: Deploy advanced email security with attachment sandboxing and link scanning to catch RAT delivery before it reaches the endpoint.
  • Application allowlisting: Restrict which executables can run on endpoints, preventing unsigned or unknown binaries from executing even if delivered successfully.
  • Outbound firewall rules: Block or alert on outbound traffic to non-standard ports and newly registered domains; restrict which processes are permitted to make external connections.
  • Least privilege: Ensure users operate with standard accounts rather than local administrator rights, limiting a RAT's ability to install persistence mechanisms or disable security tools.
  • Endpoint security: Maintain up-to-date EDR and antivirus on all endpoints and ensure tamper protection is enabled so a RAT cannot disable it.
  • User awareness training: Educate staff on phishing recognition, particularly around unsolicited attachments from external senders, even when they appear to come from known contacts.
  • Sysmon deployment: Deploy Sysmon with a comprehensive configuration (such as the SwiftOnSecurity or Olaf Hartong configurations) to give Log360 the process, network, and file telemetry needed for accurate RAT detection.