I’m training for a powerlifting meet. A phrase I keep thinking about? Time under tension. It’s simple: muscles grow when they’re under load. Take the load off, and they start to degrade, slowly, without warning. It isn’t instant, but the minute you stop pushing, it begins.

You got good at your work the same way, even if no one called it training. The bad first drafts. The ticket you wrestled with for two days before it finally gave. Sitting with a problem long enough that you stopped being scared of it. Those hours made you who you are today. Growth was the tax we paid for having no shortcut.

When the shortcut arrived, the work didn’t go away, but much of it became optional. Everything that used to be forced on you must now be opted into. But we are seeing a lot of people don’t opt in because there’s no ache from a rep you never did. You just feel faster. And faster feels like progress.

Maybe, for a while, you can’t tell the difference. And maybe, neither can anyone else. The output stops telling you who did the thinking. The person still does the hard reasoning, and the person who quietly handed it over turns in work that reads the same on the page. So the signal you used to take off someone’s output, the one that told you who was actually sharp, stops working. Everyone looks capable.

But that doesn’t last.

What’s come apart underneath is capability and output, and your job only measures one of them. The person who kept the load can still work when the machine is wrong. They can catch it in the moments it’s confidently and sometimes fluently wrong. The person who let the load go can only supervise. And supervising a system you can no longer out-think isn’t oversight. It’s trust with a manager’s title. One side keeps compounding. The other plateaus and calls it seniority.

You won’t know which one you became until the day it matters, and by then it’s already set. There’s no cramming years of skipped reps when the gap finally surfaces. The choice is being made now, in a hundred forgettable moments where you let the machine take the tension off, and the bill for those moments doesn’t arrive for years.

None of this is nostalgia, and I’m not afraid of the tools. In fact, I have embraced them wholeheartedly. Handing work to machines is the whole story of how work has ever moved: the calculator, the compiler, the search bar. Nobody is a better thinker for only doing long division by hand. The question has never been whether to use the machine. It was which work to keep, now that keeping any of it is finally up to you.

And there is a test for that. The weight worth keeping is the weight that builds the judgment you’ll need to supervise the machine you’re handing the work to. That’s the whole filter. Some of what you do all day is hauling, and you should automate it without a flicker of guilt. But some of it is the exact rep that lets you catch the machine when it’s wrong — usually the slow, irritating, judgment-shaped part. Keep that one. Let the rest go.

I came up in threat hunting, and the discipline is almost a proof of this. Hunting only exists because the automated layer isn’t enough, because the confident alert and the confident silence are both, sometimes, wrong. What makes a hunter is years of reps that don’t obviously pay off: staring at ordinary logs until the one thing that doesn’t belong finally lifts off the page. That instinct can’t be handed to you. It’s the judgment that lets you stand over an automated system and say, quietly, that’s wrong. Which is exactly the weight worth keeping. Everything that builds it, you protect. Everything that doesn’t, the machine can have.

In practice, this comes down to smaller things than it sounds. Mostly it’s about order.

Do the rep before you ask the machine: write your own version first, even a rough one, then hand it over and tell it to tear the thing apart. Go to the machine first, and you spend the day editing its thinking instead of building your own; go to yourself first, and it becomes the thing that checks your work, which is a completely different job for your brain and a completely different you a year out. And set the tool up to put strain on you rather than take it off. Ask it to hold its answer and quiz you instead. Tell it to argue the other side and go hunting for the weak joint in your reasoning. Guess what it’s going to say before you let it speak, and pay attention to the gap. Same tool either way. Whether it ends up a coach or a crutch is entirely a function of what you asked it for.

But the individual version of this is the small version, and I’ve come to think it isn’t even the one that matters most. Because the same thing is happening to organizations, and almost nobody is pricing it in.

Every company automating its grunt work is also switching off the machine that produced its own experts. The senior people it leans on, the ones whose judgment everyone trusts, were built by exactly the kind of work the next round of hires will never touch. The on-ramp and the drudgery were one and the same. Automate the drudgery, and you don’t just lose the busywork. You quietly remove the bottom two rungs of the ladder that turned juniors into the people you can’t operate without.

The entry-level work that used to forge an analyst, the slow reps that built the instinct, is the most automatable work we own. Every efficiency we take, seen from the other side, is a rep we are removing from someone who still needs it. That’s not an argument against the efficiency. It’s an argument that the reps now have to be put back on purpose, because the work will no longer install them by accident.

So the principle scales without changing shape. The weight worth keeping for a person or an organization is the one that builds the judgment you’ll need to supervise the machine you’re handing the work to. For you, that’s staying sharp enough to catch confident wrongness. For the org, it’s deliberately manufacturing the reps that used to happen on their own, so that ten years from now, the bottleneck won’t be the machines. It’ll be finding anyone who can still do the building. The companies that come through this are the ones treating it like a training program right now, while the old one is still warm, instead of assuming the work will keep forging people the way it always has.

Time under tension didn’t die with the old workflow. The load still builds you, exactly the way it built everyone who came before you. The only thing that changed is that staying under it is now a decision, and most people are making that decision every day without realizing there was one to make.

So choose your weights and reps on purpose. The ones who don’t will never feel the moment they stopped growing. They’ll glance up one ordinary afternoon and find the work has moved somewhere they can’t follow. And they’ve been standing in the same place the whole time it left.

Leave a comment

The share of actors scoring medium-risk or higher on Anthropic’s enablement scale climbed from roughly 33% to 56% in under a year. A 1.7x jump. The most bothersome part? It happened without the actors getting any more skilled. Technical sophistication was your type on paper; looks great, predicts almost nothing about the actual connection (r = 0.28), as did the breadth of techniques an actor used (r = 0.27). So did which interface they came through. The thing that used to tell you how worried to be, “Is this a sophisticated adversary?”, doesn’t really apply anymore.

That’s the real story and I don’t say it to be inflammatory. It’s a tooling problem. The mental model most of us use to triage threats assumes risk tracks skill. When skill stops tracking risk, the model breaks and a lot of our playbooks were built on top of that model.

So let’s start with something productive: mapping your existing detections to what these actors are actually doing (most of it you likely already cover) and then we’ll talk about the part you don’t.

What’s mappable

A web shell is still a web shell. None of these techniques are new. Your existing ATT&CK-aligned detections fire on the artifact and the action regardless of whether a human or a model produced them. The report logged 13,873 observations across 482 sub-techniques within14 tactics, each having a MITRE ID and likely a rule in your library.

I’ve split the coverage into two tiers because that split is the argument. Tier 1 is the high-prevalence preparatory work that dominates the dataset and Tier 2 is the smaller, post-compromise cluster where the highest-risk actors actually start to separate themselves.

Tier 1 — Preparatory and pre-intrusion

Can you say volume? The single most common technique family was T1587.001 (Malware Development), used by 560 of 832 actors. Most AI-enabled activity today is actors building offensive tooling before they engage, then making it harder to detect.

What AI changes in Tier 1: mostly volume and variety. One actor can now generate dozens of obfuscation variants for the cost of a few prompts, so signature coverage decays faster than it used to. But your behavioral detections hold and so do your runbooks. If you cover this tier well, you’re in good shape against the majority of the population in the dataset.

Tier 2 — Post-compromise and hands-on-keyboard (or: After Casa Amor)

This tier is a little rarer; lateral movement showed up in just 0.7% of all observations, but the risk is more concentrated. The 54 actors who used AI for lateral movement averaged a risk score about 10 points above the mean, the strongest single predictor of a high-risk actor in the entire study. The techniques below were three to five times more common among the highest-risk cohort than the general population.

Notice the two techniques flagged with year-over-year growth. T1087 and T1020 both presuppose that the actor is already inside the network. The activity that grew over the study window wasn’t more tool-building, it was actually more in-network work. What that really means to me: the population isn’t just getting bigger, it’s actually drifting toward the riskier end of the kill chain.

What AI changes in Tier 2: this is where your runbook’s hidden assumption breaks. It’s worth being precise about what breaks, too, because it isn’t the detections.

The cadence is what fails. Now, you’re sending three home.

Can I pull your playbooks for a chat? Every response playbook you’ve ever written silently assumes a human operator’s tempo between these steps. Recon takes a while. There’s dwell time before lateral movement. Discovery, credential access, and the pivot are separate phases with gaps between them. THOSE gaps are what your alert triage, analyst SOPs, and SOAR playbooks were designed around.

Now picture those phases collapsed into one uninterrupted sequence, executed at machine speed, by something that doesn’t get tired, doesn’t context-switch, doesn’t wait for a second analyst to confirm before moving, and doesn’t need to recouple between phases. The individual detections still fire. T1003 fires, T1021 fires, T1087 fires, but they fire concurrently or out of the order your triage expects. Now your mean-time-to-respond is suddenly racing an adversary that doesn’t need to stand up and stretch their legs.

That’s the honest version of what changes. Not “AI invents undetectable attacks” (at least not yet) it’s that the spacing between known techniques is no longer guaranteed. I want to be careful with that “yet,” though. I’m describing what the dataset shows today: known TTPs, executed faster and I genuinely don’t know if that holds. If a model crosses some capability threshold we haven’t hit, call it AGI, call it whatever, there’s no law of nature that says it stays inside the existing technique map or even inside human-plausible speed. The honest position is that I’m bounding a present-tense problem, not predicting the ceiling.

Soul Ties Is Crazy…So is Lateral Movement at Machine Speed: Where the map runs out.

Something else the report is very transparent about: you can map every individual action one of these actors takes (Anthropic did exactly that, with 13,873 observations, every one with a MITRE ID) and mapping all of it still doesn’t capture what made the highest-risk actor in the dataset dangerous.

Consider the espionage campaign Anthropic disrupted in November 2025, labeled GTG-1002. Maximum possible risk score: 100. Number of techniques: about 30 across 13 tactics which is comparable to plenty of medium-risk actors. The median actor in the whole study used 16 techniques, and some low-risk actors used more than 30. By every metric we normally reach for, things like technique count, tactic breadth, interface, assessed skill, GTG-1002 actually looks like Rob standing at the firepit in his overalls, unremarkable.

But what made it the most dangerous actor observed wasn’t any technique, it was the scaffolding. The actor wired an AI agent into a Kali box with offensive tooling exposed as MCP servers and it wasn’t asking for advice, it was standing on business; scanning, pivoting, deciding what to probe next all on its own. The AI scanned, found internal services, exploited an SSRF flaw to pivot inward, harvested SSH keys and cloud credentials and moved laterally. All the while it was making its own tactical calls about what to probe next, with the human only stepping in for the consequential decisions.

Autonomous chaining of the kill chain. Real-time pivot decisions. AI-directed execution with no human in the loop between steps. None of these has an MITRE ATT&CK ID. There’s no technique to map a detection to because the dangerous thing isn’t a technique, it’s the orchestration between techniques. The taxonomy our entire shared threat vocabulary is built on describes the moves but it essentially has no vocabulary for the player.

This is why it can feel unwinnable. You can have perfect coverage of all 482 techniques and still be blind to the one variable that best predicts catastrophic risk because that variable doesn’t exist in your framework yet.

Is all this really unwinnable? Are we defenders doomed? Are we Kordell standing at an empty door?

It feels that way some days, and I’d rather say that out loud than pretend otherwise. But “unwinnable” is the wrong frame, IMO.

The wrong work is mapping more rules to a frozen taxonomy. If the differentiator has moved to the orchestration layer, adding the 483rd technique mapping doesn’t help you. The math only changes if your detection thinking moves up a level too:

• Detect tempo, not just technique. A sequence of individually-benign-looking actions executing faster than a human plausibly could is itself the signal. Machine-speed sequencing across discovery → cred access → lateral movement is a behavioral fingerprint even when each step looks normal in isolation. This is where UEBA and sequence-aware detection come in clutch.

• Watch the orchestration interfaces. Tool-augmented operations through MCP-style servers and agentic harnesses are a new and observable surface. They don’t map to MITRE today but they leave traces.

• Compress vuln-to-patch. If attackers can autonomously find and chain exploitation at speed, your tolerance for known-unpatched systems has to drop accordingly. The transitional period rewards whoever shrinks that window fastest.

• Push on the framework. Anthropic is in active conversations with MITRE about adding cross-cutting categories for agentic, autonomous, decision-making behaviors. That vocabulary is coming. The teams that have already started detecting at the behavioral layer will adopt it fastest.

Now, I also have to mention that there’s a genuinely defensible reason for optimism about this new bombshell. The same capabilities that let a low-skill actor command an expert-level harness also let defenders find bugs before code ships, triage at machine speed, and close the patch gap. The asymmetry that’s hurting us right now isn’t permanent, it’s a function of attackers adopting the tooling faster than defenders have and that gap is one we control.

But I want to keep the same honesty I used a few paragraphs up. That optimism is scoped to the problem I’ve actually described: known techniques, executed faster by a population drifting up the kill chain. It’s a real edge against a real, present-tense threat and we should take it. What it isn’t is a guarantee about the thing I admitted I can’t see. If capability jumps somewhere we’re not expecting, “defenders have the same tools” stops being reassurance, because both sides would be improvising against a map that no longer describes the territory. I’d rather hand you a defensible reason for optimism about today than a fragile promise about a future none of us can map yet.

So here’s where I land. The battle isn’t unwinnable but the old way of fighting it is. Map your detections to the techniques (yes, genuinely, all of them, it’s worth doing), then accept that the map ends where the orchestration begins, and start building for the territory past the edge. And hold that posture loosely, because the edge moves. The teams that win the next few years won’t be the ones with the most complete rule library; they’ll be the ones who stayed honest about what their map couldn’t see yet, and built the muscle to notice when it changed.

Source: Anthropic, “Mapping AI-enabled cyber threats: Insights from the LLM ATT&CK Navigator,” June 2026

We took a detour this month. No thrunting, no hunt repos, just a long honest look at social engineering in the age of AI, with the person who scares Lauren the most in the entire SE community: Matt Bangert (aka @bngrsec), DEF CON 30 black badge winner and the guy whose AI bots now do his social engineering for him. If you have spent a decade training users to spot bad grammar, robotic voices, and the Nigerian prince in your inbox, this is the episode that tells you those red flags are already gone.

The throughline is uncomfortable and simple: the cost of a convincing lure has cratered. Matt walks through the actual math, roughly 500 vishing calls for a hundred bucks, no doomer hand-waving required, and you only need one person to pick up. The old tells are dead, the perfect phish is here, and the gut check (”am I actually expecting this, and what is being asked of me right now?”) is most of what users have left. We get into device code phishing as an initial access path, why the help desk is the single highest-value vector going (ask Scattered Spider), and the part that genuinely kept Lauren up that night: attackers turning your own AI against you. Matt’s go-to move after initial access is opening Copilot and asking it to find the passwords in SharePoint. It works. One of his engagements turned up a password hidden as white text in a spreadsheet, invisible to a human eye, trivially readable to a machine.

But this is THOR Collective, so the answer is not “we are all going to die” (even if Matt says it twice). The defenses that actually hold are boring and process-driven: callback and manager verification, out-of-band notification for any sensitive help desk event, and real defense in depth that does not put the entire load on a tired human at 2 AM. Sydney brings the defensive read throughout, Lauren brings the CISO-adjacent reality of user fatigue and finite resources, and we close with a lightning round and a running joke about the War of 1812 that may or may not become your team’s new safe word. Stick around for the credits. There is a surprise.

⏱️ Episode Breakdown

• 00:23 – Intro and the May detour into social engineering

• 02:39 – Guest intro: Matt Bangert, and the Plenty of Fish AI bot research

• 07:21 – What AI is doing to social engineering, and the new economics of a lure

• 13:08 – Battle of the Bots, and how defenders actually respond

• 15:49 – Phishing at scale, device code abuse, and the help desk problem

• 24:57 – Turning their own AI against them: Copilot abuse and the persistent insider

• 33:56 – ⚡ Lightning Round

• 40:14 – Closing, DEF CON plans, and a credits Easter egg

🎤 Hosts & Guest

Lauren Proehl (Host) — Manager of the group, cautious AI optimist, and the one steering this conversation toward the parts that should actually scare you.

Sydney Marrone (Host) — Now officially a manager too (the elder thrunter holds the belt). Co-founder, builder of ATHF and HEARTH, and the defensive voice keeping this episode grounded in what teams can actually do.

Matt Bangert / @bngrsec (Guest) — DEF CON 30 black badge winner as part of team Spilt Beans in the Social Engineering CTF, nine-ish years deep in offensive security since his OSCP, and now hands his social engineering off to AI agents. Took first in the Social Engineering Community’s Battle of the Bots vishing competition. Currently between affiliations. Catch him at DEF CON this year running the GIFs during the live vishing calls at the Social Engineering Community Village (yes, he is taking your not-safe-for-work suggestions).

• X: @bngrsec

• LinkedIn: mattbangert1

🔗 Resources & Mentions

On the Dispatch

• Ask-a-Thrunt3r: April 2026 — Signal vs Myth — last month’s episode, cutting through the Mythos hype with Trent Lo. Catch up if you missed it.

Featured in This Episode

• Matt’s SecKC Talk on AI Bots and Dating App Honeypots — Matt and Snow’s research using AI agents to detect bots and scammers on Plenty of Fish, presented at SecKC in March

• Social Engineering Community Village — the DEF CON village where Matt volunteers, led by Snow. Home of the vishing competition and Battle of the Bots.

• Battle of the Bots (Vishing Edition) — the autonomous AI vishing competition that debuted at DEF CON 33. Five teams build agents that call companies and extract flags, fully hands-off. Returning this year.

📢 Call to Action

• Audit your help desk — map your own verification flow before an attacker does it for you, and add out-of-band manager notification for MFA, phone, and password changes

• Stop training users on grammar and spelling — the perfect phish is here; shift to “am I expecting this, and what is being asked of me right now?”

• Look at what your own AI can reach — if a Copilot or assistant has a license in your environment, find out what it will hand over before someone else does

• Pick a safe word — yes, really, ask people about the War of 1812

• Come find Matt at DEF CON — Social Engineering Community Village, running the GIFs during the live vishing calls

• Catch us at the Antisyphon Threat Hunting Summit — virtual and free, June 17, 2026, the day after this drops:

  • Sydney: Avoiding Hunt Amnesia: Building a Memory Your AI Can Use — 12:00 PM ET

  • Lauren: Fast-track Reports into Ready-Made Hypotheses with AI — 3:00 PM ET

• Write for THOR Collective — first-time publishers, up-and-coming voices, builders with something to share: come find us

📬 Connect with THOR Collective

🗣️ Social Media

• Twitter/X: @THOR_Collective

• LinkedIn: THOR Collective

• BlueSky: @thorcollective

📧 Contact

Reach out through any social channel for guest post opportunities, collaborations, or to tell us what you’re building.

You’ve had the idea. Maybe for a while now.

You’ve thought about it, talked yourself out of it, told yourself next year, or decided that someone more qualified should be the one to do it.

They shouldn’t. You should.

This post exists because the gap between knowing something and believing you’re allowed to teach it is real, and it stops good proposals from ever getting written. We want to help you write yours.

The Imposter Syndrome Trap Is a Specific Lie

The thought sounds like: “Someone else knows this better than I do. Someone more qualified should be the one teaching it.”

Here’s what makes that thought dangerous: it’s technically unfalsifiable and practically infinite. There will always be someone who has been doing this longer. That doesn’t make your knowledge less real or less useful. It just means you have more to learn, same as everyone in the room, including the person you think is more qualified.

The bar for teaching a workshop is not “know everything.” The bar is “know enough more than your attendees to take them somewhere they couldn’t get to on their own.” That bar is almost certainly lower than imposter syndrome is telling you it is.

A simple test: think about the last time a colleague asked you to explain something. Think about the workaround you figured out that nobody else on your team knew existed. Think about the presentation where you thought “they skipped the part that actually matters.”

That’s your workshop.

Some of the best workshops start as “here’s the weird thing I had to figure out at work.”

That moment of “wait, I actually know this” is the seed of a proposal.

If you’re still not sure, ask three people in your network what they’d most want to learn from you. The answers will probably surprise you.

How to Scope a Workshop Topic

Most proposals collapse at this step, not because the idea is bad, but because it’s too wide.

The talk version of your idea tries to cover everything. The workshop version picks one thing and goes deep.

A talk might be “Introduction to Memory Forensics.” A workshop is “Analyzing LSASS Dumps to Identify Credential Theft: A Hands-On Lab.” See the difference? The workshop has a specific destination. Attendees know exactly what they’re walking out able to do.

Scoping test:

• Write down what you want attendees to be able to do by the end. Not “understand X,” do Y.

• Draw a box around it. Smaller than you think. Now smaller again.

• Ask: can someone complete this in 90 minutes to three hours with a laptop and a pre-built environment?

• If yes, you have a workshop scope. If no, cut it.

Tight scope delivered well beats ambitious scope delivered poorly every time. Attendees leave a focused workshop feeling like they actually got something. They leave an over-scoped one feeling like they missed most of it, and they’ll be right.

The other scope question is logistics. Does your attendee need a VM? A cloud sandbox? A pre-loaded dataset? A browser? Nothing? Work that out early. A lab environment that 40% of the room can’t access will derail an otherwise excellent workshop faster than anything.

The Format Is More Forgiving Than It Looks

The proposal is not a thesis defense.

You need to describe the topic, the target skill level, what attendees will leave able to do, and what environment or materials they’ll need. That’s it. Reviewers are looking for clarity of intent, not polish.

What is this workshop?
Who is it for?
Will people walk out with a concrete skill or artifact?

If you can answer those three questions in plain sentences, you can write a proposal.

You also don’t need a fully built-out lab to submit. You need a plan. The lab gets built after acceptance. The proposal is the idea.

And nerves are normal. They don’t go away with preparation, but preparation changes what they feel like. Instead of “I don’t know if I can do this,” they become “I really want this to land.” That is a useful kind of nervous.

The first five minutes on stage are the hardest. After that, once the first question comes in and someone runs the first command and gets a result, it stops being a performance and starts being a conversation. That’s when the room becomes yours.

The audience wants you to succeed. They chose your workshop over every other option in the schedule. They showed up because they already believe what you’re offering is worth their time.

The Community Is Better When More of Us Teach

When the people teaching are a narrow slice of the people doing the work, the content reflects that. Knowledge that lives in different parts of the community, different environments, different tooling constraints, different perspectives, doesn’t make it into workshops because the people who could teach it never submit.

That’s a loss for everyone in the room.

The downside of submitting and not getting accepted is a rejection email.

The downside of not submitting is that your workshop doesn’t exist, and neither does the community that would have formed around it.

Before You Close This Tab

Open the CFP. Not to submit today. Just to open it.

Quick-start checklist:

• Name the thing you’d most want to teach. One topic, two sentences.

• Identify the specific skill attendees will leave with. Not “they’ll understand X,” “they’ll be able to do Y.”

• Write down what environment they’ll need (VM, browser, dataset, nothing).

• Draft a title. It doesn’t have to be good. It has to exist.

• Open the CFP form and put your two sentences in it.

That’s the first step. Everything else you can figure out after you’ve decided to do it.

Your idea deserves a room. Give it one.

And if you happen to be looking for a place to start, DEATHCon’s CFP is currently open.

Mythos pulled us out of sabbatical. After a few months heads-down on conferences, work, and shipping, the THOR Collective is back with a special episode dedicated to cutting through the Mythos hype cycle. Lauren and Sydney are joined by Trent Lo (aka Surbo), Principal Security Researcher at Marsh and longtime adversary-in-chief from the CenturyLink days. Trent lives on both sides of the fence — offense and defense — which makes him exactly the right person to help us answer the question the whole industry has been screaming about since Anthropic’s announcement: is this real, or is this marketing?

The crew walks through what Mythos and Glasswing actually were (versus the cyber-nuclear-war headlines), where AI genuinely changes the game for attackers, and where defenders still hold the line. The throughline: behaviors still win. AI changes tempo, not fundamentals. There is still a human pointing the tool, and that intent — not the model — is what matters. Trent’s take is measured, grounded, and refreshingly free of doom: nation-states already have this capability and have for a while, the have-and-have-nots gap is going to widen, and the smartest move right now is to get your patching program in order before the wave of AI-found vulnerabilities crests.

Sydney walks through three new HEARTH features — What Can I Hunt, the Coverage Map, and the Context Graph — and recaps ATHF for anyone who missed her SANS AI Summit talk. Lauren teases her Vercel/Context.ai infostealer-to-SaaS hunt guide. Then the conversation pivots to defense at machine scale: how the well-resourced orgs should be thinking, what the under-resourced shops can actually do with Gemma 4 running locally and Copilot bundled in their E5 license, and why vulnerability programs are about to become the most important muscle on the team. We close with a Myth or Signal rapid round (AI SOC replacing analysts? threat hunting copilots? baselining? autonomous pentest? AI-generated malware?) and conference plans for the rest of the year.

⏱️ Episode Breakdown

• 00:23 – Intro and welcome back from sabbatical

• 02:06 – Guest intro: Trent Lo (Surbo), Principal Security Researcher at Marsh

• 04:24 – THOR updates: new HEARTH features and ATHF recap

• 07:41 – April Dispatch posts: Vercel infostealer-to-SaaS hunt + Mythos Won’t Kill Threat Hunting

• 10:17 – What Mythos and Glasswing actually were vs. the marketing hype

• 15:37 – Where humans still win: judgment, intent, and what “agentic” really means

• 21:43 – What actually worries us about Mythos (hint: it’s the keyboard, not the model)

• 25:14 – Defense in the open and the widening have-and-have-nots gap

• 27:52 – Closed source vs. open source post-Mythos, and the CVE explosion problem

• 34:25 – How defenders can actually use AI: imposter syndrome, IR, and machine-scale hunting

• 39:56 – Defense at machine scale: resourced vs. under-resourced playbooks

• 46:46 – What a two-person team should prioritize (spoiler: patch your shit)

• 51:13 – ⚡ Myth or Signal rapid round

• 53:41 – Plugs, conferences, and Allbirds becoming an AI company

• 56:32 – Happy thrunting

🎤 Hosts & Guest

Lauren Proehl (Host) — Manager of the group, cautious optimist, and the person who still has receipts on Trent from CenturyLink days.

Sydney Marrone (Host) — Now officially a manager (welcome to the dark side). Built ATHF, shipped three new HEARTH features this cycle, and is the reason 90% of you have a starting point for agentic threat hunting.

Trent Lo / Surbo (Guest) — Principal Security Researcher at Marsh. Self-described professional hand grenade thrower who also jumps on the grenades.

• LinkedIn: trentlo

• X: @surbo

🔗 Resources & Mentions

April Dispatch Posts

• Mythos Won’t Kill Threat Hunting. It’ll Prove We Were Right. by Lauren Proehl & Sydney Marrone — the editorial thesis driving this episode

• Hunting the Infostealer-to-SaaS Pipeline by Lauren Proehl — practitioner hunt guide on OAuth abuse and lateral movement via over-permissioned SaaS apps, using the Vercel/Context.ai breach as a case study

Mythos & Glasswing — Primary Sources

• Claude Mythos Preview — Anthropic’s technical writeup of the model’s vulnerability discovery capabilities

• Project Glasswing — the coordinated disclosure consortium (AWS, Cisco, Google, and others)

• Bruce Schneier: On Mythos Preview and Project Glasswing — a healthy counterweight to the breathless coverage

THOR Collective Tools & Frameworks

• HEARTH — the community hypothesis library. Three new features: What Can I Hunt (pick your data sources, get matched hypotheses), Coverage Map (HEARTH hypotheses linked to MITRE ATT&CK), and Context Graph (adds threat actors and campaigns to the coverage map to surface gaps). Source on GitHub.

• ATHF (Agentic Threat Hunting Framework) — Sydney’s open-source framework. Maturity model from manual to multi-agent, LOCK pattern, MCP server, AI assistant. Drop it into Cursor or Claude Code. Watch Sydney’s SANS AI Summit talk “Designing AI-Assisted Threat Hunting That Remembers” for the walkthrough.

Other Mentions

• AISLE — the autonomous vulnerability research team that found 12 of 12 OpenSSL CVEs in January (covered in our January episode), and 5 of 7 in the April release. Their post-Mythos analysis, AI Cybersecurity After Mythos: The Jagged Frontier, is directly relevant to Trent’s point about another company quietly doing this work for less money. Give credit for what AISLE actually did without conflating it with Mythos.

• Gemma 4 — Google’s most capable open model, released April 2 under Apache 2.0. Lauren is running it locally. Trent’s tip: jumpstart prompts here before burning real API tokens.

• Allbirds → NewBird AI — yes, the shoe company. Sold its footwear assets for $39M and pivoted to GPU-as-a-Service. We’re as confused as you are.

📢 Call to Action

• Read the April Mythos post — and pass it to anyone in your org panicking about cyber-nuclear war

• Check out the new HEARTH features at hearth.thorcollective.com — start with What Can I Hunt

• Fork ATHF on GitHub — start at Level 1 (one hunt in LOCK format) and grow from there

• Fix your patching program — the most boring, most important investment you’ll make this year

• Run Gemma 4 locally — get your reps in before you burn real API tokens

• Catch us on the conference circuit:

  • Lauren at the CrowdTour in New York

  • Trent at NCFTA Pittsburgh and Zenith

  • Antisyphon Threat Hunting Summit — virtual and free, June 17, 2026

    • Sydney: Avoiding Hunt Amnesia: Building a Memory Your AI Can Use — 12:00 PM ET

    • Lauren: Fast-track Reports into Ready-Made Hypotheses with AI — 3:00 PM ET

  • Everyone at Black Hat and DEF CON

• Write for THOR Collective — first-time publishers, up-and-coming voices, builders with something to share: come find us

📬 Connect with THOR Collective

🗣️ Social Media

• Twitter/X: @THOR_Collective

• LinkedIn: THOR Collective

• BlueSky: @thorcollective

📧 Contact

Reach out through any social channel for guest post opportunities, collaborations, or to tell us what you’re building.

The Pattern

In April 2026, Vercel disclosed a breach that followed an attack chain worth studying. Not because the techniques were novel, but because the pattern is universal and almost nobody is hunting for it.

The short version: an infostealer infection on a third-party vendor’s employee machine harvested OAuth tokens. One of those tokens belonged to a trust relationship between the vendor’s application and a Vercel employee’s corporate Google Workspace account. The attacker inherited that access, pivoted into Vercel’s internal environments, and exfiltrated data. The attacker never phished the Vercel employee, bypassing their MFA, or touching their endpoint.

The breach wasn’t about Vercel specifically. It was about a pattern that exists in every organization: employees grant third-party applications OAuth access to corporate identity providers, creating persistent trust relationships that can be weaponized if the third party is compromised. The attacker doesn’t need to compromise you. They need to compromise anyone you trust.

This post breaks that pattern into four huntable behaviors. The Vercel/Context.ai incident is used as an illustrative case, but the hunts are designed to detect this pattern regardless of which vendor, which identity provider, or which attacker is involved.

Understanding the Attack Chain

The pattern decomposes into four phases. Each phase has distinct observable behaviors that can be hunted independently:

Phase 1 — Initial Compromise (Third-Party Endpoint)
An employee at a third-party vendor has their endpoint compromised by infostealer malware. The malware harvests credentials, session cookies, and OAuth tokens from the machine. In the Vercel case, this was Lumma Stealer delivered via a trojanized game cheat download on a Context.ai employee’s machine.

Phase 2 — Token Harvesting and Abuse
The stolen OAuth tokens include grants that the vendor’s application holds against your enterprise identity provider. These are legitimate tokens issued through a legitimate consent flow. The only thing illegitimate is who’s using them. In the Vercel case, Context.ai’s OAuth app had been granted Allow All permissions on a Vercel employee’s Google Workspace.

Phase 3 — Lateral Movement via Trust Relationship
The attacker uses the harvested tokens to authenticate as the trusted third-party application and access your environment. From your identity provider’s perspective, this looks like a normal API call from an authorized application. In the Vercel case, the attacker used Context.ai’s token to access the employee’s Google Workspace, then pivoted into Vercel’s platform environments.

Phase 4 — Objective Completion
With access to your environment through the trusted application, the attacker pursues their objective: data exfiltration, secrets harvesting, persistence establishment. In the Vercel case, the attacker enumerated and decrypted environment variables.

Each phase maps to a hunt below.

Hunt 1: Uncontrolled Third-Party OAuth Grants

Behavior you’re hunting: Employees granting OAuth consent to third-party applications (especially AI and productivity tools) that hold persistent, over-permissioned access to your identity provider.

Why this matters: This is the precondition that makes the entire attack chain possible. Without an existing OAuth trust relationship, a compromised third party can’t pivot into your environment. Every unmanaged OAuth grant is a lateral movement path waiting to be activated.

What to Look For

The specific indicators are consistent regardless of which identity provider you’re running:

• Over-permissioned scopes: Applications with broad access like full Drive/OneDrive read-write, full Mail access, directory administration, or blanket Allow All grants. Any scope that gives the application access beyond what its stated function requires.

• Shadow applications: Apps that aren’t on your approved SaaS inventory. Single-user signups are the highest risk. One employee tried a tool, clicked through a consent screen, and created a trust relationship your security team doesn’t know about.

• AI and productivity tools: The explosion of AI-powered SaaS means employees are self-provisioning tools at a rate that outpaces any approval process. These tools typically request broad data access (Drive, email, calendar) to function, creating exactly the kind of over-permissioned grants this pattern exploits.

• Stale grants: Applications the employee no longer uses but the OAuth grant persists. The vendor may have been acquired, shut down, or deprioritized security, but the token is still live.

Google Workspace

Navigate to Admin Console → Security → API Controls → Third-party app access. This shows every third-party application with OAuth access across your domain, the scopes granted, and which users consented.

For audit log hunting, filter OAuth Token events for authorize actions:

Event: authorize
Scope contains: drive OR gmail OR admin.directory OR calendar
Time: Last 180 days

Prioritize any grant where the scope includes broad permissions and the application isn’t in your approved inventory.

Microsoft Entra ID

Navigate to Entra Admin Center → Enterprise Applications → All Applications. Review permissions granted, focusing on:

• Applications with delegated permissions consented by individual users (not admin-granted)

• Directory.ReadWrite.All, Mail.ReadWrite, Files.ReadWrite.All, or User.ReadWrite.All scopes

• Service principals with owners who are standard users. This is the service principal ownership abuse vector where compromising a regular user gives the attacker the ability to add credentials to a privileged app registration

AuditLogs
| where OperationName == "Consent to application"
| extend AppName = tostring(TargetResources[0].displayName)
| extend Scopes = tostring(TargetResources[0].modifiedProperties[0].newValue)
| extend User = tostring(InitiatedBy.user.userPrincipalName)
| where Scopes has_any ("Directory.ReadWrite", "Mail.ReadWrite", "Files.ReadWrite")
| project TimeGenerated, User, AppName, Scopes
| sort by TimeGenerated desc

The Deliverable

A complete inventory of third-party OAuth grants with: application name and client ID, scopes granted, consenting users, whether the application is on your approved SaaS inventory, and a risk assessment. Any application that is (a) not approved and (b) holds broad permissions should be reviewed for immediate revocation.

Vercel Case Reference

The specific indicators from the Vercel breach to check for in your environment:

OAuth Client ID (app):        110671459871-30f1spbu0hptbs60cb4vsmv79i7bbvqj.apps.googleusercontent.com
OAuth Client ID (extension):  110671459871-f3cq3okebd3jcg1lllmroqejdbka8cqq.apps.googleusercontent.com
Chrome Extension ID:          omddlmnhcofjbnbflmjginpjjblphbgk

Check for these specifically, but the hunt is about finding all uncontrolled grants. These are just today’s IOCs.

Hunt 2: Infostealer Exposure in Your Trust Chain

Behavior you’re hunting: Evidence that credentials, tokens, or session data from your employees, or from employees at vendors who hold OAuth grants against your environment, have been harvested by infostealer malware.

Why this matters: Infostealers are the initial access vector that feeds this entire pattern. But here’s the uncomfortable part: the Vercel breach didn’t start because a Vercel employee got hit. It started because a vendor’s employee got hit. You can run flawless endpoint hygiene internally and still be exposed through a third party’s compromised machine.

This hunt has two prongs: checking your own exposure and assessing your trust chain.

Your Own Exposure

Threat intelligence feed checks: Several services aggregate infostealer logs and index them by corporate domain.

• Hudson Rock (hudsonrock.com): large infostealer log database, searchable by domain. They first attributed the Context.ai compromise to Lumma Stealer.

• Flare (flare.io): dark web and infostealer market monitoring.

• SpyCloud (spycloud.com): specializes in infostealer-derived credential exposure.

• Have I Been Pwned (haveibeenpwned.com): more breach-focused than infostealer-focused, but a baseline check.

Query for your corporate domain(s). Any hits should be treated as active compromise indicators, not historical data points. If an employee’s tokens appear in an infostealer log, assume the tokens are in adversary hands until proven otherwise.

Endpoint behavioral hunting (if you have EDR):

Key file paths to monitor for unauthorized access:

# Browser credential stores (Chrome/Edge)
%LOCALAPPDATA%\Google\Chrome\User Data\Default\Login Data
%LOCALAPPDATA%\Google\Chrome\User Data\Default\Cookies
%LOCALAPPDATA%\Google\Chrome\User Data\Default\Web Data
%LOCALAPPDATA%\Microsoft\Edge\User Data\Default\Login Data

# Token caches
~/.config/gcloud/credentials.db
~/.config/gcloud/access_tokens.db
~/.aws/credentials
~/.azure/msal_token_cache.json

Hunt for:

• Processes accessing these files that aren’t the browser itself or an approved password manager

• Processes reading from multiple browser profile directories in sequence (the signature “harvest everything” behavior of infostealers)

• Outbound connections shortly after credential store access, especially to unfamiliar infrastructure

Your Trust Chain Exposure

This is harder and less comfortable. The vendors who hold OAuth grants against your identity provider have employees with endpoints. Those endpoints can be compromised. When they are, the tokens those vendors hold for your environment may be in the exfiltrated data.

What you can do:

• Cross-reference your OAuth grant inventory (from Hunt 1) with infostealer exposure feeds. If a vendor’s domain appears in Hudson Rock or similar, and that vendor holds OAuth grants against your IdP, that’s a high-priority risk.

• For critical vendors (those with broad OAuth scopes), ask directly about their endpoint security posture and infostealer monitoring during your next vendor security review.

• Monitor for public disclosure of vendor compromises. The window between a vendor’s compromise and their disclosure is exactly when you’re most exposed.

The Uncomfortable Truth

There’s a gap in this hunt that’s worth acknowledging: you can check if your employees are compromised, and you can reactively learn about vendor compromises through intelligence feeds or disclosure. But you can’t continuously monitor whether every vendor employee with access to tokens that touch your environment has a clean endpoint. This is a structural limitation of the OAuth trust model, and it’s why Hunt 1 (reducing the attack surface by controlling OAuth grants) is ultimately more impactful than Hunt 2 (detecting after the fact).

Hunt 3: Anomalous Third-Party Application Behavior

Behavior you’re hunting: OAuth-authenticated API access from a trusted third-party application that deviates from the application’s established behavioral baseline, indicating that someone other than the vendor is driving the API calls.

Why this matters: When an attacker uses a stolen OAuth token, the access appears to come from the legitimate application. Your IdP logs will show the app’s client ID making authorized API calls within its granted scopes. The access is technically legitimate. The only detectable anomaly is in how the token is being used: the behavioral pattern, not the authentication event.

Behavioral Indicators

These indicators apply regardless of identity provider or which third-party application is involved:

Geographic anomalies: An OAuth app that normally makes API calls from a cloud provider’s IP range (the vendor’s infrastructure) suddenly making calls from a different geographic region, a residential ISP, a VPN provider, or a hosting provider not associated with the vendor. This is the strongest signal. It means someone other than the vendor is using the token.

Temporal anomalies: API access outside the application’s normal operating pattern. A productivity tool that typically makes requests during business hours suddenly making calls at 3 AM. A synchronization service that normally runs on a schedule suddenly making ad-hoc requests.

Volume anomalies: A sudden spike in API calls. An app that normally makes a handful of requests per day suddenly enumerating entire Drive contents or pulling large volumes of email. The “smash and grab” pattern is distinctive: rapid, sequential access to resources the application previously accessed infrequently or not at all.

Access pattern changes: An application accessing resources or API endpoints it has scopes for but hasn’t historically used. The OAuth grant may allow broad access, but the legitimate application’s normal behavior only touches a subset. An attacker with the same token will use it differently.

Google Workspace

Use the Workspace audit logs to profile OAuth application behavior. The key log sources are Drive log events, Gmail log events, and OAuth Token log events under Admin Console → Reporting → Audit and Investigation.

Look for:

Drive Audit Log:
Event: view OR download
Actor: [OAuth app client ID]
Volume: > 50 events in 1 hour (adjust based on baseline)

And via the Reports API:

GET https://admin.googleapis.com/admin/reports/v1/activity/users/all/applications/token

Filter for token activity events associated with applications identified as high-risk in Hunt 1. Correlate IP addresses against the vendor’s known infrastructure ranges.

Microsoft Entra ID

Service principal sign-in logs are the primary data source:

AADServicePrincipalSignInLogs
| where TimeGenerated > ago(30d)
| extend AppName = tostring(ServicePrincipalName)
| summarize
    DistinctIPs = dcount(IPAddress),
    IPs = make_set(IPAddress),
    Locations = make_set(LocationDetails.city),
    CallCount = count()
    by AppName, AppId
| where DistinctIPs > 3
| sort by DistinctIPs desc

This surfaces service principals authenticating from an unusual number of distinct IPs, a potential indicator of credential misuse. Also hunt for new credentials being added to service principals, which is a persistence technique:

AuditLogs
| where OperationName has "Add service principal credentials"
| extend AppName = tostring(TargetResources[0].displayName)
| extend Actor = tostring(InitiatedBy.user.userPrincipalName)
| project TimeGenerated, Actor, AppName, OperationName

Building a Baseline

This hunt is only as good as your behavioral baseline. If you don’t know what normal looks like for an OAuth application, you can’t detect abnormal. Start by profiling the high-risk applications from Hunt 1:

• What IP ranges do they normally authenticate from?

• What times of day do they make API calls?

• What resources do they typically access?

• What’s their normal API call volume?

Document the baseline. Then alert on deviation. This doesn’t have to be sophisticated. Even a weekly manual review of OAuth app activity for your top-risk applications is better than nothing.

Hunt 4: Trust Boundary Lateral Movement

Behavior you’re hunting: Compromise of an identity provider account (via OAuth token abuse or any other means) being leveraged to access downstream platforms: CI/CD systems, cloud infrastructure, code repositories, PaaS environments, secrets managers.

Why this matters: Owning a Workspace or M365 identity is rarely the objective. It’s a waypoint. The attacker wants what that identity can reach. In modern environments, a single identity is often federated across dozens of platforms via SSO, linked credentials, and stored secrets. In the Vercel case, Workspace access led to platform environment access and secrets exfiltration. In your environment, the blast radius may be different, but the movement pattern is the same.

Map the Blast Radius First

Before you can hunt for this movement, you need to understand what’s reachable from a compromised identity. For each user with high-risk third-party OAuth grants:

• SSO-connected applications: What can this identity access via Google/Microsoft SSO? Each is a pivot target if that identity is compromised. Most organizations underestimate how many platforms are SSO-connected.

• Stored secrets in email and cloud storage: API keys, connection strings, passwords, tokens sitting in email threads, shared Drive folders, or OneNote notebooks. Attackers search for these immediately upon gaining email/Drive access.

• CI/CD and PaaS integrations: Does this user have access to deployment platforms, build systems, or cloud consoles? Are there environment variables or secrets in those platforms stored in plaintext or not marked as sensitive?

• Browser-synced credentials: If the user syncs their browser profile with their corporate identity, a Workspace/M365 compromise may expose their entire browser password store.

Detection Queries

SSO session correlation:

Look for SSO-initiated sessions in downstream platforms that correlate temporally with suspicious activity in your identity provider:

SignInLogs (downstream platform):
Authentication method: SSO
User: [users with high-risk OAuth grants]
Correlate with: unusual OAuth app activity from Hunt 3

The specific log sources depend on your platform stack, but the logic is consistent: if you see anomalous OAuth token usage in your IdP, check whether the affected identity subsequently created sessions in connected platforms.

Secrets and environment variable access:

GitHub:   org.update_actions_secret, repo.update_actions_secret
AWS:      CloudTrail GetSecretValue, GetParameter (SSM)
GCP:      Secret Manager AccessSecretVersion
Azure:    Key Vault SecretGet
PaaS:     Environment variable access events (check audit logs)

On Vercel, Netlify, and similar platforms, pay special attention to variables not configured as sensitive or encrypted, which may be readable to any authenticated user with project access.

Email and cloud storage enumeration:

The rapid-fire pattern of an attacker enumerating everything they can reach through a compromised identity:

• Drive/OneDrive: high-volume view, download, or copy events in a short window, especially against files the user doesn’t typically access

• Email: API-based access to mailbox contents (as opposed to normal interactive use), particularly bulk read patterns

• Across both: access from the same anomalous IP/geo identified in Hunt 3

Hardening Against the Pattern

Hunting finds current exposure. Hardening reduces future attack surface. These recommendations map to the four phases of the attack chain:

Reduce the trust surface (Phase 2 prevention):

• Implement an OAuth app allowlist in your identity provider. Block user consent for unapproved applications.

• Restrict broad scopes by default. No third-party app gets Allow All or equivalent without explicit security review.

• Alert on new OAuth consent events, especially for high-privilege scopes.

• Conduct quarterly reviews of active OAuth grants and revoke stale or unnecessary ones.

• Establish a lightweight process for employees to request approval for new SaaS tools rather than self-provisioning with corporate credentials.

Limit the blast radius (Phase 3/4 prevention):

• Default all secrets, environment variables, and API keys to encrypted/sensitive storage in every platform. The Vercel breach specifically exploited variables that weren’t marked sensitive.

• Audit CI/CD and PaaS platforms for secrets stored in plaintext.

• Enforce short-lived access tokens (5-15 minutes) with appropriately scoped refresh tokens where your IdP supports it.

• Implement token binding or sender-constrained tokens to make stolen tokens unusable from unauthorized devices.

• Segment SSO access. Not every identity needs access to every connected platform.

Build resilience (detection and response):

• Monitor infostealer exposure feeds for your corporate domains and critical vendor domains.

• Baseline OAuth application behavior and alert on deviation.

• Rotate tokens and secrets immediately upon any suspected identity compromise, including when a vendor discloses a compromise.

• Maintain a runbook for “third-party vendor compromise” that includes identifying all OAuth grants from that vendor, revoking them, auditing access logs for the affected period, and rotating any secrets the affected identities could reach.

Vercel/Context.ai IOCs

For immediate operational use. These are specific to the April 2026 Vercel incident and should be checked alongside the broader hunts above:

and because I spent too many years hand keying IOCs from photos and PDFs:

110671459871-30f1spbu0hptbs60cb4vsmv79i7bbvqj.apps.googleusercontent.com 110671459871-f3cq3okebd3jcg1lllmroqejdbka8cqq.apps.googleusercontent.com omddlmnhcofjbnbflmjginpjjblphbgk beta.context.ai

The Bigger Picture

The Vercel/Context.ai breach is a clean example of a pattern that’s been building for years: as organizations adopt more SaaS tools, they create more trust relationships, and each trust relationship is a lateral movement path that bypasses traditional perimeter and endpoint controls. The attacker doesn’t need to beat your security. They need to beat the security of anyone you’ve granted trust to.

That’s not a problem you solve once. It’s a behavior you hunt for continuously.

Happy thrunting!

The THOR Collective is a practitioner-driven cybersecurity collective focused on detection, hunting, and response tradecraft. Want to contribute? Reach out.

Leave a comment

This release adds three new tabs that each answer one of those questions. None of them change the underlying hunt library — hunts still live as markdown in the repo and flow into hunts-data.json on build. The tabs are different lenses on the same data, plus a context graph layer that ties hunts back to the actors and campaigns driving them.

Here’s what shipped.

What Can I Hunt?

The problem. You have an EDR, Zeek, Okta, and Microsoft 365 logs. You do not have a cloud trail from every CSP, you do not have full packet capture, and you are not going to read 130 markdown files to figure out which hunts are runnable tonight. The default question for any new hunter onboarding to an environment is “given my telemetry, what should I work on first?” — and until now HEARTH made you answer that by hand.

How it works. The left sidebar lists data source categories pulled from a curated datasource-mapping.json — EDR, Network, Identity, Cloud, Email, and so on. Check the boxes for what you actually have. The right pane filters in real time to only hunts whose required data sources you can satisfy, then ranks them with a HuntRanker score that blends three signals:

• Prevalence — how many active threat campaigns are currently leveraging the underlying techniques, shown as 🔥 hot, 🌡️ warm, or ❄️ cold.

• Actor count — how many tracked threat actors are known to use the technique.

• Active campaigns — the live campaign count touching the technique right now.

The top 5 cards float to the top as “highest-impact given current threat activity.” If you have a data source but the techniques under it have zero HEARTH hypotheses, a coverage gap alert fires with a CTA to submit one — this is how the library grows in the places it’s needed. Every card has a “View hypothesis” link that opens the rendered markdown straight from GitHub, so you can go from “what should I hunt?” to reading the full hypothesis, data requirements, and detection logic in one click.

Who it’s for. SOC analysts and detection engineers onboarding to a new environment, hunt team leads building a sprint backlog, and anyone who wants to stop triaging a 130-row spreadsheet. The pitch is simple: tell us what telemetry you have, and we’ll tell you what’s worth hunting right now.

Coverage Map

The problem. Leadership asks where your hunting program covers ATT&CK and where it doesn’t. You want a single view that shows hunts mapped to techniques, color-coded by hunt type, with gaps called out — not a spreadsheet you have to re-render every quarter.

How it works. The Coverage Map is an interactive data visualization graph placing hunts against ATT&CK techniques. Nodes are color-coded by type so you can read the map at a glance:

• Orange — ATT&CK technique

• Purple — Flame hunt (hypothesis-driven)

• Blue — Ember hunt (baselining/exploration)

• Amber — Alchemy hunt (model-assisted)

• Green — Data source

• Red (glowing) — Coverage gap

Tactic filter buttons across the top let you narrow to a single kill-chain phase — Credential Access, Persistence, Exfiltration, whatever you’re scoping. Click any node and a sidebar slides out with the full details: linked techniques, required data sources, hunt IDs, description.

The coverage gap nodes are the interesting ones. They surface techniques that public reporting has tied to active campaigns but that HEARTH does not yet have a hypothesis for. That’s your contribution backlog, sorted by relevance instead of by whim.

Who it’s for. Detection engineering leads building a coverage strategy, program leads pitching hunting maturity to stakeholders, and contributors looking for the highest-value gap to fill instead of writing yet another Mimikatz hunt.

Context Graph

The problem. A hunt hypothesis on its own tells you what to look for, not why it matters this week. To prioritize, you need the full chain: which actor ran which campaign, which techniques did that campaign use, and which HEARTH hunts land on those techniques. That’s four entity types and a lot of edges, and it does not fit in a flat list.

How it works. The Context Graph is a data visualization force-directed graph with four node types and real edges between them:

• Threat actors (red)

• Campaigns (amber)

• ATT&CK techniques (orange)

• HEARTH hunts (Flames, Embers, Alchemy in their respective colors)

Edges reflect real relationships derived from public threat intel: actor X ran campaign Y, which used T1071.001, which HEARTH hunt H002 can detect. Hover any node for a tooltip with the metadata that matters — campaign dates, actor aliases, technique ID, hunt description. Click to expand the full sidebar.

The graph is kept up to date by enrichment scripts that pull data from public threat intelligence sources. You’re not looking at a snapshot someone committed last quarter; you’re looking at a live picture of what’s being reported on.

Who it’s for. Threat intel analysts who need to connect reports to action, hunt program leads justifying prioritization to stakeholders, and researchers exploring what a given actor has actually been doing lately.

Putting it together

These tabs are designed to chain. A realistic workflow looks like this:

You read an advisory about an actor getting louder — pick your favorite. You jump into the Context Graph, find the actor node, and expand out to the campaigns and techniques they’ve been using. Two of those techniques look new and relevant to your environment.

From there you switch to the Coverage Map and filter by the tactics those techniques belong to. Three are covered by existing hunts; one is a red gap node. You note the gap as a contribution candidate and move on.

Finally you open 🎯 What Can I Hunt?, confirm your data source boxes are checked, and the three covered hunts sort into your top 5 based on current prevalence and actor count. You click through to the markdown, paste the detection logic into your platform of choice, and you’re running something meaningful by lunch.

That’s the whole point. Context Graph tells you what matters, Coverage Map tells you where you stand, and What Can I Hunt? tells you what to run. Same library, three different questions, one workflow.

Try it

All three tabs are live now at hearth.thorcollective.com. If you find a coverage gap worth filling, the contribution workflow is linked directly from the gap alerts — submit a hypothesis and it’ll flow through the normal PEAK review into the next build.

Feedback, bug reports, and new hunts all welcome. HEARTH is only as useful as the community makes it, and these tabs are meant to make that contribution loop tighter.

The headline is hard to ignore. Anthropic’s Claude Mythos can autonomously discover thousands of zero-day vulnerabilities across major operating systems and browsers. A 72% exploit success rate. It found a 27-year-old OpenBSD bug nobody caught. Where Opus 4.6 generated two working Firefox exploits, Mythos generated 181 under identical conditions. The time between vulnerability discovery and a working exploit now looks like hours, not weeks.

The briefing lays out a 90-day plan for CISOs. It’s solid. But it’s written for people managing budgets and setting strategy.

We want to talk about what this means for the people actually doing the work.

This is a genuine inflection point. So naturally, the hot takes started rolling in: AI will replace security analysts. Threat hunting is dead. Humans can’t keep up.

They’re wrong. And they’re wrong for the same reason they’ve always been wrong. They keep confusing finding bugs with finding adversaries.

The Category Error That Won’t Die

Finding a bug in source code and finding an adversary living in your environment are fundamentally different problems. One is a code analysis challenge. The other is a behavioral detection problem. One looks at what software could do wrong. The other looks at what humans are doing wrong, inside your network, right now, with intent.

Could Mythos-class models eventually correlate authentication anomalies with lateral movement at 2 AM? Probably. Could they ask why a legitimate admin tool is running on a finance workstation outside a change window? Maybe. But that’s not a threat to hunting. That’s hunting getting faster. The methodology doesn’t go away because the tools got better. It gets more important because the volume and speed of what we’re up against just changed overnight.

The Model Isn’t the Moat (But It’s Not Nothing)

After Glasswing dropped, AISLE ran Mythos’s showcase vulnerabilities through small, cheap, open-weights models. Eight out of eight detected the flagship FreeBSD exploit. A 3.6 billion parameter model found it. Headlines followed: Mythos isn’t special, smaller models can do this too.

Not so fast.

AISLE isolated the vulnerable functions and pointed their models directly at them. That’s a very different problem than what Mythos did. Anthropic pointed Mythos at entire codebases with no guidance and told it to find something. It scoured millions of lines of code, identified the weak points, chained vulnerabilities together, and built working exploits. The targeting is the hard part, and AISLE skipped it.

But here’s what AISLE got right, and it matters for us: even with a frontier model, the value isn’t the model alone. It’s the system around it. The targeting. The methodology. The expertise that knows where to look and what to do with what you find.

That’s the threat hunting argument we’ve been making for a decade. The tool doesn’t matter. The SIEM doesn’t matter. What matters is the hypothesis, the iterative refinement, the human who understands the terrain. Every agentic security framework being built right now runs the same loop hunters have been running manually. Form hypothesis, collect data, analyze, iterate, improve the posture. We didn’t copy that from AI. AI copied that from us.

What Mythos Actually Changes

Mythos increases volume and speed. It does not change attacker behavior.

The biggest breaches we see today still come from the basics:

• credential abuse

• phishing

• supply chain compromise

• misconfigurations

Not zero-days.

Attackers still have to operate in your environment. And that shows up as behavior.

That’s what we hunt.

Detection Was Already Losing

Signature-based detection was already losing.

When exploitation happens faster than your patch cycle, detection tied to known CVEs is always late. You’re reacting after the exploit exists.

Threat hunting exists because of that gap.

Mythos doesn’t break the model.

It validates it.

What Actually Scales

When exploits can be generated at machine speed, the only thing that scales is behavioral hunting.

You’re not asking “was this CVE exploited.”

You’re asking:

• does this process tree make sense?

• does this auth pattern match baseline?

• why is this system talking to something new?

• who wrote to this directory?

None of that changes.

It just matters more.

The Real Problem: Memory

Most hunting programs don’t have memory.

Hunts get run, closed, and forgotten. Insights live in Slack. Knowledge walks out the door.

That was already inefficient.

At Mythos scale, it’s a failure mode.

If you can’t recall what you’ve already investigated, you can’t keep up.

What Needs to Change

The CSA briefing’s 90-day plan is good for CISOs. Here’s what it looks like translated to hunting operations:

This week:

• Assess behavior coverage, not just data

• Baseline auth, DNS, service accounts

• Write your hunts down

This month:

• Use AI to accelerate, not replace

• Generate hypotheses and draft queries faster

• Add quality gates

This quarter:

• Start building agents for repeatable work

• CVE → hypothesis generation

• baseline → drift detection

• recommendations → tracking

Humans decide.

Agents scale.

HEARTH: The Receipts

We keep saying “we hunt behavior.” Here’s what that looks like in practice.

HEARTH is the community hypothesis library we built at THOR Collective. It currently has 133 hypotheses, 19 baselines, and 15 analytical models, all structured using the PEAK framework. Every hypothesis targets a specific adversary behavior, not a CVE.

When we mapped the Mythos briefing’s threat categories to HEARTH, the coverage held up better than we expected.

• Supply chain attacks: npm compromise, VS Code extensions, PyPI poisoning, GitHub Actions abuse

• AI/agentic attack surface: MCP server abuse, prompt injection chains, LLM credential theft, autonomous recon

• Social engineering at scale: ClickFix variants, AI tool impersonation, fake VPN clients

• Baselines: non-human identities, DNS patterns, scheduled tasks, service account auth, PowerShell usage

It’s not complete. We don’t yet cover things like detecting exploitation of newly discovered kernel-level bugs or tracking patch velocity against disclosure rates.

But the model holds.

A shared library of behavioral hypotheses is exactly the kind of infrastructure the CSA briefing points to when it says coalitions win. HEARTH is open source. Every hypothesis is a pull request away from better coverage.

The Five Levels

The briefing calls for “Mythos-ready” programs but doesn’t define what that means. This is exactly the problem the Agentic Threat Hunting Framework (ATHF) was designed to solve.

• Level 0: Ad hoc - Hunts live in Slack. No structure, no memory.

• Level 1: Documented - Hunts are written and stored.

• Level 2: Searchable - Hunt history can be queried and recalled, including by AI.

• Level 3: Generative - AI assists with hypotheses and execution.

• Level 4: Agentic - Agents handle monitoring, triage, and workflow execution.

Most teams should be targeting Level 2 right now.

That’s the minimum viable response to this shift. Because at Mythos scale, memory isn’t optional.

It’s the difference between scaling and sinking.

The Bottom Line

Mythos didn’t change what threat hunting is.

It changed how fast we need to do it.

PEAK still works. Behavioral hunting still works.

You just need to move faster, remember more, and cover more ground.

The hunters who figure that out won’t just be fine. They’ll be the ones everyone else is depending on.

Mythos didn’t change what threat hunting is.

It changed how fast we need to do it.

Happy thrunting!

Leave a comment

Over the holiday break, I deployed a set of web honeypots on Digital Ocean and let them soak. No fancy banners, no fake login portals — just nginx instances logging every request to Loki, with a daily analysis pipeline crunching the data into structured threat models. The honeypots ran from January 1–16, 2026, collecting 71,768 total requests from ~400+ unique IPs per day across tens of thousands of unique URI paths.

Over the holidays I had some free time and decided to sit down and build out a project I had been kicking around for quite some time. I wanted to see if I couldn’t build a honeypot network across global AWS infrastructure, forward the goals to a single destination (my aggregator), and then analyze those logs to see if there were any noteworthy trends.

What came back isn’t groundbreaking in the “zero-day” sense. But it paints one of the clearest pictures I’ve seen of what the automated internet actually looks like when it hits your infrastructure — and more importantly, what it’s looking for. If you’re building hunt hypotheses, tuning detections, or trying to prioritize hardening, this is the kind of ground truth that matters.

Here’s what the data said.

The Shape of the Noise

Before diving into what was targeted, let’s look at the volume and rhythm.

Two things jump out immediately:

The baseline is remarkably consistent. On quiet days, you’re looking at ~2,500 requests from 300–400 unique IPs. This is the internet’s ambient scanning noise, distributed across many sources running standard checklists. Your average exposed service gets probed roughly this much every single day whether you notice or not.

The spikes tell a different story. January 5th saw a 6x volume surge driven by just three AWS-based /24 networks (13.59.55.0/24, 54.234.91.0/24, 54.175.183.0/24) running what appears to be coordinated broad enumeration. January 7th was even more dramatic — a single /24 (144.91.101.0/24) fired off 19,873 requests in 24 hours, cycling through nearly 20,000 unique URI paths. That’s one scanner working through a massive filename permutation list of backup files, config artifacts, and secret files across /api, /admin, /core, and /backup prefixes.

The contrast matters: Jan 7 had only 44 unique IPs but 20,000 unique URIs. A typical day has 350+ IPs but only 500–700 URIs. The spike wasn’t a DDoS — it was a single, methodical scanner running a very large dictionary. And honestly that’s just what the data showed because I hadn’t expected to get that many hits and logs were truncated to 20,000 lines.

What They’re Actually Hunting For

Here’s where it gets actionable. Across 16 days, I classified every URI into families based on what technology or misconfiguration it targets. The top 10 families by total volume:

1. Environment Files & Secrets — 12,365 hits (every single day)

Paths: /.env, /config.zip, /app/.env, /.env.ts, /api/env.zip, /.aws/credentials, /assets/credentials.json

This was the single most persistent category across the entire observation window. Every single day, scanners checked for exposed dotenv files, config archives, and cloud credential artifacts. The Jan 7 spike included 8,438 env-family requests alone — a massive run through .env path permutations.

The scanner toolkits aren’t just checking /.env anymore. Isaw probes for .env.ts, .env.production, env.zip, and even /.aws/credentials and /.aws/config. They’re adapting to modern deployment patterns.

Hunt angle: If your org deploys to cloud infrastructure, check your external attack surface for any 200 responses to dotenv paths. One exposed .env file is a full credential compromise. Also worth hunting for any CI/CD pipelines that might accidentally publish these to web roots.

2. Application Files & PHP Supply Chain — 10,903 hits (15 of 16 days)

Paths: /vendor/phpunit/phpunit/src/util/php/eval-stdin.php, /vendor/phpunit/phpunit/util/php/eval-stdin.php

Legacy PHP supply chain exploitation is alive and well. The phpunit eval-stdin.php path — a file that shouldn’t exist in production but does when vendor directories are accidentally web-accessible — was one of the most consistently probed targets. Multiple path variants are checked simultaneously, suggesting scanner dictionaries include known path permutations across different phpunit versions.

Beyond phpunit, this family includes broad .php, .asp, .aspx, .jsp probing, effectively fingerprinting what server-side technologies are present.

Hunt angle: Check for web-accessible /vendor/ directories in any PHP deployments. If phpunit eval-stdin is reachable, you have RCE. Also audit your build pipelines — do they strip vendor/test directories from production artifacts?

3. Backup File & Config Artifact Enumeration — 6,500+ hits (concentrated spikes)

Paths: /api/error.bak, /admin/backup/database.bak, /core/backup/database.conf, /backup/database.cfg

The January 7th scanner drove this almost entirely. It systematically checked /api, /admin, /core, and /backup prefixes combined with backup extensions (.bak, .cfg, .conf, .old, .save, .sql). The approach was pure permutation — take common directory prefixes, combine with common sensitive filenames, append every backup extension in the book.

This is a numbers game. Across thousands of targets, even a tiny percentage of accidentally published database backups or config files yields immediate credential access.

Hunt angle: Scan your own web roots for backup extension files. Any .bak, .sql, .old, .cfg file accessible via HTTP is a finding. Add deny rules at your web server/WAF layer for these extensions globally.

4. Login & Authentication Surface Discovery — 2,262 hits (10 days)

Paths: /login, /api/login, /signin, /auth, /core/skin/login.aspx, /owa/auth/logon.aspx

Scanners are cataloging what authentication endpoints exist — not (yet) brute-forcing them, but mapping the surface. Isaw probes for generic login paths alongside specific product surfaces: ASP.NET login forms, Outlook Web Access, and API authentication endpoints.

Hunt angle: This is reconnaissance. If these endpoints exist in your environment, ensure MFA is enforced, rate limiting is in place, and you’re monitoring for the credential stuffing that follows discovery.

5. Git Repository Exposure — 686 hits (13 of 16 days)

Paths: /.git/config, /.git/index, /.git/info/refs

Persistent, steady, and high-impact. Git exposure was checked almost every day with above-baseline emphasis. If /.git/config returns 200, an attacker can reconstruct your entire source code repository, including hardcoded secrets, internal API endpoints, and deployment configurations.

Hunt angle: This is one of the easiest wins for external attack surface validation. Test your own internet-facing services for /.git/config access. Block all dotfile directories at the web server level.

6. WordPress — 551 hits (7 days)

Paths: /wp-config.php.bak, /wp-content/w3tc-config/master-preview.php, /xmlrpc.php, /wp-admin, /wp-login.php

WordPress scanning came in waves, not constantly. When it appeared, it focused on configuration file backups (wp-config.php.bak, wp-config.php.old) and known vulnerable plugin paths rather than just login brute-forcing.

7. Dev-Server / Vite File Read (/@fs/) — 350 hits (3 days, sharp spikes)

Paths: /@fs/etc/passwd?import=, /@fs/.docker.env?import=, /@fs/proc/self/environ?raw??=

This was one of the more interesting findings. The /@fs/ pattern targets Vite dev server file-read vulnerabilities (CVE-2023-34092 and related). When a Vite dev server is accidentally exposed to the internet, the /@fs/ prefix can read arbitrary files from the host filesystem.

The scanners were specifically targeting /etc/passwd, .docker.env, and /proc/self/environ through this path — all high-value for credential harvesting or container escape.

Hunt angle: This is a great detection engineering target. Any production system responding to /@fs/ requests has a dev server exposed. Hunt for Vite or similar dev servers bound to 0.0.0.0 in production environments. The ?import= query parameter is highly specific and makes a clean detection signature.

8. Citrix Gateway (/+cscoe+/, /+cscol+/) — 201 hits (6 days)

Paths: /+cscoe+/logon.html, /+cscoe+/logon_forms.js, /+cscol+/java.jar

Perimeter device fingerprinting for Cisco/Citrix gateways. Consistent low-volume probing to identify if these appliances exist and are reachable. Once fingerprinted, follow-on exploitation of known CVEs is the playbook.

9. AI/LLM API Endpoint Discovery — 140 hits (appeared Jan 8)

Paths: /v1/messages, /v1/chat/completions, /openai/v1/chat/completions, /openai/deployments/gpt-4/chat/completions?api-version=2024-02-15-preview

This one caught my attention. Starting January 8th, Iobserved scanners probing for exposed LLM API endpoints — checking for OpenAI-compatible and Anthropic-style API paths. The requests targeted both generic paths (/v1/chat/completions) and Azure OpenAI deployment-specific paths with version parameters.

This is a relatively new addition to scanner dictionaries. Exposed LLM API proxies represent a direct financial risk (token theft/abuse) and a potential data exfiltration vector if the API has access to internal knowledge bases or RAG systems.

Hunt angle: Search your environment for any services exposing /v1/chat/completions or /v1/messages to the internet without authentication. If you run LLM inference proxies, API gateways, or development endpoints, confirm they’re not accidentally internet-facing. This is a fresh hunting target that most orgs probably aren’t monitoring for yet.

10. Management Surfaces — Steady Background

Across the 16 days, Ialso saw consistent probing for:

• Spring Boot Actuator (/actuator, /actuator/gateway/routes, /env, /health) — 118 hits across 6 days

• Docker Remote API (/containers/json) — 57 hits across 5 days

• Tomcat Manager (/manager/text/list, /manager/html) — 45 hits across 5 days

• GeoServer (/geoserver/web) — 29 hits across 2 days

• Trend Micro OfficeScan (/officescan/console/cgi/cgichkmasterpwd.exe) — appeared once

Each of these individually is low volume. Collectively, they represent scanners maintaining checklists of management interfaces that, when exposed, provide immediate administrative access or sensitive configuration disclosure.

The Scanner Ecosystem

Source Concentration

One of the clearest patterns was how source-concentrated the traffic was. The top 5 source networks accounted for the vast majority of requests:

The Jan 5 spike was three AWS /24s working together — likely a single operator using EC2 instances for distributed scanning. The Jan 7 spike was a single Contabo-hosted /24 running a much larger, more comprehensive dictionary against fewer targets.

Background noise comes from a rotating cast of 300–400 IPs per day, mostly running shorter, more focused checklists. The heavy hitters are episodic and concentrated.

Scanner Dictionary Evolution

Day-over-day, Itracked which URI families appeared as “new” — never seen before in the observation window. The pattern suggests scanner operators are actively refreshing their dictionaries:

• Jan 1: Tomcat Manager, .well-known/security.txt

• Jan 4: WordPress probing increase, /@fs/ dev-server pattern appears

• Jan 5: Broad enumeration surge with /@fs/ and secrets emphasis

• Jan 7: Massive backup/config permutation sweep (/api, /admin, /core, /backup)

• Jan 8: AI/LLM API endpoints (/v1/messages, /openai/*) appear for the first time

• Jan 11: GeoServer, OfficeScan fingerprinting

• Jan 12: Docker API, Exchange ECP export tool, AWS credential files

• Jan 14: VoIP/Polycom provisioning config fetches, embedded device login forms (/boaform/admin/formlogin)

• Jan 16: Increased Spring Actuator and embedded admin path checks

The LLM endpoint probing starting Jan 8 is particularly notable — it suggests these scanning tools are being updated to reflect the current technology landscape, not just running stale lists from 2020.

Defensive Takeaways

If you’re building hunts or hardening your environment based on this data, here’s where to start:

Quick wins (external attack surface):

• Block dotfile access (/.env, /.git/*, /.aws/*) at the edge. If any of these return 200 from your infrastructure, treat it as a confirmed finding.

• Deny backup extensions (.bak, .old, .cfg, .conf, .save, .sql) across all web-accessible paths.

• Validate that /vendor/ directories are not web-accessible in PHP deployments.

Detection engineering targets:

• /@fs/ requests with ?import= parameter — highly specific Vite dev-server file read indicator.

• /v1/chat/completions or /v1/messages on unexpected hosts — exposed LLM infrastructure.

• /containers/json — Docker Remote API exposure check.

• /actuator/gateway/routes — Spring Cloud Gateway route disclosure.

• /proc/self/environ — local file read validation attempt.

Hunt hypotheses:

• Are any internal dev servers (Vite, webpack-dev-server, Next.js dev mode) accidentally bound to external interfaces?

• Do any CI/CD pipelines publish .env, .git, or vendor test directories to production web roots?

• Are LLM API proxies, inference endpoints, or development servers exposed without authentication?

• Are any Spring Boot services running with Actuator endpoints exposed and unauthenticated?

Methodology Notes

The honeypots were nginx instances forwarding all access logs to a centralized Loki instance via Grafana’s log aggregation stack. A daily Python analysis pipeline pulled the raw logs, classified URIs into technology families using regex-based rules, tracked source IP concentrations at the /24 level (to capture infrastructure patterns), and generated structured threat models with day-over-day delta analysis.

Request counts were capped at 20,000 per 24-hour window and 40,000 per 7-day window in the collection pipeline, meaning actual volumes on spike days (particularly Jan 5 and Jan 7) may have been higher than reported. The 16-day observation window provides a useful snapshot but shouldn’t be treated as a comprehensive survey — regional and temporal variation in scanning patterns is expected.

The raw data and analysis pipeline are available for anyone interested in replicating or extending this work. Reach out if you want to compare notes. Attached is also my github projects with the code so you can deploy this yourself!

https://github.com/eliwoodward/Holiday-Honeypot-Vibecoded/tree/main

Happy thrunting. 🔥

Leave a comment

Annnnnnnddddd, we’re back. If you’ve been following along, you may be a career existentialist! Congratulations, you’re in good company.

In Part I of this guide, we talked about recognizing the cycle we find ourselves in when first considering a career in cybersecurity. Forcing ourselves to answer questions we don’t have enough context to ask, shaming ourselves for not knowing everything immediately, being fatigued by a surplus of varying resources…

You’re here because you found security and you have an itch to scratch. Perhaps you met a security engineer, were inspired by research that you happened upon, felt that it was time for a change, or always wanted to enter the industry but never knew how. Or, perhaps, it is what the legends foretold and this field was always going to find you :)

Regardless of how you got here - the questions running through your head are indeed universal, and the most common answers are isolating. Let’s dive into how you can take control of this journey and break the cycle that has been holding you back from being the badass security engineer you are meant to be.

^Ctrl + C: Breaking the Loop

Stopping the Spiral Before It Stops You

• Recognize the Pattern: The 7-step cycle from Part I isn’t productive learning - it’s anxiety masquerading as research. As soon as you recognize the existential loop starting, take a step away, get some fresh air, and give your mind a moment to breathe.

• Set a Timer: Literally. Give yourself 30 minutes and the grace to explore a rabbit hole, then force yourself to kill the process, realign, and refocus on the original task at hand.

• Ask Different Questions: Not “where do I fit in all of cybersecurity?” but “what problem do I want to solve right now?”

chmod +x: Anticipating the Paralysis and Executing Accordingly

When You Don’t Know Where to Start:

• Listen to Yourself: Pick the topic that made you feel something (curiosity, anger, excitement) most recently. I probably spent too much time trying to perfect the right topic for me – there is no correct answer; even seasoned security professionals take different paths before finding the thing that sticks.

• Do the Boring Stuff First: Can’t decide between malware research or threat hunting? Start with a basic tutorial; memorizing the advanced framework will do you no good, yet.

• Start a 2-Week Experiment: “I’m trying X for two weeks” is far less intimidating than “I’m committing to Y forever.”

When Imposter Syndrome Hits:

• Take Notes: Document what you did learn, not what you think you should know.

• Don’t Be Afraid to Ask Questions: Remember when not knowing something was fine? When you could just... ask? Somewhere between elementary school and now, we convinced ourselves that curiosity makes us look stupid. Of course you don’t know the latest IOC from last week’s attack. That’s okay! Understanding what IOCs are and why they matter will take you further than memorizing specific indicators that’ll be irrelevant in a month anyway.

• Network: This may be one of the strongest ways to challenge your imposter syndrome. Find one person who’s one (or a few) steps ahead of you and ask them a specific question. Have an industry leader you’re inspired by? Send them a message – I promise it’s worth pushing past the fear.

• Trust Yourself: You don’t need to be an expert to contribute. Curiosity and a passion for sharing knowledge are essential. The industry desperately needs new perspectives - yours included.

When Self-Doubt Creeps In:

• Reframe: “I don’t understand this yet” vs. “I’ll never understand this.” Every senior threat researcher was once someone staring at their first PCAP file with no idea what they were looking at. The difference isn’t talent – it’s persistence… the good kind ;)

• Build in Public: Leverage GitHub, Notion, CTF Time, TryHackMe, Hack The Box, and other platforms to record and share what you’ve learned, including projects or even an all-encompassing (and maybe slightly wordy) README.md, keeping track of the way you’ve managed your minutes. Not only will this help you show others what you’ve been up to, but it will also keep you organized.

• Record Your Wins: Every small breakthrough, every solved challenge, every lightbulb moment deserves to be celebrated. Don’t let your instinct force you to finish one thing and barely breathe into the next – slow down and celebrate progress.

The Moving Target Mindset

Remember the knowledge depreciation problem?

Here’s the reality: fundamentals outlive tools every single time.

Python syntax changes. SIEM platforms get replaced. Specific CVEs become irrelevant. But understanding how to think like an attacker, how to correlate disparate data points, how to ask better questions – these don’t expire.

The mechanics of social engineering remain consistent even as delivery methods evolve. Network protocols evolve, sure, but how systems fundamentally communicate? That’s not going anywhere.

When you’re choosing what to learn, prioritize concepts over implementations. Learn why security engineering works, not just how different platforms approach a problem. Understand what makes OSINT effective, not just which tools are popular this year. The tools will change. Your ability to adapt is what will set you apart and help you grow alongside the field.

Spiral vs. Progress: Knowing the Difference

Not all rabbit holes are bad. Some lead to breakthroughs. Here’s how to tell the difference:

You’re in a productive learning spiral if:

• You’re actively doing something (writing code, solving a challenge, building a project).

• Each new question brings you closer to answering your original one.

• You’re uncomfortable but engaged, not existential.

You’re in a paralysis spiral if:

• You’re reading about learning more than actually learning.

• You’ve opened 23 tabs but haven’t finished any of them.

• The overwhelm is growing, not shrinking.

• You feel more confused than when you started.

The spiral doesn’t make you a failure. It makes you human. Curiosity is an essential trait for a threat intelligence; but, there’s a difference between structured investigations and unproductive rabbit holes. The former solves problems; the latter just feels like work and often leads to burn out. So, reader, if you have 23 tabs open, ask yourself “am I getting closer to an answer, or am I just scrolling?” - let the answer redirect you accordingly.

Exit 0

You will always feel behind, and at first, you’ll feel uncertain too. The goal isn’t to eliminate that uncertainty – it’s to function despite it. The field will always move faster than anyone can keep up. Tools will become obsolete. Frameworks will evolve. Threat actors will pivot.

And you’ll keep learning anyway.

Not because you’ve found the perfect path or the right specialization or finally feel qualified. But because you chose to start somewhere and then keep going. The geolocation CTF at 2 AM. The MITRE technique you finally understood. The first time a detection rule you wrote actually caught something. The GitHub project gaining traction, stars & contributions…

These wins prove you can move forward even on a day when it feels like you’ve taken 10 steps back.

So, pick something. Anything. Give yourself two weeks. Then pick something else if you need to. The paralysis wants you to believe that choosing wrong is worse than not choosing at all. It’s lying.

I previously wrote a blog for THOR Collective Dispatch about some basic examples of different approaches when it comes to LLMs. It was cool and I hope it truly helps those starting out but I wanted to follow up and share some other more specific examples, including more “advanced” patterns that have worked for me over the past year or so.

We’ve all seen the scope, complexity and rise of usage of LLMs from products which integrate them, to all new product categories to ClawdBot. If you’re not familiar with all the facets of LLMs that’s okay but before I dive into these more advanced use cases, I think it’s advantageous to understand some terminology (at a high-level) when it comes to LLMs.

Once we have a firm grasp on these different concepts, I will provide some more concrete examples of how I have used LLMs in the past.

Terminology

This section defines some common (current) concepts related to LLMs but really, they are just Markdown with the exception that Assistants also may include code.

Prompting

Really this is exactly what I wrote about in my previous blog. In this approach/use you provide statement(s), with some minimal context, maybe some general requirements and either a question or a problem statement.

I’ve seen vibe coding thrown around but never cared to look it up but my understanding is that it’s either using speech to text and just describing your problems or just typing it out listening to some JL or Joey Cool (my current vibe). Often, I believe this approach of question, answer, fix, validate, test, fix, etc. is painful and can go awry pretty quick depending on the client used.

Vibe coding maybe useful for some but where the real work will happen in our industry will be in the trenches. You must know how to describe the problem you are trying to solve, which requires you to intimately know the problem.

Agents

Agents are the next “level” where there is very precise context given to an LLM. This context (which is really what this post is about) is about providing the guardrails for a request. Some provide this context in form of documentation, use cases, hard and loose requirements, gotchas, what not to do, perspectives including situational awareness statements and more. This can be 1,000-word document referencing 1 or 500 other documents to a single 50K (or more) prompt and typically includes extremely detailed descriptions, when to consider alternative options and especially negations of decisions.

SKILLS.md

Skills (e.g. SKILLS.md) are markdown files that essentially take everything a team knows about how to perform an action and writes a document that then feeds into an agent for absolute context, decision making, etc. These are almost identical to agents but I’ll let others decide where the naming concepts go.

Workflows

Workflows are like skills, but these are supposed to be directions for an LLM on how they should “analyze” or “examine” or “perform” the task being asked. For example, how to investigate an alert may have 1 or 15 steps defined including which tools (MCPs), how to interrupt results and how to make decisions before moving on to the next phase of the workflow.

I like to think of workflows in the same way we define/document playbooks but in markdown. I think a good starting place for more mature organizations would be to embed their existing incident response documentation and response playbooks into their Agents and/or Assistants. Iterate and go wild from there.

Assistants

This is the “newest” evolution (that I’m aware of) and I believe is where we are headed as an industry. Assitants are multi-faceted, customized and curated to tackle problems both big and small. These are the combination of multiple Workflows which trigger defined SKILLS.md and tools (MCP servers) and use multiple discrete agents to perform tasks along the way.

These are larger projects that allow someone to hook into how an LLM is called (via it’s API) - for example, this is how one such project called PAI works (btw, Daniel is definitely onto something here). These hooks are used to control the flow of operations all described in text and past decisions. It’s quite interesting but nuanced.

Context Is Key

I know that’s a lot, but really the first thing you need to understand is that this is really just all text/Markdown files. Instead of designing and defining how to communicate with a services APIs using some abstraction integration pattern, you can provide the docs and in plain English define what the inputs and outputs should be along with when to use it and how to perceive the results.

With everything said so far, I’d like to switch gears to provide some examples of why context maters and describing your problem succinctly will provide more value than “vibing” (I’m old) your way through it.
Let’s take this simple example I ran across the other week. Let’s say that you want to automate logging into multiple Google Chrome Profiles (you MSSP & thrunters know what I mean) and kick-off a simple hunt (search) in each. Why you may ask, because it’s tedious and you have to do what you have to do with the tools you have and really this is a silly example (and don’t really do this please).

Using this example, you may start up Claude Desktop/Code or Cursor and say:

As a threat hunter, I want to create a python package and CLI utility which accepts a list of Google Chrome Profiles to open. I want this package to ensure the latest ChromeDriver is installed. For each provided Google Chrome Profile provided as input, I want this tool to only accept Chrome Profiles that exist on the system and do not create one if it doesn’t exist. Once validated, it should create a new browser instance that opens in the provided profile display name and the first tab is X url.

Doing this may result in some success (again this is a simple example) but more than likely it will never get it right because it will guess at which Profile and only if that name exists will it try and open that profile. It may also take a completely different approach and may solve, it but I’d honestly be surprised.

If I change this prompt by adding the following, giving it context, it will understand and find the correct answer because it has been given explicit instructions and a determined example output.

… Ensure that the provided Google Chrome Profile name represents the display name shown within Google Chrome. For example, I have a profile named “Thrunting - X organization name” and it should match the input value”

This simple addition, of providing actual context and an expected result aligns the context/data inputs with your expected outputs; again guardrails.

This was a silly example, but I hope it provides some clarification that the more concrete outputs, decision points, paths to follow, descriptions of key terms, specifications, requirements and more in the context you provide to an LLM the better inference results.

p.s. The reason why LLMS do not understand that the values you are wanting to match reside in ./LocalState instead of its parent directory is beyond me but that is where those display names are located (FYI).

Back to the Basics

First, I want to reiterate that in order to build something meaningful using an LLM, you must NO MATTER WHAT first understand the problem you are trying to solve. If you don’t intimately know the problem, then start by writing what you do know and ask questions until you know what the problem is.

I’ve talked a lot about context but that’s a vague statement. In this section I wanted to provide some examples of context that I’ve found to be extremely beneficial when it comes to LLM output. Here is a non-inclusive list of context examples (in no particular order):

Personas -> Identities -> Personalities

When starting, this is less of a concern but as your knowledge base on how you prefer to use LLMs grows you probably want to repeat a process, especially investigations, analysis, research, and/or tooling. This is where you can describe the experience, technologies, frameworks, etc. to skew results towards your current knowledge.

For example, you can describe your preferred Python package layout, templates, etc. You can define a persona for different projects or code bases. The point is to use the tools you are familiar with already when starting out. Don’t just let the LLM use TypeScript if you have never use it previously.
Over time your design patterns, thinking logic and more can be recorded and use as persona or identity for repeatable work from a specific perspective and experience.

There are some projects, like PAI, which are experimenting on building personalities from defining your background, failures, successes, etc. Pretty weird to think about but also pretty cool.

Perspectives & Goals

Describe the perspective you want this problem to be researched or reviewed from. Whether that is QA as a staff level SDET or an elite red team ninja warrior. Defining these perspectives as well as the overall goals of the project will help keep scope within the problem space.

Here you can also define the overall skills (threat hunting, phishing defense, detection rule guru, etc.). You should also define the goals of the ask in general (e.g. find new and novel threats).

Tools

This is pretty straight forward but provide a list of different external tools which can be used within this project. Most of these will be MCP servers and their exposed methods. But it can also be things like:

• A local runner docker compose stack

• Guidelines on which tools to use:

  • use python not golang or js

  • Use python-fire for CLI, attrs models

  • Class and inheritance over utility functions, etc.

  • Use uv over poetry

  • Etc.

• Specific APIs with examples (Schema docs is preferred)

For all of these, provide context as to when to use the tool, how to use it and how to interpret the results. This will definitely improve your results.

Documentation

As much reference documentation you can provide will always be helpful but ensure that you are not bloating your token usage or extending beyond the context windows of these models; size of your prompt matters both on costs and the ability for the model to provide correct inference results.

Provide things like:

• API specifications

• JSONSchemas

• Repositories

• Internal & external docs to terms/keywords specific to your org/worldview

• Provide examples of similar problems

  • It is also advantageous to provide examples that you already have documented on solving a problem or of a previous investigation decision

In addition to these standard pieces of documentation, you should also provide what NOT to do. For example:

• Provide scenarios that will / may occur and describe what not to do and why

• Document when to not use a tool (defined above)

• Document what to do if a situation does occur that’s critical

Requirements

Like I have mentioned a few times, you must understand the problem to fully get the benefits of LLMs. Another great way to improve your research, discovery, analysis, etc. uses of LLMs is to ensure you provide all the business and technical requirements.

When defining technical requirements, provide things around when to use tools, different tools or frameworks to avoid using, and other specifics. For example:

• Defining the requirements can be as simple as “use caching of results” or specific enough to warrant something like “use Redis caching, using the rueidis go package”

• Document what not to use including languages, frameworks, etc.

• Define business requirements

  • This should likely be the largest section, but it depends on the end goal of the prompt.

• Define gotchas

There are lots of opportunities to write here. As a side note, I believe the ones that will prevail in the future of the “tech” industry are the ones that can describe a problem in detail effectively and efficiently as possible.

In addition to all of the above, I recommend checking out frameworks like Skills https://platform.claude.com/docs/en/agents-and-tools/agent-skills/overview and review projects which have implemented SKILLS.md to get a different perspective. We are in a new frontier and the frameworks, schemas, etc. are constantly evolving. Just look at MCP (plug for a MCP I wrote about a year ago https://github.com/MSAdministrator/enrichment-mcp) and its evolution (I still think they should have used gRPC https://github.com/modelcontextprotocol/modelcontextprotocol/discussions/1144).

Advanced Example

Now let’s get into an example. This is purely hypothetical and for posterity I’m actually not going to put this prompt into any LLMs and just let you try it for yourself (mostly because I don’t want to waste the energy — LLMs have Externalities that reach further than most other technology known to humans — what you input has an external cost that you may not realize).

Note: I wrote this in example below in like 30 minutes. Your mileage will vary depending on the number of details provided.

Description

As a senior security research engineer focused on building highly scalable threat detection systems. As a senior software engineer proficient in Golang, gRPC, Protobuf, unary and bi-directional streaming, ingestion processing using Kafka or google pub/sub, caching using Redis pipelining, Postgres (and ip4r) scaling using pgbouncer(s), kubernetes, monitoring and metrics using Prometheus.Your goal is to build highly scalable threat enrichment pipeline that can ingest logs of different services, extract the necessary IPv4/IPv6 addresses (as well as their context e.g. source ips vs destination ips, etc.) and perform enrichment providing precise geolocation information (for now you can use ipinfo sample databases).

This service can process anywhere from 100 to 1 billion IPs per day to enrich but performance throughput and low latency (10ms~) are REQUIRED.

Tools

You have the following tools available to you:

• Golang

• gRPC & protobuf for inner service communications

• Use Postgres (using the ip4r extension)

  • Use pgbouncer for scalable queries

  • Ensure proper indexes are in place

• Cache results using Redis (rueidis client library)

• Use kubernetes and light weight images

• Setup monitoring and metrics throughout the pipeline using Prometheus

Documentation

The following are references to use:

• Use the ipinfo sample databases https://github.com/ipinfo/sample-database as the core database structure

• Expect that the incoming logs are in this schemas format (link to schema or samples)

• It is expected that every log ingested will be enriched, but this does not mean every log will have values. Indicate in the log if enrichment occurred no matter if successful or not

• Ensure you are creating the appropriate views or queries utilize the correct ip4r data types https://github.com/RhodiumToad/ip4r

What Not to do

• Do not create two separate paths for ipv4 and ipv6 addresses

Requirements

• Ensure the pipeline can handle 1 billion events per day

• Ensure that you are extracting all IPs found and that each IP addresses found is enriched in the correct context (source vs. destination, etc.)

• Ensure that extract can be changed easily, you never know when new formats are going to be supported in the future

• Keep cached results for up to 18 hours (at a minimum) but provide a way to invalidate cache

• Ensure all communications are encrypted and have proper (and secure) authorization between services

• Create indexes that use the ip4r data types for IPs

• Data will be updated from a remote location at any time so upgrading of IP geolocation must be straight forward

I hope this more advanced example helps you understand that the more context you can provide the better results you will receive. Vibe coding is cool and all but just like how a Product/Project Manager will provide guidance for a project, you too must do the same in order to get the best results.

As I have stated previously, I believe that those who understand a problem fully and can describe it in detail, are the ones that will prevail as we move into this new era of technology advancement. Time will tell if I’m right or wrong.

Peace

Leave a comment

Nobody teaches this. I’ve read dozens of hunting guides, sat through countless conference talks, and co-authored an entire framework. We spend so much effort on how to start a hunt, how to form a hypothesis, how to pick your data sources. But the question of when to stop gets a hand wave at best.

And that’s a problem. Because right now, most of us are stopping hunts based on vibes.

The Vibes Problem

Be honest. How do you currently decide a hunt is over?

“It feels like I’ve looked at enough.” “We ran out of time.” “I didn’t find anything, so I guess we’re good?” “My boss asked for the report.”

None of those are termination criteria. Those are circumstances. There’s a difference between stopping a hunt and a hunt being done.

I’ve watched hunters burn through a full week chasing phantom lateral movement because they couldn’t articulate what “done” looked like. I’ve also watched hunters close a hunt in four hours because they ran a few queries, got no hits, and called it. Both are failure modes. One wastes resources. The other creates false confidence.

We need something better than vibes.

Coverage Criteria: Did You Actually Look?

The first question to ask yourself before closing a hunt: did I actually examine all the data sources that matter for this hypothesis?

This sounds obvious but it really isn’t.

One of my first hunts ever, I was hunting PowerShell and I totally missed looking at the Windows script logging events. Partly because I was new, but also because I didn’t document my data sources. There was no list of “here’s what I need to look at.” So I looked at what I knew about and moved on, thinking I’d covered it.

I hadn’t. And I didn’t realize it until way later.

Here’s what you could do. At the start of every hunt, write down every data source that’s relevant to your hypothesis. Not “everything we have,” but the specific sources that could contain evidence of the behavior you’re looking for. Then track which ones you’ve actually queried. Simple as a table in a notebook:

If there’s a “No” in that queried column when I’m thinking about closing the hunt, I’m not done. I either need to go look at it or explicitly document why I couldn’t (access issues, data not available, retention gap) and flag that as a coverage gap in my findings.

Coverage isn’t just data sources either. It’s time windows. If your hypothesis is about an intrusion that could have happened anytime in the last 90 days but your logs only go back 30, that’s a coverage gap. Write it down.

Diminishing Returns: The Same False Positive Three Times

There’s a pattern I see in every hunt that’s gone on too long. You start finding the same things over and over.

The same service account triggering the same alert. The same legacy application doing weird DNS stuff. The same admin using RDP at odd hours because they’re in a different time zone. You’ve already investigated these. You’ve already ruled them out. But you keep bumping into them because your queries are broad enough to catch them.

When this starts happening, pay attention. It’s a signal.

Not a signal that there’s nothing to find. A signal that your current approach has extracted all the value it’s going to. You’ve saturated your search space at this level of granularity.

At this point you have three choices:

1. Refine your queries to filter out the known noise and look deeper

2. Shift your approach entirely (different data source, different technique, pivot to a related hypothesis)

3. Acknowledge you’ve hit the floor and document what you found (including the noise)

Option 3 is valid. I know it feels like quitting. It’s not. It’s recognizing that more time in this direction won’t change the outcome. That’s professional judgment, not laziness.

Time-Boxing vs. Completeness

Every hunting team I’ve worked with has some version of this tension. Leadership wants hunts scoped to a sprint. Two days, a week, whatever fits the roadmap. Meanwhile, the hunter is sitting there thinking “but I haven’t checked the cloud logs yet.”

Here’s my take: time-boxing is necessary but not sufficient.

You need time constraints. Without them, hunts expand forever. I’ve seen it. A two-week hunt becomes a month because the hunter keeps pulling threads. Some of those threads matter. Most don’t. Without a boundary, there’s no forcing function to prioritize.

But a time box alone doesn’t tell you whether you’re done. It tells you when you have to stop. Those aren’t the same thing.

What I recommend: set your time box upfront, but also define your minimum coverage criteria upfront. If you hit the time box before you hit your coverage criteria, you have a decision to make. And that decision should be documented, not just made silently.

“Hunt time-boxed to 3 days. Completed analysis of Windows event logs, Sysmon, and EDR telemetry. Did NOT complete review of cloud audit logs or email gateway logs due to time constraints. Recommend follow-up hunt or including these sources in next cycle.”

That’s a responsible close. Compare that to: “Hunt complete. No findings.” Same outcome, completely different level of honesty about what you actually did.

The Confidence Spectrum

This is the thing I wish every hunter would internalize: “I found nothing” and “I am confident nothing is there” are wildly different statements.

“Found nothing” means your queries didn’t return hits. That’s a fact about your queries, not a fact about your environment.

“Confident nothing is there” means you examined the right data, with sufficient coverage, over the right time period, using techniques appropriate to the threat, and you can explain why the absence of evidence is meaningful.

Most hunts end with the first statement pretending to be the second.

I think about this as a spectrum:

• Low confidence: “Ran some queries, no hits.” You looked, but not deeply.

• Medium confidence: “Examined primary data sources for indicators consistent with hypothesis. No evidence found, but coverage gaps exist in X and Y.”

• High confidence: “Examined all relevant data sources across the full time window. Validated detection logic against known-good simulations. No evidence of the hypothesized behavior. Coverage gaps: none identified.”

Most hunts land somewhere in the medium range. That’s fine. But say so. Don’t let a medium-confidence hunt get reported as high-confidence just because it sounds better in a slide deck.

Documentation as Closure

A hunt is not done until it’s written down.

I don’t care if you found something or not. Null findings are findings. They’re data points that inform future hunts, justify detection investments, and build institutional knowledge about what you’ve looked at and when.

If you close a hunt with no documentation, it’s like it never happened. Six months from now, someone will hunt for the exact same thing because nobody recorded that you already did.

At minimum, your hunt closure document should include:

• Hypothesis: What were you looking for and why?

• Scope: What environment, data sources, and time window?

• Coverage: What did you actually examine? What didn’t you get to?

• Findings: What did you find? Include false positives worth noting.

• Confidence level: How confident are you in the result?

• Recommendations: Detections to build, data gaps to fix, follow-up hunts to schedule.

• Time spent: How long did this actually take?

That last one matters more than people think. If you’re tracking time spent per hunt, you start to build a picture of what types of hunts are expensive versus cheap. That data helps you plan better.

I know documentation isn’t sexy. Nobody got into threat hunting to write reports. But documentation is what turns a hunt from an activity into an artifact. Artifacts compound over time in ways that individual hunts don’t.

Where This Fits in PEAK

If you use PEAK (and if you don’t, here’s a template to get started), hunt termination should be baked into the Prepare phase.

PEAK has four phases: Prepare, Execute, Act, and Knowledge. Most people pour their energy into Execute because that’s where the actual hunting happens. But Prepare is where you define what success looks like, and that includes defining what “done” looks like.

When you’re building your hypothesis in Prepare, add termination criteria right next to it:

• What data sources must I examine before I can call this complete?

• What’s my time box?

• What confidence level am I targeting?

• What would “good enough” look like if I can’t hit full coverage?

Then, in the Act phase, your closure documentation naturally includes an assessment against those criteria. Did you meet them? If not, why not?

The Knowledge phase is where this really pays off. When you capture termination criteria and coverage assessments alongside your findings, you’re building a body of knowledge about your hunting capability, not just your hunting results. Over time, you can answer questions like “how often do we hit our coverage targets?” and “where are our persistent blind spots?”

That’s the kind of thing that separates hunting programs that stick around from ones that fizzle out after a year.

The Hunt Closure Checklist

OK, I promised something practical. Here’s a checklist your team can steal and adapt.

Before You Close the Hunt

• [ ] All scoped data sources have been queried (or gaps documented)

• [ ] Queries reviewed for correctness, not just “no hits”

• [ ] If nothing found, you can explain why the absence is meaningful

• [ ] Findings documented (including null findings)

• [ ] Confidence level stated (low / medium / high)

• [ ] Follow-up recommendations and detection opportunities logged

• [ ] Hunt artifacts (queries, scripts) saved somewhere retrievable

Red Flags That You’re Stopping Too Early

• You haven’t looked at all the data sources you scoped

• Your queries are too narrow (you’d miss variants of the behavior)

• You found something interesting but didn’t follow up because time ran out

• You’re closing the hunt to hit a metric, not because you’re done

Red Flags That You’ve Gone Too Long

• You keep finding the same false positives and re-investigating them

• You’re expanding scope beyond the original hypothesis without a clear reason

• You’ve shifted from “hunting” to “exploring” with no specific goal

• The hunt has consumed more than 2x its original time box

  

Closing Thoughts

Knowing when to stop is a skill. It gets better with practice and worse with neglect. The checklist above is a starting point, not a religion. Adapt it. Argue about it with your team. Throw out the parts that don’t work.

Even imperfect criteria are better than none. You can always refine them. You can’t refine a gut feeling.

Now go finish that hunt you’ve been sitting on. You know the one.

Happy thrunting!

Just before I sat down to write this, I had been analyzing different types of maps, thousands of photos of train tracks in British Columbia, cross-referencing transmission corridors with hiking trails to identify the real-world location of a nano banana-generated Ghibli-style scene… and falling in love with the process of finding a needle in a haystack. And yes, it was to find the first flag of a CTF.

My first exposure to cyberspace came from watching Garcia – the original OSINT queen – on Criminal Minds locate an assailant in under a minute, pinging cell towers and surfacing information about virtually anyone with a few keystrokes. I remember being 8 years old, thinking less about the theatrics and more about the mechanics, how she took barely tangential pieces of information and correlated them into something coherent enough to identify, locate, and stop a suspect. In hindsight, the earliest sign that I was a nerd was that I found the data more compelling than Shemar Moore.

Cybersecurity, I’ve learned, is expansive and rarely straightforward. For most end users, security starts and ends with password strength; for most entry-level practitioners – me included – impossible travel has a way of masquerading as the ultimate IOC; and for tenured researchers, definitive attribution can surface almost like a reflex. In a field defined by scale and complexity, the sheer volume of resources can make early learning feel paralyzing. Overwhelm, self-doubt, and indecision are common byproducts. You are not alone; rather than ignoring this existential truth, it’s worth naming it.

How We Ended Up Here

If you, reader, are anything like me, then you are familiar with the following process:

1. Have a question about something

2. Research the answer

3. Intermission to go down multiple irrelevant rabbit holes

4. Find the answer to the original question

5. End up with 1000 new questions

6. Existential crisis

7. Repeat!

This process is more so a rite of passage when entering the threat intelligence & cybersecurity space. It is also a litmus test of tolerance against the inherent nature of the job - you will always have unanswered questions, and that is what makes the work so exciting.

One of my recent encounters with this process was, naturally, at 2 AM as I maniacally tried to figure out the answer to the very pressing question: “Where in cybersecurity do I fit?”

This late-night rabbit hole was, in part, prompted by my discovery of Henry Jiang’s Map of Cybersecurity Domains. While Jiang outlines different facets of the industry in a very visually pleasing and palatable way, the map left me more confused than it did entice me to any one niche. Every domain connected to three others; technical paths bled into compliance tracks; creative OSINT work sat alongside cryptography and risk frameworks. The vastness wasn’t inspiring; it was paralyzing. Blue teaming, red teaming, security & detection engineering, threat intelligence research… the list continues, my question still unanswered.

sudo whatdoichoose

Paralysis sets in when you’re optimizing for the perfect choice rather than taking the next step. Getting unstuck means understanding the mechanics of the loop you’re in, and then deliberately disrupting it.

Permission Denied: Why Paralysis Happens

• The Paradox of Choice & Hick’s Law: Unlike other fields with linear progressions, cybersecurity offers infinite branching paths that are constantly evolving. (If you want the science behind why this breaks your brain, look up Hick’s Law – TLDR: more options = longer you’ll stare at the screen doing nothing).

• The “I Need to Know Everything” Trap: Security engineers & researchers of all specialties are especially prone to this – if everything is connected, how do you choose just one thread?

• Imposter Syndrome as a Feature, Not a Bug: Everyone feels underqualified. The field moves faster than anyone can keep up. This is normal. Some moments will feel like your head is well above the water, and some will feel like your back is turned to a crashing wave.

• The Resource Rabbit Hole: You search “how to get started in threat intelligence” and get a seemingly uncountable number of YouTube videos, vendor blogs with conflicting methodologies, GitHub repos of varying quality – some abandoned, paid courses, and Twitter threads that all assume different baseline knowledge.

Curating a comprehensive learning path becomes a full-time job. You spend three hours building a perfectly organized bookmark folder and a Notion page of resources, then feel so mentally exhausted you can’t actually start learning from them. The research about learning displaces the learning itself.

The Knowledge Depreciation Problem

Why it Feels Like You’re Always Starting Over

You finally wrap your head around basic Python scripting, and suddenly everyone’s saying you should learn Go or Rust for security tooling. You master the fundamentals of approaching and solving CTF or OSINT challenges, only for the platforms you learned on to get shut down or paywalled. You spend weeks understanding MITRE ATT&CK techniques, and new research comes out that reshapes how those techniques are approached.

This isn’t unique to cybersecurity, but the velocity is brutal. By the time you feel competent with the basics, the landscape has shifted. This creates a vicious cycle: “Why should I invest time learning X if it’ll be obsolete as soon as I understand it?”

The paralysis here isn’t about too many choices – it’s about the fear that any choice you make has an expiration date. You’re not just learning a skill; you’re trying to hit a moving target that you can’t even see. Ask yourself: what would happen if you stopped chasing the target altogether? The answer may surprise you - and it’s coming up next.

For the last several weeks, I’ve been working on a project called PACMap - the Privacy, AI & Cybersecurity Map. It’s a free, open-source regulatory intelligence platform that tracks global cybersecurity, data privacy, and AI regulations in one place.

It’s live now at pacmap.dev.

Why This Exists

If you’ve ever had to answer the question “what regulations apply to us?” - you know the pain. You’re digging through government websites, PDFs, scattered news articles, and maybe paying for an expensive commercial database that still doesn’t have everything you need. There’s no single, free, well-organized source of truth for global cyber, privacy, and AI regulation data.

That bothered me. So I built one.

PACMap currently tracks 800+ regulations across 160+ jurisdictions worldwide, spanning legislation from the 1970s through proposed bills that haven’t been enacted yet. It covers four categories: cybersecurity, privacy and data protection, artificial intelligence, and cross-section laws that span multiple categories.

What’s Inside

Here’s what you get when you visit:

An interactive dashboard with summary stats, charts by category, region, and status - plus a heatmap globe showing regulatory density by country. A full-text search that lets you filter by jurisdiction, category, legislative status, date range, and keywords. Regulation detail pages with structured breakdowns of each law - scope, enforcement, key requirements, deadlines, cross-references, and links to official sources. A visual timeline of when regulations were proposed, adopted, and enforced. A compliance calendar for upcoming deadlines. Data confidence indicators on every entry so you know how reliable each record is. And an AI-powered research agent that automatically finds and adds new regulations weekly, so the platform stays current without manual updates.

The kind of thing you can use at your desk but also pull up in a board meeting without anyone asking why it looks like a hacking tool.

The Builder’s Mindset

Here’s where the THOR Collective thread comes in.

We’ve been talking all season about builders showing up. About AI lowering the barrier. About practitioners creating the tools they wish existed instead of waiting for a vendor to maybe get around to it.

PACMap is me doing exactly that.

I’m not a full-time software engineer. I’m a cybersecurity professional who got tired of a gap in the market and decided to close it myself. I used Claude Code as my primary development partner - Python backend with FastAPI, React frontend, the whole stack. The AI didn’t build it for me. I still had to know what I wanted, make the design decisions, validate the output, security scan everything, and push through every phase. But it made a solo side project of this scope actually possible.

That’s the real message: if you can clearly describe what you need and you’re willing to put in the work, you can build things that used to require a team.

It’s Free. It’s Open Source. It’s Yours.

No ads. No paywalls. PACMap is a free resource for the community. I may add a donation option down the road to cover that, but the platform itself will stay free.

For the Community

This is where the community part matters.

PACMap currently has 831 regulations ingested and growing. But there are hundreds more out there, and regulations change constantly. I need people to tell me what’s missing, what’s wrong, and what needs updating.

If you spot a regulation that’s not in there - let me know. If something’s outdated or inaccurate - flag it. If your jurisdiction isn’t well represented - I want to hear about it.

You can submit to the project at contact@pacmap.dev or through the usual THOR Collective channels.

What’s Next

The roadmap includes email alert subscriptions by jurisdiction or category, side-by-side regulation comparison, compliance mapping to frameworks like NIST CSF and ISO 27001, controls exports, a public API, and so much more.

But right now, the most important thing is that it’s live, it’s free, and it’s built for you.

Go check it out: pacmap.dev

Leave a comment

PACMap is an independent, community-oriented project. Corrections, suggestions, and missing regulation reports are always welcome.

📝 Episode Summary

New year, same crew — and we’re building. The THOR Collective kicks off 2026 (Season 2!) with a deep dive into why this is the year security practitioners stop waiting on vendors and start building their own solutions. Lauren, Sydney, and John walk through the trio of Dispatch posts that kicked off the year — a manifesto series on building in security — and why the “I’m not technical enough” excuse doesn’t hold up anymore in the age of AI-assisted development.

From there, the hosts get into the real talk: what’s actually trending in security right now (spoiler: social engineering isn’t going anywhere, and the agentic attack surface is the new frontier), what’s overhyped (looking at you, “AI SOC that replaces all your analysts”), and what each of them is personally investing in this year. Sydney’s going deep on LLM evaluations and automated baselining. Lauren’s leveling up her rapid development and project scaffolding skills. John’s bouncing adversarial emulation ideas off AI — when it’ll let him.

The episode wraps with a lightning round covering certs vs. hands-on work, writing detections vs. hunting, specializing vs. staying broad, and prompt engineering vs. YOLOing it. Plus: conference announcements (CactusCon, WiCYS, BSides SF, RSA, DEF CON), puzzle swaps, PAI voice scaring partners, and Lauren’s Odyssey-inspired take on AI as Athena; a helper on your journey, not a replacement for the hero.

⏱️ Episode Breakdown

• 00:01 – Intro and welcome to Season 2

• 03:20 – January Dispatch Highlights: “2026, The Year Builders Show Up” by Lauren & Sydney

• 09:22 – “Why You Should Build” by Lauren – breaking the psychological barrier

• 13:00 – “Why You Don’t Need a Desk to Build” by Sydney – shipping code from anywhere

• 16:32 – What are we trying to solve? The mission behind the builder series

• 18:40 – Staying current on AI: AI Daily Brief, Prompt GTFO, and community resources

• 20:45 – What’s trending: social engineering, browser extensions, OpenClaw/MoltBot, agentic attack surfaces

• 24:57 – AI finding vulnerabilities: OpenSSL discoveries and the CVE explosion

• 27:45 – What’s overhyped: the “AI SOC” replacing analysts narrative

• 30:00 – Risk tolerance and the human-in-the-loop debate

• 34:25 – What we’re investing in: LLM evaluations, automated baselining, rapid development, adversarial emulation

• 39:20 – What we’re ignoring: personal balance, saying no, giving up on red teaming

• 41:27 – Hot take: ignoring prompt engineering (and the Wispr Flow revolution)

• 43:00 – PAI voice scares

• 46:04 – Lightning Round: Certs vs. hands-on, detections vs. hunting, specialize vs. stay broad, prompt engineering vs. YOLO

• 53:00 – Conference circuit and closing: CactusCon, WiCYS, BSides SF, RSA, DEF CON, SecKC

🎤 Hosts

Lauren Proehl (Host) – Manager of the group, chronic overcommitter, manifesto writer, and self-described “cautious optimist.”

Sydney Marrone (Host) – Threat hunter turned builder. Shipping code from her phone, couch, bed, and probably CactusCon’s after party. Investing in LLM evaluations and automated baselining this year.

John Grageda (Host) – Red teamer who uses AI for adversarial emulation and engagement planning, but notes the models still refuse to build offensive tooling (”nice try, buddy”).

🔗 Resources & Mentions

January 2026 Dispatch Posts

• 2026: The Year Builders Show Up by Lauren Proehl & Sydney Marrone

• Why You Should Build by Lauren Proehl

• You Don’t Need a Desk to Build by Sydney Marrone

Tools & Resources Mentioned

• Claude Code – AI coding assistant used by the hosts for building security tools and personal projects

• PAI (Personal AI) by Daniel Miessler – personal AI assistant with voice capabilities

• Wispr Flow – voice-to-text tool for talking at your AI instead of prompt engineering

• Detect FYI – article by Alex Teixeira on automated baseline detections (30-day baseline + hourly deviation checks)

• AI Daily Brief – recommended podcast for staying current on AI news

• Prompt GTFO – community resource on cybersecurity and AI

• OpenClaw / ClawBot / MoltBot – AI agents and social networks that had the hosts questioning reality

Vulnerability Research & Bug Bounty

• AISLE Discovers 12 OpenSSL Vulnerabilities (Jan 2026) – AI-powered autonomous analyzer found all 12 CVEs in the January 2026 coordinated release, some dating back to 1998

• The End of the curl Bug-Bounty (Daniel Stenberg) – curl ended its HackerOne bug bounty program January 31, 2026 due to flood of AI-generated slop reports

• Google: Building AI Agents for Cybersecurity and Defense – Google’s approach to agentic defense and building security agents

• Slack Engineering: Streamlining Security Investigations with Agents – Slack’s approach to agentic SOC defense using AI agent personas (Director, domain experts, Critic) that break investigations into phases

Key Concepts Discussed

• AI as Augmentation, Not Replacement – Lauren’s Athena analogy from The Odyssey: AI is a helper on your odyssey, not a replacement for the hero

• The Builder Mindset – scripts, queries, playbooks all count as building; you don’t need permission from the developer gods

• Return of Generalism – AI raising the floor for lower-level analysts, enabling dynamic workforce reallocation

• Agent Manager Future – the theory that everyone becomes a manager of teams of AI agents

• Trust but Verify – applies to both AI and humans; both make mistakes

• The Boot Camp Loop – AI helps break the cycle of training without applying

• Automated Baselining – 30-day baseline detection + hourly checks against deviations (Detect FYI approach)

• Agentic Attack Surface – the unknown frontier of securing AI agents and agentic workflows

Trends Discussed

• Social engineering and phishing – still trending, now AI-enhanced

• Browser extensions – emerging attack vector

• OpenClaw/MoltBot ecosystem – AI agents with their own social networks

• AI vulnerability discovery – 12 OpenSSL vulnerabilities found by AI, some allegedly decades old

• CVE reports up ~39-40% last year

• Google’s agentic defense approach – breaking prompts into investigation phases

• Prompt injection – social engineering AI agents and models

• Curl leaving HackerOne due to AI-generated bug bounty report influx

📢 Call to Action

• Read the January builder series on Dispatch – and start your own building journey; even a script that saves you a few minutes counts

• Try building something you’ll actually use – throw it on GitHub, start small, keep building

• Check out the AI Daily Brief podcast and Prompt GTFO – for staying current on AI and security

• Get Wispr Flow – if you struggle with prompt engineering, just talk at your AI

• Explore automated baselining – use the Detect FYI approach (30-day baseline + hourly deviation checks)

• Come find us at CactusCon – February 2026, THOR Collective is sponsoring the after party; swag will be available

• Write for THOR Collective – always looking for new voices, up-and-coming voices, and first-time publishers; reach out on socials

📬 Connect with THOR Collective

🗣️ Social Media:

• Twitter/X: @THOR_Collective

• LinkedIn: THOR Collective

• BlueSky: @thorcollective

📧 Contact:

Reach out through any social channel for guest post opportunities, collaborations, or to share what you’re building in 2026

Here’s the thing: most people prompt LLMs like they’re searching Google. They type a few keywords and expect magic. That doesn’t work, especially for security work where context and precision matter. You wouldn’t walk up to a senior analyst and say “phishing bad, clicked link, help” and expect useful output. Same principle applies here. The way you prompt these tools completely changes what you get back.

I don’t claim to be an expert by any means so please take this all as my opinion--I know there are many other ways to approach using LLMs. I’ve used approaches like:

• writing a design & requirement document and feeding that into an LLM while writing examples shared below.

• providing a repository of code and giving clear problem statements

• question & answer analysis

• etc.

Here’s some examples of how I think they can be most useful for security peeps just starting out with LLMs.

Role-Stacking: Set the Stage

One of the most effective techniques I’ve found is what I call “role-stacking.” Instead of just asking a question, I tell the LLM what perspectives I need it to consider. I also found that using my own experience when setting the stage is extremely helpful since it’s what I know.

Here’s an example:

As a security analyst and phishing threat detection expert. As a software engineer experienced with Python, Flask, and Docker.

Create a simple Flask (bootstap, etc.) application to collect DNS, WHOIS/RDAP, HTML and other opensource threat intelligence for a given URL.

Notice what I did there. I’m not just asking “create a simple flask application.” I’m telling the LLM to think from multiple angles simultaneously—security analysis, phishing expertise, and software engineering. This produces output that bridges disciplines rather than staying siloed.

For SOC analysts, this might look like:

As a SOC analyst experienced in alert triage. As a threat hunter 
familiar with MITRE ATT&CK. As someone who has dealt with alert 
fatigue firsthand.

Analyze this detection rule and identify potential blind spots or false positive generators.

The role-stacking approach forces the LLM to consider your problem from multiple angles, which often shows you things you wouldn’t get from a single-perspective prompt.

Be Explicit About Your Technology Stack

LLMs perform dramatically better when you tell them what you’re actually working with. Be specific about the technologies, products, and constraints in your environment (as much as you know).

Here’s how I do it:

As a senior security engineer and sr. software engineer. Experience 
with Docker, Kubernetes, caching, data streaming, gRPC, protobuf, 
JSONSchema, common data models, Puppeteer, Playwright, extensive 
experience with APIs, network communications, web frameworks, 
anti-bot detection, Chromium, Selenium, network captures, monitoring, 
knowledge about fingerprinting, cookie injection, evading behavioral 
turnstiles/captchas.

Using these technologies, products, tools, frameworks and knowledge 
bases, let's design an application that [specific goal]...

I know that looks like a lot. I mean, it is a lot. But here’s why it matters: the LLM now knows exactly what tools are on the table. It “shouldn’t” suggest solutions using technologies I don’t have (but it does sometimes but I have found this approach helps). It’ll reason within my actual constraints most of the time. When it does, it’s a huge benefit--especially when you’re trying to solve real problems in your actual environment—-not hypothetical ones.

For threat hunters, this might be:

As a threat hunter with access to Splunk, CrowdStrike EDR, and 
network flow data. Working in a hybrid cloud environment with 
AWS and on-prem Windows infrastructure. Familiar with Sigma 
rules and MITRE ATT&CK.

Help me develop a hunting hypothesis for [specific threat behavior].

Request Thoroughness Explicitly

So, how do you get past the surface-level responses? LLMs will often give you the quick answer—which is usually the shallow answer. If you want depth, you have to ask for it and provide a very specific example output.

I frequently use phrases like:

• “Take your time, think through carefully”

• “Use critical systems thinking”

• “Consider batch and streaming patterns, integration patterns, and how this evolves over time”

• “Do not hallucinate and validate any decisions and findings”

That last one is important. Honestly, these tools can confidently generate plausible-sounding nonsense. Telling them explicitly to validate their reasoning helps—not perfectly, but noticeably.

Here’s an example:

Using your knowledge of cyber security and threat intelligence 
as it relates to phishing defense. We are evaluating several 
products to integrate into our detection pipeline.

We are evaluating VirusTotal GTI, Team Cymru, Feedly, and any.run.

Knowing all that, create an evaluation criteria process.

Take your time. Think through carefully. Do not hallucinate—validate 
any decisions and findings.

Ask for Current Information

This is especially important for security work where the landscape changes constantly. Tools, techniques, and threat actor behaviors evolve. Explicitly ask for updated context:

Search for the latest information regarding security tools and products.

Evaluate the best option for a sandbox analysis tool when it 
comes to inspecting and analyzing both phishing links and 
attachments from phishing emails.

Will the LLM always have the latest data? No. Prompting it this way encourages it to reason about recency and often produces more thoughtful responses about what might have changed. Luckily, many of these tools have web search capabilities, so this prompt pattern becomes even more effective.

Think in Systems, Not Point Solutions

Security work is inherently about systems—interconnected components that create emergent behaviors (and emergent vulnerabilities). I prompt AI tools to think the same way.

Here’s an example from my own work:

Imagine you have a platform which can use a list of indicators 
to hunt backwards in time for up to 30 days. The list of indicators 
per type (domains, IP addresses, URLs, files) will add about 
2 million new indicators per day that we must back-test/hunt for. 
As each day passes, the indicators exponentially grow in size.

Provide 5 options for building a system to handle and manage this data for X years. Remember to use critcial systems thinking.

This prompt describes a real systems problem—not a feature request. The tool now has to reason about data growth, retention strategies, computational constraints, and tradeoffs. That’s the kind of thinking that produces useful output.

For SOC analysts dealing with alert volume, try:

Our SIEM generates approximately 50,000 alerts per day across 
200 detection rules. About 15% of our analyst time is spent on 
5 rules that generate 60% of the volume.

How should we approach optimizing this situation? Consider both short-term tactical fixes and 
longer-term strategic improvements.

Practical Tips for Getting Started

If you’re new to using LLMs for security work, here are some concrete starting points:

• Start with role-stacking: Before every prompt, think about what perspectives would be valuable. Security analyst? Software engineer? Incident responder? Stack them.

• Be embarrassingly specific: Include your actual tools, technologies, and constraints. The more context, the better the output.

• Ask for validation: Explicitly request that the LLM validate its reasoning and not hallucinate. It helps.

• Think in systems: Frame your questions as systems problems, not isolated tasks.

• Iterate: Your first prompt won’t be perfect. Refine based on what you get back. Tell the tool what was useful and what wasn’t.

Finally, if you really want to stretch how you think about LLMs. Once you have completed a project / idea tell the tool to write a mark down file that can be used next time when wanting to create a similar tool (or just a project in general).

An additional approach I have been playing with is asking the LLM to generate this markdown document in a way that considers current and future progressions of how we interface with LLMs and to build it in a way that is most efficient for the LLM itself.

For example:

Assess this project as a whole and generate a markdown definiton that will be used in the future for similar projects. Think about the current adoption and patterns used to interact with LLMs as well as future progression based on industry trends.

Generate this document so that it is efficient, clear and precise for future iterations.

That’s it! These six techniques cover about 90% of how I get value from LLMs in my daily work.

A Note on People

With that being said, I want to be clear about something: these are tools to augment human judgment, not replace it. The value of a good security analyst isn’t their ability to generate text—it’s their judgment, their intuition, their ability to recognize what doesn’t fit.

LLMs help me move faster through the mechanical parts of my work. They help me explore ideas, draft documentation, reason through complex systems. But the decisions? Those are still mine.

As InfoSec professionals, we’re responsible for the security of real people and real organizations. LLms can help us do that job better—but only if we stay in the driver’s seat. Just remember that these tools are amplifiers—they amplify good thinking and bad thinking alike. Bring the good thinking.

What’s Next

I’m still learning how to use these tools effectively. The techniques I’ve shared here are simplified examples of what’s working for me right now, but I expect they’ll evolve as the tools themselves improve.

I’m currently building my own agent and workflow (state machines) so I may write about that next as I continue to learn and adapt on the many ways you can approach those problems.

In the real world, especially more complex work, I define my goals, general requirements, my constraints, ideal/desired inputs and outputs. Remember the more context you given an LLM the better it will be (e.g. provide reference API docs, schemas, query examples, etc.).

If you’ve found effective prompting patterns for security work, I’d love to hear about them. Reach out on LinkedIn or GitHub—let’s share what’s working.

I hope this helps some of you get more out of these tools. The threat landscape isn’t slowing down. Neither should we.

Enjoy!

Leave a comment

Here’s the thing: I used AI more last month on my phone than I did from my desk. The dual monitors. The mechanical keyboard. The chair that cost more than my first car. Turns out, all of that was just ✨ aesthetic procrastination ✨ with better cable management.

The Lie We Tell Ourselves

“I’ll start that project when I have time to really sit down and focus.”

Sound familiar? Meanwhile, your phone sits in your pocket—a supercomputer capable of running AI assistants, connected to every repo you’ve ever touched, waiting for you to realize you were the bottleneck, not your environment.

The truth is brutal: the battlestation is a cope. A beautiful, RGB-lit cope that lets us feel like developers without actually developing.

My Setup (It’s Unserious and It Works)

This is what I use for my personal projects—the side quests, the experiments, the stuff I build because I want to, not because someone’s paying me:

Hardware:

• iPhone (yes, really)

• A computer under my desk (could just as easily be a cloud server)

Software:

• Happy Engineering app - Claude Code on my phone (requires a Claude Pro or Max subscription)

• PAI (Personal AI Infrastructure) - ’s AI framework, tailored to my codebase, my preferences, and my neurodivergent brain. HUGE KUDOS for this. Absolute chef’s kiss.

• Git - Still git. Some things don’t change.

The computer’s under my desk (or in the cloud). I’m usually not.

PAI is the whole point.

I have my entire Personal AI Infrastructure around Claude Code. Skills that know how to do specific jobs. Memory that persists across sessions. Response formats designed for my neurodivergent brain. It remembers my projects, my preferences, my half-finished ideas from three weeks ago.

When I say “fix the research bug,” PAI knows which repo (usually HEARTH), which research system, and which bug I’ve been ranting about. I don’t re-explain context. I don’t copy-paste file paths. I just talk to it like a teammate who’s been in every meeting.

This isn’t autocomplete. It’s continuity.

The Part Where I Stopped Fighting My Brain

“Just sit down and focus.” Cool advice. About as useful as “just be taller.”

For years I thought productive meant more structure, more routine, more discipline. More of everything I was apparently bad at. I tried to force my brain into a shape it wasn’t designed for. Spoiler: it didn’t work.

Then I tried something different: meeting my brain where it actually is.

My brain wants to work at weird times. Fine. My brain can’t sustain attention for 4-hour deep work blocks. Fine. My brain gets distracted and needs to context-switch. Fine.

Mobile development doesn’t fight any of this. It leans in. Got 10 minutes waiting for food? Ship a fix. Lying awake at 2 AM with a solution? Actually implement it instead of praying you’ll remember it tomorrow. (You won’t. You never do.)

The Hemingway Technique

Ernest Hemingway famously stopped writing mid-sentence each day. Not because he was done, but because he knew exactly where to pick up tomorrow. The friction of “where do I even start?” vanished.

Here’s how it works for code:

Before Bed (5 minutes, from your phone):

1. Describe what you want to build

2. Let AI help you plan it

3. Identify the overnight task

4. Hit execute and go to sleep

While You Sleep:

• AI writes the code

• Runs the tests

• Documents what it did

Morning (whenever you wake up):

• Review the diff

• Merge or iterate

• Feel like a wizard

This isn’t theoretical. This post? Planned from my bed at 11 PM. Drafted by AI overnight. Reviewed and published while I had coffee.

“But what if the AI writes bad code?”

It might. You review it. Same as reviewing any junior dev’s PR, except this one doesn’t get offended when you request changes and actually learns from the feedback.

The Response Format That Changed Everything

I used to dread reading AI responses. Walls of text. Nested bullet points. Tables that didn’t fit on mobile. By the time I scrolled through the explanation, I’d forgotten what I asked.

So I built a format for my brain:

🎯 Task summary • Status

📌 RESULT:
Answer first. Always.

✅ DONE:
• What happened
• Evidence it worked

⏳ NEXT:
• What's coming

💬 PAI: 16 words max summary

15-20 lines max. Answer at the top. Emoji anchors for scanning. No tables.

The format got me to actually read the thing.

What I’ve Actually Built From My Phone

Because talk is cheap:

• Full PAI skill system - The AI infrastructure that powers my workflow

• Multiple HEARTH submissions - Threat hunting doesn’t care where you sit

• This entire blog setup - Hemingway’d into existence

• Bug fixes at 10 PM - The best time to fix bugs is when you’re annoyed enough to actually do it

• Automation scripts - Usually while waiting for something else

None of this required a desk. All of it required admitting that the desk was never the point.

The Obligatory “Be Smart About This” Section

Look, I’m not telling you to YOLO production deploys from your phone at 2 AM. (Okay, maybe I did that once. Don’t be like me.)

AI-assisted coding is powerful, but it’s not magic. You still need to:

• Review what gets generated - AI makes confident mistakes

• Understand what you’re shipping - Don’t merge production code you can’t explain

• Use sandboxing - Let AI run wild in containers, not on your host

• Know when to stop - Sometimes “wait until morning” is the right call

• Keep humans in the loop - Especially for anything that matters

The goal isn’t reckless speed. It’s removing artificial barriers between you and the work you actually want to do. Be smart. Be careful. But don’t let “being careful” become another excuse to never start.

Will this workflow change? Probably. The tools will get better, my needs will shift, and I’ll find new ways to break things. The principle stays: work where your brain works, not where productivity culture says you should.

Permission Granted

You don’t need the perfect setup. You need a phone and five minutes of “what if this works.”

You don’t need to fix your neurodivergent brain. You need tools that work with how you actually function.

Open your phone. Talk to an AI. Ship something.

The best time to build was when you had the “perfect” setup you never actually used. The second best time is now, from wherever you are, with whatever you have.

Resources

Tools Mentioned (and a bonus):

• Happy Engineering - Claude Code on mobile

• Claude Code - The AI foundation

• PAI (Personal AI Infrastructure) - My version of this system. Persistent memory. Custom skills. neurodivergent-friendly everything. This is the thing.

• Hemingway Technique - The bedtime planning workflow

• Superpowers - Jesse Vincent’s structured workflow system for AI agents - gives Claude Code guardrails and process

Related Dispatch Posts:

• “2026: The Year Builders Show Up” - More on the permission-to-build philosophy

• “Why You Should Build” - ’s take on creating vs. consuming

  THOR Collective Dispatch is a reader-supported publication. To receive new posts and support my work, consider becoming a free or paid subscriber.

Ask any artist and they can tell you about this feeling. A painter staring at a blank canvas. A musician sitting down with an instrument and an idea that does not have a shape yet. A writer wrestling with a sentence until it finally says what they meant. Building is an act of defiance against the void. You looked at nothing and decided something should exist there.

Security practitioners are not taught to think of themselves this way. We are taught to defend, detect, respond, contain. We are positioned as reactors to someone else’s creativity. Usually the attacker’s creativity, but sometimes that of our fellow security practitioners. They build the malware, the phishing kits, the persistence mechanisms. We clean up after them. But that framing is a trap. And it is time to walk out of it.

Here is a phrase that has held back more security practitioners than any technical limitation ever could: “I am not a developer.”

It sounds humble. Reasonable, even. But it is not humility. It is a cage we built for ourselves and then handed someone else the key. The phrase contains a hidden assumption: that building requires a credential, a pedigree, permission from some gatekeeping authority that decides who gets to create.

That was never true. And it is less true now than it has ever been.

In fact, many of you are already building and don’t even realize it. That query you wrote to catch something your SIEM vendor did not account for? That is building. The spreadsheet you rigged together to track cases because the ticketing system did not fit your workflow? Building. The ugly PowerShell script you are vaguely embarrassed about but still use every week because it works? That is building too. You didn’t wait for permission. The only difference between that and what you think of as “real” building is scope and the story you tell yourself about what counts.

Think about how much of your daily work is shaped by tools someone else made. Tools that reflect someone else’s assumptions about what you need, what workflows make sense. You adapt to them. You work around their limitations. You file feature requests into a queue with 50,000 other requests and hope someone, someday, prioritizes your problem. Now think about what it would mean to shape your own environment instead. To look at a friction point and remove it. To stop asking and start making.

Artists understand this intuitively. A painter does not wait for someone to hand them the exact painting they wanted to see. They make it. They impose their vision on the world. You can do the same thing with a script, a detection, a dashboard. The medium is different. The creative act is the same.

Not everything you build needs to be ambitious. In fact, the most transformative building often happens at the smallest scale. A script that saves ten minutes, a query that surfaces signal you were missing, a playbook that cuts an investigation in half. These things compound. Each one is evidence that you can shape your environment, not just react to it. And small creations teach you how to make bigger ones. Every artist starts with sketches. The goal is not perfection. The goal is momentum.

What you create belongs to you. Not in a legal sense (though sometimes that too - IANAL - consult your hiring agreement). In a deeper sense. The understanding you gain by building cannot be taken away. The skill stays sharp. The confidence you earn from watching something work that did not exist before you made it, that is yours forever. Vendors come and go. Tools get deprecated. Budgets get cut. But the builder’s mindset travels with you. It is not tied to any platform or employer. It compounds over a career.

You do not need to be a developer. You do not need permission or the perfect idea or the perfect afternoon with no meetings. You just need to start—or to recognize that you already have.

The canvas is blank. What will you make?

*This is the second piece in a series on building as a core security skill. Previously: “2026: The Year Builders Show Up.”*

AI got more accessible. Voice became an interface. The gap between “I have an idea” and “I built a thing” collapsed. 2026 is not about the people who have always shipped code. It is about the people who never thought they would.

Voice is an Interface Now

For most of security’s history, the keyboard was the starting line. If you wanted to build something, you had to know how to type it. Syntax. Commands. The right libraries.

Voice changes that. In 2026, analysts and engineers will talk to build. You explain an idea out loud. AI turns it into a draft, a script, a workflow. You iterate by conversation, not by rewriting from scratch. The people who can articulate what they need will have an advantage over the people who can only type what they know.

Think about what that unlocks. The analyst who knows exactly what behavior they want to hunt but never learned Python. The IR lead who has run hundreds of investigations but never written a detection rule. Voice removes the hesitation. It turns “I should build that someday” into “let me try saying this out loud.”

In fact, most of this post was generated with a voice based interface. Our ramblings can now become a thesis.

AI Turns Explanation Into Output

If you can describe what you want, you can usually create something usable. Not perfect. Not production-ready. But something real you can test and improve.

That might be a rough detection that catches 80% of what you need. A cleanup script that automates a task you have been doing manually. A runbook that gets institutional knowledge out of someone’s head. This is not about replacing expertise. It is about removing the friction between having expertise and applying it.

Most good work dies in the gap between “I should do this” and “I started doing this.” AI collapses that gap. You get a first draft in minutes instead of never.

Custom Tools for Custom Problems

Enterprise security tools solve general problems at scale. Vendors build for the middle of the bell curve and hope you can configure your way to the edges. That leaves a gap: the problems too specific, too niche, too yours for any vendor to care about.

Now, you can build tools that fit your exact situation. Tools that would never exist as products because the market is too small, but that solve your problem perfectly because they were designed for nothing else.

You are mid-investigation and need a script that correlates three log sources in a way your SIEM does not support. Before, that was a feature request or a professional services engagement. Now you describe the logic and get a working prototype in fifteen minutes. Your SIEM still does the heavy lifting. Your EDR still collects telemetry. But the last-mile automation that makes your workflow actually flow? Congratulations, you can build that yourself!

More Practitioners Become Builders

This is the real shift. Not better tools. More builders.

For years, security had a sharp divide. On one side: engineers and developers who build. On the other: analysts, operators, and managers who use what gets built. That divide is dissolving.

In 2026, people who never called themselves builders will start shipping things. Not products or platforms. Small improvements that remove friction. Glue code that connects tools. Automation that saves ten minutes and quietly adds up. This is not about becoming a developer. It is about shaping your environment instead of just operating within it.

“But I’m Not Technical Enough”

You may have been told that building requires a CS degree, years of coding, mastery of frameworks and pipelines. And that was true for a long time. The barrier to entry was high, especially if you failed a Visual Basic class like Lauren.

AI has changed what “technical enough” means. The skills that matter now are problem articulation, project planning, domain expertise, and iteration. Can you describe what is broken and what better looks like? You have spent years learning how attacks work and how your environment behaves. That knowledge is the hard part. AI can write the Python script. It cannot tell you which log source matters or why that process behavior is suspicious.

You do not have to build big. You do not need to jump straight to CI/CD pipelines or containerized deployments. Start with a Bash script that saves you fifteen minutes. A Python script that formats data the way you need it. Follow secure coding practices. Test before you trust. But start.

Speed Beats Ceremony

The orgs that move fastest in 2026 will not be the most formal. They will not require three approvals before deploying a script. They will not wait for the perfect solution when good-enough exists today. They will prototype quickly, ship rough versions, and fix things later.

Here is what makes this urgent: attackers are not waiting for you. They are already using AI to write phishing campaigns, generate malware variants, and probe infrastructure at scale. They iterate daily. They test in your production. They do not have change advisory boards or quarterly planning cycles. Speed is how they win.

The gap between attacker speed and defender speed has been widening for years. AI is the first technology that gives defenders a real chance to close it. But only if you use it to move faster, not to generate more documentation for the same slow processes. Ship something today that makes tomorrow’s attack harder to execute.

What This Means Going Forward

Security roles are changing whether job descriptions catch up or not. The analyst who can spin up a working prototype will be more valuable than the one who files a ticket and waits. The responder who builds their own tooling will handle edge cases that stumped the last three consultants.

You do not need to be a software engineer. But you do need to be willing to shape your environment. To build the small things that make your work easier. To stop waiting for someone else to solve the problems you see every day.

The question this year is simple: can you explain what you are trying to do? If you can, you can probably build it.

2026 is the year that willingness gets rewarded.

Leave a comment

This is the first piece in a series on building as a core security skill. Next up: “Why You Should Build”

📝 Episode Summary

Welcome back from the holiday break! The THOR Collective returns with a cozy end-of-year reflection meets practitioner reality check, featuring special guest Alex Hurtado, content creator extraordinaire and voice behind Detection Engineering Dispatch. This December edition tackles the often-overlooked but crucial relationship between threat hunting and detection engineering – what Alex calls “the real people that actually just keep shit working.”

Alex brings unique insights from her journey from SIEM analyst at ABC during the Rachel Bachelorette era (yes, monitoring for commercial interruptions during primetime TV) to becoming one of the voices in detection engineering content. The conversation dives deep into why detection engineering finally emerged as a distinct discipline, how vendor black-boxing forces teams to rebuild EDR rules in their SIEM, and why treating detections like production code with proper CICD pipelines is non-negotiable.

From debating whether to ship detections in “warn mode” to discussing the nuclear option of deleting 50% of your detections tomorrow, this episode delivers unfiltered insights on building sustainable detection programs. Plus, Alex shares her Chicago neighborhood-to-SIEM comparison framework, the team debates worst detections as holiday decorations, and everyone agrees: quarterly detection reviews are a must, but alert volume as a KPI needs to go.

⏱️ Episode Breakdown

• 01:32 – Introductions

• 03:00 – Alex’s journey: From ABC SIEM analyst to Detection Engineering thought leader

• 06:02 – The gatekeeping problem in detection engineering

• 10:26 – Icebreaker: Worst detection as a holiday decoration

• 13:36 – Deep dive: What is detection engineering really?

• 16:15 – Detection engineers beyond the SIEM

• 18:01 – The problem with black-box EDR vendors

• 20:35 – Hunting to Detection Engineering handoffs

• 24:30 – Chaining behaviors vs. static indicators

• 36:44 – Detection Engineering as Development (CICD, versioning, documentation)

• 42:40 – Metrics that matter: Confusion matrices vs. alert volume

• 47:30 – The nuclear option: Cutting 50% of detections

• 49:30 – AI’s impact on detection engineering

• 52:15 – Ship it or Scrap it rapid-fire

• 55:06 – Must-reads and resources

• 57:21 – 2025 wrap-up and 2026 preview

🎤 Hosts & Guest

Lauren Proehl (Host) – Manager of the group whose worst detection is a creepy 85-year-old nutcracker from grandma that should’ve been recycled (like Log4J scanning alerts still firing).

Sydney Marrone (Host) – Head of thrunting and threat hunting whose worst detection is a snow globe - stable until you make one edit and everything goes crazy with alerts.

John Grageda (Host) – Red teamer who compares his worst detection to a Christmas tree with all lights constantly rotating in chaos, reminiscent of untuned Sourcefire IDS.

Alex Hurtado (Special Guest) – Content creator, host of Detection Engineering Dispatch, and voice behind the State of Detection Engineering report. Former ABC SIEM analyst who monitored primetime TV for commercial interruptions.

🔗 Resources & Mentions

Key Concepts Discussed

• Detection Engineering Definition – “The real people that actually just keep shit working”

• Detection as Code – Treating detections like production code with CICD pipelines

• Versioning & Documentation – The critical importance of change logs and detection diaries

• Chaining Behaviors – Moving beyond static indicators to correlated attack chains

• Black-box Vendor Problem – Why teams rebuild EDR rules in SIEMs with FDR data

• Critical Asset Prioritization – Starting with crown jewels when cutting detection noise

• Confusion Matrices – True positive/false positive rates as quality metrics

Resources

• 2026 SANS Focus on Detection Engineering Survey

• Alex Teixeira / Detect.FYI

• Detection Engineering Weekly

• Detections.ai

• MITRE TTP Detections

• Detection Engineering Dispatch

📢 Call to Action

• Follow Alex Hurtado on LinkedIn – For infographics and detection engineering insights

• Subscribe to Detection Engineering Dispatch – Available on Apple Podcasts and Spotify

• Participate in the State of DE Survey – Data collection phase is ongoing

• Implement quarterly detection reviews – If you’re not doing this, start now

• Document your detections – Leave them better than you found them

• Write for THOR Collective – Always looking for new voices in thrunting, DE, SOC, and IR

📬 Connect with THOR Collective

🗣️ Social Media:

• Twitter/X: @THOR_Collective

• LinkedIn: THOR Collective

• BlueSky: @thorcollective

📧 Contact:

Reach out through any social channel to contribute content, be a guest on the podcast, or share your detection engineering war stories

Leave a comment