TTechclick ⚡ XP 0% All lessons
Zscaler · ZIA · Cloud SandboxInteractive · L1 / L2 / L3

Zscaler ZIA Cloud Sandbox — Catch the File Nobody Has Seen Before

Your antivirus knows yesterday's malware. But the file a fresher just downloaded was compiled an hour ago — no signature exists yet. Cloud Sandbox detonates that unknown file in an isolated cloud VM and decides its fate before it ever lands. Watch the pipeline, then master the one policy choice every admin gets wrong.

📅 2026-05-31 · ⏱ 11 min · 2 live demos · L3 depth · 🏷 10-Q assessment + AI Tutor inline

⚡ Quick Answer

ZIA Cloud Sandbox explained the AI-era way — watch an unknown file get hash-checked, detonated and verdicted, then learn the Quarantine vs Allow-and-Scan patient-zero trade-off and AI Instant Verdict in 11 minutes.

🎯 By the end you will be able to

Read as:

Pick what you came for — jump straight to it

1

Why Sandbox?

Signatures miss the zero-day. Sandbox is the patient-zero defence.

 2

The Pipeline

Hash lookup → cache → detonate → verdict → action. Watch it run.

 3

Rule & First Action

Quarantine vs Allow-and-Scan, AI Instant Verdict, file types.

 4

The Report

Detonation report, MITRE mapping, gotchas, verification.

🧠 Warm-up — 3 questions, no score

Just notice which ones make you pause. We answer all three inside the lesson.

1. A user downloads a brand-new file Zscaler has never seen. What decides if it gets detonated?

Answered in Path 2 — The Pipeline. (Spoiler: known hashes skip detonation.)

2. Allow & Scan lets the first user download the file immediately. What's the risk?

Answered in Path 3 — Rule & First Action.

3. You enabled a Sandbox Rule but encrypted downloads still aren't being detonated. What's missing?

Answered in Path 3. SSL inspection is the silent prerequisite.

Most engineers think…

"Cloud Sandbox scans every file a user downloads — that's why it's slow."

Wrong on both counts. Sandbox doesn't scan every file, and a well-tuned policy isn't slow. Known files are answered instantly from a verdict cache — only the genuinely unknown, first-time-seen file gets detonated. And the real design decision isn't speed, it's a trade-off most admins fumble: do you hold the unknown file (Quarantine) or let the first user have it and analyse in parallel (Allow & Scan)? Get that wrong and you either annoy 5,000 users or create patient zero. This lesson rewires that instinct.

Why a sandbox exists — the patient-zero problem

Think of airport security. The X-ray machine has a database of known dangerous shapes — it catches the obvious knife instantly. That's your signature AV. But a clever attacker brings something the database has never seen. For that, you need a separate room where security makes the person open the bag and demonstrate the object actually works. That second room is the sandbox.

In ZIA, signature AV and Cloud Sandbox are two layers. Signature engines catch known malware in milliseconds. But the file a Wipro analyst downloaded five minutes ago may have been compiled today — no signature exists anywhere on earth yet. If you only had signatures, that user becomes patient zero, and the breach spreads from there.

Cloud Sandbox closes that gap. It takes the first-time-seen file, runs it in an isolated cloud VM, watches its behaviour, and delivers a verdict — Benign, Suspicious, or Malicious — that then drives policy. Zscaler's models are trained on 600M+ samples and trillions of daily signals, so the verdict is fast and confident.

👉 So far: signatures catch the known; the sandbox detonates the unknown to stop patient zero. Next, the architecture — where the sandbox sits in the ZIA inspection path.
Figure 1 — Where Cloud Sandbox sits in the ZIA inspection path
A left-to-right architecture diagram. A user device forwards traffic to a ZIA Service Edge, which runs SSL inspection, then signature antivirus, then Cloud Sandbox for unknown files. The sandbox first checks an MD5 hash against the ThreatLabz verdict cache; known files get an instant verdict, unknown files are detonated in an isolated cloud VM. The verdict drives the policy action before the file reaches the internet or the user. A file download walks the inspection stack — Sandbox is the last, deepest layer User device downloads a file SSL inspection decrypt HTTPS · prerequisite Signature AV catches KNOWN malware Cloud Sandbox handles the UNKNOWN file MD5 hash → ThreatLabz verdict cache Known hash = instant verdict · Unknown hash = detonate UNKNOWN 🧪 Isolated cloud VM detonate · watch behaviour · MITRE map Verdict → policy action Known + benign instant allow — no detonation KNOWN
Sandbox is the deepest layer, and it only acts on the unknown file. SSL inspection on the left is what makes the rest possible.

Pause & Predict

Signature AV already scans downloads. So why add a sandbox that runs the file — isn't matching a fingerprint faster and safer? Type why a fingerprint alone isn't enough.

Answer: A fingerprint only catches malware someone has already seen and catalogued. A file compiled an hour ago has no fingerprint anywhere — AV waves it through. The sandbox doesn't need a prior fingerprint: it watches what the file actually does. That's the only way to catch the truly new (zero-day) threat before patient zero.

Four words you must own before the pipeline

A sandbox conversation falls apart if these four are fuzzy. Tap each card.

🧪
Detonation
tap to flip

Actually running the file in an isolated cloud VM and watching what it does to files, registry and network. So what: behaviour catches malware no signature has yet.

🆕
First-time-seen
tap to flip

A file whose hash ZIA has never encountered — no prior verdict exists. So what: only these need detonation; everything else is answered from cache.

🗄
Verdict cache
tap to flip

The ThreatLabz store of MD5 → verdict. So what: a file seen once for the whole cloud is "known" for everyone — that's the speed.

🩹
Patient zero
tap to flip

The first victim of brand-new malware, before a signature exists. So what: the whole Quarantine-vs-Allow debate is about whether you accept a patient zero.

The pipeline — what happens to one unknown file

Sneha at Infosys downloads invoice_q3.exe from a file-sharing site. Here is the exact journey that file takes. The key idea: detonation is the last resort, not the first step. ZIA tries to answer cheaply before it spends compute detonating.

Figure 3 — The decision flow: file in, verdict out
A left-to-right flow. A downloaded file is hashed to MD5, then checked against the ThreatLabz verdict cache. If the hash is known, the cached verdict is returned instantly with no detonation. If the hash is unknown, the file is detonated in an isolated cloud VM, a verdict of benign, suspicious or malicious is produced, and the policy action runs. The new verdict is then written back to the cache for everyone. file → hash → cache → (unknown) detonate → verdict → action 📥 File downloaded (HTTPS) 🔑 MD5 hash compute fingerprint 🗄 Verdict cache known hash? KNOWN Instant verdict no detonation UNKNOWN 🧪 Detonate in VM watch behaviour · MITRE map Verdict: Benign · Suspicious · Malicious → policy action (allow / block / quarantine) cache the new verdict
The cache write-back (dashed) is the magic: a file detonated once becomes "known" for the whole cloud — instant for the next person.

▶ Watch the sandbox pipeline — then break it

Press Play for the healthy detonation flow on an unknown file. Then Break it to see the SSL-inspection trap.

① DOWNLOADSneha 10.20.30.45 pulls invoice_q3.exe over HTTPS
▼
② HASH LOOKUPZIA computes the MD5 and checks the ThreatLabz verdict cache
▼
③ UNKNOWNNo prior verdict → the file is first-time-seen → send to the sandbox
▼
④ DETONATEFile runs in an isolated cloud VM; behaviour is watched and MITRE-mapped
▼
⑤ VERDICTResult = Malicious → policy blocks it and caches the verdict for everyone
Press Play to step through the healthy pipeline. Then press Break it.

Scenario

Rahul at TCS asks: "Why did my colleague's identical download get blocked instantly, but mine took a few seconds the first time?"

What's happening

Rahul was first. His file was first-time-seen, so it was detonated — a few seconds. The colleague hit the same MD5 after the verdict was cached, so ZIA answered instantly from the ThreatLabz verdict cache. No second detonation.

Where to see itAnalytics → Sandbox → Sandbox Activity Report (filter on the file hash)
Takeaway

One detonation per unique file, cloud-wide. This is why Sandbox feels "slow" only on the genuinely new file and instant on everything else.

Quick check · Q1 of 10

A file with a known MD5 hash (already in the ThreatLabz verdict cache and rated benign) is downloaded again. What does Cloud Sandbox do?

Correct: a. Detonation is reserved for first-time-seen (unknown) files. A known hash with a cached verdict is answered immediately — that's why Sandbox doesn't slow down everyday browsing.

Pause & Predict

The verdict on Sneha's first-time-seen file isn't instant — detonation takes seconds. So while ZIA is busy detonating, what should it do with the file the user is waiting for? Type your guess before reading on.

Answer: That single decision is the whole next section. You either hold the file (Quarantine) until the verdict is back, or let the user have it now and scan in parallel (Allow & Scan) — accepting that the first user could be patient zero. That choice is the First Time Action.

The Sandbox Rule — and the one choice everyone fumbles

A Sandbox Rule decides which traffic is eligible for sandboxing and what to do with the unknown file. You build it in the admin portal under Policy → Sandbox. The rule matches on the usual ZIA criteria and then sets the critical First Time Action.

Rule criteria you'll set

👉 So far: a Sandbox Rule matches who/where/what-site/what-file. Next, the field that defines your whole risk posture — First Time Action.
Figure 2 — First Time Action: Quarantine vs Allow & Scan (the patient-zero trade-off)
A comparison diagram. On the left, Quarantine holds the unknown file until the sandbox verdict is back, so there is no patient zero but the user waits a few minutes. On the right, Allow and Scan delivers the file to the first user immediately and analyses in parallel, so the user is never delayed but the first user can be patient zero if the file is malicious. In the middle, AI Instant Verdict uses inline machine learning to give a verdict in seconds, narrowing the gap so most files can be allowed safely without a wait. Unknown file detected — what do you do while it detonates? First Time Action? 🛑 QUARANTINE Hold the file until verdict is back ✓ No patient zero — safest ✓ Malware never lands ✗ User waits a few minutes ✗ Friction on big files Best for high-value sectors (BFSI, gov) ⚡ ALLOW & SCAN Deliver now, analyse in parallel ✓ Zero user delay ✓ Max productivity ✗ First user = patient zero ✗ Risk if file is malicious Pairs best with AI Instant Verdict 🤖 AI Instant Verdict closes the gap Inline ML rates the file in seconds (score 91–100 = block) — allow safely, no wait Rule of thumb: Quarantine where a single infection is unacceptable; Allow & Scan + AI Instant Verdict where speed wins.
There is no "right" answer — it's a risk dial. AI Instant Verdict is what lets a careful org choose Allow & Scan without creating patient zero.

▶ AI Instant Verdict — closing the first-user gap

Priya at HCL downloads an unknown file. Play the AI-Instant-Verdict path, then Break it to see what a too-broad bypass costs.

① UNKNOWNFirst-time-seen file enters; full detonation would take seconds
▼
② INLINE MLThe inline ML engine scores the file in real time (AI Instant Verdict)
▼
③ SCOREThreat score 91–100 = high-confidence malicious → blocked outright, no wait
▼
④ NO PATIENT ZEROLow score = allowed; full sandbox still confirms in the background
Press Play for the AI Instant Verdict flow. Then press Break it.

Scenario

Aditya, a security lead at a 5,000-user bank, sets the Finance team's Sandbox Rule to Allow & Scan for "user happiness". A week later, ransomware lands on a finance laptop from a fresh file.

Likely cause

With Allow & Scan, the first user received the unknown file before the verdict came back. The file was malicious — that user became patient zero. The verdict caught it cloud-wide afterward, but one machine was already hit.

DiagnosisAnalytics → Sandbox → Files Found Malicious Report — shows the malicious verdict and the user who got it first
Fix

For a high-value group, set First Time Action = Quarantine on the unknown file, and enable AI Instant Verdict so most clean files still pass without a wait. Reserve Allow & Scan for low-risk groups.

Verify

Re-test with a benign test file: it should be held, scanned and released. A known-bad test should never reach the endpoint.

Quick check · Q2 of 10

A bank wants zero chance of a single infection from an unknown download for its Finance team. Which First Time Action fits?

Correct: b. Quarantine is the only First Time Action that guarantees no patient zero — the file is held until the verdict is benign. Allow & Scan accepts a first-user risk; blocking everything (d) destroys productivity.

SSL inspection is the silent prerequisite

Here's the gotcha that breaks new deployments. Almost all malware arrives over HTTPS today. If ZIA can't decrypt the download, it can't extract the file, compute its hash, or send it to the sandbox. So without SSL inspection enabled for that traffic, your Sandbox Rule silently does nothing for encrypted downloads. Engineers enable Sandbox, test with an HTTPS site, see no detonation, and assume Sandbox is broken — when the real fix is upstream.

Admin Portal — the build order that actually works
1. Policy → SSL Inspection      → enable for the target traffic (decrypt HTTPS)
2. Policy → Malware Protection  → confirm signature AV is on (catches known)
3. Policy → Sandbox             → add a Sandbox Rule:
     Criteria : Users/Groups/Locations + URL Categories + File Types
     File Types: Windows EXE, DLL/MSI, MS Office docs, PDF, archives, scripts, APK, Undetectable File
     First Time Action: Quarantine   (or Allow & Scan for low-risk groups)
     AI Instant Verdict / AI Quarantine: ENABLED  (block ML score 91-100)
Expected result
Unknown HTTPS download from a finance user  → held, detonated, verdict in ~seconds
Known-benign file (cached verdict)          → allowed instantly, no detonation
AI score 91-100 on an unknown file          → blocked inline, before full detonation
SSL inspection OFF for that traffic         → file invisible to Sandbox (silent no-op)
ZIA Policy Simulator SSL Inspection Lab
Quick check · Q3 of 10

You added a Sandbox Rule, but unknown files downloaded over HTTPS are never detonated. HTTP test files work. What's the first thing to check?

Correct: b. SSL inspection is the prerequisite. HTTP works because it's already cleartext; HTTPS needs decryption first. No SSL inspection = the sandbox never receives the file. It's a silent no-op, not a sandbox failure.

The detonation report, the gotchas & verification

When a file is detonated, ZIA produces a detonation report. This is your evidence, and an L3 engineer reads it instead of trusting the verdict blindly.

What the report shows

The report is exportable via API into your SIEM / SOAR / EDR — so a sandbox verdict at the edge becomes a hunt across the whole SOC.

Figure 4 — Anatomy of a detonation report (one-glance card)
A six-tile cheat-sheet card summarising a Cloud Sandbox detonation report. The tiles are: final classification (benign, suspicious or malicious); file activity such as dropped or modified files; registry changes; network callbacks to command and control; MITRE ATT and CK technique mapping; and export to SIEM, SOAR and EDR for SOC-wide hunting. A footer reminds the reader to verify via the Sandbox Activity and Files Found Malicious reports. What an L3 engineer reads in the detonation report ⚖ Classification Benign · Suspicious · Malicious the headline verdict 📂 File activity dropped / modified files process creation 🗝 Registry changes persistence keys autorun edits 🌐 Network callbacks C2 domains / IPs beaconing IOCs 🎯 MITRE ATT&CK tactics + techniques turns a verdict into a hunt 📤 Export to SOC API → SIEM / SOAR / EDR hunt the IOCs everywhere Find it: Analytics → Sandbox → Sandbox Activity Report / Files Found Malicious Report Verify with a benign test file — never run live malware to "test the plumbing". Golden rule: trust the report's behaviour, not the verdict label alone — the behaviour is what you hunt.
Six things to scan in every report. The MITRE tile is what turns one blocked file into a SOC-wide threat hunt.
👉 So far: read the report, don't trust the verdict blindly. Next — the three production gotchas that bite real admins, sourced from the Zscaler community.

Three gotchas that bite in production

These come straight from real practitioner threads on the Zscaler community. Tap each.

🔁
The never-ending scan
tap to flip

If a "static" file's MD5 changes on every download (dynamic build/wrapper), it's always first-time-seen → detonated forever. So what: check why the hash isn't stable, don't blame the sandbox.

🚪
The over-broad bypass
tap to flip

Bypassing a whole URL category to "fix" one false positive leaves un-detonated ground for malware. So what: exempt the specific app/domain, never a category.

📏
The size ceiling
tap to flip

Files over the per-type limit (Office/PDF 20MB, EXE/DLL/APK/archive 50MB, scripts 5MB) aren't detonated. So what: a 60MB EXE can slip past — plan for it.

🙈
The SSL blind spot
tap to flip

No SSL inspection on the traffic = the sandbox never sees the HTTPS download. So what: this is the #1 "sandbox isn't working" cause — fix it first.

Scenario

Karthik reports a legit internal installer (setup.exe) from the company's update server is being repeatedly quarantined, frustrating the whole Pune office.

Likely cause

The build pipeline rewraps the installer on each pull, so its MD5 changes every time. ZIA sees it as first-time-seen on every download → detonation never reaches a stable cached verdict.

Diagnosis

Compare the file hash across two downloads — if it differs, the file isn't actually static.

Analytics → Sandbox → Sandbox Activity Report → check repeated hashes for the same file name
Fix

Fix the source so the file hash is stable, OR scope a tight allow-list for that specific trusted internal domain — not a whole category. Avoid blanket bypasses.

Verify

Two consecutive downloads now share one MD5; the second is served from cache with no quarantine delay.

Quick check · Q4 of 10

A 60MB Windows EXE downloads with no sandbox detonation logged, while a 10MB EXE from the same site is detonated. What's the most likely reason?

Correct: a. Cloud Sandbox enforces per-type max sizes (EXE/DLL/MSI/APK/archive ~50MB; Office/PDF ~20MB; scripts ~5MB). A file over the ceiling isn't detonated — a real gap to plan around with complementary controls.

Pause & Predict

A teammate wants to test that Sandbox really works without risking real malware. What's a safe way to prove detonation and a verdict are firing? Type your idea.

Answer: Use a benign test file (EICAR-style) or Zscaler's own Cloud Sandbox file-check / Sandbox Insights, then confirm the detonation report appears under Analytics → Sandbox. You verify the plumbing (file extracted, detonated, verdict logged) without ever running live malware.

Scenario

Meera's SOC wants to confirm a blocked file was genuinely malicious and hunt for the same behaviour on endpoints. Where does she look?

Step 1 — confirmAnalytics → Sandbox → Files Found Malicious Report → open the detonation report
Step 2 — read behaviour

Note the MITRE ATT&CK techniques, registry/file activity and any C2 callback domains in the report.

Step 3 — hunt

Export via API into the SIEM/EDR and hunt those IOCs and techniques across endpoints — the edge verdict becomes a SOC-wide hunt.

Quick check · Q5 of 10

Which port set does a ZIA Public Service Edge accept web traffic on (the path the inspected download arrives through)?

Correct: a. ZIA edges accept web traffic on 80, 443, 9400, 9480 and 9443. The download must reach the edge on an accepted port and be SSL-inspected before Sandbox can ever extract and detonate it.
The "quick fix" that becomes next quarter's incident

When a clean file is wrongly quarantined, the lazy fix is to bypass its whole URL category from sandboxing. Don't. You carve a hole where the next unknown malware rides in un-detonated. Exempt the specific trusted domain or app, keep everything else inspected and detonated. Scope tightly — a wide bypass at a bank is exactly the un-inspected ground attackers want.

Pro tips

① Pair Quarantine with AI Instant Verdict — most clean files pass in seconds, so users barely feel the hold while real threats are stopped.

② Sandbox high-risk URL categories (File Sharing, Newly Registered Domains) harder than general browsing — risk-based, not one-size-fits-all.

③ For unsupported large files, lean on File Type Control + CDR (content disarm) as a complementary layer — Sandbox is one layer, not the only one.

🤖 Ask the AI Tutor

Tap any question — instant, context-aware answer scoped to this lesson. No login, no waiting.

Pre-curated from Zscaler help docs + community Q&A. For deeper / live questions, paste your output into chat.techclick.in.

🎓 Prove it — 10-question assessment

Scenario-based, cert-prep grade. Pass mark 70% (7 of 10). Pick one answer each, then Submit — you'll get full reasoning. Passing saves to your profile.

Q1 · Remember

Cloud Sandbox primarily defends against which kind of threat that signature AV misses?

Correct: a. Signatures catch known malware instantly. Sandbox detonates the unknown, first-time-seen file to stop patient zero — that's its whole reason to exist.
Q2 · Analyze

Two users download the identical file minutes apart. The first download is detonated; the second returns a verdict instantly. Why?

Correct: b. One detonation per unique hash, cloud-wide. Once a verdict exists in the cache, every later request for that MD5 is answered instantly — no re-detonation.
Q3 · Apply

Sneha's bank wants no chance of a single endpoint infection from an unknown download. Which First Time Action do you set on the Sandbox Rule?

Correct: b. Quarantine is the only action that guarantees no patient zero. Allow & Scan (a) accepts a first-user risk; bypassing (d) removes protection entirely.
Q4 · Apply

You want the Sandbox Rule to also catch files of types Zscaler doesn't otherwise recognise. Which file-type selection helps?

Correct: c. The "Undetectable File" option under Other extends the rule to unknown file types — a key way to avoid leaving an obscure format un-sandboxed.
Q5 · Apply

Priya enables Allow & Scan for productivity but still wants high-confidence malware blocked before it lands. What does she turn on?

Correct: d. AI Instant Verdict scores the unknown file inline in seconds; a 91–100 score is blocked outright. It's what lets Allow & Scan run without creating patient zero.
Q6 · Analyze

A new Sandbox Rule detonates HTTP test files but never HTTPS downloads. What's the root cause?

Correct: c. SSL inspection is the silent prerequisite. Cleartext HTTP is already visible; HTTPS must be decrypted first. No SSL inspection = the sandbox never receives the encrypted download.
Q7 · Analyze

A trusted internal installer is quarantined on every download. The team confirms its MD5 differs each time. What's the diagnosis?

Correct: a. A changing MD5 means ZIA can never cache a verdict — every pull looks new and gets detonated/quarantined. Fix the source so the hash is stable, or scope a tight allow-list for that specific domain.
Q8 · Analyze

A blocked file's detonation report shows registry edits, a dropped executable and a C2 callback domain, mapped to MITRE ATT&CK. How should the SOC use this?

Correct: b. The report's MITRE mapping and IOCs are a hunt starter — one edge verdict becomes a SOC-wide search. Ignoring it (a) wastes the intel; whitelisting the C2 (d) is the opposite of the goal.
Q9 · Evaluate

An engineer proposes fixing all sandbox false positives by bypassing the entire "File Sharing" URL category from sandboxing for the whole company. Good design for a 5,000-user bank?

Correct: d. False positives are fixed per-domain, not per-category. A category-wide bypass at a bank is exactly the un-inspected hole attackers want. Scope tightly; keep everything else detonated.
Q10 · Evaluate

A team argues "Quarantine annoys users, so just use Allow & Scan everywhere." For a mixed org with a Finance team and a low-risk marketing team, what's the better design?

Correct: a. The action should match the blast radius. Quarantine + AI Instant Verdict protects the team where one infection is costly; Allow & Scan keeps low-risk users fast. One blanket setting ignores risk on one side or the other.
Lesson complete — saved to your profile.
Almost! You need 70% (7 of 10) — re-read the path that tripped you up and tap "Try again".

🧠 In your own words

Type one line: why does Quarantine prevent a patient zero but Allow & Scan does not? Then compare to the expert version.

Expert version: Quarantine holds the unknown file until the sandbox verdict is back — if it's malicious it never reaches any endpoint, so there's no first victim. Allow & Scan delivers the file to the first user immediately and analyses in parallel — so if that file is malicious, the first user is already infected (patient zero) before the verdict arrives. AI Instant Verdict narrows that window by scoring inline in seconds. If your answer mentioned "hold vs deliver-then-analyse", you've nailed it.

🗣 Teach a friend

Best way to lock it in — explain it in one line to a teammate. Tap to generate a paste-ready summary.

Quick reference — the Sandbox cheat-sheet

ConceptWhat to remember
Sandbox vs AVAV = known (signature). Sandbox = unknown (behavioural detonation).
Pipelinefile → MD5 → ThreatLabz cache → (unknown) detonate → verdict → action
Detonation triggerOnly first-time-seen (unknown) hashes. Known hash = instant cached verdict.
VerdictsBenign · Suspicious · Malicious
First Time ActionQuarantine (hold, no patient zero) vs Allow & Scan (deliver now, patient-zero risk)
AI Instant VerdictInline ML scores in seconds; score 91–100 = blocked. Closes the first-user gap.
PrerequisiteSSL inspection — without it, encrypted downloads are invisible to Sandbox.
Rule criteriaUsers/Groups/Locations + URL Categories + File Types (+ Undetectable File)
File-size capsOffice/PDF ~20MB · EXE/DLL/MSI/APK/archive ~50MB · scripts ~5MB
The reportClassification + MITRE ATT&CK + file/registry/network behaviour → export to SIEM/EDR
VerifyAnalytics → Sandbox → Activity / Files Found Malicious Report; test with a benign file.
Top gotcha"Sandbox isn't working" on HTTPS = SSL inspection off. Fix that first.

One Hinglish line to remember it: yaad rakhna — Sandbox sirf "naya" file detonate karta hai; SSL inspection nahi to kuch nahi hoga.

📖 Glossary

Cloud Sandbox
The ZIA service that detonates unknown files in an isolated cloud VM to find malware no signature has yet caught.
Detonation
Actually executing a file in the sandbox VM and recording its behaviour, instead of matching a signature.
First-time-seen
A file whose hash ZIA has never analysed before — it has no cached verdict, so it must be analysed fresh.
Patient zero
The first victim of brand-new malware, before any signature or verdict exists to stop it.
MD5 hash
A fingerprint of the file used to look it up in the verdict cache, so identical files aren't re-detonated.
ThreatLabz verdict cache
Zscaler's store of file-hash → verdict; a file analysed once for the cloud is "known" for everyone.
Quarantine (First Time Action)
Holds the unknown file until the sandbox verdict confirms benign — prevents a patient zero, costs a short wait.
Allow & Scan
Delivers the unknown file to the first user immediately and analyses in parallel — zero delay, first-user risk.
AI Instant Verdict
Inline ML that rates an unknown file in seconds; a score of 91–100 is blocked, closing the first-user gap.
MITRE ATT&CK
A framework of attacker tactics/techniques; the detonation report maps observed behaviour to it for SOC hunting.

📚 Sources

  1. Zscaler Help — About Sandbox · Configuring the Sandbox Policy · Sandbox Policy & Settings · Recommended Sandbox Policy (Sandbox Rule criteria, file types, First Time Action, Undetectable File). help.zscaler.com
  2. Zscaler Help — Viewing Sandbox Reports and Data · About the Sandbox Activity Report · About the Sandbox Files Found Malicious Report (detonation report, verification paths). help.zscaler.com
  3. Zscaler Help — Ranges & Limitations (per-type max file sizes: Office/PDF 20MB, EXE/DLL/MSI/APK/archive 50MB, scripts/HTA/Java 5MB) + accepted edge ports. help.zscaler.com
  4. Zscaler Blogs / Product Insights (2024–2026) — Stop Patient Zero Attacks with Advanced Cloud Sandbox · Intelligent Patient-Zero Prevention Powered by AI · The Productivity and Protection of Cloud Sandbox (Allow & Scan vs Quarantine, AI Instant Verdict, 600M+ samples, MITRE-mapped reports). zscaler.com
  5. Zscaler Community (Zenith) — "Sandbox Quarantine" · "Does an uploaded file always get detonated?" · "MD5 of a static file keeps changing so sandbox scanning never ends" · "Cloud Sandbox — blocking MD5 hash values" (real production gotchas). community.zscaler.com
  6. Don't Blame The Network (practitioner) — Beyond Signatures: How Zscaler ZIA Uses Sandboxing for Advanced Protection. dontblamethenetwork.com
  7. Zscaler Sandbox enhancements (2024–2025 changelog) — AI Instant Verdict / AI Quarantine (ML score 91–100), Votiro CDR + Isolation content-disarm for Office/PDF, Zero-Day VM Scan. zscaler.com
  8. Zscaler ZDTA Certification — Cyberthreat Protection Services objectives (Cloud Sandbox, advanced threat protection); EDU-200 / EDU-202. customer.zscaler.com / partneracademy.zscaler.com

What's next?

You can now place any unknown-file question on the sandbox pipeline and pick the right First Time Action. Next, see how Sandbox chains with the rest of the policy stack — Cloud Firewall, DNS Control, URL Filtering and IPS inside one SSE hop.

Next · ZIA Security Controls Deep-Dive → Practice on exam.techclick.in →