The bug allows unauthenticated code execution on the company's firewall products, and CISA says it poses "significant risk" to federal government.

The US Cybersecurity and Infrastructure Security Agency (CISA) is warning that a critical Zoho ManageEngine remote code execution (RCE) flaw, first disclosed in June, is now under active attack. 

According to Zoho's patch advisory, the bug "could allow remote attackers to execute arbitrary code on affected installations." 

Multiple Zoho ManageEngine products are affected, CISA said, including the Zoho ManageEngine PAM360, Password Manager Pro, and Access Manager Plus. 

Authentication is not required to exploit the vulnerability in Password Manager Pro and PAM360 products, Zoho added.

CISA has moved to add the Zoho ManageEngine bug to the Known Exploited Vulnerabilities catalog, which indicates the bug (CVE-2022-35405) is both under active exploit and poses a threat to the federal government's systems. 

CISA advises federal agencies to apply the vendor patch immediately. 

Keep up with the latest cybersecurity threats, newly-discovered vulnerabilities, data breach information, and emerging trends. Delivered daily or weekly right to your email inbox.

Subscribe

CISA: Zoho ManageEngine RCE Bug Is Under Active Exploit

Cybercriminals took control of enterprise Exchange Servers to spread large amounts of spam aimed at signing people up for bogus subscriptions.

Attackers are deploying malicious OAuth applications on compromised cloud tenants, with the goal of taking over Microsoft Exchange Servers to spread spam.  

That's according to the Microsoft 365 Defender Research Team, which detailed this week how credential-stuffing attacks have been launched against high-risk accounts that don’t have multifactor authentication (MFA) enabled, then leveraging unsecured administrator accounts to gain initial access.

The attackers were subsequently able to create a malicious OAuth app, which added a malicious inbound connector in the email server.

**Modified Server Access**

"These modifications to the Exchange server settings allowed the threat actor to perform their primary goal in the attack: sending out spam emails," the researchers noted in a blog post on Sept. 22. "The spam emails were sent as part of a deceptive sweepstakes scheme meant to trick recipients into signing up for recurring paid subscriptions."

The research team concluded that the hacker's motive was to spread misleading spam messages about sweepstakes, inducing victims to hand over credit card information to enable a recurring subscription that would offer them "the chance to win a prize."

"While the scheme likely resulted in unwanted charges to targets, there was no evidence of overt security threats such as credential phishing or malware distribution," the research team noted.

The post also pointed out that a growing population of malicious actors have been deploying OAuth applications for various campaigns, from backdoors and phishing attacks to command-and-control (C2) communication and redirections.

Microsoft recommended implementing security practices like MFA that strengthen account credentials, as well as conditional access policies and continuous access evaluation (CAE).

"While the follow-on spam campaign targets consumer email accounts, this attack targets enterprise tenants to use as infrastructure for this campaign," the research team added. "This attack thus exposes security weaknesses that could be used by other threat actors in attacks that could directly impact affected enterprises."

**MFA Can Help, but Additional Access Control Policies Required**

“While MFA is a great start and could have helped Microsoft in this case, we have seen in the news recently that not all MFA is the same," notes David Lindner, CISO at Contrast Security. "As a security organization, it is time we start from 'the username and password is compromised' and build controls around that."

Lindner says the security community needs to start with some basics and follow the principle of least privilege to create appropriate, business-driven, role-based access control policies.

"We need to set appropriate technical controls like MFA — FIDO2 as your best option — device-based authentication, session timeouts, and so on," he adds.

Lastly, organizations need to monitor for anomalies such as "impossible logins" (i.e., login attempts to the same account from, say, Boston and Dallas, that are 20 minutes apart); brute-force attempts; and user attempts to access unauthorized systems.

"We can do it, and we can greatly increase the security posture of an organization overnight by tightening our authentication mechanisms,” Lindner says.

Cyberattackers Compromise Microsoft Exchange Servers via Malicious OAuth Apps

Manufacturers need to document a medical device's intended use and operational environment, as well as plan for misuse, such as a cyberattack.

Due to the increasing concerns about medical devices' cybersecurity risks, European Union regulators put forward a new set of market entry requirements for medical devices and in vitro diagnostic medical devices to reduce the risk of patient harm as a result of a cyber incident, as well as protect national health systems.

EU regulators are raising the bar on cybersecurity requirements with the European Union Medical Device Regulation (MDR) and the European Union In Vitro Diagnostic Regulation (IVDR), which went into effect May 26, 2021. The regulations are intended to "establish a robust, transparent, predictable and sustainable regulatory framework ... which ensures a high level of safety and health whilst supporting innovation."

Organizations have until May 26, 2024, or when their current market certification expires, to make the necessary changes to their quality management systems and technical documentation to comply with the new requirements. Despite the number of assessment processes and standards and guidance documents that have been provided, medical device manufacturers, providers, and certification services may not be ready in time.

More than 90% of currently valid AIMDD/MDD certificates will expire by 2024, so a significant number of existing devices need to be reapproved, in addition to new devices entering the market. It is estimated that 85% of products currently on the market today still require new certification under MDR.IVDR. Considering that the process takes 13 to 18 months, companies need to start the process now in order to meet the 2024 deadline.

**Setting Instructions for Use**

In general, cybersecurity processes are not that different from general device performance and safety processes. The goal is to assure (through verification and validation) and demonstrate (through documentation) device performance, risk reduction and control, and minimization of foreseeable risks and undesirable side effects through risk management. Combination products or interconnected devices/systems also require management of the risks that result from interaction between software and the IT environment.

The Medical Device Coordination Group's MDCG-16 Guidance on Cybersecurity for medical devices explains how to interpret and fulfill cybersecurity requirements under MDR and IVDR. Manufacturers are expected to take into account the principles of the secure development life cycle, security risk management, and verification and validation. Further, they should provide minimum IT requirements and expectations for cybersecurity processes, such as installation and maintenance in their device's instructions for use. "Instructions for use" is a highly structured required section of the certification application manufacturers must file.

Cybersecurity measures must reduce any risks associated with the operation of medical devices, including cybersecurity-induced safety risks, to provide a high level of protection for health and safety. The International Electrotechnical Commission (IEC) spells out high-level security features, best practices, and security levels in IEC/TIR 60601-4-5. Another IEC technical report, IEC 80001-2-2, enumerates specific design and architecture security capabilities, such as automatic logoff, audit controls, data backup and disaster recovery, malware detection/protection, and system and OS hardening.

To meet ISO guidelines (ISO 14971), the Association for the Advancement of Medical Instrumentation advises striking a balance between safety and security. Careful analysis is required to prevent security measures from compromising safety and safety measures from becoming a security risk. Security needs to be right-sized and should be neither too weak nor too restrictive.

**Sharing Responsibility for Cybersecurity**

Cybersecurity is a responsibility shared between the device manufacturer and the deploying organization (typically the customer/operator). Thus, specific roles that provide important cybersecurity functions — such as integrator, operator, healthcare and medical professionals, and patients and consumers — require careful training and documentation.

The "instructions for use" section of a manufacturer's certification application should provide cybersecurity processes including security configuration options, product installation, initial configuration guidelines (e.g., change of default password), instructions for deploying security updates, procedures for using the medical device in failsafe mode (e.g., enter/exit failsafe mode, performance restrictions in fail-safe mode, and data recovery function when resuming normal operation), and action plans for the user in case of an alert message.

That section should also provide user requirements for training and enumerate required skills, including IT skills required for the installation, configuration, and operation of the medical device. In addition, it should specify requirements for the operating environment (hardware, network characteristics, security controls, etc.) that cover assumptions on the environment of use, risks for device operation outside the intended operating environment, minimum platform requirements for the connected medical device, recommended IT security controls, and backup and restore features for both data and configuration settings.

Specific security information may be shared through documentation other than the instructions for use, such as instructions for administrators or security operation manuals. Such information may include a list of IT security controls included in the medical device, provisions to ensure integrity/validation of software updates and security patches, technical properties of hardware components, the software bill of materials, user roles and associated access privileges/permissions on the device, logging function, guidelines on security recommendations, requirements for integrating the medical device into a health information system, and a list of the network data streams (protocol types, origin/destination of data streams, addressing scheme, etc.).

If the operating environment is not exclusively local but involves external hosting providers, the documentation must clearly state what, where (in consideration of data-residency laws), and how data is stored, as well as any security controls to safeguard the data in the cloud environment (e.g., encryption). The instructions for use section of the documentation needs to provide specific configuration requirements for the operating environment, such as firewall rules (ports, interfaces, protocols, addressing schemes, etc.).

Security controls implemented during premarket activities may be inadequate to maintain an acceptable benefit-risk level during the operational life of the device. Therefore, regulations require the manufacturer to establish a post-market cybersecurity surveillance program to monitor operation of the device in the intended environment; to share and disseminate cybersecurity information and knowledge of cybersecurity vulnerabilities and threats across multiple sectors; to perform vulnerability remediation; and to plan for incident response.

The manufacturer is further responsible for investigating and reporting serious incidents and fielding safety corrective actions. Specifically, incidents that have cybersecurity-related root causes are subject to trend reporting, including any statistically significant increase in the frequency or severity of incidents.

**Planning for All Scenarios**

Today's medical devices are highly integrated and operate in a complex network of devices and systems, many of which may not be under control of the device operator. Therefore, manufacturers should carefully document the device's intended use and intended operational environment, as well as plan for reasonably foreseeable misuse, such as a cyberattack.

Cybersecurity pre- and post-market risk management requirements and supporting activities are not necessarily different from traditional safety programs. However, they do add an additional level of complexity as:

*   The range of risks to consider is more complex (safety, privacy, operations, business). 
*   They require a specific set of activities that need to be conducted along the device development life cycle via a Secure Product Development Framework (SPDF).

Global regulators, including MDR/IVDR, are starting to enforce a higher level of security for medical devices and specifically requiring demonstrable security as part of the larger device life cycle. Devices should meet, based on device type and use case, a security baseline, and manufacturers need to maintain that baseline over the entire lifetime of the device.

How Europe Is Using Regulations to Harden Medical Devices Against Attack

From creating a software bill of materials for applications your company uses to supporting open source projects and maintainers, businesses need to step up their efforts to help reduce risks.

Software is at the core of all modern businesses and is crucial in every aspect of operations. Almost every business will use open source software, knowingly or otherwise, since even proprietary software depends on open source libraries. OpenUK's 2022 "State of Open" report found that 89% of businesses were relying on open source software, but not all of them are clear on the details of the software they rely on.

Businesses are increasingly demanding more information about their operation-critical software. Responsible businesses are taking a detailed interest in their software supply chain and creating a software bill of materials (SBOM) for each application. This level of information is crucial so that when security flaws are identified in their software, they can immediately be certain which software and versions are in use, and which systems are affected. Knowledge is power in these situations!

**Reliance on Volunteers**

In late 2021, a security vulnerability called Log4Shell was identified in a widely used Java logging framework, Log4j. Since this is a widely used, open source library, the vulnerability was well-publicized, and fixes were expected. However, the maintainers of the project were volunteers. They had day jobs and were not on call for urgent security fixes, even if a large number of systems were affected. This vulnerability alone was estimated to have affected 93% of enterprise cloud environments.

At the time, there was some negative press about open source, but the truth is that if this was a closed-source component, the vulnerability may never have been publicly known, leaving organizations open to attack. The open source nature of the library meant that it could be inspected, the problems found, and advice offered by others. So, yes, the maintainers weren't on call for security problems in their volunteer project. The big question, then, is: How did we get into a situation where major companies were depending on software that was the responsibility of someone who does something else to pay their bills?

Neglect of software dependencies is a risky business whatever the license of the software, but when it's open source and very widely used, it becomes especially dangerous. Sticking with the story of one vulnerability; the problem had existed in the codebase for years, but wasn't spotted. The tool that was so widely used was not, in fact, so widely supported — and what happened next is history.

This story is repeated over and over, across so many businesses that have critical dependencies but don't take action to support either the maintainers or the projects themselves. Having an SBOM for the software used by a business means they have the information on hand. For organizations that supply software to others, the expectation of supplying the SBOM alongside the code is increasingly the norm.

**Know Dependencies to Assess Risk**

Bringing knowledge of the dependencies makes it easier to assess the risk associated with each one. These open source projects are the simplest to assess: are issues responded to, and have there been any releases recently? Being able to see the maintainers and project activity for each project gives good insight into the project's health.

Businesses can play their part to reduce the risks by supporting the projects upon which they depend. Some projects accept sponsorship directly via the GitHub Sponsors scheme, others might instead appreciate offers of hosting, or a security audit. Every open source project appreciates contributions. If your business had created this library itself, then the engineers inside the company would have to fix every bug themselves.

Open source is more like a shared ownership scheme. We don't all have to build the same thing repeatedly, but rather can contribute, which is both less effort and leads to better quality as a result. One of the most impactful things businesses can do is use a little of their engineering resources and contribute to bug fixes or features to projects that are so core to the business.

Keeping your own engineers involved in a project has many benefits. They get to know it and can keep an eye on new features, or when a new release is available. Crucially, the business has insight into the health and status of the dependent project and is part of what keeps it healthy, reducing the risk to the business of a problem with a dependency. A number of organizations, including Aiven, have an OSPO (open source program office), with staff dedicated to contributing to or even maintaining the projects used by the organization. These departments often contribute to the general presence of the company in the open source ecosystem and enable other employees to engage with open source.

Another approach is to support the organizations that exist to support open source. The OpenSSF (Open Source Security Foundation) works to improve the security of open source projects and is funded by the organizations that depend on those projects. It also publishes excellent learning resources so that businesses can educate themselves about the risks of the software they use. Another similar organization is Tidelift, which partners with maintainers to ensure certain basic requirements are met, again funded by the organizations. Tidelift also provides tooling and education to help businesses manage their software supply chain and adopt best practices in this area.

**Securing a Safer Software Future**

Businesses depend on software, and this includes open source software, which is widely used and typically more secure than proprietary alternatives.

This is a smart move, but an even smarter move is to have clear knowledge of the software supply chain and its dependencies. When a problem does arise, depending on healthy projects and having the details of your software available helps every organization. If every organization did this, then the risk of having events such as the Log4Shell vulnerability are reduced.

Neglecting Open Source Developers Puts the Internet at Risk

With the update, Microsoft adds features to allow easier deployment of zero-trust capabilities. Considering the 1.3 billion global Windows users, the support could make a difference.

Organizations aiming to boost their security with zero-trust initiatives got some help from Microsoft this week, when the computing giant announced that a slew of zero-trust features are now available in its Windows 11 operating system.

The zero-trust approach to security aims to secure workers' access to sensitive systems, network, and data by using additional context, analysis, and security controls. The goal is to give "the right people the right access at the right time," Microsoft stated in the Windows 11 Security Book, a 74-page report on Windows 11's security architecture.

The model checks a user's identity and location, as well as their device's security status, and only allows access to the appropriate resources, according to the Windows 11 Security Book. In addition, zero-trust capabilities include continuous visibility and analysis to catch threats and improve defenses.

The latest version of the operating system and software platform adds a variety of features, from support for the Pluton security processor and trusted platform modules (TPMs) to comprehensive features around Trusted Boot, cryptography, and code-signing certificates, says David Weston, vice president of enterprise and OS security at Microsoft.

"Organizations worldwide are adopting a zero-trust security model based on the premise that no person or device anywhere can have access until safety and integrity is proven," he says. "We know that our customers need modern security solutions with tightly integrated hardware and software that protects from entire classes of attack."

**The Zero-Trust Buzz Gets a Boost**

The zero-trust concept has been knocking around for years, with technologists and government agencies first discussing it for security with the dawning realization that network perimeters were rapidly disappearing. Then, the work-from-home surge caused by the coronavirus pandemic injected more urgency into the movement. Now, three-quarters of security decision-makers (75%) believe that the increase in hybrid work creates vulnerabilities at their organization, leaving them more open to attacks.

"When employees are given the freedom to choose their work location, device, tools, and/or software, it becomes a challenge to establish trust based on static attributes," says Ben Herzberg, chief scientist at Satori. "As the competitive pressure pushes companies to democratize data and release new customer value faster, employees will be provided more flexibility, and zero trust will be the go-to approach for enabling that flexibility while ensuring security."

That said, implementing zero trust is a complex endeavor, as evidenced by the list of aspects that Microsoft has now built in:

    

Microsoft's Windows 11 security architecture. Source: Microsoft's Windows 11 Security Book.

The new Windows 11 features include Smart App Control, which uses machine learning, AI modeling, and Microsoft's vast telemetry network of 43 trillion daily signals to determine if an application is safe. Other features also determine whether driver code and virtual-machine code have signs of maliciousness. Additional improvements include credential checks in Windows Defender, password-less support with Windows Hello for Business, and protection against credential-harvesting websites, the company stated.

Complexity has hampered zero-trust rollouts, but adding these feature directly into Windows 11 makes it more likely that companies can easily deploy zero-trust capabilities, says Microsoft's Weston.

"Building in instead of bolting on makes deployment and management of zero-trust capabilities much simpler and efficient," he says. "In addition, having these \[features\] directly integrated in the OS enables Windows to provide key measurements in hardware increasing the trust and validity of measurements."

He adds, "The minute zero-trust capabilities are embedded into enterprise infrastructure, it becomes accessible for many companies that would otherwise have a hard time getting access to this technology. ... An integrated client environment for zero trust will make the transition for employees much smoother and internal change management simpler."

Microsoft throwing its considerable weight behind zero trust should indeed move the needle on adoption and overall security: Microsoft sees 2.5 billion endpoint queries and 80 million password attacks on a daily basis, the firm stated in a blog post published this week.

**Zero Trust Is Still Hard**

Even with the Windows 11 updates, companies should expect implementing zero trust to be a process. Building a zero-trust framework requires deep technical integrations, and the organizations that do that best are the ones most likely to be successful in their implementation, says Satori's Herzberg.

To start off, companies should identify a group of users, devices, applications, and workflows that could benefit from zero trust; create a zero-trust architecture to protect those components; and then choose and implement the proper technologies, he says.

An incremental rollout works, given that zero trust is more of a journey than a destination, says Jason Floyd, chief technology officer at Ascent Solutions.

"Zero trust was never about solving a technology problem — it’s a strategic tool directing how to use the technology already in place," he says. "Building additional zero-trust features into Windows does encourage enterprises to adopt a healthy security mindset, but not for the one-size-fits all solution some executives might be expecting."

Overall, Windows 11 adds "chip-to-cloud security," establishing trusted processes starting with firmware and reaching out to workloads running in the cloud, Microsoft's publication stated. This support aids zero-trust architectures by minimizing the work required to prove a user's identity and check system health, says Microsoft's Weston.

"This inverts the previous paradigm of systems security where a user or device was assumed healthy until proven guilty," he says. "Microsoft's view is that the zero-trust philosophy and architecture addresses many of the current and future security challenges for customers and thus Microsoft and most of our customers believe this will be the dominant approach to security."

Microsoft Looks to Enable Practical Zero-Trust Security With Windows 11

Protecting against risk is a shared responsibility that only gets more complex as you mix the different approaches of common cloud services.

More enterprises are taking a multicloud approach as part of their digital transformation efforts to support distributed teams working in hybrid and remote models. And just as hybrid work environments are here to stay, the multicloud approach has taken hold. Gartner predicts global cloud revenue will reach $474 billion in 2022, with 90% of enterprises already working toward a multicloud strategy.

When leveraged correctly, a multicloud strategy can make many processes more efficient. It also offers greater resilience to outages and more vendor flexibility than a single-cloud strategy. Additional advantages include:

*   Avoiding vendor lock-in with one cloud provider. An organization with a global footprint and specialized data can select the location of the data center with the least impact to its business. For instance, Microsoft Azure currently leads in the Middle East from a data center location perspective.
*   The ability to take advantage of distinguishing features offered by each cloud vendor, such as unique database solutions in Google Cloud or the ability to manage your on-premises and cloud resources much more seamlessly in Microsoft Azure.
*   Better costs and business resiliency, with specific services less expensive through a specific vendor and protections against service disruptions. Both require designing your services to leverage the benefits, but once established, your organization can recoup its investment over two to three years, resulting in long-term cost savings.

However, these advantages come at a cost. It can be challenging to ensure data and cloud infrastructure is secure and aligned to your obligations and controls when disparate environments are hosted through multiple providers. Telling a unified story around the data, configuration, and security within those environments can be nearly impossible.

CISOs who are embracing a multicloud data approach must focus on two main security concerns: managing risks posed by vendors and their different cloud operating models, and demonstrating the value of their security controls and strategies in the face of increased costs of operating in a multicloud world.

**Managing Risk Across Clouds**

The impact and frequency of cyberattacks has grown in parallel to the escalating focus on multicloud strategies. Ransomware attacks, data breaches, and major IT outages topped the Allianz Risk Barometer this year for only the second time in the survey's history, with executives ranking them as more worrisome than supply chain disruption, natural disasters, and the pandemic. Companies are right to show concern: Organizations worldwide experienced 50% more weekly cyberattacks in 2021, compared with 2020.

Business leaders are catching up on the importance of cyberattacks, but most are underinformed about risks posed by their vendor partners. In PwC's "2022 Global Digital Trust Insights Survey," 57% of business leaders said they anticipate a jump in attacks on cloud services, but only 37% said they understand cloud risks. The approach and operating models of security vary among cloud providers, and protecting against risk is a shared responsibility that only gets more complex as you add common cloud services that use different approaches, such as identity and access management (IAM) or virtualized servers.

For example, different cloud vendors have their own approach to role-based access. Amazon Web Services handles identity by attaching IAM policies directly to a virtual server, which grants the server the ability to take actions. Google Cloud's offering, in contrast, focuses on creating service accounts (users) and then attaching those accounts to the server so it can interact with another resource. These small differences add up at enterprise scale, driving security complexity to ensure least privilege and other security requirements across both clouds.

Because cloud services aren't designed to integrate with their competitors, learning how to use security tools for each cloud provider is just the beginning. IT teams will need to centralize their security monitoring with a security information event management (SIEM) tool, along with other third-party tools to increase interoperability of cloud services. These added systems require additional training and resources and perhaps even additional IT staffing to ensure expertise in each cloud platform _and_ how those platforms work together.

In addition to these in-built differences between their services, most cloud vendors prioritize their own specifically tailored security offerings. This drives a host of complications that plague cloud security. For one example, a cloud Web application firewall (WAF) can be used to protect your network, but it will only work with a specific cloud service provider and cannot be expanded across multiple cloud offerings. Duplicating these functionalities for different providers requires either duplicating teams to support and manage these key security tools or buying a cloud-agnostic service — which adds yet another vendor to the mix.

This additional risk and cost, typically not discovered until late in the deployment of a multicloud model, can push out timelines, increase cost, and trigger audit findings. Failure to plan for and mitigate these risks can leave a company susceptible to financial loss, regulatory action, litigation, and reputational damage.

**Communicating Value With Risk Quantification**

Gartner estimates that by 2023, 30% of CISOs' effectiveness will hinge on their ability to demonstrate value. As multicloud data strategies become the norm and the cost of security controls within that strategy increases, risk quantification can help leaders communicate their value consistently by expressing the multicloud risk posture in clear monetary values.

According to PwC, organizations that reported the most significant improvement in data trust outcomes had two things in common: They predicted an increase in their cybersecurity spending, and they incorporated business intelligence and data analytics into their operational models, including risk quantification.

To assess the financial risks of a multicloud strategy, CISOs must take into account the costs of each platform weighed against their perceived risks. Those considerations must include the data management and cybersecurity practices of all the cloud providers you're considering, along with any cloud-agnostic tools and platforms you'll be using for joint monitoring.

With so many factors at play, you can't afford to rely on imprecise, gut-feel measuring scales like "low, medium, high" and "red, yellow, green." Expressing risk data in financial terms is a powerful tool because it offers a common language to communicate changing risk priorities, improve alignment between CISOs and the board, and facilitate better-informed risk management decisions.

Here's an example: A CISO is looking at the financial value associated with the various risks of multicloud architecture. By comparing tactics for mitigating a cybersecurity incident, they find that better controls over administrative privileges reduce the financial cost of the event far more than implementing a cybersecurity training program. While the CISO understands the technical details of cyber-risk within multicloud architecture, the rest of the C-suite will benefit from the clarity of monetary values associated with each risk and mitigation tactic. By empowering CISOs to make their case to their colleagues and the board, risk quantification brings more transparency to the many moving parts of a multicloud strategy.

According to Gartner, more than 85% of organizations will function as cloud-first by 2025, and they won't be able to fully realize their digital strategies without using cloud-native technologies. A Gartner leader put it this way: "There is no business strategy without a cloud strategy."

It's imperative that business leaders pursue strategies to safeguard their data and communicate their multicloud priorities, aligning across the organization with a common language of value.

Mitigating Risk and Communicating Value in Multicloud Environments

Researchers from SentinelLabs laid out what they know about the attackers and implored the researcher community for help in learning more about the shadowy group.

LABSCON – Scottsdale, Ariz. – A new threat actor that has infected a telecommunications company in the Middle East and multiple Internet service providers and universities in the Middle East and Africa is responsible for two "extremely complex" malware platforms — but a lot about the group that remains shrouded in mystery, according to new research revealed here today.

Researchers from SentintelLabs, who shared their findings at the first-ever LabsCon security conference, named the group Metador, based on the phrase "I am meta" that appears in the malicious code and the fact that the server messages are typically in Spanish. The group is believed to have been active since December 2020, but it has successfully flown under the radar over the past few years. Juan Andrés Guerrero-Saade, senior director of SentinelLabs, said the team shared information about Metador with researchers at other security firms and government partners, but no one knew anything about the group.

Guerrero-Saade and SentinelLabs researchers Amitai Ben Shushan Ehrlich and Aleksandar Milenkoski published a blog post and technical details about the two malware platforms, metaMain and Mafalda, in hopes of finding more victims who have been infected. "We knew where they were, not where they are now," Guerrero-Saade said.

MetaMain is a backdoor that can log mouse and keyboard activity, grab screenshots, and exfiltrate data and files. It can also be used to install Mafalda, a highly modular framework that provides attackers with the ability to collect system and network information and other additional capabilities. Both metaMain and Mafalda operate entirely in memory and do not install themselves on the system’s hard drive.

**Political Comic**

The malware’s name is believed to have been inspired by Mafalda, a popular Spanish-language cartoon from Argentina that regularly comments on political topics.

Metador set up unique IP addresses for each victim, ensuring that even if one command and control is uncovered, the rest of the infrastructure remains operational. This also makes it extremely difficult to find other victims. It's often the case that when researchers uncover attack infrastructure, they find information belonging to multiple victims — which helps map out the extent of the group's activities. Because Metador keeps its target campaigns separated, researchers have only a limited view into Metador's operations and what kind of victims the group is targeting.

What the group doesn't seem to mind, however, is mixing with other attack groups. The Middle Eastern telecommunications company that was one of Metador's victims was already compromised by at least 10 other nation-state attack groups, the researchers found. Many of the other groups appeared to be affiliated with China and Iran.

Multiple threat groups targeting the same system is sometimes referred to as a "magnet of threats," as they attract and host the various groups and malware platforms simultaneously. Many nation-state actors take the time to remove traces of infection by other groups, even going as far as patching the flaws the other groups used, before carrying out their own attack activities. The fact that Metador infected malware on a system already compromised (repeatedly) by other groups suggests that the group doesn't care about what the other groups would do, the SentinelLabs researchers said.

It's possible the telecommunications company was such as high-value target that the group was willing to take the risk of detection since the presence of multiple groups on the same system increases the likelihood that the victim will notice something wrong.

**Shark Attack**

While the group appears to be extremely well-resourced — as evidenced by the technical complexity of the malware, the group's advanced operational security to evade detection, and the fact that it is under active development — Guerrero-Saade warned that it wasn't enough to determine that there was nation-state involvement. It is possible that Metador may be the product of a contractor working on behalf of a nation-state, as there are signs the group was highly professional, Geurrero-Saade said. And the members may have prior experience carrying out these kinds of attacks at this level, he noted.

"We consider the discovery of Metador akin to a shark fin breaching the surface of the water," the researchers wrote, noting that they have no idea what is happening underneath. "It's a cause for foreboding that substantiates the need for the security industry to proactively engineer towards detecting the true upper crust of threat actors that currently traverse networks with impunity."

Researchers Uncover Mysterious 'Metador' Cyber-Espionage Group

Code could allow other attackers to develop copycat versions of the malware, but it could help researchers understand the threat better as well.

One problem with running a ransomware operation along the lines of a regular business is that disgruntled employees may want to sabotage the operation over some perceived injustice.

That appears to have been the case with the operators of the prolific LockBit ransomware-as-a-service operation this week when an apparently peeved developer publicly released the encryptor code for the latest version of the malware — LockBit 3.0 aka LockBit Black — to GitHub. The development has both negative and potentially positive implications for security defenders.

**An Open Season for All**

The public availability of the code means that other ransomware operators — and wannabe ones — now have access to the builder for arguably one of the most sophisticated and dangerous ransomware strains currently in the wild. As a result, new copycat versions of the malware could soon begin circulating and adding to the already chaotic ransomware threat landscape. At the same time, the leaked code gives white-hat security researchers a chance to take apart the builder software and better understand the threat, according to John Hammond, security researcher at Huntress Labs.

"This leak of the builder software commoditizes the ability to configure, customize, and ultimately generate the executables to not only encrypt but decrypt files," he said in a statement. "Anyone with this utility can start a full-fledged ransomware operation." 

At the same time, a security researcher can analyze the software and potentially garner intelligence that could thwart further attacks, he noted.  "At minimum, this leak gives defenders greater insight into some of the work that goes on within the LockBit group," Hammond said. 

Huntress Labs is one of several security vendors that have analyzed the leaked code and identified it as being legitimate.

**Prolific Threat**

LockBit surfaced in 2019 and has since emerged as one of the biggest current ransomware threats. In the first half of 2022, researchers from Trend Micro identified some 1,843 attacks involving LockBit, making it the most prolific ransomware strain the company has encountered this year. An earlier report from Palo Alto Networks' Unit 42 threat research team described the previous version of the ransomware (LockBit 2.0) as accounting for 46% of all ransomware breach events in the first five months of the year. The security identified the leak site for LockBit 2.0 as listing over 850 victims as of May. Since the release of LockBit 3.0 in June, attacks involving the ransomware family have increased 17%, according to security vendor Sectrio.

LockBit's operators have portrayed themselves as a professional outfit focused mainly on organizations in the professional services sector, retail, manufacturing, and wholesale sectors. The group has avowed not to attack healthcare entities and educational and charitable institutions, though security researchers have observed groups using the ransomware do so anyway. 

Earlier this year, the group garnered attention when it even announced a bug bounty program offering rewards to security researchers who found problems with its ransomware. The group is alleged to have paid $50,000 in reward money to a bug hunter who reported an issue with its encryption software.

**Legit Code**

Azim Shukuhi, a researcher with Cisco Talos, says the company has looked at the leaked code and all indications are that it is the legitimate builder for the software. "Also, social media and comments from LockBit's admin themselves indicate that the builder is real. It allows you to assemble or build a personal version of the LockBit payload along with a key generator for decryption," he says.

However, Shukuhi is somewhat dubious about how much the leaked code will benefit defenders. "Just because you can reverse-engineer the builder doesn’t mean that you can stop the ransomware itself," he says. "Also, in many circumstances, by the time the ransomware is deployed, the network has been fully compromised."

Following the leak, LockBit's authors are also likely hard at work rewriting the builder to ensure that future versions won't be compromised. The group is also likely dealing with brand damage from the leak. Shukuhi says.

In an interview, Huntress' Hammond tells Dark Reading that the leak was "certainly an 'oops' \[moment\] and embarrassment for LockBit and their operational security." But like Shukuhi, he believes that the group will simply change up their tooling and continue as before. Other threat actor groups may use this builder for their own operations, he says. Any new activity around the leaked code is just going to perpetuate the existing threat.

Hammond says Huntress' analysis of the leaked code shows that the now-exposed tools might enable security researchers to potentially find flaws or weaknesses in the cryptographic implementation. But the leak does not offer all private keys that could be used to decrypt systems, he adds.

"Truthfully, LockBit seemed to brush off the issue as if it was no concern," Hammond notes. "Their representatives explained, in essence, we have fired the programmer who leaked this, and assured affiliates and supporters that business."

Developer Leaks LockBit 3.0 Ransomware-Builder Code

Emails purporting to be an update to terms of service for GitHub and CircleCI instead attempt to harvest user credentials.

CircleCI has sent out a notice to its customers that a phishing email scam is targeting their users, along with GitHub's, in an attempt to harvest credentials.

The CircleCI security alert included a copy of the malicious email that told recipients that the companies were working together to launch a new terms of service on CircleCI and GitHub accounts.

"As a result of this update, all users will need to review and accept the new Terms of Use and privacy policy in order to continue using CircleCI services," the bogus email read.

Below the notice was a malicious link directing users to log into their GitHub account through CircleCI to accept the new terms.

CircleCI assured its users the company would not require customers to log in to review their terms of service, and pointed out that the malicious link sends victims to **circle-ci\[.\]com**, a domain not owned by the company.

"We have no reason to believe your organization has been specifically targeted or that your account has been compromised, but want our customers to be aware that there is an ongoing phishing attempt and to exercise due caution," CircleCI explained in the notice of the active phishing attack to its customers.

Keep up with the latest cybersecurity threats, newly-discovered vulnerabilities, data breach information, and emerging trends. Delivered daily or weekly right to your email inbox.

Subscribe

CircleCI, GitHub Users Targeted in Phishing Campaign

Quantum computing's impact on cryptography is not a cliff that we'll all be forced to jump off of, according to Deloitte.

As computer scientists march forward in the process of taking quantum computing into the practical realm, cybersecurity vendors and practitioners will need to be ready with encryption mechanisms that can withstand the power of quantum's compute potential. But risk experts say that future-proofing measures for post-quantum cryptography don't have to be created in panic.

Contrary to the way some early pundits have painted the post-quantum computing landscape, the truth is that there will be no quantum cliff in which today's encryption mechanisms will suddenly become obsolete, says Dr. Colin Soutar, the US quantum cyber-readiness leader and managing director for Deloitte Risk & Financial Advisory, which just released a report on quantum encryption. He explains that in reality, the transition to quantum is going to be an ongoing process.

"There's a lot of discussion around quantum right now, and there's a lot of conflation of different ideas. There are even some alarmist statements about how everything needs to change overnight to update to quantum-resistant algorithms," says Soutar. "That implies there's a specific date (for quantum adoption), and there's really not."

Viewing post-quantum security problems from that kind of lens can help the cybersecurity industry start to work the issue with the same kind of risk management and roadmap planning steps they'd take for any other kind of serious emerging technology trend.

**Building Awareness, Not Alarmism**

One thing is for certain: The drumbeat for quantum computing and post-quantum cryptography is getting louder.

Quantum computing stands to give the computing world a major boost in the ability to tackle multi-dimensional analysis problems that strain today's most advanced traditional supercomputers. Whereas traditional computers fundamentally work based on the storage of information in binary, quantum computing is not limited by the "on" or "off" position of information storage.

Quantum computers depend on the phenomenon of quantum mechanics called superposition, in which a particle can exist in two different states simultaneously. They take advantage of that phenomenon by using "qubits," which can store information in a variety of states at the same time.

Once perfected, this will give quantum computers the ability to greatly speed up data analysis on tough problems in areas as disparate as healthcare research and AI. However, this kind of power also makes these computers ideal for cracking cryptographic algorithms. This is the crux of the push for awareness from security advocates over the last several years to ensure that the industry starts preparing for that post-quantum reality.

"Our view on this is less about being alarmist and saying, 'You need to update everything now' and more of raising the awareness to start to think about what your data are, what your risk could be relative to that data and the crypto you use," Soutar says. "And then deciding when you might want to think about, start looking at discovery on your roadmap, and then updates later."

According to the survey released by Deloitte this week, the good news is that among those technology and business executives who are aware of quantum computing, a little over 50% also understood the attendant security considerations to it as well.

**Timing the Post-Quantum Security Impact**

The trick in all of this for security professionals is that there are a lot of fires to put out elsewhere before worrying about something that could be years away. Today's quantum computers operate in the research realm only. They require immensely specialized equipment — including microwaves manipulating quantum objects within supercooled environments that operate at near absolute zero in many instances. There is a long way to go on the research front for quantum computers to work in a commercially viable fashion, and no one is quite sure on what the timeline will be.

That "ambiguity of the timeline" is complicated, says Soutar, who explains there are numerous timelines to consider from a post-quantum cryptography perspective.

"The implications of quantum computing on cybersecurity is fairly well known, and it could be huge. I mean, cryptography is endemic in what we do throughout the economy. The thing is that the timing is unknown because first, a quantum computer needs to be mature and viable enough and commercially robust as well, to actually be able to run Shor's algorithm," he says, referring to an algorithm for finding prime factors of an integer that is the benchmark for whether a quantum computer could effectively break public key cryptography. "Secondly, attackers need to get access to data, and they need to untangle that data."

The other variable in this is a concept of attack called "harvest now, decrypt later," where attackers gather encrypted information now with the understanding that they could break it through quantum computing resources at a later date. The Deloitte survey shows that 50.2% of organizations believe they could be at risk for harvest now, decrypt later schemes.

"That then opens up risk to this data that I'm expecting to be good for the lifetime out of an individual," Soutar says. "Maybe it's personal information, or it's financial information that I want to be secure for at least 10 years. Or it's national security information which may have longer requirements on it."

He adds, "So, people are starting to think about, 'Well, what data do I have and how do I need to protect it? For how long? Secondly, how long is it going to take me to do the updates to post quantum cryptography? When should I start thinking about it?'"

These are the big timeline questions for security and quantum computing experts, who are still at odds over whether we've got 5, 10, or 15 years before the quantum effect impacts encryption. Soutar reiterates that perhaps the better thought process is to stop thinking about it as a definitive date the industry times for, and instead think about relative risk over time. He explains that this is an idea put forward by Dr. Michele Mosca, co-founder and CEO of Evolution Inc, and co-author of a report earlier this year that details that line of thinking.

"Then you can start to think, if I'm with a huge organization, maybe it's going to take me a decade to do the updates," Soutar explains. "I've got all these medical devices or other OT devices that I've got to think about the supply chain communications, and how do I enforce this on my suppliers?"

He adds, "So, again, it's getting that right degree of understanding so that people can start to maybe even quantify what the risk is, and stack that up against other cyber-risks that they're looking to invest in over time."

**Working on the Boring Parts**

At the end of the day, Soutar says that maybe that the quantum lens can be a bit distracting to security. As long as organizations keep quantum on the horizon, it may just be a matter of making "perfunctory updates to crypto" that might not be that big of a deal for the industry if it is all done in due time.

"The quantum threat to crypto should really just be something that's addressed over time. Just do updates as the algorithms get standardized," says Soutar, who believes that the industry should be talking about the nuts and bolts of standardization, which can be boring but also are the most important way to start moving forward. "As they go through that process, then companies and governments have more confidence in making the changes, doing the updates, and they just do it. So, it really should be a non-event."

That's not to say that Soutar believes security practitioners should be sticking their heads in the sand with regard to quantum risk to security postures. The risks will accelerate, but it's just a matter of working that encryption roadmap like any other part of the cyber-risk roadmap. That includes doing risk assessments, discovering and classifying data, and projecting risk over time.

"It's never a bad idea to go look around in the attic. You don't know what you're going to find there. When we do that, when we go through basic cryptography, there are things that we find," he says. "You might say, 'Well, let's update that or let's make sure that we've got the right segregation of duties relative to that.' Or, 'Have we got all the responsibilities and governance laid out?' Again, it's the boring things. But those are things that you find when you look through the quantum lens."

Deloitte's survey shows that it may take some kind of regulatory push to prod security practitioners into serious steps on post-quantum cryptography. Soutar hopes that the industry is able to come together in the coming years to develop a framework for post-quantum cryptographic methods perhaps in the same spirit as the NIST Cybersecurity Framework (CSF).

"It's not a bad idea to have some framework out there when there's a whiff of potential regulation downstream," he says. "I think that's always better than just regulation, having something that's voluntary and outcome-based."

Source

DARKReading