High Severity Vulnerability Patched in Download Manager Plugin

On July 8, 2022 the Wordfence Threat Intelligence team initiated the responsible disclosure process for a vulnerability we discovered in “Download Manager,” a WordPress plugin that is installed on over 100,000 sites. This flaw makes it possible for an authenticated attacker to delete arbitrary files hosted on the server, provided they have access to create downloads. If an attacker deletes the wp-config.php file they can gain administrative privileges, including the ability to execute code, by re-running the WordPress install process.

Wordfence PremiumWordfence Care, and Wordfence Response received a firewall rule on July 8, 2022 to provide protection against any attackers that try to exploit this vulnerability. Wordfence Free users will receive this same protection 30 days later on August 7, 2022.

We attempted to reach out to the developer on July 8, 2022, the same day we discovered the vulnerability. We never received a response so we sent the full details to the WordPress.org plugins team on July 26, 2022. The plugin was fully patched the next day on July 27, 2022.

We strongly recommend ensuring that your site has been updated to the latest patched version of “Download Manager”, which is version 3.2.53 at the time of this publication.

Description: Authenticated (Contributor+) Arbitrary File Deletion
Affected Plugin: Download Manager
Plugin Slug: download-manager
Plugin Developer: W3 Eden, Inc.
Affected Versions: <= 3.2.50
CVE ID: CVE-2022-2431
CVSS Score: 8.8 (High)
Researcher/s: Chloe Chamberland
Fully Patched Version: 3.2.51

Download Manager is a popular WordPress plugin designed to allow site content creators to share downloadable files that are stored as posts. These downloads can be displayed on the front-end of the WordPress site for users to download. Unfortunately, vulnerable versions of the plugin contain a bypass in how the downloadable file is stored and subsequently deleted upon post deletion that make it possible for attackers to delete arbitrary files on the server.

More specifically, vulnerable versions of the plugin register the deleteFiles() function that is called via the before_delete_post hook. This hook is triggered right before a post has been deleted and its intended functionality in this case is to delete any files that may have been uploaded and associated with a “download” post.

At first glance this looks like a relatively safe functionality assuming the originally supplied file path is validated. Unfortunately, however, that is not the case as the path to the file saved with the “download” post is not validated to ensure it was a safe file type or in a location associated with a “download” post. This means that a path to an arbitrary file with any extension can be supplied via the file[files][] parameter when saving a post and that would be the file associated with the “download” post. On many configurations an attacker could supply a path such as /var/www/html/wp-config.php that would associate the site’s WordPress configuration file with the download post.

32add_action('before_delete_post', array($this, 'deleteFiles'), 10, 2);
979899100101102103104functiondeleteFiles($post_id, $post){    $files= WPDM()->package->getFiles($post_id, false);    foreach($filesas$file) {        $file= WPDM()->fileSystem->locateFile($file);        @unlink($file);    }}

When the user goes to permanently delete the “download” post the deleteFiles() function will be triggered by the before_delete_post hook and the supplied file will be deleted, if it exists.

This can be used by attackers to delete critical files hosted on the server. The wp-config.php file in particular is a popular target for attackers as deletion of this file would disconnect the existing database from the compromised site and allow the attacker to re-complete the initial installation process and connect their own database to the site. Once a database is connected, they would have access to the server and could upload arbitrary files to further infect the system.

Demonstrating site reset upon download post deletion.

This vulnerability requires contributor-level access and above to exploit, so it serves as an important reminder to make sure you don’t provide contributor-level and above access to untrusted users. It’s also important to validate that all users have strong passwords to ensure your site won’t subsequently be compromised as a result of a vulnerability like this due to an unauthorized actor gaining access via a weak or compromised password.


  • July 8, 2022 – Discovery of the Arbitrary File Deletion Vulnerability in the “Download Manager” plugin. A firewall rule is released to Wordfence PremiumWordfence Care, and Wordfence Response users. We attempt to initiate contact with the developer.
  • July 26, 2022 – After no response from the developer, we send the full disclosure details to the WordPress plugins team. They acknowledge the report and make contact with the developer.
  • July 27, 2022. – A fully patched version of the plugin is released as version 3.2.51.
  • August 7, 2022 – Wordfence free users receive the firewall rule.


In today’s post, we detailed a flaw in the “Download Manager” plugin that makes it possible for authenticated attackers to delete arbitrary files hosted on an affected server, which could lead to remote code execution and ultimately complete site compromise. This flaw has been fully patched in version 3.2.51.

We recommend that WordPress site owners immediately verify that their site has been updated to the latest patched version available, which is version 3.2.53 at the time of this publication.

Wordfence PremiumWordfence Care, and Wordfence Response received a firewall rule on July 8, 2022 to provide protection against any attackers trying to exploit this vulnerability. Wordfence Free users will receive this same protection 30 days later on August 7, 2022.

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.

Source :

Juniper Releases Patches for Critical Flaws in Junos OS and Contrail Networking

Juniper Networks has pushed security updates to address several vulnerabilities affecting multiple products, some of which could be exploited to seize control of affected systems.

The most critical of the flaws affect Junos Space and Contrail Networking, with the tech company urging customers to release versions 22.1R1 and 21.4.0, respectively.

Chief among them is a collection of 31 bugs in the Junos Space network management software, including CVE-2021-23017 (CVSS score: 9.4) that could result in a crash of vulnerable devices or even achieve arbitrary code execution.

“A security issue in nginx resolver was identified, which might allow an attacker who is able to forge UDP packets from the DNS server to cause 1-byte memory overwrite, resulting in worker process crash or potential other impact,” the company said.

The same security vulnerability has also been remediated in Northstar Controller in versions 5.1.0 Service Pack 6 and 6.2.2.

Additionally, the networking equipment maker cautioned of multiple known issues exist in CentOS 6.8 that’s shipped with Junos Space Policy Enforcer before version 22.1R1. As mitigations, the version of CentOS packed with the Policy Enforcer component has been upgraded to 7.9.

Also listed are 166 security vulnerabilities impacting its Contrail Networking product that impact all versions prior to 21.4.0 and have been collectively given the maximum CVSS score of 10.0.

“Multiple vulnerabilities in third party software used in Juniper Networks Contrail Networking have been resolved in release 21.4.0 by upgrading the Open Container Initiative (OCI)-compliant Red Hat Universal Base Image (UBI) container image from Red Hat Enterprise Linux 7 to Red Hat Enterprise Linux 8,” it noted in an advisory.

Source :

5 Key Things We Learned from CISOs of Smaller Enterprises Survey

New survey reveals lack of staff, skills, and resources driving smaller teams to outsource security.

As business begins its return to normalcy (however “normal” may look), CISOs at small and medium-size enterprises (500 – 10,000 employees) were asked to share their cybersecurity challenges and priorities, and their responses were compared the results with those of a similar survey from 2021.

Here are the 5 key things we learned from 200 responses:

— Remote Work Has Accelerated the Use of EDR Technologies

In 2021, 52% of CISOs surveyed were relying on endpoint detection and response (EDR) tools. This year that number has leapt to 85%. In contrast, last year 45% were using network detection and response (NDR) tools, while this year just 6% employ NDR. Compared to 2021, double the number of CISOs and their organizations are seeing the value of extended detection and response (XDR) tools, which combine EDR with integrated network signals. This is likely due to the increase in remote work, which is more difficult to secure than when employees work within the company’s network environment.

— 90% of CISOs Use an MDR Solution

There is a massive skills gap in the cybersecurity industry, and CISOs are under increasing pressure to recruit internally. Especially in small security teams where additional headcount is not the answer, CISOs are turning to outsourced services to fill the void. In 2021, 47% of CISOs surveyed relied on a Managed Security Services Provider (MSSP), while 53% were using a managed detection and response (MDR) service. This year, just 21% are using an MSSP, and 90% are using MDR.

— Overlapping Threat Protection Tools are the #1 Pain Point for Small Teams

The majority (87%) of companies with small security teams struggle to manage and operate their threat protection products. Among these companies, 44% struggle with overlapping capabilities, while 42% struggle to visualize the full picture of an attack when it occurs. These challenges are intrinsically connected, as teams find it difficult to get a single, comprehensive view with multiple tools.

— Small Security Teams Are Ignoring More Alerts

Small security teams are giving less attention to their security alerts. Last year 14% of CISOs said they look only at critical alerts, while this year that number jumped to 21%. In addition, organizations are increasingly letting automation take the wheel. Last year, 16% said they ignore automatically remediated alerts, and this year that’s true for 34% of small security teams.

— 96% of CISOs Are Planning to Consolidate Security Platforms

Almost all CISOs surveyed have consolidation of security tools on their to-do lists, compared to 61% in 2021. Not only does consolidation reduce the number of alerts – making it easier to prioritize and view all threats – respondents believe it will stop them from missing threats (57%), reduce the need for specific expertise (56%), and make it easier to correlate findings and visualize the risk landscape (46%). XDR technologies have emerged as the preferred method of consolidation, with 63% of CISOs calling it their top choice.

Download 2022 CISO Survey of Small Cyber Security Teams to see all the results.

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 :

Securing Port 443: The Gateway To A New Universe

At Wordfence our business is to secure over 4 million WordPress websites and keep them secure. My background is in network operations, and then I transitioned into software development because my ops role was at a scale where I found myself writing a lot of code. This led me to founding startups, and ultimately into starting the cybersecurity business that is Wordfence. But I’ve maintained that ops perspective, and when I think about securing a network, I tend to think of ports.

You can find a rather exhaustive list of TCP and UDP ports on Wikipedia, but for the sake of this discussion let’s focus on a few of the most popular ports:

  • 20 and 21 – FTP
  • 22 – SSH
  • 23 – (Just kidding. You better not be running Telnet)
  • 25 – Email via SMTP
  • 53 – DNS
  • 80 – Unencrypted Web
  • 110 – POP3 (for older email clients)
  • 443 – Web encrypted via TLS
  • 445 – Active Directory or SMB sharing
  • 993 – IMAP (for email clients)
  • 3306 – MySQL
  • 6378 – Redis
  • 11211 – Memcached

If you run your eye down this list, you’ll notice something interesting. The options available to you for services to run on most of these ports are quite limited. Some of them are specific to a single application, like Redis. Others, like SMTP, provide a limited number of applications, either proprietary or open-source. In both cases, you can change the configuration of the application, but it’s rare to write a custom application on one of those ports. Except port 443.

In the case of port 443 and port 80, you have a limited range of web servers listening on those ports, but users are writing a huge range of bespoke applications on port 443, and have a massive selection of applications that they can host on that port. Everything from WordPress to Drupal to Joomla, and more. There are huge lists of Content Management Systems.

Not only do you have a wide range of off-the-shelf web applications that you can run on port 443 or (if you’re silly) port 80, but you also have a range of languages they might be coded in, or in which you can code your own web application. Keep in mind that the web server, in this case, is much like an SSH or IMAP server in that it is listening on the port and handling connections, but the difference is that it is handing off execution to these languages, their various development frameworks, and ultimately the application that a developer has written to handle the incoming request.

With SSH, SMTP, FTP, IMAP, MySQL, Redis and most other services, the process listening on the port is the process that handles the request. With web ports, the process listening on the port delegates the incoming connection to another application, usually written in another language, running at the application layer, that is part of the extremely large and diverse ecosystem of web applications.

This concept in itself – that the applications listening on the web ports are extremely diverse and either home-made or selected from a large and diverse ecosystem – presents unique security challenges. In the case of, say, Redis, you might worry about running a secure version of Redis and making sure it is not misconfigured. In the case of a web server, you may have 50 application instances written in two languages from five different vendors all on the same port, which all need to be correctly configured, have their patch levels maintained, and be written using secure coding practices.

As if that doesn’t make the web ports challenging enough, they are also, for the most part, public. Putting aside internal websites for the moment, perhaps the majority of websites derive their value from making services available to users on the Internet by being public-facing. If you consider the list of ports I have above, or in the Wikipedia article I linked to, many of those ports are only open on internal networks or have access to them controlled if they are external. Web ports for public websites, by their very nature, must be publicly accessible for them to be useful. There are certain public services like SMTP or DNS, but as I mentioned above, the server that is listening on the port is the server handling the request in these cases.

A further challenge when securing websites is that often the monetary and data assets available to an attacker when compromising a website are greater than the assets they may gain compromising a corporate network. You see this with high volume e-commerce websites where a small business is processing a large number of web-based e-commerce transactions below $100. If the attacker compromises their corporate network via leaked AWS credentials, they may gain access to the company bank account and company intellectual property, encrypt the company’s data using ransomware, or perhaps even obtain customer PII. But by compromising the e-commerce website, they can gain access to credit card numbers in-flight, which are far more tradeable, and where the sum of available credit among all cards is greater than all the assets of the small business, including the amount of ransom that business might be able to pay.

Let’s not discount breaches like the 2017 Equifax breach that compromised 163 million American, British and Canadian citizen’s records. That was extremely valuable to the attackers. But targets like this are rare, and the Web presents a target-rich environment. Which is the third point I’d like to make in this post. While an organization may run a handful of services on other ports, many companies – with hosting providers in particular – run a large number of web applications. And an individual or company is far more likely to have a service running on a web port than any other port. Many of us have websites, but how many of us run our own DNS, SMTP, Redis, or another service listening on a port other than 80 or 443? Most of us who run websites also run MySQL on port 3306, but that port should not be publicly accessible if configured correctly.

That port 443 security is different has become clear to us at Wordfence over the years as we have tracked and cataloged a huge number of malware variants, web vulnerabilities, and a wide range of tactics, techniques, and procedures (TTP) that attackers targeting web applications use. Most of these have no relationship with the web server listening on port 443, and nearly all of them have a close relationship with the web application that the web server hands off control to once communication is established.

My hope with this post has been to catalyze a different way of thinking about port 443 and that other insecure port (80) we all hopefully don’t use. Port 443 is not just another service. It is, in fact, the gateway to a whole new universe of programming languages, dev frameworks, and web applications.

In the majority of cases, the gateway to that new universe is publicly accessible.

Once an attacker passes through that gateway, a useful way to think about the web applications hosted on the server is that each application is its own service that needs to have its patch level maintained, needs to be configured correctly, and should be removed if it is not in use to reduce the available attack surface.

If you are a web developer you may already think this way, and if anything, you may be guilty of neglecting services on ports other than port 80 or 443. If you are an operations engineer, or an analyst working in a SOC protecting an enterprise network, you may be guilty of thinking about port 443 as just another port you need to secure.

Think of port 443 as a gateway to a new universe that has no access control, with HTTPS providing easy standardized access, and with a wide range of diverse services running on the other side, that provide an attacker with a target and asset-rich environment.

Footnote: We will be exhibiting at Black Hat in Las Vegas this year at booth 2514 between the main entrance and Innovation City. Our entire team of over 30 people will be there. We’ll have awesome swag, as always. Come and say hi! Our team will also be attending DEF CON immediately after Black Hat.

Written by Mark Maunder – Founder and CEO of Wordfence. 

Source :

Anatomy of a DDoS amplification attack

Amplification attacks are one of the most common distributed denial of service (DDoS) attack vectors. These attacks are typically categorized as flooding or volumetric attacks, where the attacker succeeds in generating more traffic than the target can process, resulting in exhausting its resources due to the amount of traffic it receives. 

In this blog, we start by surveying the anatomy and landscape of amplification attacks, while providing statistics from Azure on most common attack vectors, volumes, and distribution. We then describe some of the countermeasures taken in Azure to mitigate amplification attacks. 

DDoS amplification attacks, what are they? 

Reflection attacks involve three parties: an attacker, a reflector, and a target. The attacker spoofs the IP address of the target to send a request to a reflector (e.g., open server, middlebox) that responds to the target, a virtual machine (VM) in this case. For the attack to be amplified the response should be larger than the request, resulting in a reflected amplification attack. The attacker’s motivation is to create the largest reflection out of the smallest requests. Attackers achieve this goal by finding many reflectors and crafting the requests that result in the highest amplification. 

The diagram illustrates how the attacker pushes a reflection attack to a target virtual machine that is hosted in Azure.
Figure 1. Reflected amplification attack

The root cause for reflected amplification attacks is that an attacker can force reflectors to respond to targets by spoofing the source IP address. If spoofing was not possible, this attack vector would be mitigated. Lots of effort has thus been made on disabling IP source address spoofing, and many organizations prevent spoofing nowadays so that attackers cannot leverage their networks for amplification attacks. Unfortunately, a significant number of organizations still allow source spoofing. The Spoofer project shows that a third of the IPv4 autonomous systems allow or partially allow spoofing.  

UDP and TCP amplification attacks 

Most attackers utilize UDP to launch amplification attacks since reflection of traffic with spoofed IP source address is possible due to the lack of proper handshake.  

While UDP makes it easy to launch reflected amplification attacks, TCP has a 3-way handshake that complicates spoofing attacks. As a result, IP source address spoofing is restricted to the start of the handshake. Although the TCP handshake allows for reflection, it does not allow for easy amplification since TCP SYN+ACK response is not larger than TCP SYN. Moreover, since the TCP SYN+ACK response is sent to the target, the attacker never receives it and can’t learn critical information contained in the TCP SYN+ACK needed to complete the 3-way handshake successfully to continue making requests on behalf of the target. 

The diagram illustrates how an attacker conducts a reflection attack in TCP. The attacker sends through SYN, then the reflector reflects packets restransmitted through SYN + ACK combination, which then sends an out-of-state SYN + ACK attack to the target virtual device.
Figure 2. Reflection attack in TCP 

In recent years, however, reflection and amplification attacks based on TCP have started emerging.  

Independent research found newer TCP reflected amplification vectors that utilize middleboxes, such as nation-state censorship firewalls and other deep packet inspection devices, to launch volumetric floods. Middleboxes devices may be deployed in asymmetric routing environments, where they only see one side of the TCP connection (e.g., packets from clients to servers). To overcome this asymmetry, such middleboxes often implement non-compliant TCP stack. Attackers take advantage of this misbehavior – they do not need to complete the 3-way handshake. They can generate a sequence of requests that elicit amplified responses from middleboxes and can reach infinite amplification in some cases. The industry has started witnessing these kinds of attacks from censorship and enterprise middle boxes, such as firewalls and IDPS devices, and we expect to see this trend growing as attackers look for more ways to create havoc utilizing DDoS as a primary weapon.  

Carpet bombing is another example of a reflected amplification attack. It often utilizes UDP reflection, and in recent years TCP reflection as well. With carpet bombing, instead of focusing the attack on a single or few destinations, the attacker attacks many destinations within a specific subnet or classless inter-domain routing (CIDR) block (for example /22). This will make it more difficult to detect the attack and to mitigate it, since such attacks can fly below prevalent baseline-based detection mechanisms. 

This diagram shows how an attacker uses reflectors to send spoofed packets to many target devices within a specific subnet hosted in Azure.
Figure 3. Carpet bombing attack 

One example of TCP carpet bombing is TCP SYN+ACK reflection, where attacker sends spoofed SYN to a wide range of random or pre-selected reflectors. In this attack, amplification is a result of reflectors that retransmit the TCP SYN+ACK when they do not get a response. The amplification of the TCP SYN+ACK response itself may not be large, and it depends on the number of retransmissions sent by the reflector. In Figure 3, the reflected attack traffic towards each of the target virtual machines (VMs) may not be enough to bring them down, however, collectively, the traffic may well overwhelm the targets’ network. 

UDP and TCP amplification attacks in Azure 

In Azure, we continuously work to mitigate inbound (from internet to Azure) and outbound (from Azure to internet) amplification attacks. In the last 12 months, we mitigated approximately 175,000 UDP reflected amplification attacks. We monitored more than 10 attack vectors, where the most common ones are NTP with 49,700 attacks, DNS with 42,600 attacks, SSDP with 27,100 attacks, and Memcached with 18,200 attacks. These protocols can demonstrate amplification factors of up to x4,670, x98, x76 and x9,000 respectively. 

This pie chart shows the volume of UDP- reflected amplification attacks observed in Azure from April 1, 2021, to March 31, 2022. The highest volume observed is 28% through NTP, while the least volume observed is 2% through Open VPN.
Figure 4. UDP reflected amplification attacks observed from April 1, 2021, to March 31, 2022

We measured the maximum attack throughput in packets per second for a single attack across all attack vectors. The highest throughput was a 58 million packets per second (pps) SSDP flood in August last year, in a short attack campaign that lasted 20 minutes on a single resource in Azure. 

This bar chart shows the packets per second flooding observed from April 1, 2021, to March 31, 2022 in Azure. The tallest bar represents the maximum observed throughput of 58 million packets per second SSDP flooding, while the shortest bar represents below 10M packets per second CharGEN flooding.
Figure 5. Maximum pps recorded for a single attack observed from April 1, 2021, to March 31, 2022 

TCP reflected amplification attacks are becoming more prevalent, with new attack vectors discovered. We encounter these attacks on Azure resources utilizing diverse types of reflectors and attack vectors. 

One such example is a TCP reflected amplification attack of TCP SYN+ACK on an Azure resource in Asia. Attack reached 30 million pps and lasted 15 minutes. Attack throughput was not high, however there were approximately 900 reflectors involved, each with retransmissions, resulting in a high pps rate that can bring down the host and other network infrastructure elements. 

This line chart shows the TCP SYN+ACK amplification attack volume on a single resource as seen on Azure. The line chart shows a spike reaching 30 million packets per second with a 15 minute duration. The 15-minute window illustrates the packets per second volume going down in the middle of the 15-minute window, and tapers off abruptly at the end of the 15-minute window.
Figure 6. TCP SYN+ACK amplification attack volume on an Azure resource in Asia

We see many TCP SYN+ACK retransmissions associated with the reflector that doesn’t get the ACK response from the spoofed source. Here is an example of such a retransmission: 

This screenshot shows a TCP SYN+ACK retransmission that doesn't get the ACK response. The screenshot highlights the information from source to destination and through which protocol it passes.

The retransmitted packet was sent 60 seconds after the first. 

Mitigating amplification attacks in Azure 

Reflected amplification attacks are here to stay and pose a serious challenge for the internet community. They continue to evolve and exploit new vulnerabilities in protocols and software implementations to bypass conventional countermeasures. Amplification attacks require collaboration across the industry to minimize their effect. It is not enough to mitigate such attacks at a certain location, with a pinpoint mitigation strategy. It requires intertwining of network and DDoS mitigation capabilities. 

Azure’s network is one of the largest on the globe. We combine multiple DDoS strategies across our network and DDoS mitigation pipeline to combat reflected amplification DDOS attacks.  

On the network side, we continuously optimize and implement various traffic monitoring, traffic engineering and quality of service (QoS) techniques to block reflected amplification attacks right at the routing infrastructure. We implement these mechanisms at the edge and core of our wide area networks (WAN) network, as well as within the data centers. For inbound traffic (from the Internet), it allows us to mitigate attacks right at the edge of our network. Similarly, outbound attacks (those that originate from within our network) will be blocked right at the data center, without exhausting our WAN and leaving our network. 

On top of that, our dedicated DDoS mitigation pipeline continuously evolves to offer advanced mitigation techniques against such attacks. This mitigation pipeline offers another layer of protection, on top of our DDoS networking strategies. Together, these two protection layers provide comprehensive coverage against the largest and most sophisticated reflected amplification attacks.  

Since reflected amplification attacks are typically volumetric, it is not only enough to implement advanced mitigation strategies, but also to maintain a highly scalable mitigation pipeline to be able to cope with the largest attacks. Our mitigation pipeline can mitigate more than 60Tbps globally, and we continue to evolve it by adding mitigation capacity across all network layers.  

Different attack vectors require different treatment 

UDP-based reflected amplification attacks are tracked, monitored, detected, and mitigated for all attack vectors. There are various mitigation techniques to combat these attacks, including anomaly detection across attacked IP addresses, L4 protocols, and tracking of spoofed source IPs. Since UDP reflected amplification attacks often create fragmented packets, we monitor IP fragments to mitigate them successfully.  

TCP-based reflected amplification attacks take advantage of poor TCP stack implementations, and large set of reflectors and targets, to launch such attacks. We adopt our mitigation strategies to be able to detect and block attacks from attackers and reflectors. We employ a set of mitigations to address TCP SYN, TCP SYN+ACK, TCP ACK, and other TCP-based attacks. Mitigation combines TCP authentication mechanisms that identify spoofed packets, as well as anomaly detection to block attack traffic when data is appended to TCP packets to trigger amplification with reflectors.  

The diagram shows how Azure uses mechanisms to stop amplification attacks as soon as a packet leaves a reflector or an attacker. Azure stops spoofed attacks in the following areas: 1. Attacks coming from an attacker-controlled reflector or direct from the attacker that is located outside Azure-protected space, with the attacks going to a target virtual machine or a reflector located inside a Azure; 2. Attacks coming from an attacker located within the Azure-protected space, and the attack is going to the reflector device outside of Azure, or an attack going through a reflector device to target another virtual machine.
Figure 7. Amplification attack detection 

Get started with Azure DDoS Protection to protect against amplification attacks 

Azure’s DDoS mitigation platform mitigated the largest ever DDoS attacks in history by employing a globally distributed DDoS protection platform that scales beyond 60Tbps. We ensure our platform and customers’ workloads are always protected against DDoS attacks. To enhance our DDoS posture, we continuously collaborate with other industry players to fight reflected amplification attacks. 

Azure customers are protected against Layer 3 and Layer 4 DDoS attacks as part of protecting our infrastructure and cloud platform. However, Azure DDoS Protection Standard provides comprehensive protection for customers by auto-tuning the detection policy to the specific traffic patterns of the protected application. This ensures that whenever there are changes in traffic patterns, such as in the case of flash crowd event, the DDoS policy is automatically updated to reflect those changes for optimal protection. When a reflected amplification attack is launched against a protected application, our detection pipeline detects it automatically based on the auto-tuned policy. The mitigation policy, that is automatically set for customers, without their need to manually configure or change it, includes the needed countermeasures to block reflected amplification attacks. 

Protection is simple to enable on any new or existing virtual network and does not require any application or resource changes. Our recently released Azure built-in policies allow for better management of network security compliance by providing great ease of onboarding across all your virtual network resources and configuration of logs. 

To strengthen the security posture of applications, Azure’s network security services can work in tandem to secure your workloads, where DDoS protection is one of the tools we provide. Organizations that pursue zero trust architecture can benefit from our services to achieve better protection. 

Learn more about Azure DDoS Protection Standard 

Amir Dahan and Syed Pasha
Azure Networking Team

Source :

Examining Emerging Backdoors

Next up in our “This didn’t quite make it into the 2021 Threat Report, but is still really cool” series: New backdoors!

Backdoors are a crucial component of a website infection. They allow the attackers ongoing access to the compromised environment and provide them a “foot in the door” to execute their payload. We see many different types of backdoors with varying functionality.

When our malware research team is provided with a new backdoor they need to write what’s called a “signature” to ensure that we detect and remove it in future security scans. Signatures need names, and over the years we’ve developed something of a taxonomy naming system for all of the different malware that we come across.

In this article we’re going to explore all the different categories of signatures for newly-discovered backdoors throughout the year 2021.

How do Backdoors Work?

HTTP requests to websites typically fall into one of the following categories:

  • POST – sending data to a website
  • GET – requesting data from a website
  • COOKIE – data (such as session data) saved from a website
  • REQUEST – a conjunction of all/any of the three

We see all sorts of different backdoors while cleaning up compromised websites. Sometimes they use one of these types of requests, or a combination of multiple different types.

We’ve broken all newly generated signatures from 2021 down for further analysis into the following categories:

A graph showing the distribution of new backdoor signatures generated in 2021.


By far the most common type of backdoor found in 2021 was an uploader: That is, a PHP script that allows the attackers to upload any file that they want. These malicious files allow anyone with the correct URL path, parameters and (occasionally) access credentials to upload whichever files they want to the web server. Typically, bad actors use these backdoors to upload a webshell, spam directory, dropper, or other type of file giving them full control over the environment.

To avoid detection, attackers are always tweaking their malware by using new methods of obfuscation or concealing backdoors within legitimate-looking images, core files, plugins, or even themes — this can make malicious file uploaders difficult to detect during a casual site review.

Once an attacker has identified a vulnerable environment that they can get a foothold in, planting the uploader is often the next step. After that they have enough access to upload more complicated access points such as a webshell.

Of course there are legitimate uploader scripts, as many websites require functionality to allow users to upload photos or other content to the website. To mitigate risk, secure uploader scripts contain strict rules on how they are able to behave:

  • Only certain file types/extensions are allowed (usually image, or document files)
  • May require authorisation cookies to be set
  • May place files in a restricted directory with PHP execution disabled
  • May disable direct access and instead need to be called by the existing CMS structure

Malicious uploaders, on the other hand, have no such restrictions as they are designed to upload malicious files and PHP scripts.

A malicious uploader script


Webshells are a classic type of malware that have been used by attackers for many years. They are administrative dashboards that give the attacker full access to the files and often provide a large amount of information about the hosting environment including operating system, PHP settings, web server configurations, file management, and SQL connections.

The classic FilesMan shell continues to be very popular with attackers. In 2021 we generated 20 new signatures related to new filesman variants alone, not including hack tools which grab filesman shells from remote servers.

Interestingly, a lot of malicious web shells provide far superior functionality than a lot of file managers provided by web hosting providers.

A malicious web shell backdoor

Misc RCE

Sometimes remote code execution backdoors are a little more complicated, or just rely on more basic/generic $_REQUEST calls. This is a PHP global array that contains the content of GETPOST and COOKIE inputs. The content of these variables could be anything and the attacker can fill them — e.g. with the payload — which is then processed. Sometimes the entire payload code is stored there and only very simple code snippets are injected into legitimate files. Such a snippet only loads and executes the content of these variables.

Other times, RCE backdoors make use of multiple different functions and request types.

A remote code execution backdoor


Not falling into any particular category are our collection of “generic” backdoors. They tend to use a mixture of different functions and methods to maintain backdoor access to the environment. Some are heavily obfuscated and others are mostly in plain text, but what unites them is that they don’t rely on any one technique to backdoor the environment in which they reside.

A generic, malicious backdoor


The PHP function file_get_contents fetches a local file or remote file. As far as backdoors are concerned, attackers misuse this function to grab malicious files located on other websites or servers and add it to the victim’s website. This allows them to host the actual malicious content elsewhere, while maintaining all of the same functionality on the victim environment.

Here we have a very simple backdoor using file_get_contents to grab a backdoor from a malicious server. The actual address is obfuscated through use of a URL shortening service:

A backdoor which uses file_get_contents

The footprint of this malware is very small as the payload resides elsewhere, but the functionality is potentially huge.

Remote Code Execution Backdoors

Not to be confused with remote code execution vulnerabilities, these backdoors are crafted to take whatever command is issued to it by the attacker and execute it in the victim’s environment. These PHP backdoors are often more complex than uploaders and allow the attackers more leeway in terms of how they can interact with the victim website.

If a request is sent that matches the parameters of the backdoor it will execute whichever command the attacker instructs so long as it doesn’t get blocked by any security software or firewall running within the environment.

A remote code execution backdoor

Here’s another example of a quite well hidden RCE backdoor in a Magento environment:

A well-hidden RCE backdoor in a Magento environment

Attackers make heavy use of the eval function which executes the command in the victim environment.


These backdoors utilise the PHP function file_put_contents which will write the instructed content to a file on the victim environment.

Here is an example of such a backdoor lodged in a WordPress configuration file wp-config.php:

A backdoor which uses file_put_contents

This backdoor writes the specified malicious content into the file structure of the victim website given the correct parameters in the attacker’s request, allowing them to infect other files on the server with the content of their choice.


The curl() function facilitates the transmission of data. It can be used maliciously to download remote code which can be executed or directly displayed. This way, malware authors are able to create a small backdoor that only has this curl functionality implemented while the payload itself can be downloaded from a remote source.

It has many uses, and as such can be misused in many ways by attackers. We have seen it used frequently in credit card skimmers to transmit sensitive details to exfiltration destinations. It can also be used in RCE backdoors:

A backdoor which uses CURL

Since the attackers have crafted a backdoor to (mis)use curl, and they control the parameters under which it will function, in this way they are able to send or receive malicious traffic to and from the website, depending on how the backdoor is designed.

Authentication Bypass

These types of backdoors are most often seen in WordPress environments. They are small PHP scripts which allow the attacker to automatically log in to the administrator panel without needing to provide any password.

As long as they include the database configuration file in the script then they are able to set the necessary cookies for authorization, as seen in this example here:

A backdoor which bypasses normal authentication

The existence of such backdoors presents a case that additional authentication requirements should be employed within website environments. Protecting your admin panel with our firewall’s protected page feature is a great way to do this.

If you’re not a user of our firewall there are a lot of other ways that your admin panel can be protected.

Basic RCE via POST

Backdoors that take input through POST requests are quite common and many of the backdoor types that we’ve seen contain such functionality. Some of them, however, are quite small and rely exclusively on POST requests.

The example below shows one such backdoor, coupled with basic password protection to ensure that the backdoor is not used by anybody that does not have access to the password.

A basic remote code execution backdoor which uses POST

Fake Plugins

Another tactic that we’ve seen attackers use is the use of fake plugins. This is frequently used as a payload to deliver spam and malware, since WordPress will load the components present in the ./wp-content/plugins directory.

We’ve also seen attackers use these plugins as backdoors to maintain access to compromised environments.

A fake plugin in a WordPress environment

Since admin panel compromises are a very common attack vector, the usage of fake/malicious backdoor plugins is quite popular with attackers.

System Shell Backdoors

Attackers have also written malware that interacts with the hosting environment itself and will attempt to run shell commands via PHP scripts in the environment. This is not always possible, depending on the security settings of the environment, but here’s an example of one such backdoor:

A system shell backdoor

If system() is disabled in the environment then these will not work, so the functionality of such backdoors will be limited by the security settings in the host.

COOKIE Based Backdoors

Some malware creators use COOKIES as a storage for various data. These can be decryption keys  used to decode an otherwise inaccessible payload, or even the entire malicious payload itself.

A cookie based backdoor


The create_function() is often used by malware instead of (or in conjunction with) the eval() function to hide the execution of the malicious code. The payload is encapsulated inside the crafted custom function, often with an obfuscated name to make the functionality less clear.

This function is then called somewhere else within the code, and thus the payload is evaluated. Backdoors have been found to abuse this to place their payload back on the infected website after it was removed.

A backdoor which creates a malicious function in the victim environment


Backdoors have also been seen using GET requests for input, rather than POST requests. In the example below we can see that the backdoor will execute the malicious payload if a GET request contains a certain string.

A remote code execution backdoor which uses GET

This allows the attackers to restrict the usage of the backdoor to only those who know the exact parameters to specify in the malicious GET request to the website. If the correct parameters are given then the backdoor will execute its intended function.

Database Management Backdoors

Most often attackers will misuse tools such as Adminer to insert malicious content into the victim website’s database, but occasionally we have seen them craft their own database management tools. This allows them to insert admin users into the website as well as inject malicious JavaScript into the website content to redirect users to spam or scam websites or steal credit card information from eCommerce environments.

A database management backdoor

Conclusion & Mitigation Steps

Backdoors play a crucial role for the attackers in a huge number of website compromises. Once the attackers are able to gain a foothold into an environment their goal is to escalate the level of access they have as much as possible. Certain vulnerabilities will provide them access only to certain directories. For example, a subdirectory of the wp-content/uploads area of the file structure.

Often the first thing they will do is place a malicious uploader or webshell into the environment, giving them full control over the rest of the website files. Once that is established they are able to deliver a payload of their choosing.

If default configurations are in place in a standard WordPress/cPanel/WHM configuration a single compromised admin user on a single website can cause the entire environment to be infected. Attackers can move laterally throughout the environment by the use of symlinks even if the file permissions/ownership are configured correctly.

Malicious actors are writing new code daily to try to evade existing security detections. As security analysts and researchers it’s our job to stay on top of the most recent threats and ensure that our tools and monitoring detect it all.

Throughout the year 2021 we added hundreds of new signatures for newly discovered backdoors. I expect we’ll also be adding hundreds more this year.

If you’d like us to help you monitor and secure your website from backdoors and other threats you can sign up for our platform-agnostic website security services.

Source :

NIST Releases Updated Cybersecurity Guidance for Managing Supply Chain Risks

The National Institute of Standards and Technology (NIST) on Thursday released an updated cybersecurity guidance for managing risks in the supply chain, as it increasingly emerges as a lucrative attack vector.

“It encourages organizations to consider the vulnerabilities not only of a finished product they are considering using, but also of its components — which may have been developed elsewhere — and the journey those components took to reach their destination,” NIST said in a statement.

The new directive outlines major security controls and practices that entities should adopt to identify, assess, and respond to risks at different stages of the supply chain, including the possibility of malicious functionality, flaws in third-party software, insertion of counterfeit hardware, and poor manufacturing and development practices.

Software Supply Chain Risks

The development follows an Executive Order issued by the U.S. President on “Improving the Nation’s Cybersecurity (14028)” last May, requiring government agencies to take steps to “improve the security and integrity of the software supply chain, with a priority on addressing critical software.”

Supply Chain Risks

It also comes as cybersecurity risks in the supply chain have come to the forefront in recent years, in part compounded by a wave of attacks targeting widely-used software to breach dozens of downstream vendors all at once.

According to the European Union Agency for Cybersecurity’s (ENISA) Threat Landscape for Supply Chain Attacks, 62% of 24 attacks documented from January 2020 to early 2021 were found to “exploit the trust of customers in their supplier.”

“Managing the cybersecurity of the supply chain is a need that is here to stay,” said NIST’s Jon Boyens and one of the publication’s authors. “If your agency or organization hasn’t started on it, this is a comprehensive tool that can take you from crawl to walk to run, and it can help you do so immediately.”

Source :

5 benefits of integrating corporate SIEM systems

A company can accumulate massive amounts of information that security analysts are not able to monitor instantly. This can mean that priority security alerts either go unnoticed or are considered a false alarm because the appropriate technology is not available, which results in organizations failing to take action in time.  

A Security Information and Event Management (SIEM) system specializes in prioritizing critical alerts over information received in real time, thus adapting to the needs of all organizations. This is achieved by incorporating multiple intelligence feeds and logs according to the criteria and needs set by the IT department. This makes it possible to categorize events and contextualize cybersecurity threat alerts. 

The main benefits of having corporate SIEM systems are as follows:  

  • A SIEM system ensures that alerts reach the right people so that they can carry out contextualized research and apply remediation mechanisms. This saves time as analysts are not required to interpret data from so many different sources. 
  • It reduces the company’s costs, both in terms of infrastructure – by gaining full visibility into how the systems accessing the network are using it – and in terms of consuming resources. For example, a SIEM system can analyze the bandwidth machines are using and generate an event warning if one of them is consuming more resources than it should, which the IT department then checks for anomalies. SIEM enables better management of security resources, which translates into cost savings.  
  • It restores cybersecurity configurations if they have been changed by mistake, which could leave an organization dangerously exposed to threats. SIEM can automatically detect a change in the configuration and generate an event to alert the company’s security analyst, who reviews the change and can restore the previous configuration if the new one is potentially hazardous to the company. 
  • It detects operational maintenance activities in the business infrastructure that could pose a risk to the organization. Cybersecurity administrators incorporate the function of creating an event before a change to the company’s maintenance activities log, as well as in Windows. Then if there is any malicious activity they can decide whether or not to validate these adjustments. 
  • It provides cyberattack control and protection in order to act before it becomes an irreversible problem, filtering whether it is a real attack or a false alarm. Known or unknown attacks are analyzed whether they are malwareless attacks (which resort to the legitimate tools of the system itself) or DDoS attacks or advanced persistent threats (APTs). 

In the case of malware attacks, the usual security logs can send alerts for both real attacks and false alarms. To avoid alert saturation, SIEM solutions use event correlation to determine accurately whether or not it is a malware attack, as well as to detect the potential access points for the attack.  

In DDoS attacks, SIEM is able to flag such an event from web traffic logs, prioritizing the event and sending it to an analyst for investigation before causing a slowdown or a total company service outage. 

Finally, due to their complexity, when advanced persistent threats are detected they may not trigger alerts or be considered false alarms. Having a SIEM solution helps demonstrate a pattern of anomalous behavior, flagging it as a real concern for security analysts to investigate. 

Given the differentiating value of this solution, WatchGuard has incorporated its SIEMFeeder module into WatchGuard EDR and EDPR to collect and correlate the status of IT systems, enabling organizations to turn large volumes of data into useful information for decision making. 

Source :

Top 5 Findings from the Global 2022 Cybersecurity Skills Gap Report

Closing the cybersecurity skills gap has been a topic of interest for a number of years with many organizations reporting on its slow decline. According to (ISC)2’s 2021 Cyber Workforce Report, the global cybersecurity workforce needs to grow 65 percent to effectively defend organizations’ critical assets. While the number of professionals needed to fill the gap has decreased from 3.12 million down to 2.72 million in the past year, this is still a significant void that leaves organizations vulnerable.

There is a lot to be learned from the skills gap. Today, Fortinet released the 2022 Cybersecurity Skills Gap Global Research Report that uncovers the impact the skills gap is having on organizations around the world. From the survey’s findings, five top themes have emerged:

  1. Cybersecurity affects every organization
  2. Recruitment and retention of talent is a problem
  3. Organizations are looking for individuals with certified skills
  4. Organizations are looking for more diversity
  5. Raising cybersecurity awareness remains a key challenge

The survey was conducted in January and February of 2022 and included more than 1200 IT and cybersecurity decision-makers from 29 different locations. There was an even split between the respondents in four regions: North America, EMEA, APAC and LATAM.

How Cybersecurity and the Skills Gap Affects Every Organization

A staggering 80% of organizations experienced at least one breach during the last 12 months that they could attribute to a lack of cybersecurity skills and/or awareness. Almost 20% suffered five or more breaches.Bar graph showing the number of breaches in the last 12 monthsNumber of breaches in the last 12 months

If that weren’t enough, 64% of organizations experienced breaches that resulted in lost revenue and/or cost them fines. Of those, 38% reported breaches that cost them more than a million dollars (USD).

How is the Skills Gap Creating Cyber Risk?

According to the survey respondents, a key factor contributing to the breaches is that organizations struggle to find and retain certified cybersecurity people. 67% of global leader respondents indicate that the skills shortage creates additional cyber risks for their organization.

Recruitment and Retention Are Key Challenges Causing the Skills Gap

Organizations need qualified cybersecurity professionals now more than ever, which is why 76% of organizations indicate that their board of directors now recommend increases in IT and cybersecurity headcount.Pie graph showing Board members who recommend increases in IT and cybersecurity headcount.Board members who recommend increases in IT and cybersecurity headcount

Most would hope that increasing hiring could be an easy fix to this problem, however, 60% of organizations indicated that they struggle to recruit cybersecurity talent and 52% struggle to retain it.

Another key challenge for recruitment is the that organizations need to hire people for a broad range of security and IT network-related roles and specializations. Cloud security specialist and security operations (SOC) analysts remain among the most sought-after roles in cybersecurity, followed closely by security administrators and architects. But organizations aren’t just looking to ramp up hires arbitrarily. They’re deliberately trying to build teams of specialized talent who are equipped to handle an increasingly complex threat landscape.

Finding Qualified People is a Challenge for the Skills Gap

Globally, 50% of organizations seek cloud security specialists, a priority that’s likely informed by how rapidly companies moved their operations to the cloud during the pandemic.

The challenge is finding the right people.Graph showing what roles organizations are looking to fillWhat roles are organizations looking for?

What Skills Are Needed to Work in Cybersecurity? 

Central to the challenge of recruiting and retaining cybersecurity talent is the importance of certification. Certified professionals are universally sought after with 95% of decision-makers sharing that technology-focused certifications positively impact both their role and their team. 

Organizations Are Looking for Certified Skills

As such, 81% of leaders prefer to hire people with certifications.

However, 78% indicate it’s hard to find certified people. This may contribute to the fact that globally 91% of organizations say they are willing to pay for an employee to achieve a cybersecurity certification.Graphs showing 91% of organizations would pay for an employee to get a cybersecurity certificationOrganizations would pay for an employee to get a cybersecurity certification

The preference to hire certified people may be because organization leaders followed that same path themselves:

  • 86% of decision-makers report having earned technology-focused certifications
  • 88% report having other people with certificates on their team

Certification is an Opportunity Given the Skills Gap

It should also be noted from above that global leaders attributed the struggle to find and retain certified cybersecurity people as a key factor contributing to breaches. This also may influence an organization’s hiring strategy with a tendency to lean towards professionals with corresponding certifications to the positions they are attempting to fill.

Closing the Cybersecurity Skills Gap by Prioritizing Diversity

The challenge isn’t just hiring more people, but also building more capable and more diverse teams. While enterprises need qualified talent for a range of different roles, 89% of global companies also have explicit diversity goals as part of their hiring plan.

7 out of 10 leaders worldwide say hiring women and new graduates are among their top three challenges. 61% say hiring minorities is also a top three challenge.

Despite the challenges, or perhaps because of it, three out of four organizations implemented formal processes to hire more women, and nine out of 10 actively engaged women and new graduates during the last three years. 59% of companies have structures in place to hire minorities, and 51% for hiring more veterans.Graph showing hiring from populations like news graduates, women, minorities and veterans is a top three challenge for organizationsHiring from these populations is a top three challenge for organizations

Raising Cybersecurity Awareness to Close the Skills Gap

Even though the recruitment, retention, and certification of a cybersecurity team is vital, companies cannot realistically protect themselves until they also raise the cyber awareness of all employees. That requires ensuring that all employees, at all levels and all roles within the organization, have the knowledge and awareness to protect themselves and their organization’s data. Until they do, breaches will always be likely.

87% of organizations implemented a training program to increase cyber awareness. However, 52% of leaders continue to believe their employees still lack the necessary knowledge. This raises the question of the effectiveness of the programs that organizations currently have in place. Pie graph showing percentage that agreed (52%) and disagreed (48%) with: Employees lack knowledge when it comes to cybersecurity awarenessEmployees lack knowledge when it comes to cybersecurity awareness

For those that don’t have a program in place, 66% report they are currently looking for a program that would suit their needs. 

The Power of People Can Help Close the Skills Gap

Cybersecurity can sometimes feel like a purely technological domain. But when you look past the technology that organizations rely on, cybersecurity is all about how well your employees work together to protect the organization.

Fortunately, organizations are making deliberate efforts to improve on all these fronts. However, it is imperative to remember that the cyber battle isn’t won on any one front. Cybersecurity requires an entire system of people and technology working together to protect an organization.

That starts with people who are empowered, qualified, and certified to protect the organization.

Source :