Why a decade-old EnCase driver still works as an EDR killer

[ForgottenSeer 123960]

.
No one tested those standards against vulnerable drivers. The result can highly depend on the attackers, especially when they know those standards.
For me, in this case, the industry standards are an insufficient criterion. However, I can easily accept that you might not agree.

Standards are not "guesses." They are the After-Action Report of the last ten thousand breaches. We follow them so we don't make the same mistakes the last victims did.

 

[Andy Ful]

Standards are not "guesses." They are the After-Action Report of the last ten thousand breaches. We follow them so we don't make the same mistakes the last victims did.

Every discussion should have a purpose. By saying "I do not prioritize ASR vs Core Isolation," I have a purpose to use both of them.
What is your purpose by saying that you prioritize Core Isolation? What is a practical gain for the readers?

 

[ForgottenSeer 123960]

Every discussion should have a purpose. By saying "I do not prioritize ASR vs Core Isolation," I have a purpose to use both of them.
What is your purpose by saying that you prioritize Core Isolation? What is a practical gain for the readers?

"My 'Purpose' is to ensure readers implement a Fail-Safe architecture rather than a Fail-Open one.

90% of readers (Home Users) cannot configure ASR. If I don't prioritize Core Isolation, they do nothing, and they remain vulnerable.

In every security framework (NIST, Microsoft), Kernel Integrity is the foundation. You build the house (Core Isolation) before you lock the windows (ASR).

My question to you is, why are you side-stepping the Industry Standard? Microsoft, NIST, and CISA all explicitly mandate Memory Integrity/HVCI as the baseline defense against this exact threat. By arguing against prioritization, you are confusing readers by suggesting that the 'Standard' is just an 'Option.'

 

[Andy Ful]

"My 'Purpose' is to ensure readers implement a Fail-Safe architecture rather than a Fail-Open one.

Is this in contradiction to using both ASR and Core Isolation?
Did anyone propose to use only ASR?

 

[ForgottenSeer 123960]

Is this in contradiction to using both ASR and Core Isolation?
Did anyone propose to use only ASR?

"Andy, you are arguing against a point I never made.

No one said 'Use Only ASR.' We explicitly agreed on 'Use Both.'

You asked for the 'Purpose' of my prioritization. I gave you two specific reasons.

Accessibility
Home users physically cannot configure ASR, so Core Isolation is their only option.

Standards
NIST and Microsoft architecturally prioritize Kernel Integrity (Core Isolation) over User-Mode Rules (ASR).

You completely ignored those points to ask if I'm contradicting myself. I am not.

Stop side-stepping the issue. My report prioritizes Core Isolation because it aligns with the Industry Standard and the Physical Reality of what home users can actually do.

The Question remains. Why are you advising readers that 'Prioritization doesn't matter' when every major security framework says it does?

 

[Andy Ful]

The Question remains. Why are you advising readers that 'Prioritization doesn't matter' when every major security framework says it does?

I do not advise this. because it is unnecessary. Users should use both ASR and Core Isolation.
If it is not possible, then users are forced to use only one solution. There is no real priority problem.

The discussion about the priority of Kernel Integrity over User-Mode Rules can be interesting in another thread. This one is not a good place for that.
If you were to open such a thread, then there is general agreement that kernel-based (or stronger) security has advantages over User-Mode.
However, the industry standard is still using both, because only kernel-based security would be unusable.

 

[ForgottenSeer 123960]

I do not advise this. because it is unnecessary. Users should use both ASR and Core Isolation.
If it is not possible, then users are forced to use only one solution. There is no real priority problem.

The discussion about the priority of Kernel Integrity over User-Mode Rules can be interesting in another thread. This one is not a good place for that.
If you were to open such a thread, then there is general agreement that kernel-based (or stronger) security has advantages over User-Mode.
However, the industry standard is still using both, because only kernel-based security would be unusable.

"If it is not possible, then users are forced to use only one solution."

That is exactly why the Report prioritizes Core Isolation.

For millions of Windows Home users, enabling ASR via PowerShell is effectively 'not possible.' They are the group you just admitted is 'forced to use only one solution.'

If I prioritize ASR, that group fails and stays vulnerable.

If I prioritize Core Isolation, that group succeeds and is protected.

The Retroactive Fix (The 'Fail Open' Problem). We also have to look at what happens after a failure.

If ASR fails open (or the list was stale at the moment of the drop), the malware is on the disk. Updating the ASR list afterwards does nothing because the 'Write Event' is over. The malware is inside forever.

If Core Isolation has a stale list, they can push a Windows Update to refresh the blocklist. Because Core Isolation checks at Load Time, it will retroactively block that dormant driver the next time it tries to start.

Core Isolation gives us a second chance to fix a breach. ASR does not.

Between the physical limitations of Home Users and the architectural need for retroactive protection, the priority is clear. I'm glad we agree that Kernel security is stronger. Let's leave it there.

 

[Andy Ful]

"If it is not possible, then users are forced to use only one solution."

That is exactly why the Report prioritizes Core Isolation.

The article from the OP is a good example of prioritizing nothing like that:

"After decoding the driver, the malware writes it to disk under a path that looks like a legitimate OEM component, hides the file, and copies timestamps from a real system file so it blends in. It then registers the driver as a Windows kernel service to ensure it loads on every reboot."

This concrete attack can be more likely blocked by the ASR rules, instead of 10 months old Core Isolation black list.

"They advise organizations to enable multi-factor authentication on all remote access services and review VPN logs for suspicious activity.

Defenders should also turn on Memory Integrity so Microsoft’s Vulnerable Driver Blocklist is enforced, monitor for suspicious services that mimic legitimate hardware components, and use Windows Defender Application Control and Attack Surface Reduction rules to prevent known vulnerable drivers to be loaded and exploited."

I'm glad we agree that Kernel security is stronger. Let's leave it there.

There was agreement about it from the beginning.
I think that disagreement can be related to the importance of prevention.
In my opinion, the preventive features are also important. That is why I do not prioritize them and Core Isolation.

 

[ForgottenSeer 123960]

The article from the OP is a good example of prioritizing nothing like that:

"After decoding the driver, the malware writes it to disk under a path that looks like a legitimate OEM component, hides the file, and copies timestamps from a real system file so it blends in. It then registers the driver as a Windows kernel service to ensure it loads on every reboot."

This concrete attack can be more likely blocked by the ASR rules, instead of 10 months old Core Isolation black list.

"They advise organizations to enable multi-factor authentication on all remote access services and review VPN logs for suspicious activity.

Defenders should also turn on Memory Integrity so Microsoft’s Vulnerable Driver Blocklist is enforced, monitor for suspicious services that mimic legitimate hardware components, and use Windows Defender Application Control and Attack Surface Reduction rules to prevent known vulnerable drivers to be loaded and exploited."




There was agreement about it from the beginning.
I think that disagreement can be related to the importance of prevention.
In my opinion, the preventive features are also important. That is why I do not prioritize them and Core Isolation.

We can do this all day if you like. Keep twisting my words, maybe?

My report states verbatim, 'Enable Memory Integrity (Hypervisor-protected Code Integrity - HVCI). This is the primary native defense that enforces the Microsoft Vulnerable Driver Blocklist.'

This is a statement of fact, not opinion.

You are arguing that ASR (a user-mode rule) is somehow 'more likely' to block a kernel-mode threat than the literal Kernel-Mode Defense designed to stop it.

You quoted the article advising 'organizations' to use ASR. Thank you for proving my point.

Organizations have IT teams to configure ASR.

Home Users do not.

You are applying 'Enterprise' advice to Home Users who cannot easily enable ASR.

ASR is the Doorman. If he sleeps (stale cloud check) or is missing (Home Users), the intruder walks in.

Core Isolation is the Vault Door. Even if the Doorman fails, the Vault Door stops the intruder from stealing the jewels (The Kernel).

My report prioritizes the Vault Door because it protects everyone, Enterprise and Home Users alike. Your advice prioritizes the Doorman and leaves the Home User exposed.

That is the practical difference.

P.s.

I appreciate you pointing me back to the text, because it actually confirms my report's hierarchy.

Look at the exact sentence in the 'Blocking vulnerable drivers' section:'Defenders should also turn on Memory Integrity so Microsoft’s Vulnerable Driver Blocklist is enforced... and use... Attack Surface Reduction rules...'

The article explicitly links Memory Integrity to the Enforcement of the Blocklist. It lists Memory Integrity first, establishing it as the prerequisite for the blocklist to function. ASR is listed after as a supplementary layer.

 

[Andy Ful]

@Divergent,

I was taught at Warsaw University in Poland that in logic, the conjunction of A, B, and C is equally true as that of C, B, and A. So, it prioritizes nothing unless explicitly stated that the order of A, B, and C matters. So, I am sorry. I cannot see what you can. However, the author of the article cannot clear up the intended meaning, so let's agree to disagree.

Edit.
You probably noticed that the first recommendation was "They advise organizations to enable multi-factor authentication on all remote access services and review VPN logs for suspicious activity." Mentioning this recommendation first is unimportant to me (order does not matter), but it should be important to you.

 

[ForgottenSeer 123960]

@Divergent,

I was taught at Warsaw University in Poland that in logic, the conjunction of A, B, and C is equally true as that of C, B, and A. So, it prioritizes nothing unless explicitly stated that the order of A, B, and C matters. So, I am sorry. I cannot see what you can. However, the author of the article cannot clear up the intended meaning, so let's agree to disagree.

Edit.
You probably noticed that the first recommendation was "They advise organizations to enable multi-factor authentication on all remote access services and review VPN logs for suspicious activity."

That explains the disconnect. You are applying Abstract Logic to Security Architecture.

In abstract logic, yes, 'A and B' is the same as 'B and A.' But in Engineering and Architecture, Order is Dependency.

You can't put on your shoes (B) before your socks (A), even if the 'conjunction' of wearing both is the goal.

The article didn't just list them, it used the causal connector 'so': 'Turn on Memory Integrity SO Microsoft’s Vulnerable Driver Blocklist is enforced.'

That is not a conjunction (A∧B). That is a dependency (A→B). If A is missing, B does not function.

My report prioritizes the Foundation (Core Isolation) because it is a prerequisite for the Blocklist and is accessible to 100% of users.

Your stance treats the Roof (ASR) and the Foundation as interchangeable, ignoring that half the audience (Home Users) cannot build the Roof.

I am happy to agree to disagree. You are arguing Logic Theory; I am arguing Applied Security Strategy.

Best of luck.

 

[Andy Ful]

The article didn't just list them, it used the causal connector 'so': 'Turn on Memory Integrity SO Microsoft’s Vulnerable Driver Blocklist is enforced.'

That is not a conjunction (A∧B). That is a dependency (A→B). If A is missing, B does not function.

Here is the recommendation from the original report:

They Got In Through SonicWall. Then They Tried to Kill | Huntress

Huntress responded to a 2026 intrusion using compromised SonicWall VPN credentials and a revoked EnCase forensic driver to terminate EDR processes via BYOVD.

www.huntress.com

The recommendation is a conjunction of A, B, C, D, E, and F.
Let's agree to disagree.

 

[ForgottenSeer 123960]

Here is the recommendation from the original report:

They Got In Through SonicWall. Then They Tried to Kill | Huntress

Huntress responded to a 2026 intrusion using compromised SonicWall VPN credentials and a revoked EnCase forensic driver to terminate EDR processes via BYOVD.

www.huntress.com

View attachment 295527

The recommendation is a conjunction of A, B, C, D, E, and F.
Let's agree to disagree.

I've already agreed to disagree, although you wish to keep going.

You are reading the article as a Shopping List of ingredients. I am reading it as a Dependency Chain. You keep ignoring the most critical word in the sentence you quoted: 'SO'.

'Defenders should turn on Memory Integrity SO Microsoft’s Vulnerable Driver Blocklist is enforced.' Grammar Matters. The word 'SO' indicates Causality and Prerequisite.

It does not say 'Turn on Memory Integrity AND the Blocklist.' It says 'Turn on Memory Integrity TO MAKE the Blocklist work.'

The Logic is Absolute.

Without Core Isolation, the Blocklist is OFF. (The Foundation is missing). Without the Blocklist, The ASR rule is fighting a kernel-level threat with one hand tied behind its back.

Conclusion = You cannot prioritize the 'Result' (Blocklist/Protection) if you do not first prioritize the 'Cause' (Core Isolation).

My report prioritizes the Cause. Yours lists the Results and hopes for the best.

I think the readers can see the difference.

 

[Andy Ful]

Here is an example of why one should not take care much about the order:

Understand and use attack surface reduction - Microsoft Defender for Endpoint

Learn about the attack surface reduction capabilities of Microsoft Defender for Endpoint.

learn.microsoft.com

Currently, the first point is deprecated. ASR rules are mentioned before kernel-based WDAC. This is the opposite order from that presented in the article in the OP. Should we conclude that ASR rules are more important? I do not think so.

 

[ForgottenSeer 123960]

Here is an example of why one should not take care much about the order:

Understand and use attack surface reduction - Microsoft Defender for Endpoint

Learn about the attack surface reduction capabilities of Microsoft Defender for Endpoint.

learn.microsoft.com

View attachment 295528

Currently, the first point is deprecated. ASR rules are mentioned before kernel-based WDAC. This is the opposite order from that presented in the article in the OP. Should we conclude that ASR rules are more important? I do not think so.

You just conceded the argument.

You wrote: 'This is the opposite order from that presented in the article in the OP.'

Exactly.

The OP Article (Threat Analysis), prioritizes Memory Integrity because it is analyzing a specific Kernel-Level Threat. My report mirrors this because we are solving this problem.

The Microsoft Doc (Deployment Guide), lists ASR first because it is a generic 'Setup Checklist' for IT Admins, not a prioritized defense strategy against BYOVD attacks.

You are confusing a Workflow (Step 1, Step 2, Step 3) with a Security Hierarchy (Critical vs. Optional).

When building a house, you pour the concrete (Core Isolation) before you paint the walls (ASR).

Just because the 'Paint Manual' lists painting as Step 1 doesn't mean it's more important than the foundation.

Since we are discussing the Threat in the OP, I followed the Order in the OP. You are quoting a generic manual to argue against a specific threat analysis.

I think we are done here.

 

[Andy Ful]

Let's sum up.

1. We conclude the same about using both ASR rules and Core Isolation.
2. I concluded this without assumptions about priority order.
3. You think that prioritization is important.

We agreed to disagree about the last point and presented some arguments.
I do not prioritize ASR over Core Isolation, and vice versa (cannot see sufficient evidence for prioritization).
You think that Core Isolation should be prioritized.

 

[ForgottenSeer 123960]

Let's sum up.

1. We conclude the same about using both ASR rules and Core Isolation.
2. I concluded this without assumptions about priority order.
3. You think that prioritization is important.

We agreed to disagree about the last point and presented some arguments.
I do not prioritize ASR over Core Isolation, and vice versa (cannot see sufficient evidence for prioritization).
You think that Core Isolation should be prioritized.

Let's be precise in our summation.

It is not that I think Core Isolation should be prioritized. It is that the Industry Standard, Microsoft, and the Article in the OP prioritize it for this specific threat.

The standard defines Core Isolation as the architectural foundation (Kernel Mode) over ASR (User Mode).

The article explicitly lists Memory Integrity as the prerequisite ('SO') to enforce the blocklist.

Prioritization is mandatory for Home Users who cannot enable ASR (the group you admitted is 'forced to choose').

You are choosing to disregard the hierarchy based on abstract logic. I am choosing to follow the hierarchy based on the Industry Standard and the engineering limitations of the Home User.

So yes, we agree to disagree. You disagree with the Standard. I align with it.

 

[Andy Ful]

I am not sure if a concrete criterion was used to prioritize the security layers in the article.
However, if one were to use the criterion of robustness, the order could be as follows:

1. HVCI/Memory Integrity (uses VBS).
2. WDAC (can be configured to use VBS).
3. The rest.

@Divergent seems to like a similar order.

If the criterion was prevention in Enterprises:

1. Enable MFA.
2. Review VPN authentication logs.
3. The rest.

If the criterion is the popularity of enumeration, we can have for the rainbow:

1. Red
2. Orange
3. Yellow
4. Green
5. Cyan
6. Blue
7. Violet

In this example, the enumeration does not mean that Red is more important for everyone.
The world is full of different orders, depending on the used criterion.

 

[ForgottenSeer 123960]

I am not sure if a concrete criterion was used to prioritize the security layers in the article.
However, if one were to use the criterion of robustness, the order could be as follows:

1. HVCI/Memory Integrity (uses VBS).
2. WDAC (can be configured to use VBS).
3. The rest.

@Divergent seems to like a similar order.

If the criterion was prevention in Enterprises:

1. Enable MFA.
2. Review VPN authentication logs.
3. The rest.

If the criterion is the popularity of enumeration, we can have for the rainbow:

1. Red
2. Orange
3. Yellow
4. Green
5. Cyan
6. Blue
7. Violet

In this example, the enumeration does not mean that Red is more important for everyone.
The world is full of different orders, depending on the used criterion.

Thank you, Andy. You just validated my entire report.

You wrote "If one were to use the criterion of robustness, the order could be as follows: HVCI/Memory Integrity... The rest."

Precisely.

My report is a Technical Security Analysis, not an Art Class.

In Art (Rainbows), Red is not more important than Blue.

In Engineering (Security), The Foundation is absolutely more important than the Paint.

Since you explicitly admitted that Core Isolation comes first under the criterion of Robustness, you agree with my report.

I am not writing about 'Popularity' or 'Rainbows.' I am writing about Robustness against a Kernel Killer.

I'm glad we finally reached a consensus on the only criterion that matters.

Cheers.