Team: Huntress EDR
Summary: Qakbot is a rapid-spreading malware often used to implement additional malware across networks. Remediation steps include quarantining, wiping and rebuilding affected machine. Some preventative measures include disabling administrative shares and disk image file mounting abilities.
We know dealing with a Qakbot infection can be a major pain. This malware has self-propagating capabilities and can spread rapidly through a network. Once it has taken hold, it will typically install other malware. Often it seems as soon as you clean a host, it is re-infected.
We recommend wiping the machine and rebuilding it, be sure that you have a good backup before doing so. You can also revert to a previous state if you know exactly when the compromise occurred. If you don't roll back far enough, the Qakbot infection may still be present. We also suggest moving any affected machines to a separate network segment to minimize the chances of clean hosts being infected by compromised hosts.
Disable Administrative Shares
Disabling Administrative Shares is highly recommended. It will help prevent hosts from (re)infecting one another.
Qakbot can spread laterally through networks via Windows administrative shares. These are the hidden shares—such as Admin$, IPC$, and C$—that are enabled by default on Windows hosts for administrative purposes. Qakbot uses a technique similar to Microsoft's PsExec tool to copy/execute payloads onto a remote victim host. This technique relies on the ability to access administrative shares. Temporarily disabling administrative shares will help to slow the spread and prevent re-infection after a host has been cleaned.
- On Windows workstations (7, 8.1, 10, and 11), use the value name AutoShareWks
- On Windows servers (2008, 2012, 2016, and 2019), use the value name AutoShareServer
In the image below, we used "net share" to view the administrative shares, then created the AutoShareWks DWORD value, restarted the server service, and then used "net share" again to verify the administrative shares (C$, D$, and ADMIN$) were no longer present.
Note: you must restart the server service (or reboot) for the changes to the admin share to take effect.
Several of our partners have used these methods successfully:
- PowerShell one-liner that disable ISO mounting:
reg add HKEY_CLASSES_ROOT\Windows.IsoFile\shell\mount /v ProgrammaticAccessOnly /t REG_SZ
[Similarly you can undo this with the command:]
reg delete HKEY_CLASSES_ROOT\Windows.IsoFile\shell\mount /v ProgrammaticAccessOnly
- Stop and disable the LanmanServer (Server) service, this service allows other machines to access local resources including shared files and printers, so only disable if you fully understand (and definitely don't do this on a print or file server!) If you only stop the service when the system is rebooted, the service will auto-start. You can use this PowerShell/CMD command to stop and disable the LanmamServer service (and it'll persist through reboots):
sc.exe config LanmanServer start=disabled[Similarly you can undo this change with:]
sc.exe stop LanmanServer
sc.exe config LanmanServer start=automatic
sc.exe start LanmanServer
- Not recommended for domain joined machines: Use a Group Policy to enable the Windows Firewall and block access to port 445 (SMB).
NOTE Disabling administrative shares on servers (or disabling the Server service/blocking port 445) may prevent user's from accessing shared resources and will also prevent Windows domain authentication.
Deploy the Huntress Agent Throughout the Network
We often see hosts that are re-infected even after it appears that all the malicious files have been removed from the network. Typically we find there was an infected host that was powered off or did not have the Huntress Agent installed. If passwords were not changed and administrative shares were not disabled, as soon as this "offline" host was powered on it would start infecting other hosts.
If you have new Qakbot services, review the event log from the host specifically looking for event id 4697. This is the service creation event. The log should show what account/computer created the service, which may help to identify compromised accounts and other hosts.
What to Expect from Huntress
Depending on the extent of the infection, we may temporarily disable incident reports. If hosts are constantly getting re-infected, new incident reports will be generated each time. We've seen networks with hundreds of infected hosts that were constantly re-infecting one another. Our goal is not to flood your ticket queue with new reports for hosts that have already been reported.
Once the re-infection rate has slowed, we will resume sending incident reports.
If you have any questions, please do not hesitate to contact Huntress support using the button below or by email at email@example.com.
Please sign in to leave a comment.