BaoLoader shows how code-signing trust is abused at scale

At a glance

What this is: Expel's analysis shows BaoLoader abusing at least 26 code-signing certificates over seven years to make unwanted software appear legitimate.

Why it matters: This matters because certificate trust, signing reputation and software provenance are now part of the control surface defenders must govern across application, endpoint and identity-adjacent security.

Context

Code-signing is a trust mechanism, not a quality signal. When threat actors can repeatedly obtain and rotate certificates for different shell companies, the security problem shifts from malware detection to provenance governance and the controls that decide what the platform is willing to trust.

This article sits at the intersection of software supply chain abuse and identity-like trust assertions. The certificate becomes the portable identity of the software publisher, so weak business verification, poor revocation handling and inconsistent allow-listing can all be turned into an operational advantage by attackers.

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. A certificate can only confirm that a file was signed by a trusted issuer, not that the signer is honest or the software is safe. Defenders need provenance checks, issuer review and behavioural validation alongside signature verification.

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. Similar signer names, issuer churn and revocation replacements can reveal a campaign cluster even when hashes and filenames change. That makes certificate metadata useful for hunting, attribution support and policy enforcement.

Q: What should teams do when signed software behaves like a PUP?

A: Treat it as a trust anomaly, not just a nuisance. Investigate the signer identity, the installer lineage and the application behaviour, then decide whether policy should block, quarantine or monitor it. PUPs often expose the same provenance weaknesses that malware relies on, so the response should be governed accordingly.

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.

Technical breakdown

How code-signing trust is established and abused

Code-signing relies on a chain of trust. A certificate authority vouches for the signer, the operating system checks that the file hash matches the signed hash, and users or security tools often treat that result as evidence of legitimacy. Attackers exploit that trust by creating or impersonating businesses to obtain certificates, then using them to sign unwanted or malicious software. In this case, the certificate is not the malware itself, but the trust wrapper that helps it survive scrutiny long enough to execute or be installed. The failure is not cryptography. The failure is weak assurance around who is allowed to hold that cryptographic trust.

Practical implication: treat signed binaries as trusted only after provenance and business-identity validation, not because the signature verifies.

Why repeated certificate patterns matter for hunting

Repeated use of certificates from the same company name, geography or issuer combination can reveal an operator cluster even when file names and hashes change. That is because code-signing abuse creates a durable behavioural fingerprint across campaigns. Expel's analysis shows how certificate reuse, unusual signer-name repetition and post-revocation replacement can connect seemingly different installers and PUPs back to the same actors. For defenders, that means certificate metadata is not just compliance artefact, it is huntable telemetry. The useful question is whether the signed software, the signer identity and the distribution pattern line up cleanly.

Practical implication: build hunts around signer names, issuer changes and revocation replacements, not only around file hashes.

Why PUP classifications can hide a governance problem

Potentially unwanted programs sit in a grey zone between user nuisance and overt malware, which makes them easier to dismiss than they should be. BaoLoader shows why that is dangerous: the same signing infrastructure can be used to deliver software that looks permissible while still creating backdoor, distribution or persistence risk. The governance gap is accepting a binary notion of 'malicious' versus 'benign' when the real issue is whether software provenance, distribution path and installed behaviour are consistent with policy. In practice, PUP handling needs the same provenance discipline as clearly malicious software.

Practical implication: classify unwanted software by provenance and behaviour, then enforce policy controls before users can install it.

Threat narrative

Attacker objective: The objective is to distribute unwanted or malicious software under a legitimate-looking trust envelope so it can install and persist with less resistance.

1. Entry begins when operators obtain or reuse code-signing certificates through shell companies that present as legitimate software businesses.
2. Credentialed trust is then abused when the signed installers carry PUP-labeled software that appears authentic to operating systems and users.
3. Impact occurs when the trusted signature helps unwanted software spread, evade suspicion and remain viable across multiple campaigns despite revocations.

Breaches seen in the wild

• GitHub code signing certificate theft 2022: A machine account's compromised token cloned GitHub's Desktop and Atom repos, exposing encrypted signing certificates later revoked.
• Sisense breach 2024: A credential in Sisense's GitLab reportedly opened S3 buckets of customer tokens, passwords and certificates; CISA urged a full reset.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

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.

Certificate metadata now functions like identity telemetry for software publishers. Repeated company names, jurisdiction patterns, issuer switching and revocation churn expose operator behaviour even when malware families rename themselves. That makes certificate analysis useful for attribution-lite hunting and for separating nuisance software from a coordinated distribution operation. Practitioners should treat signer identity, not just binary content, as an enrichment source in detection workflows.

Provenance controls matter more than label debates. Whether software is called a PUP, adware or malware, the control question is the same: was the publisher identity credible, was the signing path legitimate, and does the installed behaviour match the declared purpose? That is the kind of question that security policy can enforce and procurement can support. The operational lesson is to govern trust assertions, not just the executable file.

Identity assurance for software publishers needs stronger lifecycle controls. BaoLoader's repeated reappearance after revocations suggests that issuer-side checks alone do not close the gap. The real weakness is the absence of durable offboarding and re-verification across repeated certificate requests tied to the same actor pattern. Security teams should expect code-signing abuse to behave like a lifecycle failure, not a one-off fraud event.

From our research library:

• 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.
• Read next: Machine Identity, PKI and Certificate Lifecycle Guide

What this signals

Code-signing trust drift: the more often attackers can recreate publisher identities, the more your allow-listing and reputation controls need to follow certificate lineage rather than binary names. That shifts software trust from a static approval model to an identity and provenance model, which is where defenders should focus their telemetry and policy.

For identity and supply-chain programmes, the useful control question is no longer whether a binary is signed. It is whether the signing identity can be tied to a verifiable business, whether revocation is operationalised, and whether the installed behaviour matches the declared publisher purpose.

For practitioners

• 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.
• Tighten certificate issuance review Push procurement, legal and security teams to scrutinise unfamiliar software publishers, shell-company patterns and abnormal certificate reissuance before trust is granted.

Key takeaways

• BaoLoader shows that code-signing abuse is a trust lifecycle problem, not only a malware classification problem.
• Repeated certificate reuse and issuer churn give defenders a huntable pattern even when filenames and hashes change.
• Provenance checks, certificate lineage monitoring and application control are the controls most likely to limit this abuse.

Key terms

• Code Signing Certificate: A code signing certificate is a digital credential used to prove that software came from a trusted publisher and has not been altered. In identity terms, it is a non-human identity that authorizes release activity, and its value depends on lifecycle control, key custody, and revocation discipline.
• PUP: A potentially unwanted program is software that may be installed intentionally or bundled with other software, but whose behaviour creates security, privacy or operational risk. PUPs often exploit user consent gaps and trust assumptions rather than obvious malware techniques.
• Software provenance: Software provenance is the evidence that shows where an artifact came from, who created it, and whether it was altered before use. For security teams, it means signed releases, controlled build paths, and verification steps that reduce the chance of trusted software carrying hidden malicious changes.
• Certificate Revocation List: A Certificate Revocation List is a signed publication from a certificate authority that lists certificates that are no longer trusted before their natural expiry. It is used by relying systems to confirm current status, and it becomes operationally useful only when the list is reachable, current, and readable by the consuming toolchain.

Deepen your knowledge

NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, human identity, and secrets management for practitioners who need to connect trust, lifecycle and access control. It is designed for security teams that need a clear operating model for identity security across modern environments.