Forged Authenticode Across Go Loaders: A Possible Shared Signing Capability

Executive summary

During a sweep of the Filescan Community corpus, we identified the same forged Authenticode certificate profile across materially different Go loaders. The loaders have different implementations, network configurations, and associations with downstream malware, including activity related to Vidar, Lumma, Remus, and StealC.

This separation is the main finding of this research: the recurring signing profile appears to belong to the delivery or packaging layer rather than to any one payload family. It is consistent with a reusable certificate-generation and PE-signing capability (potentially a feature of commodity malware tooling or a form of “evasion as a service”), but we have not identified a common builder, operator, or commercial service.

We observed several distinct forged-certificate constructions during the research. This article focuses on the most distinctive August construction, which we call certificate profile C. This label refers only to the certificate structure, not to a malware family, loader family, campaign, or actor. Profile C uses forged end-entity certificates that resemble plausible code-signing leaves:

• the subject looks like a software publisher
• the issuer field names a real DigiCert code-signing intermediate
• the leaf is not marked as a certificate authority
• the certificate includes the Code Signing extended key usage
• the Authenticode signature uses SHA-256
• and the signature carries a genuine DigiCert timestamp chain

The certificates are not trusted DigiCert certificates. The claimed issuer name is metadata inside the forged leaf. When the leaf certificate signature is checked against the actual public key of the DigiCert intermediate it claims as issuer, verification fails.

Every directly parsed profile-C certificate uses an exact validity span of 32,140,800 seconds, or 372 days. The trusted timestamp falls roughly seven days after notBefore, while notAfter falls roughly 365 days after that timestamp. The 372-day span is not anomalous by itself; it is a shared characteristic that led us to related candidates.

Across the full certificate history available in the Filescan Community corpus, the exact 372-day span appears only on 108 certificate entries representing 97 distinct file hashes. Those hashes split into three non-overlapping metadata buckets:

• 59 hashes claiming the DigiCert code-signing intermediate observed in profile C
• 31 hashes with equal subject and issuer distinguished names
• 7 hashes carrying one genuinely issued Priyo Hutomo / SSL.com certificate

All 59 profile-C files found in the corpus are Go binaries. We analyzed a subset in depth and found materially different loader and payload implementations. The 59-hash metadata bucket is therefore broader than the smaller set of samples whose behavior we directly characterized.

1. Authenticode signatures, certificates, and timestamps

An Authenticode-signed PE contains a PKCS#7 SignedData structure. At a high level, it combines three distinct elements:

The timestamp countersignature lives in an unauthenticated attribute and signs only the publisher signature’s bytes, never the certificate or the file digest.

The Authenticode content records the digest of the PE image, and the publisher signature covers authenticated attributes that bind the signature to that content. The file also includes the leaf certificate containing the public key needed to verify the publisher signature. A name in that leaf’s issuer field is only a claim: trust requires the leaf’s certificate signature to validate under the issuer’s public key and the resulting chain to reach a trusted root.

Timestamping is separate. In the samples analyzed here, a timestamp authority used a legacy PKCS#9 counterSignature to sign the publisher’s signature bytes, not the PE digest or the publisher certificate. Because the timestamp is added after the publisher signature, it sits in an unauthenticated-attribute bag where adding it does not invalidate that signature. A genuine timestamp can therefore coexist with a forged and untrusted publisher certificate.

This structure also explains what we believe happened to the profile-C files. We found no evidence that the attackers modified a formerly valid DigiCert certificate. Instead, the evidence is consistent with newly generated, attacker-controlled leaf certificates whose fields name a real DigiCert intermediate. The PE is signed with the private key corresponding to that forged leaf, after which a genuine timestamp is obtained for the file-specific publisher signature.

2. A plausible-looking but untrusted code-signing leaf

A representative profile-C certificate claims the issuer:

CN=DigiCert Trusted G4 Code Signing RSA4096 SHA384 2021 CA1,
O="DigiCert, Inc.",
C=US

That intermediate is real and is published by DigiCert. The malware certificate, however, was not cryptographically issued by it.

A leaf from one of the profile-C samples (89dacc86…, signer Velnoriq Labs) contains:

subject=C = US, O = Velnoriq Labs, CN = Velnoriq Labs
issuer=C = US, O = "DigiCert, Inc.", CN = DigiCert Trusted G4 Code Signing RSA4096 SHA384 2021 CA1

notBefore=Aug 10 21:30:45 2026 GMT
notAfter=Aug 17 21:30:45 2027 GMT

X509v3 Basic Constraints: critical
    CA:FALSE

X509v3 Extended Key Usage:
    Code Signing

These fields resemble an ordinary code-signing leaf, but X.509 trust does not come from the human-readable issuer string, but from successfully validating the certificate signature and building a chain to a trusted root.

Profile C is therefore best described as a structurally plausible but cryptographically untrusted code-signing leaf.

3. Cryptographic verification proves the claimed issuer did not issue the leaf

The decisive question is: does the leaf’s X.509 certificate signature validate under the actual public key of the issuer it claims? For the held profile-C samples, it does not.

We obtained the real DigiCert Trusted G4 Code Signing RSA4096 SHA384 2021 CA1 intermediate from DigiCert’s certificate repository and used its actual public key to verify the certificate signature of each profile-C leaf independently of Windows chain-building and Authenticode trust evaluation. We also compared each leaf’s claimed issuer DN with the real intermediate’s subject DN:

• the claimed issuer DN matches the real intermediate’s subject DN
• the leaf certificate signature does not validate under the real intermediate’s public key

Real intermediate loaded: CN=DigiCert Trusted G4 Code Signing RSA4096 SHA384 2021 CA1,O=DigiCert\, Inc.,C=US

=== 89dacc86bc936a33d32fc6070e8b0923f247d8dc89f21b331ecba9bb2ae9b01a
  claimed issuer : CN=DigiCert Trusted G4 Code Signing RSA4096 SHA384 2021 CA1,O=DigiCert\, Inc.,C=US
  subject        : CN=Velnoriq Labs,O=Velnoriq Labs,C=US
  serial         : 1eed7af41fa8481caa3d4d03df04d59d
  leaf sig algo  : rsassa_pkcs1v15 / sha256
  matches real intermediate subject? True
  VERIFY RESULT  : FAILED — signature does not validate under the real DigiCert intermediate's public key

The signature over the leaf was not produced by the authority that name identifies. This is the core cryptographic finding. The problem is not that the intermediate is absent from the signed file. Legitimate software may omit an intermediate because Windows can already have it locally or obtain it through normal chain-building mechanisms. However, verification still fails when the genuine claimed issuer is explicitly supplied.

4. The exact 372-day validity pivot

Every directly parsed profile-C certificate in our held set uses the same exact validity interval: 32,140,800 seconds (372 days).

The trusted timestamp on those signatures falls roughly seven days after notBefore, while notAfter falls roughly 365 days after the timestamp.

Four representative samples:

Sample	notBefore	Trusted timestamp	notAfter	Span
00d3f42d…	2026-08-06 22:07:02Z	2026-08-13 22:07:05Z	2027-08-13 22:07:02Z	32,140,800 s
01893775…	2026-08-10 19:22:23Z	2026-08-17 19:22:25Z	2027-08-17 19:22:23Z	32,140,800 s
054ef58f…	2026-08-09 18:52:32Z	2026-08-16 18:52:35Z	2027-08-16 18:52:32Z	32,140,800 s
89dacc86…	2026-08-10 21:30:45Z	2026-08-17 21:30:47Z	2027-08-17 21:30:45Z	32,140,800 s

Across the profile-C samples analyzed, notBefore sits 604,801 to 604,803 seconds before the trusted timestamp and notAfter sits 31,535,997 to 31,535,999 seconds after it.

This is consistent with generation logic approximately equivalent to:

notBefore = T - 7 days
notAfter  = T + 365 days

where T is close to the timestamping time.

We have not recovered the certificate-generation code, so this is an inference from its outputs. We do not know why the generator uses this offset, and the data does not establish a connection to commercial certificate validity periods.

Corpus population

Across the full certificate history available in the Filescan corpus, we measured over 750,000 certificate entries. The exact 372-day span appears on:

• 108 certificate entries
• 97 distinct file hashes

The exact validity span is therefore useful for finding candidates, but it is not specific to profile C. Those 97 hashes split cleanly into three non-overlapping certificate-metadata groups:

Corpus population tree

We analyzed the equal-DN bucket and our observations are compatible with several explanations:

• a loader or packer that includes certificate generation and PE signing as a feature
• a standalone malicious certificate generator or PE signer used by different tooling
• separate implementations reproducing shared code or configuration

The current evidence cannot distinguish among these possibilities. We therefore do not classify the 31-hash equal-DN bucket as a profile-C variant or as one proven implementation lineage.

5. A genuine DigiCert timestamp does not make the signer genuine

Profile C combines a genuine DigiCert timestamp chain with a forged, untrusted signer certificate. As discussed in Section 1, those two things are not mutually exclusive: the timestamp is independent of whether the underlying signing certificate is trusted. A valid countersignature only shows that a particular signature existed at a given point in time; it does not validate the identity or trustworthiness of the signer.

The remaining question was whether the timestamp had actually been issued for the signature on each file, or whether the same timestamped data had simply been copied from another sample and reused across the cluster.

To check this, we compared the countersignature’s authenticated messageDigest with the hash of the Authenticode signature it countersigns. If the timestamped blob had been copied unchanged from a donor file, the digest would still correspond to the donor’s signature rather than the signature in the current sample.

That is not what we found. In each case, the messageDigest matches the hash of that file’s own Authenticode signature, and the resulting values differ between samples. This rules out that a single timestamped blob was copied unchanged across multiple files.

Genuine timestamp doesn’t mean genuine signer

6. What Windows shows

Windows does not treat profile C as trusted. On a tested Velnoriq Labs sample, the Certificate dialog displays a yellow warning:

Real Windows Certificate dialog for the Velnoriq Labs sample, showing the yellow warning, claimed DigiCert issuer, and 372-day dates

Windows does not have enough information to verify this certificate.

The same dialog shows:

Issued to: Velnoriq Labs
Issued by: DigiCert Trusted G4 Code Signing RSA4096 SHA384 2021 CA1
Valid from: 8/10/2026 to 8/17/2027

The UI therefore exposes two important facts at the same time: the claimed DigiCert issuer name is displayed, but Windows still cannot verify the signer.

Controlled self-signed vs orphan-leaf comparison

We reproduced the presentation difference with a controlled benign A/B test. Both test binaries use:

• the same benign test-binary basis
• subject Test Publisher
• the same RSA-4096 leaf key
• CA:FALSE
• equivalent Key Usage
• Code Signing EKU
• 372-day validity
• SHA-256 Authenticode digest

The only experimental variable was trust construction:

• A: self-signed
• B: signed by a separate throwaway Test Root CA, with that issuer certificate deliberately absent

Windows presents the two failures differently:

Self-signed	Orphan leaf

The difference is a presentation effect, not a trust bypass. Digital Signature Details still marks both signatures invalid, but the orphan-leaf construction produces the less explicit message that Windows lacks enough information to verify the certificate while also displaying the name of a recognized CA. That ambiguity could make superficial manual inspection less decisive.

7. Other certificate profiles and related research

Profile C is not the only forged-certificate structure observed in the Filescan corpus. Between April and August 2026, we found at least three different certificate-generation profiles.

Certificate-generation profiles observed over time. The grouping describes structure, not a shared lineage.

Profile A: cloned TLS certificate identity

April and May samples use orphan leaves whose identity fields copy real TLS certificates. For the samples analyzed, the copied values map to legitimate certificates associated with Oracle and LinkedIn in Certificate Transparency data. The genuine TLS certificates cannot serve as valid PE code-signing credentials: the samples copy public identity metadata from them into newly constructed certificates used in Authenticode signatures. The embedded certificates were not issued to the samples by those organizations or their certificate authorities.

For the Oracle example:

Field	Forged leaf (78a7732b…)	Genuine CT certificate
Subject	CN=www-cs-02.oracle.com	Same hostname
Issuer	CN=DigiCert Global G3 TLS ECC SHA384 2020 CA1	Same issuer DN
Serial	0214c7c407d1793b0ccbf241aac955c7	Same
Not Before	2026-02-06 00:00:00 UTC	Same
Not After	2027-02-07 23:59:59 UTC	Same
Public key	RSA-4096	ECC P-384
Basic Constraints	CA:TRUE	CA:FALSE
Extended Key Usage	serverAuth, clientAuth	TLS-oriented
Subject Alternative Name	Absent	83 names

The forged leaf reproduces the subject, issuer, serial, and validity timestamps while using a different key and extension profile. It is therefore structurally inconsistent with the genuine certificate whose identity it copies.

Profile B: simpler self-signed certificate

July samples use a simpler self-signed profile with domain-shaped common names such as catch.go and random-looking organization/location fields.

This is distinct from the August equal-DN 372-day bucket, which uses company-style names.

Profile C: generated publisher identity

Profile C does not copy a real website identity and does not present as an obvious self-signed certificate. It uses generated software-publisher-style names while claiming a real DigiCert code-signing intermediate.

Factory-v3 / UpdateFactory

One analyzed April profile-A sample contains both:

C:\Users\Administrator\Desktop\UpdateFactory\compiler\1.25.3\go\src\runtime\cgo

and the Go module name:

Factory-v3

That sample is directly consistent with the Factory-v3 / UpdateFactory malware lineage previously reported by Unit 42 in July 2026.

The August profile-C samples do not contain equivalent Factory-v3 or UpdateFactory identifiers. Other similarities we examined are too common or non-specific to bridge the April and August populations.

The available evidence therefore does not establish that profile C was produced by Factory-v3 or UpdateFactory.

Other 2026 reporting, including Straiker’s forged-certificate Go loader case and Gen Digital’s GoFlateLoader research, provides useful ecosystem context, but we found no evidence that directly links those activities to this certificate cluster.

8. Loader and payload context

All 59 profile-C files identified in the corpus are Go binaries. We did not analyze the implementation of every file, so the following are representative forms observed in the subset examined in depth, not an exhaustive classification of the full population:

• standalone executables that manually map PE images in memory
• DLLs exporting Microsoft Defender MpClient.dll function names, consistent with DLL search-order hijacking scenarios
• at least one executable where credential-theft functionality appears native to the Go process rather than contained in a separately mapped image

Dynamic and static analysis produced varying levels of consistency with Vidar, Lumma, Remus, and StealC-related activity. Those names describe downstream payload associations, not the Go loaders themselves. The variation in both loader form and payload association shows that profile C is not tied to one malware family or one loader implementation.

This is consistent with certificate generation and PE signing being a reusable capability in the packaging layer. Plausible implementations include a shared signer, a feature exposed by one or more loaders or packers, or separate tooling based on common code or configuration. Without recovered tooling, distinctive shared code, common infrastructure, or evidence of service operation, we cannot determine which explanation is correct or claim that a commodity builder produced all of the files.

9. Defensive guidance

The forged certificate is not a demonstrated endpoint-security bypass. Its defensive value lies in certificate validation and hunting.

Validate cryptography, not labels

A familiar issuer name is not proof of issuance. If a file claims a well-known CA, verify the certificate signature and trust chain rather than treating the DN as trusted metadata.

Use the 372-day span as a candidate pivot

For profile C, a useful triage conjunction is:

• exact 32,140,800-second certificate validity span
• software-publisher-style subject
• claimed issuer matching the DigiCert code-signing intermediate observed here
• Code Signing EKU and plausible end-entity profile
• failure of cryptographic verification against the claimed issuer

The exact 372-day interval alone is not specific enough. The Filescan Community corpus also contains the equal-DN bucket and a genuinely issued SSL.com certificate with the same span, so treat the interval as a candidate query pivot, not a family signature.

Do not deploy these fields alone

Avoid standalone detections on:

• DigiCert issuer DN
• publisher name
• absence of an embedded intermediate
• certificate serial number

Each can legitimately occur outside this malware activity or can be copied from legitimate certificates. If a defender needs to block a specific malicious certificate, a certificate fingerprint or a sufficiently specific conjunction of cryptographic and structural properties is safer than a human-readable field alone.

A genuine timestamp says something narrow

A trusted TSA timestamp establishes that a particular signature existed at a particular time. It does not establish that the signer certificate was validly issued or trusted.

Conclusion

Human-readable certificate fields are attacker-controlled unless the cryptographic chain proves otherwise. Profile C combines:

• a software-publisher-style subject
• a real DigiCert code-signing issuer name
• a plausible code-signing extension profile
• a genuine DigiCert timestamp countersignature
• and an exact 372-day validity interval

Yet the leaf certificate signature does not validate under the actual public key of the DigiCert intermediate it claims as issuer.

The 372-day interval was the thread that exposed a broader corpus population, including a 31-hash equal-DN bucket and a genuinely issued SSL.com certificate. It is not anomalous by itself: it is useful for candidate discovery, but insufficient for lineage or attribution.

The more consequential finding is that profile C recurs across heterogeneous Go loaders and downstream malware associations. This is consistent with a reusable signing capability, potentially part of commodity tooling or an “evasion as a service” model, but it does not establish a common builder, operator, or service. The evidence currently locates the commonality at the certificate and signing layer, not in one demonstrated loader implementation.

For defenders, treat certificate fields as evidence, not trust. Validate the cryptography, combine structural features, and measure proposed indicators against legitimate software before deploying them.

Indicators of Compromise

All indicators below are profile C.

File hashes

SHA-256
00d3f42dc0c6527d375f8b5430915ca27f0da7b9608e446d3e5f6c17082577a5
018937753ffa1fdc88796297948d82cff81b0b0beb1dae0335417b178eb581f2
054ef58f518a55839fd787321390f653087406002b05c6b3f509412feea95082
89dacc86bc936a33d32fc6070e8b0923f247d8dc89f21b331ecba9bb2ae9b01a
8dd70bf61c236b0e0d9130b261d0d74ba740a53f695b30be2555d8429efb9cf6
e51f3f92cea62632428dc9b4863bece65992a5966d1a17051a1791a83a7b747f

Network indicators

Network indicators found through the analysis of some of the Go loaders and their payloads.

Indicator
digitden[.]cyou
kupzovo[.]shop:7567
vexdico[.]shop:8539
mrlketo[.]shop:8932
https://steamcommunity[.]com/profiles/76561198657426610
https://telegram[.]me/mlduus
https://www.pinterest[.]com/mlduus
https://telegram[.]me/m1duus
https://www.pinterest[.]com/m1duus
65.109.35[.]163

References

1. Microsoft, Time Stamping Authenticode Signatures https://learn.microsoft.com/en-us/windows/win32/seccrypto/time-stamping-authenticode-signatures
2. RFC 5280, Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile https://www.rfc-editor.org/rfc/rfc5280
3. DigiCert, DigiCert Trusted Root Authority Certificates https://knowledge.digicert.com/general-information/digicert-trusted-root-authority-certificates
4. DigiCert, Authenticode Program Signing & Timestamping Using SignTool https://knowledge.digicert.com/tutorials/ev-authenticode-using-signtool
5. Palo Alto Networks Unit 42, Factory-v3 / UpdateFactory research and code-signing impersonation reporting https://unit42.paloaltonetworks.com/vidar-stealer-xmrig-miner-campaign-analysis/
6. Straiker, Fake Claude Code, Real Malware: Inside the Campaign Targeting AI Developers https://www.straiker.ai/blog/acr-stealer-claude-code-impersonation-campaign
7. Gen Digital, GoFlateLoader: A Widespread Golang Loader Delivering Multiple Infostealers https://www.gendigital.com/blog/insights/research/goflateloader-delivers-multiple-infostealers