Cybersecurity

10496 readers

170 users here now

c/cybersecurity is a community centered on the cybersecurity and information security profession. You can come here to discuss news, post something interesting, or just chat with others.

THE RULES

Instance Rules

Be respectful. Everyone should feel welcome here.
No bigotry - including racism, sexism, ableism, homophobia, transphobia, or xenophobia.
No Ads / Spamming.
No pornography.

Community Rules

Idk, keep it semi-professional?
Nothing illegal. We're all ethical here.
Rules will be added/redefined as necessary.

If you ask someone to hack your "friends" socials you're just going to get banned so don't do that.

Learn about hacking

Hack the Box

Try Hack Me

Pico Capture the flag

Other security-related communities !databreaches@lemmy.zip !netsec@lemmy.world !securitynews@infosec.pub !cybersecurity@infosec.pub !pulse_of_truth@infosec.pub

Notable mention to !cybersecuritymemes@lemmy.world

founded 3 years ago

MODERATORS

kid@sh.itjust.works

Lanky_Pomegranate530@midwest.social

VMware vCenter Exploit Turns Into Babuk Ransomware Attack on ESXi (wp.me)

submitted 1 week ago by UnLocoPoco@lemmy.world to c/cybersecurity@sh.itjust.works

2 comments fedilink hide all child comments

A suspected China-nexus actor reportedly exploited CVE-2026-59310 only 5 days after disclosure, compromising an estimated 361 IPs across 47 countries.

The attack chain reportedly went from:

vCenter → Root Access → Credential Theft → ESXi → Babuk-derived ransomware

The interesting part is how the attackers turned a vCenter compromise into control of the underlying virtualization infrastructure.

I broke down the full attack chain, persistence mechanisms, credential harvesting, ESXi lateral movement, and ransomware deployment.

you are viewing a single comment's thread
view the rest of the comments

[–] ramble81@lemmy.zip 2 points 1 week ago

I was ready to harp on the 361 installs that left vCenter open publicly, but there’s a little more nuance.

The issue is with the syslog service, which could be configured to take input from Guest OSes (which that is a bad practice too, but less than a public facing vCenter).

Realistically the syslog service within vCenter should only be for management logs from the control plane. If you want to stream that to a centralized aggregator after that to cross reference logs then that would work too and not leave you compromised.