Monday threat briefing: attackers continue to exploit OpenSSH CVE-2024-6387 on internet-facing Linux hosts
Marcus Webb ·
Attackers targeting the OpenSSH regreSSHion flaw, tracked as CVE-2024-6387, continue mass scanning and exploitation against internet-facing Linux servers on Monday mornings. The bug enables pre authentication remote code execution on glibc based systems, which keeps unpatched cloud workloads attractive for botnets and opportunistic crews. OpenSSH on OpenBSD is not affected.
The timing matters because many enterprises roll changes into production late Sunday and early Monday, which often exposes older base images and autoscaling groups that have not been rebuilt with patched OpenSSH packages. Some environments also relied on temporary mitigations that were never removed, which leaves drift between intended and actual configurations.
What to know about CVE-2024-6387
CVE-2024-6387 is a signal handler race condition in sshd that can be triggered during the login grace period, which can lead to code execution as root on affected Linux distributions. Vendors shipped fixes in OpenSSH 9.8p1 and in backported distro packages. Systems using musl or OpenBSD were not impacted, but most mainstream Linux servers that run glibc were.
Exploit attempts are noisy in many cases. Repeated short lived SSH connections, crashes or restarts of sshd, and kernel logs that reference unexpected signals during authentication can indicate probing. Commodity botnets frequently pivot from initial code execution to cryptomining payloads, while more capable actors use the access to stage lateral movement.
What defenders should do now
Patch OpenSSH to 9.8p1 or the latest vendor supported package across all Linux fleets, including golden images and container base layers. Verify that autoscaling groups and cloud launch templates reference updated images, then force instance refresh cycles.
If immediate patching is not possible, set LoginGraceTime to 0 in sshd_config and reload the service, which removes the vulnerable code path. This mitigation can degrade usability, so it should be temporary. Restrict SSH to known management networks with firewalls or security groups, disable password authentication, and require key based access through a bastion or SSH certificates.
Hunt for indicators at scale. Query for sshd crashes and restarts, unusual spikes in short SSH sessions, and new or modified authorized_keys files on servers that should be immutable. Use external scanning to inventory exposed SSH versions, then close gaps between inventory and patch status. Monitor for follow on activity such as new scheduled tasks, outbound connections to newly registered domains, and sudden CPU spikes that indicate cryptomining.
The broader lesson is that commodity remote code execution in core services still outpaces phishing for initial access. Teams that continuously rebuild cloud images, constrain management plane exposure, and validate configuration drift reduce the Monday morning window that automated adversaries rely on.