Hi The exploit not work for me.

[betterpreter]

I used your POC in my home lab with Windows 10 version 1909 (OS Build 18363.592), and it mysteriously worked for me only when I first enabled kernel debugging using "bcdedit /set debug on" and then opened Wireshark to listen to the relevant network adapter. I am also using VMware Workstation.

Is there a straightforward condition that needs to be met to make it work without using Wireshark? Additionally, I didn't understand why your guide instructs to shut down the firewall and then re-enable it. If the firewall is on, wouldn't it block the IPv6 packets? Am I mistaken?

[ynwarcs]

hi, to address the firewall question first - the firewall does block IPv6 packets but the vulnerability is present in functions that are executed before the packets are sent to the firewall. This means that you can reproduce the vulnerability even while the firewall is enabled. I suggested re-enabling to make it clear that it doesn't need to be disabled.

as for why the poc isn't working, it's most likely due to packets not being coalesced. In my local tests, having wireshark installed (or running) didn't make much of a difference in behaviour, as long as kdnic.sys was being used (i.e. debugging was enabled). Though I tested via Hyper-V and not in VMware, but I could boot it up later and see if I can reproduce the behaviour you see.

in the meanwhile, you could try a few more times and with increased num_tries or num_batches, just to make sure that it's not being flaky and the wireshark connection was just a coincidence. In Marcus's post, he also mentioned he had to let the target VM run on a single core to let coalescing happen, so you could try that or similar tactics to make the target under more load.

[ynwarcs]

The exact conditions are:

• IPv6 has to be enabled and system able to receive packets (check with ping -6)
• There has to be packet coalescing on the target system

It is easy to verify the first condition but it's hard to verify the second condition. There could be a script that does that (it would check the number of responses to malformed+proper packet duo sent together) but I don't have time to write it and test it, maybe someone else will.

I would be very surprised if you can't trigger the vuln when using the debugging mode. Can you check if your adapter driver is kdnic.sys? Go to adapter options, right click on the network adapter (it should be named something like "Kernel Debugger Adapter"), go to Configure -> Driver tab -> Driver details -> check that kdnic.sys appears in the list. You should also check if the packets are not being sent as broadcast: scapy should print out a warning, but you can verify manually in wireshark by checking the ethernet destination address field. If everything seems OK on these two parts, then I cannot help you much more, you'll need to attach a kernel debugger and step through code to see what's going on.

[Helloyunho]

Tested on VMware Fusion Pro running Windows 11 on arm64. Able to reproduce DoS.

[leber2]

Same here. Can't seem to get it to work.

Do I have to configure something in the target machine? This is the version of the windows if trying to exploit.

Can you point me at the right direction? What I'm doing wrong?

[Helloyunho]

I didn't have to do anything for the exploit to work. But speaking of version, it seems like MS actually patched the exploit with August update. My VM was not updated somewhere between June and July so that's probably why the exploit was able to BSoD it.