Fan noise at odd hours on a Synology is often just scheduled tasks, so rule that out before assuming malware — DSM runs things at night/early morning that people don’t expect: backup jobs, hyper backup schedules, S.M.A.R.T. tests, index/re-indexing after new files (Synology Indexing is a classic CPU spike), snapshot rotation, and auto DSM updates. Check Control Panel → Task Scheduler and the Resource Monitor / Log Center for what was actually running at those times. If the spikes correlate with a scheduled task, it’s benign.

If it’s genuinely unexplained, here’s how to actually check a Synology for compromise — note that you can’t run ClamAV scans of the DSM system itself easily; you scan data shares and look at process-level indicators:

1. System-level indicators (most valuable):

• SSH in and check ps aux for processes you don’t recognize, especially anything running from /tmp, /var/tmp, or with weird encoded command lines (base64, curl | sh patterns).
• netstat -tunap (or ss -tunap) — look for established outbound connections you can’t explain. Crypto miners and C2 beacons show up here. Match the PIDs back with lsof -p <pid>.
• crontab -l for root and every user, plus /etc/crontab and /etc/cron.d/ — persistence almost always lands here on NAS malware (e.g. the old Synology ransomware families).
• Check /usr/local/bin/ and /usr/local/etc/rc.d/ for unknown binaries/startup scripts.
• DSM’s own logs: Log Center filtering for failed logins — a wall of auth failures means it’s being brute-forced (usually from the internet if you have DSM ports exposed). “Weird noise” + constant fan + brute-force attempts = someone found your DSM port.

2. Data-share scanning:

• Install ClamAV from Package Center and scan shares, or manually hunt the usual ransomware canaries: files like README_FOR_DECRYPT.txt, !!!.txt, HOW_TO_FIX.txt in shares: find /volume1 -iname "*decrypt*" -o -iname "*readme*.txt" -newer /volume1/some_known_file 2>/dev/null
• Look for unusually recent mass file modifications: find /volume1/homes -mtime -1 -type f | wc -l — thousands of files changed overnight when nobody touched the NAS is a ransomware signature.

3. If you find something or want to be sure: the honest answer is a NAS is not forensically cleanable reliably — DSM doesn’t give you a trusted base to scan from. The robust path is: export what you need, wipe and reflash DSM from Synology Assistant, restore data, and then close the actual door — which for most compromised NASes is DSM port-forwarded to the internet. Put it behind a VPN (WireGuard/Tailscale) instead and 90% of this risk class disappears.

Also worth checking: synoupgrade --check for a pending DSM update, and Security Advisor (Package Center) which automates several of the checks above.