This does kind of drive home some points. Obviously, once malware is running with your full user permissions, all bets are off. But there are some things that could have mitigated harm here.

The malware wasn’t just mining cryptocurrency—it was also stealing as much sensitive information as possible. It collected:

• SSH keys from ~/.ssh/

If you password-protect your SSH keys with a decent password, it will help address this. Now, the problem is that any software that can get at your SSH keys probably has a shot at also setting up some kind of keylogger system, but at least it makes it not a one-step process.

• Shell history from .bash_history and .zsh_history

Avoiding using sensitive data as command line arguments is a good habit to be in. They’re visible systemwide to all processes on a normal system, which already creates a meaningful leak on multiuser systems, and various pieces of command-line software go out of their way to avoid having passwords and the like passed on the command-line.

• AWS and Azure credentials from ~/.aws/ and ~/.azure/

Not familiar with the current forms of these, but I bet that they provide some way not to store unencrypted credentials there.

• Environment variables and system information

Environment variables are a really good place not to put sensitive data, because software that crashes and uploads a crash dump to God-knows-where will also tend to dump environment variables along with it, as it’s important debugging information. Storing credentials in an environment variable is not a good idea.

• Lists of files in my home directory