OptinMonster tiekimo grandinės ataka: kaip vienas pavogtas raktas atvėrė duris į 1,2 mln. WordPress svetainių

Įsivaizduokite: jūsų WordPress visiškai atnaujintas, visi įskiepiai aktualūs, savame kode jokių pažeidžiamumų. Administratorius prisijungia prie valdymo skydelio — eilinė darbo diena. Po kelių valandų svetainėje atsiranda paslėpta paskyra su administratoriaus teisėmis ir užpakalinių durų įskiepis su web shell’u. Niekas neįsilaužė į jūsų serverį. Problema atėjo iš patikimo įrankio, už kurį mokate pinigus.

2026 m. birželio 12 d. užpuolikai surengė tiekimo grandinės ataką prieš tris populiarius „Awesome Motive” kompanijos WordPress įskiepius: OptinMonster (daugiau nei 1,2 mln. aktyvių diegimų), TrustPulse ir PushEngage. Ataka neišnaudojo pažeidžiamumų pačiuose įskiepiuose — ji smogė aukščiau grandinėje, CDN infrastruktūrai, per kurią įskiepiai tiekia savo JavaScript klientams. Ataką pirmieji pastebėjo Sansec tyrėjai, specializuojantys e-komercijos saugumo srityje. Vėliau išsamią techninę analizę paskelbė Patchstack.

Čia nėra CVE numerio ar CVSS balo. Tai ataka prieš pasitikėjimą: užpuolikai išnaudojo tai, kad svetainės pasitiki JavaScript, kurį joms tiekia įskiepių pardavėjas. Ir tas pasitikėjimas buvo panaudotas prieš jas.

KAIP TAI TAPO ĮMANOMA

Užpuolikai nelaužė OptinMonster. Jie neieškojo pažeidžiamumų įskiepių kode, nebandė per jėgą įveikti API, nesikasė per WordPress branduolį. Jie tiesiog įėjo per pačios kompanijos rinkodaros svetainę — įprastą WordPress diegimą su UpdraftPlus, kuriame buvo žinomas, neužlopintas pažeidžiamumas. Pralaužti įskiepių gamintojo rinkodaros svetainę daug paprasčiau nei pralaužti patį įskiepį. O laukiantis atlygis pasirodė neproporcingai didelis.

Toje rinkodaros svetainėje gulėjo CDN paskyros API raktas — to paties CDN, per kurį Awesome Motive tiekia JavaScript failus visiems klientams, visoms 1,2 mln. svetainių su OptinMonster. Raktas buvo vienas. Prieigos lygis — visiškas. Užpuolikas nereikėjo kompromituoti kiekvienos svetainės atskirai: jis pakeitė vieną failą vienoje vietoje, ir CDN pats išplatino užkrėstą skriptą visiems klientams. Tai ir yra tiekimo grandinės ataka gryniausiame pavidale — vietoj milijono spynų buvo pralaužta viena dirbtuvė, kurioje jos gaminamos.

Užpuolikai pakeitė teisėtus JavaScript SDK kenksmingomis versijomis šiuose CDN domenuose:

a.omappapi.com/app/js/api.min.js     (OptinMonster)
a.opmnstr.com/app/js/api.min.js      (OptinMonster)
a.optnmstr.com/app/js/api.min.js     (OptinMonster)
a.trstplse.com/app/js/api.min.js     (TrustPulse)
clientcdn.pushengage.com/sdks/pushengage-web-sdk.js  (PushEngage)

Kenksmingasis kodas nepakeitė originalaus — jis buvo pridėtas prie teisėto minifikuoto SDK pabaigos. Įskiepis toliau veikė įprastai, o kenksmingoji logika veikė lygiagrečiai. Būtent dėl to standartinė stebėsena iš karto nesukėlė pavojaus signalo.

KAIP VEIKĖ KENKSMINGASIS KODAS

Skriptas buvo parašytas chirurginiu tikslumu — aktyvavosi tik esant tinkamoms sąlygoms ir išvengė aptikimo keliais lygmenimis.

Pirmiausia patikrino vykdymo aplinką: ieškojo navigator.webdriver, headless naršyklių žymeklių (window._phantom, window.__nightmare) ir nulinio dydžio naršyklės langų. Tai apsauga nuo automatinių skanerių ir saugumo tyrėjų. Tada įsitikino, kad veikia būtent WordPress administratoriaus kontekste: tikrino admin juostos buvimą, /wp-admin/ kelius ir wordpress_logged_in_ slapuką. Jei administratoriaus nerasta — paprasčiausiai sustodavo. Sėkmingai suveikus, pažymėdavo localStorage, kad toje pačioje naršyklėje per 24 valandas nepasikartotų.

Radęs administratorių, skriptas rinko viską, ko reikia veikti jo vardu: nustatė WordPress šaknį ir admin kelią, ištraukė galiojantį REST nonce iš wpApiSettings, per admin-ajax.php?action=rest-nonce arba iš vartotojo pridėjimo puslapio. Turėdamas administratoriaus sesiją ir galiojantį nonce, visi tolesni užklausai tinklo lygmeniu atrodė kaip teisėti paties administratoriaus veiksmai.

Kenksminga administratoriaus paskyra buvo kuriama per keturis lygiagrečius metodus — skriptas bandė juos po vieną iki pirmojo sėkmingo:

// 1 metodas: REST API
POST /wp-json/wp/v2/users
{"username": "dev_3m6nyp", "email": "[email protected]", "roles": ["administrator"]}

// 2 metodas: WordPress forma
POST /wp-admin/user-new.php?action=createuser

// 3 metodas: AJAX
POST /wp-admin/admin-ajax.php (tas pats payload)

// 4 metodas: paslėptas 1x1px iframe, įkeliantis user-new.php

Skriptas kūrė tiek fiksuotą paskyrą developer_api1 su adresu [email protected], tiek atsitiktines paskyras pagal šabloną dev_xxxxxx / [email protected]. Jame net buvo įdiegtas daugiakalbis žodynas su pranešimais „vartotojas jau egzistuoja” — kad lokalizuotose WordPress instaliacijose galėtų teisingai nustatyti sėkmę.

Gavęs administratoriaus prieigą, skriptas atsisiuntė užpakalinių durų ZIP archyvą iš C2 serverio ir įdiegė jį per POST /wp-admin/update.php?action=upload-plugin. Užpakalinių durų įskiepis keitė pavadinimą: skirtinguose stebėjimuose jis maskavosi kaip „Content Delivery Helper” (content-delivery-helper, versija 2.7.1) arba „Database Optimizer” (database-optimizer, versija 2.9.4). Be to, slėpė save įskiepių sąraše, atnaujinimų eilėje ir WordPress veiklos žurnaluose — per valdymo skydelį jo aptikti praktiškai nebuvo įmanoma.

Įdiegtos užpakalinės durys atvėrė du nuotolinio kodo vykdymo kanalus. Per parametrą ?developer_api1_fm veikė web shell, vykdantis system($_POST['cmd']). Per parametrą developer_api1_eval buvo vykdomas bet koks base64-dekoduotas PHP kodas. Surinkti duomenys buvo XOR-šifruojami raktu jX9kM2nP4qR6sT8v, koduojami į base64 ir siunčiami į domeną tidio.cc (sąmoninga teisėto tidio.com imitacija) per atsparią grandinę: navigator.sendBeacon → fetch → XMLHttpRequest → pikselinis paveikslėlis.

REALI ATAKOS GRANDINĖ

Mastą patvirtino Patchstack statistika. Per 36 valandas — birželio 14–15 d. — jų WAF taisyklė užblokavo 271 kenksmingo administratoriaus kūrimo bandymą 13 svetainių iš 81 unikalaus IP adreso. Pasiskirstymas pagal vektorius: 263 užklausos per REST API /wp-json/wp/v2/users, 5 per formą /wp-admin/user-new.php, 3 per /wp-admin/admin-ajax.php.

Srauto pobūdis ypač iškalbingas: 81 skirtingas IP adresas, maždaug 60 % mobiliosios naršyklės (Android/Samsung), likusios — Windows, macOS ir Linux. Tai ne centralizuota ataka iš užpuoliko serverių. Tai realių WordPress administratorių naršyklės, kurios tapo nevalingais atakos įrankiais. Todėl WAF’ams ir buvo taip sunku atskirti kenksmingas užklausas nuo teisėtų: jos nešė galiojančią sesiją ir galiojantį nonce.

Domenas tidio.cc buvo užregistruotas dar 2026 m. balandžio 28 d. — pusantro mėnesio prieš ataką. Tuo pat metu gautas TLS sertifikatas. Ataka buvo planuota iš anksto.

CHRONOLOGIJA

2026 m. balandžio 28 d.: C2 domeno tidio.cc registracija ir TLS sertifikato gavimas — infrastruktūros paruošimas.

2026 m. birželio 12 d., 22:17 UTC: kenksmingasis kodas pirmą kartą pastebėtas OptinMonster ir TrustPulse api.min.js failuose.

2026 m. birželio 12 d., 22:42 UTC: paskutinis patvirtintas kenksmingojo kodo buvimas OptinMonster ir TrustPulse CDN. Poveikio langas pagrindiniame CDN — apie 25 minutės, tačiau dėl CDN kraštinių mazgų talpyklos dalis mazgų kenksmingą skriptą tiekė ilgiau.

2026 m. birželio 13 d., 19:02 UTC: PushEngage SDK vis dar tiekia užkrėstą kodą iš dalies CDN mazgų.

2026 m. birželio 14 d.: kenksmingasis kodas pašalintas iš PushEngage CDN; Awesome Motive paskelbia oficialų pranešimą apie incidentą.

2026 m. birželio 14–15 d.: Patchstack aktyviai blokuoja išnaudojimo bandymus apsaugotose svetainėse.

KODĖL TAI SVARBU

Viskas atnaujinta. Įskiepiai aktualūs. Serveris pataisytas. Ir vis tiek pažeistas. Būtent tai daro šią ataką tikrai nemalonia — ji netrenkia į silpną jūsų apsaugos vietą, o į aklą. Standartinis modelis „atnaujink įskiepius ir bus gerai” čia tiesiog neveikia, nes pažeidžiamumas buvo ne įskiepyje, o jo pristatymo infrastruktūroje. Jūs negalėjote jo pamatyti, negalėjote jo pašalinti atnaujinimais ir negalėjote jo aptikti standartinėmis priemonėmis.

Yra dar vienas dalykas, kurį svarbu aiškiai suprasti: užklausas kenksmingo administratoriaus kūrimui generavo ne užpuoliko serveris — jas generavo jūsų paties administratoriaus naršyklė. Su jo sesija, jo nonce, jo slapukais. WordPress matė teisėtą vartotoją, atliekantį teisėtą veiksmą. Todėl dauguma WAF taisyklių tylėjo: kaip blokuoti administratorių, kuriantį vartotoją? Pasirodo, galima — bet tik jei tiksliai žinai konkretaus užpuoliko parašus. Patchstack tai padarė, tačiau tik tada, kai kampanija jau vyko.

Jei jūsų svetainė naudoja WooCommerce — pavojus dar didesnis. Mokėjimo kortelių duomenys, klientų adresai, užsakymų istorija, prenumeratos žetonai. Užpakalinės durys su visu RCE tokioje svetainėje — tai jau ne techninis incidentas. Tai duomenų nutekėjimas su visomis pasekmėmis: pranešimas reguliatoriui, pranešimas klientams, reputacijos žala.

KAIP PATIKRINTI SAVO SVETAINĘ

Jei jūsų svetainėje buvo aktyvus OptinMonster, TrustPulse ar PushEngage ir administratorius prisijungė prie valdymo skydelio 2026 m. birželio 12–14 d. — patikrinimas būtinas. WordPress valdymo skydelis šiam tikslui netinka: užpakalinės durys aktyviai slepia save nuo administratoriaus sąsajos — pašalina save iš įskiepių sąrašo, atnaujinimų eilės ir veiklos žurnalų. Visi svarbūs patikrinimai atliekami tik serverio failų sistemos lygmeniu.

Pradėkite nuo administratoriaus paskyrų sąrašo. Jei turite WP-CLI, pakanka vienos komandos — ji išveda visų vartotojų su administrator vaidmeniu prisijungimo vardus ir el. pašto adresus, naujausias viršuje:

wp user list --role=administrator --fields=user_login,user_email

Komanda turi būti paleidžiama WordPress failų savininko vardu — kitaip WP-CLI negalės perskaityti wp-config.php. Jei gavote klaidą Permission denied, patikrinkite failo savininką ir naudokite sudo -u:

# Patikrinkite WordPress failų savininką
ls -la /var/www/html/wp-config.php

# Paleiskite to vartotojo vardu (paprastai www-data)
sudo -u www-data wp user list --role=administrator --fields=user_login,user_email --path=/var/www/html

Jei WP-CLI nėra, tą patį galima padaryti tiesiogiai per MySQL. Užklausa sujungia vartotojų lentelę su metaduomenų lentele ir filtruoja tuos, kurių capabilities lauke yra administrator:

SELECT user_login, user_email FROM wp_users
JOIN wp_usermeta ON wp_users.ID = wp_usermeta.user_id
WHERE meta_key = 'wp_capabilities'
AND meta_value LIKE '%administrator%'
ORDER BY user_registered DESC;

Ieškokite developer_api1 / [email protected] ir paskyrų pagal šabloną dev_xxxxxx — šeši atsitiktiniai simboliai po dev_. Bet kuris iš jų — tiesioginis kompromiso indikatorius.

Toliau tikrinkite failų sistemą. Parametrai -la komandoje ls rodo paslėptus failus ir katalogus (prasidedančius tašku), taip pat prieigos teises ir paskutinio pakeitimo datą — tai padeda pastebėti neseniai sukurtus aplankus:

ls -la /var/www/html/wp-content/plugins/

Užpakalinės durys diegiamos pavadinimu content-delivery-helper arba database-optimizer, tačiau pavadinimas kinta — todėl atkreipkite dėmesį į bet kokius nepažįstamus katalogus, ypač sukurtus birželio 12–14 d.

Net jei pavadinimai neatrodo įtartinai, ieškokite užpakalinių durų parašų tiesiogiai kode. Parametras -r paleidžia rekursinę paiešką visuose nurodyto kelio failuose. Trys komandos ieško: web shell parametro pavadinimo, savavališko PHP vykdymo parametro ir XOR šifravimo rakto. Jei bent viena kažką grąžino — užpakalinės durys yra:

grep -r "developer_api1_fm" /var/www/html/wp-content/plugins/
grep -r "developer_api1_eval" /var/www/html/wp-content/plugins/
grep -r "jX9kM2nP4qR6sT8v" /var/www/html/wp-content/plugins/

Jei svetainė veikė atakos metu — papildomai užblokuokite C2 domeną, kad nutrauktumėte galimus išorinius ryšius. Pirmas variantas per nftables prideda taisyklę į output grandinę, kuri numeta visus siunčiamus paketus į IP 84.201.6.54. Antras variantas per /etc/hosts nukreipia visus DNS užklausimus į tidio.cc neegzistuojančiu adresu — tinka kaip atsarginė priemonė, jei nftables nenaudojamas:

# 1 variantas: nftables — blokavimas paketų lygmeniu
nft add rule inet filter output ip daddr 84.201.6.54 drop

# 2 variantas: /etc/hosts — blokavimas DNS lygmeniu
echo "0.0.0.0 tidio.cc" | sudo tee -a /etc/hosts

Jei radote bent vieną iš šių indikatorių — svetainė laikoma visiškai pažeista. Užpakalinių durų ir kenksmingos paskyros pašalinimas tik pradžia: esant RCE galimybei, užpuolikas galėjo palikti papildomų prieigos taškų bet kurioje failų sistemos vietoje. Keiskite viską: administratorių slaptažodžius, API raktus, duomenų bazės prisijungimo duomenis ir saugumo raktus bei salts wp-config.php faile — būtent salts naudojami sesijų slapukų pasirašymui, juos pakeitę iš karto panaikinsite visas aktyvias sesijas.

KAIP APSISAUGOTI IŠ ANKSTO

Ši ataka jau praėjo, tačiau tiekimo grandinės per CDN mechanizmas niekur nedingo. Štai kas realiai sumažina riziką jūsų serveryje jau dabar.

Stebėkite naujų administratorių paskyrų kūrimą. WordPress pagal nutylėjimą nepraneša, kai atsiranda nauja paskyra su admin teisėmis. Tai galima ištaisyti per kablį user_register — pridėkite šį kodą į functions.php arba mu-plugin. Jis suveikia kiekvienos naujos registracijos metu, patikrina priskirtą vaidmenį ir siunčia jums el. laišką, jei tai administrator. Naujas administratorius — pakankamai retas įvykis, kad kiekvienas toks atvejis reikalautų nedelsiant atkreipti dėmesį:

add_action('user_register', function($user_id) {
    $user = get_userdata($user_id);
    if (in_array('administrator', $user->roles)) {
        wp_mail(
            get_option('admin_email'),
            'Naujas administratorius: ' . $user->user_login,
            'Prisijungimas: ' . $user->user_login . "
El. paštas: " . $user->user_email
        );
    }
});

Failų sistemos vientisumo stebėjimas per AIDE fiksuoja failų sistemos būseną žinomos švaraus diegimo momentu ir kiekvieno vėlesnio paleidimo metu lygina su etalonu. Užpakalinių durų įskiepis, atsiradęs wp-content/plugins/, bus pastebėtas kito patikrinimo metu — net jei jis slepiasi nuo valdymo skydelio. Inicializuokite duomenų bazę vieną kartą, tada paleiskite patikrinimą kasdien per systemd timer:

# Etaloninio stovio inicializavimas — paleiskite švariai sistemai
sudo aide --init
sudo mv /var/lib/aide/aide.db.new /var/lib/aide/aide.db

# Dabartinės būsenos tikrinimas pagal etaloną
sudo aide --check

Dviejų veiksnių autentifikacija visiems WordPress administratoriams nebūtų sustabdžiusi šios konkrečios atakos — skriptas naudojo jau aktyvią sesiją. Tačiau ji uždaro gretimuosius vektorius: sesijų perėmimą, credential stuffing, sukčiavimą. Tiekimo grandinės atakos retai ateina vienos — dažnai jas lydi bandymai gauti prisijungimo duomenis kitais būdais.

Galiausiai reguliariai tikrinkite administratorių sąrašą rankiniu būdu. Kartą per savaitę paleiskite sudo -u www-data wp user list --role=administrator ir palyginkite su tuo, kas turėtų būti. Tai užtrunka trisdešimt sekundžių ir leidžia aptikti nepageidaujamas paskyras gerokai anksčiau, nei jos padarys realios žalos.

KAIP IŠVENGTI PANAŠIŲ ATAKŲ ATEITYJE

Ši ataka atskleidė problemą, kurios visiškai pašalinti sunku, tačiau galima ženkliai apriboti. Pirma pamoka: CDN raktai su rašymo teisėmis neturi būti saugomi serveriuose, veikiančiuose ant WordPress ar kitos TVS. Rinkodaros svetainė — tai ne saugi infrastruktūra. Slaptai su gamybine prieiga ten ne vieta.

Antra pamoka: administratoriaus paskyrų kūrimo stebėsena turi būti jūsų įspėjimų sistemos dalis. Nauja WordPress administratoriaus paskyra — tai įvykis, apie kurį turite sužinoti nedelsiant, o ne iš savaitinio ataskaitos. Tai galima sukonfigūruoti per saugumo įskiepius arba tiesiogiai per WordPress kablius su pranešimu el. paštu.

Trečia pamoka: Subresource Integrity (SRI) — mechanizmas, leidžiantis naršyklei patikrinti išorinio skripto maišą prieš jį vykdant. Jei <script> žymė turėtų integrity atributą su laukiamo failo SHA-256 maiša, naršyklė atsisakytų vykdyti pakeistą SDK. Deja, dauguma SaaS įskiepių neįgyvendina SRI savo SDK failams — būtent todėl, kad reguliariai juos atnaujina. Tačiau kritinėms išorinėms skriptams verta apsvarstyti šį mechanizmą ten, kur tai įmanoma.

Ketvirta pamoka: dviejų veiksnių autentifikacija visiems WordPress administratoriams nebūtų sustabdžiusi šios konkrečios atakos (skriptas naudojo jau aktyvią sesiją), tačiau sumažintų riziką prisijungimo duomenų pažeidimo scenarijuose, kurie dažnai lydi tiekimo grandinės atakas.

KOMPROMISO INDIKATORIAI

Kenksmingos paskyros:

developer_api1 / [email protected]  (fiksuota)
dev_xxxxxx / [email protected]        (atsitiktinės, 6 simboliai)

Užpakalinių durų įskiepiai (pavadinimas kinta, tikrinkite diską):

content-delivery-helper   "Content Delivery Helper"   v2.7.1
database-optimizer        "Database Optimizer"        v2.9.4

Web shell parametrai:

?developer_api1_fm      (web shell, vykdo system($_POST['cmd']))
developer_api1_eval     (vykdo base64-dekoduotą PHP)

C2 infrastruktūra:

tidio.cc  (IP: 84.201.6.54, AS214036 Ultahost)
Keliai: /cdn-cgi/p, /cdn-cgi/b, /cdn-cgi/l, /cdn-cgi/pe-p, /cdn-cgi/pe-b, /cdn-cgi/pe-l

Kenkėjiškos programos šifravimo raktas:

jX9kM2nP4qR6sT8v

Užkrėsti CDN failai (jau išvalyti, tačiau naudingi retrospektyvinei žurnalų analizei):

a.omappapi.com/app/js/api.min.js
a.opmnstr.com/app/js/api.min.js
a.optnmstr.com/app/js/api.min.js
a.trstplse.com/app/js/api.min.js
clientcdn.pushengage.com/sdks/pushengage-web-sdk.js

IŠVADOS

Ataka prieš OptinMonster nemaloni būtent todėl, kad nepalieka paprasto „atnaujinkite įskiepius” ar „naudokite stiprius slaptažodžius” patarimo. Nukentėjusios svetainės darė viską teisingai. Problema buvo ne jose — ji buvo pas pardavėją, vietoje, kur svetainių savininkai neturi nei prieigos, nei matomumo.

Awesome Motive atveju tai vadovėlinis pavyzdys, kodėl gamybiniai slaptai negali gyventi žemesnio saugumo infrastruktūroje. WordPress diegimas su UpdraftPlus ir CDN API raktu su rašymo teisėmis rinkodaros serveryje — tai buvo laiko bomba. Ji sprogo per trečiosios šalies įskiepio pažeidžiamumą, kurį kažkas surado ir tikslingai išnaudojo būtent šiam tikslui.

Jums kaip WordPress administratoriui — tai priminimas, kad jūsų saugumo perimetras platesnis, nei manote. Jis apima kiekvieną išorinį skriptą, kiekvieną CDN, kiekvieną SaaS pardavėją, kuriam jūsų svetainė pasitiki lankytojo naršyklėje. Administratorių paskyrų kūrimo stebėsena, failų sistemos vientisumo tikrinimas per AIDE, WAF su parašais grįstomis taisyklėmis — tai ne perteklinis atsargumas. Tai vieninteliai dalykai, kurie tikrai padės, kai problema ateis ne iš jūsų kodo, o iš svetimo.