Gcore Radar is a quarterly report prepared by Gcore that provides insights into the current state of the DDoS protection market and cybersecurity trends. This report offers you an understanding of the evolving threat landscape and highlights the measures required to protect against attacks effectively. It serves as an insight for businesses and individuals seeking to stay informed about the

Gcore Radar is a quarterly report prepared by Gcore that provides insights into the current state of the DDoS protection market and cybersecurity trends. This report offers you an understanding of the evolving threat landscape and highlights the measures required to protect against attacks effectively. It serves as an insight for businesses and individuals seeking to stay informed about the latest developments in cybersecurity.

As we entered 2023, the cybersecurity landscape witnessed an increase in sophisticated, high-volume attacks. Here, we present the current state of the DDoS protection market based on Gcore's statistics.

**Key Highlights from Q1–Q2**

*   The maximum attack power rose from 600 to 800 Gbps.
*   UDP flood attacks were most common and amounted to 52% of total attacks, while SYN flood accounted for 24%. In third place was TCP flood.
*   The most-attacked business sectors are gaming, telecom, and financial.
*   The longest attack duration in the year's first half was seven days, 16 hours, and 22 minutes.
*   Most attacks lasted less than four hours.

**High-Volume Attacks: An Escalating Threat**

There has been a significant increase in the power and volume of DDoS attacks over the last two years:

*   In 2021, the capacity of DDoS attacks was up to 300 Gbps.
*   In 2022, the attack capacity was about 650 Gbps.
*   In Q1–Q2 of 2023, we see a capacity of about 800 Gbps.

Figure 1. Attack intrensity 2021–2023, Gbps

Alt Text: Illustration of attack raising from 300 Gbps in 2021 and 650 Gbps in 2021 to 800 Gbps in 2023

The alarming 50–100% annual increase in DDoS attack volume highlights the growing sophistication of cyber attackers and their utilization of increasingly powerful tools. This means that businesses need to invest in DDoS mitigation strategies and solutions to protect their networks, systems, and customer data. Failure to address these evolving threats can result in costly disruptions, reputational damage, loss of customer trust, and security breaches.

**DDoS Attack Techniques**

According to Gcore's statistics, in Q1–Q2 of 2023:

*   UDP flood became more popular among attackers and is the most common method
*   SYN flood is in second place
*   In third place is TCP flood
*   All other techniques combined accounted for just 5% of attack types

Figure 2. Attack type spread, Q1–Q2 2023

Alt Text: Attack types illustrated: 52% - UDP, 24% - SYN flood, 19% - TCP flood, 5% - other traffic

According to Andrey Slastenov, Head of **Web Security at Gcore**, there has been an increase in the frequency of complex, multi-vector attacks by attackers. Attackers are now employing adaptive strategies, such as combining high-volume UDP attacks with a massive number of TCP packets, and shifting from targeting the application layer with a large amount of traffic to using a high volume of small packets. These changes in tactics indicate a deliberate effort to intensify the DDoS assault by overwhelming the network infrastructure and potentially bypassing mitigation measures. The ultimate goal is to maximize the impact of the attack and disrupt services.

**DDoS Attacks by Business Sector**

DDoS attacks across different business sectors have revealed specific trends and impacts. According to Gcore's report, gaming, telecom, and financial industries were the most attacked sectors in Q1–Q2 of 2023.

Figure 3. Most attacked industries based on Gcore's statistics.

Alt Text: Attack types illustrated: 30.1% - Gaming, 24.7% - Telecom, 16.8% - Financial, 28.4% - Other

The **gaming industry** was the most targeted sector, accounting for a considerable proportion of the DDoS attacks. Gaming platforms, operating in real-time and catering to millions of active users, experience detrimental consequences from even short periods of downtime. Attackers aim to disrupt services, undermine player experiences, and potentially gain a competitive advantage. The financial implications are substantial, with gaming companies often incurring a cost of $25,000 to $40,000 per hour of downtime.

The **telecommunication sector** faces a significant volume of DDoS attacks, affecting internet service providers (ISPs) and other telecom services. These attacks can result in widespread internet outages, impacting not only the telecom companies themselves but also businesses and consumers relying on their services. The disruptive nature of such attacks on critical infrastructure can have far-reaching consequences, disrupting communications and various aspects of daily life and business operations for customers.

The **financial sector**, encompassing banks and financial technology (FinTech) companies, remains constantly threatened by DDoS attacks. The rise in digital banking and online financial services adoption has increased the potential for disruptive attacks that can bring financial operations to a complete halt.

**DDoS Protection from Gcore**

Gcore can protect you from DDoS attacks with protection against threats at L3, L4, and L7 wielding over 1 Tbps of filtering capacity. Its real-time traffic filtering selectively blocks malicious sessions, allowing normal business processes to continue during attacks. All Gcore DDoS Protection servers are equipped with high-performance 3rd generation Intel® Xeon® Scalable processors, enabling fast processing so we can respond to attacks as quickly as possible. Learn **how Gcore repelled** a 650 Gbps attack in January 2023.

Found this article interesting? Follow us on Twitter __ and LinkedIn to read more exclusive content we post.

Surviving the 800 Gbps Storm: Gain Insights from Gcore's 2023 DDoS Attack Statistics

The startup, one of four finalists in Black Hat USA's 2023 startup competition, uses deterministic AI to optimize cloud security.

Cloud misconfigurations are a leading cause of breaches that lead to data loss for the enterprise, especially with the continued shift to cloud and multicloud environments. But surveying and monitoring all possible endpoints and connections with cloud services is too big a job for humans to accomplish alone — which is how such breaches proliferate. Gomboc.ai aims to solve the problem with a proprietary type of deterministic artificial intelligence (AI) that the company says sidesteps the issues with the more well-known generative AI model.

That hook — deterministic AI — earned Gomboc a spot in the finals of the second annual Startup Spotlight, presented by Black Hat USA. "We are solving the cloud security misconfiguration problem," says CEO and co-founder Ian Amit. That would be a huge accomplishment, since such problems cause most cloud breaches.

"Security misconfiguration backlogs are one of the highest priority issues CISOs deal with since they pose an immediate threat to the organization's cloud security posture, and existing solutions that focus on prioritization and ticketing do not provide a scalable way to address those," Amit adds.

**What Is Deterministic AI?**

Generative AI, which includes high-profile models like OpenAI's ChatGPT and Google's Bard, analyzes large collections of data to learn the structures well enough to assemble plausible new content from it — that is, it _generates_ outputs. Deterministic AI, on the other hand, defines data characteristics so that a specific problem will have one specific, correct solution that does not change — that is, the data values _determine_ the outputs.

Amit sees this as one of his company's great differentiators.

"\[W\]hen given the same input, Gomboc will always provide the same output — a crucial factor when writing secure code," he says. "Gomboc does not generate nor hallucinate any sort of IaC."

Generative, or stochastic, AI systems generate code based on statistical analysis, which Amit says can result in code that's inaccurate, imprecise, or bereft of context.

Instead, Gomboc built a proprietary ingestion engine that processes cloud service provider updates as they're released. It then applies the new data to clients' existing network policies, pushing any fixes live itself rather than issuing a ticket for a human to address. The tool works within existing DevSecOps environments, Amit says, keeping approval simple and easy to track.

    

Of course, deterministic AI, aka reactive AI or expert systems, is not an approach exclusive to Gomboc. Other security companies that employ deterministic AI include identity verification service Vouched and life-science compliance firm LighthouseAI. But by focusing on the highly complex and fraught multicloud environment, Gomboc is putting the technology to good use.

**What's Ahead for Gomboc**

The four finalists in the Black Hat Startup Spotlight — Gomboc, Binarly, Endor Labs, and Mobb — will present their business models to a panel of judges at the Mandalay Bay in Las Vegas on Wednesday, Aug. 9. Eligible candidates included companies that are 2 years old or less and have fewer than 50 employees. Dark Reading's editor-in-chief, Kelly Jackson Higgins, will host the event, which begins at 4:30 p.m. PT.

Amit says that his company's future plans include expanding to more environments, especially multicloud and hybrid installations. At the Black Hat USA booth, he promises a product demo and merch, as well as a chance to talk to the team who built the product.

The story of the company name is an interesting one: A gomboc is a geometric solid with exactly two points of equilibrium, one stable and one unstable. That means it will always return to its stable equilibrium point, no matter how it's pushed or rolled.

"Our platform turns everyone's cloud infrastructure into a self-righting environment \[in a security sense\] no matter how a company grows or scales. A Gomboc is a shape that does exactly that: It always rights itself no matter how much you push it," Amit says. "We're big math nerds here at Gomboc, so the shape and analogy have a special place in our hearts."

**Speed Round**

**Website:** https://www.gomboc.ai/  
**Founded:** Late 2022 (Funded in November)  
**Funding stage:** Seed  
**Total funding raised so far:** $5.3M  
**Number of employees:** 10  
**If the company were a band, what would its band name be, and what kind of band would it be:** Ship or Be Shipped (Hard Rock/Metal)  
**Pineapple on pizza, yea or nay?:** "As New Yorkers, it's absolutely nay."

Startup Spotlight: Gomboc.ai Balances Cloud Infrastructure Security

Exposed and unpatched solar power monitoring systems have been exploited by both amateurs and professionals, including Mirai botnet hackers.

Hundreds of solar power monitoring systems are vulnerable to a trio of critical remote code execution (RCE) vulnerabilities. The hackers behind the Mirai botnet and even amateurs have already started taking advantage, and others will follow, experts are predicting.

Palo Alto Networks' Unit 42 researchers previously discovered that the Mirai botnet is spreading through CVE-2022-29303, a command injection flaw in SolarView Series software developed by the manufacturer Contec. According to Contec's website, SolarView has been used in more than 30,000 solar power stations.

On Wednesday, vulnerability intelligence firm VulnCheck pointed out in a blog post that CVE-2022-29303 is one of _three_ critical vulnerabilities in SolarView, and it's more than just the Mirai hackers targeting them.

"The most likely worst-case scenario is losing visibility into the equipment that's being monitored and having something break down," explains Mike Parkin, senior technical engineer at Vulcan Cyber. It's also theoretically possible, though, that "the attacker is able to leverage control of the compromised monitoring system to do greater damage or get deeper into the environment."

**Three Ozone-Sized Holes in SolarView**

CVE-2022-29303 is borne from a particular endpoint in the SolarView Web server, confi\_mail.php, which fails to sufficiently sanitize user input data, enabling the remote malfeasance. In the month it was released, the bug received some attention from security bloggers, researchers, and one YouTuber who showed off the exploit in a still publicly accessible video demonstration. But it was hardly the only problem inside SolarView.

For one thing, there's CVE-2023-23333, an entirely similar command injection vulnerability. This one affects a different endpoint, downloader.php, and was first revealed in February. And there's CVE-2022-44354, published near the end of last year. CVE-2022-44354 is an unrestricted file upload vulnerability affecting yet a third endpoint, enabling attackers to upload PHP Web shells to targeted systems.

VulnCheck noted that these two endpoints, like confi\_mail.php, "appear to generate hits from malicious hosts on GreyNoise meaning that they too are likely under some level of active exploitation."

All three vulnerabilities were assigned "critical" 9.8 (out of 10) CVSS scores.

**How Big of a Cyber Problem Are the SolarView Bugs?**

Only Internet-exposed instances of SolarView are at risk of remote compromise. A quick Shodan search by VulnCheck revealed 615 cases connected to the open Web as of this month.

This, says Parkin, is where the unnecessary headache starts. "Most of these things are designed to be operated _within_ an environment and shouldn't need access from the open Internet under most use cases," he says. Even where remote connectivity is absolutely necessary, there are workarounds that can protect IoT systems from the scary parts of the wider Internet, he adds. "You can put them all on their own virtual local area networks (VLANs) in their own IP address spaces, and restrict access to them to a few specific gateways or applications, etc."

Operators might risk remaining online if, at least, their systems are patched. Remarkably, however, 425 of those Internet-facing SolarView systems — more than two thirds of the total — were running versions of the software lacking the necessary patch.

At least when it comes to critical systems, this may be understandable. "IoT and operational technology devices are often a lot more challenging to update compared to your typical PC or mobile device. It sometimes has management making the choice to accept the risk, rather than take their systems off-line long enough to install security patches," Parkin says.

All three CVEs were patched in SolarView version 8.00.

3 Critical RCE Bugs Threaten Industrial Solar Panels, Endangering Grid Systems

Dark Reading's latest special report looks at a missing, but necessary, ingredient to effective third-party risk management.

When it comes to enterprise risk, third-party cybersecurity risks have increased substantially in recent years. By implementing an effective third-party risk management program, organizations can mitigate much of their risk and better protect themselves from attacks that emanate from third parties. The key word here is "effective."

Dark Reading's latest special report, "How to Use Threat Intelligence to Mitigate Third-Party Risk," digs into how threat intelligence can be implemented to attain a continuous risk assessment on partners, suppliers, vendors, contractors, and other third parties.

Third-party threat intelligence helps security teams move beyond capturing a point-in-time view of security and regulatory compliance maturity and more accurately assess the risk over time. The convergence of threat intelligence and third-party risk management (TPRM) programs can ensure that third parties don't drastically increase the risk of data breaches or other cybersecurity events and, should such an incident occur, can help to minimize its impact.

**How TPRM Is Changing**

Historically, if TPRM was done at all, effective programs included identifying, categorizing, and assessing the risk of third parties, along with due-diligence questionnaires designed to gauge the maturing of their security and regulatory compliance program. Additionally, an enterprise would conduct a thorough independent investigation of vendors before signing any contract. Finally, the organization would include new partners and suppliers in their incident response planning so as to minimize any incident's impact.

"Organizations can send questionnaires, and they're going to provide some indication of the policies they have in place and their certifications," says senior research analyst at Forrester Alla Valente, who covers governance, risk, and compliance (GRC), third-party risk, and supply chain risk. "But that doesn't tell you everything happening inside their networks or systems. It also doesn't provide answers about broader risks, such as geography or if nation-states are targeting that vertical. These are all things you want to identify."

While there is scant data on how enterprises use TPRM threat intelligence to improve their third-party risk management, TPRM programs are gaining steam. In Prevalent's "2022 Third-Party Risk Management Industry Study," two-thirds of respondents reported that their TPRM programs have more visibility among executives and the board than the year before.

Read Dark Reading's "How to Use Threat Intelligence to Mitigate Third-Party Risk" for ideas on reducing third-party risks for your organization by leveraging threat intelligence.

Mitigating Risk With Threat Intelligence

By Deeba Ahmed
The researchers believe that the SmugX attack is an extension of a previously discovered campaign linked to Mustang Panda.
This is a post from HackRead.com Read the original post: SmugX: Chinese Hackers Targeting Embassies in Europe

**The attack method of the SmugX campaign includes attackers using HTML smuggling to target victims.**

Check Point Research’s (CPR) cyber threat intelligence researchers have discovered a disturbing attack trend. According to CPR’s report published on July 3, 2023, Chinese threat actors have become increasingly interested in targeting European governments, embassies, and foreign local policy-making entities. Eastern Europe is among their preferred targets, with prime targets being Slovakia, the Czech Republic, and Hungary.

This newly discovered campaign is dubbed SmugX. Researchers claim that this campaign has been active since December 2022, but they believe that it is an extension of a previously discovered campaign linked to Mustang Panda and RedDelta. Interestingly, both groups are Chinese.

As far as the attack method is concerned, research revealed that in SmugX, attackers are using HTML smuggling to target European embassies. In this method, the modular PlugX malware implant is smuggled (hidden) inside HTML documents.

Hackers use this technique to trick web security systems and evade antivirus mechanisms or security defences. HTML smuggling exploits HTML features to conceal malicious data documents from automated content filters, including them as JavaScript blobs that reassemble on the targeted device.

It is worth noting that PluxX is a commonly used tool for HTML smuggling. Multiple Chinese threat actors have used this malware previously, such as the group that targeted the Vatican in 2020 or the one that targeted the Indonesian Intelligence Service in 2021. The malware was also used to target users in Mongolia, Ghana, Papua New Guinea, Nigeria, and Zimbabwe in a USB drive-based campaign.

CPR researchers agree that SmugX’s primary objective is to obtain sensitive data on the foreign policies of the targeted countries. This analysis is based on the lure samples posted to the malware repository on VirusTotal. The filenames of these samples were self-explanatory.

Researchers wrote that the names strongly suggested that the attackers wanted to target diplomats and government entities, whereas the content contained mainly diplomatic-related content related to China. The attack utilizes several .docx and .pdf files containing diplomatic content.

CPR researchers obtained a letter from the Serbian embassy in Budapest, a document revealing the Swedish Presidency of the Council of the European Union’s priorities, and an invitation from the Hungarian foreign ministry for a diplomatic conference.

The researchers also discovered an article about the two Chinese human rights lawyers who had received a ten-year sentence. Here are the titles of these documents:

*   202305 Indicative Planning RELEX
*   Draft Prague Process Action Plan\_SOM\_EN
*   2262\_3\_PrepCom\_Proposal\_next\_meeting\_26\_April
*   Comments FRANCE – EU-CELAC Summit – 4th May
*   China jails two human rights lawyers for Subversion

One of the phishing documents (left) – Targeted countries (right)

“While none of the techniques observed in this campaign is new or unique, the combination of the different tactics, and the variety of infection chains resulting in low detection rates, enabled the threat actors to stay under the radar for quite a while,” CPR researchers noted.

CPR is still investigating and monitoring SmugX activities and will share new details soon. Please continue to visit this platform for the latest updates on SmugX.

**RELATED ARTICLES**

1.  Killnet Hits European Parliament Website with DDoS Attack
2.  Research sector hit in new phishing attack using Google Drive
3.  Fake WHO Emails on COVID-19 Drop Nerbian RAT Across Europe
4.  European Spyware Vendor Offering Android & iOS Device Exploits
5.  Zimbra email platform flaw exploited to steal European govt emails

SmugX: Chinese Hackers Targeting Embassies in Europe

The National Defense Authorization Act may include new language forbidding government entities from buying Americans' search histories, location data, and more.

A “must-pass” defense bill wending its way through the United States House of Representatives may be amended to abolish the government practice of buying information on Americans that the country’s highest court has said police need a warrant to seize. Though it’s far too early to assess the odds of the legislation surviving the coming months of debate, it’s currently one of the relatively few amendments to garner support from both Republican and Democratic members. 

Introduction of the amendment follows a report declassified by the Office of the Director of National Intelligence—the nation’s top spy—which last month revealed that intelligence and law enforcement agencies have been buying up data on Americans that the government’s own experts described as “the same type” of information the US Supreme Court in 2018 sought to shield against warrantless searches and seizures. 

A handful of House lawmakers, Republicans and Democrats alike, have declared support for the amendment submitted late last week by representatives Warren Davidson, a Republican from Ohio, and Sara Jacobs, a California Democrat. The bipartisan duo is seeking stronger warrant requirements for the surveillant data constantly accumulated by people’s cellphones. They argue that it shouldn’t matter whether a company is willing to accept payment from the government in lieu of a judge’s permission.

“Warrantless mass surveillance infringes the Constitutionally protected right to privacy,” says Davidson. The amendment, he says, is aimed chiefly at preventing the government from “circumventing the Fourth Amendment” by purchasing “your location data, browsing history, or what you look at online.”

A copy of the Davidson-Jacobs amendment reviewed by WIRED shows that the warrant requirements it aims to bolster focus specifically on people’s web browsing and internet search history, along with GPS coordinates and other location information derived primarily from cellphones. It further encapsulates “Fourth Amendment protected information” and would bar law enforcement agencies of all levels of jurisdiction from exchanging “anything of value” for information about people that would typically require a “warrant, court order, or subpoena under law.”

The amendment contains an exception for anonymous information that it describes as “reasonably” immune to being de-anonymized; a legal term of art that would defer to a court’s analysis of a case’s more fluid technicalities. A judge might, for instance, find it unreasonable to assume a data set is well obscured based simply on the word of a data broker. The Federal Trade Commission’s Privacy and Identity Protection Division noted last year that claims that data is anonymized “are often deceptive,” adding that “significant research” reflects how trivial it often is to reidentify “anonymized data.”

The amendment was introduced Friday to defense legislation that will ultimately authorize a range of policies and programs consuming much of the Pentagon’s nearly $890 billion budget next year. The National Defense Authorization Act (NDAA), which Congress is required to pass annually, is typically pieced together from hundreds, if not thousands, of amendments. 

This year negotiations are particularly contentious, given the split chamber and a mess of interparty strife, and only one in six NDAA amendments introduced so far have apparent bipartisan support. 

Republican members Nancy Mace of South Carolina, Kelly Armstrong of North Dakota, and Ben Cline of Virginia have backed the Davidson-Jacobs amendment, according to the House Rules Committee website. They’re joined by Democrats Pramila Jayapal of Washington, Zoe Lofgren of California, and Veronica Escobar of Texas.

Jacobs previously coauthored a related amendment with Davidson that attempted to compel the US military to disclose annually how often its various spy agencies purchase Americans’ smartphone and web-browsing data. The amendment was stripped from the final version of last year’s NDAA.

The data broker report declassified last month by the US director of national intelligence, Avril Haines, stressed that neither presently, nor at any point in the past, would the government be permitted to force “billions of people to carry location-tracking devices on their persons at all times.” That is, nevertheless, what is happening today, independent of the government’s actions. The unceasing explosions of new technologies are clashing more and more frequently with the nation’s antiquated privacy laws, giving the Department of Homeland Security, Defense Intelligence Agency, and others like them an unmistakable loophole through which virtually anyone can be surveilled without a reason. 

Demand Progress senior policy counsel Sean Vitka, whose group has spent years lobbying for privacy reform in the face of the government’s growing and often secret reliance on data brokers, says the relatively untracked purchases—up to and including “turnkey lists of everyone who has gone to an abortion clinic, a place of worship, a rehab facility, or a protest”—represent an “existential threat” to the right to privacy. The Davidson-Jacobs amendment marks a “critical opportunity to get \[federal lawmakers\] on the record,” adds Vitka.

The American Civil Liberties Union intends to score how lawmakers vote on the amendment, WIRED has learned. The lawmakers’ effort is also being supported by the Electronic Frontier Foundation, National Association of Criminal Defense Lawyers, FreedomWorks, and the Brennan Center for Justice at NYU School of Law, among dozens of similar civil society organizations.  

Congressional staffers and others privy to ongoing conferencing over privacy matters on Capitol Hill say that regardless of whether the amendment succeeds, the focus on data brokers is just a prelude to a bigger fight coming this fall over the potential sunsetting of one of the spy community’s powerful tools, Section 702 of the Foreign Intelligence Surveillance Act, the survivability of which is anything but assured.

US Spies Are Buying Americans' Private Data. Congress Has a Chance to Stop It

Now is the time to build safeguards into nascent AI technology.

Are we in a golden age of artificial intelligence? It's tough to make predictions — and probably ill-advised. Who wants to predict the future of such a new technology?

We can, however, say some things for certain. A great deal is being made of AI's application to creative works, from voice acting to first drafts of screenplays. But AI is likely to be most useful when dealing with drudgery. This is good news for developers, if the promise matches early experiments — first drafts of code can be easily created and ready for developers to tweak and iterate upon.

However, it's important to remember that not every coder is working for a legitimate business. Just as cybersecurity threat actors have emulated their targets in becoming more businesslike, they're also adopting new technologies and techniques. We can expect AI to help in the development of malware and other threats in the coming years, whether we're entering a golden age of AI or not.

**Drafting Code and Scams**

One trend we've seen in recent years is a rise of "as-a-service" offerings. Early hackers were tinkerers and mischief-makers, tricking phone systems or causing chaos mostly as an exercise in fun. This has fundamentally changed. Threat actors are professional and often sell their products for others to use.

AI will fit very nicely into this way of working. Able to create code to tackle specific problems, AI can amend code to target vulnerabilities or take existing code and change it, so it's not so easily detected by security measures looking for specific patterns.

But the possibilities for AI's misuse doesn't stop there. Many phishing emails are detected by effective filtering tools and end up in junk folders. Those that do make it to the inbox are often very obviously scams, written so badly they're borderline incomprehensible. But AI could break this pattern, creating thousands of plausible emails that can evade detection and be well-written enough to fool both filters and end users.

Spear-phishing, the more targeted form of this attack, could also be revolutionized by this tech. Sure, it's easy to ignore an email from your boss asking you to wire cash or urgently buy gift cards — cybersecurity training helps employees avoid this sort of scam. But what about a deep-fake phone call or video chat? AI has the potential to take broadcast appearances and podcasts and turn them into a convincing simulacrum, something far harder to ignore.

**Fighting Back Against AI Cyberattacks**

There are two main ways to fight back against the benefits that AI will confer on the enemy — better AI and better training — And both will be necessary.

The advent of this new generation of AI has started a new arms race. As cybercriminals use it to evolve their attacks so will security teams need to use it to evolve their defenses.

Without AI, defenses rely on overworked people and monitoring for certain preprogramed patterns to prevent attacks. AI defensive tools will be able to predict attack vectors and pinpoint sensitive areas of the network and systems. They'll also be able to analyze malicious code, allowing a better understanding of how new attacks work and how they can be prevented.

AI could also work, in a pinch, as an emergency stop — disabling the network upon detecting a breach and locking down the entire system. While not ideal from a business continuity perspective, this could be far less damaging than a data breach.

But fighting AI with AI is not the only answer. We also need human intelligence. No matter how smart and targeted, the best defense against a phishing attack is an employee or customer who knows what to look for and is suspicious enough not to take the bait. Implementing robust security policies and best-practice cyber hygiene will remain key to defending against attacks.

This means that training will need to be updated to include the signs of an AI attack … whatever those might be. Training will need to evolve with AI — a single training course every few years isn't going to cut it anymore when that training is quickly out of date.

While the possible signs of an AI-driven cyberattack are changing rapidly, in general, attacks are:

*   **Fast and scalable**, exploiting multiple vulnerabilities in a short time span.
*   **Adaptive and evasive**, changing tactics and techniques to avoid detection and response.
*   **Targeted and personalized**, using AI to craft convincing phishing emails or social engineering campaigns.
*   **Deceptive and manipulative**, using AI to create fake or altered content such as deepfakes, voice cloning, or text generation.
*   **Stealthy and persistent**, hiding in the network infrastructure for a long time without being noticed.

These signs aren't exhaustive, and some AI-driven attacks may not exhibit all of them. However, they indicate the level of threat that AI poses to cybersecurity.

To effectively fight AI-driven cyberattacks, businesses must think beyond individual bad actors and prepare for coordinated attacks by state-sponsored actors or criminal organizations that may use AI to launch sophisticated campaigns using a risk-based approach. They should also have a proactive strategy that includes regular security audits, backups, encryption, and incident response plans. This is most easily accomplished by obtaining a well-known security certification such as PCI-DSS.

Finally, it's imperative that organizations improve the cybersecurity of their own AI systems by ensuring their integrity, confidentiality, and availability, and by mitigating the risks of adversarial attacks, data poisoning, and model stealing.

These strategies will help protect businesses, but they shouldn't standalone — security should be collaborative. By collaborating with other organizations, researchers, and authorities to share information, best practices, and failures that can be learned from, businesses will be better prepared for the new wave of AI security threats.

AI is both a new threat and a continuation of older threats. Businesses will have to evolve how they tackle cyber threats as these threats become more sophisticated and more numerous, but a lot of the fundamentals remain the same. Getting these right remains critical. Security teams don't need to pivot away from old ideas but build on them to keep their businesses safe.

A Golden Age of AI … or Security Threats?

The ransomware group shows an evolution of its tactics with MOVEit zero-day — potentially ushering in a new normal when it comes to extortion supply chain cyberattacks, experts say.

The MOVEit file transfer zero-day vulnerability, first discovered on June 1, was used to breach at least 160 confirmed victims by June 30. The successful mass extortion campaign represents an evolution of tactics by the Russian-backed Cl0p ransomware group, which experts say is likely to catch the attention of rival threat actors.

Threat researchers note that the MOVEit campaign has some clues about how to respond to future of supply chain cyberattacks for defenders as well.

So far, the breached organizations include a who's who of international brands, like Avast's parent company,  
British Airways, Siemens, UCLA, and more. Reports say the ransomware group pulled off the technically detailed mass exploitation after at least two years of careful development, patiently plotting and planning when and where to strike, armed with the secret flaw in the MOVEit file transfer software.

**Ransomware-Less Ransomware Attacks**

Researchers note a few innovations Cl0p has made between previous exploits and the MOVEit campaign, which are likely to influence other threat groups. For instance, Cl0p has streamlined the extortion business model by doing away with ransomware all together, John Hammond, Huntress security threat researcher explained to Dark Reading.

"From what the industry has seen in \[recent\] Cl0p breaches (namely, GoAnywhere MFT and MOVEit Transfer), they haven't executed ransomware within the target environments," Hammond says. "The operations have strictly been exfiltrating data and using that stolen information for later blackmail and extortion. It's not clear why they opted not to encrypt files."

While it's not clear why Cl0p pivoted, the end result is a ransomware business model without the overhead of trying building better ransomware, he adds.

"Perhaps other cybercrime gangs will follow suit, and the development of ransomware tooling and creating faster malware may fall to the way-side when adversaries can just focus on their real goal of making money," Hammond says.

**Third-Party Zero Day Exploit Providers**

All of that said, if making money was the primary motivation for the MOVEit cyberattacks, the group would have chosen a much simpler approach than investing the time and resources to discover and develop an exploit like the one in MOVEit.

John Fokker, head of threat intelligence with the Trellix Advanced Research Center explained to Dark Reading he thinks he has the answer: The group acquired the zero-day from a third party.

"There are several aspects and factors of this particular cyberattack and vulnerability that are really interesting," John Fokker, head of threat intelligence with the Trellix Advanced Research Center explained to Dark Reading. "The MOVEit vulnerability isn't an easy or straightforward one — it required extensive research into the MOVEit platform to discover, understand, and exploit this vulnerability. The skill set required to uncover and exploit this vulnerability isn't easily trained and is hard to come by in the industry."

He adds, devoting that level of detail to an operation isn't something Cl0p ransomware group usually does, which is another clue leading Fokker and his team to suspect Cl0p acquired the MOVEit zero-day vulnerability rather than developing it from scratch.

"It's definitely a possibility that Cl0p didn't actually discover this zero-day vulnerability and exploit but rather acquired it from a third party," Fokker adds. "We believe with moderate confidence that this was the case, based on what was mentioned above in addition to certain other elements of the attack and leak postings."

**Shoring up the Software Supply Chain Against Future Zero-Day Exploits**

Stopping more sophisticated zero-day supply chain attacks requires investment in proactive efforts, including robust, responsive bug bounty programs funded by software vendors, notes Randy Pargman, director of threat detection with Proofpoint explains.

"There's a huge discrepancy between the amount of money that software vendors are willing to pay for bug bounties versus the amount that zero-day researchers can get from governments and underground markets for their research, so vendors could do better by investing more," Pargman says. "Where software companies can still improve the most is in making it easier for bug bounty hunters to report issues, and treating researchers with respect."

But as Omkhar Arasaratnam, general manager of the Open Source Security Foundation says, what he's more concerned about are reports of panicked responses to the MOVEit exploit among cybersecurity professionals.

"The cybersecurity community should focus on making incidents boring," Arasaratnam says. "When paramedics arrive at an accident scene they do not run around frantically or in a panic. Paramedics deliberately, and stoically execute the procedures that they've learned to gain access, assess the scene, triage, and help effectively. Cybersecurity can take a lesson from paramedics."

Cl0p's MOVEit Campaign Represents a New Era in Cyberattacks

An access violation vulnerability exists in the GraphPlanar::Write functionality of Diagon v1.0.139. A specially crafted network request can lead to a heap buffer overflow. An attacker can send a network request to trigger this vulnerability.

**SUMMARY**

An access violation vulnerability exists in the GraphPlanar::Write functionality of Diagon v1.0.139. A specially crafted network request can lead to a heap buffer overflow. An attacker can send a network request to trigger this vulnerability.

**CONFIRMED VULNERABLE VERSIONS**

The versions below were either tested or verified to be vulnerable by Talos or confirmed to be vulnerable by the vendor.

Diagon v1.0.139

**PRODUCT URLS**

Diagon - https://github.com/ArthurSonzogni/Diagon

**CVSSv3 SCORE**

4.0 - CVSS:3.1/AV:L/AC:H/PR:N/UI:N/S:U/C:N/I:L/A:L

**CWE**

CWE-122 - Heap-based Buffer Overflow

**DETAILS**

Diagon is an interpreter that translates markdown into several formats: latex, planar graph, table, tree and many others.

The Diagon interpreter translates from a representation of a graph to a planar graph. For instance, the input could looks like this:

    A--B--C--D--E--F--D--C
    

And the planar graph would result in:

          ┌─┐
          │A│
          └┬┘
          ┌┴┐
          │B│
          └┬┘
    ┌─────┐│
    │  D  ││
    └┬─┬─┬┘│
     │ │┌┴┐│
     │ ││E││
     │ │└┬┘│
     │┌┴─┴┐│
     ││ F ││
     │└───┘│
    ┌┴─────┴─┐
    │   C    │
    └────────┘
    

The input will be parsed and eventually reach the GraphPlanar::Write() function:

    void GraphPlanar::Write() {
      ComputeArrowStyle();
    
      if (id_to_name.size() <= 2) {
        return;
      }
    
      int num_vertices = id_to_name.size();
    
      // Create a graph.
      Graph graph(num_vertices);
      for (auto& it : vertex)
        add_edge(it.from, it.to, graph);
      InitializeEdgeIndex(graph);
    
      // Make it connected.
      boost::make_connected(graph);                                                                         [1]
      InitializeEdgeIndex(graph);
    
      // Make it biconnected.
      Embedding embedding;
      bool is_planar = ComputePlanarEmbedding(graph, embedding);
      if (!is_planar) {
        output_ = "Graph is not planar.\n";
        return;
      }
    
      boost::make_biconnected_planar(graph, embedding.data());                                              [2]
      InitializeEdgeIndex(graph);
      Graph biconnected_graph(graph);
    
      ComputePlanarEmbedding(graph, embedding);
      boost::make_maximal_planar(graph, embedding.data());                                                  [3]
      InitializeEdgeIndex(graph);
    
      // Find a canonical ordering.
      ComputePlanarEmbedding(graph, embedding);
      std::vector<boost::graph_traits<Graph>::vertex_descriptor> ordering;
      boost::planar_canonical_ordering(graph, embedding.data(),
                                       std::back_inserter(ordering));                                       [4]
    
      std::vector<size_t> inverse_ordering(num_vertices);                                                   [5]
      for (int i = 0; i < inverse_ordering.size(); ++i) {
        inverse_ordering[ordering[i]] = i;                                                                  [6]
      }
      [...]
    }
    

This function, until the code at [3], will manipulate the graph representation of the input to satisfy the pre-requisites of the planar_canonical_ordering function at [4]. Indeed, to call the planar_canonical_ordering at [4], the graph must be maximal planar; that is, calculated at [3]. Before calling the make_maximal_planar at [3] the graph must be biconnected. To make the graph biconnected, the function make_biconnected_planar, at [2], is called. The last dependency is that the graph must be connected, which is satisfied using make_connected called at [1].

The Graph type is defined as follows:

    using Graph = boost::adjacency_list<boost::vecS,
                                boost::vecS,
                                boost::undirectedS,
                                boost::property<boost::vertex_index_t, int>,
                                boost::property<boost::edge_index_t, int>>;
    

The first template parameter is used to specify how to store the edges. In this case, the boost::vecS will store the edges in a std::vector. This configuration will allow parallel edges. For instance, in the example bellow, we have the edge (C,D) but also (D,E).

Using the boost::vecS, allegedly, will break some assumption of the called function. For instance, it could create a graph that is not biconnected at [2]. This can lead to an out-of-bounds read and write. In the POC shown below, after calling the planar_canonical_ordering function at [4] the ordering will have a number of elements lower than the num_vertices variable that represent the number of vertices in the graph. Because inverse_ordering, at [5] , is created based on the actual number of vertices, the inverse_ordering buffer and the ordering one will mismatch in sizes. This would cause, at [6], an out-of-bounds read and write.

**Exploit Proof of Concept**

Following the content of the POC used:

    $ cat POC.md
    A--B--C--D--E--F--D--C
    

If we run Diagon compile with ASAN with the POC:

    $ diagon GraphPlanar < POC.md
    AddressSanitizer:DEADLYSIGNAL
    =================================================================
    ==3943598==ERROR: AddressSanitizer: SEGV on unknown address (pc 0x0000006952ef bp 0x7ffddd10d730 sp 0x7ffddd10c7e0 T0)
    ==3943598==The signal is caused by a READ memory access.
    ==3943598==Hint: this fault was caused by a dereference of a high value address (see register values below).  Dissassemble the provided pc to learn which register was used.
        #0 0x6952ef in GraphPlanar::Write() /home/vagrant/Diagon/src/translator/graph_planar/GraphPlanar.cpp:342:35
        #1 0x693085 in GraphPlanar::Translate(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&) /home/vagrant/Diagon/src/translator/graph_planar/GraphPlanar.cpp:194:3
        #2 0x4fbd0e in (anonymous namespace)::Translate(Translator*, int, char const**) /home/vagrant/Diagon/src/main.cpp:277:36
        #3 0x4f97e7 in main /home/vagrant/Diagon/src/main.cpp:326:12
        #4 0x7fe4a9895d09 in __libc_start_main csu/../csu/libc-start.c:308:16
        #5 0x44ca69 in _start (/home/vagrant/Diagon/results/ordering_graphplanar_write_error/diagon_unfixed+0x44ca69)
    
    AddressSanitizer can not provide additional info.
    SUMMARY: AddressSanitizer: SEGV /home/vagrant/Diagon/src/translator/graph_planar/GraphPlanar.cpp:342:35 in GraphPlanar::Write()
    ==3943598==ABORTING
    

We can see that a segmentation fault occured. The GraphPlanar.cpp:342 line corresponds to the code at [6]

**VENDOR RESPONSE**

The maintainer has provided a patch at: https://github.com/ArthurSonzogni/Diagon/releases/tag/v1.1.158

**TIMELINE**

2023-05-03 - Vendor Disclosure  
2023-05-08 - Vendor Patch Release  
2023-07-05 - Public Release

Discovered by Francesco Benvenuto of Cisco Talos.

CVE-2023-31194: TALOS-2023-1745 || Cisco Talos Intelligence Group

A heap-based buffer overflow vulnerability exists in the Sequence::DrawText functionality of Diagon v1.0.139. A specially crafted network request can lead to a heap buffer overflow. An attacker can send a network request to trigger this vulnerability.

**SUMMARY**

A heap-based buffer overflow vulnerability exists in the Sequence::DrawText functionality of Diagon v1.0.139. A specially crafted network request can lead to a heap buffer overflow. An attacker can send a network request to trigger this vulnerability.

**CONFIRMED VULNERABLE VERSIONS**

The versions below were either tested or verified to be vulnerable by Talos or confirmed to be vulnerable by the vendor.

Diagon v1.0.139

**PRODUCT URLS**

Diagon - https://github.com/ArthurSonzogni/Diagon

**CVSSv3 SCORE**

8.4 - CVSS:3.1/AV:L/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H

**CWE**

CWE-122 - Heap-based Buffer Overflow

**DETAILS**

Diagon is an interpreter that translates markdown in several formats: latex, planar graph, table, tree and many others.

The Diagon interpreter translates a markdown text sequence diagram to a graphical sequence diagram. For instance, the input could look like this:

    Left -> Right: Message1
    Left <- Right: Message2
    

and the sequence diagram would result in:

     ┌────┐  ┌─────┐
     │Left│  │Right│
     └─┬──┘  └──┬──┘
       │        │
       │Message1│
       │───────>│
       │        │
       │Message2│
       │<───────│
     ┌─┴──┐  ┌──┴──┐
     │Left│  │Right│
     └────┘  └─────┘
    

The input will be parsed and will eventually reach the Sequence::UniformizeActors function:

    void Sequence::UniformizeActors() {
      [...]
    
      for (auto& message : messages) {
        for (auto& actor : {message.from, message.to}) {
          if (!actor_index.count(actor)) {
            actor_index[actor] = actors.size();
            Actor a;
            a.name = actor;
            actors.push_back(a);
          }
        }
      }
    }
    

This function will parse the actors in each message in messages, which consist of each row of the sequence diagram text. The actors are the sender and the receiver. In the example above, the actors are “Left” and “Right.” The function populates the actors vector and associates, in the actor_index map, the name of the actor with the number of elements in the actors vector at the creation time of the entry. This essentially can be considered an index starting from 0 and increasing with each new actor.

Eventually the Sequence::LayoutComputeActorsPositions function will be called to calculate the position of the various actors in the sequence diagram:

    void Sequence::LayoutComputeActorsPositions() {
      [...]
      
      for (auto& message : messages) {
        ActorSpace space{actor_index[message.from],  //
                         actor_index[message.to],    //
                         message.width + 1};         //
        if (space.a > space.b)
          std::swap(space.a, space.b);
        spaces.push_back(space);
      }
    
      if (actors.size() != 0)
        actors[0].center = actors[0].name.size() / 2 + 1;
    
      bool modified = true;
      int i = 0;
      while (modified) {
        modified = false;
        for (const ActorSpace& s : spaces) {
          if (actors[s.b].center - actors[s.a].center < s.space) {                                                  [1]
            actors[s.b].center = actors[s.a].center + s.space;
            modified = true;
          }
        }
        if (i++ > 500) {                                                                                            [2]
          std::cout << "Something went wrong!" << std::endl;
          break;
        }
      }
    
      for (auto& actor : actors) {                                                                                  [3]
        actor.left = actor.center - actor.name.size() / 2 - actor.name.size() % 2;
        actor.right = actor.left + actor.name.size() + 2;
      }
    }
    

Then, using the calculated positions, a Screen class is instantiated:

    std::string Sequence::Draw() {
        // Estimate output dimension.
        int width = actors.back().right;
        int height = 0;
        for (const Message& message : messages) {
          height = std::max(height, message.bottom);
        }
        height += 4;
    
        Screen screen(width, height);
    
        for (auto& actor : actors)
          actor.Draw(screen, height);
    
        for (auto message : messages)
          message.Draw(screen);
    
        if (ascii_only_)
          screen.ASCIIfy(0);
        return screen.ToString();
    }
    

The Screen class contains the lines_ matrix where the graphical sequence diagram is going to be written. This matrix takes into consideration the various sizes involved: the actors, the arrows, the messages, etc. Eventually the names of the actors and the messages between the them will be “drawn.” For each of these texts the Screen::DrawText function will be called:

    void Screen::DrawText(int x, int y, std::wstring_view text) {
        for (auto& c : text)
            lines_[y][x++] = c;                                                                                     [4]
    } Here `lines_` is the member of the `Screen` class instantiated in `Sequence::Draw`.
    

Sequence::LayoutComputeActorsPositions uses a variable called spaces. This is a vector dictating the minimum spaces between two actors. The spaces vector contains various instances of the ActorSpace struct. This struct contains two indexes for specifying which actors are involved: the ones stored in the actor_index map, and an integer value that represents the minimum spaces required between the two actors. For each message, one struct is created, using the minimum space required to write the message between the two actors. The spaces vector also contains the spaces required for each pair of adjacent actors. Each actor has three parameters to satisfy this space requirements: left, center and right. These dictate the position of each actor in the diagram.

To simplify the code explanation following, we are going to omit that the spaces array has the distances also for the adjacent actors and consider only the spaces in relationship to the messages and their sender and receiver actors. The Sequence::LayoutComputeActorsPositions function executes a while loop to modifying the actors positions based on the content of spaces. The while is executed until either the condition actors[s.b].center - actors[s.a].center < s.space, at [1], is false, meaning that the space between the two actors is enough for the message to be drawn with no modification of the actors positions, or the while has been executed 500 times, a check is executed at [2], and something was wrong, as suggested by the print.

This function has a bug, which can lead to a heap buffer overflow. Let’s take for example the following representation of a sequence diagram:

      A -> A:Message
    

In this example the sender and the receiver are the same actor, meaning that the index of the two will be equal; in this example, 0. The condition at [1], actors[s.b].center - actors[s.a].center < s.space for this example, can be simplified as actors[0].center - actors[0].center < s.space. Because the portion on the left is always equal to 0, this condition is always true. This means that the actors[s.b].center value is always updated without progress for making the condition at [1] false. Furthermore, also at [3], the actor’s left and right positions are updated, increasing their value.

Eventually the code at [4] is reached. The variable lines_ has a width and a height that are based on the positions calculated for the actors and the messages. The problem is that, even if the while in Sequence::LayoutComputeActorsPositions has been executed 500 times, no progress on changing the position of the actor to accommodate the message has been made. Indeed, the actor’s center, left and right values increased substantially, but the distance between the values did not. In this example the only actor present has the following position values:

      (gdb) p actors
      $19 = std::vector of length 1, capacity 1 = {{
          [...]
          left = 0xfb0,
          center = 0xfb1,
          right = 0xfb3
        }}
    

The left is 1 value from center, which is 2 value away from right. This is due to the calculation made at [3]. The space between left and right should take into consideration the length of the message, but because of the bug just explained it was not possible to account for that. This can lead to a heap buffer overflow vulnerability at [4] writing the message out-of-bounds.

**Exploit Proof of Concept**

Following the content of the POC used:

    $ cat POC.md
    A->A:POC_BOF
    

If we run Diagon compilation with ASAN with the POC:

    $ diagon Sequence < POC.md
    
    Something went wrong!
    =================================================================
    ==256826==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x628000017fd0 at pc 0x000000c77eab bp 0x7fff5f481050 sp 0x7fff5f481048
    WRITE of size 4 at 0x628000017fd0 thread T0
        #0 0xc77eaa in Screen::DrawText(int, int, std::basic_string_view<wchar_t, std::char_traits<wchar_t> >) /home/vagrant/Diagon/src/screen/Screen.cpp:32:20
        #1 0x8a1515 in Message::Draw(Screen&) /home/vagrant/Diagon/src/translator/sequence/Sequence.cpp:71:12
        #2 0x8aefb0 in Sequence::Draw[abi:cxx11]() /home/vagrant/Diagon/src/translator/sequence/Sequence.cpp:692:13
        #3 0x8acc37 in Sequence::Translate(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&) /home/vagrant/Diagon/src/translator/sequence/Sequence.cpp:293:10
        #4 0x4fbd0e in (anonymous namespace)::Translate(Translator*, int, char const**) /home/vagrant/Diagon/src/main.cpp:277:36
        #5 0x4f97e7 in main /home/vagrant/Diagon/src/main.cpp:326:12
        #6 0x7f1a7e31ad09 in __libc_start_main csu/../csu/libc-start.c:308:16
        #7 0x44ca69 in _start (/home/vagrant/Diagon/build/diagon-1.0.139+0x44ca69)
    
    0x628000017fd0 is located 0 bytes to the right of 16080-byte region [0x628000014100,0x628000017fd0)
    allocated by thread T0 here:
        #0 0x4f677d in operator new(unsigned long) (/home/vagrant/Diagon/build/diagon-1.0.139+0x4f677d)
        #1 0x7f1a7e655a0e in void std::__cxx11::basic_string<wchar_t, std::char_traits<wchar_t>, std::allocator<wchar_t> >::_M_construct<wchar_t*>(wchar_t*, wchar_t*, std::forward_iterator_tag) (/lib/x86_64-linux-gnu/libstdc++.so.6+0x14ba0e)
    
    SUMMARY: AddressSanitizer: heap-buffer-overflow /home/vagrant/Diagon/src/screen/Screen.cpp:32:20 in Screen::DrawText(int, int, std::basic_string_view<wchar_t, std::char_traits<wchar_t> >)
    Shadow bytes around the buggy address:
      0x0c507fffafa0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
      0x0c507fffafb0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
      0x0c507fffafc0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
      0x0c507fffafd0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
      0x0c507fffafe0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
    =>0x0c507fffaff0: 00 00 00 00 00 00 00 00 00 00[fa]fa fa fa fa fa
      0x0c507fffb000: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
      0x0c507fffb010: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
      0x0c507fffb020: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
      0x0c507fffb030: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
      0x0c507fffb040: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
    Shadow byte legend (one shadow byte represents 8 application bytes):
      Addressable:           00
      Partially addressable: 01 02 03 04 05 06 07
      Heap left redzone:       fa
      Freed heap region:       fd
      Stack left redzone:      f1
      Stack mid redzone:       f2
      Stack right redzone:     f3
      Stack after return:      f5
      Stack use after scope:   f8
      Global redzone:          f9
      Global init order:       f6
      Poisoned by user:        f7
      Container overflow:      fc
      Array cookie:            ac
      Intra object redzone:    bb
      ASan internal:           fe
      Left alloca redzone:     ca
      Right alloca redzone:    cb
      Shadow gap:              cc
    ==256826==ABORTING
    

We can see that a heap buffer overflow occured at Sequence.cpp:71 that corresponds to the code at [4].

**VENDOR RESPONSE**

The maintainer has provided a patch at: https://github.com/ArthurSonzogni/Diagon/releases/tag/v1.1.158

**TIMELINE**

2023-05-03 - Vendor Disclosure  
2023-05-08 - Vendor Patch Release  
2023-07-05 - Public Release

Discovered by Francesco Benvenuto of Cisco Talos.

Tag

#intel