AI sysadminų ir hakerių rankose: kas laimi 2026 metais.

2026 m. gegužės 13 d. saugumo tyrimų platforma depthfirst įkėlė nginx šaltinio kodą į savo AI kodo analizės sistemą. Maždaug po šešių valandų sistema pateikė ataskaitą: heap buffer overflow ngx_http_script.c faile, egzistuoja nuo versijos 0.6.27, 2008 metai.

Aštuoniolika metų ta klaida išgyveno šimtus rankinių kodo peržiūrų, dešimtis saugumo auditų, tūkstančius prisidėjusiųjų. AI ją rado per šešias valandas.

Čia ir reikia pradėti pokalbį apie AI sistemos administratoriaus gyvenime — ne nuo marketingo skaidrių apie „rutinos automatizavimą”, o nuo konkretaus fakto: įrankis, kuris anksčiau buvo prieinamas tik gerai finansuojamoms tyrimų komandoms, dabar prieinamas visiems. Įskaitant tuos, kurie atakuoja tavo serverius.

DU VIENO ĮRANKIO VEIDAI

Kai sakoma „AI keičia sysadminų pasaulį” — paprastai turima omenyje kažkas malonaus: komandų papildymas, konfigūracijų generavimas, greiti atsakymai į klausimus. Tai tiesa, bet tai tik pusė paveikslo.

AI yra įrankis. Plaktukas nežino kas jį laiko. Ir lygiai tas pats progresas, kuris leidžia tau greičiau analizuoti žurnalus ar generuoti ansible playbooks, leidžia užpuolikui greičiau rasti pažeidžiamumus tavo infrastruktūroje.

Suprasti abu pusė — tai ne paranoja, o profesionalus būtinumas.

KAIP AI DIRBA UŽPUOLIKAMS

Pradėkime nuo nepatogaus. Užpuolikai gavo daugiau iš AI nei gynėjai — ir gavo anksčiau.

Tai ne apie tai, kad fuzzing ar statinė kodo analizė atsirado vakar. Jie egzistuoja dešimtmečius. Problema buvo kitokia: norint paleisti SAST įrankį ir teisingai interpretuoti rezultatus, reikėjo žmogaus su ekspertize. Tai buvo natūrali kliūtis. AI ją pašalino.

Paimk NGINX Rift istoriją. Kai žmogus analizuoja nginx, jis žiūri į konkretų failą, konkrečią funkciją — nes viso repozitorijaus laikyti galvoje fiziškai neįmanoma. AI įkelia visą kodą ir kuria elgesio modelį: kur vėliavėlė nustatoma, kur ji skaitoma, kur turėtų būti atstatoma, bet nėra. Būtent taip buvo rastas is_args — dvi kodo vietos, kurios žmogui atrodo kaip atskiri, nepriklausomi fragmentai, o AI matosi kaip viena grandinė su pažeistu invariantu.

Toliau — greičiau. Specializuoti saugumo modeliai ne tik randa pažeidžiamumą — jie iš karto sukuria veikiantį PoC. Nuo atradimo iki veikiančio exploito NGINX Rift atveju praėjo kelios valandos. 2018 metais tai būtų užtrukę savaites ir reikalavę komandą patyrusių tyrėjų.

Tai ne hipotetinis scenarijus. 2023 metais atsirado WormGPT ir FraudGPT — LLM modeliai be apribojimų, apmokyti ant underground forumų duomenų. Jie ne tik generuoja kenkėjišką kodą — jie konsultuoja dėl taktikos, pritaiko atakas konkrečiam tikslui, aiškina kaip apeiti konkrečią apsaugą. Prieiga buvo parduodama už kelis šimtus dolerių per mėnesį. Auditorija — žmonės be techninės ekspertizės, kurie anksčiau fiziškai negalėjo vykdyti tokių atakų.

Recon pasikeitė ne mažiau radikaliai. Anksčiau prieš atakuojant reikėjo praleisti valandas žvalgyboje: surinkti subdomenus, nuskaityti prievadus, nustatyti technologijų rinkinį, rasti komponentų versijas, palyginti su CVE duomenų baze. Kiekvienas žingsnis — rankomis. Dabar tai vienas prompt — ir per minutes gauni tikėtinai pažeidžiamų endpoint’ų žemėlapį tiksliniam domenui. Nuclei su AI generuojamais šablonais, specializuoti GPT agentai ir įrankiai kaip Burp Suite su AI plėtiniais tai daro automatiškai — ir jie prieinami visiems, ne tik profesionalioms komandoms.

Ir dar vienas vektorius, kurį dažnai pamirštama: phishing. Pirmoji prieiga prie infrastruktūros gaunama ne tik per paslaugų pažeidžiamumus — dažnai per žmogų. AI sugeneruotas laiškas nebėra su sulūžusiu anglišku ir rašybos klaidomis — klasikiniais požymiais, pagal kuriuos mokė atpažinti phishing. Jis parašytas konkretaus žmogaus stiliumi, turi aktualų kontekstą, atrodo kaip tikras darbo susirašinėjimas. LinkedIn atidavė užpuolikams nemokamą duomenų rinkinį apie tai kas kur dirba ir su kuo bendrauja.

Galutinė išvada paprasta: langas tarp CVE paskelbimo ir aktyvaus išnaudojimo pradžios sutrumpėjo nuo savaičių iki dienų. NGINX Rift — gyvas pavyzdys. PoC pasirodė gegužės 13-ą, išnaudojimas prasidėjo 16-ą. Trys dienos.

KAIP AI DIRBA GYNĖJAMS

Paveikslas nėra simetriškas — tačiau gynėjams pokyčiai taip pat esminiai.

Akivaizdžiausia vieta kur AI tikrai padeda — žurnalai. Klasikinis metodas: rašai grep/awk skriptus žinomiems atakų šablonams, konfigūruoji fail2ban su konkrečiomis reguliariosiomis išraiškomis, žiūri į dashboards. Veikia. Bet pagauna tik tai, kam parašyta taisyklė. Ataka su nestandartiniu elgesiu tiesiog praeina pro šalį — nėra taisyklės, nėra alerto.

AI anomalijų detektorius veikia kitaip. Jis iš anksto nežino kaip atrodo ataka — jis žino kaip atrodo norma. Kuria baseline iš istorinių duomenų: kiek užklausų per valandą, kokie endpoint’ai, koks atsakymo laikas, iš kur ateina prisijungimai. Ir įspėja apie nukrypimą. Ne „šis IP padarė 1000 užklausų per minutę”, o „šis šablonas /api/auth neatsitinka panašiai į nieko ką matėme per pastarąsias 90 dienų”. Konkretus pavyzdys: NGINX Rift heap shaping atakos metu generuojama serija nestandartinių užklausų — jos nepateks į fail2ban pagal regex taisykles, tačiau anomalijų detektorius pastebės šabloną prieš prasidedant realiam išnaudojimui. Elastic SIEM, Splunk UEBA, Wazuh su prijungtu OpenSearch ML priedų — visa tai jau veikia production aplinkoje. Netobulai, false positive pasitaiko — tačiau kartelė pakelta principingai aukščiau.

Konfigūracijų auditas — dar viena sritis kur AI taupo realų laiką. Pateik jam savo nginx.conf ir paprašyk rasti saugumo problemas — per minutę gausi sąrašą: silpnos TLS versijos, trūkstamos saugumo antraštės, nesaugios rewrite taisyklės, nereikalingi moduliai. Žmogus žiūrintis į konfigūraciją kurią pats rašė prieš dvejus metus — mato ją autoriaus akimis. AI žiūri šviežiai, be konteksto „taip istoriškai susiklostė”. NGINX Rift atveju — AI būtų radęs pažeidžiamas rewrite taisykles su unnamed captures ir klaustuku replacement eilutėje dar audito etape, prieš bet kokį pataisymą. Tas pats su nftables ruleset, sshd_config, sudoers, pg_hba.conf.

Incident response pasikeitė juntamai. Serveris elgiasi keistai 3 val. nakties — anksčiau tai reiškė atidaryti kelis terminalus ir rankomis rinkti vaizdą per journalctl, netstat, ps, lsof. Užtrukdavo nuo pusvalandžio iki kelių valandų. Dabar: pateiki AI žurnalų išrašą ir diagnostinių komandų išvedimą — gauni struktūruotą hipotezę ir kitų žingsnių sąrašą tikrinimui. AI ne visada teisi. Bet mechaninį duomenų rinkimo ir pirminio analizavimo darbą ji nuima — ir tu naudoji galvą ten kur ji tikrai reikalinga.

Kodo generavimas nusipelno atskiro paminėjimo. Bash skriptai, Python įrankiai, ansible rolės, systemd unit failai — AI rašo pakankamai gerai daugumai tipinių užduočių. Ne tobulai, reikia peržiūros — tačiau skirtumas tarp „rašyti nuo nulio” ir „redaguoti paruoštą juodraštį” yra kelių kartų skirtumas greičio ir kito nuovargio lygio dienos pabaigoje.

KO AI NEMOKA — IR KODĖL TAI SVARBU

Sąžiningas pokalbis apie AI reikalauja ne tik pasakoti ką gali, bet ir kur lūžta. Nes būtent čia žmonės nusidegina — pasitiki ten kur nereikėtų.

Verslo kontekstas. AI nežino, kad tas prievadas atidarytas todėl, kad CTO taip nusprendė prieš trejus metus dėl priežasčių kurios jau nebeaktualios, tačiau niekas nenori keisti. Nežino, kad tas vartotojas su plačiomis teisėmis — atleistas darbuotojas, kuriam pamiršo atšaukti prieigą. Nežino, kad serverio našumas degradavo todėl, kad marketingas paleido el. pašto kampaniją be perspėjimo. Organizacijos kontekstas — tai sritis kur AI yra aklas. Auditas parodys problemą, tačiau tik žmogus žino kodėl ji egzistuoja ir ką su ja realiai galima daryti.

Naujos atakos be šablonų. AI anomalijų detektorius kuriamas ant to ką jis matė. Iš esmės naujas atakos vektorius — zero-day be viešo PoC, nestandartinis technikų derinys — gali praeiti pro šalį. Būtent todėl užpuolikai turi struktūrinį pranašumą: jiems reikia sugalvoti vieną naują techniką. Gynėjai turi būti pasiruošę visoms. AI siaurina tą atotrūkį, bet jo neuždaro.

Haliucinacijos techninėse detalėse. Tai reali problema ir jos neįvertina. AI užtikrintai nurodo vėliavėles kurių nėra, komandas kurių nėra, konfigūracijos parinktis kurios pasenusios arba niekada taip neveikė. Realus pavyzdys: paprašyk AI parašyti komandą ECDSA sertifikato tikrinimui per openssl — didelė tikimybė gauti openssl ec -noout -modulus, kurios ECDSA atveju neegzistuoja. Atrodo įtikinamai, parašyta užtikrintai — ir neveikia. Jei temos nepakankamai gerai išmanai kad galėtum patikrinti — rizika didelė.

Atsakomybė ir pasekmės. Kai AI agentas vykdo komandą kuri pargriūna production — tai tavo atsakomybė. AI nepatiria pasekmių. Neskambina 3 val. nakties. Neaiškina verslui. Tai ne argumentas prieš AI naudojimą — tai argumentas kad žmogus liktų sprendimų grandinėje ten kur klaida neatitaisoma.

KUR EINA RIBA

Yra užduočių kurias AI atlieka gerai ir verta deleguoti: pirmasis perėjimas per dokumentaciją, skripto juodraštis, žurnalų išrašo analizė, nepažįstamos klaidos paaiškinimas, konfigūracijos šablono generavimas.

Yra užduočių kur AI padeda, tačiau sprendimas lieka žmogui: konfigūracijos auditas (AI randa, žmogus nusprendžia ką su tuo daryti), incident response (AI kuria hipotezę, žmogus tikrina), architektūros planavimas (AI siūlo variantus, žmogus žino kontekstą).

Ir yra užduočių kurių visiškai negalima deleguoti: sprendimas taikyti pakeitimą production aplinkoje be testavimo, rizikos vertinimas atsižvelgiant į verslo kontekstą, atsakomybė už incidentą, sprendimo priėmimas kai duomenų nepakanka ir reikia intuicijos pagrįstos patirtimi.

Riba ne tarp „naudoti AI” ir „nenaudoti AI”. Riba tarp „AI kaip eksperto stiprintojo” ir „AI vietoj eksperto”. Antrasis variantas — tai kur viskas lūžta.

NAUJA REALYBĖ SISTEMOS ADMINISTRATORIUI

Prieš keletą metų pakako giliai išmanyti savo tech rinkinį ir sekti CVE savo komponentuose. Laiku taisyti, bazinis hardening — ir dauguma atakų praeidavo pro šalį tiesiog todėl, kad užpuolikai ėjo mažiausio pasipriešinimo keliu: ieškojo senų pažeidžiamumų pasenusiose sistemose.

Dabar ta logika lūžta. Trys dienos nuo PoC iki aktyvaus išnaudojimo — tai jau ne išimtis, tai norma. Automatizuotas recon randa tavo serverį greičiau ir jį aprašo išsamiau. Entry-level užpuolikas su AI įrankiais daro tai, kam anksčiau reikėjo komandos.

Kritinių komponentų — nginx, ssh, branduolio — taisymas nebėra laukiamas iki suplanuoto priežiūros lango kartą per mėnesį. Reikia skubaus taisymo proceso kritiniams CVE ir prenumeratos į saugumo advisories, kad apie juos sužinotum anksčiau nei kolegos pasidalins pokalbyje.

Rule-based stebėjimas yra geras, tačiau anomalijų baseline — kitas lygis. Jei Wazuh ar Elastic dar nesukonfigūruoti su ML detektoriumi — tai kitas punktas sąraše, ne „kažkada”.

Ir svarbiausia: naudoti AI savo pusėje. Ne tam kad pakeistum save įrankiu. Tam kad nenaudotum proto tam, ką AI daro greičiau ir tiksliau — ir saugotum jį ten kur reikia žmogaus.

KONKRETUS RINKINYS — KAS TIKRAI VEIKIA 2026 METAIS

Wazuh — open source SIEM, self-hosted, nemokamas. Pagal nutylėjimą veikia rule-based aptikimu — gerai pagauna žinomus atakų šablonus. Anomalijų aptikimas per OpenSearch ML priedą konfigūruojamas atskirai ir reikalauja laiko, tačiau suteikia galimybę aptikti nukrypimus nuo baseline. Taip pat: failų vientisumo kontrolė, sistemos žurnalų analizė, tinklo veikla. Vidutinis įėjimo slenkstis — savaitė kad paleistum ir tinkamai sukonfigūruotum.

Elastic Security — galingiau nei Wazuh, tačiau reikalauja išteklių ir konfigūravimo laiko. UEBA variklis pradeda gerai veikti kai sukaupta kelių savaičių istorinių duomenų. Jei jau naudoji ELK — logiškas pratęsimas.

Claude, ChatGPT, Copilot — skriptų rašymui, konfigūracijų analizei, žurnalų klaidų paaiškinimui, ansible rolių generavimui. Puikus pirmasis perėjimas. Blogas galutinis atsakymas be peržiūros — ypač viskam kas liečia production. Visada tikrink AI pateikiamas komandas prieš paleidžiant jas serveryje.

Semgrep — statinė analizė su pritaikytomis taisyklėmis. Jei rašai kodą kurį diegiesi — naudingas prieš diegimą, o ne po. Yra paruoštų taisyklių rinkinių tipiniams web aplikacijų pažeidžiamumams.

Nuclei — pažeidžiamumų skaitytuvas su nuolat atnaujinamais šablonais, daugelis kurių generuojami AI sistemų. Leisk jį savo infrastruktūroje — kad matytum ką mato užpuolikas iš išorės, o ne tik ką sukonfigūravai iš vidaus. Atotrūkis tarp šių dviejų vaizdų dažnai būna netikėtai didelis.

IŠVADA — KAS LAIMI

depthfirst rado 18 metų senumo klaidą nginx per šešias valandas. Tai ir gera, ir bloga naujiena vienu metu.

Gera: įrankiai kurie anksčiau egzistavo tik didelėse saugumo kompanijose dabar prieinami visiems. Gali atlikti savo infrastruktūros auditą tokia kokybe, kuri anksčiau kainavo dešimtis tūkstančių dolerių.

Bloga: tie patys įrankiai prieinami užpuolikams. Ir jie jau juos naudoja — aktyviai.

Taigi kas laimi? Sąžiningas atsakymas: šiuo metu — užpuolikai. Jie turi struktūrinį pranašumą: jiems reikia rasti vieną skylę. Gynėjai turi užkimšti visas. AI to santykio nepakeitė — jis jį pagreitino. Užpuolikai gavo įrankį anksčiau, greičiau jį įsisavino ir dabar dirba su juo be apribojimų kurie yra komerciniuose produktuose.

Tačiau tai nereiškia kad žaidimas pralaimėtas. Atotrūkis mažėja — ir mažėja būtent tarp tų kurie nelaukia kol AI pats viską sukonfigūruos, o naudoja jį sąmoningai: auditui, anomalijų aptikimui, greitesnei reakcijai.

Sistemos administratorius 2026 metais — tai ne tas kas mintinai žino iptables sintaksę ar rsync vėliavėles. Tai tas kas sugeba greitai įsigilinti į naujus įrankius, supranta grėsmes principų lygmeniu, o ne tik konkrečių CVE lygmeniu, ir naudoja automatizavimą — įskaitant AI — kad neatsiliktų nuo pokyčių tempo.

Plaktukas — tik įrankis. Viskas priklauso nuo to kieno rankose jis yra ir kam naudojamas.