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.
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.
#cno.code.<name>
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?"
file:bytes#cno.code.industroyer
#cno.common
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
#cno.detect
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?"
inet:fqdn#cno.detect
#cno.infra
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?"
inet:server#cno.infra.anon.proxy
"What domains do we know of that belong to a Dynamic DNS provider?"
inet:fqdn#cno.infra.ddns
"What servers have we identified as representing an anonymizing VPN service?"
inet:server#cno.infra.anon.vpn
#cno.mal
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?"
inet:fqdn#cno.mal
"What are all the nodes that we've identified as malicious and within the GreyEnergy ecosystem?"
#cno.mal.greyenergy
#cno.threat
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?"
inet:email#cno.threat.papertrail.own
"What nodes are included in the ``#cno.threat.43d62bd7d979d42f2f6838dce9831cb8`` cluster?"
#cno.threat.43d62bd7d979d42f2f6838dce9831cb8
#cno.ttp
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?"
inet:fqdn#cno.ttp.se.masq
"What are all the phishing emails we've identified?"
inet:email:message#cno.ttp.phish
"What hijacked resources have we seen threat actors use?"
#cno.ttp.se.hijacked
#rep
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?"
inet:ipv4#rep.feye.apt1
"What files in our Synapse instance has VirusTotal reported as having a revoked certificate?"
file:bytes#rep.vt.revoked.cert
#vtx
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 (#vtx.tlp.red
).
"What are all the nodes associated with MDR ticket 2021-902?"
#vtx.mdr.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
.
Note
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:
Create or fork a new View and switch into it.
Click on the meatballs menu icon to the right of the Storm Query Bar... and select Import Nodes File(s).
Select the
.nodes
file and click Submit.
Run the
diff
command in your Query Bar to view the newly added nodes.
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:
nodes.import https://vertex.link/blogs/vtx-tag-trees/_downloads/56ef0894a38120777a19df6b199159cc/vtx_tag_trees.nodes
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.