Skip to main content
Sandfish

Project

About Sandfish

A phishing sandbox with automatic browser interaction, email and QR code analysis, archive replay, and evidence search across related phishing activity.

Objective

Sandfish is a phishing sandbox for investigating suspicious websites and emails. Automatic browser interaction can follow multi-step phishing pages with synthetic form data. Analysts can inspect captured network requests and screenshots, analyze QR code destinations, replay WACZ archives, and compare phishing kits through recorded evidence.

The objective is to make each conclusion traceable to an observation. A result shows what Sandfish observed, which processing completed, which limits applied, and why a rule matched.

Choosing a tool? Read Sandfish vs other phishing tools for comparisons with urlscan.io, ANY.RUN, VirusTotal URL, Cloudflare Radar, Hybrid Analysis, and Joe Sandbox. The article includes feature and price tables, with sources and case evidence.

What Sandfish analyzes

Sandfish accepts four source types. Start a supported submission from the home page.

SourceProcessing
URLOpens the live page in an instrumented browser and records its network traffic.
HTMLServes the file from a synthetic origin. Absolute resource URLs can still load from the live web.
WACZReplays recorded web responses and analyzes the replayed session.
EMLParses the message, records email evidence, and can create related web analyses.

During automatic browser interaction, live captures can select controls, submit synthetic form data, follow new tabs, and receive downloads within fixed limits. This can expose credential collection and payment stages that appear only after interaction. The report records the interaction actions and stop reason. URL and HTML captures produce WACZ archives for later inspection and replay.

Web evidence includes requests, redirects, screenshots, page snapshots, cookies, runtime window names, identifiers, JavaScript fingerprints, infrastructure, TLS certificates, and delivered files. Behavior-event coverage depends on the capture browser. Email evidence includes headers, MIME parts, links, attachments, and authentication results. Header claims remain separate from independently verified authentication.

Sandfish also decodes QR codes in captured screenshots and links each result to its source frame. Eligible HTTP(S) destinations from live captures can create related analyses. Each completed destination analysis has its own evaluation and keeps the source group's visibility. Replay can decode QR codes but does not start new live captures from them.

Evidence before conclusions

Signals identify matched rules and link to supporting source records. Processing status, evidence completeness, score, and verdict answer different questions. The documentation explains the review order.

The current scoring policy combines risk findings and limits the contribution of correlated findings. Assurance findings can provide a limited credit for evidence of legitimacy. The evaluation records the policy version, risk score, assurance credit, and final score. Assurance cannot reverse a malicious verdict under this policy. The score is not a probability.

Sandfish preserves completed evaluation generations. A rescore applies current rules to stored facts without another browser run. New web evaluations also retain their input snapshots and reference data. Older evaluations can lack those inputs. Replay and recapture create separate analysis members because they can observe different content.

An empty signal list can mean that no rule matched or that required evidence was unavailable. The current policy gives a benign verdict only to a complete evaluation with no scored risk. That verdict describes the available evidence under the recorded policy. It does not prove that a source is safe.

Investigation tools

  • Search evidence with text queries or advanced AND/OR conditions. Follow evidence links to find other visible analyses with matching values.
  • Browse analyses and inspect requests, source content, screenshots, findings, and related group members.
  • Explore impersonated brands recorded by current evaluations. A shared brand does not establish a shared kit or operator.
  • Use an analysis's Similar tab to compare phishing-kit implementation evidence or find related activity through selected operator-controlled identifiers.
  • Use the phishing analysis API to automate source submission, read results, and export supported evidence collections. The OpenAPI schema defines the request and response fields.

Records and relationships

An analysis group represents one submitted source and its related analyses. Each analysis represents one email parse, web capture, or replay. An analysis can have several evaluation generations. Its current evaluation supplies the displayed verdict. Related email content, QR destinations, recaptures, and replays remain separate members. A group does not have one combined threat verdict.

A phishing kit groups analyses with substantial shared implementation evidence. This can include documents, document structure, visible text, JavaScript, or a reviewed kit signature. A named signature can identify an implementation before enough deployments exist to form a cluster. A kit describes how pages are built. It does not identify who deployed them.

An actor groups analyses that reuse selected operator-controlled identifiers. It records a technical relationship. It does not attribute activity to a person, organization, or country.

Interpret every relationship with its evidence

Shared hosting, a common library, or one public service can connect unrelated sites. Open the member analyses and review the supporting facts before you draw a conclusion.

Discovery and monitoring

Configured feed sources can supply public URLs for analysis. Sandfish supports public phishing reports, VirusTotal community discovery, and discovery from observed hosting infrastructure. Operators select which sources run. Each source has its own request limits. Provider labels select candidates; they do not become Sandfish findings or contribute to the score. Automatically admitted feed analyses are public.

Destination monitoring is a separate feature for administrators. It can collect available traffic from supported Telegram destinations and, when enabled, Webhook.site HTTP destinations. The reader shows stored evidence, collection state, and coverage limits. Monitoring does not change completed evaluations or automatically associate a message with a particular case or victim.

Access and privacy

Public analysis groups and ordinary captured evidence are readable without an account. Their source content and captured requests can contain sensitive data. Private groups are visible only to their owner. Private submissions require a paid plan. When visibility is omitted, paid accounts default to private; free accounts and guests default to public.

Guests have a limited daily allowance for URL and EML submissions. HTML and WACZ uploads require an account. API keys use account permissions, key scopes, and account quotas.

Payload sample downloads require an account and access to the analysis. Samples arrive in password-protected ZIP files. Sample bytes can expire while their metadata and digests remain searchable.

Collected Telegram and HTTP destination traffic, collection status, exports, and media require an administrator browser session. An ordinary account or API key does not grant this access, even when the linked analysis is public.

Related email and QR-code analyses can also visit live destinations. Review the visibility and submission guidance before submitting a source.

Collection limits

  • A capture records one environment at one time. Automation checks, permissions, missing resources, and interaction limits can prevent access to later stages.
  • Live-capture behavior events do not cover page-script API calls. An embedded frame's presence does not mean Sandfish collected its forms or text.
  • QR recognition reads screenshot pixels. Codes outside the captured viewport or codes that cannot be decoded can remain unobserved.
  • Replay supplies recorded responses, but browser state, timing, and missing archive entries can change the result.
  • A rescore cannot recover content that was never captured. New browser evidence requires a recapture or a suitable replay.
  • Dashboard trends describe the visible Sandfish corpus. Hosting locations can identify a CDN or redirect server. They do not identify an operator's location.

Review the documented limits together with the coverage and source records for each analysis.

Project principles

  1. Preserve source provenance.
  2. Keep processing status, completeness, score, and verdict separate.
  3. Make rule evidence visible.
  4. Keep kit similarity separate from actor linkage.
  5. State collection and replay limits.
  6. Avoid identity or campaign claims that the evidence cannot support.