For several years, I have been setting up VMs with 2-3 year old versions of Windows as well as some additional applications to demonstrate two-stage exploits using Metasploit for educational purposes (more precisely Bachelor-level IT security courses).

This year, I set up a Windows VM from an x86 1803 ISO, installed Firefox 38 and successfully and reproducibly managed to obtain SYSTEM privileges after first using exploit/windows/browser/firefox_smil_uaf (both on its own and via browser_autopwn2) and subsequently exploit/windows/local/appxsvc_hard_link_privesc. This VM works perfectly and I have a restore point from before any attacks that I can go back to and successfully use both exploits.

However, when trying to build a new VM for the course from scratch, I cannot get any of the two exploits to work (Windows Defender detects them as malware every single time). I use the exact same ISO file and installed the exact same software - I kept a folder of all binaries/files as well as a log of every setting that I changed. I tried setting up the Windows VM at least three times now, but every time, Windows Defender detects the exploits, whereas they work flawlessly (i.e., undetected) in my first VM. The VMs have the same amount of memory etc. None of them is connected to the Internet at any time.

How can I find out what difference exists between the VMs (my first, working one, and all the others that I set up based on my notes)? There must be some difference that I missed or accidentally misconfigured. I did not touch any Windows Defender settings in any of the VMs.

A workaround would also be fine for me. I already tried to set the payload(s) to windows/meterpreter/reverse_winhttps and used different encoders, but to no avail in the new VMs. In my first VM, the exploits always work, regardless of the payload or used encoder. Any clues are appreciated.

  • 1
    Do you set up the VM with internet connection? If so, then the problem is probably that Windows Defender signatures get updated before you run the exploit. Workaround: Turn off Real Time Protection before running the exploit.
    – nobody
    Aug 31, 2021 at 8:43
  • @nobody: There is no Internet connection (not even during the setup of Windows). Aug 31, 2021 at 10:46
  • what other software was installed? ... could the updated signatures have come in via this route?
    – brynk
    Sep 6, 2021 at 19:12
  • 1
    does setting the host clock back to earlier times affect the outcome? (you may also need to do it in the bios as well)
    – brynk
    Sep 7, 2021 at 0:28
  • 1
    agreed checking timestamps etc would be like looking for a needle in a haystack - another option might be to use the Sysinternals tools to scrutinise the running procs and then compare the hashes - i think the newer versions can show/ dump digests of binaries? (or, at least, versions?) procexp and procmon
    – brynk
    Sep 7, 2021 at 21:47

1 Answer 1


I don't know how it became active on your guest VM, but the software you mention in your last comment is highly likely the root of your interference. From Enhancements to Behavior Monitoring and Network Inspection System in the Microsoft anti-malware platform 2018 (I couldn't find the 2013 ref):

NIS is our zero-day vulnerability shielding feature that can block network traffic matching known exploits against unpatched vulnerabilities.

When a new zero-day unpatched vulnerability is widely found that affects Microsoft products, we can release a NIS signature to block that exploit on any machine with NIS enabled. This activates NIS to do synchronous inspection. After the vulnerability is patched, we can de-activate the signature

More NisSrv.exe Hoffman'18 and more at gHacks Brinkmann'17.


I haven't tested any of these yet, so take them with a grain of salt - please provide feedback and I'll update this answer if any of these work ...

1. The first link in this answer offers the following, which seems to imply that you should be able to configure this and turn it off:

By providing two distinct configuration features, we hope all machines will have NRI enabled, while still providing the option to enable NIS according to your performance requirements.

  • Disable Network Inspection System – this will prevent all zero-day vulnerability shielding signatures from loading on the machine
  • Disable Behavior Monitoring – this will prevent all NRI BM signatures from being loaded on the machine

2. It also mentions that it disables itself if another virus scanner is present - maybe in your earlier configuration you installed some virus scanner and then disabled on-access scanning?

3. Or, if the disabling config item is not apparent, the Sysinternals suite that you've got a hold of may help (be sure to 'right click > Run as administrator'):

  • first off i would try autoruns.exe which is in the this tool will allow you to 'tick' and 'untick' services ed: that run at start up, and it will modify relevant registry keys to (from memory) remove the service key/s from the part/s of the registry where they will be identified as active services (to be loaded at run time)
  • I would see if I can find the NisSrv.exe malware signatures, but I can't readily find any info on where these might be on disc, but, procmon.exe filtering to observe file and disc activity will reveal this information if it's stored on disc, or possibly also watching registry if the sigs are stored there - set up monitoring and filtering first, and then introduce your test

4. You might also be able to revoke or reduce the permissions under which this service runs, thereby preventing it from being able to operate properly. (Sorry, I can't remember how to change the account under which service processes run - I think it is in service manager?)

  • Regarding 1, I can find no settings that sound similar to these. In the Windows Defender settings, I verified that any advanced options I could find were identical between the two VMs. Regarding 2, I can say for sure that no other virus scanner(s) have been involved on any of the two machines. I also did not change any Windows Defender settings. Regarding 3, autoruns shows WdNisSvc being enabled (they are ticked). I could not find any signatures so far. Regarding 4, the accounts are identical. In both VMs, the service is set to start manually, but only in one of the VMs it is running. Sep 9, 2021 at 9:30
  • For anyone encountering this in the future, I would like to add that I found the trigger, even though I was not able to find the actual reason. It turns out that my two VMs only differed in their VirtualBox setting on what OS they were emulating. In my exploitable VM, I accidentally chose Win10 64-bit instead of 32-bit. I was just able to reproduce that a completely fresh install of a Win10 1803 x86 ISO with only this setting leads to the "Network Realtime Inspection Service" being in a stopped state. Why this is the case, I have no idea, but my question is answered as I found the difference. Sep 9, 2021 at 12:05

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .