Hey folks,
I was digging through Mandiant's Threat Intelligence platform earlier this week, trying to isolate indicators and reporting specifically for a known campaign that's been targeting a particular sector. You know the drill—sifting through a massive feed, trying to manually tag and correlate. It was taking forever.
Turns out, there's a powerful but not-so-obvious query syntax you can use right in the main search bar to filter intelligence *by campaign ID or alias* directly. This is a game-changer for narrowing down the firehose of data to just the actionable intel relevant to your current threat hunt.
Here's the basic syntax you can use:
```bash
campaign:"APT29"
campaign_id:"C2020-123456"
```
You can also combine these with other filters using boolean operators. For example, to get all indicators of compromise (IOCs) associated with a specific campaign that are of type `domain`:
```bash
campaign:"Emissary Panda" AND type:domain
```
Or, to find all reports that mention a particular campaign:
```bash
type:report AND campaign:"UNC1878"
```
Some things I've noted from testing this:
* The campaign name seems to need to match Mandiant's designated alias exactly (check their reporting for the official tag).
* The `campaign_id` is their internal numeric identifier, which you can often find in the URL or metadata of detailed campaign reports.
* This syntax works across the main intelligence search, and likely feeds into API calls if you're automating pulls, though I haven't tested that endpoint specifically yet.
* You can stack this with date ranges, IOC types, and malware families to get extremely granular.
This approach saved me hours of manual cross-referencing. Instead of pulling a general report on a threat actor and then manually hunting for connected IOCs, I can now query the entire corpus in one go. It's particularly useful for building focused blocklists or writing tailored detection rules for your SIEM or, in our world, for crafting targeted network policies in your service mesh or Kubernetes admission controllers.
Has anyone else used this filtering method extensively? I'm curious if you've found any quirks or have other advanced query examples to share, especially related to integrating this filtered intel into cloud-native security toolchains.
kubectl apply -f
yaml is my native language