As Russia has accelerated its cyberattacks on its neighbor, it's barraged the country with an unprecedented volume of different data-destroying programs.

Despite that sheer volume of wiper malware, Russia's cyberattacks against Ukraine in 2022 have in some respects seemed relatively ineffective compared to previous years of its conflict there. Russia has launched repeated destructive cyberwarfare campaigns against Ukraine since the country's 2014 revolution, all seemingly designed to weaken Ukraine's resolve to fight, sow chaos, and make Ukraine appear to the international community to be a failed state. From 2014 to 2017, for instance, Russia's GRU military intelligence agency carried out a series of unprecedented cyberattacks: They disrupted and then attempted to spoof results for Ukraine's 2014 presidential election, caused the first-ever blackouts triggered by hackers, and finally unleashed NotPetya, a self-replicating piece of wiper malware that hit Ukraine, destroying hundreds of networks across government agencies, banks, hospitals, and airports before spreading globally to cause a still-unmatched $10 billion in damage.

But since early 2022, Russia's cyberattacks against Ukraine have shifted into a different gear. Instead of masterpieces of malevolent code that required months to create and deploy, as in Russia's earlier attack campaigns, the Kremlin's cyberattacks have accelerated into quick, dirty, relentless, repeated, and relatively simple acts of sabotage.

In fact, Russia appears, to some degree, to have swapped quality for quantity in its wiper code. Most of the dozen-plus wipers launched in Ukraine in 2022 have been relatively crude and straightforward in their data destruction, with none of the complex self-spreading mechanisms seen in older GRU wiper tools like NotPetya, BadRabbit, or Olympic Destroyer. In some cases, they even show signs of rushed coding jobs. HermeticWiper, one of the first wiping tools that hit Ukraine just ahead of the February 2022 invasion, used a stolen digital certificate to appear legitimate and avoid detection, a sign of sophisticated pre-invasion planning. But HermeticRansom, a variant in the same family of malware designed to appear as ransomware to its victims, included sloppy programming errors, according to ESET. HermeticWizard, an accompanying tool designed to spread HermeticWiper from system to system, was also bizarrely half-baked. It was designed to infect new machines by attempting to log in to them with hardcoded credentials, but it only tried eight usernames and just three passwords: 123, Qaz123, and Qwerty123.

Perhaps the most impactful of all of Russia's wiper malware attacks on Ukraine in 2022 was AcidRain, a piece of data-destroying code that targeted Viasat satellite modems. That attack knocked out a portion of Ukraine's military communications and even spread to satellite modems outside the country, disrupting the ability to monitor data from thousands of wind turbines in Germany. The customized coding needed to target the form of Linux used on those modems suggests, like the stolen certificate used in HermeticWiper, that the GRU hackers who launched AcidRain had carefully prepared it ahead of Russia's invasion.

But as the war has progressed—and as Russia has increasingly appeared unprepared for the longer-term conflict it mired itself in—its hackers have switched to shorter-term attacks, perhaps in an effort to match the pace of a physical war with constantly changing front lines. By May and June, the GRU had come to increasingly favor the repeated use of the data-destruction tool CaddyWiper, one of its simplest wiper specimens. According to Mandiant, the GRU deployed CaddyWiper five times in those two months and four more times in October, changing its code only enough to avoid detection by antivirus tools.

Even then, however, the explosion of new wiper variants has only continued: ESET, for instance, lists Prestige, NikoWiper, Somnia, RansomBoggs, BidSwipe, ZeroWipe, and SwiftSlicer all as new forms of destructive malware—often posing as ransomware—that have appeared in Ukraine since just October.

But ESET doesn't see that flood of wipers as a kind of intelligent evolution, so much as a kind of brute-force approach. Russia appears to be throwing every possible destructive tool at Ukraine in an effort to stay ahead of its defenders and inflict whatever additional chaos it can in the midst of a grinding physical conflict. 

“You can’t say their technical sophistication is increasing or decreasing, but I would say they’re experimenting with all these different approaches,” says Robert Lipovsky, ESET's principal threat intelligence researcher. “They're all in, and they're trying to wreak havoc and cause disruption.”

Ukraine Suffered More Wiper Malware in 2022 Than Anywhere, Ever

If you Google "third-party data breaches" you will find many recent reports of data breaches that were either caused by an attack at a third party or sensitive information stored at a third-party location was exposed. Third-party data breaches don't discriminate by industry because almost every company is operating with some sort of vendor relationship – whether it be a business partner,

If you Google "third-party data breaches" you will find many recent reports of data breaches that were either caused by an attack at a third party or sensitive information stored at a third-party location was exposed. Third-party data breaches don't discriminate by industry because almost every company is operating with some sort of vendor relationship – whether it be a business partner, contractor or reseller, or the use of IT software or platform, or another service provider. Organizations are now sharing data with an average of 730 third-party vendors, according to a report by Osano, and with the acceleration of digital transformation, that number will only grow.

****The Importance of Third-Party Risk Management****

With more organizations sharing data with more third-party vendors, it shouldn't be surprising that more than 50% of security incidents in the past two years have stemmed from a third-party with access privileges, according to a CyberRisk Alliance report.

Unfortunately, while most security teams agree that supply chain visibility is a priority, the same report notes that only 41% of organizations have visibility into their most critical vendors and only 23% have visibility into their entire third-party ecosystem.

The reasons for the lack of investment into Third Party Risk Management (TPRM) are the same that we consistently hear – lack of time, lack of money and resources, and it's a business need to work with the vendor. So, how can we make it easier to overcome the barriers to managing third-party cyber risk? Automation.

****The Benefits of Automation****

Automation empowers organizations to do more with less. From a security perspective, here are just some of the benefits automation provides, as highlighted by Graphus:

*   76 % of IT executives in a cybersecurity survey said that automation maximizes the efficiency of security staff.
*   Security automation can save more than 80% over the cost of manual security.
*   42% of companies cited security automation as a major factor in their success at improving their cybersecurity posture.

With regards to TPRM, automation can transform your program by:

****Step 1 - Assess your vendors with Continuous Threat Exposure Management (CTEM)****

Continuous threat exposure assessments include comprehensive assessments that incorporate the following:

*   Automated asset discovery
*   External infrastructure/Network Assessments
*   Web application security assessment
*   Threat intelligence informed analysis
*   Dark web findings
*   More accurate security rating

This is a more comprehensive analysis of third parties compared to just sending questionnaires. A manual questionnaire process can take between 8-40 hours per vendor, provided that the vendor responds quickly and accurately. But this approach doesn't allow the ability to see vulnerabilities or validate the effectiveness of the required controls in a questionnaire.

Incorporating an automated threat exposure assessment capability and integrating it with questionnaires can reduce the time to review vendors, and we've found that the combination can reduce the time to assess and onboard new vendors by 33%.

****Step 2 – Use a Questionnaire Exchange****

Organizations that manage many questionnaires, or vendors that respond to many questionnaires, should consider using a questionnaire exchange. Simply stated, it's a hosted repository of completed standard or custom questionnaires that can be shared with other interested parties upon approval.

If you select a platform that performs the automation described above, both parties get a verified and automated approach to the most recent questionnaires that are auto-validated by continuous assessments. Again, this can save your team time by requesting access to existing questionnaires or scaling their time in the response of a new questionnaire that can be reused upon request.

****Step 3 - Continuously combine threat exposure findings with the questionnaire exchange****

Security ratings alone don't work. Using questionnaires alone to assess third parties doesn't work. Threat exposure management, which incorporates accurate security ratings from the direct assessments, combined with validated questionnaires - where the questionnaire is querying the assessment and updating the security rating - provides you with a powerful solution for continuous Third-Party Risk Management. Platforms that use active and passive assessments, and don't solely rely on historical OSINT data, provide the most accurate attack surface visibility – since it's of a third-party at that time.

This information can be leveraged to auto-validate the applicable controls in the questionnaire for security and compliance framework requirements and flag any discrepancy between the client answer and the technology assessment finding. This gives organizations a real "trust but verify" approach toward third-party reviews. Since this can be done quickly, you can be notified when third parties become non-compliant with specific technical controls.

Organizations looking to maximize the efficiency of their third-party cyber risk management program should look to add automation to their processes. In more difficult macro-economic environments companies can turn to automation to reduce the toil that their team performs, while still achieving progress and results, in exchange for team members being able to focus on other initiatives.

**Note:** Victor Gamra, CISSP, a former CISO, has authored and provided this article. He is also the Founder and CEO of FortifyData, an industry-leading Continuous Threat Exposure Management (CTEM) firm. FortifyData empowers businesses to manage cyber risk at the organizational level by incorporating automated attack surface assessments, asset classification, risk-based vulnerability management, security ratings, and third-party risk management into an all-in-one cyber risk management platform. To learn more, please visit www.fortifydata.com.

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

3 Steps to Automate Your Third-Party Risk Management Program

Shipping companies and medical laboratories in Asia have been the subject of a suspected espionage campaign carried out by a never-before-seen threat actor dubbed Hydrochasma.
The activity, which has been ongoing since October 2022, "relies exclusively on publicly available and living-off-the-land tools," Symantec, by Broadcom Software, said in a report shared with The Hacker News.
There is no

Cyber Espionage / Cyber Attack

Shipping companies and medical laboratories in Asia have been the subject of a suspected espionage campaign carried out by a never-before-seen threat actor dubbed **Hydrochasma**.

The activity, which has been ongoing since October 2022, "relies exclusively on publicly available and living-off-the-land tools," Symantec, by Broadcom Software, said in a report shared with The Hacker News.

There is no evidence available as yet to determine its origin or affiliation with known threat actors, but the cybersecurity company said the group may be having an interest in industry verticals that are involved in COVID-19-related treatments or vaccines.

The standout aspects of the campaign is the absence of data exfiltration and custom malware, with the threat actor employing open source tools for intelligence gathering. By using already available tools, the goal, it appears, is to not only confuse attribution efforts. but also to make the attacks stealthier.

The start of the infection chain is most likely a phishing message containing a resume-themed lure document that, when launched, grants initial access to the machine.

From there, the attackers have been observed deploying a trove of tools like Fast Reverse Proxy (FRP), Meterpreter, Cobalt Strike Beacon, Fscan, BrowserGhost, and Gost proxy.

"The tools deployed by Hydrochasma indicate a desire to achieve persistent and stealthy access to victim machines, as well as an effort to escalate privileges and spread laterally across victim networks," the researchers said.

The abuse of FRP by hacking groups is well-documented. In October 2021, Positive Technologies disclosed attacks mounted by ChamelGang that involved using the tool to control compromised hosts.

Then last September, AhnLab Security Emergency response Center (ASEC) uncovered attacks targeting South Korean companies that leveraged FRP to establish remote access from already compromised servers in order to conceal the adversary's origins.

Hydrochasma is not the only threat actor in recent months to completely eschew bespoke malware. This includes a cybercrime group dubbed OPERA1ER (aka Bluebottle) that makes extensive use of living-off-the-land, dual use tools and commodity malware in intrusions aimed at Francophone countries in Africa.

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

Hydrochasma: New Threat Actor Targets Shipping Companies and Medical Labs in Asia

Which of the myriad, extant cyberthreats should your business be paying the most attention to in 2023? 



(Read more...)




The post The 5 most dangerous cyberthreats facing businesses this year appeared first on Malwarebytes Labs.

Which of the myriad, extant cyberthreats should your business be paying the most attention to in 2023? 

That’s the question we set out to answer in this year’s annual State of Malware report, and the answers might surprise you. To understand why, you need to know what makes this year’s report so different from previous ones.

Unquestionably, over the last five years, the most serious cybersecurity task facing businesses has changed from defending against waves of malicious, email-borne malware to stopping seasoned criminals armed with Ransomware-as-a-Service (RaaS).

RaaS attacks can be extraordinarily severe. They can bring entire organizations to a halt, come with ruinous ransoms, and may take months of dedicated effort to recover from. They represent an existential threat to businesses.

The worst-of-the-worst is LockBit, the first on our list of the most dangerous threats you face. LockBit’s largest known ransom demand in 2022 was $50 million, although multiple sources report even higher demands were made. Its victims included businesses of all sizes, from local law firms with a handful of employees to multi-national enterprises.

LockBit was the most widely used RaaS in 2022, by far. It accounted for almost a third of all known RaaS attacks, and more than three times as many as its closest competitor, ALPHV.

Known attacks by the top 5 RaaS groups in 2022

And yet, if you were to create a list of the most detected malware from last year, you wouldn’t see LockBit on it. In fact, you wouldn’t see any RaaS on it. In cybersecurity, what’s common and what’s serious have diverged markedly.

For that reason, lists of the most detected malware are gone from this year’s report. In their place, we asked our experts—our threat intelligence analysts, and the threat hunters in our Managed Detection and Response (MDR) team: What essential information do resource-constrained organizations need to know?

They came up with a list of the five worst-in-class malware threats spanning Windows, Android and macOS. The report explains what these threats do and why, what it takes to detect them, and what it takes to recover from an attack. Each of our five is an archetype, so if you prepare to stop them, you’re well prepared for anything, on any of your devices.

Compiling our report like this also led us to an important insight: The most dangerous attacks you will face are not from the strangest new malware, the most sophisticated, the most eye-catching, or the most prevalent.

Instead, the most dangerous threats come from a set of known, mature tools and tactics that an entire ecosystem of cybercriminals rely upon to take in billions of dollars a year. Criminals have come to rely upon these attack types and their vectors because they work, and they work because they are hard to defend against and difficult to remove.

The 2023 State of Malware report explains what they are, how they find their victims, and how to avoid becoming one of them.

To learn more about LockBit and how to defend against it, and to discover the four other threats you should prepare for this year, download the 2023 State of Malware report. In it you will also learn:

*   What it takes to stop what Europol called the “world’s most dangerous malware.”
*   Why there was a 300% increase in some new malware delivery methods.
*   How to catch the emerging, hard-to-detect attacks that don’t rely on malware.
*   Why security people are as important as security software.

Get the 2023 State of Malware report

The 5 most dangerous cyberthreats facing businesses this year

At the beginning of January, Gcore faced an incident involving several L3/L4 DDoS attacks with a peak volume of 650 Gbps. Attackers exploited over 2000 servers belonging to one of the top three cloud providers worldwide and targeted a client who was using a free CDN plan. However, due to Gcore’s distribution of infrastructure and a large number of peering partners, the attacks were mitigated,

Server Security / DDoS Attack

At the beginning of January, Gcore faced an incident involving several L3/L4 DDoS attacks with a peak volume of 650 Gbps. Attackers exploited over 2000 servers belonging to one of the top three cloud providers worldwide and targeted a client who was using a free CDN plan. However, due to Gcore's distribution of infrastructure and a large number of peering partners, the attacks were mitigated, and the client's web application remained available.

****Why was mitigating these attacks so significant?****

**1\. These attacks were significant because they exceeded the average bandwidth of similar attacks by 60×.** The performed attacks relate to volume-based attacks targeted to saturate the attacked application's bandwidth in order to overflow it. Measuring total volume (bps)—rather than the number of requests—is the way these attacks are usually tabulated.

The average bandwidth of this attack type is generally in the tens of Gbps (about 10 Gbps). Therefore, the specified attacks (at 650 Gbps) exceeded the average value by 60 times. Attacks of this volume are rare and are of particular interest to security experts.

Additionally, this value (650 Gbps) is comparable to the record DDoS attack on the largest Minecraft server (2.4 Tbps), only one-fourth as massive.

**2\. The client being attacked was using a CDN plan without additional DDoS protection.** When clients use Gcore's CDN (as part of the Edge Network), the malicious traffic of the L3/L4 attacks directly affects only its infrastructure (it serves as a filter), not the targeted clients' servers. The negative impact falls on the capacity and connectivity of the infrastructure When a CDN is powerful enough, it can protect clients against L3/L4 attacks—even when accessed using a free plan.

****What were the technical specifications of the attacks?****

The duration of the incident was 15 minutes, and at its peak, it reached over 650 Gbps. A possible reason why the incident took so long is that the attackers weighed the ineffectiveness of the attacks (the client application kept running) against their high cost.

The incident consisted of three attacks with different vectors. They are marked with traffic peaks on the diagram below:

1.  **UDP flood attack (~650 Gbps).** Hundreds of millions of UDP packets were sent to the target server to consume the bandwidth of the application and cause its unavailability. Attacks of this vector use a lack of requirements of UDP connection establishment: the attackers can send packets with any data (it increases the volume) and use spoofed IP addresses (it makes it difficult to find the sender).
2.  **TCP ACK flood attack (~600 Gbps).** A large number of packets with the ACK flag were sent to the target server to overflow it. Attacks of this vector are based on the fact that the junk TCP packets do not include a payload, but the server is forced to process them, and it may not have enough resources to handle requests from real end users. A CDN's protection system is capable of filtering packets and not forwarding them to the server if they do not contain payloads and are not bound to an open TCP session.
3.  **A mix of TCP and UDP (~600 Gbps).** A custom variation of the previous two types of attacks.

The distinctiveness of the incident was that the attacks were performed from multiple non-spoofed IP addresses. This allowed specialists to identify that the attackers used 2,143 servers in 44 different regions, and all of the servers belonged to a single public cloud provider. Utilizing Anycast allowed Gcore to absorb the attack 100% over peering connections with this provider.

Sankey diagram showing the source and flow of the attack. Names of the locations from the first column are associated with one of the top 3 cloud providers.

****Why did the attacks not affect the client?****

**1\. Gcore's connectivity through peering with many locations played a key role in mitigating the attacks.** Gcore has over 11,000 peering partners (ISPs), and these partners connect their networks using cables and provide each other with access to traffic originating from their networks. These connections allow for bypassing the public internet and directly absorbing traffic from the peering partners. Additionally, this traffic is either free of charge or costs much less than traffic on the public internet. This low cost makes it possible to protect customer traffic on a free plan.

In the context of the DDoS attack that occurred, the level of connectivity greatly benefited the efficacy of mitigation. Gcore and the cloud provider used to launch the attack are peering partners, so while the attack was happening, Gcore was able to ingest most of the traffic over the cloud provider's private network. This greatly reduced the amount of traffic that needed to be handled by the public internet.

Private peering also enables more accurate filtering and better attack visibility, which leads to more efficient attack mitigation.

**2\. Gcore's large capacity, due to the placement of servers in many data centers, also played a role.** Gcore's edge servers are present in over 140 points of presence and are based on high-performance 3rd generation Intel® Xeon® Scalable processors.

The overall network capacity is over 110 Tbps. With over 500 servers located in data centers worldwide, the company is able to withstand large-scale DDoS attacks. So, the 650 Gbps of traffic could be distributed across the network, and each particular server would only receive 1-2 Gbps, which is an insignificant load.

****Security trends****

According to Gcore's experience, DDoS attacks will continue to grow year over year. In 2021, the attacks reached 300 Gbps, and by 2022, they had increased to 700 Gbps. Therefore, even small and medium-sized businesses need to use distributed content delivery networks such as the CDN and Cloud to protect against DDoS attacks.

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

Gcore Thwarts Massive 650 Gbps DDoS Attack on Free Plan Client

Attribute-based encryption could help keep sensitive metadata off of the Dark Web.

Even before COVID-19 disrupted operations, organizations had accelerated their digital transformation initiatives to meet changing customer expectations. One sector that particularly embraced this shift is the healthcare sector, as organizations rapidly developed and adopted a range of digital health solutions, such as electronic health records and using artificial intelligence (AI) to aid drug discovery.

Healthcare is "an industry that had been moving forward with digitization under numerous different names and approaches well before the onset of COVID," says Guy Becker, director of healthcare products management at cybersecurity company Sasa Software. However, this rapid digitization has also resulted in a sharp spike in criminal cyberattacks on the healthcare industry.

Check Point reported a global increase in attacks on organizations between November and December 2020. The report showed a 137% increase in East Asia, a 112% rise in Latin America, 67% in Europe, and 37% in North American healthcare organizations. In recent years, there has been a dramatic increase in cybersecurity incidents in the healthcare sector, such as computer virus infections, ransomware, and the theft and publication of patient data.

The reality is grimmer today, especially when you consider that scanned medical documents and other healthcare images often contain sensitive data. NTT Research recently held a hackathon to find ways to use attribute-based encryption (ABE) to address that situation and others.

"Metadata stored within medical images, including X-rays and CT scans, can disclose confidential information, like patient names, photographed body parts, and the medical centers or physicians involved, leading to patient identification," explains Jean-Philippe Cabay, data scientist at NTT Global in Belgium, whose team won the hackathon. "Attribute-based encryption ensures that only authorized users with the appropriate attributes can access medical images, keeping them secure and private."

**Health Imaging Data Is a Hacker's Goldmine**

Hospitals and healthcare organizations are working to protect digital imaging and communications in medicine (DICOM) files, according to Becker. This development is a result of the convergence of several factors, increased attacks on healthcare due to its high value (worth at least 10 times more than credit card data on the Dark Web) and traditionally weak security posture, demand for heightened healthcare security by governments and the EU, increased need for remote healthcare services due to COVID, and a general digital transformation trend to streamline and digitize services.

In addition, the vulnerability presented by potentially malicious imaging files is enhanced by the growing risk of breached medical devices. For example, imaging machines operating within the hospital network can be compromised without the knowledge of the technicians and engineers looking after them. Such compromise could lead to malicious code being injected into clinical data and spread across a hospital's network. Because imaging clinics and medical centers often need to transfer imaging data, a breach of such transactions could expose sensitive patient data, with devastating consequences.

Becker says the protection of sensitive imaging networks begins with the standard recommended measures: network segmentation, timely backups, frequent updating of systems and applications, the use of advanced intrusion detection and prevention systems, and regular employee education and training.

Some of these measures pose particular challenges for healthcare organizations. Healthcare systems have to be online 24/7, which makes frequent updating — and rebooting, or taking machines offline — an impossible requirement to meet. Chronic understaffing, which frequently reduces staff compliance to the minimum clinical requirement, means nonhealthcare-related demands, such as cybersecurity, get pushed down to a distant second position, Becker says.

But in its recently concluded hackathon, NTT Research said its Belgian team successfully demonstrated "a groundbreaking application" of ABE to protect images. ABE was introduced in 2005 in a paper by Brent Waters, NTT's director of Cryptography and Information Security (CIS) Lab, and Amit Sahai, a professor of computer science at UCLA. It is a type of public-key encryption that allows for sharing data based on policies and attributes of the users — who the user is, rather than what they have.

**Protecting DICOM Images With ABE**

Essentially, ABE determines who can access data based on specific traits. ABE combines role-based encryption with content-based access and multi-authority access. For content-based access, ABE doesn't just determine who gets access to data, but also what specific data they are allowed to access. Thus a radiologist might be able to access a CT scan but not patient identity, whereas a records clerk would be able to access identity but not imaging. Multiauthority access could come into play when a patient sees a specialist — the primary care physician might issue the specialist credentials to view a patient's medical history, while a licensing board establishes credentials that allow them to write notes in that history; the specialist would need both sets of credentials to access the complete patient record.

The winning team's three-part demo involved detecting and labeling a graphical object, encrypting the images and mapping between labels and ABE policies, and storing the objects, the metadata, and the blurred images in a database. Cabay's coauthor, NTT senior software engineer Pascal Mathis, said their project uses an extract, transfer load (ETL) pipeline to transfer the images.

Mathis further explained that the AI component and encryption engine resides on an edge device, which sends only encrypted data to the database. Cabay says their project demonstrates how ABE can help to encrypt images in healthcare, such that "access is so locked-down that even the database administrator only sees images with blurred spots and encrypted information."

Other major providers of picture archiving and communications systems (PACS), such as Philips, GE, and Sectra, are advancing solutions for digitization and increased automation of the imaging workflow, as part of a general migration to cloud-based systems and an enhanced security posture. These systems feature native end-to-end encryption and robust backup and breach prevention capabilities inherent to cloud environments. However, the DICOM data itself is not examined and may well be harboring malicious content, Becker notes.

"Standard detection-based network security tools, such as EDRs, XDRs, and MDRs, currently lack the capability to scan and disinfect DICOM imaging data," he says. "It was this gap in security that moved us to develop, together with our healthcare partners, an imaging gateway that purifies the actual DICOM data stream itself."

As healthcare becomes increasingly reliant on technology for more efficiency, healthcare industry leaders must prioritize using tools that enable the secure remote transmission of imaging studies to the hospitals' PACS without incurring risk to the healthcare network.

How to Stop Attackers That Target Healthcare Imaging Data

By Waqas
Threat actors have hacked two data centers in Asia and accessed login credentials of top technology giants, including Apple, Uber, Microsoft, Samsung, Alibaba, etc., and leaked them on a hacker forum.
This is a post from HackRead.com Read the original post: Login Details of Tech Giants Leaked in Two Data Center Hacks

The leaked data includes email addresses, password hashes, names, phone numbers, and more.

Hackers obtained login credentials for several mainstream corporate giants, including Microsoft, Samsung, Uber and Apple, etc. and gained remote access to the entities’ surveillance cameras after attacking two data centers in Asia.

A screenshot from the leaked data shows login credentials for Samsung, Amazon, Uber, Alibaba and more. (Credit: Hackread.com)

This was **revealed** by the cyber security firm Resecurity. The company originally identified the data breach in September 2021; however, details of it were only revealed to the media now as on February 20th, 2023, hackers leaked the stolen login credentials online.

It is worth noting that these credentials were leaked on Breachforums by a threat actor going by the handle of “Minimalman.” For your information, Breachforums is a hacker and cybercrime forum that surfaced as an alternative to the popular and **now-seized Raidforums**.

According to Resecurity, hackers accessed two of the largest data center operators in Asia that were being used by several mainstream companies and technology giants. From there, the hackers could obtain customer support logins for high-profile companies, including Amazon and Apple, BMW, Microsoft, Alibaba, Walmart, Goldman Sachs, etc.

As seen by Hackread.com on the hacker forum, the threat actors managed to obtain and leak credentials from over 2,000 firms and a Chinese foreign-exchange platform.

The data centers have been identified as Shanghai-based GDS Holdings and Singapore-based ST Telemedia Global. Both data centers reportedly forced all customers to change their passwords in January 2023.

**Dangers**

The dangers of hackers obtaining login credentials of tech giants such as Apple, Amazon, Microsoft, Samsung and others are numerous and severe. Firstly, such credentials allow hackers to access sensitive customer data, including payment information and personal details, which can lead to **identity theft and financial fraud**.

Secondly, hackers can use these credentials to gain access to the company’s networks, potentially compromising intellectual property and trade secrets. Additionally, with access to company accounts, hackers can launch cyber attacks against other organizations, amplifying the damage caused by their actions.

Furthermore, a breach of a tech giant’s login credentials can have far-reaching consequences, impacting not only the company and its customers but the wider economy and society as a whole. For instance, if a company like Amazon were to suffer a significant data breach, it could lead to a loss of consumer trust, which could in turn affect the confidence of investors and the stock market.

Moreover, a successful hack of a tech giant’s credentials could inspire copycat attacks, leading to an escalation in cybercrime and potentially destabilizing the digital infrastructure that underpins much of our daily lives.

To mitigate these risks, tech giants must remain vigilant in their cybersecurity measures, ensuring that their systems are regularly updated and that their employees are trained to detect and prevent security breaches.

Companies must also invest in advanced technologies such as machine learning and artificial intelligence to detect and respond to cyber threats in real time. Finally, companies must ensure that they comply with industry standards and regulations related to cybersecurity, such as the General Data Protection Regulation (**GDPR**), to protect the privacy and security of their customers.

1.  **Sydney Data Center Targeted By FinFisher Spyware**
2.  **Hackers attack National Data Center with watering hole attack**
3.  **Hyperconverged Infrastructure (HCI) is Changing Data Centers**
4.  **Top sites affected after OVH data center catches disastrous fire**

I am a UK-based cybersecurity journalist with a passion for covering the latest happenings in cyber security and tech world. I am also into gaming, reading and investigative journalism

Login Details of Tech Giants Leaked in Two Data Center Hacks

Nation-state adversaries, new reporting regulations, and a fast-paced threat landscape mean that financial services and technology firms need to bolster their security posture.

The cybersecurity landscape for financial institutions and finance technology (fintech) has changed dramatically in the past few years, and 2023 will likely be no different.

In 2022, for example, distributed denial-of-service (DDoS) attacks targeting financial firms increased by 22% worldwide, compared to the previous year, according to a joint report published by the Financial Services Information Sharing and Analysis Center (FS-ISAC) and Internet infrastructure firm Akamai. Financial institutions in Europe saw an even greater jump, with 73% more DDoS attacks, the report stated.

While many businesses wave aside DDoS attacks as noise on the Internet, such tactics are increasingly used as a diversion tool, especially with geopolitical tensions running high, as they have since Russia invaded Ukraine, says Teresa Walsh, global head of intelligence at the FS-ISAC.

Financial institutions need to gauge "the potential for DDoS attacks to be used as a decoy for more damaging cyber activities, such as the infiltration of systems and the installation of malware," she says. "While DDoS attacks themselves tend to not cause large windows of downtime due to a wide array of standard defensive measures available to financial institutions, the same practices are not as readily available for DDoS used as a smokescreen."

The increase in DDoS attacks is just one area where financial services and fintech firms face an increasing level of threats. Driven by nation-state groups taking sides in the Russia-Ukraine war, ransomware is becoming more destructive, while attacks on financial data are increasingly a problem facing all types of organizations. In addition, attackers are using cybercriminal services — such as access brokers and ransomware-as-a-service — leading to more specialized and sophisticated operations against financial institutions and cryptocurrency services.

Regulations are also changing the cybersecurity landscape for financial firms, which must now — as of May 1, 2022 — disclose cyber incidents within 36 hours to their regulators in the United States, if the incident could impact the US banking system. At the same time, the recent ransomware attack on derivative service provider ION Group and the ongoing popularity of business email compromise (BEC) schemes shows the brittleness of the financial supply chain.

While financial firms have some of the best cybersecurity, attackers continue to find ways to succeed, says Tom Kellermann, senior vice president of cyber strategy at Contrast Security.

"They have invested much more than other industries in cybersecurity, they have the best technologies, and they have some of the very best people in the world," he says. "But they're being hunted by the most organized sophisticated cybercrime cartels in the world, coupled with intelligence services from rogue nation states who want to hack the sector — not just for the purposes of economic espionage, but to help offset economic sanctions."

**Geopolitics & Cybercriminal Specialization Spur Changes**

Two major forces are changing the overall cybersecurity landscape. Russia's invasion of Ukraine has led to a parallel cyberwar that, unlike the physical conflict, has spilled outside the boundaries of those two nations. The Russia-Ukraine conflict has led to a greater number of attackers focusing on destructive operations, in addition to stealing funds or deploying ransomware for profit.

More than half (54%) of financial firms interviewed by Contrast Security considered cyberattacks from Russia as the top threat, with a quarter naming North Korea as their top worry.

"The Russians are most concerning to these institutions because Russian cybercrime cartels are far more knowledgeable of, not only the financial sector in terms of how it operates and what is most valuable ... but also the interdependencies that exists in the sector," Kellermann says. "Which is why you're seeing that surge of attacks against APIs and an increase in island-hopping and watering hole attacks."

Overall, cyberattacks in the sector have become more sophisticated, with many traditionally standalone attacks now being used as part of more complex operations, with "as-a-service" models replacing some parts of the attack chain. Access brokers have become far more popular, as demonstrated by the growth of the Emotet malware-as-a-service operation, cybersecurity firm Kaspersky said in a list of cyberthreats targeting the financial services industry.

"These access broker cybercriminal groups, they are basically hacking as much as they can and then they are selling the access to us to anyone that wants to buy," Marc Rivero, a senior security research at Kaspersky, said during a presentation on the company's predications. "That allows other groups to spend less time compromising their targets."

Even company finance and accounting departments are seeing increased risks. More than a third of organizations (35%) had their accounting and financial data targeted by attackers in a cyber event in the past 12 months, and nearly half (49%) expect an increase in similar attacks in the next year, according to a survey conducted by consultancy Deloitte.

Increasingly, attackers are focusing on compromising financial transactions between corporate users and financial institutions, and between financial firms and their vendors, said Daniel Soo, a principal with Deloitte's risk and financial advisory group.

"These attackers are becoming a little bit more targeted, where they can get into some financials and see what's underlying each of these firms," he says. "And it's a little bit frightening, because by peering into the financials, you can learn a lot about organizations."

**More Regulations, Compliance Risks**

Financial institutions also have to deal with increasing regulations across multiple jurisdictions. Data breaches must be reported to European authorities to satisfy the General Data Protection Regulation (GDPR), and the United States is increasing oversight at both the state — led by California — and federal level. The American Data Privacy Protection Act (ADPPA) did not pass through Congress, but federal standards continue to progress, including a 36-hour reporting requirement for financial firms.

The increasing regulations means that any financial institution needs to build a holistic cyber resilience program to have the flexibility to meet changing regulations, particularly multinational institutions, says FS-ISAC's Walsh.

"This has been a major priority for many years now, so we expect few institutions to have to make dramatic changes to their cyber management or reporting infrastructure in response to regulation," she says.

Kellermann adds, "Plausible deniability is dead. They are just going to have to report now."

**Improvement Needed in Financial Security Posture**

While financial services firms typically lead the pack as adopters of cybersecurity, the fast pace of innovation in payment technologies requires financial institutions to quickly move to secure those technologies, according to Contrast Security's survey. In 2023, 72% of financial organizations plan to increase their investment in the security of their applications, while 64% mandated cybersecurity requirements for their vendors, the survey found.

In addition, the definition of cybersecurity and cybercrime is expanding to new categories. In a report released in January 2023, the Financial Industry Regulatory Authority (FINRA) added a new section for financial crimes in its cybersecurity and technology governance section.

For the most part, the financial industry needs to make its information infrastructure and processes more resilient — not only in resisting an attack, but also in the organization's ability to recover following an attack, says Deloitte's Soo. Currently, only 26% of companies have a process in place to estimate damages from specific types of cyber incidents, with another 17% aiming to put one in place in the next 12 months, Deloitte stated in its report.

"There's certainly going to be a disruption often related to some sort of cyber incident, and resilience is very much around 'how do you recover quickly in a very structured way'," Soo says. "How can you recover and how can you limit the blast radius, \[so\] you localize any type of damage?"

Cyberthreats, Regulations Mount for Financial Industry

Fintech has drastically shifted the financial services industry toward digital technologies and, in so doing, has introduced a variety of new risks.

As with every other sector that has embraced digital transformation, cybercrime has become a more prominent threat in finance. According to VMware's Modern Bank Heists study, since the COVID-19 pandemic, there have been 238% more cyberattacks on companies in the financial sector, a shocking rise.

The recent string of attacks on DeFi platforms shows clearly how fintech companies tend to be a big prize for bad actors. Fintech apps, especially, tend to offer the potential for massive payoffs. Attackers can also cause more damage by targeting users of the tech, who may implement less rigorous cybersecurity measures. One malicious app can strip fintech users of their assets and leave the fintech company with a reputation in shambles.

Fintech companies are having to rethink how they approach their identity and access control strategy to ensure that their platforms are equally trusted by both consumers and businesses. As this industry continues to adapt to the cloud, it's imperative that the proper controls be put in place to retain an organization's security posture — and this comes with its own array of challenges.

**Why Fintech Applications Are Hard to Secure**

Cloud development has made new types of apps possible and existing apps work better than ever. However, it has also generated new opportunities for misconfigurations, human error, and identity management issues, and it has rapidly expanded potential attack surfaces. Because fintech apps are leveraging a massive range of technologies, this continues to be one of the most challenging areas when it comes to security.

Whether moving a legacy app to a new and better cloud-based architecture or expanding existing capabilities, any type of change leaves an organization vulnerable at cloud scale. This can make the blast radius of a single attack much larger, since an infrastructure's attack surface now expands and is dynamic in the cloud.

Fintech applications also must meet tight regulatory standards that vary around the world, and often face steep fines for noncompliance. For example, in 2019, the Spanish DPA fined a financial service provider 1 million euros due to an insufficient legal basis for data processing, which violated General Data Protection Regulation (GDPR). Operating in the financial realm means providing a higher level of accountability to customers and across the industry, which can be a tall order. Fintech demands that organizations ensure visibility, reliability, and correct configuration.

To stay competitive in this very crowded arena, fintech companies need to keep a tight grip on security and privacy from day one of development, especially as third-party services continue to grow.

**How Third-Party Services Can Increase Security Challenges**

As fintech organizations become more dependent on vendors and other partners such as manufacturers, suppliers, and subcontractors, as well as increasingly complex supply chains, they also become more exposed to attackers. Respondents from CRA Business Intelligence's recent Third-Party Risk Survey believe that third parties are increasingly the cause of IT security incidents, with more than half of all respondents (57%) reporting they were victims of an IT security incident — either an attack or a breach — related to a third-party partner in the past 24 months.

Organizations often lack visibility into third- and fourth-party partners, and with that, the vast scope of data accessible to them. In today's software-centric world, interoperability is essential, but it often leaves organizations even more vulnerable to attackers. Fintech developers must remain constantly alert for potential software supply chain issues and the security challenges third-party services can bring to their organizations.

**Remaining Compliant Amid Tight Regulatory Standards**

In direct response to recent high-profile cases of fraud within cryptocurrency, regulators are beginning to pay even closer attention on the already highly regulated space, creating a challenge for fintech applications and companies to stay on the pulse of these changes and remain compliant and protective of their sensitive information. According to Gartner's Fintech in 2022 Report, fintech leaders ranked regulatory challenges as the top threat to their business right now.

In the midst of these shifting regulations and requirements that vary around the world, including Payment Card Industry Data Security Standards (PCI-DSS), Anti-Money Laundering (AML)/ Know Your Customer (KYC), and newly established California Privacy Rights Act (CPRA) regulations, companies are being pushed to button up their data protection and privacy standards. So, how can businesses remain compliant?

Every enterprise must know who has access to the data and applications, their location, and what they do with it. As threats continue to grow exponentially within fintech, implementing identity and access management (IAM) tools will be essential.

It's important for an enterprise to have the proper technology and processes in place to not only ensure they remain compliant with industry regulations, but also provide consistent protection for their sensitive data, especially in the cloud. IAM tools, for example, provide organizations security that won't slow down development or add more work for their teams.

The security threats posed by financially motivated cybercriminals will unfortunately only become increasingly sophisticated. The fintech industry is faced with much pressure to protect sensitive customer data and needs to be prepared for cyber threats by establishing a proactive security posture and robust identity and access management strategy that can handle the complexity and scale of today's cloud security challenges.

Third-Party Providers Create Identity and Access Control Challenges for Fintech Apps

Red Hat Security Advisory 2023-0832-01 - The kernel packages contain the Linux kernel, the core of any Linux operating system. Issues addressed include buffer overflow, null pointer, and use-after-free vulnerabilities.

-----BEGIN PGP SIGNED MESSAGE-----  
Hash: SHA256

====================================================================                     
Red Hat Security Advisory

Synopsis:          Important: kernel security and bug fix update  
Advisory ID:       RHSA-2023:0832-01  
Product:           Red Hat Enterprise Linux  
Advisory URL:      https://access.redhat.com/errata/RHSA-2023:0832  
Issue date:        2023-02-21  
CVE Names:         CVE-2022-2873 CVE-2022-41222 CVE-2022-43945  
====================================================================  
1. Summary:

An update for kernel is now available for Red Hat Enterprise Linux 8.

Red Hat Product Security has rated this update as having a security impact  
of Important. A Common Vulnerability Scoring System (CVSS) base score,  
which gives a detailed severity rating, is available for each vulnerability  
from the CVE link(s) in the References section.

2. Relevant releases/architectures:

Red Hat CodeReady Linux Builder (v. 8) - aarch64, ppc64le, x86_64  
Red Hat Enterprise Linux BaseOS (v. 8) - aarch64, noarch, ppc64le, s390x, x86_64

3. Description:

The kernel packages contain the Linux kernel, the core of any Linux  
operating system.

Security Fix(es):

* kernel: mm/mremap.c use-after-free vulnerability (CVE-2022-41222)

* kernel: nfsd buffer overflow by RPC message over TCP with garbage data  
(CVE-2022-43945)

* kernel: an out-of-bounds vulnerability in i2c-ismt driver (CVE-2022-2873)

For more details about the security issue(s), including the impact, a CVSS  
score, acknowledgments, and other related information, refer to the CVE  
page(s) listed in the References section.

Bug Fix(es):

* WARNING: CPU: 116 PID: 3440 at arch/x86/mm/extable.c:105  
ex_handler_fprestore+0x3f/0x50 (BZ#2134586)

* Hardware error: RIP: copy_user_enhanced_fast_string+0xe (BZ#2137592)

* Cannot trigger kernel dump using NMI on SNO node running PAO and RT  
kernel (BZ#2139580)

* MEI support for Alder Lake-S (BZ#2141783)

* Host Pod -> Cluster IP Service traffic (Pod Backend - Different Node)  
Flow Iperf Cannot Connect (BZ#2141959)

* RHEL8.7: Xorg cannot display resolution higher than 1024x768 on system  
using ast graphics driver (BZ#2149287)

* Intel 8.7 Bug: OS doesn't boot when vmd and interrupt remapping are  
enabled (BZ#2149474)

* i40e,iavf: SR-IOV VF devices send GARP with wrong MAC address  
(BZ#2149745)

* RHEL8.4 - boot: Add secure boot trailer (BZ#2151530)

* error 524 from seccomp(2) when trying to load filter (BZ#2152138)

* Workqueue: WQ_MEM_RECLAIM iscsi_ctrl_1:98 __iscsi_unbind_session  
[scsi_transport_iscsi] (BZ#2152734)

* Connectivity issue with vDPA driver (BZ#2152912)

* High Load average due to cfs cpu throttling (BZ#2153108)

* The "kernel BUG at mm/usercopy.c:103!" from BZ 2041529 is back on  
rhel-8.5 (BZ#2153230)

* RHEL8: tick storm on nohz (isolated) CPU cores (BZ#2153653)

* kernel BUG: scheduling while atomic: crio/7295/0x00000002 (BZ#2154460)

* Azure RHEL 8 z-stream: Sometimes newly deployed VMs are not getting  
accelerated network during provisioning (BZ#2155272)

* Azure: VM Deployment Failures Patch Request (BZ#2155280)

* Azure vPCI RHEL-8: add the support of multi-MSI (BZ#2155289)

* MSFT MANA NET Patch RHEL-8: Fix race on per-CQ variable napi_iperf panic  
fix (BZ#2155437)

* GSS: OCP 4.10.30 node crash after ODF upgrade : unable to handle kernel  
NULL pointer dereference at 0000000000000000 :  
ceph_get_snap_realm+0x68/0xa0 [ceph] (BZ#2155797)

* Error in /usr/src/kernels/4.18.0-423.el8.x86_64/scripts/kernel-doc script  
causing irdma build to fail (BZ#2157905)

* RHEL8.8: Backport upstream patches to reduce memory cgroup memory  
consumption and OOM problem (BZ#2157922)

* The 'date' command shows wrong time in nested KVM s390x guest  
(BZ#2158813)

* ethtool -m results in an out-of-bounds slab write in the be2net driver  
(BZ#2160182)

* (Redhat OpenShift)Error downloading big ZIP files inside pod on power OCP  
and pod getting restarted (BZ#2160221)

* i40e/iavf: VF reset task fails "Never saw reset" with 5 second timeout  
per VF (BZ#2160460)

* iavf: It takes long time to create multiple VF interfaces and the VF  
interface names are not consistent (BZ#2163257)

4. Solution:

For details on how to apply this update, which includes the changes  
described in this advisory, refer to:

https://access.redhat.com/articles/11258

The system must be rebooted for this update to take effect.

5. Bugs fixed (https://bugzilla.redhat.com/):

2119048 - CVE-2022-2873 kernel: an out-of-bounds vulnerability in i2c-ismt driver  
2138818 - CVE-2022-41222 kernel: mm/mremap.c use-after-free vulnerability  
2141752 - CVE-2022-43945 kernel: nfsd buffer overflow by RPC message over TCP with garbage data

6. Package List:

Red Hat Enterprise Linux BaseOS (v. 8):

Source:  
kernel-4.18.0-425.13.1.el8_7.src.rpm

aarch64:  
bpftool-4.18.0-425.13.1.el8_7.aarch64.rpm  
bpftool-debuginfo-4.18.0-425.13.1.el8_7.aarch64.rpm  
kernel-4.18.0-425.13.1.el8_7.aarch64.rpm  
kernel-core-4.18.0-425.13.1.el8_7.aarch64.rpm  
kernel-cross-headers-4.18.0-425.13.1.el8_7.aarch64.rpm  
kernel-debug-4.18.0-425.13.1.el8_7.aarch64.rpm  
kernel-debug-core-4.18.0-425.13.1.el8_7.aarch64.rpm  
kernel-debug-debuginfo-4.18.0-425.13.1.el8_7.aarch64.rpm  
kernel-debug-devel-4.18.0-425.13.1.el8_7.aarch64.rpm  
kernel-debug-modules-4.18.0-425.13.1.el8_7.aarch64.rpm  
kernel-debug-modules-extra-4.18.0-425.13.1.el8_7.aarch64.rpm  
kernel-debuginfo-4.18.0-425.13.1.el8_7.aarch64.rpm  
kernel-debuginfo-common-aarch64-4.18.0-425.13.1.el8_7.aarch64.rpm  
kernel-devel-4.18.0-425.13.1.el8_7.aarch64.rpm  
kernel-headers-4.18.0-425.13.1.el8_7.aarch64.rpm  
kernel-modules-4.18.0-425.13.1.el8_7.aarch64.rpm  
kernel-modules-extra-4.18.0-425.13.1.el8_7.aarch64.rpm  
kernel-tools-4.18.0-425.13.1.el8_7.aarch64.rpm  
kernel-tools-debuginfo-4.18.0-425.13.1.el8_7.aarch64.rpm  
kernel-tools-libs-4.18.0-425.13.1.el8_7.aarch64.rpm  
perf-4.18.0-425.13.1.el8_7.aarch64.rpm  
perf-debuginfo-4.18.0-425.13.1.el8_7.aarch64.rpm  
python3-perf-4.18.0-425.13.1.el8_7.aarch64.rpm  
python3-perf-debuginfo-4.18.0-425.13.1.el8_7.aarch64.rpm

noarch:  
kernel-abi-stablelists-4.18.0-425.13.1.el8_7.noarch.rpm  
kernel-doc-4.18.0-425.13.1.el8_7.noarch.rpm

ppc64le:  
bpftool-4.18.0-425.13.1.el8_7.ppc64le.rpm  
bpftool-debuginfo-4.18.0-425.13.1.el8_7.ppc64le.rpm  
kernel-4.18.0-425.13.1.el8_7.ppc64le.rpm  
kernel-core-4.18.0-425.13.1.el8_7.ppc64le.rpm  
kernel-cross-headers-4.18.0-425.13.1.el8_7.ppc64le.rpm  
kernel-debug-4.18.0-425.13.1.el8_7.ppc64le.rpm  
kernel-debug-core-4.18.0-425.13.1.el8_7.ppc64le.rpm  
kernel-debug-debuginfo-4.18.0-425.13.1.el8_7.ppc64le.rpm  
kernel-debug-devel-4.18.0-425.13.1.el8_7.ppc64le.rpm  
kernel-debug-modules-4.18.0-425.13.1.el8_7.ppc64le.rpm  
kernel-debug-modules-extra-4.18.0-425.13.1.el8_7.ppc64le.rpm  
kernel-debuginfo-4.18.0-425.13.1.el8_7.ppc64le.rpm  
kernel-debuginfo-common-ppc64le-4.18.0-425.13.1.el8_7.ppc64le.rpm  
kernel-devel-4.18.0-425.13.1.el8_7.ppc64le.rpm  
kernel-headers-4.18.0-425.13.1.el8_7.ppc64le.rpm  
kernel-modules-4.18.0-425.13.1.el8_7.ppc64le.rpm  
kernel-modules-extra-4.18.0-425.13.1.el8_7.ppc64le.rpm  
kernel-tools-4.18.0-425.13.1.el8_7.ppc64le.rpm  
kernel-tools-debuginfo-4.18.0-425.13.1.el8_7.ppc64le.rpm  
kernel-tools-libs-4.18.0-425.13.1.el8_7.ppc64le.rpm  
perf-4.18.0-425.13.1.el8_7.ppc64le.rpm  
perf-debuginfo-4.18.0-425.13.1.el8_7.ppc64le.rpm  
python3-perf-4.18.0-425.13.1.el8_7.ppc64le.rpm  
python3-perf-debuginfo-4.18.0-425.13.1.el8_7.ppc64le.rpm

s390x:  
bpftool-4.18.0-425.13.1.el8_7.s390x.rpm  
bpftool-debuginfo-4.18.0-425.13.1.el8_7.s390x.rpm  
kernel-4.18.0-425.13.1.el8_7.s390x.rpm  
kernel-core-4.18.0-425.13.1.el8_7.s390x.rpm  
kernel-cross-headers-4.18.0-425.13.1.el8_7.s390x.rpm  
kernel-debug-4.18.0-425.13.1.el8_7.s390x.rpm  
kernel-debug-core-4.18.0-425.13.1.el8_7.s390x.rpm  
kernel-debug-debuginfo-4.18.0-425.13.1.el8_7.s390x.rpm  
kernel-debug-devel-4.18.0-425.13.1.el8_7.s390x.rpm  
kernel-debug-modules-4.18.0-425.13.1.el8_7.s390x.rpm  
kernel-debug-modules-extra-4.18.0-425.13.1.el8_7.s390x.rpm  
kernel-debuginfo-4.18.0-425.13.1.el8_7.s390x.rpm  
kernel-debuginfo-common-s390x-4.18.0-425.13.1.el8_7.s390x.rpm  
kernel-devel-4.18.0-425.13.1.el8_7.s390x.rpm  
kernel-headers-4.18.0-425.13.1.el8_7.s390x.rpm  
kernel-modules-4.18.0-425.13.1.el8_7.s390x.rpm  
kernel-modules-extra-4.18.0-425.13.1.el8_7.s390x.rpm  
kernel-tools-4.18.0-425.13.1.el8_7.s390x.rpm  
kernel-tools-debuginfo-4.18.0-425.13.1.el8_7.s390x.rpm  
kernel-zfcpdump-4.18.0-425.13.1.el8_7.s390x.rpm  
kernel-zfcpdump-core-4.18.0-425.13.1.el8_7.s390x.rpm  
kernel-zfcpdump-debuginfo-4.18.0-425.13.1.el8_7.s390x.rpm  
kernel-zfcpdump-devel-4.18.0-425.13.1.el8_7.s390x.rpm  
kernel-zfcpdump-modules-4.18.0-425.13.1.el8_7.s390x.rpm  
kernel-zfcpdump-modules-extra-4.18.0-425.13.1.el8_7.s390x.rpm  
perf-4.18.0-425.13.1.el8_7.s390x.rpm  
perf-debuginfo-4.18.0-425.13.1.el8_7.s390x.rpm  
python3-perf-4.18.0-425.13.1.el8_7.s390x.rpm  
python3-perf-debuginfo-4.18.0-425.13.1.el8_7.s390x.rpm

x86_64:  
bpftool-4.18.0-425.13.1.el8_7.x86_64.rpm  
bpftool-debuginfo-4.18.0-425.13.1.el8_7.x86_64.rpm  
kernel-4.18.0-425.13.1.el8_7.x86_64.rpm  
kernel-core-4.18.0-425.13.1.el8_7.x86_64.rpm  
kernel-cross-headers-4.18.0-425.13.1.el8_7.x86_64.rpm  
kernel-debug-4.18.0-425.13.1.el8_7.x86_64.rpm  
kernel-debug-core-4.18.0-425.13.1.el8_7.x86_64.rpm  
kernel-debug-debuginfo-4.18.0-425.13.1.el8_7.x86_64.rpm  
kernel-debug-devel-4.18.0-425.13.1.el8_7.x86_64.rpm  
kernel-debug-modules-4.18.0-425.13.1.el8_7.x86_64.rpm  
kernel-debug-modules-extra-4.18.0-425.13.1.el8_7.x86_64.rpm  
kernel-debuginfo-4.18.0-425.13.1.el8_7.x86_64.rpm  
kernel-debuginfo-common-x86_64-4.18.0-425.13.1.el8_7.x86_64.rpm  
kernel-devel-4.18.0-425.13.1.el8_7.x86_64.rpm  
kernel-headers-4.18.0-425.13.1.el8_7.x86_64.rpm  
kernel-modules-4.18.0-425.13.1.el8_7.x86_64.rpm  
kernel-modules-extra-4.18.0-425.13.1.el8_7.x86_64.rpm  
kernel-tools-4.18.0-425.13.1.el8_7.x86_64.rpm  
kernel-tools-debuginfo-4.18.0-425.13.1.el8_7.x86_64.rpm  
kernel-tools-libs-4.18.0-425.13.1.el8_7.x86_64.rpm  
perf-4.18.0-425.13.1.el8_7.x86_64.rpm  
perf-debuginfo-4.18.0-425.13.1.el8_7.x86_64.rpm  
python3-perf-4.18.0-425.13.1.el8_7.x86_64.rpm  
python3-perf-debuginfo-4.18.0-425.13.1.el8_7.x86_64.rpm

Red Hat CodeReady Linux Builder (v. 8):

aarch64:  
bpftool-debuginfo-4.18.0-425.13.1.el8_7.aarch64.rpm  
kernel-debug-debuginfo-4.18.0-425.13.1.el8_7.aarch64.rpm  
kernel-debuginfo-4.18.0-425.13.1.el8_7.aarch64.rpm  
kernel-debuginfo-common-aarch64-4.18.0-425.13.1.el8_7.aarch64.rpm  
kernel-tools-debuginfo-4.18.0-425.13.1.el8_7.aarch64.rpm  
kernel-tools-libs-devel-4.18.0-425.13.1.el8_7.aarch64.rpm  
perf-debuginfo-4.18.0-425.13.1.el8_7.aarch64.rpm  
python3-perf-debuginfo-4.18.0-425.13.1.el8_7.aarch64.rpm

ppc64le:  
bpftool-debuginfo-4.18.0-425.13.1.el8_7.ppc64le.rpm  
kernel-debug-debuginfo-4.18.0-425.13.1.el8_7.ppc64le.rpm  
kernel-debuginfo-4.18.0-425.13.1.el8_7.ppc64le.rpm  
kernel-debuginfo-common-ppc64le-4.18.0-425.13.1.el8_7.ppc64le.rpm  
kernel-tools-debuginfo-4.18.0-425.13.1.el8_7.ppc64le.rpm  
kernel-tools-libs-devel-4.18.0-425.13.1.el8_7.ppc64le.rpm  
perf-debuginfo-4.18.0-425.13.1.el8_7.ppc64le.rpm  
python3-perf-debuginfo-4.18.0-425.13.1.el8_7.ppc64le.rpm

x86_64:  
bpftool-debuginfo-4.18.0-425.13.1.el8_7.x86_64.rpm  
kernel-debug-debuginfo-4.18.0-425.13.1.el8_7.x86_64.rpm  
kernel-debuginfo-4.18.0-425.13.1.el8_7.x86_64.rpm  
kernel-debuginfo-common-x86_64-4.18.0-425.13.1.el8_7.x86_64.rpm  
kernel-tools-debuginfo-4.18.0-425.13.1.el8_7.x86_64.rpm  
kernel-tools-libs-devel-4.18.0-425.13.1.el8_7.x86_64.rpm  
perf-debuginfo-4.18.0-425.13.1.el8_7.x86_64.rpm  
python3-perf-debuginfo-4.18.0-425.13.1.el8_7.x86_64.rpm

These packages are GPG signed by Red Hat for security.  Our key and  
details on how to verify the signature are available from  
https://access.redhat.com/security/team/key/

7. References:

https://access.redhat.com/security/cve/CVE-2022-2873  
https://access.redhat.com/security/cve/CVE-2022-41222  
https://access.redhat.com/security/cve/CVE-2022-43945  
https://access.redhat.com/security/updates/classification/#important

8. Contact:

The Red Hat security contact is <secalert@redhat.com>. More contact  
details at https://access.redhat.com/security/team/contact/

Copyright 2023 Red Hat, Inc.  
-----BEGIN PGP SIGNATURE-----  
Version: GnuPG v1

iQIVAwUBY/S5A9zjgjWX9erEAQhBpA//VkylLhtaxlPm0/2zyTgGV7ZzCOtuW9q6  
b9NL6MWgVuxi6zPLs2hl/ICeMJUgRrfkrGnH2Zgbmz8IXMaZV0I3NGnqkChpTiZn  
xxjxTsT7pRRRoH+ABhVVkWUANpBX8TANOwsQ6Go1H+Oiq/QNUAko/VTHLvbSFnn3  
ZhfAcQj/nTmaGMKLm4yIgmRCoEjH1DuA7OLVM28A6/RbrWH4mdc8Z+PUxGcFLzb2  
2/UH2O/ofoK+CMJzeovM9eDb/TUheDJJO9Ina6bu/g244LeIowrbDT6utbzp2N5G  
xXxfpruNNhDj7JQYdm17JEQEILe9LfOc3l6m3qOVndFCWKMZTY8QKam7uwevOOpV  
h8vDG1rtX4nPGJ0uD4mPcecUC6RBsi/QRXK95nAs+tx9cVtHQu5k62fbZe/7uG62  
fXz69aRlQ1YrHgq2bsddvYGjBK2Wfwm2jZlhPtws08TlnjCJLwNbI1xl0r+vksa6  
f1H26FKD8bX51sKEa0adHuNIjO/OUc/f3MVTWNaffj+kKqWRvnJt3L8hjL2BttRo  
ZUXVqMPoz8xT0wkymVvmkLSH9fY9q+JTnozjmJST6TlRBw1fmJhJHhvn6nsY5ftG  
1vDJJP1giFevpZYRbeW5TW3/PoD057vWJrutyjBc5D82UWqVY44Kzeca7eyUaBlk  
fe0d+/U6+Is=/2vf  
-----END PGP SIGNATURE-----  
--  
RHSA-announce mailing list  
RHSA-announce@redhat.com  
https://listman.redhat.com/mailman/listinfo/rhsa-announce

Tag

#intel