Blog

Previously, we implemented a basic testing framework to start handling data errors, corrupt data, and edge cases. In Part 4, we're going to kick it up a notch. It's time to implement robust error handling for each discrete task!

We left off having implemented a basic testing framework to drive code implementation for edge cases and errors. Now we're going to build up that framework by developing tests specifically for each discrete function and attempting to ensure we have solid error handling for anything that comes our way. We're also going to implement log rotation while we're at it, to ensure that there's a reasonable amount of logs captured without taking up too much drive space. Let's get going!

Previous entries in this series covered the initial tool setup and testing of the environment, establishing the structure of the project, initial tests, and connecting to APIs. In this third entry, we're going to enhance our testing approach through a Test-Driven Development (TDD) methodology to build a more robust and reliable system.

Initially, our tests covered basic scenarios but didn’t fully account for real-world challenges like invalid configurations, API rate limits, and malformed data. We will expand our test cases significantly to address this, focusing on edge cases and error handling.

Part 1 of this series covered the initial tool setup, and testing of the environment. In Part 2, we're going to dive into structure, tests, and API connections.

In this post, I’m excited to dive into the development of IntelliSIEM’s data collection module. This step is crucial as it lays the foundation for how we will gather, process, and analyze threat data from various sources.

Welcome to the first post in my series chronicling the development of IntelliSIEM, a robust threat intelligence aggregator and reporter tool. In this post, I’ll guide you through setting up the development environment using Python 3.12 and PyCharm Professional.

Hello, Bite Size Bytes readers! It’s been a while since my last post, and a lot has happened in the past year. I've recently moved to a new area, which has been a big adjustment and an exciting adventure. Settling in took some time, but I’m now back and ready to dive into new projects and share my experiences with you.

With the increasing support of MFA using security keys to authenticate in services like GitHub, M365, Google, AWS, Salesforce, and many others, coupled with the prevalent use of VMware desktop virtualization for development and testing, it is more and more of a need to get YubiKeys to passthrough to a Guest VM. This process does NOT require disabling OTP+U2F, as some have suggested. I've tested this thoroughly on VMware Workstation 17 (Windows/Linux) and VMware Fusion 13 (Mac).

PowerShell speaks WPF and that means you can build a XAML-based GUI for your PowerShell script. It's easy to do - here's a small demo:

Admit it. Be honest now. We've all done it. We've run a command against a batch of users and forgot to limit the scope to the ones we were really targeting.

Some environments have multiple domains in a single Active Directory forest. Working with Powershell in the same domain as your user account is easy, but what do you do when you need to run Powershell commands in one of the other domains? Change context. Powershell can traverse AD as a file system, and this allows an easy way to change the context for your script. Keep in mind, that to be able to load the AD Powershell module, you need to install the RSAT tools on the workstation that you are using to run your commands.

I've been writing a lot of custom applications lately, many using Powershell and then packaged using Sapien's Powershell Studio. Something that I've had to do a few times lately is provide applications to allow a non-privileged user to manipulate a user account in a different domain. There are a few pieces that go into this, including mounting AD: as a provider and then "cd" to that "drive". To make all of this context changing work, it requires embedding the RunAs command into the executable to allow the script to run as an admin account from the domain being affected. The problem with that Powershell can not read the current true username from $env:username. Since it is important to log who is actually making changes to another persons account, this is a problem.