Diamond Model of Intrusion Analysis


Why Build Apps in ThreatConnect

Why Build Apps and Share them in ThreatConnect’s TC Exchange™ – Collaborate to Strengthen Your Threat Intelligence Practice
If you’ve spoken with anyone here at ThreatConnect, you may have noticed that we, and many of our customers are all pretty excited about the launch of ThreatConnect’s TC Exchange™.



I thought it would be a good idea to explain why we are buzzing about TC Exchange, and its ability to strengthen your threat intelligence practice by building custom applications for data ingestion and processing, workflows and analysis.  

Screen Shot 2015-08-24 at 3.41.22 PM


                                                                                        WHY ARE WE EXCITED ABOUT TC EXCHANGE?

TC Exchange empowers our users to customize ThreatConnect in a variety of ways, allowing them to build a stronger threat intelligence practice. We’ve built an application runtime environment and released associated SDK’s that allow our users to install, schedule and run applications that integrate with our already powerful API 


So what’s new here? Before TC Exchange, integrations were either hard coded in the platform and not easily configurable by the users or, if using the API, they always had to be run and configured on a separate server running programming language such as Python. Now installed applications can be configured easily from the ThreatConnect UI without having to tweak the integration code. This is a very powerful capability that allows integrations to be ‘plug ‘n play.’


A commercial Threat Intelligence Platform should be completely customizable to specific intelligence needs and processes, and we’re giving our customers the ability to do just that. However, what excites us the most is what this underlying technology will allow us to do for our customers with the TC Exchange.


                                                                                HOW CAN TC EXCHANGE HELP MY THREAT INTELLIGENCE PRACTICE?

The TC Exchange gives our users the ability to download applications, whether built by our team, a partner, or another user, and run them in their own instance of ThreatConnect. In the public cloud instance, subscribing customers can run jobs for available apps in the TC Exchange. This means that users can build customized apps for a variety of purposes and can choose to share those apps in our cloud based exchange for others to use. Beyond simply sharing indicators or tailored intelligence, TC Exchange provides the ability to community-source applications and tools, allowing users to share efficient processes with each other.


“That’s great,” you say. “But what does this mean to me?”


Let me flesh this out a bit more by describing what applications in ThreatConnect can do.



normalmizeddata (1)

Apps in ThreatConnect can be used for traditional integrations such as ingesting structured and unstructured intelligence and integrating with defensive products.  For those with more mature processes, you can also enrich indicators from various reputation services, push malware to one of our many automated malware analysis partners, or create customized ratings based on intelligence you’re receiving or on your own past incidents. These apps can be chained together to complete an entire workflow from discovery to detection.



Allow me to give you an example of an end-to-end workflow we can enable. Let’s say a customer is using ThreatConnect to store malicious files associated to known threats that they have dealt with in the past. Using an application running in ThreatConnect, the malware is automatically queued for analysis in ThreatGrid. The analysis is returned and parsed in ThreatConnect, including related callout domains and IP addresses. A second application now kicks in based on the thresholds set for the indicators derived from the analysis. If there is enough confidence that the new indicators are evil, they are sent to the SIEM for alerting or even to a Firewall or OpenDNS Umbrella for blocking. The configuration of the malware analysis returned and the thresholds for sending derived indicators for alerting or blocking are all set by the user from within ThreatConnect. Many of these apps will be available from us or our partners in TC Exchange for you to leverage in the public cloud or in your private instance.




However, you might wish to build your own or tweak existing applications. There are several reasons why you may want to do this. For instance:

  • If you have a custom, closed source of intelligence you want to ingest into ThreatConnect.
  • You may track adversary relevance in ThreatConnect based on a set of custom attributes and wish to automatically update those attributes based on incidents they are newly associated with.
  • You can chain multiple existing apps together and create custom triggers between them.

For processing intelligence with our API, what you can do with an app is limited only by your creativity. We support you with a growing library of open sourced applications for you to tweak to your needs. With our fully supported and documented Java and Python SDK, a Sandbox instance of ThreatConnect to build and test against, and support from our team with questions and troubleshooting as you go, we ensure you can easily customize ThreatConnect to your needs for ingestion, processing, analysis, and action on threat intelligence.

TC-Icons-Sandbox-DarkIf you’ve built an application for processing intelligence, chances are others can benefit from it too. Developers are encouraged to share their code within the TC Exchange, get some kudos from their peers, and help others make intelligence-informed decisions about their security posture. All apps can be submitted by users to ThreatConnect. Once the app makes it through our thorough code and security review, we’ll make it available for download to other users and if applicable to be run in the ThreatConnect Public Cloud.


Not yet a customer you say?


No problem! We are opening up Developer Accounts for the purpose of developing custom applications for the ThreatConnect platform. If you have a great idea for an app, and are serious about building it, contact us at exchange@threatconnect.com.


We’re holding a contest for you to put our app development team to the test. Our Best App Idea Contest runs from august 24th through October 16th. Read more here to learn more about the contest and rules. Users can send their ideas for the best app, the winner will get a free year’s subscription to ThreatConnect and best of all we’ll build that application for you!


There should no longer be a question of whether or not a commercial TIP can do what you need it to do. We’ve built ThreatConnect to be extensible to the needs of mature Fortune 500 & government security teams, as well as those just getting started with utilizing threat intelligence. The TC Exchange and application runtime environment are just the evolution of the trail we began blazing two years ago. We have not put our machete’s away yet.


Learn More About the App Idea Contest!

Learn More About TC Exchange!

Luke in the Sky with Diamonds


Applying the Diamond Model for Threat Intelligence to the Star Wars’ Battle of Yavin

Alternate titles:

  • “Diamonds are a Sith’s best friend”
  • “I used to Bullseye Womp Rats in my t-shirt back home.”
  • “I’m on a diplomatic mission to DEF CON.”
  • “That’s no Shamoon…it’s a space station attack!

Those of you who know me are aware that I’m a wee bit of a Star Wars fan. And if you’re unfortunate enough to be in that circle, you’ll also know that I tend to geek out on deconstructing security incidents. As one would assume, these two passions rarely have the chance to meet. The 2014 Data Breach Investigations Report was one such blessed opportunity (see if you can count the SW refs), and the other came along recently in a most unexpected form.

At some point in the event planning leading up to Black Hat, our marketing department came up with the great idea to create Star Wars themed t-shirts for our 3rd annual BH/DC bash. Someone further refined that idea to incorporate the Diamond Model for Intrusion Analysis on the back, which made it an insanely great idea and kicked off a spontaneous multi-day nerdfest in our little office. I have pictures, but since the Internet never forgets, I won’t share them to spare the dignity of those involved.

The Diamond Model is an approach to conducting intelligence on network intrusion events. The model gets its name (and shape) from the four core interconnected elements that comprise any event – adversary, infrastructure, capability, and victim. Thus, analyzing security incidents (or intrusions/activity threads/campaigns/etc) essentially involves piecing together “the Diamond” using bits of information collected about these four facets to understand the threat in its full and proper context.

Screen Shot 2015-08-13 at 4.46.01 PMStar Wars provides a wealth of incidents for study – in fact, the entire story of Episode 4: A New Hope centers around the response to and consequences of a data breach. The climactic event in the movie, however, is of course the destruction of the first Death Star. Watching the movie with your cyber-goggles on grants a different perspective and raises many interesting questions. Why didn’t Vader recognize R2-D2 as the likely storage mechanism for the stolen plans? Why did the response team descend into bickering over ancient religions and eventual force-choking rather than dealing rationally and cooperatively with the situation? If they were such a critical external-facing vulnerability, why weren’t the Death Star’s exhaust ports better protected? That last one is the thread we decided to pull on and weave into the best con t-shirt this side of the galaxy.

It isn’t hard to imagine that if the Emperor had known Luke could bullseye womp rats in his T-16 back home on Tatooine, he might have surmised that he could also nail small exhaust ports from his much more capable X-Wing with the help of the Force. But he apparently didn’t know that, which constitutes a major intelligence failure on behalf of the Empire that turned the tide of the war. The Empire would strike back, of course, but the inevitable return of the Jedi was set in motion. Had the Diamond Model been invented a long time ago in a galaxy far, far away, the outcome might have been different.


The graphic on the back of the t-shirt shows what the Empire could have reasonably known by assimilating the intelligence available to it at the time. The name of the incident underscores one of the pesky difficulties of incident analysis – dating. All we know of the earth-date of the incident is that it occurred “a long time ago.” We could go with the date of 0 BBY based on the Galactic Standard Calendar, but that has no relevance to earthlings. Thus, we’ve adopted the day the incident became publicly known – May 25, 1977 (which also happens to be the birthday of a certain kid I know named Luke, but I digress). “F” simply designates it as the 6th major incident of the day.

dsdm_victimWe need not spend much time on the victim element of the Diamond; the Empire understood the power and value of its critical asset, the Death Star. And their reaction to the theft of the plans implies that they knew about the risk exposed by the exhaust port vulnerability, but apparently underestimated the adversary’s means of exploiting it.

dsdm_adversaryFrom what can be gleaned from the movie, the Empire had decent intel on a key adversary persona, the young Skywalker. Enough, at least, to get a proper geolocation (thanks to his opsec failure of taking rooted machines home) and murder his known associates (of course, this should have tipped them off to the whole Anakin connection much earlier, but we won’t go down that rabbit hole right now). They also had pretty good knowledge of the Rebel Alliance, but were hampered by fuzzy attribution and their somewhat amorphous structure. Certain imperial units tried to genericize references to the Alliance by using “APT Π/2,” while others emphasized the Force connection with the “Jedi Panda” moniker. We believe these naming inconsistencies led to confusion that effectively afforded the Alliance enough obscurity to continue offensive operations.


We must assume the Empire had a high degree knowledge about the Rebel infrastructure involved in the attack. They slyly allowed the Millennium Falcon escape the Death Star and tracked it back to the Rebel base on Yavin 4. As they moved to execute the takedown operation, they undoubtedly knew of the Rebel’s carrier and fighter class ships, evidenced by the fact that they neutralized nearly all of them fairly quickly. It is likely, however, that the Empire did not realize that the Alliance had commandeered an astromech droid that had once belonged to one of its top military officials. The failure to contextualize this small piece of intelligence would later prove costly.

dsdm_capabilitiesAnd that brings us to the final element in the Diamond Model, capability. They knew the Alliance fighters could deploy proton torpedoes. Led by two Sith, they certainly knew about the Force. They knew about lightsabers and – even though they couldn’t hit anything with them – they knew about blasters too. No serious intelligence gaps here.

While the Empire was missing key bits of information on some facets of the Diamond, their inability to make connections between the facets is what, quite literally, killed them in the end. The vertices between the points tie everything together and give the critical understanding of what the adversary wants and what they can do to accomplish it. In this light, it’s clear that they failed to grasp the sum total of Luke’s desire to revenge the death of his father (sssshhhh – remember he doesn’t yet know), his natural precision targeting ability, his inherent strength in the Force, his covert channel communication with dead-but-still-alive ex-imperial generals, etc. Had they been able to put all this together, the story might have ended differently. Sure, we would probably have missed the awesomeness of The Empire Strikes Back, but we could have skipped all that screen time devoted to the Ewoks as part of the attack on the second Death Star.


At this point, it should be obvious that the Empire needed a Threat Intelligence Platform. It should also be obvious that you need this t-shirt. To get one before they are all gone, just come see us at one of our upcoming events this year. Or, if you have a face-to-face meeting coming up with one of our people, ask them to bring you one.

Threat Intelligence within the Risk Management Process


How Threat Intelligence fits within Risk Managment

This is the second post in a series exploring the relationship of threat intelligence and risk management. If you missed the previous one, wherein I briefly explained why these two should “arget=”_blank”>swipe right” and get together, read that first. If you’re wondering what qualifies me to pontificate about managing risk, don’t worry; it’s on my resume. With the introductions out of the way, conditions are perfect to get down to business, and we’re going to kick it off by examining how threat intelligence fits within the risk management process.

To do this, we’ll leverage two common cyber risk management guidelines referenced by the recent Cybersecurity Framework – NIST SP 800-39 and ISO/IEC 27005. I draw most heavily from NIST 800-39 for this post, mainly because it’s free and easily accessible in case you want to follow along. They’re both widely used, similar in many ways, and more than adequate to serve our purposes here.

The NIST SP 800-39 Risk Management Process

NIST Special Publication 800-39 was developed to “provide guidance for an integrated, organization-wide program for managing information security risk to organizational operations, organizational assets, individuals, other organizations, and the Nation resulting from the operation and use of federal information systems.” Note that it’s a program for managing risk, not a specific process. Furthermore, NIST SP 800-39 isn’t an island to itself; SP 800-37 and 800-30 offer supporting guidance on applying the risk management framework in an ongoing process.

800-39 presents risk management as a comprehensive process requiring organizations to frame, assess, respond, and monitor risk on an ongoing basis using effective communications and feedback for continuous improvement of security activities. These process components are depicted in the figure below (clipped from 800-39), and I will examine the role of threat intelligence within each following that.


NIST SP 800-39 Risk Management Process

Frame establishes the context for risk-based decisions and strategy for execution in the areas of assessment, monitoring, and response. Part of this requires that organizations identify assumptions about threats, likelihood of occurrence, vulnerabilities, and consequences. Describing the sources and methods for acquiring threat information is specifically stated (ch. 2, pg. 8, par. 2) as a main output of risk framing and a main input to risk assessment (depicted by the information/communication flows in the figure). This corresponds well to the direction phase of the intelligence cycle, and gives a starting point for collaboration between risk and intel teams. Risk management should communicate what they need to know about threats to properly frame risk and how they need to receive that info to properly assess risk. Intel ops should create a plan for collecting that information and disseminating it in a format useful for risk assessments.

Assess encompasses everything done to analyze and determine the level of risk (likelihood of harm occurring and degree of harm when it occurs) to the organization. Threat intelligence has a clear and critical role here in helping risk management to identify, assess, and track threats as well as evaluate existing vulnerabilities in light of those threats. I plan to do an entire post on the role of intelligence specific to risk assessment/analysis, so I’m not going to go much deeper than that for now. Suffice it to say that intel ops can help risk management conduct meaningful threat assessments rather than defaulting to the prevailing finger-in-the-wind or what-scares-me-most techniques.

Respond addresses what organizations choose to do once risk has been assessed and determined. They identify and evaluate various courses of action, determine which are best, and implement the chosen course(s) of action. While not as obvious the previous two components, intelligence does offer value here. Evaluating the effectiveness of proposed courses of action is very difficult without a good understanding of the motives, means, and methods of the threat being addressed. I’d venture to say that many of our problems in security stem from failing to consider the adaptive nature of adversaries, which results in implementing controls that only temporarily or partially mitigate the threat. Intelligence can also offer insight into implementing and configuring selected courses of action for maximum effectiveness. The Kill Chain and/or Diamond Model approach is particularly useful here as a foundation for conversations between intel ops and risk managers.

Monitor involves verifying proper implementation, measuring ongoing effectiveness, tracking changes that impact effectiveness or risk, etc. Note that this is not synonymous with network threat monitoring, where there is an obvious intelligence aspect. I view the role of intelligence here to be an extension and continuation of the previous response component. In other words, it’s not intel’s job to monitor internal system/control changes directly, but they certainly should be monitoring external threat changes that may necessitate internal system/control changes. Additionally, monitoring risk over time may warrant shifts in the intelligence process to better support security decisions and practice.

The tl;dr of the preceding paragraphs is captured in this annotated version of NIST’s original figure.


NIST SP 800-39 Risk Management Process annotated with role of threat intelligence

While 800-39 is the flagship document in the series, the specific detail of managing risk is provided by other supporting NIST security standards and guidelines. 800-37 is the one that contains guidance on applying the risk management framework, and is depicted below.

Rather than going through each step (many of which mimic what was already covered for SP 800-39), I’ll just highlight some key integration points for threat intelligence. Before doing so, however, it’s important to know that NIST takes what I would call an asset and control-focused approach to risk management in SP 800-37. Notice how step 1 starts with categorizing the system, then selecting and implementing controls, etc. From that view, there’s no *obvious* point at which a threat assessment drives the selection and implementation of controls. This is a weakness of NIST’s risk management framework in my opinion – or at least in the way it is presented. Asset and control-centered approaches almost inevitably adapt and evolve slower than threat-centric approaches. However, purely threat-centric approaches have weaknesses too; they tend to miss the critical context of the environment to which they’re applied.


NIST SP 800-37 Risk Management Framework

To be clear, SP 800-37 does make mention of threat information; it’s just buried in the details. Intelligence isn’t referenced in the document except in relation to the framework being used within the intelligence community. The word “threat” isn’t used at all in the guidance for categorizing information systems, but I’ll go ahead and make the recommendation that you should hook intel ops into this step if you’re using SP 800-37. Your categorization of the system will be more effective if you conduct it in light of what you know about adversaries that might try to exploit it. Inviting intelligence ops to the party early will also help during the next few steps, where the concept of threat knowledge is actually mentioned in the guidance. That basically boils down to selecting, implementing, tracking, and updating controls based on the current knowledge of the threat environment that only an intelligence capability (whether internal or external) can provide. I’m in full agreement with NIST there.

The ISO/IEC 27005 Risk Management Process


ISO/IEC 27005 Risk Management Process

ISO/IEC 27005 “provides guidelines for information security risk management in an organization, supporting in particular the requirements of an information security management system according to ISO/IEC 27001.” I actually prefer ISO 27005 to NIST 800-39 from a pure presentation/organization perspective, but that’s probably just because I have more practical experience working with it. Both processes are very helpful and share many similarities once you learn the basic lingo of each.

The ISO 27005 risk management process is presented in the figure above. “Context Establishment” in ISO lines up well with “Frame” in NIST. Both include an “Assessment” phase consisting of similar components. ISO’s “Treatment” more or less equals NIST’s “Respond.” “Monitoring” is used in both, as is the notion of communication paths among the various phases. Thus, everything said above in reference to NIST 800-39 can pretty much be copy/pasted into the appropriate slot here. I’m going to spare you that drudgery, though; I mainly wanted to include the ISO 27005 diagram for comparison’s sake. It also reinforces that what we learned above regarding the role of threat intelligence within risk management isn’t just a NIST thing. All that to say – you can apply lessons here to wherever you’re at with whatever you use.

What about risk assessment?

Risk assessment is a sub-component of the overall risk management process. NIST 800-39 and ISO 27005 both include it and emphasize its importance. There are quite a few points of contact between threat intelligence and risk assessment – so much so, in fact, that I think it deserves separate treatment. We’ll pick this up in the next post to make sure we give it due justice. Until then, I wish you all well on your journey toward intelligence-driven risk management.


All posts in this series:

ThreatConnect How To: Pivoting & Exporting Data


The Diamond Model of Intrusion Analysis is the analytic methodology upon which ThreatConnect is built.  Developed by a number of preeminent security researchers and analysts (including our own Andy Pendergast), the Diamond Model exists both as a cognitive model to organize extensive sets of interrelated logic, as well as a series of mathematical techniques found in set theory, graph theory and cluster analysis to improve analytical workflow and to enable more precise and strategic decision making against the adversary. In the realm of threat intelligence, the Diamond Model empowers analysts to efficiently aggregate and act upon troves of incoming data and, over time, begin to form automated relationships between existing pieces of threat intelligence. Eventually, analysts will be able to discern adversarial intent and targeting tactics with greater clarity, allowing for the proactive mitigation of both advanced and emerging cyber threats.

The Diamond Model breaks down individual events and categorizes them along four unique vertices: Infrastructure, Capability, Adversary and Victim.


The relationships between these vertices enable analytic pivoting across them. From knowledge of any one of the vertices, related knowledge can be categorized or discovered by pivoting to adjacent vertices in the same event, other events in the same incident, or correlated with other observed events. Let’s take a look at a few use cases to illustrate this point.

Pivoting: The Diamond Model Approach

When you build something, it must be constructed upon a solid foundation. From a software development standpoint, the same principal also applies to the construction of Threat Intelligence Platforms. This is why we developed ThreatConnect upon a proven analytic methodology.

When performing intelligence analysis in ThreatConnect, it is important to remember that there is no right or wrong way to pivot through the data. This is especially true in terms of selecting your beginning and ending pivots. It all depends on what intelligence questions you are trying to answer, or how you want to perform threat discovery and analysis.

The Diamond Model methodology is fundamental to the design of the ThreatConnect User Interface (UI), and as such, it becomes a guiding force for performing holistic threat analysis. For example, if I begin my search with a known adversary, using the diamond model as my reference means that I will want to traverse each of the remaining vertices in the triangle. The order in which I pivot through each node is irrelevant – what matters is that as frequently as is possible, I complete my path across all vertices. Since there are four vertices in the diamond, there are 24 possible permutations for my pivoting sequence.

To make it a little clearer, think of it like this: I may start my pivot with a known adversary, and in my next three pivots I will want to identify the adversary’s capabilities, their infrastructure, and their victim(s). Conversely, I may start with a known victim of an attack and pivot my way through the Diamond until I reach the adversary. Using this method yields a more complete picture of a given threat or event. Visually, you can see the 24 permutations of pivot traversal paths through the diamond model in the following table.  Think of it as possible pivot paths that allow you to deduce new intelligence you might otherwise not have been aware you possessed:


Invariably, you will come across situations where traversing through each node of the diamond is not possible due to missing data. This is to be expected. However, it turns out to be a great way to understand your intelligence gaps and where you need better data or intelligence and where you should be focusing your operations. For example, for every victim in my group there should exist an adversary. Should I discover the absence of an adversary in a given pivot, a good question to ask is, “Are there known adversaries for this victim?”  If I discover the answer is yes, I simply add that data point. If, on the other hand, I do not know it may be the case that the adversary is simply unknown, i.e. no intelligence on them yet exists. Knowing the “unknown” can be equally, if not more, important than knowing the “known”. It can be a guiding force in time allocation and resources, as it pertains to improving my operations.

Tagging in ThreatConnect can also play a huge role in addressing gaps in your intelligence and improving your ability to control, search and analyze incomplete threat data. Look for an upcoming blog on how to effectively use tagging in ThreatConnect.

Examples of Diamond Model Pivoting

Pivoting within the ThreatConnect user interface requires the use of two features to navigate effectively: the pivot button (1) and the “relationship type” (2) filter.  Although simply pivoting will indeed display the elements of information that are interrelated, the relationship type filter is a useful way to focus in on the explicit exact nature of a given association for more precise analysis.


To demonstrate the utility of the pivot methodology, we are going to walk through several unique use cases, using each of the four terminal nodes as the genesis of our analytical process.


  • MD5: 54C4448B0263062614A9AEA055A80480 >> software.qpoe.com.com >> Crimson Iron >> Group of Twenty (G20)


In this example, we begin with “Capability” in context of the Diamond, represented by the MD5: 54C4448B0263062614A9AEA055A80480. Next, we select a relationship type and we can see that the malware calls out to the “Infrastructure” software.qpoe[.]com. This pairing of Capability and Infrastructure (technical axis) and associated attributes, tactics, techniques and procedures has been grouped to an “Adversary” that has been given the internal cover term “Crimson Iron.” This internal name has been associated with a known Chinese APT threat group, and we have established evidence that this group has previously targeted the Group of Twenty (G20) as the “Victim” (geopolitical axis) in this pivot structure.


  • 184.105.203[.]61 >> software.qpoe[.]com >> MD5: 54C4448B0263062614A9AEA055A80480 >> 20130816D: Yayih Trojan >> Crimson Iron


Conversely, our pivots can take different routes depending on where we begin our investigation. In this case, we start with an “Infrastructure” indicator – the IP Address 184.105.203[.]61. This IP has previously resolved to software.qpoe[.]com, which is the same C2 callout that had been previously observed within MD5: 54C4448B0263062614A9AEA055A80480.  This specific hash is associated with the incident 20130816D: Yayih Trojan, which, through pivoting, we find that the “Crimson Iron” adversary is associated with this particular incident.


  • rooterit >> rooterit@outlook.com >> www.rooter[.]tk  >> 20130516A: Voice of Tibet Incident >> Voice of Tibet >> http://vot.org/footer/html


In the context of a top down Diamond pivot, we begin with the “Adversary” node. This adversary, known as “rooterit,” has been observed using the email address rooterit@outlook[.]com to register malicious domains for some time, one of which is www.rooter[.]tk. ThisC2 node has been previously observed within the Incident grouping 20130516A: Voice of Tibet Incident. This incident was observed in a strategic website compromise (aka watering hole) against the “Victim” Voice of Tibet’s website.


  • Afghanistan Ministry of Communications and IT >> [http:]//cdn.afghanistan[.]af/scripts/gop-script.js >> 388E6F41462774268491D1F121F333618C6A2C9A >> China


In many cases, the only node threat researches have to begin a case with is the victim, and maybe a hash value or two.  Although such a lack of information is indeed frustrating, the Diamond Model integration into ThreatConnect can overcome the challenge of intelligence gaps by illustrating associations between a rich repository of known indicators, threats, incidents and victims. The victim-centric pivot structure demonstrates this nicely.  For this use case, we will use the example of Operation Poisoned Helmand, which is further documented on the ThreatConnect blog. We start with the Afghan Ministry of Communications and IT, which fell victim to a drive-by attack in December 2014.  Pivoting into this victim, we see that a subdomain ([http:]//cdn.afghanistan[.]af/scripts/gop-script.js) on the legitimate backend CDN infrastructure was serving up a malicious JavaScript file.  Thus, the adversary was leveraging the victim’s own infrastructure against its target(s).  Further investigation of the malicious JavaScript file, SHA1: 388E6F41462774268491D1F121F333618C6A2C9A, demonstrates that in the past, this particular file has been affiliated with our “Adversary”: a known China APT threat group.

In general, two great approaches to pivoting are as follows:

1.) Pivot for discovery

This is more of a free form style of analysis where you may not have a specific end goal in mind. Instead, you are using the pivot feature to get ‘acquainted’ with your intelligence data so you can ask smarter questions about it at a later stage.

2.) Pivot for inquiry

This is when you have a very specific, tailored intelligence question in mind, and you use pivoting in an attempt to find the answer to your question. For example, “How many file indicators are associated with a given vulnerability?”

Both of these approaches form the basis of performing more mature tasks using the Diamond Model such as expanding what infrastructure or capabilities can be grouped or attributed to a specific threat group and validated hypothesis on what activity should and should not be grouped together.


We covered the process of importing data into ThreatConnect in a previous blog post; however, there are times that you might want to export your data as well.  In the next few paragraphs, we will walk you through this very simple process.

Whilst building up your pivoting breadcrumb trail (1), you may notice that within the ThreatConnect UI, you are now offered the option of exporting your data (2).


When you go to export, a pop-up box will prompt you to select which pieces of information you would like to include.


When following the breadcrumb trail isn’t enough, this extremely useful feature grants the analyst the ability to export the relevant data into a CSV file, which allows for more extensive analysis in other complementary platforms (such as Maltego).  Additionally, a hard CSV file is useful to have on hand for reference purposes in the future.

ThreatConnect Research TIP: While the export feature is available by default for Individual User Accounts, Organizational User Accounts have additional security protocols for the purposes of keeping your information private. Because Organizational User Accounts have role-based access controls, only Sharing Administrators have the ability to export data out of ThreatConnect. However, if you are having issues with the export feature, contact your organizational administrator to verify that you have the correct permissions.


Pivoting and exporting threat intelligence data in ThreatConnect are powerful features that enable you to quickly connect the dots and perform more holistic threat analysis. It’s also a great way to identify gaps in your intelligence so you can make better decisions about how to fill those gaps.

The openness and flexibility of the ThreatConnect platform allows you to extend your pivot logic programmatically via the API, allowing you to build this into your own operational custom workflow and work with ThreatConnect data in other analysis tools. Additionally, at any point in your pivot you can simply export data that is relative to your interest and use it defensively with confidence and context.

Register for a free account to get started with ThreatConnect, and make your analysis as strong as a diamond.