Who’s Being Promiscuous in Your Active Directory?

Simon Price — Tue, 15 Sep 2009 00:18:50 +0000

I’m always a fan of more queries and peaks at what is going on in my AD domain, especially at what is happening on the workstations. I was working on some WMI queries to get information about network interfaces using the Win32_NetworkAdapterConfiguration class, and thought about promqry.exe. Promqry is a tool provided by Microsoft to query a computer’s network interfaces and return if it is running in promiscuous mode.

This information can be handy for several reasons:

An interface running in promiscuous mode may be due to the user running network sniffer such as Wireshark.
An interface running in promiscuous mode may be due to the user running virtualization software, such as Virtual PC.
An interface running in promiscuous mode may be due to malicious code.

I definitely want to know if users are running network sniffers, or virtualization software (likely the guests are not licensed or managed causing rogue workstations in the environment). Of course any potential activity that may be caused by malware or malicious code is a concern as well.

You could very easily download promqry and run a for loop against your machines. I wanted to use WMI for this task instead and rather than a text file, use the directoryservices object to query my AD for computers.

I couldn’t find any property in Win32_NetworkAdapterConfiguration to check for this, but I found this post on promqry which tracked down the WMI classes it uses. That led me in the right direction. The other key to this is what MSNdis_CurrentPacketFilter returns. Microsoft documents this here and we are checking if the NDIS_PACKET_TYPE_PROMISCUOUS bit is enabled.

Below is a quick Powershell script which will grab computer objects from AD, then use WMI and the MSNdis_CurrentPacketFilter class to check for promiscuous mode. You can incorporate this WMI query with Win32_NetworkAdapterConfiguration and get a better picture of the interface network settings:


$ErrorActionPreference = "SilentlyContinue"

$PingTest = New-Object System.Net.NetworkInformation.Ping
$Filter = "(&(ObjectCategory=computer))"
$Searcher = New-Object System.DirectoryServices.DirectorySearcher($Filter)
ForEach ($comp in $Searcher.Findall()) {
    $strComputer = $comp.properties.item("Name")
    write-host "Checking: $strComputer"
    if ($PingTest.Send($strComputer).Status -eq "Success") {
        $colComputer = get-wmiObject -class "MSNdis_CurrentPacketFilter" -namespace "root\WMI" -comp $strComputer
        if ($colComputer -eq $null) {
            write-host "Couldn't connect to WMI" }
        else {
            foreach ($comp in $colcomputer) {
                $val = $comp.NdisCurrentPacketFilter
                if ($val -band 0x00000020) {
                    $inst = $comp.InstanceName
                    write-host "Interface: $inst"
                    write-host "The NDIS_PACKET_TYPE_PROMISCUOUS value is set" -foregroundcolor red -backgroundcolor yellow
                }
            }
        }
    }
    else { write-host "Could not ping, machine not queried." }
}

The following screenshot shows the results. I don’t like waiting for RPC to time out when the machine is off or not reachable, so a quick ping check before querying WMI speeds things up. Also, when an interface has the bit set, the output is highlighted with red text and a yellow foreground. You could wrap an email function and schedule this so that you are alerted when it comes up.

You will need proper access to the workstations to query root\WMI so when you run this in a domain, your account should have local administrator privileges to the computers it will query. If it doesn’t, the command will return “Couldn’t connect to WMI”.

Finally, if you haven’t looked at the MSNdis class yet, I suggest taking a look, especially at MSNdis_80211 which will query various wireless information that may be of interest. There isn’t a whole lot of documentation on it, so I’ll work on getting some details together and maybe draft a Powershell script to find wireless adapters and networks they are connected to or available networks close enough to connect to. Until then, enjoy finding those promiscuous mode adapters in your domain.

Related Posts:

Windows Task Scheduler: Backwards Incompatibility

Simon Price — Mon, 07 Sep 2009 01:49:35 +0000

Scheduled tasks are plentiful in most environments. Managing them is typically a nightmare. You have some running to truncate and copy off logs someplace, or others to run a proprietary backup utility to dump a copy of your Quickbooks data; whatever the reason, over time there are more and they are everywhere. Typically, you want to know that they exist, when they are scheduled to run, and most importantly who they are going to run as. (Look our for password expirations!)

Unless you have invested in an enterprise solution for tasks, you are using Windows Task Scheduler and have the tools included with the Windows OS to do the trick. This article is to point out two major snafus you may come across when attempting to manage scheduled tasks across your environment:

Using WMI class versus the task scheduler API and what effects it has.
New versions in Vista / Windows 7 / Windows 2008 that do not work with XP / 2003.

The first item is more for those who attempt scripting and programming to manage the tasks across machines in the environment. WMI has a class called Win32_Scheduledjob which does quite a bit for managing tasks. However, any tasks created with or modified by the task scheduler API (such as through the task scheduler GUI or schtasks.exe) will cause the tasks to no longer be managed by WMI. For example, if you create a task using schtasks.exe, this tasks will not be returned in a WMI query; or, if you create a task using WMI, but then modify it with the task scheduler GUI, it will also no longer turn up in WMI.

So, Win32_Schedulejob is not a great option and we go about our business using the GUI and schdtasks.exe. We move on to our second issue, which is the backwards incompatibility for those using Vista, Windows 7 or Windows 2008. For example, from my Windows 7 workstation, if I use schtasks.exe or the Task Schedule MMC snap-in, I can query, manipulate, create tasks on Vista, Windows 7 or Windows 2008. When I attempt to reach a Windows XP or Windows 2003 machine, I get Access Denied. Running the older XP version of schtasks.exe did not return errors when run against any version OS. This is painful. The solution is to run the management commands from an XP or 2003 machine, or to copy the schtasks.exe and schedsvc.dll files from those version into a directory on your Vista / Win7 machine and run it from there. See this screenshot using both versions of the tool from my Windows 7 workstation, querying a Windows XP machine. I printed the file version each time to show the newer copy fails with Access is Denied.

You may very well have proper access, but this Access Denied means you have a newer version of the tool.

This Technet article explains what is new in Task Scheduler 2.0 (Vista and above) compared to 1.0. There are many new features, but I would have liked to have a schtasks.exe and a MMC snap-in that was backwards compatible to manage older versions.

One last note is that .job files from XP/2003 are not compatible with the newer Task Scheduler 2.0 (xml format). I’ve seen that folks used the older schtasks.exe to dump the task information in table format, than use Excel to properly edit it to the valid xml format.

Related Posts:

Praetorian Prefect » WMI

Who’s Being Promiscuous in Your Active Directory?

Windows Task Scheduler: Backwards Incompatibility