Security teams detect Dyre by looking for banking credential theft activity on user endpoints and browser sessions. Monitor for suspicious browser injection, altered login flows, unexpected process relationships and outbound connections tied to credential harvesting. Check for account takeover signs, unusual authentication from new locations, and endpoints that show web form tampering or keystroke capture behaviour.
How Dyre shows up on endpoints and in browser activity
Dyre is best detected as a browser-centric credential theft campaign rather than a simple malware infection. The strongest clue is a chain of endpoint and session anomalies that line up with banking login abuse, especially when a user reports a normal sign-in but the browser behaviour, page content, or network activity does not look normal.
Look for browser injection into legitimate sessions, because the malware often manipulates what the user sees while preserving the appearance of a trusted website. That can include altered login flows, hidden form tampering, or fields that behave differently after the page loads. A useful signal is when the browser process tree and the surrounding child processes do not match ordinary user activity.
Outbound connections matter as much as the page content. Connections tied to credential harvesting, especially those that appear only during login or immediately after form submission, can show the malware is exfiltrating what it captures. If the endpoint also shows keystroke capture behaviour or unexpected process relationships, the browser session should be treated as compromised until proven otherwise.
What a Dyre investigation should confirm first
Start by confirming whether the endpoint is the source of the theft or only the place where the stolen session was used. That distinction matters because the same user can show both malware activity and account takeover signs, but the incident response path is different if the browser itself was tampered with versus if credentials were reused elsewhere.
Validate the user’s authentication history, including unusual logins from new locations, impossible travel patterns, or sessions that do not fit the user’s normal device and network profile. If the account shows signs of takeover at the same time the endpoint shows browser injection or web form tampering, assume the compromise is active and not historical. For detection teams, endpoint telemetry and identity telemetry need to be correlated before closing the case.
Also check whether the browser artefacts point to password interception, form grabbing, or session theft rather than generic adware or commodity spyware. A banking trojan like Dyre is most actionable when multiple clues reinforce each other: modified login behaviour, suspicious process lineage, and authentication events that cannot be explained by the user’s normal pattern.
Why browser-session clues are more reliable than a single alert
Single indicators are easy to miss or misread, especially if the malware is injected into a living browser session. The more reliable detection pattern is behavioural: a legitimate user action followed by tampered form handling, process anomalies, and an outbound connection that aligns with credential collection. That combination is stronger than any one signature in isolation.
For teams building detections, browser injection should be treated as a high-value signal because it often precedes credential theft, not just follows it. The same is true for changes to authentication flow behaviour. If a login page that normally renders and submits cleanly suddenly shows form tampering, extra prompts, or unexpected redirects, the browser session itself may be under malicious control.
Endpoint detections should be tuned to catch both malware tradecraft and user-impact symptoms. In practice, that means watching for suspicious parent-child process chains, injected browser modules, suspicious DLL loading, and short-lived connections that appear around sign-in events. The endpoint view tells you how the compromise happened; the browser and identity views tell you what the attacker was after.
Risk and Threat Considerations
Dyre is dangerous because it attacks the trust relationship between the user, the browser, and the banking session. Once the browser is manipulated, the victim may enter valid credentials into a page that looks legitimate while the attacker quietly harvests them, then reuses the session or credentials for takeover.
Failure mechanism: Browser injection and form tampering allow the malware to capture credentials or session material without obvious user-visible malware prompts, then use those secrets for account access from another location or device.
Impact: The result can be banking account takeover, fraudulent transactions, secondary session compromise, and broader exposure if the same credentials are reused elsewhere.
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 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 detection centers on keystroke capture and browser tampering. |
| T1114 — Email Collection | Dyre-style credential theft often pairs with stolen-session abuse and harvested credentials. | |
| Recommendation — Map form-grabbing and keylogging telemetry to input-capture detections. Correlate credential-theft telemetry with downstream account-access activity. | ||
| NIST CSF 2.0 | DE.CM-01 — Networks and network services are monitored to find potential cybersecurity events | Dyre is detected through endpoint and outbound-connection monitoring. |
| DE.AE-02 — Detected events are analyzed to understand attack targets and methods | Analyst correlation is needed to separate malware presence from account takeover. | |
| Recommendation — Monitor endpoint and network telemetry for browser-injection and credential-harvesting indicators. Analyze browser, process, and authentication signals together to classify the intrusion path. | ||
| NIST SP 800-53 Rev 5 | SI-4 — System Monitoring | Dyre detection depends on monitoring injected browser and process behaviour. |
| Recommendation — Use system monitoring to flag browser injection, tampering, and suspicious process lineage. | ||
Practitioner Guidance
What to verify: Confirm whether the suspicious browser activity coincides with credential submission, not just with a malicious file on disk. If the browser session, endpoint telemetry, and authentication logs all point to the same time window, treat the event as credential compromise rather than a generic endpoint alert.
Decision rule: If you see altered login flows or form tampering, prioritise credential reset, session invalidation, and account review before spending time on full malware provenance analysis. If only process anomalies exist without authentication anomalies, keep investigating, but do not assume account theft until the identity evidence supports it.
What good looks like: Effective detections connect endpoint behaviour to user authentication outcomes, so analysts can distinguish malware presence from successful credential theft. The most useful outcome is a rule set that flags the browser manipulation early enough to interrupt the takeover path, not merely after funds or sessions have already been abused.
Practitioner takeaway: For Dyre, the endpoint matters because it reveals the theft mechanism, but the decisive evidence is the combination of browser tampering and identity misuse.