How to Check If a Download Is Safe

In February 2026, a documented case involved a fake website impersonating the widely used 7-Zip software and distributing a modified installer. The report described how the site used HTTPS, appeared legitimate, and initially avoided detection by some security tools.

Situations like this raise an uncomfortable question: if your browser shows no warning and your antivirus reports nothing suspicious, how can you tell whether a download is safe?

This guide explains what you can realistically check, and how to reduce impact if a new threat is not yet recognised.

HTTPS does not confirm legitimacy

In the fake 7-Zip case, the website used a valid HTTPS connection. This meant the browser could establish a protected connection to the domain being visited and accept the certificate presented for that domain. It did not establish that the domain belonged to the genuine 7-Zip project or that the installer offered there was safe.

A useful way to understand the distinction is:

Browser reaches a domain

HTTPS/TLS checks the identity presented for that domain

Protected encrypted connection is established

The website and download still need to be judged separately

A malicious or misleading website can register its own domain and obtain a valid certificate for that domain. The certificate helps establish a protected connection to the named domain; it does not certify that the organisation, claim, download or content on the website is trustworthy.

This is why the presence of HTTPS should be treated as an important connection security control, not as proof that a download is legitimate.

Why antivirus may not detect a new threat

Antivirus and endpoint protection do not rely on one test. Security products may use file reputation, known threat information, behavioural signals and other detection methods. However, those systems cannot be assumed to recognise every harmful file immediately.

A newly created or modified malicious file may not yet have established reputation or widely recognised indicators. In other cases, suspicious behaviour may become clearer only after the file runs. A trusted installer may also become compromised, or a malicious file may attempt to exploit a software vulnerability that has not yet been identified or for which an effective fix is not yet available.

A simplified detection problem looks like this:

File appears

Security products compare what is currently known about it

Known or suspicious indicators may trigger detection
or
There may not yet be enough evidence to classify it confidently

New evidence and behaviour can change that assessment later

In the 7-Zip example, the installer appeared legitimate but contained additional malicious components, and not every security tool classified it immediately.

This does not necessarily mean that the security product itself was malfunctioning. It illustrates why a clean result at one point in time should not be treated as proof that a file is safe.

If you have not run the file yet

If you have downloaded a file but have not yet opened it, pause and review the following:

Check the domain carefully

Look for subtle spelling differences, missing hyphens, or recently registered domains. A quick WHOIS lookup can show whether a domain was created very recently.

Upload the file to a multi-engine scanning service

You can upload the installer to

https://www.virustotal.com

https://www.hybrid-analysis.com

https://metadefender.opswat.com

These services can provide useful additional information by analysing a file with several detection and analysis systems. A clean result does not guarantee that the file is safe, while several independent detections should increase concern and require further investigation.

Before uploading a file, consider whether it contains confidential, personal, customer, commercially sensitive or proprietary information. Public malware-analysis services should not be treated as private document-analysis tools. Do not upload sensitive business files unless you are authorised to share them and have checked how the particular service handles submitted material.

Where confidentiality matters, use an appropriate private analysis method or seek technical review rather than uploading the file casually to a public scanning service.

Pay attention to Windows warnings

If Windows displays Unknown publisher, Windows protected your PC, or another SmartScreen warning, stop and verify the file before continuing. A warning is a reason for caution, but it is not by itself proof that the file is malicious.

SmartScreen considers information such as the reputation of the file and, where applicable, the reputation and signing identity of its publisher. A legitimate new or less widely distributed application may therefore receive a warning because there is not yet enough reputation information available.

Where a publisher identity or digital signature is available, compare it with the organisation you expected to obtain the software from. An unsigned file or an unknown publisher does not automatically mean malware, but it removes one useful trust signal and should make the source of the download more important.

Compare with the official source

If possible, confirm the official domain directly from a trusted reference rather than from search results alone.

If you have already run the file

If you have already opened or installed the file and now have reason to question it, the response should depend on what happened and what the device is used for.

Useful first steps include:

• stop using the downloaded application until it has been reviewed

• run the installed endpoint protection or antivirus product and follow any remediation it recommends

• record where the file came from, approximately when it was downloaded and what actions were taken after it ran

• review whether unfamiliar software, processes or security alerts have appeared

• consider whether important accounts or administrative credentials were used on the device after the questionable file was executed.

If there are reasonable signs that the device may actually be compromised, isolation becomes more important. Disconnecting an affected device from wired, wireless and other network connections can help limit further communication or spread while it is being assessed. This is also part of the NCSC’s response guidance for malware infections.

If credentials may have been exposed, account recovery should normally be carried out from a known clean device. Important passwords or sessions may need to be reset or revoked, particularly for administrative and business accounts, while taking care not to remove access needed for recovery.

Where confidence in the device cannot be restored, cleaning individual files may not be sufficient. Rebuilding the device from a known good operating system installation and restoring verified clean data can provide a more reliable recovery path. The NCSC similarly advises wiping and reinstalling where malware cannot be reliably removed.

Not every uncertain download means that a device has been compromised. The purpose of these steps is to preserve options and reduce further risk while the situation is reviewed.

DNS filtering as an additional layer

DNS filtering can provide another useful layer by checking domain requests before a device connects to an online destination. Depending on the service and policy, it may block known malicious domains and selected categories such as newly registered or higher risk domains.

For a downloaded program attempting to communicate externally, the path may look like this:

Downloaded software runs

Software attempts to contact an external domain

DNS request reaches the configured filtering resolver

Filtering service checks the destination

Blocked destination: the normal DNS connection cannot continue
or
Allowed destination: the connection may continue

This can reduce exposure if malicious software depends on a domain that the filtering service already recognises or that the configured policy blocks.

However, DNS filtering should not be treated as a guarantee. A malicious program may use a destination that has not yet been classified, abuse a legitimate online service, use another permitted DNS path, or communicate in a way that does not depend on the filtering decision expected by the organisation.

DNS filtering also does not inspect the complete contents of the downloaded file. Its value is as another control around where the device can connect, not as a replacement for endpoint protection or careful download verification.

Reducing impact when detection lags

When a threat is not immediately recognised, the aim changes from expecting perfect prevention to limiting what the file can do and preserving a reliable recovery path.

Detection can lag because a malicious file is new or modified, because reputation information has not yet developed, because harmful behaviour only becomes visible after execution, or because the attack depends on a weakness that existing controls do not yet recognise.

Useful protective measures include:

• avoiding routine use of administrator accounts for ordinary work

• restricting software installation where appropriate

• keeping the operating system, browser and applications supported and updated

• maintaining active endpoint protection

• using DNS and network controls to limit unnecessary outbound communication

• monitoring important devices and accounts for unusual behaviour

• maintaining recent, separate backups of important business information

• knowing how an affected device or account could be isolated and recovered.

The purpose of these layers is not to claim that every harmful file will be stopped. It is to make compromise harder, reduce the possible impact and give the organisation practical recovery options if prevention fails.

Cloud storage is not the same as backup

Services such as Microsoft OneDrive, Dropbox, and Google Drive replicate changes across devices. They include version history and retention features, which are useful, but they are not independent backup systems.

If malware encrypts or deletes files, those changes can synchronise to cloud storage. While recovery is often possible, replication services are designed to mirror changes, including unwanted ones.

If an attacker gains access to your account, replication can propagate deletions or encryption across devices before you notice.

Independent cloud backup with versioning, retention controls, and protection against intentional deletion provides a separate recovery path that does not rely on the affected device or user account.

We explain the architectural difference between replication and independent backup in more detail in this video.

Security relies on layers and recovery planning

When a browser, antivirus product or endpoint protection platform shows no warning, there may still be no immediate technical signal that a file is unsafe. No single product, scan result, website certificate or warning indicator can provide certainty.

A more realistic security and resilience model is:

Prevent
reduce the opportunity for unsafe software to reach or run on the device

Detect
identify suspicious files, behaviour, connections or account activity

Contain
limit what an affected device, application or account can reach

Recover
restore clean systems, important information and access to business services

Learn
understand how the incident occurred and which controls were insufficient

Improve
adjust configuration, procedures and protection before normal operation resumes

Recovery is therefore part of security rather than something considered only after security has failed. For a business, that includes knowing that important data can be restored, that backups are independent enough to survive the incident, that important accounts can be recovered, and that there is a practical way to continue or restore essential operations.

The NCSC similarly treats backups as an important part of organisational response and recovery, and recommends that organisations know how to restore their important data rather than simply assuming that a backup exists.

The objective is not perfect certainty. It is to reduce risk, recognise problems as early as practical, limit their effect and maintain a credible path back to normal operation.

Further Guidance and Support

This guide forms part of a broader layered security approach. For structured guidance on security and resilience planning, see our Security and Resilience page.

For information about practical implementation and ongoing support, you can review our IT services and local IT support coverage across London, Hertfordshire, and Essex.

Author
Elías Sánchez
IT Support Consultant
Evening Computing

This guide was prepared by Elías Sánchez with research and drafting assistance from AI tools. All technical content has been reviewed and adapted for clarity and accuracy.

Last reviewed
17 August 2026