# Antivirus false-positive playbook for the MoonBite miner Status: playbook, 2026-10-10. Companion to `docs/SIGNING-AND-NOTARISATION.md`, `docs/REPRODUCIBLE-BUILDS.md`, `release/miner/ANTIVIRUS.md` (the short user-facing note shipped inside the bundle) and the verifier scripts `scripts/release/verify-release.sh` / `scripts/release/Verify-Release.ps1`. The MoonBite miner is a RandomX CPU miner. Security products will flag it. This is expected, it is not evidence of malware, and it will keep happening with every release because detection is on the **class of software**, not on a bug we can fix. The job is to (a) build in a way that gives heuristics the fewest excuses, (b) make every release independently verifiable, and (c) submit every release to the vendors that flag it, with the same factual text, every time. --- ## 1. Why RandomX miners are flagged - **JIT code generation.** RandomX compiles random programs to native machine code at runtime and executes them from writable-then-executable memory. Behavioural engines score "allocate RWX pages, write code, jump into it" as shellcode-like. - **Large page / huge memory allocation.** The RandomX dataset is about 2 GiB (fast mode) and the miner requests large pages (`SeLockMemoryPrivilege` on Windows, `madvise`/hugetlbfs on Linux). Few benign desktop programs do this. - **Sustained 100 percent CPU on all cores** for hours, with periodic network traffic to a node. Cryptojacking malware looks identical from the outside; the only difference is consent. - **Shared ancestry with XMRig.** Any RandomX implementation shares code patterns and strings (`randomx`, `dataset`, `hugepages`, `donate`) with XMRig, which is the single most abused miner binary in the world. YARA rules written for XMRig match on those strings. Vendors name these detections `PUA.CoinMiner`, `PUA:Win32/CoinMiner`, `Riskware.BitCoinMiner`, `PUA.Win64.XMRig`, `not-a-virus:RiskTool.Win64.BitCoinMiner`, `HackTool`, `Trojan.CoinMiner` and similar. "PUA" and "RiskTool" and "not-a-virus" mean "legitimate software often deployed without consent"; "Trojan" means the engine could not tell the difference. - **Bitdefender's own explanation**: coin miners "are considered Potentially Unwanted Applications (PUA) by cybersecurity vendors, even when the application is legitimate", because attackers reuse the exact same binaries. https://www.bitdefender.com/en-us/blog/hotforsecurity/why-security-software-detects-coin-miners-as-potentially-unwanted-applications - **Trend Micro** classifies XMRig builds as `PUA.CoinMiner` / `PUA.Win64.XMRig`: https://trendmicro.com/vinfo/be/threat-encyclopedia/malware/pua.win64.xmrig.kbw - **Monero's documentation** tells users the same thing about XMRig: some antivirus flags it "because it is often deployed to infected computers to mine without the owner's consent", and that on your own computer you configured it yourself. https://docs.getmonero.org/interacting/mining/guides/help/ Consequence: a miner will never reach zero detections. Target: zero **"Trojan"/"malicious"** verdicts from the major engines, and honest **PUA** labels where vendors insist, with Microsoft Defender, Google Safe Browsing and Chrome not blocking the download. --- ## 2. Build-time mitigations Each item removes one heuristic signal. Do all of them; none alone is enough. | Do | Why | |---|---| | **No UPX or any packer**, no obfuscation, no string encryption | Packed sections are the strongest static malware signal there is | | **Native build, not PyInstaller/onefile.** If a Python launcher is unavoidable, use **onedir**, never onefile, and rebuild the bootloader from source | onefile extracts an interpreter and DLLs to `%TEMP%\_MEIxxxx` and runs from there, which matches the "dropper" pattern; the stock bootloader hash is shared with thousands of malicious samples | | **Version-info resource** on every Windows PE: `CompanyName=MoonBite Labs`, `ProductName=MoonBite Miner`, `FileDescription`, `FileVersion`, `LegalCopyright`, `OriginalFilename` matching the real filename | Missing or generic version info is a heuristic hit; consistent metadata is also what SignPath and vendors look for | | **Consistent publisher and product names** across releases, binaries, site and VirusTotal comments | Vendors whitelist by publisher string and hash lineage | | **No self-update, no download-and-execute** | "Downloads and runs code" is a textbook dropper behaviour. Updates are a new release the user fetches | | **No drops into `%TEMP%`, `%APPDATA%`, `/tmp`** at runtime; data goes to the explicit MoonBite data directory | Writing executables or scripts to temp dirs is a stage-2 malware pattern | | **No persistence**: no Run key, no scheduled task, no service, no launchd/systemd unit, no cron, no Startup folder | Persistence turns a PUA verdict into a Trojan verdict. Users who want autostart do it themselves | | **No process injection, no hidden windows, no `--background` daemonising on Windows**; the console stays visible while mining | Hidden CPU burn is the cryptojacking signature | | **No anti-debug, no VM detection, no sleep-to-evade** | Sandboxes flag evasion harder than anything else | | **Clear banner at start**: program name, version, what it mines, which address, how to stop | Analysts read the sandbox screenshot | | **Large pages requested, not forced**: fall back cleanly without elevating privileges or editing the user's privilege policy | Changing `SeLockMemoryPrivilege` via `secedit`/registry at runtime is a known XMRig-launcher trick that vendors key on | | **Static link where practical; otherwise ship dependencies in the archive**, never fetch them at runtime | Fewer unknown DLLs, no downloads | | **Wallet never bundles the miner; miner never bundles the wallet** | Keeps the wallet's reputation clean and gives the miner a single, honest story | | **Website never mines in the browser**, no WASM/JS miner, no "demo" that uses real CPU | Browser miners are blocked by all engines and by Safe Browsing | | **Reproducible build** (`docs/REPRODUCIBLE-BUILDS.md`) from a tagged commit in GitHub Actions with `actions/attest-build-provenance` | Lets the vendor (and users) confirm the hash is the repo's output | | **Sign if at all possible** (`docs/SIGNING-AND-NOTARISATION.md`); otherwise minisign the manifest | Signed files inherit publisher reputation; unsigned start at zero every release | | **Timestamp every signature** if signing | So the signature stays valid after the certificate expires | | **Keep the archive small and flat**: binary, `mine.sh`/`mine.ps1`/`.bat`, `README`, `ANTIVIRUS.md`, `SHA256SUMS.txt`, `.minisig` | Fewer files, fewer heuristics | Sources for the packaging points: PyInstaller false-positive discussion https://discuss.python.org/t/pyinstaller-false-positive/43171 and https://beatsyncpro.ai/blog/why-pyinstaller-gets-antivirus-flags.html ; Microsoft on not signing PUA-like behaviour and consistent identity https://learn.microsoft.com/en-us/windows/apps/package-and-deploy/smartscreen-reputation --- ## 3. SmartScreen is reputation, not detection "Windows protected your PC / Unknown publisher" is **Microsoft Defender SmartScreen**, not Defender Antivirus. It means the file hash (and, if signed, the certificate) has not yet accumulated enough clean downloads. Microsoft's current guidance (May 2026): - Reputation is built from two signals, publisher and file hash. Unsigned files start at zero on every new version; signed files can inherit the certificate's reputation. - EV certificates no longer bypass SmartScreen. - "There is no need (or mechanism) to manually submit a file for SmartScreen reputation review for consumer endpoints. Reputation builds organically through download volume." Typically "several weeks and hundreds of clean installs from a wide audience". - Enterprise admins can submit files through the Security Intelligence portal for managed deployments. Source: https://learn.microsoft.com/en-us/windows/apps/package-and-deploy/smartscreen-reputation So: do not file SmartScreen "false positives" for an unsigned release; there is nothing to correct. Tell users what the dialog means, point them at the SHA-256 / minisign / attestation check, and let reputation accrue. If SmartScreen says **"malicious"** rather than "unrecognized", that is a Defender detection and goes through the WDSI submission below. --- ## 4. Per-release submission checklist Run this on release day, after `SHA256SUMS.txt.minisig` is published and `gh attestation verify` passes, and before announcing. Budget about 90 minutes. Keep a `release/vX.Y.Z-av-submissions.md` log (date, vendor, submission ID, detection name, outcome). Do it from a pseudonymous project mailbox (`security@moonbite.org` or similar); no vendor form below requires a legal name. ### 4.0 Pre-scan on VirusTotal 1. Upload each artefact (zip, tar.gz, exe) to https://www.virustotal.com/gui/home/upload. Note the SHA-256 shown; it must equal the line in `SHA256SUMS.txt`. 2. Record which engines flag, with the exact detection name, in the log. Separate "PUA/RiskTool/not-a-virus" from "Trojan/Malware/Generic". 3. Post a **community comment** on each file's VT page, signed in as the project account, using the template in section 5 with the hashes and attestation line. Tag it `#falsepositive #opensource #cryptominer`. 4. VirusTotal's own vendor contact list is the most maintained index of submission channels: https://docs.virustotal.com/docs/false-positive-contacts Check it each release for URL changes. 5. Re-check the VT page one week later; many vendors fix silently and the detection count should fall. Note the drop in the log. ### 4.1 Vendor submissions (current URLs, verified 2026-10-10) For each vendor that flagged the file on VT, or that users report: | Vendor | Where | Notes | |---|---|---| | **Microsoft Defender** (and Smart App Control) | https://www.microsoft.com/en-us/wdsi/filesubmission (short link https://aka.ms/wdsi) | Choose "Software developer", product "Microsoft Defender Antivirus"; pick "Incorrectly detected as PUA" or "Incorrectly detected as malware" as appropriate; attach the zip; paste the template. Sign in with the project Microsoft account so you can see submission history. If the details page errors, keep the submission ID and email `mpcreply@microsoft.com` quoting it (community-reported route) | | **Google Safe Browsing / Chrome download warning** | Site owners: Search Console > Security Issues > Request review for the exact file URL. Non-owner or no issue listed: https://safebrowsing.google.com/safebrowsing/report_error/ | Register `moonbite.org` in Search Console in advance so "Harmful downloads" sample URLs are visible. Google "take up to 72 hours"; community reports 5 days. Chrome's download warning is also fed by the engines flagging the file, so fix those too. Guidance: https://web.dev/articles/request-a-review | | **Avast / AVG** (Gen Digital) | https://www.avast.com/report-false-positive ; AVG: https://www.avg.com/submit-sample and https://www.avg.com/us-en/whitelist | Same lab since 2016; one submission usually clears both. Email alternative `DL-Virus@gendigital.com` | | **Avira** (Gen Digital) | https://www.avira.com/en/analysis/submit | Email alternative `novirus@avira.com` | | **Bitdefender** | Sample / URL submit form https://www.bitdefender.com/en-us/business/submit (choose category "False positive"; reaches the same research team for consumer products); consumer guidance https://www.bitdefender.com/consumer/support/answer/40673/ | Zip if over 25 MB; include detection name. Email alternative `virus_submission@bitdefender.com`. Guidance: https://www.bitdefender.com/business/support/en/77211-343054-resolving-legitimate-applications-detected-as-threats-by-bitdefender.html | | **ESET** | Email `samples@eset.com`, subject "False positive", archive password `infected`; or in-product "Submit sample for analysis" with reason "False positive file" | ESET KB141: https://support.eset.com/en/kb141-submit-a-virus-website-or-potential-false-positive-sample-to-the-eset-lab . No reply unless they need more info | | **F-Secure / WithSecure** | https://www.withsecure.com/en/support/contact-support/submit-a-sample | Legacy emails `vsamples@f-secure.com`, `spyware-samples@f-secure.com` | | **Kaspersky** | https://opentip.kaspersky.com/ : upload, then "Submit to reanalyze" on the result page and give the project email | Guidance: https://support.kaspersky.com/1870 . Legacy email `newvirus@kaspersky.com` | | **Malwarebytes** | https://forums.malwarebytes.com/forum/122-false-positives/ (free users; create a project forum account); paid users via support | Guidance: https://help.malwarebytes.com/hc/en-us/articles/31589211404571-Report-a-false-positive-to-Malwarebytes-Support | | **McAfee** (Trellix consumer) | https://www.mcafee.com/support/s/article/000001921?language=en_US (how to submit); enterprise dispute form https://www.mcafee.com/enterprise/en-us/threat-center/detection-dispute-form.html | Email `virus_research@mcafee.com` returns automated reports only | | **Norton / Gen (Symantec engine)** | https://submit.norton.com/ (file and URL disputes); enterprise Broadcom: https://symsubmit.symantec.com/ | Guidance for Symantec Endpoint: https://knowledge.broadcom.com/external/article/173729/how-to-submit-false-positives-on-content.html . If no change after 48 business hours, open a Norton support chat quoting the dispute | | **Sophos** | https://support.sophos.com/ > Submit a sample (requires a free Sophos ID); email `samples@sophos.com` | 10 MB upload cap on the form; zip the exe only. 3-5 working days | | **Trend Micro** | https://www.trendmicro.com/en_us/about/legal/detection-reevaluation.html | Zip or RAR, 12 MB max, password-protected, password in the "Details" field. Email alternative `virus_doctor@trendmicro.com` | | **Webroot** (OpenText) | https://www.webroot.com/us/en/business/support/vendor-dispute-contact-us (vendor dispute); consumers report in-app or via a support ticket | One ticket per file; a second ticket resets the queue position | If a vendor is not in the table (Jiangmin, Antiy, Cynet, SecureAge, Zillya, etc. often appear on VT), use the VirusTotal contacts page above; low-share engines are rarely worth more than one email. ### 4.2 After submitting - Log every submission ID. - Re-scan on VT after 72 hours and after 7 days; update the log. - If a major engine (Microsoft, Google, Avast, Bitdefender, Kaspersky, ESET, Norton) still returns "Trojan"/"Malware" after two weeks, escalate once via the same channel quoting the ID, and add a notice to `/mine`. - Post the outcome summary (counts only, no drama) in the release notes: "VirusTotal at release: N/72 engines, all PUA/RiskTool class, submitted to the N vendors; at +7 days: M/72." - Never ask users to disable their antivirus. The correct user instruction is "verify the hash and signature, then add an exclusion for this folder if you choose to run it". --- ## 5. Submission text template Use verbatim, filling the brackets. Same text for every vendor and for the VirusTotal comment, so analysts see consistency across channels. ``` Subject: False positive - open-source cryptocurrency CPU miner (MoonBite) This is an open-source cryptocurrency CPU miner for the MoonBite coin (RandomX proof of work), published by MoonBite Labs at https://moonbite.org/mine and https://moonbite.org/mine[vX.Y.Z]. File: [moonbite-miner-windows-x86_64.zip] SHA-256: [64 hex] Contained binary: [moonbited.exe] SHA-256 [64 hex] Version: [X.Y.Z], released [YYYY-MM-DD] Detected as: [vendor detection name, e.g. PUA:Win32/CoinMiner] Reproducible build: built by GitHub Actions from tag [vX.Y.Z], commit [sha], workflow https://moonbite.org/git/moonbite-network[id]. Build provenance attestation verifiable with: gh attestation verify [file] --repo moonbitecoin/moonbite-network Release manifest SHA256SUMS.txt is signed with minisign, public key [RWQ...] (published at https://moonbite.org/.well-known/moonbite-release.pub and in DNS TXT _moonbite-release.moonbite.org). Source: https://moonbite.org/git/moonbite-network (MIT), node: https://moonbite.org/git/moonbite-core. Behaviour: the program mines only when the user starts it from a visible console and stops when closed. It does not install persistence (no services, scheduled tasks, run keys, launch agents or cron), does not self-update, does not download or execute code, does not write to temp directories, does not hide its window and is not bundled with any other software. The MoonBite wallet is a separate download and does not include the miner. Large-page memory is requested with graceful fallback and no privilege changes. The detection is accurate as "coin miner" but incorrect as malware or as unwanted: the user explicitly downloads and runs it to mine for themselves. We request reclassification to clean, or at most to a PUA/RiskTool label that the user can allow. Contact: [security@moonbite.org] ``` For the VirusTotal community comment, drop the Subject and Contact lines and add the hashtags `#falsepositive #opensource #cryptominer #moonbite`. --- ## 6. User-facing wording (site and bundle) The `/mine` and `/get-wallet` pages carry an "Antivirus warnings and how to verify" section with this content, and `release/miner/ANTIVIRUS.md` ships the same in the bundle: - A CPU miner may be flagged as "CoinMiner" or "PUA" by antivirus software. That is a classification of what miners are, not a finding about this file. - MoonBite never bundles the miner with the wallet, and the website never mines in your browser. - Windows may show "Unknown publisher"; macOS may say the developer cannot be verified. Our builds are currently unsigned by a platform certificate; that is why we publish a SHA-256 manifest, a minisign signature and a GitHub build attestation for every release. - Verify before you run: compare the SHA-256, check the minisign signature against the key printed on the site, in the repo and in DNS, and run `gh attestation verify`. The scripts `verify-release.sh` and `Verify-Release.ps1` do all three. - If the hash does not match, do not run the file; report it. --- ## 7. What never to do - Never obfuscate, pack or rename the binary to dodge a signature; that is exactly what malware does, and it will convert a PUA into a Trojan verdict and poison the publisher name for good. - Never tell users to turn off Defender or SmartScreen. - Never bundle the miner into the wallet installer "for convenience". - Never mine in the browser, even as a demo with real hashing. - Never submit a build to a vendor before its hash is in the signed manifest; the vendor's whitelist entry would then point at a file users never receive.