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
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.
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.
Configure QTS to use SMB 3
Open Control Panel.
Go to Network & File Services > Win/Mac/NFS > Microsoft Networking.
Click Advanced Options.
Under Highest SMB version select SMB 3.
Click Apply.
Configure Time Machine to use QNAP NAS for backups
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.
Open Time Machine.
Click Select Backup Disk.
Select the NAS shared backup folder.
Click Use Disk.
Enter the username and password of the backup user account. Tip: This can be your NAS account or a dedicated Time Machine user account.
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
Open HBS 3.
Go to Services > Time Machine.
Check Use shared Time Machine account.
Enter a password for the Time Machine account.
(Optional) Set a storage quota.
Select Maximum
Enter the total capacity in GB. Important: If the backup data size is greater than the quota, the Time Machine backup will fail.
Click Apply.
Configure Time Machine to use QNAP NAS for backups
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.
Open Time Machine.
Click Select Backup Disk.
Select the NAS shared folder TMBackup.
Click Use Disk.
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.
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.
A new attack technique called ‘GIFShell’ allows threat actors to abuse Microsoft Teams for novel phishing attacks and covertly executing commands to steal data using … GIFs.
The new attack scenario, shared exclusively with BleepingComputer, illustrates how attackers can string together numerous Microsoft Teams vulnerabilities and flaws to abuse legitimate Microsoft infrastructure to deliver malicious files, commands, and perform exfiltrating data via GIFs.
As the data exfiltration is done through Microsoft’s own servers, the traffic will be harder to detect by security software that sees it as legitimate Microsoft Team’s traffic.
Overall, the attack technique utilizes a variety of Microsoft Teams flaws and vulnerabilities:
Bypassing Microsoft Teams security controls allows external users to send attachments to Microsoft Teams users.
Modify sent attachments to have users download files from an external URL rather than the generated SharePoint link.
Spoof Microsoft teams attachments to appear as harmless files but download a malicious executable or document.
Insecure URI schemes to allow SMB NTLM hash theft or NTLM Relay attacks.
Microsoft supports sending HTML base64 encoded GIFs, but does not scan the byte content of those GIFs. This allows malicious commands to be delivered within a normal-looking GIF.
Microsoft stores Teams messages in a parsable log file, located locally on the victim’s machine, and accessible by a low-privileged user.
Microsoft servers retrieve GIFs from remote servers, allowing data exfiltration via GIF filenames.
GIFShell – a reverse shell via GIFs
The new attack chain was discovered by cybersecurity consultant and pentester Bobby Rauch, who found numerous vulnerabilities, or flaws, in Microsoft Teams that can be chained together for command execution, data exfiltration, security control bypasses, and phishing attacks.
The main component of this attack is called ‘GIFShell,’ which allows an attacker to create a reverse shell that delivers malicious commands via base64 encoded GIFs in Teams, and exfiltrates the output through GIFs retrieved by Microsoft’s own infrastructure.
To create this reverse shell, the attacker must first convince a user to install a malicious stager that executes commands, and uploads command output via a GIF url to a Microsoft Teams web hook. However, as we know, phishing attacks work well in infecting devices, Rauch came up with a novel phishing attack in Microsoft Teams to aid in this, which we describe in the next section.
GIFShell works by tricking a user into loading a malware executable called the “stager” on their device that will continuously scan the Microsoft Teams logs located at $HOME\AppData\Roaming\Microsoft\Teams\IndexedDB\https_teams.microsoft.com_0.indexeddb.leveldb\*.log.
Microsoft Teams log folder Source: BleepingComputer
All received messages are saved to these logs and are readable by all Windows user groups, meaning any malware on the device can access them.
Once the stager is in place, a threat actor would create their own Microsoft Teams tenant and contact other Microsoft Teams users outside of their organization. Attackers can easily achieve this as Microsoft allows external communication by default in Microsoft Teams.
To initiate the attack, the threat actor can use Rauch’s GIFShell Python script to send a message to a Microsoft Teams user that contains a specially crafted GIF. This legitimate GIF image has been modified to include commands to execute on a target’s machine.
When the target receives the message, the message and the GIF will be stored in Microsoft Team’s logs, which the malicious stager monitors.
When the stager detects a message with a GIF, it will extract the base64 encoded commands and execute them on the device. The GIFShell PoC will then take the output of the executed command and convert it to base64 text.
This base64 text is used as the filename for a remote GIF embedded in a Microsoft Teams Survey Card that the stager submits to the attacker’s public Microsoft Teams webhook.
As Microsoft Teams renders flash cards for the user, Microsoft’s servers will connect back to the attacker’s server URL to retrieve the GIF, which is named using the base64 encoded output of the executed command.
The GIFShell server running on the attacker’s server will receive this request and automatically decode the filename allowing the attackers to see the output of the command run on the victim’s device, as shown below.
For example, a retrieved GIF file named ‘dGhlIHVzZXIgaXM6IA0KYm9iYnlyYXVjaDYyNzRcYm9iYnlyYXVJa0K.gif’ would decode to the output from the ‘whoami’ command executed on the infected device:
the user is:
bobbyrauch6274\bobbyrauIkBáë
The threat actors can continue using the GIFShell server to send more GIFs, with further embedded commands to execute, and continue to receive the output when Microsoft attempts to retrieve the GIFs.
As these requests are made by the Microsoft website, urlp.asm.skype.com, used for regular Microsoft Teams communication, the traffic will be seen as legitimate and not detected by security software.
This allows the GIFShell attack to covertly exfiltrate data by mixing the output of their commands with legitimate Microsoft Teams network communication.
Even worse, as Microsoft Teams runs as a background process, it does not even need to be opened by the user to receive the attacker’s commands to execute.
The Microsoft Teams logs folder have also been found accessed by other programs, including business monitoring software, such as Veriato, and potentially malware.
Microsoft acknowledged the research but said it would not be fixed as no security boundaries were bypassed.
“For this case, 72412, while this is great research and the engineering team will endeavor to improve these areas over time, these all are post exploitation and rely on a target already being compromised,” Microsoft told Rauch in an email shared with BleepingComputer.
“No security boundary appears to be bypassed. The product team will review the issue for potential future design changes, but this would not be tracked by the security team.”
Abusing Microsoft teams for phishing attacks
As we previously said, the GIFShell attack requires the installation of an executable that executes commands received within the GIFs.
To aid in this, Rauch discovered Microsoft Teams flaws that allowed him to send malicious files to Teams users but spoof them to look as harmless images in phishing attacks.
“This research demonstrates how it is possible to send highly convincing phishing attachments to victims through Microsoft Teams, without any way for a user to pre-screen whether the linked attachment is malicious or not,” explains Rauch in his writeup on the phishing method.
As we previously said in our discussion about GIFShell, Microsoft Teams allows Microsoft Teams users to message users in other Tenants by default.
However, to prevent attackers from using Microsoft Teams in malware phishing attacks, Microsoft does not allow external users to send attachments to members of another tenant.
While playing with attachments in Microsoft Teams, Rauch discovered that when someone sends a file to another user in the same tenant, Microsoft generates a Sharepoint link that is embedded in a JSON POST request to the Teams endpoint.
This JSON message, though, can then be modified to include any download link an attacker wants, even external links. Even worse, when the JSON is sent to a user via Teams’ conversation endpoint, it can also be used to send attachments as an external user, bypassing Microsoft Teams’ security restrictions.
For example, the JSON below has been modified to show a file name of Christmas_Party_Photo.jpeg but actually delivers a remote Christmas_Party_Photo.jpeg………….exe executable.
Microsoft Teams JSON to spoof an attachment Source: Bobby Rauch
When the attachment is rendered in Teams, it is displayed as Christmas_Party_Photo.jpeg, and when highlighting it, it will continue to show that name, as shown below.
Spoofing a JPEG file Source: Bobby Rauch
However, when the user clicks on the link, the attachment will download the executable from the attacker’s server.
In addition to using this Microsoft Teams spoofing phishing attack to send malicious files to external users, attackers can also modify the JSON to use Windows URIs, such as ms-excel:, to automatically launch an application to retrieve a document.
Rauch says this would allow attackers to trick users into connecting to a remote network share, letting threat actors steal NTLM hashes, or local attackers perform an NTLM relay attack to elevate privileges.
“These allowed, potentially unsafe URI schemes, combined with the lack of permissions enforcement and attachment spoofing vulnerabilities, can allow for a One Click RCE via NTLM relay in Microsoft Teams,” Rauch explains in his report on the spoofing attack.
Microsoft not immediately fixing bugs
Rauch told BleepingComputer that he disclosed the flaws to Microsoft in May and June of 2022, and despite Microsoft saying they were valid issues, they decided not to fix them immediately.
When BleepingComputer contacted Microsoft about why the bugs were not fixed, we were not surprised by their response regarding the GIFShell attack technique, as it requires the device to already be compromised with malware.
“This type of phishing is important to be aware of and as always, we recommend that users practice good computing habits online, including exercising caution when clicking on links to web pages, opening unknown files, or accepting file transfers.
We’ve assessed the techniques reported by this researcher and have determined that the two mentioned do not meet the bar for an urgent security fix. We’re constantly looking at new ways to better resist phishing to help ensure customer security and may take action in a future release to help mitigate this technique.” – a Microsoft spokesperson.
However, we were surprised that Microsoft did not consider the ability of external attackers to bypass security controls and send attachments to another tenant as not something that should be immediately fixed.
Furthermore, not immediately fixing the ability to modify JSON attachment cards so that Microsoft Teams recipients could be tricked to download files from remote URLs was also surprising.
However, Microsoft has left the door open to resolving these issues, telling BleepingComputer that they may be serviced in future versions.
“Some lower severity vulnerabilities that don’t pose an immediate risk to customers are not prioritized for an immediate security update, but will be considered for the next version or release of Windows,” explained Microsoft in a statement to BleepingComputer.
A vulnerability in the binding configuration of Cisco SD-WAN vManage Software containers could allow an unauthenticated, adjacent attacker who has access to the VPN0 logical network to also access the messaging service ports on an affected system.This vulnerability exists because the messaging server container ports on an affected system lack sufficient protection mechanisms. An attacker could exploit this vulnerability by connecting to the messaging service ports of the affected system. To exploit this vulnerability, the attacker must be able to send network traffic to interfaces within the VPN0 logical network. This network may be restricted to protect logical or physical adjacent networks, depending on device deployment configuration. A successful exploit could allow the attacker to view and inject messages into the messaging service, which can cause configuration changes or cause the system to reload.Cisco has released software updates that address this vulnerability. There are workarounds that address this vulnerability.This advisory is available at the following link: https://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-vmanage-msg-serv-AqTup7vs
Affected Products
Vulnerable ProductsThis vulnerability affects Cisco devices if they are running a vulnerable release of Cisco SD-WAN vManage Software.For information about which Cisco software releases are vulnerable, see the Fixed Software section of this advisory.Products Confirmed Not VulnerableOnly products listed in the Vulnerable Products section of this advisory are known to be affected by this vulnerability.Cisco has confirmed that this vulnerability does not affect the following Cisco products:
IOS XE SD-WAN Software
SD-WAN vBond Orchestrator Software
SD-WAN vEdge Cloud Routers
SD-WAN vEdge Routers
SD-WAN vSmart Controller Software
Workarounds
There is a workaround that addresses this vulnerability.Administrators can use access control lists (ACLs) to block ports 4222, 6222, and 8222, which are used by Cisco SD-WAN vManage Software messaging services. They may be configured in the following ways depending on deployment:
Cisco Cloud Controllers ACLs (Inbound Rules allowed list) are managed through the Self-Service Portal. Customers will have to review their ACL configurations on the Self-Service Portal to ensure that they are correct. This does not involve updating the controller version. By default, Cisco-hosted devices are protected against the issue described in the advisory unless the customer has explicitly allowed access. For more information, see Cisco SD-WAN Cloud Hosted Controllers Provisioning.
While these workarounds have been deployed and were proven successful in a test environment, customers should determine the applicability and effectiveness in their own environment and under their own use conditions. Customers should be aware that any workaround or mitigation that is implemented may negatively impact the functionality or performance of their network based on intrinsic customer deployment scenarios and limitations. Customers should not deploy any workarounds or mitigations before first evaluating the applicability to their own environment and any impact to such environment.
Fixed Software
Cisco has released free software updates that address the vulnerability described in this advisory. Customers may only install and expect support for software versions and feature sets for which they have purchased a license. By installing, downloading, accessing, or otherwise using such software upgrades, customers agree to follow the terms of the Cisco software license: https://www.cisco.com/c/en/us/products/end-user-license-agreement.htmlAdditionally, customers may only download software for which they have a valid license, procured from Cisco directly, or through a Cisco authorized reseller or partner. In most cases this will be a maintenance upgrade to software that was previously purchased. Free security software updates do not entitle customers to a new software license, additional software feature sets, or major revision upgrades.When considering software upgrades, customers are advised to regularly consult the advisories for Cisco products, which are available from the Cisco Security Advisories page, to determine exposure and a complete upgrade solution.In all cases, customers should ensure that the devices to be upgraded contain sufficient memory and confirm that current hardware and software configurations will continue to be supported properly by the new release. If the information is not clear, customers are advised to contact the Cisco Technical Assistance Center (TAC) or their contracted maintenance providers.Customers Without Service ContractsCustomers who purchase directly from Cisco but do not hold a Cisco service contract and customers who make purchases through third-party vendors but are unsuccessful in obtaining fixed software through their point of sale should obtain upgrades by contacting the Cisco TAC: https://www.cisco.com/c/en/us/support/web/tsd-cisco-worldwide-contacts.htmlCustomers should have the product serial number available and be prepared to provide the URL of this advisory as evidence of entitlement to a free upgrade.Fixed ReleasesCustomers are advised to upgrade to an appropriate fixed software release as indicated in the following table(s):Cisco SD-WAN vManage Software ReleaseFirst Fixed ReleaseEarlier than 20.3Migrate to a fixed release.20.3Migrate to a fixed release.20.620.6.420.7Migrate to a fixed release.20.8Migrate to a fixed release.20.920.9.1Note: It is the customer’s responsibility to upgrade their cloud controllers to the latest version in which this vulnerability is fixed.The Cisco Product Security Incident Response Team (PSIRT) validates only the affected and fixed release information that is documented in this advisory.
Exploitation and Public Announcements
The Cisco PSIRT is not aware of any public announcements or malicious use of the vulnerability that is described in this advisory.
Source
Cisco would like to thank Orange Business for reporting this vulnerability.
VersionDescriptionSectionStatusDate1.1Added cloud information.Workarounds and Fixed SoftwareFinal2022-SEP-091.0Initial public release.-Final2022-SEP-07
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 release
Behavior change
June 8, 2021
Hardening changes disabled by default but with the ability to enable them using a registry key.
June 14, 2022
Hardening changes enabled by default but with the ability to disable them using a registry key.
March 14, 2023
Hardening 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:
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 ID
Message
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 ID
Message
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.
Late evening, on September 6, 2022, the Wordfence Threat Intelligence team was alerted to the presence of a vulnerability being actively exploited in BackupBuddy, a WordPress plugin we estimate has around 140,000 active installations. This vulnerability makes it possible for unauthenticated users to download arbitrary files from the affected site which can include sensitive information.
After reviewing historical data, we determined that attackers started targeting this vulnerability on August 26, 2022, and that we have blocked 4,948,926 attacks targeting this vulnerability since that time.
The vulnerability affects versions 8.5.8.0 to 8.7.4.1, and has been fully patched as of September 2, 2022 in version 8.7.5. Due to the fact that this is an actively exploited vulnerability, we strongly encourage you to ensure your site has been updated to the latest patched version 8.7.5 which iThemes has made available to all site owners running a vulnerable version regardless of licensing status.
All Wordfence customers, including Wordfence Premium, Wordfence Care, Wordfence Response, and Wordfence Free users, have been, and will continue to be, protected against any attackers trying to exploit this vulnerability due to the Wordfence firewall’s built-in directory traversal and file inclusion firewall rules. Wordfence Premium, Care, & Response, customers receive enhanced protection as attackers heavily targeting the vulnerability are blocked by the IP Blocklist.
The BackupBuddy plugin for WordPress is designed to make back-up management easy for WordPress site owners. One of the features in the plugin is to store back-up files in multiple different locations, known as Destinations, which includes Google Drive, OneDrive, and AWS just to name a few. There is also the ability to store back-up downloads locally via the ‘Local Directory Copy’ option. Unfortunately, the method to download these locally stored files was insecurely implemented making it possible for unauthenticated users to download any file stored on the server.
More specifically the plugin registers an admin_init hook for the function intended to download local back-up files and the function itself did not have any capability checks nor any nonce validation. This means that the function could be triggered via any administrative page, including those that can be called without authentication (admin-post.php), making it possible for unauthenticated users to call the function. The back-up path is not validated and therefore an arbitrary file could be supplied and subsequently downloaded.
Due to this vulnerability being actively exploited, and its ease of exploitation, we are sharing minimal details about this vulnerability.
Indicators of Compromise
The Wordfence firewall has blocked over 4.9 million exploit attempts targeting this vulnerability since August 26, 2022, which is the first indication we have that this vulnerability was being exploited. We are seeing attackers attempting to retrieve sensitive files such as the /wp-config.php and /etc/passwd file which can be used to further compromise a victim.
The top 10 Attacking IP Addresses are as follows:
195.178.120.89 with 1,960,065 attacks blocked
51.142.90.255 with 482,604 attacks blocked
51.142.185.212 with 366770 attacks blocked
52.229.102.181 with 344604 attacks blocked
20.10.168.93 with 341,309 attacks blocked
20.91.192.253 with 320,187 attacks blocked
23.100.57.101 with 303,844 attacks blocked
20.38.8.68 with 302,136 attacks blocked
20.229.10.195 with 277,545 attacks blocked
20.108.248.76 with 211,924 attacks blocked
A majority of the attacks we have observed are attempting to read the following files:
/etc/passwd
/wp-config.php
.my.cnf
.accesshash
We recommend checking for the ‘local-download’ and/or the ‘local-destination-id’ parameter value when reviewing requests in your access logs. Presence of these parameters along with a full path to a file or the presence of ../../ to a file indicates the site may have been targeted for exploitation by this vulnerability. If the site is compromised, this can suggest that the BackupBuddy plugin was likely the source of compromise.
Conclusion
In today’s post, we detailed a zero-day vulnerability being actively exploited in the BackupBuddy plugin that makes it possible for unauthenticated attackers to steal sensitive files from an affected site and use the information obtained in those files to further infect a victim. This vulnerability was patched yesterday and we strongly recommend updating to the latest version of the plugin, currently version 8.7.5, right now since this is an actively exploited vulnerability.
All Wordfence customers, including Wordfence Premium, Wordfence Care, Wordfence Response, and Wordfence Free users, have been, and will continue to be, protected against any attackers trying to exploit this vulnerability due to the Wordfence firewall’s built-in directory traversal and file inclusion firewall rules.
If you believe your site has been compromised as a result of this vulnerability or any other vulnerability, we offer Incident Response services via Wordfence Care. If you need your site cleaned immediately, Wordfence Response offers the same service with 24/7/365 availability and a 1-hour response time. Both these products include hands-on support in case you need further assistance.
If you know a friend or colleague who is using this plugin on their site, we highly recommend forwarding this advisory to them to help keep their sites protected, as this is a serious vulnerability that is actively being exploited in the wild.
We will continue to monitor the situation and follow up as more information becomes available.
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
Vice 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.
Vice 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.
Vice 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.
Vice 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.
Vice 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.
Vice 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.
Vice 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).
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 unusedports.
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
Stopransomware.gov is a whole-of-government approach that gives one central location for ransomware resources and alerts.
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.
Gets the virtual network adapters of a virtual machine, snapshot, management operating system, or of a virtual machine and management operating system.
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):
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.
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.
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.
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:
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 Settings, Org Settings, Modern 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).
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.
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.
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:
Vendor
Series
Model
Capacity
Notes
Seagate
SkyHawk
ST10000VX0004
10TB
Does not fit the drive tray.
Seagate
Ultrathin
ST500LT032
500GB
Does not have bottom screws.
Western Digital
UltraSlim
WD5000MPCK
500GB
Does not have bottom screws and connectors do not fit the tray.
Any
Any
SMR Drives
Any
Drives 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.
You can secure your WordPress sites with CrowdSec using our latest application bouncer, available on the WordPress marketplace. This new plugin is compatible with versions 1.0.x and beyond. Given that the vast majority of websites in the world are hosted on WordPress, this plugin improves our defense arsenal in our mission to defend the greatest number.
Step one: Install CrowdSec agent
This bouncer has been designed to protect WordPress-hosted websites from all kinds of attacks. To be able to use this blocker, the first step is to install the CrowdSec agent.
Then, both installation and configuration of the plugin can be done in a few clicks from the WordPress marketplace.
CrowdSec plugin available on WordPress
Please note that first and foremost CrowdSec must be installed on a server that is accessible via the WordPress site. Remember: CrowdSec detects, bouncers deter.
Both pieces of software don’t have to be installed on the same server, although that would be easiest. To protect your server in the best possible way, the CrowdSec agent needs to be able to read relevant logs – either via file, syslog or whatever works best in your environment.
Step two: Install WordPress plugin
Installing the CrowdSec WordPress plugin is as easy as installing any other WordPress plugin:
Click ‘Plugins’ in the left navigation on your site’s dashboard.
Type ‘CrowdSec’ in the text field to the right. Hit enter.
In the CrowdSec plugin click ‘Install Now’
Once installed click ‘activate’ as illustrated below.
Now configure the plugin by clicking CrowdSec in the left navigation as shown below.
Set LAPI URL to the location of your CrowdSec agent. Is it installed on the same server, fill it out as shown above.
‘Bouncer API’ is created in cscli. Just follow the instructions.
For details on how to configure the CrowdSec WordPress bouncer, go to the official documentation or read on. Pay special attention to the option ‘Public website only’. This must be disabled if you wish to protect wp-admin (which you most likely would want to).
The “Flex mode” – a bulwark agains false positives
Thanks to the “Flex mode”, it is impossible to accidentally block access to your site to people who don’t deserve it. This mode makes it possible to never ban an IP but only to offer a Captcha, in the worst-case scenario.
CrowdSec blends into your design
When a user is suspected to be malevolent, CrowdSec will either send them her a Captcha to resolve or simply a page notifying that access is denied. Please note that it is possible to customize all the colors of these pages in a few clicks so that they integrate best with your design. On the other hand, all texts are also fully customizable. This will allow you, for example, to present translated pages in your users’ language.
The right balance between performance and security
By default, the “live mode” is enabled. The first time a stranger connects to your website, this mode means that the IP will be checked directly by the CrowdSec API. The rest of your user’s browsing will be even more transparent thanks to the fully customizable cache system.
But you can also activate the “Stream mode.” This mode allows you to constantly feed the bouncer with the malicious IP list via a background task (CRON), making it even faster when checking the IP of your visitors. Besides, if your site has a lot of unique visitors at the same time, this will not influence the traffic to the API of your CrowdSec instance.
Stream mode activation
If you’ve ever been confronted with high traffic, you are probably familiar with Redis or Memcached technologies. You have the capability to activate these caching technologies in the CrowdSec bouncer settings to guarantee invisible IP control on your site. For further explanation on stream vs live mode, check the official documentation.
CDN-friendly without forgetting other load balancers
If you use a CDN, a reverse proxy, or a load balancer, it is now possible to indicate in the bouncer settings the IP ranges of these devices to check the IP of your users. For other IPs, the bouncer will not trust the X-Forwarded-For header.
Coming up next
Soon, the plugin will have a dashboard allowing you to visualize the activity of your bouncer in live. It will also be possible to connect directly to CrowdSec’s global reputation database, without having to install an agent on your machine if you don’t wish to.
Widely tested, 100% open source
This plugin has been tested on the vast majority of WordPress versions installed in the world (90%+), according to WordPress real-time statistics. It has also been tested on a very wide range of PHP versions (7.2, 7.3, 7.4 and 8), the language in which WordPress is coded.
This plugin is released under MIT license, the most permissive and free license in the world. Its source code is fully available on GitHub. You can discover the entire collection of CrowdSec bouncers at our Hub. Beyond this one, you will find there more freshly released additions.
We would love to hear your feedback about this WordPress plugin. If you are interested in testing the bouncer to protect your sites or would like to get in touch with the team, give us a shout!