If you are like me, you like to tinker with your homelab once in a while but perhaps it doesn’t make sense to have it up and running all of the time. Saving some money on power consumption and also reducing the amount of warm air the homelab produces may also be high on your wishlist.
My homelab consists of 3 Minisforum MS-A2 hosts, connected to a 10Gbps Unifi XG16 switch and home automation is done using Homey Pro in my house. I’m running VMware VCF 9.1 in the homlab as well. Usually I don’t want the homelab running when it’s not being used, so I’ve created 2 scripts to automte bringing the homelab on- and offline. The two scripts combine powering on/off hosts and switches in Homey Pro, and managing (start/stop) VCF services and VMs using PowerShell/PowerCLI. Shutting down the homelab is done in a clean way – a graceful shutdown if you will. You don’t just want to cut the power to a running VMware VCF environmemt, I don’t think vSAN, the VMs and Kubernets clusters would cope in the long run.
One script is used to bring the homelab on-line (Full-VCF-9-1-Start-up.ps1), a couple of variables will dictate wheter I want to bring the VMware VCF environment completely up or if to only get the hosts and vCenter up and running leaving the VCF services (vSAN, VCF Management services, SDDC manager and so on) unavailable.
The second script (Full-VCF-9-1-Shut-down.ps1) will do the same but in reverse – meaning it will shut down the VMware VCF environment including the hosts and the switch the homelab is connected to or, again, using variables to only shutdown the VCF services (vSAN, VCF Management services, SDDC manager and so on) but leave the hosts and the switch still powered on.
All configurations are stored in one file (sample-variables.ps1). Display names of VMs, vCenter fully qualified domain name, IP address to Homey Pro, access token for Homey Pro and so on are all stored in the configuration file. The same configuration file can be called from both the startup- as well as the shutdown script.
By separating the configuration from the main logic in the scripts themselves makes it possible to have multiple configuration files. Perhaps you have multiple VCF fleets in your homelab?
Broadcom har publicerat säkerhetsbulletinen VMSA-2026-0006 som åtgärdar flera allvarliga sårbarheter i VMware vCenter, ESX, Workstation och Fusion. Två av sårbarheterna har fått det högsta möjliga allvarlighetsvärdet (CVSS 9.8) och kan potentiellt ge angripare obehörig åtkomst eller möjlighet att köra kod på utsatta system.
Vad har hänt?
Den 29 juli 2026 publicerade Broadcom säkerhetsrådgivningen VMSA-2026-0006, som omfattar fem identifierade CVE:er i VMware-plattformen. De mest kritiska bristerna påverkar VMware vCenter och kan utnyttjas av angripare med nätverksåtkomst till systemet.
Berörda produkter inkluderar:
VMware ESX
VMware vCenter
VMware Workstation
VMware Fusion
VMware Cloud Foundation
VMware vSphere Foundation
VMware Telco Cloud Platform
VMware Telco Cloud Infrastructure
De mest kritiska sårbarheterna
CVE-2026-59309 – Authentication Bypass i vCenter
Den allvarligaste sårbarheten finns i VMware Directory Service och gör det möjligt för en angripare med nätverksåtkomst att kringgå autentisering och få obehörig åtkomst till vCenter. Broadcom klassificerar bristen som kritisk med ett CVSS-värde på 9.8.
För organisationer som använder vCenter som central administrationsplattform innebär detta en betydande risk eftersom en lyckad attack kan ge direkt tillgång till virtualiseringsmiljön.
CVE-2026-59310 – Directory Traversal som kan leda till kodexekvering
Den andra kritiska sårbarheten finns i vCenters Syslog-server och möjliggör en så kallad directory traversal-attack. En angripare med nätverksåtkomst kan potentiellt utnyttja bristen för att köra godtycklig kod på systemet. Även denna sårbarhet har fått CVSS 9.8.
Kombinationen av fjärråtkomst, hög påverkan och avsaknad av lösningar eller workarounds gör att denna sårbarhet bör prioriteras omedelbart.
Sårbarhet som möjliggör escape från virtuell maskin
CVE-2026-47876 – VMXNET3 Out-of-Bounds Write
En annan mycket allvarlig sårbarhet påverkar den virtuella nätverksadaptern VMXNET3 i VMware ESX. En angripare med administrativa rättigheter i en virtuell maskin kan potentiellt köra kod på ESX-värden. Sårbarheten har ett CVSS-värde på 9.3.
Även om exploatering kräver privilegier inuti en virtuell maskin är konsekvensen betydande eftersom den kan möjliggöra ett genombrott från gästsystem till hypervisorn. Endast VMXNET3-adaptrar påverkas enligt Broadcom.
Övriga sårbarheter
Bulletinen innehåller även två ytterligare sårbarheter:
CVE-2026-41703
En out-of-bounds read-sårbarhet som påverkar ESX, Workstation och Fusion. Den kan leda till informationsläckage eller överbelastningsattacker (DoS). För ESX bedöms allvarlighetsgraden som Important med CVSS 7.6.
CVE-2026-41709
En sårbarhet relaterad till otillräcklig loggning i ESX. En administratör kan utföra vissa åtgärder utan att dessa registreras korrekt i loggarna. CVSS-värdet är 2.7.
Finns det några workarounds?
Nej. Broadcom anger att det inte finns några tillgängliga workarounds för de kritiska sårbarheterna. Organisationer rekommenderas därför att installera säkerhetsuppdateringarna så snart som möjligt.
Rekommenderade åtgärder
För IT- och säkerhetsteam bör följande aktiviteter prioriteras:
Identifiera samtliga VMware vCenter- och ESX-installationer i miljön.
Verifiera aktuell versionsnivå mot Broadcoms säkerhetsbulletin.
Planera och genomför patchning enligt rekommenderade versioner.
Granska exponering av vCenter-system mot interna och externa nätverk.
Säkerställ att VMXNET3-baserade virtuella maskiner omfattas av uppdateringsplanen.
Övervaka loggar och säkerhetshändelser för tecken på obehörig aktivitet fram till dess att patchning är genomförd.
Sammanfattning
VMSA-2026-0006 är en av de mest allvarliga VMware-bulletinerna under året. Framför allt sticker de två vCenter-sårbarheterna ut genom att de kan utnyttjas via nätverket och har fått det maximala CVSS-betyget 9.8. Tillsammans med den allvarliga VMXNET3-sårbarheten i ESX innebär detta att organisationer som använder VMware bör prioritera uppdatering av sina miljöer utan dröjsmål.
Den 8 juni 2026 publicerade Broadcom en ny säkerhetsrådgivning (VMSA‑2026‑0004) som berör flera produkter inom VMware‑portföljen. Rådgivningen beskriver tre allvarliga sårbarheter – CVE‑2026‑41722, CVE‑2026‑41723 och CVE‑2026‑41724 – som alla klassas med CVSS‑poäng 8.0, vilket innebär hög allvarlighetsgrad.
Vad handlar sårbarheterna om?
Broadcom bekräftar att VMware Cloud Foundation Operations och flera relaterade produkter innehåller lagrade cross‑site scripting‑sårbarheter (Stored XSS).
Det innebär att en användare med tillräckliga rättigheter – exempelvis någon som kan skapa policies, vyer eller text‑widgets – kan injicera skadlig kod som sedan körs i administratörens webbläsare. I värsta fall kan detta leda till att angriparen utför administrativa åtgärder utan tillstånd.
Påverkade produkter
Enligt rådgivningen berörs bland annat:
VMware Cloud Foundation
VMware Cloud Foundation Operations
VMware vSphere Foundation
VMware Aria Operations
VMware Telco Cloud Platform
Samtliga sårbarheter är klassade som Important och saknar tillfälliga lösningar – patchning är alltså det enda sättet att åtgärda problemen.
Finns det patchar?
Ja. Broadcom har släppt uppdateringar för alla berörda produktversioner. Några exempel:
Cloud Foundation Operations 9.1.x → Fast version: 9.1.0.0
Cloud Foundation Operations 9.0.x → Fast version: 9.0.2.0 EP2
Aria Operations 8.x → Fast versioner: 8.18.6 och 8.18.7
Organisationer bör omedelbart kontrollera vilken version de kör och uppdatera enligt Broadcoms rekommendationer.
Varför är detta viktigt?
Stored XSS‑sårbarheter är särskilt farliga eftersom de kan ligga kvar i systemet och aktiveras varje gång en administratör öppnar en manipulerad vy eller widget. I miljöer där VMware‑plattformen används för att hantera stora delar av infrastrukturen kan detta få omfattande konsekvenser.
Rekommendationer till organisationer
Uppdatera berörda produkter så snart som möjligt.
Granska interna behörigheter – minimera antalet användare som kan skapa policies och widgets.
Övervaka loggar för ovanliga administrativa aktiviteter.
Säkerställ att säkerhetsrutiner för webbaserade administrationsgränssnitt följs.
Den snabba utvecklingen inom AI – särskilt generativ AI – förändrar fundamentalt hur organisationer designar sin IT-infrastruktur. Traditionella, silo-baserade datacenter klarar inte längre kraven på skalbarhet, automation, säkerhet och kostnadskontroll. Samtidigt har många organisationer upptäckt att publika moln inte alltid levererar förutsägbar ekonomi eller tillräcklig kontroll.
VMware Cloud Foundation (VCF) 9.1 är ett svar på denna utveckling: en enhetlig privat molnplattform designad för att köra produktionskritiska AI-, container- och VM-arbetslaster med hög prestanda, säkerhet och kostnadseffektivitet.
Från traditionell infrastruktur till modern private cloud
Moderna verksamheter kräver:
Självbetjäning (self-service) för utvecklingsteam
Full automation och orkestrering
Stöd för både traditionella och containerbaserade workloads
Konsistent drift över datacenter, edge och moln
Traditionell infrastruktur är ofta rigid och silo-baserad, vilket gör den ineffektiv och svår att skala.
Publika moln löser vissa problem – men introducerar andra:
Oförutsägbara kostnader (t.ex. egress och tjänsteavgifter)
Delad infrastruktur → säkerhets- och compliance-risker
Begränsad kontroll över data och arbetslaster
Private cloud framstår därför som ett alternativ som kombinerar flexibilitet med kontroll och säkerhet.
Vad är VMware Cloud Foundation 9.1?
VCF 9.1 är en fullstack, integrerad private cloud-plattform som kombinerar:
Compute (vSphere / ESX)
Storage (vSAN)
Nätverk (NSX)
Kubernetes (vSphere Kubernetes Service / Tanzu)
Management och automation
Säkerhet och cyberresiliens
Detta skapar en enhetlig plattform som:
Kör alla typer av workloads (VM, containers, AI/ML)
Levererar en konsistent upplevelse över alla miljöer
Sänker total cost of ownership (TCO)
Nyheter i VCF 9.1 – tekniska förbättringar
1. Effektiv infrastruktur och drift i stor skala
VCF 9.1 fokuserar kraftigt på att förbättra resursutnyttjande och skala effektivt:
NVMe Memory Tiering (upp till 40% lägre TCO)
Mjukvarubaserad spegling (ingen RAID-beroende)
Reboot-fri aktivering
Automatiska rekommendationer via VCF Operations
Resultat: → Betydligt lägre serverkostnader och bättre prestanda
Avancerad deduplicering och komprimering
Global deduplicering
Next-gen komprimering
Resultat: → Upp till ~39% lägre lagringskostnader jämfört med traditionella lösningar
Topology-aware scheduling
NUMA-medveten workload-placering
Optimerad CPU-användning
Resultat: → Bättre prestanda för AI- och high-core workloads
2. Skalning och automation
VCF 9.1 introducerar flera förbättringar för storskaliga miljöer:
Upp till 500 Kubernetes-kluster per Supervisor (2.6× ökning)
Idag, den 24 februari 2026, har Broadcom publicerat en viktig säkerhetsadvisory för VMware Aria Operations (tidigare vRealize Operations) och relaterade produkter. Advisoryn VMSA-2026-0001 beskriver tre sårbarheter som tillsammans kan ge upphov till allvarliga risker – från fjärrkörning av kod till privilegieeskalering och lagring av skadliga skript.
Vilka produkter påverkas?
De drabbade produkterna inkluderar framför allt:
VMware Aria Operations – alla 8.x-versioner
VMware Cloud Foundation (VCF) – komponenten Operations i versioner 9.x, 5.x och 4.x
VMware Telco Cloud Platform – Aria Operations i 5.x och 4.x
VMware Telco Cloud Infrastructure – Aria Operations i 3.x och 2.x
Med andra ord: om du använder Aria Operations i en modern VMware-miljö (särskilt i Cloud Foundation eller Telco-miljöer) är det hög tid att kontrollera din version.
De tre sårbarheterna i korthet
CVE-2026-22719 – Command Injection (CVSS 8.1 – Important) En oautentiserad angripare kan under en support-assisterad produktmigrering injicera och köra godtyckliga kommandon. Detta kan i värsta fall leda till remote code execution (RCE) på Aria Operations-nivå. → Attackvektor: Nätverk, men med hög komplexitet (AC:H).
CVE-2026-22720 – Stored Cross-Site Scripting (CVSS 8.0 – Important) En autentiserad användare med rättigheter att skapa anpassade benchmarks kan injicera skadlig JavaScript-kod som lagras och senare körs i administratörens kontext. Detta kan leda till att angriparen utför administrativa åtgärder utan ytterligare autentisering. → Kräver interaktion (UI:R) från en administratör.
CVE-2026-22721 – Privilege Escalation (CVSS 6.2 – Moderate/Important) En angripare med åtkomst till vCenter och viss behörighet i Aria Operations kan eskalera sina rättigheter till full administratörsåtkomst i Aria Operations. → Kräver hög privilegienivå från början (PR:H) och komplex attack.
Broadcom klassar den sammanlagda advisoryn som Important.
Lösningar och åtgärder – vad ska du göra?
Broadcom har redan släppt korrigerande versioner:
VMware Aria Operations 8.x → Uppgradera till 8.18.6
VMware Cloud Foundation 9.x → Uppgradera till 9.0.2.0
Äldre VCF-versioner (5.x, 4.x) → Se KB92148 för specifika instruktioner
Telco Cloud Platform/Infrastructure → Se KB428241
Tillfällig workaround finns endast för CVE-2026-22719 – se KB430349. För de två andra sårbarheterna finns ingen workaround; patch är obligatorisk.
Release notes och patchar hittar du via Broadcoms supportportal (länkar i advisoryn):
Det pratas ibland om “BRICKSTORM-sårbarheten”, men det är viktigt att reda ut begreppen: BRICKSTORM är i första hand en bakdörr/malware-familj som används för långvarig, smygande åtkomst – inte en enskild CVE i sig. Den har observerats i intrång där angripare tar sig in (ofta med stulna legitimationer eller via andra sårbarheter), och sedan installerar BRICKSTORM på VMware vSphere-miljöer, särskilt vCenter och ESXi, eftersom de ger kontroll över hela den virtualiserade infrastrukturen.
Nedan får du en praktisk och defensivt fokuserad genomgång: hur BRICKSTORM relaterar till vCenter/ESXi, varför den är farlig, samt konkreta skydds- och detektionsåtgärder.
Varför vCenter och ESXi är så attraktiva mål
I många organisationer är vCenter “kontrollplanet”: där finns åtkomst till att skapa/ändra VM:ar, snapshotta, klona, hantera nätverk och lagring, och ofta även integreringar mot identitet (AD/SSO).
När en angripare får fotfäste på vCenter/ESXi kan de i praktiken:
Skapa eller dölja “rogue” VM:ar för att köra verktyg, pivotera eller exfiltrera data.
Stjäla snapshots/kloner av VM:ar och sedan extrahera credentials offline (en extremt effektiv credential access-väg).
Tunnla trafik (t.ex. via SOCKS-proxy-funktion) så att kommandokontroll och lateral rörelse ser “normal” ut från insidan.
Utnyttja privilegierade konton/komponenter i vSphere (t.ex. vCenter-konton, vpxuser i vissa scenarier) för att röra sig sidledes.
Poängen: om angriparen kontrollerar vCenter kontrollerar de ofta allt som körs på ESXi.
Vad BRICKSTORM är och vad den gör
Enligt den gemensamma analysen (CISA/NSA/Canadian Centre for Cyber Security) är BRICKSTORM en sofistikerad bakdörr som setts mot VMware vSphere (vCenter och ESXi) samt Windows. Den används för långvarig persistence och kommer med indikatorer och detektionssignaturer (bl.a. YARA och Sigma).
Kända/rapporterade egenskaper i kampanjerna inkluderar bland annat:
Lång “dwell time” (angriparen ligger kvar länge innan upptäckt).
Krypterade C2-kanaler (t.ex. HTTPS/WebSockets/TLS/DoH i rapporterad aktivitet) och ibland proxyfunktion för pivotering.
Masquerading (binärer med legitima namn/utseende) och persistence via uppstartsskript/paths.
Typisk angreppsbild kopplad till vCenter/ESXi
Även om intrång kan börja på olika sätt, återkommer ofta ett mönster:
Initial access: internetexponerade edge-enheter, stulna credentials (t.ex. MSP-konton), eller exploaterade sårbarheter som ger fotfäste.
Pivot till vCenter: angriparen tar sig till management-nät/administrationsplan.
Installation av BRICKSTORM på vCenter (och ibland vidare mot ESXi/VM:ar), för stabil och dold åtkomst.
Missbruk av vCenter-funktioner: snapshots, kloner, “rogue” VM:ar, credential harvesting och vidare lateral movement.
I ett rapporterat incidentexempel hade angripare åtkomst från april 2024 och använde BRICKSTORM för persistence åtminstone fram till 3 september 2025 efter att ha laddat upp den till en intern vCenter-server.
Skydd: så minskar du risken att bli nästa vCenter/ESXi-offer
Här är en defensiv checklista med hög “bang for the buck”.
1) Separera och lås ner management-planet
Isolera vCenter/ESXi management i ett separat nät (ingen direkt access från klientnät/DMZ).
Tillåt administration endast via jump hosts/bastion med hårda kontroller.
Blockera utgående trafik från vCenter/ESXi så långt det går (default deny, tillåt bara det som behövs).
Varför: BRICKSTORM-kampanjer utnyttjar ofta att kontrollplanet är “för nära” resten av miljön och att verktyg/EDR inte alltid täcker appliances.
2) Stärk identitet och åtkomst
MFA överallt för administrativ access (SSO/IdP, VPN, bastion, vCenter).
Minimera och granska privilegier: separata admin-konton, “just enough admin”.
Rotera och skydda servicekonton (särskilt om du är MSP eller har många tenants).
Larma på nya API-tokens, nya administratörer, och ovanliga inloggningar.
3) Patcha och hårdna vSphere-komponenterna
Håll vCenter och ESXi strikt uppdaterade (även om BRICKSTORM inte är “en CVE”, utnyttjas den ofta efter att angriparen fått access via svaga länkar).
Stäng av onödiga tjänster (t.ex. begränsa/disable SSH när det inte behövs).
Aktivera och använd Lockdown Mode där det är möjligt, och strama åt brandväggsregler på ESXi.
Följ VMware hardening guides (och håll konfigurationsavvikelser under kontroll).
4) Säkerhetskopiera och gör recovery realistiskt
Ha offline/immutabla backuper av kritiska system (inkl. vCenter-konfig, viktiga VM:ar).
Öva återställning: om vCenter komprometteras kan du behöva återbygga snarare än “städa”.
Detektion: så upptäcker du BRICKSTORM och liknande aktivitet
Eftersom traditionell endpoint-telemetri ofta är begränsad på appliances behöver du kombinera loggar, nätverksdetektion och vSphere-specifik övervakning.
1) Använd officiella IOCs + YARA/Sigma
Den gemensamma rapporten innehåller indikatorer och detektionssignaturer (YARA & Sigma) och uppdaterades senast 19 december 2025. Börja där och implementera matchning i din SIEM/EDR/NDR/hunting-pipeline.
Praktiskt tips:
Kör YARA där du kan (forensiska image-sökningar, EDR på Linux/Windows där relevant).
Kör Sigma-regler i SIEM (översätt vid behov till din plattformsformat).
2) Övervaka vCenter för “administrativt missbruk”
Larma/hunta på:
Ovanliga snapshot- och kloningsmönster (tidpunkt, frekvens, mål-VM:ar).
Skapande av nya VM:ar som snabbt skapas/avregistreras/stängs ner (kan vara “rogue”/dolda).
Nya/oväntade konton, rolländringar och behörighetseskaleringar.
Aktivitet från oväntade IP-adresser mot vCenter API/UI.
3) Nätverksdetektion: leta efter “osannolika” utgående mönster
BRICKSTORM-aktivitet har rapporterats använda krypterade protokoll och ibland proxyfunktioner, vilket gör att klassisk signaturbaserad detektion kan vara svår.
Larma på:
vCenter/ESXi som plötsligt gör nya utgående TLS/HTTPS-förbindelser till okända destinationsnät.
DNS-over-HTTPS-liknande beteenden från system som normalt inte behöver det.
Tecken på tunnling/proxy (t.ex. många interna destinationsförsök som “kommer från” vCenter/ESXi).
4) Host-baserad jakt på vCenter/ESXi (när du kan)
På vCenter Server Appliance (VCSA) är det extra värdefullt att:
Samla in och centralt lagra loggar (syslog) från vCenter/ESXi.
Larma på förändringar i uppstart/persistence-mekanismer (init-/startup-skript, ovanliga binärer, PATH-manipulation, tjänster som inte borde finnas).
Obs: Exakta filnamn/artefakter varierar mellan varianter och kan vara anpassade per offer, så basera inte allt på en enda IOC. Kombinera TTP-baserad jakt + officiella signaturer.
Om du misstänker intrång: snabb IR-checklista (vCenter/ESXi)
Isolera management-nätet (kontrollerat): stoppa utgående trafik från vCenter/ESXi där möjligt.
Säkra bevis: ta forensiska snapshots/exports av relevanta loggar och system (innan “städning”).
Jämför mot rapportens IOCs + regler (YARA/Sigma).
Rotera credentials: särskilt vCenter admin, SSO/IdP, servicekonton, och alla konton som kan nå management-planet.
Granska vSphere-händelser: snapshots, kloner, nya VM:ar, rolländringar.
Planera för återuppbyggnad: i vissa fall är säkraste vägen att återställa/återinstallera vCenter från “known good” och återansluta hostar kontrollerat.
Sammanfattning
BRICKSTORM är farlig av en enkel anledning: den siktar på din kontrollyta, inte dina vanliga endpoints. När vCenter/ESXi komprometteras kan angriparen:
extrahera credentials via snapshots,
skapa/dölja VM:ar,
och använda plattformen som språngbräda för långvarig åtkomst.
Skyddet handlar därför om att låsa ner management-planet, stärka identitet, segmentera, begränsa utgående trafik och bygga detektion som faktiskt täcker vSphere – plus att implementera de IOCs och YARA/Sigma-regler som publicerats i den gemensamma analysen.
Finns det något verktyg för detektering av BRICKSTORM?
Utöver klassisk logg- och nätverksövervakning finns det nu specialiserade verktyg framtagna specifikt för att upptäcka spår av BRICKSTORM i VMware-miljöer. Ett av de mest användbara är brickstorm-scanner, ett öppet verktyg publicerat av Mandiant.
brickstorm-scanner är ett forensiskt detektionsverktyg som är designat för att identifiera indikatorer på BRICKSTORM-kompromettering, med särskilt fokus på:
vCenter Server Appliance (VCSA)
ESXi-hostar
Linux-system som kan ha använts i attackkedjan
Verktyget är utvecklat baserat på Mandiants incidentresponsarbete och publika hotunderrättelser kring BRICKSTORM.
Vad letar verktyget efter?
brickstorm-scanner söker efter flera typer av artefakter som är typiska för BRICKSTORM-operationer, bland annat:
Kända filhashar och binärer
Ovanliga eller modifierade start-/persistence-mekanismer
Misstänkta processer och tjänster
Avvikelser i filsystemet som tyder på masquerading
Spår av bakdörrsinstallation på vCenter/VCSA
Viktigt: verktyget är byggt för detektion och triage, inte för borttagning. Ett positivt fynd ska alltid följas av en fullständig incidenthantering.
Hur och när bör verktyget användas?
brickstorm-scanner passar särskilt bra i följande scenarier:
Threat hunting i vSphere-miljöer
Efter misstänkt intrång (t.ex. ovanliga vCenter-händelser, snapshots, eller nätverkstrafik)
Proaktiv kontroll av högvärdessystem som vCenter
Rekommenderad praxis:
Kör verktyget offline eller i ett kontrollerat IR-läge
Samla och spara resultat som forensiskt bevismaterial
Korrelatera fynd med:
vCenter-/ESXi-loggar
SIEM-larm
Nätverksdata
Officiella IOCs och YARA/Sigma-regler
Begränsningar att känna till
Som med alla IOC-baserade verktyg gäller:
Ett negativt resultat betyder inte att miljön är ren
BRICKSTORM-aktörer är kända för att:
Anpassa filnamn och paths
Kompilera unika varianter per offer
Verktyget bör därför användas som en del av en större detektionsstrategi, inte som enda skydd
Rekommenderad kombination
För bästa effekt bör brickstorm-scanner användas tillsammans med:
Centraliserad logginsamling från vCenter & ESXi
Nätverksövervakning (NDR) för utgående trafik från management-planet
Regelbunden granskning av snapshots, kloner och VM-skapande
Stark identitetssäkerhet (MFA, begränsade API-tokens, bastion access)
Officiella resurser från VMware (BRICKSTORM-guidelines)
För att hjälpa organisationer att skydda sina VMware-miljöer mot avancerade hot som BRICKSTORM har VMware publicerat en samling guider och resurser inom sitt Security & Compliance Guidelines-repo på GitHub.
Även om GitHub-sidan i sig inte är en fullständig “instruktionsmanual”, fungerar den som en samling av riktlinjer, verktyg och konfigurationsguider som du kan använda för att:
Förbättra din säkerhetskonfiguration
I hela vcf-security-and-compliance-guidelines-projektet finns exempel på:
Hardening-riktlinjer för VMware-komponenter (som vCenter och ESXi) för att minska ytan för angrepp.
Checklistor och policyer som hjälper dig att säkra både VMware Cloud Foundation och vSphere.
Ransomware-resurser kategoriserade utifrån olika hot, inklusive BRICKSTORM, som ger en defensiv ram att arbeta utifrån.
Exempel på vad du får hjälp med
Guidelines-projektet är inte bara en kodbas – det innehåller:
Security Configuration Hardening Guide: detaljerade rekommendationer för hur du sätter säkerhetsinställningar rätt i VMware-produkter.
Ransomware-resurser: samlade dokument och best practices för att förbereda, upptäcka och återhämta dig från intrång som involverar ransomware-liknande bakdörrar såsom BRICKSTORM.
Exempelskript, politiska kontroller och rådatat: som kan implementeras i verktyg och automationer i din miljö.
Hur dessa riktlinjer hjälper mot BRICKSTORM
Den BRICKSTORM-specifika delen av VMware-guiden är tänkt att komplettera andra detektions- och skyddsåtgärder – som de vi redan nämnt (t.ex. brickstorm-scanner). Den används bäst i kombination med:
Standard hardening-guider för vSphere/vCenter, som minskar attackytan generellt.
Policy-drivna kontroller och larm i din SIEM/övervakningslösning.
Automatiserade compliance-kontroller, vilket gör det lättare att se avvikelser från “known good”-konfigurationer.
Eftersom VMware-guiden underhålls tillsammans med andra säkerhetsresurser innebär det att du får kontinuerligt uppdaterade best practices som hjälper dig att:
* implementera least privilege och hård autentisering * konfigurera loggning och audit trails * upptäcka avvikelser i konfigurationer * förbereda återställningspunkter och resilient design
Att använda dessa riktlinjer är ett sätt att proaktivt minska risken för BRICKSTORM-komprometteringar istället för att enbart reagera efter att ett intrång inträffat.
Broadcoms partnercertifieringsprogram för 2026 är utformat för att säkerställa att partnerresurser har rätt kompetens och erfarenhet för att leverera värde till kunderna. Programmet bygger på en tydlig struktur med olika roller, certifieringsnivåer och krav som gör det möjligt för partners att differentiera sig på marknaden.
Certifieringsmodellen – Tre nivåer av expertis
Broadcoms certifieringsmodell är uppdelad i tre nivåer:
Proven Professional – Grundläggande teoretisk förståelse.
Certified Expert – Avancerad kompetens och praktisk erfarenhet.
Knight – Tvärfunktionell expertis och exceptionell förmåga.
Dessa nivåer gäller för fem funktionella roller:
Sales
Pre-Sales
Implementation
Architect
Support
Varje roll har specifika krav och kompetenser som måste valideras innan certifiering beviljas.
Produkter som omfattas av certifiering
Certifieringarna täcker ett brett spektrum av Broadcoms lösningar, inklusive:
Broadcom har publicerat ett säkerhetsmeddelande (Notification Id 36728) som gäller en ny produktversion och säkerhetsuppdateringar för VMware Tanzu Greenplum Backup and Restore 1.32.2. Meddelandet är klassificerat som High severity med en CVSS 3.1-poäng på 7.5, vilket innebär att det rör sig om betydande säkerhetsbrister som kan utnyttjas av angripare om de inte åtgärdas i tid.
Vad är Tanzu Greenplum Backup and Restore?
Tanzu Greenplum Backup and Restore är en komponent i VMware Tanzu Data- och Greenplum-ekosystemet som används för att säkerställa att data i Greenplum-kluster kan säkerhetskopieras och återställas på ett tillförlitligt sätt. Den här komponenten är kritisk i produktionsmiljöer där dataförlust eller driftstopp kan få stora konsekvenser.
Sammantaget om säkerhetsuppdateringarna
Den nya versionen 1.32.2 innehåller ett antal säkerhetsfixar för komponenten greenplum-backup-restore. Broadcom listar flera lösta sårbarheter som adresseras i den här uppdateringen — samtliga är associerade med identifierade CVE-nummer. Dessa sårbarheter kan potentiellt utnyttjas av angripare för att orsaka allvarliga problem, inklusive:
Förhindrande av drift
Exekvering av oönskad kod
Potentiell dataintegritetsrisk
Eskalering av privilegier
Rekommendationer
För alla som använder VMware Tanzu Greenplum Backup and Restore i produktions- eller testmiljöer rekommenderas följande:
Uppgradera snarast
Installera version 1.32.2 så snart som möjligt för att skydda systemet från kända säkerhetsbrister. Support Portal
Granska CI/CD och automatisk patchning
Se till att era build pipelines, konfigurationshantering och patchningsrutiner innehåller steg för att ta med nya säkerhetsuppdateringar.
Testa i isolerade miljöer först
Innan ni rullar ut uppdateringar i produktion — testa först i en staging-miljö för att undvika driftstörningar.
Sammanfattning
Broadcoms säkerhetsmeddelande 36728 beskriver en viktig produktuppdatering till VMware Tanzu Greenplum Backup and Restore 1.32.2 som åtgärdar ett antal säkerhetsbrister med high och medium allvarlighetsgrad. Genom att uppgradera till denna version och följa bästa praxis inom patchhantering minskar ni risken för allvarliga incidenter i era system.
När du kör virtuella maskiner med vSphere delar flera VM:ar på samma underliggande fysiska resurser — CPU, minne, I/O, nätverk och lagring. Om inte dessa resurser är korrekt konfigurerade och balanserade kan det leda till flaskhalsar, låg responstid, eller att vissa VM:ar påverkar andra negativt. Därför är det viktigt att följa vissa best practices för att få ut maximal prestanda, stabilitet och effektiv resursanvändning.
Därför publicerar VMware riktlinjer för hur hårdvara, ESXi-konfiguration, virtuell maskin-konfiguration, lagring, nätverk och infrastrukturhantering bör utformas.
Rekommendationer för hårdvara
CPU & virtualisering
Välj CPU:er som stöder hårdvaruassisterad virtualisering — t.ex. Intel VT-x / AMD-V, och för minneshantering Intel EPT eller AMD RVI.
Kontrollera att hårdvaran finns med på vSphere: s officiella kompatibilitetslista.
Undersök minnet noga — exempelvis genom att köra test under 72 timmar för att upptäcka eventuella minnesfel innan produktion.
Minnes- och lagringskonfiguration
Om du använder minnestiering (memory tiering) — en ny möjlighet i vSphere 9.0 — bör du välja NVMe-enheter med hög uthållighet och minst 100 000 skrivningar per sekund (per enhet) för att hantera belastning bra.
För lagringsenheter: använd snabba back-end-lösningar med rätt RAID, cache och ”stripe size” beroende på arbetsbelastning.
För flash / SSD / NVMe: överväg PCIe-anslutna NVMe-kort — de ger oftast bäst prestanda.
Nätverk & I/O-kort
När du använder snabb lagring — t.ex. NVMe eller flash för swap / cache — är det viktigt att nätverk och I/O-kort (t.ex. PCIe-kort) placeras i platser med tillräcklig bandbredd (tillräckligt många ”lanes”).
Virtuell maskin & ESXi — inställningar som påverkar prestanda
När hårdvaran är på plats är följande inställningar viktiga:
Undvik överdriven minnes-overcommit: överutnyttja inte värdens minne på bekostnad av prestanda.
Använd “Large Memory Pages” (t.ex. 2 MB sidor) där det är möjligt — det kan minska overhead och förbättra minnesprestanda.
För arbetsbelastningar som är känsliga för latens — t.ex. databaser — se till att lagring, I/O-vägar och nätverk är korrekt konfigurerade för låg latens.
Vid användning av funktioner som direkt I/O-åtkomst (t.ex. SR-IOV, DirectPath I/O) — konfigurera korrekt för att undvika prestandaförsämringar.
Infrastruktur- och management-nivå: vCenter & hantering
Prestanda påverkas inte bara av hårdvara och VM-konfiguration — även hur infrastrukturen hanteras spelar stor roll:
Om du använder vCenter Server: tänk igenom databas- och lagringskonfiguration för vCenter, särskilt med avseende på nätverk och I/O.
Använd resurshantering — t.ex. kluster med VMware Distributed Resource Scheduler (DRS), VMware vMotion / Storage vMotion och VMware vSAN (om relevant) — men dimensionera och konfigurera dessa med omsorg för att undvika prestandaproblem.
För vSAN: välj mellan ”all-flash” eller hybrid beroende på krav — och planera nätverk, lagring och layout noggrant.
Hur du kommer igång — praktiska tips
Inventera din hårdvara – kontrollera att CPU, minne, lagrings- och nätverkskort är kompatibla med vSphere 9.0. Kör minnestest om möjligt.
Planera din lagrings- och I/O-struktur – välj lagringsenheter med tillräcklig prestanda, undvik översubskription av I/O, konfigurera korrekt PCIe-bandbredd.
Tänk på hakearbeten och latens-känsliga arbetsbelastningar – använd Large Pages, dedikerade resurser, och överväg direkt I/O/SR-IOV om det behövs.
Konfigurera resurshantering och kluster med omsorg, t.ex. DRS, vMotion, vSAN, sambandet mellan resurser och verkliga arbetsbelastningar.
Övervaka prestanda kontinuerligt — missa inte att gå igenom vCenter-loggar, övervaka I/O, CPU, minne och svarstider på VM:ar.
Slutsats
Att driftsätta en virtuell miljö med vSphere 9.0 är mer än bara att installera ESXi och vCenter — det kräver noggrann planering av hårdvara, lagring, nätverk och konfigurationer för att verkligen få ut god prestanda. Genom att följa best practices från dokumentet kan du skapa en stabil, effektiv och högpresterande virtualiseringsmiljö.
You must be logged in to post a comment.