I oktober 2026 riktade angripare in sig på flera ryska webbhotellsleverantörer samtidigt genom en kritisk sårbarhet i VMmanager 6, en virtualiseringshanteringspanel utvecklad av ISPsystem (en del av Astra Group). Denna panel kör VPS för oss och för många andra leverantörer. Vi drabbades också.
Dina servrar fortsätter att köras. Nedan följer vad som hände, varför, vad vi redan har gjort och vad du behöver göra.
Orsaken: en sårbarhet i leverantörens produkt
Attacken möjliggjordes av en kritisk sårbarhet i själva VMmanager 6-programvaran. Detta var inte en felkonfiguration hos en enskild leverantör: samma sårbarhet utnyttjades samtidigt mot många webbhotellföretag.
FirstVDS, ForestsNet Cloud, MHost, HSH Network och YaColo har offentligt rapporterat intrång via VMmanager 6. Leverantören har bekräftat händelsen: enligt en representant för Astra Group fanns sårbarheten i en av VMmanager-versionerna.
| Datum | Event |
|---|---|
| Oktober 11 – 16 | Angripare infekterar VMmanager 6-paneler genom sårbarheten och etablerar persistens |
| Natten den 16–17 oktober | Aktiv fas: åtkomst till paneldatabaser och, hos vissa leverantörer, till noder som är värd för klientservrar |
| oktober 18 | Vi inledde vår egen utredning och vidtog inledande åtgärder |
| Natten den 17–18 oktober | ISPsystem släpper den första fixen (version 2026.05.2-6) |
| Oktober 19 – 20 | Leverantören släpper ytterligare korrigeringar; arbetet med sårbarheten fortsätter |
| oktober 25 | Leverantören släppte den sista säkerhetsuppdateringen, och vi har installerat den. Detaljer om sårbarheten och attackvektorn har dock fortfarande inte avslöjats. |
Vad säljaren ännu inte har avslöjat
I tidpunkten för publiceringen har ISPsystem inte försett webbhotellsleverantörerna med tillräckligt med information för att med säkerhet kunna åtgärda sårbarheten och verifiera deras infrastruktur. Följande har inte publicerats:
- en beskrivning av sårbarheten och den initiala åtkomstmetoden;
- en CVE-identifierare och en lista över berörda versioner;
- indikatorer på kompromiss (IoC): angriparens serveradresser, fil- och processnamn, tecken på persistens;
- bekräftelse på att de släppta korrigeringarna helt åtgärdar sårbarheten.
Den första korrigeringen släpptes natten till den 18 oktober, följt av flera fler. Enligt andra berörda leverantörer avrådde leverantören själv från att öppna åtkomsten till panelen igen förrän fler patchar har släppts. Utan tekniska detaljer måste varje leverantör rekonstruera attacken på egen hand, från sina egna loggar och genom att dela resultat med kollegor.
Vi har bett leverantören om fullständig teknisk information och kommer att publicera den så snart vi får den. Vi anser att ansvaret för sårbarheten, och för att information om den offentliggörs i tid, ligger hos produktens utvecklare.
Vad som kan ha läckt ut
Angriparna fick tillgång till paneldatabasen, som innehöll:
- listan över servrar och deras IP-adresser;
- e-postadresser till panelkonton;
- root-lösenord som ställs in via panelen vid beställning, ominstallation eller ändring av lösenordet;
- VNC-konsollösenord.
Hos vissa leverantörer nådde angriparna även virtualiseringsnoderna. Där körde de ett program som monterade klient-serverdiskar i skrivskyddat läge och sökte igenom dem efter hemligheter:
- SSH-nycklar,
authorized_keys, lösenordshashar, lösenordshanterare, GnuPG-nycklar; - moln- och DevOps-inloggningsuppgifter: AWS, Google Cloud, Azure, Kubernetes, Docker, Terraform, GitHub, GitLab och npm-tokens;
.envochdocker-compose.ymlfiler, applikations- och databaskonfigurationer;- kryptoplånböcker, fröfraser, API-nycklar för utbyte;
- webbläsarlösenord och cookies, skalhistorik;
- API-nycklar för AI-tjänster, säkerhetskopior av lösenord för restic och Borg.
Programmet kördes på infrastrukturnivå och exekverades aldrig inuti servrarna. Som ett resultat lämnar det inga spår på själva servern, även om data kopierades.
Vi hittade inga spår av det här programmet på våra noder, men med tanke på bristen på information från leverantören kan vi inte helt utesluta att det kördes.
Vad vi gjorde
Utan att vänta på fullständig information från leverantören genomförde vi vår egen undersökning och stängde de åtkomstvägar vi kände till:
- Stängde allmänhetens åtkomst till kontrollpanelen omedelbart efter att attacken upptäckts.
- Hittade och blockerade obehöriga administratörskonton i båda våra paneler, skapade av angriparna för persistens. Detaljer har bevarats för utredningen och delats med leverantören.
- Installerade alla korrigeringar som släppts av ISPsystem.
- Roterade allt som lagrats på panelservern: nodåtkomstnycklar, servicelösenord för fakturerings- och supportintegrationer, DNS och reservnycklar.
- Kontrollerade noderna som är värdar för klientservrar: filer, tjänster, processer och loggar.
Vad som inte påverkades
Baserat på vår utredning påverkade inte händelsen:
- säkerhetskopieringsservrar;
- personuppgifter vid fakturering;
- betalningsuppgifter;
- andra tjänster än den berörda virtualiseringshanteringsplattformen.
Att separera dessa system gjorde skillnaden: åtkomst till en del av virtualiseringshanteringsmiljön gav inte åtkomst till faktureringsdata, klientkonton eller säkerhetskopieringsinfrastrukturen.
Vad du behöver göra
Den största risken är att angriparna använder stulna lösenord och nycklar. Gör följande så snart som möjligt, även om allt på din server ser normalt ut.
- Kryptoplånböcker först. Om servern innehöll plånböcker eller seedphraser, flytta pengarna till nya plånböcker som skapats på en annan, ren enhet.
- Ändra ditt root-lösenord om du ställde in den via panelen och inte har ändrat den sedan dess.
- Växla till SSH-nyckelinloggning och inaktivera lösenordsinloggning.
- Rotera alla hemligheter som lagras på servern: användar- och databaslösenord, SSH-nycklar, API-nycklar och tokens, åtkomst till molntjänster, CI/CD, e-post, betalningssystem och AI-tjänster.
- Återkalla gamla nycklar istället för att bara skapa nya: i molnkonsoler, GitHub, GitLab och hos betalningsleverantörer.
- Kontrollera servern: okända användare, knappar in
~/.ssh/authorized_keys, cron-jobb, okända processer och systemd-tjänster. - Kontrollera inloggningsloggar på servern och i de tjänster vars nycklar lagrades på den: leta efter inloggningar från okända adresser efter den 11 oktober.
Om du har servrar hos andra leverantörer som kör VMmanager 6, gör samma steg där också.
Behövs hjälp?
Hittat något misstänkt på din server, eller är du osäker? Kontakta vårt supportteam – vi hjälper dig att åtgärda det och installerar om servern om det behövs.
Vi ber om ursäkt för besväret, inklusive tiden utan åtkomst till panelen. Vi kommer att uppdatera den här artikeln när ny information från leverantören blir tillgänglig och kommer att publicera en detaljerad obduktion när utredningen är klar.
