Apple iOS Distribution Certificate Used to Sign Windows Malware

Why This Caught Our Attention

Code signing is one of the most widely misunderstood trust signals in endpoint security.

For many defenders, "signed" implicitly means safer, reviewed, or at least less suspicious. In practice, signatures are far more nuanced: they describe who attests to a file's integrity -- not whether that attestation should be trusted in a given context or under a given policy.

During routine malware analysis, we encountered a Windows PE32+ executable that illustrated this gap perfectly. The file was signed -- but the signer was not who you would expect.

Instead of a Windows code-signing identity, the leaf signer was an Apple iPhone Distribution certificate:

Subject: iPhone Distribution: Jafar Sakhar (Team ID J4FUC525X9)

Issuer: Apple Worldwide Developer Relations Certification Authority

That mismatch is the focus of this blog.

What We Observed (And Why It's Not "Just One Sample")

The first sample was weird. The second was concerning. By the hundredth, the pattern was undeniable.

By pivoting on the Apple Team ID J4FUC525X9, we linked approximately 225 Windows PE samples signed with the same Apple iOS distribution identity. More importantly: those samples weren't all the same "thing."

This signing identity is being used across a broad malware ecosystem - from commodity RATs, to stealers, to self-replicating worms, to kernel driver loaders, to ransomware-adjacent destructive tooling.

That's the "not normal" part: it's not one operator accidentally doing something odd. It looks operational.

Campaign At A Glance

What Windows Does With This Signature (And Why It Still Matters)

Windows behaves correctly.

Using Microsoft tooling (Get-AuthenticodeSignature, signtool, and WinVerifyTrust validation), we confirmed:

• The file contains an Authenticode signature (PKCS#7 is parseable)
• The signer identity is visible and attributable
• Timestamping is present (a valid DigiCert timestamp chain exists)

But Windows fails trust validation with WinVerifyTrust error 0x800B010A:

"A certificate chain could not be built to a trusted root authority."

In plain terms:

So why is this still interesting? Because in the real world, humans and pipelines routinely treat "signed" as a shortcut -- especially under triage pressure.

Normal Signing Chain vs. This Campaign

Signed Is Not Trusted: The Three Things Defenders Conflate

This campaign cleanly illustrates three concepts being mistaken for one:

The cryptography isn't broken. The trust interpretation is.

Okay, But Where's The Malware?

This isn't a niche curiosity. Across representative samples analyzed via on VirusTotal with multi-sandbox behavioral analysis, we confirmed at least six distinct malware categories signed with this same iOS identity.

Malware Ecosystem Overview

Category 1: Information Stealers

Impact: HIGH -- credential theft, financial loss, identity compromise

Stealers in this set harvest credentials, cookies, Discord tokens, screenshots, clipboard contents, and system identifiers, with observed exfiltration to services like Discord webhooks and GoFile.

Named family: Exela Stealer (confirmed with 100% sandbox confidence)

The Exela sample (03a35f49..., 76 MB PyInstaller bundle) triggered 30 Sigma rules in sandbox -- 1 CRITICAL, 7 HIGH, 15 MEDIUM, 7 LOW. The full attack chain:

Exela Stealer is an open-source Python stealer framework. Its presence shows this certificate is being used by the broader stealer-as-a-service ecosystem.

Category 2: RATs / Remote Access Tooling

Impact: HIGH -- persistent remote control, payload staging, lateral movement

Named family: njRAT (Bladabindi) (confirmed by 6 separate YARA rules)

The earliest sample in the campaign -- Server.exe (8d8e05dd..., 101 KB, December 30, 2024) -- is a textbook njRAT payload:

njRAT is one of the most widely deployed commodity RATs globally. Finding it signed with this iOS cert means the signing service is being used by broad crimeware operators, not a single niche actor.

Category 3: Kernel Driver Loaders (Most Dangerous)

Impact: CRITICAL -- ring-0 execution, EDR/AV bypass, rootkit enablement

This is where the campaign crosses into "dangerous even for hardened endpoints.

SoulwareFREE240.exe (dcb76db8..., 23.4 MB) captures a complete Bring Your Own Vulnerable Driver (BYOVD) attack chain:

Why this matters: BYOVD is the exact technique used by Lazarus Group (APT38), BlackByte ransomware, AvosLocker, and Cuba ransomware. The same technique used by nation-state actors and ransomware gangs is being distributed to gamers via this iOS-signed certificate.

The dropped iQVW64.SYS is the Intel Ethernet Diagnostics Driver (CVE-2015-2291) -- a well-known BYOVD target.

Category 4: Worms / Spreaders

Impact: MEDIUM-HIGH -- self-replication, network-wide compromise from single execution

Named family: Mofksys (confirmed by Zenbox at 68-92% confidence across samples)

TJprojMain.exe variants contain a ~270 KB VB-based worm wrapped in a 13-22 MB container. The self-replication chain:

Sigma rules triggered: 1 CRITICAL ("Schedule system process"), 3 HIGH (svchost masquerading, system file anomaly, suspect svchost activity). AV classifications: Kaspersky Virus.Win32.VB.mz, Microsoft Worm:Win32/Mofksys.RND!MTB.

A single execution can compromise an entire network.

Category 5: Ransomware-Adjacent / Destructive Tools

Impact: HIGH -- backup destruction, recovery disablement, service tampering

While not confirmed ransomware (no encryption observed), some samples execute the exact same pre-encryption playbook used by every major ransomware family:

One sample (loader.exe, 17f4d45c...) matched YARA rule INDICATOR_SUSPICIOUS_USNDeleteJournal: "Detects executables containing anti-forensic artifacts of deleting USN change journal. Observed in ransomware."

Category 6: Cryptocurrency Clipbankers

Impact: MEDIUM -- direct financial theft via clipboard hijacking

Named family: Clipbanker (Kaspersky: HEUR:Trojan-Banker.Win32.Clipbanker.b)

Runtime Broker.exe (852ff4f0..., 11 MB, Themida-packed) monitors the clipboard for cryptocurrency wallet addresses and silently replaces them with attacker-controlled addresses. Persistence via CurrentVersion\Run\Update64.

Infrastructure: Not One Actor, An Ecosystem

The infrastructure behind these samples reveals multiple distinct operations sharing the same signing identity.

The "64th Services" RAT Operation

The most organized cluster. A single threat actor operates a commercial malware distribution pipeline:

RAT behavioral chain (from multi-sandbox analysis):

1. VMProtect-unpacked loader executes
2. AV disabled: powershell -NoProfile -WindowStyle Hidden -Command "Add-MpPreference -ExclusionPath 'C:\'" -- excludes the ENTIRE C: drive from Defender
3. Persistence: copies to C:\Windows\system32\<random>.exe and masquerades as Microsoft.ServiceHub.exe
4. License check: contacts keyauth.com / prod.keyauth.com API v1.2
5. Payload download: fetches additional payloads from 64services.netlify.app based on license tier
6. Anti-analysis: kills fiddler*, wireshark*, httpdebugger*

The VirusTotal domain report for 64services.netlify.app confirms 6 communicating files and 9 downloadable payloads hosted on the infrastructure.

The "Alexskr" Game Cheat Operation

A separate operator with their own C2 panel:

Shared Licensing Infrastructure

KeyAuth (keyauth.win) is a licensing-as-a-service platform used across this campaign. For perspective:

110,861 files on VirusTotal communicate with keyauth.win.

Infrastructure Cross-Reference

Zero-Detection Samples: What AV Completely Misses

Some of the most concerning samples in this campaign are the ones with no AV engine flags at all.

TzLoaderV6.dll -- 0 out of 73 Detections

This sample uses Google Sheets API, requires .NET 8.0 runtime, and connects to cloud metadata endpoints. The only indicator of malicious intent is the iOS certificate.

The cross-platform certificate anomaly is literally the ONLY machine-readable detection signal. Without that awareness, this sample is invisible.

Detection Distribution Across All 225 Samples

Timeline: This Wasn't A Weekend Experiment

The observed activity spans 13+ months (December 2024 through January 2026), with clear burst upload patterns and long-lived distribution infrastructure.

The "This Is Structural" Part: The Cert Kept Working After Expiration

Samples continued being uploaded after the certificate expired (~August 2025). The reason is straightforward:

• Windows doesn't reject expired code-signing certs (it marks them with a timestamp warning)
• The cross-platform nature means iOS revocation has zero effect on Windows
• AV detection rates didn't improve after expiration

This is a structural gap, not a bug.

Shared Tooling & Packing

The diversity in packing reveals a multi-operator ecosystem:

Anti-Analysis Techniques Observed Across Campaign

Victim Targeting: Gamers As The Canary

The primary targets are clear from filenames, distribution archives, and embedded infrastructure:

Targeted Games & Platforms

Distribution Mechanisms

Why gamers matter for enterprise defenders: The gaming cheat ecosystem is a proving ground for malware techniques that later migrate to enterprise attacks. BYOVD was gaming cheat technology before it was an APT technique. This campaign shows the next evolution: cross-platform cert abuse as an evasion layer.

Why This Matters Even Though Windows Doesn't Trust It

This finding isn't interesting because Windows is vulnerable, it isn't.

It's interesting because signature metadata still carries weight in the real world:

• Triage pipelines that deprioritize "signed" files
• Detection logic that checks signature presence but not trust outcome
• Analyst bias toward recognizable issuers
• Confusion when signatures appear in unexpected contexts

This iOS signer on Windows binaries exploits that gray zone: it doesn't grant Windows trust, but it creates hesitation, ambiguity, and missed prioritization.

Certificate Ecosystem Abuse, Not A Platform Vulnerability

It's important to be explicit about scope:

This is not an Apple OS vulnerability, not a macOS or iOS signing flaw, and not a Windows trust failure.

What we observe is abuse of developer certificate material outside its intended ecosystem. That material may have been fraudulently obtained, compromised post-issuance, or misused in ways the certificate program did not anticipate.

Immediate Defender Guidance

SOC / Analysts: Fast Triage Rule

If you only take one thing from this post:

Windows PE (.exe/.dll/.sys) + "Apple Worldwide Developer Relations" + "iPhone Distribution" = quarantine. No exceptions.

This is a high-confidence anomaly with effectively no legitimate enterprise use case.

Quick Triage Checklist

• Is it a Windows .exe, .dll, or .sys?
• Does the signature chain include "Apple Worldwide Developer Relations"?
• Does the signer contain "iPhone Distribution" or "iPhone Developer"?
• If all three: quarantine immediately.

CISOs: Policy-Level Takeaway

If your environment has any cultural or technical tendency to treat "signed" as "good," this is your wake-up call:

1. Update hunting to include signer context, not just signature presence
2. Brief your SOC that cross-platform signer mismatch is a high-confidence malicious indicator
3. Review any "allow signed" policies for overly broad trust assumptions

WDAC / Application Control Teams

This campaign is the textbook case for why application control can't be "allow signed stuff":

• Some WDAC designs that broadly allow on "trusted roots" can be abused in surprising ways
• Policy engines rarely validate "certificate type makes sense for this platform"
• Signer context belongs in allow/deny logic, not just analyst mental models

Practical note: A FilePublisher-style block keyed on "Apple Worldwide Developer Relations Certification Authority" for Windows PE would block 100% of this campaign with zero false positives in typical Windows environments.

How To Check (PowerShell)

# Check if a Windows binary is signed with an iOS certificate

$sig = Get-AuthenticodeSignature -FilePath "suspicious.exe"

$sig.SignerCertificate | Format-List Subject, Issuer

# Look for:

#   Subject: CN=iPhone Distribution: ...

#   Issuer:  CN=Apple Worldwide Developer Relations Certification Authority

Indicators of Compromise

Certificate Identity

Malicious Infrastructure

Malicious URLs

Exfiltration Destinations

Vulnerable Driver (BYOVD)

Representative Sample Hashes

The full list of ~225 sample hashes is available in the companion IOC file.

The "This Should Never Happen" Summary

An Apple iPhone Distribution certificate - designed exclusively to sign iOS apps for the App Store - was weaponized to sign ~225 Windows executables spanning stealers, RATs, worms, kernel driver tooling, clipbankers, and ransomware-adjacent behaviors.

Every one of these binaries presents a valid cryptographic signature blob that Windows can parse and display. And yet, no operating system prompt, no default policy engine, and no common security workflow is built to treat "cross-ecosystem signer mismatch" as the abnormality it is.

This isn't a vulnerability. It's a gap in how the industry thinks about trust.

Access the full IoC dataset and technical appendix here:
https://github.com/magicsword-io/IoCs

Want to keep up with how modern attacks actually work? Subscribe to the MagicSword newsletter for practical research, real-world attack tradecraft, and prevention-focused intelligence from the team tracking abused tools every day.

If you want to see how this intelligence turns into real blocking, stopping abused tools before they execute, you can book a demo here.