BaoLoader shows how code-signing trust is abused at scale

At a glance

What this is: This is Expel’s analysis of BaoLoader, a long-running operation that abused code-signing certificates to make unwanted software appear trusted.

Why it matters: It matters because code-signing trust, software reputation, and application control now intersect with identity governance for software publishers and the controls that validate what runs in the enterprise.

By the numbers:

• The average estimated time to remediate a leaked secret is 27 days, despite 75% of organisations expressing strong confidence in their secrets management capabilities.
• 53% of organisations have experienced a security incident directly related to machine identity management failures.
• 214 days.
• 57% of organisations lack a complete inventory of their machine identities.

👉 Read Expel's analysis of BaoLoader and code-signing certificate abuse

Context

Code-signing creates a trust boundary between software publishers, certificate authorities, and endpoint controls. When attackers can obtain or reuse certificates under fabricated business identities, the issue is not only malware delivery, but also the collapse of the assurance model that defenders rely on for software validation and allowlisting.

BaoLoader sits in that trust gap. Expel’s analysis shows how the operators used certificate identity, software branding, and installer naming to make unwanted software look legitimate, which is relevant to application control, software supply chain review, and the governance of publisher identities behind signed binaries.

Key questions

Q: How should security teams respond when signed software looks legitimate but behaves like unwanted software?

A: Treat the signature as one control signal, not proof of trust. Validate the publisher’s identity, certificate lineage, revocation status, and product history before allowing execution. If the software is a PUP or bundled installer, require deeper provenance review and endpoint control exceptions should be narrow, time-bound, and tied to a named business owner.

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. If attackers can create thin businesses or inconsistent records, they can buy trust from certificate authorities while still delivering unwanted or malicious software. The technical signature remains valid, but the identity behind it no longer supports the confidence defenders expect.

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. When those signals cluster, the issue is often not a single suspicious binary but a repeatable trust-abuse operation that can be hunted and blocked at the identity and policy layer.

Q: What should organisations do when allowlisted software starts arriving through suspicious distribution channels?

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.

Technical breakdown

How code-signing trust is abused to legitimize unwanted software

Code-signing is meant to prove that a file came from a known publisher and has not been altered after signing. The trust chain runs from the operating system to a certificate authority and then to the signer’s certificate. Attackers abuse that chain by creating or impersonating businesses, obtaining certificates, and using them to sign software that appears normal to users and some security controls. The validation logic still works technically, but the identity behind the signature is fraudulent or misleading.

Practical implication: security teams should treat signer identity as a control surface, not just a file property.

Why certificate patterns reveal clustered operator activity

BaoLoader’s value to defenders is not only the signed binary itself, but the repeated certificate patterns behind it. Reuse of the same business names across different certificate authorities, repeated geographic patterns, and similar installer naming all suggest a coordinated operation rather than isolated resale. Certificate metadata becomes an investigation source, especially when the same signer name appears across multiple issuers or when the business details are thin and inconsistent.

Practical implication: hunt for signer reuse, issuer churn, and business identity inconsistencies across signed files.

Why PUP labels can hide a broader trust and abuse problem

Potentially unwanted program is a usefulness label, not a full security assessment. A PUP may still install persistence, alter browser behavior, or act as a loader for additional code, and the presence of a valid signature does not reduce the need to inspect runtime behavior and provenance. In cases like BaoLoader, the operational concern is not only whether the binary is malicious in isolation, but whether its distribution model depends on manipulated trust.

Practical implication: do not let a PUP classification suppress certificate provenance review or application control decisions.

Threat narrative

Attacker objective: The objective is to make unwanted software execute with the credibility of legitimate publisher trust, increasing installation success and reducing user and control resistance.

1. Entry begins when users download signed installers that appear legitimate because they are backed by abused code-signing certificates and familiar software branding.
2. Escalation occurs when the signed installer executes with enough trust to drop additional components, load helper DLLs, or install bundled software such as Web Companion.
3. Impact follows when the trusted-looking package normalises unwanted software on endpoints and creates a durable foothold for further abuse or monetisation.

Breaches seen in the wild

• Sisense breach — unauthorized GitLab access led to exfiltration of access tokens, API keys and certificates.
• MITRE ATT&CK Enterprise Matrix — MITRE ATT&CK Enterprise — adversary tactics and techniques, threat detection, attack chain mapping, credential access, lateral movement, privilege escalation.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

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.

Code-signing certificate abuse is a publisher-identity problem with NHI parallels. The businesses used to obtain certificates behave like service identities for software distribution, because they are created, used, and discarded to support repeated trust establishment. That makes this a useful analogue for NHI governance, where identity creation without lifecycle oversight produces persistent trust risk. For security teams, identity lifecycle controls should extend to software publisher identities and signing authorities.

PUPs should not be treated as low-risk by default when signing patterns show coordinated abuse. A label that sounds operationally minor can obscure a serious trust-abuse campaign, especially when the same operators repeatedly cycle certificates across jurisdictions and issuers. The important question is not the label attached by antivirus tooling, but whether the distribution chain is engineered to exploit trust. For practitioners, reputation scoring must be paired with provenance checks and application control.

Certificate clustering is the named concept defenders should operationalise. Repeated signer names, issuer variation, and thin company records together create a visible pattern that can be hunted and governed. In BaoLoader, that clustering is what exposes continuity across campaigns and differentiates the operation from one-off abuse. For practitioners, certificate clustering should become a threat-hunting and policy-enforcement signal.

Application control is more effective when it incorporates signer identity review. Allowlisting and blocking decisions are often made on file names or hashes alone, but this case shows how quickly those indicators can be rotated. Identity-aware controls around publishers, certificates, and revocation status make it harder for trusted-looking unwanted software to enter the environment. For practitioners, the control boundary belongs at signer identity, not just file reputation.

From our research:

• 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.
• Forward pivot: For related governance context, see Ultimate Guide to NHIs , What are Non-Human Identities for how identity inventories shape control decisions.

What this signals

Certificate provenance should be treated as part of the enterprise identity perimeter. When software trust is anchored in publisher identity, weak business verification becomes a control gap that can be exploited repeatedly. Teams that already govern non-human identities should extend that discipline to software publishers, certificate issuance, and revocation monitoring.

The operational signal is that allowlisting alone is not enough when attacker-controlled software can be signed by a seemingly valid publisher. Security programmes need controls that join binary reputation, publisher identity, and installation context before execution is normalised.

Certificate clustering: repeated signer names, thin company records, and issuer switching are the practical pattern to watch. That signal is most valuable when paired with application control and provenance review, because the trust decision happens before malware detection has a chance to help.

For practitioners

• 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. Focus on installers that users commonly seek out for productivity tasks, because those are the easiest to disguise.
• 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. The goal is to surface coordinated certificate acquisition, not just single-file malware.
• 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. This is especially useful where installers masquerade as PDF tools or other common utilities.
• Reassess PUP handling in endpoint policy Treat PUP-classified software as a trust and provenance problem when it arrives with signed installers, bundled components, or suspicious parent-child process chains. That makes review mandatory before the software is normalised across the estate.

Key takeaways

• BaoLoader shows that code-signing trust can be weaponised even when the file signature validates correctly.
• The operational evidence is the repeated reuse of at least 26 certificates across seven years, which points to a sustained trust-abuse model rather than isolated misuse.
• Defenders should govern publisher identity and certificate provenance with the same seriousness they apply to other high-risk identities.

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.
• Publisher Provenance: The evidence that shows who actually created, signed, and distributed a piece of software. In practice, provenance combines certificate lineage, business identity records, issuer history, and distribution context to help defenders decide whether a signed file deserves trust.
• Potentially Unwanted Program: Software that may be technically functional but is considered undesirable because of its installation method, user impact, or bundled behaviour. A PUP label does not mean low risk, especially when the software is distributed through manipulated trust chains or suspicious installer patterns.
• Certificate Clustering: A defensive analysis technique that groups signed binaries by shared signer names, issuers, geographic records, and naming patterns. Clustering helps reveal coordinated abuse campaigns that would otherwise look like separate downloads or unrelated publisher identities.

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

👉 The full Expel post covers certificate clustering, file lineage, and the campaign distinctions behind BaoLoader.

Deepen your knowledge

The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, and secrets management. It helps practitioners connect identity controls to the broader security programme they are responsible for.