> Whilst the handshake and data security mechanisms are 
  > arguably well designed the persistence mechanism isn’t in 
  > any sense stealthy.  This particular rootkit would be 
  > easily detectible using tools as Tripwire and Rootkit 
  > Hunter.

Say the persistence mechanism wasn't there. How would you go about detecting this rootkit?

If the persistence mechanism wasn't there, you'd be able to detect it from the added files -- /bin/dh and ipt_ip_udp.so in your modules directory. Tools like tripwire work by hashing the files on your system so you can tell at a glance when one changes.

there's nothing to stop it hooking opendir() and friends to hide it from ls!

True, if the tool has been built with dynamic linking. Statically linking your security tools makes it a lot harder to hide your naughtyware. Depending on how deep the rabbit hole led in your infection, there are of course other things that could be done, like a malicious kernel module overriding the getdirentries(2) syscall, which would mean even more fun manually parsing the directory entries.

Then again, the best course of action is to pull that server down and build a new clean box, and do all the analysis offline. Boot from some sort of read-only media to minimize the threat, and analyze from a known good kernel, making sure to not run anything from the infected box unless you're goddamn sure what you're doing.

One could argue that network facing machines should boot from RO media anyway with data stored on NO_EXEC volumes.

A good firewall would prevent CnC of this machine, since they replace sequence numbers and source ports. Sadly, public research into rootkits has been stale for a decade. My guess is since nobody actually implements any strong security measures in their OSS machines there's no need to advance the state of attacks.

Anyone know the hash, pls? Thanks. We need to add this to ELF malware repository. It's a serious effort to raise detection of ELF malware, reference: https://www.youtube.com/watch?v=Q9RcVjCXIOU

Is known what distros are affected by this backdoor, who made it and who knows the magic key?

> Is known what distros are affected by this backdoor

From my understanding of the article, it was a rootkit, rather than a pre-existing backdoor. So it would have been something that was installed after a system had been penetrated using other exploits.

Thanks for the clarification.

Yep

Magic bytes are widely used in Backdoor development.

The are actively responding to a possible intrusion and are therefore not motivated to give away specific details of the attacker's techniques to either the attacker or other hostile parties.

The MD5's you want are specific to the kit used to attack their client and would disclose the effectiveness of their response and investigation to an attacker,and are also not much good to anyone else. In the Disqus comments the author offers to provide them on request from legitimate researchers.

This is a standard precaution, not at all bogus, and it is great that they were able to share as much as they did for general use.

A better explanation is provided down-thread on the article's comments page. The author comments are overly laden with PR-ese, but there's not much you can do with MD5 hashes of files that are customized per system anyway. Since this rootkit modifies system files and doesn't alter the kernel to hide itself, standard rootkit detection tools will find it.