Hope is not a NOBUS strategy

So typically the first thing I do when I get a new implant to look at is see if the authors implemented public key encryption into it, or if they just have some sort of password authentication, and then maybe a symmetric algorithm for protecting their traffic. This was, for a while, a good way to track nation states because people who wanted their implants "easier" to deploy did not put public keys in them, whereas those of us who wanted a NOBUS backdoor generated a new public key per target (like this amazing one, Hydrogen, from 2004).

In fact, let's talk about a few key features of Hydrogen because most people have forgotten them and they're relevant, and let's do it in the form of my favorite thing, a numbered list:

1. Embedded public key used to encrypt all traffic (and prevents MITM)
2. Not easy to write an IDS or Nessus scanner script for, since the only handshake was a one byte back and forth and there was no defined standard destination/source port
3. Uses Twofish instead of AES, for "reasons"
4. Replay attack resistant (due to blind key exchange, which on many unix's was hashes of ps -aux since you could not then depend on /dev/urandom existing)
5. Can be installed permanently or just used as a RAT
6. Pure POSIX-compatible C code
1. Ports cleanly to such amazing operating systems as DEC UNIX, SCO UNIX, without any #ifdefs
2. Even ports to Windows (but via a few minor #ifdefs)
7. 40K binaries - can be uuencoded and cut and pasted over slow links
8. Connectback or Connect-To via Environment variables because of...
1. Commandline spoofing (aka, you can call it ps -ef)
9. Deployment scripts which write directly into the binary without needing recompile
10. Bi-directional TCP and UDP redirection/Command Execution/File Transfer/Environment Variable setting, etc.
11. Export Controlled!

It's easy to say that an implant with blind key exchange is better than one that uses a symmetric key, right up until you try to manage a lot of implants and find yourself needing a database to try to figure out which private keys go to which hosts, and of course, since your tools were probably written by hackers and not cryptographers, it's easy to get the math wrong, especially in the late 90's when so much was just getting started. Likewise, your big number library that you're dragging around to every operating system is half the size of your implant. As a final note: any bugs in your implant (aka, crashes, failure to let you in because you messed up the key, freezes, etc.) are fatal in a way that bugs in your word processor most definitely are not.

So it ends up not being a matter of technical capability, but one of POLICY.

From a policy perspective, we don't want to add implants to a host that can be taken over by an adversary. And we want all traffic in transit to be protected by strong encryption as well. It was rare to find cryptographics of this type in a remote access trojan for the time. BO2k, for example, had symmetric crypto as an optional plugin (and was mostly used for jokes). Modified SSHd's were sometimes used around then, but were large and clunky and had many drawbacks (such as not supporting socket redirection and being annoying to modify).

CNE OPSEC is often an exercise in risk reduction and probability calculation. True NOBUS capability, on the other hand, is mathematically based, something others cannot replicate, ideally something baked in as early as possible (i.e. the specification or hardware). In that sense no software vulnerability is NOBUS, much as we may want them to be.