Using Perl in the Enterprise
This post isn't specifically about IR and forensics, but it is sorta...tangentially.
I was reading on a blog entry today how to use PowerShell to determine the type of battery in your Dell computer. I thought this was pretty cool...after all, though my systems aren't susceptible, I'm sure there are folks out there, IT admins in enterprise environments, who are wondering how in the world they're going to check all of their systems. Well, the code looks like a pretty good solution, but it's PowerShell. The same thing could be done with Perl or VBScript, particularly if you have access to the MS Scripting Repository.
Anyway, being a Perl kind of guy, I cobbled together a quick script to get my battery type. Then I started thinking...how many times have I been preparing to go on-site, and wanted to know some specifics about the system(s) in question, and received either "I don't know" or incorrect information. What if I had a simple script (CScript) or program (even compiled Perl) that I could send to an Administrator, and they could run and get the answers? So then I added some things to the code and got it up and running. Here's what it looks like when run against my local system:
WinterMute:Win32_Processor
Name = Intel(R) Pentium(R) M processor 2.13GHz
Manufacturer = GenuineIntel
ProcessorId = AFE9FBFF000006D8
WinterMute:Win32_Battery
Name = DELL D55056
Chemistry = 6
WinterMute:Win32_BIOS
Name = Phoenix ROM BIOS PLUS Version 1.10 A04
SerialNumber = 3PYQJ91
Version = DELL - 27d5091e
WinterMute:Win32_DiskDrive
Name = \\.\PHYSICALDRIVE0
Manufacturer = (Standard disk drives)
Model = ST9808211A
InterfaceType = IDE
I then ran it against a VMWare Windows 2000 session:
192.168.1.22:Win32_Processor
Name = Genuine Intel(R) CPU T2600 @ 2.16GHz
Manufacturer = GenuineIntel
ProcessorId = 0FE9FBFF000006E8
192.168.1.22:Win32_BIOS
Name = Default System BIOS
SerialNumber = VMware-56 4d 3a 85 4a bd 0a d6-09 07 50 66 47 ec 6b 96
Version = PhoenixBIOS 4.0 Release 6.0
192.168.1.22:Win32_DiskDrive
Name = \\.\PHYSICALDRIVE0
Manufacturer = (Standard disk drives)
Model = VMware, VMware Virtual S SCSI Disk Device
InterfaceType = SCSI
I guess the VMWare guest OS doesn't think it has a battery. Oh, well.
The code I wrote implements WMI in order to collect its information. Now, I simply wrote a quick script that would collect string values from the various WMI Win32 Classes. There's no limit to what you can do with to collect information from managed systems, and manipulate that information (store it in a database or spreadsheet, sort on it, compare it to previous runs, etc.). It's also an excellent way to perform hardware or software inventories. Say you'd like to check all machines with certain patches installed...there's a class you can use to collect all of the installed patches, and if the one you're interested in isn't on that list, flag the machine.
Okay, so how does this relate to IR? Well, patched machines are generally more secure. Also, I would think that a battery bursting into flames would constitute a "security incident" of some kind. Finally, you can use WMI or other tools to manage your configurations...is that system's audit policy out of compliance? With remote tools you can reach out, collect the Event Logs currently on the system, and then update the audit policy. You can also use WMI to determine how much RAM and HDD space is on a system, as first steps in performing live response.
I was reading on a blog entry today how to use PowerShell to determine the type of battery in your Dell computer. I thought this was pretty cool...after all, though my systems aren't susceptible, I'm sure there are folks out there, IT admins in enterprise environments, who are wondering how in the world they're going to check all of their systems. Well, the code looks like a pretty good solution, but it's PowerShell. The same thing could be done with Perl or VBScript, particularly if you have access to the MS Scripting Repository.
Anyway, being a Perl kind of guy, I cobbled together a quick script to get my battery type. Then I started thinking...how many times have I been preparing to go on-site, and wanted to know some specifics about the system(s) in question, and received either "I don't know" or incorrect information. What if I had a simple script (CScript) or program (even compiled Perl) that I could send to an Administrator, and they could run and get the answers? So then I added some things to the code and got it up and running. Here's what it looks like when run against my local system:
WinterMute:Win32_Processor
Name = Intel(R) Pentium(R) M processor 2.13GHz
Manufacturer = GenuineIntel
ProcessorId = AFE9FBFF000006D8
WinterMute:Win32_Battery
Name = DELL D55056
Chemistry = 6
WinterMute:Win32_BIOS
Name = Phoenix ROM BIOS PLUS Version 1.10 A04
SerialNumber = 3PYQJ91
Version = DELL - 27d5091e
WinterMute:Win32_DiskDrive
Name = \\.\PHYSICALDRIVE0
Manufacturer = (Standard disk drives)
Model = ST9808211A
InterfaceType = IDE
I then ran it against a VMWare Windows 2000 session:
192.168.1.22:Win32_Processor
Name = Genuine Intel(R) CPU T2600 @ 2.16GHz
Manufacturer = GenuineIntel
ProcessorId = 0FE9FBFF000006E8
192.168.1.22:Win32_BIOS
Name = Default System BIOS
SerialNumber = VMware-56 4d 3a 85 4a bd 0a d6-09 07 50 66 47 ec 6b 96
Version = PhoenixBIOS 4.0 Release 6.0
192.168.1.22:Win32_DiskDrive
Name = \\.\PHYSICALDRIVE0
Manufacturer = (Standard disk drives)
Model = VMware, VMware Virtual S SCSI Disk Device
InterfaceType = SCSI
I guess the VMWare guest OS doesn't think it has a battery. Oh, well.
The code I wrote implements WMI in order to collect its information. Now, I simply wrote a quick script that would collect string values from the various WMI Win32 Classes. There's no limit to what you can do with to collect information from managed systems, and manipulate that information (store it in a database or spreadsheet, sort on it, compare it to previous runs, etc.). It's also an excellent way to perform hardware or software inventories. Say you'd like to check all machines with certain patches installed...there's a class you can use to collect all of the installed patches, and if the one you're interested in isn't on that list, flag the machine.
Okay, so how does this relate to IR? Well, patched machines are generally more secure. Also, I would think that a battery bursting into flames would constitute a "security incident" of some kind. Finally, you can use WMI or other tools to manage your configurations...is that system's audit policy out of compliance? With remote tools you can reach out, collect the Event Logs currently on the system, and then update the audit policy. You can also use WMI to determine how much RAM and HDD space is on a system, as first steps in performing live response.