När hackare byter ut dina verktyg mot trojaner – och varför din incidentplan är värd sin vikt i guld

Föreställ er att ni precis har laddat ner det senaste CPU-Z för att kolla om er nya processor verkligen levererar som den ska. Istället för ett diagnostikverktyg får ni en rysk installationsguide och en trojan som plundrar era webbläsarlösenord. Dobryy den’! Välkommen till 2026, där till och med de mest pålitliga verktygen kan förvandlas till fällor över en natt.

Jag, Tricksie, har sett allt från skumma skriptkiddies till statsfinansierade APT-grupper – men det här är lika elegant som det är elakt. När till och med CPUIDs hemsida (bakom HWMonitor) blir kapad i sex timmar och serverar malware, då vet vi att incidenthantering inte längre är en ”nice-to-have”. Det är din livlina. Så låt oss bryta ner vad som hände, varför det är väldigt relevant för er, och hur ni undviker att bli nästa offer.

Varför just supply chain attacks är som att få en trojansk häst levererad med posten

Att hacka ett företag direkt? Trött. Att istället kapra en leverantör som tusentals litar på? Det är modern cyberkrigföring. Här är varför den här attacken är så genialisk (och farlig):

• Förtroendekapital: CPUIDs verktyg används av allt från hemmabyggare till företags-IT. När deras downloadlänkar byts ut, sprids malwaren automatiskt till en redan trogen användarbas.
• Kort men dödlig exponering: Sex timmar räcker för att smitta hundratals (om inte tusentals) system. Windows Defender fångade de flesta fallen – men det räcker med en lyckad infektion för att få fotfäste i ett nätverk.
• Målmedveten malware: Den här skadekoden var inte någon generisk ransomware. Den sikade specifikt på Chrome-lösenord genom att utnyttja IElevation-gränssnittet. Det betyder att angriparna visste exakt vad de ville ha.

FBI, AWS och varför ”major incident” inte längre är hyperbole

Whilst vi pratar om incidenthantering – låt oss titta på två fall som visar varför ni behöver en plan innan skiten träffar fläkten:

1. FBI:s övervakningsnätverk hackades: I februari upptäcktes onormal aktivitet i deras system för elektronisk övervakning (ja, de som lyssnar på er). Två månader senare klassades det som en ”major incident” enligt amerikansk lag. Poängen? Till och med de som jagar hackare blir jagade.
2. AWS:s incidentresponstjänst: Amazon säljer nu en tjänst som lovar att ”automatisera 99% av era säkerhetslarm” och ge er tillgång till experter på minuter. Om de prioriterar snabb incidenthantering, borde ni inte det då också?

Min favoritdetalj? FBI:s hackare använde en kommersiell ISP:s infrastruktur för att kringgå säkerhetskontroller. Det är som att stjäla en polisbil för att råna en bank. Bold.

Den obekväma sanningen: Er incidentplan är (förmodligen) skräp

Jag har sett incidentplaner som är allt från ”ring IT-chefen” till 200-sidiga bindare som ingen läst. Här är varför de flesta misslyckas:

• De är statiska: En plan från 2020 hjälper er inte mot 2026 års AI-drivna malware.
• Ingen övar: ”Vi kör en tabletop-övning om året!” – säger företaget som paniksluter ner allt när det verkligen händer.
• Oklar eskalationsväg: Vem fattar beslut när chefen är på semester? (Spoiler: Ingen.)
• Glömmer ”mänskliga faktorn”: Folk klickar på fel saker. Det kommer hända. Planera för det.

En gång hjälpte jag ett företag efter en ransomware-attack. Deras ”plan” bestod av att betala lösen. Problemet? De hade ingen Bitcoin-plånbok, och när de väl skapat en hade angriparna höjt priset. Öva era krisscenarier. Inklusive de pinsamma.

Checklista: 7 saker ni måste ha på plats innan nästa attack

1. Automatiserad övervakning av kritiska verktyg: Om ni laddar ner programvara från tredje part (som CPU-Z), se till att er EDR-lösning (CrowdStrike, SentinelOne etc.) blockerar okända installerare som dyker upp.
2. Isolerade miljöer för nya verktyg: Inget nytt program får köra i produktionsmiljön förrän det har varit i karantän i 24–48 timmar. Inga undantag.
3. Tyglade adminrättigheter: Malwaren i CPUID-fallet försökte utnyttja Chrome via COM-gränssnitt. Om era användare inte har lokal adminåtkomst, begränsas skadan avsevärt.
4. Incidentteam med tydliga roller:
   • Vem ledar insatsen?
   • Vem kommunicerar internt/externt?
   • Vem har mandat att stänga ner system?
5. Förberedda meddelanden: Ha mallar klara för alla scenarier – från ”vi undersöker” till ”vi är komprometterade”. Inga ”oops”-tweets.
6. Backup som faktiskt fungerar: Teståterställ era backuper kvartalsvis. En korrupt backup är lika värdelös som ingen backup.
7. Relationer med experter: Vet vilka externa säkerhetsföretag ni kan ringa klockan 3 på natten. (AWS Incident Response är ett alternativ – men se till att ni har kontrakt innan skiten händer.)

Nästa steg: Från panik till proaktivitet

Att läsa det här räcker inte. Här är vad ni gör imorgon:

1. Kartlägg era ”crown jewels”: Vilka verktyg/program måste fungera? Om de kapas – vad är er plan B?
2. Kör en ”what if”-övning: ”What if HWMonitor plötsligt börjar be om våra Active Directory-lösenord?” Hur hade ni upptäckt det? Hur hade ni stoppat det?
3. Uppdatera er EDR: Se till att era säkerhetsverktyg aktivt blockerar:
   • Okända installerare från kända domäner (som CPUID).
   • Ovanliga processer som försöker läsa minnet från webbläsare.
4. Träna era användare: Skicka ut ett falskt ”uppdateringsmejl” för ett verktyg ni använder. Hur många klickar? (Jag garanterar att svaret kommer chockera er.)
5. Granska era leverantörer: Fråga dem: ”Vad händer om era hemsida kapas och börjar servera malware?” Deras svar kommer antingen lugna er – eller få er att byta leverantör.

Och kom ihåg: Om ni någonsin ser en rysk installationsguide när ni försöker uppdatera CPU-Z – stäng av datorn. Ta en fika. Andas. Sen kan ni börja panikåterställa från backup.

– Tricksie 🦊
PS. Om ni undrar varför jag nämnde ”Dobryy den’” – det var det ryska installatörsmeddelandet som dök upp i CPUID-attacken. Ja, hackarna kunde ha ansträngt sig lite mer med lokaliseringen.