Synology has issued an urgent advisory to its global customer base: threat actors are actively exploiting a vulnerability in DiskStation Manager (DSM) that was originally patched in December 2024 to conduct ransomware attacks against organizations running outdated firmware. The attacks are straightforward in their objective — encrypt data stored on Network Attached Storage (NAS) devices and extort payment for decryption keys.
This is not a theoretical threat. Synology has confirmed in-the-wild exploitation, and the targeting pattern indicates that adversaries are specifically scanning for internet-facing or otherwise accessible Synology NAS devices that have not been updated to the patched DSM release. For organizations that rely on Synology devices for primary storage, backup repositories, or surveillance footage archives, a successful compromise could result in catastrophic data loss, operational disruption, and potential regulatory exposure depending on the nature of the encrypted data.
The fact that this vulnerability was patched in December 2024 and is still being exploited in 2026 underscores a persistent and dangerous reality: NAS devices are chronically under-patched. They sit in the gap between endpoint management and network infrastructure, often overlooked by vulnerability management programs that focus primarily on servers and workstations. If you are running Synology hardware anywhere in your environment — branch offices, home labs, backup targets — treat this as an immediate action item.
Technical Analysis
Affected Products and Versions
The vulnerability affects Synology NAS devices running DiskStation Manager (DSM) versions prior to the December 2024 patch release. Synology's advisory urges all customers to update to the latest DSM version immediately. While the specific CVE identifier has not been publicly disclosed in the available reporting, the vendor's statement confirms that the flaw was addressed in a security update issued in December 2024.
Devices running DSM 7.x builds prior to the December 2024 patch should be considered vulnerable. This includes the full range of Synology NAS hardware — from compact two-bay units deployed in small offices to enterprise-grade rack-mounted systems used in data centers and media production environments.
How the Attack Works
Based on Synology's characterization, the attack chain follows a pattern consistent with opportunistic ransomware campaigns targeting exposed NAS infrastructure:
-
Reconnaissance and Scanning: Threat actors scan for Synology NAS devices with management interfaces accessible over the network — particularly those exposed to the internet on ports 5000 (HTTP) and 5001 (HTTPS), which are the default DSM management ports. Automated scanning tools can identify DSM version information from service banners or login page responses.
-
Vulnerability Exploitation: The attacker exploits the patched vulnerability to gain unauthorized access to the device. The specifics of the flaw have not been publicly detailed beyond its patch availability, but the outcome — the ability to encrypt data — suggests it provides code execution or administrative-level access to the storage system.
-
Data Encryption: Once access is established, the attacker encrypts files stored on the NAS volumes. On Synology devices, this typically involves traversing shared folders and encrypting files in place, potentially leveraging built-in utilities or deploying ransomware payloads designed for the DSM Linux-based operating environment.
-
Ransom Extortion: The victim is presented with a ransom demand, typically delivered via a note placed on the file system or displayed through the DSM interface.
Exploitation Status
- Active exploitation confirmed: Synology has directly observed threat actors exploiting this vulnerability in the wild against unpatched devices.
- Attack motivation: Financial — data encryption for ransom extortion.
- Target scope: Any Synology NAS device running a DSM version that predates the December 2024 security patch.
- Attack vector: Network-accessible DSM management interfaces, with internet-facing devices at highest risk.
Why NAS Devices Are High-Value Targets
From a threat actor's perspective, NAS devices are attractive targets for several reasons:
- Concentrated data: A single NAS often holds terabytes of business-critical files, backups, and media.
- Weak patch hygiene: Unlike endpoints managed by MDM or GPO, NAS firmware updates are frequently manual and neglected.
- Limited security tooling: Most NAS devices lack EDR, application allowlisting, or behavioral monitoring.
- Backup destruction: If the NAS serves as a backup target, encrypting it eliminates the victim's recovery path, dramatically increasing ransom payment likelihood.
Detection & Response
This is a technical threat with confirmed active exploitation. The following detection content is designed for SOC teams to hunt for indicators of compromise and attack precursor behaviors targeting Synology infrastructure.
Sigma Rules
The following Sigma rules target behaviors associated with NAS exploitation and ransomware activity. The first rule focuses on detecting suspicious process execution patterns on Synology DSM systems via Sysmon for Linux or forwarded syslog. The second targets mass file modification consistent with ransomware encryption activity.
---
title: Suspicious Process Execution on Synology DSM via Shell
id: 8f2a1b34-7c9d-4e5f-a1b2-3c4d5e6f7a8b
status: experimental
description: Detects shell processes spawning encryption or file manipulation utilities on Synology DSM systems, consistent with post-exploitation ransomware activity.
references:
- https://attack.mitre.org/techniques/T1059/004/
- https://attack.mitre.org/techniques/T1486/
author: Security Arsenal
date: 2026/11/05
tags:
- attack.execution
- attack.impact
- attack.t1059.004
- attack.t1486
logsource:
category: process_creation
product: linux
detection:
selection_parent:
ParentImage|endswith:
- '/sh'
- '/bash'
- '/ash'
- '/php'
- '/python'
- '/python3'
selection_child:
Image|endswith:
- '/openssl'
- '/gpg'
- '/tar'
- '/find'
- '/dd'
- '/7z'
- '/zip'
- '/encfs'
condition: selection_parent and selection_child
falsepositives:
- Legitimate DSM backup tasks that invoke tar or openssl
- Administrator scripts performing archival operations
level: high
---
title: Mass File Rename or Extension Change Consistent with Ransomware
id: 2c3d4e5f-6a7b-8c9d-0e1f-2a3b4c5d6e7f
status: experimental
description: Detects rapid file rename operations or creation of ransom note files on network shares, indicative of ransomware encryption activity targeting NAS-hosted data.
references:
- https://attack.mitre.org/techniques/T1486/
author: Security Arsenal
date: 2026/11/05
tags:
- attack.impact
- attack.t1486
logsource:
category: file_event
product: windows
detection:
selection_ransom_note:
TargetFilename|contains:
- 'README'
- 'DECRYPT'
- 'RECOVER'
- 'RESTORE'
- 'HOW_TO'
- 'RANSOM'
TargetFilename|endswith:
- '.txt'
- '.html'
- '.hta'
selection_encrypted_ext:
TargetFilename|endswith:
- '.encrypted'
- '.locked'
- '.crypto'
- '.enc'
condition: 1 of selection_*
falsepositives:
- Legitimate documentation files
- Security awareness training materials
level: high
---
title: DSM Management Interface Access from Non-RFC1918 Source
id: 4d5e6f7a-8b9c-0d1e-2f3a-4b5c6d7e8f9a
status: experimental
description: Detects authentication attempts to Synology DSM management ports from external IP addresses, which may indicate reconnaissance or exploitation attempts.
references:
- https://attack.mitre.org/techniques/T1190/
- https://attack.mitre.org/techniques/T1078/
author: Security Arsenal
date: 2026/11/05
tags:
- attack.initial_access
- attack.t1190
- attack.t1078
logsource:
category: firewall
product: network
detection:
selection:
DestinationPort:
- 5000
- 5001
SourceIp|cidr:
- '0.0.0.0/0'
filter_internal:
SourceIp|cidr:
- '10.0.0.0/8'
- '172.16.0.0/12'
- '192.168.0.0/16'
condition: selection and not filter_internal
falsepositives:
- Legitimate remote administration via VPN (if VPN IPs are not RFC1918)
- ISP-assigned management addresses
level: medium
KQL Hunt Queries (Microsoft Sentinel / Defender)
The following KQL queries are designed for Microsoft Sentinel environments where Synology Syslog is ingested via CEF/Syslog connectors, and where network traffic is visible through firewall logs or Defender for Endpoint network events.
Query 1: Identify inbound connections to DSM management ports from external sources
// Hunt for external connections to Synology DSM management ports (5000/5001)
// Useful for identifying reconnaissance and exploitation attempts
let DSM_Ports = dynamic([5000, 5001]);
CommonSecurityLog
| where DestinationPort in (DSM_Ports)
| where ipv4_is_private(SourceIP) == false
| where DeviceAction !in ("Deny", "Drop", "Block")
| summarize ConnectionCount = count(),
UniqueSources = dcount(SourceIP),
FirstSeen = min(TimeGenerated),
LastSeen = max(TimeGenerated)
by DestinationIP, DestinationPort, SourceIP, DeviceAction
| order by ConnectionCount desc
| project FirstSeen, LastSeen, SourceIP, DestinationIP, DestinationPort, ConnectionCount, DeviceAction
Query 2: Detect ransom note file creation or mass file modification on network shares via Defender for Endpoint
// Hunt for ransomware-like file operations on endpoints accessing network shares
// Focuses on creation of ransom notes and encrypted file extensions
let RansomExtensions = dynamic([".encrypted", ".locked", ".crypto", ".enc"]);
let RansomNoteNames = dynamic(["README", "DECRYPT", "RECOVER", "RESTORE", "HOW_TO", "RANSOM"]);
DeviceFileEvents
| where TimeGenerated > ago(24h)
| where FolderPath has_any ("\\", "smb", "nas", "share") or InitiatingProcessCommandLine has_any ("net use", "smb", "mount")
| extend FileName = tostring(split(FolderPath, "\\")[-1])
| extend FileExtension = strcat(".", tostring(split(FileName, ".")[-1]))
| where FileExtension in~ (RansomExtensions)
or FileName has_any (RansomNoteNames)
| summarize FileCount = count(),
FirstSeen = min(TimeGenerated),
LastSeen = max(TimeGenerated),
AffectedFiles = make_set(FolderPath, 50)
by DeviceName, InitiatingProcessAccountName, InitiatingProcessFileName, ActionType
| where FileCount > 10
| order by FileCount desc
Query 3: Analyze Synology Syslog for authentication anomalies and suspicious session activity
// Hunt for anomalous authentication events on Synology DSM via Syslog ingestion
// Look for brute force patterns, logins from unusual geolocations, or session spikes
Syslog
| where TimeGenerated > ago(72h)
| where Computer contains "synology" or HostName contains "synology" or Facility contains "synology"
| where SyslogMessage has_any ("login", "authentication", "session", "ssh", "logged in", "failed")
| extend ParsedMessage = tostring(SyslogMessage)
| extend IsFailed = ParsedMessage has_any ("failed", "invalid", "denied")
| extend IsSuccess = ParsedMessage has_any ("logged in", "success", "accepted")
| summarize
FailedAttempts = countif(IsFailed),
SuccessfulLogins = countif(IsSuccess),
TotalEvents = count()
by Computer, bin(TimeGenerated, 1h)
| where FailedAttempts > 20 or SuccessfulLogins > 50
| order by FailedAttempts desc
Velociraptor VQL Hunt
For organizations running Velociraptor with agents on endpoints that interact with Synology NAS devices, the following VQL artifact hunts for evidence of mass file encryption activity on network-mounted shares.
-- Hunt for ransom note files and encrypted file extensions on network shares
-- Deploy as a hunt across endpoints that access Synology NAS via mapped drives or UNC paths
LET ransom_extensions = ('.encrypted', '.locked', '.crypto', '.enc')
LET ransom_note_keywords = ('README', 'DECRYPT', 'RECOVER', 'RESTORE', 'HOW_TO', 'RANSOM')
-- First: Find ransom note files on all accessible drives
SELECT FullPath, Size, Mtime, Btime,
'RansomNote' AS IndicatorType
FROM glob(globs='**/*.txt', root='/')
WHERE FullPath =~ '(README|DECRYPT|RECOVER|RESTORE|HOW_TO|RANSOM)'
AND Mtime > now() - 86400 * 7
UNION ALL
-- Second: Find files with known ransomware extensions
SELECT FullPath, Size, Mtime, Btime,
'EncryptedFile' AS IndicatorType
FROM glob(globs='**/*.encrypted', root='/')
WHERE Mtime > now() - 86400 * 7
UNION ALL
-- Third: Check network connections to DSM ports for active sessions
SELECT Laddr.IP AS LocalIP, Laddr.Port AS LocalPort,
Raddr.IP AS RemoteIP, Raddr.Port AS RemotePort,
Status, Pid, Name AS ProcessName,
'DSM_Connection' AS IndicatorType
FROM netstat()
WHERE RemotePort IN (5000, 5001)
AND Status =~ 'ESTABLISHED'
Remediation and Hardening Script
The following Bash script is designed to be run on Synology DSM via SSH (if enabled) or adapted for execution through Task Scheduler in DSM Control Panel. It performs version verification, checks for exposed services, and applies hardening configurations.
#!/bin/bash
# Synology DSM Security Verification and Hardening Script
# Run via SSH or DSM Task Scheduler as root
# Purpose: Verify DSM version, check exposure, and apply baseline hardening
LOGFILE="/var/log/dsm_security_check_$(date +%Y%m%d_%H%M%S).log"
echo "==========================================" | tee -a "$LOGFILE"
echo "Synology DSM Security Verification Script" | tee -a "$LOGFILE"
echo "Date: $(date)" | tee -a "$LOGFILE"
echo "==========================================" | tee -a "$LOGFILE"
# --- Step 1: Check current DSM version ---
echo "" | tee -a "$LOGFILE"
echo "[STEP 1] Current DSM Version Information" | tee -a "$LOGFILE"
echo "------------------------------------------" | tee -a "$LOGFILE"
DSM_VERSION=$(cat /etc.defaults/VERSION 2>/dev/null || cat /etc/VERSION 2>/dev/null)
echo "$DSM_VERSION" | tee -a "$LOGFILE"
# Extract product version for comparison
PRODUCT_VERSION=$(echo "$DSM_VERSION" | grep productversion | cut -d'"' -f2)
BUILD_NUMBER=$(echo "$DSM_VERSION" | grep buildnumber | cut -d'"' -f2)
echo "Product Version: $PRODUCT_VERSION" | tee -a "$LOGFILE"
echo "Build Number: $BUILD_NUMBER" | tee -a "$LOGFILE"
echo "" | tee -a "$LOGFILE"
echo "ACTION REQUIRED: Verify this build includes the December 2024" | tee -a "$LOGFILE"
echo "security patch or later. Check Synology Security Advisory at:" | tee -a "$LOGFILE"
echo "https://www.synology.com/en-global/security/advisory" | tee -a "$LOGFILE"
# --- Step 2: Check if DSM is accessible from the internet ---
echo "" | tee -a "$LOGFILE"
echo "[STEP 2] Checking Network Exposure" | tee -a "$LOGFILE"
echo "------------------------------------------" | tee -a "$LOGFILE"
# Check listening ports
echo "Currently listening services:" | tee -a "$LOGFILE"
netstat -tlnp 2>/dev/null | grep -E ':(5000|5001|22|80|443|21|873|3306|6379|27017)' | tee -a "$LOGFILE"
echo "" | tee -a "$LOGFILE"
echo "WARNING: If ports 5000/5001 are accessible from the internet," | tee -a "$LOGFILE"
echo "your device is at HIGH RISK. Restrict access immediately." | tee -a "$LOGFILE"
# --- Step 3: Check for suspicious processes ---
echo "" | tee -a "$LOGFILE"
echo "[STEP 3] Checking for Suspicious Processes" | tee -a "$LOGFILE"
echo "------------------------------------------" | tee -a "$LOGFILE"
# Look for unexpected processes
echo "Processes running as root (review for anomalies):" | tee -a "$LOGFILE"
ps aux | grep -E '^root' | grep -vE '(syno|systemd|kthreadd|kworker|nginx|postgres|scsi)' | tee -a "$LOGFILE"
# Check for recently modified files in web directories
echo "" | tee -a "$LOGFILE"
echo "Recently modified files in web directories (last 7 days):" | tee -a "$LOGFILE"
find /volume1/web /var/services/web -type f -mtime -7 -ls 2>/dev/null | head -50 | tee -a "$LOGFILE"
# --- Step 4: Check user accounts ---
echo "" | tee -a "$LOGFILE"
echo "[STEP 4] Reviewing User Accounts" | tee -a "$LOGFILE"
echo "------------------------------------------" | tee -a "$LOGFILE"
echo "Active user accounts:" | tee -a "$LOGFILE"
cat /etc/passwd | grep -v nologin | grep -v false | tee -a "$LOGFILE"
echo "" | tee -a "$LOGFILE"
echo "WARNING: Review for unauthorized accounts, especially those with admin privileges." | tee -a "$LOGFILE"
# --- Step 5: Check for unauthorized SSH keys ---
echo "" | tee -a "$LOGFILE"
echo "[STEP 5] Checking SSH Authorized Keys" | tee -a "$LOGFILE"
echo "------------------------------------------" | tee -a "$LOGFILE"
for userdir in /volume1/homes/*/; do
if [ -f "${userdir}.ssh/authorized_keys" ]; then
echo "SSH keys found for: ${userdir}" | tee -a "$LOGFILE"
cat "${userdir}.ssh/authorized_keys" | tee -a "$LOGFILE"
echo "---" | tee -a "$LOGFILE"
fi
done
if [ -f /root/.ssh/authorized_keys ]; then
echo "SSH keys found for: root" | tee -a "$LOGFILE"
cat /root/.ssh/authorized_keys | tee -a "$LOGFILE"
fi
# --- Step 6: Check scheduled tasks for persistence ---
echo "" | tee -a "$LOGFILE"
echo "[STEP 6] Reviewing Scheduled Tasks" | tee -a "$LOGFILE"
echo "------------------------------------------" | tee -a "$LOGFILE"
echo "Cron entries:" | tee -a "$LOGFILE"
cat /etc/crontab 2>/dev/null | tee -a "$LOGFILE"
ls -la /etc/cron.d/ 2>/dev/null | tee -a "$LOGFILE"
echo "" | tee -a "$LOGFILE"
echo "DSM Task Scheduler tasks (check via Control Panel > Task Scheduler)" | tee -a "$LOGFILE"
# --- Step 7: Check firewall status ---
echo "" | tee -a "$LOGFILE"
echo "[STEP 7] Firewall Configuration" | tee -a "$LOGFILE"
echo "------------------------------------------" | tee -a "$LOGFILE"
echo "IPTables rules:" | tee -a "$LOGFILE"
iptables -L -n -v 2>/dev/null | head -40 | tee -a "$LOGFILE"
echo "" | tee -a "$LOGFILE"
echo "==========================================" | tee -a "$LOGFILE"
echo "SUMMARY AND REQUIRED ACTIONS" | tee -a "$LOGFILE"
echo "==========================================" | tee -a "$LOGFILE"
echo "1. UPDATE DSM to the latest version immediately via" | tee -a "$LOGFILE"
echo " Control Panel > Update & Restore > DSM Update" | tee -a "$LOGFILE"
echo "2. DISABLE internet exposure of DSM ports (5000/5001)" | tee -a "$LOGFILE"
echo " Use a firewall or VPN for remote access instead." | tee -a "$LOGFILE"
echo "3. ENABLE Auto Block: Control Panel > Security > Account" | tee -a "$LOGFILE"
echo "4. ENABLE 2FA for all admin accounts" | tee -a "$LOGFILE"
echo "5. DISABLE default 'admin' account if not already done" | tee -a "$LOGFILE"
echo "6. VERIFY backups are current and stored offline/immutable" | tee -a "$LOGFILE"
echo "7. REVIEW all user accounts and remove unauthorized access" | tee -a "$LOGFILE"
echo "8. CHECK Synology Security Advisories regularly:" | tee -a "$LOGFILE"
echo " https://www.synology.com/en-global/security/advisory" | tee -a "$LOGFILE"
echo "" | tee -a "$LOGFILE"
echo "Log saved to: $LOGFILE" | tee -a "$LOGFILE"
Remediation
Immediate Actions (Within 24 Hours)
-
Update DSM immediately. Navigate to Control Panel > Update & Restore > DSM Update and apply the latest available update. Ensure your DSM version includes the December 2024 security patch or later. Do not defer this — active exploitation is confirmed.
-
Remove internet exposure of DSM management interfaces. Ports 5000 (HTTP) and 5001 (HTTPS) should not be directly accessible from the internet. If remote management is required, use one of the following approaches:
- Synology's VPN Server package to establish a secure tunnel
- A site-to-site VPN or zero-trust network access (ZTNA) solution
- Firewall rules restricting management interface access to specific trusted IP ranges
-
Audit user accounts. Review all DSM user accounts for unauthorized additions. Disable or remove any accounts that cannot be attributed to legitimate administrators. Pay particular attention to accounts with administrative group membership.
-
Enable two-factor authentication (2FA). Enforce 2FA for all user accounts, especially those with administrative privileges. This is configured under Control Panel > User & Group > [User] > 2-Factor Authentication.
Short-Term Actions (Within 1 Week)
-
Enable Auto Block. Configure automatic IP blocking for repeated failed login attempts under Control Panel > Security > Account > Auto Block. Set a threshold of 5 failed attempts within 5 minutes with a block duration of at least 24 hours.
-
Disable the default admin account. If you have not already done so, create a uniquely named administrative account and disable the default "admin" account. This eliminates the most commonly targeted username in brute-force attacks.
-
Verify backup integrity. Confirm that your backup strategy is functioning and that backups are stored in a location that is not writable from the NAS itself. Follow the 3-2-1 rule: three copies of data, on two different media types, with one copy stored offsite or offline. Consider immutable backup solutions that prevent modification or deletion within a defined retention window.
-
Review installed packages. Audit all installed DSM packages and remove any that are not actively required. Each installed package increases the attack surface.
Ongoing Actions
-
Enable automatic DSM updates. Configure automatic installation of security updates under Control Panel > Update & Restore > Update Settings. Select "Install important updates automatically" at minimum.
-
Subscribe to Synology security advisories. Monitor the official Synology Security Advisory page at https://www.synology.com/en-global/security/advisory and subscribe to their security notification mailing list.
-
Integrate Synology Syslog with your SIEM. Forward DSM system logs to your centralized logging platform (Microsoft Sentinel, Splunk, Elastic, etc.) via Syslog. This enables the detection queries provided above and ensures that authentication events, configuration changes, and system anomalies are captured in your monitoring pipeline.
-
Conduct a vulnerability scan. Include all Synology NAS devices in your regular vulnerability management scanning scope. Ensure that your scanner is configured to authenticate to DSM and enumerate installed package versions and firmware build numbers.
Vendor Resources
- Synology Security Advisories: https://www.synology.com/en-global/security/advisory
- Synology DSM Update Portal: Access via DSM Control Panel or https://www.synology.com/en-global/support/download
- Synology Account Security Best Practices: Refer to Synology's official documentation on securing your NAS
Key Takeaways
This campaign is a textbook example of why patch management cannot stop at traditional endpoints. NAS devices store some of the most valuable data in an organization — yet they frequently operate without EDR, without centralized logging, and without the patch discipline applied to servers and workstations. The window between patch availability and active exploitation continues to shrink, and in this case, threat actors are deliberately targeting devices that are months behind on a known security update.
If you are a SOC analyst, add the detection queries above to your hunting rotation. If you are a CISO or IT manager, inventory every Synology device in your environment today — including the ones in branch offices and home labs that nobody remembers deploying — and verify their firmware status. If you are an IR responder, familiarize yourself with the DSM file system layout and logging artifacts now, because the next call you get may involve an encrypted NAS with no offline backup.
Related Resources
Security Arsenal Incident Response Services AlertMonitor Platform Book a SOC Assessment incident-response Intel Hub
Is your security operations ready?
Get a free SOC assessment or see how AlertMonitor cuts through alert noise with automated triage.