New malware family hijacks SSH keys for long-term server access

Security researchers have uncovered a previously undocumented malware strain engineered to extract Secure Shell (SSH) keys from compromised hosts, granting operators a stealthy foothold that survives password resets, reinstalls, and even partial remediation. Unlike conventional trojans that prioritise immediate financial gain or ransomware deployment, this family is patient. It quietly collects private authentication material, siphons it to attacker-controlled infrastructure, and lies in wait until the operator decides to move, often weeks or months after the initial compromise.

For Australian organisations that rely on SSH to administer Linux fleets, cloud workloads, and operational technology, the parallels with past incidents highlight how exposed unattended key material can be. The discovery lands just as local IT teams are still piecing together lessons from earlier credential-theft waves, including reporting on the Emotet resurfaces campaign that detailed how banking trojans recycled old address books to spread again. The new strain is quieter, but its long dwell time makes it considerably harder to evict.

Anatomy of the credential harvesting routine

The malware arrives through familiar channels: weaponised attachments, exposed Jenkins or GitLab instances, and brute-forced SSH endpoints on edge devices. Once executed, it performs a low-privilege sweep of common key storage paths on Linux and BSD systems, walking directories such as ~/.ssh, /root/.ssh, and corporate jump-host repositories. Anything matching id_rsa, id_ed25519, *.pem, or known corporate key-naming conventions is exfiltrated, along with the corresponding authorized_keys and known_hosts files.

Researchers tracking the campaign note that the operator also harvests SSH agent sockets where available, allowing the malware to reuse loaded keys without touching disk. In some samples, the loader abuses a misconfigured LD_PRELOAD to hook into libcrypto and intercept key material as it is generated by the legitimate ssh-keygen binary. The result is a routine that captures both static key files and ephemeral session credentials, dramatically widening the operator's options for re-entry.

The stolen material is bundled, lightly encrypted with a per-victim XOR pad, and transmitted over HTTPS to a hard-coded command-and-control host. Because the exfiltration channel blends with ordinary outbound traffic, host-based detections often miss it unless defenders are actively watching for unusual curl or wget calls from sshd-adjacent processes.

Why persistent SSH access is a goldmine for operators

Traditional post-exploitation playbooks emphasise credential dumping through Mimikatz on Windows or shadow-file reads on Unix, but SSH keys have quietly become a higher-value target. A stolen private key does not expire, is not subject to multi-factor prompts the way a stolen password is when paired with a hardware token, and frequently grants access to dozens of downstream systems through jump-host chains that defenders rarely audit.

Once an operator holds a private key, lateral movement becomes a matter of opening new tunnels through trusted infrastructure. Security teams at Australian financial-services firms have reported in private briefings that compromised keys routinely unlocked development environments, CI/CD runners, and at least one production Kubernetes control plane, all because the same key had been copied across roles for convenience.

The financial incentives are also shifting. Initial access brokers, many of whom advertise on Russian- and Portuguese-language forums, are now bundling harvested keys into their listings alongside RDP and VPN credentials. Buyers willing to pay a premium receive not just a foothold but a roadmap, complete with known_hosts entries showing which internal addresses the key has reached before. That context turns a generic intrusion into a targeted, low-noise operation that blends with routine sysadmin activity.

Local risk picture and the compliance landscape

Australian organisations are not observing this campaign from the sidelines. ASX-listed companies in Sydney and Melbourne routinely outsource Linux administration to managed-service providers, and several recent ACSC advisories have warned that shared SSH keys between operator and contractor roles are routinely the weakest link in those relationships. When a contractor's laptop is compromised, every key it touches becomes a potential doorway back into the customer environment.

The timing also collides with new compliance expectations. Under the Security of Critical Infrastructure (SOCI) Act and the updated Notifiable Data Breaches scheme, asset owners in sectors from energy to healthcare must report incidents that affect the confidentiality of credentials used to manage systems of national significance. A stolen SSH key used to pivot into a billing platform or a port-operations terminal therefore carries reporting obligations that did not exist a decade ago, and many boards are only now learning to ask the right questions.

Operational realities amplify the exposure. Australian IT teams frequently work across Perth and Brisbane time zones, sharing on-call laptops, syncing ~/.ssh folders through personal Dropbox or iCloud accounts for convenience, and rotating infrequently because rotation requires coordination across teams. Researchers interviewed at the AISA conference in Sydney noted that some attendees admitted their last full SSH key rotation predated the move to hybrid work in 2022, leaving years of drift unaccounted for.

The following table compares a handful of recent credential-focused families that have shaped the threat landscape:

Campaign	Primary target	Credential type	Persistence mechanism	Typical dwell time
New SSH-key stealer	Linux/BSD servers, cloud VMs	SSH private keys, agent sockets	Reuse of harvested keys via jump hosts	Weeks to months
Emotet resurgence (2017-2024)	Windows endpoints	Email credentials, browser passwords	Modular outlook modules, malicious bookmarks	Days to weeks
Mimikatz-based operators	Windows servers, domain controllers	NTLM hashes, Kerberos tickets	Golden ticket injection, scheduled tasks	Hours to days
Rocke group (Linux cryptominer)	Public-facing Linux services	Cloud API keys, weak SSH passwords	Cron persistence, tampered binaries	Months
APT29 SSH toolkit	Linux mail servers, diplomatic targets	OpenSSH keys, config tampering	Patched sshd binary	Years

Readers who want a deeper retrospective on earlier credential-theft waves can find it on the April 2017 archive page, which collected the earliest reporting on banking trojan key logging that predates the current SSH-focused wave by nearly a decade.

Detection, containment and recovery steps

Prevention alone will fail. Defenders should start by instrumenting file-access auditing on key directories, deploying host-based IDS rules that flag reads of id_rsa and related artefacts outside expected backup windows, and parsing shell history for ssh-add and ssh-keygen invocations that did not originate from a known automation user. Forwarding sshd and PAM logs into a SIEM so that subsequent use of a stolen key can be correlated against the compromise window is equally important.

When a host is suspected of being touched, isolation should be surgical rather than blunt. Pulling the network cable risks tipping off the operator and watching them burn bridges; instead, drop the suspect host into a quarantine VLAN with no inbound or outbound SSH, capture volatile memory for forensic triage, and force a full rotation of every key that had been stored on or generated by the system. This is also the point where having a pre-built response toolkit pays off, and a practical walkthrough of terminating malicious processes before running a full scanner can shave hours off the containment window.

Longer term, Australian organisations should move towards short-lived certificates issued by an internal SSH Certificate Authority, eliminating the need for shared long-term keys entirely. Where certificates are impractical, hardware-backed keys stored on YubiKeys or smart cards close the gap considerably, since the private material never leaves the token and cannot be copied by file-grabbing malware. Pairing either approach with the Essential Eight maturity controls that ACSC recommends brings the organisation closer to a posture where credential theft becomes a logged event rather than a catastrophe.

Sector-specific guidance and the regulatory hook

Different Australian sectors face different regulatory hooks when keys walk out the door. Financial-services firms regulated by APRA must notify the prudential regulator of material operational risk incidents, and a stolen key that enables cross-domain movement into a trading system is likely to qualify. Healthcare providers handling My Health Record data fall under stricter obligations under the Privacy Act 1988, with mandatory OAIC notification once a serious harm threshold is crossed.

Energy and water entities designated as systems of national significance under the SOCI Act now have a direct line to the Australian Signals Directorate for active-assistance requests. Frameworks like those assume that the affected entity can describe, within hours, which keys were exposed, where they were valid, and whether any lateral movement followed. Most organisations still cannot answer those three questions without significant manual work, which is why rehearsing the answer in tabletop exercises before an incident is now standard advice from Melbourne- and Brisbane-based incident-response firms.

For smaller Australian businesses without in-house IR capacity, the ACSC's ReportCyber portal provides a triage pathway, and several local MSSPs offer retainer-based surge support that includes key-rotation services. The unit economics of post-incident rotation, often billed per host and per credential, are trivial compared with the cost of a protracted intrusion, a fact that more boards are now willing to hear.