Cloud roundup: New ransomware exploits N-central bug

If you’re still triaging the N-central saga from earlier this week, there’s a new wrinkle: it’s now ransomware. Otherwise it’s a lighter AWS day — two operational upgrades worth bookmarking rather than dropping everything for.

StormEncryptor ransomware ties back to the N-central auth bypass

Microsoft disclosed that Storm-1175, a financially motivated China-linked actor that previously ran Medusa ransomware, has moved to a new strain called StormEncryptor — and the likely entry point is CVE-2026-18577, the N-able N-central authentication bypass CISA added to KEV earlier this week (The Hacker News). Microsoft assesses that CVE-2026-18577 is actually a patch bypass for the earlier CVE-2026-18556, meaning the first fix didn’t fully close the door. Once in, Storm-1175 moves fast — AnyDesk or SimpleHelp for persistence, Advanced IP Scanner for discovery, Mimikatz for credential dumping, then exfiltration and encryption within days of initial access. If you’re an MSP, or downstream of one running N-central, this is the concrete “why” behind all the patch-immediately warnings from earlier this week: confirm you’re on the latest hotfix (not just the first one), and hunt for AnyDesk/SimpleHelp installs you didn’t put there yourself.

EC2 gets application-level health checks, not just instance-level

AWS launched Application Status Checks for EC2 — you configure a protocol, port, path, and expected response code, and EC2 polls it every 60 seconds, feeding the result into the same status-check signal Auto Scaling already watches (AWS). It’s live in all commercial regions plus GovCloud. The gap this closes: instance and system status checks tell you the VM is up, not that nginx crashed or the app inside stopped responding — that’s traditionally been a custom health-check script or an ALB target group doing double duty. If you run EC2 outside an ALB, or want faster detection than an ALB’s own health-check interval, this is a built-in way to get unhealthy instances replaced without writing your own watcher.

AWS DRS now preserves UEFI boot mode on Linux failover

AWS Elastic Disaster Recovery now carries UEFI boot mode through to recovered Linux instances automatically, instead of dropping them into legacy BIOS mode and leaving you to fix boot config after a failover (AWS). No configuration change needed, no extra cost. It’s a small thing until the day you actually fail over and discover your UEFI-dependent app won’t boot — worth knowing about before you need it, not during an actual DR event.

Also worth a look

AWS brought U7in-24TB high-memory EC2 instances to São Paulo for SAP HANA/Oracle-scale workloads, and bumped OpenSearch Serverless from 1,500 to 10,000 collections per collection group — useful if you’re running dense multi-tenant search and were bumping into the old ceiling.

Bottom line

The N-central story just got a lot more concrete: it’s now actively being used to deploy ransomware, so if you haven’t confirmed your hotfix level, do that today. On the AWS side, the two operational items — EC2 app-level health checks and DRS’s UEFI fix — are both worth turning on now, quietly, before you need them.