Two years on, attackers still exploit OpenSSH regreSSHion CVE-2024-6387 for root access on Linux servers

Criminal botnets and initial access brokers are still exploiting CVE-2024-6387, the OpenSSH regreSSHion flaw, on internet-facing Linux servers two years after disclosure. On Wednesday, security teams warned that thousands of unpatched hosts remain reachable, giving threat actors a reliable path to root shells and rapid lateral movement inside enterprise networks.

The vulnerability is a signal handler race in sshd that enables unauthenticated code execution on glibc based distributions. OpenSSH 9.8p1 and vendor backports fixed the issue, and a temporary mitigation sets LoginGraceTime to 0 to remove the vulnerable timer.

Active exploitation and tradecraft

Exploit reliability improves with repeated connections, so botnets script high frequency preauth attempts from rotating infrastructure until the race condition triggers. Observed payloads include XMRig crypto miners, lightweight backdoors, and short bash chains that fetch second stage loaders, followed by credential theft and discovery.

Linux focused crews such as Kinsing, 8220, and P2PInfect have historically targeted management ports and misconfigured services, and incident responders continue to tie their activity to opportunistic OpenSSH exploitation. Ransomware affiliates also purchase this access from brokers, then pivot with harvested SSH keys and remote tools for data theft and extortion.

A related issue, CVE-2024-6409, affected some vendor builds with distribution specific patches in the privsep child. Enterprises should confirm their distribution’s advisory coverage for both identifiers since banner strings often do not reflect underlying patch backports.

Public scans still identify older OpenSSH versions at scale, although many operators strip or obfuscate version banners. Defenders should validate package provenance rather than relying on banner checks, and verify that restarts applied patched sshd binaries.

Mitigation and detection

Apply vendor patched OpenSSH packages or move to 9.8p1 or later, then restart sshd and confirm with package and process checks. If immediate patching is not possible, set LoginGraceTime to 0 and enforce connection rate limiting at the network edge to reduce the resource exhaustion risk that mitigation introduces.

Reduce attack surface by placing SSH behind a bastion or a private access service, restrict source networks, and require hardware backed keys. Disable password authentication and agent forwarding, rotate known_hosts and authorized_keys if compromise is suspected, and audit for new users and sudoers changes.

Hunt for preauth crash logs from sshd, bursts of short lived connections, unexpected core files, and new processes invoking curl or wget as root. Look for XMRig binaries, kinsing artifacts, persistence via cron or systemd units, and tampering with ld.so.preload.

The persistence of successful exploits against a core remote access service highlights the risk of unmanaged perimeter daemons and long tail patch cycles. Treating SSH as a managed application with strict exposure controls, continuous attestation, and enforced key policy reduces dwell time for commodity botnets and higher tier intrusion sets.