SMBv1 – Windows Endpoint Monitoring:
I pray that nobody has SMBv1 actually enabled as of June 2024 however, I have an update to share on this subject with regards to the Windows Endpoint Monitoring collector and workbook.
Previously, the Windows Endpoint Monitoring script was simply checking whether or not the Windows Feature for SMBv1 was installed. If you don’t have it installed it won’t be in use, so this was a good indicator. However, what you really want (and what your auditors will want) is for SMBv1 to be disabled, that way even if the feature gets installed, it can’t be used.
To that end, there is a new V1.2 of the Collector Script which instead checks the three keys responsible for correctly disabling the SMBv1 client and server features.*
*Keep in mind even client devices (Windows Desktop OS) can act as an SMB server so both items need to be disabled. This is done via two policies which ultimately configure three keys which are detailed later on.
That data is then fed into a new V1.2 of the Device Inventory Workbook which has a reworked SMBv1 section to match. You can either upload this new workbook and delete your old copy or, if you had some customization you had done, just open up the new queries and text, then copy them in.
Know that the possible statuses are either “Correctly disabled” or “Incompletely/Not Disabled.” Please understand that devices reporting as “Incompletely/Not Disabled” do NOT necessarily indicate SMBv1 is enabled or in use, it just means it’s not fully disabled which again will likely get you flagged on an audit. The script will output in red to help you determine what is wrong. Additionally, even if you are showing as Correctly Disabled, you should ensure you actually have a policy pushing and enforcing the disablement keys.
The Policy:
For some reason, Microsoft doesn’t document the Intune policy names but they do exist! You can use a Settings Catalog to deploy the setting “Configure SMB v1 client driver” as ENABLED (this is enabling you to configure the driver state, not enabling the driver) with the drop-down then set to “Disable driver (recommended)” to disable the client side. You will also want to deploy “Configure SMB v1 server” as DISABLED to disable the server side. Obviously, test your policies and roll them out carefully.
Note: The original Windows Endpoint Monitoring series has/will be updated to include this same information/links to the new editions.
WMI Commands in Various Collectors:
While setting up a new device and working on the above update, I recently realized a small portion of my script wasn’t working with PowerShell 7.0. After some quick research, I learned this was because the WMI command line (WMIC) commands are headed for the chopping block and some simply don’t work with PowerShell 7.0. See here.
Importantly, it was the GetOwner class on the Get-WmiObject command that had just vanished. As such, I’ve updated this command to use Get-CimInstance to correct this problem. Specifically, this was in use for the section of code which went to explorer.exe as a backup method of determining the current user which was primarily for RDP sessions. This is backward compatible to PowerShell 5.1.
This update has been added to the…
- Sample Collection Script used in the learning series.
- The Windows 365 App Collector.
- The Windows Endpoint Monitoring Collector V1.2.
The prior method is still in the code but commented out in case anyone runs into issues.
That all said, WMIC commands in their entirety are headed for the chopping block, and several of my scripts are still full of them. While a good bit of work, I’d like to track them all down and update them.
Update 6/18/2024: I came back through and made some minor updates to my phrasing to better clarify WMI versus WMIC and what is being retired. Reason being, after doing some research related to another post coming soon, to say WMI is being retired would be incorrect. Rather, the WMIC commands are being retired, but CIM commands still sometimes utilize the WMI database. See here.
Conclusion:
Thanks for your time and happy updating!
Disclaimer:
The following is the disclaimer that applies to all scripts, functions, one-liners, setup examples, documentation, etc. This disclaimer supersedes any disclaimer included in any script, function, one-liner, article, post, etc.
You running this script/function or following the setup example(s) means you will not blame the author(s) if this breaks your stuff. This script/function/setup-example is provided AS IS without warranty of any kind. Author(s) disclaim all implied warranties including, without limitation, any implied warranties of merchantability or of fitness for a particular purpose. The entire risk arising out of the use or performance of the sample scripts and documentation remains with you. In no event shall author(s) be held liable for any damages whatsoever (including, without limitation, damages for loss of business profits, business interruption, loss of business information, or other pecuniary loss) arising out of the use of or inability to use the script or documentation. Neither this script/function/example/documentation, nor any part of it other than those parts that are explicitly copied from others, may be republished without author(s) express written permission. Author(s) retain the right to alter this disclaimer at any time.
It is entirely up to you and/or your business to understand and evaluate the full direct and indirect consequences of using one of these examples or following this documentation.
The latest version of this disclaimer can be found at: https://azuretothemax.net/disclaimer/
Azure to the Max 