Back to School Qbot, now Digitally Signed

The authors of Win32/Qbot (a.k.a. Qakbot) are back with new variants of this infamous malware, and this time the binaries are digitally signed.

Qbot is a multifunctional trojan that has had some significant impact in the past. It has also been around a while, with the first variants dating as far back as spring 2007, with more massive distribution starting two years later in 2009. The following figure shows the relative detection ratio of all Qbot variants over time.

There have been some new variants in late spring this year and since then the developers of Qbot have been quiet…until now. It seems that they have come back from their summer vacations and pushed out a new release. Two weeks ago we caught the latest version with our advanced heuristics. What’s interesting is that the authors first tried releasing the trojan without packing it. That probably wasn’t very successful, so they added a layer of protection provided by a packer. Our sample collection system even shows that the Qbot authors have experimented a little with different packer combinations. The latest packed version was detected by ESET (again heuristically) under the name Win32/Kryptik.SLR two days ago. While the resemblance of the detection name to the McLaren supercar is purely coincidence, the authors of Qbot have had much better success this time, as the following VirusTotal screenshot shows.

Another interesting finding is that this packed variant is digitally signed. The Qbot authors are using a certificate probably stolen from a company called Word & Brown. Fortunately, at the time of this writing the certificate has been revoked by VeriSign.

A quick analysis shows that the code of this Qbot version has been rewritten, but the functionality remains very similar to the previous versions. As a reminder, Qbot’s main purpose is stealing different types of sensitive information, including:

  • Various user names and passwords
  • Keystrokes
  • Cookies
  • Digital certificates
  • Visited URLs
  • And much more…

It features a backdoor, which enables the bot to be controlled remotely, update itself, download and run other executables on the infected system. It can also insert malicious IFRAME tags into webpages, has the possibility to block access to domains containing certain keywords (which it uses as an anti-AV feature), and can be used for man-in-the-middle attacks against victims’ online banking systems. Win32/Qbot uses rootkit techniques to hide its presence in the operating system and also has characteristics of a worm, as it can spread through network shares and removable drives.

The functionality of Qbot is quite extensive and also expandable. More detailed technical write-ups of previous versions can be found here: Win32/Qbot.AN and here: Win32/Qbot.AU.

We will continue monitoring this threat and provide more interesting information when it comes up. Meanwhile, our detection team is working on providing the most effective protection for our customers. The latest variant of Qbot is generically detected by ESET security software as Win32/Qbot.AY.

Robert Lipovsky

Malware Researcher

Author Robert Lipovsky, ESET

  • Carl

    How do end users typically encounter certificate validation? Do they know how to handle things when there is an anomoly, or they just click through any warnings?  On a typical O/S what keeps end users from installing software that has a bad certificate?

  • ,orel

    Nice article, well written. Anyway, why do you test avast 4 and avast 5 when the latest version 6 has been out already  for over six  months?

    • David Harley

      Actually, Miroslav, we are not Virus Total. :) And VT would also probably want to point out that they aren’t testing antivirus software at all. They’re using multiple scanners to check suspicious files: quite a different thing.

  • Jason Mashak

    While you're testing outdated software, you should test everything on a Commodore 64. I'm sure SOMEONE is using one. Somewhere. How well does ESET work with a cassette-tape drive?
    avast! 4.8 gave way a long time ago to avast! 5 and now 6. This is just silly, guys.
    Jason Mashak | AVAST Software | Prague, Czech Rep.

    • David Harley

      Avast! guys, if Virus Total is using old versions of your engine, I really think you ought to be discussing it with VT, not ESET.

      But for the record (and speaking purely personally, though I’ve said this before many times, in very public contexts) I don’t regard VT reports as a guide to comparative detection performance – nor does VT! – and I wouldn’t recommend that anyone else use them as such. The report makes the point very succinctly about how successful this particular variant is in evading detection, but it has nothing to do with comparative testing.

  • Jason Mashak

    Thanks for clarifying, David.

  • Robert Lipovsky

    That's a very good question, Carl. On current Windows systems, the security feature in place is User Account Control, but as far as I know, there isn't much difference when launching an executable that's signed vs. unsigned vs. signed with an invalid certificate. If a user wants to be "proactive", they can check the digital certificate by right-clicking on the executable and looking in the Properties under the Digital Signatures tab. Another way is by using the Sysinternals tool Sigcheck.
    However, the situation is different with system drivers. On 64 bit versions of Windows Vista and Windows 7, there's a kernel-mode code signing policy, so if a driver isn't signed with a valid certificate, it will not be loaded.

  • Carl

    Robert Lipovsky, thanks for the reply. I also concerned about inexperienced users who may encounter something (if any warning is given at all).  Particularly, on XP machines in world as we've still got lots running out there (including my own home computer). If the warning is too easy to circumvent or too difficult to understand or doesn't come at all, certificates provide little if any protection or confidence to the end user. 
    I'm not a security person.  I'm not really an IT person.  I'm an MIS person who has to support a family in their home computer usage, and "by default" I'm the first line of tech support to a small office. So things pop up all the time where I have to figure out how best to handle computer security situations.
    A good example (although a different type of certification) is when I look over my fellow employees' shoulders while the surf the 'net.  I see users get a browser certificate error, and click through to get to the site anyway.  It could be as simple as they directed the browser to and the certificate is valid only for, but when I ask the user why they did it, they don't say something like "Well, I checked out the error, and the problem is that the certificate is valid for only one domain not subdomain" or some such, it's usually something like "Well, the site doesn't work if I don't click 'accept'."  We're training users to click through security errors. How many times do users just click right through a UAC warning, too? I'm afraid that in the case of digital signing of binaries, we're not even getting to that, because only the cautious users are even checking things like digital signatures. 
    But the cautious users aren't the ones I'm worried about.  I think so much security is focused on large corps with not quite enough on tiny businesses and home users who have to navigate this stuff on their own. It's hard for them to win if digital signatures aren't even being used by the OS and generating a warning or being blocked.

Follow us

Copyright © 2018 ESET, All Rights Reserved.