Skip to content
nulltapE-reader edition

← All e-reader articles

6 min read

Sogou's Link Handler Let UNC3569 Install GRAYRABBIT

A crafted Sogou URI reached an old, unsandboxed Chromium renderer. Verify the fixed build, then hunt the process, file, and network chain.

Read on the standard site

An opened keyboard keycap revealing a glowing browser pane inside

On September 10, 2026, security vendor Gen Digital Threat Labs disclosed that UNC3569 used a crafted sgbiz: link to make Sogou Input Method’s embedded browser execute a known Chromium exploit and install GRAYRABBIT. Windows teams with Sogou on endpoints should use this disclosure window to verify version 16.3.0.3498 or later and examine older systems for the published chain.

The evidence does not show a poisoned Sogou software update. The vulnerable path ran from a Windows custom URI handler through the skin marketplace’s browser. Tencent then used Sogou’s automatic updater to distribute the fix on April 21. Gen says the input method has hundreds of millions of installations, but neither primary report counts exposed endpoints or victims of this specific chain.

A handler supplied the browser

The exposed path began with a URI.

Sogou registers the sgbiz: scheme so Windows can send internal requests to biz_helper.exe. A request to sgbiz:sg_process names a Sogou module and supplies launch arguments in param. The handler checked the module name for forbidden path characters, resolved it beneath the Sogou installation directory, and confirmed that the file existed. It did not validate param before the patch.

UNC3569 used that asymmetry instead of launching an arbitrary binary. Its crafted link selected the legitimate SGMyInput.exe and supplied -page=skincenter -url=<attacker page>. The skincenter page is the route that creates a Chromium Embedded Framework webview. Once ready, that webview accepted the supplied URL without a scheme check or destination allowlist.

This distinction sets the exposure precisely. A clicked link could steer a trusted Sogou process to an attacker-selected page. The module validation still prevented the URI from directly naming an arbitrary executable.

Chromium delivered user-level execution

The renderer had no sandbox.

SGWebRender.exe loaded SGMiniBrowserHelperHost1.0.0.8.dll, which initialized CEF 80.1.16 and Chromium 80.0.3987.163. Sogou set CefSettings.no_sandbox to 1; it also enabled disable-web-security and allow-file-access-from-files. Gen found the flag behind those last two settings was hardcoded on, not exposed as a runtime option.

The observed page on noht1ng[.]top exploited CVE-2021-38003, a V8 type-confusion flaw fixed before Chrome 95.0.4638.69. The JavaScript corrupted V8 map structures, obtained heap read and write access, replaced a WebAssembly executable page with shellcode, and invoked the WebAssembly export. With no renderer sandbox to escape, the shellcode ran with the current user’s rights.

Even without that V8 exploit, Gen assessed that a page in this webview could issue authenticated requests to internal services and read the responses because the same-origin policy was disabled. The report does not establish that UNC3569 used that access in the observed intrusion.

Six stages show a crafted Sogou URI reaching its unsandboxed Chromium renderer, a V8 exploit, and the GRAYRABBIT payload. A separate patch lane shows validation stopping the attacker URL at the handler.

Figure details

Six equal cards show the published chain. A user opens a crafted `sgbiz:` URI and authorizes a browser pop-up; `biz_helper.exe` checks the module but passes an unchecked `param`; `SGMyInput.exe` opens the skin-center webview with `-url`; `SGWebRender.exe` runs Chromium `80.0.3987.163` with `no_sandbox=1`; `CVE-2021-38003` enables WebAssembly shellcode execution; and the download-and-sideload step installs GRAYRABBIT with `7z.exe` and `7z.dll`. A green lane below shows version `16.3.0.3498` parsing `-url` and `-firsturl`, requiring HTTPS and an approved hostname suffix, and stopping the published route before attacker content loads.

The exploit staged GRAYRABBIT

Execution moved into a DLL sideload chain.

The 921-byte shellcode downloaded three files from 8.218.50[.]207 into C:\Users\Public\Documents\: legitimate 7z.exe, a trojanized loader supplied as 7zp.dll, and an encrypted blob named p. On disk, the shellcode renamed the loader to 7z.dll beside 7z.exe, then ran:

c:\users\public\documents\7z.exe a c:\users\public\documents\p.7z c:\users\public\documents\p

That archive operation was a pretext for Windows DLL search behavior. Starting 7z.exe loaded the adjacent malicious 7z.dll. The loader counted running processes and produced the valid decryption key only on a system with at least 50 processes. It decrypted the payload into executable memory, ran it through Windows thread-pool APIs, and used an NTFS alternate data stream rename to remove its DLL from disk.

The final core.dll was an x64 GRAYRABBIT backdoor. It connected to mail.uaiubifas[.]top over raw TCP on port 443, not TLS, and encrypted fixed-size 4,096-byte frames with RC4 key m5b1u3. Its commands covered process execution, an interactive shell, system collection, file transfer, file upload, and reflective plugin loading.

Gen published three SHA-256 values for this intrusion:

  • 29c7ee41d0cc9e07d981e451df56d0c3d37c41ac4ec10c7b516cc033ee397a63 for 7zp.dll, the trojanized loader (boy.dll) saved to disk as 7z.dll
  • 749160a2f20f82744026719cf72e483595c6aad718efa74d675a98662e02422e for p, the encrypted PE loader shellcode
  • D7a3c7eb94edc0e020f74c678743d71d61e944634aade4a67a96c3589e828b3a for GRAYRABBIT (core.dll)

The remaining current-campaign network indicators are the exploit host noht1ng[.]top and staging address 8.218.50[.]207.

Tencent guarded the entry point

Tencent fixed the front door.

Gen reported CVE-2026-51990 on April 9. Tencent acknowledged it the next day and told Gen that version 16.3.0.3498 had reached all users through automatic update on April 21. Tencent called the chain “relatively complex” and said it required social engineering to make a user authorize a browser pop-up. That prompt is a material interaction requirement, although Gen still observed the chain in an active intrusion.

The patch is confined to biz_helper.exe. It identifies -url and -firsturl, accepts only HTTPS, lowercases the parsed hostname, and applies a suffix allowlist for sogou.com, qq.com, woa.com, and sogou. Gen later observed a browser-context module allowlist and a dangerous-argument blocklist as well.

The automatic update closes the published external route, according to Gen. It does not replace or sandbox the embedded browser. The patched SGWebRender.exe and helper DLL still contained the old CEF build, no_sandbox=1, disable-web-security, and allow-file-access-from-files. Gen’s direct description is blunt: the component remains “sandboxless and security-stripped.” The report recommends the latest Sogou version while also calling for more browser hardening.

Two reports cover different layers

The reports answer different questions.

The 2024 Virus Bulletin paper attributes GRAYRABBIT to UNC3569, documents use since November 2021, and describes the malware as a “lightweight and simple backdoor” for files, host collection, plugins, and a remote shell. It also establishes UNC3569’s pattern of exploiting known flaws, wrapping payloads in XOR-encoded shellcode, and using open-directory infrastructure in Hong Kong and Singapore.

That paper predates CVE-2026-51990 and is silent on Sogou, the sgbiz: route, the current exploit host, and Tencent’s fix. It said GRAYRABBIT had evolved little over the two years it examined. Gen describes the 2026 x64 sample as more mature, with a byte-operation-encoded C2 domain and an expanded command set. The time gap can explain both observations; the two sources do not establish when those changes entered the family.

The Virus Bulletin paper reports government, education, technology, and finance targeting worldwide, concentrated in East and Southeast Asia. Gen says its Sogou finding came from an active UNC3569 intrusion, but does not name the victim, sector, country, or count. Those wider historical targets should inform prioritization, not be presented as victims of this Sogou chain.

Check version, process, and traffic

Start with the installed Sogou version.

Confirm that managed Windows endpoints running Sogou Input Method report 16.3.0.3498 or later. An automatic-update declaration is not endpoint evidence: stale, offline, unmanaged, or failed-update systems can retain the vulnerable handler. Isolate an older installation from untrusted link handling until it is updated or removed.

For systems that ran an older build, query EDR process lineage for biz_helper.exe launching SGMyInput.exe with -page=skincenter and a -url argument, followed by SGWebRender.exe. Then look for 7z.exe, 7z.dll, or p under C:\Users\Public\Documents\, the published hashes, DNS for noht1ng[.]top or mail.uaiubifas[.]top, and raw TCP 443 to the latter. Proxy-only inspection can miss that C2 because the reported protocol is not HTTPS.

A useful verification test has two parts. Software inventory should return no Sogou build below 16.3.0.3498; EDR and network searches over the retained period should return no match for the process, file, hash, domain, address, or raw-TCP sequence above. Any match is compromise evidence to investigate, even if the endpoint has since updated, because the patch prevents the entry route and does not remove an implant already installed.

Primary sources