Single DigiCert Certificate Ties 11 Trojanized Files Across Two 2345 Product Lines

One Certificate, Eleven Payloads: How a Single DigiCert Key Signed a Campaign Across Two Product Lines

Eleven Windows executables and DLLs, all bearing a currently valid DigiCert code-signing certificate issued to Shanghai 2345 Mobile Technology Co., Ltd., have been confirmed as part of an expanding trojanized software campaign that now spans two distinct 2345 product lines — the SafeCenter security suite and the HaoZip archiving utility — across two coordinated build events separated by twenty days. The signed-binary cohort, bound by a single certificate serial (0D 7E F8 80 11 79 BF 12 A7 46 6F 7D A5 B3 27 7A, valid through 2026-07-07), has grown to encompass a full modular payload suite whose core DLLs actively detect debug environments and employ long-sleep delays to exhaust sandbox timeouts — producing uniformly clean sandbox verdicts across every dynamic analysis run despite AV detection ratios ranging from 20 to 38 out of 76 engines. The combination of a valid certificate [T1553.002], layered anti-analysis measures [T1497], and payload delivery through the vendor's own Alibaba-backed CDN [T1071.001] constitutes a detection-evasion stack that defeats most automated pipelines simultaneously.

Earlier coverage established the foundational signed-binary pattern for the SafeCenter component set. This update documents the technique's application at scale, the addition of the HaoZip product line as a second delivery vehicle, and the appearance of a newly observed LZMA-compressed update package dated 2026-05-28 on the campaign's primary delivery domain — evidence that the operator is actively refreshing the channel in near-real-time.

The Certificate That Binds Eleven Files to a Single Operator

The analytical anchor for this campaign is a code-signing certificate issued by DigiCert Trusted G4 Code Signing RSA4096 SHA384 2021 CA1 to "Shanghai 2345 Mobile Technology Co., Ltd." The certificate serial 0D 7E F8 80 11 79 BF 12 A7 46 6F 7D A5 B3 27 7A, thumbprint AC3C08A55AB1F2700909A5B423DB4A35508D83B4, was valid from 2023-04-28 and does not expire until 2026-07-07. All eleven signed files in the current cohort carry this exact certificate in a confirmed-valid state. Because all eleven share a single private key, they were signed by the same controlling party in a single managed signing operation — the certificate was not stolen or shared across unrelated actors.

The certificate's longevity is operationally significant. A three-year code-signing certificate issued to a named Chinese software company and still showing "Valid" status provides a persistent trust anchor that suppresses Windows SmartScreen warnings and causes many AV heuristics to treat the binaries as legitimate software. The practical result is visible in the sandbox data: every signed DLL in the cohort returns zero malicious verdicts across all sandbox runs — 0/2 or 0/3 malicious — while simultaneously drawing detection ratios of 25 to 33 out of 76 engines from static analysis. The gap between static and dynamic detection is not coincidence; it is the designed outcome of combining a valid certificate with active anti-analysis code.

The eleven signed files span a size band from 973 KB (SdRTProtectUICtrl.dll) to 6,002 KB (WebProtect.dll) and cover both the SafeCenter suite (product string "2345安全卫士中心", version 8.30.0.13270) and the HaoZip archiver (product string "2345好压（HaoZip）", version 6.5.4.11267). The SafeCenter-branded DLLs — SdDefenceLogic.dll, SdGDOperate.dll, SdAntiVEngine.dll, WebProtect.dll, SdRTProtectUI.dll, SdRTProtectUICtrl.dll, SdRTPLog.dll, SdHipsLogic.dll, and SafeExpMon.dll — all carry PE timestamps of 2026-03-18, placing them in a single coordinated build event. HaoZipTool.exe and HaoZipWorker.exe carry PE timestamps of 2026-04-07, representing a second build wave twenty days later. The two-wave pattern is consistent with a staged rollout across product lines from a shared build environment.

Six additional unsigned executables — 2345InstDll.exe, 2345SafeCenterSvc.exe, 2345RTProtect.exe, 2345ScUpgrade.exe, 2345SFGuard64.exe, and 2345SafeCenterUpdate.exe — complete the deployment set, all carrying the copyright "版权所有 (c) 2023，2345.cc" and version 8.30.0.13270 with PE timestamps of 2026-03-18. These represent the installer, service host, real-time protection, updater, and guard components deployed alongside the signed DLLs. Every single file across all seventeen samples carries the "overlay" tag — data appended after the PE's last section, outside the region covered by the code-signing signature. This is a consistent build artefact across the entire set and may encode configuration data or secondary stage material that static analysis has not yet fully characterised.

The Anti-Analysis Stack: Why Sandboxes See Nothing

The most operationally consequential finding in this update is the layered anti-analysis implementation embedded in the signed DLLs. Five of the eleven signed files — SdDefenceLogic.dll (78eb6454), SdGDOperate.dll (56f4b083), SdAntiVEngine.dll (f331ccb5), WebProtect.dll (551ef09e), and SafeExpMon.dll (f3e78e04) — carry the "detect-debug-environment" tag, indicating active checks for analysis environments at runtime. SafeExpMon.dll additionally carries the "long-sleeps" tag: a technique in which the binary introduces extended delays before executing its primary logic, causing automated sandbox environments to time out and return a clean verdict before any malicious behaviour triggers.

The sandbox results confirm the technique is working. SdDefenceLogic.dll (33/76 on static analysis) returns 0/2 malicious across Zenbox and C2AE. SdGDOperate.dll (32/77 static) returns 0/2 malicious. SdAntiVEngine.dll (32/77 static) returns 0/2 malicious. WebProtect.dll (31/75 static) returns 0/2 malicious. SafeExpMon.dll (28/76 static) returns 0/3 malicious across Zenbox, SecondWrite, and C2AE — the most sandbox coverage of any file in the set, and still zero malicious verdicts. The pattern holds without exception: every file across all seventeen samples returns either CLEAN or UNKNOWN_VERDICT from every sandbox run.

This is not a marginal evasion advantage. Sandbox verdicts are a primary triage signal for many security operations workflows. A file that draws 33 static-analysis engine detections but returns clean from three independent sandboxes will frequently be deprioritised or cleared by automated triage pipelines. The operator has engineered the signed DLLs specifically to exploit this gap — combining the trust signal of a valid certificate with runtime evasion to produce a payload suite that defeats both the OS trust layer and the dynamic analysis layer simultaneously.

The build provenance of the signed DLLs shows additional consistency. SdDefenceLogic.dll carries imphash 6fb62fed3face10898262309eee9b94c; SdGDOperate.dll carries imphash d60d08ba708c976be38aa329b477f893; SdAntiVEngine.dll carries imphash 6427577159067be6a308bcd184484012. While these imphashes differ across the DLLs — reflecting their distinct functional roles — the shared PE timestamp, shared certificate, shared copyright string, and shared overlay pattern establish a common build pipeline. The .text section entropy across the signed DLLs ranges from 6.32 to 6.71, consistent with compiled but not heavily packed code; the evasion is behavioural rather than structural, which is why static entropy analysis does not flag these files as packed.

Embedded Resources and the HaoZip Cross-Product Link

Three files in the cohort present an additional anomaly that the YARA rule Adobe_XMP_Identifier surfaces across all three: SdRTProtectUI.dll (743d48b7), HaoZipTool.exe (14e48638), and HaoZipWorker.exe (ecfb01c2). The Adobe_XMP_Identifier rule, authored by InQuest Labs, identifies Adobe Extensible Metadata Platform identifiers embedded within files — XMP data used to track graphical asset relationships including parent-child provenance and individual revisions. The co-firing of this rule across one SafeCenter DLL and two HaoZip executables links the two product-line distribution channels to a common build pipeline and suggests shared graphical assets or embedded resources originating from the same development environment.

More striking than the YARA hit is the entropy profile of the .rsrc sections in these three files. SdRTProtectUI.dll carries a .rsrc section of 1,367,040 bytes at entropy 7.81 — near the theoretical maximum for random data, and anomalously high for a resource section that should contain icons, dialogs, and version strings. HaoZipTool.exe carries a .rsrc section of 92,160 bytes at entropy 7.68. HaoZipWorker.exe carries a .rsrc section of 81,920 bytes at entropy 7.56. Normal PE resource sections for GUI applications typically register entropy in the 4.5–6.0 range; values above 7.5 are consistent with compressed or encrypted content embedded within the resource data.

The combination of high-entropy .rsrc sections and PE overlay data in all three files raises the possibility that the resource sections contain embedded secondary payloads or configuration blobs that are not executed in the signed PE's primary code path — potentially loaded at runtime by a separate component or extracted by the installer. Static analysis has not yet characterised what these embedded resources contain, and the anti-analysis measures in the DLL layer prevent sandbox confirmation. This is an open triage question: the signed PE region is what DigiCert's certificate covers, but the high-entropy resource content and the overlay data appended after the last PE section sit outside that coverage.

HaoZipWorker.exe (ecfb01c2) is the most recently observed file in the entire set, with a first-submission date of 2026-05-29 — one day before CTX Team's analysis. Its detection ratio of 20/76 is among the lowest in the cohort, with engines including ALYac, APEX, Acronis, Alibaba, Antiy-AVL, Arcabit, BitDefender, Bkav, and CTX itself still missing it. The recency of this sample, combined with its HaoZip branding and the same certificate serial as the March build wave, confirms the operator is actively extending the campaign into the HaoZip user base rather than winding down.

Delivery Infrastructure: The CDN That Cannot Be Blocked

The payload delivery architecture for this campaign is built on a domain and CDN stack that makes network-layer interdiction structurally difficult. The domain download.2345cdn.com — registered 2019-08-29 via eName Technology Co., Ltd., with DNS delegated to ns1.alidns.com and ns2.alidns.com — resolves via CNAME to download.2345cdn.com.w.kunluncan.com, placing all file delivery on Alibaba's KunlunCAN CDN. The domain's TLS certificate (serial 54162008a7bf1ddb0a8b67fd81b4674af00924f7, issued 2026-01-13 by TrustAsia DV TLS RSA CA 2024) covers *.2345cdn.com and resolves to ten A-records across Shanghai and Hubei IP space.

The domain carries a detection ratio of 12/91 and a Cisco Umbrella rank of 998,133 as of 2026-03-17 — reflecting its dual use as a legitimate 2345 software update channel. This is precisely the operational logic: a domain that serves genuine software updates to a large installed base cannot be blocked at the network layer without disrupting legitimate 2345 product functionality. The operator has structured the campaign so that the malicious update packages travel on the same infrastructure, with the same TLS certificate, as the benign ones.

The URL paths observed on download.2345cdn.com make the dual-use explicit. The path /2345assist/haozip_assist_update_2.8.0.10552.dat is a HaoZip assist update package. The path /2345pcsafe_data/20260528/v1218/dp01.data.lzma — a versioned, LZMA-compressed data file with a path component dated 2026-05-28 — is a SafeCenter data package whose naming convention (versioned directory, .data.lzma extension) is consistent with a configuration or payload update channel being actively refreshed. The 2026-05-28 date in the path, combined with HaoZipWorker.exe's first-submission date of 2026-05-29, indicates the operator pushed a new payload update and a new signed binary within a 24-hour window — a tempo consistent with active campaign maintenance rather than a static deployment.

The 43 IP indicators introduced in this update are entirely explained by the Alibaba CDN infrastructure. All 20 dossier-covered IPs present the same TLS certificate: serial 6d417efa174c4fab5bafa7ae, issued by GlobalSign GCC R3 OV TLS CA 2024, subject *.alicdn.com (Alibaba China Technology Co., Ltd.), with SANs including *.alikunlun.com, *.mobgslb.tbcache.com, s.tbcdn.cn, and m.intl.taobao.com. These are Alibaba Cloud edge nodes, not attacker-controlled servers. Seventeen of the twenty fall within AS4837 (CHINA UNICOM China169 Backbone); the remaining three — 221.130.195.162 (AS9808, China Mobile Communications Group), 111.20.23.111 (AS140105, Shaanxi Mobile Communication Company Limited), and 111.6.67.52 (AS24445, Henan Mobile Communications Co., Ltd.) — are on China Mobile provincial networks, all still presenting the same Alibaba CDN certificate.

The sole network IOC with any active malicious signal is 221.130.195.162, which registers 2/91 detections and a reputation score of -1 — the only non-zero values in the entire IP pool. Even this outlier presents the Alibaba CDN wildcard certificate, suggesting its malicious signal may reflect prior abuse of the same CDN edge node rather than attacker-controlled infrastructure. Analysts should treat the IP list as CDN delivery infrastructure shared with legitimate Alibaba traffic; the domain and URL paths are the meaningful network indicators, not the IP addresses.

The Attack Chain: From Installer to Evasive Service Suite

The attack chain begins at download.2345cdn.com [T1071.001], where users of 2345 SafeCenter or HaoZip software receive trojanized update packages via the Alibaba KunlunCAN CDN. The earliest-observed file in the set, 2345InstDll.exe (b79098e3, first seen 2026-03-29, threat label adware.jaik/ad2345), functions as the installer component [T1203]. Its alt-names include a path referencing a malware collection bundle alongside the standard installation path under C:\Program Files (x86)\2345Soft\2345SafeCenter\8.30.0.13270, suggesting it was collected from a distribution environment before being submitted for analysis. Detection at 28/76 static engines, with 0/2 sandbox malicious verdicts, follows the same pattern as the rest of the set.

Once the installer executes, the payload suite is deployed as Windows services [T1569.002]. The service host executables — 2345SafeCenterSvc.exe (5b88b925) and 2345RTProtect.exe (8d04d2bc) — carry alt-names referencing installation paths across multiple drive letters (C:\Program Files (x86)\2345Soft\2345SafeCenter\8.30.0.13270, C:\Program Files\2345Soft..., D:\2345Soft..., D:\Program Files...), consistent with service-based persistence across varied enterprise disk configurations [T1543.003]. The "Svc" suffix on 2345SafeCenterSvc.exe and the "RTProtect" naming on 2345RTProtect.exe are consistent with Windows service registration patterns. This persistence inference is drawn from the naming and path evidence; no direct registry or sc.exe evidence is present in this data slice, so it should be treated as analytically supported but not confirmed.

The signed DLL suite is then loaded into the service process. Nine signed DLLs — SdDefenceLogic.dll, SdGDOperate.dll, SdAntiVEngine.dll, WebProtect.dll, SdRTProtectUI.dll, SdRTProtectUICtrl.dll, SdRTPLog.dll, SdHipsLogic.dll, and SafeExpMon.dll — are installed under the versioned path C:\Program Files (x86)\2345Soft\2345SafeCenter\8.30.0.13270. Their valid DigiCert certificate produces 0/2–0/3 sandbox malicious verdicts, confirming execution bypass of dynamic analysis controls. Defense evasion is then layered on top [T1497]: five of these DLLs check for debug environments at runtime, and SafeExpMon.dll introduces long-sleep delays that exhaust sandbox timeouts before any malicious logic triggers.

The update and command channel [T1071.001] runs back to download.2345cdn.com over HTTPS, with the TrustAsia DV TLS certificate covering *.2345cdn.com providing a valid TLS session that blends with legitimate software update traffic. The versioned URL paths — including the newly observed /2345pcsafe_data/20260528/v1218/dp01.data.lzma — indicate the operator is pushing configuration or payload updates through this channel on a near-daily basis. The LZMA compression of the data file is consistent with a compressed payload or configuration blob; its contents have not been extracted in this analysis.

The HaoZip wave follows the same structural pattern but targets a different user population. HaoZipTool.exe (14e48638) and HaoZipWorker.exe (ecfb01c2), both signed with the same certificate on 2026-04-07, are installed under C:\Users\Administrator\AppData\Roaming\HaoZip\Application\6.5.4.11267\ — a user-space path rather than a system-level Program Files location, which may reflect a different installation model for the HaoZip product. Both carry high-entropy .rsrc sections and the Adobe_XMP_Identifier YARA hit, linking them to the same build pipeline as SdRTProtectUI.dll despite the product-line difference.

The 64-Bit Outlier and an Anomalous YARA Signal

One file in the set stands apart from the cohort in ways that warrant dedicated triage: 2345SFGuard64.exe (4861ec8b). It is the only PE32+ (x86-64) executable in a set otherwise composed of 32-bit PE files. It is unsigned, unlike the eleven signed DLLs and EXEs. And it is the sole file in the entire set to trigger the YARA rule skip20_sqllang_hook.

The skip20_sqllang_hook rule, authored by Mathieu Tartare at ESET and published via the ESET malware-ioc repository, detects byte patterns corresponding to functions hooked by the Skip-2.0 malware — a tool documented as capable of bypassing SQL Server authentication by hooking sqllang.dll. The rule description notes that if the $1_0 or $1_1 patterns match, the targeted binary is probably a sqllang.dll version targeted for authentication bypass. The rule fires on 2345SFGuard64.exe, which carries a detection ratio of 31/76 and the threat label adware.ad2345.

CTX Team flags this as a medium-confidence finding that warrants priority triage. There are two plausible readings. The first is that the byte pattern overlap is coincidental — that 2345SFGuard64.exe contains code sequences that happen to match the hook patterns without implementing SQL Server authentication bypass. The second is that the 64-bit guard executable carries a secondary capability beyond adware, potentially including SQL Server lateral-movement or credential-bypass functionality. If the second reading is confirmed, it would substantially elevate the threat profile of this campaign beyond the adware/PUA classification that the rest of the file set supports.

The anomaly is reinforced by the file's other outlier characteristics. At 3,094 KB, it is the largest file in the unsigned cohort. Its PE machine type is 34404 (x86-64), while every other file in the set is 332 (x86). Its imphash (89fc557f925f579f70988c400eee5dbf) is unique within the set. And it is isolated in the cohort index — no shared imphash, signer, or threat label with peers. The combination of architectural uniqueness, unsigned status, and an anomalous YARA hit from a rule designed to detect SQL Server authentication bypass makes this the highest-priority unresolved question in the current data slice.

The second unsigned outlier worth noting is 2345SafeCenterUpdate.exe (d80edb9f), the smallest file in the set at 187 KB. Its detection ratio of 11/76 is the lowest in the cohort, and its threat label — adware.minipage — differs from the ad2345/chinad labels that dominate the rest of the set. Its minimal size and distinct family label suggest it may be a lightweight stub updater with a different code lineage, potentially sourced from a different component of the 2345 software ecosystem. It is isolated in the cohort index with no shared imphash, signer, or threat label with peers.

What a Still-Valid Certificate and an Active CDN Channel Signal About Operator Posture

The expansion from the initial SafeCenter component set to a 17-file suite spanning two product lines and two build waves — all bound by a single, still-valid DigiCert code-signing certificate — demonstrates that the operator has sustained access to the 2345 signing infrastructure and is actively iterating the toolset. The certificate does not expire until 2026-07-07. Unless DigiCert revokes it on the basis of abuse evidence, the signed-binary evasion advantage persists for the near term, and the operator can continue signing new payloads under the same trusted identity.

The operational tempo visible in the data — a first build wave on 2026-03-18, a second on 2026-04-07, a new LZMA-compressed update package dated 2026-05-28, and a new signed HaoZipWorker.exe submitted 2026-05-29 — is not consistent with a one-time deployment. It is consistent with a campaign under active development, with the operator pushing new components and update packages on a cadence of weeks to days. The CDN-backed delivery channel, refreshed with versioned path components that encode dates and version numbers, provides the operator with a high-availability, high-trust update mechanism that is structurally difficult to disrupt without affecting legitimate 2345 software users.

The industry detection picture reflects the difficulty. Across the 17-file set, detection ratios range from 11/76 to 38/76 on static analysis, but Microsoft Defender is absent from the flagging engines on the majority of files — a gap that matters given its prevalence in enterprise Windows environments. The engines that do flag consistently include CrowdStrike, Kaspersky, ESET-NOD32, Malwarebytes, SentinelOne, and Sophos, but coverage is uneven across the cohort. The signed DLLs with the most sophisticated anti-analysis implementations — SafeExpMon.dll, SdDefenceLogic.dll — draw fewer flagging engines than the unsigned executables, which is the expected outcome of the certificate trust suppression.

The structural question this campaign raises for the broader ecosystem is about the limits of code-signing as a trust signal. A certificate issued to a named, registered Chinese software company — a company with a real installed base of consumer products — provides a trust anchor that is difficult to invalidate without either revoking the certificate (requiring CA action) or treating all software from that vendor as suspect (requiring a policy decision that affects legitimate users). The operator appears to understand this constraint and has structured the campaign to exploit it: the signed components are the ones with the most sophisticated evasion, because those are the ones where the certificate trust signal provides the most operational value.

The anomalous skip20_sqllang_hook hit on the sole 64-bit executable is the signal that most changes the analytical calculus. If that finding is confirmed through deeper reverse engineering, it would indicate the campaign carries a capability — SQL Server authentication bypass — that is not consistent with financially motivated adware distribution and that would significantly expand the potential impact surface beyond the consumer endpoints that 2345 software primarily targets. The presence of a 64-bit guard executable in a set otherwise composed of 32-bit components, unsigned and architecturally isolated, is itself an indicator that the toolset may be more heterogeneous than the adware family labels suggest. That triage should be treated as urgent.