On October 12, 2026 at 15:49 UTC, the Interlock ransomware group posted a leak-site listing naming Valenti Management, a restaurant franchise operator, with valentichilisrestaurants.com as the victim domain. Re-checked on October 14, the listing is still up. There is no press coverage, no company statement, and no regulatory filing. A leak-site listing is an advertisement written by an extortionist and it establishes one thing — that it was posted. Both the silence and the listing arriving first are normal, and neither confirms what was taken.
Two details need stating carefully. A May 27, 2014 GE Capital release describes "Valenti Mid-South Management, LLC, a major Wendy's franchisee based in Tampa, FL" operating "125 Wendy's restaurants in Tennessee, Mississippi, Arkansas, Missouri and Pennsylvania, as well as 17 Chili's in Mississippi and Alabama"; business-directory records give 5020 W Linebaugh Ave, Tampa. Tampa back office, restaurants elsewhere — on a twelve-year-old document. And the listing calls the victim a Wendy's operator while naming a Chili's domain; the two brands run through differently named Valenti affiliates, so which legal entity was hit is not established, and that decides who owes notification to whom.
The data the attacker claims is not in the restaurants
The listing enumerates ten categories: supplier price lists and distributor discount agreements, menu launch plans, franchise and partnership contracts, employee Social Security numbers with wage, tax, benefits and medical records, financial and bank statements, real-estate leases and construction contracts, loyalty-program and payment-card data, supply-chain and inventory data, and litigation, insurance and internal-audit files.
Not one of those is a restaurant system. Every category is a corporate-office file share. A multi-unit operator's security spend goes where PCI pushes it — store networks, point-of-sale, the card data environment — and nine of the ten sit outside that boundary.
Which matters because of what the CISA/FBI/HHS/MS-ISAC advisory on Interlock, AA25-203A, released July 22, 2025, says about the encryptor. Interlock actors "have been observed encrypting VMs, leaving hosts, workstations, and physical servers unaffected; however, this does not mean they will not expand to these systems in the future." For a large enterprise that reads as a limitation. For a back office whose whole server estate is a handful of guests on one cluster, it is a complete description of it.
The path there is not an unpatched appliance. No vector is established for this victim, and the advisory's documented initial access is social engineering: drive-by download from compromised legitimate websites, and ClickFix — a fake CAPTCHA that walks the user through opening the Windows Run box and executing a Base64-encoded PowerShell payload. From there the FBI observed a credential stealer (cht.exe) and a keylogger (klg.dll), then compromised credentials and RDP for lateral movement, then domain administrator accounts "possibly by using a Kerberoasting attack." The chain begins on a workstation that ends up unencrypted and ends at the virtual machines.
The practice: the hypervisor should not trust the workstation domain
If vCenter or your ESXi hosts authenticate against the same Active Directory that authenticates laptops, then a domain admin credential harvested by a keylogger on a front-office PC is a hypervisor credential. That is the entire lateral path, and it does not require a single CVE.
Check it, don't assume it. In vCenter, Administration → Single Sign On → Configuration lists the identity sources; if your corporate AD is there and a group from it appears under Global Permissions with the Administrator role, the two planes are one plane. On each host, esxcli system permission list and Host → Configure → System → Authentication Services show the same thing. The fix is to administer the hypervisor with accounts in the local SSO domain (vsphere.local) and grant AD groups read-only at most.
That costs you single sign-on and hands you break-glass credentials to store and rotate — a password-manager entry, a quarterly rotation, and the genuine risk that someone writes it on a whiteboard. The second costs more: management interfaces reachable only from an admin VLAN or jump host — a jump host to build and patch, and admins who now have two hops. In exchange, the vCenter web interface (443, 5480) and host management (443, 902) stop being reachable from the subnet where ClickFix lands.
If you cannot re-architect identity this quarter, do the week-long version instead: make the hypervisor admin group a distinct group whose membership does not overlap Domain Admins, and alert on any vCenter logon sourced from outside the admin VLAN. That is a detection rule, not a migration.
And separate the snapshot from the backup. A snapshot lives on the same datastore as its VM, so an encryptor with datastore access takes both. AA25-203A's own mitigations ask for backups that are offline, immutable, and physically separate — which is storage spend plus the restore-testing time nobody schedules. Patch state is a separate question from identity, and on older releases the fixed version can turn out to be a support contract rather than a download.
How to check this week
- List every account and group that can authenticate to vCenter or an ESXi host, and which directory it comes from.
- Confirm whether the account that can delete a VM is the same account that can delete its backup.
- From an ordinary user workstation, try to reach the hypervisor management interface on 443. If it answers, that is the finding.
- Check whether your backup target is reachable from inside the cluster it is backing up.
- Confirm the file shares holding payroll and contracts are in backup scope, not just the store systems.
North InfoSec runs AI-assisted penetration testing and security assessments, including the kind of chained testing described above. northinfosec.com