Google shkatërron një rrjet kompjuterësh të infektuar të fshehur në 1.3 milionë pajisje televizive

Javën e kaluar, Google dhe partnerët e industrisë çmontuan derën e pasme XCPE e cila regjistroi më shumë se 1.3 milion dekoderë në një botnet. “Ne vlerësojmë me besim të lartë se dera e pasme dhe botneti u zhvilluan, u vendosën dhe u operuan qëllimisht për përfitim financiar nga Videostrong Technology Co., një Prodhues i Pajisjeve Origjinale Android (OEM) dhe Prodhues i Dizajnit Origjinal (ODM).

Videostrong fitoi para nga dera e pasme duke shitur akses te bashkëpunëtorët kriminalë dhe duke ngarkuar modulet e malware të këtyre bashkëpunëtorëve në pajisjet e infektuara. Këto module dytësore po kryenin mashtrime me reklama; duke regjistruar në heshtje pajisjet e infektuara në rrjetet proxy rezidenciale; dhe duke ngarkuar malware shtesë në pajisjet e kompromentuara me XCPE. Ne gjithashtu morëm masa për të ndërprerë domenet e komandës dhe kontrollit (C2) që operojnë këto module bashkëpunëtore. Meqenëse secili prej këtyre bashkëpunëtorëve ka kanale të diversifikuara shpërndarjeje për modulet e tyre përtej XCPE, ne vlerësojmë se heqja e domeneve të tyre C2 do të ndërpresë aksesin në të paktën 10 milionë pajisje të tjera të kompromentuara.

Ne e gjetëm këtë program keqdashës të integruar direkt në shumë modele dhe marka të ndryshme pajisjesh gjatë shumë viteve, të mbështetur nga një infrastrukturë e dedikuar dhe konfigurime në zhvillim të vazhdueshëm për të shmangur zbulimin dhe për të menaxhuar bashkëpunëtorët e tyre. Ne besojmë se kjo fushatë nuk ishte një person i izoluar mashtrues ose një mbikëqyrje zhvillimi. Si rezultat, Google i ka prerë lidhjet me Videostrong dhe i ka ndaluar ata të prodhojnë pajisje me aplikacione Google të para-ngarkuara.

Google kërkon që prodhuesit e pajisjeve origjinale (OEM) të kalojnë nëpër një sërë testesh gjithëpërfshirëse të përputhshmërisë dhe sigurisë për të siguruar një përvojë të qëndrueshme dhe të sigurt të përdoruesit në të gjithë ekosistemin Android. Megjithatë, Videostrong përdori teknika të fshehjes për të shfrytëzuar një boshllëk në testet tona dhe për të ngarkuar kodin keqdashës pas nisjes së parë të pajisjes. Si rezultat, Google ka zbatuar ndryshime në procesin e saj ekzistues të shqyrtimit për t’u mbrojtur më mirë nga aktivitete të ngjashme në të ardhmen. Një prodhues pajisjesh që infekton qëllimisht përdoruesit e tij me programe keqdashëse është një shkelje e papranueshme e besimit dhe përfaqëson një rrezik serioz për ata përdorues. Pa dijeninë ose pëlqimin e përdoruesve, pajisjet e infektuara u ofruan si një mekanizëm shpërndarjeje për një gamë të gjerë aktorësh kriminelë. Kjo çoi në një sërë aktivitetesh keqdashëse që u kryen në dhe përmes pajisjeve, duke përfshirë mashtrimin me reklama, nxjerrjen e të dhënave dhe drejtimin e trafikut keqdashës të rrjetit përmes pajisjeve.

Ne punuam ngushtë me Agjencinë Kombëtare të Policisë së Japonisë, Lumen, HUMAN Security, Plume, Synthient dhe TrendAI për të analizuar këtë ekosistem të programeve keqdashëse dhe për të ndërprerë operacionet e tij.

Ndërkohë që presim që kjo ndërprerje të ketë një efekt të rëndësishëm në këto operacione kriminale, ky nuk është fundi i punës sonë në luftën kundër aktivitetit dashakeq. Operatorët e “backdoor”, rrjetet e mashtrimit me reklama dhe ofruesit e serverëve rezidencialë me proxy veprojnë si një zinxhir furnizimi i ndërlidhur. Ndërprerjet në moment janë një mjet kritik për të mbrojtur përdoruesit tanë, por ndërprerjet e qëndrueshme në këtë ekosistem fluid do të kërkojnë shënjestrimin e vazhdueshëm të kësaj infrastrukture.

Google ndërmori veprimet e mëposhtme për të mbështetur ndërprerjen e botnetit XCPE:

Veprim ligjor për të hequr domenet dhe serverat që Videostrong përdori për të kontrolluar botnet-in dhe për të instaluar module malware.

Veprim ligjor për të hequr domenet C2 të përdorura nga mbi një duzinë familjesh malware të ngarkuara si module përmes kësaj dere të pasme.

I ndaloi Videostrong dhe çdo filiali ose bashkëpunëtori të ardhshëm të ndërtonin dhe shisnin pajisje të çertifikuara Android në të ardhmen, ose të furnizonin softuer për shitës të tjerë të çertifikuar.

Zbatimi i përmirësimeve në mënyrën se si sigurojmë integritetin e firmware-it në pajisjet e certifikuara Android TV.

Rrjeti x.cpe u ndërtua për fitim të vazhdueshëm. Duke u dhënë bashkëpunëtorëve të programeve keqdashëse akses në derë të fshehtë, operatorët komplotuan për të fituar para nga këto pajisje shumë kohë pas blerjes.

Që të paktën nga fundi i vitit 2024, Videostrong ka evoluar malware-in e tij të parainstaluar nga programe të thjeshta me një fazë në një arkitekturë modulare me tre faza, të projektuar për qëndrueshmëri dhe fitim parash nga shumë përdorues:

Dera e prapme primare: Duke vepruar në android.uid.systemnivelin e privilegjeve x.cpe(duke funksionuar si com.oemservicenë disa versione) është e parangarkuar në ndarjen e firmware-it. Nëse çinstalohet nga një përdorues, ajo riinstalohet automatikisht nga /oem/ndarja pas rinisjes, duke ruajtur akses të vazhdueshëm në nivelin e sistemit. Funksioni i saj kryesor është të krijojë dhe lehtësojë komunikimet midis serverit C2 dhe ngarkuesit dhe motorit të ekzekutimit.

Motori i Ngarkuesit dhe Ekzekutimit: Për të shmangur skanimet e sigurisë, x.cpevepron kryesisht si komunikues C2 dhe shkarkon ekzekutimin e modulit në një ngarkues të jashtëm, com.abc.nexus. Ky skedar përdor shërbime anti-analizë vendase për të penguar zbulimin e sandbox-it dhe konfiguron dhe inicializon modulet e monetizimit. Kohët e fundit, com.abc.nexusështë hequr gradualisht në favor të përdorimit të malware-it më të përshtatur dropper që ngarkon dhe ekzekuton module të vetme.

Modulet e Monetizimit: Videostrong monetizon pajisjet e saj të fshehura duke ngarkuar module monetizimi të cilat zhvillohen nga entitete të tjera përveç Videostrong që veprojnë si bashkëpunëtorë. Këto module vendosen si daemonë ELF vendas, SDK të integruara të kompiluara direkt në com.abc.nexusbytekodin DEX, ose merren si APK sekondare nga infrastruktura e skanimit të malware. Modulet e ngarkuara i transformojnë pajisjet e infektuara në nyje dalëse proxy rezidenciale (p.sh., Linkfog, AppSalt, NetNut), motorë mashtrimi me reklama (p.sh., CBOXTV, HiddenView), ose ekzekutojnë backdoor shtesë që ngarkojnë edhe më shumë module monetizimi (p.sh. Moyu, Spirit).

Komanda dhe Kontrolli: Botneti përdor një proces C2 me dy faza. Së pari, ai fillon kërkesat HTTP POST për të marrë cilësimet dinamike të konfigurimit, të dhënat e gjeolokacionit dhe parametrat e serverit STUN. Pastaj krijon një lidhje të vazhdueshme, në kohë reale, të Message Queuing Telemetric Transport (MQTT) për të marrë udhëzime për instalimet e heshtura të aplikacioneve, komandat arbitrare të shell, kapjet e ekranit dhe zbulimin e rrjetit. MQTT është një protokoll rrjeti i lehtë, publiko-dhe-abono, i projektuar për rrjete të largëta me gjerësi të ulët bande, latencë të lartë ose jo të besueshme.

Infrastruktura e skenimit të malware-it: Module shtesë të monetizimit, si dhe skripte të ndryshme shell dhe aplikacione legjitime, mbahen nga distanca dhe shkarkohen nga pajisjet e infektuara me komandën e operatorit nëpërmjet ndërmjetësit MQTT. Një shumicë e konsiderueshme e këtyre skedarëve mbahen ndërsa Github lëshon në faqet e Github në pronësi të operatorit. Skedarët e tjerë mbahen në servera të kontrolluar nga operatori dhe faqe pritjeje skedarësh.

Zinxhiri i infeksionit fillon me një paketë stub (e thirrur x.cpenë disa versione dhe com.oemservicenë të tjera) të parangarkuar në ndarjen e sistemit të firmware-it dhe që funksionon në android.uid.systemnivelin e privilegjeve. Kjo paketë stub ka funksionalitet të kufizuar. Pas nisjes, ajo kontrollon direktorinë e pajisjes oem/për paketën përkatëse x.cpedhe fillon instalimin në /data/app/direktori siç përshkruhet më poshtë.

Për të ruajtur gjendjen ndër-procesore në të gjithë ekosistemin e firmware-it, x.cpeeksporton dy ContentProviders, të cilët ekspozojnë tabela të strukturuara të konfigurimit që ruajnë parametrat e kohës së ekzekutimit, identifikuesit e pajisjeve, blob-et e konfigurimit të proxy-t dhe flamujt e ekzekutimit të arritshëm nga aplikacionet e sistemit të bashkë-instaluara. Kjo u mundëson aplikacioneve të tjera në ekosistemin e Videostrong, siç është softueri i tyre i transmetimit YokaTV Player, të marrin parametrat e konfigurimit të ofruar nga serveri C2 i përmendur më poshtë.

Malware përdor një protokoll komunikimi me dy faza. Së pari, ai merr konfigurimet fillestare të bootstrap nëpërmjet një kërkese HTTP, të ndjekura nga një abonim i vazhdueshëm MQTT për të marrë komanda dhe udhëzime për shkarkimin e modulit.

Për të nxjerrë në mënyrë dinamike serverin bootstrap HTTP C2, ndiqet rutina e mëposhtme.

Pyetje content://com.release.debug.provider/configspër private_urlnëpërmjet x.cpe.util.ExtraReadUtils.

Bën pyetje në vetinë e sistemit Android për të përcaktuar nëse ro.mecool.deviceështë e vërtetë.

Nëse është e vërtetë, parazgjedhja ështëhttp://mcstb.anyevonline.com:8000

Nëse është e gabuar, ajo gjeneron në mënyrë dinamike sa vijon: http://stb[AndroidVersion][Type].anyevonline.com:8000.

Duke përdorur emrin e zgjedhur të hostit, klienti bën një kërkesë HTTP POST me një objekt JSON të enkriptuar me AES që përmban telemetrinë e harduerit (SN, MAC, model, versioni i firmware-it) në pikat fundore të mëposhtme:

/router/config/mqtt : Kjo pikë fundore ofron detaje të ndërmjetësit MQTT (duke përfshirë Emrin e Hostit të Ndërmjetësit, Portën TCP, Tokenat/Fjalëkalimet e Autentifikimit dhe strukturën specifike të Temës: /device/{model}/{chipId}/{action}. Pas marrjes së këtyre të dhënave, pajisja fillon një lidhje të vazhdueshme, në kohë reale, me ndërmjetësin MQTT.

/router/config/acs : Kjo përgjigje e pikës fundore kthen URL-të për ip-api[.]com dhe një server Google STUN për të mundësuar që malware të identifikojë gjeolokacionin dhe IP-në publike dhe hartëzimin e portave për të përshkuar kufijtë e përkthimit të adresës së rrjetit (NAT). Gjithashtu kthen një URL ( http://ott.szbboys[.]com:8000/cpe/file/upload për ngarkimin e skedarëve, regjistrave ose të dhënave diagnostikuese nga pajisja, dhe kthen flamuj për të konfiguruar modulet e reklamave ( adBwmActive,,, adDevourUse) adDevourCodedhe për të aktivizuar ose çaktivizuar modulet kryesore të malware.

/router/config/app: Kjo pikë fundore ofron konfigurime në nivel moduli, duke përfshirë hartëzimin dhe parametrat e serverit, të cilat x.cpedeshifrohen dhe kalojnë te një SQLite ContentProvideri quajtur ShareProvider( com.oem.share.provider). Duke ekspozuar këtë ndërfaqe të dhënash ndërprocesore, x.cpeu mundëson moduleve të marrin parametrat e azhurnuar të infrastrukturës së rrjedhës së sipërme (siç janë URL-të për konfigurime shtesë, manualet e përdoruesit, etj.).

Pas konfigurimit fillestar, komunikimi i vazhdueshëm C2 në kohë reale menaxhohet nga biblioteka MQTT ( x.cpe.mqtt.MqttUtils). Të gjitha mostrat e identifikuara të analizuara deri më sot përdorin një emër të vetëm host-i ndërmjetësi, mqtt.szbboys[.]com.

Temat specifike të MQTT-së janë të lidhura me veprime specifike, duke përfshirë:

Instalimi i Heshtur i Aplikacioneve : Marr APK-të e largëta në një drejtori të përkohshme.

Çaktivizo Google Play Protect : Për të anashkaluar sigurinë, AppUtils.disablePackageVerify()synon cilësimin global ” package_verifier_user_consent” nëpërmjet Settings.Global.putIntdhe e vendos atë në -1, duke çaktivizuar verifikimin e aplikacionit Google Play Protect.

Ekzekutimi Arbitrar i Shell-it : Ekzekuton komandat në distancë nëpërmjet shnivelit të privilegjit UID të sistemit. Rezultatet publikohen te ndërmjetësi MQTT.

Ekzekutimi i Skriptit Shell : Shkarkon dhe ekzekuton skriptet shell nëpërmjet x.cpe.util.RunCmds.

Monitorimi i Desktopit në Distancë dhe Kapja e Ekranit : Përdoret android.app.Instrumentation.sendKeyDownUpSync()për të injektuar kode çelësash dhe reflektim Java në API-të e fshehura ( android.view.SurfaceControl.screenshot/ SurfaceControl$ScreenshotHardwareBuffer) për të kapur vazhdimisht ekranin, për ta kompresuar në JPEG dhe për ta publikuar në MQTT.

Zbulimi i Rrjetit : Thirrje të skedarëve binare të integruar ( libtraceroute.so) për të gjetur gjurmët e gishtave të rrjetit të viktimës dhe për të kryer teste standarde ping. Skedarët binare gjithashtu kryejnë pyetje të fuqishme të drejtimit WHOIS me kërkim AS.

Analiza jonë e të dhënave C2 tregon se mbizotërimi i ndërveprimeve me pajisjet viktima lidhej me veprimet e instalimit, çinstalimit dhe konfigurimit të modulit. Ne gjithashtu vëzhguam operatorë Videostrong që ekzekutonin veprime të ndjeshme në pajisje, duke përfshirë kapjen e pamjeve të drejtpërdrejta të ekranit; injektimin e shtypjes së tasteve; nxjerrjen e të dhënave të ndjeshme duke përfshirë informacionin e llogarisë, informacionin e pajisjes, inventarët e paketave dhe regjistrat e sistemit; dhe ekzekutimin e skripteve dhe komandave të shell, duke përfshirë edhe krijimin e shell-eve të kundërta në pajisje.

Versione më të hershme të x.cpemoduleve të monetizimit me qëllim të keq të integruara drejtpërdrejt. Në fund të vitit 2024 – ndoshta si përgjigje ndaj zbatimit të mëparshëm të Google në lidhje me BadBox – Videostrong hoqi modulet me qëllim të keq nga x.cpedhe prezantoi një paketë të veçantë me qëllim të keq që ata zhvilluan, com.abc.nexus, e cila x.cpedrejton udhëzimet dhe të dhënat nëpërmjet Komunikimit Ndër-Proces (IPC). Variantet moderne të x.cpelehtësojnë komunikimet C2, por kalojnë parametrat e konfigurimit, përditësimet e modulit dhe ngarkesa të tjera si com.abc.nexusmotor ekzekutimi. Ne besojmë se aktori mund ta ketë evoluar malware-in në këtë mënyrë në një përpjekje për t’u siguruar x.cpe që mund të mbetej i pazbuluar.

Pas nisjes, com.abc.nexus.broadcast.BootReceivertransmeton com.abc.nexus.dataqëllimin, duke u nisur nga com.abc.nexus.service.CoreService. Brenda CoreService.onCreate, aplikacioni kryen detyra mirëmbajtjeje dhe qëndrueshmërie. Logjika kryesore konfiguron një dëgjues RemoteMessageHandlerpër komunikimet IPC nga x.cpe,dhe analizon ngarkesat JSON të marra prej tij.

Pas këtyre hapave, CoreServiceinicializon modulet e monetizimit. com.abc.nexusShërbimet nxjerrin dhe orkestrojnë një seri bibliotekash native të ndërthurura dhe ngarkesash dytësore të shkarkuara dinamikisht të cilat ndryshojnë ndjeshëm në bazë të mostrës. Shumë versione të com.abc.nexusvijnë të parangarkuara me katër ose më shumë module të integruara, ndërsa versionet e tjera përmbajnë vetëm një. Modulet më të zakonshme të malware përfshijnë TitanService, BwmService, AdtimeService, lb102Service, dhe LinkfogService(ndonjëherë të quajtura AgentService). Diskutimi i këtyre dhe moduleve të tjera mund të gjendet në seksionin e moduleve të monetizimit.

Operatorët e programeve keqdashëse zbatojnë një numër mekanizmash për të vendosur qëndrueshmëri dhe për të penguar zbulimin dhe analizën.

Si një parangarkesë sistemi, x.cpenuk mund të hiqet nga përdoruesi. Nëse x.cpeçinstalohet nga /data/app/, pas rinisjes x.cpeshërbimi BootReceiverndjek të njëjtën rutinë të përshkruar më sipër dhe e riinstalon paketën.

“Backdoor” është në gjendje të shkarkojë në heshtje skedarë shtesë në pajisje dhe t’i ekzekutojë ato pa pëlqimin e përdoruesit, sepse së pari fshin konfigurimin e pëlqimit të përdoruesit në pajisje dhe më pas çaktivizon Google Play Protect.

Në shumë variante të com.abc.nexus,vumë re nxjerrjen e një programi të sofistikuar anti-analizë dhe forcimi të proceseve libseccomp_guard.so, i cili funksionon para inicializimit të moduleve të malware-it, për të siguruar që ato të mbeten të mbrojtura nga sandbox-et automatike dhe instrumentet e sigurisë. Ai filtron thirrjet e sistemit për të parandaluar ndalimin ose ndërprerjen e fijeve individuale, mohon ndërhyrjen ndër-proces për të siguruar izolimin dhe parandalon krijimin e proceseve fëmijë.

Që nga gushti i vitit 2026, paketa të reja dropper janë instaluar nëpërmjet kanalit MQTT, të cilat duket se janë të sinkronizuara me çinstalimin masiv të com.abc.nexusnë të gjithë botnetin. Ne vlerësojmë se kjo mund të përfaqësojë një evolucion të ri të malware-it për të shmangur më tej zbulimin. Këto paketa të reja janë të maskuara si aplikacione të sistemit Android, me emra të tillë si com.android.system.ntpdhe com.android.sso.auth.handler. Ku com.abc.nexusmund të veprojë si një ngarkues dhe motor ekzekutimi për qëllime të përgjithshme (duke ekzekutuar udhëzimet që i kalohen nga x.cpe), këto paketa në vend të kësaj instalojnë module të vetme monetizimi (si AppSalt). Variante të shumëfishta të këtyre paketave nxjerrin një skedar ELF vendas, libexploit.so, i cili nga ana tjetër ekzekuton funksionet nativeAdbRoot()dhe nativeAdbShell(). Këto funksione rinisin adbdshërbimin lokal si root dhe fillojnë një lidhje shell ADB. Pas kësaj, aplikacioni përdor lidhjen për t’u instaluar në systemndarje. systemNdarja rimontohet si lexim-shkrim dhe ngarkesa replikohet në një drejtori të sapokrijuar në /system/priv-app/dhe krijon një skedar XML në /system/etc/permissions/privapp-permissions-.xml. Ky skedar jep malware-in android.permission.INSTALL_PACKAGESdhe android.permission.REBOOT.

Aplikacioni konfiguron modulet e programeve keqdashëse përmes parametrave të konfigurimit të koduar në mënyrë të ngurtë dhe nuk dëgjon x.cpemesazhe IPC. Vetë aplikacioni kontrollohet nga operatorët përmes skripteve të shell-it të shtyra përmes ndërmjetësit dhe të ekzekutuara nga x.cpe. Këto përfshijnë vendosjen e vetisë persist.networkstack.uninstall(e cila, kur lexohet nga aplikacioni, shkakton çinstalimin dhe pastrimin), persist.networkstack.skip_system_install(e cila anashkalon instalimin e sistemit, duke e detyruar atë të vazhdojë të funksionojë në /data/app/) dhe persist.networkstack.install_time(e cila zbaton timestomping, duke anashkaluar timestamp-in e parazgjedhur të aplikacionit për t’u lidhur me paketat e tjera të instaluara në systemdrejtori).

Botneti është i shpërndarë globalisht, me përqendrime të caktuara që ndoshta nënkuptojnë depërtim në treg për distributorin e markës.

Ndërsa shumica dërrmuese e pajisjeve të infektuara në botnetin XCPE janë dekoderë Android TV, ne vumë re një numër pajisjesh të tjera të infektuara IoT të bazuara në Android, duke përfshirë pajisje tele-shëndetësore, makina karaoke dhe pajisje sinjalistike dixhitale.

x.cpengarkon një sërë modulesh keqdashëse për fitim parash. Më shpesh modulet shoqërohen me shërbime proxy rezidenciale dhe ndarje të bandwidth-it, por kemi vërejtur edhe module mashtrimi me reklamat. Duke pasur parasysh që një pajisje e vetme mund të ekzekutojë module të shumëfishta që ofrojnë të njëjtën funksionalitet ose të ngjashëm (p.sh., deri në tre SDK proxy rezidenciale të instaluara në një pajisje të vetme), është e qartë se Videostrong kërkon të fitojë para nga çdo pajisje e infektuar në masën më të madhe të mundshme.

Shërbimet ngarkohen me com.abc.nexusanë të tre metodave:

Daemonët vendas : Skedarët binare ELF vendas të paketuar paraprakisht me com.abc.nexus, të cilët çpaketohen në drejtoritë e të dhënave dhe krijohen si procese në sfond me privilegje sistemi/rrënjë.

SDK-të / Shërbimet e Integruara : SDK-të Java/Kotlin të kompiluara direkt në Nexus dhe të thirrura nëpërmjet cikleve të jetës së Shërbimit Android ose shkaktarëve të transmetimit IPC.

Instaluesit Dinamë të Shkarkimit dhe APK-ve Sekondarë : Funksioni i Shkarkuesit që tërheq ELF-të vendase të largëta ose APK-të dytësore të pavarura dhe thirr menaxherët e paketave të sistemit. Nexus merr mesazhe nga x.cpedrejtimi i tij për të shkarkuar module specifike.

Modulet e malware-it të ngarkuara përmes derës së pasme përfshijnë si në vijim:

Com.abc.nexus’s LinkfogServicezbulon një skedar binar Go të emëruar lw_android_agent nga assets/në hapësirën ruajtëse lokale të aplikacionit dhe e furnizon atë me parametrat e shitësit. Ky shërbim i shndërron në heshtje pajisjet e infektuara në nyje dalëse të informatikës kufitare rezidenciale dhe PCDN. Ai lidhet me tunelet e kundërta FRP dhe ngarkon metrikat e llogaritjes së bandwidth-it në backend-et e Linkfog API. Linkfog (i operuar nga Beijing Linkfog Technology nëpërmjet 点心云 / Dianxinyun) e quan veten një “Rrjet i Dorëzimit të Përmbajtjes Peer-to-Peer”.

Ekstraktet nga . Skedari është një skedar binar ELF 32-bit i pa-turbulluar i shkruar në C, i kompiluar si një skedar binar nativ Android. Ai përdor JNI (Java Native Interface) për të inicializuar rutinat e tij kryesore, nxjerr dinamikisht një çelës dekriptimi ChaCha20 nëpërmjet udhëzimeve ARM NEON SIMD për të dekoduar konfigurime shumë të turbullta dhe krijon një kanal C2 të enkriptuar. Pas regjistrimit të suksesshëm, C2 përgjigjet me konfigurimin JSON që specifikon pikat fundore të proxy-t. Cikli i komandës proxy delegon operacionet e proxy-t bazuar në komandat hyrëse të variablave JSON dhe është i aftë të përdorë si transmetimin TCP ashtu edhe UDP. com.abc.nexus AdtimeService libjaguar.soassets/x_ctrl_do_ctrl_msg

AppSalt SDK është SDK-ja proxy rezidenciale në pronësi të Honeygain, e cila nga ana tjetër është në pronësi të Oxylabs. com.abc.nexus.service.CoreServiceinicializon Appsalt SDK. Së pari, aplikacioni merr një çelës API të SDK-së së Appsalt nga një bibliotekë vendase libnative_keys.soduke thirrur getAppsaltKey()funksionin e saj. Appsalt SDK inicializohet pa shfaqur një ekran pëlqimi – në vend të kësaj, ai thërret në mënyrë eksplicite optIn()metodën e cila vendos një flamur pëlqimi pa shfaqur ndonjë ndërfaqe përdoruesi. Gjatë nisjes së Appsalt SDK, ai kontrollon burimin e instalimit të aplikacionit dhe ndalon ekzekutimin nëse aplikacioni është instaluar nga Dyqani zyrtar i Google Play.

Pasi Appsalt të inicializohet me sukses, ai krijon një lidhje WebSocket me domenin kryesor të komandës dhe kontrollit. Appsalt përdor mesazhe të formatuara në JSON për regjistrimin fillestar dhe kërkesat e rrahjeve të zemrës. Serverët e komandës dhe kontrollit Appsalt përdorin mesazhe të formatuara në MessagePack për të lëshuar komanda që kanë të bëjnë me operacionet proxy. Appsalt SDK është konfiguruar me një grup fillestar domenesh që veprojnë si porta proxy. Lista e portave proxy mund të përditësohet nga serveri i komandës dhe kontrollit. Pajisja krijon lidhje UDP / QUIC me këto porta.

Ky proxy rezidencial dhe nyje për ndarjen e bandwidth-it zbatohet përmes com.abc.nexus.service.BwmServicekomponentit (ndonjëherë i emëruar) com.abc.nexus.service.SN4Service)dhe SDK-së së tij të shoqëruar. Pas inicializimit, ai sigurohet brenda një mjedisi të izoluar sandbox, kap telemetrinë e pajisjes dhe regjistrohet me një server të largët përmes UDP. Nga ky C2, ai merr udhëzime për të filluar një tunel proxy të multipleksuar Java NIO TCP. Shërbimi funksionon për të drejtuar trafikun arbitrar përmes pajisjes së infektuar në emër të një aktori kërcënimi të largët.

GaGaNode është SDK e palës së parë në pronësi të operatorit rezidencial të proxy-t IPCola. Ai lidhet nëpërmjet TCP me një server primar C2 dhe dërgon të dhëna të sinjalit të zemrës nëpërmjet HTTP POST në një server të veçantë. SDK përmban funksionalitetin e vet të relesë së proxy-t dhe inicializon SDK shtesë të proxy-t nga bashkëpunëtorët. Pas regjistrimit të pajisjes në C2, com.gaganode.sdk.node.endpoint.amerr paketa hyrëse nga serverat e relesë dhe i vendos ato në radhë që klienti t’i lexojë dhe t’i proxy-tojë përmes soketit të nyjes së daljes. Shërbimi menaxhon seanca të shumta proxy në të njëjtën kohë (të referuara si klientë), dhe secili klient ka radhën e vet tcp/udp për mesazhet.

Ne vërejmë që GaGaNode inicializon SDK-të e proxy-ve rezidencialë të PopaNet/NetNut dhe EarnFM Fleet. Kështu, GaGaNode/IPCola ka të ngjarë të jetë në gjendje të fitojë më tej para nga SDK-ja e saj dhe t’u ofrojë këtyre bashkëpunëtorëve qasje në nyjet e daljes së infektuara.

Popanet është një SDK proxy për banesa i zhvilluar nga NetNut, një operator proxy për banesa. Moduli GaGaNode e inicion Popanet SDK ( io.popanet.Popa). Ky program keqdashës është identik me programimin keqdashës të përshkruar në ndërprerjen tonë të mëparshme të NetNut . E gjithë infrastruktura C2 e përdorur nga mostrat e Popanet me të cilat u lidhën x.cpeu çaktivizua si pjesë e ndërprerjes së mëparshme të Netnut.

SDK-ja e Traffmonetizer inicializohet brenda shërbimit kryesor të sfondit com.abc.nexus.service.CoreService . Funksionimi i CoreService varet nga disponueshmëria e politikës JSON të ofruar nga dera e pasme XCPE nëpërmjet IPC. Përpara se të thirren metodat e inicializimit të SDK-së së Traffmonetizer, aplikacioni merr një çelës API të SDK-së së Traffmonetizer nga biblioteka vendase libnative_keys.soduke thirrur getTraffmonetizerKey()funksionin e saj.

Funksionaliteti i Traffmonetizer ndahet midis dy komponentëve ku SDK-ja e Android vepron si një makinë gjendjeje e cila trajton thirrjet kthyese të bibliotekës vendase përmes dispeçerëve të ngjarjeve asinkrone, ServiceBlocmonitoron përditësimet e statusit të lidhjes nga thirrjet kthyese vendase dhe monitoron ndryshimet e rrjetit Wi-Fi dhe të të dhënave celulare. ConnectivityBloc

Inicializimi dhe konfigurimi i bibliotekës vendase të Traffmonetizer pasohet nga një thirrje e baseClientStart()cila krijon një lidhje WebSocket me një server C2. Traffmonetizer përdor një lidhje të vetme WebSocket (TLS) me serverin e komandës dhe kontrollit për të shumëfishuar mesazhet e kontrollit dhe lidhjet e tuneluara (mbështet si TCP ashtu edhe UDP). Traffmonetizer gjithashtu mbështet tunelimin “Dërgimi i Përmbajtjes” i cili u lejon nyjeve të tunelojnë trafikun që kërkon shumë bandwidth.

EarnFM është një ofrues serveri proxy rezidencial, dhe Fleet SDK është SDK-ja e ofruesit që regjistron pajisjet si nyje dalëse në rrjetin proxy. Në com.abc.nexus, FleetSDK inicializohet nga com.gaganode.sdksiç u përmend më sipër. FleetSdk më pas ngarkon skedarin binar nativ libfleetshare.so.

FleetSDK krijon një lidhje të vazhdueshme WebSocket me serverin e tij kryesor C2 për drejtimin e trafikut arbitrar të rrjetit. Kornizat hyrëse të detyrave merren përmes kanalit WebSocket dhe përpunohen në një cikël të vazhdueshëm. Mesazhet përmbajnë komanda të strukturuara JSON që udhëzojnë daemon-in të lidhet me hostë specifikë të largët, me mbështetje si për TCP ashtu edhe për UDP.

Spirit është një derë e pasme dinamike për ngarkimin e kodit. Spirit përdor faza të shumëfishta. Ngarkesa e fazës së parë merr informacionin e pajisjes (harduerin, sistemin operativ dhe informacionin e prodhuesit/markës dhe gjeo-lokacionin), duke e postuar atë nëpërmjet HTTP në një server C2 të koduar fort, dhe merr një listë modulesh shtesë për t’u shkarkuar nga serveri. Faza e dytë komunikon me një server të veçantë dhe përdoret për caktimin e detyrave, sinkronizimin e konfigurimit, rikthimin e moduleve, rrahjet e zemrës dhe raportimin. Ne kemi vërejtur Spirit duke ngarkuar një sasi të konsiderueshme modulesh shtesë për monetizim nga malware, duke përfshirë disa nga familjet e ngarkuara tashmë direkt nga com.abc.nexus.

Moyu është një derë e pasme me 3 faza e vëzhguar më parë si pjesë e ndërmarrjes BadBox. Në x.cpepajisjet me derë të pasme, ne e vëzhguam atë të inicializuar nga com.abc.nexus.service.DevourService.Faza e parë është një dropper jashtë linje që rindërton dhe ngarkon një fazë të dytë të integruar. Faza e dytë pyet një përditësim C2 për të shkarkuar, deshifruar dhe ngarkuar fazën e tretë. Faza e tretë zbaton një derë të pasme me mashtrim të fshehur të klikimit/konvertimit Double-WebView, rrëmbim të vazhdueshëm të clipboard-it dhe ekzekutim sekondar të ngarkuar dinamikisht JAR dhe një trojan të veçantë rezidencial proxy.

Bird është një derë e pasme me 2 faza, e lidhur më parë me ndërmarrjen BadBox. Faza 1 sinjalizon një profil të pajisjes dhe mjedisit të analizës në serverin e tij C2 dhe, kur serveri miraton, shkarkon, deshifron dhe ngarkon JAR-in e Fazës 2. Faza 2 zbaton një derë të pasme dinamike të ngarkimit të kodit (dy ngarkues plugin-esh plus një thirrës metode reflektuese të drejtuar nga C2), një shkarkues të veçantë (instalimi i heshtur i APK-së dhe instalimet e Google Play të drejtuara nga Aksesueshmëria) dhe abuzimi me reklamat (reklama në ekranin e bllokuar, mbivendosje, nisje të shfletuesit).

Fission është një derë e pasme për ngarkim dinamik të kodit (DCL) e integruar brenda aplikacioneve standarde video (p.sh., com.newtv.cboxtv). Pas inicializimit, shtojca e fazës së parë kontakton serverin e saj C2 për të shkarkuar module shtesë. Ngarkesa e deshifruar e fazës së dytë merr objektivat e ekzekutimit dhe URL-të e gjurmimit nga C2. Kërkesa dërgon një kërkesë POST të pakriptuar me metrika gjurmimi nga të brendshmet.DeviceManager.

Ngarkesa që vëzhguam ishte konfiguruar për të kryer mashtrim me reklamat. Në vend që të shfaqë reklama të dukshme në një WebViewkomponent të UI-së, shtojca e Fazës 2 ekzekutohet pa kokë në sfond. Moduli pyet pikat fundore të serverit të reklamave në sfond për të marrë përgjigjet e vendosjes së reklamave, analizon si sinjalizuesit kryesorë të përshtypjeve ( pvm) ashtu edhe URL-të e monitoruesve të ndjekjes së palëve të treta ( pvtpm), dhe menjëherë dërgon kërkesa HTTP GET në secilën pikë fundore të ndjekjes për të regjistruar një pamje të rreme të reklamës pa shfaqur përmbajtje krijuese. Kur ekzekutohet brenda dyqaneve specifike të aplikacioneve smart-TV ( ose ), shtojca inicializon dhe aktivizon SDK-në e reklamave direkt për të raportuar ekspozimet ndaj reklamave sintetike. com.changhong.appstorecom.tcl.appmarket2.