As an armchair specialist, I don't support the “owning each ssh server on the planet” reactions.
Public networks have too many eyes potentially (not just the admins responsible for specific systems). Traffic to ssh server that corresponds to suspicious activity but is also absent from logs would raise the alarms quite soon.
Hooking the build process also means that the main targets are places that are important enough to have their own siloed software repositories. Getting into two LTS systems was a bonus. I suppose that simpler exploits are available for popular systems (if they run regular complex applications instead of being a minimal empty box that securely does nothing).
The number of modification/decryption layers is probably not arbitrary. Most likely, each was added to evade detection by one or another protection system you and I don't know about, but with which attacker is familiar.
Can you point to an URL where a system has a documented or implemented configuration that correlates traffic to log entries in a manner that can be alarmed on without just going off all the time?
I'm not talking about random packets. There is global and local traffic collection (after all, each pimple on the face of humanity wants to have own little NSA after a wonderful advertisement campaign, and lots of “engineers” are OK with getting paid for that). So when someone capable enough matches obvious abnormal ssh traffic to some intermediate victim with later unwanted behavior of that system, and ties it to the general activities of some known long term actor, that system is going to be studied most thoroughly. Using this backdoor over the internet would mean risking getting busted after each single use. On the contrary, inside high profile “secure” networks such covert management channel would worth the price even if it's single use (as last measure shutdown switch, for example).
I suppose “smart” readers can be as easily manipulated to look in any wrong direction as “dumb” ones. All stories mention what each decryption and indirection step does, but they don't explain why exactly those steps were chosen, that this one hides from intrusion detection system A, and that one prevents collection of runtime activity artifacts by tracing system B, and so on. On one hand, it would be impolite to announce that you study, and know well, how to break your colleague's product, on the other hand, some of those systems might be secret if we talk about state level.
It's obviously not something you just blast into a botnet or something, that's too high-profile. But it would give you one hell of a tool for targeted attacks, and it would be very hard to detect: I don't think there's any automated system that would identify it. Probably the best chance would be on a system which was later identified as comprimised where the operator is sufficiently paranoid to be logging all ssh traffic and doing some inspection of that afterwards (which would be very tedious). Otherwise, the main form of detection would be inspection of the binary itself, which is likely where the various layers come from. It seemed designed to be stealthy from inspection of the code to inspection of the resulting binary, but the fatal flaw there was it didn't have debug info covering it and it lit up on a performance analysis.
All this adds up to a group which wanted to have an easy way into a relatively small but diverse set of high-value targets, it's likely they would have waited for the targeted distro released to reach fairly widespread adoption before exploiting it, and they would have tried to keep it low-profile enough that it would not be discovered for some time.
Public networks have too many eyes potentially (not just the admins responsible for specific systems). Traffic to ssh server that corresponds to suspicious activity but is also absent from logs would raise the alarms quite soon.
Hooking the build process also means that the main targets are places that are important enough to have their own siloed software repositories. Getting into two LTS systems was a bonus. I suppose that simpler exploits are available for popular systems (if they run regular complex applications instead of being a minimal empty box that securely does nothing).
The number of modification/decryption layers is probably not arbitrary. Most likely, each was added to evade detection by one or another protection system you and I don't know about, but with which attacker is familiar.