DanaBot is a Windows banking trojan and modular loader that has been around since 2018 and is very much not dead.

  • It operates as Malware-as-a-Service (MaaS): affiliates rent access and plug it into their own phishing or malvertising chains.
  • It combines web-injects, form-grabbing, keylogging, credential theft and remote access to abuse online banking, crypto exchanges, and other financial services.
  • After a temporary disruption during Operation Endgame in mid-2025, DanaBot resurfaced with version 669, rebuilt infrastructure (including Tor .onion C2s), and renewed campaigns using email lures and malicious files.
  • From a defender’s perspective, DanaBot matters because it’s a flexible initial access platform: once it’s on a host, the operator can steal money directly, pivot into the network, or drop additional payloads (stealers, RATs, ransomware).

This post walks through what DanaBot is, how the latest campaigns work, how the malware behaves on a host, and what artefacts and detections you can use to spot and contain it.

1. Quick History: What Is DanaBot?

DanaBot was first documented around 2018 as a Delphi-based banking trojan aimed primarily at:

  • Stealing credentials for online banking portals and financial services.
  • Injecting fake content into browsers (web-injects) to capture logins and push fraudulent transactions.
  • Providing remote access and loader functionality so affiliates could extend campaigns with other malware.

Key characteristics over time:

  • MaaS model – DanaBot is run as a service; operators pay for campaigns, infrastructure, and updates.
  • Region targeting – Early waves focused on Europe and North America; later versions broadened the target set.
  • Modular architecture – Core loader + plug-in modules (stealer, web-inject, RAT, proxy, etc.).
  • Persistent evolution – Changes in encryption, configuration formats, and distribution tactics keep static detections struggling.

In May 2025, DanaBot’s infrastructure was disrupted as part of a coordinated law-enforcement action (Operation Endgame). Activity dipped for about six months — but this turned out to be a pause rather than a full takedown.

By November 2025, researchers started seeing version 669 in the wild:

  • New command-and-control (C2) infrastructure, including Tor-based .onion endpoints and backconnect nodes.
  • Fresh campaigns delivering DanaBot via phishing emails and malicious files.
  • Updated, more modular code base to improve stealth and flexibility.

DanaBot is a good example of how financially motivated malware families survive big takedowns by rebuilding and adapting.

2. Initial Access: How DanaBot Gets In

DanaBot doesn’t bring its own exploit kit. It relies on social engineering and user execution, mainly through email and file-based lures.

2.1 Phishing emails and malicious attachments

The most common delivery vector remains malspam:

  • Lures themed around invoices, overdue payments, shipping updates, payroll, and tax documents.
  • Language tailored to the victim’s region and industry (finance, retail, manufacturing, logistics, etc.).
  • Attachments or links that lead to ZIP archives, ISO/VHD containers, or MSIs containing the loader.

Typical attachment patterns:

  • Invoice_<random>.zip with a contained script or executable.
  • Payment_Receipt_<date>.iso housing a shortcut (LNK) tied to a script engine (wscript/cscript/PowerShell).
  • Payroll_Update_2025.msi masquerading as an internal HR or accounting update.

The victim is told they must open the file to:

  • View a bill or urgent payment notice.
  • Confirm banking details.
  • Download updated documents or “security modules” for online banking.

2.2 Malvertising and cracked-software installers

DanaBot operators, like many others, also abuse:

  • Search ads and SEO poisoning that push users towards trojanised installers.
  • Cracked software sites or “free” license generators for popular tools.

The pattern:

  1. User searches for a tool (e.g., PDF editor, remote admin client, office activator, cracked software).
  2. They click a malicious ad or poisoned search result, landing on a website that looks legitimate enough.
  3. The site offers an installer or archive that actually bundles a DanaBot loader alongside or instead of the promised software.

This fits neatly into broader “bundle of stealers/loaders” trends, where a single installer might deploy multiple families depending on configuration — DanaBot being one of them.

2.3 File formats & script chains

Once the victim runs the file, the first stage typically involves:

  • A script-based loader (.vbs, .js, .bat, or encoded PowerShell) that:
    • Unpacks or downloads a DLL or EXE payload.
    • Sets up basic persistence (scheduled tasks or Run keys).
    • Launches the core DanaBot module.
  • Or a MSI installer that:
    • Installs a decoy application or shows a fake setup wizard.
    • Drops the DanaBot loader into %ProgramData%, %APPDATA%, or %TEMP%.
    • Executes the loader via msiexec.exe or a custom stub.

From a forensic point of view, the early chain often looks like:

OUTLOOK.EXE / WINWORD.EXE / browser → wscript.exe / msiexec.exe → suspicious DLL/EXE in a user-writable path.

That parent-child sequence is one of the best early signals you can hunt on.

3. Architecture and Capabilities

DanaBot’s modular architecture is what makes it so attractive to criminals.

3.1 Loader + core engine

At a high level:

  • A compact loader is delivered first. Its job:
    • Unpack / decrypt the main module from resources or a downloaded blob.
    • Inject it into a legitimate process (process hollowing or code injection).
    • Establish basic communication with the C2 and fetch configuration.
  • The core engine then:
    • Registers the victim (campaign ID, build ID, system info).
    • Requests and loads additional plug-ins depending on the operator’s needs.
    • Coordinates web-injects, form grabbing, keylogging, and remote commands.

This separation allows operators to keep the initial footprint small and adapt behaviour on the fly.

3.2 Banking and web-inject modules

DanaBot is first and foremost a banking trojan, so a lot of engineering is focused on the browser:

  • Web-injects – Injecting customised HTML/JS into banking and financial sites accessed by the victim’s browser. This allows attackers to:
    • Modify visible account balances.
    • Insert extra fields into forms (e.g., PINs, card CVV, security questions).
    • Alter transfer destinations behind the scenes.
  • Form-grabbing – Intercepting form submissions at the browser or network layer and exfiltrating:
    • Usernames and passwords.
    • MFA codes and one-time tokens.
    • Full card details, personal data, and other secrets.
  • Session hijacking – Stealing cookies, session tokens, and authentication artefacts that can be replayed from the attacker’s own infrastructure.

Because these modules are constantly updated to keep up with changes in banking sites, static indicators age quickly. Behaviour-based detection is far more robust.

3.3 Stealer and credential modules

Beyond banking portals, DanaBot can harvest:

  • Browser-stored credentials (Chrome, Edge, Firefox, etc.).
  • Crypto wallet data and browser extensions relating to cryptocurrency.
  • Credentials for email, remote access tools, and enterprise portals stored in browsers or local config files.

These are exfiltrated to C2 infrastructure, often tagged with:

  • Campaign ID.
  • Bot ID.
  • Host-level details (username, computer name, OS version).

This data can then be used for:

  • Direct fraud (e.g., draining exchange accounts).
  • BEC-style campaigns and account takeover.
  • Sale to other criminals on underground markets.

3.4 Remote access and loader functionality

DanaBot isn’t just about stealing credentials. It also acts like a lightweight RAT and loader:

  • Execute arbitrary commands and scripts.
  • Upload and download files.
  • Deploy additional payloads (including other stealers or ransomware prep tools).
  • Configure the bot as a proxy or backconnect node for later access.

Version 669 and later builds lean heavily on:

  • More flexible C2 infrastructure (Tor, multiple IPs, rotating domains).
  • “Backconnect” functionality to let operators pivot into the network from the bot.

That’s why defenders increasingly treat DanaBot as an initial access vector, not just a credential stealer.

4. Forensic Artefacts on Disk and in the Registry

When investigating a suspected DanaBot infection, consider the whole chain, not just the final binary.

4.1 File system artefacts

Look for:

  • Installer and archive remnants in Downloads, Desktop, and temp folders:
    • ZIP/ISO/VHD/MSI files related to the phishing/malvertising lure.
  • Dropped EXE/DLL payloads in:
    • %APPDATA% / %LOCALAPPDATA%
    • %PROGRAMDATA%
    • C:\Users\Public
  • Associated configuration files or encrypted blobs kept alongside the main binary.

Combine filesystem timestamps with email and proxy logs to understand:

  • Exactly when the payload was fetched.
  • How much time elapsed between download and execution.

4.2 Prefetch, Amcache, Shimcache

On Windows endpoints with Prefetch enabled:

  • Look for .pf files for suspicious executables:
    • Unusual names.
    • Binaries executing from user-writable paths.
    • Abnormal run counts over a short period.

Amcache and Shimcache entries can corroborate that:

  • Particular binaries were present and likely executed, even if logs are missing.
  • The first time a given executable appeared on the system (Amcache “first run” approximations).

Tie these to:

  • Email timestamps.
  • Browser download timestamps.
  • Security alerts for process creation or script execution.

4.3 Persistence mechanisms

DanaBot campaigns use a variety of persistence methods, including:

  • Registry Run keys:
    • HKCU\Software\Microsoft\Windows\CurrentVersion\Run
    • HKLM\Software\Microsoft\Windows\CurrentVersion\Run
  • Scheduled tasks:
    • Tasks that launch EXEs or scripts from unexpected locations.
    • Often named to look like system updates or vendor services.
  • Services:
    • New or modified Windows services pointing to attacker-controlled binaries.

Document:

  • Creation timestamps for these artefacts.
  • Which user or process created them.
  • Whether they appeared shortly after a suspicious installer executed.

These details matter when you’re proving a timeline for incident reports or legal processes.

5. Process, Memory, and Network Behaviour

5.1 Process tree patterns

Common suspicious sequences in DanaBot incidents include:

  • OUTLOOK.EXE / WINWORD.EXE / acrord32.exe → script engine (wscript.exe, cscript.exe, powershell.exe) → installer or loader.
  • Browser process → msiexec.exe → DanaBot loader (when delivered via web-only chains).
  • An unsigned binary in %APPDATA% or %PROGRAMDATA% spawning:
    • Browser processes.
    • PowerShell or cmd shells.
    • Long-lived processes with regular network connections.

If Sysmon or EDR is available, focus on process creation events around the suspected infection time and build a small, focused tree rather than drowning in all endpoint activity.

5.2 In-memory artefacts

If you can dump memory from suspected hosts or injected processes:

  • Look for:
    • DanaBot-specific configuration blocks (encrypted but often structured).
    • Hard-coded or decrypted C2 endpoints.
    • Web-inject templates for banking portals (HTML, JavaScript snippets).
  • Identify which browser processes appear to have injected code or suspicious modules loaded.

Memory analysis is particularly useful if:

  • The payload is mostly fileless post-initial execution.
  • The operator has cleaned up disk artefacts.

5.3 Network patterns

DanaBot’s network behaviour shifts as operators rotate infrastructure, but common traits include:

  • HTTPS C2 to low-reputation IPs or domains, sometimes over non-standard ports.
  • Use of both direct IP-based C2 and Tor backconnect (v669) for resilience.
  • Short, periodic beacon packets carrying encrypted data, followed by bursts when:
    • New modules are delivered.
    • Large amounts of credential data are exfiltrated.

From a hunting perspective:

  • Identify first-time-seen domains/IPs per host, prioritising those tied to suspicious processes.
  • Cross-reference with known DanaBot IOCs where possible (but don’t rely solely on them).
  • Correlate outbound connections with time windows where banking or credential theft occurred.

6. Detection and Hunting Ideas

6.1 Behavioural detections on endpoints

Some practical rules and analytics:

  • Office apps or PDF readers spawning:
    • wscript.exe, cscript.exe, powershell.exe, or msiexec.exe with command-line parameters referencing remote URLs or user-writable folders.
  • msiexec.exe installing from internet locations, especially non-corporate domains.
  • Scripts or executables launched from Downloads, %TEMP%, or email attachment directories that:
    • Create Run keys or scheduled tasks.
    • Spawn long-lived processes with network activity.

Where supported, create high-fidelity alerts for:

  • Unsigned binaries in user folders acting as parents of browser processes.
  • Unexpected injection into browsers or credential-heavy applications.

6.2 Network and proxy analytics

At the network layer:

  • Block or alert on outbound connections to known DanaBot C2 infrastructure if you track IOCs.
  • Monitor for Windows hosts talking to:
    • Recently-registered domains with no prior reputation.
    • Tor-related endpoints or suspicious backconnect infrastructure.
  • Inspect anomalies such as:
    • Outbound connections during unusual hours that coincide with login attempts to banking portals.
    • Burst uploads of encrypted data from endpoints not usually associated with large transfers.

6.3 Banking and fraud telemetry

If you operate consumer or business banking portals, you can also look at:

  • Device fingerprints and geolocation anomalies around sessions that may have been touched by DanaBot.
  • Sessions where actions (adding beneficiaries, large transfers) deviate from normal behaviour shortly after a new device login.
  • Patterns where logons originate from a victim’s usual IP/device but later sensitive actions come from different infrastructure — indicating session hijack.

Closer collaboration between fraud teams and security teams can turn those patterns into earlier alerts.

7. Response and Containment Strategy

7.1 Treat DanaBot as high impact

Even a single DanaBot infection should be handled as high-risk:

  • It implies theft of banking and/or crypto credentials.
  • It can act as a foothold for broader network intrusion.
  • It may be connected to ransomware or extortion crews via the MaaS ecosystem.

7.2 Immediate steps

On confirmation or strong suspicion:

  1. Isolate affected endpoints from the network.
  2. Reset credentials for:
    • Online banking and financial portals accessed from the host.
    • Corporate accounts used on the host (email, VPN, SaaS).
  3. Notify relevant stakeholders (fraud teams, bank contacts, incident management).
  4. Preserve evidence:
    • Memory (if possible).
    • Disk images or at least key artefacts (logs, registry, file listings, browser data).

7.3 Scoping the intrusion

Use your SIEM/EDR and email/proxy logs to determine:

  • Who else received similar phishing emails or downloaded the same lure.
  • Whether other endpoints have:
    • The same binaries or persistence entries.
    • Similar suspicious process trees or network connections.
  • Whether any privileged systems (AD admin workstations, high-value servers) show signs of related activity.

If DanaBot is found on multiple hosts, consider the possibility of coordinated fraud or pre-ransomware staging.

7.4 Recovery and lessons learned

After eradication (malware removal, persistence cleanup, reimaging where appropriate):

  • Confirm that no backdoor accounts, scheduled tasks, or services remain.
  • Review and strengthen:
    • Email filtering and attachment controls.
    • Policies around execution from user-writable paths.
    • Use of dedicated, hardened machines for financial operations.
  • Feed new IOCs and TTPs into your detection content and threat intel repositories.

Every DanaBot case is an opportunity to make future infections louder, faster to detect, and harder to monetise.

8. Final Thoughts

DanaBot is a great example of how financially motivated malware refuses to die:

  • Even after a major international takedown, the operators regrouped, rebuilt infrastructure, and shipped updated versions within months.
  • The family continues to evolve toward a flexible banking trojan + loader + infostealer platform that other criminals can plug into.
  • It sits at the intersection of fraud, credential theft, and initial access brokerage, which makes it relevant far beyond just banking.

For defenders and DFIR practitioners, the key isn’t memorising every hash or C2. It’s recognising the patterns:

  • Social engineering that turns invoices, shipping notices, and “updates” into execution chains.
  • Scripted loaders and MSIs that end in modular banking trojans.
  • Browser and credential artefacts that show where money and data were targeted.

If you can detect and disrupt those patterns early, DanaBot goes from a costly incident to a contained one — and you’ll be better prepared for the next MaaS family that inevitably tries to fill the same niche.