Skip to main content

Vynae - process exploration in PowerShell

Vynae can be found on my GitHub.

Vynae is a fleshed-out version of the original project, PidHunter. PidHunter was written for use in the Collegiate Cyber Defense Competition for tracing process IDs and gathering simple information about processes running in Windows Server environments. It started as a lightweight script that could be deployed on multiple servers and return consistent results. Mainly, it was used to detect Crowd Strike beacons after we discovered one of our servers had a beacon running on it. I wanted a way to pull up process and network information on the fly without needing to run multiple commands or tools. As such, it was hyper-specific to the situation I was in. While I originally tried to expand PidHunter to be useful in normal operations, it never really took off and was abandoned.

Cue summer semester 2022 where I found I had a good amount of extra time before classes started in earnest. I needed to take a break from some other projects, and as I'm taking an IR class this summer, I wanted to work on a project related to that. As I was digging through some older projects, I came across PidHunter and decided to roll with it. I very quickly realized that PidHunter was not something that could be updated without fully restarting it from bottom to top. To begin with, it relied entirely on WMI instead of CIM and used conversions to take the PowerShell objects and convert them into string variables for output formatting. This cut out a lot of functionality and advantage that PowerShell has when working with objects, and heavily reflected the inexperience I had writing PowerShell code at the time.

A little side note, Windows Management Framework is a Microsoft version of the open-source standard Common Information Model. CIM provides the same access as WMI, while also being more secure to use, and having more future-proofing as Microsoft is deprecating WMIC and likely WMI at some point. They seem to have been moving away from WMI to the more secure WinRM.

Moving on, after I decided to start from scratch on Vynae, I also wanted to create a more distinct output that was easier to understand at a glance. Unfortunately, I originally decided on re-writing the process tracing and information gathering functions of PidHunter, so I stuck with hardcoded Write-Host output formatting. As feature creep rose, the viability of this solution sunk greatly. One of the future updates will pass all formatting to a special function, allowing the actual process handling functions better readability. Regardless, I made the choice to have the most important information output in green and, in the case of a bad result, red. This allowed a break in the standard white on blue and made parsing through the results visually, easier.

Regarding feature creep, Vynae added network connection filtering, hashing, improved PPID tracing, and process spawn tracing. PidHunter only supported the display of certain process information and filtering by name or ID. As these features came to mind, they were added to the code without much planning or thought. This led the code to be rather redundant, leaving each function self-contained. The code then is somewhat lacking in readability and conciseness. This is something to be addressed at some point in the future but isn't a large issue for the moment.

Keeping in mind the intended features and the outcome goals (Using CIM and output formatting), I decided to use parameters instead of relying purely on arguments as PidHunter had. I hadn't used parameters in PowerShell scripts before, and a lot of the earlier code reflects that. Instead of directly using the values of the parameters in individual functions, I tended to pass them as variables and then use the value of the passed variable within the function. While this isn't a terrible issue, it does lead some functions to have redundant code and extra lines.

Vynae is the first 'completed' project I've done, in the sense that it meets all the original design goals and features. Typically, I draft something out and then leave it sitting, not moving forward with the project. As such, I've gone all out with it, and plan on keeping it updated for some time, adding improvements and optimizations over time. It isn't necessarily solving any great problem in tech, but I do think that it's a nifty little script that can be used in the day-to-day to get process information without running multiple commands.


Popular posts from this blog

Using PGPy to encrypt and decrypt files and messages

 PGPy is a library for python that enables the creation, storage, and encryption/decryption of PGP keys and files in python. Recently, in a small project to reacquaint myself with python, I used PGPy for key generation and encryption and decryption. That project can be found in my github at . The goal of the project was to use command-line switches to control the program, and to provide basic encryption and decryption capabilities, along with rot13 and base64 encoding.  First, to load in a key use key, _ = pgpy.PGPKey.from_file(keyfilename) . This loads the key from either a binary or ASCII armored file. You can swap out .from_file for .from_blob , if you plan on using a key stored in a string or bytes object rather than a file. In my example code, I pull the key from a file, as I found it to be the simpler method.  Next, you'll need to open a file or create a string or bytes object that contains the message you wish to encrypt. We'll call this file

Frag Attacks - A critical Wifi vulnerability

Wifi fragmentation and aggregation attacks (FragAttacks) are a new collection of vulnerabilities in which a threat actor can exfiltrate data or attack victims within radio range. Mathy Vanhoef, a postdoctoral researcher at New York University Abu Dhabi, recently published his paper, Fragment and Forge: Breaking Wi-Fi through Frame Aggregation and Fragmentation , detailing several attack vectors and examining the intricacies of the aggregation vulnerabilities that have been part of the 802.11 standards since the inception in 1997.  Quite interestingly, every device tested was susceptible to one or more of the FragAttacks. While several 802.11 standards make these attacks harder to perform, they can be executed on all devices across all standards. It's a good thing then, that there was a nine-month embargo on information related to these attacks, allowing manufacturers to provide security updates to affected devices. Mathy Vanhoef has also created a website documenting the FragAttack

RFC 791 pt2

 This week's post will cover the operation of the Internet Protocol. Specifically, Time to Live (TOL), Type of Service(TOS), the Header Checksum, and the other remaining options available when transmitting data across IP. While this post will cover the basic operations and provide descriptions of their functions and use, a more technical dive will be saved for next week's post, which will cover the specification section of RFC 791. The final post in this series will cover the security implications of the Internet Protocol, and briefly cover the updates made to the original document and protocol.  Continuing from the last post, there are two main functions of the Internet Protocol. Addressing and Fragmentation. To begin,  the device you use to connect to the internet, or the internet module, uses the addressing function of IP to send and receive data. The internet module reads the address of the datagram and uses it to route to the desired endpoint. This address is carried in th