Part 1 left us holding fifa[.]house: twenty-one certificates, a first-to-last window from January to April, and about twenty sibling domains riding its SANs. Precise names, precise minutes, and not one address. The domain is NXDOMAIN today, so there is nothing left to resolve and nothing left to scan.

That is the shape of what Certificate Transparency hands you. A domain exists, its cert was issued at this minute, these names rode along on the SAN. A single point in time, the instant a piece of infrastructure announces itself.

Passive DNS gives you the rest of it.

It records the answers recursive resolvers actually returned, captured by sensors and stitched into a searchable history. Where CT shows the intent to stand something up, passive DNS shows the operational life: where a name pointed, when it moved, what it shared an address with, and what went dark the day the campaign got burned.

Passive DNS is also the source in this series where free access has narrowed the most. The two names everyone reaches for first, Farsight DNSDB and PassiveTotal, now sit inside larger platforms: DNSDB moved to DomainTools at enterprise pricing, and PassiveTotal became part of Microsoft Defender Threat Intelligence, where the free community tier did not survive the move. Both are strong products and the consolidation is ordinary. The practical problem is downstream of it: a generation of analysts learned pDNS through those tools, so a lot of intro writeups still assume a license you may not have. Everything below runs on data you can query today, for free, starting with infrastructure the community owns.

What the data tells you

A passive DNS record is boring on its own and devastating in aggregate. Each entry is roughly: a query name, a record type, the response data, a first-seen timestamp, a last-seen timestamp, and a count of how many times the sensor network observed it.

Those last two fields are what matter. A current DNS lookup answers where a name points right now. Passive DNS answers where it has pointed, and for how long, across years, which turns three otherwise impossible questions into routine ones:

What IPs did this domain use before takedown? Active DNS gives you nothing once a domain is parked or sinkholed; pDNS still has the body. What else resolved to this IP while the badness I already know about was live? That is reverse passive DNS, how you turn one indicator into a cluster. And when did the infrastructure turn on? First-seen timestamps date an operation and catch the staging nobody noticed.

You are reconstructing infrastructure that the operator thought was gone. They rotated the IP, they let the domain lapse, they moved to a new host. The resolver network already wrote it down.

Why adversaries leave traces in it

They cannot opt out. That is the short version.

DNS is not optional for an attacker; everything else they run rides on it. The moment a victim, a sandbox, a scanner, or the operator’s own implant resolves a domain near a sensor-instrumented resolver, that resolution gets recorded on infrastructure the adversary does not control. There is no setting to turn it off.

And operators are lazy in patterned ways. They reuse hosting, nameservers, a registrar, a mail setup, a TLS config, because standing up new ones is effort. Every reuse is a thread you can pull, and passive DNS keeps a lot of them visible over time. That is what lets you tell a coincidence, one shared IP ever, from a pattern, four domains on the same obscure VPS during the same two weeks.

The behaviors that show up loudest: fast flux and rapid IP rotation, a domain churning dozens of A records in a short window, which is not a normal CDN; DGA traffic, mostly-NXDOMAIN noise with occasional registered hits that cluster on shared infrastructure; and staging gaps, infrastructure that first-seen dates two weeks before an intrusion and goes dark right after, tempo you read off the timestamps.

How to query and pivot

Start with the data the community runs, because it is the most durable and the least likely to disappear behind a sales call.

CIRCL Passive DNS is run by the Luxembourg CERT for exactly this audience: incident handlers and researchers. Access is free but vetted: request an account, get credentials. It speaks the Passive DNS Common Output Format, which matters more than it sounds, and we come back to that. The REST query is about as simple as it gets:

# Forward lookup: where has this name lived
curl --user 'user:pass' \
  'https://www.circl.lu/pdns/query/badexample.com'

# Returns newline-delimited JSON (COF), one record per line:
# {"rrname":"badexample.com","rrtype":"A","rdata":"203.0.113.40",
#  "time_first":1708300000,"time_last":1709900000,"count":412}

Mnemonic Passive DNS is the other community workhorse, run by the Norwegian security firm mnemonic and exposed through an open API. Low-volume use needs no key, which makes it the fastest thing to script against when you are triaging:

# Forward lookup
curl 'https://api.mnemonic.no/pdns/v3/badexample.com'

# Reverse lookup: every name seen resolving to this IP
curl 'https://api.mnemonic.no/pdns/v3/203.0.113.40'

Notice the second call. That is the pivot that does the work: hand it an IP, get back every domain the sensor network saw pointing there, each with its own first-seen and last-seen. One known-bad IP becomes a candidate list in a single request.

One caveat before you conclude a source is broken. Sensor coverage is geographic, and the community networks are Europe-weighted. Running the Ghost Stadium origins below through Mnemonic returns almost nothing, while VirusTotal’s free tier returns the full cluster for the same addresses. That is not you querying wrong, it is a resolver network that never saw the traffic. Check a second source before you accept an empty answer, and expect community pDNS to be thinnest exactly where the campaign targets somewhere else.

Now the discipline that keeps you from drowning. Time-window everything. An IP that hosted fifty thousand domains over five years is shared hosting, a CDN edge, or parking, so pivoting on it will bury you. An IP that hosted four domains during the exact fourteen days your incident was live is a cluster. Treat first-seen and last-seen as your filter, not trivia: high count, long span, many unrelated names means shared infrastructure, so drop it; low count, tight window, and a name you already distrust means signal, so chase it.

The pivot fields, in rough order of how often they pay off:

A and AAAA records, forward and reverse, are your primary loop. Domain to historical IPs, each IP back to co-resident domains, filtered by overlapping time windows.

NS records cluster operations by shared nameserver. Self-hosted or bulletproof ones are especially telling: legitimate operators rarely run their own, and adversaries who do reuse them across campaigns.

MX records expose reused mail infrastructure, which is gold for phishing and business email compromise clusters.

TXT records leak verification tokens. A reused google-site-verification value or a distinctive SPF include string can tie together domains that share nothing else visible.

CNAME chains reveal shared redirectors and CDN fronting setups.

Once you have a candidate cluster from the community sources, widen the aperture with the free SaaS-style platforms, which give you a pivoting interface and deeper history than a raw API:

Validin Community Edition is the strongest free pivot environment right now: free account, web UI plus API, several years of history, and pivoting across DNS, certs, and host behaviors in one place. When you want to chase a cluster visually instead of by curl, go here.

Silent Push Community Edition is a free account with passive DNS lookups and infrastructure scanning, useful as a second opinion when your other sources come up thin.

VirusTotal gives passive DNS relations on the free API (/domains/{domain}/resolutions, /ip_addresses/{ip}/resolutions), rate-limited to about four requests a minute, so use it for confirmation and enrichment, not bulk sweeping.

SecurityTrails is worth knowing about and no longer worth planning around. It had a small free tier with historical DNS and subdomain data, and a lot of writeups still list it as a free option. Check what it costs before you build a workflow on it. This is the failure mode this installment opened with, and it happens to sources faster than the writeups get updated.

One more thing about the Common Output Format. COF is the shape CIRCL returns, one JSON record per line with rrname, rrtype, rdata, time_first, time_last, and count, and PyPDNS is a COF client you can point at any server that speaks it. Mnemonic is not one of them: it wraps its answers in a responseCode/data envelope, calls the fields query, answer, and times, and stamps its timestamps in epoch milliseconds. Normalize whatever you pull into COF at the edge of your tooling and the rest of your pipeline stops caring which source it came from.

# CIRCL, or any COF-speaking server, via pypdns
from pypdns import PyPDNS

pdns = PyPDNS(basic_auth=('user', 'pass'))
# rfc_query returns PDNSRecord objects; the older query() is deprecated
# and hands back plain dicts
for record in pdns.rfc_query('badexample.com'):
    # record.rdata, record.time_first, record.time_last, record.count
    if record.count and record.count < 50 and record.rrtype in ('A', 'AAAA'):
        print(record.rdata, record.time_first, record.time_last)

Enrich and correlate

Passive DNS feeds everything else. Every pivot above produces indicators that get sharper when you cross them against the other sources in this series.

Run the resolved IPs and co-resident domains back through Certificate Transparency (Part 1). A shared cert across two domains you connected by IP is independent confirmation they are the same operator, and its SAN list often hands you names the pDNS sweep missed. That is not theoretical here: three Ghost Stadium seed domains expanded to twenty-five registrable domains through SAN expansion alone, and one certificate carried forty-five names.

Take the live IPs into internet scan data, the next installment. Open ports, banners, and fingerprints tell you what the infrastructure was for. A box that hosted three of your cluster domains and also exposed a known C2 panel is no longer a maybe.

Pull WHOIS and registration data on the clustered domains (Part 4). Even post-GDPR, registration timing, registrar choice, and nameserver assignment cluster actor infrastructure in ways the privacy proxy does not hide.

Add ASN and hosting context: which network owns the IP, its abuse history, whether it is a known bulletproof provider. A cluster sitting inside one obscure autonomous system is a far stronger signal than the same domains spread across AWS, Cloudflare, and a shared reseller.

And aggressively discard. Sinkholes pull thousands of dead malicious domains onto one IP, a massive-looking cluster that is really a researcher’s trap; parking and CDN edges do the same with benign domains. Learn the sinkhole and parking ranges, recognize the major CDNs on sight, and filter them before they waste an afternoon.

In practice: Ghost Stadium

The question going in: where does this operation actually host behind the CDN, and can we recover an origin to hunt from?

Forward-resolve the confirmed kit domains and the active core resists you. Nearly every record is Cloudflare (AS13335), and reversing any of those addresses returns the shared edge: tens of thousands of unrelated domains, first-seen dates scattered across years, the textbook high-count, long-span noise you time-window and throw away. For that slice, the origin this lens exists to recover is simply not in the record.

So go back to the one name Part 1 actually handed over. fifa[.]house is dead, and every active tool you own returns nothing on it. Its resolution history returns six addresses across five networks, every handoff inside ten weeks: NetLab Global (AS979) on 2026-01-03, a second NetLab address on 02-06, ArossCloud on 02-16, CogNetCloud on 02-24, then Zillion Network and IT7 Networks together on 03-10. The handoffs are contiguous. You can read the operator’s moving schedule straight off the first-seen column.

Then run the same filter on the last hop, because your own lead is where you are least likely to apply it. On 04-16 the domain answers from two Amazon addresses, and it is tempting to call that a seventh host and a move to legitimate cloud. Both reverse to the same name, a2aa9ff50de748dbe.awsglobalaccelerator[.]com, and each carries hundreds of unrelated tenants, dental practices and consultancies and half-built startups. That is parking. The domain was registered through GoDaddy and kept GoDaddy nameservers to the last day, so what the record shows on 04-16 is the registration lapsing, not the operator relocating. High count, many unrelated names, discard. The rule does not stop applying because the address is yours.

It also overturns the assumption we carried in with. This domain never sat behind Cloudflare. Its nameservers were GoDaddy’s domaincontrol[.]com from the first day to the last, matching the GoDaddy registration and the GoDaddy certificate that Part 1 documented, and it answered from origin hosts the entire time. The domain we assumed was the most hidden of the set turns out to be the least.

You will still find Cloudflare all over those captures, and it is worth knowing why before it misleads you. urlscan lists every ASN a scan touched, and AS13335 is in that list for all eleven fifa[.]house captures. None of it is the site. It is cdnjs.cloudflare[.]com serving the kit’s copied jQuery, plus a pair of Flourish embeds that happen to be Cloudflare-fronted themselves. The page’s own address, the page.ip field, is NetLab or CogNetCloud in every one of those captures. This is the shared-library trap from earlier wearing an ASN instead of a resource hash, and it is the single easiest way to talk yourself into a wrong answer here. A scan summary tells you who the page talked to. One field in it tells you where the page lived.

Better still, the two lenses explain each other. Twenty-one certificates between January and April read like reissuance for its own sake when CT was all we had. It was not. The domain sat on six addresses across five networks in that window, and the certificate churn is the shadow of the hosting churn. Neither source shows that behavior alone.

Two of those addresses reach past this domain. 65.49.223[.]138 is IT7 Networks (AS25820), the same network as the kit cluster below, and 148.178.16[.]5 sits in 148.178.16.0/23, the same Zillion Network /23 as the kit-cluster address 148.178.16[.]48. fifa[.]house is not merely adjacent to the directly-hosted slice. It is inside it.

Which is the wider correction. Part 1 closed on Validin’s framing, every active domain in the set sitting behind Cloudflare, and treated it as the wall this installment had to get over. The wall has holes. urlscan records the IP each capture actually resolved to, so bucket the kit-serving captures by address and a directly-hosted slice falls out, dozens of kit lookalikes answering straight from hosting IPs with no CDN in front. They cluster hard. 89.208.250[.]38 at IT7 Networks (AS25820) served eight of them (fifa[.]blue, fifa[.]cab, fifa[.]cash and more); a Zillion Network block (AS54801) carried another handful; a Hong Kong host (AS140227) carried the flfa typosquats. Reverse one of those IPs and the co-resident cluster comes back in a single pivot, which is exactly what reverse passive DNS is for.

Two disciplines make or break this. First, filter to the kit-unique bundle. Bucket on the kit’s shared library instead, a jQuery-style helper it copied wholesale, and you drag in unrelated GitHub Pages and Squarespace sites on Fastly, the same shared-infrastructure trap this installment keeps warning about, wearing a resource hash instead of an IP. Second, confirm before you attribute. One FIFA node in the favicon cluster, stadiumrushes[.]com, answered from a real origin, 198.54.115[.]155 on a LiteSpeed box, and looked like a find until checking the kit ticket path returned a 404. It serves a different FIFA clone, so it is a separate lead, not a Ghost Stadium origin.

Now the two names Part 1 surfaced that were absent from every published set. Mnemonic returns nothing for either one, which is precisely the empty answer this installment warned you not to accept. Check a second source and the history is sitting right there.

Validin has fifa-sg[.]shop resolving on 2026-05-17 and on no other day: two Cloudflare A records, the same two hosts again as AAAA, four Cloudflare nameservers, then NXDOMAIN from the eighteenth through today. VirusTotal returns the same two addresses on the same date, which is the corroboration you want before you build anything on one vendor’s history. That is also the date of Part 1’s four-certificate burst, which makes the domain’s entire operational life about one day wide. shop-26fifa[.]com never resolved at all. Cloudflare nameservers from 2026-05-20 to now, no A record anywhere in the history, and a registry record still marked active and paid through May 2027.

So passive DNS has plenty to say about both and still cannot hand you an origin, because every address either of them ever carried belonged to Cloudflare. That is the honest boundary of this lens. It recovers history, not hosting, and when an operator fronts a name from its first minute there is no origin in the record to recover. One of these ran for a day and was abandoned. The other was never switched on and is still being paid for. Write both down.

None of the origin-recovered domains are new; they were all in Validin’s set. What is new is the hosting. Validin’s view stopped at Cloudflare, and the per-capture IP fills that gap for the slice that never used it. 89.208.250[.]38 is a real host with ports and services you can point a scanner at, and eight of the domains it served are kit-confirmed. Reverse it and the FIFA footprint is wider than the kit filter alone shows: VirusTotal returns ten registrable fifa[.]* names there between 2026-01-10 and 03-18, and Validin adds fifa[.]work and wwww-fifa[.]com for twelve. Three counts, three filters, all of them honest as long as you say which one you used.

Then ask who else has lived there, because this is the discipline turned back on your own best lead. The same address answered for a Synology dynamic-DNS host in 2020 and an unrelated personal domain in 2019, and since 2026-05-08 it has resolved bwg-la9.ameredu[.]com, which is BandwagonHost naming. The FIFA tenancy is a ten-week window on a recycled reseller IP, not an operator-owned box. Time-windowing is not only how you filter a reverse lookup. It is how you decide what a recovered origin actually entitles you to say.

Assessment, high confidence: this operation is only partly Cloudflare-fronted. The active core hides its origin, but a substantial directly-hosted slice exposes it on a small set of reused IPs at IT7 Networks and Zillion Network. Recover origins from urlscan’s capture history rather than live resolution, filter to the kit-unique resource so shared-library noise does not fold in unrelated hosts, and treat every recovered IP as a reverse pivot into more of the cluster. Every address above is a capture-time observation from early to mid 2026. None of it is a claim about what is still listening today, which is the next installment’s job.

Auditing the list you were handed

Validin publishes their set as suspected, not confirmed, and that word earns its place. Two entries look nothing like the campaign: 808140[.]pro and 808150[.]pro, carrying forty-eight bbs* subdomains between them, with no FIFA string anywhere in sight. Worth asking what they are doing on a FIFA list. Passive DNS answers it, and the answer is not the one the list implies.

All fifty-one are NXDOMAIN today, so live DNS gives you nothing and pDNS is the only way in. Resolution history returns three addresses, and the first job is throwing one away. 91.195.240[.]94 reads as the most recent hosting until you check the owner: SEDO GmbH. That is parking, and the 2026 dates read as the domains expiring rather than the operator moving. The two real origins are 156.235.100[.]101 (USCLOUD, Seychelles) in February 2025 and 154.40.50[.]41 (NetLab Global) that April.

Reverse them and the sprawl comes back whole: the entire bbs*.808140[.]pro run on 2025-02-23, the 808150[.]pro half that April. Time-window as you go, because the Seychelles box also carried unrelated tenants that June, months after the operator left.

Now cross into Part 1’s lens. Let’s Encrypt issued four certificates for these names on 2025-02-23: a thirty-two name cert covering 808140[.]pro, its www. variant, and thirty bbs* hosts, reissued identically eight minutes later, plus two-name certs for 808140[.]com and 808150[.]com. Same day, same issuer, and that is the thread tying an unlisted .com side to the listed .pro side. Search those .com names in CT and a numbered series falls out, 808110 through 808190 on the tens plus a stray 808122, with m., admin., blog., and dev. subdomains. 808150[.]com has certificates going back to 2021 and a kefu. subdomain, Chinese for customer service, in 2023.

CT has one more thing to say, and it complicates the parking read rather than confirming it. Twenty-six single-name certificates land on these hosts between 2026-02-24 and 04-05, all from DigiCert’s Encryption Everywhere program, and they cover names Validin never listed: sitemap., sitemaps., and www. variants of individual bbs hosts. That window sits on top of the SEDO dates. Per-host DV issuance is also what a parking service does when it wants HTTPS on every name it is holding, so the parking read survives, but it is now a read rather than a fact. Note which one you took.

That is not World Cup infrastructure. It is a long-running numbered operation with a mobile site and a support desk, four years older than the tournament, and not one of its .com names made the published set at all. urlscan agrees: all fourteen captures of the bbs* hosts show the same control panel default page, 恭喜，站点创建成功！, and no capture anywhere shows kit content.

One thread keeps it open rather than closing it. 154.40.50[.]41 also served fifa[.]house and fifa[.]bio in February 2026, nine months after the 808150[.]pro sprawl. That shared address is the only bridge between the two, and it is a thin one. Nine months apart on a hosting provider’s IP is reuse as easily as tenancy, and that address was a ten-day stop in a six-address rotation rather than anybody’s home. It is probably why these names are on the list. It is not enough to keep them there.

Assessment, moderate confidence: 808140[.]pro and 808150[.]pro belong to a separate Chinese operation that predates the World Cup campaign and once shared an IP with it. Not one name in that numbered .com series is in the published set. Four have a tie to the listed pair beyond the numbering: 808140[.]com and 808150[.]com, certified the same day as the .pro names, and 808160[.]pro with its .com twin, which shared the Seychelles box in the same window. Those four are net-new to somebody else’s problem.

The transferable part is not the four names. A published indicator set is a starting point, not an answer, and the entries that look wrong to you are worth ten minutes before you block on them or build a detection from them. Every lens used above was free.

Hunt hypothesis template

HYPOTHESIS
  An adversary operating against us reuses hosting and nameserver
  infrastructure across domains. Starting from one known-bad
  indicator, related infrastructure is discoverable in passive DNS
  and was active during the incident window.

DATA SOURCES
  Primary:   CIRCL pDNS (COF), Mnemonic pDNS (own schema)
  Pivot UI:  Validin Community, Silent Push Community
  Enrich:    VirusTotal free, CT logs (Part 1)
  Context:   ASN / hosting reputation, self-run passivedns sensor

PIVOT STEPS
  1. Forward-resolve the known-bad domain. Record A/AAAA history
     with first/last seen.
  2. Constrain to IPs active during the incident window. Drop
     long-lived, high-count, shared-hosting addresses.
  3. Reverse-resolve each surviving IP. List co-resident domains.
  4. Keep only co-residents whose active window overlaps the
     incident. This is the candidate cluster.
  5. Pivot on shared NS, MX, and reused TXT tokens to extend the
     cluster beyond IP co-residence.
  6. Confirm cluster members against CT (shared certs) and scan
     data (matching service fingerprints).

EXPECTED SIGNAL
  A tight set of domains sharing IPs, nameservers, or verification
  tokens, with first-seen dates clustered around the staging
  period and last-seen dates clustered around takedown.

VALIDATION / TRIAGE
  Discard sinkholes, parking, CDNs, and shared resellers. Require
  at least two independent links (e.g. shared IP in-window AND
  shared NS) before promoting a domain to confirmed cluster member.

ATT&CK MAPPING
  T1583  Acquire Infrastructure (.001 Domains, .002 DNS Server)
  T1584  Compromise Infrastructure (.001 Domains, .002 DNS Server)
  T1568  Dynamic Resolution (.001 Fast Flux, .002 DGA)
  T1071.004  Application Layer Protocol: DNS

Tooling quick reference

COMMUNITY-RUN (start here, free, durable)
  CIRCL Passive DNS    circl.lu/services/passive-dns
                       Free, vetted account. COF output. CSIRT-built.
  Mnemonic pDNS        api.mnemonic.no/pdns/v3/{query}
                       Open API, no key for low volume. Own JSON schema.
  PyPDNS               pypi.org/project/pypdns
                       Python COF client. Any COF server via url=.

FREE SAAS PIVOT INTERFACES
  Validin Community    app.validin.com
                       Best free pivoting. Web + API. Multi-year history.
  Silent Push CE       silentpush.com (Community Edition)
                       Free pDNS + infra scanning. Daily credits, and
                       the CE number is not published. Check first.
  VirusTotal           /domains/{d}/resolutions, /ip_addresses/{ip}/resolutions
                       Free API key. ~4 req/min, ~500/day.

RUN YOUR OWN
  passivedns           github.com/gamelinux/passivedns
                       Sniff and log resolutions off your own tap.

OPTIONAL COMMERCIAL UPGRADES (not required for any of the above)
  DomainTools DNSDB (formerly Farsight), Microsoft Defender TI
  (formerly PassiveTotal), SecurityTrails (Recorded Future),
  Spamhaus pDNS, WhoisXML / DNSlytics.

The methodology does not change when you pay. Paid tools give you more coverage and faster queries, not a different technique. Run the loop above on the free sources and you already know how to use the expensive ones, and you are not stuck the day a trial expires.

Up Next

Open Season: Internet Scan Data. Take 89.208.250[.]38 with you, and take its dates with it. It is a real host at IT7 Networks that carried the kit from January to March 2026 and has belonged to somebody else since May, so a scan run today profiles the current tenant and tells you nothing about the campaign. Passive DNS got us the address and the window. It cannot tell us what was listening inside that window, and that is exactly the gap the next source closes. Censys and Shodan and what their free tiers actually give you, why a historical view beats a live probe on a recycled IP, the favicon hash everyone reaches for on a target like this and why it is the wrong primitive, and the one the kit cannot help serving.

Open Season is a recurring series from the THOR Collective exploring how practitioners can use open-source data to hunt adversary infrastructure. Each installment covers a single data source, soup to nuts. Want to contribute an installment or suggest a data source? Reach out.

Before I get into CZDS, first I want to set the stage of how we can view this data along with the other sources (mentioned in LPs blog and many others).

When a threat actor, let’s call them BOB, is going to setup a phishing campaign they will typically:

• Register a domain (or compromise one)

• Deploy their infrastructure (this one is more difficult to identify at this stage)

• Configure DNS

• (Nowadays) Obtain a SSL/TLS certificate

• Kick off the campaign

There are also operational steps that are highly dependent on infrastructure:

• General reconnaissance

• Brand impersonation/cloning/etc.

• Testing and verification

• Lure infrastructure may be different

All of these are different sources of data.

The important thing to understand is that each phase leaves behind a different type of telemetry:

• Certificate Transparency logs tell us when certificates are issued.

• Passive DNS tells us how infrastructure resolves over time.

• Hosting and network intelligence tells us where infrastructure lives.

• Registrar data gives us ownership and registration context.

CZDS gives us visibility into one of the earliest events in this lifecycle: domain delegation.

Today, though, we are going to talk more about the first phase: domain registration.

DNS (Domain Name System) is a globally distributed, hierarchical naming system. The age-old question of how the internet works is how domain.com eventually resolves to an IP address. When a new domain is delegated, the appropriate TLD registry publishes that delegation, so recursive resolvers can eventually discover it.

Before a phishing page exists, before a certificate is issued, before a victim receives an email, there is usually a domain registration and DNS delegation event.

That small window is where CZDS becomes interesting.

Because of this, ICANN has a service called CZDS (Centralized Zone Data Service) which provides daily zone files for participating gTLD registries. These zone files map delegated domains to their authoritative name servers and, when necessary, include glue records containing the IP addresses of those name servers.

In other words, CZDS gives defenders a view into the DNS delegation layer of the internet.

It does not tell you what a domain is currently hosting, what IP address a website resolves to, or what content exists behind the domain. Instead, it tells you that a domain exists and where its authoritative DNS infrastructure lives.

By collecting this data over time, you can begin to see how certain authoritative name servers repeatedly appear alongside fuzzy domain registrations, how domain name re-use/re-registration occurs over extended periods of time, or view outliers/clusters in relation to your own threat intelligence feed.

What is CZDS?

One reason CZDS tends to be overlooked is that the raw data isn’t immediately exciting. A zone file is just text, and most of the records you’ll encounter are completely benign.

Unlike Certificate Transparency, where suspicious certificate requests can sometimes stand out on their own, the value in CZDS rarely comes from an individual record. It emerges when you collect snapshots over time, enrich them with other datasets, and start asking relationship-based questions instead of record-based ones.

To use CZDS you do have to register an account and get an API key to download the compressed files. Each .zone file contains DNS delegation information for a gTLD, including delegated domains, authoritative name servers, and glue records where required.

I’m not going to go into details about name servers here, but the basics are that authoritative name servers publish the DNS records that allow resolvers to translate domain names into IP addresses and other resource records.

The IP addresses you see in a CZDS TLD zone file are glue records. They are not the IP addresses of the domain itself but rather the IP addresses of authoritative name servers when those addresses are needed to complete DNS delegation.

This distinction is important because CZDS is not passive DNS.

CZDS will not tell you:

• Where a domain currently resolves

• Historical A/AAAA resolutions

• HTTP behavior

• Malware delivery infrastructure

• Certificate history

For that, you still need additional data sources.

What CZDS does provide is the earliest DNS-level visibility into domain existence and delegation relationships.

There is an important tradeoff, though. Certificate Transparency can often provide visibility close to the moment a certificate is issued, whereas CZDS is distributed as periodic snapshots by participating registries. Rather than observing individual delegation events in real time, you’re observing how the delegation layer changes over time. Those are different datasets with different strengths, and together they provide a more complete picture of infrastructure evolution.

Data Relationships

This is where the data becomes much more interesting.

A single domain registration by itself is usually just noise.

A domain that shares authoritative infrastructure with hundreds of other suspicious domains is a different story.

The value is not necessarily in the individual record. The value comes from the relationships.

Imagine ingesting daily zone files for a handful of popular gTLDs. One morning, a newly delegated domain catches your attention. On its own, it isn’t particularly interesting. But when you pivot to its authoritative name servers, you discover they’re also responsible for hundreds of other recently delegated domains.

Those name servers resolve through the same glue IPs, which belong to infrastructure you’ve previously associated with phishing activity. None of the domains have active websites yet, and none have appeared in Certificate Transparency logs. Nevertheless, you’ve already identified what appears to be a coordinated infrastructure cluster before most defenders would even know it exists.

That’s the advantage of treating CZDS as relationship data instead of a list of domain names. You’re not waiting for malicious content to appear; you’re looking for infrastructure patterns that suggest future activity.

For example:

domain
  |
  +-- authoritative nameserver
          |
          +-- glue IP
                  |
                  +-- ASN
                  |
                  +-- other domains

Once you start looking at CZDS data as relationship data instead of just DNS records, you can begin building infrastructure graphs.

There are dozens of ways that this data can be useful for your organization:

• Shared authoritative name servers

• Shared glue IPs

• Newly delegated domains

• Registrar patterns (with additional data)

• DNS hosting providers

• Infrastructure reuse

• Identifying clusters of related registrations

The problem though is size because of exponential growth over time (which has limited my research) unless you engineer it.

NOTE: If anyone has petabyte(s) storage for free and forever then holla at me

The interesting engineering problem is not necessarily storing every record forever. It is deciding what relationships and attributes actually matter.

For example, instead of storing:

domain -> every historical DNS record

you may get more value from storing:

nameserver -> domains
IP -> nameservers
ASN -> infrastructure
registrar -> domains
first_seen
last_seen

The intelligence questions you want to answer should drive the data model.

Understanding CZDS Zone Files

Each .zone file contains DNS delegation information for a gTLD, including delegated domains, authoritative name servers, and glue records where required.

For example, a simplified delegation may look something like:

example.com. 172800 IN NS ns1.example.net.
ns1.example.net. 172800 IN A 192.0.2.10

The first record tells resolvers which authoritative name server is responsible for the domain.

The second record exists because ns1.example.net is within the namespace being delegated, and the resolver needs the IP address to find that server.

This is why CZDS is useful, but also why it is commonly misunderstood.

These zone files will give you the authoritative information for a gTLD but not details about the domain itself (the domain’s A, AAAA, CNAME, MX, etc. records); that you must still do if needed/warranted/etc.

The intelligence comes from combining CZDS with other sources.

For example:

CZDS
 |
 +-- Domain delegation
        |
        +-- Nameserver
              |
              +-- Glue IP
                    |
                    +-- ASN
                    |
                    +-- Other observed domains

That relationship can then be enriched with:

• Certificate Transparency

• WHOIS/RDAP

• Passive DNS

• Hosting intelligence

• Reputation feeds

• Internal telemetry

The goal is not to answer:

“Is this domain malicious?”

The goal is to answer:

“What infrastructure relationships does this domain have, and have we seen similar behavior before?”

Parsing Zone Files

Here’s a general layout of the field data in these zone files:

www.example.com. 3600 IN A 192.168.1.10

which produces the following in a JSON format:

{
    "dns_record": "www.example.com",
    "ttl": "3600",
    "record_class": "IN",
    "record_type": "A",
    "record_data": "192.168.1.10"
}

For CZDS specifically, the records you will most commonly care about are delegation-related records:

• NS records

• Glue A records

• Glue AAAA records

The challenge with CZDS is not parsing a single file.

The challenge is scale.

Zone files can be large, and storing every record from every zone forever, quickly becomes impractical unless you have a very specific reason for doing so.

This is why streaming is important.

Instead of:

records = load_entire_zone_file() 

you generally want:

for record in stream_zone_file(): 

    process(record) 

This allows you to:

• Process large zones with constant memory usage

• Build enrichment indexes incrementally

• Extract only relationships you care about

• Avoid loading multi-gigabyte files into memory

Implementation Examples

I have had a few implementations of using CZDS over the years. The most recent is embedded as a source within a project called go-member-extender. This takes a MMDB database (binary search tree over IP addresses; fast lookups possible) and can extend or upsert it with data from different sources.

This one happens to be CZDS and written in Golang:

https://github.com/MSAdministrator/go-mmdb-extender/blob/main/internal/source/czds/czds.go

The general idea is:

CZDS Zone File 
        | 
        v 
Parse delegation data
        |
        v
Extract relationships
        |
        v
Enrich IP intelligence database

The advantage of this approach is that you can combine CZDS-derived information with other enrichment sources without needing to query massive raw datasets during investigations.

If Python is more your thing, then check out my Python package/CLI tool for CZDS below.

This one doesn’t touch a MMDB at all and just retrieves the zone files as requested.

https://github.com/MSAdministrator/czds

With either tool, remember you must have API access and have been granted access to more than one zone files.

Python Streaming Parser (example)

The first implementation uses dnspython and provides behavior similar to Go’s DNS parsing libraries.

The goal is:

• Stream records

• Avoid loading entire zones

• Support compressed zone files

• Process records as they arrive

from __future__ import annotations

import gzip
from pathlib import Path
from typing import Iterator

import dns.exception
import dns.name
import dns.rdata
import dns.rdataclass
import dns.rdatatype
import dns.tokenizer
import dns.zonefile


def stream_zone_records(
    filename: str | Path,
    origin: str,
) -> Iterator[dns.rdata.Rdata]:
    """
    Stream records from a zone file without loading the entire zone.

    Yields ResourceRecord objects one at a time, similar to Go's
    dns.NewZoneParser().
    """
    opener = gzip.open if str(filename).endswith(".gz") else open

    with opener(filename, "rt", encoding="utf-8", errors="replace") as f:
        tok = dns.tokenizer.Tokenizer(f)

        reader = dns.zonefile.Reader(
            tok,
            dns.name.from_text(origin),
            rdclass=dns.rdataclass.IN,
            relativize=False,
        )

        while True:
            try:
                rr = reader.read_rr()
            except EOFError:
                break
            except dns.exception.DNSException as e:
                raise RuntimeError(f"Zone parse error: {e}") from e

            if rr is None:
                continue

            yield rr

The important part here is not the dictionary itself. The important part is that we are transforming raw DNS data into relationships that can later be queried.

A raw zone file is just text.

A relationship database built from those records becomes intelligence.

Lightweight CZDS Parser

The second implementation is a lightweight parser written specifically around the CZDS workflow.

The goal was not to replace full DNS parsing libraries.

The goal was a small streaming parser that handles the features needed for large-scale zone processing:

• Streaming iteration (for rr in ZoneParser(path):)

• Constant memory usage

• .gz and plain text support

• $ORIGIN

• $TTL

• Owner inheritance

• Multiline records with parentheses

• Comment stripping

• Quoted-string preservation

• RFC 3597 TYPE#### support

• Lightweight ResourceRecord dataclass

This version is intentionally focused on CZDS-style processing rather than being a complete replacement for every possible BIND zone feature.

NOTE: This bottom one was written by Claude so take it with a grain of salt but it looks like to would work.

from __future__ import annotations

from dataclasses import dataclass
from pathlib import Path
import gzip
import re
import shlex
from typing import Iterator, TextIO

RFC3597_TYPE = re.compile(r"^TYPE\d+$", re.IGNORECASE)
_CLASSES = {"IN", "CH", "HS"}


@dataclass(slots=True)
class ResourceRecord:
    name: str
    ttl: int | None
    rdclass: str
    rdtype: str
    rdata: tuple[str, ...]


class ZoneParser:
    """Streaming BIND zone parser suitable for CZDS."""

    def __init__(self, path: str | Path):
        self.path = Path(path)
        self.origin = ""
        self.default_ttl: int | None = None
        self.current_owner: str | None = None

    def __iter__(self) -> Iterator[ResourceRecord]:
        opener = gzip.open if self.path.suffix == ".gz" else open
        with opener(self.path, "rt", encoding="utf-8", errors="replace") as f:
            yield from self._parse(f)

    @staticmethod
    def _strip_comment(line: str) -> str:
        out = []
        quoted = False
        escaped = False
        for ch in line:
            if escaped:
                out.append(ch)
                escaped = False
                continue
            if ch == "\\":
                escaped = True
                out.append(ch)
                continue
            if ch == '"':
                quoted = not quoted
                out.append(ch)
                continue
            if ch == ";" and not quoted:
                break
            out.append(ch)
        return "".join(out)

    def _fqdn(self, owner: str) -> str:
        if owner == "@":
            return self.origin
        if owner.endswith("."):
            return owner[:-1]
        return f"{owner}.{self.origin}" if self.origin else owner

    def _parse(self, fh: TextIO) -> Iterator[ResourceRecord]:
        buf = []
        depth = 0
        for raw in fh:
            line = self._strip_comment(raw).strip()
            if not line:
                continue
            depth += line.count("(")
            depth -= line.count(")")
            buf.append(line.replace("(", " ").replace(")", " "))
            if depth > 0:
                continue
            record = " ".join(buf)
            buf.clear()

            if record.startswith("$ORIGIN"):
                parts = record.split(None, 1)
                if len(parts) > 1:
                    self.origin = parts[1].rstrip(".")
                continue
            if record.startswith("$TTL"):
                parts = record.split(None, 1)
                if len(parts) > 1:
                    self.default_ttl = int(parts[1])
                continue

            lex = shlex.shlex(record, posix=True)
            lex.whitespace_split = True
            tokens = list(lex)
            if not tokens:
                continue

            idx = 0
            owner = None
            first = tokens[0]
            up = first.upper()
            if not first.isdigit() and up not in _CLASSES:
                owner = first
                self.current_owner = owner
                idx = 1
            else:
                owner = self.current_owner
                if owner is None:
                    continue

            ttl = None
            rdclass = "IN"

            while idx < len(tokens):
                t = tokens[idx]
                u = t.upper()
                if t.isdigit():
                    ttl = int(t)
                    idx += 1
                elif u in _CLASSES:
                    rdclass = u
                    idx += 1
                else:
                    break

            ttl = self.default_ttl if ttl is None else ttl
            if idx >= len(tokens):
                continue

            rdtype = tokens[idx].upper()
            idx += 1

            if not (rdtype.isalpha() or RFC3597_TYPE.fullmatch(rdtype)):
                continue

            yield ResourceRecord(
                name=self._fqdn(owner),
                ttl=ttl,
                rdclass=rdclass,
                rdtype=rdtype,
                rdata=tuple(tokens[idx:]),
            )


if __name__ == "__main__":
    import sys
    for rr in ZoneParser(sys.argv[1]):
        print(rr)

Like Certificate Transparency, CZDS isn’t valuable because it magically identifies malicious domains. Its value comes from exposing another layer of attacker infrastructure that would otherwise remain difficult to observe.

By itself, a zone file is little more than a collection of DNS delegation records. Combined with Certificate Transparency, Passive DNS, registrar information, hosting intelligence, and your own internal telemetry, those records become edges in an infrastructure graph that can reveal relationships long before a phishing campaign reaches a victim.

That’s ultimately the lesson I took away after reading LP’s post. Modern threat intelligence isn’t about finding one perfect dataset, it’s more about understanding what each dataset can tell you, what it can’t, and how combining them creates something far more valuable than any individual source alone.

Leave a comment

Most data sources catch an adversary after they act. Certificate Transparency catches them before.

When an operator stands up new infrastructure, say a phishing page or a C2 redirector, they almost always want TLS on it. A padlock makes a fake login look real, and browsers punish plain HTTP, so they request a certificate. The moment a publicly trusted CA issues it, that certificate is written into the Certificate Transparency logs, public append-only ledgers built so anyone can audit what CAs hand out.

The operator never chose to publish the domain. The CA did it for them, automatically, often before the service is even reachable. That gap is what you hunt in: the window between cert issued and attack launched, sometimes hours, sometimes days.

And it is completely free. CT was built as a public good and it remains one, no matter how many vendors wrap it in a dashboard and charge for the view.

What the data tells you

A CT log entry is a certificate plus metadata. For hunting, the fields that matter are the common name and the Subject Alternative Names (the domains the cert is valid for), the issuer (which CA signed it), the validity window (not_before and not_after), and the log entry timestamp, which is when the certificate actually reached the log.

The single most useful field is the SAN list. A certificate is frequently valid for more than one name, and operators bundle related infrastructure onto one cert all the time: the phishing domain, its www variant, a staging subdomain, sometimes a second unrelated campaign domain they were too lazy to separate. One cert, read carefully, hands you the operator’s other names for free.

The second useful field is the log entry timestamp. Certificates hitting the logs in a tight cluster for similar-looking names are a batch of infrastructure going up at once, and that rhythm is something you can cluster on. Use that one rather than not_before, for reasons in the traps below.

As of early 2026 there are roughly thirty to forty active CT log shards, operated by Google, Cloudflare, Let’s Encrypt, Sectigo, and a few others. Chrome and Apple each maintain their own list of trusted logs, and the two do not overlap perfectly. Chrome’s is the one most tooling tracks. To be trusted in a modern browser a cert needs proof that it was logged, and that proof is a Signed Certificate Timestamp, or SCT, a log’s signed promise that it accepted the certificate. You do not have to talk to the logs directly. Aggregators do that for you.

Why adversaries leave traces in it

Because the alternative is worse for them. Skip CT and the cert is untrusted, which means browser warnings, which means victims bounce before they type their password. The whole point of the fake login page is that it looks legitimate, and looking legitimate now requires a logged certificate. CT compliance is load-bearing for the attack.

They can use self-signed certs on non-browser infrastructure like C2, and some do. But anything a human opens in a browser needs a real cert, and a real cert gets logged. The economics of phishing leave no way around it.

Know what this lens cannot see, though. CT only covers publicly trusted CAs, so a private CA leaves no entry, and neither does IP-only infrastructure that never gets a name. Anything behind a provider that terminates TLS on a shared certificate (Cloudflare universal certs, Vercel, most phishing-as-a-service platforms) may never produce an entry you can tie to the operator. Absence from CT is not absence of infrastructure.

The behaviors that show up:

Batch issuance.

An actor registering and certing ten lookalike domains in an afternoon produces ten certs that hit the logs within minutes of each other. Cluster on the timing.

Naming conventions.

Operators reuse patterns. Once you see login-acme-support.com, you go looking for login-acme-secure.com and acme-support-login.com, because the same person tends to name things the same way.

CA preference.

Throwaway phishing infrastructure leans on free, automated CAs because cost and speed matter at volume. That is a weak signal on its own, but it stacks with the others.

How to query and pivot

The free workhorse is crt.sh, Sectigo’s CT search engine. It indexes the major logs into a Postgres database and exposes both a web UI and a JSON API. Start simple:

# every name ever seen in a cert under a domain
curl -s 'https://crt.sh/?q=%25.example.com&output=json' \
  | jq -r '.[].name_value' | sed 's/^\*\.//' | sort -u

The % is a SQL wildcard, so %.example.com pulls every subdomain that has ever appeared in a logged certificate. Write it as %25 in the URL, which is how % is percent-encoded. The bare version usually works but is not valid encoding, and it will fail behind some proxies. This alone surfaces dev, staging, and internal-looking hosts that were never meant to be public. For an adversary domain, it surfaces their other names.

Point it at your own domain while you are here. Every name in a publicly trusted cert is public the moment the CA issues it, so an internal hostname in one is a hostname you have published. If it should not be, it belongs on a private CA or behind a wildcard.

When you need real power, crt.sh exposes its Postgres directly, no account, read-only guest access:

psql -h crt.sh -p 5432 -U guest certwatch

From there you can run actual SQL against the certificate data, which is how you do timing clustering and pattern hunting that the web UI cannot:

-- one row per certificate, ordered by when it actually hit the logs
SELECT min(le.entry_timestamp) AS logged,
       x509_notBefore(c.certificate) AS not_before,
       x509_issuerName(c.certificate) AS ca
FROM certificate c
JOIN ct_log_entry le ON le.certificate_id = c.id
WHERE to_tsquery('certwatch', 'login-acme-support.com') @@ identities(c.certificate)
GROUP BY c.id, c.certificate
ORDER BY logged;

Grouping on c.id collapses a cert logged to several logs into one row, and min(entry_timestamp) gives you the moment it first appeared. Ordering on that rather than not_before is deliberate, for reasons in the traps below. The to_tsquery match is the current way in: as of July 2026 crt.sh has retired the old certificate_identity table for a full-text index, so queries against it now error, and the tsquery goes on the left.

That index does prefix and suffix matching, not substring, so you cannot ask crt.sh for every name containing a string. You have to arrive with names. The public Postgres is slow and kills anything running over about a minute, so be specific.

The pivots, in the order they tend to pay off:

SAN expansion.

Pull a suspicious cert. Read every name on it. Each new name is a new lead, and you feed each one back into crt.sh to find its certs and its SANs in turn. This is the core loop.

Timing clustering.

Sort candidate certs by log entry time. Names that cluster within minutes or hours of each other are very likely the same operator’s batch. The tighter the cluster and the more the names rhyme, the stronger the signal.

Naming-convention sweeps.

Take the pattern from one confirmed domain and go looking for its siblings. Operators are creatures of habit, and the database remembers every cert. crt.sh will not do this as a free-text substring search, so generate the candidate names yourself and check them in batches. A few hundred generated names cost nothing but patience. The indexes that do offer substring matching over CT gate it behind a paid tier or a browser session, so treat those as a manual spot-check.

Mind the traps though.

Wildcard certs (*.example.com) are candidates, not confirmed hosts, so always resolve before you trust them. Every certificate appears in the logs at least twice, once as a precertificate and once as the final cert, so deduplicate before you count.

And do not build timing analysis on not_before. The issuing CA sets it and every CA does it differently: Let’s Encrypt backdates about an hour, some a full day, some pin to midnight UTC. Compare certs from two CAs on that field and you are reading two clocks with two offsets, which invents bursts that never happened and flattens ones that did. Use the log entry timestamp. not_before is a CA’s opinion; the log entry is a fact.

For watching issuance live, certstream gives you a real-time firehose of every cert hitting the logs:

# wss://certstream.calidog.io  (filter for your patterns in real time)
pip install certstream

Point a small script at the stream, match on your target’s naming patterns or brand strings, and you get alerted within minutes of a new lookalike cert being minted. For a handful of domains without writing code, Certspotter from SSLMate offers free monitoring for up to five domains with email alerts.

One warning before you build on it. The public certstream.calidog.io endpoint fails in the worst possible way: the socket opens, stays up, and no certificates arrive. Nothing errors, so your watcher looks healthy and is deaf. Tested while writing this with the official client and with raw websockets, both endpoints, zero certificates.

The website will not tell you either. On connect the page replays a cached /latest.json into the live pane at a randomized, human-looking pace, and that cache has not moved since October 2025, so a dead feed still scrolls convincingly. Treat the public firehose as a demo. If the alert matters, self-host certstream-server-go, or certstream-server-rust at certstream.dev if you want the stream over SSE instead. And alert on silence as well as on matches, because here silence is ambiguous.

One note if you build your own tooling. CT is migrating from the original RFC 6962 dynamic logs to the tile-based Static CT API (Sunlight), and Chrome’s trusted list already mixes both. Query through crt.sh, certstream, or Certspotter and this is handled for you. Write your own log reader and you need to speak both during the changeover.

In practice: Ghost Stadium

The question going in: can certificate data surface campaign infrastructure the published sets have missed, and can it at least date the operation?

Point the CT loop at Ghost Stadium and the operator turns out to live by the same economics as everyone else. The kit is a fake FIFA World Cup 2026 ticket storefront meant to be opened in a browser, so every live node needs a trusted cert, and every cert lands in the logs. Pull the certs for fifa-sg[.]shop, a confirmed net-new node that has since been deleted, and the issuance pattern is louder than any SAN. On 2026-05-17 it drew four certificates in twenty-one minutes from three different CAs, Google Trust Services, then Let’s Encrypt, then SSL Corporation, back to back. That is automated standup, an operator spraying certificate requests the moment the domain goes live. Measure the same burst on not_before and it stretches to seventy minutes, because the three CAs backdate by different amounts. The tight number is the real one.

shop-26fifa[.]com shows the same shape three days later, four certs across two CAs inside fourteen minutes on 2026-05-20. The domain was registered at 18:30:41 UTC and its first certificate hit the logs under three minutes later. Cert issuance and registration are not just the same day, they are the same event, which is why this lens and Part 4 corroborate each other. It is also the cleanest argument for reading log entries: that first certificate carries a not_before of 17:34:45, fifty-six minutes before the domain it covers existed.

Check one thing before you call that automation. The registrar was NameSilo and the certificates came from Let’s Encrypt and SSL Corporation, unrelated vendors, so somebody’s own tooling drove it. fifa[.]house is the counterexample: registered through GoDaddy, certified by GoDaddy thirty-seven seconds later. That interval says something about GoDaddy’s provisioning and nothing at all about the operator. When registrar and CA are the same company, a fast cert is a checkout bundle, not tradecraft.

The reissuance rhythm then just keeps going: fifa[.]house cycled through twenty-one certs from January to April across GoDaddy, Let’s Encrypt, and TrustAsia, tempo you read straight off the log entries.

SAN co-tenancy is where this gets interesting, because the same campaign does it both ways. fifa-sg[.]shop and shop-26fifa[.]com are disciplined: apex, wildcard, nothing else. Read those two and you would conclude the operator certs one name at a time.

fifa[.]house is the opposite. One of its certificates carries forty-five names spanning about twenty registrable domains: fifa[.]bio, fifa[.]cafe, fifa[.]college, fifa[.]tax, the whole fifa-com[.]* run across seven TLDs, then www-fifaworldcup[.]* across seven more. Feed three seed domains into the SAN loop and twenty-five come back out.

Widen that to a sample of six hundred domains from the published set and the split holds: ninety-one percent of their certificates cover a single registrable domain, nine percent bundle more, and a hundred and sixty-two certs carry exactly one hundred names, which is Let's Encrypt's SAN limit. Somebody is filling certificates to the limit and somebody else is provisioning one at a time. The certificates are where that seam shows.

Expanding on shared certs drags in infrastructure that is merely adjacent. One of those hundred-name certs mixes FIFA lookalikes with Chinese gambling brands that may be a different operation entirely, and six more turned out to be a bulk-cert service carrying unrelated tenants that have nothing to do with this campaign at all. The highest-yield pivot here is also the one most likely to hand you somebody else's estate. Confirm before you count.

Ghost Stadium is also heavily reported, and that shapes what CT is good for. Group-IB mapped more than 4,300 fraudulent FIFA domains registered since August 2025, but that total spans six fraud schemes and four independent threat actors; Ghost Stadium itself is the 300-plus domains actively serving the kit. Group-IB describes the operator as Chinese-speaking and financially motivated, and that is as far as attribution goes here. Validin went further on infrastructure and published a suspected set of 6,113 domains, about half still resolving, with the full list on GitHub where anyone can diff against it.

So check rather than assert. The SAN loop turned three seed domains into twenty-five registrable domains, forty-nine DNS names once you count www variants. Diff those against Validin’s set and forty-six of the forty-nine were already on it. Two of the three misses were seeds rather than discoveries — fifa-sg[.]shop and shop-26fifa[.]com went into the loop, they did not come out of it — and the third is a www variant of a listed domain. SAN expansion produced exactly one name nobody had.

Read that before you take it as a verdict. Most of Validin’s set came from a lookalike regex that matches any fifa-shaped domain, so fifa[.]cafe was going to be on that list whether or not a human ever looked at it. Against a regex superset, “already published” means the name matched a pattern. Against Group-IB’s 300 active domains it would mean someone investigated it. Those are different bars, and CT grades worse against the first one than it deserves.

Corroboration with timestamps is still worth having when you are deciding whether to act on someone else’s list. But the net-new nodes in this series came from pairing the cert view with a kit-specific fingerprint in a later installment, not from certificates alone. One more thing from Validin that matters for what comes next: every active domain in their set sits behind Cloudflare, which is exactly the wall Part 2 has to get over.

Then take one confirmed node and resolve it. These answered from 104.21, 172.64, and 172.67 space while they were live, all Cloudflare, AS13335. CT told you the name exists and the minute its cert was minted. It cannot tell you where the box actually sits, because the operator parked Cloudflare in front of it. That gap is exactly what the next source exists to close.

Assessment, high confidence: against an actor this heavily reported, Certificate Transparency expands a name list fast but rarely past what someone has already published. Use it to confirm cluster membership, read the batch rhythm, and date the standup. Expect a thin net-new edge, not a new cluster.

Hunt hypothesis template

HYPOTHESIS
  An adversary targeting our brand stages lookalike infrastructure
  and certs it before launch. New certificates matching our brand
  patterns appear in CT logs ahead of the attack and cluster by
  issuance time and naming convention.

DATA SOURCES
  Primary:  crt.sh (web, JSON API, direct Postgres)
  Live:     certstream (wss://certstream.calidog.io), Certspotter
  Backup:   Censys/Shodan cert search (free), MerkleMap, Merkle Town
  Cross-ref: passive DNS (Part 2), scan data (Part 3),
             registration data (Part 4)

PIVOT STEPS
  1. Start from known domains and pull their certs. crt.sh
     matches names, not substrings.
  2. For each hit, expand the SAN list. Every name is a new lead.
  3. Sort candidates by log entry time, not not_before. Flag
     tight issuance clusters.
  4. Generate names from the convention and check them in
     batches. crt.sh has no substring search.
  5. Resolve survivors; confirm via pDNS co-residence and scan-time
     cert match before promoting to confirmed.
  6. Add matched patterns to a certstream watch for live alerting.

EXPECTED SIGNAL
  A cluster of lookalike domains sharing a naming convention, with
  certs hitting the logs in a tight window, from one CA or
  sprayed across several, resolving to shared or adjacent hosting.

VALIDATION / TRIAGE
  Deduplicate precert/leaf pairs. Treat wildcards as candidates,
  not hosts. Resolve before trusting. Require a second independent
  link (shared IP, shared registrant) before confirming.

ATT&CK MAPPING
  T1583.001  Acquire Infrastructure: Domains
  T1588.004  Obtain Capabilities: Digital Certificates
  T1587.003  Develop Capabilities: Digital Certificates
  T1608.003  Stage Capabilities: Install Digital Certificate
  T1596.003  Search Open Technical Databases: Digital Certificates

Tooling quick reference

FREE, NO ACCOUNT (start here)
  crt.sh              crt.sh/?q=%25.domain&output=json
                      Web UI, JSON API, and direct Postgres:
                      psql -h crt.sh -p 5432 -U guest certwatch
  certstream          wss://certstream.calidog.io
                      Real-time firehose of all new certs.
                      Public server accepts the connection then
                      delivers nothing, which looks like a quiet
                      day. Self-host certstream-server-go for
                      anything load-bearing.

FREE MONITORING / BACKUP INDEXES
  Certspotter         api.certspotter.com/v1/issuances
                      Free alerts for up to 5 domains. Works
                      without an account for lookups.
  Merkle Town         Cloudflare CT dashboard/search
  MerkleMap           merklemap.com  (alternate CT search)
  Censys / Shodan     cert search. Substring search exists here
                      but free tiers restrict it to the browser;
                      the search APIs want a paid plan.

PASSIVE SUBDOMAIN TOOLS THAT USE CT
  subfinder, amass    use CT logs as a primary passive source

OPTIONAL COMMERCIAL UPGRADES (not required)
  Censys/Shodan paid cert data, SSLMate paid monitoring,
  vendor CT feeds. None needed for anything above.

Two things are true about the hunt above. The SAN loop worked exactly as advertised and turned three domains into twenty-five. And all but one were already on a list somebody published months ago. CT did not fail there. It walked ground that had already been mapped, and told us when each stone was laid.

That is the shape of this source. What you get out of CT scales with how early you are and how few people have looked before you. Arrive after the reporting lands and it corroborates and dates. Arrive first and it is the only place the infrastructure exists yet, because the certificate is minted before the site serves a page, before the mail goes out, before there is anything else to detect.

Which is the argument for pointing it at yourself. Nobody has published the list of domains that will impersonate your brand next quarter. On that hunt you are not late, you are first, and you already know the brand strings worth watching. The limitation that blunts CT against a well-reported actor does not apply when the target is you.

CT is the rare source where you are not chasing the adversary, you are waiting at the door they have to walk through. They need a trusted cert, that cert gets logged the moment a CA issues it, and the log is public and free for anyone to read. No vendor owns that.

Catch the cert before the campaign starts, and you are hunting the attack while it is still being built.

Up Next

Take fifa[.]house with you. CT handed us twenty-one certificates on it, a first-to-last window from January to April, and roughly twenty sibling domains riding its SANs. What CT cannot tell us is where any of it was hosted. The name is NXDOMAIN today, so there is nothing left to resolve. Same for fifa-sg[.]shop, dead since May. We have precise names and precise minutes, and no addresses.

Open Season: Passive DNS. That gap is what the next source closes. Passive DNS is the historical record of what resolved where and when, the one place a dead name still has an address, and the way behind a CDN to an origin the operator forgot to firewall. It reverses an IP into every domain that shared it, and clusters campaigns by the hosting and nameservers they reuse. We anchor it on community-run data, no vendor gates.

Open Season is a recurring series from the THOR Collective exploring how practitioners can use open-source data to hunt adversary infrastructure. Each installment covers a single data source, soup to nuts. Want to contribute an installment or suggest a data source? Reach out.

Leave a comment

The threat intelligence industry has spent years selling practitioners a lie: that hunting takes a budget.

You have heard the pitch on every sales call. The good data is gated, the real pivots need an enterprise license, and mapping an adversary’s infrastructure runs six figures before you start. Everything cheaper is for hobbyists.

It was never true, and this series is the proof.

The internet already records adversary infrastructure constantly, in public and for free, if you know where to look. Every certificate an operator mints gets logged by the CA that issued it. Passive sensors keep the domains they resolve long after those domains go dark. Scanners banner-grab exposed services within hours, registration paperwork carries a timestamp, and anything leaked to a public repo sits there until someone finds it. None of this needs permission, and most of it predates the vendors now reselling it to you at a markup.

That is the first ground rule, and it does not bend. Every source in this series is free to reach, no enterprise license, no “contact sales.” Where a paid tool genuinely helps, it shows up as an optional upgrade and the core method still runs without it. A technique that only works with a paid key is not in here. A practitioner with a terminal and no budget can run everything that follows.

Reading defensive data offensively

Most analysts meet these sources from the defensive side, watching their own walls. You monitor Certificate Transparency in case someone mis-issues a cert for your domain, check passive DNS to see where your own infrastructure resolved, scan your external surface, and grep public repos for your leaked secrets. Useful work, all of it, and all of it reactive.

This series is about turning the telescope around.

Point the same tools the other way and they do offensive work without complaint. The Certificate Transparency log that warns you about a phished brand will also surface the staging domains an actor certed last night, before the first email goes out. Passive DNS that maps your own footprint reverses an adversary’s IP into every domain that shared it. The scanners inventorying your attack surface will flag a Cobalt Strike team server hiding behind a redirector. The queries are identical; only who you aim them at changes.

That shift is the whole discipline: you stop waiting for an alert and start finding the campaign while it is still being built. It costs nothing but the time to learn the queries.

What this is, and what it is not

Open Season is a methodology series. Each installment takes a single freely accessible data source and walks it end to end: what the source actually tells you, why adversaries leave traces in it whether they want to or not, how to query and pivot through it, how to enrich and correlate it against the other sources, a hunt hypothesis you can lift and run, and a tooling quick reference. Soup to nuts, one source at a time.

It is written for practitioners. Threat hunters, detection engineers, CTI analysts, IR leads. People who will actually open the terminal. There is no executive summary energy here, no “in today’s evolving threat environment.” If you want a vendor whitepaper, there are a thousand of those and they are easy to find. This is the other thing.

It is also not a story series. The THOR Collective does narrative threat intelligence elsewhere, the “From the Fire” kind, behavioral and contextual. Open Season is the opposite register. Straight hunt methodology, structured, repeatable, the kind of thing you keep open in a second tab while you work.

The map

Each installment stands on its own, but they compound, because real hunting is never one source. You pivot from a cert to an IP to a domain to a registrant to a repo, and the picture assembles across all of them.

Certificate Transparency. Every public cert, logged forever, queryable for free through crt.sh. Issuance timing, SAN analysis, naming conventions, real-time monitoring of new certs as they are minted. The fastest way to catch infrastructure before it goes live.

Passive DNS. The historical record of what resolved where, and when. Reverse an IP into its co-resident domains, time-window the noise out, cluster operations by shared hosting and nameservers. Anchored on community-run data, not vendor gates.

Internet Scan Data. What a box is actually running. Open ports, banners, TLS fingerprints. JARM and JA4 to identify C2 frameworks even behind a redirector, with tools you run yourself for nothing.

WHOIS and Registration Intelligence. The paperwork, in the post-GDPR, RDAP era. What still leaks after redaction: registration timing, nameserver patterns, registrar choices, and the historical records that predate privacy.

Code and Paste Repositories. Where operators leak their own tooling, configs, and credentials. GitHub, GitLab, paste sites. Reading the adversary’s OPSEC failures off the public record.

Front Companies and Fraudulent Employment. The capstone, where every prior source converges on a single live problem: hunting DPRK IT worker operations and the shell infrastructure that supports them.

To keep the methodology concrete, the series hunts one live operation the whole way down. Ghost Stadium is the FIFA World Cup 2026 ticket-phishing kit that Group-IB and CybelAngel attribute to a Chinese-speaking, financially motivated operator, and it has stood up thousands of lookalike domains ahead of the tournament. Each installment works it with that installment’s lens, then hands the next one a live node to carry forward. The capstone deliberately flips to a different adversary, to show the pivots do not care who they are aimed at.

Why free matters

A last word on the free rule, because it holds up everything else.

Paywalls do two kinds of damage. The obvious one is exclusion: small teams, students, nonprofits, and underfunded defenders get locked out. The quieter one is rot. Techniques only a handful of licensed analysts can run never get taught or pressure-tested, the community loses its ability to check the vendors’ work, and the shared skill base shrinks.

Free, community-run data behaves the opposite way. People share it, fork it, script against it, improve it. A couple of classic sources went commercial while this series was being written, and each time the community routed around the paywall and built something open. The way to protect that is to keep using it and teaching it, and to stop treating a purchase order as the price of entry.

So: pick up the queries and point the telescope the other way. The adversary’s infrastructure is already on the public record, and you already have what you need to find it.

Part 1 starts with the source that catches infrastructure before it is even live: Certificate Transparency.

Open Season is a recurring series from the THOR Collective exploring how practitioners can use open-source data to hunt adversary infrastructure. Each installment covers a single data source, soup to nuts. Want to contribute an installment or suggest a data source? Reach out.

Leave a comment

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

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

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

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

But that doesn’t last.

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

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

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

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

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

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

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

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

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

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

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

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

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

Leave a comment

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

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

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

What’s mappable

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

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

Tier 1 — Preparatory and pre-intrusion

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

⏱️ Episode Breakdown

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

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

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

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

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

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

• 33:56 – ⚡ Lightning Round

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

🎤 Hosts & Guest

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

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

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

• X: @bngrsec

• LinkedIn: mattbangert1

🔗 Resources & Mentions

On the Dispatch

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

Featured in This Episode

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

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

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

📢 Call to Action

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

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

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

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

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

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

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

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

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

📬 Connect with THOR Collective

🗣️ Social Media

• Twitter/X: @THOR_Collective

• LinkedIn: THOR Collective

• BlueSky: @thorcollective

📧 Contact

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

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

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

They shouldn’t. You should.

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

The Imposter Syndrome Trap Is a Specific Lie

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

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

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

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

That’s your workshop.

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

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

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

How to Scope a Workshop Topic

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

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

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

Scoping test:

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

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

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

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

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

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

The Format Is More Forgiving Than It Looks

The proposal is not a thesis defense.

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

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

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

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

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

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

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

The Community Is Better When More of Us Teach

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

That’s a loss for everyone in the room.

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

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

Before You Close This Tab

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

Quick-start checklist:

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

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

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

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

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

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

Your idea deserves a room. Give it one.

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

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

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

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

⏱️ Episode Breakdown

• 00:23 – Intro and welcome back from sabbatical

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

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

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

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

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

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

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

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

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

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

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

• 51:13 – ⚡ Myth or Signal rapid round

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

• 56:32 – Happy thrunting

🎤 Hosts & Guest

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

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

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

• LinkedIn: trentlo

• X: @surbo

🔗 Resources & Mentions

April Dispatch Posts

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

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

Mythos & Glasswing — Primary Sources

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

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

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

THOR Collective Tools & Frameworks

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

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

Other Mentions

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

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

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

📢 Call to Action

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

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

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

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

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

• Catch us on the conference circuit:

  • Lauren at the CrowdTour in New York

  • Trent at NCFTA Pittsburgh and Zenith

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

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

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

  • Everyone at Black Hat and DEF CON

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

📬 Connect with THOR Collective

🗣️ Social Media

• Twitter/X: @THOR_Collective

• LinkedIn: THOR Collective

• BlueSky: @thorcollective

📧 Contact

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

The Pattern

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

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

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

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

Understanding the Attack Chain

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

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

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

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

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

Each phase maps to a hunt below.

Hunt 1: Uncontrolled Third-Party OAuth Grants

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

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

What to Look For

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

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

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

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

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

Google Workspace

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

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

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

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

Microsoft Entra ID

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

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

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

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

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

The Deliverable

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

Vercel Case Reference

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

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

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

Hunt 2: Infostealer Exposure in Your Trust Chain

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

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

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

Your Own Exposure

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

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

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

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

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

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

Endpoint behavioral hunting (if you have EDR):

Key file paths to monitor for unauthorized access:

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

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

Hunt for:

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

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

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

Your Trust Chain Exposure

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

What you can do:

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

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

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

The Uncomfortable Truth

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

Hunt 3: Anomalous Third-Party Application Behavior

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

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

Behavioral Indicators

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

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

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

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

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

Google Workspace

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

Look for:

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

And via the Reports API:

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

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

Microsoft Entra ID

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

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

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

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

Building a Baseline

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

• What IP ranges do they normally authenticate from?

• What times of day do they make API calls?

• What resources do they typically access?

• What’s their normal API call volume?

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

Hunt 4: Trust Boundary Lateral Movement

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

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

Map the Blast Radius First

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

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

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

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

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

Detection Queries

SSO session correlation:

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

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

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

Secrets and environment variable access:

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

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

Email and cloud storage enumeration:

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

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

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

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

Hardening Against the Pattern

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

Reduce the trust surface (Phase 2 prevention):

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

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

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

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

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

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

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

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

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

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

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

Build resilience (detection and response):

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

• Baseline OAuth application behavior and alert on deviation.

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

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

Vercel/Context.ai IOCs

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

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

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

The Bigger Picture

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

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

Happy thrunting!

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

Leave a comment

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

Here’s what shipped.

What Can I Hunt?

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

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

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

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

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

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

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

Coverage Map

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

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

• Orange — ATT&CK technique

• Purple — Flame hunt (hypothesis-driven)

• Blue — Ember hunt (baselining/exploration)

• Amber — Alchemy hunt (model-assisted)

• Green — Data source

• Red (glowing) — Coverage gap

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

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

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

Context Graph

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

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

• Threat actors (red)

• Campaigns (amber)

• ATT&CK techniques (orange)

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

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

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

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

Putting it together

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

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

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

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

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

Try it

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

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

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

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

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

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

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

The Category Error That Won’t Die

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

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

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

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

Not so fast.

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

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

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

What Mythos Actually Changes

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

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

• credential abuse

• phishing

• supply chain compromise

• misconfigurations

Not zero-days.

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

That’s what we hunt.

Detection Was Already Losing

Signature-based detection was already losing.

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

Threat hunting exists because of that gap.

Mythos doesn’t break the model.

It validates it.

What Actually Scales

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

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

You’re asking:

• does this process tree make sense?

• does this auth pattern match baseline?

• why is this system talking to something new?

• who wrote to this directory?

None of that changes.

It just matters more.

The Real Problem: Memory

Most hunting programs don’t have memory.

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

That was already inefficient.

At Mythos scale, it’s a failure mode.

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

What Needs to Change

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

This week:

• Assess behavior coverage, not just data

• Baseline auth, DNS, service accounts

• Write your hunts down

This month:

• Use AI to accelerate, not replace

• Generate hypotheses and draft queries faster

• Add quality gates

This quarter:

• Start building agents for repeatable work

• CVE → hypothesis generation

• baseline → drift detection

• recommendations → tracking

Humans decide.

Agents scale.

HEARTH: The Receipts

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

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

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

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

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

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

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

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

But the model holds.

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

The Five Levels

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

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

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

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

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

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

Most teams should be targeting Level 2 right now.

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

It’s the difference between scaling and sinking.

The Bottom Line

Mythos didn’t change what threat hunting is.

It changed how fast we need to do it.

PEAK still works. Behavioral hunting still works.

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

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

Mythos didn’t change what threat hunting is.

It changed how fast we need to do it.

Happy thrunting!

Leave a comment

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

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

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

Here’s what the data said.

The Shape of the Noise

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

Two things jump out immediately:

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

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

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

What They’re Actually Hunting For

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

6. WordPress — 551 hits (7 days)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

10. Management Surfaces — Steady Background

Across the 16 days, Ialso saw consistent probing for:

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

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

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

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

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

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

The Scanner Ecosystem

Source Concentration

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

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

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

Scanner Dictionary Evolution

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

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

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

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

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

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

• Jan 11: GeoServer, OfficeScan fingerprinting

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

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

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

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

Defensive Takeaways

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

Quick wins (external attack surface):

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

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

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

Detection engineering targets:

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

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

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

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

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

Hunt hypotheses:

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

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

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

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

Methodology Notes

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

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

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

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

Happy thrunting. 🔥

Leave a comment

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

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

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

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

^Ctrl + C: Breaking the Loop

Stopping the Spiral Before It Stops You

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

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

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

chmod +x: Anticipating the Paralysis and Executing Accordingly

When You Don’t Know Where to Start:

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

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

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

When Imposter Syndrome Hits:

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

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

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

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

When Self-Doubt Creeps In:

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

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

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

The Moving Target Mindset

Remember the knowledge depreciation problem?

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

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

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

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

Spiral vs. Progress: Knowing the Difference

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

You’re in a productive learning spiral if:

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

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

• You’re uncomfortable but engaged, not existential.

You’re in a paralysis spiral if:

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

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

• The overwhelm is growing, not shrinking.

• You feel more confused than when you started.

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

Exit 0

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

And you’ll keep learning anyway.

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

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

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

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

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

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

Terminology

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

Prompting

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

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

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

Agents

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

SKILLS.md

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

Workflows

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

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

Assistants

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

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

Context Is Key

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

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

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

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

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

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

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

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

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

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

Back to the Basics

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

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

Personas -> Identities -> Personalities

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

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

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

Perspectives & Goals

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

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

Tools

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

• A local runner docker compose stack

• Guidelines on which tools to use:

  • use python not golang or js

  • Use python-fire for CLI, attrs models

  • Class and inheritance over utility functions, etc.

  • Use uv over poetry

  • Etc.

• Specific APIs with examples (Schema docs is preferred)

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

Documentation

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

Provide things like:

• API specifications

• JSONSchemas

• Repositories

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

• Provide examples of similar problems

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

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

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

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

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

Requirements

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

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

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

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

• Define business requirements

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

• Define gotchas

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

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

Advanced Example

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

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

Description

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

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

Tools

You have the following tools available to you:

• Golang

• gRPC & protobuf for inner service communications

• Use Postgres (using the ip4r extension)

  • Use pgbouncer for scalable queries

  • Ensure proper indexes are in place

• Cache results using Redis (rueidis client library)

• Use kubernetes and light weight images

• Setup monitoring and metrics throughout the pipeline using Prometheus

Documentation

The following are references to use:

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

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

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

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

What Not to do

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

Requirements

• Ensure the pipeline can handle 1 billion events per day

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

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

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

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

• Create indexes that use the ip4r data types for IPs

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

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

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

Peace

Leave a comment

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

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

The Vibes Problem

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

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

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

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

We need something better than vibes.

Coverage Criteria: Did You Actually Look?

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

This sounds obvious but it really isn’t.

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

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

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

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

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

Diminishing Returns: The Same False Positive Three Times

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

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

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

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

At this point you have three choices:

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

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

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

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

Time-Boxing vs. Completeness

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

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

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

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

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

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

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

The Confidence Spectrum

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

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

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

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

I think about this as a spectrum:

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

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

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

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

Documentation as Closure

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

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

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

At minimum, your hunt closure document should include:

• Hypothesis: What were you looking for and why?

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

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

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

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

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

• Time spent: How long did this actually take?

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

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

Where This Fits in PEAK

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

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

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

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

• What’s my time box?

• What confidence level am I targeting?

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

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

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

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

The Hunt Closure Checklist

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

Before You Close the Hunt

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

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

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

• [ ] Findings documented (including null findings)

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

• [ ] Follow-up recommendations and detection opportunities logged

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

Red Flags That You’re Stopping Too Early

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

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

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

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

Red Flags That You’ve Gone Too Long

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

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

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

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

  

Closing Thoughts

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

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

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

Happy thrunting!

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

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

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

How We Ended Up Here

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

1. Have a question about something

2. Research the answer

3. Intermission to go down multiple irrelevant rabbit holes

4. Find the answer to the original question

5. End up with 1000 new questions

6. Existential crisis

7. Repeat!

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

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

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

sudo whatdoichoose

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

Permission Denied: Why Paralysis Happens

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

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

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

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

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

The Knowledge Depreciation Problem

Why it Feels Like You’re Always Starting Over

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

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

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

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

It’s live now at pacmap.dev.

Why This Exists

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

That bothered me. So I built one.

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

What’s Inside

Here’s what you get when you visit:

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

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

The Builder’s Mindset

Here’s where the THOR Collective thread comes in.

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

PACMap is me doing exactly that.

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

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

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

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

For the Community

This is where the community part matters.

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

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

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

What’s Next

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

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

Go check it out: pacmap.dev

Leave a comment

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

📝 Episode Summary

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

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

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

⏱️ Episode Breakdown

• 00:01 – Intro and welcome to Season 2

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

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

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

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

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

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

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

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

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

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

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

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

• 43:00 – PAI voice scares

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

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

🎤 Hosts

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

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

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

🔗 Resources & Mentions

January 2026 Dispatch Posts

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

• Why You Should Build by Lauren Proehl

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

Tools & Resources Mentioned

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

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

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

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

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

• Prompt GTFO – community resource on cybersecurity and AI

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

Vulnerability Research & Bug Bounty

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

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

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

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

Key Concepts Discussed

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

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

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

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

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

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

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

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

Trends Discussed

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

• Browser extensions – emerging attack vector

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

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

• CVE reports up ~39-40% last year

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

• Prompt injection – social engineering AI agents and models

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

📢 Call to Action

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

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

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

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

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

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

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

📬 Connect with THOR Collective

🗣️ Social Media:

• Twitter/X: @THOR_Collective

• LinkedIn: THOR Collective

• BlueSky: @thorcollective

📧 Contact:

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

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

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

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

• providing a repository of code and giving clear problem statements

• question & answer analysis

• etc.

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

Role-Stacking: Set the Stage

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

Here’s an example:

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

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

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

For SOC analysts, this might look like:

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

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

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

Be Explicit About Your Technology Stack

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

Here’s how I do it:

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

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

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

For threat hunters, this might be:

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

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

Request Thoroughness Explicitly

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

I frequently use phrases like:

• “Take your time, think through carefully”

• “Use critical systems thinking”

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

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

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

Here’s an example:

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

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

Knowing all that, create an evaluation criteria process.

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

Ask for Current Information

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

Search for the latest information regarding security tools and products.

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

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

Think in Systems, Not Point Solutions

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

Here’s an example from my own work:

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

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

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

For SOC analysts dealing with alert volume, try:

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

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

Practical Tips for Getting Started

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

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

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

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

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

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

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

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

For example:

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

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

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

A Note on People

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

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

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

What’s Next

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

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

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

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

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

Enjoy!

Leave a comment