GHOSTWORKER: slēpts UniFi vārtejas implants, kas slepus sazinās caur Google DNS

§ 01. Kas mūs sagaidīja

Apiešanai vajadzēja vienu neautentificētu pieprasījumu, un tā atgrieza kontrollera pilnu lietotāju kontu sarakstu. Starp šiem kontiem bija divi nesankcionēti Ubiquiti "support" administratori. Pēc root līmeņa piekļuves iegūšanas ierīcei mēs identificējām papildu kompromitācijas pierādījumus: neatpazītu bināro failu direktorijā /bin, kas nebija saistīts ne ar vienu instalēto pakotni, konfigurēts noturībai pēc pārstartēšanas, maskēts kā kodola pavediens un sazinājās ārēji caur DNS-over-HTTPS (DoH). Šo implantu visā ziņojumā saucam par GHOSTWORKER.

Mūsu izmeklēšana apstiprināja trīs atsevišķus konstatējumus, kas šajā ziņojumā apzināti aplūkoti nošķirti. Pirmkārt, ierīce ir ievainojama pret maksimāla kritiskuma autentifikācijas apiešanu, ko CISA norāda kā aktīvi izmantotu; ievainojamību mēs pārbaudījām ar nedestruktīvu testu. Otrkārt, vārteja jau bija kompromitēta, pirms mēs sākām novērtējumu. Kontrollera pašas datubāzes satur pierādījumus par nesankcionētiem administratora kontiem un operatora aktivitāti jau kopš 2026. gada jūnija vidus. Treškārt, ierīcē atradās īpaši izstrādāts implants ar noturības pēc pārstartēšanas un procesa slēpšanas mehānismiem.

Mēs neesam konstatējuši, ka autentifikācijas apiešanas ekspluatāciju un GHOSTWORKER izvietošanu veica viens un tas pats draudu aktors. Gadījumos, kad pieejamie pierādījumi pamato tikai analītisku secinājumu, nevis apstiprinātu konstatējumu, šī atšķirība ir skaidri norādīta.

§ 02. Kā apiešana darbojas

UniFi OS savu iekšējo servisu priekšā liek autentifikācijas vārteju un ļauj dažiem publiskiem maršrutiem iziet cauri bez pieteikšanās. Vārteja izlemj, vai maršruts ir publisks, nolasot nedekodēto pieprasījuma URL. nginx aiz tās maršrutē pēc dekodētā URL. Šiem diviem nav jāsakrīt. URL, kas sākas ar publisko prefiksu /api/auth/validate-sso/, bet satur kodētas ../ sekvences, iziet cauri vārtejas publiskajai pārbaudei, tad dekodējas aizsargātā /proxy/<serviss>/… ceļā un sasniedz iekšējo servisu (backend) bez autentifikācijas. Šī neatbilstība ir CVE-2026-34908 (bojāta piekļuves kontrole) un CVE-2026-34909 (ceļa šķērsošana), pāris, ko Ubiquiti apraksta SAB-064 un ko Bishop Fox izklāsta savā aprakstā.

Lūk, visa lieta divos pieprasījumos, kas nosūtīti caur tiešu TLS savienojumu (raw socket), lai ..%2f saglabātos un HTTP klients to nenormalizētu.

Apiešana atdeva septiņus lokālo lietotāju ierakstus – lietotājvārdus, e-pasta adreses un lauku nosaukumus api_keys, nfc_token un password_revision. Tā ar administratora tiesībām sasniedz arī rakstīšanas galapunktus: PUT uz īpašnieka kontu izmainīja profila lauku, un tas palika, tāpēc mēs to ielikām atpakaļ. PUT, kas iestata x_password superadministratoram, kam seko parasta pieteikšanās, deva mums strādājošu sesiju – un no turienes pilnu kontroli pār konsoles SSH iestatījumiem.

§ 03. Kļūstot par daļu no botu tīkla

Ubiquiti 2026. gada 21. maijā publicēja drošības paziņojumu SAB-064 par CVE-2026-34908, CVE-2026-34909 un CVE-2026-34910. Katrai ievainojamībai piešķirts CVSS novērtējums 10.0, un, sasaistot tās ķēdē, neautentificēts attālināts uzbrucējs varēja iegūt root līmeņa piekļuvi skartajām UniFi sistēmām.

Bishop Fox pēc tam demonstrēja pilnu ekspluatācijas ķēdi pret UniFi OS Server 5.0.6. Ubiquiti novērsa ievainojamības UniFi OS Server 5.0.8 versijā, tostarp unifi-core 5.0.153. Ubiquiti publicētajā skarto produktu sarakstā ir UDM, UDM-Pro, UDM-SE un UDM-Pro-Max, tostarp klienta vidē izvietotais modelis.

2026. gada 23. jūnijā CISA pievienoja visas trīs ievainojamības savam zināmo ekspluatēto ievainojamību (KEV) katalogam, apstiprinot, ka ekspluatācija novērota reālos uzbrukumos. Tā laika ziņojumi daļu agrīnās ekspluatācijas saistīja ar Mirai/Gafgyt saimes botu tīklu aktivitāti un aprakstīja uzbrucējus, kas kompromitētajās UniFi ierīcēs veido nesankcionētus administratora kontus.

Šī aktivitāte ir būtiska šai izmeklēšanai, jo mēs neatkarīgi identificējām nesankcionētus administratora kontus skartajā vārtejā. Šī sakritība atbilst publiski ziņotajai pēcekspluatācijas uzvedībai; tomēr tā pati par sevi nepierāda, ka par šo kompromitāciju atbildīga tā pati kampaņa vai draudu aktors.

§ 04. Binārais fails, kas nepieder nevienai pakotnei

Ar SSH paroli, kas iestatīta caur apiešanu, un pārstartētu ierīci – klients to saskaņoja – root SSH nostrādāja.

uid=0(root) gid=0(root) groups=0(root)
Linux UDM-Pro 4.19.152-ui-alpine … aarch64 GNU/Linux
eth8  UP  <wan-ip>/28 (WAN)   br0  192.168.1.1/24 (LAN)   uptime: up 2 min

Pirmais, kas izcēlās, bija fails direktorijā /bin:

# dpkg -S /bin/unifi_updater
dpkg-query: no path found matching pattern /bin/unifi_updater

Leģitīmie UniFi binārie faili visi pieder kādai pakotnei. Šis nepiederēja. Tas bija 4 097 312 baitus liels, piederēja root un tika palaists pēc katras pārstartēšanas no root crontab:

# /var/spool/cron/crontabs/root  (uzstādīts sestdien, 2026. gada 27. jūnijā, 20:50:49)
@reboot sleep 60 && /bin/unifi_updater

§ 05. Pretanalīze vienā baitā

Kā atrasts, fails salauž ierastos rīkus – file, readelf, capa un standarta YARA visi to sauc par "ELF 64-bit MSB, unknown arch 0xffffb700." To izdara viens baits. EI_DATA, ELF galvenes piektais baits, norāda baitu secību, un tas ir iestatīts uz 0x02 (big-endian) failā, kura lauki patiesībā ir little-endian. Rīki tic karogam, samaina mašīnas tipa baitus b7 00 un nolasa arhitektūru, kas neeksistē. ARM64 kodols EI_DATA ignorē, tāpēc fails joprojām darbojas. Iestatiet šo baitu atpakaļ uz 0x01, un fails nolasās normāli.

§ 06. GHOSTWORKER statiskā analīze

GHOSTWORKER binārā faila statiskā analīze atklāja funkcionalitāti, kas atbilst noturīgai vārtejas kompromitācijai, C2, piekļuves datu vākšanai, resursdatora izlūkošanai un turpmāku payload'u piegādei.

Kopumā šīs spējas ir īpaši nozīmīgas tāpēc, ka implants tika izvietots tīkla vārtejā. Ierīce ieņem priviliģētu pozīciju, caur kuru iet ievērojama tīkla datplūsma, savukārt GHOSTWORKER satur funkcionalitāti šīs pozīcijas izmantošanai: tas var izveidot ārēju C2, izgūt papildu payload'us, manipulēt ar ugunsmūra uzvedību, profilēt lokālo vidi un vākt piekļuves datus, kas atklāti pieejamajā datplūsmā.

Procesa maskēšanās un atklāšanas iespēja

Tas dod noderīgu atklāšanas pazīmi. Leģitīmi kworker procesi ir kodola pavedieni un tāpēc netiek palaisti no parasta izpildāma faila diskā. GHOSTWORKER turpretī tikai pieņem kodola procesa izskatu, kamēr aiz tā ir lietotāja telpas izpildāmais fails.

Tāpēc process ar nosaukumu [kworker/*] jāuzskata par aizdomīgu, ja:

• /proc/<pid>/exe norāda uz izpildāmu failu;
• /proc/<pid>/maps rāda parastu lietotāja telpas izpildāmā faila kartējumu;
• process uztur ārējus tīkla savienojumus;
• procesam ir parasta komandrinda vai izpildāmā faila inode, kas neatbilst kodola pavedienam.

§ 07. Vadība un kontrole (C2) caur DoH

Tas nesūta beacon tieši uz IP adresi. Tas sūta DNS-over-HTTPS uz Google publisko DNS serveri – POST /dns-query uz Host: dns.google uz 8.8.8.8:443 – ar saviem datiem, iepakotiem DNS nosaukumos ar to pašu %s%c%08lx.%s%d formātu, zem domēna, ko operators kontrolē. Tīklā tas ir tikai vēl viens HTTPS savienojums ar Google: nav nešifrētu DNS pieprasījumu, ko žurnalēt, nav neparasta galamērķa, ko atzīmēt. Katrs pieprasījums nes viltotu galddatora Chrome User-Agent virkni (…rv:129.0… Chrome/129.0.0.0).

Kriptogrāfija ir tā, kas saka, ka šis nav gatavs, plaši pieejams rīks. Binārajā failā ir iegulti trīs PEM bloki:

• pašparakstīts CA sertifikāts, CN=linfosyshosting.nl, derīgs no 2020-07-17 līdz 2030-07-15;
• privātā atslēga, kas tam atbilst – mēs verificējām moduli;
• atsevišķa 3072 bitu RSA publiskā atslēga komandu verifikācijai un izejošo datu šifrēšanai.

Tas, ka implants nes servera privāto atslēgu, nozīmē, ka kanāls ir piesaistīts un savstarpēji autentificēts: implants runā tikai ar to, kam ir šī atslēga. Tas aizsargā operatoru, un aizstāvjiem tas dod precīzu pazīmi, pēc kā meklēt.

§ 08. Linfosys infrastruktūra

Ar GHOSTWORKER saistītais TLS sertifikāts norāda resursdatora nosaukumu linfosyshosting.nl. Domēnu noskaidrojām, izmantojot tikai pasīvus avotus, un neuzsākām nekādu savienojumu ar aizdomīgo C2 infrastruktūru. Passive DNS saistīja resursdatora nosaukumu ar 185.206.140.190.

RIPE reģistrācijas un maršrutēšanas dati rāda konsekventu saikni starp resursdatora nosaukumu, mitināšanas tīklu un implanta izmantoto DNS infrastruktūru.

Infrastruktūrai ir vairāki nosaukumu konsekvences punkti. Sertifikāta resursdatora nosaukums, DNS tuneļa vārdu serveri un tīkla reģistrācija visi satur Linfosys identifikatoru. Pieejamie reģistrācijas dati arī norāda, ka gan sertifikāta identitāte, gan attiecīgā tīkla reģistrācija par vairākiem gadiem apsteidz šo incidentu, datējamas ar aptuveni 2020. gadu.

Operatora piekļuves infrastruktūra

UniFi kontrollera admin_activity_log kompromitācijas periodā reģistrēja administratīvu piekļuvi no vairākām ārējām mitināšanas pakalpojumu sniedzēju adresēm:

Attiecināšanas ierobežojumi

Mēs neattiecinām šo aktivitāti uz kādu konkrētu personu vai uz Linfosys BV.

Tas, ka RIPE reģistrē C2 adrešu telpu ar Linfosys nosaukumu, nodibina tikai reģistrācijas un maršrutēšanas saikni. Tas nenosaka, kurš darbināja GHOSTWORKER infrastruktūru. Ticami skaidrojumi ietver klientu, kas izmanto šo tīklu, tālākpārdevēju vai pakārtotu operatoru, kompromitētu infrastruktūru vai infrastruktūru, kas apzināti izvēlēta tāpēc, ka tās nosaukums un reģistrācija izskatītos leģitīmi.

Arī pats sertifikāts satur identitātes informāciju, kas šķiet neuzticama. Tā organizācijas lauks norāda "Piratpartiet", savukārt citi subjekta atribūti apvieno ģeogrāfisku informāciju no vairākām savstarpēji nesaistītām jurisdikcijām. Tāpēc mēs vērtējam sertifikāta identitātes laukus kā, visticamāk, izdomātus vai apzināti maldinošus un nepiešķiram tiem attiecināšanas nozīmi.

Spēcīgākais infrastruktūras atradums tādējādi nav sertifikātā norādītā identitāte, bet atkārtotā tehniskā korelācija starp Linfosys zīmola resursdatora nosaukumu, autoritatīvo DNS infrastruktūru un autonomo sistēmu, kas mitina aizdomīgo C2.

§ 09. Kāds jau bija iekšā

Kontrollera datubāzes rāda ielaušanos, kas sākās pirms mūsu testa. Divi superadministratora konti tika pievienoti ārpus normālās plūsmas – unifi_support (2026. gada 17. jūnijā) un supports_unifi_system (9. jūlijā), abi kopējot Ubiquiti atbalsta nosaukumus – tas pats triks, kas implanta faila nosaukumā. Neviens neparādās unique_logins tabulā, kas uzskaita tieši vienu īstu lietotāju, kurš jebkad pieteicies. Tie tika pievienoti tieši datubāzē; ar tiem neviens nekad nav pieteicies.

Vienu sakritību ir grūti uzskatīt par nejaušību. supports_unifi_system tika izveidots 9. jūlijā 19:56:12 UTC, un pieteikšanās no 185.44.78.8 reģistrēta 19:56:18 – sešas sekundes vēlāk. Implanta crontab tika ierakstīts 61 sekundi pēc tās pašas adreses pēdējās administratora paneļa darbības 27. jūnijā. Mēs sarindojam to, ko zinām, pēc pārliecības pakāpes:

• Apstiprināts. Ierīce ir ievainojama pret apiešanu, un mēs to izmantojām. Divi superadministratori ar atbalsta dienesta nosaukumiem tika pievienoti tieši un sasaistās ar ārējiem IP. AArch64 implants ar manipulētu ELF galveni, @reboot noturību, [kworker] maskēšanos, DoH C2 un iegultu sertifikātu plus tā privāto atslēgu bija uz vārtejas. Sertifikāts, tā vārdu serveri un tā mitināšanas tīkls visi nes Linfosys nosaukumu, un visi datēti ar 2020. gadu.
• Ticami. Tas ir viens ielauzējs, ne vairāki: tā pati galvenā IP aptver implanta uzstādīšanu un administratoru pieteikšanos, un nosaukumu triks ir konsekvents. Lai kas tas būtu, viņš pārzina amatu – DoH tunelēšana, piesaistīts sertifikāts, kodola pavediena maskēšanās un galvenes manipulācija krietni pārsniedz botu tīklu līmeņa rīkus. Ticamākais stāsts ir pieredzējis operators, kas izmanto jaunu, aktīvi ekspluatētu ievainojamību pret ierīci, kura gadījās būt sasniedzamai no interneta.
• Nepierādīts. Mēs to nevaram sasaistīt ar Linfosys kā uzņēmumu. Mēs neredzējām sākotnējo ielaušanos. Un mēs neatguvām beacon intervālu vai komandu kopu, jo tam paraugs būtu jāpalaiž, no kā mēs izvairījāmies, lai nekontaktētu C2.

§ 10. Kompromitācijas indikatori

Viss zemāk redzamais tika novērots novērtējuma laikā, ar pievienotiem publiskiem reģistra datiem, kur norādīts. Mēs nepublicējam klienta aktīvos noslēpumus un abas privātās atslēgas.

§ 11. Ko meklēt

Apiešanu ir viegli notestēt, un implants atstāj viegli pārbaudāmas pēdas. Uz UniFi un uz Linux tīkla malas ierīcēm kopumā:

• Notestējiet apiešanu. Ja GET /proxy/users/api/v2/users atgriež 401, bet tas pats ceļš aiz /api/auth/validate-sso/..%2f..%2f..%2f atgriež 200, jūsu ierīce ir ievainojama. Ielāpojiet un izņemiet pārvaldības saskarni no publiskā interneta.
• Nepieņemiet, ka ielāpošana visu sakārto. Pēc ielāpošanas pārbaudiet lokālos administratorus, meklējot ārpus normālās plūsmas pievienotus kontus – tādus, kuru nav unique_logins, īpaši tādus, kas atdarina atbalsta kontus – un salīdziniet admin_activity_log avota IP ar saviem īstajiem administratoriem.
• Meklējiet bināros failus, kas nepieder nevienai pakotnei. Jebkas direktorijā /bin vai /sbin, ko dpkg -S nevar izskaidrot, ir vērts pārbaudīt tuvāk, tāpat arī jebkurš @reboot cron ieraksts, kas to palaiž.
• Meklējiet maskēšanos. Process ar nosaukumu [kworker/*], kura /proc/<pid>/exe norāda uz īstu failu, nav kodola pavediens. Pārbaudiet arī /var/tmp/a.tmp un ELF failus ar EI_DATA=0x02, kas joprojām darbojas.
• Vērojiet izejošo DoH no tīkla aprīkojuma. Vārteja, kas sūta application/dns-message uz publisku DNS serveri, ir anomālija. Bloķējiet vai vērojiet linfosyshosting.nl, *.linfosys.{nl,eu,com}, 185.206.140.190 un AS61351.
• Ja atrodat kaut ko no tā, uzskatiet ierīci par pilnībā kompromitētu. Izolējiet to, saglabājiet bināro failu un žurnālus, pārbūvējiet no tīras programmaparatūras un nomainiet visus noslēpumus, kas tajā glabājās. Ar faila dzēšanu nepietiek.

§ 12. Kāpēc tas ir svarīgi

Tīkla malas vārtejas ir viegli aizmirst. Tās ir vērstas pret internetu, ielāpus tās saņem pēdējās, viss, kas atrodas aiz tām, tām uzticas, un, kad tās darbina pilnu programmatūras steku, viena root kompromitācija atklāj Wi-Fi atslēgu, RADIUS noslēpumu, kontrollera datubāzes, video sistēmu un skaidru skatu uz visu, kas iet cauri.

Šajā gadījumā nav nekā eksotiska. Maksimāla kritiskuma, publiski atklāta, jau izmantota UniFi ievainojamība bija atklāti sasniedzama uz vecas konsoles, un līdz brīdim, kad plānots tests to sasniedza, kāds jau bija ievietojis administratora kontus un root implantu. Galvenais ir laiks: tiklīdz šāda ievainojamība nonāk KEV sarakstā, laika sprīdis starp publiskošanu un kompromitāciju sasniedzamai ierīcei ir nedēļas, ne mēneši, un "ielāposim nākamajā ciklā" ir likme, ko var zaudēt, pirms cikls pienāk.

Mēs to veicām kā autorizētu testu un publicējam uzbrucēja indikatorus pilnībā, lai citi varētu pārbaudīt savu vidi uz šī paša operatora klātbūtni. Ja jūs darbināt internetam pieejamu vārteju, ātrākais noderīgais, ko šodien varat izdarīt, ir divu pieprasījumu tests augstāk – un pēc tam meklējiet [kworker], kam pieder fails.