The interesting part is how the attackers turned a vCenter compromise into control of the underlying virtualization infrastructure.
Not really, that's the management layer - it has authority over everything.
It's why we secure access to such stuff.
this post was submitted on 17 Aug 2026
12 points (100.0% liked)
Cybersecurity
10491 readers
210 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
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
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.