Remote Access Trojans (RATs) Guide: How RATs Operate and How to Detect Them

A remote access trojan (RAT) is malware that, once run by a deceived user, gives an attacker hidden, ongoing control of the computer as if they were sitting at it. The attacker can run commands, move files, watch the screen and record keystrokes, usually over an encrypted connection that looks like normal web traffic. This explainer covers what RATs can do in general terms, the families defenders meet most often, the network and host signals that reveal them, the growing abuse of legitimate remote monitoring and management (RMM) software for the same purpose, and how to respond and eradicate. It is for SOC analysts, incident responders and endpoint engineers, and it is strictly defensive: it contains no builder, configuration or operator detail.

Key takeaways

• A RAT is a trojan with a steering wheel. The trojan part is how it arrives (the user runs it); the RAT part is what it gives the attacker: interactive, persistent control.
• Families are cheap and shared. ATT&CK lists commodity RATs such as njRAT (S0385), Remcos (S0332), AsyncRAT (S1087) and QuasarRAT (S0262) that are open source, sold or cracked, so the family name says little about who is behind an intrusion.
• Legitimate RMM tools are the RAT that antivirus ignores. CISA, NSA and MS-ISAC warned that RMM software lets attackers avoid custom malware and that such software generally does not trigger antivirus or antimalware alerts (paraphrased).
• Detect the behaviour, not the brand. Persistent, regular outbound connections from an unexpected process, plus keylogging, screen capture and credential-store access on the host, catch both custom RATs and abused RMM.
• Eradication means credentials too. RATs capture passwords, session cookies and tokens (T1056.001, T1539, T1528), so a rebuild without password resets and session revocation leaves the attacker a way back in.

What it is

A RAT combines two ideas. The trojan element is deception: it arrives disguised as a document, installer or update and the victim executes it (see the Trojans Guide). The remote access element is a client that connects to an attacker-controlled server and waits for instructions, giving the operator the same capabilities a helpdesk technician has, without consent or visibility. Security vendors also use "backdoor" for the same thing; in practice "backdoor" stresses hidden re-entry and "RAT" stresses interactive control.

RATs are not inherently sophisticated. ATT&CK describes njRAT as first observed in 2012, QuasarRAT as publicly available on GitHub since at least 2014, NanoCore (S0336) as a modular .NET tool used since 2013, and WarzoneRAT (S0670) as malware-as-a-service sold since at least late 2018. Remcos is described as marketed as remote control and surveillance software by a company, and observed in malware campaigns. Low cost is exactly why they appear in fraud, espionage and pre-ransomware intrusions alike.

Capabilities in general terms

How it works

1. Delivery: phishing attachments and links (T1566.001, T1566.002), fake installers and malvertising (T1583.008), cracked software, or a loader that installs the RAT as a second stage. Crypters and loader chains such as Snip3 (S1086), which ATT&CK links to AsyncRAT and other RAT deliveries, wrap the RAT to avoid detection.
2. Installation and persistence: the RAT copies itself to a user-writable folder under a believable name (T1036.005) and adds a Run key, scheduled task or service.
3. Check-in: it contacts its controller, typically over HTTPS or a custom TCP protocol on a non-standard port, often through dynamic DNS names or rented hosting, and sends basic host details.
4. Operation: the operator browses files, captures credentials and screens, and pulls down further tools. Most commodity RATs keep a long-lived connection rather than occasional beacons, which helps detection.
5. Expansion: stolen credentials are reused against VPN, cloud and email (T1078 Valid Accounts), often from the attacker's own infrastructure, so the RAT is no longer needed for access.

The channel itself is the subject of the Command and Control (C2) Guide, which covers beaconing analysis, TLS fingerprints and DNS analytics in depth; this guide does not repeat them.

Abuse of legitimate RMM tools

Attackers increasingly skip the RAT and use the real thing. In advisory AA23-025A (January 2023) CISA, NSA and MS-ISAC described help-desk-themed phishing that led victims to download portable copies of ScreenConnect and AnyDesk, configured to connect to the attacker's own server, then used to run a bank refund scam. Because portable RMM runs in the user's context, the advisory notes it can bypass both administrative privilege requirements and software management controls. ATT&CK tracks this as T1219 Remote Access Tools and T1219.002 Remote Desktop Software.

See the RMM Tool Security Guide for hardening the tools you do approve, and the Callback Phishing (TOAD) Guide for the phone-led lures that deliver them.

Why it matters

A RAT turns one deceived user into an attacker-controlled workstation inside the trust boundary, with that user's network position, saved passwords and signed-in sessions. That makes it a fraud tool against individuals and a staging point for enterprise intrusion. Because the identity material it steals keeps working after the malware is removed, a RAT incident is as much an identity incident as an endpoint one. The Snowflake breach illustrates the downstream risk: credentials harvested from infected endpoints, never rotated, were replayed against accounts without MFA long after the original infections.

Detection signals

For hunting queries over this telemetry, see the Threat Hunting Guide and the Sysmon Guide.

Prevention and rollout

1. Inventory remote access: list every RMM and remote desktop product in use and approve a short list, as AA23-025A recommends.
2. Audit, then enforce application control: run App Control for Business or AppLocker in audit mode to find unapproved RMM and unknown executables, then block on a pilot ring before wider enforcement; roll back by reverting the device group to audit.
3. Restrict network paths: allow approved RMM only through approved routes (VPN or virtual desktop), and block other RMM domains and ports at the perimeter.
4. Enable behaviour rules: EDR behaviour monitoring and the relevant attack surface reduction rules in block mode.
5. Harden identity: phishing-resistant MFA and token protection reduce the value of stolen passwords and cookies. See the Phishing-Resistant MFA Guide.

Smaller organisations with a managed service provider should confirm which RMM the provider uses, block all others, and ask the provider for session logs on request. Larger organisations should treat unapproved RMM as an incident trigger, not a policy violation, because legitimate users rarely need a second remote support tool.

Response and eradication

1. Isolate the host through EDR, keeping the EDR channel open; in Defender for Endpoint, selective isolation helps where VPN or proxy setups would otherwise cut the device off from the service.
2. Preserve evidence: collect the investigation package (processes, network connections, autoruns, scheduled tasks, event logs) and, for RMM abuse, export the vendor's session and account logs before they age out.
3. Scope: search the estate for the binary hash, persistence name, C2 domain or RMM relay identifier, and check identity logs for the user's accounts.
4. Reset and revoke: reset every password used on the device, revoke sign-in sessions and refresh tokens (in Microsoft Entra ID, "Revoke sessions" or Revoke-MgUserSignInSession), and rotate API keys, SSH keys and tokens stored there. Existing access tokens stay valid until expiry (one hour by default in Entra ID) unless the application supports Continuous Access Evaluation, and application-issued session cookies must be revoked by each application. See the Token and Session Security Guide.
5. Rebuild: reimage the device; do not rely on removing the RAT, because the operator may have installed further tools.
6. Close the entry route and add the lure, domain and RMM account to blocklists.

Metrics

• Number of unapproved RMM executions detected per month, and time to block.
• Percentage of endpoints with application control enforced.
• Mean time from first RAT network connection to host isolation.
• Percentage of RAT incidents with all credentials reset and sessions revoked within 24 hours.
• Number of post-remediation sign-ins from attacker infrastructure (target: zero).

Common misconceptions

• "No malware alert, so no RAT": abused RMM tools are signed and clean, which is exactly why attackers choose them.
• "Blocking the C2 domain ends it": RATs carry fallback addresses and the operator already holds stolen credentials and cookies.
• "Removing the binary is enough": without rebuilding and checking persistence, scheduled tasks and second-stage tools, reinfection is common.
• "MFA protects the accounts": a stolen session cookie is issued after MFA, so replay bypasses it until the session is revoked. See the Session Hijacking and Cookie Theft Guide.
• "The family tells us the actor": commodity RATs are used by many groups; attribution needs infrastructure and behaviour, not the RAT name.
• "Our MSP's RMM is trusted, so any RMM is fine": the risk is a second, unapproved tool or an attacker using the approved tool with stolen provider credentials.

Related concepts

• Trojan: the delivery category RATs belong to. See the Trojans Guide.
• C2 frameworks: tools such as Cobalt Strike (S0154) offer RAT-like control for operators and red teams; covered in the Command and Control (C2) Guide.
• Infostealer: steals credentials and exits, where a RAT stays. See the Infostealer Threat Guide.
• Mobile RATs and spyware: covered in the Mobile Malware Guide.
• Remote Desktop Protocol abuse: using RDP with stolen credentials (T1021.001) gives similar control without malware. See the Remote Desktop (RDP) Security Guide.

Framework mapping

Practitioner checklist

• Publish an approved remote access tools list and block all other RMM with application control.
• Alert on any RMM binary running from a user folder or installed outside your software deployment process.
• Correlate outbound connections with process, path and signer, and alert on user-folder processes holding long-lived connections.
• Enable EDR behaviour detection for keylogging, screen capture and browser credential-store access.
• Restrict approved RMM to VPN or virtual desktop paths and block other RMM domains and ports.
• Write the RAT runbook to include password reset, session revocation, token rotation and reimage, not just binary removal.
• Retain RMM vendor session logs and identity sign-in logs long enough to scope an incident.
• Confirm with managed service providers which RMM they use and how their access is protected.

Standards and references

• CISA: Protecting Against Malicious Use of Remote Monitoring and Management Software (AA23-025A)
• MITRE ATT&CK: Remote Access Tools (T1219)
• MITRE ATT&CK: AsyncRAT (S1087)
• MITRE ATT&CK: Input Capture, Keylogging (T1056.001)
• NIST: SP 800-83 Rev. 1, Guide to Malware Incident Prevention and Handling for Desktops and Laptops
• NCSC: Mitigating malware and ransomware attacks
• Microsoft Learn: Take response actions on a device
• Microsoft Learn: Revoke user access in Microsoft Entra ID

Related NHI Mgmt Group resources: Trojans Guide · Command and Control (C2) Guide · RMM Tool Security Guide · Malware Guide · Identity Incident Response Playbook