RATs & Device Malware

One-line relationship: the class of threat that everything else in this portal structurally can’t stop — a compromised, already-trusted device is why C6 (fraud & malware detection) exists as its own capability rather than being subsumed by C1–C5.

What it is

A Remote Access Trojan (RAT) gives an attacker live, hands-on-keyboard control of a victim’s device — not a stolen credential replayed later, but the attacker literally operating the victim’s own session, on the victim’s own device, past whatever authentication already succeeded. Related patterns:

• Overlay attacks — malware draws a fake UI on top of a genuine app (mobile-native in origin; web variants exist as malicious browser extensions rendering convincing overlays) to capture input the user believes they’re entering into the real interface.
• Emulators / automation frameworks — running the app (or driving a browser) in a non-genuine, scripted environment, typically to automate fraud at scale rather than target one victim.

Why hardware binding doesn’t help here

This is the sharpest version of the phishing-resistant-vs-phishing-proof line this portal keeps drawing: a passkey defeats credential replay perfectly, and a DPoP-bound token defeats token theft perfectly — but neither does anything against an attacker who is already inside the authenticated session on the genuine, trusted device. The mobile app’s hardware-bound enclave key implicitly narrowed this risk somewhat (a RAT would need to also compromise the OS sandbox to reach the enclave), but on the web, once malware has control of the browser or the OS beneath it, every cryptographic guarantee this portal has built still holds and is still irrelevant — the attacker isn’t forging anything, they’re driving the real, correctly-authenticated session.

Why this must be detected, not prevented, by the auth layer

This is precisely why C6 exists as its own capability: detection SDKs, malware signature databases, and behavioral anomaly detection (see Behavioral Biometrics) are the actual defense here, not stronger authentication. Authentication answers “is this the right person/client,” which a RAT session trivially satisfies; C6 answers “is this environment compromised,” a structurally different question that no amount of PKCE, DPoP, or WebAuthn hardening touches.

What to take to the client

If a client asks “we’ve done passkeys and DPoP, are we done with web-auth security?” — RATs are the answer to why not. Authentication-layer controls close the credential-theft and token-theft classes of attack completely; they leave the compromised-device class entirely untouched, which is why device/malware intelligence (C6) is load-bearing infrastructure, not a nice-to-have bolt-on.