Hey everyone! 👋 I've been diving deep into our Mandiant Threat Intel feed for the past few months, and while the IOCs (IPs, domains, hashes) are relatively straightforward to ingest, I found the real gold—and the real challenge—was in operationalizing the **Tactics, Techniques, and Procedures (TTPs)** they report on. It's one thing to read about a new credential-dumping technique used by a threat actor; it's another to confidently answer: "Is this happening in *our* environment *right now*?"
So I embarked on a little project to systematically validate those reported TTPs against our own EDR and network logs. I wanted to share my walkthrough, both my method and some concrete outcomes, in case it helps anyone else trying to move from "cool intel" to "actionable detection."
**My goal was twofold:**
1. **Prove the value** of the intel subscription by finding traces of reported TTPs we might have missed.
2. **Tune our detection rules** to be more specific and less noisy, based on real-world examples from the intel reports.
**Here's the step-by-step process I followed:**
* **Step 1: TTP Extraction & Translation**
I started by picking a recent Mandiant report on a financially motivated group we're concerned about. Instead of just noting the MITRE ATT&CK codes (like T1059.001 for PowerShell), I broke down each TTP into **specific, loggable events**. For example, "Use of PowerShell for Discovery" became:
* Process creation: `powershell.exe`
* Command-line arguments containing specific keywords (`Get-Process`, `Get-Service`, `net localgroup`).
* Parent process context (was it spawned from `cmd.exe`, `outlook.exe`, etc.?).
* **Step 2: Log Source Mapping**
Next, I mapped those atomic events to our actual log sources. This is where it gets real!
* `powershell.exe` creation → Our EDR's process creation events (we use CrowdStrike).
* Specific command-line arguments → EDR's command-line logging (had to verify this was enabled for all hosts!).
* Network connections post-discovery → Our proxy and firewall logs.
* **Step 3: Building the Queries**
I then crafted detection queries in our SIEM (Splunk). The key was to combine the elements into a story. A simple example:
```
source="crowdstrike:process:creation" process_name="powershell.exe"
| search command_line="*Get-Process*" OR command_line="*net localgroup*"
| stats count earliest(_time) as first_seen latest(_time) as last_seen by parent_process_name, command_line, host_name
| where count > 5 // Looking for repeated, potentially automated activity
```
This is simplified, but you get the idea. I built a small library of these for the TTPs in the report.
* **Step 4: The Validation Run & Findings**
I ran these queries over a 30-day period. Here's what I found:
* **True Positive:** We *did* find sequences matching a "Windows Command Shell for Discovery" TTP. It was our internal red team! This was actually a great find—it validated the query worked and gave us a safe example to analyze.
* **Noise Reduction:** We found many, many instances of `powershell.exe` launches from standard admin tools (like SCCM). This allowed us to **add exclusions** to our production detection rules, making future alerts much more relevant.
* **A Gap Revealed:** One TTP involved detecting a specific registry key modification. We realized our current EDR logging level wasn't capturing that detail broadly. **Justifying an expanded logging policy** became a direct outcome of this validation.
**Pitfalls & Lessons Learned:**
* **Time-Consuming at First:** The initial setup—translating TTPs to queries—took the longest. But now I have a template, and it gets much faster.
* **Context is King:** Finding the TTP activity isn't enough. You *must* correlate it with other context (user, asset criticality, other suspicious activity) to avoid alert fatigue. A junior sysadmin running `net user` is very different from a service account doing it.
* **It's Iterative:** This isn't a one-and-done task. Every new report means updating or creating new queries.
For me, this exercise transformed how I view our threat intel feed. It's no longer a "check-the-box" subscription. By forcing myself to validate the TTPs, I'm now better at:
* Prioritizing which intel to focus on.
* Having concrete evidence for requesting logging enhancements.
* Building detection content that's pre-validated against our own environment's noise floor.
I'd love to hear from others! Have you tried something similar? What tools are you using to bridge the gap between reported TTPs and your internal logs? Any tips for managing the ongoing workload of keeping these detection rules updated?
test everything twice
Your focus on extracting and translating TTPs from the raw reports is the critical first bottleneck most teams underestimate. The abstraction layer between the MITRE ATT&CK framework terminology and the concrete, queryable events in your specific EDR and log sources is where projects stall.
I'd suggest building a small mapping table as part of this process, with columns for the MITRE Technique ID, the Mandiant description snippet, and most importantly, the corresponding telemetry sources and event IDs from your own platform. For example, their description of "Credential Dumping via LSASS" must translate to specific process access events with certain access rights in your CrowdStrike or Microsoft 365 Defender workspace. This table becomes a reusable artifact that accelerates future validation cycles and ensures you're not reinterpreting the TTP from scratch each time.
Without that structured translation, you risk building detections that are either too generic, generating alert fatigue, or too narrow, missing variants of the same technique.
—BJ
That extraction and mapping is the hardest part. We built a similar table internally, but we learned you have to treat it as code.
It's not just a spreadsheet. It's a YAML file in a git repo. Each TTP mapping includes the expected log source, the exact query or rule logic, and the specific version of the EDR agent it was validated against. When the agent updates and changes event IDs, the pipeline fails a validation check. Saves us from stale mappings.
Your step two, tuning detection rules based on the intel examples, is where it really pays off. We found our generic "suspicious process creation" alerts got a lot more precise after we started pulling command-line examples straight from the Mandiant reports into our rule logic.
—cp
That goal is spot on, especially tuning detection rules based on real-world examples. It's where the theoretical model of a TTP gets grounded in the messy reality of your logs.
One nuance we've seen is that pulling command-line examples directly into rules can sometimes make them too brittle, particularly with obfuscation. We've had better luck using the intel to build a profile of anomalous behavior rather than a strict signature. For instance, instead of just matching the exact `powershell.exe -enc` command from a report, we'll combine that with the parent process and the network connection that typically follows in the documented activity chain. It catches variations faster.
Treating the mapping as version-controlled code, like user1005 mentioned, was the logical next step for us too. It forced us to define the telemetry prerequisites for each detection, which exposed gaps in our logging coverage we needed to fix first.
Data is the source of truth.
Moving from exact command-line signatures to behavioral profiles is indeed the right evolution. The key challenge I've found isn't just building the profile, but managing the performance cost of correlating events from disparate sources, like process creation and network connections, in real time. This often pushes you into streaming aggregation or a detection engine that can handle stateful multi-event sequences.
Your point about exposing logging gaps is critical. We documented each TTP's required telemetry, and it frequently showed us that our assumed logging level was insufficient. For example, we might have process creation events, but not the detailed process access rights needed to confidently detect a specific LSASS technique without excessive false positives. That forced a conversation with the endpoint team about policy changes, which is a tangible outcome from this kind of validation work.
brianh