"Panchan’s Mining Rig: New Golang Peer-to-Peer Botnet"

Reading through this the main take away I got was not to use simple passwords for your ssh connections that are open to access over the internet.

Generally the advice from IPFire is to use long and complex passwords for ssh access but preferably to use Public Key based authentication rather than Password based authentication.

Also don’t create rules to allow ssh access via the internet. If you need to access systems via ssh from a remote location, set up an OpenVPN Roadwarrior tunnel so that any ssh access is only local (but still with Public Key authentication using up to date and strong key exchange, ciphers and MAC’s in your setup.

1 Like

And also

The malware looks under the running user HOME directory for SSH configuration and keys. It reads the private key under ~HOME/.ssh/id_rsa and uses it to attempt to authenticate to any IP address found under ~HOME/.ssh/known_hosts. This is a novel credential harvesting method we haven’t seen used in other malware.

Setting “HashKnownHosts yes” in the ssh_config file, should make it harder to read from the known_hosts file.

If the attacker can read your home directory then you are already compromised.

1 Like


for the records: This has been the default setting for IPFire’s SSH client since early 2020.

As @bonnietwin rightly pointed out, the effect of this is limited: For automated, not particularly sophisticated attacks, it indeed greatly hampers discovering of potential victims. However, if an attacker is able to monitor activities on a compromised system, it will eventually note which other hosts are accessed through SSH from that machine, and can then go forward with attacking them.

On that note, I’d like to repeat myself (from this post of mine): It appears to be way less effort to proactively secure infrastructure than to get rid of infections, particularly given the rather mature post-exploitation activity we recently see for Linux malware.

Thanks, and best regards,
Peter Müller

1 Like