Virtualizor BGP-Hijacked Update Compromise

What happened: Virtualizor disclosed that an unauthorized BGP announcement diverted traffic for 162.55.80.0/24 from 28 August through 30 August 2026. During that interval an attacker obtained a technically valid TLS certificate and served a modified update through the trusted Virtualizor path. Because the update client did not cryptographically verify packages, a small number of installations accepted malicious content. Virtualizor could not produce a definitive affected-host list, so every operator whose server could update during the interval needs evidence-led review.

Observed tradecraft: A hosting provider independently reported malicious modifications on five of 34 inspected hypervisor nodes. Its captured evidence included modified Virtualizor files, a root SSH key, a new local account, a Java payload launched from a hidden JVM cache path, systemd persistence, and outbound communication to published infrastructure. That observation is valuable but remains one provider's first-hand dataset; it is not proof that every exposed server received the same artifacts or sequence.

Detection strategy: Detection should begin with product inventory and update-window reconstruction, then move to exact hashes, network pivots, hidden-path Java execution, suspicious Virtualizor/PHP child processes, Linux authentication evidence, and file-integrity comparison. Q02 is the strongest portable host-compromise query, Q03 is an exact infrastructure pivot, Q04 needs a maintenance baseline, and Q01 only identifies likely Virtualizor servers. Routing proof, package provenance, user creation, SSH authentication, and authorized-key changes remain separate telemetry requirements.

Operational consequence: A confirmed root compromise is not safely resolved by deleting the visible service or payload. The running process may survive service-file removal, credentials and host trust may be lost, and the hypervisor is a control point for guest workloads. Preserve volatile and update evidence first, restrict management and update paths, rotate exposed credentials through an approved sequence, and rebuild confirmed compromised hosts from trusted media. Prevention should prioritize signed update provenance, controlled update egress, independent route monitoring, and recoverable host baselines.

Current-run snapshots retain only sanitized plain-text evidence. Remote content was handled as untrusted data and no source-supplied command, code, or instruction was executed.

Claim ledger

Hypotheses are separated into endpoint hunts and explicit evidence gaps; attribution beyond the cited sources is not inferred.

Hypotheses

Affected surface and telemetry

Surface: Softaculous Virtualizor hypervisor control panel and update channel. Exposure: root context on Virtualizor hypervisor hosts; client/billing sessions traversing the affected range. Endpoint events cover only the documented process and IPv4 network views; the remaining platform evidence requires the named routing, product, authentication, AAA, configuration, or forensic repositories.

Coverage boundaries

• No portable Falcon event proves BGP diversion, TLS certificate issuance, or update-package provenance.
• Linux user creation, SSH authentication, and authorized_keys changes require tenant-specific audit/auth ingestion.
• File-write telemetry for PHP and service files is not assumed; integrity comparison is required.
• IPv6 network coverage is not supplied because the published indicators are IPv4 and no documented IPv6 behavior exists.

Atomic values are transcribed only from current-run hashed source snapshots. Exact matches are retrospective evidence, not proof of maliciousness or authorization to block.

ATT&CK mappings are analyst inferences from source-backed behavior, not vendor attribution statements.

These non-CQL hunts close the most important evidence gaps and should be correlated with the endpoint results.

All queries are STATIC-ONLY. Validate event population, fields, semantics, and volume in the intended repository before operational use.

// HUNT: Inventory processes associated with Virtualizor installation paths
// HYPOTHESIS: H01
// USE: inventory
// MITRE: N/A — inventory
// CONF: low
// FP: high
// COST: medium
// TIMEFRAME: 30d — includes the incident window and establishes product presence
// REQUIRES: ProcessRollup2 with ImageFileName, CommandLine, ComputerName, UserName, SHA256HashData
// FALSE POSITIVES: every legitimate Virtualizor process, update, backup, and administrator maintenance task
// TUNING: scope to Linux server groups and compare returned hosts with the application owner's inventory
// VALIDATION: STATIC-ONLY
#event_simpleName = ProcessRollup2
| test(@timestamp >= now() - 2592000000)
| (ImageFileName = /\/usr\/local\/virtualizor\//i or CommandLine = /\/usr\/local\/virtualizor\//i)
| table([@timestamp, ComputerName, UserName, ParentBaseFileName, FileName, ImageFileName, CommandLine, SHA256HashData])
| sort(@timestamp, order=desc, limit=1000)

// HUNT: Java payload or service marker associated with Virtualizor malicious update persistence
// HYPOTHESIS: H02
// USE: hunt
// MITRE: T1543.002
// CONF: high
// FP: medium
// COST: low
// TIMEFRAME: 14d — covers the incident and immediate response period
// REQUIRES: ProcessRollup2 with ImageFileName, CommandLine, ParentBaseFileName, UserName, SHA256HashData
// FALSE POSITIVES: internal testing or legitimate Java services deliberately using the same cache path or incident strings
// TUNING: exclude only documented security-test hosts and approved fixture hashes after owner review
// VALIDATION: STATIC-ONLY
#event_simpleName = ProcessRollup2
| test(@timestamp >= now() - 1209600000)
| (CommandLine = /jre-runtime\.dat|java-jre-update\.service/i or ImageFileName = /\/usr\/lib\/jvm\/\.cache\//i)
| table([@timestamp, ComputerName, UserName, ParentBaseFileName, FileName, ImageFileName, CommandLine, SHA256HashData])
| sort(@timestamp, order=desc, limit=1000)

// HUNT: Connections to provider-observed Virtualizor compromise infrastructure
// HYPOTHESIS: H03
// USE: hunt
// MITRE: T1071
// CONF: medium
// FP: medium
// COST: low
// TIMEFRAME: 14d — covers the incident and immediate response period
// REQUIRES: NetworkConnectIP4 with ComputerName, ContextBaseFileName, ContextProcessId, RemoteAddressIP4, RemotePort
// FALSE POSITIVES: security research, scanner traffic, sinkholing, or later reuse of the same addresses
// TUNING: exclude documented research sensors and require corroborating process, authentication, or file-integrity evidence
// VALIDATION: STATIC-ONLY
#event_simpleName = NetworkConnectIP4
| test(@timestamp >= now() - 1209600000)
| (RemoteAddressIP4 = "31.77.220.138" or RemoteAddressIP4 = "193.32.127.248")
| table([@timestamp, ComputerName, ContextBaseFileName, ContextProcessId, LocalAddressIP4, RemoteAddressIP4, RemotePort])
| sort(@timestamp, order=desc, limit=1000)

// HUNT: Suspicious utility execution tied to Virtualizor or PHP service context
// HYPOTHESIS: H04
// USE: hunt
// MITRE: T1059.004
// CONF: medium
// FP: high
// COST: medium
// TIMEFRAME: 30d — supports incident scoping and maintenance-baseline comparison
// REQUIRES: ProcessRollup2 with two-generation ancestry, ImageFileName, CommandLine, UserName
// FALSE POSITIVES: legitimate updates, backups, package management, administrator support, and monitoring tasks
// TUNING: scope to confirmed Virtualizor hosts and exclude owner-approved maintenance command lines, users, and time windows
// VALIDATION: STATIC-ONLY
#event_simpleName = ProcessRollup2
| test(@timestamp >= now() - 2592000000)
| FileName = /^(?:sh|bash|curl|wget|java|useradd|usermod|systemctl)$/i
| (ParentBaseFileName = /^(?:php|php-fpm|zzvirtservice|virtualizor)$/i or GrandparentBaseFileName = /^(?:php|php-fpm|zzvirtservice|virtualizor)$/i or CommandLine = /\/usr\/local\/virtualizor\//i)
| table([@timestamp, ComputerName, UserName, ParentBaseFileName, GrandparentBaseFileName, FileName, ImageFileName, CommandLine, SHA256HashData])
| sort(@timestamp, order=desc, limit=1000)

Every query remains hunt-only. No alert package or Custom IOA is produced without tenant parse evidence, positive and benign tests, a measured baseline, routing, ownership, SLA, and rollback.

Review expiration, infrastructure reuse, laboratory handling, and local authorization before operational use. Do not contact published infrastructure.

b81a4e1fab9fc4e404d57224fe71e2c143aa93942bd46998789bdc944a7870c7

cdn.nerat.cc
connect.ne-rat.xyz

193.32.127.248
31.77.220.138

type,value,action,severity,expiration,description,tags
sha256,b81a4e1fab9fc4e404d57224fe71e2c143aa93942bd46998789bdc944a7870c7,detect,high,review-2026-10-03,Java payload reported by vendor and provider,source:S01 source:S02
domain,cdn.nerat.cc,detect,high,review-2026-10-03,payload download domain,source:S01 source:S02
domain,connect.ne-rat.xyz,detect,medium,review-2026-10-03,vendor-published C2 domain,source:S01
ipv4,193.32.127.248,hunt,medium,review-2026-10-03,source of reported proxyuser SSH login,source:S02
ipv4,31.77.220.138,hunt,medium,review-2026-10-03,destination of reported Java connection on TCP 2025,source:S02

Deployable playbook · Incident-window exposure and integrity review

1. Record owners and every Virtualizor master/hypervisor before changing state.
2. Export update history, analyzer output, running processes, services, users, SSH keys, connections, and product-file digests; hash the exports.
3. Pilot the review on one non-production or already isolated node and compare against the published incident window and indicators.
4. If corroborated compromise exists, invoke the incident commander and workload continuity plan before isolation or rebuild.
5. Verify known-good image digests, current product version, approved identities, clean analyzer result, and workload health before re-entry.
6. Expand only after evidence capture and recovery steps succeed; otherwise keep nodes isolated and correct the procedure.
7. Rollback means restoring workloads to the last known-good platform, not returning a compromised host to service.
8. Retain evidence hashes, rebuild records, approvals, and owner sign-off.

Deployable playbook · Management credential and egress restriction pilot

1. Capture current API keys, SSH keys, accounts, source restrictions, egress rules, and dependency owners.
2. Confirm a tested break-glass path and health checks for update, licensing, backup, and orchestration workflows.
3. Pilot replacement credentials and egress allowlisting on one non-critical management group.
4. Verify only approved identities and destinations remain while dependent jobs complete.
5. Expand by management ring after 24 hours of successful health and denied-flow review.
6. If a critical integration fails, restore only its prior documented credential or rule, time-box the exception, and investigate.
7. Retain before/after exports, flow samples, job evidence, and approval records.

Continuity rule: preserve volatile evidence and verify alternate administration before isolation, reboot, credential replacement, device reload, or host rebuild.

Validation state: STATIC REVIEW PASSED after local structure/safety, maintained-field, CQL heuristic, provenance, and duplicate gates. This is not Falcon parsing, canary success, or deployment evidence.

Recorded evidence

• Every CQL card remains tenant-unverified and was not executed against Falcon.
• The offline tenant-validation dry run checks extraction and profile readiness only; it does not contact a tenant.
• IOC rows are bound to current hashed snapshots and require context before action.
• Next step: run each query manually in a safe one-hour window, confirm fields and semantics, then expand to the documented lookback.