Sign In

1. Download and verify the collector. Select this machine's platform above and download the signed collector. On Windows, right-click the file, open Properties › Digital Signatures, select Cyber Automation Pty Ltd and confirm that Details reports the signature is OK. On Linux, also download the signature and the signing public key (on a server without a browser use the curl link above, the same link with .asc appended, and the same site's /downloads/c4c/public-key.gpg), then run:

   gpg --import public-key.gpg
   gpg --verify OverWatchC4C.asc OverWatchC4C
   chmod +x OverWatchC4C

   Continue only if gpg reports a good signature and the primary key fingerprint matches the signing fingerprint shown above (spacing differs; the "not certified with a trusted signature" warning is expected).
2. Create the assessment with the same platform still selected. Its six-digit pairing code appears in the assessment row below and is valid for five hours. Get pairing code issues a replacement at no extra cost and any earlier code stops working. The code is offered only while the assessment is waiting for its collector. A collector for any supported platform can use it: the assessment takes the platform of the machine that pairs, so the platform selected here only chooses which collector to download.
3. Assess the same machine again with Run again on its assessment: it creates a new assessment with the same name and platform (1 credit) and shows its pairing code. Earlier runs keep their reports and are listed with it.
4. Run the collector from the folder that holds it, as Administrator or root:

   cd C:\Users\<you>\Downloads
   .\OverWatchC4C.exe

   sudo ./OverWatchC4C

   At the Six-digit pairing code: prompt type the six digits and press Enter. Nothing else is needed: the OverWatch address is built into the signed collector, and there is no account, password, configuration file or baseline to supply. Use the same account, and the same use of sudo, for every run of an assessment, because the collector keeps its state in that account's profile.
5. Let it finish. The collector pairs, inspects process memory, discovers services and web roots from service configuration and running processes (IIS, Apache, nginx, Tomcat, Jetty, ASP.NET Core, Node.js and Python applications), runs each compromise check behind a [n/N] progress line, assesses installed software, listeners and security controls, saves the evidence and uploads it. On Linux, collector release 4.9.33 and later inventory every dpkg, rpm, apk and pacman package database present and upload the operating system's own identity files; earlier collectors query only the first package manager they find and do not inventory Alpine's apk. It ends with Evidence received by OverWatch. Your report will appear in Check 4 Compromise. Most hosts take a few minutes. The run, including time spent at the pairing prompt, is capped by --max-duration (default 2 hours); if the cap is reached, the partial evidence collected so far is saved and uploaded in that same run (unfinished checks are marked skipped; collectors before 4.9.27 save it but need the same command run again to upload it). Do not press Ctrl-C: an interrupted run keeps the partial evidence it has, and the rerun uploads that instead of collecting again.
6. Collect the report. The row moves through received and reporting to complete, when the PDF report button appears (the list refreshes while this tab is open). If it shows report error, use Retry report (at most two retries; if the report is reported as not retryable, contact support and the evidence is kept). Nothing more runs on the machine. Running the collector again starts a new assessment: it says the previous evidence was received and where it is kept, then asks for a new pairing code (press Ctrl-C at the prompt if you did not mean to). Collectors 4.9.31 and earlier instead print Evidence was already received by OverWatch and stop; see Assess the same machine again. Delete permanently removes a complete, failed or cancelled assessment together with its stored evidence and report after an are-you-sure prompt (cancel a running assessment first); it never refunds the credit.
7. If something goes wrong. pairing code rejected right after the prompt (collectors before 4.9.27 print server returned HTTP 401) means the code was mistyped, expired, replaced by a newer code, already used, issued for another platform, or the assessment was cancelled. The collector accepts one code per run, so get a valid code and run the command again. After Evidence saved:, a message that the assessment was cancelled or that collector access expired means the upload is refused for good and the evidence stays on the machine; create a new assessment and run the collector again, and it starts the new assessment and asks for its code (collectors 4.9.31 and earlier need --new-assessment for that, as their message says; collectors before 4.9.27 print server returned HTTP 401 there too). If the collector stopped before "Evidence received" (network, closed window, restart), run the same command again within 72 hours of pairing; it resumes without a new code or credit. The collector makes outbound HTTPS connections to the OverWatch address only and uses a proxy only from the HTTPS_PROXY environment variable; sudo drops that variable, so pass it explicitly (sudo HTTPS_PROXY=http://proxy:port ./OverWatchC4C), and on Windows set it in the elevated console because the system proxy settings are not used.
8. Assess the same machine again once its previous evidence was received, or the previous assessment was cancelled or expired: create a new assessment (1 credit) and run the same command. The collector says what became of the previous assessment and which folder keeps its evidence (that evidence is never changed), then starts a new assessment and asks for the new code. If that attempt fails, run the command again and enter a valid code. An assessment whose evidence has not been uploaded yet is always resumed first; run the command again once it ends with "Evidence received". --new-assessment is still accepted but no longer needed. Collectors 4.9.31 and earlier do not start a new assessment by themselves: if the collector prints Evidence was already received by OverWatch and stops, or says to use --new-assessment, run it again with --new-assessment, or download the current collector above.

Options. --webroot followed by an absolute path (repeatable) adds an application folder that discovery cannot find; discovery still runs. --max-duration 4h raises the time limit (1m to 24h). --output-dir chooses where state and evidence are kept; by default that is OverWatch\C4C under the configuration folder of the account the collector runs as (%AppData%\OverWatch\C4C on Windows, $HOME/.config/OverWatch/C4C on Linux, which is /root/.config/OverWatch/C4C under sudo), private to that account, with each assessment's evidence in its own subfolder. --offline collects locally only: no pairing, no upload, no report, and no credit as long as you do not create an assessment. --version prints the collector version; for this dashboard release it should read 4.9.60, matching the signed collector version shown above.

The report separates compromise indicators, configuration weaknesses, vulnerability matches and areas that could not be examined. Collection only reads: it never remediates, has no remote command shell and installs no service. Its only lasting writes are its own state and evidence files in the private output folder, which stay on the machine until you delete them; raw physical-memory analysis also uses a temporary workspace in the system temp folder that is removed afterwards. Because it reads other processes' memory and runs system queries, allow-list the collector in your EDR first or expect alerts. Findings require investigation; an assessment cannot prove a compromised host is clean. You can cancel an assessment until its evidence is received. Cancelling revokes the collector's access, does not refund the credit and does not stop a collector that is already running; its upload is then refused.

Use this to examine evidence from another machine: a mounted disk image, process memory dumps or a raw physical memory image. Run the collector on a trusted Windows or Linux analysis machine; either can examine Windows or Linux memory dumps, memory images and mounted disk images (a Windows analysis machine needs collector release 4.9.25 or later for mounted disk images; see below). Select the analysis machine's platform above, create one assessment per evidence set (at most five can be waiting or collecting at once), and enter its six-digit code at the prompt as usual. Run as Administrator or root so protected files in the evidence can be read, and give every case its own empty --output-dir outside the evidence. Live checks on the analysis machine are skipped. The report shows the evidence mode, subject operating system and selected paths separately from the analysis machine, whose hostname appears in the assessment row.

Mounted filesystem. Mount the image read-only (the collector cannot verify this) and point --evidence-root at the mounted directory by its absolute real path, with no symbolic links. A drive or filesystem root such as E:\ or / is refused. On a Windows analysis machine, mount the image into an empty NTFS folder (Disk Management's Mount in the following empty NTFS folder, mountvol, or the imaging tool's folder-mount option) and select that folder, typed exactly as Explorer shows it: volume mount points are accepted as the evidence root from collector release 4.9.25. Releases up to 4.9.23 refuse a mount-point folder with evidence root must be a directory; with those, use an ordinary folder that holds an extracted copy of the evidence tree. Directory junctions (mklink /J) and symbolic links are refused on every release; select the real directory instead. The evidence operating system is detected from Windows\System32\config\SYSTEM or etc/os-release (from collector release 4.9.33 also usr/lib/os-release and release files such as etc/redhat-release, so a RHEL or CentOS 6 image is detected as Linux); add --evidence-os windows or --evidence-os linux when neither or both exist, or to override detection. Volumes mounted underneath the root, such as a separate /var or /home, are skipped: examine each as its own assessment with --evidence-os set, and expect path-dependent coverage such as the Debian package database under /var/lib/dpkg to be missing for a volume examined on its own. --webroot and baselines cannot be combined with evidence selection.

sudo ./OverWatchC4C --evidence-root /mnt/evidence --output-dir /var/tmp/c4c-case
.\OverWatchC4C.exe --evidence-root C:\Evidence\image --output-dir C:\C4C\case

Process memory dumps. --memory-dump accepts ELF process cores and Windows user-mode minidumps: up to 16, repeatable, and combinable with --evidence-root. Use full dumps that include memory-protection information; small minidumps yield no executable-memory findings. Kernel crash dumps such as MEMORY.DMP are not process dumps. Keep dumps on a local drive and outside the output directory.

.\OverWatchC4C.exe --memory-dump C:\Evidence\process.dmp --evidence-os windows --output-dir C:\C4C\case

Raw physical memory images. --physical-memory-image (up to 4) needs --evidence-os windows or --evidence-os linux, --volatility-path and --volatility-symbols. The engine path must be the absolute path of the Volatility 3 program file itself: installed system-wide, not a pip --user or pipx shim or symbolic link, on Linux executable and not group- or world-writable, at most 128 MiB, and outside the evidence. The symbol path must be an absolute path to a prepared local symbol directory that is not a symbolic link. Keep images, engine and symbols on a local drive. --volatility-sha256 optionally pins the SHA-256 of that program file only, not the Python interpreter, the volatility3 package or its plugins. Missing or unusable files are refused before pairing, but engine, symbol and dump-format problems appear only as check errors in the evidence and report after the code has been used. Test the exact command first with --offline and a separate output directory, then open the evidence.json it names and confirm that no memory check has status "error"; the console does not list these errors.

Raw images and dumps never leave the analysis machine; the report receives derived findings, hashes, sizes, paths and the engine version. --offline keeps everything local: no pairing, no upload and no report. C4C does not acquire memory, mount disks, unlock encrypted volumes or install drivers. Deleted or unallocated disk areas and unavailable symbols remain reported coverage gaps.