Hur en AI-förstärkt aktör bröt sig in i över 600 FortiGate-enheter utan exploit

Mellan den 11 januari och den 18 februari 2026 komprometterade en ryskspråkig, ekonomiskt motiverad aktör fler än 600 FortiGate-brandväggsapparater i fler än 55 länder – och gjorde det utan att utnyttja en enda sårbarhet i produkten. Amazon Threat Intelligence, som publicerade undersökningen den 20 februari 2026, uppger att aktören hittade hanteringsgränssnitt exponerade mot internet på portarna 443, 8443, 10443 och 4443 och tog sig in med vanligt återanvända lösenord på konton utan multifaktorautentisering. De enhetskonfigurationer som den hämtade ut innehöll SSL-VPN-autentiseringsuppgifter med lösenord som gick att återställa, administratörsuppgifter, brandväggsprincip och nätverkstopologi. Kommersiella stora språkmodeller användes genom hela operationen, skrev spaningsverktyg och utformade attackplaner; enligt en separat forskare som hittade aktörens egen server var en modell också konfigurerad att köra offensiva kommandon. Denna incident är en post i Orca AI Incident Archive, som innehåller den fullständiga dokumentationen, dess källunderlag och dess bedömning, tillsammans med de närliggande fallen i serien.

Vad Amazon rapporterade och hur de fick reda på det

Rapporten ”AI-förstärkt hotaktör får åtkomst till FortiGate-enheter i stor skala” tillskrivs CJ Moses, CISO för Amazon Integrated Security, och publicerades på AWS Security Blog den 20 februari 2026. Dess första väsentliga fynd är ett negativt sådant: ”Ingen exploatering av FortiGate-sårbarheter observerades.” Den initiala åtkomsten var genomgående inloggningsuppgiftsbaserad – systematisk skanning efter administrationsgränssnitt på de fyra portarna ovan, följt av autentiseringsförsök med vanligt återanvända inloggningsuppgifter.

Det som gjorde kampanjen synlig var aktörens egen operativa säkerhet. Amazon säger att de identifierade infrastrukturen som var värd för de skadliga verktygen genom rutinmässigt hotunderrättelsearbete, och att samma server innehöll AI-genererade attackplaner, offerkonfigurationer och källkoden för anpassade verktyg, lagrade utan kryptering. Den missen gav Amazon en nästan fullständig bild av metoden. "Det är som ett AI-drivet löpande band för cyberbrottslighet", säger rapporten.

De stulna konfigurationsfilerna är pivoten från apparaten till nätverket bakom den. Enligt Amazon innehåller de SSL-VPN-användaruppgifter med återställbara lösenord, administrativa autentiseringsuppgifter, fullständig nätverkstopologi och routinginformation, brandväggsprinciper som avslöjar den interna arkitekturen samt IPsec VPN-peer-konfigurationer. Aktören skrev AI-assisterade Python-skript för att tolka, dekryptera och organisera dem.

Efterexploateringen, med Amazons egna ord

Väl inne följde aktören ett standardiserat, väl dokumenterat tillvägagångssätt. Dess operativa dokumentation, skriven på ryska, beskriver hur man använder Meterpreter med mimikatz-modulen för att köra DCSync-attacker mot domänkontrollanter och extrahera NTLM-lösenordshashar från Active Directory. I bekräftade intrång erhöll den fullständiga databaser med domänuppgifter. Amazon noterar minst ett fall där kontot Domain Administrator använde ett lösenord i klartext som antingen återanvänts från FortiGate-konfigurationen eller var oberoende svagt.

Därifrån är de dokumenterade teknikerna pass-the-hash och pass-the-ticket mot ytterligare infrastruktur, NTLM relay med vanliga poisoning-verktyg samt fjärrkommandoexekvering på Windows-värdar. Aktören riktade sig specifikt mot Veeam Backup & Replication-servrar med PowerShell-skript, kompilerade dekrypteringsverktyg och försök mot kända Veeam-sårbarheter – ett beteende som Amazon beskriver som "förenligt med åtgärder inför ransomware-attacker", även om rapporten inte dokumenterar att ransomware har distribuerats.

Aktörens anteckningar refererar till flera CVE:er, bland annat CVE-2019-7192, CVE-2023-27532 och CVE-2024-40711. BleepingComputer, som rapporterade om rapporten den 21 februari 2026, identifierar den första som en QNAP-sårbarhet för fjärrkodkörning och de två senare som Veeam-problem. Ingen av dem var vägen in. Mer talande är att samma anteckningar dokumenterar upprepade misslyckanden: tjänster som redan var patchade, stängda portar, exploit som inte gällde för måloperativsystemet. För ett bekräftat offer drog aktörens egen bedömning slutsatsen att nyckelinfrastrukturen var "välskyddad" med "inga sårbara exploateringsvektorer".

Två begränsningar i tillskrivningen är värda att klargöra. Amazon uppger att aktören "inte är känd för att vara associerad med någon avancerad ihållande hotgrupp med statligt sponsrade resurser", och att AWS-infrastruktur inte observerades vara inblandad i kampanjen.

Där AI:n faktiskt satt

Amazons redogörelse för AI-lagret är specifik om roller men tyst om produkter. Aktören använde minst två olika kommersiella LLM-leverantörer, enligt rapporten: en som den primära verktygsutvecklaren, attackplaneraren och operativa assistenten, och en andra som kompletterande planerare när aktören behövde hjälp att pivotera inom ett visst nätverk. I ett observerat fall skickade aktören in en komplett intern topologi – IP-adresser, värdnamn, bekräftade autentiseringsuppgifter och identifierade tjänster – och bad om en steg-för-steg-plan för att nå system som dess befintliga verktyg inte kunde komma åt.

Amazons bevis för att verktygen var maskingenererade är stilistiska snarare än forensiska. Det listar redundanta kommentarer som bara upprepar funktionsnamn, en arkitektur som satsar mer på utdataformatering än på funktion, JSON som parsas genom strängmatchning i stället för korrekt deserialisering, och kompatibilitetsshim med tomma dokumentationsstubbar. Verktygen fungerade för aktörens snäva fall och misslyckades i kanterna. Volymen, noterar Amazon, skulle normalt antyda ett utvecklingsteam; här kom den från en aktör eller en mycket liten grupp.

Det som AWS-rapporten inte innehåller är någon modellleverantör, något produktnamn eller något omnämnande av Model Context Protocol. De finns i en andra forskningsstudie som publicerades dagen därpå.

Servern, och namnen som Amazon inte publicerade

Den 21 februari 2026 publicerade säkerhetsbloggen Cyber and Ramen sin egen analys av en öppen katalog på 212.11.64[.]250:9999, som ligger hos AS4264 (Global-Data System IT Corporation, Zürich) – en av de två adresser som Amazon listar som hotaktörsinfrastruktur. Forskaren räknade 1 402 filer i 139 underkataloger, inklusive stulna FortiGate-konfigurationssäkerhetskopior, Active Directory-kartläggningsdata, dumpar av autentiseringsuppgifter, Nuclei-skanningmallar och Veeam-verktyg för extrahering av autentiseringsuppgifter, plus två mappar namngivna efter Claude som innehöll över 200 filer med uppgiftsutdata, sessionsdiffar och cachade prompttillstånd.

Två anpassade komponenter namnges i den analysen. ARXON beskrivs som en Python-server för Model Context Protocol som tar emot rekognosering per mål, anropar DeepSeek för att generera attackplaner och underhåller en kunskapsbas som växer med varje mål; den innehåller också skript för batchvis skapande via SSH av FortiGate VPN-konton och validering av inloggningsuppgifter för Domain Admin. CHECKER2 är en Go- och Docker-baserad orkestrerare för parallell VPN-skanning, med loggar som visar 2 516 mål i 106 länder. Forskaren uppger att inga offentliga referenser till något av verktygen kunde hittas, vilket tyder på att båda byggdes för denna operation.

Samma analys beskriver en exponering av samma server i december 2025, denna gång innehållande en kopia av HexStrike, ett offensivt MCP-ramverk med öppen källkod, och en .claude-inställningsfil som på förhand godkände att Claude Code fick köra Impacket-verktyg, Metasploit och hashcat mot hårdkodade domänuppgifter som tillhörde en anställd på ett stort asiatiskt mediebolag. I februari, säger forskaren, hade aktören gått från den utgångspunkten med öppen källkod till ARXON och CHECKER2 – en utveckling på ungefär åtta veckor.

BleepingComputer förmedlade dessa fynd i en uppdatering av sin artikel från 21 februari. Distinktionen spelar roll: ARXON, CHECKER2, DeepSeek och Claude Code är forskarens tolkning av filer, loggar och inställningar i en osäkrad katalog. Amazon, som hade oberoende tillgång till samma infrastruktur, namngav ingen av dem. Ingen modellleverantör har bekräftat något av det.

Vad som är etablerat, vad som vilar på en enda källa

Tre påståenden vilar på två oberoende parter. Fortinets eget blogginlägg från den 6 mars 2026, "Attacks at the Speed of AI", anger att Fortinet "observerade ingen exploatering av FortiGate-sårbarheter" och att kampanjen lyckades via exponerade hanteringsportar och svaga autentiseringsuppgifter med enfaktorsautentisering, med hjälp av lösenordssprayning. Det bekräftar Amazons mekanism från leverantörens sida, utan att någon av parterna hade sett den andras publicerade bevis.

Enbart Amazon är källan till omfattningen – fler än 600 enheter, fler än 55 länder, fönstret januari till februari – och till aktörsprofilen: rysktalande, finansiellt motiverad, låg till medelhög teknisk basnivå, stort AI-beroende, grunt djup efter exploatering, otillräcklig operativ säkerhet. Ingen utomstående part har återgett siffran 600.

Enbart Cyber och Ramen är källan till de namngivna verktygen, modellleverantörerna, filantalen och de 2 516 skanningsmålen. Dess egna bevisdokument bekräftade intrång vid ett industrigasföretag i Asien–Stillahavsregionen, en telekomoperatör i Turkiet och mediebolaget från decemberexponeringen, med rekognosering som hänvisar till Sydkorea, Egypten, Vietnam och Kenya – en bekräftad grupp av offer i minst fem länder, långt under de 55 som Amazon anger. De två siffrorna mäter olika saker, och ingen av dem har offentligt avstämts.

Fortinets svar – och den omfattning det inte bekräftade

"Fortinets inlägg, skrivet av Carl Windsor och daterat den 6 mars 2026, instämmer med Amazon om mekanismen men går isär om omfattningen. "Utifrån Fortinets utredning och övervakning påverkades ett fåtal kunder av denna attack", står det. "Vi håller på att meddela dessa organisationer." Det bekräftar inte 600 enheter, anammar inte Amazons antal länder och namnger inte aktören."

Fortinets inramning är att tekniken är gammal och automatiseringen ny: lösenordssprayning mot dåligt skyddade edge-enheter, nu driven av no-code, promptbaserade konversationer. Företaget uppger att attacken "skulle ha varit omöjlig med MFA på plats" och "mycket osannolik att lyckas" med en aktiverad policy för lösenordskomplexitet. Det publicerade också indikatorer: administratörsåtkomst från 212[.]11.64[.]250 eller 185[.]196.11[.]225, skapandet av konton med namnen fortiuser, fortinet-support eller fortinet-tech-support, oväntade VPN-konfigurationer eller -användare samt skript schemalagda att köras som en persistensmekanism.

Detta är en skillnad i omfattning, inte en tvist om huruvida kampanjen ägde rum. Ingen som namnges i akten bestrider intrånget; arkivet ger det betyget A, utan någon markering för omtvistat, och registrerar verklig skada.

Vad förändrades efteråt?

Det finns ingen CVE och ingen patch, eftersom det inte fanns någon sårbarhet. Åtgärden är konfiguration, och båda organisationerna enades om samma lista. Amazon uppger att man delade komprometteringsindikatorer med relevanta partner, samarbetade med branschpartner och hjälpte organisationer att vidta åtgärder som minskade aktörens effektivitet; rapporten anger inte hur många organisationer som underrättades. Fortinet uppger att man underrättar drabbade kunder direkt.

Den tekniska vägledningen är densamma för båda: ta bort administrativ åtkomst från internetexponerade gränssnitt och hantera via en intern eller out-of-band-väg; framtvinga MFA för administrativ åtkomst och VPN-åtkomst; tillämpa lösenordskomplexitet; rotera SSL-VPN-autentiseringsuppgifter på alla enheter vars hanteringsgränssnitt var eller kan ha varit åtkomligt; granska återanvändning av lösenord mellan FortiGate VPN-konton och Active Directory; samt isolera backupinfrastrukturen, patcha den och behåll oföränderliga kopior.

För identifiering pekar Amazon på DCSync-aktivitet (händelse-ID 4662 med replikeringsrelaterade GUID:er), nya schemalagda aktiviteter som namngetts för att efterlikna legitima Windows-tjänster, ovanliga fjärrhanteringsanslutningar från VPN-adresspooler, artefakter från LLMNR- och NBT-NS-förgiftning samt obehörig åtkomst till säkerhetskopierade autentiseringsuppgiftslager. De varnar också för att signaturbaserad identifiering har begränsat värde här, eftersom verktygen är uppbyggda av legitima öppen källkods-verktyg – Impacket, gogo, Nuclei – som förekommer i vanliga penetrationstester.

Varför skivan är en milstolpe

Arkivet markerar detta som en milstolpe, och anledningen syns i kontrasten mellan vad aktören åstadkom och vad aktören skulle kunna göra. En enda operatör eller en mycket liten grupp, bedömd till låg till medelhög skicklighet, genomförde samtidiga intrång i dussintals länder, tog fram en verktygslåda som normalt skulle implicera ett utvecklingsteam och genererade attackplaner för varje mål tillräckligt snabbt för att hålla flera intrång igång samtidigt.

Samma rapport anger taket. Aktören kunde inte kompilera skräddarsydda exploits, kunde inte felsöka misslyckade exploateringsförsök och kunde inte improvisera när en plan stötte på ett härdat mål – så den gick vidare i stället för att fortsätta. Dess AI-genererade kod brast i kanterna. Dess operativa anteckningar är en förteckning över patchade tjänster och stängda portar. Det modellerna tog bort var arbete, inte omdöme: spaning, parsning, dokumentation och planering automatiserades; de delar som krävde anpassning förblev utom räckhåll.

Det är också därför de öppna frågorna är tråkiga och specifika. Hur många organisationer Fortinet faktiskt meddelade skulle avgöra skillnaden mellan "ett fåtal kunder" och fler än 600 enheter. En andra granskning av ARXON-katalogen, oberoende av forskaren som hittade den, skulle avgöra vad verktyget var och vilka modeller det anropade. Fram till dess stöder dokumentationen en säker slutsats om metoden och en mycket svagare om omfattningen.