GhostDesk moves persistence into Chrome, and your executable rules will not see it

Malwarebytes reports that a fake CCleaner installer, served from a site imitating the official CCleaner download page, patches Chrome's Security Extension manifest so that a spyware extension it calls GhostDesk loads every time the browser starts ^[1][2]. That matters because after the first executable runs, the thing that survives reboots is a modified JSON file and two JavaScript files inside a browser component, not a new binary or a new service.

The lure is a well-chosen one. CCleaner has more than 2 billion downloads worldwide, which makes it a durable pretext ^[3]. The fraudulent site, ccleanerwind[.]top, copies the official homepage and offers a "CCleaner Pro" button next to the normal download; according to Malwarebytes both buttons deliver the same malicious executable ^[2]. The file reuses CCleaner's icon and filename but carries version metadata matching no known release: internal name svc_it7p, original filename rt_mxk.exe ^[4]. Malwarebytes says it found further samples following the same svc_<4 random characters> and rt_<3 random characters>.exe pattern ^[5], and assesses that the PC-cleaner disguise is likely intended to make the malware's file and system activity look routine ^[6].

Execution is deliberately unremarkable. The dropper writes out a legitimate copy of cscript.exe and uses it to run a chain of scripts ^[7]. Those scripts query the registry for machine GUID, machine name and supported languages ^[8]; overwrite %AppData%\Microsoft\DriverStore\runtimebroker.dll with a reflexive loader for further payloads ^[9]; patch the Chrome Security Extension's manifest.json to declare a service worker (background.js) and a content script (content.js), both dropped into %LocalAppData%\cse ^[10]; and open a local WebSocket endpoint on 192.168.100.4:49727 that is upgraded to reach portliderongrade.duckdns[.]org:4444, sending a GET with a token and then taking keep-alive packets from the operator's server ^[11].

Count the on-disk artifacts in that chain and the detection problem is visible: two are portable executables, the initial installer and the replaced runtimebroker.dll, while three are a manifest edit and two scripts ^[1]. Controls keyed to new or unsigned executables have two chances to fire, both early. The part that persists gets none, because Chrome loads it as its own trusted component: background.js runs silently in the background whenever Chrome starts, and content.js runs as the main extension ^[12], with the two halves talking to each other over chrome.runtime.sendMessage and chrome.runtime.onMessage.addListener ^[13].

The capability set is the usual browser-resident theft. content.js buffers keystrokes typed into input fields and ships the buffer to background.js after two seconds of inactivity or a field change ^[14]; it listens for outgoing POST requests and submit events as a man-in-the-middle, screening forms for keywords tied to credentials, authentication tokens and financial data ^[15]; it watches clipboard paste events for cryptocurrency strings and substitutes a predefined value ^[16]; and it injects script elements into pages matching certain URL patterns ^[17]. background.js holds the configuration for all of it, including cryptocurrency addresses, injection rules and toggles for form capture and keylogging, and handles WebSocket exfiltration ^[18]. Malwarebytes summarises the result as credential theft, screenshot capture and keystroke logging ^[19]. Note that the clipboard swap is labelled cryptojacking in the writeup, though the behaviour described is address replacement rather than mining ^[2].

Worth watching: whether your tooling can detect in-place modification of browser components at all, since a manifest.json edit inside an existing extension directory is neither a new install nor a policy-visible extension ID. Specific artefacts to hunt are the %LocalAppData%\cse folder ^[10], writes to %AppData%\Microsoft\DriverStore\runtimebroker.dll ^[9], and egress to duckdns.org subdomains on port 4444 ^[11]. The handshake beginning on a private-range address, 192.168.100.4 ^[11][3], is a reminder that a WebSocket listener bound locally will not show up in perimeter logs until it is upgraded outbound. All of the above rests on a single vendor's analysis.