What if your IP address is hidden, your traffic is routed through multiple privacy layers, and your virtual machine disappears after every session — but you can still be identified?
This question is more complicated than it appears.
In cybersecurity, we spend considerable time studying how attackers compromise systems, establish persistence, manipulate network traffic, and extract sensitive information. Yet another question deserves equal attention:
How much information can an observer collect about a researcher operating inside a supposedly isolated environment?
A VPN can change the network address visible to an external service. Tor can distribute trust across multiple relays. Virtual machines can establish useful isolation boundaries. Disposable environments can reduce persistent application data.
But none of these mechanisms automatically makes an operator anonymous.
A compromised host can observe its guests. Network traffic may reveal timing patterns. Browser activity can disclose identity. A single authenticated account can defeat several layers of network privacy.
I wanted to examine these problems through practical security engineering rather than theoretical promises.
That research led me to develop Rvbbit Ghost.
GitHub: https://github.com/buter-chkalova/rvbbit-ghost
Rvbbit Ghost is an experimental Windows-based orchestration system for disposable Whonix research sessions. It combines VirtualBox isolation, signed-image verification, an OpenVPN-before-Tor architecture, session lifecycle management, and security validation.
It is not an invisibility tool, an exploitation framework, or a guarantee of anonymity.
Its purpose is to explore a narrower and more useful question:
Can we make sensitive, authorized research sessions more isolated, more repeatable, and less likely to expose persistent data — without pretending that the underlying operating system has become trustworthy by magic?
1. The Real Problem: Anonymity Is Not a Single Security Property
When people discuss online anonymity, they frequently reduce the problem to one measurement:
What IP address does the destination see?
That is only one part of the attack surface.
Consider a research environment in which the public IP address has been successfully concealed.
An observer might still identify or correlate an operator through:
- Browser fingerprinting and application characteristics.
- Authenticated accounts and reused identifiers.
- Traffic timing, duration, and volume.
- Endpoint telemetry and host-level execution records.
- Files downloaded from a protected environment and opened elsewhere.
- Metadata exposed through documents or communications.
- Compromised operating systems, hypervisors, or browser processes.
- Behavioral patterns connecting multiple supposedly independent sessions.
Anonymity, privacy, and isolation overlap, but they are not interchangeable.
Network privacy concerns what network observers can learn.
Identity separation concerns whether different activities can be connected to the same person.
Execution isolation concerns whether activity inside one environment can affect another.
Data disposability concerns what application state persists after the environment has been destroyed.
A system can improve one of these properties while providing relatively little protection for the others.
This distinction became the foundation of Rvbbit Ghost.
Figure 1. Rvbbit Ghost architecture and security boundaries.
2. Architecture: Windows → Whonix → OpenVPN → Tor
The project uses Windows 10/11 as the host operating system, VirtualBox as the virtualization layer, and Whonix as the guest environment.
The intended traffic path is:
Whonix-Workstation
|
| Internal VirtualBox network
v
Whonix-Gateway
|
| OpenVPN tunnel
v
VPN provider
|
| Tor connection
v
Tor network
|
v
Internet
The ordering matters.
Whonix-Workstation does not receive a direct VirtualBox NAT adapter. Its only network interface connects to a session-specific internal network shared with Whonix-Gateway.
The Gateway handles external connectivity and is configured to establish OpenVPN before Tor.
This means Workstation is not intended to have an independent route to the Internet.
Why separate Workstation and Gateway?
A single operating system handling browsing, applications, network routing, and privacy enforcement combines several responsibilities within one environment.
Separating these components provides a clearer security boundary.
Whonix-Workstation contains the browser session.
Whonix-Gateway handles the network routing.
VirtualBox controls the guest networking configuration.
The Windows launcher manages installation, verification, session creation, readiness checks, and cleanup.
This does not mean the Gateway is invulnerable. A sufficiently capable attacker compromising the Gateway or the underlying host may undermine the intended routing restrictions.
But separation creates a structure in which specific assumptions can be identified and tested.
That is a meaningful engineering advantage.
3. Why Put a VPN Before Tor?
This is one of the more interesting architectural decisions.
Tor already provides network anonymity properties through its relay architecture. Adding a VPN does not automatically make Tor more anonymous.
Instead, it changes the distribution of information among observers.
In the VPN-before-Tor configuration:
The ISP can observe:
- The subscriber's Internet connection.
- The VPN endpoint.
- Connection timing, duration, and traffic volume.
The VPN provider can observe:
- The subscriber's source IP address.
- Connections from its infrastructure toward the Tor network.
- Traffic timing and volume.
The Tor entry relay typically observes:
- The VPN exit address rather than the subscriber's home address.
The destination website observes:
- The Tor exit address.
- Browser characteristics and data voluntarily submitted to the service.
In an uncompromised configuration, the destination should not directly learn the operator's home IP address through ordinary network routing.
However, an important limitation remains:
The VPN provider becomes another party capable of observing and potentially correlating network metadata.
If an adversary can observe multiple points across the path, timing analysis may remain possible.
This is why I do not describe VPN-before-Tor as a universal improvement over Tor alone.
Its value depends on the threat model.
For one scenario, concealing direct public Tor connections from the ISP may be useful. For another, adding a VPN provider may introduce an unnecessary dependency.
The important question is not how many layers exist.
It is which observer each layer is intended to constrain.
4. Fail-Closed Networking: A Security Boundary Must Survive Failure
Security controls are relatively easy to describe when every component works correctly.
The more interesting question is what happens when a dependency fails.
Suppose a VPN connection unexpectedly terminates.
Does Tor continue through the host's ordinary network route?
Does the Workstation retain connectivity?
Does the user receive a warning, or does the environment silently continue operating under different assumptions?
Rvbbit Ghost requires a fail-closed configuration in Whonix-Gateway.
The operator must configure the appropriate tunnel firewall and verify that connectivity fails when OpenVPN is stopped.
The intended behavior is straightforward:
VPN active
|
v
Tor permitted
|
v
Workstation connectivity permitted
VPN unavailable
|
v
Tor egress blocked
|
v
Workstation Internet connectivity fails
This protects against a category of configuration failures in which traffic could otherwise follow an unintended route.
There is an important implementation detail.
The Windows launcher does not independently inspect and cryptographically prove the state of the VPN tunnel inside the guest.
Instead, it requires a fresh operator-confirmed readiness check before starting Workstation.
This is operator attestation, not automatic verification of the tunnel by the host.
That limitation is documented deliberately.
Adding a host-to-guest monitoring mechanism could provide additional automation, but it would also create another integration channel between the Windows host and the isolated guest.
In security engineering, improving observability can sometimes weaken isolation.
That trade-off deserves explicit consideration.
5. Reducing the Host–Guest Attack Surface
Virtualization is frequently treated as if creating a VM automatically produces a strong security boundary.
In reality, virtualization environments provide numerous integration mechanisms designed for convenience.
Some are useful in everyday computing but undesirable in sensitive research environments.
Rvbbit Ghost disables several VirtualBox integration features, including:
- Shared clipboard and clipboard file transfer.
- Drag and drop.
- Shared folders.
- USB integration.
- Audio integration.
- VirtualBox remote display.
- VirtualBox recording.
Why?
Because every integration point can become a channel through which information crosses the host–guest boundary.
A shared clipboard can accidentally transfer sensitive material between environments.
A shared folder can expose host files to guest software.
External device access can increase the complexity of the isolation boundary.
Disabling these features does not eliminate hypervisor vulnerabilities or prevent a compromised Windows administrator from observing the guest.
It does reduce unnecessary interaction between the two environments.
The principle is simple:
Do not create a cross-boundary capability unless the workflow actually requires it.
This is the same philosophy used in reducing attack surfaces across operating systems, container environments, and enterprise networks.
6. Disposable Virtual Machines: Reducing Persistent State
Persistence is central to both offensive and defensive cybersecurity.
Attackers seek persistence to maintain access.
Defenders examine persistent artifacts to understand how an intrusion occurred.
Privacy engineering introduces a different question:
What application data should remain after a legitimate research session ends?
Rvbbit Ghost uses disposable linked clones derived from clean Whonix snapshots.
The lifecycle follows this model:
Verified Whonix appliance
|
v
Imported base
|
v
Clean snapshot
|
v
Disposable VM pair
|
v
Research session
|
v
Shutdown
|
v
Validated cleanup
Each session creates a temporary Gateway and Workstation pair with session-specific identities and networking.
During normal shutdown, the session VMs and their associated differencing disks are removed.
The goal is to avoid carrying browser cookies, browsing history, cache, local storage, and other session-specific state into the next research session.
This reduces the risk of accidental cross-session contamination.
But it is essential to distinguish logical disposal from secure physical erasure.
Deleting a virtual disk does not prove that every underlying storage block has been overwritten or rendered unrecoverable.
Windows filesystem journals, page files, backups, crash dumps, SSD behavior, and other storage mechanisms may preserve artifacts beyond the lifecycle of a VM.
Likewise, the clean base images and project maintenance state persist by design.
Rvbbit Ghost therefore makes a limited, defensible claim:
It reduces persistent browser-session state.
It does not guarantee forensic-proof deletion.
7. Supply-Chain Security: Isolation Begins Before the First Boot
A disposable environment is not trustworthy merely because it is temporary.
If the original VM image has been modified maliciously, every disposable clone may inherit the compromise.
For this reason, Rvbbit Ghost includes supply-chain verification during installation.
The project downloads a pinned Whonix appliance from the official source and verifies its OpenPGP signature using GnuPG and a pinned upstream signing-key fingerprint.
The purpose is to reduce the risk of importing an unauthorized or modified base image.
The trust chain still depends on components such as the Windows host, Gpg4win, package installation mechanisms, firmware, and the verified upstream software.
Cryptographic signature verification does not eliminate these dependencies.
It makes one important part of the supply-chain boundary more explicit and testable.
For me, this is a central lesson:
Security architecture must account for how trusted components enter the system, not only how those components behave after installation.
8. What Could an Attacker Still Do?
This is where the project becomes particularly interesting from an offensive-security and threat-modeling perspective.
Rather than asking whether the architecture is anonymous, we can examine hypothetical attack scenarios and identify which defensive assumptions they challenge.
Scenario A: Network Traffic Correlation
Imagine a sophisticated adversary capable of observing traffic at multiple points across a network.
The adversary cannot necessarily decrypt Tor traffic, but may observe connection timing and traffic volume.
If activity entering one part of a system can be correlated with activity leaving another, traffic analysis may reveal relationships that encryption alone does not hide.
Rvbbit Ghost does not eliminate this class of attack.
OpenVPN-before-Tor changes the directly observable source address at the Tor entry point, but it does not make timing correlations mathematically impossible.
Security lesson: Encryption protects content, but metadata remains an important part of the attack surface.
Scenario B: Browser-Based Identification
Suppose a website collects browser characteristics and observes user activity.
Tor Browser is designed to reduce fingerprinting and make users harder to distinguish.
However, unusual configuration changes, additional extensions, disclosed personal information, and authenticated identities can undermine those protections.
Rvbbit Ghost intentionally relies on the standard Tor Browser rather than attempting to create a heavily customized browser fingerprint.
This is an important distinction.
Making a browser appear technically unusual can sometimes make it more identifiable, not less.
Security lesson: Anonymity sets are often more valuable than arbitrary customization.
Scenario C: Host Compromise
Consider a Windows computer already compromised by malware with sufficient privileges.
The malicious software may potentially observe processes, keystrokes, screen content, storage activity, or information accessible through the hypervisor.
Network routing inside Whonix does not prevent a compromised host from observing data before it is encrypted or after it is decrypted inside the guest.
The attacker may not need to defeat Tor at all.
This is a fundamental limitation.
A sufficiently privileged malicious host cannot be made harmless by placing an application inside VirtualBox.
Security lesson: A privacy boundary cannot be stronger than the trusted infrastructure enforcing it against an adversary that controls that infrastructure.
Scenario D: Malicious Downloaded Content
Imagine a researcher downloading a document from an untrusted website during an authorized investigation.
Inside the isolated environment, the document remains subject to the protections and vulnerabilities of the guest.
If the researcher exports the document and opens it directly on the Windows host, the original security boundary no longer applies to that execution.
A malicious document may exploit the application used to open it, and an external application may initiate its own network activity.
The VPN/Tor routing policy for Whonix-Workstation does not automatically protect arbitrary Windows applications.
Security lesson: Isolation is a property of an execution environment, not a permanent property of a downloaded file.
Scenario E: Identity Correlation Across Sessions
A researcher creates two disposable virtual machines on different days.
Both sessions use Tor.
Both VMs are subsequently deleted.
Are they necessarily unlinkable?
No.
If both sessions authenticate to the same account, reuse identifying information, or produce uniquely recognizable content, they may be linked independently of the network path.
Deleting cookies does not erase information already collected by remote services.
The system can create fresh application state, but it cannot guarantee that a human operator will behave as an unrelated identity.
Security lesson: Operational security is not something that infrastructure can fully automate.
Scenario F: Virtualization and Escape Vulnerabilities
A vulnerability in a browser, guest operating system, virtualization component, or host driver can potentially undermine the assumed separation.
Disabling integrations reduces exposure, but it is not a proof that VM escape or host compromise is impossible.
Rvbbit Ghost does not claim protection against unknown hypervisor vulnerabilities or malicious firmware.
These threats remain outside its assurance boundary.
Security lesson: Reducing available attack paths is valuable even when eliminating every possible path is unrealistic.
9. What Remains Visible After the Session?
One of the most important decisions in this project was not to disable Windows security logging.
Rvbbit Ghost does not erase Windows Event Logs, disable Defender, manipulate audit records, or falsify execution history.
That is intentional.
A host operating system can generate many types of evidence associated with virtual-machine execution.
For example:
- Process execution and PowerShell activity.
- VirtualBox configuration and diagnostic records.
- Security-product telemetry.
- Network connection metadata.
- Filesystem activity and storage artifacts.
Disabling selected logging features does not guarantee that execution becomes unobservable.
Other components may continue recording information.
Moreover, selectively manipulating forensic records can weaken incident response and undermine legitimate investigations.
My objective was not to turn Windows into an anti-forensic platform.
It was to isolate the browser session and reduce unnecessary persistence within the project-controlled environment.
This distinction matters professionally.
Privacy engineering and anti-forensic manipulation are not the same discipline.
A responsible research environment should have an explicit data-retention model and documented limitations rather than making unsupported claims about disappearing without a trace.
10. Engineering Reliability Is Part of the Security Model
Many security tools focus heavily on the initial configuration while paying less attention to what happens after an unexpected interruption.
But real systems crash.
Power can fail.
Processes may terminate halfway through cleanup.
A VM may be deleted successfully while another remains registered.
Rvbbit Ghost addresses these lifecycle problems through several engineering mechanisms.
Validated resource cleanup
Project-specific VM names and recorded UUIDs are checked before destructive cleanup operations.
The objective is to avoid accidentally deleting unrelated VirtualBox machines.
Cross-process locking
Installation, startup, maintenance, auditing, and cleanup operations require coordinated access to project state.
A cross-process lock reduces the risk of conflicting state changes.
Atomic state persistence
The project uses atomic state replacement and schema migration to make stored lifecycle information more resilient.
Interrupted-session recovery
If a session is interrupted, the project can identify registered session resources and attempt validated recovery and cleanup.
Clean-base maintenance
Updated clean snapshots can be created after controlled maintenance and renewed VPN checks.
These mechanisms may be less visually impressive than encryption or traffic routing, but they are important.
A security control that works only when every operation completes perfectly is not a particularly reliable control.
Failure handling is part of the security architecture.
11. Validation: What Has Actually Been Tested?
I think security research should distinguish implementation, automated validation, and real-world assurance.
The repository includes a PowerShell validation suite covering important properties such as:
- PowerShell syntax and configuration checks.
- Pinned release metadata and expected download origins.
- Network isolation invariants.
- Invalid signature rejection.
- State migration and atomic persistence.
- Lock contention.
- Audit failure behavior.
- Partial cleanup and recovery handling.
These checks provide useful confidence in specific parts of the implementation.
However, the project remains an experimental research prototype.
Static and mocked behavior checks do not prove that the full environment will work correctly across every combination of Windows, VirtualBox, Whonix, and VPN provider versions.
Full end-to-end validation requires a properly configured Windows test host.
I do not consider this a minor distinction.
There is a substantial difference between saying:
“The project contains tests for critical security invariants.”
And saying:
“The complete system has been independently proven secure.”
The first is an engineering statement.
The second would require a much stronger body of evidence.
12. Where Could This Research Go Next?
Rvbbit Ghost also provides a foundation for investigating improvements to isolated research environments.
Several areas are particularly interesting.
More systematic adversarial testing
A useful next step would be a reproducible laboratory test matrix covering network failures, unexpected shutdowns, isolation misconfigurations, and recovery behavior.
Instead of relying solely on successful startup scenarios, the objective would be to deliberately test where assumptions break.
For example, a controlled experiment could measure whether connectivity is consistently blocked under different VPN failure conditions.
The test results should be recorded and compared against the architecture's intended invariants.
Stronger readiness verification
Operator-confirmed VPN checks are an acknowledged limitation.
Research could explore how to verify guest networking state more reliably without creating excessive host-to-guest trust or integration.
The difficult part is not merely collecting another status value.
It is establishing whether that status provides trustworthy evidence of the actual routing behavior.
Formalized session lifecycle testing
Disposable environments benefit from precise state models.
Installation, initialization, launch, execution, shutdown, recovery, and removal can be treated as explicit states with permitted transitions.
Future testing could focus on whether unexpected transitions leave behind resources or violate isolation assumptions.
Comparative host security
Windows with a hosted hypervisor is a practical environment for experimentation.
It is not the strongest possible architecture for every threat model.
Comparing Windows-hosted Whonix with Linux-based configurations and Qubes-Whonix could help identify where architectural changes provide greater security value than additional scripts.
Privacy and forensic artifact measurement
Another useful research direction would be to compare what remains after normal VM shutdown across different storage and host configurations.
This could include project-controlled data, retained maintenance state, VirtualBox artifacts, and relevant host telemetry.
The objective should be accurate measurement, not concealment or destruction of legitimate audit evidence.
A careful study could distinguish between data that is removed from ordinary application use and data that may remain accessible through forensic examination.
13. Where Rvbbit Ghost Fits Into Offensive Security
Offensive security is not limited to exploiting vulnerable applications.
It also involves understanding operating-system behavior, trust relationships, attack surfaces, network protocols, and the assumptions that make an attack possible.
Rvbbit Ghost approaches these subjects from the environment-design perspective.
For an authorized researcher, it provides an experimental platform for studying:
- Network isolation and routing dependencies.
- Trust boundaries between host and guest systems.
- Operational security and identity correlation.
- Data persistence and disposal.
- Supply-chain validation.
- Security control failures and recovery.
- The limits of layered privacy architectures.
It does not include an exploitation framework, credential theft functionality, persistence payloads, or mechanisms for bypassing customer attribution requirements.
That separation is deliberate.
Professional penetration testing operates within written authorization and rules of engagement.
Some engagements require declared source IP addresses, comprehensive audit logs, or specific network routes. In those situations, Tor and consumer VPN infrastructure may be inappropriate.
A privacy-oriented research environment should never override the customer's security requirements.
Understanding when not to use a tool is part of using that tool professionally.
14. The Most Important Lesson: More Layers Do Not Automatically Mean More Security
It is tempting to describe a chain containing Windows, virtualization, a VPN, Whonix, and Tor as inherently secure because it contains multiple technologies.
But security is not simply the number of layers between an operator and a destination.
Each layer introduces assumptions.
Windows must remain trustworthy enough to host the environment.
VirtualBox must enforce its intended boundaries.
The Whonix images must be authentic.
The VPN must behave according to the configured policy.
Tor and the browser must operate within their expected threat models.
The operator must avoid revealing identity through unrelated channels.
Some layers mitigate specific exposures. Others introduce new dependencies.
The correct engineering question is therefore not:
How can I add another privacy layer?
It is:
What exact failure or adversary does this layer protect against, how can I verify that protection, and what new risks does it introduce?
That question should guide the evolution of the project.
Final Thoughts
Rvbbit Ghost is not an attempt to create a machine that cannot be observed.
It is an attempt to explore how far isolation, disposable execution, explicit routing requirements, and disciplined lifecycle management can go on a conventional Windows host.
The project reflects an approach to cybersecurity that I consider increasingly important:
Understand the attacker. Model the trust boundaries. Test the failure conditions. Build defensive controls. Document what those controls cannot do.
A VPN does not make identity disappear.
Tor does not protect against every compromised endpoint.
Virtualization does not eliminate the underlying host from the trusted computing base.
Deleting a VM does not erase every trace of execution.
And a sophisticated architecture does not compensate for poor operational security.
But none of that makes isolation, privacy controls, or disposable environments meaningless.
It makes precise threat modeling more important.
The goal is not perfect invisibility.
The goal is to understand exposure, reduce unnecessary risk, and build systems whose security properties can be explained and tested.
Security begins where assumptions are challenged — not where promises are made.
Explore the Project
Rvbbit Ghost — Experimental Whonix Session Orchestration
GitHub: https://github.com/buter-chkalova/rvbbit-ghost
Additional technical documentation:
Rvbbit Ghost is an experimental, open-source research prototype intended for authorized security assessments, privacy research, and controlled laboratory environments. It does not guarantee anonymity or protect against every adversary.
Author: rvbbit
GitHub: buter-chkalova
Top comments (0)