Category: OpenDns

IT threat evolution Q2 2022

Targeted attacks

New technique for installing fileless malware

Earlier this year, we discovered a malicious campaign that employed a new technique for installing fileless malware on target machines by injecting a shellcode directly into Windows event logs. The attackers were using this to hide a last-stage Trojan in the file system.

The attack starts by driving targets to a legitimate website and tricking them into downloading a compressed RAR file that is booby-trapped with the network penetration testing tools Cobalt Strike and SilentBreak. The attackers use these tools to inject code into any process of their choosing. They inject the malware directly into the system memory, leaving no artifacts on the local drive that might alert traditional signature-based security and forensics tools. While fileless malware is nothing new, the way the encrypted shellcode containing the malicious payload is embedded into Windows event logs is.

The code is unique, with no similarities to known malware, so it is unclear who is behind the attack.

WinDealer’s man-on-the-side spyware

We recently published our analysis of WinDealer: malware developed by the LuoYu APT threat actor. One of the most interesting aspects of this campaign is the group’s use of a man-on-the-side attack to deliver malware and control compromised computers. A man-on-the-side attack implies that the attacker is able to control the communication channel, allowing them to read the traffic and inject arbitrary messages into normal data exchange. In the case of WinDealer, the attackers intercepted an update request from completely legitimate software and swapped the update file with a weaponized one.

Observed WinDealer infection flow

The malware does not contain the exact address of the C2 (command-and-control) server, making it harder for security researchers to find it. Instead, it tries to access a random IP address from a predefined range. The attackers then intercept the request and respond to it. To do this, they need constant access to the routers of the entire subnet, or to some advanced tools at ISP level.

Geographic distribution of WinDealer victims

The vast majority of WinDealer’s targets are located in China: foreign diplomatic organizations, members of the academic community, or companies active in the defense, logistics or telecoms sectors. Sometimes, though, the LuoYu APT group will infect targets in other countries: Austria, the Czech Republic, Germany, India, Russia and the US. In recent months, they have also become more interested in businesses located in other East Asian countries and their China-based offices.

ToddyCat: previously unknown threat actor attacks high-profile organizations in Europe and Asia

In June, we published our analysis of ToddyCat, a relatively new APT threat actor that we have not been able to link to any other known actors. The first wave of attacks, against a limited number of servers in Taiwan and Vietnam, targeted Microsoft Exchange servers, which the threat actor compromised with Samurai, a sophisticated passive backdoor that typically works via ports 80 and 443. The malware allows arbitrary C# code execution and is used alongside multiple modules that let the attacker administer the remote system and move laterally within the targeted network. In certain cases, the attackers have used the Samurai backdoor to launch another sophisticated malicious program, which we dubbed Ninja. This is probably a component of an unknown post-exploitation toolkit exclusively used by ToddyCat.

The next wave saw a sudden surge in attacks, as the threat actor began abusing the ProxyLogon vulnerability to target organizations in multiple countries, including Iran, India, Malaysia, Slovakia, Russia and the UK.

Subsequently, we observed other variants and campaigns, which we attributed to the same group. In addition to affecting most of the previously mentioned countries, the threat actor targeted military and government organizations in Indonesia, Uzbekistan and Kyrgyzstan. The attack surface in the third wave was extended to desktop systems.

SessionManager IIS backdoor

In 2021, we observed a trend among certain threat actors for deploying a backdoor within IIS after exploiting one of the ProxyLogon-type vulnerabilities in Microsoft Exchange. Dropping an IIS module as a backdoor enables threat actors to maintain persistent, update-resistant and relatively stealthy access to the IT infrastructure of a target organization — to collect emails, update further malicious access or clandestinely manage compromised servers.

We published our analysis of one such IIS backdoor, called Owowa, last year. Early this year, we investigated another, SessionManager. Developed in C++, SessionManager is a malicious native-code IIS module. The attackers’ aim is for it to be loaded by some IIS applications, to process legitimate HTTP requests that are continuously sent to the server. This kind of malicious modules usually expects seemingly legitimate but specifically crafted HTTP requests from their operators, triggers actions based on the operators’ hidden instructions and then transparently passes the request to the server for it to be processed just as any other request.

Figure 1. Malicious IIS module processing requests

As a result, these modules are not easily spotted through common monitoring practices.

SessionManager has been used to target NGOs and government organizations in Africa, South America, Asia, Europe and the Middle East.

We believe that this malicious IIS module may have been used by the GELSEMIUM threat actor, because of similar victim profiles and the use of a common OwlProxy variant.

Other malware

Spring4Shell

Late in March, researchers discovered a critical vulnerability (CVE-2022-22965) in Spring, an open-source framework for the Java platform. This is a Remote Code Execution (RCE) vulnerability, allowing an attacker to execute malicious code remotely on an unpatched computer. The vulnerability affects the Spring MVC and Spring WebFlux applications running under version 9 or later of the Java Development Kit. By analogy with the well-known Log4Shell vulnerability, this one was dubbed “Spring4Shell”.

By the time researchers had reported it to VMware, a proof-of-concept exploit had already appeared on GitHub. It was quickly removed, but it is unlikely that cybercriminals would have failed to notice such a potentially dangerous vulnerability.

You can find more details, including appropriate mitigation steps, in our blog post.

Actively exploited vulnerability in Windows

Among the vulnerabilities fixed in May’s “Patch Tuesday” update was one that has been actively exploited in the wild. The Windows LSA (Local Security Authority) Spoofing Vulnerability (CVE-2022-26925) is not considered critical per se. However, when the vulnerability is used in a New Technology LAN Manager (NTLM) relay attack, the combined CVSSv3 score for the attack-chain is 9.8. The vulnerability, which allows an unauthenticated attacker to force domain controllers to authenticate with an attacker’s server using NTLM, was already being exploited in the wild as a zero-day, making it a priority to patch it.

Follina vulnerability in MSDT

At the end of May, researchers with the nao_sec team reported a new zero-day vulnerability in MSDT (the Microsoft Support Diagnostic Tool) that can be exploited using a malicious Microsoft Office document. The vulnerability, which has been designated as CVE-2022-30190 and has also been dubbed “Follina”, affects all operating systems in the Windows family, both for desktops and servers.

MSDT is used to collect diagnostic information and send it to Microsoft when something goes wrong with Windows. It can be called up from other applications via the special MSDT URL protocol; and an attacker can run arbitrary code with the privileges of the application that called up the MSD: in this case, the permissions of the user who opened the malicious document.

Kaspersky has observed attempts to exploit this vulnerability in the wild; and we would expect to see more in the future, including ransomware attacks and data breaches.

BlackCat: a new ransomware gang

It was only a matter of time before another ransomware group filled the gap left by REvil and BlackMatter shutting down operations. Last December, advertisements for the services of the ALPHV group, also known as BlackCat, appeared on hacker forums, claiming that the group had learned from the errors of their predecessors and created an improved version of the malware.

The BlackCat creators use the ransomware-as-a-service (RaaS) model. They provide other attackers with access to their infrastructure and malicious code in exchange for a cut of the ransom. BlackCat gang members are probably also responsible for negotiating with victims. This is one reason why BlackCat has gained momentum so quickly: all that a “franchisee” has to do is obtain access to the target network.

The group’s arsenal comprises several elements. One is the cryptor. This is written in the Rust language, allowing the attackers to create a cross-platform tool with versions of the malware that work both in Windows and Linux environments. Another is the Fendr utility (also known as ExMatter), used to exfiltrate data from the infected infrastructure. The use of this tool suggests that BlackCat may simply be a re-branding of the BlackMatter faction, since that was the only known gang to use the tool. Other tools include the PsExec tool, used for lateral movement on the victim’s network; Mimikatz, the well-known hacker software; and the Nirsoft software, used to extract network passwords.

Yanluowang ransomware: how to recover encrypted files

The name Yanluowang is a reference to the Chinese deity Yanluo Wang, one of the Ten Kings of Hell. This ransomware is relatively recent. We do not know much about the victims, although data from the Kaspersky Security Network indicates that threat actor has carried out attacks in the US, Brazil, Turkey and a few other countries.

The low number of infections is due to the targeted nature of the ransomware: the threat actor prepares and implements attacks on specific companies only.

Our experts have discovered a vulnerability that allows files to be recovered without the attackers’ key — although only under certain conditions — with the help of a known-plaintext attack. This method overcomes the encryption algorithm if two versions of the same text are available: one clean and one encrypted. If the victim has clean copies of some of the encrypted files, our upgraded Rannoh Decryptor can analyze these and recover the rest of the information.

There is one snag: Yanluowang corrupts files slightly differently depending on their size. It encrypts small (less than 3 GB) files completely, and large ones, partially. So, the decryption requires clean files of different sizes. For files smaller than 3 GB, it is enough to have the original and an encrypted version of the file that are 1024 bytes or more. To recover files larger than 3 GB, however, you need original files of the appropriate size. However, if you find a clean file larger than 3 GB, it will generally be possible to recover both large and small files.

Ransomware TTPs

In June, we carried out an in-depth analysis of the TTPs (tactics, techniques and procedures) (TTPs) of the eight most widespread ransomware families: Conti/Ryuk, Pysa, Clop, Hive, Lockbit2.0, RagnarLocker, BlackByte and BlackCat. Our aim was to help those tasked with defending corporate systems to understand how ransomware groups operate and how to protect against their attacks.

The report includes the following:

  • The TTPs of eight modern ransomware groups.
  • A description of how various groups share more than half of their components and TTPs, with the core attack stages executed identically across groups.
  • A cyber-kill chain diagram that combines the visible intersections and common elements of the selected ransomware groups and makes it possible to predict the threat actors’ next steps.
  • A detailed analysis of each technique with examples of how various groups use them, and a comprehensive list of mitigations.
  • SIGMA rules based on the described TTPs that can be applied to SIEM solutions.

Ahead of the Anti-Ransomware Day on May 12, we took the opportunity to outline the tendencies that have characterized ransomware in 2022. In our report, we highlight several trends that we have observed.

First, we are seeing more widespread development of cross-platform ransomware, as cybercriminals seek to penetrate complex environments running a variety of systems. By using cross-platform languages such as Rust and Golang, attackers are able to port their code, which allows them to encrypt data on more computers.

Second, ransomware gangs continue to industrialize and evolve into real businesses by adopting the techniques and processes used by legitimate software companies.

Third, the developers of ransomware are adopting a political stance, involving themselves in the conflict between Russia and Ukraine.

Finally, we offer best practices that organizations should adopt to help them defend against ransomware attacks:

  • Keep software updated on all your devices.
  • Focus your defense strategy on detecting lateral movements and data exfiltration.
  • Enable ransomware protection for all endpoints.
  • Install anti-APT and EDR solutions, enabling capabilities for advanced threat discovery and detection, investigation and timely remediation of incidents.
  • Provide your SOC team with access to the latest threat intelligence.

Emotet’s return

Emotet has been around for eight years. When it was first discovered in 2014, its main purpose was stealing banking credentials. Subsequently, the malware underwent numerous transformations to become one of the most powerful botnets ever. Emotet made headlines in January 2021, when its operations were disrupted through the joint efforts of law enforcement agencies in several countries. This kind of “takedowns” does not necessarily lead to the demise of a cybercriminal operation. It took the cybercriminals almost ten months to rebuild the infrastructure, but Emotet did return in November 2021. At that time, the Trickbot malware was used to deliver Emotet, but it is now spreading on its own through malicious spam campaigns.

Recent Emotet protocol analysis and C2 responses suggest that Emotet is now capable of downloading sixteen additional modules. We were able to retrieve ten of these, including two different copies of the spam module, used by Emotet for stealing credentials, passwords, accounts and emails, and to spread spam.

You can read our analysis of these modules, as well as statistics on recent Emotet attacks, here.

Emotet infects both corporate and private computers all around the world. Our telemetry indicates that in the first quarter of 2022, targeted: it mostly targeted users in Italy, Russia, Japan, Mexico, Brazil, Indonesia, India, Vietnam, China, Germany and Malaysia.

Moreover, we have seen a significant growth in the number of users attacked by Emotet.

Mobile subscription Trojans

Trojan subscribers are a well-established method of stealing money from people using Android devices. These Trojans masquerade as useful apps but, once installed, silently subscribe to paid services.

The developers of these Trojans make money through commissions: they get a cut of what the person “spends”. Funds are typically deducted from the cellphone account, although in some cases, these may be debited directly to a bank card. We looked at the most notable examples that we have seen in the last twelve months, belonging to the Jocker, MobOk, Vesub and GriftHorse families.

Normally, someone has to actively subscribe to a service; providers often ask subscribers to enter a one-time code sent via SMS, to counter automated subscription attempts. To sidestep this protection, malware can request permission to access text messages; where they do not obtain this, they can steal confirmation codes from pop-up notifications about incoming messages.

Some Trojans can both steal confirmation codes from texts or notifications, and work around CAPTCHA: another means of protection against automated subscriptions. To recognize the code in the picture, the Trojan sends it to a special CAPTCHA recognition service.

Some malware is distributed through dubious sources under the guise of apps that are banned from official stores, for example, masquerading as apps for downloading content from YouTube or other streaming services, or as an unofficial Android version of GTA5. In addition, they can appear in these same sources as free versions of popular, expensive apps, such as Minecraft.

Other mobile subscription Trojans are less sophisticated. When run for the first time, they ask the user to enter their phone number, seemingly for login purposes. The subscription is issued as soon as they enter their number and click the login button, and the amount is debited to their cellphone account.

Other Trojans employ subscriptions with recurring payments. While this requires consent, the person using the phone might not realize they are signing up for regular automatic payments. Moreover, the first payment is often insignificant, with later charges being noticeably higher.

You can read more about this type of mobile Trojan, along with tips on how to avoid falling victim to it, here.

The threat from stalkerware

Over the last four years, we have published annual reports on the stalkerware situation, in particular using data from the Kaspersky Security Network. This year, our report also included the results of a survey on digital abuse commissioned by Kaspersky and several public organizations.

Stalkerware provides the digital means for a person to secretly monitor someone else’s private life and is often used to facilitate psychological and physical violence against intimate partners. The software is commercially available and can access an array of personal data, including device location, browser history, text messages, social media chats, photos and more. It may be legal to market stalkerware, although its use to monitor someone without their consent is not. Developers of stalkerware benefit from a vague legal framework that still exists in many countries.

In 2021, our data indicated that around 33,000 people had been affected by stalkerware.

The numbers were lower than what we had seen for a few years prior to that. However, it is important to remember that the decrease of 2020 and 2021 occurred during successive COVID-19 lockdowns: that is, during conditions that meant abusers did not need digital tools to monitor and control their partners’ personal lives. It is also important to bear in mind that mobile apps represent only one method used by abusers to track someone — others include tracking devices such as AirTags, laptop applications, webcams, smart home systems and fitness trackers. KSN tracks only the use of mobile apps. Finally, KSN data is taken from mobile devices protected by Kaspersky products: many people do not protect their mobile devices.  The Coalition Against Stalkerware, which brings together members of the IT industry and non-profit companies, believes that the overall number of people affected by this threat might be thirty times higher — that is around a million people!

Stalkerware continues to affect people across the world: in 2021, we observed detections in 185 countries or territories.

Just as in 2020, Russia, Brazil, the US and India were the top four countries with the largest numbers of affected individuals. Interestingly, Mexico had fallen from fifth to ninth place. Algeria, Turkey and Egypt entered the top ten, replacing Italy, the UK and Saudi Arabia, which were no longer in the top ten.

We would recommend the following to reduce your risk of being targeted:

  • Use a unique, complex password on your phone and do not share it with anyone.
  • Try not to leave your phone unattended; and if you have to, lock it.
  • Download apps only from official stores.
  • Protect your mobile device with trustworthy security software and make sure it is able to detect stalkerware.

Remember also that if you discover stalkerware on your phone, dealing with the problem is not as simple as just removing the stalkerware app. This will alert the abuser to the fact that you have become aware of their activities and may precipitate physical abuse. Instead, seek help:  you can find a list or organizations that can provide help and support on the Coalition Against Stalkerware site.

Source :
https://securelist.com/it-threat-evolution-q2-2022/107099/

Threat landscape for industrial automation systems for H1 2022

H1 2022 in numbers

Geography

  • In H1 2022, malicious objects were blocked at least once on 31.8% of ICS computers globally.Percentage of ICS computers on which malicious objects were blocked
  • For the first time in five years of observations, the lowest percentage in the ‎first half of the year was observed in March.‎ During the period from January to March, the percentage of attacked ICS computers decreased by 1.7 p.p.Percentage of ICS computers on which malicious objects were blocked, January – June 2020, 2021, and 2022
  • Among regions, the highest percentage of ICS computers on which malicious objects were blocked was observed in Africa (41.5%). The lowest percentage (12.8%) was recorded in Northern Europe.Percentage of ICS computers on which malicious objects were blocked, in global regions
  • Among countries, the highest percentage of ICS computers on which malicious objects were blocked was recorded in Ethiopia (54.8%) and the lowest (6.8%) in Luxembourg.15 countries and territories with the highest percentage of ICS computers on which malicious objects were blocked, H1 202210 countries and territories with the lowest percentage of ICS computers on which malicious objects were blocked, H1 2022

Threat sources

  • The main sources of threats to computers in the operational technology infrastructure of organizations are internet (16.5%), removable media (3.5%), and email (7.0%).Percentage of ICS computers on which malicious objects from different sources were blocked

Regions

  • Among global regions, Africa ranked highest based on the percentage of ICS computers on which malware was blocked when removable media was connected.Regions ranked by percentage of ICS computers on which malware was blocked when removable media was connected, H1 2022
  • Southern Europe leads the ranking of regions by percentage of ICS computers on which malicious email attachments and phishing links were blocked.Regions ranked by percentage of ICS computers on which malicious email attachments and phishing links were blocked, H1 2022

Industry specifics

  • In the Building Automation industry, the percentage of ICS computers on which malicious email attachments and phishing links were blocked (14.4%) was twice the average value for the entire world (7%).Percentage of ICS computers on which malicious email attachments and phishing links were blocked, in selected industries
  • In the Oil and Gas industry, the percentage of ICS computers on which threats were blocked when removable media was connected (10.4%) was 3 times the average percentage for the entire world (3.5%).Percentage of ICS computers on which threats were blocked when removable media was connected
  • In the Oil and Gas industry, the percentage of ICS computers on which malware was blocked in network folders (1.2%) was twice the world average (0.6%).Percentage of ICS computers on which threats were blocked in network folders

Diversity of malware

  • Malware of different types from 7,219 families was blocked on ICS computers in H1 2022.Percentage of ICS computers on which the activity of malicious objects from different categories was prevented

Ransomware

  • In H1 2022, ransomware was blocked on 0.65% of ICS computers. This is the highest percentage for any six-month reporting period since 2020.Percentage of ICS computers on which ransomware was blocked
  • The highest percentage of ICS computers on which ransomware was blocked was recorded in February (0.27%) and the lowest in March (0.11%). The percentage observed in February was the highest in 2.5 years of observations.Percentage of ICS computers on which ransomware was blocked, January – June 2022
  • East Asia (0.95%) and the Middle East (0.89%) lead the ransomware-based ranking of regions. In the Middle East, the percentage of ICS computers on which ransomware was blocked per six-month reporting period has increased by a factor of 2.5 since 2020.Regions ranked by percentage of ICS computers on which ransomware was blocked, H1 2022
  • Building Automation leads the ranking of industries based on the percentage of ICS computers attacked by ransomware (1%).Percentage of ICS computers on which ransomware was blocked, in selected regions, H1 2022

Malicious documents

  • Malicious documents (MSOffice+PDF) were blocked on 5.5% of ICS computers. This is 2.2 times the percentage recorded in H2 2021. Threat actors distribute malicious documents via phishing emails and actively use such emails as the vector of initial computer infections.Percentage of ICS computers on which malicious documents (MSOffice+PDF) were blocked
  • In the Building Automation industry, the percentage of ICS computers on which malicious office documents were blocked (10.5%) is almost twice the global average.Percentage of ICS computers on which malicious office documents (MSOffice+PDF) were blocked, in selected industries

Spyware

  • Spyware was blocked on 6% of ICS computers. This percentage has been growing since 2020.Percentage of ICS computers on which spyware was blocked
  • Building Automation leads the ranking of industries based on the percentage of ICS computers on which spyware was blocked (12.9%).Percentage of ICS computers on which spyware was blocked, in selected industries

Malware for covert cryptocurrency mining

  • The percentage of ICS computers on which malicious cryptocurrency miners were blocked continued to rise gradually.Percentage of ICS computers on which malicious cryptocurrency miners were blocked
  • Building Automation also leads the ranking of selected industries by percentage of ICS computers on which malicious cryptocurrency miners were blocked.Percentage of ICS computers on which malicious cryptocurrency miners were blocked, in selected industries

The full text of the report has been published on the Kaspersky ICS CERT website.

Source :
https://securelist.com/threat-landscape-for-industrial-automation-systems-for-h1-2022/107373/

Akamai’s Insights on DNS in Q2 2022

by Or Katz and Jim Black
Data analysis by Gal Kochner and Moshe Cohen

Executive summary

  • Akamai researchers have analyzed malicious DNS traffic from millions of devices to determine how corporate and personal devices are interacting with malicious domains, including phishing attacks, malware, ransomware, and command and control (C2).
  • Akamai researchers saw that 12.3% of devices used by home and corporate users communicated at least once to domains associated with malware or ransomware.
  • 63% of those users’ devices communicated with malware or ransomware domains, 32% communicated with phishing domains, and 5% communicated with C2 domains.
  • Digging further into phishing attacks, researchers found that users of financial services and high tech are the most frequent targets of phishing campaigns, with 47% and 36% of the victims, respectively.
  • Consumer accounts are the most affected by phishing, with 80.7% of the attack campaigns.
  • Tracking 290 different phishing toolkits being reused in the wild, and counting the number of distinct days each kit was reused over Q2 2022, shows that 1.9% of the tracked kits were reactivated on at least 72 days. In addition, 49.6% of the kits were reused for at least five days, demonstrating how many users are being revictimized multiple times. This shows how realistic-looking and dangerous these kits can be, even to knowledgeable users. 
  • The most used phishing toolkit in Q2 2022 (Kr3pto, a phishing campaign that targeted banking customers in the United Kingdom, which evades multi-factor authentication [MFA]) was hosted on more than 500 distinct domains.

Introduction

“It’s always DNS.” Although that is a bit of a tongue-in-cheek phrase in our industry, DNS can give us a lot of information about the threat landscape that exists today. By analyzing information from Akamai’s massive infrastructure, we are able to gain some significant insights on how the internet behaves. In this blog, we will explore these insights into traffic patterns, and how they affect people on the other end of the internet connection. 

Akamai traffic insights

Attacks by category

Based on Akamai’s range of visibility across different industries and geographies, we can see that 12.3% of protected devices attempted to reach out to domains that were associated with malware at least once during Q2 2022. This indicates that these devices might have been compromised. On the phishing and C2 front, we can see that 6.2% of devices accessed phishing domains and 0.8% of the devices accessed C2-associated domains. Although these numbers may seem insignificant, the scale here is in the millions of devices. When this is considered, along with the knowledge that C2 is the most malignant of threats, these numbers are not only significant, they’re cardinal.

Comparing 2022 Q2 results with 2022 Q1 results (Figure 1), we can see a minor increase in all categories in Q2. We attribute those increases to seasonal changes that are not associated with a significant change in the threat landscape.

Fig. 1: Devices exposed to threats — Q1 vs. Q2 Fig. 1: Devices exposed to threats — Q1 vs. Q2

In Figure 2, we can see that of the 12.3% potentially compromised devices, 63% were exposed to threats associated with malware activity, 32% with phishing, and 5% with C2. Access to malware-associated domains does not guarantee that these devices were actually compromised, but provides a strong indication of increased potential risk if the threat wasn’t properly mitigated. However, access to C2-associated domains indicates that the device is most likely compromised and is communicating with the C2 server. This can often explain why the incidence of C2 is lower when compared with malware numbers.

Fig. 2: Potentially compromised devices by category Fig. 2: Potentially compromised devices by category

Phishing attack campaigns 

By looking into the brands that are being abused and mimicked by phishing scams in Q2 2022, categorized by brand industry and number of victims, we can see that high tech and financial brands led with 36% and 47%, respectively (Figure 3). These leading phishing industry categories are consistent with Q1 2022 results, in which high tech and financial brands were the leading categories, with 32% and 31%, respectively. 

Fig. 3: Phishing victims and phishing campaigns by abused brands Fig. 3: Phishing victims and phishing campaigns by abused brands

When taking a different view on the phishing landscape–targeted industries by counting the number of attack campaigns being launched over Q2 2022, we can see that high tech and financial brands are still leading, with 36% and 41%, respectively (Figure 3). The correlation between leading targeted brands when it comes to number of attacks and number of victims is evidence that threat actors’ efforts and resources are, unfortunately, effectively working to achieve their desired outcome.

Akamai’s research does not have any visibility into the distribution channels used to deliver the monitored phishing attacks that led to victims clicking on a malicious link and ending up on the phishing landing page. Yet the strong correlation between different brand segments by number of attack campaigns and the number of victims seems to indicate that the volume of attacks is effective and leads to a similar trend in the number of victims. The correlation might also indicate that the distribution channels used have minimal effect on attack outcome, and it is all about the volume of attacks that lead to the desired success rates.

Taking a closer look at phishing attacks by categorization of attack campaigns — consumers vs. business targeted accounts— we can see that consumer attacks are the most dominant, with 80.7% of the attack campaigns (Figure 4). This domination is driven by the massive demand for consumers’ compromised accounts in dark markets that are then used to launch fraud-related second-phase attacks. However, even with only 19.3% of the attack campaigns, attacks against business accounts should not be considered marginal, as these kinds of attacks are usually more targeted and have greater potential for significant damage. Attacks that target business accounts may lead to a company’s network being compromised with malware or ransomware, or to confidential information being leaked. An attack that begins with an employee clicking a link in a phishing email can end up with the business suffering significant financial and reputational damages.

Fig. 4: Phishing targeted accounts — consumers vs. business  Fig. 4: Phishing targeted accounts — consumers vs. business

Phishing toolkits 

Phishing attacks are an extremely common vector that have been used for many years. The potential impacts and risks involved are well-known to most internet users. However, phishing is still a highly relevant and dangerous attack vector that affects thousands of people and businesses daily. Research conducted by Akamai explains some of the reasons for this phenomenon, and focuses on the phishing toolkits and their role in making phishing attacks effective and relevant. 

Phishing toolkits enable rapid and easy creation of fake websites that mimic known brands. Phishing toolkits enable even non–technically gifted scammers to run phishing scams, and in many cases are being used to create distributed and large-scale attack campaigns. The low cost and availability of these toolkits explains the increasing numbers of phishing attacks that have been seen in the past few years. 

According to Akamai’s research that tracked 290 different phishing toolkits being used in the wild, 1.9% of the tracked kits were reused on at least 72 distinct days over Q2 2022 (Figure 5). Further, 49.6% of the kits were reused for at least five days, and when looking into all the tracked kits, we can see that all of them were reused no fewer than three distinct days over Q2 2022.

Fig. 5: Phishing toolkits by number of reused days Q2 2022 Fig. 5: Phishing toolkits by number of reused days Q2 2022

The numbers showing the heavy reuse phenomenon of the observed phishing kits shed some light on the phishing threat landscape and the scale involved, creating an overwhelming challenge to defenders. Behind the reuse of phishing kits are factories and economic forces that drive the phishing landscape. Those forces include developers who create phishing kits that mimic known brands, later to be sold or shared among threat actors to be reused over and over again with very minimal effort.

Further analysis on the most reused kits in Q2 2022, counting the number of different domains used to deliver each kit, shows that the Kr3pto toolkit was the one most frequently used and was associated with more than 500 domains (Figure 6). The tracked kits are labeled by the name of the brand being abused or by a generic name representing the kit developer signature or kit functionality.

In the case of Kr3pto, the actor behind the phishing kit is a developer who builds and sells unique kits that target financial institutions and other brands. In some cases, these kits target financial firms in the United Kingdom, and they bypass MFA. This evidence also shows that this phishing kit that was initially created more than three years ago is still highly active and effective and being used intensively in the wild.

Fig. 6: Top 10 reused phishing toolkits  Fig. 6: Top 10 reused phishing toolkits

The phishing economy is growing, kits are becoming easier to develop and deploy, and the web is full of abandoned, ready-to-be-abused websites and vulnerable servers and services. Criminals capitalize on these weaknesses to establish a foothold that enables them to victimize thousands of people and businesses daily.

The growing industrial nature of phishing kit development and sales (in which new kits are developed and released within hours) and the clear split between creators and users means this threat isn’t going anywhere anytime soon. The threat posed by phishing factories isn’t just focused on the victims who risk having valuable accounts compromised and their personal information sold to criminals — phishing is also a threat to brands and their stakeholders.

The life span of a typical phishing domain is measured in hours, not days. Yet new techniques and developments by the phishing kit creators are expanding these life spans little by little, and it’s enough to keep the victims coming and the phishing economy moving. 

Summary

This type of research is necessary in the fight to keep our customers safer online. We will continue to monitor these threats and report on them to keep the industry informed.

The best way to stay up to date on this and other research pieces from the Akamai team is to follow Akamai Security Research on Twitter.

Source :
https://www.akamai.com/blog/security-research/q2-dns-akamai-insights

Mitigating Log4j Abuse Using Akamai Guardicore Segmentation

Executive summary

A critical remote code-execution vulnerability (CVE-2021-44228) has been publicly disclosed in Log4j, an open-source logging utility that’s used widely in applications, including many utilized by large enterprise organizations.

The vulnerability allows threat actors to exfiltrate information from, and execute malicious code on, systems running applications that utilize the library by manipulating log messages. There already are reports of servers performing internet-wide scans in attempts to locate vulnerable servers, and our threat intelligence teams are seeing attempts to exploit this vulnerability at alarming volumes. Log4j is incorporated into many popular frameworks and many Java applications, making the impact widespread.

Akamai Guardicore Segmentation is well positioned to address this vulnerability in different ways. It’s highly recommended that organizations update Log4j to its latest version- 2.16.0. Due to the rapidly escalating nature of this vulnerability, Akamai teams will continue to develop and deploy mitigation measures in order to support our customers.

As a follow up to Akamai’s recent post we wanted to provide more detail on how organizations can leverage  Akamai Guardicore Segmentation features to help address log4j exposure.

Log4j vulnerability: scope and impact

Log4j is a Java-based open-source logging library. On December 9, 2021, a critical vulnerability involving unauthenticated remote code execution (CVE-2021-44228) in Log4j was reported, causing concern due to how commonly Log4j is used. In addition to being used directly in a large multitude of applications, Log4j is also incorporated into a host of popular frameworks, including Apache Struts2, Apache Solr, Apache Druid, and Apache Flink.

Although Akamai first observed exploit attempts on the Log4j vulnerability on December 9th, following the widespread publication of the incident, we are now seeing evidence suggesting it could have been around for months. Since widespread publication of the vulnerability, we have seen multiple variants seeking to exploit this vulnerability, at a sustained volume of attack traffic at around 2M exploit requests per hour. The speed at which the variants are evolving is unprecedented.

A compromised machine would allow a threat actor to remotely provide a set of commands which Log4j executes. An attacker would have the ability to run arbitrary commands inside a server. This can allow an attacker to compromise a vulnerable system – including those that might be secured deep inside of a network with no direct access to the internet.

Akamai’s security teams have been monitoring attackers attempting to use Log4j in recent days. Other than the increase in attempted exploitation, Akamai researchers are also seeing attackers using a multitude of tools and attack techniques to get vulnerable components to log malicious content, in order to get remote code execution. This is indicative of threat actors’ ability to exploit a new vulnerability, and the worse the vulnerability is, the quicker they will act.

Mitigating Log4j abuse using Akamai Guardicore Segmentation

Customers using Akamai Guardicore Segmentation can leverage its deep, process level visibility to identify vulnerable applications and potential security risks in the environment. They can then use it to enact precise control over network traffic in order to stop attempted attacks on vulnerable systems, without disruptions to normal business operations. 

Guardicore Hunt customers have their environments monitored and investigated continuously by a dedicated team of security researchers. Alerts on security risks and suggested mitigation steps are immediately sent.

If you’d like to hear more about Akamai Guardicore Segmentation, read more or contact us.

What’s under threat: identify vulnerable Java processes and Log4j abuse

In order to protect against potential Log4j abuse, it is necessary to first identify potentially exploitable processes. This requires deep visibility into network traffic at the process level, which is provided by the Reveal and Insight features of Akamai Guardicore Segmentation. Precise visibility into internet connections and traffic at the process level allows us to see clearly what mitigation steps need to be taken, and visibility tools with historical data are pivotal in helping to prevent disruption to business operations.

Identify internet connected Java applications: using Reveal Explore Map, create a map for the previous week, and filter by java applications- such as tomcat, elastic, logstash- and by applications that have connections to/from the internet. Using this map, you can now see which assets are under potential threat. While this won’t yet identify Log4j applications, this can give you an idea of which machines to prioritize in your mitigation process.

Create a historical map to analyze normal communication patterns: using Reveal Explore Map, create a historical map of previous weeks (excluding the time since Log4j was reported) to view and learn normal communication patterns. Use this information to identify legitimate communications, and respond without disrupting the business. For example, a historical map might indicate what network connections exist under normal circumstances, those could be allowed, while other connections blocked or alerted on. Additionally, compare and contrast with a more recent map to identify anomalies.

Use reveal explore map to identify legitimate communications, and respond without disrupting the business.

Identify applications vulnerable to Log4j abuse: in the query section below, use Query 1 with Insight queries to identify assets that are running Java applications which have Log4j jar files in their directories. This query should return all Log4j packages in your environment, allowing you to assess and address any mitigation steps needed. To better prioritize exposed machines, cross reference the information with the Reveal Explore Map described previously.

Note that this query identifies Log4j packages that exist in the Java process current working directory or sub-directories.

Detect potential exploitation attempts in Linux logs: run an Insight query using YARA signature rule (Query 2, provided below in the query section) to search for known Log4j IoCs in the logs of linux machines. This can help you identify whether you’ve been attacked.

Note, a negative result does not necessarily mean that no attack exists, as this is only one of many indicators.

Stopping the attack: using Guardicore Segmentation to block malicious IoCs and attack vectors

It is imperative to be able to take action, once vulnerable applications have been identified. While patching is underway, Akamai Guardicore Segmentation offers a multitude of options for alerting on, stopping and preventing potential attacks. Critically, a solution with detailed and precise control over network communication and traffic is required to be able to surgically block or isolate attack vectors, with minimal to no disruption to normal business functions.

Automatically block IoC’s with Threat Intelligence Firewall (TIFW) and DNS Security: Akamai security teams are working around the clock to identify IPs and Domains used for Log4j exploitation. Customers who have these features turned on can expect a constantly updated list of IoCs to be blocked, preventing Log4j being used to download malicious payloads. Note that TIFW can be set to alert or block, please ensure it’s configured correctly. DNS Security is available from V41 onwards. The IoCs are also available on the Guardicore Threat Intel Repository and Guardicore Reputation Service.

Fully quarantine compromised servers: if compromised machines are identified during your investigation, use Akamai Guardicore Segmentation to isolate attacked/vulnerable servers from the rest of your network. Leverage built-in templates to easily enable deployment of segmentation policy to mitigate attacks.

Block inbound and outbound traffic to vulnerable assets: as a precautionary measure, you may also choose to block traffic to all machines identified with an unpatched version of Log4j, until patching is completed. Using a historical map of network traffic can help you limit the impact on business operations.

Create block rules for outgoing traffic from Java applications to the internet: if necessary, all internet-connected Java applications revealed in previous steps can be blocked from accessing the internet, as an additional precaution, until patching is complete.

Search queries

Query 1: To Identify assets that are running Java applications, which also have a Log4j jar file under their directories, run the following Insight query:

This query identifies assets that are running Java applications, which also have a Log4j jar file under their directories.

Query 2: To detect potential exploitation attempts, run an Insight query using YARA signature rules (our thanks to Florian Roth who published the original rule): 

SELECT path, count FROM yara WHERE path LIKE '/var/log/%%' AND sigrule = "rule EXPL_Log4j_CallBackDomain_IOCs_Dec21_1 {
strings:
$xr1 = /\b(ldap|rmi):\/\/([a-z0-9\.]{1,16}\.bingsearchlib\.com|[a-z0-9\.]{1,40}\.interact\.sh|[0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}):[0-9]{2,5}\/([aZ]|ua|Exploit|callback|[0-9]{10}|http443useragent|http80useragent)\b/
condition:
1 of them
}
rule EXPL_JNDI_Exploit_Patterns_Dec21_1 {
strings:
$ = {22 2F 42 61 73 69 63 2F 43 6F 6D 6D 61 6E 64 2F 42 61 73 65 36 34 2F 22}
$ = {22 2F 42 61 73 69 63 2F 52 65 76 65 72 73 65 53 68 65 6C 6C 2F 22}
$ = {22 2F 42 61 73 69 63 2F 54 6F 6D 63 61 74 4D 65 6D 73 68 65 6C 6C 22}
$ = {22 2F 42 61 73 69 63 2F 4A 65 74 74 79 4D 65 6D 73 68 65 6C 6C 22}
$ = {22 2F 42 61 73 69 63 2F 57 65 62 6C 6F 67 69 63 4D 65 6D 73 68 65 6C 6C 22}
$ = {22 2F 42 61 73 69 63 2F 4A 42 6F 73 73 4D 65 6D 73 68 65 6C 6C 22}
$ = {22 2F 42 61 73 69 63 2F 57 65 62 73 70 68 65 72 65 4D 65 6D 73 68 65 6C 6C 22}
$ = {22 2F 42 61 73 69 63 2F 53 70 72 69 6E 67 4D 65 6D 73 68 65 6C 6C 22}
$ = {22 2F 44 65 73 65 72 69 61 6C 69 7A 61 74 69 6F 6E 2F 55 52 4C 44 4E 53 2F 22}
$ = {22 2F 44 65 73 65 72 69 61 6C 69 7A 61 74 69 6F 6E 2F 43 6F 6D 6D 6F 6E 73 43 6F 6C 6C 65 63 74 69 6F 6E 73 31 2F 44 6E 73 6C 6F 67 2F 22}
$ = {22 2F 44 65 73 65 72 69 61 6C 69 7A 61 74 69 6F 6E 2F 43 6F 6D 6D 6F 6E 73 43 6F 6C 6C 65 63 74 69 6F 6E 73 32 2F 43 6F 6D 6D 61 6E 64 2F 42 61 73 65 36 34 2F 22}
$ = {22 2F 44 65 73 65 72 69 61 6C 69 7A 61 74 69 6F 6E 2F 43 6F 6D 6D 6F 6E 73 42 65 61 6E 75 74 69 6C 73 31 2F 52 65 76 65 72 73 65 53 68 65 6C 6C 2F 22}
$ = {22 2F 44 65 73 65 72 69 61 6C 69 7A 61 74 69 6F 6E 2F 4A 72 65 38 75 32 30 2F 54 6F 6D 63 61 74 4D 65 6D 73 68 65 6C 6C 22}
$ = {22 2F 54 6F 6D 63 61 74 42 79 70 61 73 73 2F 44 6E 73 6C 6F 67 2F 22}
$ = {22 2F 54 6F 6D 63 61 74 42 79 70 61 73 73 2F 43 6F 6D 6D 61 6E 64 2F 22}
$ = {22 2F 54 6F 6D 63 61 74 42 79 70 61 73 73 2F 52 65 76 65 72 73 65 53 68 65 6C 6C 2F 22}
$ = {22 2F 54 6F 6D 63 61 74 42 79 70 61 73 73 2F 54 6F 6D 63 61 74 4D 65 6D 73 68 65 6C 6C 22}
$ = {22 2F 54 6F 6D 63 61 74 42 79 70 61 73 73 2F 53 70 72 69 6E 67 4D 65 6D 73 68 65 6C 6C 22}
$ = {22 2F 47 72 6F 6F 76 79 42 79 70 61 73 73 2F 43 6F 6D 6D 61 6E 64 2F 22}
$ = {22 2F 57 65 62 73 70 68 65 72 65 42 79 70 61 73 73 2F 55 70 6C 6F 61 64 2F 22}
condition:
1 of them
}
rule EXPL_Log4j_CVE_2021_44228_JAVA_Exception_Dec21_1 {
strings:
$xa1 = {22 68 65 61 64 65 72 20 77 69 74 68 20 76 61 6C 75 65 20 6F 66 20 42 61 64 41 74 74 72 69 62 75 74 65 56 61 6C 75 65 45 78 63 65 70 74 69 6F 6E 3A 20 22}
$sa1 = {22 2E 6C 6F 67 34 6A 2E 63 6F 72 65 2E 6E 65 74 2E 4A 6E 64 69 4D 61 6E 61 67 65 72 2E 6C 6F 6F 6B 75 70 28 4A 6E 64 69 4D 61 6E 61 67 65 72 22}
$sa2 = {22 45 72 72 6F 72 20 6C 6F 6F 6B 69 6E 67 20 75 70 20 4A 4E 44 49 20 72 65 73 6F 75 72 63 65 22}
condition:
$xa1 or all of ($sa*)
}
rule EXPL_Log4j_CVE_2021_44228_Dec21_Soft {
strings:
$ = {22 24 7B 6A 6E 64 69 3A 6C 64 61 70 3A 2F 22}
$ = {22 24 7B 6A 6E 64 69 3A 72 6D 69 3A 2F 22}
$ = {22 24 7B 6A 6E 64 69 3A 6C 64 61 70 73 3A 2F 22}
$ = {22 24 7B 6A 6E 64 69 3A 64 6E 73 3A 2F 22}
$ = {22 24 7B 6A 6E 64 69 3A 69 69 6F 70 3A 2F 22}
$ = {22 24 7B 6A 6E 64 69 3A 68 74 74 70 3A 2F 22}
$ = {22 24 7B 6A 6E 64 69 3A 6E 69 73 3A 2F 22}
$ = {22 24 7B 6A 6E 64 69 3A 6E 64 73 3A 2F 22}
$ = {22 24 7B 6A 6E 64 69 3A 63 6F 72 62 61 3A 2F 22}
condition:
1 of them
}
rule EXPL_Log4j_CVE_2021_44228_Dec21_OBFUSC {
strings:
$x1 = {22 24 25 37 42 6A 6E 64 69 3A 22}
$x2 = {22 25 32 35 32 34 25 32 35 37 42 6A 6E 64 69 22}
$x3 = {22 25 32 46 25 32 35 32 35 32 34 25 32 35 32 35 37 42 6A 6E 64 69 25 33 41 22}
$x4 = {22 24 7B 6A 6E 64 69 3A 24 7B 6C 6F 77 65 72 3A 22}
$x5 = {22 24 7B 3A 3A 2D 6A 7D 24 7B 22}
condition:
1 of them
}
rule EXPL_Log4j_CVE_2021_44228_Dec21_Hard {
strings:
$x1 = /\$\{jndi:(ldap|ldaps|rmi|dns|iiop|http|nis|nds|corba):\/[\/]?[a-z-\.0-9]{3,120}:[0-9]{2,5}\/[a-zA-Z\.]{1,32}\}/
$fp1r = /(ldap|rmi|ldaps|dns):\/[\/]?(127\.0\.0\.1|192\.168\.|172\.[1-3][0-9]\.|10\.)/
condition:
$x1 and not 1 of ($fp*)
}
rule SUSP_Base64_Encoded_Exploit_Indicators_Dec21 {
strings:
/* curl -s */
$sa1 = {22 59 33 56 79 62 43 41 74 63 79 22}
$sa2 = {22 4E 31 63 6D 77 67 4C 58 4D 67 22}
$sa3 = {22 6A 64 58 4A 73 49 43 31 7A 49 22}
/* |wget -q -O- */
$sb1 = {22 66 48 64 6E 5A 58 51 67 4C 58 45 67 4C 55 38 74 49 22}
$sb2 = {22 78 33 5A 32 56 30 49 43 31 78 49 43 31 50 4C 53 22}
$sb3 = {22 38 64 32 64 6C 64 43 41 74 63 53 41 74 54 79 30 67 22}
condition:
1 of ($sa*) and 1 of ($sb*)
}
rule SUSP_JDNIExploit_Indicators_Dec21 {
strings:
$xr1 = /(ldap|ldaps|rmi|dns|iiop|http|nis|nds|corba):\/\/[a-zA-Z0-9\.]{7,80}:[0-9]{2,5}\/(Basic\/Command\/Base64|Basic\/ReverseShell|Basic\/TomcatMemshell|Basic\/JBossMemshell|Basic\/WebsphereMemshell|Basic\/SpringMemshell|Basic\/Command|Deserialization\/CommonsCollectionsK|Deserialization\/CommonsBeanutils|Deserialization\/Jre8u20\/TomcatMemshell|Deserialization\/CVE_2020_2555\/WeblogicMemshell|TomcatBypass|GroovyBypass|WebsphereBypass)\//
condition:
filesize < 100MB and $xr1
}
rule SUSP_EXPL_OBFUSC_Dec21_1{
strings:
/* ${lower:X} - single character match */
$ = { 24 7B 6C 6F 77 65 72 3A ?? 7D }
/* ${upper:X} - single character match */
$ = { 24 7B 75 70 70 65 72 3A ?? 7D }
/* URL encoded lower - obfuscation in URL */
$ = {22 24 25 37 62 6C 6F 77 65 72 3A 22}
$ = {22 24 25 37 62 75 70 70 65 72 3A 22}
$ = {22 25 32 34 25 37 62 6A 6E 64 69 3A 22}
$ = {22 24 25 37 42 6C 6F 77 65 72 3A 22}
$ = {22 24 25 37 42 75 70 70 65 72 3A 22}
$ = {22 25 32 34 25 37 42 6A 6E 64 69 3A 22}
condition:
1 of them
}"
AND count > 0 AND path NOT LIKE "/var/log/gc%"
Source :
https://www.akamai.com/blog/security/recommendations-for-log4j-mitigation
Record-Breaking DDoS Attack in Europe
They’re back! 
Or, more accurately, the cybercriminals responsible for July’s record-setting European DDoS attack may have never left. In the weeks following our coverage of the previous incident, the victim (a customer based in Eastern Europe) has been bombarded relentlessly with sophisticated distributed denial-of-service (DDoS) attacks, ultimately paving the way for a new European packets per second (pps) DDoS record.
On Monday, September 12, 2022, Akamai successfully detected and mitigated the now-largest DDoS attack ever launched against a European customer on the Prolexic platform, with attack traffic abruptly spiking to 704.8 Mpps in an aggressive attempt to cripple the organization’s business operations.
Attack breakdown
Adversaries are constantly evolving their techniques, tactics, and procedures to evade detection and maximize disruption, as demonstrated by this ongoing attack campaign. Let’s break down and compare the two record-setting events. 
 July AttackSeptember Attack
Peak pps659.6 Mpps704.8 Mpps
Cumulative Attacks75201
IPs Targeted5121813
VectorUDPUDP
Distribution1 location6 locations
Date of AttackJuly 21, 2022September 12, 2022
Top Scrubbing LocationsHKG, LON, TYOHKG, TYO, LON
Prior to June 2022, this customer only saw attack traffic against its primary data center; however, they recognized the importance of a comprehensive defensive strategy early on, and onboarded their 12 remaining global data centers to the Prolexic platform for peace of mind. This proved highly fortuitous, as the attack campaign expanded unexpectedly, hitting six different global locations, from Europe to North America. These events reflect a growing trend in which adversaries are increasingly hitting deep-reconnaissance targets. 
Attack mitigation
To thwart an attack of this magnitude and complexity, Akamai leveraged a balanced combination of automated and human mitigation: 99.8% of the assault was pre-mitigated thanks to the customer’s proactive defensive posture, a preemptive security measure implemented by the Akamai Security Operations Command Center (SOCC). Remaining attack traffic and follow-up attacks leveraging different vectors were swiftly mitigated by our frontline security responders. In the wake of increasingly sophisticated DDoS attacks worldwide, many businesses struggle with the staffing of internal security resources, and instead look to Akamai’s SOCC to augment and act as an extension of their incident response team.
The attackers’ command and control system had no delay in activating the multidestination attack, which escalated in 60 seconds from 100 to 1,813 IPs active per minute. Those IPs were spread across eight distinct subnets in six distinct locations. An attack this heavily distributed could drown an underprepared security team in alerts, making it difficult to assess the severity and scope of the intrusion, let alone fight the attack. Sean Lyons, Senior Vice President and General Manager of Infrastructure Security says, “Akamai Prolexic’s DDoS specialization culture, focus on customer infrastructure designs and history are rooted in defending the most complex, multifaceted attacks, and our platform is equipped with purpose-built tooling for rapid threat mitigation, even in the ‘fog of war.’ “
Akamai Prolexic’s DDoS specialization culture, focus on customer infrastructure designs and history are rooted in defending the most complex, multifaceted attacks, and our platform is equipped with purpose-built tooling for rapid threat mitigation, even in the ‘fog of war.
Sean Lyons, Senior Vice President and General Manager of Infrastructure Security
Distinct IP Count Per Minute. 
 
Conclusion
Having a proven DDoS mitigation strategy and platform in place is imperative for shielding your business from downtime and disruption. Learn more about Akamai’s industry-leading DDoS solutions and how our advanced attack-fighting capabilities keeps organizations safe from increasingly sophisticated threats. 
Under attack? 
Click here for 24/7 emergency DDoS protection.
Guidance on minimizing DDoS risk
  • Immediately review and implement Cybersecurity and Infrastructure Security Agency (CISA) recommendations. 
  • Review critical subnets and IP spaces, and ensure that they have mitigation controls in place.
  • Deploy DDoS security controls in an always-on mitigation posture as a first layer of defense, to avoid an emergency integration scenario and to reduce the burden on incident responders. If you don’t have a trusted and proven cloud-based provider, get one now. 
  • Proactively pull together a crisis response team and ensure runbooks and incident response plans are up-to-date. For example, do you have a runbook to deal with catastrophic events? Are the contacts within the playbooks updated? A playbook that references outdated tech assets or people who have long left the company isn’t going to help.
For additional information on the steps you can take to protect your organization, please visit the following CISA resources:
Password Security and the Internet of Things (IoT)
The Internet of Things (IoT) is here, and we’re using it for everything from getting instant answers to random trivia questions to screening visitors at the door. According to Gartner, we were expected to use more than 25 billion internet-connected devices by the end of 2021. But as our digital lives have become more convenient, we might not yet have considered the risks involved with using IoT devices.
How can you keep yourself secure in today’s IoT world, where hackers aim to outsmart your smart home? First we’ll look at how hackers infiltrate the IoT, and then we’ll look at what you can do right now to make sure the IoT is working for you – not against you.
How hackers are infiltrating the Internet of Things
While we’ve become comfortable asking voice assistants to give us the weather forecast while we prep our dinners, hackers have been figuring out how to commandeer our IoT devices for cyber attacks. Here are just a few examples of how cyber criminals are already infiltrating the IoT.
Gaining access to and control of your camera
Have you ever seen someone with a sticker covering the camera on their laptop or smartphone? There’s a reason for that. Hackers have been known to gain access to these cameras and spy on people. This has become an even more serious problem in recent years, as people have been relying on videoconferencing to safely connect with friends and family, participate in virtual learning, and attend telehealth appointments during the pandemic. Cameras now often come with an indicator light that lets you know whether they’re being used. It’s a helpful protective measure, but not a failsafe one.
Using voice assistants to obtain sensitive information
According to Statista, 132 million Americans used a digital voice assistant once a month in 2021. Like any IoT gadget, however, they can be vulnerable to attack. According to Ars Technica, academic researchers have discovered that the Amazon Echo can be forced to take commands from itself, which opens the door to major mischief in a smart home. Once an attacker has compromised an Echo, they can use it to unlock doors, make phone calls and unauthorized purchases, and control any smart home appliances that the Echo manages.
Many bad actors prefer the quiet approach, however, slipping in undetected and stealing information. They can piggyback on a voice assistant’s privileged access to a victim’s online accounts or other IoT gadgets and make off with any sensitive information they desire. With the victim being none the wiser, the attackers can use that information to commit identity fraud or stage even more ambitious cyber crimes.
Hacking your network and launching a ransomware attack
Any device that is connected to the internet, whether it’s a smart security system or even a smart fridge, can be used in a cyber attack. Bad actors know that most people aren’t keeping their IoT gadgets’ software up to date in the same way they do their computers and smartphones, so they take advantage of that false sense of security. Once cyber criminals have gained access to an IoT device, they can go after other devices on the same network. (This is because most home networks are designed to trust devices that are already connected to them.) When these malicious actors are ready, they can launch a ransomware attack that brings your entire digital life to a halt – unless you agree to fork over a hefty sum in bitcoin, that is.
Using bots to launch a DDOS attack
Although most people never notice it, hackers can and do infect IoT devices with malware en masse, gaining control over them in the process. Having turned these zombie IoT devices into bots, the hackers then collectively use them to stage what’s called a botnet attack on their target of choice. This form of assault is especially popular for launching distributed denial of service (DDOS) attacks, in which all the bots in a botnet collectively flood a target with network requests until it buckles and goes offline.
How you can keep your Internet of Things gadgets safe from hackers
So how can you protect your IoT devices from these determined hackers? Fortunately, you can take back control by becoming just a little more cyber smart. Here are a few ways to keep your IoT gadgets safe from hackers:
  • Never use the default settings on your IoT devices. Although IoT devices are designed to be plug-and-play so you can start enjoying them right away, their default settings are often not nearly as secure as they should be. With that in mind, set up a unique username and strong password combination before you start using any new IoT technology. While you’re at it, see if there’s an option to encrypt the traffic to and from your IoT device. If there is, turn it on.
  • Keep your IoT software up to date. Chances are, you regularly install the latest software updates on your computer and phone. Hackers are counting on you to leave your IoT gadgets unpatched, running outdated software with vulnerabilities they can exploit, so be sure to keep the software on your IoT devices up to date as well.
  • Practice good password hygiene. We all slip into bad password habits from time to time – it’s only human – but they put our IoT security at risk. With this in mind, avoid re-using passwords and be sure to set unique, strong passwords on each of your IoT devices. Update those passwords from time to time, too. Don’t store your passwords in a browser, and don’t share them via email. A password manager can help you securely store and share your passwords, so hackers never have a chance to snatch them.
  • Use secure, password-protected WiFi. Cyber criminals are notorious for sneaking onto open, insecure WiFi networks. Once they’re connected, they can spy on any internet activity that happens over those networks, steal login credentials, and launch cyber attacks if they feel like it. For this reason, make sure that you and your IoT devices only use secure, password-protected WiFi.
  • Use multi-factor authentication as an extra layer of protection. Multi-factor authentication (MFA), gives you extra security on top of all the other measures we mentioned above. It asks you to provide one more credential, or factor, in addition to a password to confirm you are who you say you are. If you have MFA enabled and a hacker tries to log in as you, you’ll get a notification that a login attempt is in progress. Whenever you have the option to enable MFA on any account or technology, take advantage of it.
Protect your Internet of Things devices with smart password security
The IoT is making our lives incredibly convenient, but that convenience can be a little too seductive at times. It’s easy to forget that smart home devices, harmless-looking and helpful as they are, can be targeted in cyber attacks just like our computers and phones. Hackers are counting on you to leave your IoT gadgets unprotected so they can use them to launch damaging attacks. By following these smart IoT security tips, you can have the best of both worlds, enjoying your smart life and better peace of mind at the same time.
Learn how LastPass Premium helps you strengthen your password security.

Source :
https://blog.lastpass.com/2022/08/password-security-and-the-iot/
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.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 :
https://www.openssl.org/blog/blog/2022/05/13/spectre-meltdown/
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. 
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 :
https://www.microsoft.com/security/blog/2022/05/23/anatomy-of-ddos-amplification-attacks/