While reading another story of botnet takedown, my wondering has reached its apogee: Why don't malware authors use cryptography (encryption + signing) provided by good libraries when their creations communicate with C&C servers?

Benefits are obvious, while the cost of integration is relatively low (isn't it?). If one would consider OpenSSL, it was founded in 1998, but I haven't heard about malware signing and encrypting at least some of its commands until ~2008.

A good example is Waledac botnet, which was taken down by Microsoft.

UPDATE: I found out that Conficker(2008) worm actually used payload signing and surprisingly in the end it downloaded Waledac.

  • How would encryption help if the command and control servers are taken down or if somebody takes control of the server? Commented Apr 23, 2016 at 18:19
  • Just to be clear, the starting premise of this question is that without strong encryption, botnets communications can be intercepted or hijacked by LEAs? Commented Apr 23, 2016 at 19:15
  • 1
    Since you assume that a botnet could be protected against a takedown by using stronger encryption - could you please add references where botnets where taken down because of bad encryption? Commented Apr 23, 2016 at 19:26
  • IMHO, for botnet integrity, digital signatures are more important than encryption. Consider a bot using DGA and centralized structure. If server&domain gets seized by LEA and it is not using digital signatures, then they can issue rogue commands to destroy botnet. On the other side, if it was using digital signatures, then seizure would only tip off the botmaster. They couldn't issue any commands, because the private key for signing is on the botmaster's PC. Same applies to P2P.
    – assp1r1n3
    Commented Apr 23, 2016 at 19:35
  • So do you have reference then for a botnet taken down due to bad cryptography - encryption or signature or whatever? I think if botnet authors see this is a problem they will care, if this is not an issue then why make it unnecessarily complex. Commented Apr 23, 2016 at 19:41

3 Answers 3


It seems surprising because crypto libraries are available on all (major) platforms. But it sounds often simpler than it is. For example accessing the Crypto API on Windows takes a lot of additional code to do it properly.

But the amount of malware authors being very familiar with cryptography is rather small. Therefore they tend to focus on functionality like propagation, hiding techniques or data collection instead. Crypto is often just “nice to have“.

Furthermore adding solid crypto mechanisms would increase complexity and detectability of a malware. Simple and small solutions are preferred. Adding crypto is an huge source for errors limiting the success of the malware tasks.

  • The encryption of communication is not that important. Digital signature is. And I don't think that JUST checking the digital signature of the command received from C&C server is a such a big deal. Am I right?
    – assp1r1n3
    Commented Jun 4, 2016 at 21:30
  • Data encryption, especially during communication, is just as important. It makes detection of malware traffic, understanding the malware architecture, identifying the nodes and spoofing to gain information and privileges much harder. If you are relying on an existing crypto library anyway, the complexity of communication encryption and certificate-based validation is very similar. Personally I would prefer encryption over authentication/validation.
    – Marc Ruef
    Commented Jun 5, 2016 at 1:06

I'm not a malware author, but I assume it's because it's almost impossible, and it doesn't deliver a benefit.

How can the malware 'validate itself' in any meaningful way? Malware is fully exposed to a researcher, who can know whatever the malware knows. It can't contain a secret code that a researcher can't also learn. Any researcher can spoof whatever the malware wants to send to the C&C server.

The exceptions are specific targets, like the Gauss malware used.

  • 3
    The malware should only include the public key of the signature, that doesn't add any risk to the botnet master or to the botnet itself unless the signature algorithm used has an implementation flaw or the algorithm itself is flawed.
    – kR105
    Commented Apr 23, 2016 at 23:25
  • 2
    The point of encryption and signatures using public key cryptography is that only the "authorised" user (in this case the hacker) can create valid instructions. Done correctly, the researcher can only replay what instructions it's recorded - if those instructions are protected against replays (time-based nonce's, etc), there's nothing the researcher can do.
    – adelphus
    Commented May 23, 2016 at 23:17
  • @adelphus, the malware has to have all the information needed to decrypt the instructions locally, or it can't execute them either. So the information is always available to the researcher before the malware transmits it. Therefore the researcher has everything needed to send falsified data. The only way this would not be the case is if the malware had a local source of data the researcher didn't know about. Commented May 24, 2016 at 4:00
  • @adelphus can you elaborate on protection against replays?
    – assp1r1n3
    Commented Sep 3, 2016 at 18:26

Maybe malware authors are lazy, or using strong cryptography would use up too much space. When creating a bot "stub" size is important. In order to remain less suspicious malware is as small as possible, so it can be "bound" with other software. A client to server connection already takes up a lot of the malware's room, adding strong encryption would make the file much larger.

  • OpenSSL is not the only library implementing strong crypto. There are numerous implementations of the rarest crypto algorithms for almost any language and platform. Considering space and footprint issues, take for example mbed TLS, lightweight and easy, yet powerful enough.
    – assp1r1n3
    Commented Apr 23, 2016 at 19:40
  • 2
    So, you want to say that these people are lazy to include one library into their project, and yet they are not lazy to update their code obfuscators hours(!) after they were added to AV databases? Makes little to no sense.
    – assp1r1n3
    Commented Apr 23, 2016 at 19:47
  • In my teenage years (slashdot and milw0rm days), I was IRC buddies with two classes of engineers - the ones who'd actually understand the internal mechanisms of smashing the stack (or in these days, finding a ROP gadget for WebKit to break out of the PS4 hypervisor), and then the script kiddies who'd buy botnet software that they'd embed into applications and throw onto KaZaA. There are 'frameworks/libraries' like we have metasploit and Jquery which are pretty standard that you can pick up for 50 bucks and it will talk to your C&C on IRC. I'd imagine derivatives of those code bases are in play
    – Andrew
    Commented May 24, 2016 at 3:33

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .