How to Build a Threat-Graph Investigation

Quick answer: A pile of indicators can be turned into a case with structure. Simply seed the graph, expand relevant nodes, enrich key data and export it after documenting findings. 

A list of malware indicators is just the beginning point of an investigation. At its core, it does not provide any potential aspect for research—crucial elements are required. This includes a defined connection between different samples, domains and IPs and the importance this holds. 

Whereas a threat graph provides required information in a defined way by converting entities into nodes and relationships into edges. 

This way, using the right approach and tools like a free malware analyzer, the process can be made effective. Keep reading to explore how to build a threat-graph investigation. 

BEFORE YOU START  Graph pivots and native enrichment use a free daily allowance first, then spend credits. Enrichment through a provider where you have supplied your own API key is not charged. Add your keys under Keys before you start enriching — five minutes there will save you most of your credit spend on this case.

1. Seed the Case

There are three ways in, and they suit various starting points.

Name the case right away, in the Case name field, and use a name your future self will recall — the ticket number plus the family, not “test 3”. Set the visibility level: Private is the default and the right answer for anything customer-related; Public makes the case downloadable.

Adding Nodes by Hand

The Add node menu must have a type and a value, which helps you put things in the graph that no automatic extraction would detect: Sample, File, Domain, IP address, URL, Malware family, Campaign and Mutex.

The last three are the ones analysts neglect to use, and they are what make the graph an audit rather than an indicator dump. A Campaign node gives the case a sturdy foundation to hang clusters from. A Malware family node helps you state attribution explicitly instead of leaving it implied. A Mutex node stores the kind of artifact that ties two otherwise disparate samples together far more effectively than a shared hosting provider. Select two nodes and use Link selected to record the interaction you believe exists.

2. Expand Outward, One Node at a Time

Double-click a node to enhance it. That single action is most of the tool. A sample stretches to its infrastructure and relatives; a domain to its specs, URLs and the samples that contact it; an IP to any data it has hosted.

The batch endpoint does the same across many variables at once:

POST /v1/graph/pivot     # batch multi-IOC pivot (metered / credited)

Resist the request to expand everything. A graph with four hundred nodes is not a richer study; instead, it is an unreadable one — and every rise costs an action. Two rules keep it useful:

• Expand with a question: “Does this IP host anything else that feels like our sample?” tells you which node to select and when to stop.
• Prune as you go: Delete nodes that responded to their question and turned out to be redundant. The graph you keep should be the query, not the search history.

THE SHARED-INFRASTRUCTURE TRAP: A bulk hosting provider, a CDN, a parking IP or a popular dynamic-DNS domain will attach anything to anything. When an expansion delivers a hub node with hundreds of unused edges, that node is infrastructure, not a link. Prune it or mark it, and never let it serve as an attribution claim.

3. Enrich — and Know What You Are Paying For

Enrichment involves adding external context to a node: reputation, hosting and ASN data, open ports, passive DNS, abuse history. Use Enrich on defined nodes, or Enrich all for the whole graph.

A malware analyzer can make this enrichment useful by connecting technical parameters with reputation, infrastructure, and abuse data, but the primary objective is to enrich the nodes that matter to your assessment.

POST /v1/graph/enrich    # native providers, plus bring-your-own-key providers

                         #   e.g. VirusTotal, Shodan, AbuseIPDB and others

The practical implications: add your own keys before a large case, and enrich cautiously rather than reflexively. Adding meaning to every node in a hundred-node graph gives you a hundred nodes of context you will not read. Enrich the nodes that are heavy-duty in your conclusion.

Also, learn how to build strong digital compliance programs. 

4. Lay the Graph Out So It Can Be Read

Layout is not decor — the layout you choose dictates what a reader notices. Five are available, plus Fit and Full screen.

Explore in fcose; publish in dagre. A hierarchical figure with eight nodes will explain to a reader that a force-directed hairball with eighty never will.

5. Bring in the Two Comparison Tools

Now is the time to include two comparison tools to sort of the results that will not be supporting the final results: 

Compare Two Samples

When the graph joins two samples together, affirm it rather than asserting it. Compare (/diff) takes two SHA-256 hashes and diffs verdict, structural similarity, IOCs, abilities and ATT&CK mapping. “Same family, repacked” and “same actor, different tool” look very similar on a graph and completely opposite in a diff.

Map the Case to ATT&CK

ATT&CK (/attack) gives technique density across the corpus with a per-technique pivot into adjacent samples, and exports a MITRE ATT&CK Navigator layer. Two uses inside a case: check whether the techniques your samples use are typical or unusual in the wider corpus, and overlay the layer on your own detection coverage map to illustrate which specific elements of this campaign you would currently miss.

6. Save the Case, With Notes

Press Save. A saved case is a durable probe that you can reopen, extend and hand over, and it lives alongside the collections API:

GET  /v1/investigations   # saved CTI cases: graph snapshots, notes, exports

GET  /v1/collections      # list your investigations

POST /v1/collections      # create one: samples + IOCs + notes

Write the notes while the argument is fresh, and write them for someone who was not there. Four things belong in an individual case:

1. What you were asked: The question the case allows you to answer.
2. What is observed versus what is perceived as true: Mark inferences as inferences. A graph edge looks like a fact even when it supports your hypothesis.
3. Confidence, and why: “High — three samples featuring a mutex and a hard-coded C2 path” is useful. “High” solely is not.
4. What you did not check: The most helpful sentence in any handover, and the one most often skipped.

SNAPSHOT, NOT A LIVE FEED  A saved graph is a point-in-time record. Infrastructure moves, domains get taken down, and the results change as engines update. Date every case and re-check the load-bearing nodes before you click on an old one.

7. Export to the Right Format for the Audience

Below is how to export the right format for the person viewing it. The better the format is, the better the responses will be:

Match the export to what the recipient can ingest. A STIX bundle sent to someone who will launch it in a text editor helps nobody; a CSV of forty indicators fed into a SIEM watchlist gets executed on the same afternoon.

Common Mistakes

Here are some common mistakes that need to be considered for a good quality of results:

Also, learn how to align your threat and vulnerability management strategy with SOC operations.

Where This Leaves You

In the end, a useful threat graph is not the one with the most nodes. Rather, it is the one that simply shares the relationship, evidence and reasoning behind the investigation. Seed the case carefully, expand with a defined question and enrich only the nodes that act as a helping hand for the end results. 

The other most important aspect is to clearly note down what is observed, what comes out as a conclusion, and what is not checked. A clean graph is much more effective for the next analyst than a huge collection. 

Brandon Powers