STIX 2.1 is a structured way to model threat intelligence. Each piece of intelligence becomes a STIX object, and you connect those objects using relationships to explain how adversaries operate and how evidence fits together.
If you’re new to STIX, don’t worry—you don’t need to read the 50+ page spec to get started. This post gives you a practical, visual way to think about STIX so you can start building your first threat intelligence models today.
Examples of what is possible
Before we break down the parts, here’s what a real STIX “story” looks like when you connect threat intelligence properly. By the end of this post, you’ll be able to build graphs like these.
Mandiant: APT1
FireEye: Poison Ivy
The 5 object families (in plain English)
Everything in STIX 2.1 is made from just five families of objects. Once you understand these, you can model anything in cyber threat intel.
1. SDOs — STIX Domain Objects (the what and who)
SDOs describe concepts in threat intelligence — things you’d talk about in a report.
Examples:
| Object Type | Example | Meaning |
|---|---|---|
threat-actor |
APT29 | A known adversary |
malware |
Cobalt Strike | A malware/tool |
campaign |
SolarWinds breach | Linked activity over time |
infrastructure |
Phishing server | Resources used by an actor |
vulnerability |
CVE-2024-12345 | A weakness being exploited |
Use SDOs to describe entities and behaviors in your analysis.
2. SCOs — STIX Cyber-observable Objects (the evidence)
SCOs are digital fingerprints collected from logs, sensors, and telemetry.
Examples:
| Object Type | Example | Meaning |
|---|---|---|
ipv4-addr |
185.199.110.153 | An IP observed |
domain-name |
evil-update.biz | Suspicious domain |
file |
SHA256 hash | File on disk |
url |
http://bad.site/payload.exe | Malicious link |
Think of SCOs as raw evidence. They don’t tell you who or why — only what was seen.
3. SROs — STIX Relationship Objects (the connections)
SROs are what turn isolated objects into intelligence by describing how things relate.
They connect SDOs to SDOs, SDOs to SCOs, and sometimes SCOs to SCOs.
Examples:
| Source Object (from) | Relationship Type | Target Object (to) | Meaning |
|---|---|---|---|
threat-actor |
uses |
malware |
APT29 uses Cobalt Strike |
campaign |
attributed-to |
threat-actor |
Operation Aurora linked to APT17 |
malware |
communicates-with |
ipv4-addr |
Malware beaconing to 45.77.89.10 |
indicator |
indicates |
malware |
Hash detected → suggests malware infection |
threat-actor |
targets |
identity |
Actor targets a bank or company |
tool |
drops |
file |
Tool leaves behind a payload |
vulnerability |
exploited-by |
malware |
Log4Shell exploited by botnet |
infrastructure |
hosts |
domain-name |
C2 server hosts malicious domain |
file (SCO) |
drops |
file (SCO) |
A file extracts another file |
4. SMOs — STIX Meta Objects (the supporting layer)
SMOs don’t describe threats — they describe the data itself (like who created it, how it’s shared, or how it’s structured).
Examples:
| SMO Type | Purpose |
|---|---|
marking-definition |
Add TLP (sharing rules) |
extension-definition |
Add custom fields |
language-content |
Translate content |
If you need to mark, extend, or annotate objects — SMOs are how.
5. SBO — STIX Bundle Objects (the container)
Once all objects and relationships are assembled, they are grouped into a Bundle — a STIX container designed for sharing, storing, and exchanging threat intelligence.
A STIX Bundle:
- Has no meaning on its own — it’s just a transport wrapper
- Contains all SDOs, SCOs, SROs, and SMOs linked together
- Can be visualized or parsed by TI platforms (like OpenCTI, MISP, ATT&CK Navigator, etc.)
That’s exactly what you saw earlier with the APT1 graph — it’s simply a Bundle rendered as a graph.
Building a STIX intelligence model step by step (real-world example)
Let’s walk through a simple but realistic threat intelligence scenario and model it using STIX the right way.
Scenario: During an investigation, you detect a new malware sample communicating with a suspicious IP. Further research links it to a known threat actor.
Step 1: Start with what you discovered (SCO)
The first thing you usually find in an investigation is technical evidence. That means SCOs.
| Object Type | Example Value | Why it’s an SCO |
|---|---|---|
file |
SHA256 hash of a malware sample | Observable fact |
ipv4-addr |
45.77.23.10 | Observable fact |
url |
hxxp://update-check[.]biz/payload.exe | Observable fact |
At this point, you’re just collecting evidence, not making judgments.
Step 2: Identify what it is (SDO)
Next, you identify this as malware. Now it becomes intelligence, so you create an SDO.
| Object Type | Example | Why |
|---|---|---|
malware |
“FrostByte” | You’ve classified the behavior |
indicator |
pattern for hash/IP | To help detect it again |
Now your STIX model begins to explain meaning, not just record artifacts.
Step 3: Add relationships (SRO)
Now link what you know using relationships (SROs).
| Relationship type | Source → Target | Meaning |
|---|---|---|
communicates-with |
malware → ipv4-addr | Malware calls home to this IP |
downloads |
malware → url | Malware retrieved from URL |
based-on |
indicator → file | Detection comes from malware hash |
This is where raw data becomes connected intelligence.
Relationship types come from STIX guidance
The STIX spec recommends common relationships so producers use consistent language. For example, the Attack Pattern SDO can use relationships like:
| Source (SDO) | Relationship type | Target (SDO) |
|---|---|---|
attack-pattern |
delivers | malware |
attack-pattern |
targets | vulnerability |
These are guidelines — you can still create your own relationship types if needed. When in doubt, use a generic relationship type:
| Generic type | Use case |
|---|---|
related-to |
When unsure of exact relationship |
duplicate-of |
Same object appears twice |
derived-from |
One object was created from another |
Embedded relationships vs SROs
Some relationships are built inside objects using properties like _ref or _refs. These are called embedded relationships.
Example: Every SDO has a created_by_ref, which points to an Identity SDO. You don’t need a separate SRO for that — it’s built into the object.
| Type of link | Example STIX field | When used |
|---|---|---|
| Embedded relationship | created_by_ref |
Always applies, defined by the spec |
| SRO relationship | uses, targets, etc. |
Analyst-defined connections |
Rule of thumb:
- Use embedded relationships when defined by the spec.
- Use SROs to express analyst insights.
Sighting relationships (special SRO)
Sighting objects express that someone actually saw something malicious.
| Property | Meaning |
|---|---|
sighting_of_ref |
What was seen (e.g. malware, threat-actor) |
where_sighted_refs |
Who saw it (e.g. company, sensor source) |
observed_data_refs |
Evidence behind the sighting |
first_seen / last_seen |
When it was seen |
Sightings are what turn theory into field intelligence.
Step 4: Enrich context (more SDOs)
You dig deeper and discover this malware is being used by a known threat actor in phishing campaigns.
| Object Type | Example | Purpose |
|---|---|---|
threat-actor |
“ArcticFox” | Attribution |
campaign |
“Winter Wolf” | TTP grouping |
infrastructure |
VPS server hosting malware | Attack staging |
Now your model explains who, how, and why, not just what.
Step 5: Add metadata (SMOs)
Before sharing, you mark and document your intelligence using SMOs.
| SMO Type | Example |
|---|---|
marking-definition |
TLP:AMBER |
Marking Definition objects are a good example of how embedded relationships work. SDOs contain an object_marking_refs property, which can include a TLP Marking Definition object.
Step 6: Package everything (SBO)
Your final product is a STIX Bundle that includes:
- SDOs (malware, threat actor, campaign)
- SCOs (IP, file hash, URL)
- SROs (relationships)
- SMOs (TLP markings)
This is now shareable threat intelligence.
Where to go from here
If you’ve made it this far — well done. You now understand:
- The five STIX object families
- The difference between evidence (SCO) and intelligence (SDO)
- How to connect objects with relationships (SRO)
- How to add metadata and control sharing with SMOs
- How to package intel inside a Bundle (SBO)
This is enough to read and understand any STIX dataset you come across — and more importantly, you now have the mental model to start producing your own STIX intelligence.
But this is just the foundation. In the next posts, we’ll go deeper into the parts that matter in real workflows:
- Generate STIX with Python
- Store and query STIX using memory, local storage, and databases
- Extend STIX cleanly with custom objects and fields
- Build real-world intel models using reusable templates and patterns
Stixify
Your automated threat intelligence analyst. Extract machine readable STIX 2.1 data ready for use with your security stack.
Discuss this post
Head on over to the dogesec community to discuss this post.
Never miss an update
Sign up to receive new articles in your inbox as they published.