Kai dirbtinis intelektas tampa grėsme: naujas kibernetinio saugumo etapas
Lūžio savaitė DI saugume
Daugelį metų kibernetinio saugumo industrija svarstė, ar dirbtinis intelektas labiau pasitarnaus gynėjams, ar atakuotojams. Trečioji 2026 m. vasario savaitė pateikė aiškų atsakymą: abiem pusėms vienu metu. Per vos septynias dienas trys atskiri incidentai parodė, kad DI nebėra tik įrankis geresnei gynybai kurti — jis tapo atakų paviršiumi, ginklu ir nesąmoningu bendrininku vienu metu. Nuo pirmosios „Android" kenkėjiškos programos, naudojančios generatyvųjį DI veikimo metu, iki „Microsoft Copilot" klaidos, kuri savaitėmis skaitė konfidencialius el. laiškus, ir kritinio pažeidžiamumo SDK, kurį kūrėjai naudoja DI programoms kurti — žinutė aiški. DI grėsmių era prasidėjo, o organizacijos, vertinančios DI diegimą tik kaip galimybę, yra pavojingai nepasiruošusios.
PromptSpy: kenkėjiška programa, kuri mąsto pati
Vasario 19 d. ESET tyrėjai paskelbė savo išvadas apie PromptSpy — pirmąją žinomą „Android" kenkėjišką programą, naudojančią generatyvųjį DI veikimo metu. Skirtingai nuo tradicinių mobiliųjų grėsmių, kurios remiasi iš anksto užkoduotomis procedūromis, PromptSpy integruojasi su „Google" Gemini API ir dinamiškai naršo įrenginio sąsajoje. Kai reikia užsitikrinti išlikimą įrenginyje, programa padaro ekrano nuotrauką, siunčia ją Gemini ir gauna žingsnis po žingsnio instrukcijas, kaip prisegti save prie naujausių programų sąrašo. Tada vykdo tuos žingsnius per „Android" prieinamumo paslaugą, tikrina rezultatą ir kartoja ciklą, kol pavyksta. Tai reiškia, kad kenkėjiška programa automatiškai prisitaiko prie bet kurios „Android" versijos, gamintojo ar pritaikytos sąsajos — gebėjimas, kuriam anksčiau reikėjo mėnesių rankinio atvirkštinės inžinerijos kiekvienam įrenginiui.
Pagrindinis PromptSpy kenkėjiškas krovinys yra integruotas VNC modulis, suteikiantis nuotoliniams operatoriams visišką prieigą prie užkrėsto įrenginio. Jis gali fiksuoti užrakinimo ekrano duomenis, blokuoti pašalinimo bandymus, daryti ekrano nuotraukas, įrašyti ekrano veiklos vaizdo įrašus ir išfiltruoti įrenginio duomenis. Nors ESET pažymi, kad PromptSpy dar nepasirodė plačiojoje telemetrijoje — o tai rodo, kad jis gali būti proof of concept stadijoje — platinimo domeno, skirto Argentinos naudotojams, atradimas rodo, kad grėsmė juda už laboratorijos ribų. Tai ne pirmas kartas, kai ESET susiduria su DI paremta kenkėjiška programa: 2025 m. rugpjūtį buvo aptiktas PromptLock — DI valdomas išpirkos reikalaujantis virusas. Tendencija spartėja.
Microsoft Copilot: kai DI asistentas skaito tai, ko neturėtų
Vasario 18 d. „Microsoft" patvirtino, kad „Microsoft 365 Copilot" klaida tyliai skaitė ir apibendrino konfidencialiais pažymėtus el. laiškus — apeidama Data Loss Prevention (DLP) politikas, kurios buvo aiškiai sukonfigūruotos blokuoti tokią prieigą. Klaida, sekama kaip CW1226324, pirmą kartą aptikta sausio 21 d. ir paveikė Copilot „darbo skirtuko" pokalbių funkciją. Dėl šios klaidos Copilot neteisingai apdorojo pranešimus iš Išsiųstų ir Juodraščių aplankų, įskaitant el. laiškus su konfidencialumo žymomis, specialiai sukurtomis automatizuotų įrankių prieigai apriboti. Savaitėmis DI įrankis, kuriam buvo patikėtas įmonės produktyvumas, darė būtent tai, ką DLP politikos turėjo užkirsti.
„Microsoft" neatskleisdė, kiek organizacijų buvo paveikta, ir tik nurodė, kad pradėjo diegti pataisą „anksčiau vasarį", tęsdama paveiktų vartotojų stebėjimą. Šis incidentas kerta į esminės problemos širdį: kai integruojate didelį kalbos modelį į įmonės darbo eigą ir suteikiate jam platų prieigą prie duomenų, jūs faktiškai sukuriate vidinį asmenį su beveik neribotomis skaitymo teisėmis. Tradicinės DLP politikos buvo sukurtos žmonėms ir deterministinei programinei įrangai — ne tikimybinėms DI sistemoms, kurios kiekvieną kartą skirtingai interpretuoja instrukcijas. Šis incidentas turėtų būti pabudimo signalas bet kuriai organizacijai, diegiančiai DI asistentus su prieiga prie jautrių įmonės duomenų.
Semantic Kernel RCE: spraga DI kūrimo infrastruktūroje
Trejetą užbaigė kritinis nuotolinio kodo vykdymo pažeidžiamumas (CVE-2026-26030), atskleistas „Microsoft" Semantic Kernel Python SDK — karkase, kurį daugelis kūrėjų naudoja integruoti didelius kalbos modelius į savo programas. Įvertintas CVSS 9,9 iš 10, šis trūkumas gali leisti atakuotojams vykdyti savavališką kodą serveriuose, kuriuose veikia Semantic Kernel pagrindu sukurtos DI programos. Pažeidžiamumas ypač nerimą kelia, nes Semantic Kernel yra daugelio įmonių DI diegimų pagrindinis sluoksnis. Tai jungiamasis kodas tarp verslo logikos ir kalbos modelių — tai reiškia, kad pažeidimas čia gali kaskadu paplisti per visą DI infrastruktūrą. Kai įrankiai, kuriais kūrėjai kuria DI, patys yra pažeidžiami, kiekvienos ant jų pastatytos programos saugumas tampa klaustuku.
Bendras vardiklis: DI plečia atakų paviršių
Kiekvienas iš šių incidentų atskirai pasakoja specifinę techninę istoriją. Žvelgiant kartu, jie atskleidžia sisteminį modelį: kiekvienas DI infrastruktūros sluoksnis dabar yra potencialus atakų vektorius. Taikomųjų programų sluoksnyje DI asistentams suteikiama prieiga prie duomenų, viršijanti jų saugumo ribas. Infrastruktūros sluoksnyje SDK ir karkasai, palaikantys DI programas, turi savo pažeidžiamumų. O grėsmių veikėjų sluoksnyje priešininkai paverčia ginklu tas pačias generatyvinio DI galimybes, kurias įmonės skuba diegti. Tai ne sutapimas — tai neišvengiamas galingų tikimybinių sistemų diegimo aplinkose, sukurtose deterministinei, nuspėjamai programinei įrangai, rezultatas.
Pagrindinės rizikos, su kuriomis organizacijos dabar susiduria:
- DI paremta kenkėjiška programa, prisitaikanti realiuoju laiku, panaikina įrenginių fragmentacijos privalumą kaip natūralų gynybos barjerą — atakuotojams nebereikia kurti atskirų exploit'ų kiekvienam įrenginio variantui.
- Įmonių DI įrankiai su plačia prieiga prie duomenų tampa de facto vidiniais asmenimis — gebančiais skaityti, apibendrinti ir potencialiai išfiltruoti jautrią informaciją tokiu mastu, kurio nė vienas žmogus nepajėgtų pasiekti.
- Tiekimo grandinės rizika dabar apima DI karkasus ir SDK — vienas pažeidžiamumas plačiai naudojamame DI kūrimo įrankių rinkinyje gali vienu metu sukompromituoti tūkstančius priklausomų programų.
- Tradicinės saugumo priemonės — ugniasienės, DLP politikos, prieigos kontrolės sąrašai — buvo sukurtos nuspėjamai, taisyklių besilaikančiai programinei įrangai ir iš esmės yra nepakankamos tikimybinėms DI sistemoms valdyti.
Gynybos strategijos DI erai
Šie incidentai nereiškia, kad organizacijos turėtų atsisakyti DI diegimo — atsilikimo konkurencinė kaina per didelė. Tačiau jie reikalauja esminio pokyčio, kaip įmonės vertina DI saugumą. Laikai, kai DI įrankiai buvo traktuojami kaip eilinė verslo programinė įranga, baigėsi. DI sistemoms reikia specialiai sukurtų saugumo karkasų, atsižvelgiančių į jų unikalias savybes: tikimybinį elgesį, plataus duomenų prieigos poreikius ir gebėjimą vienu metu būti ir įrankiu, ir taikiniu.
Praktiniai žingsniai, kuriuos organizacijos turėtų žengti dabar:
- Įdiekite DI-specifines prieigos kontroles. Suteikite DI įrankiams minimalią duomenų prieigą, reikalingą jų funkcijai. Traktuokite kiekvieną DI asistentą kaip nepatikimą vidinį asmenį ir taikykite nulinio pasitikėjimo principus jų prieigai — įskaitant išvesties stebėjimą ir elgsenos analizę.
- Atlikite DI tiekimo grandinės auditą. Kataloguokite kiekvieną DI karkasą, SDK ir modelių teikėją savo infrastruktūroje. Prenumeruokite kiekvieno saugumo pranešimus. Sukurkite greitą pataisymų procesą, skirtą DI infrastruktūros komponentams, su tokiais pat griežtais SLA kaip ir operacinių sistemų pataisymams.
- Įdiekite DI-sąmoningą stebėjimą. Tradicinius SIEM ir EDR įrankius reikia papildyti DI-specifinėmis aptikimo galimybėmis. Stebėkite anomalius API kvietimus į DI paslaugas, neįprastus DI įrankių duomenų prieigos modelius ir netikėtą modelių elgesį, kuris gali rodyti kompromitavimą ar piktnaudžiavimą.
- Sukurkite DI incidentų reagavimo procedūras. Jūsų esamos reagavimo į incidentus procedūros greičiausiai neapima scenarijų, tokių kaip „mūsų DI asistentas nutekino konfidencialius duomenis" ar „atakuotojas naudoja generatyvųjį DI naršyti mūsų mobiliuosiuose įrenginiuose." Sukurkite specifinius DI incidentų reagavimo planus, įskaitant izoliavimo strategijas, atsižvelgiančias į realiu laiku prisitaikančią DI grėsmių prigimtį.
Kelias į priekį
2026 m. vasaris greičiausiai bus prisimintas kaip savaitė, kai kibernetinio saugumo industrija nebegalėjo ignoruoti dvigubos DI prigimties. Technologija, žadanti revoliucionuoti verslo produktyvumą, tuo pat metu kuria atakų vektorius, kuriems mūsų esama saugumo infrastruktūra niekada nebuvo projektuota. Organizacijos, kurios pripažįsta šį dvilypumą ir investuoja į DI-sąmoningą saugumo laikyseną šiandien, bus gerokai geriau pasirengusios nei tos, kurios reaguos į kitą neišvengiamą incidentą. Klausimas nebėra, ar DI bus paverstas ginklu — jis jau paverstas. Klausimas yra, ar jūsų gynyba vystosi taip pat greitai kaip grėsmės.
Norite aptarti šias temas nuodugniau?
Mūsų komanda pasiruošusi architektūros peržiūroms ir strateginėms sesijoms.
Suplanuoti konsultaciją →