Online RAID Capacity Upgrade

https://www.youtube.com/embed/V6VFGkeFN8I?enablejsapi=1&origin=https%3A%2F%2Fwww.qnap.com

A New Challenge for Modern Businesses

For modern businesses, one of the greatest challenges is to select and set up a reliable network-attached storage server to secure and share important data to increase work efficiency. Meanwhile, the necessity to reduce the risk of data loss by backing up data increases the demand for higher capacity storage. With the increasing storage capacity of hard drives, QNAP provides a solution to hot swap lower capacity drives with larger capacity drives so that your QNAP Turbo NAS can grow with your business.

The QNAP Turbo NAS series provides a high-performance and low-TCO (total cost of ownership) solution for modern businesses. In addition to best-in-class hardware specifications and easy-to-use applications, the QNAP Turbo NAS series also offers innovative features such as Online RAID Capacity Upgrade (for example, replace three 500GB hard drives with three 1TB hard drives) and Online RAID Level Migration (for example, RAID level migration from RAID 1 to RAID 5). These advanced features used to be exclusive to corporations with large budgets, but QNAP implements an intuitive way to allow more businesses to enjoy these powerful technologies.

The scenario below demonstrates how users can benefit from using Online RAID Capacity Upgrade.

Use Case

  • Jeffrey bought three 500GB drives for the initial setup of a TVS-882 and used a RAID 5 configuration for these drives.
  • Six months later, the storage needs of his department sharply increased and the current storage capacity of his TVS-882 was no longer enough. At the same time, the price of 1TB hard drives had significantly dropped. Thus, Jeffery decided to buy three 1TB hard drives.
  • Jeffery now wants to upgrade the capacity of his TVS-882 NAS.

Operation procedure

Log in to QTS with an administrator account. Go to  “Storage & Snapshots” > “Storage/Snapshots”. Select the storage pool that will be expanded, then click “Manage“. The “Storage Pool Management” window will appear, select the RAID group that will be expanded and click “Replace Disks One by One” in the “Manage” menu.

Highlight the first disk to be replaced, and click “Change“.

Tips: After you replace hard drives, the description field will show the message “You can replace this drive”. You can now replace the hard drive to a larger one or skip this step if the hard drives have already been replaced.
Caution: When the hard drive synchronization is in process, DO NOT turn off the NAS or swap hard drives.

When the description field displays “Please remove this drive”, remove the hard drive from the NAS. Wait for the NAS to beep twice.

When the description field displays “Please insert the new drive”, insert the new drive to the same drive slot.

After inserting the hard drive, wait for the NAS to beep. The system will start rebuilding.

When the RAID is finished rebuilding, repeat the steps above to replace the other hard drives one by one.

After swapping out hard drives and the rebuilding completes, click “Expand Capacity” to expand the RAID.

Click “OK” to continue.

The NAS will beep and start expanding the capacity.

Depending on the drive sizes, the process may take anywhere from a few hours to tens of hours to complete. Please wait patiently for the process to finish. DO NOT turn off the NAS.

After RAID expansion is finished, the new capacity will be shown and the RAID group status will be “Ready”. The process is now complete and the new storage space is available for use.

Tips: To expand the capacity of closed NAS models (those without accessible drive bays) you need to shut down the NAS, unplug its cables, lay the NAS on a flat surface, open its cover, and then replace the hard drives within. Then replace the cover, plug in the cables, turn on the NAS, and then follow the instruction on the screen.

Source :
https://www.qnap.com/en/how-to/tutorial/article/online-raid-capacity-upgrade

Manually Install QRescue to recover Qlocker-encrypted files on QNAP NAS

Overview:

QRescue is the data recovery tool for Qlocker-encrypted 7z files. It contains:

  • PhotoRec (Open Source Project / GNU General Public License / Project Link):
    File recovery software designed to recover lost files from hard disks and CD-ROMs, and lost pictures (thus the Photo Recovery name) from storage medium.
  • QRescue (Powered by QNAP):
    The script to recover file structures from the encrypted 7z files and PhotoRec files.

Requirements:

  • Download the QRescue app from this link.
    https://download.qnap.com/QPKG/QRescue.zip
  • Prepare an external hard disk drive with a capacity larger than the total used storage space on your NAS.
    • Note: It’s advised to prepare an external HDD with 1.5 to 2x free space than the total used storage space on your NAS. Additional space might be required during the recovery process. If the available space is less than the suggested value, error and other issues may occur.

Demo Video:

Steps: 

Part 1. Configure external HDD with the name “rescue” and create folders with the name “recup1” for recovery.

QRescue will process the recovery process to external drive first, and we need to do some configuration for this recovery process and create the specific destination and folder name.

  1. You need to prepare an external HDD that its usable capacity is larger than the total used storage size of your NAS. This is because you will recover the files to the external device first. Please check your used volume size first by clicking More > About on the QTS desktop.
  2. Insert the external drive to your NAS. Please go to Storage Manager > External Device > Select your external device > Click “Actions” > Click “Format” to format the external drive.
  3. The File System must be “EXT4”, and the Label name must be key in “rescue”. If these configuration is ready, please click “Format

    Notice:
    The QRescue app will use “rescue” as the external drive name. If you use other names, the recovery process might fail.
  4. (Optional) If you disable the admin account or you don’t use admin to login QTS, you might not see the external drive on the File Station. Please go to Control Panel > Privilege > Shared Folder > Edit Shared Folder Permission to enable or change read / write permission for “rescue” folder and to match the account that you log in the NAS.
    • Sample:
      Grant other administrator group account (Example: “_qnap_support” is the administrator group account for read/write permission to external hard drive naming “rescue”).


       
  5. Using File Station to check the volume for the correct external device name.
  6. Create the new folder and name as “recup1” (format: recup+{number}). If you have more than one storage volume, you need to add more folders for recovery.



    Notice:
    The QRescue app will use “recup+{number}” as the folder name. If you use other names, the recovery process might fail.Part 2. Download and Manually Install the QRescue AppThis QRescue app is a special build. Therefore, you need to manually install this app from the QTS App Center.
  7. Please go to this link to download the QRescue app.
    https://download.qnap.com/QPKG/QRescue.zip
  8. Please go to App Center > Click Install Manually > Click Browse to find the QRescue app location on your computer.
  9. After selecting the app location, you can click Install. Wait until the installation completes and open the QRescue app on QTS desktop or side-bar.
  10. When you open the QRescue app, you will see the web console. It can help to run PhotoRec and QRescue to recover your files.Part 3. Run PhotoRecRunning PhotoRec can help you to recover the lost files from hard disks to the external drive. Now you will recover the NAS files to the “recup1” (example: recup+{disk_number}) folder on the external drive.
  11. Type this command and press Enter on your keyboard. You will start to run PhotoRec.
    Command:
    photorec
  12. Use Up/Down arrows to choose the hard drive. And you can start to select the NAS disk for running recovery by PhotoRec.
    • Sample:
      • /dev/mapper/cachedev1 as 1st data volume
      • /dev/mapper/cachedev2 as 2nd data volume
      • /dev/mapper/cachedev20 as 20th data volume
    • Note:
      You can check the number of data volumes in Storage & Snapshots > Storage/Snapshots
  13. Select the “ext4” partition and press “Enter
  14. Select the file system as [ ext2/ext3 ] and click “Enter” key.
  15. Select the space as [ Whole ] and click the “Enter” key.
  16. Now we need to select the external device’s folder as the recovery destination. 
    • Source Destination: /share/external/DEV3301_01/qpkg/QRescue   [QRescue qpkg]
    • Recovery Destination: /share/rescue/recup1 [External Device]
    • Click “..” to go back to the upper level folder
       
      • Sample destination: External disk on QRescue app
      • Sample: External Device (name: rescue) > Destination Folder (name: recup1)
  17. Please click “C” on the keyboard when the destination is “/share/rescue/recup1”.
  18. Start to run the recovery process by PhotoRec. Now you can see the estimated time to completion.
  19. When you finish the PhotoRec, you can press enter when you select  [Quit] or type in “ctrl-c” to exit.
    Part 4. Run QRescueRun QRescue can help you to recover the files retrieved by PhotoRec. Now you will recover the files from the “recup+{number}” folder to the “restore+{number}” folder which auto creates on your external drive.
  20. Type this command and click Enter on your keyboard. You will start to run QRescue.
    Command:
    qrescue.sh
  21. (Optional) If you have two or more data volumes on your NAS, the screen will let you select which data volume you will start the process. Please type the number and press “enter”. If you only have one data volume, you might not see this step.

  22. (Optional) Now you can see the progress for which files were completed in the recovery process.
  23. When all of the QRescue process is completed, the screen will show the result summary and the process for sending the system log.
  24. QRescue app also will send the event log to QuLog Center / System Log and notify you on finishing the whole recovery process. If you have opened the QNAP support ticket, don’t forget to make the feedback for your case. QNAP support team will help you to double check. Thank you very much.

Part 5. Move the recovery data to your NAS.

You can move the recovery data to your NAS by File Station


Source :
https://www.qnap.com/en/how-to/tutorial/article/manually-install-qrescue-to-recover-qlocker-encrypted-files-on-qnap-nas

How to set up myQNAPcloud to remotely access a QNAP NAS

Requirements

Register your NAS with myQNAPcloud

  1. Log in to your QNAP NAS.
  2. Open myQNAPcloud.
  3. Click Get Started.

    The Welcome to myQNAPcloud! window appears.
  4. Follow the steps to register your NAS. Click Next to move to the next step.
    1. Enter your QNAP ID and Password.
    2. Enter a Device name for your NAS.
      Note: This name is used to identify your NAS on myQNAPcloud and must be unique across all users.
    3. Choose what NAS services will be enabled and the Access Control setting.

      Your device is registered on myQNAPcloud.

      A summary page displays all the registration details and services guidelines of your NAS.

Remotely access your QNAP NAS with myQNAPcloud

  1. Go to https://www.myqnapcloud.com/.
  2. Sign in using your QNAP Account.
    Note: If you are already signed in you are automatically redirected to My Devices .
  3. Go to My Devices.
    The devices registered to your QNAP Account are displayed.
  4. Click the ”  ” button next to the device to display the device IP and SmartURL.
  5. Click SmartURL.

    A login page for your NAS appears.

Source :
https://www.qnap.com/en/how-to/tutorial/article/how-to-set-up-myqnapcloud-to-remotely-access-a-qnap-nas

How to back up your Mac to QNAP NAS using Time Machine

Requirements:

  • QNAP NAS with QTS 4.3.0 (or later).

There are two ways to back up your Mac to a QNAP NAS: using QTS or HBS 3.

QTS: Go to “Perform Time Machine Backup to your QNAP NAS”.
HBS 3: Go to “Back up Mac with the shared Time Machine account in HBS 3”

  • Perform Time Machine Backup to your QNAP NAS
    • (Optional) Create a designated Time Machine backup user and shared folder
    • Configure Time Machine to use QNAP NAS for backups
  • Back up Mac with the shared Time Machine account in HBS 3
    • Set up shared Time Machine account
    • Configure Time Machine to use QNAP NAS for backups

Perform Time Machine Backup to your QNAP NAS

  • (Optional) Create a designated Time Machine backup user and shared folder
    1. Create a Time Machine backup user.
      Tip: A dedicated Time Machine user account can be created to provide additional security and the ability to set storage quotas for each Mac.
      • Open Control Panel.
      • Go to Privilege > Users.
      • Click Create.
      • Select Create a User.
      • Click Create.
    2. Create a Time Machine backup shared folder.
      • Open Control Panel.
      • Go to Privilege > Shared Folders.
      • Click Create.
      • Select Shared Folder.
      • Enter a Folder Name.
      • Click Next.
      • Give the Time Machine backup user RW access privileges.
      • Click Next.
      • Check Set this folder as the Time Machine backup folder (macOS).
      • Click Finish.
    3. Configure QTS to use SMB 3
      1. Open Control Panel.
      2. Go to Network & File Services > Win/Mac/NFS > Microsoft Networking.
      3. Click Advanced Options.
      4. Under Highest SMB version select SMB 3.
      5. Click Apply.
  • Configure Time Machine to use QNAP NAS for backups
    1. Connect the NAS to your Mac
      • Open Finder on your Mac.
      • Open the Go menu.
      • Click Connect to Server.
      • Enter smb://<NAS name.local or IP address>.
      • Enter the username and password of the backup user account.

        Note:
        If your NAS is a member of a domain then you should log in using the domain name and user account. For example, if your NAS is named qnapnas and you want to connect using local NAS user account nasuser1, then your username is qnapnas\nasuser1.
      • This can be your NAS account or the dedicated Time Machine user account.
      • Select the NAS shared backup folder.
    2. Open Time Machine.
    3. Click Select Backup Disk.
    4. Select the NAS shared backup folder.
    5. Click Use Disk.
    6. Enter the username and password of the backup user account.
      Tip: This can be your NAS account or a dedicated Time Machine user account.
    7. Click Connect.
      Result: You can now use Time Machine to back up this Mac to your NAS.

Back up Mac with a shared Time Machine account in HBS 3

  • Set up the shared Time Machine account
    1. Open HBS 3.
    2. Go to Services > Time Machine.
    3. Check Use shared Time Machine account.
    4. Enter a password for the Time Machine account.
    5. (Optional) Set a storage quota.
    6. Select Maximum
    7. Enter the total capacity in GB.
      Important: If the backup data size is greater than the quota, the Time Machine backup will fail.
    8. Click Apply.
  • Configure Time Machine to use QNAP NAS for backups
    1. Connect the NAS to your Mac
      • Open Finder on your Mac.
      • Open the Go menu.
      • Click Connect to Server.
      • Enter smb://<NAS name.local or IP address>/TMBackup.
      • Enter the username TimeMachine and the password you created earlier.
    2. Open Time Machine.
    3. Click Select Backup Disk.
    4. Select the NAS shared folder TMBackup.
    5. Click Use Disk.
    6. Enter the username TimeMachine and the password you created earlier.

      Note:
      If your NAS is a member of a domain then you should log in using the domain name and user account. For example, if your NAS is named qnapnas and you want to connect using local NAS user account nasuser1, then your username is qnapnas\nasuser1.
    7. Click Connect.
      Result: You can now use Time Machine to back up this Mac to your NAS.

      Tip: Backups can be located under the shared folder TMbackup.

Source :
https://www.qnap.com/en/how-to/tutorial/article/how-to-back-up-your-mac-to-qnap-nas-using-time-machine

Moving the Mission Forward: Mandiant Joins Google Cloud

Google’s acquisition of Mandiant is now complete, marking a great moment for our team and for the security community we serve.

As part of Google Cloud, Mandiant now has a far greater capability to close the security gap created by a growing number of adversaries. In my 29 years on the front lines of securing networks, I have seen criminals, nation states, and plain bad actors bring harm to good people. By combining our expertise and intelligence with the scale and resources of Google Cloud, we can make a far greater difference in preventing and countering cyber attacks, while pinpointing new ways to hold adversaries accountable.  

When I founded Mandiant Corporation in 2004, we set out to change how businesses protected themselves from cyber threats. We felt the technologies people depended on to defend ultimately failed to innovate at the pace of the attackers. In order to deliver cyber defenses as dynamic as the threats, we believed you had to have your finger on the pulse of adversaries around the world. To address this need, we set out to respond to as many cyber security breaches as possible. We wanted to learn first-hand how adversaries were circumventing common safeguards with new and novel attacks; monitor the development and deployment of attacker tools, their infrastructure, and their underground economies; and study the attacker’s targeting trends.

Armed with this knowledge and experience, we felt we were best positioned to close the gap between the offense and the defense in the security arms race.  

As we investigated thousands of security incidents over the years, we honed the deep expertise required to find the proverbial needle in the haystack: the trace evidence that something unlawful, unauthorized, or simply unacceptable had occurred. We believed this skill was the foundation to automating security operations through software, so that organizations and governments around the world could easily implement effective security capabilities. 

By joining forces with Google Cloud, we can accelerate this vision. I am very excited that Mandiant and Google Cloud can now work together to leverage our frontline intelligence and security expertise to address a common goal: to relentlessly protect organizations against cyber attacks and provide solutions that allow defenders to operate with confidence in their cyber security posture. More specifically, we can leverage our intelligence differentiator to automate security operations and validate security effectiveness.

Mandiant Remains Relentless

While we are now part of Google Cloud, Mandiant is not going away—in fact, it’s getting stronger. We will maintain our focus on knowing the most about threat actors and extend our reputation for delivering world-class threat intelligence, consulting services, and security solutions. 

Automating Security Operations

Today’s announcement should be welcome news to organizations facing cyber security challenges that have accelerated in frequency, severity, and diversity. I have always believed that organizations can remain resilient in the fight against cyber threats if they have the right combination of expertise, intelligence, and adaptive technology. 

This is why I am a proponent of Google Cloud’s shared fate model. By taking an active stake in the security posture of customers, we can help organizations find and validate potential security issues before they become an incident. Google Cloud and Mandiant have the knowledge and skills to provide an incredibly efficient and effective security operations platform. We are building a “security brain” that scales our team to address the expertise shortage.

Validating Security Effectiveness

Google Cloud’s reach, resources, and focus will accelerate another Mandiant imperative: validating security effectiveness. Organizations today lack the tools needed to validate the effectiveness of security, quantify risk, and exhibit operational competency. Mandiant is working to provide visibility and evidence on the status of how effective security controls are against adversary threats. With this data, organizations have a clear line of sight into optimizing their individual environment against relevant threats.

Advancing Our Mission

Google Cloud has made security the cornerstone of its commitment to users around the world, and the Mandiant acquisition underscores that focus.

We are thrilled to continue moving our mission forward alongside the Google Cloud team. Together, I believe Mandiant and Google Cloud will help reinvent how organizations protect, detect, and respond to threats. This will benefit not only a growing base of customers and partners, but the security community at large.

You can learn more about this milestone moment and the exciting opportunities ahead in this blog post by Google Cloud CEO Thomas Kurian, “Google + Mandiant: Transforming Security Operations and Incident Response.”

Source :
https://www.mandiant.com/resources/blog/mandiant-joins-google-cloud

KB5004442—Manage changes for Windows DCOM Server Security Feature Bypass (CVE-2021-26414)

Summary

The Distributed Component Object Model (DCOM) Remote Protocol is a protocol for exposing application objects using remote procedure calls (RPCs). DCOM is used for communication between the software components of networked devices.  

Hardening changes in DCOM were required for CVE-2021-26414. Therefore, we recommended that you verify if client or server applications in your environment that use DCOM or RPC work as expected with the hardening changes enabled.

To address the vulnerability described in CVE-2021-26414, you must install updates released September 14, 2021 or later and enable the registry key described below in your environment. We recommended that you complete testing in your environment and enable these hardening changes as soon as possible. If you find issues during testing, you must contact the vendor for the affected client or server software for an update or workaround before early 2022.

Note We recommend that you update your devices to the latest security update available to take advantage of the advanced protections from the latest security threats.

Timeline

Update releaseBehavior change
June 8, 2021Hardening changes disabled by default but with the ability to enable them using a registry key.
June 14, 2022Hardening changes enabled by default but with the ability to disable them using a registry key.
March 14, 2023Hardening changes enabled by default with no ability to disable them. By this point, you must resolve any compatibility issues with the hardening changes and applications in your environment.

Registry setting to enable or disable the hardening changes

During the timeline phases in which you can enable or disable the hardening changes for CVE-2021-26414, you can use the following registry key:

  • Path : HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Ole\AppCompat
  • Value Name: “RequireIntegrityActivationAuthenticationLevel”
  • Type: dword
  • Value Data: default = 0x00000000 means disabled. 0x00000001 means enabled. If this value is not defined, it will default to enabled.

Note You must enter Value Data in hexadecimal format. 

Important You must restart your device after setting this registry key for it to take effect.

Note Enabling the registry key above will make DCOM servers enforce an Authentication-Level of RPC_C_AUTHN_LEVEL_PKT_INTEGRITY or higher for activation.

Note This registry value does not exist by default; you must create it. Windows will read it if it exists and will not overwrite it.

New DCOM error events

To help you identify the applications that might have compatibility issues after we enable DCOM security hardening changes, we added new DCOM error events in the System log; see the tables below. The system will log these events if it detects that a DCOM client application is trying to activate a DCOM server using an authentication level that is less than RPC_C_AUTHN_LEVEL_PKT_INTEGRITY. You can trace to the client device from the server-side event log and use client-side event logs to find the application.

Server events

Event IDMessage
10036“The server-side authentication level policy does not allow the user %1\%2 SID (%3) from address %4 to activate DCOM server. Please raise the activation authentication level at least to RPC_C_AUTHN_LEVEL_PKT_INTEGRITY in client application.”(%1 – domain, %2 – user name, %3 – User SID, %4 – Client IP Address)

Client events

Event IDMessage
10037“Application %1 with PID %2 is requesting to activate CLSID %3 on computer %4 with explicitly set authentication level at %5. The lowest activation authentication level required by DCOM is 5(RPC_C_AUTHN_LEVEL_PKT_INTEGRITY). To raise the activation authentication level, please contact the application vendor.”
10038“Application %1 with PID %2 is requesting to activate CLSID %3 on computer %4 with default activation authentication level at %5. The lowest activation authentication level required by DCOM is 5(RPC_C_AUTHN_LEVEL_PKT_INTEGRITY). To raise the activation authentication level, please contact the application vendor.”(%1 – Application Path, %2 – Application PID, %3 – CLSID of the COM class the application is requesting to activate, %4 – Computer Name, %5 – Value of Authentication Level)

Availability

These error events are only available for a subset of Windows versions; see the table below.

Windows versionAvailable on or after these dates
Windows Server 2022September 27, 2021KB5005619
Windows 10, version 2004, Windows 10, version 20H2, Windows 10, version 21H1September 1, 2021KB5005101
Windows 10, version 1909August 26, 2021KB5005103
Windows Server 2019, Windows 10, version  1809August 26, 2021KB5005102
Windows Server 2016, Windows 10, version 1607September 14, 2021KB5005573
Windows Server 2012 R2 and Windows 8.1October 12, 2021KB5006714

Source :
https://support.microsoft.com/en-us/topic/kb5004442-manage-changes-for-windows-dcom-server-security-feature-bypass-cve-2021-26414-f1400b52-c141-43d2-941e-37ed901c769c

#StopRansomware: Vice Society

Summary

Actions to take today to mitigate cyber threats from ransomware:

• Prioritize and remediate known exploited vulnerabilities.
• Train users to recognize and report phishing attempts.
• Enable and enforce multifactor authentication.

Note: This joint Cybersecurity Advisory (CSA) is part of an ongoing #StopRansomware effort to publish advisories for network defenders that detail various ransomware variants and ransomware threat actors. These #StopRansomware advisories include recently and historically observed tactics, techniques, and procedures (TTPs) and indicators of compromise (IOCs) to help organizations protect against ransomware. Visit stopransomware.gov to see all #StopRansomware advisories and to learn more about other ransomware threats and no-cost resources.

The Federal Bureau of Investigation (FBI), the Cybersecurity and Infrastructure Security Agency (CISA), and the Multi-State Information Sharing and Analysis Center (MS-ISAC) are releasing this joint CSA to disseminate IOCs and TTPs associated with Vice Society actors identified through FBI investigations as recently as September 2022. The FBI, CISA, and the MS-ISAC have recently observed Vice Society actors disproportionately targeting the education sector with ransomware attacks.

Over the past several years, the education sector, especially kindergarten through twelfth grade (K-12) institutions, have been a frequent target of ransomware attacks. Impacts from these attacks have ranged from restricted access to networks and data, delayed exams, canceled school days, and unauthorized access to and theft of personal information regarding students and staff. The FBI, CISA, and the MS-ISAC anticipate attacks may increase as the 2022/2023 school year begins and criminal ransomware groups perceive opportunities for successful attacks. School districts with limited cybersecurity capabilities and constrained resources are often the most vulnerable; however, the opportunistic targeting often seen with cyber criminals can still put school districts with robust cybersecurity programs at risk. K-12 institutions may be seen as particularly lucrative targets due to the amount of sensitive student data accessible through school systems or their managed service providers.

The FBI, CISA, and the MS-ISAC encourage organizations to implement the recommendations in the Mitigations section of this CSA to reduce the likelihood and impact of ransomware incidents.

Download the PDF version of this report: pdf, 521 KB

Technical Details

Note: This advisory uses the MITRE ATT&CK® for Enterprise framework, version 11. See MITRE ATT&CK for Enterprise for all referenced tactics and techniques.

Vice Society is an intrusion, exfiltration, and extortion hacking group that first appeared in summer 2021. Vice Society actors do not use a ransomware variant of unique origin. Instead, the actors have deployed versions of Hello Kitty/Five Hands and Zeppelin ransomware, but may deploy other variants in the future.

Vice Society actors likely obtain initial network access through compromised credentials by exploiting internet-facing applications [T1190]. Prior to deploying ransomware, the actors spend time exploring the network, identifying opportunities to increase accesses, and exfiltrating data [TA0010] for double extortion–a tactic whereby actors threaten to publicly release sensitive data unless a victim pays a ransom. Vice Society actors have been observed using a variety of tools, including SystemBC, PowerShell Empire, and Cobalt Strike to move laterally. They have also used “living off the land” techniques targeting the legitimate Windows Management Instrumentation (WMI) service [T1047] and tainting shared content [T1080].

Vice Society actors have been observed exploiting the PrintNightmare vulnerability (CVE-2021-1675 and CVE-2021-34527 ) to escalate privileges [T1068]. To maintain persistence, the criminal actors have been observed leveraging scheduled tasks [T1053], creating undocumented autostart Registry keys [T1547.001], and pointing legitimate services to their custom malicious dynamic link libraries (DLLs) through a tactic known as DLL side-loading [T1574.002]. Vice Society actors attempt to evade detection through masquerading their malware and tools as legitimate files [T1036], using process injection [T1055], and likely use evasion techniques to defeat automated dynamic analysis [T1497]. Vice Society actors have been observed escalating privileges, then gaining access to domain administrator accounts, and running scripts to change the passwords of victims’ network accounts to prevent the victim from remediating. 

Indicators of Compromise (IOCs)

Email Addresses
v-society.official@onionmail[.]org
ViceSociety@onionmail[.]org
OnionMail email accounts in the format of [First Name][Last Name]@onionmail[.]org
TOR Address
http://vsociethok6sbprvevl4dlwbqrzyhxcxaqpvcqt5belwvsuxaxsutyad[.]onion
IP Addresses for C2Confidence Level
5.255.99[.]59High Confidence
5.161.136[.]176Medium Confidence
198.252.98[.]184Medium Confidence
194.34.246[.]90Low Confidence

See Table 1 for file hashes obtained from FBI incident response investigations in September 2022.

Table 1: File Hashes as of September 2022

MD5SHA1
fb91e471cfa246beb9618e1689f1ae1da0ee0761602470e24bcea5f403e8d1e8bfa29832
 3122ea585623531df2e860e7d0df0f25cce39b21
 41dc0ba220f30c70aea019de214eccd650bc6f37
 c9c2b6a5b930392b98f132f5395d54947391cb79

MITRE ATT&CK TECHNIQUES

Vice Society actors have used ATT&CK techniques, similar to Zeppelin techniques, listed in Table 2.

Table 2: Vice Society Actors ATT&CK Techniques for Enterprise

Initial Access
Technique TitleIDUse
Exploit Public-Facing ApplicationT1190Vice Society actors exploit vulnerabilities in an internet-facing systems to gain access to victims’ networks.
Valid AccountsT1078Vice Society actors obtain initial network access through compromised valid accounts.
Execution
Technique TitleIDUse
Windows Management Instrumentation (WMI)T1047Vice Society actors leverage WMI as a means of “living off the land” to execute malicious commands. WMI is a native Windows administration feature.
Scheduled Task/JobT1053Vice Society have used malicious files that create component task schedule objects, which are often mean to register a specific task to autostart on system boot. This facilitates recurring execution of their code.
Persistence
Technique TitleIDUse
Modify System ProcessT1543.003Vice Society actors encrypt Windows Operating functions to preserve compromised system functions.
Registry Run Keys/Startup FolderT1547.001Vice Society actors have employed malicious files that create an undocumented autostart Registry key to maintain persistence after boot/reboot.
DLL Side-LoadingT1574.002Vice Society actors may directly side-load their payloads by planting their own DLL then invoking a legitimate application that executes the payload within that DLL. This serves as both a persistence mechanism and a means to masquerade actions under legitimate programs.
Privilege Escalation
Technique TitleIDUse
Exploitation for Privilege EscalationT1068Vice Society actors have been observed exploiting PrintNightmare vulnerability (CVE-2021-1675 and CVE-2021-34527) to escalate privileges.
Defense Evasion
Technique TitleIDUse
MasqueradingT1036Vice Society actors may attempt to manipulate features of the files they drop in a victim’s environment to mask the files or make the files appear legitimate.
Process InjectionT1055Vice Society artifacts have been analyzed to reveal the ability to inject code into legitimate processes for evading process-based defenses. This tactic has other potential impacts, including the ability to escalate privileges or gain additional accesses.
Sandbox EvasionT1497Vice Society actors may have included sleep techniques in their files to hinder common reverse engineering or dynamic analysis.
Lateral Movement
Technique TitleIDUse
Taint Shared ContentT1080Vice Society actors may deliver payloads to remote systems by adding content to shared storage locations such as network drives.
Exfiltration
Technique TitleIDUse
ExfiltrationTA0010Vice Society actors are known for double extortion, which is a second attempt to force a victim to pay by threatening to expose sensitive information if the victim does not pay a ransom.
Impact
Technique TitleIDUse
Data Encrypted for ImpactT1486Vice Society actors have encrypted data on target systems or on large numbers of systems in a network to interrupt availability to system and network resources.
Account Access RemovalT1531Vice Society actors run a script to change passwords of victims’ email accounts.

Mitigations

The FBI and CISA recommend organizations, particularly the education sector, establish and maintain strong liaison relationships with the FBI Field Office in their region and their regional CISA Cybersecurity Advisor. The location and contact information for FBI Field Offices and CISA Regional Offices can be located at www.fbi.gov/contact-us/field-offices and www.cisa.gov/cisa-regions, respectively. Through these partnerships, the FBI and CISA can assist with identifying vulnerabilities to academia and mitigating potential threat activity. The FBI and CISA further recommend that academic entities review and, if needed, update incident response and communication plans that list actions an organization will take if impacted by a cyber incident.

The FBI, CISA, and the MS-ISAC recommend network defenders apply the following mitigations to limit potential adversarial use of common system and network discovery techniques and to reduce the risk of compromise by Vice Society actors:

Preparing for Cyber Incidents

  • Maintain offline backups of data, and regularly maintain backup and restoration.  By instituting this practice, the organization ensures they will not be severely interrupted, and/or only have irretrievable data.
  • Ensure all backup data is encrypted, immutable (i.e., cannot be altered or deleted), and covers the entire organization’s data infrastructure. Ensure your backup data is not already infected.
  • Review the security posture of third-party vendors and those interconnected with your organization. Ensure all connections between third-party vendors and outside software or hardware are monitored and reviewed for suspicious activity.
  • Implement listing policies for applications and remote access that only allow systems to execute known and permitted programs under an established security policy.
  • Document and monitor external remote connections. Organizations should document approved solutions for remote management and maintenance, and immediately investigate if an unapproved solution is installed on a workstation.
  • Implement a recovery plan to maintain and retain multiple copies of sensitive or proprietary data and servers in a physically separate, segmented, and secure location (i.e., hard drive, storage device, the cloud).

Identity and Access Management

  • Require all accounts with password logins (e.g., service account, admin accounts, and domain admin accounts) to comply with National Institute of Standards and Technology (NIST) standards for developing and managing password policies.
    • Use longer passwords consisting of at least 8 characters and no more than 64 characters in length;
    • Store passwords in hashed format using industry-recognized password managers;
    • Add password user “salts” to shared login credentials;
    • Avoid reusing passwords;
    • Implement multiple failed login attempt account lockouts;
    • Disable password “hints”;
    • Refrain from requiring password changes more frequently than once per year unless a password is known or suspected to be compromised.
      Note: NIST guidance suggests favoring longer passwords instead of requiring regular and frequent password resets. Frequent password resets are more likely to result in users developing password “patterns” cyber criminals can easily decipher.
    • Require administrator credentials to install software.
  • Require phishing-resistant multifactor authentication for all services to the extent possible, particularly for webmail, virtual private networks, and accounts that access critical systems.
  • Review domain controllers, servers, workstations, and active directories for new and/or unrecognized accounts.
  • Audit user accounts with administrative privileges and configure access controls according to the principle of least privilege. 
  • Implement time-based access for accounts set at the admin level and higher. For example, the Just-in-Time (JIT) access method provisions privileged access when needed and can support enforcement of the principle of least privilege (as well as the Zero Trust model). This is a process where a network-wide policy is set in place to automatically disable admin accounts at the Active Directory level when the account is not in direct need. Individual users may submit their requests through an automated process that grants them access to a specified system for a set timeframe when they need to support the completion of a certain task.

Protective Controls and Architecture

  • Segment networks to prevent the spread of ransomware. Network segmentation can help prevent the spread of ransomware by controlling traffic flows between—and access to—various subnetworks and by restricting adversary lateral movement.
  • Identify, detect, and investigate abnormal activity and potential traversal of the indicated ransomware with a networking monitoring tool. To aid in detecting the ransomware, implement a tool that logs and reports all network traffic, including lateral movement activity on a network. Endpoint detection and response (EDR) tools are particularly useful for detecting lateral connections as they have insight into common and uncommon network connections for each host.
  • Install, regularly update, and enable real time detection for antivirus software on all hosts.
  • Secure and closely monitor remote desktop protocol (RDP) use.
    • Limit access to resources over internal networks, especially by restricting RDP and using virtual desktop infrastructure. If RDP is deemed operationally necessary, restrict the originating sources and require MFA to mitigate credential theft and reuse. If RDP must be available externally, use a VPN, virtual desktop infrastructure, or other means to authenticate and secure the connection before allowing RDP to connect to internal devices. Monitor remote access/RDP logs, enforce account lockouts after a specified number of attempts to block brute force campaigns, log RDP login attempts, and disable unused remote access/RDP ports.

Vulnerability and Configuration Management

  • Keep all operating systems, software, and firmware up to date. Timely patching is one of the most efficient and cost-effective steps an organization can take to minimize its exposure to cybersecurity threats. Organizations should prioritize patching of vulnerabilities on CISA’s Known Exploited Vulnerabilities catalog.
  • Disable unused ports.
  • Consider adding an email banner to emails received from outside your organization.
  • Disable hyperlinks in received emails.
  • Disable command-line and scripting activities and permissions. Privilege escalation and lateral movement often depend on software utilities running from the command line. If threat actors are not able to run these tools, they will have difficulty escalating privileges and/or moving laterally.
  • Ensure devices are properly configured and that security features are enabled.
  • Disable ports and protocols that are not being used for a business purpose (e.g., RDP Transmission Control Protocol Port 3389).
  • Restrict Server Message Block (SMB) Protocol within the network to only access servers that are necessary, and remove or disable outdated versions of SMB (i.e., SMB version 1). Threat actors use SMB to propagate malware across organizations.

REFERENCES

REPORTING

The FBI is seeking any information that can be shared, to include boundary logs showing communication to and from foreign IP addresses, a sample ransom note, communications with Vice Society actors, Bitcoin wallet information, decryptor files, and/or a benign sample of an encrypted file.

The FBI, CISA, and the MS-ISAC strongly discourage paying ransom as payment does not guarantee victim files will be recovered. Furthermore, payment may also embolden adversaries to target additional organizations, encourage other criminal actors to engage in the distribution of ransomware, and/or fund illicit activities. Regardless of whether you or your organization have decided to pay the ransom, the FBI and CISA urge you to promptly report ransomware incidents to a local FBI Field Office, or to CISA at report@cisa.gov or (888) 282-0870. SLTT government entities can also report to the MS-ISAC (SOC@cisecurity.org or 866-787-4722).

DISCLAIMER

The information in this report is being provided “as is” for informational purposes only. The FBI, CISA, and the MS-ISAC do not endorse any commercial product or service, including any subjects of analysis. Any reference to specific commercial products, processes, or services by service mark, trademark, manufacturer, or otherwise, does not constitute or imply endorsement, recommendation, or favoring by the FBI, CISA, or the MS-ISAC.

Revisions

September 6, 2022: Initial Version

Source :
https://www.cisa.gov/uscert/ncas/alerts/aa22-249a

Basic Authentication Deprecation in Exchange Online – September 2022 Update

One month from today, we’re going to start to turn off basic auth for specific protocols in Exchange Online for customers who use them.

Since our first announcement nearly three years ago, we’ve seen millions of users move away from basic auth, and we’ve disabled it in millions of tenants to proactively protect them.

We’re not done yet though, and unfortunately usage isn’t yet at zero. Despite that, we will start to turn off basic auth for several protocols for tenants not previously disabled.

Starting October 1st, we will start to randomly select tenants and disable basic authentication access for MAPI, RPC, Offline Address Book (OAB), Exchange Web Services (EWS), POP, IMAP, Exchange ActiveSync (EAS), and Remote PowerShell. We will post a message to the Message Center 7 days prior, and we will post Service Health Dashboard notifications to each tenant on the day of the change.

We will not be disabling or changing any settings for SMTP AUTH.

If you have removed your dependency on basic auth, this will not affect your tenant or users. If you have not (or are not sure), check the Message Center for the latest data contained in the monthly usage reports we have been sending monthly since October 2021. The data for August 2022 will be sent within the first few days of September.

What If You Are Not Ready for This Change?

We recognize that unfortunately there are still many tenants unprepared for this change. Despite multiple blog posts, Message Center posts, interruptions of service, and coverage via tweets, videos, conference presentations and more, some customers are still unaware this change is coming. There are also many customers aware of the deadline who simply haven’t done the necessary work to avoid an outage.

Our goal with this effort has only ever been to protect your data and accounts from the increasing number of attacks we see that are leveraging basic auth.

However, we understand that email is a mission-critical service for many of our customers and turning off basic auth for many of them could potentially be very impactful.

One-Time Re-Enablement

Today we are announcing an update to our plan to offer customers who are unaware or are not ready for this change.

When we turn off basic auth after October 1st, all customers will be able to use the self-service diagnostic to re-enable basic auth for any protocols they need, once per protocol. Details on this process are below.

Once this diagnostic is run, basic auth will be re-enabled for those protocol(s). Selected protocol(s) will stay enabled for basic auth use until end of December 2022. During the first week of calendar year 2023, those protocols will be disabled for basic auth use permanently, and there will be no possibility of using basic auth after that.

Avoiding Disruption

If you already know you need more time and wish to avoid the disruption of having basic auth disabled you can run the diagnostics during the month of September, and when October comes, we will not disable basic for protocol(s) you specify. We will disable basic for any non-opted-out protocols, but you will be able to re-enable them (until the end of the year) by following the steps below if you later decide you need those too.

In other words – if you do not want basic for a specific protocol or protocols disabled in October, you can use the same self-service diagnostic in the month of September. Details on this process below.

Diagnostic Options

Thousands of customers have already used the self-service diagnostic we discussed in earlier blog posts (here and here) to re-enable basic auth for a protocol that had been turned off, or to tell us not to include them in our proactive protection expansion program. We’re using this same diagnostic again, but the workflow is changing a little.

Today, we have archived all prior re-enable and opt-out requests. If you have previously opted out or re-enabled basic for some protocol, you’ll need to follow the steps below during the month of September to indicate you want us to leave something enabled for basic auth after Oct 1.

To invoke the self-service diagnostic, you can go directly to the basic auth self-help diagnostic by simply clicking on this button (it’ll bring up the diagnostic in the Microsoft 365 admin center if you’re a tenant Global Admin):

thumbnail image 1 of blog post titled 
	
	
	 
	
	
	
				
		
			
				
						
							Basic Authentication Deprecation in Exchange Online – September 2022 Update

Or you can open the Microsoft 365 admin center and click the green Help & support button in the lower right-hand corner of the screen.

thumbnail image 2 of blog post titled 
	
	
	 
	
	
	
				
		
			
				
						
							Basic Authentication Deprecation in Exchange Online – September 2022 Update
thumbnail image 3 of blog post titled 
	
	
	 
	
	
	
				
		
			
				
						
							Basic Authentication Deprecation in Exchange Online – September 2022 Update

When you click the button, you enter our self-help system. Here you can enter the phrase “Diag: Enable Basic Auth in EXO

Customers with tenants in the Government Community Cloud (GCC) are unable to use the self-service diagnostic covered here. Those tenants may opt out by following the process contained in the Message Center post sent to their tenant today. If GCC customers need to re-enable a protocol following the Oct 1st deadline they will need to open a support ticket.

Opting Out

During the month of September 2022, the diagnostic will offer only the option to opt-out. By submitting your opt-out request during September, you are telling us that you do not want us to disable basic for a protocol or protocols during October.  Please understand we will be disabling basic auth for all tenants permanently in January 2023, regardless of their opt-out status.

The diagnostic will show a version of the dialog below, and you can re-run it for multiple protocols. It might look a bit different if some protocols have already been disabled. Note too that protocols are not removed from the list as you opt-out but rest assured (unless you receive an error) we will receive the request.

thumbnail image 4 of blog post titled 
	
	
	 
	
	
	
				
		
			
				
						
							Basic Authentication Deprecation in Exchange Online – September 2022 Update

Re-Enabling Basic for protocols

Starting October 1, the diagnostic will only allow you to re-enable basic auth for a protocol that it was disabled for.

If you did not opt-out during September, and we disabled basic for a protocol you later realize you need, you can use this to re-enable it.

thumbnail image 5 of blog post titled 
	
	
	 
	
	
	
				
		
			
				
						
							Basic Authentication Deprecation in Exchange Online – September 2022 Update

Within an hour (usually much sooner) after you run the diagnostics and ask us to re-enable basic for a protocol, basic auth will start to work again.

At this point, we have to remind you that by re-enabling basic for a protocol, you are leaving your users and data vulnerable to security risks, and that we have customers suffering from basic auth-based attacks every single day (but you know that already).

Starting January 1, 2023, the self-serve diagnostic will no longer be available, and basic auth will soon thereafter be disabled for all protocols.

Summary of timelines and actions

Please see the following flow chart to help illustrate the changes and actions that you might need to take:

thumbnail image 6 of blog post titled 
	
	
	 
	
	
	
				
		
			
				
						
							Basic Authentication Deprecation in Exchange Online – September 2022 Update

Blocking Basic Authentication Yourself

If you re-enable basic for a protocol because you need some extra time and then afterward no longer need basic auth you can block it yourself instead of waiting for us to do it in January 2023. The quickest and most effective way to do this is to use Authentication Policies which block basic auth connections at the first point of contact to Exchange Online.

Just go into the Microsoft 365 admin center, navigate to SettingsOrg SettingsModern Authentication and uncheck the boxes to block basic for all protocols you no longer need (these checkboxes will do nothing once we block basic for a protocol permanently, and we’ll remove them some time after January 2023).

thumbnail image 7 of blog post titled 
	
	
	 
	
	
	
				
		
			
				
						
							Basic Authentication Deprecation in Exchange Online – September 2022 Update

Reporting Web Service Endpoint

For those of you using the Reporting Web Service REST endpoint to get access to Message Tracking Logs and more, we’re also announcing today that this service will continue to have basic auth enabled until Dec 31st for all customers, no opt-out or re-enablement is required. And, we’re pleased to be able to provide the long-awaited guidance for this too right here

EOP/SCC PowerShell

Basic authentication will remain enabled until Dec 31st, 2022. Customers need to migrate to certificate based authentication. Follow the Instructions here: App-only authentication

One Other Basic Authentication Related Update

We’re adding a new capability to Microsoft 365 to help our customers avoid the risks posed by basic authentication. This new feature changes the default behavior of Office applications to block sign-in prompts using basic authentication. With this change, if users try to open Office files on servers that only use basic authentication, they won’t see any basic authentication sign-in prompts. Instead, they’ll see a message that the file has been blocked because it uses a sign-in method that may be insecure.

You can read more about this great new feature here: Basic authentication sign-in prompts are blocked by default in Microsoft 365 Apps.

Office Team is looking for customers to opt-in to their Private Preview Program for this feature. Please send them an email if you are interested in signing up: basicauthdeprmailer@microsoft.com.

Summary

This effort has taken three years from initial communication until now, and even that has not been enough time to ensure that all customers know about this change and take all necessary steps. IT and change can be hard, and the pandemic changed priorities for many of us, but everyone wants the same thing: better security for their users and data.

Our customers are important to us, and we do not want to see them breached, or disrupted. It’s a fine balance but we hope this final option will allow the remaining customers using Basic auth to finally get rid of it.

The end of 2022 will see us collectively reach that goal, to Improve Security – Together.

The Exchange Team

Source :
https://techcommunity.microsoft.com/t5/exchange-team-blog/basic-authentication-deprecation-in-exchange-online-september/ba-p/3609437

UniFi Network – Understanding and Implementing Minimum RSSI

This article explains what Minimum RSSI is and how to configure it in the UniFi Network application. We only recommend using this if you are familiar with basic RF theory as misconfiguration may result in performance degradation of your network.

How Minimum RSSI works

Received Signal Strength Indication (RSSI) is a value indicating the perceived signal level of a wireless client from the AP’s perspective. The Minimum RSSI value is set individually on each AP and indicates the minimum signal level required for a client to remain connected. 

The main purpose of this is to assist with a client’s roaming between two nearby APs. It prevents a device getting “stuck” connected to the initial AP at a weaker signal strength as opposed to roaming to a new AP that may be more optimal. Once the signal drops below the Minimum RSSI value set, the initial AP will kick the client so that it can reconnect to the new AP.

Once an AP kicks a client (by sending a de-authentication packet), it is up to the client to find a better AP to connect to. It may connect back to the same AP, especially if it is the only one within range. Since the signal strength still does not meet the Minimum RSSI, it will again be booted. Improper tuning can thus result in network instability. For this reason, it is important to realize that there is no one size fits all and you should carefully test your configuration to avoid introducing connectivity problems.

How to determine and configure Minimum RSSI

Minimum RSSI is can be enabled within the UniFi Network Application by selecting an AP in UniFi Devices and then navigating to Settings in the side-panel of the selected device. Once enabled, this can be manually set for your 2G and 5G radios independently. 

You can view the Signal Strength for your current wireless clients by clicking on a device in the Client Devices tab. The signal is measured in units of dbm (decibels per milliwatt). You will notice that this is a negative number because the power is less than 1 mW:

  • dbm = 10 log P1/1mW
  • 0 dBm = 1 mW
  • -10 dBm = 0.1 mW
  • -20 dBm = 0.01 mW, and so forth

A value close to 0 indicates high signal quality, whereas a larger negative value indicates poor signal quality. Remember, you need to granularly select the appropriate value for each AP and avoid using a single value everywhere. 

Other Considerations

There are many factors that can affect the a client’s RSSI at the AP side including distance, building materials, objects, interference, etc. As much as we would love to give a recommendation, it really isn’t this simple. It’s safe to say -80dBm would be a starting point for standard home or office configurations, but there are too many environmental variables so you should have caution at all times.

The best method to determine appropriate Minimum RSSI values is to perform a site survey. This can be done by testing the signal strength of various wireless clients at different distances. Each device will have different antenna configurations and will thus perform differently in the same geographic location. You want to connect to an SSID, make it specific to that AP (an override on that SSID), and then roam to what you would consider the outer edge of the desired coverage area. Mark the client’s RSSI, and then take a couple more points. The more data you gather, the better idea you’ll get for the minimum RSSI value to use.

Source :
https://help.ui.com/hc/en-us/articles/221321728-UniFi-Network-Understanding-and-Implementing-Minimum-RSSI

UniFi – HDD Requirements and Compatibility

HDDs are not required for normal operation, however they expand the functionality by enabling things such as video recording from UniFi Protect, and call recordings and voicemails from UniFi Talk.

We strongly recommend using the UniFi 8TB HDD for UniFi OS Consoles with a 3.5” HDD bay (UDM Pro, UDM SE, UNVR, and UNVR-Pro). These are specialized, industrial-grade drives that can support continuous read and write operations required by a video surveillance system.

Cloud Keys (UCK-G2-PLUS) require a 2.5” HDD for which we strongly recommend continuing to use the drive shipped natively with your equipment. If it will be replaced, the Toshiba 2.5″ 5400RPM 1TB HDD (MQ01ABD100V) appears most stable according to internal testing.

Incorrect drives will result in premature failure which can degrade your entire network’s performance, as well as prevent remote management.

Third-party Drives

If you insist on using a third-party drive, it should meet the following criteria:

  • It fits inside the HDD tray
    • 3.5” for Dream Machines and Network Video Recorders
    • 2.5” for the UCK Gen2 Plus
  • It is a surveillance-grade drive designed for continuous load
    • These are generally 7200RPM, CMR Drives. SMR drives are not recommended and may lead to performance issues, loss of video footage, or even system crashes.
  • It offers at least 1 TB of storage.  No maximum HDD capacity has been established.

If you’re using multiple HDDs with your UniFi OS Console, they must all be the same size.  

The total usable storage capacity will be affected based on whether either the redundancy level is set to One Disk (RAID1 / RAID5) or Half of Disks (RAID10). 

Incompatible HDDs

Some hard drives require an additional 12V external power supply. These hard drives are not supported by the UCK Gen2 Plus or the UNVR.

The following is a list of 3.5” drives that are confirmed to be incompatible with our UniFi OS Consoles:

VendorSeriesModelCapacityNotes
SeagateSkyHawkST10000VX000410TBDoes not fit the drive tray.
SeagateUltrathinST500LT032500GBDoes not have bottom screws.
Western DigitalUltraSlimWD5000MPCK500GBDoes not have bottom screws and connectors do not fit the tray.
AnyAnySMR DrivesAnyDrives fit the tray but cause issues.

If you have questions about a particular hard drive or need help choosing a hard drive, please reach out to the Ubiquiti Community for insights and recommendations.

Source :
https://help.ui.com/hc/en-us/articles/360037340954-UniFi-HDD-Requirements-and-Compatibility

Exit mobile version