Scambait Training Sandbox Brief

Build a turnkey, low-resource scambaiting training sandbox and operator troll panel. The project must be safe-by-default, fully documented, reversible, and restricted to a disposable lab VM and consenting participants. Do not use it to access, deceive, disrupt, or retaliate against real people or systems. Do not include credential theft, malware, persistence, stealth, or security-control bypasses.

Project goals
- Deliver a reproducible Windows 10 lab environment suitable for an Acer “potato” laptop with limited CPU, RAM, and storage.
- Support VMware Workstation Pro (free personal-use edition) and VirtualBox, and document tradeoffs and resource-light settings.
- Treat NeeP’s pre-made Windows 10 scambaiting VM post on Scammer.info as an optional reference/blueprint, not as a required download: https://scammer.info/t/pre-made-windows-10-scambaiting-virtual-machine-2024-version/161011. Explain how to verify provenance, scan downloads, and use a disposable snapshot. Do not redistribute copyrighted images or assume the referenced image is available or safe.
- Provide a clean-room build path from a legitimate Windows installation source and a documented optional import path for a user-supplied VM.

Safety boundary for anti-VM requests
- Do not implement anti-analysis, anti-forensics, stealth, or mechanisms intended to defeat endpoint security or hide malicious activity.
- Do not strip or falsify VMware, VirtualBox, or QEMU indicators via registry/device spoofing. Instead, provide a harmless compatibility/appearance profile that changes only visible personalization (for example, wallpaper, account display name, window layout, and desktop shortcuts) and clearly label the VM as virtualized in the operator documentation.
- If a referenced application requires a particular guest configuration, document the compatibility setting transparently; do not attempt to conceal the hypervisor or bypass security checks.

VM provisioning and performance
- Include concise, tested setup instructions for both VMware Workstation Pro and VirtualBox. State minimum and recommended CPU/RAM/disk settings, prioritizing low-spec operation and avoiding unnecessary background services.
- Use a small virtual disk, modest display resolution, limited vCPU/RAM, and snapshots/checkpoints. Explain how to revert to a known-good state and securely delete the disposable VM.
- Provide setup scripts only for benign configuration and provisioning. Scripts must be idempotent, have a dry-run or confirmation mode where practical, log changes, validate prerequisites, and include a clear undo/reset path. Never silently weaken host security.

Network containment and WireGuard
- Provide a simple WireGuard setup guide for a dedicated lab tunnel, with placeholder configuration values and instructions to obtain a legitimate VPN profile from a provider or lab gateway. Do not embed credentials or private keys.
- Enforce a strict guest-level killswitch: default-deny outbound traffic, allow only the WireGuard tunnel interface and the minimum traffic needed to establish/maintain its handshake, and ensure guest traffic stops if the tunnel/interface drops. Include DNS leak prevention and IPv6 handling (disable IPv6 in the guest or apply equivalent leak-proof rules).
- Explain how to test the policy by checking the public egress address while connected, then deliberately stopping the tunnel and verifying that no outside connectivity or DNS resolution remains. Include a safe failure mode and troubleshooting steps. Never claim leak protection without a test.
- Do not route traffic through the host’s ordinary network as a fallback. Document that a VPN does not make unsafe activity acceptable or anonymous.

Strict VM/host isolation
- Use host-only networking for offline practice by default. If Internet access is explicitly needed for a controlled lab, use a separately documented NAT segment with the guest killswitch; never bridge the VM to the physical LAN.
- Disable shared clipboard, drag-and-drop, shared folders, USB passthrough, and other host/guest integration features by default. Include VMware .vmx examples for disabling clipboard and drag-and-drop, and the corresponding VirtualBox GUI/command-line settings. Verify the settings after every import/update.
- Treat host-only as the default and require an explicit operator action to enable the isolated NAT lab segment. Explain that no real target systems or accounts may be contacted.

Local Troll Control Panel
Implement a local-only operator panel using Python/Tkinter or a lightweight local web UI. Choose the simplest maintainable option and document how to start/stop it. Bind any web interface to loopback only; if a secondary host-side control endpoint is provided, use an explicit allowlist/firewall rule, authentication token, and no exposure to the LAN/Internet. Do not create a covert remote-control channel.

Features, only within the disposable guest and with clear operator status:
- Mouse chaos: reversible inverted X/Y axes, bounded “drunken” jitter with adjustable intensity and duration, and swapped left/right clicks.
- Keyboard gremlins: a reversible, bounded typo generator for a controlled practice text field only (never system-wide text entry), plus a sticky number-pad demo that is visibly enabled and can be stopped immediately.
- Fullscreen cosmetic overlays: simulated Windows 10 blue-screen and Windows Update screens. They must be clearly fictional in code and documentation, must not imitate real crash/update behavior, must not modify or interrupt the operating system, and must dismiss with Esc. Avoid collecting or displaying personal data.
- Panic hotkey F12: immediately stop all effects, remove overlays, restore normal input behavior, release any held keys/buttons, and show a clear confirmation. If global hooks cannot be safely and reliably reset, do not use them; instead constrain effects to the panel/demo window.
- Secondary operator control: provide a visible system-tray controller or a loopback-only control page so the operator can start/stop effects from outside the guest view. Include authentication for any host-to-guest control path and document its threat model. Panic must remain available from both primary and secondary controls.
- Add a master enable switch, per-effect duration limits, and a prominent “sandbox active” indicator. Default all effects off at startup. Do not install persistent hooks or run at login unless explicitly opted into by the operator.

Reliability, accessibility, and testing
- Make the UI usable with keyboard navigation and readable contrast. Ensure all effects have bounded duration and can be cancelled.
- Add unit/integration tests for effect start/stop, panic reset, overlay Esc dismissal, authentication, loopback binding, and network-killswitch behavior. Include a manual test checklist for VMware and VirtualBox.
- Ensure crashes or panel termination return inputs to normal. Explain any OS permission requirements and avoid requesting administrator privileges unless essential.
- Provide a README with architecture, prerequisites, setup, operation, teardown, recovery, known limitations, and a safety checklist. Include a file tree and exact commands for install, launch, tests, and clean removal.
- Do not claim a feature or security property works until it is implemented and tested. Report any platform-specific limitations plainly.

Deliverables
1. A complete working project with source code and tests.
2. Reproducible VM setup documentation for both hypervisors, including the optional Scammer.info reference path and the clean-room path.
3. A transparent, reversible guest personalization script (not anti-VM spoofing), plus an undo/reset script.
4. WireGuard and strict killswitch instructions with a test procedure and fail-closed behavior.
5. Isolation configuration examples, including relevant .vmx entries and VirtualBox equivalents.
6. A final summary of what was built, how to run it, test results, and any remaining limitations.