Debugging Windows Discovery Using Powershell

I’ve worked with Windows systems for most of my career in technology, and one thing that cannot be understated is the power of Powershell. Powershell is like any other command line tool; give it a command, and it does a thing. This is obviously the expectation, but when you introduce other systems sending commands as well as using their own modules, it can get really confusing when trying to determine what powershell is or isn’t doing. 

So, for some context, when Windows discovery is initiated from ServiceNow, it runs a series of PowerShell commands to retrieve various bits of information from the system it’s interrogating. This is done by the MID server importing multiple modules, creating a remote connection to the target machine, setting some variables, and then running the commands to retrieve outputs that will then be used in your discovery patterns. When this works, it’s a beautiful thing.

This brings us to debugging

Debugging a system that has custom modules running commands on remote machines, capturing errors, and spitting them back to you with a wonderfully verbose “Access Denied” error is almost as useful as a screen door on a submarine. Luckily, there are more efficient ways to debug. In this next section, I will walk you through importing the modules required to run those elusive discovery commands directly from your MID server.

The first thing you will need is the ability to log in to your MID server via RDP or your remote desktop application of choice,  with admin privileges. Once connected, we can start the module import process. 

Open Powershell as an administrator and run(replacing <MIDSERVER> with the name of your MID folder): 

C:\ServiceNow\\agent\scripts\PowerShell\

Then you can run the following command to see a list of files in your current directory:

dir

At this point, you have a couple of options:

• You can import each module individually, you will also need to import the modules in subdirectories
• Or you can run the script below to import everything(replacing <MIDSERVER> with the name of your MID folder):

Get-ChildItem -Path "C:\ServiceNow\\agent\scripts\PowerShell" -Recurse -Filter *.psm1 | ForEach-Object { Import-Module $_.FullName }

NOTE: You may see a few warnings, but this is expected.

The last thing we need to do is set our remote computer and credentials to be used. You can do that with the following commands:

$credential = Get-Credential ## This will prompt you for discovery credentials
$computer = "localhost" ## Replace localhost with the name/ip

Now that we have set our credentials and remote computer name/ip we can pass that information into our commands.

At this point, you will be able to run any command that discovery runs during its Identification/Classification/Exploration phase. So, capture the command from your MID log and run it to your heart's content. This should give you a really good indication of where and when discovery is breaking. Below is an example of a command that was captured and troubleshot using this method. 

Method Example

This is the debug log we pulled from the MID (the highlighted portion is the command we will run):

2024-08-13 11:39:38
DEBUG (Worker-Expedited:PowershellProbe-fb31213c87045290abc962cd0ebb35d3)
[PowerConsole:237] execute(& { fetchMultipleWMI -wmi "false"  -output_format "json"  -WMI_FetchData "root\virtualization\v2\Msvm_ComputerSystem.Name,HKEY_LOCAL_MACHINE/SYSTEM/CurrentControlSet/Services/Tcpip/Parameters/Domain,HKEY_LOCAL_MACHINE/SYSTEM/CurrentControlSet/Services/Tcpip/Parameters/Hostname,root\MSCluster\MSCluster_Resource.PrivateProperties,root\MSCluster\MSCluster_Resource.Name,root\MSCluster\MSCluster_Node.Name,root\MSCluster\MSCluster_Cluster.Name,root\MSCluster\MSCluster_ClusterToResource.GroupComponent,root\MSCluster\MSCluster_ClusterToResource.PartComponent,root\MSCluster\MSCluster_ClusterToNode.Antecedent,root\MSCluster\MSCluster_ClusterToNode.Dependent,root\virtualization\Msvm_ComputerSystem.Name,root\MSCluster\MSCluster_Resource.Type,Win32_ComputerSystem.Domain,Win32_ComputerSystem.Name,Win32_OperatingSystem.Caption,Win32_OperatingSystem.Version" ; } | Out-String | ForEach-Object { [Console]::WriteLine($_) }), command id: 729466fe-5488-49a4-8f42-00be6a53032b

Now we’ve identified the command we can insert our credentials and computer and try locally, which looks something like this: 

fetchMultipleWMI -computer $computer -cred $credential -wmi "false" -output_format "json"  -WMI_FetchData "root\virtualization\v2\Msvm_ComputerSystem.Name,HKEY_LOCAL_MACHINE/SYSTEM/CurrentControlSet/Services/Tcpip/Parameters/Domain,HKEY_LOCAL_MACHINE/SYSTEM/CurrentControlSet/Services/Tcpip/Parameters/Hostname,root\MSCluster\MSCluster_Resource.PrivateProperties,root\MSCluster\MSCluster_Resource.Name,root\MSCluster\MSCluster_Node.Name,root\MSCluster\MSCluster_Cluster.Name,root\MSCluster\MSCluster_ClusterToResource.GroupComponent,root\MSCluster\MSCluster_ClusterToResource.PartComponent,root\MSCluster\MSCluster_ClusterToNode.Antecedent,root\MSCluster\MSCluster_ClusterToNode.Dependent,root\virtualization\Msvm_ComputerSystem.Name,root\MSCluster\MSCluster_Resource.Type,Win32_ComputerSystem.Domain,Win32_ComputerSystem.Name,Win32_OperatingSystem.Caption,Win32_OperatingSystem.Version"

If the command returns an error, you will be able to determine the module that is being used, the error message, and where the error occurred. Now, continue troubleshooting as you normally would, but this time much faster with more verbosity. 

‍Interested to learn more or need some help troubleshooting? Reach out to us at chat@rapdev.io