Notifications
Clear all
Topic starter
20/08/2026 6:08 pm
TL;DR: BaoLoader used at least 26 code-signing certificates over seven years to make PUP-labeled software look legitimate, and Expel ties AppSuite-PDF, PDF Editor, ManualFinder, PDFTools, PDFProSuite, and OneStart to the same operators. The pattern shows that code-signing abuse is not just a malware delivery detail, but a trust problem that defenders can use for hunting and policy enforcement.
NHIMG editorial — based on content published by Expel: BaoLoader and the long-running abuse of code-signing certificates
By the numbers:
- 53% of organisations have experienced a security incident directly related to machine identity management failures.
- Average time to detect a compromised machine identity: 214 days.
- 57% of organisations lack a complete inventory of their machine identities.
Questions worth separating out
A: Treat the signature as one control signal, not proof of trust.
Q: Why do code-signing certificates create a security risk when business identity is weak?
A: Because the trust model assumes the signer is a real, accountable publisher.
Q: How do defenders know if signed software is part of a coordinated abuse campaign?
A: Look for repeated signer names, changes in certificate issuers, similar installer naming patterns, and minimal business information across multiple files.
Practitioner guidance
- Inventory trusted publishers and signer chains Map which signed software is allowed in the environment, then record the certificate issuer, signer name, and revocation status for each trusted publisher.
- Create detections for certificate clustering Alert on repeated signer names across different issuers, thin company records, and abrupt shifts in country or registration data tied to signed binaries.
- Tie application control to publisher provenance Use allowlisting and execution control to block software whose signed file metadata does not match the expected publisher profile, business record, or product lineage.
What's in the full report
Expel's full blog covers the operational detail this post intentionally leaves for the source:
- Certificate-by-certificate mapping of the BaoLoader cluster across issuers, countries, and business identities
- File tables and hash examples that help analysts reproduce the clustering logic in their own environments
- The relationship between specific installers, bundled components, and downstream Web Companion behaviour
- Additional context on how the authors distinguish BaoLoader from Chromeloader and TamperedChef
👉 Read Expel's analysis of BaoLoader and code-signing certificate abuse →
Code-signing certificate abuse in BaoLoader: what teams miss?
Explore further
20/08/2026 6:42 pm
Certificate identity has become a governance issue, not just a malware artifact. BaoLoader shows that signed binaries can still be untrustworthy when the business identity behind the certificate is synthetic or manipulated. That means software trust decisions now depend on publisher identity quality, revocation discipline, and downstream allowlisting logic. For practitioners, certificate provenance deserves the same governance attention as other high-risk identities.
A few things that frame the scale:
- 53% of organisations have experienced a security incident directly related to machine identity management failures, according to The Critical Gaps in Machine Identity Management report.
- 57% of organisations lack a complete inventory of their machine identities, which makes certificate and workload governance harder to operationalise.
A question worth separating out:
A: Investigate the distribution path as aggressively as the binary itself. If a signed installer is delivered through adverts, bundled downloads, or misleading names, remove broad trust exceptions, verify the publisher’s history, and enforce application control based on provenance rather than file reputation alone.
👉 Read our full editorial: BaoLoader shows how code-signing trust is abused at scale
