It's All Connected: Align and Validate Your Tactical and Strategic Intelligence
by thesilence | 2025-05-22
Introduction
Tracking, analyzing, and correlating threat activity is often performed at two distinct levels of focus:
Tactical or "zoomed in": identifying indicators of compromise (IOCs) and associating them with software and/or threat clusters.
Strategic or "zoomed out": high-level assessments about a cluster's goals, targeting, or tactics, techniques, and procedures (TTPs).
Public reporting reflects these approaches. A description of the latest threat activity focuses on IOCs, in contrast with a threat profile or trend report that summarizes activity.
Both perspectives have a place in cyber threat intelligence (CTI). Tactical reporting supports detection and alerting, and provides the basis for initial clustering of both threats and software. Strategic reporting is used to communicate key information about a threat, often to provide an overview or communicate risk to decision makers.
That said, in order for all stakeholders to make informed decisions and act on reliable intelligence, our tactical and strategic assessments need to align. In this blog we'll discuss how we can use Synapse to extrapolate strategic assessments from our tactical data, and ensure our strategic assessments are accurate and traceable to specific tactical evidence.
The Problem
Threat clustering starts from the ground up - we observe an attack or compromise, use the evidence collected to infer characteristics such as scope and motivation, and (eventually) attempt to identify those responsible. But those higher-level assessments should all start with observable evidence: tactical data that tells us what occurred, where it happened, and when it took place. These fundamental data points allow us to deduce the how (TTPs) and the why (goals and objectives). Our higher-level assessments should be directly grounded in these observables; but in practice, some common issues occur with this process.
Many organizations rely on or make use of third-party reporting (whether free or commercial). Threat reporting has improved over the years, expanding beyond simply reporting IOCs (hashes, FQDNs) to include additional useful information such as TTPs (e.g., MITRE ATT&CK techniques). Once identified and reported, individual IOCs are of limited use to threat actors, who readily abandon them for new ones. For this reason, TTPs can be more useful for detection and hunting - especially over time. For example, teams can search for log entries showing general evidence of privilege escalation as opposed to searching for specific hashes of known privilege escalation tools.
That said, a common drawback is that reports rarely "show their work" - does a reporting organization sufficiently justify their conclusions with supporting data? Without evidence, how can we trust their assessments are accurate? Let's take TTPs as an example. Most reports that include TTPs simply include a summary list of ATT&CK techniques used across whatever activity is described in the report, the same way they might include a summary list of IOCs. While this provides useful insight, a simple list is problematic for two reasons:
it does not associate the technique with the specific instance or example (evidence) of its use; and
it generally does not distinguish between techniques used by threat actors (operators) and techniques inherent to the software the actors just happen to use. This is an important distinction if:
a group's software use changes over time;
the use of certain software is mis-attributed to a group; or
you are attempting to track the developers of a tool (and their techniques!) separately from groups that may use the tool.
Tip
Vertex uses software generically to refer to any / all executable code leveraged by threat actors in their operations, whether "malware", utilities, scripts, applications, etc.
If we are clustering threat activity based on firsthand knowledge (visibility into our own organization, our customers, or our own primary research) we are in a much better position with respect to evidence, but there are still challenges. In particular, clustering is a fluid process. As we gather additional information we may re-evaluate earlier clustering assessments. Clusters also grow and merge over time. (This is why we use tags for tracking most clustering activity in Synapse; tags are flexible and easy to modify.) In short, as our assessments change and evolve, it's easy for our tactical data to change out from under our strategic assessments. As a result, our high-level profile of a threat gets out of sync with our evidence.
So why does this matter? Are we just worried about tidy record keeping?
As a simple example, let's say we initially assess that Vicious Wombat was responsible for a compromise where the attackers used the SHINYOBJECT backdoor. We create a profile for Vicious Wombat indicating that they use SHINYOBJECT software in their operations. Later, we revisit the activity and determine that two independent threats were present in the victim network at the same time, and that SHINYOBJECT was actually used by Angsty Rutabaga. If we fail to reconcile our updated evidence with our higher-level assessments or profiles, we (and anyone relying on our intelligence) may wrongly assume that if we find a SHINYOBJECT backdoor, Vicious Wombat is responsible and we should search for additional evidence of that group. Similarly, if we identify and need to investigate a new Angsty Rutabaga intrusion, we may miss critical evidence because we fail to search for the presence of SHINYOBJECT, since we mistakenly associate it with Vicious Wombat.
CTI, like all operational teams or departments, needs to provide value to our stakeholders. By classifying tools and clustering threat activity, we aim to improve the speed and effectiveness of detection and response. At the IOC level, categorizing (applying context to) indicators can tell us whether the file that triggered an alert is a known backdoor (we should worry) or a utility that has a legitimate purpose but may also be used maliciously (we should investigate further). At the TTP level, we gain an advantage by searching for "patterns" of activity that are more long-lived and harder to change than individual IOCs.
On an even broader scale, CTI uses our understanding of the goals and targeting associated with various adversaries to help decision makers assess organizational risk. Just as we waste time and energy when we hunt or respond based on unreliable or miscategorized IOCs or TTPs, the same occurs if we expend resources or encourage decision making based on inaccurate or outdated strategic assessments.
Using Synapse to Keep Things Tidy
The tactical and strategic aspects of CTI are inextricably linked, and equally important. So how can we do a better job of tracking them in general, and also ensure they remain accurate, up-to-date, and (most importantly) consistent?
Fortunately, Synapse allows us to do exactly this! Because both data and assessments are represented structurally, we can easily query Synapse to:
Identify the strategic behaviors of a threat cluster based on tactical evidence.
Trace strategic assertions to the observable evidence that supports them.
Consistency-check the data and assessments associated with a given threat cluster.
How it Works
In Synapse, we track and cluster tactical data by applying labels (tags) to objects (nodes) to record our assessments and provide context. Tags can annotate IOCs (files, hashes, FQDNs, x509 certificates…) as well as nodes representing threat activity (such as attacks, compromises, or campaigns).
At the strategic level, we can view and link information in Synapse using the Threat Intel Workflow or directly in the Research Tool. This higher-level information is represented structurally using lightweight (light) edges that link nodes representing objects such as threat clusters, software, techniques, or industries. This allows us to model "summary" information, such as software using certain techniques, or a threat cluster leveraging specific vulnerabilities.
While at first these tactical and strategic representations may appear to be independent and unrelated, they are directly linked through Synapse's data model. Many strategic elements in the model - such as threats (risk:threat) or techniques (ou:technique) - have a :tag property for the tag associated with that element. For example, we may use #cno.threat.sparkling_unicorn to annotate IOCs or activity nodes associated with ("attributed" to) the Sparkling Unicorn threat cluster. (You can read about some of the tags used by The Vertex Project here.)
By navigating between nodes that have tags, and the nodes (such as risk:threat) associated with those tags, we can easily pivot from tactical to strategic data (and vice versa) and ensure they are consistent.
To show how this works in practice, we'll use sample data related to the notional threat cluster "Sparkling Unicorn".
Practical Examples
Strategic assessments (profiles) related to a threat group or threat cluster typically include a core set of common elements, such as the software the cluster uses or the industries impacted by their activity. Each of these strategic elements can be structurally represented in Synapse. These relationships can be extrapolated directly from our tactical evidence, or traced back to the nodes that provide the evidence, depending on the "direction" in which we query the data.
We'll describe the ways that several of these elements are represented in Synapse, and then look closely at an example of how to use Storm to navigate between tactical and strategic elements and verify that they are internally consistent.
Threat Clusters and Software
If Sparkling Unicorn uses REDTREE malware, we should have nodes in Synapse representing REDTREE malware (such as a file:bytes node of a known REDTREE sample) that are also associated with ("attributed to") the Sparkling Unicorn threat cluster. That is, one or more nodes should have both tags (in this case, #cno.soft.redtree.mal and #cno.threat.sparkling_unicorn.own).
This is the tactical evidence we've observed that Sparkling Unicorn uses REDTREE malware. We can then represent this strategic assessment with a -(uses)> light edge:
risk:threat:org:name='sparkling unicorn' -(uses)> risk:tool:software
We can also view this relationship in the Threat Intel Workflow:
Threat Clusters (or Software) and Techniques
Techniques in Synapse (ou:technique nodes) represent specific methodologies used by threat actors (e.g., in their hands-on operations) or by software (e.g., in its communication protocols, persistence methods, or algorithms used). Many organizations simply use MITRE's ATT&CK framework to track and report techniques, and we can easily add the ATT&CK elements to Synapse using the Synapse MITRE ATT&CK Power-Up.
We can also create our own ou:technique nodes, either instead of or in addition to MITRE. This is important if we want to track behavior not covered by MITRE, or when MITRE's framework does not meet our needs. For example, MITRE lists Registry Run Keys / Startup Folder as one sub-technique under Boot or Logon Autostart Execution. Windows includes both user-specific and system-wide startup folders, as well as multiple registry keys that can be used to automatically execute software for persistence. Let's say we want to monitor the specific methods used in more detail - for example, tracking startup folder use separate from registry key use, or tracking use of the Run registry keys separate from the Explorer Shell Folders keys. This allows us to be more fine-grained in identifying and comparing activity. To do this, we can create our own set of ou:technique nodes (while still mapping them back to a MITRE "parent" if desired).
Let's say we create an ou:technique specifically for the use of the Windows SOFTWARE\Microsoft\Windows\CurrentVerson\Run registry key for persistence, and note that the :tag used to represent the technique is cno.ttp.persist.registry.run. We note the use of a technique by applying the technique's tag to the node(s) showing evidence of its use. The node will also have the tag of the relevant threat cluster or software we claim uses the technique.
There are various nodes that could represent evidence of using the Windows Run registry key for persistence. For example:
an
it:exec:reg:setnode showing a process setting theRunkey;a batch script (
file:bytesnode) containing a command to modify theRunkey (e.g.,reg add); ora command / command execution node (
it:cmdorit:exec:proc) with a command that modifies theRunkey.
Our evidence node(s) will have both the #cno.ttp.persist.registry.run tag and:
the software tag (e.g.,
#cno.soft.redtree.mal), if persistence was established via automated installation; orthe threat cluster tag (e.g.,
#cno.threat.sparkling_unicorn.own), if persistence was established by an operator running an interactive command or script.
At the strategic level, we represent software or a threat cluster leveraging a particular technique with a -(uses)> light edge:
risk:tool:software:soft:name=redtree -(uses)> ou:technique
When we use Synapse to represent techniques used by software separately from techniques used by threat actors (operators), we gain a key advantage. Namely, this allows us to easily remove that subset of techniques from a threat cluster if the cluster stops using the software (i.e., their TTPs change over time) or revised analysis indicates they never used the software in the first place. For reporting purposes, we can easily use Storm to create a combined list of techniques used by a threat cluster and the software they use:
risk:threat:org:name='sparkling unicorn'
tee { -(uses)> ou:technique } { -(uses)> risk:tool:software -(uses)> ou:technique } | uniq
Tip
If some nodes always exemplify a technique we want to track, we can use a trigger or cron job to automatically apply the relevant technique tag to those nodes.
For example, many threat actors use email messages (phishing) to entice users to install malware or provide sensitive information such as credentials. Let's say we use the tag #cno.ttp.phish.message to represent the use of phishing emails, and we assume that any email message (file:bytes) that we identify as malicious (#cno.mal) is some sort of phishing attempt.
We can write a trigger that fires when we apply a #cno.mal tag to a file:bytes node, checks if the file has a :mime property equal to message/rfc822, and adds the #cno.ttp.phish.message tag if so:
trigger.add tag:add --form file:bytes --tag cno.mal --query { +:mime=message/rfc822 [ +#cno.ttp.phish.message ] }
Threat Clusters and Vulnerabilities
Vulnerabilities in Synapse (risk:vuln nodes) represent a condition that can be leveraged to cause unintended or undesirable consequences, typically to further a threat actor's objectives. In CTI we often equate vulnerabilities with CVEs. But it is important to keep in mind that not all software/hardware vulnerabilities have an associated CVE, and things like "this building has a physical approach that is not covered by security cameras" or "thesilence will click on links to cat memes and can be tricked into installing malware" are also vulnerabilities. Just as with techniques, we can make use of vulnerabilities from sources such as NIST or CISA, and / or create our own vulnerabilities, depending on our analysis needs.
Similar to software and techniques, our tactical data should consist of one or more evidence nodes showing the attempted or successful use ("exploitation") of the vulnerability. The evidence will vary based on the vulnerability, but could include a log entry (it:log:event), HTTP request (inet:http:request), authentication attempt(s) (inet:service:login), etc. In the case of exploit code, the evidence may be a file:bytes node that represents the exploit source code, compiled exploit code, or malicious document. We apply the tag for the vulnerability (e.g., #cno.vuln.cve_2024_55591) to the node along with the tag for the software or cluster that leverages it.
At the strategic level, both threats and software make use of vulnerabilities (they don't "target" them), so are linked with a -(uses)> edge:
risk:threat:org:name='sparkling unicorn' -(uses)> risk:vuln
Using Storm to Validate our Data
Now that we've shown how Synapse represents the use of software, techniques, and vulnerabilities at both the tactical and strategic level, let's walk through how we can use Storm to pivot between these representations to extract valuable information and verify the consistency of our assertions.
For our example, we'll use the assertion that a particular threat cluster uses specific software. Recall that:
our tactical evidence consists of nodes tagged with both a threat cluster (
#cno.threat.sparkling_unicorn.ownor#cno.threat.sparkling_unicorn.use) and a malware family (#cno.soft.redtree.mal);the tagged nodes are linked to the
risk:threatandrisk:tool:softwarenodes via each node's:tagproperty; andthe strategic relationship is shown by linking the
risk:threatnode to eachrisk:tool:softwarenode via a-(uses)>light edge.
Tactical to Strategic
We can use our tactical evidence (tagged nodes) to identify the software used by Sparkling Unicorn:
risk:threat:org:name='sparkling unicorn' +:reporter:name=vertex :tag -> syn:tag -> * +#cno.soft.* -> #
uniq | +syn:tag^=cno.soft :up -> syn:tag | uniq | -> risk:tool:software:tag
Tip
This query assumes that we are modeling our data consistently, and every #cno.soft.* tag has an associated risk:tool:software node.
Here is the same query with comments added for clarity:
// Lift the risk:threat node for 'sparkling unicorn' reported by Vertex
risk:threat:org:name='sparkling unicorn' +:reporter:name=vertex
// Pivot from the threat cluster's tag to the associated syn:tag node
:tag -> syn:tag
// Pivot from the syn:tag node to any nodes with that tag
-> *
// Filter to those nodes *also* tagged with a software family / ecosystem
+#cno.soft.*
// Pivot from the tagged nodes to all of their unique syn:tag nodes
-> # | uniq |
// Filter to only syn:tag nodes that represent software families / ecosystems
+syn:tag^=cno.soft
// Pivot from the leaf tags to the "main" software tag (e.g., from cno.soft.redtree.mal to cno.soft.redtree)
:up -> syn:tag | uniq |
// Pivot from the "main" tags to the risk:tool:software nodes
-> risk:tool:software:tag
This gives us the set of risk:tool:software nodes used by Sparkling Unicorn, based on the evidence (tagged nodes) in Synapse - in other words, the software that should be linked to our Sparkling Unicorn risk:threat node via -(uses)> light edges.
Strategic to Tactical
Similarly, based on the software that Sparkling Unicorn uses (according to our cluster profile), we can pivot to the tagged nodes (e.g., IOCs) that support these assertions:
risk:threat:org:name='sparkling unicorn' +:reporter:name=vertex
$tag = :tag -(uses)> risk:tool:software :tag -> syn:tag -> * +#$tag
With comments:
// Lift the risk:threat node for 'sparkling unicorn' reported by Vertex
risk:threat:org:name='sparkling unicorn' +:reporter:name=vertex
// Capture the :tag value as a variable
$tag = :tag
// Navigate to the software used by this threat
-(uses)> risk:tool:software
// Pivot from the software nodes to their tags
:tag -> syn:tag
// Pivot from the tags to nodes with those tags
-> *
// Filter to tagged nodes (software) that are *also* tagged with the threat cluster tag
+#$tag
This gives us the evidence nodes demonstrating that Sparkling Unicorn -(uses)> a set of software (risk:tool:software nodes).
Validating our Data
These queries illustrate how we can pivot between tactical and strategic data. But so far they do not check that both aspects of our data are consistent with each other - that is, these queries do not highlight any discrepancies between our evidence and our assertions. We can modify our queries to do this.
Our original "tactical to strategic" query above pivots from tagged nodes to the associated software (risk:tool:software nodes) that should be linked to our threat cluster (risk:threat) with -(uses)> edges. We can add a subquery filter to verify that the links exist and show us any missing software that should be linked based on our query results, but is not (comments included for relevant additions to our original query):
risk:threat:org:name='sparkling unicorn' +:reporter:name=vertex
// Capture the guid of our risk:threat node as a variable
$threat = $node.value()
:tag -> syn:tag -> * +#cno.soft.* -> # | uniq | +syn:tag^=cno.soft :up -> syn:tag | uniq | -> risk:tool:software:tag
// Filter out any risk:tool:software node that has an existing 'uses' edge to our risk:threat
-{ <(uses)- risk:threat = $threat }
This query returns any risk:tool:software nodes that are not linked to our risk:threat via a -(uses)> edge, but should be, based on the tagged nodes in Synapse. This means we either need to double-check our tagged nodes (was something tagged incorrectly?) or add the missing edges. (If our query does not return any nodes, all of our software nodes are linked correctly!)
Based on the results of our query, we have tagged nodes associated with both Sparkling Unicorn and the Beacon and SHINYOBJECT software families, but we have failed to link the associated risk:tool:software nodes to the Sparkling Unicorn risk:threat:
Similarly, our "strategic to tactical" query pivots from software to any tagged nodes associated with both the software and our threat. It returns the nodes that are tagged, but does not let us know if we are missing any tagged nodes for software we claim Sparkling Unicorn uses.
Once again we can use a subquery filter to find any risk:tool:software nodes that we claim Sparkling Unicorn uses, but where we are missing the associated tactical evidence (relevant comments added):
risk:threat:org:name='sparkling unicorn' +:reporter:name=vertex
$tag = :tag -(uses)> risk:tool:software
// Filter out any risk:tool:software nodes that have existing evidence of their use by our threat cluster
-{ :tag -> syn:tag -> * +#$tag }
The query returns any risk:tool:software nodes that are linked to our risk:threat via -(uses)> light edges, but do not have any associated evidence (tagged nodes). Once again we need to review our data - did we forget to tag some relevant nodes? Or have we mistakenly stated that Sparkling Unicorn uses certain software, and we need to remove some edges? (As with the previous query, if no risk:tool:software nodes are returned, then our data is consistent!)
Based on the results of our query, we have indicated that Sparkling Unicorn uses Mimikatz, but we do not have any evidence (i.e., tagged nodes) to support this:
Note that in order to ensure our tactical and strategic data are fully consistent, we need to perform both validation queries.
Tip
Don't let the Storm intimidate you! Any useful Storm query can be saved and accessed on demand in a variety of ways, such as Node Actions or macros. Running the above checks can be as simple as right-clicking the risk:threat node you want to verify!
Of course, we can write similar Storm queries to verify the techniques or vulnerabilities used by a threat or piece of software, as each of these assessments has the same kind of relationship within Synapse as the software used by a threat.
Conclusion
Synapse's ability to record both tactical and strategic information about threat activity while clearly linking the two provides us with a powerful analytical tool. We can easily use Synapse to ensure that our strategic assessments remain in sync with (and are solidly based on) tactical evidence.
In this first of two blogs, we illustrated this process with several common relationships that are linked in Synapse via tagged nodes and the :tag property of another node, namely:
Threat clusters and the software they use.
Threat clusters (or software) and the techniques they use.
Threat clusters (or software) and the vulnerabilities they use.
In Part 2, we'll look at additional information that we commonly report on (or want to know about) with respect to threats, namely:
the industries or countries "targeted" by a threat; and
the goals or objectives of the threat.
The connections between the tactical and strategic data for these assessments are different from the ":tag property to tagged nodes" relationship we explored here. Stay tuned as we'll walk through the details of these additional relationships and show you how to use Storm to ensure they are consistent as well!
To learn more about Synapse, join our Slack community, check out our videos on YouTube, and follow us on Twitter.
