MFA was enforced. The tenant had a third-party MFA provider through Conditional Access. Every sign-in log entry showed a successful authentication. No password spray. No credential theft. And yet the attacker had a valid refresh token and access to the mailbox.
The entry point was a device code phishing link. Once I understood the mechanism, everything made sense.
Huntress provides a one-liner to install their Linux EDR agent. It works fine when you run it manually on a single machine you control. It does not work reliably when you fire it across dozens of client endpoints via an RMM, against distros you did not pick, behind firewalls configured however the client configured them, on machines you have never touched.
The gap between "one-liner that installs the agent" and "deployment that succeeds consistently at scale" is a wrapper script. This post is about that wrapper, the decisions behind it, and three specific bugs that would have silently broken deployments without the fixes.
Ticket Scout is now available for Chrome and Edge browsers. This extension highlights ticket numbers on web pages and provides instant lookups when connected to your PSA.
If you're tired of manually copying ticket numbers to search in your PSA or losing context while switching between tools then this browser extension may be just what you were looking for and didn't know you wanted.
I created it to solve my own frustrations and wanted to share with the rest of the community.
Almost every M365 BEC investigation I have worked follows a similar pattern: someone clicks a link, credentials get harvested, and the attacker spends the next several days quietly reading email. The entry point is obvious by the time it surfaces. What takes longer to find is the persistence mechanism the attacker left behind. Most of the time, that mechanism is a single inbox rule sitting in the compromised mailbox with a name that looks like a typo.
When a user reports a phishing email, the ticket lands and someone has to deal with it. Without automation that means: download the .eml, open it in a text editor, read through several hundred lines of raw headers, manually pull SPF/DKIM/DMARC verdicts, and write up a note. Every analyst does it slightly differently. Some do it thoroughly. Some do it fast. Most do it inconsistently at 4pm on a Friday.
I built an automation that fires the moment the ticket is created, parses the attached .eml, evaluates authentication headers, and posts a structured triage summary back to the ticket (usually within a few seconds of the ticket opening). Here is what it does and the part that would have burned me if I had not caught it.
If you're using Huntress Managed SIEM, you know the power of good queries — and the frustration of scattered, undocumented detection rules. I built the Huntress SIEM Library to solve that problem.
This is a community-focused repository for sharing, version-controlling, and collaborating on Huntress SIEM queries using ES|QL (Elastic Stack Query Language).
Welcome to my little corner of the internet! If you're here, you probably care about cybersecurity, automation, or DevOps — or you're just really lost (in which case, welcome anyway).
This blog is where I share the things I've learned while trying to make technology work better, faster, and more securely.