JemmyLoveJenny: The Windows Driver Signing Trick That Keeps Showing Up

HookSignTool, forged timestamps, leaked signing keys, and why the same certificate artifacts keep turning up in malicious Windows drivers.

Every once in a while you pull apart a Windows driver and find certificate metadata that looks completely made up.

JemmyLoveJenny

Fake TimeStamp Responder

A timestamping certificate valid from January 1, 2000 through December 31, 2099.

It looks ridiculous. It is also worth paying attention to.

Those strings are associated with HookSignTool, a public tool that has been used to sign Windows drivers with old code-signing certificates while forging the time at which the signing supposedly occurred. The author used the handle JemmyLoveJenny, and the tool leaves behind some very recognizable PKI and timestamp artifacts when it is used with its defaults.

Cisco Talos did a great job documenting the technique in 2023. I went back through it because the artifacts never really disappeared. Elastic found them in DragonBreath-related malware in 2025. Then in June 2026, an ABYSSWORKER driver used during a DragonForce intrusion showed the same Fake TimeStamp Responder and JemmyLoveJenny SHA1 TimeStamping Services CA certificate metadata. (LOLDrivers)

So let's dig through what this actually is, why it works, where it has been used, and why defenders should still care about it today.

First, what is JemmyLoveJenny?

First, the name gets used a little loosely.

JemmyLoveJenny is the handle associated with HookSignTool and the private PKI/timestamping setup used by the project. You may see names such as:

JemmyLoveJenny EV Root CA
JemmyLoveJenny SHA1 TimeStamping Services CA
Fake TimeStamp Responder
pki.jemmylovejenny[.]tk

The important piece is that the attack does not depend on Windows globally trusting a JemmyLoveJenny root CA like it would a normal public commercial CA.

The useful trust comes from an old code-signing certificate and its private key. HookSignTool helps make that old certificate useful again by interfering with the signing-time checks and creating a timestamp that falls inside the certificate's old validity period.

This is also why looking only at the publisher field can send you in the wrong direction. Depending on the sample, the leaf signer might be something like:

EVANGEL TECHNOLOGY (HK) LIMITED
Shenzhen Jinxian Technology Co., Ltd.
Shanghai easy kradar Information Consulting Co. Ltd.

Meanwhile, the JemmyLoveJenny material is sitting farther down in the timestamp or countersignature information.

If you collect certificate metadata from drivers, collect the whole story. A single signed=true field is not enough for this stuff.

Why an old certificate can still matter

The reason HookSignTool is useful goes back to Microsoft's Windows driver-signing compatibility rules.

Beginning with Windows 10 version 1607, Microsoft tightened kernel-mode driver signing and generally required new kernel drivers to go through Microsoft's signing process. The catch was compatibility. Microsoft could not simply break every older driver and piece of hardware already deployed.

Microsoft still documents exceptions for some legacy cross-signed drivers, including drivers signed with an end-entity certificate issued before July 29, 2015 that chains to a supported cross-signed CA. Secure Boot state and whether a system was upgraded from an older Windows version can also affect those legacy paths.

That creates an interesting situation: an expired certificate can still be valuable if it is old enough and you also have the private key.

Normal signing tooling will notice that the certificate is expired. HookSignTool gets around that problem by hooking Windows APIs involved in time validation during the signing process. The signing utility is shown a date inside the old certificate's validity window instead of the current date. The driver ends up with a signature and timestamp that claim the signing happened years earlier.

The basic ingredients are:

an older code-signing certificate that fits the legacy Windows rules;
its private key;
a way to make the signing process believe it happened while that certificate was still valid.

Talos found more than a dozen expired certificates used around this tooling, including certificates tied to the 2015 Hacking Team leak and other leaked key material.

For defenders, this is the part I care about: the signature can validate and the story behind it can still be garbage.

A driver can show up today carrying an old certificate and a timestamp that makes the signing event look years older than it really is. Windows may accept the signature because the driver fits a legacy trust path. That does not mean the code is safe, current, or something you ever intended to run.

This came out of cracking and cheat tooling

HookSignTool was not originally published as some polished ransomware utility.

Talos traced it back to 52pojie, a Chinese software-cracking forum, where JemmyLoveJenny released it in 2019. It was also available publicly on GitHub by at least 2020.

Talos found the same general technique around game cheats and cracked software. One example involved a modified PrimoCache driver that needed to be re-signed so Windows would still load it.

That history makes sense. Cheat developers, software crackers, and malware operators can all run into the exact same Windows problem: they have a kernel driver they want loaded and Windows wants a signature it will accept.

Once the tooling and old private keys are public, the use case can change pretty quickly.

RedDriver: using HookSignTool for a real malicious driver

The clearest early malicious example is RedDriver.

Cisco Talos disclosed RedDriver with its HookSignTool research in July 2023 and said the malware had been active since at least 2021. Talos confirmed that RedDriver used HookSignTool to forge its signature timestamp and get around Windows driver-signing policy.

RedDriver was a kernel driver used to intercept browser traffic through the Windows Filtering Platform. The infection chain downloaded and loaded the driver, which could redirect traffic from Chrome, Edge, Firefox, and several browsers popular with Chinese-speaking users. Talos also found references to Chinese internet-cafe management software.

The signing technique was just how the attacker got the driver loaded. The interesting behavior came after that.

LOLDrivers preserves the certificate metadata from the RedDriver sample, including the familiar timestamp chain.

CN=Fake TimeStamp Responder,

OU=timestamp.pki.jemmylovejenny.tk,

O=JemmyLoveJenny PKI Service,

C=CN

and:

CN=JemmyLoveJenny SHA1 TimeStamping Services CA

Those are great hunting strings because they are weird, stable enough to pivot on, and unlikely to blend into a normal enterprise driver population.

Microsoft blocked certificates discussed in the 2023 Talos research, and Microsoft also took action that year against malicious use of signed drivers and related trust material.

But blocking one set of certificates does not remove the underlying idea. There are other old certificates, other stolen keys, and other ways to get a driver signed.

POORTRY: keep another signed driver ready

POORTRY is where this gets a lot more operational.

POORTRY, also called BurntCigar in some reporting, is an EDR-killer driver used with a loader Mandiant called STONESTOP. Mandiant documented malicious POORTRY drivers in 2022, including samples that had obtained Microsoft Windows Hardware Compatibility signatures.

Once defenders and Microsoft started responding to those signed samples, the operators changed what they were using.

Sophos documented POORTRY moving through leaked certificates and forged timestamps in 2024. Sophos linked the tooling to incidents involving Cuba, BlackCat, Medusa, LockBit, and RansomHub ransomware families.

One incident is a good example of how little attachment the operators had to any particular signer.

During an August 2023 response, Sophos saw attackers enter through Splashtop and deploy POORTRY/STONESTOP. A driver signed with a known stolen bopsoft certificate was blocked. Thirty seconds later, the attackers tried another POORTRY driver signed as EVANGEL TECHNOLOGY (HK) LIMITED.

From a defensive perspective, the 30-second retry is useful. The operator already had another signed driver ready to go. The publisher changed; the capability did not.

LOLDrivers tracks POORTRY samples using the same HookSignTool-style timestamp artifacts. A sample signed with an old Shenzhen Jinxian Technology certificate contains both Fake TimeStamp Responder and JemmyLoveJenny SHA1 TimeStamping Services CA in its certificate metadata. (LOLDrivers) Another POORTRY sample using the Evangel Technology certificate also contains the JemmyLoveJenny timestamp chain. (LOLDrivers)

POORTRY has used more than one signing strategy over time. I would not build a detection around one publisher or one certificate and call it done.

By July 2024, Sophos observed a RansomHub intrusion where POORTRY had moved beyond terminating security processes and was deleting critical EDR components from disk.

Once a malicious driver is in the kernel, the problem changes quickly.

The artifacts were still showing up in 2025

In November 2025, Elastic Security Labs published research on RONINGLOADER, tied to DragonBreath activity. The campaign used trojanized installers masquerading as applications such as Google Chrome and Microsoft Teams, along with several ways to evade or disable endpoint defenses.

While pivoting through related signed drivers, Elastic found older samples such as inject.sys with explicit HookSignTool artifacts, including JemmyLoveJenny.

A newer driver from October 2025, ollama.sys, did not contain those artifacts and used a more conventional signing path, even though Elastic found related certificate characteristics.

For hunting, I would not make the string mandatory. Search for JemmyLoveJenny, absolutely. It is a good indicator. Just do not require it to be present before you decide an old or unusual driver signature is suspicious.

And again in a DragonForce intrusion in 2026

The example that made me want to revisit all of this is from June 2026. Elastic had already published a separate technical look at the ABYSSWORKER driver in March 2025.

The Symantec and Carbon Black Threat Hunter Team then published an intrusion involving DragonForce ransomware against a major U.S. services company. The attacker was in the environment for roughly one to two months and used multiple kernel-level defense-evasion techniques, including vulnerable drivers and a custom malicious driver from the ABYSSWORKER family.

Symantec listed the ABYSSWORKER sample as:

8284c8676cc22c4b2e66826ac16986da7ddecba1f2776b16771be17bfdc45dc2

That same sample is tracked in LOLDrivers as tdevflt.sys, masquerading as a Palo Alto Networks Cortex XDR PnP Device Filter Driver.

Now look at the certificate metadata:

Fake TimeStamp Responder
JemmyLoveJenny PKI Service
JemmyLoveJenny SHA1 TimeStamping Services CA
a leaf signing certificate issued to Shanghai easy kradar Information Consulting Co. Ltd. and valid from January 29, 2015 to January 29, 2016

The fake timestamp responder certificate has serial:

1eb132d57e7968960df26e854eb0dda6

The JemmyLoveJenny timestamping CA has serial:

1eb132d57e796896

These are the same artifact families defenders were looking at in the RedDriver research years earlier.

So if you have old detections or enrichment logic for these strings sitting in a repo somewhere, I would not delete them yet.

A quick iVentoy side note

There is also an odd non-ransomware example worth knowing about.

In May 2025, researchers and users raised concerns about iVentoy after analysis of Windows components found a self-signed certificate named JemmyLoveJenny EV Root CA0. The reports alleged that the software installed the certificate into the local trusted root store as part of its driver-loading process.

That alone does not prove iVentoy was malicious, and I would not describe it that way based on the available reporting.

What it does show is that the JemmyLoveJenny name can surface outside a clean malware-only bucket. The original tooling came out of cracking and compatibility work, so that is not particularly surprising.

For hunting, I would still treat the name as something that needs an explanation.

If a driver carries the JemmyLoveJenny timestamp chain, investigate it.

If an application adds a JemmyLoveJenny root certificate to the machine trust store, investigate that too. I would want to know what code depends on it, why it needs a new trusted root, and how broadly that trust can be used.

Signed does not mean trusted

This is really the reason I wanted to write this.

We have trained ourselves to look at a signature as a trust decision.

Signed.

Valid.

Publisher present.

Looks good.

But a Windows signature answers a much narrower question. It tells you something about the cryptographic relationship between a file and a certificate. From there, Windows applies a bunch of trust and compatibility rules to decide whether that code is allowed to load.

Those rules have history.

That history matters a lot with kernel drivers.

JemmyLoveJenny is a good example because the weirdness is right there in the certificate chain. You can see the old certificate, the timestamping infrastructure, and the attempt to make an old signing event look valid again.

Other attacks are nowhere near this obvious.

An adversary may have:

a leaked code-signing certificate;
a stolen private key;
a legitimately signed but vulnerable driver;
a malicious driver that obtained a Microsoft signature;
an older cross-signed driver that Windows still accepts;
a different signing or loading path entirely.

POORTRY is probably my favorite example of this. The operators did not care about one certificate or one signing method. Sophos watched them retry with a differently signed POORTRY driver roughly 30 seconds after the first one was blocked.

That is the part defenders need to remember.

The adversary does not have a philosophical attachment to HookSignTool.

They need code in the kernel.

If one path works, they use it. If that path stops working, they move to another one.

LOLDrivers has several POORTRY samples that make this easy to see. Some carry the JemmyLoveJenny timestamping artifacts. (LOLDrivers) (LOLDrivers) Others are tracked under the same POORTRY family with different signing histories and certificates. (LOLDrivers) (LOLDrivers)

The capability stays the same even when the trust story around the file changes.

Cross-signed drivers are finally getting squeezed

There is another reason this topic is interesting right now.

Microsoft is actively tightening the legacy cross-signed driver path that made a lot of this possible in the first place.

Starting in April 2026, Microsoft's Windows Driver Policy no longer trusts cross-signed certificate authorities by default for kernel-mode driver signing. Microsoft now describes the normal path as submitting drivers through the Hardware Dev Center for Windows Hardware Compatibility Program certification.

That is a meaningful change.

We wrote about this separately at MagicSword because the numbers in LOLDrivers are pretty wild: a huge portion of the catalog has historically relied on third-party cross-signed certificates.

For years, Windows had to carry this compatibility baggage because enterprises still had old hardware, old products, and old kernel drivers that could not just disappear overnight.

Attackers got the same compatibility.

That is the uncomfortable part of backward compatibility. Windows does not know whether you are loading a twelve-year-old storage driver because a factory floor still depends on it or because an attacker found a useful private key and a way to make malicious kernel code fit the same trust model.

Microsoft closing that path is good.

I want it closed.

But I would not read that announcement as "the malicious driver problem is solved."

It is one path.

We already have plenty of examples where attackers obtained legitimate Microsoft signatures, abused WHQL-signed or otherwise valid vulnerable drivers, stole signing certificates, or simply brought a legitimate signed driver with a vulnerability they could exploit. (Mandiant / Google Cloud Threat Intelligence) (Sophos X-Ops)

JemmyLoveJenny is interesting because it shows how creative people got around one generation of controls.

There will be another generation.

If you can require WHQL, that is a much stronger boundary

One Microsoft control I do like here is the App Control for Business kernel policy option Required:WHQL.

That policy requires kernel drivers to be WHQL-signed and removes support for the legacy driver-signing path for systems where you enforce it.

That is a much cleaner trust boundary than "this driver has some signature Windows can validate."

Obviously, test it.

There are real enterprises with old VPN clients, specialty hardware, industrial software, security products, and other drivers that will make a strict kernel policy painful.

But if you have a managed population where every required driver can meet the modern signing requirement, I would absolutely look at it.

This is where application control gets interesting to me.

Not because application control magically knows whether every signed binary is evil.

It gives you a place to define what your environment is actually willing to trust.

Where MagicSword fits

This is also the way we think about the problem at MagicSword.

LOLDrivers gives us the public research and the intelligence layer: known vulnerable drivers, known malicious drivers, certificates, hashes, families, and the reporting around how those drivers were used.

MagicSword takes that intelligence and turns it into enforcement through Application Control.

I love hunting. I spent a large part of my career writing detections and trying to figure out how attackers got around the last detection.

But if I already know a driver is being used to kill EDR, I do not really want another alert telling me the attacker loaded it.

I want the driver not to load.

If we know a driver is associated with RedDriver, POORTRY, ABYSSWORKER, or another known malicious or vulnerable driver family, that knowledge should be useful before execution, not only after an analyst gets an alert.

MagicSword also lets defenders use application-control policy as a broader trust boundary instead of relying on signed = true as the decision.

That is important because attackers have repeatedly shown they understand Windows trust better than a lot of defensive products do.

They know which certificates still work.

They know which signed vulnerable drivers work.

They know when a legacy path is still available.

They know when a Microsoft-signed tool gives them the capability they need.

Our job is to stop pretending the signature itself answers the security question.

A few artifacts I would still know

I do not think this post needs to turn into a giant detection guide.

But these are worth knowing because they are so specific to this story:

JemmyLoveJenny

JemmyLoveJenny PKI Service

JemmyLoveJenny SHA1 TimeStamping Services CA

Fake TimeStamp Responder

timestamp.pki.jemmylovejenny.tk

pki.jemmylovejenny.tk

The RedDriver entry in LOLDrivers contains the JemmyLoveJenny timestamping CA and the Fake TimeStamp Responder certificate metadata.

POORTRY samples in LOLDrivers show the same timestamping chain across multiple driver variants. (LOLDrivers) (LOLDrivers)

The more recent ABYSSWORKER sample associated with the 2026 DragonForce intrusion also carries the same certificate artifacts. (LOLDrivers)

That is enough for me.

If I see those strings in a driver today, I am going to look at it.

But I would not build my driver security strategy around finding those strings. HookSignTool can be changed. Certificate names can be changed. Signing paths can be changed. The attacker can choose a completely different technique.

The useful lesson is the trust model, not the IOC.

Timeline

Year	What happened
2018	FuckCertVerifyTimeValidity, a related timestamp-forging technique, appears publicly. (Cisco Talos)
2019	JemmyLoveJenny releases HookSignTool on 52pojie. (Cisco Talos)
2020	HookSignTool is publicly available on GitHub by at least this point. (Cisco Talos) (GitHub)
2021	RedDriver is active and later becomes a documented malicious HookSignTool example. (Cisco Talos)
2022	Mandiant documents POORTRY/STONESTOP and malicious abuse of driver signing. (Mandiant / Google Cloud Threat Intelligence)
2023	Talos documents HookSignTool/JemmyLoveJenny and RedDriver; Microsoft blocks certificates covered in the reporting. (Cisco Talos) (Cisco Talos)
2023–2024	POORTRY rotates through Microsoft signatures, leaked certificates, and forged timestamps during ransomware activity. (Sophos X-Ops)
2025	Elastic finds explicit HookSignTool/JemmyLoveJenny artifacts in drivers tied to DragonBreath-related activity. (Elastic Security Labs)
2026	Microsoft begins removing default trust for legacy cross-signed kernel-driver CAs, while a DragonForce intrusion uses an ABYSSWORKER sample containing the JemmyLoveJenny timestamping artifacts. (LOLDrivers) (Microsoft Learn)

The part I keep coming back to

JemmyLoveJenny is a weird little piece of Windows driver-signing history.

It is also a very good example of how attackers look at trust controls.

They do not look at "signed" and stop there.

They look at what Windows will accept.

There is a difference.

HookSignTool took an old certificate and a Windows compatibility decision and found a way to make the two useful again. RedDriver used it. POORTRY operators used the same general ecosystem while rotating through other signing options. Years later, the artifacts were still showing up around DragonBreath and ABYSSWORKER activity.

Microsoft is closing down the legacy cross-signed driver path now, and that is a good thing.

But there will still be stolen certificates.

There will still be vulnerable signed drivers.

There will still be malicious drivers that get through legitimate signing channels.

There will still be attackers looking for whatever Windows will let them load.

So when I look at a Windows driver, I do not care that it is merely signed.

I care why Windows trusts it, whether I trust it, and whether that driver ever needed to run in my environment in the first place.

That is a much better security question.

LOLDrivers tracks the variants, the certificates, the families, and the reporting behind every driver in this post. MagicSword turns that intelligence into enforcement. Book a demo to see what that looks like in practice.