Sophos Archives - Page 7 of 8 - Appunti dalla rete

Staying Safe With QR Codes

QR codes link the offline to the online. What started as a way to streamline manufacturing in the automotive industry is now a widespread technology helping connect the physical world to digital content. And as the world embraced remote, no-touch solutions during the Covid pandemic, QR codes became especially popular. QR codes offer convenience and immediacy for businesses and consumers, but cybercriminals also take advantage of them. Here’s what you need to know about QR codes and how to stay safe when using them.

Why QR codes?

Due to their size and structure, the two-dimensional black and white barcodes we call QR codes are very versatile. And since most people carry a smartphone everywhere, they can quickly scan QR codes with their phone’s camera. Moreover, since QR codes are relatively easy to program and accessible for most smartphone users, they can be an effective communication tool.

They also have many uses. For example, QR codes may link to a webpage, start an app or file download, share contact information, initiate a payment, and more. Covid forced businesses to be creative with touchless experiences, and QR codes provide a convenient way to transform a physical touchpoint into a digital interaction. During Covid, QR codes became a popular way to look at restaurant menus, communicate Covid policies, check in for an appointment, and view marketing promotions, among other scenarios.

As a communication tool, QR codes can transmit a lot of information from one person to another, making it easy for someone to take action online and interact further with digital content.

What hackers do with QR codes

QR codes are inherently secure, and no personally identifiable information (PII) is transmitted while you’re scanning them. However, the tricky part about QR codes is that you don’t know what information they contain until you scan them. So just looking at the QR code won’t tell you if it’s entirely trustworthy or not.

For example, cybercriminals may try to replace or sticker over a QR code in a high-traffic, public place. Doing so can trick people into scanning a malicious QR code. Or, hackers might send malicious QR codes digitally by email, text, or social media. The QR code scam might target a specific individual, or cybercriminals may design it to attract as many scans as possible from a large number of people.

Once scanned, a malicious QR code may take you to a phishing website, lead you to install malware on your device, redirect a payment to the wrong account, or otherwise compromise the security of your private information.

In the same way that cybercriminals try to get victims to click phishing links in email or social media, they lure people into scanning a QR code. These bad actors may be after account credentials, financial information, PII, or even company information. With that information, they can steal your identity or money or even break into your employer’s network for more valuable information (in other words, causing a data breach).

QR code best practices for better security

For the most part, QR code best practices mirror the typical security precautions you should take on social media and elsewhere in your digital life. However, there are also a few special precautions to keep in mind regarding QR codes.

Pay attention to context. Where is the code available? What does the code claim to do (e.g., will it send you to a landing page)? Is there someone you can ask to confirm the purpose of the QR code? Did someone send it unprompted? Is it from a business or individual you’ve never heard of? Just like with phishing links, throw it out when in doubt.

Look closely at the code. Some codes may have specific colors or branding to indicate the code’s purpose and destination. Many codes are generic black and white designs, but sometimes there are clues about who made the code.

Check the link before you click. If you scan the QR code and a link appears, double-check it before clicking. Is it a website URL you were expecting? Is it a shortened link that masks the full URL? Is the webpage secure (HTTPS)? Do you see signs of a phishing attack (branding is slightly off, strange URL, misspelled words, etc.)? If it autogenerates an email or text message, who is the recipient and what information is it sending them? If it’s a payment form, who is receiving the payment? Read carefully before taking action.

Practice password security. Passwords and account logins remain one of the top targets of cyber attacks. Stolen credentials give cybercriminals access to valuable personal and financial information. Generate every password for every account with a random password generator, ideally built into a password manager for secure storage and autofill. Following password best practices ensures one stolen password results in minimal damage.

Layer with MFA. Adding multi-factor authentication to logins further protects against phishing attacks that steal passwords. With MFA in place, a hacker still can’t access an account after using a stolen password. By requiring additional login data, MFA can prevent cybercriminals from gaining access to personal or business accounts.

QR codes remain a popular marketing and communication tool. They’re convenient and accessible, so you can expect to encounter them occasionally. Though cyber attacks via QR codes are less common, you should still stay vigilant for signs of phishing and social engineering via QR codes. To prevent and mitigate attacks via QR codes, start by building a solid foundation of digital security with a trusted password manager.

Source :
https://blog.lastpass.com/2022/08/staying-safe-with-qr-codes/

Multiple attackers increase pressure on victims, complicate incident response

Sophos’ latest Active Adversary report explores the issue of organizations being hit multiple times by attackers

Written by Matt Wixey

AUGUST 09, 2022

SECURITY OPERATIONS THREAT RESEARCH ACTIVE ADVERSARY PLAYBOOK BLACKCAT CONTI CRYPTOMINERS FEATURED HIVE IABS KARAKURT LOCKBIT RANSOMWARE SOPHOS X-OPS

There’s a well-worn industry phrase about the probability of a cyberattack: “It’s not a matter of if, but when.” Some of the incidents Sophos recently investigated may force the industry to consider changing this rule-of-thumb: The question is not if, or when – but how many times?

In an issue we highlighted in our Active Adversary Playbook 2022, we’re seeing organizations being hit by multiple attackers. Some attacks take place simultaneously; others are separated by a few days, weeks, or months. Some involve different kinds of malware, or double – even triple – infections of the same type.

Today, Sophos X-Ops is releasing our latest Active Adversary white paper: Multiple Attackers: A Clear and Present Danger. In the paper, we take a deep dive into the problem of multiple attackers, exploring how and why organizations are attacked several times. Recent case studies from our Managed Detection and Response (MDR) and Rapid Response (RR) teams provide insight into the how, and exploring cooperation and competition among threat actors helps explain the why.

Our key findings are:

The key drivers of multiple exploitations are vulnerabilities and misconfigurations going unaddressed after a first attack
Multiple attacks often involve a specific sequence of exploitation, especially after big, widespread vulnerabilities like ProxyLogon/ProxyShell are disclosed – with cryptominers arriving first, followed by wormable botnet builders, RATs, initial access brokers (IABs), and ransomware
While some threat actors are interdependent (e.g., IABs later enabling ransomware), others, such as cryptominers, try to terminate rival malware, and may even ‘close the door’ by patching vulnerabilities or disabling vulnerable services after gaining access
Historically, threat actors have been protective of their infections, to the extent of kicking rivals off compromised systems
Ransomware actors, despite occasionally tangling with each other, seem less concerned about competition, and sometimes adopt strategies which directly or indirectly benefit other groups
Certain features of the underground economy may enable multiple attacks – for instance, IABs reselling accesses, and ransomware leak sites providing data that other threat actors can later weaponize
Some of the case studies we analyze include a ransomware actor installing a backdoor which was later abused by a second ransomware group; and an incident where one organization was attacked by three ransomware groups in the space of a few weeks, all using the same misconfigured RDP server to gain access. After the dust had settled, Sophos discovered some files which had been encrypted by all three groups

At this stage there’s only anecdotal evidence to suggest that multiple attacks are on the rise, but, as Sophos’ Director of Incident Response, Peter Mackenzie, notes: “This is something we’re seeing affecting more and more organizations, and it’s likely due to an increasingly crowded market for threat actors, as well as ransomware-as-a-service (RaaS) becoming more professionalized and lowering the bar to entry.”

An infographic summarising the key findings and takeaways from our white paper

Key takeaways for organizations

Multiple attacks not only complicate incident response, but also place additional pressure on victims – whether that’s through more than one ransom demand, or just the sheer technical difficulty of trying to recover from two or more attacks in a short space of time.

In the white paper we provide best practice security guidance, as well as the following eight actionable takeaways to help organizations lower the risk of falling victim to multiple attackers:

Takeaway 1: Update absolutely everything
It sounds simple, but: Update everything. One of our key findings is that cryptominers, and webshells and backdoors deployed by IABs, often come first when a vulnerability has been disclosed, and the latter typically try to operate stealthily – so you might think you’ve avoided an attack, when in fact there’s already malware on your system. That might be compounded (in a subsequent attack) by ransomware. Patching early is the best way to avoid being compromised in the future – but it doesn’t mean you haven’t already been attacked. It’s always worth checking that your organization wasn’t breached prior to patching.

Takeaway 2: Prioritize the worst bugs first
But how can you patch early, and how do you know what to patch? Prioritizing can be a big ask, given how many vulnerabilities are disclosed (18,429 in 2021, more than 50 a day on average, and the greatest number of reported vulnerabilities ever disclosed during a calendar year). So focus on two key elements: 1) critical bugs affecting your specific software stack; and 2) high-profile vulnerabilities that could affect your technology. There are paid services which offer vulnerability intelligence, but there are also free tools which let you set up custom alerts for particular products. Bug Alert is a non-profit service that aims to give early warning of high impact bugs. Monitoring ‘infosec Twitter’ is also recommended, as that’s where many prominent vulnerabilities are discussed when first released. Or you could use CVE Trends, which collates data from several sites to show the most-talked-about vulnerabilities.

Takeaway 3: Mind your configurations
Misconfigurations – and a failure to remediate them after an attack – are a leading cause of multiple exploitations. Cryptominer operators, IABs, and ransomware affiliates always look for exposed RDP and VPN ports, and they’re among the most popular listings on most criminal marketplaces. If you do need remote access and/or management over the internet, put it behind a VPN and/or a zero-trust network access solution that uses MFA as part of its login procedure.

Takeaway 4: Assume other attackers have found your vulnerabilities
Threat actors don’t operate in isolation. IABs might resell or relist their products, and ransomware affiliates may use multiple strains – so one vulnerability or misconfiguration can lead to multiple threat actors seeking to exploit your network.

Takeaway 5: Don’t slow-walk addressing an attack in progress
Being listed on a leak site may attract other, opportunistic threat actors. If you’re unfortunate enough to be hit with a ransomware attack, take immediate action, in conjunction with your security teams and incident response provider(s), to close the initial entry point and assess what data has been leaked, as part of your wider remediation plan.

Takeaway 6: Ransomware plays nicely with ransomware
Many threat actors have traditionally been competitive, to the point of kicking each other off infected systems, and that’s still true today when it comes to cryptominers and some RATs. But ransomware doesn’t seem to follow this trend, and may proceed to encrypt files even if other ransomware groups are on the same network – or operate in a mutually beneficial way, so that one group exfiltrates and the other encrypts.

Takeaway 7: Attackers open new backdoors
Some attackers may introduce further vulnerabilities after gaining access, or create deliberate or unintentional backdoors (including the installation of legitimate software), which a subsequent threat actor can exploit. So while it’s crucial to close off the initial infection vector, it’s also worth considering a) other weaknesses and misconfigurations that could be used to gain access, and b) any new ingress points that may have appeared.

Takeaway 8: Some attackers are worse than others
Not all ransomware strains are equal. Some have capabilities and features that may complicate attempts to respond to and investigate others – another reason to try to avoid becoming a victim of multiple attacks.

Conclusion

In an increasingly crowded and competitive threat environment, the problem of multiple attackers is likely to grow, with more threat actors coming into the mix and exploiting the same targets – either deliberately or unintentionally.

For organizations, this means that rapidly responding to attacks, applying patches, fixing misconfigurations – and checking for backdoors which attackers might have installed prior to any entry points being closed – will become more and more important.

Multiple attackers are bad news for analysts and responders too, complicating incident response, threat intelligence, and security monitoring. In one of the case studies we explore in the report, for example, one ransomware group wiped Windows Event Logs – which not only deleted traces of that group’s activities, but also those of the two ransomware groups which had attacked the network previously. In another case study, one threat actor was likely an affiliate of two separate ransomware groups.

The threat actors themselves –particularly ransomware actors – will at some point have to decide how they feel about cooperation: whether to fully embrace it or become more competitive. Going forward, some groups might deliberately team up, so that one group’s tactics complement another’s. Or we might see ransomware become more like cryptominers – actively searching for, and terminating, rivals on infected hosts. At the moment, however, it’s an uncertain area – one which we hope our report will shed some light on.

Source :
https://news.sophos.com/en-us/2022/08/09/multiple-attackers-increase-pressure-on-victims-complicate-incident-response/

Lockbit, Hive, and BlackCat attack automotive supplier in triple ransomware attack

After gaining access via RDP, all three threat actors encrypted files, in an investigation complicated by event log clearing and backups. 3 attackers, 2 weeks – 1 entry point.

Written by Linda Smith, Rajat Wason, Syed Zaidi

AUGUST 10, 2022

SECURITY OPERATIONS ACTIVE ADVERSARY PLAYBOOK BLACKCAT FEATURED HIVE LOCKBIT RANSOMWARE SOPHOS X-OPS

In May 2022, an automotive supplier was hit with three separate ransomware attacks. All three threat actors abused the same misconfiguration – a firewall rule exposing Remote Desktop Protocol (RDP) on a management server – but used different ransomware strains and tactics.

The first ransomware group, identified as Lockbit, exfiltrated data to the Mega cloud storage service, used Mimikatz to extract passwords, and distributed their ransomware binary using PsExec.

The second group, identified as Hive, used RDP to move laterally, before dropping their ransomware just two hours after the Lockbit threat actor.

A screenshot showing files encrypted five times - twice each by Lockbit and Hive, and once by BlackCat

As the victim restored data from backups, an ALPHV/BlackCat affiliate accessed the network, installed Atera Agent (a legitimate remote access tool) to establish persistence, and exfiltrated data. Two weeks after the Lockbit and Hive attacks, the threat actor distributed their ransomware, and cleared Windows Event Logs. Sophos’ Rapid Response (RR) team investigated, and found several files which had been encrypted multiple times – as many as five in some instances.

Figure 1: Files which had been encrypted five times – twice each by Lockbit and Hive, and once by ALPHV/BlackCat

A timeline showing the attacks by the three ransomware groups

Figure 2: The multi-attacker timeline discovered by Sophos X-Ops

We’ve covered several dual ransomware attacks before – and recently investigated the phenomenon of multiple attacks more generally, as it’s something which appears to be increasingly common – but this is the first incident we’ve seen where three separate ransomware actors used the same point of entry to attack a single organization.

Locks, bees, and cats: The perfect storm

Figure 3: A brief overview of the three ransomware groups that consecutively attacked one organization

While the attacks took place in May, we discovered that a threat actor established an RDP session on the organization’s domain controller, way back in December 2021. This might have been an initial access broker (IAB) – an attacker who finds vulnerable systems and sells access to them on criminal marketplaces – or an early scouting mission by one of the three threat actors.

Either way, in mid-April 2022, a Lockbit affiliate gained RDP access to the organization’s corporate environment through an exposed management server.

Next, the threat actor moved laterally to a domain controller and other hosts, and began exfiltrating data to the Mega cloud storage service, as well as executing two PowerShell scripts: sharefinder.ps1 (to gather information about connected domain network shares) and invoke-mimikatz.ps1 (to extract passwords from LSASS, the Local Security Authority Subsystem Service).

On May 1st, the Lockbit affiliate created two batch scripts (1.bat and 2.bat) to distribute the ransomware binaries LockBit_AF51C0A7004B80EA.exe and Locker.exe across the network, via PsExec.

A screenshot of a batch script, 1.bat, used by the attackers

Figure 4: 1.bat script

A screenshot of a batch script, 2.bat, used by the attackers

Figure 5: 2.bat script

Upon execution, the ransomware encrypted files on nineteen hosts and dropped ransom notes entitled Restore-My-Files.txt.

A ransom note from the Lockbit ransomware group

Figure 6: The Lockbit ransom note

Two hours later, while the Lockbit threat actor was still encrypting files, a Hive ransomware affiliate gained access to the network via the same exposed RDP server and used RDP to move laterally to other hosts.

Hive used legitimate software (PDQ Deploy) already installed on the network to distribute its ransomware binary windows_x32_encrypt.exe. This tactic, known as ‘living off the land’, is popular among threat actors – particularly ransomware actors – as it has a small footprint and is less likely to be detected than downloading malicious tools.

Hive’s ransomware binary encrypted files on sixteen hosts and dropped a further ransom note, HOW_TO_DECRYPT.txt, on impacted devices.

A ransom note from the Hive ransomware group

Figure 7: The Hive ransom note

At this point, the organization’s IT team restored most of the infected systems to April 30, the day before the Lockbit threat actor began to encrypt files. From an investigative perspective, this meant some crucial evidence was lost. But the attacks were not over yet.

Only a day after that system restore, an ALPHV/BlackCat affiliate arrived, making RDP connections to domain controllers, file servers, application servers, and other hosts – all from the same management server exploited by Lockbit and Hive.

The ALPHV/BlackCat threat actor exfiltrated data to Mega over the course of a week, and established persistence by installing a backdoor: a legitimate remote access tool named Atera Agent. On May 15th – two weeks after the Lockbit and Hive attacks – the ALPHV/BlackCat affiliate used the credentials of a compromised user to drop ransomware binaries fXXX.exe and fXXXX.exe on six hosts, leaving a ransom note titled RECOVER-eprzzxl-FILES.txt in every folder.

A ransom note from the ALPHV/BlackCat ransomware group

Figure 8: The ALPHV/BlackCat ransom note

Based on analysis from SophosLabs researchers, these binaries not only encrypted files but also deleted volume shadow copies and Windows Event logs. This further complicated our subsequent investigation, as the ALPHV/BlackCat actor erased not only logs relating to their attack, but also those relating to the attacks by Lockbit and Hive.

It’s not clear why Lockbit and ALPHV/BlackCat deployed two ransomware binaries, but one possible reason is fault tolerance: If one executable is detected or blocked, or fails to encrypt, the second might act as a back-up.

Key features of the BlackCat ransomware binaries

The two BlackCat ransomware binaries, fXXX.exe and fXXXX.exe, have the following functionality:

Encrypt files and add the extension .eprzzxl
Collect Universally Unique IDs (UUIDs) from the impacted devices:

wmic csproduct get UUID

Enable Remote to Local and Remote to Remote symbolic link evaluations that allow easy access to files and folders in remote locations:

fsutil behavior set SymlinkEvaluation R2L:1
fsutil behavior set SymlinkEvaluation R2R:1

Modify a registry key to allow the maximum number of network requests by remote processes:

reg add HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\LanmanServer\Parameters /v MaxMpxCt /d 65535 /t REG_DWORD /f

Delete Volume Shadow copies:

vssadmin.exe Delete Shadows /all /quiet

Disable Windows automatic repair on the impacted device

bcdedit /set {default} recoveryenabled No

Clear Windows Event logs

cmd.exe /c for /F \"tokens=*\" %1 in ('wevtutil.exe el') DO wevtutil.exe cl \"%1\"

The aftermath

After the dust had settled, Sophos’ RR team found files that had been encrypted by all three ransomware groups. In fact, as shown in the screenshot below, some files had even been encrypted five times! Because the Hive attack started 2 hours after Lockbit, the Lockbit ransomware was still running – so both groups kept finding files without the extension signifying that they were encrypted.

A screenshot showing quintuple-encrypted files

Figure 9: An example of quintuple-encrypted files

However, despite all three ransomware groups being known for ‘double extortion’ techniques (where, in addition to encrypting files, threat actors threaten to publish the victim’s data if the ransom is not paid), no information was published on any of the groups’ leak sites.

Several things complicated this investigation. The system restoration, BlackCat’s log-wiping, and a lack of DHCP logging all contrived to make piecing together the attacks extremely difficult. Despite these challenges, Sophos’ Rapid Response team was able to gather and analyze the evidence left behind.

When it comes to defense, there are two elements: proactive (following security best practices to minimize the risk of being attacked), and reactive (how to recover quickly and safely if an attack does happen).

On the proactive side, our white paper on multiple attackers includes several learning points and best-practice guidance, including:

Patch and investigate. Keep Windows and other software up to date (and consider setting up some vulnerability alerts, and monitoring in-the-know sources, to get a head start on breaking news about new bugs). This also means double-checking that patches have been installed correctly and are in place for critical systems like internet-facing machines or domain controllers. Patching early is the best way to avoid being compromised in the future – but it doesn’t mean that you haven’t already been attacked. It’s always worth investigating to ensure that your organization wasn’t breached prior to patching. Threat actors may leave backdoors (which may include the installation of legitimate software) or introduce new vulnerabilities, either deliberately or inadvertently, so this is a key thing for responders to look for to reduce the likelihood of a second attack.
Lock down accessible services. Perform scans of your organization’s network from the outside and identify and lock down the ports commonly used by VNC, RDP, or other remote-access tools. If a machine needs to be reachable using a remote management tool, put that tool behind a VPN or zero-trust network access solution that uses MFA as part of its login. It’s also worth remembering that attacks can happen more than once; if an access point remains open, other threat actors are likely to find and exploit it.
Practice segmentation and zero-trust. Separate critical servers from each other and from workstations by putting them into separate VLANs as you work towards a zero-trust network model.
Set and enforce strong passwords and multifactor authentication (MFA). Strong passwords serve as one of the first lines of defense. Passwords should be unique or complex and never re-used. This is easier to do if you provide staff with a password manager that can store their credentials. But even strong passwords can be compromised. Any form of multifactor authentication is better than none for securing access to critical resources such as e-mail, remote management tools, and network assets.
Inventory your assets and accounts. Unprotected and unpatched devices in the network increase risk and create a situation where malicious activities could pass unnoticed. It is vital to have a current inventory of all connected computers and IoT devices. Use network scans and physical checks to locate and catalog them.
Install layered protection to block attackers at as many points as possible. Extend that security to all endpoints that you allow onto your network.

But once threat actors are inside a network, there’s not much that can be done to ‘stop the bleeding’ without having comprehensive Incident Response and remediation plans, and taking immediate action. We’ve written a series of articles called ‘Hindsight security: Actions breach victims wish they had taken sooner’, which includes advice on securing RDP, enforcing MFA, setting up an incident response plan, and more. You can also request a copy of the Sophos Incident Response Guide here.

IOCs

Sophos X-Ops has posted IOCs relating to the Lockbit, Hive, and BlackCat attacks covered in this report on our Github repository.

Source :
https://news.sophos.com/en-us/2022/08/10/lockbit-hive-and-blackcat-attack-automotive-supplier-in-triple-ransomware-attack/

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 Premium, Wordfence 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)
CVSS Vector: CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
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.

32	`add_action('before_delete_post',` `array($this,` `'deleteFiles'), 10, 2);`

979899100101102103104 functiondeleteFiles($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.

Timeline

July 8, 2022 – Discovery of the Arbitrary File Deletion Vulnerability in the “Download Manager” plugin. A firewall rule is released to Wordfence Premium, Wordfence 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.

Conclusion

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 Premium, Wordfence 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 :
https://www.wordfence.com/blog/2022/08/high-severity-vulnerability-patched-in-download-manager-plugin/

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 :
https://thehackernews.com/2022/07/juniper-releases-patches-for-critical.html

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:

1 — 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.

2 — 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.

3 — 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.

4 — 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.

5 — 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 :
https://thehackernews.com/2022/07/5-key-things-we-learned-from-cisos-of.html

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.¹ 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

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 :
https://www.openssl.org/blog/blog/2022/05/13/spectre-meltdown/

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 :
https://help.altaro.com/hc/en-us/articles/4416905883409-Which

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 :
https://www.wordfence.com/blog/2022/06/securing-port-443/

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.

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.

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.

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.

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:

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

Azure DDoS Protection product page.
Azure DDoS Protection Standard documentation.
Azure DDoS Protection Standard reference architectures.
DDoS Protection best practices.
Azure DDoS Rapid Response.
Protect your on-premises resources.

Amir Dahan and Syed Pasha
Azure Networking Team

Source :
https://www.microsoft.com/security/blog/2022/05/23/anatomy-of-ddos-amplification-attacks/