tag: Virtualizor · 2 items
- Engineer — Act: Any Virtualizor installation that auto-updated after August 28 at ~20:57 UTC may have received the trojanized package and should be treated as compromised; immediately audit those hypervisors for persistence mechanisms (cron, SSH keys, kernel modules) and isolate pending forensic review.
- SOC/IR — Act: Confirmed root-level compromise on 5 hypervisors with an update-window starting August 28 at 20:57 — sweep all Virtualizor hosts for new root SSH authorized_keys, unexpected cron jobs, or novel init services added after that timestamp; initiate assume-breach IR process for any positive hits.
- Leader — Plan: If your infrastructure or a managed hosting vendor runs Virtualizor, request a written attestation from them confirming whether their hypervisors fell within the compromised update window, and add BGP-hijack supply-chain risk to the next vendor risk review cycle.
- Engineer — Act: Any environment running Virtualizor may have received a trojaned update; immediately verify installed binary integrity against known-good checksums and audit servers for post-compromise artifacts. If update timestamps align with the hijack window, treat the host as compromised and scope accordingly.
- SOC/IR — Act: Identify all Virtualizor-managed hosts in the estate and flag them for assume-breach review; hunt for unusual process execution, outbound connections, or file modifications following recent update activity on those hosts.
- Leader — Learn: BGP hijacking to intercept software update traffic is a sophisticated supply-chain vector that bypasses code-signing assumptions when the update mechanism itself is redirected; useful context for reviewing how third-party software update trust is modeled in your vendor risk program.