Online malware analysis services: Upload Samples Without Leaking Data or Tipping Off Attackers

Uploading a suspicious file or URL to a public analysis service is a disclosure decision, and many organisations make it hundreds of times a day without a policy, from analyst browsers and from automated playbooks. Services such as VirusTotal, Hybrid Analysis and urlscan.io give fast multi-engine verdicts and sandbox behaviour, but what you submit can be shared with partners, paying customers or the public, and can tell an attacker that their tooling has been found. This guide explains what each kind of service does with a submission, how to decide between hash lookup, private analysis and public upload, how to configure SOAR and email integrations so they do not leak, how TLP applies, and what to monitor. It is written for SOC analysts, incident responders, threat intelligence teams and the engineers who build their automations. Running your own sandbox is covered in the Malware Sandbox Guide.

Key takeaways

• Search before you submit. A hash or URL lookup reveals nothing new; an upload hands over the content. Make lookup the default and upload the exception.
• Public means public. VirusTotal shares scanning reports with its public community and says the contents of submitted files may be shared with premium customers; urlscan.io public scans appear in public search results.
• Private options exist but change what you get. VirusTotal Private Scanning keeps submissions to your organisation and deletes them after a retention period, but its reports contain no antivirus verdicts.
• Automation is where most leaks happen. Researchers found password reset links, shared document links and API keys searchable on urlscan.io, largely because security tools and SOAR playbooks submitted URLs as public scans.
• URLs carry credentials. Pre-signed links, reset tokens and API keys in query strings are non-human credentials; treat a public URL submission containing one as a credential leak and rotate.

What online analysis services do with your submission

"Online malware analysis service" covers three different things, and each handles data differently. Check the current terms of any service you use: the summaries below reflect the providers' documentation as read on 28 October 2026.

Two consequences follow. First, a "quick check" of an internal document someone forwarded as suspicious can place that document in a searchable commercial corpus. Second, attackers watch these services too: a sample built for one target that suddenly appears on a public service tells its author it has been found, which may prompt them to change infrastructure before you have scoped the intrusion.

Lookup, private analysis or public upload: a decision model

Classify what you hold before choosing a service. The questions are: could the item contain [Organisation] or customer data, is it a targeted sample, and is there an incident in progress?

• Small teams: a written rule of "lookup by default, private scan for anything that might be ours, public upload only for commodity samples" covers most cases without new tools.
• Large SOCs and MSSPs: centralise submissions through one integration with enforced visibility, and log every submission with the analyst, case number and visibility used.
• Regulated environments: treat each external service as a data processor or recipient in your data protection assessment, and record lawful basis and transfer location for anything that may contain personal data.

Configuring integrations so they do not leak

Positive Security's research (November 2022) showed how leaks happen in practice. Public urlscan.io scans exposed password reset and account creation links, DocuSign signing requests, shared Google Drive, Dropbox and SharePoint links, invoices and API keys. The cause was mostly automation: security tools and SOAR playbooks submitting URLs as public scans, including one widely used integration pack that defaulted to public visibility and overrode user settings until it was fixed in May 2022. In the researchers' bait-link test, about half of the links sent were publicly scanned. urlscan.io responded with deletion rules for leaked patterns, clearer visibility defaults in the interface and a team-wide maximum visibility setting.

1. Inventory every integration that submits to an external service: email security, secure web gateway, SOAR, EDR, ticketing plug-ins, browser extensions and analyst scripts. Record the API key used and its owner.
2. Set visibility explicitly in code (for urlscan.io, the visibility parameter on every submission) rather than relying on account defaults, and set the account or team maximum visibility to unlisted or private.
3. Prefer lookup endpoints in playbooks: query by hash or URL first, and branch to submission only when nothing is known.
4. Strip identifiers from URLs before scanning: recipient email addresses, tracking IDs and query parameters that look like tokens.
5. Use a custom user agent for your integrations, as the researchers recommended, so your own submissions are traceable.
6. Review submitted scans monthly from the account history, and delete or report anything sensitive.
7. Test with bait links: send a harmless unique URL through the email path and check whether it appears publicly.

Where identity fits: API keys and credentials in submissions

Two non-human identity problems sit inside this workflow.

• Credentials inside submitted URLs: pre-signed cloud storage URLs, password reset tokens, magic links and API keys in query strings are bearer credentials. If one is submitted publicly, treat it as leaked: revoke or rotate it, expire the link and review access logs. The researchers recommended that service owners never accept API keys in GET parameters and expire reset links quickly. See the Leaked Credential Response Playbook.
• The service API keys themselves: VirusTotal, urlscan.io and sandbox API keys used by SOAR are NHIs with access to your submission history and, for premium tiers, to sample downloads. Store them in a secrets manager, give each integration its own key, and rotate when staff leave. A leaked enterprise key exposes what you have been investigating. See the SaaS API Token Security Guide.
• Samples that contain credentials: infostealer logs, configuration files and scripts recovered during an incident often contain your own passwords and tokens. Rotate first; never upload them to a public service.

TLP and sharing samples deliberately

Public upload is one form of sharing; the Traffic Light Protocol is how you share on purpose. FIRST's TLP 2.0 (authoritative since August 2022) defines TLP:RED (individual recipients only), TLP:AMBER (need to know within the recipient's organisation and its clients), TLP:AMBER+STRICT (recipient's organisation only), TLP:GREEN (within the community, not via public channels) and TLP:CLEAR (no limit). A TLP:GREEN or more restrictive sample must not go to a public service, because a public upload is disclosure to the world.

• Label on receipt: record the TLP of samples and indicators received from partners, ISACs or vendors in the case record, and enforce it in automation (TLP is defined for human use; automated handling is left to the designers of each exchange).
• Share after containment: once a targeted sample is scoped, share it with your sector community under TLP:AMBER or GREEN through MISP or a sharing platform, then decide whether to make it public. See the Traffic Light Protocol Guide and the MISP Threat Sharing Guide.
• Public upload as a contribution: for commodity malware, uploading helps every defender. VirusTotal itself encourages uploading files found malicious in private scanning to the standard service to share the threat.

Reading results safely

• Zero detections is not clean: new or targeted samples often score zero, and sandbox reports can show nothing because the sample detected the environment (T1497 Virtualization/Sandbox Evasion) or waited for user interaction.
• Private reports differ: VirusTotal Private Scanning reports contain no antivirus verdicts, so compare like with like when deciding.
• Contacted infrastructure is not all malicious: samples contact legitimate sites to test connectivity; validate before blocking.
• Do not visit indicators from analyst workstations: open sandbox-extracted URLs and downloads only from isolated analysis environments.
• Feed detections, not just tickets: turn behaviour into Sigma and YARA content. See the Sigma Rules Guide.

An analyst procedure for one suspicious item

1. Record: open or update the case, note the source of the item, any TLP label and whether it came from inside [Organisation].
2. Hash and look up: compute SHA-256 locally and search it; for URLs, search the URL or domain without submitting a new scan.
3. Classify: apply the decision model above. If unsure whether the item contains [Organisation] or customer data, treat it as if it does.
4. Analyse privately first: use the private or in-house sandbox, from an isolated analysis host, never from a corporate workstation.
5. Decide on sharing: the incident lead approves any public upload of a sample linked to an open incident; record who approved and when.
6. Act on results: block confirmed indicators, rotate any credential found in the sample or URL, and attach the report to the case.

Detection and measurement

Treat submissions to external services as data flows you monitor.

• Proxy and DNS logs: uploads (HTTP POST with large bodies) to known analysis service domains from hosts that are not analyst or integration hosts.
• Integration logs: visibility value on every urlscan.io submission; any "public" value outside the approved commodity path is an alert.
• Account history: monthly export of submissions per API key for review against the decision model.
• Brand and leak monitoring: periodic searches on public services for your domains, email domains and document-sharing URLs, so you find what others (or your own tools) submitted.

Framework mapping

Common failure patterns

• Playbooks on public by default: an email security or SOAR integration submits every reported URL publicly, publishing customers' reset links and shared documents, the pattern behind the 2022 urlscan.io findings.
• Uploading the incident: an analyst uploads a bespoke implant from a live intrusion to a public service before containment, and the attacker rotates infrastructure.
• Checking a "suspicious" business document: a forwarded contract or HR file goes to a multi-engine scanner and becomes available to premium customers.
• One shared API key: every analyst and integration uses the same enterprise key, so submissions cannot be attributed and a leak exposes the whole history.
• Trusting a clean verdict: zero detections or a quiet sandbox run closes the ticket on a targeted sample that evaded the environment.
• Ignoring TLP on received samples: a TLP:AMBER sample from an ISAC is uploaded publicly, breaching the sharing terms and the source's trust.

Practitioner checklist

• Publish a submission decision model: lookup by default, private for anything possibly containing your data, public only for commodity samples.
• Inventory every tool and playbook that submits to external analysis services, with its API key and owner.
• Set visibility explicitly in every integration and cap account or team visibility at unlisted or private.
• Strip identifiers and tokens from URLs before scanning, and never submit internal or pre-signed links.
• Store service API keys in a secrets manager, one per integration, and rotate them on staff changes.
• Record TLP for received samples and block public upload of anything above TLP:CLEAR.
• Monitor proxy logs for uploads to analysis services from unexpected hosts and review submission history monthly.
• Search public services for your domains and sharing links quarterly, and rotate anything found.

Standards and references

• FIRST: Traffic Light Protocol (TLP) 2.0
• VirusTotal: How it works
• VirusTotal: Private Scanning
• urlscan.io: Scan visibility
• CISA: Malware Next-Generation Analysis
• Positive Security: urlscan.io data leaks research
• MITRE ATT&CK: Virtualization/Sandbox Evasion

Related NHI Mgmt Group resources: Malware Sandbox Guide · Malware Analysis Guide for Defenders · Traffic Light Protocol Guide · Phishing Incident Response Playbook · Leaked Credential Response Playbook