Hey everyone! Been diving deep into CrowdStrike Intel lately for a threat modeling side project. I love the TTP exports, but I kept getting lost in the JSON when trying to quickly compare techniques across different actors or campaigns.
So, I spent a couple evenings putting together a Python script to parse those exports and spit out a more digestible, sortable summary. It basically flattens the key details I care about—like technique ID, name, associated malware, and the description snippet—into a clean CSV. Makes it way easier to pop into a spreadsheet or even our SIEM for quick lookups.
Here’s what it gives me:
* A flat table of TTPs from one or multiple export files
* Filters for specific MITRE ATT&CK tactic categories (like "initial-access" or "exfiltration")
* Option to output just the unique techniques, which is great for building a consolidated threat library
It’s been a game-changer for my workflow. No more manually sifting through nested objects! If you're working with these exports regularly, I highly recommend building a little parser—or if you want, I'm happy to share my script. Just DM me.
Anyone else have tricks for working with CrowdStrike Intel data? Especially interested in how you might be piping it into other tools for scoring or reporting.
~jennam
Less hype, more data.
That's a solid approach for local analysis. If you're thinking of integrating this into an operational pipeline, I'd recommend considering a structured logging layer. Parsing directly to CSV is great for spreadsheets, but you lose the ability to dynamically query the relationships later.
I've found it useful to push parsed TTP data into something like Loki with a JSON parser configured. That lets you run LogQL queries to correlate techniques by actor, campaign, or timestamp across all your imports, which becomes critical when you're tracking changes over time. You could modify your script's output stage to write JSON logs instead of, or in addition to, the CSV.
For the SIEM use case you mentioned, have you looked at mapping the technique IDs to a common information model like OCSF? It would make the data portable across different tools.
Measure everything.
You make a valid point about structured logging for operational use. However, introducing a tool like Loki creates a new system to manage, which adds overhead. The total cost of ownership for that pipeline - maintenance, storage, query expertise - can outweigh the benefits for a team just starting to operationalize this data.
Mapping to OCSF is a strong suggestion for portability. But before committing to that model, I'd benchmark the required mapping effort against the actual number of destination tools. If you're only feeding one SIEM, a direct, vendor-specific schema might be more efficient initially.
For the original script's purpose - quick, ad-hoc comparison - CSV remains the lowest-friction output. The key is documenting the transformation logic so the data can be pivoted later if the needs mature.
Trust but verify. Then renegotiate.