How to Read a Security Scan Report: A Plain-English Guide

Published: 19 April 2026 • Updated: 4 May 2026 • 10 min read • By Kumari Rajapaksha, Founder

You paste a suspicious link or upload a file, the page returns a wall of panels, numbers, engine names and coloured badges, and somewhere on that page is the answer to the only question you actually care about: is this thing safe or not? Security scan reports are genuinely useful, but they are built for analysts first and worried humans second. This guide unpacks what you are actually looking at on a VirusTotal, urlscan.io or ScanTotal report, and how to translate it into a decision in about a minute.

The short version: no single number on a scan report is the answer. What matters is the pattern across a few different checks, and most of the confusion people run into comes from over-weighting one signal.

Anatomy of a security scan report A mock scan report card showing four labelled regions: the verdict badge, detection count, behavioural indicators, and source citations. ⚠ MALICIOUS DETECTIONS 12 / 70 engines flagged BEHAVIOUR ⚠ Connects to known C2 infrastructure ⚠ Process injection observed Sources: GSB, MITRE ATT&CK, sandbox replay Verdict Top-line answer Detection count Reputation signal Behavioural What it does Sources Audit trail
A scan report combines four parts: a verdict, a detection count from reputation engines, behavioural indicators from sandbox runs, and the sources behind each call. Reading them together is what gives you the answer.

The Three Kinds of Signals a Report Combines

Every modern scan report, whether it comes from VirusTotal, urlscan.io, Hybrid Analysis, or ScanTotal, is really a fusion of three different kinds of checks. Once you know which part of the report is doing which job, the whole page gets much easier to read.

1. Reputation lookups. The file hash or URL is checked against databases of things that have already been seen and labelled. On VirusTotal this is the famous row of antivirus engine names and verdicts. Reputation is fast and extremely accurate for known threats, but it has a blind spot: anything new is unseen, so zero detections does not automatically mean safe.

2. Structural or heuristic analysis. The scanner looks at the shape of the thing itself, a URL with a raw IP address on a non-standard port pointing to a /bins/ directory looks suspicious regardless of whether any database has logged it yet. A file with certain structural red flags behaves the same way. Heuristics fill the time gap while fresh threats haven't made it into the reputation databases.

3. Behavioural or live analysis. The scanner actually executes the file in a sandbox or fetches the URL and watches what happens. Behavioural reports are the richest but also the slowest, because something has to actually run. Hybrid Analysis and urlscan.io are well known for this kind of output; ScanTotal's Active Analysis performs live probing on URLs without running user code.

When you look at a report that shows "0/70 engines detected, but risk score 80/100 and three behavioural red flags," those three signals are not contradicting each other. They are telling you a consistent story: nobody has reported this yet (reputation blind spot), but the shape and behaviour look bad (heuristic + behavioural warning). That is exactly the kind of pattern a fresh malicious URL produces.

Reading the Detection Count (the "X out of 70" Number)

The single most-recognised number on a security report is the detection ratio, something like "3 / 70" or "0 / 72." This is the count of antivirus or URL-reputation engines that flagged the item out of the total that were queried. It is enormously useful, and it is also the single most over-interpreted number in security.

0 detections. Not yet known to be bad. Very common for fresh files or URLs. Do not read this as "confirmed safe." Pair it with heuristic and behavioural signals.

1-2 detections. Often a false positive, especially if the flagging engines are ones with a reputation for aggressive generic rules. Legitimate installers, PowerShell scripts and developer tools trip small numbers of engines regularly. The VirusTotal community tab (the "Comments" and the detailed engine list) is the right place to sanity-check.

3-10 detections. The grey zone. At this point, at least some engines with independent classification pipelines are agreeing, which is meaningful. Look at what the engines are calling it: if several name a specific malware family, treat it seriously.

10+ detections. The community has broadly agreed this is malicious. The higher the number, the more confident the call. Treat the item as hostile and move on.

VirusTotal's own documentation is explicit about this nuance, it is a meta-scanner aggregating many independent engines, and the count is input to judgement, not a final verdict. The official VirusTotal results documentation is worth a read if you want the technical detail.

Reading a URL-Scan Report (urlscan.io Style)

URL-focused reports like urlscan.io package a different set of signals because the target is a live page, not a file. The key panels to look at:

urlscan.io in particular has a very rich public-scan interface with a community feed of recent scans, which is useful context but also written primarily for SOC analysts. The urlscan FAQ explains the result fields in depth.

Reading a File-Scan Report (Hashes, Sandboxes and Behaviours)

File reports are even denser because a single binary can be analysed from many angles. The three sections worth scanning first:

Hash and file-type header. The SHA-256 and SHA-1 hashes are the file's unique digital fingerprint. The file-type detection (PE executable, Office macro document, Mach-O, ISO, LNK) tells you what the file really is, not just what its extension claims. Any mismatch between extension and real type is a red flag, a invoice.pdf that is actually a Windows executable is a classic malware disguise.

Behavioural / sandbox report. This is the crown jewel of tools like Hybrid Analysis. When the file is executed in a controlled environment, the sandbox records what it does: files dropped, registry keys written, network connections opened, processes spawned. A sandbox report that shows an "invoice" file opening PowerShell and reaching out to a foreign IP is unambiguous, regardless of whether any AV engine has seen that particular sample yet.

Rules and IoCs. YARA rule matches, MITRE ATT&CK technique tags, and indicators of compromise (IoCs). These connect your sample to broader threat research. If your file matches a YARA rule named malware_family_info_stealer, that is a very specific and serious signal, it means a researcher has seen enough samples of this exact family to write a signature.

Want a simpler front door?
ScanTotal combines Google Safe Browsing, heuristic URL analysis and live probing into a single plain-English verdict, ideal for a first check before opening VirusTotal or urlscan.io for deeper digging.
Run a Free Scan

Reading a ScanTotal Report

ScanTotal reports are deliberately shorter and written in the style that most home and small-business users need: a single overall verdict at the top, followed by the evidence that led to it. The structure mirrors the three-signal model above:

For the deeper story on how the three engines combine and what each one is good at, we published a companion piece: The Three Layers of URL Safety, Reputation, Heuristics, and Live Probing.

Common Misreadings to Avoid

Two specific mistakes account for most of the confusion people have when they read a scan report.

Treating "0 detections" as a clean bill of health. A new malicious file can sit at 0/70 for hours or even days before the detection community catches up. Reputation is necessary but not sufficient. If you are scanning something because you already suspect it, the suspicion itself is a signal, look at the heuristic and behavioural sections before you relax.

Treating "1/70 detection" as proof of malware. Single detections by aggressive engines on otherwise clean files are genuinely common, especially for niche installers, developer tools, game mods and older legitimate software. Before you call a single detection malware, check which engine flagged it, whether the detection name is a specific family (e.g. Trojan.Win32.FamilyX) or a generic heuristic (e.g. Heur.Suspicious.Gen), and whether the community tab has analyst comments supporting or disputing the call.

What a false positive actually is

A false positive is a clean file, URL, or message that a scanner incorrectly flags as malicious. The opposite, a false negative, is a genuine threat that slips past undetected. Every scanner faces a trade-off between these two, because the signals that catch unknown malware (unusual API calls, suspicious code patterns, weird network behaviour) are also present in plenty of legitimate software.

If a scanner tunes itself to never miss a threat, it ends up flagging lots of perfectly fine files. If it tunes itself to never flag a clean file, threats slip through. The sweet spot is somewhere in the middle, and different vendors pick slightly different points on that curve depending on their customers and philosophy.

False positives aren't a sign of a broken scanner. They're a normal consequence of the mathematics of detection: the more aggressively you look for novel threats, the more legitimate files you'll catch by accident. The good scanners minimise false positives aggressively; none eliminate them.

Why false positives happen

1. Shared tooling with malware

Malware authors use the same compilers, packers, and installer frameworks as legitimate developers. When a security engine flags a specific packer or installer format, every file using that packer becomes suspicious by association. Game anti-cheat tools, DRM-protected installers, and compressed executables are frequent casualties.

2. Overlapping code patterns

Heuristic engines look at what a program does or could do. Hooking keyboard input, injecting into another process, modifying system files, hiding its own window, all of these are textbook malware behaviours. They're also exactly what legitimate accessibility software, productivity tools, remote administration software, and parental controls need to do. A well-written parental-control app can trip half a dozen malware signatures purely on architecture.

3. New releases with no reputation

Many scanners weight their verdict by how long a file has been seen in the wild and how many other users have encountered it. A brand-new release of a small-publisher tool has zero history. Several engines will report "unknown, possibly suspicious" for the first few days, and that reads as a detection even when nothing is actually wrong. This is particularly common with indie developer tools, niche open-source software, and newly-signed installers.

4. Developer-signed binaries without widespread distribution

A legitimately code-signed binary from a small developer, think a Python developer shipping a compiled utility, looks structurally identical to malware that steals a certificate. Until the certificate and publisher build up trust, every binary they ship gets extra scrutiny.

5. Shared hosting reputation

For URLs, the biggest source of false positives is shared infrastructure. If a phishing site gets hosted on a major CDN, the CDN's IP addresses can temporarily carry threat reputation. Every other site on that IP, entirely unrelated, can show up as "served from an IP associated with malicious activity" until the database catches up.

6. Cache staleness

Detection databases update constantly, but they don't update instantly everywhere. A URL that was briefly compromised, cleaned up, and now safe might still be flagged for hours or days until the cache refreshes. Conversely, a URL that was clean and is now compromised might not be flagged for a similar window.

Where false positives come from A Venn diagram of three overlapping circles labelled aggressive heuristic rules, new rare or packed files, and code that resembles known malware. A detection is most likely to be a false positive where these three overlap. Aggressiveheuristics New, rare orpacked files Code that lookslike malware FALSEPOSITIVE
A false positive is most likely where all three overlap: a cautious scanner meets an unusual-but-legitimate file whose code happens to resemble something malicious. None of the three alone is proof of anything.

How to verify a detection in four steps

1Look at the engine count

If you're using a multi-engine service, how many engines fired? One or two out of sixty is very different from twenty out of sixty. A lone-wolf detection, especially from an engine you've not heard of, is the single strongest signal that you're looking at a false positive. Most of the well-established engines (kept intentionally unnamed here because this applies across vendors) share core signature data, so when most of them agree a file is clean, they're usually right.

2Check the digital signature

On Windows, right-click the file, Properties → Digital Signatures. On macOS, codesign -dv --verbose=4 /path/to/app in Terminal. On Linux, check package signatures against the distribution's keyring.

A valid signature from a known publisher that matches the distributor you downloaded from is a strong legitimacy signal. An expired certificate, a mismatched name, or no signature at all changes the picture.

3Download again from the official source

Go to the publisher's actual website (typed by hand, not clicked from search results) and download the file fresh. Compare the SHA-256 hash against what you have and, ideally, against a hash the publisher publishes alongside the download.

This catches two things: tampered downloads (which were legitimately flagged) and download-mirror corruption (which produced an accidental "bad hash" match). If the fresh hash matches and the publisher's page confirms it's the intended build, you have a file that's almost certainly what it claims to be.

4Wait and rescan

Detection databases update multiple times a day. A false positive on a new release often clears within 24-48 hours as vendors either confirm the detection was correct (rare, when other signals check out) or update their rules. Rescanning a day later is free and informative. If a single-engine detection remains for a week on a file that's otherwise verified, the detection is almost certainly wrong and can be reported to the vendor.

When a "false positive" is actually real

The trap to avoid is labelling every detection you don't like as a false positive. Some patterns should make you pause before assuming the scanner is wrong:

The three categories of browser warning

Most browser warnings fall into three broad buckets, and knowing which bucket a warning belongs to is half the battle:

Reputation warnings come from Google Safe Browsing (Chrome, Firefox, Safari all use it, though Firefox and Safari maintain their own lists too), Microsoft SmartScreen (Edge and Windows), and per-browser heuristics. These are the most serious warnings, when the browser says "deceptive site", it's because another user already got phished there.

Reputation warnings (take these seriously)

"Deceptive site ahead" (Chrome) / "Reported phishing page" (Safari) / "Reported web forgery" (Firefox)

Source: Google Safe Browsing / similar · Severity: High

The browser has checked the URL against a phishing blocklist and found a match. Somebody, another user, an automated crawler, a partner service, reported this URL as phishing, and the report was verified.

Safe to bypass? Almost never. False positives exist but are rare and usually clear within a day or two of the site being re-evaluated. If you're certain you need to access the specific site (legitimate testing, verifying a report), do it from an isolated machine with no credentials at hand.

Common real causes: the site is a copy of a real service's login page, a fake shopping site, a credential-harvesting page hosted on compromised infrastructure.

"Dangerous site" / "The site ahead contains malware"

Source: Google Safe Browsing · Severity: High

A stronger variant of the deceptive-site warning. Instead of phishing, this URL has been associated with serving malware, drive-by downloads, exploit kits, fake software bundles.

Safe to bypass? No. The warning specifically flags sites that compromise the visitor just by being visited, without the visitor needing to enter anything. Treat it as authoritative.

"Windows protected your PC" / SmartScreen download block

Source: Microsoft SmartScreen · Severity: Medium-High

Microsoft's reputation service has either identified a file as malicious or hasn't identified it as known-good. The warning wording differs slightly between the two cases, "Windows protected your PC" is often shown for low-reputation-but-not-confirmed-malicious files, while stronger wording is used for known malware.

Safe to bypass? Depends on the context. If you downloaded a brand-new release of legitimate software from the publisher's official site and SmartScreen blocks it on "low reputation", that can be a genuine false positive, reputation takes time to build for new releases. If you downloaded something you don't recognise, or from a source you don't fully trust, the warning is likely right.

Before bypassing: scan the file through an independent multi-engine service like ScanTotal, check the digital signature, and confirm you downloaded from the publisher's real domain.

Certificate warnings (often cosmetic, sometimes serious)

Certificate warnings don't mean the site is malicious. They mean HTTPS can't verify you're talking to who you think you're talking to. That's important but it's a narrower issue.

NET::ERR_CERT_DATE_INVALID / "Your connection is not private"

Source: Browser TLS layer · Severity: Varies

The site's certificate has expired or is not yet valid. Certificates are signed with a date range; once they expire, browsers refuse to trust them. Or, equally often, your computer's clock is wrong, making every certificate look invalid relative to the wrong "current date".

First check: is your system clock correct? Windows, macOS, and Linux all have automatic time-syncing that can drift if a machine has been offline or had its battery die. Set the clock correctly and reload; if the warning disappears, you had a clock issue, not a certificate issue.

If the clock is correct and the certificate really is expired: the site is poorly maintained. Don't enter credentials, card numbers, or anything sensitive, there's no way to verify you're actually talking to the legitimate site. For read-only browsing of a low-risk site, bypassing is usually safe; for anything involving authentication or payment, leave.

NET::ERR_CERT_COMMON_NAME_INVALID / ERR_CERT_AUTHORITY_INVALID

Source: Browser TLS layer · Severity: Medium-High

The certificate is valid but doesn't match the hostname, or was signed by an authority the browser doesn't trust. Common causes: the site has an internal or self-signed certificate (common inside corporate networks), the server was misconfigured, or, more worryingly, someone is attempting to intercept the connection.

Inside a corporate/work network: this can be legitimate, especially for internal services. Your IT team likely has a root certificate to install.

On a public network you don't control: treat as suspicious. A mismatched certificate on a public site can indicate a man-in-the-middle attempt, especially on untrusted WiFi. Do not bypass.

NET::ERR_CERT_REVOKED

Source: Browser TLS layer · Severity: High

The certificate was explicitly revoked by the issuing authority, usually because the private key was compromised, the domain changed hands, or the certificate was issued in error.

Safe to bypass? No. Revoked certificates are the strongest "something is wrong here" signal in the TLS system, and by the time a browser surfaces the revocation, the issue is serious.

Mixed content and insecure-form warnings

"Not secure" label in the address bar

Source: Browser itself · Severity: Low-Medium

The page is served over plain HTTP, or mixes HTTPS with HTTP resources. Most common on older sites that haven't migrated to HTTPS.

Impact: somebody on your network can read and modify what you see and what you send. On your home network that's usually fine; on public WiFi, a hotel network, or a work network you don't control, it matters more. Never submit passwords, payment info, or personal details on an HTTP-only page.

"This form is not secure" (HTTP form on HTTPS page)

Source: Chrome, Firefox · Severity: Medium

A form that would submit its data over HTTP, even though the page containing it is HTTPS. Modern browsers block this by default, because the form submission itself is the sensitive moment. Don't submit, there's no way for the submission to be private even though the page looked secure.

A short decision tree

When you hit any browser warning, work through these questions in order:

  1. Is the warning about reputation (phishing, malware, dangerous site)? → Don't bypass unless you have a very specific, technical reason and an isolated environment.
  2. Is the warning about a certificate? → Check your system clock first. If clock is correct, certificate issue is real. Don't submit any credentials or payment details. Continue browsing read-only only if the site is low-value.
  3. Is the warning about insecure content? → Fine to browse; don't submit anything sensitive. Prefer finding an HTTPS alternative.
  4. Do you need to interact with this site right now? → If not, close the tab and come back later or via a different route. Most "must bypass now" decisions turn out to be avoidable.

Layer 1: Reputation (Google Safe Browsing)

Result: No match

Google Safe Browsing had no record of this URL. That on its own isn't reassuring, fresh phishing URLs often don't make it into reputation lists for hours or days, because somebody has to encounter, report, and verify them first. A "no match" verdict from reputation alone is absence of evidence, not evidence of safety.

This is where a lot of simpler scanners would stop. "Clean on all engines checked." A user seeing that response might assume the URL is fine, click through, and hand over their credentials. Reputation-only scanning is how fresh phishing URLs stay effective for the first 12-48 hours of their lifespan.

Credit where it's due: Google Safe Browsing is exceptional at what it's designed to do, distribute known-bad verdicts to billions of devices at low latency. But by design, it's retrospective.

Layer 2: Heuristic analysis

Heuristic analysis scores a URL on structural features, without fetching it. It's pure pattern-matching against the URL string itself. Our scanner runs a ten-check scoring system; here's what fired on this one:

Heuristic risk score: 55 / 100 (HIGH) ✓ HTTP instead of HTTPS (+15) ✓ Suspicious path keywords detected: "auth", "signin", "secure-verification" (+20) ✓ Excessive subdomains (4+ segments) (+10) ✓ Very long URL (+5) ✓ File extension ".html" in directory-style path (+5)

Let's unpack what each check found:

HTTP, not HTTPS

Any modern service with a login form uses HTTPS. A page claiming to be a secure email login and served over plain HTTP is a contradiction. Legitimate services dropped HTTP for login flows around 2016; seeing it in 2026 on a signin page is almost conclusive.

Suspicious path keywords

The path /auth/signin/secure-verification/ is pattern-matched against a short list of terms that appear disproportionately in phishing URLs: auth, signin, login, secure, verify, verification, update. Three of them show up in this path alone. Legitimate signin URLs rarely concatenate that many "security" words, they just say /login/ or similar. Phishing URLs stuff them together because the attackers expect victims to skim-read the URL and pick up reassurance from familiar words.

Excessive subdomains

Attackers lean on a pattern where the first part of the hostname looks like the service they're impersonating, gmail-support.mailhost[.]example, so a glance suggests "this is something Gmail-related." Heuristics count the number of dots in the hostname; a path like [a].[b].[host].xyz has four segments, which is unusual for genuine commercial domains that typically use two or three.

Long URL and explicit .html filename

Real consumer services hide filenames behind routing frameworks. A URL that ends in /index.html suggests either a static-site host (legitimate but unusual for a signin page) or a cheaply-deployed phishing kit, which is a bundle of HTML/JS files an attacker uploads to a compromised host without any application framework. The long overall URL is a weaker signal but nudges the score up.

So by this stage we already have enough to warn the user strongly: reputation doesn't know it, but the URL's shape is obviously wrong for a legitimate login page. A more complete picture comes from the third layer.

Layer 3: Active probing

Active probing fetches the URL in a sandboxed environment and inspects what's actually served. Not just headers, the actual response content (within reason, for safety).

Result: Suspicious, form behaviour doesn't match legitimate email-provider patterns

Content-Type: text/html (as expected for an HTML page)

Response size: ~45 KB (small for a modern login page)

Form submission target: different hostname to the page being served

Additional: no reference to a real OAuth provider, no mention of a real authentication endpoint, page title is a generic "Sign in" string

The form-target mismatch is the killer signal. The page tells the browser: "when the user submits their credentials, send them to a different domain." On a legitimate email provider that can happen for sound reasons, SSO redirects, tokenised POSTs, but not to an unrelated third-party domain the victim has never heard of. Here, the form action posted to a host that wasn't the page host and wasn't any recognised authentication service.

The "no reference to a real OAuth provider" signal reinforces it. A real modern email login page has references to the provider's own authentication infrastructure visible in the source, script paths, meta tags, canonical links. This page had none of that. It was a hand-crafted copy of the login page's visual layout with a hollow interior.

Combined verdict

Across the three engines:

The combined verdict was high risk / likely phishing, and the scanner recommended not visiting the URL at all. Had the user relied only on the reputation layer, they'd have seen "clean" and likely visited. The other two layers are what made the verdict correct.

A Quick Reading Workflow

If you scan something and are not sure how to read the result, this takes about a minute:

  1. Start with the headline verdict. Big red banner, high detection count, or explicit "phishing detected"? Trust it and move on.
  2. If it is borderline, look at the detection ratio. 0 means unknown, not safe. 1-2 means investigate. 3+ means probably real.
  3. Look at the structural indicators. If the URL has a raw IP, odd port or malware-named path, the heuristic panel will say so plainly. Weight these heavily for unknown URLs.
  4. Check the behavioural panel if there is one. Sandbox actions and live-probe findings are the last line of defence when reputation is silent.
  5. Cross-check on a second scanner if the stakes are high, money, credentials, or a business-critical file. VirusTotal for files, urlscan.io for URLs, ScanTotal for a consolidated consumer-friendly read.

The best scan reports in the industry, VirusTotal, urlscan.io, Hybrid Analysis, are extraordinarily valuable resources and ones we rely on ourselves. They are written for professionals, which is right for their audience, and it is why a friendlier first-pass layer is useful on top. Read them as evidence boards rather than yes/no oracles, and a lot of the mystery goes away.

Security Tools VirusTotal urlscan.io Threat Intel How-To

Want a plain-English first-pass scan?

Paste any URL, file or text into ScanTotal for a friendly verdict in seconds, free and private.

Open Scanner

Sources & Further Reading

Related Articles

The Three Layers of URL Safety
Reputation, heuristics and live probing, how the three signal types combine.
How to Check If a Link Is Safe
The practical workflow for vetting a suspicious URL.
Is This File Safe?
Checking a download for malware before you open it.