RATANKBA is a banking Trojan family that steals credentials and manipulates online banking sessions. It typically targets users through malicious downloads or fake updates, then records keystrokes, injects web content, and can enable unauthorised transfers. Defenders should watch for suspicious browser injection, credential theft, and unusual banking login behaviour.
What RATANKBA Is and How It Works
RATANKBA is banking malware built to steal financial credentials and manipulate authenticated browser sessions. Its value to attackers comes from living inside the banking workflow, where keystrokes, page content, and transaction steps can all be intercepted or altered before the victim notices.
That makes RATANKBA more than a simple password stealer. Once the user reaches an online bank or payment portal, the Trojan can turn a legitimate session into an attacker-controlled transaction path, which is why session integrity matters as much as initial login security.
Attack Path and Delivery Methods
This family is typically delivered through malicious downloads or fake updates, which means the first security problem is often execution by deception rather than a network exploit. The malware then relies on the victim launching or approving the payload, after which it can persist long enough to harvest inputs and manipulate browser activity.
Delivery through fake updates is especially effective because it abuses user trust in routine software maintenance. The banking component is not necessarily the initial entry point; it is the target the attacker reaches after establishing code execution on the endpoint.
Credential Theft and Session Manipulation
RATANKBA is dangerous because it combines credential theft with active session tampering. Keystroke logging can capture usernames, passwords, one-time codes, and other typed secrets, while web injection can overlay false content, change payee details, or present fraudulent prompts inside a real banking session.
That mix defeats controls that only look for stolen passwords. Even when the user authenticates successfully, the attacker may still be able to alter the transaction in transit, which makes browser integrity and transaction verification critical defensive concerns.
Detection and Response for Banking Trojan Activity
Defenders should look for suspicious browser injection, unexpected changes to banking pages, unusual login timing, and transfers that do not match the user’s normal behaviour. Endpoint telemetry is important because the relevant signals often appear on the host before they are visible in the banking application itself.
After suspected compromise, analysts should assume exposed credentials and active sessions may no longer be trustworthy. Review browser and endpoint artefacts, confirm whether fraudulent transfers occurred, and treat any banking access used during the infection window as potentially compromised.
Risk and Threat Considerations
RATANKBA creates direct financial fraud risk because it can turn a valid banking login into an unauthorised payment event. The threat is not limited to stolen passwords, it also includes session hijacking, transaction manipulation, and invisible changes to what the user sees before confirming a transfer.
Failure mechanism: The malware captures authentication material or hijacks an active browser session, then injects or rewrites online banking content so the victim unknowingly approves attacker-controlled activity.
Impact: Organisations and customers can suffer unauthorised transfers, account compromise, fraud investigation overhead, and loss of trust in the integrity of online banking channels.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
MITRE ATT&CK addresses the attack and risk surface, while NIST SP 800-53 Rev 5 sets the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| MITRE ATT&CK | T1056 — Input Capture | RATANKBA logs keystrokes and captures user input during banking sessions. |
| T1185 — Browser Session Hijacking | The Trojan manipulates online banking sessions through browser injection and session abuse. | |
| T1566 — Phishing | Malicious downloads and fake updates commonly deliver the Trojan through user deception. | |
| Recommendation — Correlate input-capture behaviour with endpoint telemetry and hunting for credential theft. Inspect browser and session anomalies for signs of hijacking or injected content. Hunt for deceptive delivery chains and block fake-update lures at the user and web layers. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | Credential theft makes the lifecycle and protection of authenticators central to recovery. |
| SI-3 — Malicious Code Protection | The term describes endpoint malware that requires detection and blocking of malicious code. | |
| Recommendation — Rotate exposed authenticators and invalidate compromised credentials after suspected infection. Deploy malicious code protection and tune it for banking Trojan delivery and execution. | ||
Practitioner Guidance
Why practitioners should care: Banking Trojans are not only credential theft problems, they are transaction integrity problems. Security teams should treat browser manipulation as a sign that the endpoint, the session, and the banking workflow may all need review at once.
What to watch for: Watch for fake-update delivery patterns, anomalous browser extensions or injection behaviour, and banking sessions that succeed but produce unexpected transaction outcomes. Those signals often indicate the compromise happened before the final payment step.
Practitioner takeaway: The safest response is to assume that a live banking session may be less trustworthy than the password that opened it.