The very first goal I set when I even learned what CTI was, was to create intelligence and share it to help people. In my SANS class, I learned about The Citizen Lab in Canada and the FBI disrupting actors that ruin people's lives and all I could think is "yup, this is what I want to do!" But then I started the role and creating intelligence and it was all proprietary. A lot of the indicators or pivot points were sensitive and couldn't be shared.
Herein lies the problem with CTI as a career: the best stuff we write is internal. It's for our stakeholders, it has our org's name all over it, and it is NOT leaving the building. So when you're job hunting (especially for your FIRST CTI role), how do you show you have experience?
A portfolio! It's a handful of finished intel products YOU made yourself, from public sources, that you can hand to someone and say "this is how I think." (Scary right? Don't worry, they gave ME a job so you'll be perfectly fine!)
This post is the home base for a series. Each part builds one piece of a portfolio, and they all come from the same investigation, so by the end, you'll have an example of a connected body of work.
What Hiring Managers Are Actually Checking
Mandiant published a CTI Analyst Core Competencies Framework that breaks the job into four pillars:
- Problem Solving: critical thinking, research and analysis, investigative mindset
- Professional Effectiveness: communication, teamwork and emotional intelligence, business acumen
- Technical Literacy: enterprise IT networks, the cybersecurity ecosystem, who does what in a security org
- Cyber Threat Proficiency: drivers of offensive operations, threat concepts and frameworks, threat actors and TTPs
That's twelve competencies, and a good portfolio piece hits a bunch of them at once. When someone reads your sample, they're mostly looking for:
- Can you write a bottom line? Does the first paragraph tell me what happened, why I should care, and what to do about it? You may have found me on TikTok, so you KNOW how quickly people scroll if you're not engaging IMMEDIATELY. People (and especially leaders) want to know "why" ASAP.
- Do you know the difference between what you saw and what you think? Observed vs. inferred vs. unknown (yes, the same thing from the pivoting post). Saying "I'm not sure, here's why" is a skill and I'm sick of work cultures that assume saying that means weakness or incompetency, but that's a soapbox for another time. 😅
- Did you cite your sources? Every claim should trace back to something. Bonus points for noting when sources disagree.
- Do you use frameworks correctly? Make sure you're not just adding as many Technique numbers as possible. Mapping a technique to the observed behavior is what's valuable and actionable.
- Do you know who you're writing for? An exec and a SOC analyst glean very different things from the same report.
The Series
Part 1: The threat actor profile (operational, coming soon). Pick a well-reported group and let's build a profile: alias table, targeting, Diamond Model, TTPs, sources, jargon, more jargon, etc. Includes a lab to help you write your first draft. This is the piece you'll lean on when someone asks "what's a threat actor you've tracked, and how did you track them?"
Part 2: From one domain to the whole setup (tactical, coming soon). Take one domain tied to your group and pivot for real: certificate chains, SANs, certificate transparency logs on crt.sh, passive DNS, and server fingerprints like JARM and JA4X (JA4X is pretty new and I'm really excited about it). If you did the beginner pivoting post and the Pivot Hunt, you're already ahead of the game!
Part 3: Script it (tactical, coming soon). Write a small Python tool that automates the boring half of Part 2. It doesn't have to be fancy, it just has to work!
Part 4: The exec brief (strategic, coming soon). Turn Parts 1 and 2 into a one-pager for a made-up company's leadership. Bottom line first, no jargon you don't explain, and actionable recommendations at the end.
Part 5: Put an agent on it (coming soon). Add a model step to your Part 3 script, run it, and then write up where it was wrong. We'll get into what belongs in a script vs. a model vs. your own brain, what happens when it makes up ATT&CK IDs, and how to not leak data or get prompt-injected by the adversary's own content.
Want an extra? Pick one depending on the role you're going for:
- Detection-leaning role: take one technique from your profile and write a detection idea for it (a Sigma rule, a KQL query, or just plain English logic).
- Strategic role: a recurring roundup (weekly or monthly) on one topic, like ransomware in your sector.
Know the Systems You're Writing About
This one isn't a portfolio piece, but it comes up in CTI interviews a lot, so I'm putting it here. You'll get questions about security fundamentals, not just threat actors. If your profile says a group "abuses OAuth tokens to bypass MFA," expect a follow-up like "okay, how does that work?"
You don't need to be a sysadmin, but a few things I've found are beneficial to have a handle on:
- DNS: what happens when you look up a domain, and what registrars, nameservers, and records are (you'll need this for Part 2 anyway)
- TLS and certificates: what a certificate actually proves, what a chain is, and why certificate transparency logs exist
- Identity: how SSO, MFA, and session tokens work, and the usual ways people get around them (phishing, MFA fatigue, token theft, help desk social engineering)
- Where defenders see things: what EDR, firewall, proxy, and identity logs each capture, so your "what a defender would see" column is real
- Basic hardening: least privilege, patching, segmentation, logging. When you're making recommendations, it's important to know how it could impact the org both culturally and financially. As in, "everyone should have Yubikeys!" Ok... who's going to pay for that? :-p
Quick self-check: for every recommendation in your portfolio, could you explain how the control works and why it would have stopped (or caught) the behavior you described? If not, no worries! You can always go read more. The internet is endless and time is an illusion. nvm.
Where to Put It
Anywhere someone can click a link: a personal site, a GitHub repo with each piece as a README or PDF, LinkedIn articles, Medium. I'd pick one home and link everything else back to it. Then put that link on your resume and your LinkedIn, and bring it up in interviews ("I actually wrote a profile on that group, happy to send it").
Your Part 3 script should live on GitHub no matter what. Code people want to see code ESPECIALLY your mistakes! Not just a copy/paste repo of all completed, perfect, no commit projects. It's super important to share your real repo in order to get real feedback!
Ground Rules (Annoying Older Sibling Again)
- Nothing from your current or past employer. No internal data, no client names, no "anonymized" versions of real incidents. Even if you think it's scrubbed, don't do it.
- Cite, don't copy. It's tempting to just grab a paragraph from a great Prophet Security write up, but CTI thrives when YOU give YOUR unique perspective. Summarize, compare sources, and add your own assessment.
- Be careful with attribution. Use the names the sources use, show the alias table, and don't claim a link between groups that your sources don't support.
- Defang your IOCs.
evil[.]com,hxxps://. Nobody wants a live malicious link in your portfolio. - Passive only. Looking stuff up in crt.sh, passive DNS, and scan databases is fine. Poking at adversary infrastructure directly is generally not, unless you have a really good understanding of your homelab and what you're up against.
- Own every word. That goes double for anything an AI tool wrote for you. An interviewer will ask YOU about it, not your agent.
Mistakes I See (and Have Made)
If you are like me, you find rabbit holes and why actors chose specific infrastructure or naming conventions VERY interesting. Unfortunately, general security leadership typically does not. They do not want the 14 page report to see the Russian nesting doll of encoding. They want "Ok, how is this protecting us MORE than before this investigation and how can it help us prevent moving forward?" I've started making 3 drafts of everything: extremely tactical for fellow CTI nerds, operational for secops/seceng, and strategic for leaders +.
- The IOC dump. No one wants a list of 400 hashes with no context, because now you just gave someone 400 IOCs to look up and figure out if they should really block them
- Burying the bottom line. See above, a mistake I've made MANY A TIME.
- Being 100% sure about everything. Real intel has gaps. Name them. For real, you SHOULD have a section calling out what you could not confirm and why. And if you frame that well enough, that's how you get resources and all sorts of cool toys 😏
- Picking a group nobody's written about. Cool in theory, but you'll run out of sources fast and spend all your time guessing.
- Never finishing. Girl. Don't get me started on not finishing 😅 This is me. Always. "BUT I DIDN'T FIND OUT WHY THEY USED "375498" IN THE DOMAIN NAME! WHAT DOES IT MEAAANNN????" Michael Jordan meme: Stop it. Get help. lol but seriously, at some point, you HAVE to be done. Share it, people want to know and it has to be timely! You can ALWAYS update later.
Resources
- Curated Intelligence: CTI Fundamentals, a reading list on theory, frameworks, and analytic writing
- Curated Intelligence: The CTI Research Guide, for tracking your sources without losing your mind
- Mandiant CTI Analyst Core Competencies Framework
- Katie Nickels: Getting Started in Cyber Threat Intelligence
- MITRE ATT&CK Groups
Part 1 is coming soon! When you finish a piece, send it my way! I'd genuinely love to read it. Reach out