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:

1. Initial access: internetexponerade edge-enheter, stulna credentials (t.ex. MSP-konton), eller exploaterade sårbarheter som ger fotfäste.
2. Pivot till vCenter: angriparen tar sig till management-nät/administrationsplan.
3. Installation av BRICKSTORM på vCenter (och ibland vidare mot ESXi/VM:ar), för stabil och dold åtkomst.
4. 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)

1. Isolera management-nätet (kontrollerat): stoppa utgående trafik från vCenter/ESXi där möjligt.
2. Säkra bevis: ta forensiska snapshots/exports av relevanta loggar och system (innan “städning”).
3. Jämför mot rapportens IOCs + regler (YARA/Sigma).
4. Rotera credentials: särskilt vCenter admin, SSO/IdP, servicekonton, och alla konton som kan nå management-planet.
5. Granska vSphere-händelser: snapshots, kloner, nya VM:ar, rolländringar.
6. 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.

🔗 https://github.com/mandiant/brickstorm-scanner

Vad är brickstorm-scanner?

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:

1. Kör verktyget offline eller i ett kontrollerat IR-läge
2. Samla och spara resultat som forensiskt bevismaterial
3. 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.

Resurserna ligger under katalogen ransomware-resources/BRICKSTORM i detta repo:
https://github.com/vmware/vcf-security-and-compliance-guidelines/tree/main/ransomware-resources/BRICKSTORM

Ä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.