How to find discrepancy between exploitable and unexploitable VM

Question

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.

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.

STRATEGIES FOR DISABLING

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?)