The Get‑CimInstance is a powerful cmdlet used to
retrieve instances of the CIM classes.
CIM stands for the common information model,
which is a standard for defining and organizing systems and application data.
The CimInstance cmdlet is part of the PowerShell CIM cmdlets,
which are used to work with the CIM infrastructure in Windows.
Overall,
the Get‑CimInstance cmdlet is a powerful tool for retrieving
information about a wide range of system and application data
in your Windows environment.
When you use the Get‑CimInstance cmdlet,
you specify the name of the CIM class that you want to retrieve
instances of. Now here are four examples, but there are literally
dozens and dozens more options you can go through to find specific
data you are looking for.
For example, if you want to retrieve information about the operating system,
you can use the Win32_OperatingSystem class. I want to start this demo with
some basic scripts that look at the configuration of various aspects of our
systems using the Get‑CimInstance function with the Win32 class. First, the
operating system, which pulls from, as you would suspect, the Win32 operating
system class. For this demo,
I begin with the Windows Client VM and look to pull some
basic operating system information back.
Nice to see the version and build here, that lets me know if core patches
and maintenance is being applied to the server or not. If you run the
script throughout, it is an easy way to see if you have systems on the
network that are not meeting our minimum standards, but this object has
so much more data buried, so let's pull the rest of that out by piping
this into a selectAll statement to show all the categories of the
operating system.
Ah,
there you go, much better, you probably noticed the
screen scrolled by pretty fast.
This will allow me to see things like when the system was installed,
who is it registered to, back up top here, the time zone the machine
is in. Now that is handy if you have remote work environments or if
you have data centers spread across regions. And as I mentioned in
the last run, the version of the operating system.
Okay,
next, let's dip our toe into incident response waters and have us scroll
through the processes that are running on the machine currently. I can then
narrow down to a specific process with a filter.
You will see each of these columns has a heading that can be dropped into the
filter and used to narrow the list down. Here, I want to see all the Visual
Studio Code processes running. When I run that,
I will see all the threads from the program and some
basic information like the handle count,
which is an indication of how much resources the process has
taken up. Now just like the operating system, I can expand these
results out and see the full object.
So now, each of those code processes you saw there will
display their full object list. Quite a lot of data. Now
depending on the size of these things,
you may start to thinking about dropping the results into a CSV file
or text file to make the formatting easier to read.
Now interesting enough as I scroll through here,
this detail does not have who the registered user that started the
process is. This is something we'll come back to in the next section,
but jumping over to my main host machine now, I would say these classes
are pretty wild, what you can dig into.
There is a Get‑CimClass cmdlet that allows you to display the entire list.
As you can see, I will be scrolling for a little bit, so
what I recommend is finding a topic and performing a
specific wildcard search on that topic.
In this case, I want to see all the classes tied to the BIOS. Within our
security program, we try to control what is plugged into our machines. A lot
of the time, this is handled with policies and tools on the machine, but
taking a look at the logical disk class,
I can see I have a C drive and a D drive, which will pique my interest a little.
I do have a side script here for USB. Utilized inside here
are two more commands that look for the USB interfaces in the
results of the disk drive class.
Then, drive type 2, which is removable drive in the logical disk class,
which is the same class from the previous run in the other script, but
with the filter to only display removable drives.
Now looking at this,
I was hoping there would be more information on the manufacturer,
serial, signature, but I'm not seeing anything, but that information would
tell me what type of drive it was and if it was a supported drive in our
policies. But definitely confirms it is plugged in here.
Okay, looking at the next section of commands,
looking at network adapters. I would highly recommend not displaying
all objects by default with this, and instead applying a filter to
narrow down to what adapter you want to see.
There will be a ton of information dumped on your screen otherwise.
So nice that it shows the IP address, DNS, domain, among the other
info, this will help determine if the system is connected to the
company network, VPN, or other service.
Now,
earlier I showed you how I could see various processes running on the machine.
Here is a cmdlet for viewing the users. Good information, but just
want to show there is a CIM instance that has the class for that,
and not only who are the users on the machine, but who is currently
logged into the machine, which in some cases is probably more important.
Okay,
pulling this back into a security conversation, the classes go
beyond Win32 options. Here is one that will dive into the
details of the antivirus installed.
In this case, it pulls back that Defender is installed on the machine.
Because Defender is a service that runs on the machine,
I have another script here, I can utilize the Win32 service class to
pull back more details on the Defender session. Ideally, it is
running, and if I selected the entire object,
I can see when it was last updated and started,
but I'll dig into that into another video.
Okay, I'll hold off on working my way through the rest of this script for now,
as the next section on invoking the CIM method ties
nicely into what we see here.