Snapshots for ransomware resilience – Ubiquiti NAS research report

1. Executive summary

The Ubiquiti UNAS is an inexpensive, entry-level NAS that offers snapshot capabilities that provide protection against a cyber attacker, and solves the major problem where an attacker can delete backups on a network share.

In July 2026, we conducted an extensive series of experimental tests to assess the capabilities of the Ubiquiti NAS, which is a relatively new offering to the market attracting discussions in online forums.

Through careful experimentation, we assessed the cyber-resilience capabilities of the device at 5.5/10, with the following important observations:

Important notes:

1. We assessed the NAS from a cyber-resilience viewpoint for storing backups with snapshots, not general performance or general cyber-security.
2. Our conclusions are subject to security assumptions that hold true in general attack scenarios – see section 2.3.
3. We tested the entry-level UNAS 2 model, but the UNAS 4 and UNAS Pro models run the same core operating system (UniFi OS) so we would expect similar results.
4. We tested this NAS independently from any backup software.

2. Scoring, pros and cons, security model

2.1 Scorecard

We scored the NAS based on 10 different criteria:

• 1 criterion for usability
• 8 criteria for security – which help us assess the level of cyber-security provided based on the “promises” provided
• 1 overall criterion to evaluate how “bulletproof” the NAS is against the targeted level of security – in other words, “are the promises strong enough to be guarantees”?

Score: 5.5 / 10 (5 Yes, 4 No, 1 Partial). Criterion #10 is scored Partial (½): the UNAS delivers ML1-level ransomware resilience under normal conditions but is not “bulletproof” against a deliberate, patient attacker (see section 4).

2.2 Pros and Cons

Pros:

• Provides ASD Essential Eight compliance to Maturity Level 1 (“Unprivileged user accounts are prevented from modifying and deleting backups.”).

Cons:

• Does not provide ASD Essential Eight compliance to Maturity Level 2 (fails “Privileged user accounts (excluding backup administrator accounts) are prevented from modifying and deleting backups.”).

2.3 Security and attack model

In any analysis, it’s necessary to understand the security model we used and any assumptions made.

What we consider:

• The network’s authentication system (Active Directory, Entra, etc) is compromised and the attacker has administrator level access
• The attacker has access to the machines that are being backed up – like a file server – so any IP based firewall restrictions the NAS may have are rendered ineffective

What we assume:

• The administrator credentials for the NAS are stored securely and kept confidential. (e.g. not stored in the browser of a compromised machine.)
• The NAS itself is not exploited at an operating system or kernel level – regular firmware upgrades are a good mitigation against this.
• The attacker does not have ssh access into the NAS.
• The NAS does not suffer from physical destruction, hardware failure, theft, etc.

3. Testing methodology

All tests were run with the test tool (nas_snaptest.py) executing on the Windows client, against the mapped SMB share, using the share-only account. The tool never logs into the NAS. Snapshots are taken, and pool/drive space is read, from the NAS admin interface at the checkpoints where the tool pauses. This separation is deliberate: the modelled “attacker” holds the backup share’s credentials and nothing else.

The full step-by-step procedure for every test — all eight test groups, with the complete screenshot evidence needed to reproduce the results — is documented separately in Ubiquiti UNAS — Experimental testing methodology. The scorecard and section 4 reference those test groups by number.

4. Overall assessment — ransomware resilience

4.1 Assessment against ASD Essential 8 Maturity Levels

Note: we are referring to only the “Regular backups” strategy of the ASD E8 in this discussion.

Based on the features provided by the Ubiquiti NAS, we believe the core use-case is for users to attempt to achieve Maturity Level 1 (ML1) compliance of the ASD Essential 8, but not Maturity Level 2 (ML2).

Maturity Level One – satisfied with careful access controls

“Unprivileged user accounts are prevented from modifying and deleting backups.”

Maturity Level Two – cannot be satisfied

“Privileged user accounts (excluding backup administrator accounts) are prevented from modifying and deleting backups.”

Under regular usage scenarios, we are satisfied that the UNAS meets those criteria when configured properly.

4.2 Resilience under attack and ransomware scenarios

Our bigger question is, does the UNAS as a whole give an administrator dependable assurance of cyber-resilience at the level the device is capable of — here ASD Essential Eight Maturity Level One (ML1) for backups — under a ransomware scenario, and without ongoing manual oversight?

In short: is it “bulletproof” in what it tries to do?

The scenario in mind is a small organisation that deploys the UNAS as its backup target, configures it once, and relies on it so that if ransomware compromises a workstation and reaches the mapped backup share, clean data can still be recovered. The assurance sought is ASD E8 ML1 “Regular backups.”

4.2.1 What works – and why we gave it a half point

Consider the ordinary ransomware case: the client is compromised and the mapped backup set is encrypted or overwritten in place.

The UNAS successfully protects the recovery point. An attack on the network share is unsuccessful: the attacker cannot see, enumerate, reach, or delete the snapshots (Test group 2); cannot delete them through flooding the disk (Test group 7); and a full recovery can be achieved from the most recent snapshot. This satisfies the specific E8 ML1 control that unprivileged accounts are prevented from modifying and deleting backups, and for the common attack it delivers the resilience the user is seeking.

4.2.2 Where it breaks, and why we deducted a half point

Consider a scenario:

• Total storage of the NAS: 8 TB
• Drive quota for the backup share: 2 TB
• Current contents on the backup share: 1 TB
• Total NAS space consumption: 2.5 TB (comprising 1 TB current data, 1.5 TB past snapshots)
• Snapshots are taken on a daily basis

A sophisticated and patient attacker could theoretically set up a “fill and churn” attack – say add 800 GB of data to the backup share on Day 1, then each day after, change that data “in place”.

Even if the backup didn’t change at all, each successive snapshot would therefore take an extra 800 GB of space. We begin with 5.5 TB free on the NAS, and after 7 days, the NAS is completely full. At some point during this attack, snapshots would start failing, and when combined with the “silent failure” problem (see section 4.3) all this may well go undetected.

All the attacker would need to do then is wait some period of time, before deleting the backups and installing ransomware. Then in this case, the last snapshot would be from weeks ago – forcing the victim to decide whether to pay a ransom or recover from an out-of-date backup.

This attack is considerably harder to carry out than a quick, opportunistic one. But what caused us to deduct the half point is that the attack exists, and we have real concerns that it would go undetected because of the unpredictable and silent snapshot failures that we encountered (section 4.3). We also cannot expect an administrator to log into the admin console each day – so the administrator would be unaware that the recovery points stopped being created.

4.3 Other problems encountered

While testing the NAS, we encountered a few anomalies worth noting:

1. Email notification could not be configured to work (Test 8.1). So an operator relying on being alerted may simply not learn that recovery points have stopped being created.
2. Snapshot-creation failures were sometimes silent (Test group 7 and Test group 8) — no event-log entry at all
3. Snapshot failures were inconsistent – at times, a snapshot failed with still ~800 GB free on the NAS. At other times, snapshots would be successful with under 1 GB free.

4.4 How to get the best out of the Ubiquiti NAS

Given its pros and cons, strengths and weaknesses – how would we get the most out of the Ubiquiti NAS as a resilient storage medium for backups?

We’ll look at this from a few angles.

4.4.1 Security configuration on the UNAS

1. Set up strong passwords for the UNAS administrator account, and do not reuse that password elsewhere. Never store the password in a browser, and always log out of the browser when performing administration (or use a private browsing session).
2. Set up separate credentials for the network shares, and never share them elsewhere.
3. Input those credentials only in the backup software, and avoid mapping a network share explicitly from Windows Explorer or the command line.

4.4.2 Storage configuration on the UNAS

Many people may ask, could the overall resilience to cyber attacks be improved if the UNAS were configured carefully?

We considered the variables here:

• Maximum number of snapshots – before the oldest unlocked snapshot gets auto-deleted
• Maximum disk quota for the share
• Total disk space of the NAS

And the overall constraint is – no one has an unlimited budget, and if the cost of the NAS escalates (like installing 30 TB hard drives) then other backup storage media become more appealing.

As systems administrators, our initial instinct would be to set the maximum number of snapshots to something high – 180, and to set a disk quota to 1.5 times the size of the source disks, and we would aim to have a total disk space available of 2.5 times the disk quota. These are the figures we’ve settled upon after 20 years in the game of backing up servers and workstations.

Let’s look at the effect of varying any parameter:

1. Increasing the maximum number of snapshots would increase the number of historical restore points, but if old snapshots aren’t deleted quickly enough, the entire NAS would fill up, causing both backups and snapshots to fail.
2. Decreasing the maximum number of snapshots would mean it’s less likely the NAS would completely fill up, but the shorter history makes an attack more likely to succeed.
3. Increasing the disk quota would enable the attacker to flood more data per day, causing snapshots to fail sooner.
4. Decreasing the disk quota would limit the attacker’s ability to flood the NAS, but could interfere with the backup operation and decrease the backup retention capabilities of the backup software.
5. Increasing the total disk space would add headroom, delaying when an attacker could successfully complete an exploit, but cost substantially more in disk storage costs.

There’s no clear “do this” path to follow, because each action has side effects.

Because of these side effects, we recommend sticking to the default guidance on parameters and instead looking to the backup software for monitoring and mitigations.

4.4.3 Monitoring from the backup software

The shortcomings of the UNAS could be overcome with good monitoring from the backup software. Products like BackupAssist provide a range of active and passive mitigations – from CryptoSafeGuard monitoring activity on both the backup target and source folders, to daily backup reports that show the amount of free space on the backup share.

In the flood attack described above:

• The UNAS would likely never report the problem
• BackupAssist would issue a warning when the backup target hit 90% usage – delivered by email and central managed backup console

4.5 To MFA or not MFA?

One thing we noticed when using the Ubiquiti NAS is the absence of MFA. We configured the NAS in “isolated” mode to start with – meaning that we did not connect the device to a UniFi account or attempt to set it up via the phone app. Consequently, the NAS is protected by a single password for the web admin console, and when we set up SSH, we set a different password for root access via SSH. MFA was not available on either mode of access.

The user manuals for the UNAS state that MFA is available on UniFi accounts – but that would require connecting the NAS to Ubiquiti’s central management and authentication services.

In our view, it would have been ideal to allow MFA on the web management console even in isolated mode. However, it is not a “show stopper” for us – because we chose to run the NAS in isolated mode, meaning it is not connected to the Internet and we secure access to the LAN via other means like a VPN.

So in summary, an administrator would have to choose between:

• Be completely isolated, but not have MFA (and implement other security controls in its place)
• Be integrated into UniFi and have MFA, but be reliant on Ubiquiti.

4.6 Summary of key limitations

As a final recap of the limitations we encountered:

1. The UNAS does not protect the backups from a malicious administrator.
2. Nor is it “bulletproof” (i.e. completely secure) against a deliberate, patient attacker: a multi-day flood or churn campaign can stop new recovery points from being created, or cause existing ones to be deleted, forcing recovery from older data.
3. MFA is not available if you choose to run the NAS in isolated mode.
4. We encountered some apparent bugs:
   1. Unable to set up email notifications, and no log messages
   2. Silent failures when creating a snapshot failed
   3. Unknown causes of snapshot failure: sometimes, snapshots could be created right up to the NAS filling up completely; other times the snapshot would fail even when there was about 11% free space, and no error logs appeared
5. So while the UNAS delivers ASD Essential Eight Maturity Level One resilience for the ordinary ransomware case, it falls short of the guarantees of immutable cloud storage. Overall score: 5.5 / 10.

Appendix — findings summary

• Credential separation is easy. The SMB File Services credential is a distinct secret from the UniFi admin login; the share session has no route to snapshot controls.
• A compromised network share does not affect its snapshots. A share-only attacker destroyed the live backup set, could not see/enumerate/delete snapshots, and a byte-clean restore was verified.
• Snapshots are invisible to SMB clients. From within a share, there is no “Previous Versions” visible.
• Restore model is not ideal but still works. A destructive rollback is offered to restore to an earlier snapshot; alternatively a per-file Download (non-destructive) is offered for small selective pulls. There is no way to mount a snapshot as a share for recovery (criterion #6: FAIL).
• Snapshot lock is available but rudimentary. Snapshot locking is a manual process, reversible with one click, has no expiry, and cannot be scheduled. Protects against automatic deletion when the maximum number of snapshots is hit (PASS for #7) but not against a deliberate administrator (FAIL for #4), and provides no fixed immutability window (FAIL for #5, FAIL for #8).
• Snapshot space usage is outside the drive’s quota. The snapshots of a drive do not count against the drive’s space usage. For example, if a drive has a 1 TB quota, 600 GB of live data, and 500 GB of past snapshots, there will still be 400 GB free on the drive. This is because the 500 GB of past snapshots live on the same storage pool (thus occupying space on the NAS) but are not counted towards the 1 TB quota.
• Automatic deletion respects locks. When the snapshot limit is reached, the NAS deletes the oldest snapshot first, but only ever an unlocked one. Locked snapshots are never deleted automatically — the NAS will hold more than its configured limit rather than touch a locked snapshot. It flags this clearly in the interface.
• Snapshots can be scheduled, with options from hourly to monthly.
• Snapshots do slow down the NAS slightly but would not be noticeable via gigabit ethernet. Fresh writes are unaffected by snapshots; overwrite/churn throughput settles at ~155 MiB/s with deep history and does not degrade as snapshot count grows (two 12-round sweeps, flat and within ~1 MiB/s at depth ≥5). Early-round variability was traced to the NAS’s own background I/O (an iostat-captured ~32 GiB read burst), not to snapshots. Measured internally; over-SMB throughput confirmed at ~117 MB/s sustained during the #9 flood, consistent with gigabit ethernet being the network-side limit.
• After a flood attack, snapshots survive under all conditions. Both cross-drive flooding and same-share churn flooding were driven to absolute pool full in separate tests. In both cases the NAS refused further writes rather than deleting snapshots — neither the unlocked nor the locked tracer was deleted. Snapshot integrity verified by SHA1 hash comparison across three distinct point-in-time versions of the same file. The safe failure mode holds regardless of the source of pool pressure.
• Overall ransomware resilience (#10): Partial (½). The UNAS delivers ASD E8 ML1 resilience for the ordinary ransomware case — a share-only attacker cannot reach the snapshots, delete them, or cause them to be deleted through space pressure, and a byte-clean restore is available. But a determined, patient attacker can flood the pool or exploit oldest-unlocked count-based deletion to stop new recovery points from being created or delete existing ones, forcing a restore from older data, without ever breaching the modify/delete control. Mitigations (enforcing a usage quota, backup-only use, monitoring, manual locking of verified snapshots) reduce but do not eliminate the risk. See section 4.