CARBONATO-ն բաց Docker-ը դարձնում է ԱԲ բոտնետի հանգույց

2026 թ. սեպտեմբերի 30-ին Սինգապուրի կիբեռանվտանգության գործակալության CARBONATO-ի վերաբերյալ զգուշացումը նկարագրեց բոտնետի արշավ, որը թիրախավորում է համացանցին առանց նույնականացման բացված Docker Remote API-ները, սովորաբար՝ TCP 2375 պորտով։ Հարձակվողն այդ մուտքով գործարկում է արտոնյալ կոնտեյներ և հասնում հիմնական մեքենային։ Այնուհետև այնտեղ տեղադրված Hermes Agent-ը կարող է կատարել օպերատորի առաջադրանքները, իսկ առանձին սցենարները փնտրում են հաջորդ հասանելի հանգույցները։

2026 թ. սեպտեմբերի 22-ին հրապարակված ThreatDown-ի հետազոտությունը բաց Docker Registry-ից հավաքված 59 պահոցի, 234 image tag-ի և 4,3 ԳԲ նյութի հիման վրա վերակազմեց գործողությունը. հրապարակված SOUL.md հրահանգներում ԱԲ ծառայությունների API բանալիները կոչվում են «loot #1»։ Հավաքածուն պարունակում էր նաև կեղծ կրիպտոդրամապանակներ տարածող առանձին գործողության նյութեր։ Բոտնետի բաղադրիչները ցույց են տալիս, որ սկզբնական մուտքն ու տարածումը ապահովում են նախապես գրված սցենարները, իսկ ԱԲ գործակալն օգտագործվում է արդեն գրավված մեքենայի վրա։

Մուտքի դուռը Docker-ի կառավարման API-ն է

Հարձակման համար բավարար է, որ Docker daemon-ը ցանցից ընդունի կառավարման հարցումներ՝ առանց հաճախորդին նույնականացնելու։ Այդ դեպքում հարձակվողը կարող է օգտագործել Docker-ի սովորական API-ն՝ կոնտեյներ ստեղծելու և գործարկելու համար։ CARBONATO-ի գործարկած արտոնյալ կոնտեյներին միացվում է հիմնական մեքենայի ֆայլային համակարգը, իսկ գործընթացների և ցանցի միջավայրերը հասանելի են դառնում կոնտեյների ներսից։ Այդ համադրությունը թույլ է տալիս կոնտեյների միջոցով հրամաններ կատարել նաև հիմնական մեքենայում։

Բաց Docker Registry-ն և բաց Docker Remote API-ն շղթայի տարբեր օղակներ են։ Հետազոտողների գտած Registry-ում պահված պատկերներն ու կարգավորումները բացահայտել են հարձակվողի գործիքները. գրավված մեքենաները դրանից ներբեռնում էին վնասաբեր բաղադրիչը։ Զոհի Remote API-ն այն միջերեսն է, որով հարձակվողը տեղակայում է արտոնյալ կոնտեյները։ Հետևաբար միայն Registry-ի հասանելիությունը ստուգելը չի պարզի՝ արդյոք կազմակերպության Docker հանգույցը կարելի է կառավարել անվստահելի ցանցից։

Արտոնյալ կոնտեյները պահպանում է մուտքը հոսթին

Հիմնական մեքենա հասնելուց հետո գործարկվում է կայունացման սցենարը։ Այն բացում է հակադարձ SSH կապ դեպի հարձակվողի միջնորդ սերվեր, տեղադրում SSH ծառայություն, ավելացնում հարձակվողի բանալին և Telegram-ով ուղարկում տեղակայման տվյալները։ Այդ քայլերը օպերատորին վերադարձի ուղի են տալիս մինչև Hermes Agent-ով որևէ առաջադրանք ուղարկելը։ Կապի համար օգտագործվող հեռավար պորտը հաշվարկվում է զոհի IP հասցեից, որպեսզի օպերատորը կարողանա այն նորից գտնել։

Բաղադրիչը փորձում է նմանվել սովորական Linux ծառայության. կոնտեյների անուններից մեկը systemd-resolved է, իսկ գործընթացի որոշ արգումենտներ նմանակում են համակարգային գործընթացի անվանումը։ Կայունացման սցենարները փոփոխություններ են անում cron-ում, systemd-ի ժամանակաչափերում և գործարկման այլ մեխանիզմներում։ Վերահսկող գործընթացները կարող են Registry-ից կրկին ներբեռնել բաղադրիչը, երբ դրա ֆայլերը կամ կոնտեյները հեռացվում են։ Այս պատճառով հայտնաբերված կոնտեյները ջնջելուց հետո պետք է ուսումնասիրել նաև հիմնական մեքենայի հեռավար մուտքն ու ավտոմատ գործարկման գրառումները։

Hermes Agent-ին ուղղորդում են օպերատորի հրահանգները

CARBONATO-ն տեղադրում է Nous Research-ի բաց կոդով Hermes Agent-ը՝ առանց փոխելու ծրագրի հիմնական կոդը։ Փոխարենը վերագրվում է SOUL.md հրահանգների ֆայլը, որը գործակալին տալիս է GH0ST անունը և հարձակվողի նպատակները։ Օպերատորը Telegram-ով առաջադրանք է ուղարկում գրավված հանգույցին. գործակալն այն փոխանցում է լեզվային մոդելին, կատարում ստացված հրամանները և արդյունքը վերադարձնում նույն հաղորդակցման ուղով։ Գործակալին առաջադրանք տալու այս հնարավորությունը չի նշանակում, որ նա ինքն է գտնում մուտքի դուռը կամ ծրագրում բոտնետի տարածումը։

Հրահանգները առաջնահերթ են համարում ԱԲ մատակարարների API բանալիները, ապա՝ SSH տվյալները, հասանելիության նշանները և տվյալների շտեմարանների գաղտնիքները։ Կարգավորման մեջ նշված են նաև հայտնաբերված արժեքները պարզ տեքստով պահելու և դուրս ուղարկելու հրամաններ։ Սա ցույց է տալիս հարձակվողի նպատակը, բայց միայն այդ ֆայլի առկայությունը չի հաստատում, թե կոնկրետ որ կազմակերպության բանալիներն են դուրս բերվել։ Վտանգված հանգույցի դեպքում դրա վրա հասանելի գաղտնիքները պետք է ստուգել հաշիվների օգտագործման գրանցումների հետ և փոխել հնարավոր բացահայտված արժեքները։

Տարածումը կատարում են առանձին սցենարները

Գրավված հանգույցը պարբերաբար զննում է իրեն հասանելի ցանցերը, ներառյալ Docker-ի կամրջային ցանցերը, և փնտրում նույն կերպ բաց կառավարման ծառայություններ։ Նոր թիրախ գտնելիս սցենարը ստուգում է, որ ծառայությունը Docker է, ապա կրկնում է արտոնյալ կոնտեյների տեղակայումը։ Նոր հանգույցն իր հերթին ներբեռնում է բաղադրիչը և միանում որոնման շղթային։ Այս փուլում լեզվային մոդելը դեր չունի. տարածումը շարունակվում է առանց օպերատորի հերթական հաղորդագրության։

Ցանցային այս ուղին կարևոր է նաև այն կազմակերպությունների համար, որոնց Docker API-ն անմիջապես տեսանելի չէ հանրային համացանցից։ Եթե այն առանց նույնականացման հասանելի է մեկ այլ՝ արդեն գրավված մեքենայից, հարձակվողը կարող է փորձել նույն մուտքը ներքին ցանցում։ Ռիսկը, հետևաբար, որոշվում է ոչ միայն հանրային IP հասցեով, այլև նրանով, թե որ համակարգերն են կարողանում դիմել կառավարման միջերեսին։

Ինչ ստուգել Docker հանգույցներում

Ստուգման հերթականությունը սկսվում է բաց կառավարման միջերեսից և շարունակվում արդեն հնարավոր գրավման հետքերով։ Եթե հանգույցը նախկինում հասանելի է եղել առանց նույնականացման, միայն ցանցային մուտքը փակելը բավարար չէ դրա վիճակը գնահատելու համար։

1. Պարզել, թե որ Docker Remote API-ներն են հասանելի համացանցից կամ անվստահելի ներքին ցանցերից, և սահմանափակել առանց նույնականացման մուտքը։ Եթե հեռավար կառավարումն անհրաժեշտ է, Docker-ի կառավարման ծառայության պաշտպանության ուղեցույցը նկարագրում է SSH կապը և հաճախորդի վկայագրով նույնականացվող TLS-ը։
2. Հնարավոր ազդեցության ենթարկված հանգույցներում փնտրել անսպասելի արտոնյալ կոնտեյներներ, հիմնական մեքենայի ֆայլային համակարգի միացումներ, չարտոնված SSH բանալիներ և ավտոմատ գործարկման գրառումներ։ Ավելի բնորոշ հետքեր են GH0ST պարունակող SOUL.md ֆայլը, CARBONATO_API_KEY միջավայրի փոփոխականը և սերվերից Telegram-ին ուղղված անբացատրելի կապերը։
3. Պարզել, թե ինչ API բանալիներ, հասանելիության նշաններ և SSH գաղտնիքներ են հասանելի եղել այդ մեքենայից։ Կասկածվող կամ հաստատված ներթափանցման դեպքում փոխել հնարավոր բացահայտված տվյալները և ստուգել, թե դրանցով ինչ հարցումներ են կատարվել։
4. Դիտարկել հարակից Docker հանգույցներն ու ցանցային գրանցումները՝ կառավարման ծառայությունների կրկնվող որոնման նշանների համար։ Ներթափանցման հետքերի դեպքում մեկուսացնել տուժած մեքենաները և ուսումնասիրել հիմնական համակարգի պահպանված մուտքերը՝ նախքան այն կրկին ծառայության վերադարձնելը։

Կարդացեք նաև:

• Docker Cloud Sandboxes-ը գործակալին ամպ է տանում՝ նոութբուքը կարող է քնել