Some QBot campaigns have gone from phishing email to ransomware deployment within 24 hours. That's not a lot of room between "initial access" and "incident response."
In the first half of 2023, QBot was reported as the most prevalent malware globally, with monthly impact figures exceeding 11% in some months. The FBI's Operation Duck Hunt dismantled its C2 infrastructure in late August 2023, but new variants emerged within four months. In May 2025, the DOJ indicted an operator who was still actively deploying ransomware. The infrastructure went down. The operators didn't.
This guide breaks down what QBot is, how it infects systems, the behavioral patterns that make it detectable across variants, how to remove it, and how to build defenses that survive whatever ships next.
Key Takeaways:
QBot evolved from a banking trojan into a ransomware delivery platform and initial access broker, although this evolution is not explicitly described in the current MITRE ATT&CK profile or in FBI reporting.
Detection rules targeting QBot's behavioral mechanics, not just binary signatures, remain useful across variants, because QBot's execution chains, persistence patterns, and LOLBAS usage have remained consistent even as delivery methods and binary packaging change.
Operation Duck Hunt disrupted QBot's C2 servers, and activity resumed after the takedown, so teams should not retire QBot detection rules based on the takedown alone.
A detection-as-code workflow with version control, CI/CD testing, and automated enrichment is an effective defense against loader malware that changes its surface faster than manual rule management can keep up.
What Is QBot (Qakbot)?
QBot is a durable malware family used to establish access for later-stage intrusion activity. The QBot entry on MITRE ATT&CK documents that role. What makes QBot worth understanding in depth is how it evolved from a banking trojan into a loader, and why that evolution matters for defenders.
Origins and Evolution: From Banking Trojan to Malware Loader
QBot started as a banking trojan and became one of the most prolific loaders in the ransomware ecosystem. It was first identified around 2007–2008, designed to steal credentials through browser web-inject modules.
The critical shift happened when QBot began delivering ransomware. Since then, it has served as an access vector for multiple ransomware operations over time. The standard kill chain now looks like this:
Malspam → Initial Payload → Loader DLL → Process Injection → C2 Beacon
→ Persistence → Lateral Movement → Cobalt Strike → Ransomware
QBot's modular plugin system downloads capabilities post-infection, including credential theft and email collection modules. Initial DLL capture alone won't reveal the full capability set.
QBot's Role in the Ransomware-as-a-Service Ecosystem
QBot functions as an access broker: it gets the initial foothold, then hands that access off to ransomware operators. That handoff is why you'll see QBot and ransomware from entirely different operators on the same host. TA570 and TA577 are two of the most active QBot distribution affiliates, running distinct campaigns with different delivery approaches.
The DOJ's 2025 indictment includes a civil forfeiture complaint against over $24 million in seized assets.
How QBot Infects Systems
QBot's delivery methods have shifted over time, but the patterns are recognizable if you know what to look for. Initial delivery, macro-free execution paths, and persistence behaviors each create detection opportunities.
Phishing Emails and Thread Hijacking
Thread hijacking remains one of QBot's notable initial delivery methods. Stolen email threads let operators craft fake replies and add a Re: prefix to the subject line. Each email uses varied lures to minimize IOC reuse.
These thread-hijacked emails carry PDF attachments, OneNote files, or URLs that lead to ZIP archives containing the actual payload. They consistently bypass secure email gateways because the conversation history passes content inspection.
HTML Smuggling and Macro-Free Delivery Techniques
As Microsoft tightened macro execution policies, QBot operators shifted to macro-free delivery chains. Several methods have been observed:
HTML/SVG smuggling: ZIP archives embedded in SVG files via HTML smuggling. SVG files are treated as images by many email security tools.
ISO/LNK delivery: ISO files containing a LNK shortcut and a QBot DLL, sometimes disguised with renamed extensions such as
.dat,.scr, or.jpg. Mounting the ISO bypasses Mark-of-the-Web protections.OneNote embedding: OneNote files with embedded MSI installers, followed by self-deletion PowerShell scripts.
Lateral Movement and Persistence Mechanisms
QBot's post-execution behavior creates some of the strongest detection opportunities in its kill chain. After execution, the malware uses process hollowing and injects into explorer.exe, wermgr.exe, or mobsync.exe. Persistence comes through scheduled tasks and base64-encoded payloads stored in HKCU\SOFTWARE\ registry keys.
Lateral movement follows a consistent pattern: DLL copy to targets via SMB shares, remote service creation to execute them, and DeleteFlag = 1 set on the service to trigger automatic removal upon reboot and defeat post-reboot forensic analysis.
QBot Capabilities and MITRE ATT&CK Mapping
Five ATT&CK techniques produce the highest-fidelity QBot signals. The rest of the S0650 mapping is useful for coverage auditing, but these are the ones worth building detection rules around.
Credential Harvesting and Data Exfiltration
QBot's plugin system expands its capabilities after C2 contact, which is why initial DLL capture alone won't reveal what it can do. Post-infection modules include password grabbing, cookie theft, browser web-inject modules, and an email collection capability used to support follow-on phishing campaigns.
It uses esentutl.exe to extract browser data from local databases.
Key MITRE ATT&CK Techniques QBot Uses
These are the techniques that produce detection rules worth maintaining across QBot variants:
T1055.012 (Process Hollowing): Suspended process creation is a common indicator of this technique
T1053.005 (Scheduled Task):
regsvr32.exe -sinvoked as SYSTEM via a scheduled taskT1005 (Data from Local System):
esentutl.exespawned by unusual parents, with a low false positive rateT1547.001 (Registry Run Keys / Startup Folder)
T1021.002 (SMB/Windows Admin Shares): DLL copy and remote service creation via admin shares
The QBot Takedown and Its Aftermath
Operation Duck Hunt took down QBot's infrastructure in August 2023. Four months later, new variants were circulating. Here's what the operation actually accomplished and why later activity still matters.
Operation Duck Hunt: The FBI-Led Disruption
On August 25, 2023, the FBI and partners across seven countries dismantled QBot C2. The operation identified 700,000+ infected computers worldwide, seized $8.6 million in cryptocurrency, and deployed an FBI-created uninstaller to victim machines that severed the C2 connection.
However, CISA explicitly warned: the disruption did not mitigate other previously installed malware or ransomware already on victim computers.
Post-Takedown Resurgence and New Variants
QBot-linked activity resumed within months. By October 2023, reporting linked former affiliates to distribution of other malware and ransomware families. In December 2023, a new QBot variant emerged. By May 2024, Storm-1811 activity had been observed since mid-April 2024.
Defenders should separate the malware from the operators who use it. The QBot binary may change, but the adversaries behind it remain active. Do not retire QBot detection rules.
How to Detect QBot in Your Environment
No single log source captures QBot's full kill chain. You need correlation across process, network, and script telemetry. Here's which sources surface the best signals, what a practical detection rule looks like, and how to tune alerting so your team actually uses it.
1. Log Sources That Surface QBot Activity
Start with these four telemetry sources. Windows Process Creation (Sysmon EID 1 / Security EID 4688) is the most important. Watch for suspicious scheduled tasks launching LOLBins such as regsvr32.exe, anomalous explorer.exe child processes related to discovery activity, and ONENOTE.EXE-initiated chains involving msiexec.exe and script execution.
Sysmon EID 8 + 10 can help detect process injection: suspicious GrantedAccess values such as 0x1fffff, 0x1f3fff, and 0x143a on explorer.exe followed by CreateRemoteThread may indicate injection activity.
Network traffic reveals C2 on ports 443, 995, and 2222. CISA has published QBot advisories and IOCs. JA3 fingerprints for QBot C2 traffic aren't consistently documented in available reporting, so they're less reliable as an enrichment source.
PowerShell Script Block Logging (EID 4104) can capture AD reconnaissance activity, including use of System.DirectoryServices.DirectorySearcher. The Path field may be empty in some cases, but it should not be treated on its own as evidence of memory-only execution.
2. Detection Rules for Common QBot Indicators
Behavior-based detection rules are more durable against QBot than simple binary indicators. Here's a Python detection rule for QBot's WSH script execution from mounted drives:
3. Reducing False Positives in QBot Alerting
Single-condition QBot alerts will bury your team in false positives. Multi-condition tuning is the difference between a detection program that works and one your analysts learn to ignore. Three strategies help.
Scope
regsvr32.exealerts by parent, user context, and DLL path. Require all three: parent isschtasks.exe, running as SYSTEM, DLL is in a user-writable location, notSystem32orProgram Files.Gate
explorer.exenetwork alerts on a prior injection event. Require that the specific PID was the target of aCreateRemoteThreadevent within 60 seconds and the destination port is 995 or 2222.Use JA3 as enrichment, not a standalone alert trigger. Alert only when JA3 matches and the source process is
explorer.exeorrundll32.exeand the destination port is 995 or 2222.
Docker achieved an 85% false positive reduction year-over-year while tripling ingestion volume using similar multi-condition tuning approaches. You don't have to choose between ingesting more data and keeping your alert queue usable.
How to Remove QBot and Recover
Don't start eradication until you've scoped the full infection. QBot drops secondary payloads, and those may still be active after you've identified the initial loader. Containment comes first, then eradication, then hardening.
1. Containment and Eradication Steps
Assume the host is still active and secondary payloads are already present. Isolate infected systems without powering down by pulling the cable or disabling the NIC. Powering off destroys volatile memory. Import relevant threat intelligence IOC feeds into perimeter controls and enable DNS query logging.
Before eradication, identify the full scope. Hunt for QBot registry persistence under HKCU\SOFTWARE\Microsoft[random alphabetical key], DLL artifacts in AppData\Roaming\Microsoft\, and secondary payloads, particularly LSASS memory access events and PowerShell with -NoP -Enc flags.
Do not reset credentials until network isolation is confirmed for all affected systems. Resetting while the attacker retains active access may trigger ransomware. When ready, reset domain admin accounts first. QBot activity has been observed in environments where Mimikatz is used for credential dumping, but there is no evidence that QBot itself specifically targets domain administrator credentials via both Mimikatz and Pypykatz.
2. Post-Incident Hardening to Prevent Reinfection
Focus on the controls most likely to break QBot reinfection paths. After eradication, implement these controls:
Deploy ASR rules to block Office child processes, obfuscated scripts, and PSExec/WMI-originated process creation
Enforce phishing-resistant MFA (FIDO2 or hardware tokens) on all privileged accounts
Deploy LAPS to randomize local admin passwords
Segment workstations from servers and domain controllers
Monitor DNS and firewall logs for a minimum of 72 hours post-eradication for C2 communication before restoring normal access.
Why Detection-as-Code Makes QBot Detection More Durable
When a new QBot variant drops, the question is how fast you can update, test, and ship a rule. Detection-as-code applies software engineering practices, including version control, peer review, CI/CD pipelines, and automated testing, to detection rule management.
Detection rules follow the same principles used in SRE and DevOps workflows: version-controlled, peer-reviewed, tested before deployment, and deployed through automated pipelines.
The practical advantage is speed. A behavioral rule update targeting a consistent execution chain can be tested and moved through a CI/CD pipeline quickly. Traditional SIEM rule management through a GUI console can take days between identifying a new behavior and deploying a production rule. Detection-as-code compresses that to hours.
Wolt built this workflow using Git-based code reviews and CI/CD pipelines, making detection changes "fearless" because broken rules were caught before deployment.
InPanther, detection rules written in Python, SQL, or YAML go throughCI/CD testing with unit tests before deployment. The Detection Builder can generate initial rule scaffolding from natural language descriptions, but you review and own the code, with no black-box detection logic.
Share:
RESOURCES






