Three green checks, and the root cron job was still sitting in /etc

An operator tidying up scheduled tasks on his Synology NAS opened Task Scheduler, saw two power entries he did not remember creating, and went looking for an explanation; in the system crontab he instead found a root job invoking a hidden script every 20 minutes ^[1][3]. The vendor's own Security Advisor, run as a full scan, reported no malware, no mining software and no malicious system configuration files while both malicious files were on the disk ^[8][9].

The account is a single first-person write-up published on dev.to, whose author states that every command output, version number and CVE ID in it came from the actual investigation ^[20]. The power schedule turned out to be unrelated to the compromise ^[2]. That is the part worth sitting with: the artifact that triggered the question was innocent, and without the question the file would not have been opened ^[2].

The crontab line was `*/20 * * * * /bin/sh /etc/.conf #Sn5Yj8A2l0T`: a dot-prefixed file in /etc, run as root, tagged with a random marker string ^[3]. The script checked four conditions. If it had been deleted, it wgot itself back. If /etc/crontab lacked its marker, it overwrote the file with `>` rather than appending, reinstalling its own line. If /etc/rc.subr lacked the marker, it appended a boot-time invocation. If the payload was not running, it downloaded a file with a .png extension, saved it as `node`, and executed it ^[4]. The .png was not an image; its first bytes were the ELF header, making the extension camouflage ^[5]. It lived at /etc/node, 568 KB, dated 14 January, while the real Node.js binary sits at /usr/local/bin/node ^[6]. He found it in July, six months later ^[7]. At a 20-minute cadence that is roughly 72 executions a day and on the order of 13,000 over the dwell period ^[19].

Three reasons the scanner stayed green, per the author. The payload was UPX-packed, and the only readable string he could extract from it was the UPX project URL, so a signature matcher had no fingerprint to compare against ^[10]. The dropper was an ordinary shell script: wget, chmod, echo, every line legitimate in isolation, malicious only in combination ^[11]. And the cron entry was valid syntax, indistinguishable from a legitimate schedule to a check that looks for known-bad templates ^[12].

The entry route was named in the download URL itself. The filename contained "synology-10441", which the author connects to CVE-2024-10441, an unauthenticated remote code execution flaw in the DSM system plugin daemon, CVSS 9.8, out of Pwn2Own 2024 ^[14]. His NAS was running below the fixed build, with the advisory published in late 2024 ^[15]. His first theory, a brute-forced password because auto-block was off, was wrong: the flaw needs no authentication, so auto-block would have changed nothing ^[16]. What it did need was an unpatched DSM plus a management interface reachable from the internet ^[17]. Testing four ports from a phone on mobile data, he got refusals, meaning no port forwarding; the exposure came from QuickConnect, which relays through vendor servers ^[18]. He recorded SHA256 hashes of both files before cleanup ^[13].

Worth checking on your own boxes: the installed build against the vendor's fixed build ^[15], the crontab and rc files against a known-good copy rather than against a scanner verdict ^[12], and whether a vendor relay feature is providing reachability you believe you removed at the router ^[18].