Use PowerShell for IT security. Part I: Event Tracking

At a time when I wrote a series of articles on penetration tests to help humanity in the fight against hackers, I came across information about some interesting cmdlets and PowerShell techniques. I made an outstanding discovery: PowerShell is a standalone defense. It seems like a good time to start a new series of publications about PowerShell.



In these publications, we’ll be of the opinion that, although PowerShell will not replace special security platforms ( Varonis employees may breathe a sigh of relief), this tool will help IT professionals track threats and take other security measures. In addition, the IT department will begin to appreciate the wonders of specialized security platforms, such as our Metadata Framework solution. PowerShell can perform interesting security tasks on a small scale, but this tool does not have the characteristics to work with the entire infrastructure.



An important event



To begin, consider using PowerShell as a system monitoring tool for tracking files, processes, and user actions.

')

Before you start cursing me, let me say that I know perfectly well that any command language of the operating system can be used to track events at the system level. Any junior system administrator can configure, for example, a Linux shell script to poll the directory to see if the file has been updated, or to get a list of running processes to find non-standard processes among them.



Now it's not about that.



Instead, PowerShell provides direct event-driven tracking based on the operating system’s access to low-level changes. This is equivalent to receiving pop-up notifications about the latest events on the news site instead of having to refresh the page manually.



In this case, PowerShell will not work without stopping, loading the processor cycles. The script is activated when an event occurs (changing a file or logging on to a new user). Such security tracking is much more effective than screening polls.



Below I will explain how this is done.



Anyone who, like me, has studied operating systems, knows that there is a boundary between user-level processes and system-level processes.



The operating system (whether it is Linux or Windows) handles device actions at the lower level, from reading the disk to receiving packets, and hides it from ordinary applications running on the PC.



Thus, if you run your favorite word processing application and view the first page of the document, the whole operation will look like a smooth and synchronous action. However, all sorts of events actually occur (search on disk, reading disk blocks, sending characters to the screen, etc.) that are intentionally hidden from us. For this you can thank Bill Gates.



Previously, only the severe system engineers knew about event handling at the lower level. Now PowerShell programmers can share this information with pleasure.



OS tool language



Consider the Windows Management Instrumentation (WMI), which is an attempt by Microsoft to ensure consistent viewing of operating system objects.



WMI, which is only a few years old, is part of a large enterprise Internet management system (WBEM) designed to standardize information received from routers, switches, storage arrays, and operating systems.



How does WMI look and work?



For our purposes, the tool is a query language like SQL, but instead of accessing database columns, it provides comprehensive information about the operating system in the form WMI hierarchy. Of course, the query language is called WQL.



Windows has a WBEMTest utility that can be used to interact with WQL. The image below shows a request for a Win32_Process object containing information about the currently running process.





Training work with WQL in WBEMTest



In fact, this is the software equivalent of Windows Task Monitor. Impressive, isn't it? If you want to learn more about WQL, download Ravi Chaganti's excellent e-book on this topic.



PowerShell and Register-WmiEvent Cmdlet



But that is not all. From training tasks in WBEMTest, you can go to queries directly in PowerShell.



The PowerShell cmdlet Get-WMIObject suitable for this. It allows you to send a WQL query directly as a parameter.



The image below shows the first few startup results of select Name, ProcessId, CommandLine from Win32_Process in the AWS test environment.





gwmi is Get-WmiObject in PowerShell



The result is a bit unreliable, as there are some hidden properties related to the main class of data logging. In addition, this cmdlet gives an impressive list in the console.



To improve Win32_Process, I moved the query result to Out-GridView , a PowerShell cmdlet that formats the data into a neat table based on a graphical interface.







Not bad for a PowerShell code line. But the WMI service is capable of more than just requesting OS objects.



As I mentioned earlier, it gives access to the relevant events of these objects. In WMI, these events are roughly divided into three types: create, modify, and delete.



Before the release of PowerShell 2.0, access to these events had to be obtained in an intricate way: creating many different objects, after which a synchronous hang occurred, so this was not real asynchronous event handling. For more information, read the MS Technet post.



Now the Register-WmiEvent in PowerShell 2.0 allows you to respond to events in a more acceptable manner. In other words, when an event occurs, a call triggers, which can be registered.



Let's return to my fictional (and already famous) company Acme, whose IT infrastructure operates in the AWS environment.



The system administrator (let's call him Bob) from time to time notices that the place on the Salsa server ends. He suspects that Acme CEO Ted Bloutley uploads large files, such as audio, to one of Bob’s directories, and then transfers it to his Taco server.



Bob wants to create a trap: it is necessary that when creating a large file in the main directory, a notification appears in his console.



To do this, he needs to work with the CIM_DataFile. class CIM_DataFile. Instead of accessing processes, as we did earlier, Bob uses this class to connect to the main file's metadata.





In PowerShell, you can directly access the CIM_DataFile object.



As Bob, I created the following Register-WmiEvent , which will send notifications to the console when creating a large file in the main directory.



Register-WmiEvent -Query "SELECT * FROM __InstanceModificationEvent WITHIN 5 WHERE TargetInstance isa 'CIM_DataFile' and TargetInstance.FileSize > 2000000 and TargetInstance.Path = '\\Users\\bob\\' and targetInstance.Drive = 'C:' "-sourceIdentifier "Accessor3" -Action { Write-Host "Large file" $EventArgs.NewEvent.TargetInstance.Name "was created”}



Running this script directly in the Salsa console activates the Register-WmiEvent command in the background, assigning it a job number. Further interaction occurs only when an event occurs.



In the next post I will talk about this in more detail. In fact, I use WQL to query from the \ Users \ bob directory of any CIM_DataFile object in excess of 2 million bytes. When you create a file that meets the conditions, a notification appears, for which InstanceModificationEvent. is activated InstanceModificationEvent.



In any case, playing the role of Bob, I ran the script from the PowerShell command line, and then, like Ted from our story, I copied a large MP4 file into the Bob directory. You can see the result below.







Now we know that Ted is a fan of Melody Gardo. Who would have thought!



The publication demonstrated some amazing possibilities of using PowerShell as a tool for detecting threats and a small analysis of behavior.



We will continue to explore these aspects in the following articles.