First, a caveat: fan noise spiking at odd hours is often just DSM doing its own housework (scheduled tasks run by default in the middle of the night — indexing photos, deduplication, etc.). Check Control Panel → Task Scheduler before assuming malware; if the noisy jobs are legit DSM ones, that’s your answer.

If you still want to verify the box is clean, since Synology DSM is basically a locked-down Linux under the hood:

1. Check what’s actually listening and running. SSH in (enable it in Control Panel → Terminal) and run sudo netstat -tulpn and ps aux. Anything unfamiliar with no package owner is a red flag. synowebapi/synology prefixed processes are normal.

2. Check persistence points: crontab -l and /etc/crontab, plus ~/.ssh/authorized_keys for all users — malware loves adding a key.

3. Log review: DSM’s Log Center will show auth failures. A wall of failed SSH logins from random IPs just means the NAS is internet-exposed — which is a fixable problem in itself (move SSH to a non-standard port or better, keep it LAN-only and use Tailscale/WireGuard for remote access).

4. Full scan: Synology has a built-in malware scanner (Security Advisor / synoscan), but it’s fairly shallow. A stronger option is running ClamAV on a separate machine pointed at a read-only mount of the shares — clamscan -r --bell -i /mnt/nas — which catches infected files (Windows-targeting stuff mostly) even if the NAS itself isn’t compromised.

5. If you find something you can’t explain: the safest move on a NAS is a config backup, a full DSM reinstall, and data restore — chasing a rootkit on an appliance is not worth it.

One hardening tip regardless of outcome: disable admin SSH + port-forwarding to the NAS entirely, and don’t expose DSM to the internet directly (use quickconnect or a VPN tunnel instead).

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.

Synology?

SSH in and run top. See what it’s doing. You could compare the checksum of the binaries that are running to make sure that they’re the real binaries, if you really want to get into it.

But if I had to guess, it’s either running a backup or re-running its indexing.

Atop is pretty sweet for logging performance metrics over time and including data on what would have caused it with autosorting by effect of process included. Interface isn’t pretty and seems a little complicated on the surface but there are colors to help. That is if synology has repos to install it.

Could it be doing remote backup during downtime? That could be somewhat compute intensive, if the data is also being encrypted and compressed for the remote target.

Are there no ways to peek at running processes and resource usage on a Sinology NAS? I’d start with that.

Also, how old is the device? Maybe it is overheating due to dirt/dust buildup and some cleaning up and re-pasting would solve the issue.