Open Port Vulnerabilities List

Insufficiently protected open ports can put your IT environment at serious risk. Threat actors often seek to exploit open ports and their applications through spoofing, credential sniffing and other techniques. For example, in 2017, cybercriminals spread WannaCry ransomware by exploiting an SMB vulnerability on port 445. Other examples include the ongoing campaigns targeting Microsoft’s Remote Desktop Protocol (RDP) service running on port 3389.

Handpicked related content:

Read on to learn more about the security risks linked to ports, vulnerable ports that need your attention and ways to enhance the security of open ports.

A Refresher on Ports

Ports are logical constructs that identify a specific type of network service. Each port is linked to a specific protocol, program or service, and has a port number for identification purposes. For instance, secured Hypertext Transfer Protocol (HTTPS) messages always go to port 443 on the server side, while port 1194 is exclusively for OpenVPN.

The most common transport protocols that have port numbers are Transmission Control Protocol (TCP) and User Datagram Protocol (UDP). TCP is a connection-oriented protocol with built-in re-transmission and error recovery. UDP is a connectionless protocol that doesn’t recover or correct errors in messages; it’s faster  and has less network overhead traffic than TCP. Both TCP and UDP sit at the transport layer of the TCP/IP stack and use the IP protocol to address and route data on the internet. Software and services are designed to use TCP or UDP, depending on their requirements.

TCP and UDP ports are in one of these three states:

  • Open — The port responds to connection requests.
  • Closed — The port is unreachable, indicating that there is no corresponding service running.
  • Filtered — The firewall is monitoring traffic and blocking certain connection requests to the port.

Security Risks Linked to Ports

Numerous incidents have demonstrated that open ports are most vulnerable to attack when the services listening to them are unpatched or insufficiently protected or misconfigured, which can lead to compromised systems and networks. In these cases, threat actors can use open ports to perform various cyberattacks that exploit the lack of authentication mechanisms in the TCP and UDP protocols. One common example is spoofing, where a malicious actor impersonates a system or a service and sends malicious packets, often in combination with IP spoofing and man-in-the-middle-attacks. The campaign against RDP Pipe Plumbing is one of the latest to employ such a tactic. In addition, ports that have been opened on purpose (for instance, on a web server) can be attacked via that port using application-layer attacks such as SQL injection, cross-site request forgery and directory traversal.

Another common technique is the denial of service (DoS) attack, most frequently used in the form of distributed denial of service (DDoS), where attackers send massive numbers of connection requests from various machine to the service on the target in order to deplete its resources.

Vulnerable Ports that Need Your Attention

Any port can be targeted by threat actors, but some are more likely to fall prey to cyberattacks because they commonly have serious shortcomings, such as application vulnerabilities, lack of two-factor authentication and weak credentials.

Here are the most vulnerable ports regularly used in attacks:

Ports 20 and 21 (FTP)

Port 20 and (mainly) port 21 are File Transfer Protocol (FTP) ports that let users send and receive files from servers.

FTP is known for being outdated and insecure. As such, attackers frequently exploit it through:

  • Brute-forcing passwords
  • Anonymous authentication (it’s possible to log into the FTP port with “anonymous” as the username and password)
  • Cross-site scripting
  • Directory traversal attacks

Port 22 (SSH)

Port 22 is for Secure Shell (SSH). It’s a TCP port for ensuring secure access to servers. Hackers can exploit port 22 by using leaked SSH keys or brute-forcing credentials.

Port 23 (Telnet)

Port 23 is a TCP protocol that connects users to remote computers. For the most part, Telnet has been superseded by SSH, but it’s still used by some websites. Since it’s outdated and insecure, it’s vulnerable to many attacks, including credential brute-forcing, spoofing and credential sniffing.

Port 25 (SMTP)

Port 25 is a Simple Mail Transfer Protocol (SMTP) port for receiving and sending emails. Without proper configuration and protection, this TCP port is vulnerable to spoofing and spamming.

Port 53 (DNS)

Port 53 is for Domain Name System (DNS). It’s a UDP and TCP port for queries and transfers, respectively. This port is particularly vulnerable to DDoS attacks.

Ports 137 and 139 (NetBIOS over TCP) and 445 (SMB)

Server Message Block (SMB) uses port 445 directly and ports 137 and 139 indirectly. Cybercriminals can exploit these ports through:

  • Using the EternalBlue exploit, which takes advantage of SMBv1 vulnerabilities in older versions of Microsoft computers (hackers used EternalBlue on the SMB port to spread WannaCry ransomware in 2017)
  • Capturing NTLM hashes
  • Brute-forcing SMB login credentials

Ports 80, 443, 8080 and 8443 (HTTP and HTTPS)

HTTP and HTTPS are the hottest protocols on the internet, so they’re often targeted by attackers. They’re especially vulnerable to cross-site scripting, SQL injections, cross-site request forgeries and DDoS attacks.

Ports 1433,1434 and 3306 (Used by Databases)

These are the default ports for SQL Server and MySQL. They are used to distribute malware or are directly attacked in DDoS scenarios. Quite often, attackers probe these ports to find unprotected database with exploitable default configurations.

Port 3389 (Remote Desktop)

This port is used in conjunction with various vulnerabilities in remote desktop protocols and to probe for leaked or weak user authentication. Remote desktop vulnerabilities are currently the most-used attack type; one example is the BlueKeep vulnerability.

Tips for Strengthening the Security of Open Ports

Luckily, there are ways to enhance the security of open ports. We highly recommend the following six strategies:

1. Patch firewalls regularly.

Your firewall is the gatekeeper to all the other systems and services in your network. Patching keeps your firewalls up to date and repairs vulnerabilities and flaws in your firewall system that cybercriminals could use to gain full access to your systems and data.

2. Check ports regularly.

You should also regularly scan and check your ports. There are three  main ways to do this:

  • Command-line tools — If you have the time to scan and check ports manually, use command-line tools to spot and scan open ports. Examples include Netstat and Network Mapper, both of which can be installed on a wide range of operating systems, including Windows and Linux.
  • Port scanners — If you want faster results, consider using a port scanner. It’s a computer program that checks if ports are open, closed or filtered. The process is simple: The scanner transmits a network request to connect to a specific port and captures the response.
  • Vulnerability scanning tools — Solutions of this type can also be used to discover ports that are open or configured with default passwords.
  1. Track service configuration changes.

Many services on your network connect to various ports, so it is important to monitor the running states of installed services and continuously track changes to service configuration settings. Services can be vulnerable when they are unpatched or misconfigured.

Using Netwrix Change Tracker, you can harden your systems by tracking unauthorized changes and other suspicious activities. In particular, it provides the following functionality:

  • Actionable alerting about configuration changes
  • Automatic recording, analyzing, validating and verifying of every change
  • Real-time change monitoring
  • Constant application vulnerability monitoring

4. Use IDP and IPS tools.

Intrusion detection systems (IDS) and intrusion prevention systems (IPS) can help you prevent attackers from exploiting your ports. They monitor your network, spot possible cybersecurity incidents, log information about them and report the incidents to security administrators. IPS complements your firewalls by identifying suspicious incoming traffic and logging and blocking the attack.

5. Use SSH Keys.

Another option is to use SSH keys. These access credentials are more secure than passwords because decrypting SSH is very difficult, if not impossible. There are two types of SSH keys:

  • Private or identity keys, which identify users and give them access
  • Public or authorized keys, which determine who can access your system

You can use public-key cryptographic algorithms and key generation tools to create SSH keys.

6. Conduct penetration tests and vulnerability assessments.

Consider conducting penetration tests and vulnerability assessments to protect your ports. Although both of these techniques are used to spot vulnerabilities in IT infrastructure, they are quite different. Vulnerability scans only identify and report vulnerabilities, while penetration tests exploit security gaps to determine how attackers can gain unauthorized access to your system.


What is an open port vulnerability?

An open port vulnerability is a security gap caused by an open port. Without proper configuration and protection, attackers can use open ports to access your systems and data.

Which ports are most vulnerable?

Certain ports and their applications are more likely to be targeted because they often have weaker credentials and defenses. Common vulnerable ports include:

  • FTP (20, 21)
  • SSH (22)
  • Telnet (23)
  • SMTP (25)
  • DNS (53)
  • NetBIOS over TCP (137, 139)
  • SMB (445)
  • HTTP and HTTPS (80, 443, 8080, 8443)
  • Ports 1433, 1434 and 3306
  • Remote desktop (3389)

Is port 80 a security risk?

Port 80 isn’t inherently a security risk. However, if you leave it open and don’t have the proper configurations in place, attackers can easily use it to access your systems and data. Unlike port 443 (HTTPS), port 80 is unencrypted, making it easy for cybercriminals to access, leak and tamper with sensitive data.

Source :

Spectre and Meltdown Attacks Against OpenSSL

The OpenSSL Technical Committee (OTC) was recently made aware of several potential attacks against the OpenSSL libraries which might permit information leakage via the Spectre attack.1 Although there are currently no known exploits for the Spectre attacks identified, it is plausible that some of them might be exploitable.

Local side channel attacks, such as these, are outside the scope of our security policy, however the project generally does introduce mitigations when they are discovered. In this case, the OTC has decided that these attacks will not be mitigated by changes to the OpenSSL code base. The full reasoning behind this is given below.

The Spectre attack vector, while applicable everywhere, is most important for code running in enclaves because it bypasses the protections offered. Example enclaves include, but are not limited to:

The reasoning behind the OTC’s decision to not introduce mitigations for these attacks is multifold:

  • Such issues do not fall under the scope of our defined security policy. Even though we often apply mitigations for such issues we do not mandate that they are addressed.
  • Maintaining code with mitigations in place would be significantly more difficult. Most potentially vulnerable code is extremely non-obvious, even to experienced security programmers. It would thus be quite easy to introduce new attack vectors or fix existing ones unknowingly. The mitigations themselves obscure the code which increases the maintenance burden.
  • Automated verification and testing of the attacks is necessary but not sufficient. We do not have automated detection for this family of vulnerabilities and if we did, it is likely that variations would escape detection. This does not mean we won’t add automated checking for issues like this at some stage.
  • These problems are fundamentally a bug in the hardware. The software running on the hardware cannot be expected to mitigate all such attacks. Some of the in-CPU caches are completely opaque to software and cannot be easily flushed, making software mitigation quixotic. However, the OTC recognises that fixing hardware is difficult and in some cases impossible.
  • Some kernels and compilers can provide partial mitigation. Specifically, several common compilers have introduced code generation options addressing some of these classes of vulnerability:
    • GCC has the -mindirect-branch-mfunction-return and -mindirect-branch-register options
    • LLVM has the -mretpoline option
    • MSVC has the /Qspectre option

  1. Nicholas Mosier, Hanna Lachnitt, Hamed Nemati, and Caroline Trippel, “Axiomatic Hardware-Software Contracts for Security,” in Proceedings of the 49th ACM/IEEE International Symposium on Computer Architecture (ISCA), 2022.

Posted by OpenSSL Technical Committee May 13th, 2022 12:00 am

Source :

Altaro VM Backup’s Services Explained

Altaro VM Backup has a number of services, handing different types of operations and in certain cases it’s important to know the role of a specific service.

Below you can find an extensive list of each service’s responsibility.

Services on the Altaro VM Backup Console

The list below can also be used for services running on an Altaro Offsite Server machine only.

Display Name                          Description
Altaro VM Backup EngineManagement of backup schedules and configuration
Altaro VM Backup Deduplication ServicePerforms deduplication of data during backup operations
Altaro Offsite Server 6Altaro Offsite Server for v5 & v6 Offsite Copies
Altaro Offsite Server 8Altaro Offsite Server for Offsite Copies
Altaro Offsite Server 8 ControllerProvides an interface between the Offsite Server Management Console UI and the Altaro Offsite Server
Altaro VM Backup API ServiceEnables a RESTful API interface to Altaro VM Backup
Altaro VM Backup Hyper-V Host Agent – N1Facilitates backup and restore operations for Virtual machines on a Hyper-V Host and/or a VMware Host using VDDK 5.5
Altaro VM Backup Hyper-V Host Agent – N2Facilitates backup and restore operations for Virtual machines on a VMware Host using VDDK 6.5 & 6.7
Altaro VM Backup ControllerProvides an interface between the Management Console UI and the Altaro VM Backup Service

Services on a Hyper-V Host added to Altaro VM Backup

DisplayName                          Description
Altaro VM Backup Hyper-V Host Agent – N1Facilitates backup and restore operations for Virtual machines on a Hyper-V Host and/or a VMware Host using VDDK 5.5
Altaro VM Backup Hyper-V Host Agent – N2Facilitates backup and restore operations for Virtual machines on a VMware Host using VDDK 6.5 & 6.7
Altaro Offsite Server 6Altaro Offsite Server for v5 & v6 Offsite Copies
Altaro Offsite Server 8Altaro Offsite Server for Offsite Copies

Source :

Best Practices for setting up Altaro VM Backup

This best practice guide goes through the Altaro VM Backup features explaining their use and the optimal way to configure them in order to make the best use out of the software.

You will need to adapt this to your specific environment, especially depending on how much resources you have available, however this guide takes you through the most important configurations that are often overlooked too.

Setting up the Altaro VM Backup Management Console

The Altaro VM Backup Management Console can be utilised to add and manage multiple hosts in one console. However these hosts must be in the same LAN and at the same physical site (same building). Setups with multiple physical sites must have an instance of Altaro VM Backup at each site.

To manage these multiple installations, you can utilise the ‘Central Monitoring Console’ where you’ll be able to monitor as well as manage these Altaro VM Backup installations remotely.

A single Altaro VM Backup instance can manage both Hyper-V & VMware hosts.

For optimal results, Altaro runs some maintenance specific tasks using (multiple) single threaded operations. For this reason installing on a machine which has a CPU with a higher single thread performance would yield better results than installing on a machine which has a CPU with more cores and lower single thread performance.

Thus for the fastest results, installing Altaro VM Backup on a machine with a higher single thread CPU speed would be best.

Backup Locations

Make sure Opportunity Locks (Oplocks) are disabled if the backup location is a NAS.

If your backup location is a Windows machine, the equivalent to Oplocks is: Set-SmbServerConfiguration -EnableLeasing 0

Run the above command via Powershell.

Offsite Copies

With Altaro VM Backup, you are provided with the functionality of an Offsite Copy Location, which is a redundant/secondary copy of your backups. You can even backup your VM’s to 2 different offsite copy locations for further redundancy of your data, so you can pick a cloud location as well as an Altaro Offsite Server for instance.

There are multiple options for setting this up:

  • You can choose a Physical Drive connected to the management console (the best practice for offsites is to have them located in another building/location).
  • Drive Rotation/Swap which allows you to set up a pool of drives/network paths.
  • A Network Path (LAN Only) or else to an offsite location via a WAN/VPN/Internet connection, which is an ideal tool for Disaster Recovery purposes. Please note that the latter situation (non-LAN) requires use of the Altaro Offsite Server
  • Backup to Microsoft AzureAmazon S3 or Wasabi.

Setting up an offsite copy location is as crucial as setting up backups to a primary location. Apart from the obvious reason that you’ll have a redundant set of backups to restore from, should the local backups become unusable due to disk corruption or other disk failures. Having a secondary copy of your backup sets also allows you to keep a broader history for your VM backups on your secondary location and you’ll be able to go further back when restoring if required.


Altaro VM Backup makes use of Augmented In-line Deduplication. Enabling this is highly recommended and is done from the ‘Advanced Settings’ screen as this will essentially ensure that any common data blocks across virtual machines are only written to the backup location once. This helps by saving a considerable amount of space and also makes backups much quicker since common information is only transferred once.

Boot From Backup

The Boot From Backup drive feature comes along with 2 options, either ‘Verification Mode’ or ‘Recovery Mode’. This is a very good option for getting your RTO down since you’re able to boot up the VM immediately from a backup location and start a restore in the background as well.

However it’s very important that if you are planning to do this, you’ll need a fast backup location that can handle the I/O of a booted VM that’s essentially going into production. Please note that when the VM has finished restoring, it’s suggested to restart the restored VM as soon as you get a chance in order to switch to the restored drives, which would have faster I/O throughput.


E-mail notifications are a simple and effective method of monitoring the backup status, yet it’s often overlooked. Setting up these notifications will provide you with a quick overview of the status over your of your backup jobs, hence – you won’t need to login into the Altaro Management console every day to confirm the backup status.

This way you’ll be alerted of any backup failures, allowing you to address said issues before the next backup schedule. Thereby ensuring that you always have a restorable backup point; so as a general best practice, always monitor your backup notifications.

Master Encryption Key

The Master Encryption Key in Altaro is utilised to encrypt the backups using AES 256-bit. It’s used if you choose to encrypt the local backups from the ‘Advanced Settings’ screen, while if you’re configuring offsite copies it must be used as offsite copies must be encrypted.

Altaro VM Backup will require the encryption key upon restoring, so it’s critical that you either remember it or take note of it in a secure password manager as there is no method of recovery for the master encryption key.

Scheduled Test Drills

Altaro VM Backup has the ability to run manual or automated verification of your backup data. This allows you to run scheduled verification jobs that will check the integrity of your backups on your backup location, or schedule full VM restores so that you can actually boot up the VM and confirm that everything works as expected. The VM will be restored with the NIC disabled so as to avoid IP conflicts with the production machine as well.

Failure of storage devices is not uncommon, therefore scheduling test drills is strongly advised for added peace-of-mind. Full instructions on configuring test drills.

Other General Best Practices

  • Backups and production VM’s should not be placed on the same drive.
  • Make sure Opportunity Locks (Oplocks) are disabled if the backup location is a NAS.
  • Backups should not be placed on a drive where an OS is running.
  • Altaro uses the drive it’s installed on as temporary storage and will require a small amount of free space (varying according to the size of the VMs being backed up).
  • Keep at least 10% of the backup location free.
  • The main Altaro VM Backup installation should not be installed on a machine that is also a domain controller (DC).
  • Directories/files inside the Altaro backup folder should not be tampered with, deleted or moved.
  • Do not take snapshots DFSR databases: “Snapshots aren’t supported by the DFSR database or any other Windows multi-master databases. This lack of snapshot support includes all virtualization vendors and products. DFSR doesn’t implement USN rollback quarantine protection like Active Directory Domain Services.” Source. 

Best Practices for Replication

Exclude Page File from Backup

As you’re aware Altaro VM Backup will take note of all changes since the last backup and transfer over all of the blocks that changed to the backup location. The page file will be changing very often and potentially causing your replication jobs to take longer.

Therefore, excluding the page file from backup equals, less transferred changes and as a result the replication jobs takes less time. This can be done by placing the page file onto a separate VHDX/VMDK file from the VM itself and then you can follow the steps here, in order to exclude the VHDX/VMDK file.

High Disk IO and Hypervisor Performance

Replication needs to make use of CDP (Continuous Data Protection), in order to take a backup every couple of minutes/hours, which makes Replication possible.

It’s important to note however that you should only enable high-frequency CDP (15 minutes or less) on VM’s that you really need to. This will ensure that the VM’s you really need to will be able to achieve the selected maximum frequency and in order not to have an impact your Hypervisor’s performance.

Source :

How to relocate the Altaro temporary files

Altaro VM Backup will create temporary files during backup operations and by default the location for these files is on the C: drive.

If you’d like to move the location of this temporary directory, please see according to which version you’re running below:

7.6 and newer

To do so, you can follow these steps:

  1. Ensure you are running at least 7.6.14. If not, update to the latest version from here
  2. Firstly, create a folder named “Overrides” in this path: C:\ProgramData\Altaro\AltaroBackupProfile
    If you’d like to move the temp files on the Altaro Offsite Server, create a folder named “Overrides” in this path: C:\ProgramData\Altaro\AltaroOffsiteServerProfile
  3. Then create a text file named “OverrideTempFolder.txt” inside the newly created folder
  4.  In the text file enter the path where you wish to store Altaro’s temp files, for example:{ “TempFolderPathOverride”:”E:\\Temp\\Altaro” }Ensure this location exists & that you use a double backslash as a separator (like above)
  5. Restart all Altaro services and on next Operation, the Altaro temporary files will now be stored in the above directory

7.5 and older

To do so, you can follow these steps:

  1. Ensure you are running at least version 5.0.97
  2. Firstly, create a folder named “Overrides” in this path: C:\ProgramData\Altaro\AltaroBackupProfile
    If you’d like to move the temp files on the Altaro Offsite Server, create a folder named “Overrides” in this path: C:\ProgramData\Altaro\AltaroOffsiteServerProfile
  3. Then create a text file named “OverrideTempFolder.txt” inside the newly created folder
  4.  In the text file enter the path where you wish to store Altaro’s temp files, for example: “E:\AltaroTemp” (without quotes) — ensure this location exists
  5. Restart all Altaro services and on next Operation, the Altaro temporary files will now be stored in the above directory


  • ProgramData is a hidden folder by default
  • Ensure that the file extension is showing, or you might end up with a file named “OverrideTempFolder.txt.txt”
  • Ensure there are no spaces at the end of the path and no extra line breaks in the text file

    Source :

Which Altaro directories do I need to exclude from AntiVirus software?

If you are running an AntiVirus software or a file-scanning software, we do recommend excluding a couple of directories used by Altaro in order to ensure that it’s operation remains undisrupted.

We do recommend excluding the following:

  • all onsite backup drive directories
  • all offsite backup drive directories
  • C:\ProgramData\Altaro on the Altaro Management and on the Hyper-V hosts
  • C:\Program Files\Altaro on the Altaro Management and on the Hyper-V hosts

Also, if you relocated the Altaro temporary files ensure to exclude that directory as well.

Source :

Altaro Dealing with “Windows Error 64” and “Windows Error 59”


The backup fails with a one of the following errors:

  • “Windows Error 64: The specified network name is no longer available.”
  • “Windows Error 59: An unexpected network error occurred.”


There’s a number of reasons that can very easily cause networks issues which will result in a failed backup pointing to a Windows Error 64 or 59. Mainly it could be down to potential hardware failures/issues or even configuration of network devices for that matter.

Aside from that, firewalls, other traffic on the line or other software could be causing load on the network or even on the storage device itself, that might be going over timeouts or maximum retransmission limits.

Sending backups over an unreliable connection such as a VPN/WAN connection can also result in such a failure, unless using the Altaro Offsite Server tool for offsite copies.

Timeouts from specific NAS boxes when using domain credentials can also be causing such disconnections.


There are numerous, distinct solutions applicable for backups failing with this error, seeing as it could be occurring for a number of reasons.

  • If you’re using a NAS as a backup location, it’s recommended that you utilise the credentials of the NAS box itself, even if it’s connected to Active Directory. The reason behind this, being that certain NAS’s have a timeout period associated for connections connected via domain credentials, so it could be the cause for the backup failure.
  • In addition to that this also doubles as a security measure in order to protect against Crypto-malware.
  • Another point to keep in mind if you’re using a NAS box, is to check whether the particular model you’re using has a sleep/standby option that could be causing such backup failure.
  • If you have other storage media available, try taking backups to this location, as the previous location may be experiencing hardware or software issues that may only present themselves during backup times. This will serve as a definite confirmation if the issue is with the previously configured location as well as a temporary solution.
  • If the backup location you have configured is going over an unreliable network, such a VPN/WAN connection, please note that this is not supported. This would only be supported if you’re making use of the Altaro Offsite Server which is only applicable for offsite copies and not primary backups.
  • If you’re using a backup device, such as a NAS which supports connections via iSCSI it’s recommended to set up the backup location this way. Devices connected via iSCSI usually perform better and in turn offer increased performance.
  • If the backup device is connected to a different switch to the backup server then it’s best to connect it to the same switch and re-test.
  • It’s recommended to change the network cables that the backup device and the backup server are connected with; additionally changing the ports on the switch would also be suggested.
  • Make sure Opportunity Locks (Oplocks) are disabled if the backup location is a NAS
  • If your backup location is a Windows machine, the equivalent to Oplocks is: Set-SmbServerConfiguration -EnableLeasing 0

    Run the above command via Powershell.
  • It’s also a good idea to reboot the backup device as well as the backup server to clear any open connections and refresh the devices.

    DWORD: SessTimeoutThe value entered here should be in seconds. You can try entering a value of 300 seconds (5 minutes) or 600 seconds (10 minutes). The default for this is 1 minute.
    This will increase the time the backup server waits for a response before the connection is aborted.

    DWORD: TcpMaxDataRetransmissions
    The value entered here will reflect the number of retries. The default number for this is 5.This will increase the number of tries the TCP retransmission mechanism will attempt to transmit data before the connection is aborted.
  • If the above does not help and you’re still experiencing issues, it’s recommended to temporarily disable any firewalls and antivirus products on the backup server, the hosts and the backup device. This applies for both software and hardware firewalls.

Source :

Microsoft finds Raspberry Robin worm in hundreds of Windows networks

Microsoft says that a recently spotted Windows worm has been found on the networks of hundreds of organizations from various industry sectors.

The malware, dubbed Raspberry Robin, spreads via infected USB devices, and it was first spotted in September 2021 by Red Canary intelligence analysts.

Cybersecurity firm Sekoia also observed it using QNAP NAS devices as command and control servers (C2) servers in early November [PDF], while Microsoft said it found malicious artifacts linked to this worm created in 2019.

Redmond’s findings align with those of the Red Canary’s Detection Engineering team, which also detected this worm on the networks of multiple customers, some of them in the technology and manufacturing sectors.

Although Microsoft observed the malware connecting to addresses on the Tor network, the threat actors are yet to exploit the access they gained to their victims’ networks.

This is in spite of the fact that they could easily escalate their attacks given that the malware can bypass User Account Control (UAC) on infected systems using legitimate Windows tools.

Microsoft shared this info in a private threat intelligence advisory shared with Microsoft Defender for Endpoint subscribers and seen by BleepingComputer.

Raspberry Robin worm infection flow
Raspberry Robin worm infection flow (Red Canary)

Abuses Windows legitimate tools to infect new devices

As already mentioned, Raspberry Robin is spreading to new Windows systems via infected USB drives containing a malicious .LNK file.

Once the USB device is attached and the user clicks the link, the worm spawns a msiexec process using cmd.exe to launch a malicious file stored on the infected drive.

It infects new Windows devices, communicates with its command and control servers (C2), and executes malicious payloads using several legitimate Windows utilities:

  • fodhelper (a trusted binary for managing features in Windows settings),
  • msiexec (command line Windows Installer component),
  • and odbcconf (a tool for configuring ODBC drivers).

“While msiexec.exe downloads and executes legitimate installer packages, adversaries also leverage it to deliver malware,” Red Canary researchers explained.

“Raspberry Robin uses msiexec.exe to attempt external network communication to a malicious domain for C2 purposes.”

Security researchers who spotted Raspberry Robin in the wild are yet to attribute the malware to a threat group and are still working on finding its operators’ end goal.

However, Microsoft has tagged this campaign as high-risk, given that the attackers could download and deploy additional malware within the victims’ networks and escalate their privileges at any time.

Source :

Critical PHP flaw exposes QNAP NAS devices to RCE attacks

QNAP has warned customers today that some of its Network Attached Storage (NAS) devices (with non-default configurations) are vulnerable to attacks that would exploit a three-year-old critical PHP vulnerability allowing remote code execution.

“A vulnerability has been reported to affect PHP versions 7.1.x below 7.1.33, 7.2.x below 7.2.24, and 7.3.x below 7.3.11. If exploited, the vulnerability allows attackers to gain remote code execution,” QNAP explained in a security advisory released today.

“To secure your device, we recommend regularly updating your system to the latest version to benefit from vulnerability fixes.”

The Taiwanese hardware vendor has already patched the security flaw (CVE-2019-11043) for some operating system versions exposed to attacks (QTS build 20220515 or later and QuTS hero h5.0.0.2069 build 20220614 or later).

However, the bug affects a wide range of devices running:

  • QTS 5.0.x and later
  • QTS 4.5.x and later
  • QuTS hero h5.0.x and later
  • QuTS hero h4.5.x and later
  • QuTScloud c5.0.x and later

QNAP customers who want to update their NAS devices to the latest firmware automatically need to log on to QTS, QuTS hero, or QuTScloud as administrator and click the “Check for Update” button under Control Panel > System > Firmware Update.

You can also manually upgrade your device after downloading the update on the QNAP website from Support > Download Center.

QNAP devices targeted by ransomware

Today’s warning comes after the NAS maker warned its customers on Thursday to secure their devices against active attacks deploying DeadBolt ransomware payloads.

BleepingComputer also reported over the weekend that ech0raix ransomware has started targeting vulnerable QNAP NAS devices again, according to sample submissions on the ID Ransomware platform and multiple user reports who had their systems encrypted.

Until QNAP issues more details on ongoing attacks, the infection vector used in these new DeadBolt and ech0raix campaigns remains unknown.

While QNAP is working on patching the CVE-2019-11043 PHP vulnerability in all vulnerable firmware versions, you should ensure that your device is not exposed to Internet access as an easy way to block incoming attacks.

As QNAP has advised in the past, users with Internet-exposed NAS devices should take the following measures to prevent remote access:

  • Disable the Port Forwarding function of the router: Go to the management interface of your router, check the Virtual Server, NAT, or Port Forwarding settings, and disable the port forwarding setting of the NAS management service port (port 8080 and 433 by default).
  • Disable the UPnP function of the QNAP NAS: Go to myQNAPcloud on the QTS menu, click the “Auto Router Configuration,” and unselect “Enable UPnP Port forwarding.”

QNAP also provides detailed info on how to toggle off remote SSH and Telnet connections, change the system port number, change device passwords, and enable IP and account access protection to further secure your device.

Update June 22, 08:45 EDT: After this story was published, QNAP’s PSIRT team updated the original advisory and told BleepingComputer that devices with default configurations are not impacted by CVE-2019-11043.

Also, QNAP said that the Deadbolt ransomware attacks are targeting devices running older system software (released between 2017 and 2019).

For CVE-2019-11043, described in QSA-22-20, to affect our users, there are some prerequisites that need to be met, which are:

  1. nginx is running, and
  2. php-fpm is running.

As we do not have nginx in our software by default, QNAP NAS are not affected by this vulnerability in their default state. If nginx is installed by the user and running, then the update provided with QSA-22-20 should be applied as soon as possible to mitigate associated risks.

We are updating our security advisory QSA-22-20 to reflect the facts stated above. Again we would like to point out that most QNAP NAS users are not affected by this vulnerability since its prerequisites are not met. The risk only exists when there is user-installed nginx present in the system.

 We have also updated the story to reflect the new information provided by QNAP.

Source :

QNAP Urges Users to Update NAS Devices to Prevent Deadbolt Ransomware Attacks

Taiwanese network-attached storage (NAS) devices maker QNAP on Thursday warned its customers of a fresh wave of DeadBolt ransomware attacks.

The intrusions are said to have targeted TS-x51 series and TS-x53 series appliances running on QTS 4.3.6 and QTS 4.4.1, according to its product security incident response team.

“QNAP urges all NAS users to check and update QTS to the latest version as soon as possible, and avoid exposing their NAS to the internet,” QNAP said in an advisory.

This development marks the third time QNAP devices have come under assault from DeadBolt ransomware since the start of the year.

Deadbolt Ransomware Attacks

In late January, as many as 4,988 DeadBolt-infected QNAP devices were identified, prompting the company to release a forced firmware update. A second uptick in new infections was observed in mid-March.

DeadBolt attacks are also notable for the fact that they allegedly leverage zero-day flaws in the software to gain remote access and encrypt the systems.

Ransomware Attacks

According to a new report published by Group-IB, exploitation of security vulnerabilities in public-facing applications emerged as the third most used vector to gain initial access, accounting for 21% of all ransomware attacks investigated by the firm in 2021.

Source :