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

Some of you already got this post. Congratulations. You were part of the pre-drop hype.

In 2025, THOR Collective Dispatch published 80 posts.

That is not a content goal. That is a signal.

It means we showed up consistently to talk about how info sec actually works. The messy parts. The decisions that do not fit cleanly into slides. The tradeoffs teams make every day when the logs are loud and the clock is running.

This year was not about chasing trends. It was about sharpening thinking, pressure-testing ideas, and building things that last.

If you read one post or all eighty, thank you. To close out the year, here are six pieces that best represent what Dispatch stood for in 2025.

Detection-in-Depth

Eliminating detection blind spots through layered visibility
Guest post by

This post put real structure behind a phrase that often gets waved around without substance.

Detection-in-depth reframed detection as a layered, living system instead of a collection of clever rules. It emphasized baselining before tuning, precision over perfection, and continuous validation instead of set-and-forget detections.

Most importantly, it addressed a hard truth. If you are not actively testing your detections, attackers are doing it for you.

This piece helped teams think more clearly about blind spots, redundancy, and why layered detection is the difference between catching an attacker early and discovering them after impact.

The Agentic Threat Hunter

We’re done playing whack-a-mole
By

This post drew a line in the sand.

Threat hunting methodology still works. Humans alone do not scale.

The Agentic Threat Hunter argued for a shift in how we hunt. Not AI as a chatbot. Not AI as a vendor checkbox. AI as a collaborator that can hypothesize, investigate, and correlate at machine speed while humans stay focused on strategy and judgment.

It reframed the hunter’s role from query executor to system designer and supervisor. Write hypotheses down. Treat hunts like code. Pair with AI intentionally. Automate repetition and protect creativity.

This post resonated because it named what many teams already feel. The future of hunting is not more dashboards. It is better partners.

From the Fire: Q1FY25

TTPs that sparked, spread, and still burn
By

This was threat intel done right.

Instead of chasing zero-day headlines, From the Fire focused on behaviors that kept showing up across incident response and adversary emulation. OAuth consent abuse. Malicious package ecosystems. RMM tooling turned initial access.

Each section broke down what attackers were doing, what telemetry mattered, and what to hunt for right now. This was not theory. This was backlog fuel.

If other posts pushed the craft forward, this one kept it grounded in reality. These are the fires still burning.

Introducing HEARTH

A community-driven threat hunting repository
By , , and

This post turned Dispatch from a publication into infrastructure.

HEARTH addressed a problem every hunter knows. Good hunt ideas live in isolation and disappear. HEARTH gave them a shared home with structure, review, and attribution.

Standard templates. Clear categorization. Community refinement. Real credit for contributors.

It reinforced a belief at the core of THOR Collective. Threat hunting improves when knowledge compounds. Not when it stays siloed.

This was not just an announcement. It was an investment in how the community builds together.

Hunting Beyond Indicators

Why behaviors beat artifacts
Guest post by

This post tackled one of the most common traps in threat hunting.

Indicators help with known bad. They do not help you find the unknown.

Sam made the case for behavior-first hunting grounded in TTPs, with indicators used as enrichment instead of direction. Cast a wide net. Accept false positives. Automate triage. Let your data access define what you can realistically hunt.

This was not anti-IOC. It was pro-thinking.

It reminded us why threat hunting exists in the first place. To find what has not been named yet.

Red with Benefits: Purple Teaming with Sliver Beacons

Turning post-exploitation into detection signal
By

This post showed what collaboration actually looks like.

Instead of using Sliver purely as a red team flex, John demonstrated how to turn beacon activity into shared detection engineering feedback. Map actions to ATT&CK. Pair them with expected telemetry. Capture gaps in VECTR. Fix what did not fire.

This was purple teaming without theater. No gotchas. No scorekeeping. Just learning.

If other posts defined strategy and mindset, this one showed how to pressure-test those ideas with real tooling.

And One More Thing We Loved This Year: Ask-a-Thrunt3r

This Logtoberfest Ask-a-Thrunt3r episode captured the same questions running through Dispatch all year: where is threat hunting actually headed?

With joining the crew, we talked agentic AI, democratizing threat hunting, and why attackers are already moving faster than most defenders. No polished narratives. No easy answers. Just practitioners working through what’s real, what’s broken, and what still needs figuring out.

If you listened to one Ask-a-Thrunt3r episode this year, make it this one.

What This Year Reinforced

This year made a few things very clear:

• Structure makes hunting stronger, not slower

• Documentation is a force multiplier

• Automation works best when it supports thinking

• Detection improves through testing, not hope

• And threat hunting gets better when we build together

We are proud of what shipped this year. We are even more excited about what comes next.

Thanks for reading.
Thanks for building with us.
And thanks for keeping the fire burning.

Here’s to the new year.

Happy thrunting!

Here are this month’s 6 Dispatch posts:

• Ask-a-Thrunt3r: October 2025 Logtoberfest Edition

  The THOR Collective’s October Ask-a-Thrunt3r episode with guest Damien Lewke from Nebulock discusses democratizing threat hunting and the impact of agentic AI on cybersecurity, separating genuine innovation from vendor hype. Cybersecurity professionals can gain insights on the future of threat hunting and the importance of upskilling SOC analysts for the evolving landscape.

  By Lauren Proehl

• Hunting Beyond Indicators - Part 2

  The post discusses the benefits of hunting based on behaviors rather than indicators in cybersecurity. By focusing on specific TTPs like SCADA Python scripts and Modbus protocols, analysts can uncover novel threats that may not be widely known, emphasizing the importance of understanding the threat landscape and using creativity in hunting strategies. By utilizing tools like PyLingual and Yara rules, analysts can efficiently triage and analyze suspicious files for potential threats.

  By Sam Hanson

• The Autonomous SOC (Taylor’s Version)

  The evolution towards an autonomous SOC is driven by the increasing complexity of cyber threats, the need for efficiency due to talent shortages, and the maturation of defensive AI. While automation is crucial, maintaining strong foundational processes and avoiding biases in AI training data are essential for success. The future of the SOC involves elevated roles for human analysts in proactive security, AI training, and business risk translation.

  By Sydney Marrone and Kassandra Murphy

• The PEAK Threat Hunting Template You’ll Wish You Had Sooner

  The THOR Collective Dispatch provides a threat hunting template based on the PEAK Threat Hunting Framework, emphasizing the importance of structured documentation for collaborative, repeatable hunts. The template includes sections for scoping, queries, visualizations, detection logic, findings, response, lessons learned, and knowledge sharing, making it AI-friendly and versatile for current and future threat hunting efforts. Get the template from the Google Doc or GitHub to enhance your team’s skillset.

  By Sydney Marrone

• Purple Teaming in the Real World: When Everything Goes Off the Rails (and That’s Normal)

  Purple teaming rarely goes as planned, with delays, permissions issues, and unexpected blockers being common. Cybersecurity professionals should expect chaos, make buffer time, validate access early, break requests into small chunks, test in whatever order possible, and document blockers as findings to navigate real-world engagements effectively.

  By John Grageda

• Aligning Risk Management and Threat-Informed Defense Practices (Part 2)

  Aligning GRC with threat-informed defense practices can improve organizational cybersecurity by creating a proactive, holistic strategy. Combining compliance frameworks with threat knowledge can help organizations understand risks, implement controls, achieve compliance, and detect real-life attacks. Before integrating GRC with threat-informed defense, organizations need upper management support, honesty about maturity levels, and the right personnel and tools in place.

  By Micah VanFossen

Stay tuned for more thrunting wisdom next month!

Issues When Teams Are Siloed

GRC can get a bad rap in security circles, at times it can be deserved. Unfortunately most GRC processes have not stayed up to date with current workflows. And many of us have heard the phrase “compliance ≠ security.” Look, no one wants to upload another screenshot of a setting or write paperwork in hopes one person will eventually look at it and give the thumbs up. But guess what, compliance teams hate it when the SecOps or CTI output looks like a bunch of random noise that can’t be used to verify anything. These teams speak different languages and have different goals. But, all hope is not lost. By aligning GRC and SecOps, creating common languages and goals, you’re teams can go from this

To singing “you’ve got a friend in me.” In this manner these teams can work together to help the organization remain compliant, secure, and efficient.

It’s true that compliance probably won’t provide sufficient security if the business stops at meeting minimum requirements to check a box, pass an audit, or align with a standard. But, if compliance serves as a starting point toward a more mature security program, it can contribute to improving security.

And while it’s easy to point the finger at compliance, SecOps doesn’t get off the hook here. If lessons learned from incidents don’t feed back into governance, the same mistakes repeat because controls never change. Without a good understanding of all expected controls, it’s difficult to best judge where mitigations exist, or what constitutes a concerning alert that has bypassed those controls. If GRC and SecOps don’t share data, analysts are likely to miss the “so what?” of an incident.

Why Align?

We can all agree that cyber risks and threats continue to evolve and grow year over year, attempting to disrupt how we do things. With greater innovation and interconnectedness, has come greater opportunities for digital security to positively or negatively impact businesses. The key to staying ahead has come down to acting on intelligence. Which side can proactively anticipate the other, and make (or prevent) the next move?

During battle, the side with the most knowledge and strongest ability to act according to that knowledge often has the best odds of coming out on top. No soldier wants to be on the less informed side when lives are on the line. The same is true in the cyber realm. It has become increasingly clear that strategic, tactical, and operational intelligence is the greatest asset a defender can hold. Knowledge of self, knowledge of the enemy, and knowledge of how to use that information to gain an advantage (once again, is it even a cyber blog if Sun Tzu doesn’t appear?). For years, the approach to cyber has been reactive. Attempting to block or alert on IOCs (Indicators of Compromise) such as known-bad websites, files, or hashes. As the number of ransomware attacks and breaches continues to rise, it can be understood that this approach is lacking. IOCs can change on the dime, making it impossible to catch every IP or hash change (Pyramid of Pain joke, we want to inflict pain on the adversary, not on ourselves). The strategy of implementing defensive controls to keep out all cyber threats is also unrealistic and impractical. There are too many threats to defend against, too many alerts to analyze, and the costs associated with remaining uninformed keep growing. A reactive cybersecurity strategy will continue to cost organizations.

Now that we understand some of the frameworks at hand (ATT&CK and RMF), why should an organization combine the two? What is the benefit of a risk managed and threat-informed defense?

The goal behind this strategy is to switch, (or as I like to think of it, level up) from the wishful (and very exhausting) compliance-driven strategy of doing the bare minimum to meet cybersecurity compliance requirements, and hoping to defend against every cyber threat that exists. The desired end state will be a proactive defense that uses the knowledge of dangerous threats which are specific and most relevant to the organization/industry to tailor and then test defensive controls against those adversary behaviors. Breaking down the GRC/TID silos can sync defensive teams, enabling larger strategic initiatives to be developed.

The issues with relying solely on risk management for security is that a compliance framework is incapable of changing at the speed that threats do. NIST 800-53 rev 4 was released in 2013. As of 2023, it was still the requirement for most RMF specific assessments. Finally now in 2025 most have migrated to rev 5, released ONLY 5 years ago (remember the days before AI, yeah way back then). The main problem with a compliance approach is that a compliant system is not by default also a secure system. Most systems that undergo a compliance validation process are never properly tested against the threats to that system. Screenshots don’t compare so well to command execution or lateral movement. Another issue in only using compliance metrics to measure security is that compliance frameworks are meant to provide a broad scale of security for a wide range of users, it is not specific to an organization’s needs. It is ultimately up to each organization to take action to become secure by knowing their threats and risks, and testing/validating that defenses protect against the threats that could bring them the most harm.

Control frameworks adequately addresses the reduction of risk through implementation of security controls, however, they do not take into consideration specific threats or threat actor behaviors/TTPs. Meanwhile, CTI and MITRE ATT&CK is great for identifying threat behavior, but organizations will still need to act on that knowledge by implementing cyber defenses and controls.

A more effective cybersecurity posture can be achieved by combining the compliance framework with the knowledge found in ATT&CK and CTI to create a holistic, risk-managed and threat-informed cyber defense strategy. The control framework creates a deep knowledge of self, while ATT&CK/CTI grants knowledge of the adversary. Combined, they allow an organization to know the enemy, know security defenses, and act according to that knowledge to defend against the adversary, even before the adversary strikes.

When aligning GRC with threat-informed defense practices, an organization can create a proactive, holistic cyber defense strategy that:

• Knows the relevant risks and threats facing the organization (threat profile)

• Identifies what has been done to reduce risk and mitigate known threat actor behavior

• Verifies proper control implementation and coverage

• Achieve compliance with validated defenses against known threats

• Can detect and protect against real-life attacks

• Locates issues and reduces potential impact prior to an attack

• Uses intelligence to connect threats, risks, controls, and business objectives

WHEN

So, we have identified that it is a good idea to combine governance, compliance, and risk management with threat knowledge, but how is it done well? When and where should an organization begin when combining these two frameworks into a defensive strategy?

The first step should be to receive upper management support. An effective roll-out of this process will require culture and procedural changes, and it needs to be supported from the top.

Next, an organization needs to be honest with their current maturity level. If you are still working to implement MFA, it’s probably not the time to be standing up a CTI function. Basics first, then focus on relevant threats and risks.

Anton Chuvakin wrote a fantastic piece on the challenges of operationalizing threat-informed defense. He listed out a few common problems within organizations who do not align strategies across teams. While the full blog can be found here: https://medium.com/mitre-engenuity/threat-informed-defense-is-hard-so-we-are-still-not-doing-it-31ae7b68955f, a quick rundown is provided below.

• “To start, one can say that foundational levels of security are not and perhaps even should not be threat-centric. After all, much of basic security is just good engineering, no? Threat-informed defense should be built upon foundational cyber-hygiene.

• Ironically, the “cyber-havenots” are less likely to practice threat-informed security while they are the ones who can benefit the most from focusing their scarce resources on threats that matter! Basics matter, but basics prioritized by real threats are better!

• Poor quality of threat intel makes organizations unwilling and unable to make decisions off their collected threat data. Threat intelligence is often incomplete, inaccurate, or outdated, and this makes it difficult for organizations to make informed security decisions.

• Outside of security, immature IT capabilities ruin threat-informed defense. If your IT asset management, change management, etc. are inflexible, silo’d, hostile to security, your defenses can probably only be static and unchanging.

• Sometimes, the bridge from threat intelligence to security controls isn’t conceptualized, built or practiced. The organizations have threat intel in one bucket, and their security controls in another.

• Organizations also lack the types of personnel that can turn threat knowledge into improved defenses or drive threat-informed changes to defense approaches they practice.

• Compliance culture is focused on building static, auditor-proof defenses. A shift in security culture is often required to adopt a threat-informed approach and this is hard for many organizations, large or small.

• Narrow use case around threats: organizations only practice threat-informed detection, but not the rest of security”

So, we can see it takes personnel, culture, existing foundational levels of security and IT hygiene, and quality threat intelligence prior to finding value in deploying threat-informed or threat-centric defenses.

Here is my list of “must have’s” an organization absolutely will need before really jumping into the threat-informed defense + GRC game.

• Required or identified compliance framework that will act as the baseline

• Some security / IT maturity (asset inventory, basic defensive engineering controls)

• Logs, some type of SIEM / query capability

• Detection (defend) capability, usually in the form of EDR/SIEM

• Testing (attack) capability, this can be manual or via automated BAS tools

• Identified attack chain(s) or atomic TTPs (relevant CTI)

At this point, an organization will also need to identify a team or individual to manage threat-informed defense across the organization. This team needs to be given authority to make changes where necessary and shift the processes and tools that need to go or be modified. Ideally this would be a couple members from multiple teams (GRC, Detection Engineering/SecOps, CTI, Red Team).

Quick example, when looking at the Risk Management Framework, incorporating threat information would begin in step 2 (Select Controls) and continue throughout the life cycle of the system. When selecting controls, the organization should aim for that control to address both compliance requirements and prevent or detect adversary behavior. However, as adversaries change, so should defenses and controls. Maintaining up-to-date knowledge is integral to a threat-informed cyber defense.

Provided below are some questions to ask when getting started with threat-informed defense. These are by no means extensive, only serving as guidelines for identifying which techniques to focus on. It is highly encouraged to tailor questions to your specific organization and mission needs.

• What threat actors commonly target my industry?

• What techniques are used by these groups?

• What controls do we currently have in place?

• What controls are we confident in, and which ones are we less certain of their effectiveness?

• What are our crown jewels (business-critical functions, information, and systems) that we must protect?

• Who are the stakeholders that require CTI and GRC outputs?

I really enjoy the following graphic from Wirespeed (who was just recently purchased by Coalition, congrats to them) which depicts actions of security teams before and after the detection of an attack has occurred.

This graphic really helps to visualize the timeline of what occurs prior to detection, and then afterwards all the way through containment and post incident review.

In the next post we’ll discuss the how to and offer some ways an organization might approach integrating GRC with threat-informed defense. I’ll also share some free tools that can help with some of the processes, and finally take a look into so what could this really mean for an organization?

Nice idea. Doesn’t happen.

Here’s how our latest adversarial emulation actually unfolded and why newer folks need to understand that this kind of chaos is completely normal.

We Started Strong

The red team and blue team were perfectly aligned going in. We defined:

• The TTPs that mattered

• The logging and alerting gaps that the IR team was worried about

• What we wanted to trigger

• What we expected to at least show up in the logs

• A timeline that seemed realistic

• A clean RoE
  

The engagement was mapped out months in advance.
Back at the start of the year, it all felt reasonable and well-planned.

And then reality stepped in.

The Delay Train Arrives

The infrastructure team got hit with a massive company-wide initiative. Completely unplanned when we originally scoped this project. They were already stretched thin, juggling priorities, and then here we come, asking them to build infrastructure in production for us.

They weren’t dragging their feet, they were overwhelmed.

So:

Delay #1: Infrastructure didn’t get built on time.
Delay #2: When it finally went live, we didn’t have permissions to do anything with it.
Delay #3: Every new action revealed a new permission blocker, which meant a new ticket, and more waiting.

And here’s the part that stung a little:

Every time we hit an infrastructure issue, we had to go back to the same infrastructure folks… again!

We knew how slammed they were.
We knew how much was on their plate.
And every “hey, sorry, but we need one more thing” message felt like we were poking someone who was already juggling flaming chainsaws.

But we still had to ask because we still had a job to do.
We couldn’t test without access, and we couldn’t magically create permissions ourselves.

It was uncomfortable, but unavoidable.

The “Test Whatever We Can Today” Phase

The engagement slowly turned into a buffet where we only got to eat whatever dishes happened to be available that day.

Do we have everything required to conduct this test case today? Cool, run it.
Are we missing something that prevents the test case from running? Add it to the ticket pile and pivot to something else.

It was messy.
It was non-linear.
It was the opposite of the beautiful timeline we had anticipated.

We eventually blew past our original deadline by almost two weeks! Not because anyone slacked, but because the environment simply wasn’t ready and everyone was stretched thin.

We Still Got the Work Done

Even with the chaos, things gradually came together.
Permissions started landing.
Infrastructure was stood up.
More pieces unlocked.

We ran every test case, just not in order, and definitely not smoothly.
But we ran them.
We found the visibility gaps.
We gave our incident response team a clear picture of where they were blind.

The engagement delivered real value. We just ended up taking the scenic route.

If You’re New to This Field

Purple teaming rarely goes how you think it will.
Adversarial emulation is rarely clean.
Real orgs operate in real conditions. Shifting priorities, shared responsibilities, overloaded teams, surprise initiatives, and resource crunches.

You will run into:

• Permission issues

• Missing infrastructure

• Delays

• Unexpected blockers

• Competing priorities

• People who want to help but literally don’t have the bandwidth

• Test-case issues

It’s not a failure.
It’s not a sign you’re doing something wrong.
It’s simply how these engagements work in the real world sometimes.

Ways to Make Future Engagements Hurt Less

We can’t control everything, but we can learn from it.

Build real buffer time

Not a few days. Actual buffer. Weeks!

Get access validated long before testing begins

If you’re touching the environment for the first time on Day 1, you’re already behind.

Break infra requests into small, digestible chunks

Make it easy for busy teams to help you.

Test in whatever order the environment allows

Forward momentum keeps things alive.

Document blockers as real findings

Permissions, missing agents, missing logs, they’re part of the engagement story.

Acknowledge that some delays are simply uncontrollable

When we planned this early in the year, no one knew a company-wide initiative would land on top of everything. Sometimes timing just works against you.

The Honest Part

This engagement was frustrating.
It was chaotic.
It forced constant adaptation.
And it wasn’t the sleek, well-oiled purple team machine people imagine.

But that’s real-world security.

Attackers don’t wait.
Infrastructure teams don’t magically clear their schedule.
And purple teams don’t get perfect conditions.

The value is in navigating the mess and still producing something meaningful on the other side.

If you’re newer to this work, just know:
It won’t always be smooth.
Sometimes it’s two weeks of “access denied” messages and a constant feeling of “sorry to bug you again…”

But the mission gets done and that’s what truly matters. Make sure to show the folks that are going above and beyond to help you with your engagement some recognition. Let their bosses know how awesome they are!

Maybe you pieced together queries across five tabs, made mental notes during a caffeine-fueled hyperfocus, and promised to write it up later. We’ve all been there.

But good hunts deserve better.
They deserve structure. They deserve documentation. They deserve to be repeatable, reviewable, and shareable.

That’s why we built a threat hunting template grounded in the PEAK Threat Hunting Framework. So your hunts don’t get lost in Slack threads, screenshots, or brain fog.

This template builds on ideas from our earlier posts, AI is My Bestie and Agentic Threat Hunting, Part 2, taking the next step toward structured, AI-ready documentation for threat hunters.

This template walks through the full threat hunting lifecycle using PEAK (Prepare, Execute, Act with Knowledge). It’s structured for real-world use: collaborative hunts, repeatable documentation, and clear readouts for SOC, IR, Threat Intel, and Detection Engineering.

Want a copy?
Click here or scroll down to grab the full template below.

What’s Inside

• Hunt Overview

• PREPARE: Define the Hunt

  • ABLE Methodology

  • Related Tickets

  • Threat Intel & Research

• EXECUTE: Run the Hunt

  • Initial & Refined Queries

  • Visualizations or Analytics

  • Detection Logic

• ACT: Findings & Response

  • Executive Summary

  • Findings Table

• KNOWLEDGE: Lessons Learned & Documentation

  • Adjustments to Future Hunts

  • Sharing Knowledge & Documentation

  • References

• AI Ready Hunts

• Download the Template

Threat Hunting Report – PEAK Framework

Hunt ID: H/B/M-XXXX
(H for Hypothesis-driven, B for Baseline, M for Model-Assisted)

Hunt Title:
A concise, descriptive name for this hunt.

PREPARE: Define the Hunt

Scoping with the ABLE Methodology

Clearly define your hunt scope using the ABLE framework. Replace all placeholders ([ ]) with relevant details for your scenario.

Example ABLE Inputs

Related Tickets

(detection coverage, previous incidents, etc.)

Threat Intel & Research

• MITRE ATT&CK Tactics, Techniques, & Procedures (TTPs):

  • TAxxxx - Tactic Name

  • Txxxx - Technique Name

• Related Reports, Blogs, or Threat Intel Sources:

  • [Link]

  • [Reference]

• Historical Prevalence & Relevance:

  • (Has this been observed before in your environment? Are there any detections/mitigations for this activity already in place?)

EXECUTE: Run the Hunt

Hunting Queries

(Document queries for Splunk, Sigma, KQL, or another query language to execute the hunt. Capture any adjustments made during analysis and iterate on findings.)

Initial Query

index=thrunt sourcetype=linux:audit "sudo" OR "pkexec" 
| stats count by user, command, parent_process

• Notes:

  • Did this query return expected results?

  • Were there false positives or gaps?

  • How did you refine the query based on findings?

Refined Query (if applicable)

index=thrunt sourcetype=linux:audit "sudo" OR "pkexec" 
| stats count by user, command, parent_process, _time 
| sort - _time

• Rationale for Refinement:

  • Added _time for better event sequencing.

  • Applied sort to identify patterns in privilege escalation attempts.

Visualization or Analytics

(Describe any dashboards, anomaly detection methods, or visualizations used. Capture observations and note whether visualizations revealed additional insights. Add screenshots!)

• Examples:

  • Time-series charts to detect activity spikes

  • Heatmaps of unusual application installs

Detection Logic

(How would this be turned into a detection rule? Thresholds, tuning considerations, etc.)

• Initial Detection Criteria:

  • What conditions would trigger an alert?

  • Are there threshold values that indicate malicious activity?

• Refinements After Review:

  • Did certain legitimate activities cause false positives?

  • How can you tune the rule to focus on real threats?

Capturing Your Analysis & Iteration

• Summarize insights gained from each query modification and visualization.

• Reiterate key findings:

  • Did this query lead to any findings, false positives, or security incidents?

  • If this hunt were repeated, what changes should be made?

  • Does this hunt generate ideas for additional hunts?

• Document the next steps for refining queries for detections and other outputs.

ACT: Findings & Response

Hunt Review Template

Hypothesis / Topic

(Restate the hypothesis and topic of the investigation.)

Executive Summary

Key Points:

• 3-5 sentences summarizing the investigation.

• Indicate whether the hypothesis was proved or disproved.

• Summarize the main findings (e.g., "We found..., we did not find..., we did not find... but we did find...").

Findings

(Summarize key results, including any unusual activity.)

KNOWLEDGE: Lessons Learned & Documentation

Adjustments to Future Hunts

• What worked well?

• What could be improved?

• Should this hunt be automated as a detection?

• Are there any follow-up hunts that should be conducted?

• What feedback should be shared with other teams (SOC, IR, Threat Intel, Detection Engineering, etc.)?

Sharing Knowledge & Documentation

(Ensure insights from this hunt are shared with the broader security team to improve future hunts and detections.)

• Knowledge Base (KB) Articles

  • Write an internal KB article that captures:

    • The hunt's objective, scope, and key findings

    • Any detection logic or rule improvements

    • Lessons learned that are relevant for future hunts or incident response

  • Document newly uncovered insights or patterns that could benefit SOC, IR, or Detection Engineering teams, especially anything that could inform future detections, playbooks, or tuning decisions.

• Threat Hunt Readouts

  • Schedule a readout with SOC, IR, and Threat Intel teams.

  • Present key findings and suggested improvements to detections.

• Reports & External Sharing

  • Publish findings in an internal hunt report.

  • Share relevant insights with stakeholders, vendors, or industry communities if applicable.

References

• [Insert link to related documentation, reports, or sources]

• [Insert link to any external references or articles]

AI Ready Hunts

One of the most powerful parts of this template is that it is not just for humans. It is AI friendly. In Agentic Threat Hunting, Part 2, I argued the first step toward agentic hunting is not plugging AI directly into Splunk, it is giving it memory. When your PEAK hunts live in structured markdown in a GitHub repo with an AGENTS.md, they become something AI can actually learn from. AI can summarize hunts, suggest query variants, map to ATT&CK, or even generate new hypotheses. That makes this template versatile. It is useful for your team today and it is fuel for your AI bestie tomorrow.

Want a Copy?

Whether you’re documenting a YOLO hunt postmortem or building a hunting playbook from scratch, this template is here to help you do it on purpose. And because it’s structured, you can throw it into AI and get support on summarizing, remixing, or scaling your hunts. That’s what makes it versatile: useful now, and ready for the next wave of agentic hunting.

You can grab the template as a Google Doc here or from our GitHub to adapt it for your team.

Try it on your next hunt.
Share how you adapted it.
Tag us or drop a comment below!

Stay curious and happy thrunting! 🐏