T1681 Search Threat Vendor Data: ATT&CK Defence Guide

Adversaries read the same threat intelligence you do, and they use it to find out what defenders know about them and to change whatever has been exposed. MITRE ATT&CK T1681 Search Threat Vendor Data describes threat actors searching open or closed threat intelligence sources for reporting on their own campaigns, or on other groups that share their targets and objectives, and then changing behaviour before their next operation. It sits in the Reconnaissance tactic (TA0043) on the PRE platform in ATT&CK v20, has no sub-techniques, and happens entirely outside your network. That makes it an exposure reduction problem rather than a detection problem: the questions are what your organisation publishes and shares, how fast your detections decay once an indicator is public, and whether your defences still work after the adversary has read the report. This guide is for threat intelligence, detection engineering and incident response teams, and for anyone who publishes or shares indicators. For the wider discipline, see the Threat Intelligence Guide.

Key takeaways

Assume every published indicator has a short life. ATT&CK records that UNC3886 replaced indicators named in public reporting in under a week, so a blocklist built from a vendor blog is a short-term control, not a defence.
Adversaries register on intelligence platforms. SentinelLABS and Validin observed Contagious Interview operators opening accounts on a threat intelligence platform within about a day of reporting on related infrastructure and searching their own domains.
The real mitigation is behavioural detection. ATT&CK's only mitigation is M1056 Pre-compromise, and its note for this technique is to design defences that are not reliant on atomic indicators.
Your own lookups can leak. Submitting a sample or URL to a public service, or naming an indicator in a public post, can tell the adversary what you have seen. TLP labels and disclosure timing are part of the control set.
Measure decay, not volume. Track how long indicators stay useful after publication and what share of your detections survive an indicator change.

What the technique covers

ATT&CK describes the reports adversaries consult as including behaviour descriptions, detailed breakdowns of attacks, atomic indicators such as malware hashes and IP addresses, and timelines of a group's activity. ATT&CK draws a clear line between this technique and T1597.001 Threat Intel Vendors: T1597.001 is reconnaissance on victims using paid intelligence, while T1681 is the adversary researching reporting about its own activity, or about peers it resembles, to adapt.

What the adversary reads	What it learns	Likely change
Vendor blogs and research reports	Which hashes, domains, IP addresses and tools are burned; which TTPs defenders can now detect	Rebuild or re-host infrastructure, recompile tools, alter tradecraft
Community intelligence platforms and scanner databases	Whether its domains, certificates and servers are already indexed or tagged	Retire flagged assets, choose infrastructure that is not yet indexed
Public sandbox and multi-scanner services	Whether a sample or URL has been submitted, and roughly when	Treat a submission as a sign a victim noticed; rotate the asset
Open-source blocklists and detection rule repositories	Which strings and signatures defenders match on	Change the artefacts those signatures key on
Reporting on other groups with similar targets	Which shared techniques are now well detected	Borrow approaches that are less covered

This mirrors the logic of the Pyramid of Pain: hashes, IP addresses and domains are cheap for an adversary to change, network and host artefacts and tools cost more, and TTPs cost the most. T1681 is the adversary choosing which of those to change after reading about itself.

Cases: how adversaries have used it

UNC3886 (G1048): Mandiant reported that this espionage group, which exploited the VMware Tools flaw CVE-2023-20867 from compromised ESXi hosts, had been observed replacing indicators named in publications in under a week of release, and that its cleanup followed public disclosures within days. Mandiant responded by writing its report around tactics and methods so defenders could detect the attack path regardless of the exact malware used. See the UNC3886 Threat Actor Profile Guide.
Contagious Interview (G1052): SentinelLABS and Validin reported that on 12 March 2025, about a day after Validin published research on related infrastructure, nine accounts were registered on Validin's free community platform within roughly 15 minutes, several from Astrill VPN addresses. Validin blocked them within about 15 minutes; further attempts followed in March, April and May using other email providers and invented affiliations. The operators made 57 unique searches, the first for a keyword that had appeared in a public Maltrail blocklist file about a day earlier, and queried one URL about five minutes after it was submitted to VirusTotal. They also scouted domains before registering them. See the Contagious Interview Threat Actor Profile Guide.

The two cases point in different directions, which matters for defenders. UNC3886 used reporting to clean up and replace indicators quickly. SentinelLABS found Contagious Interview made no systematic changes to existing infrastructure after searching; its main response was to stand up new infrastructure quickly after takedowns, which the researchers linked to decentralised command and revenue pressure. In both cases, defences that relied on a published list of indicators lost value within days.

What defenders can see

ATT&CK's detection strategy for this technique (DET0866, analytic AN1998) is blunt: the activity has a very high occurrence and false positive rate and largely takes place outside the target's visibility. You cannot see an adversary reading a blog post. What you can see is narrower:

If you run an intelligence platform or public research service: account registrations clustered in time, from VPN or hosting ranges, with throwaway email addresses, invented affiliations and vague purposes; searches for indicators you have not published; repeat attempts after blocking. This is the visibility Validin had.
If you publish research: web server logs for report pages and indicator files, and changes to the named infrastructure after publication (DNS records removed, certificates rotated, servers taken offline). Watching those changes tells you how fast your indicators decay.
If you only consume intelligence: the signal is indirect. Indicator matches drop to zero shortly after a report while related behavioural detections keep firing, or an intrusion continues with fresh infrastructure but the same tradecraft.
Your own outbound queries: proxy and API logs showing staff or tools submitting internal samples, URLs or documents to public scanning services. These are your leaks, and they are visible in your telemetry.

Reducing your exposure

ATT&CK lists only M1056 Pre-compromise. The practical controls below are NHI Mgmt Group recommendations built on that mitigation and the cases above.

Control	What it does	Owner
Behaviour-first detection	Write and prioritise detections on technique behaviour (process lineage, cloud API sequences, authentication patterns) so an indicator swap does not blind you	Detection engineering
Indicator expiry	Give every imported indicator a review or expiry date and a source; retire atomic indicators from alerting quickly after publication unless they keep matching	CTI
Private lookups first	Use private or contracted analysis for samples from live incidents; send to public multi-scanners only after a deliberate decision	IR and SOC
TLP discipline	Label shared intelligence with TLP 2.0, keep live-incident indicators at TLP:AMBER or TLP:AMBER+STRICT, and agree when they move to TLP:CLEAR	CTI and IR leads
Coordinated publication	Before publishing, agree with affected parties and infrastructure providers so takedowns land at or before publication, not after the adversary has read it	CTI and communications
Hunt the gap	After a major report, hunt for the reported behaviour, not only the indicators, across the period before and after publication	Threat hunting

TLP 2.0 is the FIRST standard authoritative from August 2022, with five labels: TLP:RED, TLP:AMBER, TLP:AMBER+STRICT, TLP:GREEN and TLP:CLEAR. FIRST states that TLP is not a formal classification scheme and describes no technical enforcement: it works only if recipients honour it, so restrict live-incident data to sharing partners you trust. See the Traffic Light Protocol Guide.

Where identity fits

Indicators about compromised identities age differently from network indicators. A stolen API key, OAuth client secret or service account token named in a report is still dangerous after publication if it has not been revoked, and an adversary reading the report learns whether defenders noticed it. Rotate and revoke exposed machine credentials before or at publication, never after, and keep detections on how credentials are used (unusual source, scope, timing) rather than on the specific key value. See the Threat Intelligence for Identity and NHI Guide.

Decision guidance

Public multi-scanner or private analysis: for commodity malware with no targeting, public submission helps the community and costs little. For a sample from an active, targeted intrusion, prefer private analysis until containment is complete, because a submission can tell the operator it was found.
Publish now or wait: publishing early helps other victims; waiting lets you contain and coordinate takedowns. Where a public report would tip off an adversary still in your estate, contain first, share at TLP:AMBER, then publish.
Small organisations: you mostly consume intelligence. Focus on indicator expiry, behavioural detections from your security tooling and a rule that live-incident samples are not uploaded publicly without approval.
Large organisations and vendors: you publish and run platforms. Add registration vetting and abuse monitoring to any community intelligence service, and plan publication with providers so infrastructure is disrupted when the report appears.

How to put it in place

Inventory indicator-driven detections: list every alert that keys on a hash, IP address, domain or URL, with its source and age.
Pair each with a behaviour: for the top campaigns relevant to you, make sure at least one behavioural detection covers the same activity. See the Indicators of Compromise vs Indicators of Attack Guide.
Set expiry rules: default review dates for atomic indicators in your intelligence platform, with automatic demotion from alerting to enrichment.
Write the sharing policy: TLP defaults by data type, who may submit to public services, and approval for public release.
Test it: in a purple team exercise, replay a known technique with changed infrastructure and tooling, and confirm detections still fire. Roll back any rule change that raises false positives beyond agreed thresholds.
Review after each major report: record how quickly matches to the published indicators fell, and feed that back into expiry settings.

Measurement

Indicator half-life: median days from publication until a published indicator stops matching in your telemetry or goes offline.
Behavioural coverage: share of priority techniques with at least one non-indicator detection.
Stale indicators: share of alerting indicators past their review date.
Public submissions: number of internal samples or URLs sent to public services without approval, from proxy logs.
Detection survival: share of detections that still fired in exercises where infrastructure and tooling were changed.

Common failure patterns

Blocklist as strategy: loading a vendor's indicator list and treating the campaign as covered, when the adversary may already have moved.
Burning your own investigation: uploading a targeted sample or phishing URL to a public service mid-incident, which can signal discovery.
Indicators that never expire: years-old IP addresses still alerting, generating noise on reassigned cloud addresses and hiding real detections.
Revoke after publish: naming a compromised credential or host in shared reporting before it has been rotated or isolated.
TLP as a security control: sharing live data at TLP:GREEN with a large community and assuming it will stay there, when TLP has no technical enforcement.

Framework mapping

Framework	Reference	Relevance
MITRE ATT&CK v20	T1681, TA0043; related T1597.001; mitigation M1056; detection strategy DET0866	Technique definition, cases and ATT&CK's guidance
NIST CSF 2.0	ID.RA-02, ID.RA-03, DE.AE-07	Receiving intelligence, recording threats and using intelligence in analysis
NIST SP 800-53 Rev 5	PM-16 Threat Awareness Program, PM-15 Security and Privacy Groups and Associations, SI-5 Security Alerts, Advisories, and Directives, RA-10 Threat Hunting	Intelligence sharing and use, and hunting for behaviour
ISO/IEC 27001:2022	Annex A 5.7 Threat intelligence	Collecting and analysing threat information
FIRST TLP 2.0	RED, AMBER, AMBER+STRICT, GREEN, CLEAR	Disclosure hygiene when sharing indicators

Practitioner checklist

List every indicator-based detection with source, age and expiry date.
Give each priority campaign at least one behavioural detection that survives an indicator change.
Set default expiry and demotion rules for atomic indicators in your intelligence platform.
Require approval before live-incident samples or URLs go to public scanning services, and monitor proxy logs for submissions.
Apply TLP 2.0 labels to all shared intelligence, with TLP:AMBER or TLP:AMBER+STRICT for live incidents.
Rotate or revoke any credential, key or token before it appears in shared or public reporting.
Coordinate publication with infrastructure providers so takedowns land at release.
After each major public report, hunt for the described behaviour, not just the indicators.

T1681 Search Threat Vendor Data: Detection, Mitigation and Response