Handout C: Driver Signature Validation Log

Windows driver loading audit from compromised industrial control workstations. Stuxnet used two stolen digital certificates from legitimate component manufacturers to load malicious drivers while bypassing signature verification checks.

Driver Load Event Log

Windows Kernel Driver Signature Verification Log
Period: June 2010 - System Compromise Timeline
Extracted from: C:\Windows\System32\LogFiles\Sysmon\DriverLoad.log

[2010-06-04 11:23:45] DRIVER LOAD: mrxnet.sys
  Path: C:\Windows\System32\drivers\
  Size: 184,320 bytes
  Signature: VALID
  Issuer: Realtek Semiconductor Co., Ltd.
  Certificate Serial: 0x0c:f6:6a:b4 [REVOKED 2010-07-15]
  Thumbprint: A1B2C3D4E5F6...A1B2
  Status: LOADED INTO KERNEL SPACE
  Permissions: SYSTEM
  Activity: Module remains resident; establishes inter-process communication

[2010-06-04 11:24:02] DRIVER LOAD: pnputil.exe
  Path: C:\Windows\System32\
  Size: 89,472 bytes
  Signature: INVALID (UNSIGNED)
  Status: BLOCKED by PnP Manager
  Reason: Unsigned driver load prevention enabled

[2010-06-04 11:24:15] DRIVER LOAD: jmraid.sys
  Path: C:\Windows\System32\drivers\
  Size: 156,288 bytes
  Signature: VALID
  Issuer: JMicron Technology Corp.
  Certificate Serial: 0x0a:2c:4d:7e:91:b3 [REVOKED 2010-07-15]
  Thumbprint: F1E2D3C4B5A6...F1E2
  Status: LOADED INTO KERNEL SPACE
  Permissions: SYSTEM
  Activity: Module remains resident; hooks I/O operations and USB traffic

================================================================================

Certificate Details (Stolen/Compromised):

CERTIFICATE #1: Realtek Semiconductor Co., Ltd.
  Issuer: VeriSign Class 3 Code Signing 2004 CA
  Valid From: 2008-03-14
  Valid Until: 2009-03-14 [EXPIRED LEGITIMATELY]
  Serial Number: 0x0c:f6:6a:b4
  Common Name: Realtek Semiconductor Co., Ltd.
  Organization: Realtek Semiconductor Corporation
  Country: Taiwan (TW)
  Status: LEGITIMATE COMPANY CERTIFICATE (STOLEN/MISUSED)
  Revoked: Yes (2010-07-15 - after attack discovered)
  Notes: Realtek is real company; issued by real CA; dates correct for period

CERTIFICATE #2: JMicron Technology Corp.
  Issuer: VeriSign Class 3 Code Signing 2004 CA
  Valid From: 2008-11-25
  Valid Until: 2009-11-25 [EXPIRED LEGITIMATELY]
  Serial Number: 0x0a:2c:4d:7e:91:b3
  Common Name: JMicron Technology Corp.
  Organization: JMicron Technology Corporation
  Country: Taiwan (TW)
  Status: LEGITIMATE COMPANY CERTIFICATE (STOLEN/MISUSED)
  Revoked: Yes (2010-07-15 - after attack discovered)
  Notes: JMicron is real company; storage controller manufacturer

================================================================================

FORENSIC ANALYSIS: Certificate Usage Timeline

[Before 2010-04-01]
  Both certificates already issued and expired legitimately in 2009
  β†’ Attacker obtained private keys from Realtek/JMicron

[2010-04-01 to 2010-07-14]
  Malware drivers signed with these expired-but-valid certificates
  β†’ Windows PnP allows expired certificates if signature itself is valid
  β†’ Drivers load successfully despite cert expiration date

[2010-07-15 onwards]
  Both certificates added to CRL (Certificate Revocation List)
  β†’ Post-discovery revocation; too late as initial compromise already occurred

IM NOTES (Do Not Show to Players): This is the remarkable technical sophistication:

  1. Stolen vs. Forged: Realtek and JMicron did NOT forge these certificates. The attacker obtained their PRIVATE KEYS. This means either:

    • Breach of Realtek/JMicron certificate storage
    • Compromise of their build/signing infrastructure
    • Or: The companies were complicit (extremely unlikely; not supported by evidence)

  2. Legitimate company, illegitimate use: The certificates are 100% genuine. The signature verification passes. Windows kernel sees a properly signed driver from Realtek/JMicron and loads it without question.

  3. Expired but valid: The certificates had legitimately expired in 2009, but Windows code signing doesn’t reject expired certificates if the signature itself is cryptographically valid. This allowed the attacker to use 2008-2009 era certificates.

  4. Nation-state indicator: Obtaining private keys from two Taiwanese component manufacturers points to extremely sophisticated supply chain access or state-level intelligence capability.

  5. Zero-day implications: Using legitimate certificates to load malicious drivers is not a vulnerability in the traditional sense – it’s a compromise of the trust infrastructure itself.

  6. Detection challenge: A security analyst in 2010 would see β€œsigned by Realtek” and think it’s legitimate. Only correlation with known malware or behavioral analysis would reveal the true nature.

This is documented fact from Symantec’s analysis and confirmed by both Realtek and JMicron.

Key Discovery Questions

  • How can a driver be legitimate (validly signed) but malicious?

The signature is real; the certificate is real; the company is real. But the PRIVATE KEY used to create the signature was stolen. When you verify a signature, you’re trusting that only the legitimate owner has the private key. Stuxnet breaks that trust by using stolen keys.

  • Why would two different Taiwanese companies have their signing keys compromised?

Most likely: The attacker compromised their build infrastructure (the servers where they generate and sign drivers). If you control the build system, you control what gets signed and how. For two companies to be compromised suggests either:

  1. Both companies use the same third-party code signing service (compromised)
  2. Attacker targeted specific supply chain partners
  3. Nation-state-level access to Taiwanese technology companies
  • How does this change traditional antivirus/malware detection?

AV signatures look for β€œknown malware files.” But a file signed with Realtek’s legitimate key, from a legitimate Taiwanese company, looks trustworthy. The malicious behavior is hidden in kernel code that runs with system privileges. By the time AV would detect unusual behavior, the malware is already embedded in the kernel. Traditional signature-based detection fails.

IM Facilitation Notes

This handout introduces the concept of trust infrastructure compromise:

  • Signatures and certificates create a chain of trust
  • Breaking one link (stolen keys) poisons the entire chain
  • Defense requires more than signature verification – you need behavioral monitoring, supply chain verification, and behavioral analysis

The stolen certificates were one of the most important indicators that Stuxnet was a nation-state operation, not a criminal or hacktivist group.