TL;DR: PowerShell Scanner expands what PDQ Connect can collect by letting sysadmins bring custom PowerShell results into device pages, dynamic groups, filters, and reports. If PowerShell can find the data, Connect can help you track it alongside your existing inventory details.
The PowerShell Scanner is now available in PDQ Connect, giving sysadmins a way to run custom PowerShell scripts across managed devices and return the results directly to Connect. It is one of PDQ Connect’s most requested features, so huge shout-out to our passionate users and fans who’ve been pushing for this feature, and major kudos to our dev team who made it a reality. Remember, it’s not about the destination; it’s about the feature requests you’ve submitted along the way.
To celebrate the launch, the PDQ Live webcast dove into all the details about the PowerShell Scanner. What it is, what the development process looked like, and even demoed a handful of PowerShell scanners covering everything from hardware audits to security checks that would make your SOC analyst proud. If you’re new to the PowerShell Scanner, this recap will give you everything you need to know to get started, as well as some useful scripts to jump-start your experience.
What is the PowerShell Scanner?
The PowerShell Scanner is a feature that lets you run custom PowerShell scripts against your managed devices and return the results to PDQ Connect.
If you’re familiar with PowerShell, you’ll know that you can run commands to return data. For example, I can run Get-CimInstance Win32_VideoController to return information about the video card installed on an endpoint. A PowerShell Scanner takes this concept to the next level by returning that information to PDQ Connect.
The process is simple. You write a PowerShell script, define what data comes back, upload it as a PowerShell Scanner, and PDQ handles the rest. The data is refreshed every time your devices get scanned and shows up everywhere else in the product: device records, dynamic groups, filters, and reports.
Why PowerShell scanners are a big deal for PDQ Connect
By default, PDQ Connect collects a ton of great information covering system, software, hardware, Windows updates, services, and more. But built-in coverage will never account for the specific, weird, particular things you need to know about your specific, weird, particular environment. PowerShell scanners fill that gap.
Need to know which machines have local admin accounts that crept in while nobody was looking? PowerShell Scanner. Need to audit every browser extension across your fleet because another credential stealer is making headlines? PowerShell Scanner. Want to verify that LSA protection is actually running instead of just sitting in Group Policy feeling good about itself? PowerShell Scanner. If PowerShell can reach the data, you can surface it in Connect without waiting on anyone to ship a new built-in feature.
For security-focused sysadmins, the ability to write custom detection logic, assign risk scores to findings, and build dynamic groups around the results is a meaningful upgrade in visibility. You can't defend what you can't see, and the list of things you can now see just got a lot longer.
Why did it take this long to add PowerShell scanners to Connect?
PDQ Inventory has had PowerShell scanners for years, so the question of why it took this long to add them to Connect naturally comes up. The answer really comes down to cloud versus on-prem architecture.
Inventory is a traditional on-prem tool. Every customer has their own database, their own isolated environment. Connect runs on a shared cloud infrastructure, which introduces a different set of engineering constraints that do not exist when everyone is managing their own installation.
The harder problem is that PowerShell scanners are completely dynamic by nature. One scanner might return three columns of battery data. Another returns 28 columns of mixed data types from a custom security audit object. Designing a system that can store arbitrarily shaped data in a shared cloud database in a way that stays fast, efficient, and scales across a large customer base is not a trivial problem. It took time to do it right.
Again, huge shout out to the dev team because the results speak for themselves. A scanner that supports the full range of data types, handles the dynamic column structures, and performs the way you would expect it to, pretty damn quick.
Highlighted PowerShell scanners from the PDQ Live webcast
A majority of the PDQ Live webcast was dedicated to showing off useful PowerShell scanners to help users get started. Here’s a rundown of all the scanners we covered during the show.
Default web browser: Returns the default browser set for each user profile on a machine, plus a list of all installed browsers. Useful for enforcing browser standards or tracking down why that one internal app keeps breaking for certain users.
Graphics card inventory: Pulls GPU model, VRAM, driver version, driver date, and current resolution per device. Handy for planning driver rollouts or identifying machines that are going to have a bad time running anything GPU intensive.
Local admin members: Enumerates every member of the local Administrators group and returns them as individual rows. Build a dynamic group off this, and you will know the moment someone gets added who should not be there.
Monitor information: Returns manufacturer, model, serial number, manufacture date, native resolution, diagonal size, and connection type per display. Solid for hardware audits and settling the age-old debate of who has the nicest monitors in the office.
Browser extensions: Inventories Chrome, Edge, Brave, Vivaldi, and Opera extensions across all user profiles on a machine. Malicious browser extension stories show up in the news at a steady clip. This scanner means you can check your entire fleet in minutes instead of relying on the honor system.
VS Code extensions: Same concept, applied to VS Code. Extensions are a platform unto themselves and can absolutely do harmful things. This scanner uses Get-ChildItem to walk user directories since the built-in VS Code cmdlet only works for the currently logged-on user.
Secure Boot certificate check: Verifies whether the Windows UEFI CA 2023 certificate is in your Secure Boot database and whether a Secure Boot update is staged and pending a reboot. Built through a community collaboration on the PDQ Discord. Thanks to Joshua D. and Marcel for helping build this scanner.
Suspicious scheduled tasks: Scheduled tasks are one of the most popular hiding spots for threat actor persistence, and there are so many of them on any given machine that a malicious one can blend right in. This scanner filters out tasks from known-good publishers and scores everything else based on risk indicators: unsigned binaries, paths outside of Program Files or System32, and tasks invoking PowerShell or cmd.exe with arguments. A score of 3 or higher means go look at it. Build a dynamic group off the score column, and you have lightweight, ongoing detection coverage for free.
Unquoted service paths and writable service binaries: A classic privilege escalation technique. When a service binary path contains spaces and is not wrapped in quotes, Windows will attempt to execute each space-delimited segment as a complete path. If a low-privileged user can write to any of those locations, they can place their own binary there and have Windows run it as SYSTEM. This scanner flags both unquoted paths and service binary directories that non-privileged users can write to. If it returns results, those are real, actionable vulnerabilities.
LSA protection and Credential Guard status: Mimikatz has been around forever and everyone in Windows administration knows what it can do once it has access to LSASS. The standard defenses, LSA protection, virtualization-based security, and Credential Guard, are well documented and most organizations have them configured somewhere in Group Policy or Intune. The catch is that "configured" and "actually running" are two different things, and most people never check the difference. This scanner checks actual runtime status rather than just reading registry keys. You get confirmation that VBS is running, that Credential Guard is active, and that the underlying dependencies like TPM and Secure Boot are where they need to be. It also returns a timestamp on each assessment so you can filter on stale data and know when you're looking at current results versus something that ran three weeks ago.
Pinned taskbar items: Walks every user profile and returns whatever each user has pinned to their taskbar. Mostly a fun one, but it demonstrates a solid technique for reading data from user space via HKU that translates well to other use cases. One note from the webcast: Release the COM object at the end of the script. If you hold a lock on a user profile while that user is in the middle of logging in or out, you will orphan their profile and generate a help desk ticket from someone who is very confused about why Windows gave them a temporary account. Ask someone who has done it.
Get the scripts
All the scripts from the webcast live in the PDQ Bonus Content GitHub repo. They are documented, ready to run, and built to be modified. Adjust the scoring thresholds, add columns, and tighten the filters to match your environment. Run them as they are or use them as a starting point. However, as with any internet script, always read through it to understand what it’s doing, and test it before just sending it.
How to create a PowerShell Scanner to PDQ Connect
Creating a PowerShell Scanner in PDQ Connect is a super simple process, especially if you’ve already got your PowerShell script ready to go.
In PDQ Connect, click Scanners, then click Create scanner.
Name the scanner, then click the Type dropdown and select PowerShell.
Click Import .ps1 to import an existing PowerShell script, or enter your script into the scripting window.
When you’re ready to test your script, select a device in the Select test device field, then click Run script.
The output should return from the test device for you to validate, after which you can enable and save the scanner.
One thing to note is that PDQ Connect automatically attempts to assign the correct data type for the returned results. If an incorrect data type is chosen, you can manually change it while you’re validating the output.
With the scanner saved and enabled, it will automatically run against your devices during the normal PDQ Connect scan cycle. To see the results, just click on a device, click the PowerShell menu item, and select the name of the PowerShell Scanner.
Start scanning
PowerShell scanners in PDQ Connect help sysadmins collect custom endpoint data that standard scans do not capture. Hardware data that used to live in spreadsheets, security checks you ran manually once and meant to automate, software configurations you had zero visibility into until something went wrong ... all of it can now run on a schedule, feed dynamic groups, and show up in reports.
If you’re already a PDQ Connect customer, the PowerShell Scanner is ready and waiting for your first PowerShell script. If you’re not, start a free trial and see what your fleet has been hiding from you.
