Remote Access Trojan

Expanded Definition

A remote access trojan, or RAT, is a form of malicious software designed to give an attacker remote, interactive control over a victim system after initial compromise. Unlike a simple dropper or one-shot payload, a RAT usually establishes persistence, maintains a command channel, and supports tasking such as file theft, screen capture, process manipulation, lateral movement, or staged payload delivery. In practice, the term is used in incident response, malware analysis, and threat hunting to describe the attacker controlled agent that remains on endpoint or server infrastructure.

Definitions are broadly consistent across the security industry, but operational use varies: some teams use RAT to describe any remote administration malware, while others reserve it for stealthy, unauthorized implants that evade detection. For governance and control mapping, the important distinction is not the label itself but the capability set, especially persistence, remote command execution, and covert communications. That aligns closely with control expectations in NIST SP 800-53 Rev 5 Security and Privacy Controls, where monitoring, access control, and incident response help detect and contain malicious remote control activity. The most common misapplication is treating a RAT as a generic virus, which occurs when analysts overlook the attacker’s ongoing interactive control and focus only on the initial infection vector.

Examples and Use Cases

Implementing detection and containment for RAT activity rigorously often introduces more telemetry and tuning overhead, requiring organisations to weigh visibility against alert volume and endpoint performance.

• A phishing campaign delivers a loader that installs a RAT, then uses the command channel to enumerate local users, network shares, and security tools.
• An attacker abuses a trojanised software update to implant remote control capability, then maintains access through scheduled tasks and registry-based persistence.
• A security team finds a RAT on a finance workstation after unusual outbound connections appear in proxy logs and the endpoint begins launching child processes on command.
• Incident responders use memory analysis and network indicators to determine whether the implant is a full RAT or a lighter backdoor with only limited tasking support.
• In environments with autonomous services and agents, defenders also review non-human identity exposure because stolen API keys or service credentials can be used to support RAT-driven post-compromise actions, a concern echoed in the OWASP Non-Human Identity Top 10.

Why It Matters for Security Teams

RATs matter because they turn a single successful intrusion into durable attacker presence. Once deployed, they can undermine endpoint trust, hide follow-on activity, and complicate containment by blending remote administration features with covert command and control. Security teams need to understand RAT behavior to distinguish between legitimate remote support tooling and unauthorized operator access, especially where endpoint control is paired with stolen credentials, token abuse, or disguised scheduled automation.

The identity connection is often overlooked: after initial execution, a RAT frequently becomes the mechanism through which attackers harvest secrets, pivot into privileged accounts, and abuse non-human identities to extend access beyond the original host. That makes identity monitoring, network egress control, and endpoint telemetry inseparable from malware response. Organisations typically encounter the full operational cost only after data theft, ransomware staging, or repeated re-entry events, at which point RAT eradication and privilege review become operationally unavoidable to address.

Related resources from NHI Mgmt Group

• How should security teams reduce ransomware risk from remote access credentials?
• What is the difference between remote access and least-privilege proxy publishing?
• How can teams reduce blast radius for remote and machine access?
• What should teams do when remote access still depends on legacy SSH trust?