HomeBlogWhat Is Threat Research?
Security research

What is threat research? How security vendors find, verify and publish it

Threat research studies how attackers operate, from the tools they buy on cybercrime forums to the infrastructure they run. Vendor research teams turn those observations into findings that defenders and journalists can check.

Security research: what is threat research

A seller on a cybercrime forum posts an advert for a new phishing kit. It promises to bypass multi-factor authentication, comes with a monthly subscription and a support channel, and has screenshots of a working admin panel. Threat research is the work of finding that advert, getting close enough to the tool to understand what it really does, and publishing an account that defenders can act on.

The finished research usually reads like a short technical report: what the tool or campaign is, how it works, who is selling or using it, and what defenders should look for. Most of the time goes on collecting material, checking it and cutting claims the evidence cannot support. The writing comes last and takes the least time.

Security vendors publish threat research to help defenders and to show buyers that they understand the threats their products are built to stop. Buyers only believe the second when the research holds up as the first, so the process behind it decides whether anyone trusts the result.

What is threat research?

Threat research is the investigation of attacker tools, infrastructure, techniques and markets to produce new, evidence-backed findings about how attacks work. Researchers collect primary material such as malware samples, forum listings and phishing pages, verify what it does, and publish findings that defenders can use to detect or prevent the activity.

Vendors often use the term interchangeably with three neighbouring disciplines, each of which produces a different output for a different reader.

Discipline What it studies Typical output
Threat research Attacker tools, campaigns, infrastructure and markets Published findings, technical write-ups, indicators of compromise
Threat intelligence The same activity, packaged for a specific organisation's decisions Feeds, briefings, alerts and risk assessments for defenders
Vulnerability research Flaws in software and hardware Vulnerability reports, CVEs, proof-of-concept code
Survey-based research Opinions and practices of security professionals Market reports built on questionnaire data

Threat research feeds threat intelligence: a finding about a new phishing kit becomes detection logic, a briefing for a customer, or an entry in a feed. Survey-based reports describe what security professionals think about threats, and security readers give them far less weight than evidence of how a threat works.

What a threat researcher does

Most of a threat researcher's week is spent watching places where attackers trade and talk, then following anything unusual far enough to know whether it is new. A listing for a tool nobody has written about, a spike in phishing pages built from the same template, or a seller adding a new capability each starts as a lead that might come to nothing.

Checking a lead can mean reading a seller's full post history, comparing screenshots across listings, examining a sample in a sandbox, or pivoting from one domain to the hosting and certificates around it. A lot of leads end there, because the tool turns out to be a rebrand of something already documented or the seller cannot deliver what they advertise.

Criminal sellers exaggerate as much as any vendor, so a researcher has to separate what a tool claims to do from what the evidence shows it does. Reverse engineering skills help, but so does reading a seller's claims with the same suspicion a practitioner brings to a vendor whitepaper.

Where threat research comes from

A research team can only find what its sources show it. The large vendor labs, such as Cisco Talos, Palo Alto Networks Unit 42 and Fortinet's FortiGuard Labs, draw on several of the following at once.

  • Cybercrime forums and marketplaces, where sellers advertise tools, initial access and stolen data to buyers.
  • Telegram and other messaging channels, which now host a lot of the sales and support activity that used to sit on forums.
  • Malware samples, from public repositories, sandboxes and the vendor's own detections, which show what a tool does once it runs.
  • Product telemetry, which shows how an attack behaves against real customers at volume and which customers it reaches.
  • Incident response engagements, where researchers see the full chain of an attack after the fact, from initial access to impact.
  • Honeypots and scanning, which capture opportunistic attacks and map the attacker infrastructure behind them over time.

Product telemetry is the source that sets vendor research apart from independent work. A vendor that sees a campaign hitting its own customers can describe scale and targeting that an outside researcher can only estimate. Underground monitoring catches threats earlier, often before a tool has been used widely, and a lot of the most cited research starts there. Vendors with access to both can report a threat early and then show its real-world reach.

How security vendors publish threat research

A finding can be accurate and still fail once it is published, if it arrives late, claims more than the evidence shows or is written for the wrong reader. Most vendor research teams follow some version of these six steps to get from a lead to a published piece.

  1. Find the signal. A lead comes from monitoring, telemetry or an incident. At this stage it is an observation, with no claim attached yet.
  2. Verify it. Confirm what the tool or campaign does with screenshots, samples, infrastructure or test results, and record what could not be confirmed.
  3. Check that it is new. Search existing research for the same tool under other names. A rebrand of a known kit is a different, smaller story.
  4. Decide what to claim. Separate what the evidence shows from what the seller claims and what the researcher infers, and word each differently.
  5. Write for a technical reader. Lead with the finding and mechanism, then the evidence, then defender actions, mapped to MITRE ATT&CK where useful.
  6. Publish what defenders need. Include indicators of compromise (IOCs), detection guidance or mitigation steps wherever the research supports them.

Underground tools get renamed, resold and written up by other teams within weeks, so a finding that sits in review for a month can lose its value as new research. Teams that publish regularly keep verification thorough and limit sign-off to the people who need to see the piece.

Once published, a good finding gets reused across the vendor's marketing: as a blog post, a briefing for sales, a talk, and source material for journalists. We cover that reuse in our content guide. Each version depends on the original research holding up when practitioners check it.

What makes practitioners cite threat research

Security practitioners read vendor research with suspicion, since they know it is also marketing. The research they cite and share tends to be new, evidenced, carefully worded and useful to a defender.

A practitioner who has already read about a tool elsewhere has no reason to cite a second write-up, so research gets most of its value from being early or from adding something other teams missed. Readers also expect evidence they can check, such as screenshots of the listing, sample hashes, infrastructure or test output. Without it, the reader has only the vendor's word.

The wording of a finding also affects how far readers trust it. A finding that says the operators claim a capability, and that the researchers confirmed part of it, reads as more credible than one that presents every advertised feature as fact. Other researchers correct overstated findings in public, and those corrections stay attached to the vendor's name.

Defenders share research that ends with IOCs, detection ideas or concrete mitigations, and tend to stop reading when it ends with a product pitch. The commercial return comes from the credibility the research builds, which we discuss in our guide to security marketing.

Ethics and responsible handling

Threat research involves real victims, stolen data and criminal sellers. Practitioners and journalists notice quickly when a published piece handles any of them carelessly.

Research should not name a breached organisation without its consent or a public confirmation, and screenshots of leaked data need redacting before publication. When research uncovers an active compromise, the affected organisation or the relevant national authority should hear about it before the public does.

Vulnerabilities follow coordinated disclosure. When research finds a flaw in legitimate software, the vendor gets time to fix it before the details are published. Teams that deal with criminal sellers should also set rules on when, if ever, they will pay for access or samples, since that money funds the activity being researched. These decisions rarely appear in the published article, but they limit what it can show and say.

Example: how WormGPT became a reference point

In July 2023, we published research for SlashNext on WormGPT, a generative AI tool that cybercriminals were using to launch business email compromise (BEC) attacks. The investigation started from underground monitoring, documented what the tool was and how criminals were using it, and was written for a technical reader first.

Screenshot of the WormGPT threat research article on the Varonis blog
Screenshot: the WormGPT investigation, still live on the Varonis blog.

WormGPT became the anchor of a wider research programme for SlashNext covering phishing kits, anti-bot services and malicious AI tools. The research was retained as core brand IP through SlashNext's $150M acquisition, and the pieces, including the original WormGPT investigation, are still live on the Varonis blog today. The full list of published work is on our case studies page.

In-house team or external researchers

A vendor that wants to publish threat research has three realistic options, and the right one depends on how much it plans to publish and what access it already has.

Option Strengths Limits
Dedicated in-house research team Full access to telemetry, deep product knowledge, steady output Experienced researchers are scarce and expensive; takes time to build
Existing security staff, part time Uses expertise already on the payroll Research loses out to day-to-day work; output is irregular
External researchers Established underground access and publishing experience from day one Less access to internal telemetry; needs a clear brief and review process

Large vendors with significant telemetry usually build in-house. Smaller and growth-stage vendors often find that existing staff cannot set aside time for research, and bring in external researchers instead. Cyberou's security research service works that way. Our practitioners find and verify novel findings, the client's team reviews every piece, and the research is published under the client's brand.