Vertex Tag Tree Overview

by a Vertex Analyst | 2023/03/07

At The Vertex Project, Synapse users commonly ask us to help them develop and provide feedback on their internal tag tree structure. We frequently field questions like, “What is the best way to structure our tag trees?” and even “Can you share a subset of your internal tag trees?” In this blog, we’ll walk through a subset of the tag trees that we use and share them for you to optionally import into your own Synapse instance.

Synapse Tags and Tag Trees

Before we delve into our tag tree use cases and structure, let's talk about tags, and why they are important to analytical workflows in Synapse.

Tags are Synapse elements that allow analysts to annotate nodes and concisely record analytical conclusions inline with data elements. Tags are critical to analysis workflows because they not only enable analysts to contextualize data, but they also facilitate data operations in the graph (e.g., lift, filter). They allow analysts to:

  • structurally represent and capture analyst assertions,

  • uniformly contextualize data and interpret assessments across teams, and

  • programmatically interact with nodes during enrichment, analysis, and intelligence production.

In Synapse, tags are organized into hierarchical structures known as tag trees. Creating tags within a hierarchical construct allows analysts to group assessments into analytically relevant namespaces (e.g., computer network operations, business, etc.), scope assertions by topic or discipline, and contextualize and interact with data using varying levels of abstraction.

In the Design Concepts - Analytical Model section of the Synapse documentation, we cover tag hierarchy design theory and highlight the core concepts that one should consider when constructing tag trees. We highly recommend reading up on our tag tree documentation to help design tags that best fit your organization’s needs.

Once you've begun creating tags within Synapse, you will be able to use the Tag Tree Explorer, located in the Help Tool, to easily view and manage your tag trees and their associated documentation.

The Vertex Threat Intelligence Taxonomy

To help threat intelligence analysts get started, we are sharing a subset of our production threat intelligence and public reporting tag trees, which we use internally to track, classify, and identify cyber activity. Specifically, we use the CNO tag tree to track and cluster assessments related to computer network operations (CNO) data including threat groups, code families, malware families, threat actor TTPs, and indicator categories, among other types of data.


The #cno.code.<name> tag tree is the top level tag tree that Vertex analysts use to identify a code family (appending the name of the associated code family to the tag). This tag tree does not denote maliciousness - analysts can create code families to categorize and group code samples, including those contributing to benign pieces of software. Additionally, while a malware family generally extends to include various parts of the malware’s ecosystem, a code family is more granular as it is specific to a certain code sample. As such, every module in an entire exploit framework would have its own code family.

"Have we identified any samples of the Industroyer code family in our Synapse instance?"



The #cno.common tag tree is the top level tag tree that Vertex analysts use to denote a CNO-related indicator or activity that is so commonly encountered that it is unlikely to be analytically relevant (e.g., the empty file or its associated hashes). Analysts may use this tag to identify sandbox artifacts, for example, so that future analysts will not spend time pursuing that particular path of inquiry. Another candidate for this tag tree could be a benign domain frequently seen in DNS requests. Tagging that domain with #cno.common will alert future analysts to ignore that domain and not spend time investigating whether or not it is a potential command and control server.

"What indicators did we identify during this engagement (excluding those that are so common that they are unlikely to be analytically relevant)?"

#vtx.mdr.2021.023 -#cno.common


The #cno.detect tag tree is the top level tag tree that Vertex analysts use to identify nodes representing malicious indicators that should be detected by security software/appliances. This tag tree is an efficient way for analysts to lift nodes and export indicators to security software/appliances for detection. Using a tag tree with its own namespace allows analysts to adjust what indicators are detected without impacting assessment-related tags (for example, analysts may only want to detect a subset of nodes tagged within Synapse as malicious).

"What domains have we determined that our security appliances should detect?"



The #cno.infra tag tree is the top level tag tree that Vertex analysts use to identify assessments regarding infrastructure, such as sinkholes, anonymization services, and Dynamic DNS (DDNS) domains.

"What sinkholes do we know of that were active between December 2021 and March 2022?"

#cno.infra.dns.sink.hole=(20211201, 20220301)

"What servers have we identified as part of an anonymous proxy service?"


"What domains do we know of that belong to a Dynamic DNS provider?"


"What servers have we identified as representing an anonymizing VPN service?"



The #cno.mal tag tree represents Vertex's assessment that a node is malicious, and in some cases, part of a particular malware family's ecosystem. A Vertex analyst can also append the name of the associated malware family if known.

Besides identifying a node as malicious, this tag tree also differs from #cno.code in that it allows for less granular assessments, given that it is not restricted to specific code families. For example, a Vertex analyst researching activity associated with a malware family named “RedTree” can use the #cno.mal.redtree tag to keep track of all nodes representing malicious indicators within the RedTree ecosystem, even if RedTree might comprise multiple different code families.

"What are all the domains that we've tagged as malicious within our Synapse instance?"


"What are all the nodes that we've identified as malicious and within the GreyEnergy ecosystem?"



When a Vertex analyst identifies a threat cluster, they will tag the related nodes using the #cno.threat tag tree and a randomly-generated GUID. Analysts may continue to build out clusters and eventually graduate them into a named cluster (i.e. #cno.threat.sunbeam), which can be easier to reference in reporting and presentations.

A threat cluster typically involves several variations of this tag:

  • #cno.threat.<guid>.seed - denotes the starting node, or origin of the threat cluster. Knowing where to find the starting point or original node of a cluster can be helpful for analysts checking their work and verifying that they have clustered the activity correctly.

  • #cno.threat.<guid>.own - applied to nodes that we assess are controlled by the operators

  • #cno.threat.<guid>.use - represents resources that are only used by/not unique to the operators

"What email addresses do we associate with the Papertrail threat cluster?"


"What nodes are included in the ``#cno.threat.43d62bd7d979d42f2f6838dce9831cb8`` cluster?"



Vertex analysts use the #cno.ttp tag tree to identify nodes that represent certain threat actor tactics, techniques, and procedures. These may include things such as the use of actor-controlled resources designed to imitate those of legitimate (benign) resources, incorporating operational security behaviors into their operations, hijacking legitimate resources for use in malicious activities, and relying on dead drop command and control infrastructure, among others.

"What are all the domains we know of that masquerade as legitimate domains?"

"What are all the phishing emails we've identified?"


"What hijacked resources have we seen threat actors use?"


The #rep tag tree records third party assessments and helps provide Vertex analysts with context about the nodes on which they appear. Analysts can use this context to inform their research and analysis.

"What are all the IPv4 addresses we know of that FireEye has attributed to APT1?"


"What files in our Synapse instance has VirusTotal reported as having a revoked certificate?"



Vertex analysts use the #vtx tag tree to keep track of internal research (#vtx.story.<name>), tasks (#vtx.mdr.<####> where "mdr" is the name of a specific project), or data sharing restrictions (

"What are all the nodes associated with MDR ticket 2021-902?"


Ingesting Our Tag Trees

We’re sharing a subset of our above-mentioned tag trees in a .nodes file that we’ve exported from our Synapse production instance. You can download the .nodes file here.


If you are importing these tags into your production Cortex, we recommend that you import them into a separate View to distinguish our internal tags from your production tags, and to prevent any potential name collisions.

To import the tags into your Synapse instance:

  1. Create or fork a new View and switch into it.

_images/fork.webp _images/fork2.webp
  1. Click on the meatballs menu icon to the right of the Storm Query Bar... and select Import Nodes File(s).

  1. Select the .nodes file and click Submit.

  1. Run the diff command in your Query Bar to view the newly added nodes.

  1. Review the imported nodes, and if you're happy with them, merge your forked View down into your Production View.


Alternatively, if you are using the CLI, execute the following command:


We hope that this blog provided a useful example of how we at The Vertex Project approach tag trees for our internal Synapse instance. While we're happy to share a subset of our tag trees, keep in mind that tag trees are not one size fits all - use what works for you and what questions you want to be able to answer with your analysis.

To learn more about tag trees and Synapse, please join our community Slack channel , follow us on Twitter , and take a look at our videos on YouTube.