VirusTotal vs OTX: Context, Detections and When to Use Each

VirusTotal and Open Threat Exchange are often opened for the same reason:

I have an indicator. What is already known about it?

That overlap is real.

The mistake is assuming the two platforms answer the same question.

They do not.

A useful distinction is:

VirusTotal is strongest when the object itself — file, URL, domain or IP — needs multi-source technical characterization, detection context and relationships.

OTX is strongest when the indicator needs to be placed inside community-shared threat intelligence: Pulses, campaigns, research context and IOC collections.

Both can enrich an indicator.

But they enrich it from different directions.

The right question is therefore not:

Which threat-intelligence tool is better?

It is:

Do I need to understand this artifact, or do I need to understand the shared threat context around this indicator?

---

The short answer

Use VirusTotal first when the research object is:

• a file hash;
• a suspicious file;
• a URL;
• a domain;
• an IP address;

and you need:

• security-engine detections;
• URL/blocklist results;
• static or dynamic characterization;
• object relationships;
• reputation/context around that object.

Use OTX first when the research object is:

• an indicator;
• a campaign clue;
• a threat-actor lead;
• a set of IOCs;

and you need:

• Pulses;
• community-shared context;
• related indicators;
• threat/campaign framing;
• subscription or feed-style enrichment.

A mature workflow may use both.

---

Comparison at a glance

This is a workflow-fit table.

It is not a score.

---

VirusTotal: object-centric analysis

VirusTotal describes itself as an information aggregator.

Its standard service combines output from:

• antivirus engines;
• URL scanners;
• file and website characterization tools;
• datasets;
• community contributions.

For files and URLs, VirusTotal can aggregate many different security perspectives around one object.

Its current API also exposes objects and relationships for:

• files;
• URLs;
• domains;
• IP addresses;
• analyses;
• comments;
• collections;
• sandbox-related information in eligible tiers;
• other contextual objects.

This makes VirusTotal naturally object-centric.

You start with a concrete artifact or identifier.

Then you ask what VirusTotal already knows about it.

---

VirusTotal does not produce one universal verdict

This is one of the most important interpretation rules.

VirusTotal's own documentation says that it aggregates the output of different antivirus vendors and URL scanners and does not generate the underlying vendor verdicts itself.

That means a result such as:

5 security vendors flagged this file as malicious

should not be rewritten as:

VirusTotal proved this file is malware.

The stronger observation is:

Five participating engines returned malicious classifications in the observed VirusTotal analysis.

Then inspect:

• which engines;
• detection names;
• analysis date;
• behavioral/static context;
• relationships;
• prevalence;
• signatures;
• other evidence.

Detection count is a signal.

It is not a mathematical probability of maliciousness.

---

One detection can be wrong

VirusTotal explicitly documents false positives.

A legitimate file can be flagged by one or more engines.

This means:

1/70

is not automatically:

malicious.

Likewise:

0/70

is not automatically:

safe.

A zero-detection artifact can be:

• new;
• targeted;
• packed;
• unsupported;
• not yet recognized;
• malicious in a way not captured by the engines used.

Security detection is an observation layer.

It should be combined with context.

---

Do not rank antivirus products using VirusTotal results

VirusTotal explicitly warns against using its environment for antivirus-product comparisons.

The engines integrated into VirusTotal may:

• use different configurations;
• have different heuristics;
• differ from desktop/commercial products;
• operate in different security roles.

Therefore a table such as:

Vendor A detected 100 samples
Vendor B detected 90 samples

does not support:

Vendor A is a better antivirus product.

That is outside the methodological purpose of the platform.

For OSINT.dev, the rule is simple:

use detections to understand the artifact, not to benchmark vendors.

---

URL detections and file detections are different evidence

VirusTotal also warns that a URL scanner and an antivirus engine from the same company can produce different results.

That is not necessarily contradictory.

A URL can be malicious because it is:

• phishing;
• a redirector;
• part of a malicious campaign;
• a distribution point;

while the specific downloaded file may not be detected.

The reverse can also happen.

Keep the unit of analysis explicit:

URL
file
domain
IP

Do not merge all "malicious" labels into one property.

---

VirusTotal relationships are often more useful than the headline count

The richest investigations usually move beyond:

positives

and inspect relationships around the object.

Depending on object type and access, useful context can include relationships such as:

• contacted domains/IPs;
• embedded URLs;
• communicating files;
• downloaded files;
• referring files;
• parent/child relationships;
• certificates;
• passive DNS-like context;
• sandbox behavior;
• crowdsourced rules or tags.

The exact available fields vary by object and tier.

This is where VirusTotal becomes more than "many antivirus engines."

It becomes a technical context graph around the artifact.

---

Start with hashes when you already have a file

If you possess a suspicious file, a privacy-preserving first step is often:

1. calculate its hash locally;
2. query VirusTotal by hash;
3. inspect any existing report;
4. decide whether an upload is actually necessary.

Why?

Because uploading the file creates a different operational action from querying an already-known hash.

A known hash may already have rich analysis.

If the file is sensitive, confidential or private, standard submission may be inappropriate.

---

Standard VirusTotal submission is not private scanning

This distinction is critical.

VirusTotal has a separate Private Scanning product.

Its current documentation says private scans:

• are not added to the main threat corpus;
• are not shared beyond the organization;
• remain only for a limited retention period;
• do not include the standard multi-antivirus partner verdict model.

The existence of a separate privacy-preserving product tells you something important:

Do not assume the ordinary VirusTotal submission workflow provides the same privacy guarantees.

VirusTotal's standard service is built around collective threat-intelligence analysis and sharing with security partners.

Before submitting a file or URL, ask:

• Is the artifact confidential?
• Does it contain customer data?
• Does it contain credentials?
• Is the URL private or unannounced?
• Is the investigation sensitive?
• Can I query by hash instead?

Do not upload sensitive data simply because a scan would be convenient.

---

VirusTotal public/private API tiers are also different

The free/public API and paid capabilities do not expose the same features.

Current VirusTotal documentation describes the public API as a basic, rate-limited service intended for non-commercial uses, while premium/private capabilities provide richer data and higher/custom limits.

This matters for reproducibility.

If you write:

Search VirusTotal for all files matching this rule

that may require capabilities unavailable to a standard community account.

Record the access context when it matters.

---

OTX: community and Pulse-centric threat intelligence

Open Threat Exchange is now operated under LevelBlue.

Its core data-sharing model revolves around Pulses.

LevelBlue's current documentation describes a Pulse as a collection containing one or more Indicators of Compromise and contextual information about a threat.

Pulses can connect indicators such as:

• IP addresses;
• domains;
• hostnames;
• URLs;
• file hashes;
• email indicators;
• CIDR ranges;
• CVEs;
• other IOC types.

This makes OTX naturally context-centric.

You start with an indicator.

Then ask:

Which Pulses, campaigns or shared research contexts include this indicator?

---

What a Pulse gives you

A good Pulse can provide more than:

IOC found

It can provide:

• title;
• description;
• threat summary;
• related indicators;
• tags;
• targeted software/industries in some cases;
• references;
• author/community context;
• publication/update time.

That is useful because isolated indicators are often ambiguous.

Example:

203.0.113.10

by itself says little.

Inside a Pulse it may be presented as:

• command-and-control infrastructure;
• phishing infrastructure;
• campaign-related host;
• scanning source;
• historical indicator.

The Pulse provides a narrative container.

That narrative must still be evaluated.

---

A Pulse is not automatic truth

OTX is a collaborative threat-intelligence community.

Community sharing is a strength.

It also means provenance and source quality matter.

For an important Pulse, inspect:

• author;
• references;
• publication date;
• update date;
• source research;
• indicator dates where available;
• whether the context is first-party research or republished intelligence.

Do not turn:

indicator appears in OTX Pulse X

into:

indicator is malicious today.

The strongest observation is:

OTX Pulse X associates this indicator with threat context Y, published/updated at time Z.

Then verify whether that context remains relevant.

---

Threat indicators decay

LevelBlue's own OTX/USM documentation makes this point explicitly.

Its look-back guidance warns that old threat indicators can lose current value and that longer look-back periods can increase false positives from obsolete information.

This is critical.

An IP that was malicious three months ago may now be:

• reassigned;
• cleaned;
• sinkholed;
• used by another customer;
• no longer part of the campaign.

An old domain may have expired or changed ownership.

Therefore every OTX lookup should include a time question:

When was this indicator relevant?

Without time, threat intelligence becomes a permanent blacklist.

That is analytically dangerous.

---

OTX is strongest when the relationship among indicators matters

Suppose you have:

hash A
domain B
IP C
URL D

VirusTotal may provide deep object-level context around each one.

OTX may show that all four appear in the same Pulse describing a campaign.

That shared context is useful.

It can help generate hypotheses such as:

these indicators were reported together in the same threat-intelligence context.

That is stronger than saying:

all four are malicious

without inspecting the Pulse and timing.

---

OTX supports subscription and feed-style workflows

OTX is designed not only for one-off searching but also for threat-data sharing.

Users can:

• create Pulses;
• subscribe to Pulses;
• consume indicators;
• use OTX APIs/DirectConnect integrations;
• export or integrate IOC data into security workflows.

This makes OTX particularly useful when the workflow becomes:

continuously ingest community-shared threat intelligence.

That is a different operational model from checking one file in VirusTotal.

---

Community intelligence creates duplication

An indicator may appear in many Pulses.

That does not necessarily mean:

many independent sources confirmed it.

Several Pulses may:

• reference the same original report;
• copy the same IOC list;
• repackage another feed;
• derive from the same vendor publication.

Count provenance, not appearances.

Ten Pulses repeating one source are not ten independent observations.

---

VirusTotal community context exists too

The comparison should not oversimplify.

VirusTotal is not purely machine detections.

It also includes community functions such as:

• comments;
• votes;
• collections;
• crowdsourced rules;
• community contributions.

Likewise, OTX is not purely narrative.

It contains concrete IOC data.

So:

VirusTotal = machine
OTX = human

would be wrong.

The better distinction is:

VirusTotal's center of gravity is technical object analysis and aggregated characterization.

OTX's center of gravity is shared threat-intelligence context organized around Pulses and indicators.

---

The same indicator can mean different things in each platform

Imagine:

evil-example.test

VirusTotal view

You may see:

• URL/domain scanner results;
• analysis history;
• relationships;
• DNS or certificate context depending on access;
• communicating files;
• community comments.

This answers:

What technical/security observations exist around this object?

OTX view

You may see:

• Pulses containing the domain;
• campaign context;
• related hashes/IPs;
• references;
• tags;
• community research.

This answers:

In which shared threat narratives has this indicator appeared?

These views complement one another.

---

Worked example 1 — suspicious file hash

You receive:

SHA256: abc...

Step 1 — VirusTotal

Query by hash.

Possible results:

many detections
sandbox context
family labels
relationships
first/last analysis

The object-centric view is immediately useful.

Step 2 — OTX

Search the same hash.

You find two Pulses linking it to a campaign and several other IOCs.

Now you have:

• artifact characterization;
• shared campaign context.

Step 3 — verify the context

Inspect the Pulse sources and dates.

Do not assume the family name or campaign label is correct because it appears in both systems.

They may ultimately depend on the same source.

---

Worked example 2 — domain in a phishing investigation

You have:

login-example.test

VirusTotal

Useful questions:

• Is the domain/URL known?
• Which URL scanners classify it?
• Are files or related URLs connected?
• What historical analysis exists?

OTX

Useful questions:

• Which Pulses include it?
• Is it associated with a phishing campaign?
• What related domains/IPs/hashes were shared?
• What references support the Pulse?

Conclusion

A calibrated finding could be:

Multiple VirusTotal URL scanners classified the submitted URL as phishing at the observed analysis time, and OTX Pulse X associated the domain with campaign Y based on reference Z.

This is stronger than:

Both tools say it is malicious.

You preserved the evidence type.

---

Worked example 3 — old IP indicator

An IP appears in an OTX Pulse from two years ago.

Today VirusTotal shows little or neutral current context.

Do not write:

VirusTotal contradicts OTX.

The more likely explanation may simply be time.

OTX observation:

The IP was associated with threat context X in a Pulse from 2024.

Current VirusTotal observation:

Current VirusTotal context does not show the same level of detection/reputation under the checked conditions.

Both can be true.

Indicators age.

---

Worked example 4 — confidential suspicious document

You receive an internal document that might be malicious.

Do not immediately upload it to standard VirusTotal.

First:

preserve file
hash locally
query hash

If the hash is unknown and deeper analysis is necessary, decide whether:

• an internal sandbox;
• an approved private malware-analysis environment;
• VirusTotal Private Scanning;

is appropriate under your organization's policies.

Threat-intelligence convenience should not create a data leak.

---

Worked example 5 — one detection only

VirusTotal shows:

1 malicious
69 undetected

Do not conclude either:

malware

or:

false positive

from the count alone.

Inspect:

• detecting vendor;
• detection label;
• file type;
• signature;
• behavior;
• prevalence/context;
• community notes;
• whether the file is signed;
• whether the vendor has a known false-positive path.

VirusTotal itself documents that false positives occur and should be handled with the vendor producing the detection.

The useful finding is:

One participating engine classified the file as malicious at time X; other context is required.

---

Detection labels can disagree

Different engines may return:

Trojan.Generic
Downloader.X
Riskware
PUA
Malware

These names do not necessarily describe different malware families.

Vendor naming schemes vary.

Avoid treating every label as a separate independent family attribution.

Use broader behavior/context when possible.

Exact malware attribution often requires specialist analysis.

---

Threat-intelligence labels can disagree too

OTX Pulses can use:

• different campaign names;
• different actor labels;
• different malware names;
• different tags.

Threat naming is not globally standardized.

Two research groups can describe the same activity differently.

A Pulse tag is useful context.

It is not an authoritative ontology.

---

Indicator context is stronger when it includes source references

An OTX Pulse without clear references deserves more caution than a Pulse linking to:

• original research;
• official advisory;
• technical report;
• malware analysis;
• incident report.

Likewise, a VirusTotal detection without supporting behavior may deserve different confidence than:

detections
+ sandbox behavior
+ relationships
+ independent reporting

The rule is:

context quality matters more than label quantity.

---

Hashes are stronger identifiers than filenames

A filename such as:

invoice.pdf

is weak.

A SHA-256 hash is much stronger as an artifact identifier.

If you are comparing VirusTotal and OTX for a file:

• preserve the hash;
• search by hash where possible;
• keep file name only as contextual metadata.

Do not assume two files with the same filename are the same artifact.

---

Domain and IP indicators are more temporally unstable than hashes

A file hash identifies a specific byte sequence.

A domain or IP can change operational meaning over time.

For example:

203.0.113.10

can host different customers at different dates.

A domain can:

• expire;
• be transferred;
• change DNS;
• change content.

Therefore time should be especially prominent when interpreting:

• IP;
• domain;
• URL;

threat intelligence.

---

URL identity also needs precision

These URLs are not necessarily equivalent:

https://example.test/
https://example.test/login
https://example.test/login?id=42

VirusTotal has URL-specific object identifiers and canonicalization logic.

When comparing results across platforms, preserve the exact URL investigated.

Do not collapse:

malicious URL path

into:

entire domain malicious

unless the evidence supports domain-level attribution.

---

Public scan services can expose investigative interest

Submitting a URL or file to a threat-analysis platform is an operational action.

Depending on the service and product tier, the submitted artifact may enter broader security-sharing ecosystems.

Therefore ask before submission:

• Is the indicator already public?
• Is the URL sensitive?
• Could submission alert a target or expose an investigation?
• Does the artifact contain private data?
• Is a lookup possible without submission?
• Is private scanning required?

OPSEC belongs inside tool selection.

Not after it.

---

OTX sharing also needs provenance discipline

If you create or distribute Pulses, avoid turning unverified candidates into threat facts.

A good Pulse should distinguish:

observed IOC
candidate IOC
historical IOC
confirmed relationship
contextual reference

and include useful source references.

Threat-sharing systems become less useful when uncertainty is removed from the data.

---

Automation changes the risk

Both VirusTotal and OTX support API workflows.

Automation can make it easy to process thousands of indicators.

That creates two different risks.

VirusTotal

Automated standard submission may unintentionally share:

• sensitive files;
• internal URLs;
• customer data.

Prefer lookup/enrichment before submission.

OTX

Automated consumption may treat old/community indicators as permanently malicious.

Use:

• timestamps;
• confidence;
• Pulse context;
• look-back windows;
• deduplication;
• review.

The machine should not silently convert:

appeared in threat feed

into:

block forever.

---

Build indicator states

A useful threat-research pipeline can preserve states such as:

unknown
observed
community_reported
detected
candidate_malicious
confirmed_malicious
historical
expired
false_positive
unresolved

Do not flatten everything into:

malicious = true/false

Real intelligence is rarely that simple.

---

A practical decision matrix

This table suggests which platform is the more natural first lens.

The second platform may still add value.

---

A repeatable two-tool workflow

If both platforms are relevant:

1. Preserve the indicator

Record:

• exact value;
• type;
• source;
• timestamp;
• case context.

2. Decide whether lookup or submission is appropriate

Especially for VirusTotal.

For files:

hash first

when possible.

3. Query VirusTotal

Record:

• analysis date;
• detection stats;
• specific detections;
• relevant technical context;
• relationships.

Do not store only the headline ratio.

4. Query OTX

Record:

• Pulse IDs;
• Pulse titles;
• authors;
• publication/update times;
• related IOCs;
• references.

5. Compare time

Ask:

• Are the observations contemporaneous?
• Is OTX describing an old campaign?
• Is VirusTotal showing current context?

6. Trace provenance

Are both systems ultimately referencing the same threat report?

If yes, reduce your independence assumptions.

7. Classify the result

Example:

current_detection_signal
historical_campaign_context
community_report
unresolved

8. Decide the next action

• corroborate;
• escalate;
• preserve;
• monitor;
• stop.

Do not keep querying only to accumulate more red flags.

---

How to write the conclusion

Bad:

VirusTotal and OTX confirm this domain is malicious.

Better:

At the time checked, multiple VirusTotal URL scanners classified URL X as malicious/phishing, while OTX Pulse Y associated the domain with campaign Z based on references A and B. The Pulse was last updated on date D.

Better still, if relevant:

The two sources are not fully independent because the OTX Pulse references report A, which may also contribute to one or more downstream reputation feeds.

A reference-grade finding describes:

• signal;
• source;
• time;
• provenance;
• uncertainty.

---

Common mistakes

Mistake 1 — Treating VirusTotal detection count as a verdict

It is aggregated engine output.

Mistake 2 — Treating 0 detections as safe

Coverage and novelty matter.

Mistake 3 — Treating one detection as confirmed malware

False positives exist.

Mistake 4 — Benchmarking antivirus vendors from VirusTotal

VirusTotal explicitly warns against that methodology.

Mistake 5 — Uploading confidential files to standard VirusTotal

Query by hash first; use approved private/local analysis when required.

Mistake 6 — Treating an OTX Pulse as permanent truth

Indicators age.

Mistake 7 — Counting Pulse appearances as independent confirmations

Many Pulses can repeat one source.

Mistake 8 — Ignoring Pulse author and references

Community context needs provenance.

Mistake 9 — Mixing file, URL, domain and IP reputation

They are different objects.

Mistake 10 — Ignoring time on IP/domain IOCs

Infrastructure can be reassigned.

Mistake 11 — Collapsing threat labels into one taxonomy

Vendors and researchers name threats differently.

Mistake 12 — Automating "feed match = malicious"

Preserve intermediate states and review.

---

Which platform should you open first?

Use VirusTotal first when the uncertainty is:

What technical/security context exists around this concrete artifact or object?

Use OTX first when the uncertainty is:

In which community-shared threat context has this indicator appeared, and what related IOCs or campaigns are reported?

Use both when you need:

artifact characterization and campaign/community context.

That is the cleanest distinction.

---

Related OSINT.dev tools

VirusTotal

Best for:

• file/hash analysis context;
• URL/domain/IP reputation and relationships;
• multi-source detections;
• artifact characterization.

Treat detections as signals.

Review submission privacy before uploading.

AlienVault / LevelBlue OTX

Best for:

• Pulses;
• community-shared IOC context;
• related indicators;
• campaign framing;
• threat-intelligence feed workflows.

Treat time and provenance as first-class fields.

Choosing Between Manual, Semi-Automated and Automated OSINT Workflows

Use the workflow-design guide when the question is:

Should VirusTotal/OTX enrichment be automated across many indicators?

This comparison answers:

what does each platform contribute?

The automation guide answers:

how should the enrichment pipeline be controlled?

---

The core principle

VirusTotal and OTX are most useful when you preserve the difference between object evidence and shared threat context.

Think of the workflow this way:

VirusTotal — What technical/security observations exist around this object?

OTX — In what shared threat-intelligence context has this indicator appeared?

Then add the two disciplines both systems require:

time

and:

provenance

A detection is not eternal.

A Pulse is not a verdict.

A feed match is not a conviction.

A zero-result search is not proof of safety.

Use the tools to reduce uncertainty.

Do not use them to manufacture certainty.

---

References

Official/current product documentation used in this comparison:

• VirusTotal — How it works
  https://docs.virustotal.com/docs/how-it-works

• VirusTotal API v3 — Overview
  https://docs.virustotal.com/reference/overview

• VirusTotal — False positives
  https://docs.virustotal.com/docs/false-positive

• VirusTotal — Why VirusTotal is not an antivirus comparison tool
  https://docs.virustotal.com/docs/antivirus-stats

• VirusTotal — Private Scanning
  https://docs.virustotal.com/docs/private-scanning

• VirusTotal — Public vs Private API use cases
  https://docs.virustotal.com/docs/difference-public-private

• LevelBlue — About Open Threat Exchange (OTX)
  https://docs.levelblue.com/documentation/usm-anywhere/user-guide/otx/about-otx

• LevelBlue — Open Threat Exchange and USM Anywhere
  https://docs.levelblue.com/documentation/usm-anywhere/user-guide/otx/open-threat-exchange

• LevelBlue — OTX look-back period and indicator freshness
  https://docs.levelblue.com/documentation/usm-anywhere/user-guide/otx/otx-key

• LevelBlue — Open Threat Exchange
  https://www.levelblue.com/open-threat-exchange