Dyre is banking malware designed to steal credentials and enable fraudulent transactions. It targets browser sessions and user logons, so defenders should watch for injected browser activity, credential theft indicators and anomalous banking access, and enforce multi-factor authentication and transaction monitoring where possible.
What Dyre Does in a Banking Attack Chain
Dyre is banking malware built to steal credentials and enable fraudulent transactions by interfering with browser sessions and user logons. Its value to the attacker comes from sitting in the path of legitimate banking activity, where stolen authentication material can be reused in real time.
This makes Dyre more than a simple password stealer. It is designed to turn a normal customer session into an attacker-controlled opportunity, often by capturing logons, changing what the user sees in the browser, or enabling follow-on fraud after access has already been obtained.
Why Browser-Session Malware Is Dangerous
Malware of this type is dangerous because it targets the trust relationship between the user, the browser and the bank. Once an attacker can observe or manipulate a live session, strong perimeter controls may not stop fraudulent actions that appear to come from an authenticated user.
The browser is especially attractive because many banking workflows depend on it for authentication, challenge handling and transaction confirmation. If the malware can inject content or intercept session activity, it can undermine both credential secrecy and user intent at the same time.
How Organisations Detect Exposure and Compromise
Exposure starts with any endpoint that can reach online banking or payment portals, so inventory and endpoint coverage matter. Defenders should look for injected browser activity, suspicious logon behaviour, unusual access times and transaction patterns that do not fit normal customer or employee behaviour.
Detection is stronger when endpoint telemetry is correlated with authentication and transaction logs. The MITRE ATT&CK Enterprise Matrix is useful here because it maps credential access and post-compromise activity to observable techniques that security teams can hunt for.
Where banking access is protected by stronger authentication, defenders should also review whether the protected flow still allows session hijack or transaction redirection after the initial logon step. The NIST SP 800-63 Digital Identity Guidelines are relevant because phishing-resistant authentication reduces some credential theft paths, but it does not by itself neutralise malware already running in the browser.
Containment and Recovery After Suspected Infection
When Dyre-like activity is suspected, the response priority is to stop reuse of captured access and prevent fraudulent transfers from completing. That usually means isolating affected endpoints, revoking or resetting exposed credentials, and validating recent banking activity for unauthorised or altered transactions.
Transaction monitoring is important because financial abuse may continue even after the malware is removed. The NIST Cybersecurity Framework 2.0 helps organise that response across identify, protect, detect, respond and recover so the issue is handled as both an endpoint compromise and a fraud event.
Risk and Threat Considerations
Dyre creates a direct risk of credential theft, session compromise and fraudulent banking activity. The danger is not limited to stolen passwords, because a live browser session can let an attacker act inside an apparently valid customer session and bypass controls that only inspect the initial login.
Failure mechanism: The malware captures or manipulates browser traffic after authentication, then reuses that access to authorise transfers or alter transaction details before the victim notices.
Impact: Organisations can face financial loss, customer account compromise, chargeback exposure, incident response costs and loss of trust in the affected banking channel.
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-63, NIST CSF 2.0 and NIST SP 800-53 Rev 5 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| MITRE ATT&CK | T1056 — Input Capture | Dyre steals credentials through browser and logon interaction. |
| Recommendation — Map browser and logon theft activity to input-capture tradecraft and hunt for credential interception. | ||
| NIST SP 800-63 | Digital Identity Guidelines | Phishing-resistant authentication reduces credential replay risk after theft. |
| Recommendation — Use phishing-resistant authenticators to reduce the value of stolen banking credentials. | ||
| NIST CSF 2.0 | DE.CM-01 — Networks, systems, and devices are monitored to detect anomalous activity | Dyre requires detection of anomalous logons, browser injection and fraudulent activity. |
| RS.MA-01 — Response plan is executed during or after an incident | Suspected Dyre infection requires coordinated containment and fraud response. | |
| Recommendation — Monitor endpoint and transaction telemetry for anomalous access and browser manipulation. Execute incident response procedures to isolate hosts and contain fraudulent banking activity. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | Dyre targets credentials, so credential lifecycle controls matter directly. |
| Recommendation — Rotate exposed credentials and enforce strong authenticator lifecycle controls. | ||
Practitioner Guidance
Why practitioners should care: Banking malware of this kind is most effectively controlled where endpoint monitoring, authentication and transaction review work together. If one layer is missing, the attacker can still succeed by abusing the others.
What to watch for: Investigate abnormal browser behaviour, repeated failed logons, new device patterns, suspicious transaction timing and any mismatch between user intent and the final payment destination.
Practitioner takeaway: Treat browser-session abuse as both an identity problem and a fraud problem, because removing the malware alone does not prove that the account, session or transaction state is clean.