The Defender Domino: How a DigiCert Breach Turned Microsoft into an Unwitting Proxy for APT-Q-27

Security Joes
2 days ago
9 min read

On May 1, 2026 - Security Joes investigated an unusual wave of Microsoft Defender alerts affecting multiple customer environments at the same time. At first glance, the volume and consistency of the detections suggested a widespread security event. Across different organizations, the same alert patterns appeared, creating the impression of a coordinated malware outbreak or an anomaly on the detection side.

The detections were ultimately classified as false positives by Microsoft. Many organizations closed the case, suppressed the noise, and moved on.

For us, the classification only answered one question: whether the alerts represented active compromises inside those environments. It did not fully explain why trusted certificate-related artifacts were flagged in the first place.

That gap became the starting point of the investigation.

In following the alert storm, we discovered a public security incident involving DigiCert, in which attackers had abused access to obtain valid code-signing certificates. In these cases, the certificates were not just administrative artifacts or theoretical risks. By signing malicious files, malware was able to appear legitimate to one of the most sensitive trust mechanisms.

This raises a larger question: what happens when the trust layer defenders rely on becomes part of the attacker's delivery chain?

What follows is an investigation into abused certificates, their associated publicly known files, and how this activity connects to a China-Nexus threat group. Rather than focusing solely on the alert storm that exposed the issue, this analysis follows the manipulated chain of trust, from certificate issuance to signed malware, to the infrastructure and tooling behind the campaign.

An Overview of the Article: Key Takeaways

On May 3, 2026, the cybersecurity community was flooded with Microsoft Defender ATP alerts tied to a single detection: Trojan:Win32/Cerdigent.A!dha
Microsoft later confirmed these alerts were false positives, tracing back to the DigiCert incident.
The DigiCert compromise led to the creation of 60 valid certificates, which were subsequently used to sign malware.
By investigating publicly available files, we uncovered a direct connection to a China-Nexus APT group.
In addition, practical guidance for hunting and detecting this specific threat is provided below.

False-Positives and the common denominator

Whether you're an analyst or a CISO, if you were working on Sunday you likely witnessed a surge of alerts tied to a single detection.

The volume alone was enough to raise concerns, but what amplified it was the severity implied by the alert itself, compounded by reports across the community of others being hit with the same issue.

Fig2 - Community created github page detailing the False-Positives

Later that day, a public post from Bleeping Computer revealed that Microsoft had acknowledged the error, along with a subtle reference to the root cause: a cybersecurity incident affecting DigiCert.

This prompted us to investigate further and understand the full scope of what had occurred.

The Cost of a Single Gap: What could go wrong?

It began with a familiar support scenario: a customer-facing employee received what appeared to be a routine file through a support channel. According to DigiCert's incident report, the threat actor contacted the support team via chat and delivered a ZIP file disguised as a customer screenshot; inside was a malicious .scr executable. Several delivery attempts were blocked, but one ultimately compromised a support analyst's endpoint. DigiCert later stated that the affected machine had CrowdStrike Falcon installed, but the agent was not functioning properly at the time. This highlights the kind of operational gap that turns "covered by EDR" into a dangerous assumption.

From that endpoint, the attacker gained access to DigiCert's internal support portal, setting the stage for a far larger trust abuse problem.

From the compromised machine, the attacker was able to interact with internal support functionality that exposed initialization codes for already approved EV code-signing certificate orders. This access did not require a direct compromise of DigiCert's signing infrastructure. Instead, it exploited a trust-adjacent workflow: support access intersecting with certificate issuance.

The result was a set of valid code-signing certificates that could be used to make malicious files appear legitimate. Once malware is signed with a trusted certificate, the attacker is no longer simply delivering a payload; they are borrowing trust from the software ecosystem itself.

Revoked Certificates

The table below captures the revoked certificates from the incident, including the certificate SHA-256 fingerprint, subject metadata, issuer, validity window, and revocation details.

Certificate SHA-256 fingerprint	Subject	Country	Issuer	Valid from	Revoked
6f78526ebbc6c7b6c51c27db13755f4667396187c307d835ea236a8d236b2157	CPSS (Na Ji Hun)	KR	DigiCert Trusted G4 Code Signing RSA4096 SHA384 2021 CA1	2026-04-13	2026-04-13
1b15339819aac959e22096d57b1af2c3afd6c2648a6ae8bb766d8f4ba56eca72	Com2uS Corporation	KR	DigiCert Trusted G4 Code Signing RSA4096 SHA384 2021 CA1	2026-04-13	2026-04-13
58c47d15b4191d4aa083d655f021fc319eaa83872225de5616f45bf97cfa31e2	Com2uS Corporation	KR	DigiCert Trusted G4 Code Signing RSA4096 SHA384 2021 CA1	2026-04-14	2026-04-14
26c193f392598842d20ffd0c4ff35b33d2766d58cec7094d16a54436e5701911	Korea Digital Forensic Center Co., Ltd.	KR	DigiCert Trusted G4 Code Signing RSA4096 SHA384 2021 CA1	2026-04-10	2026-04-10

The full list of revoked certificates from this incident includes multiple organizations across several countries, all tied back to the same DigiCert certificate trust.

Seen In-The-Wild

Using this information, Security Joes hunted public sources for samples sharing these certificate fingerprints

SHA-256	Detections	Size
f76c31ecdafb59279833f17f350d9c2b1317da269823097e8dd1736c72449c88	36	42.46 KB
00ed464e867fdc31ac4eb4e18757fe4b79b2f79ff63cc469cfcfeb205df20af0	45	617.86 KB
02f95352c8d55f41f53339283ffed6f1cf548b2c5040aa9d1e37bafcd9fa55b4	43	625.76 KB
99b7658dc52cedff3403e0df0b392828baa3344571593115b2349579c2b840ca	46	806.27 KB
bb24c5116eb8fe9bc2a2cddbbe4db6eeff414753f0eeb1e80e3d610b135b9840	2	262.77 KB
34110c6a0a8c6e88ddd9647d2427a5448a23806aca460304a36df6dce65f7771	42	961.78 KB
8509af4802dd79fc503c425c9dda035d9b636f22ffac81a8f04e6a9d080fdcc3	35	299.69 KB
056bfca8608ea860e17fad10d04ebbb6c351ae5d82a46e3a7a7c5c33e33129ed	39	42.46 KB
ba4de3c93d319523ab95cf3b724e6cef636e3890746c60067fd70b6f7792e428	38	666.46 KB
6ff62e2099092a781caacc486c4088dd89690088408a6cf6198d145b80944c41	33	669.46 KB
4c7c01f5933b9714e037fafac97a4cefac605a54645045f911a769c940b404f7	39	512.46 KB
12491915ec929b14808911bcde5a4459863b16aa417c6a8b09115dcf97066c01	26	303.78 KB
c918dded298b0d76d4ac51f23b391f62a95f58b3fa2488202ecbbc9c7ce8e785	35	626.46 KB
c08a59750b5a72761d457e7b9875aa251f71c64d0c6bf7e391bb5c5f35cefc3c	37	666.06 KB
be629aef6df812939b0bc1b4de07f455467359f39c2faa013c092237f7310bca	43	666.28 KB
53ef62aeb5380761b6b2bc3f881081a2b1f46b96f899b585c62ee26338b15c4a	41	665.78 KB
9ae8388b6bc4043a49573a617927cabbd61c254014e0ceb4223cf50431841b2c	39	673.78 KB
dc05f848515c046a75947917e13377b6ed21ea537e8346704933029f56b3f90f	41	960.36 KB
7cb929fee994dc32a1718176d7dc3888bcba47d508117c13db143a5bd306fe30	38	1.08 MB
17993ab101f5656319dc04ca0aec9ead25ef1a371e68c31ecbe65b8b2ab80dc9	38	621.78 KB
ef23637b2b2cd34b3370bbebd10505857360a0ccfa4d4abf810fb764d6004140	33	36.78 KB
85113d10061110c755626eec419703a57e82afebaf95064c83cf5d4c5c55193a	45	672.28 KB
8492444e70af40fc58fdb4b1a1f30fbbb944c186224353d35e34036da6d11f08	44	671.28 KB
56541af54c5b4ad7de32560f780f0e606e5bf67170ad3bc241c9e2d75ea3f760	40	671.78 KB
c85911c6b8fa64bb84fe9a46c6f61e45c5aa8e47c73dfa839445a5037b1b43f9	39	671.86 KB
d7121915d643fb80745bbfa0ab9425edcc9bc451e7117ec9a7be3b101af50d0a	48	672.78 KB
56b6571ded7d34c7d3adccc46a116f2960d7a2d77a7a4caa70abd23c99602eb7	1	44.93 MB
e6dc0e3229a1fa43bee721ab2165f36c18b9b5668b11f04de33d66490d240bf8	40	9.95 MB
39781b4480850b78d8e644e53c581081d40c2a2761cafe3c670e0b06fcd16a7a	37	942.77 KB
36d22778dda953d192e7fd910faab2f4012421efbb35360ec7fe3e1c5109f1aa	36	32.23 KB
1056ba2ec7a2151e1ade4a02279ace0c291fadc329cfd661fa427b4efed53578	39	962.23 KB
4ba01f317dd469c6ce5fb5333828ea5faf6761c263431ebcd0a5c17c06b00868	40	675.73 KB
5e841260983954da60716b99306a410898bca4d30c14626553205753f60a6d2f	4	264.44 KB
3602827187429435936454364581471d9f1b84d97a61ff63e346db952fef4094	0	96 MB
8bfbbe4cc06517b8ddd593651c9b76a3606fe3ca3737b70c797598a7540198c7	0	1.33 MB
07e607362ffb256490035a4779b63b769f7cc32a3e7033b4b0fcf77933bec49f	25	1.41 MB
262b95f10f78e7e558758530828cda02026037a5dc7fb9673f3a0ef4807f3912	25	668.75 KB
7822abb768504c945a529db36343950c2ac90716c8450802c153cecdb02e29e6	41	962.25 KB

The malware itself is not novel. Median detection sits at 39, with 24 of 38 samples (63%) falling within the 36–45 detection band. The AV industry has largely caught up to these binaries. The certificate theft was about trust, not novelty. The certificates bought initial execution past SmartScreen and EDR publisher reputation checks; once the file lands and runs, on-disk AV detection holds up fine.

One dominant payload family emerges. Seventeen of 38 samples (45%) cluster between 600–700 KB, with 13 of those packed into an 11 KB band (665–676 KB). That is not coincidence. That is a single compiled artifact, or an extremely stable packer, signed repeatedly using different mis-issued certificates.

At least three distinct artifacts exist within this corpus: a tiny loader, a main payload, and a large installer.

How the dragon bites

java.exe

Our research starts off by looking at the following sample:

Attribute	Value
File name	java.exe
SHA256 Hash	36D22778DDA953D192E7FD910FAAB2F4012421EFBB35360EC7FE3E1C5109F1AA
Compiler	Microsoft Linker 48.0 / Microsoft.NET
Compiler Timestamp	Mon Feb 28 06:00:04 2067 (UTC)
Debug symbols	C:\Users\Administrator\Desktop\084049\java\java\obj\Release\java.pdb
File size	34064 bytes

The behaviour of this small process is straightforward. Upon execution it calls ExecuteAsync() , which in turn invokes ExecuteUpdateProcess()

This fetches a configuration URL and executes all downloaded items

The configuration is base64 double-encoded and decodes to:

hxxps://storage.googleapis[.]com/nvbackend/nv.txt

At the time of analysis, the resource was unavailable, though its contents are known through VirusTotal.

detoured.dll

Following the trail of evidence, Nvbackend.exe is a legitimate Nvidia binary. Reports exist of threat actors abusing Nvidia executables to sideload malicious DLL files. Additionally, the image file can also be obtained revealing it to be a simple decoy.

Attribute	Value
File name	detoured.dll
SHA256 Hash	80B6790557199CE089982634CD6B03DBB9423F2FB0C3F16584B4F066934B9108
Compiler	Microsoft Linker 14.44 / Visual Studio
Compiler Timestamp	Wed Apr 22 16:28:26 2026 (UTC)
File size	106736 bytes

Upon decompiling the executable and reviewing its exported function, the intended purpose of this stage becomes clear.

The main routine prepares memory for shellcode injection using the decoded contents of nvbackend.log . The decoding process can be reversed using the following Python routine:

from pathlib import Path
import sys

if len(sys.argv) != 3:
    print(f"Usage: {sys.argv[0]}  ")
    sys.exit(1)

input_path = Path(sys.argv[1])
output_path = Path(sys.argv[2])

data = input_path.read_bytes()

decoded = bytearray()

for b in data:
    b = (b + 0x52) & 0xFF
    b = (b + 0x25) & 0xFF
    b = b ^ 0x62
    decoded.append(b)

output_path.write_bytes(decoded)

print(f"Decoded {len(data)} bytes to {output_path}")

We can then inspect and analyse the shellcode using tools like scdbg

The resulting shellcode is packed with UPX, which can also be unpacked to reach the final payload, one that includes process listing and execution capabilities, enabling escalation to administrator-level execution.

Who Sits Behind the Curtain

After identifying the C2 domain, we searched OpenCTI to assess whether it had any known associations with threat actors or previously reported activity. This pivot produced several relevant hits, providing the first indications of who might be behind the compromise.

Fig17 - Public connection between the found domain and the APT group

In that public reference, there's also a link to other research regarding the activity of the group APT-Q-27, linking directly to the found domain and describing a campaign that also relied on forged or misused certificates, closely matching the certificate-abuse patterns observed in our investigation.

APT-Q-27, also tracked as GoldenEyeDog and Dragon Breath, is a China-Nexus threat cluster associated with financially motivated and espionage-adjacent operations that consistently abuse trust relationships rather than relying on noisy exploitation. Public reporting describes the group as repeatedly using fake software download sites, SEO poisoning, watering-hole distribution, trojanized installers, DLL sideloading, signed loaders, and staged payload delivery to place remote-access or credential-theft tooling on victim systems. Known tooling includes Zhong Stealer, Silver Fox, Winos4.0, and Gh0st RAT-style payload chains, with campaigns engineered to appear legitimate at the point of execution.

Historically, targeting has included Chinese-speaking users and organizations, online gambling and gaming communities, cryptocurrency and fintech entities, customer support personnel, and corporate environments where trust workflows can be manipulated. QiAnXin reporting notes impact across internet companies, securities, manufacturing, IT, gaming, and cryptocurrency sectors, while Sophos describes earlier Dragon Breath activity targeting online gambling participants across the Philippines, Japan, Taiwan, Singapore, Hong Kong, and China. More recent Zhong Stealer reporting reflects a shift toward support-channel social engineering, where attackers pose as customers, deliver archive attachments, and pressure support staff into opening them. This pattern is directly relevant to the DigiCert incident, as it reflects the same operational interest in abusing human-facing trust boundaries.

Conclusions

The Defender alert storm exposed a deeper weakness: certificate trust workflows can be abused without ever breaching core signing infrastructure. The DigiCert support portal access enabled the issuance of legitimate EV code-signing certificates that were subsequently used to sign commodity malware. The campaign leveraged publisher trust to bypass initial reputation checks, though the binaries remained broadly detectable at rest. Evidence and public reporting link the activity and infrastructure to a China-Nexus cluster: APT-Q-27, GoldenEyeDog, and Dragon Breath.

IOCs & TTPS

IOCs

Indicator	Type	Context
36D22778DDA953D192E7FD910FAAB2F4012421EFBB35360EC7FE3E1C5109F1AA	SHA-256	Initial “tiny size” loader analyzed in the article, named java.exe.
80B6790557199CE089982634CD6B03DBB9423F2FB0C3F16584B4F066934B9108	SHA-256	detoured.dll, the DLL used in the next stage of the execution chain.
detoured.dll	Filename	DLL loaded as part of the side-loading chain; its exported function prepares memory and executes the decoded shellcode.
nvbackend.log	Filename	Encoded payload containing shellcode decoded and executed by detoured.dll.
hxxps://storage[.]googleapis[.]com/nvbackend/nv.txt	URL	Decoded resource location retrieved by the initial loader.
C:\Users\Administrator\Desktop\084049\java\java\obj\Release\java.pdb	PDB path	Debug artifact recovered from the initial loader.
uu[.]goldyeuu[.].io	Domain	Final domain identified in the shellcode

TTPs

Tactic	Technique	Observed behavior
Initial Access	Social engineering / support-channel abuse	The broader incident began with a support interaction in which a ZIP file disguised as a customer-provided screenshot led to endpoint compromise.
Defense Evasion	Code signing with abused valid certificates	Malicious files were signed with valid certificates created through abuse of DigiCert-related workflows, allowing malware to inherit apparent legitimacy.
Defense Evasion	DLL side-loading / trusted binary abuse	The activity involved a legitimate NVIDIA binary, NvBackend.exe, alongside a malicious DLL and staged payload files, consistent with DLL side-loading tradecraft.
Defense Evasion	Masquerading	Files such as java.exe, NvBackend.exe, image.jpg, and nvbackend.log used benign-looking names or extensions to blend into expected software/resource patterns.
Defense Evasion	Encoding / obfuscation	The loader configuration was double Base64-encoded, while nvbackend.log contained an encoded shellcode payload that required decoding before execution.
Execution	Staged payload execution	The loader retrieved remote resources and executed downloaded components as part of a multi-stage chain.
Execution	Shellcode execution	The exported function in detoured.dll prepared memory and executed shellcode decoded from nvbackend.log.
Defense Evasion	Packing	The final executable code was packed with UPX and required unpacking to recover the final payload.
Discovery	Process enumeration	The final payload exposed functionality associated with process listing.
Privilege Escalation / Execution	Process execution for elevated context	The final stage contained process execution logic likely intended to support administrator-level execution.
Command and Control	C2 communication	The malware chain ultimately revealed communication with a C2 domain, which was later used for infrastructure pivoting and attribution context.
Resource Development / Infrastructure	Cloud-hosted payload staging	The loader referenced resources hosted under a Google Cloud Storage URL, indicating use of cloud infrastructure for payload delivery.