The Fundamental Problem With Detection-Based Security
Every traditional antivirus and most next-generation endpoint protection platforms are built on the same foundational model: observe, classify, respond. The software watches what is happening on the endpoint, compares it against known bad patterns (signatures, ML models, behavioural rules), and takes action when something looks like a threat.
This model has a structural weakness that cannot be engineered away: it requires the threat to do something before it can be identified and stopped. The detection must happen after the malicious code has at least partially executed.
In the security industry, the gap between when a threat first executes and when it is detected and contained is called dwell time. For commodity malware — viruses and ransomware families that have been seen thousands of times — modern AV products achieve very short dwell times. The ML models recognise the pattern quickly and stop the threat within seconds.
But for zero-day threats — attacks built on techniques that have not been seen before, or deliberately crafted to evade the specific detection engines used by major AV vendors — dwell time extends. The models do not recognise the pattern. The behavioural rules do not fire quickly enough. The threat executes, persists, and begins its work before the detection system catches up.
For ransomware, even seconds of undetected execution means files begin encrypting. For credential stealers, milliseconds of access to memory means passwords are extracted. For backdoors, the persistence mechanism is written to disk and to the registry before the behavioural engine flags the behaviour as anomalous.
The detection model does not have a fix for this problem. Faster ML, more training data, more behavioural rules — these all reduce dwell time, but they cannot reduce it to zero, because detection by definition requires observing what the threat does.
Xcitium's ZeroDwell Containment approaches this from a different angle entirely.
What Is ZeroDwell Containment?
ZeroDwell Containment is Xcitium's patented approach to endpoint protection. Instead of observing what a file or process does and deciding whether it is malicious, ZeroDwell asks a different question first: is this file or process definitively trusted?
If the answer is yes — because the file is in Xcitium's global trusted file database, or because the IT administrator has explicitly whitelisted it — it runs normally.
If the answer is anything other than a confirmed yes — meaning the file is new, unknown, recently modified, or unrecognised — it runs inside a virtual container. The execution proceeds; the user can interact with it; but the process is isolated from the real operating system. It cannot read or write to the real file system. It cannot modify the real registry. It cannot make outbound network connections to real network interfaces.
While the contained process runs, Xcitium's Valkyrie cloud platform analyses it. If Valkyrie determines the file is malicious, it is quarantined — and because the real system was never accessible, no damage has been done. If Valkyrie clears the file as safe, it is released to run normally and added to the trusted database so future executions are immediate.
The term "ZeroDwell" refers to the dwell time on the real system: zero. The threat may have executed inside the container, but it never touched the production environment.
How Containment Works — Step by Step
Step 1: File or Process Launch
A user on a Windows 10 endpoint opens an email attachment — a PDF that appears to be an invoice. The PDF viewer launches, and the PDF contains an embedded script that attempts to drop an executable. The executable has never been seen before by any security vendor. There is no signature, no ML match, no behavioural precedent.
Xcitium's kernel-level driver intercepts the process creation event immediately. Before the executable is allowed to interact with the operating system, Xcitium performs an instant reputation lookup against:
- Xcitium's global trusted file database (billions of known-good files)
- Local whitelist configured by the IT administrator
- Global blacklist of known malicious files
Step 2: Classification — Trusted, Untrusted, or Unknown
The result of the reputation lookup places every file or process into one of three trust states:
Trusted: The file is in Xcitium's global database as known-good, or has been explicitly whitelisted by the IT administrator. It runs normally with no containment overhead.
Untrusted: The file is in Xcitium's global database as known-malicious, or the IT administrator has explicitly blacklisted it. It is blocked immediately from executing.
Unknown: The file is not in either database. This is the critical category — the file has no reputation. It may be legitimate software that has not yet been catalogued, a custom internal application, or a novel piece of malware. Xcitium cannot tell, and critically, does not need to tell before taking protective action.
In our example, the executable is Unknown. It proceeds to Step 3.
Step 3: Auto-Containment in the Virtual Container
The Unknown executable is permitted to launch — but inside Xcitium's virtual container. From the perspective of the process itself, it appears to be running normally. It can read the virtual file system (a copy of the relevant directory structure), it can interact with a virtualised registry, and it can attempt network operations (which are redirected to a monitoring layer, not the real network interface).
What it cannot do:
- Write files to the real disk
- Modify real registry keys
- Send data over the real network interface
- Inject into other processes outside the container
- Access real credentials from memory
If this executable is ransomware, it will attempt to enumerate files and begin encrypting them. Inside the container, it may "succeed" — writing encrypted versions of virtualised file copies. But the real file system is untouched. When the container is closed, the virtualised environment is discarded.
Step 4: Valkyrie Analysis
While the process runs in the container, Xcitium uploads a copy of the file to the Valkyrie cloud platform for analysis. Valkyrie runs multiple analysis pipelines in parallel:
- Static analysis: File structure, entropy analysis, embedded strings, PE header characteristics, code patterns
- Dynamic analysis: Behaviour observation in a controlled detonation sandbox — what does the file do when it executes in a clean environment?
- AI classification: Multiple ML models trained on Xcitium's global threat intelligence database score the file
- Human analyst review: For files that AI analysis cannot classify with high confidence, a human threat analyst at Xcitium's security labs reviews the evidence and issues a verdict
The time taken for Valkyrie analysis varies. Simple files with clear patterns may be classified in minutes. Sophisticated, obfuscated files requiring human review may take longer. During this entire window, the contained process continues running in the virtual environment without any access to the real system.
Step 5: Verdict and Outcome
If Valkyrie returns a malicious verdict: The contained process is terminated, the virtual environment is discarded, and the file is quarantined. The real system has not been modified in any way. There is nothing to remediate. The IT administrator receives an alert in the Dragon Platform console with the full analysis report.
If Valkyrie returns a clean verdict: The file is released from containment, added to the trusted database, and runs normally. On this machine and any other endpoint in the same Xcitium deployment, future executions of this file are immediate — no containment required.
The Three Trust Levels in Practice — How They Are Configured
Understanding how Xcitium determines trust is important for IT administrators deploying the platform in an Indian business environment.
Global Trusted File Database: Xcitium maintains a database of billions of known-good files — operating system components, major commercial software, widely-used applications. Files in this database are trusted automatically without requiring manual whitelist configuration. This covers the vast majority of standard business software.
IT Administrator Whitelist: Custom or proprietary applications — internal ERP systems, bespoke invoicing software common in Indian businesses, custom scripts — will not be in Xcitium's global database. The IT administrator must explicitly whitelist these during the initial deployment phase. This is done via the Dragon Platform console by uploading file hashes or by running the applications in a monitored mode and approving the resulting containment events. Most deployments complete the whitelist build-out within the first two to four weeks.
Auto-Containment Default Policy: Any file not in the trusted database or administrator whitelist is contained automatically. This policy can be adjusted at the application level — for example, allowing a specific legacy application to run outside containment while keeping the default policy for all other unknowns. This flexibility is important for environments with complex legacy software estates, which is common in Indian manufacturing and distribution businesses.
Untrusted / Blacklist: Files explicitly marked malicious by Xcitium or by the administrator are blocked entirely. This is analogous to the block list in any traditional AV product.
How ZeroDwell Handles Ransomware — A Scenario
To make this concrete, consider a realistic ransomware scenario targeting an Indian manufacturing company.
A purchasing manager receives an email appearing to be from a supplier, containing a macro-enabled Excel file. The email passes spam filters because it comes from a legitimately compromised supplier mailbox. The file extension is correct. The document looks real.
The manager opens the file. Excel launches with a prompt to enable macros. The manager clicks Enable (this is the human failure point that no technology fully solves). The macro executes. It downloads an executable from a remote URL — a ransomware payload that was compiled 48 hours ago and is not yet recognised by any AV vendor's ML model.
On a detection-based AV system: The executable downloads successfully. It begins executing. The AV runs ML analysis — no signature match. Behavioural analysis starts observing. The ransomware begins enumerating the file system and encrypting documents. After several seconds or minutes of encryption, the behavioural engine flags the encryption pattern as ransomware-like and triggers an alert. IT is notified. Response begins. Some files — possibly hundreds or thousands — are already encrypted.
On Xcitium with ZeroDwell:
- The macro runs (macros from Office documents are classified as Unknown by default in most configurations)
- The downloaded executable is Unknown — it runs in a virtual container
- Inside the container, the ransomware enumerates what it believes is the file system and begins encrypting files. These are virtual copies — the real disk is untouched
- Valkyrie analysis runs in parallel. Within minutes, AI classification identifies the encryption behaviour pattern as ransomware. Human review confirms. Malicious verdict issued.
- The contained process is terminated. Virtual environment discarded. Real file system: zero changes. Zero files encrypted.
- IT administrator receives an alert in Dragon Platform with the full attack chain, download URL, and ransomware family classification.
The difference in outcome is not a matter of detection speed. It is a matter of whether the real system was ever accessible to the threat.
How ZeroDwell Handles Fileless Attacks
Fileless attacks are a particular challenge for traditional AV because they leave no file on disk to scan. The malware lives entirely in memory, typically injected through a legitimate process — PowerShell, WMI, mshta.exe, regsvr32.exe — using what the security industry calls "living off the land" (LOLBin) techniques.
Xcitium's containment extends to process-level, not just file-level. When PowerShell is invoked with an unusual command line or from an unexpected parent process — for example, spawned by a browser process or an Office document — it is classified based on context. If the invocation pattern places it in the Unknown category (unusual parent, obfuscated command, encoded payload), it runs in a contained environment.
Inside the container, the PowerShell script executes. If it is attempting to download additional payloads, inject into other processes, or establish persistence via the registry, these actions occur in the virtual environment and are monitored by Valkyrie's dynamic analysis. The real registry is not modified. Real processes cannot be injected into from within the container.
This is not a perfect defence against every fileless technique — particularly in edge cases where the attacker has already established a trusted foothold and is using a whitelisted process. But for the majority of fileless attacks delivered via initial execution of an unknown script or document, containment prevents the real-system impact.
What the End User Experience Looks Like
A common question from IT administrators is: "Will users know they are running in a container? Will it break their workflow?"
For most standard business applications, the answer is: users notice nothing. Their whitelisted software — email clients, Office, ERP, browsers, communication tools — runs with full trust and zero overhead.
For genuinely unknown applications — a new piece of software being evaluated, a vendor's utility downloaded from their website, a macro-heavy spreadsheet from an external party — the application may run with minor constraints. In some cases, a file the contained process tries to save will go to the virtual environment rather than the real disk, which the user may notice if they try to locate the saved file.
Xcitium displays a "running in containment" visual indicator (a distinctive border around the application window) so users know their interaction is sandboxed. This is intentional transparency — it signals to the user that this application has not been verified and their real files are protected.
When users encounter this, the recommended workflow is to notify IT, who can review the Dragon Platform console, check the Valkyrie verdict, and either whitelist the application or confirm it is blocked.
Valkyrie Deep Dive — What Happens During Analysis
Valkyrie is Xcitium's cloud-based threat analysis platform and is a core component of what makes ZeroDwell effective at scale.
AI Analysis Pipelines: Valkyrie runs multiple independent ML classifiers against every submitted file. These include static analysis models (examining file structure, embedded code, entropy), dynamic analysis models (observing behaviour in a controlled detonation environment), and ensemble models that combine signals across multiple analysis types. The use of multiple independent models reduces false positives and catches threats that evade any single classifier.
Human Threat Intelligence: For files that AI analysis cannot classify with high confidence — typically highly obfuscated, newly crafted, or unusual file types — Xcitium's human analyst team reviews the evidence. These are trained malware reverse engineers who provide definitive verdicts on ambiguous files. The human review layer is what makes Valkyrie particularly effective against targeted attacks, where adversaries may specifically craft tools to score low on ML classifiers.
Global Threat Sharing: Verdicts issued by Valkyrie are propagated across all Xcitium customers globally. A file classified as malicious for one customer in India is immediately classified as malicious for all Xcitium endpoints worldwide. This creates a collective defence model where the global customer base contributes to a continuously improving threat database.
Verdict Timeline: Most files receive a verdict within minutes for AI analysis. Human review cases may take longer. During the entire analysis window, the file continues running in containment — the analysis time does not create a protection gap.
ZeroDwell vs Traditional AV — The Architectural Difference
TRADITIONAL DETECTION-BASED AV
================================================
File/Process → [ML Scan] → [Behaviour Watch] → [Detection Triggers?]
| |
└──────── Executes on REAL system immediately ───────┘
(damage possible during detection gap)
XCITIUM ZERODWELL CONTAINMENT
================================================
File/Process → [Trusted?] ─── YES ──→ Runs normally on real system
|
NO (Unknown)
|
└──→ [Virtual Container] ─── Valkyrie Analysis ───┐
| |
│ (real system: UNTOUCHED) │
│ │
Malicious verdict ←─────────────────────────┤
│ │
Quarantine Clean verdict
(zero damage) │
Release to real system
(added to trusted DB)
The structural difference: in the traditional model, the threat executes on the real system and detection determines whether damage occurs. In the ZeroDwell model, the real system is not accessible until trust is established — detection determines whether the contained execution is released, not whether damage occurs.
Honest Limitations of ZeroDwell
No security technology is a complete solution, and ZeroDwell has specific limitations that IT administrators should understand before deployment.
The whitelist build-out period: During the initial weeks of deployment, legitimate software that is not in Xcitium's global trusted database will be contained. For organisations with custom-built or niche applications — common in Indian manufacturing, BFSI, and government sectors — the whitelist build-out requires IT effort. Applications running in containment work functionally, but users may experience the containment UI and file-save constraints until whitelisting is complete. Cloudfy Systems manages this process as part of deployment onboarding.
Trusted software can still be abused: ZeroDwell protects against unknown files and processes. If an attacker compromises a trusted application — for example, exploiting a vulnerability in a whitelisted ERP client that is already running — the attack occurs within a trusted process context. This is not unique to Xcitium (it is a limitation of any containment model based on application trust), but it is a realistic attack vector. The EDR layer provides detection capability for these cases.
Performance on very high-throughput file operations: On endpoints that process very large numbers of unknown files — for example, a file server ingesting documents from external parties at scale — the containment and Valkyrie submission overhead can affect throughput. For these use cases, Xcitium's server deployment configuration and exclusion policies should be tuned carefully.
Internet connectivity for Valkyrie: Valkyrie analysis requires internet connectivity to the Xcitium cloud. In fully air-gapped environments, the cloud analysis component is not available. Xcitium has on-premises Valkyrie options for air-gapped deployments — discuss these requirements with Cloudfy Systems if applicable.
More information on how ZeroDwell integrates with Xcitium's full product stack — Dragon Platform console, Open XDR, and MDR service — is available on our Xcitium Endpoint Security services page. As an authorised Xcitium partner in India, Cloudfy Systems can arrange a technical demonstration of ZeroDwell containment in a live environment, showing exactly what happens when a zero-day file is executed. To discuss your environment or schedule a demo, contact us at +91 97600 50555 or connect@cloudfysystems.com.
You can also speak with our security team to discuss deployment requirements, whitelist planning, or a proof-of-concept against your current endpoint security tooling.
Frequently Asked Questions
Does ZeroDwell Containment stop ransomware even if it bypasses signature detection?
Yes — this is the central purpose of the architecture. ZeroDwell does not rely on recognising ransomware patterns. Any unknown executable, regardless of how novel its code, runs in a virtual container where it cannot access the real file system. Ransomware encrypting files inside the container has no effect on real data. The Valkyrie analysis identifies the encryption behaviour, issues a malicious verdict, and the contained process is terminated with zero real-system impact. This is architecturally different from ML-based detection, which requires recognising that encryption is happening on real files before triggering a response.
How long does it take for Valkyrie to analyse a file?
Most files receive an AI-based verdict within a few minutes. Files that require human analyst review — typically highly obfuscated or novel samples — may take longer. During the entire analysis window, the file runs in containment and cannot affect the real system, so the analysis duration does not create a protection gap. For organisations in regulated sectors that need documented analysis timelines, Xcitium's premium Valkyrie tier provides faster SLAs for human review.
Will ZeroDwell impact the performance of our business applications?
For standard business applications that are already trusted in Xcitium's global database — Microsoft Office, Google Chrome, standard ERP clients, communication tools — performance impact is negligible. These applications run with full trust and no containment overhead. The performance consideration applies to the initial whitelist build-out phase, when custom or proprietary applications are running in containment until cleared. After deployment and whitelist completion, most organisations report no user-perceptible performance difference from their previous endpoint security tool.
Is ZeroDwell effective against fileless malware and PowerShell attacks?
ZeroDwell containment operates at the process level, not just the file level, which means it applies to script-based and fileless attack vectors. PowerShell or WMI invocations from unusual parent processes or with obfuscated command lines are classified as Unknown and contained, preventing them from modifying the real registry or injecting into real processes. Fileless attacks that operate entirely within a pre-existing trusted process context are handled by the EDR layer, which provides process-level monitoring and MITRE ATT&CK-mapped detection for these techniques.
How does an IT administrator whitelist internal applications in Xcitium?
Whitelisting is managed through the Xcitium Dragon Platform cloud console. The primary methods are: uploading file hashes for known internal applications; using a monitored deployment mode where containment events are reviewed and approved from the console; and using the application control policy to allow specific applications by file path, publisher certificate, or hash. For organisations with large numbers of custom applications — common in Indian manufacturing and distribution — Cloudfy Systems includes whitelist planning and build-out in the deployment engagement, typically completing the process within two to four weeks of initial rollout.