Angriparen som behövde 31 sekunder: vad den första autonoma ransomware-attacken betyder för återställning

När angriparen slutade behöva en människa

Den 1 juli 2026 publicerade Sysdig Threat Research Team sin analys av en ransomware-operation som teamet döpte till JADEPUFFER. Med Sysdigs egna ord är det "what we assess to be the first documented case of agentic ransomware: a complete extortion operation driven end-to-end by a large language model (LLM)." (På svenska: det som Sysdig bedömer vara det första dokumenterade fallet av agentbaserad ransomware, en komplett utpressningsoperation som drevs från början till slut av en stor språkmodell.)

Det här är inte ännu en historia om AI-skrivna nätfiskemejl eller deepfake-samtal. I de payloads som Sysdig fångade utnyttjade agenten en applikation som var exponerad mot internet, samlade in inloggningsuppgifter, tog sig vidare till en andra server, tog över dess konfigurationstjänst, krypterade och raderade data och lämnade ett lösenkrav. När ett steg misslyckades diagnostiserade agenten felet och försökte igen utan att vänta på instruktioner.

På BackupSec anser vi att JADEPUFFER är mindre viktig som en enskild incident än som en förhandsvisning. Den är en tidig datapunkt för en fråga som varje backup- och återställningsarkitektur förr eller senare måste besvara: vad händer när beslutsloopen på andra sidan krymper från timmar till sekunder?

Inuti JADEPUFFER:s attackkedja

I stora drag är det här en kill chain som säkerhetsteam har försvarat sig mot i åratal. Sysdig säger det själv: "None of the individual techniques were novel or sophisticated." (Ingen av de enskilda teknikerna var ny eller avancerad.) Det nya var vad som utförde dem. Förloppet nedan följer Sysdigs genomgång:

1. Initial åtkomst. Agenten utnyttjade CVE-2025-3248 i Langflow, ett ramverk med öppen källkod för att bygga LLM-applikationer. NVD beskriver sårbarheten som kodinjektion i endpointen /api/v1/validate/code som låter "a remote and unauthenticated attacker" (en fjärransluten, oautentiserad angripare) köra godtycklig kod, och ger den CVSS 9,8. Rättningen kom i Langflow 1.3.0 den 31 mars 2025, och CISA lade till sårbarheten i sin Known Exploited Vulnerabilities-katalog den 5 maj 2025. Patchen fanns; den hade inte installerats.
2. Insamling av inloggningsuppgifter. På Langflow-värden kartlade agenten systemet och sökte igenom miljön efter API-nycklar till LLM-leverantörer, molnuppgifter, kryptoplånböcker och databasuppgifter, och dumpade sedan Langflows egen Postgres-databas. Den hittade en MinIO-objektlagring som gick att nå från värden, loggade in med MinIO:s standarduppgifter (minioadmin:minioadmin) och listade buckets som enligt Sysdig innehöll "application data, backups, ML artifacts, and a terraform-state bucket" (applikationsdata, backuper, ML-artefakter och en bucket med terraform-state). Från en av dem hämtade den en credentials.json-fil med ett par av access key och secret.
3. Persistens. Den lade in en crontab-post på Langflow-värden som anropar angriparens infrastruktur var 30:e minut.
4. Vidare till det verkliga målet. Enligt Sysdig var operationens egentliga mål en separat produktionsserver, exponerad mot internet, som körde MySQL och en Alibaba Nacos-konfigurationstjänst. Agenten anslöt till den exponerade MySQL-porten som root. Sysdig observerade inte varifrån dessa root-uppgifter kom: "Their origin is unknown." (Deras ursprung är okänt.)
5. Övertagande av Nacos. Agenten angrep Nacos via flera vägar samtidigt: familjen av autentiseringsförbigångar kring CVE-2021-29441 (enligt NVD kan autentiseringsfiltret i Nacos före 1.4.1 kringgås med en förfalskad user-agent-header), en JSON Web Token förfalskad med Nacos publikt dokumenterade standardnyckel för signering, och ett bakdörrskonto med administratörsbehörighet som skrevs direkt in i Nacos-databasen med hjälp av root-åtkomsten. JWT-vägen misslyckades ("custom secret in use", det vill säga en egen hemlighet användes) och övergavs. Bakdörrskontot fungerade, efter den 31-sekunderskorrigering som beskrivs nedan.
6. Påverkan. Agenten krypterade samtliga 1 342 konfigurationsposter i Nacos med MySQL:s AES_ENCRYPT(), raderade de ursprungliga konfigurations- och historiktabellerna och fortsatte sedan med att radera hela databasscheman. Lösensedeln påstår AES-256; Sysdig påpekar att AES_ENCRYPT() som standard använder AES-128-ECB om inte servern har konfigurerats om. Detaljen som betyder mer för återställningen: nyckeln skrevs ut en gång och varken sparades eller skickades någonstans, så med Sysdigs ord: "The victim cannot recover the encrypted configurations even with payment." (Offret kan inte återställa de krypterade konfigurationerna ens mot betalning.) Bara en kopia som togs före attacken, och som hölls utom räckhåll för angriparen, kunde få tillbaka den datan.
7. Utpressning. Den skapade en README_RANSOM-tabell med kravet, en Bitcoin-adress och en kontaktadress hos Proton Mail.

Den ärliga reservationen

Vi vill vara exakta med vad "autonom" betyder här, eftersom en överdrift skulle undergräva det argument vi snart ska föra.

Sysdig pekar ut två saker som företaget inte kan se. Det observerade inte hur agenten fick tag på de MySQL-root-uppgifter som användes i steg fyra. Och det har "no visibility into JADEPUFFER's system prompt or agent configuration" (ingen insyn i JADEPUFFER:s systemprompt eller agentkonfiguration), så det kan inte säga vilket mål eller vilka resurser en människa gav agenten innan den kördes. Någon byggde, konfigurerade och startade den.

Det Sysdig däremot dokumenterar är beteendet inuti de sessioner som fångades: mer än 600 olika payloads, kod som berättar om sitt eget resonemang, och fel som diagnostiserades och rättades på sekunder. Utifrån det underlaget drar Sysdig slutsatsen att "the evidence points to an autonomous agent driving the operation rather than a human operator or a fixed toolkit." (Underlaget pekar på att en autonom agent drev operationen, snarare än en mänsklig operatör eller en fast verktygslåda.)

Den distinktionen spelar roll, och vi tycker att den stärker argumentet snarare än försvagar det. Även en kedja där en människa sätter målet och agenten sköter utförandet tar bort den största källan till fördröjning i en traditionell ransomware-operation: den tid en mänsklig operatör lägger på att tänka, stämma av med en uppdragsgivare och bestämma vad som ska prövas härnäst.

Varför 31 sekunder betyder mer än det låter

De 31 sekunderna är inte attackens totala längd. Sysdig publicerar ingen total tid för hela kedjan, och vi tänker medvetet inte hitta på någon. Det som publiceras är ett tidsstämplat förlopp från övertagandet av Nacos. Agenten lade in sitt bakdörrskonto med administratörsbehörighet, försökte logga in klockan 19:34:36 UTC och misslyckades. Den testade två möjliga orsaker parallellt och skickade sedan klockan 19:35:07 en korrigerande payload på 15 rader som byggde upp kontot korrekt. Inloggningen lyckades klockan 19:35:18. Med Sysdigs ord: "The window between the failed login and the correct multi-step fix is 31 seconds." (Tidsfönstret mellan den misslyckade inloggningen och den korrekta rättningen i flera steg är 31 sekunder.) Sysdig rapporterar samma mönster på andra ställen i sessionen. När en förfrågan returnerade XML i stället för JSON tolkade nästa payload XML. När en DROP DATABASE misslyckades på grund av en foreign key-begränsning slog nästa payload först av kontrollen.

Jämför det med hur en mänsklig operatör agerar när ett steg misslyckas. Hen pausar. Hen omvärderar. I en strukturerad ransomware-as-a-service-operation kanske hen skickar ett meddelande till en uppdragsgivare och väntar på besked. Hen försöker igen inom en tidsram som mäts i minuter eller timmar, ibland över ett skiftbyte. Den fördröjningen, glappet mellan ett misslyckande och nästa försök, har alltid varit en av de få saker som talat till försvararnas fördel. Det är därför ett larm klockan 2 på natten fortfarande kan hanteras av en människa klockan 8 på morgonen utan att incidenten nödvändigtvis har blivit dramatiskt värre under tiden.

En agent som krymper det glappet till 31 sekunder rör sig inte bara snabbare. Den tar bort ett antagande som finns inbyggt i nästan varje runbook för incidenthantering: att det finns ett fönster i mänsklig skala mellan en angripares första misslyckade försök och nästa, och att en detektions- och responsprocess som arbetar i en liknande mänsklig takt rimligen kan förvänta sig att hinna ingripa inom det.

Siffrorna som stämde redan innan AI dök upp

Backupinfrastrukturen blev inte ett mål på grund av agentbaserad AI. Den var redan ett mål, och data om det är två år äldre än JADEPUFFER.

• Veeams 2024 Ransomware Trends Report, en enkät med 1 200 respondenter från organisationer som drabbats av minst en ransomware-attack under 2023, fann att "backup repositories are targeted in 96% of attacks, with bad actors successfully affecting the backup repositories in 76% of cases." (Backup-repositories angrips i 96 % av attackerna, och angriparna lyckas påverka dem i 76 % av fallen.) Veeam upprepar siffran 96 % på sin egen blogg.
• Sophos undersökning från 2024 om komprometterade backuper, baserad på 2 974 IT- och cybersäkerhetsexperter vars organisationer drabbats av ransomware det föregående året, fann att "The median overall ransomware recovery costs for organizations whose backups were compromised ($3M) came in eight times higher than that of organizations whose backups were not impacted ($375K)." (Den totala medianen för återställningskostnaden var åtta gånger högre, 3 miljoner USD mot 375 000 USD, för organisationer vars backuper hade komprometterats jämfört med organisationer vars backuper inte påverkats.)

Siffrorna beskriver en värld av mänskliga angripare som redan förstod att det enskilt mest effektiva draget, när en ransomware-operation väl har fått fotfäste, är att förstöra eller kryptera backuplagret. Ingenting med agentbaserad AI ändrar den kalkylen. Det som ändras är vem, eller vad, som kan genomföra det i stor skala, dygnet runt, utan att behöva sova, ta en paus mellan skift eller vänta på en uppdragsgivares godkännande innan nästa inloggningsuppgift prövas.

IBM:s 2026 X-Force Threat Intelligence Index lägger till trendlinjen. IBM X-Force observerade en ökning med 44 % av attacker som började med att en publikt exponerad applikation utnyttjades, vilket är exakt den ingångsväg JADEPUFFER använde, och antalet aktiva ransomware- och utpressningsgrupper ökade med 49 % jämfört med året innan. Attackytan växte redan innan något av detta behövde en autonom operatör.

Från detektionsfönster till säker återställning

Att utnyttja en känd sårbarhet är redan det vanligaste sättet att ta sig in. Samma IBM-rapport säger att utnyttjande av sårbarheter "became the leading cause of attacks, accounting for 40% of incidents observed by X-Force in 2025." (blev den främsta orsaken till attacker och stod för 40 % av de incidenter X-Force observerade under 2025.) Glappet mellan kända och åtgärdade sårbarheter är för stort, och fylls på för kontinuerligt, för att perfekt prevention ska vara realistisk. JADEPUFFER passar in i mönstret: Sysdig noterar att attacken mot det verkliga målet "leaned on years-old issues, a 2021 Nacos auth-bypass and an unchanged default signing key." (byggde på flera år gamla problem, en autentiseringsförbigång i Nacos från 2021 och en standardnyckel för signering som aldrig byttes.) JADEPUFFER ändrar inte det argumentet. Den skärper det.

Om branschens arbetsantagande har varit att en detektions- och responsprocess i mänsklig takt rimligen kan förvänta sig att fånga ett intrång någonstans mellan initial åtkomst och oåterkallelig påverkan, så är en agent som rättar sig själv på 31 sekunder en direkt utmaning mot det antagandet. Svaret kan inte vara "upptäck och agera snabbare än en maskin", eftersom det inte är ett race som försvarare kan räkna med att fortsätta vinna i all oändlighet. Svaret måste vara arkitektoniskt: gör utfallet av ett snabbt, adaptivt intrång överlevbart, oavsett hur mycket snabbare angriparen blir.

Konkret ändras inte de egenskaper som spelar roll för backup- och återställningsinfrastruktur bara för att angriparen är en AI-agent i stället för en människa. De går från att vara önskvärda till att vara icke förhandlingsbara:

• Separation av inloggningsuppgifter och identiteter som inte hänger på att en människa hinner lägga märke till ovanlig aktivitet. Om de inloggningsuppgifter som når din backupmiljö är samma som en agent kan skörda från en komprometterad värd på några sekunder, måste isoleringen vara strukturell, inte procedurmässig.
• Immutability som är validerad, inte bara konfigurerad. Ett retention-lås som en tillräckligt privilegierad inloggningsuppgift i det tysta kan stänga av är en kontroll som förutsätter att en mänsklig angripare tvekar. En agent gör inte det.
• Återställningstester som utgår från att angriparen redan känner din miljö. JADEPUFFER:s agent anpassade sig till misslyckade steg i realtid. En återställningsplan som bara har testats mot ett enda, förväntat felscenario är en plan byggd för en långsammare och mer förutsägbar motståndare än den som nu bevisligen är möjlig.

Vad det här betyder för riskansvariga i större organisationer

JADEPUFFER är en dokumenterad kampanj, inte ett bevis för att varje ransomware-operation nu är autonom. Men om Sysdigs bedömning håller har något som tidigare var teoretiskt nu observerats: en LLM-agent som kör en verklig attackkedja mot ett verkligt mål, med en självkorrigerande loop som mäts i sekunder.

För riskansvariga är den praktiska frågan inte längre om agentbaserad ransomware kommer att bli vanligare. Sysdig säger att försvarare "should expect the volume and breadth of such campaigns to rise as agentic tooling matures," (bör räkna med att sådana kampanjer ökar i antal och bredd i takt med att agentverktygen mognar) och IBM X-Force "expects adversaries to automate complex tasks like reconnaissance and advanced ransomware attacks." (räknar med att angripare automatiserar komplexa uppgifter som rekognosering och avancerade ransomware-attacker.) Den praktiska frågan är om antagandena i din återställningsarkitektur byggdes för en motståndare i mänsklig takt, eller för en som inte längre behöver vara det.

Här kommer BackupSec in

På BackupSec har vi byggt vårt arbetssätt kring en premiss som JADEPUFFER gör mer akut: prevention kommer att fallera, och det lager som avgör utfallet är det som är byggt för att överleva fallerandet, hur snabbt det som orsakade det än rörde sig.

• ZeroMON övervakar Veeam Backup & Replication. Den driftsätts on-premises som en OVA, ansluter med ett konto med enbart läsbehörighet och skickar ingenting till BackupSec eller någon tredje part. Den följer hälsan hos backupjobb, loggar konfigurationsändringar i Veeam (vem som ändrade vad och när), visar immutability-status så som Veeams egna repository-inställningar rapporterar den och håller Veeams Security Analyzer-checklista synlig. Dess larmregler täcker de drag på Veeam-sidan som en inkräktare gör mot backuper, till exempel ändrade inloggningsuppgifter, ändringar av retention och schema, inaktiverade jobb och raderingssessioner. Larm skickas via e-post och som notiser i appen. ZeroMON bevakar Veeam: den ser inte insamling av inloggningsuppgifter på andra värdar, och den läser Veeams immutability-inställningar i stället för att kontrollera låsen i själva lagringen.
• ZeroTAM ger ditt team en dedikerad rådgivare inom backupsäkerhet: arkitekturgranskning, planering av återställning efter ransomware, kapacitet och prioriterad support i en kris. Det är där du kan stresstesta om din identitetsseparation, immutability och isolering har utformats för en angripare i mänsklig takt.
• ZeroPEN är ett hotdrivet penetrationstest av Veeam Backup & Replication, Veeam ONE och Enterprise Manager. Det simulerar en ransomware-kill chain i åtta steg mappade mot MITRE ATT&CK, från initial åtkomst och missbruk av inloggningsuppgifter via åtkomst till repositories och neutralisering av backuper till ett bevis på förmåga att kryptera. Uppdraget omfattar verifiering av återställningsintegritet och immutability och levererar revisionsfärdiga bevis med ett omtest för kritiska fynd. Det är icke-destruktivt: ZeroPEN "never deletes real backups, performs real encryption, or stops production or backup services." (raderar aldrig riktiga backuper, utför aldrig riktig kryptering och stoppar aldrig produktions- eller backuptjänster.)

Frågan JADEPUFFER väcker är inte om ditt försvar är snabbt. Den är om din återställningsarkitektur har byggts så att den inte är beroende av att försvaret är snabbt.

Prata med BackupSec om att validera din återställningsarkitektur →

Den här analysen bygger på Sysdigs forskning om JADEPUFFER från juli 2026, IBM:s 2026 X-Force Threat Intelligence Index, Veeams 2024 Ransomware Trends Report och Sophos undersökning från 2024 om komprometterade backuper, med sårbarhetsdetaljer från NVD och CISA. Tolkningen och ramverket som presenteras här är BackupSecs egna. Vill du diskutera hur analysen gäller just din miljö, kontakta vårt team →