En ny ransomware-gruppe kaldet BERTI er dukket op med en disruptiv tilgang rettet mod virtualiserede infrastrukturer, især dem, der bruger VMware ESXiI modsætning til konventionel ransomware, BERT lukker virtuelle maskiner ned med magt før kryptering, lammende genopretningsstrategier og forstærkender forretningsforstyrrelser.
Målretning mod kernen af virtuel infrastruktur
BERT, der først blev opdaget i april 2025 og sporet under aliaset "Water Pombero", har allerede påvirket organisationer i Asien, Europa og Nordamerika. Dens Linux-variant er særligt farlig: den registrerer ESXi-miljøer og udfører kommandoer for at tvinge alle aktive virtuelle maskiner til at afslutte, før krypteringsprocessen påbegyndes. Dette eliminerer muligheden for hurtig backup eller live-migrering, hvilket gør gendannelse betydeligt vanskeligere.
Højhastighedskryptering på flere platforme
BERT kan køre op til 50 tråde samtidigt og krypterer hurtigt store virtuelle miljøer. Hvis den startes uden argumenter, begynder den automatisk at afslutte VM'er ved hjælp af native ESXi-kommandoer – hvilket demonstrerer en dyb forståelse af VMware-infrastruktur.
Malwaren er også rettet mod Windows- og Linux-systemer og bruger ofte PowerShell-scripts til at deaktivere forsvar som Windows Defender og Brugerkontokontrol, før den henter data fra russisk-baserede servere. Dens tværplatformsdesign gør det muligt effektivt at angribe hybride IT-miljøer.
Indvirkning på tværs af industrier
BERT har primært rettet sig mod sundheds-, teknologi- og eventsektorerne, og der er beviser, der peger på genbrug af kode fra tidligere lækkede REvil-ransomware-programmer. Denne genbrug indikerer et højt niveau af sofistikering og en bevidst indsats for at øge effekten.
VMware-miljøer med forhøjet risiko
Traditionelle planer for katastrofeberedskab – såsom gendannelse af virtuelle maskiner fra sikkerhedskopier eller flytning af arbejdsbelastninger – bliver ineffektive, når hypervisorer kompromitteres. En enkelt inficeret ESXi-vært kan føre til kryptering af snesevis af VM'er. BERT bruger specifikke filtypenavne til at markere sine ofre: .encryptedbybert på Windows og .encrypted_by_bert på Linux og ESXi.
Afbødningsstrategier
- Overvåg for unormal PowerShell-brug og scriptudførelse, især dem der deaktiverer sikkerhedslag.
- Segmenter ESXi-administrationsnetværk for at begrænse lateral bevægelse.
- Vedligehold offline, uforanderlige sikkerhedskopier og test regelmæssigt gendannelsesprocedurer.
Anbefalinger til RELIANOID Klienter, der bruger VMware
Kunder af RELIANOID Brugere af VMware ESXi anbefales at:
1. Løb ikke RELIANOID på den samme ESXi-vært som arbejdsbelastningerne
Hvorfor: BERT lukker VM'er ned på kompromitterede ESXi-værter før kryptering. Hvis RELIANOID kører på den samme vært, vil den blive stoppet sammen med dine backend-tjenester – hvilket gør det umuligt at omdirigere, foretage failover eller give vedligeholdelsesadgang.
Anbefaling:
- Brug anti-affinitetsregler for at bevare RELIANOID på en separat vært eller klynge fra backend-VM'erne (f.eks. databaser, applikationsservere).
- Hvis muligt, udplacer RELIANOID som en klynge på tværs af flere ESXi-værter for at sikre, at mindst én overlever et ransomware-angreb på hypervisor-niveau.
2. Sikkerhedskopiering RELIANOID Konfiguration fra ESXi-infrastrukturen
Hvorfor: If RELIANOID er krypteret eller slettet, vil konfigurationstab komplicere gendannelsen – selvom backend-tjenesterne gendannes.
Anbefaling:
- Automatiser ekstern RELIANOID konfigurationseksport til sikker, offsite-lagring (uden for ESXi-klyngen).
- Gem sikkerhedskopier på uforanderligt lager (f.eks. objektlagring med politikker for én skrivning og mange læsninger).
3. Beskyt RELIANOID VM mod at blive kompromitteret via VMware-værktøjer eller delte tjenester
Hvorfor: Sofistikeret ransomware som BERT kan misbruge gæsteværktøjer eller svag kommunikation mellem VM'er.
Anbefaling:
- Deaktiver unødvendige VMware Tools-funktioner i RELIANOID VM.
- Undgå at bruge delte ISO/CD-ROM'er eller delte virtuelle diske mellem RELIANOID og andre VM'er.
- Installer ikke yderligere software indeni RELIANOID medmindre det er absolut nødvendigt – minimer dens angrebsflade.
4. Isoler RELIANOID VM fra ESXi Management Plane
Hvorfor: BERT kompromitterer ESXi via administratorgrænseflader. RELIANOID bør aldrig have adgang til ESXi-administration for at forhindre at blive en angrebsbro.
Anbefaling:
- Forbind ikke RELIANOID til enhver portgruppe eller VLAN, der bruges til ESXi-administration eller VMotion.
- Brug kun dedikerede virtuelle NIC'er/VLAN'er til frontend- (WAN/offentlige) og backend- (app-servere) trafik.
- Blokering RELIANOID fra at løse eller kommunikere med ESXi IP'er/undernet.
5. Overvåg for tegn på VM-afslutning eller mistænkelig adfærd indefra RELIANOID
Hvorfor: Hvis BERT forbereder sig på at kryptere ESXi-værten, vil RELIANOID VM'en kan opleve uventede nedlukninger eller kommandoforsøg.
Anbefaling:
- Aktivér syslog-videresendelse fra RELIANOID til ekstern logging/SIEM.
- Overvåg for:
- Pludselige nedlukningshændelser
- Høje CPU/disk/netværksstigninger er ikke knyttet til normal LB-aktivitet
- Usædvanlige SSH- eller loginforsøg
6. Hav en forudkonfigureret standbytilstand RELIANOID Apparat uden for ESXi
Hvorfor: Hvis ESXi-miljøet er fuldstændig kompromitteret, RELIANOID skal hurtigt kunne omimplementeres andre steder (f.eks. cloud, bare metal, anden hypervisor).
Anbefaling:
- Vedligehold en forudinstalleret, forudkonfigureret RELIANOID billede (OVA, ISO eller LXC) på en anden placering (f.eks. cloud-objektlagring, eksternt datacenter).
- Sørg for, at DNS-poster, NAT og SSL-certifikater hurtigt kan omdirigeres til den nye RELIANOID node.
Efterhånden som angreb bliver mere målrettede og avancerede, er behovet for proaktiv infrastruktursikkerhed mere kritisk end nogensinde. RELIANOID er her for at hjælpe dig med at holde dig foran.
Relaterede blogs
