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.
Editorial analysis by NHI Mgmt Group, based on content published by Expel: “The history of AppSuite: the certs of the BaoLoader developer”.
Key questions
Q: Where does code-signing trust fail in practice when attackers abuse certificates?
A: It fails when organisations treat a valid signature as proof of benign intent.
Q: Why do repeated certificate issuances matter for threat hunting?
A: Repeated issuances create a behavioural pattern that links otherwise different installers to the same operator.
Q: What should teams do when signed software behaves like a PUP?
A: Treat it as a trust anomaly, not just a nuisance.
Practitioner guidance
- Audit signed software by publisher identity Create detections that compare signer name, issuer and declared product metadata, then flag binaries where the trust wrapper does not match the software's behaviour or distribution path.
- Treat revocation as a hunt trigger When a certificate is revoked, search for sibling binaries signed by the same company name, related shell companies or the same installer lineage across endpoints and malware feeds.
- Enforce application control for PUP-prone software Use application allow-listing and executable reputation controls to block unsigned, newly signed or policy-violating installers before they reach users.
Bottom line: BaoLoader shows that code-signing abuse is a trust lifecycle problem, not only a malware classification problem.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
20/08/2026 6:42 pm
Code-signing trust has become a governance problem, not just a malware problem. When the certificate itself becomes the object of abuse, defenders are no longer dealing only with file reputation. They are dealing with a trust lifecycle that can be bought, transferred, revoked and reissued, often faster than security teams can update policy. The practical conclusion is that signing trust must be governed as an attack surface in its own right.
A few things that frame the scale:
- Only 44% of developers are reported to follow security best practices for secrets management, exposing a significant developer behaviour gap, according to the State of Secrets in AppSec.
A question worth separating out:
Q: How should organisations govern code signing certificates for software releases?
A: Treat code signing certificates as privileged identity assets. Define ownership, approval, renewal, and revocation workflows, and ensure certificate policy is enforced before software reaches distribution paths. The goal is to keep publisher identity, release governance, and trust decisions aligned so a signed package is also a verified one.
👉 Read our full editorial: BaoLoader shows how code-signing trust is abused at scale