The exploding dependency tree is top source of risk & operational pain
Apps are now greater than 70% third-party code & libraries. The more dependencies you have, the more vulnerabilities you inherit. Attackers exploit these weaknesses faster than teams can react.

The scan-patch model is breaking
Scan & Patch, EDR, & ADR can't keep up.
Time to exploit down to 36 hours. Attackers are accelerating. Attack Surface expanding number or vulnerabilities by 2X

Runtime Guardrails for Prod
BlueRock puts security guardrails in place before vulnerabilities become threats. Instead of reacting to breaches, we prevent them.
-
High Performance
-
Low False Positives
-
Invisible to Devs

(then Azure & GCP)
blueRock Runtime Guardrails for Containerized & Linux apps
-
Save Time
-
Save Distractions
-
Better Security
Sign Up For Early Access
Secure your operations with the latest in runtime security. Get early access or schedule a demo today.
Threat Research
How does BlueRock neutralize threats? See below to learn more.

Wiz researchers identified architecture risks in AI-as-a-Service platforms that could jeopardize customer data, leading to a collaboration with Hugging Face to address these vulnerabilities. The research revealed that untrusted, potentially malicious models could exploit Hugging Face’s infrastructure to execute remote code, gain escalated privileges, and perform cross-tenant attacks. Specifically, malicious PyTorch models could compromise the Inference API and Inference Endpoints, allowing unauthorized access to other customers' models. Additionally, vulnerabilities in Hugging Face Spaces were discovered, where malicious Dockerfiles could exploit network isolation issues to access and overwrite container registries. These findings underscore the importance of ensuring AI models run in sandboxed environments and highlight the need for robust security measures in rapidly growing AI services. Hugging Face has taken steps to mitigate these risks by implementing vulnerability scanning and undergoing regular penetration testing.
In the attack described, the adversaries began by uploading a malicious PyTorch model to Hugging Face's platform, exploiting the unsafe Pickle format to execute arbitrary code. This step was effectively mitigated by BlueRock's Reverse Shell Protection, which prevents unauthorized attempts to bind shell input and output streams to network sockets, thereby blocking reverse shell attacks initiated by the malicious model. Following this, the attackers escalated their privileges by querying the node’s IMDS, obtaining the role of a Node inside the EKS cluster. BlueRock's Cloud IMDS Firewall (AWS) would have mitigated this step by restricting access to the Instance Metadata Service, preventing the attackers from exploiting cloud instance metadata for privilege escalation. These mechanisms together provide a robust defense against the described attack vectors, ensuring that malicious code execution and unauthorized privilege escalation are effectively thwarted.
- T1204.002: User Execution: Malicious File: The article mentions that Wiz Research was able to compromise the service running the custom models by uploading their own malicious model and leveraging container escape techniques to break out from their tenant and compromise the entire service. This implies the use of 'User Execution: Malicious File' as the attackers uploaded a specially crafted malicious file (the model) to achieve their goals.
- T1059: Command and Scripting Interpreter: The article explains that the malicious model could contain a remote code execution payload, potentially granting the attacker escalated privileges and cross-tenant access to other customers' models. This indicates the use of 'Execution: Command and Scripting Interpreter' as the attackers used the Pickle format to execute arbitrary code.
- T1210: Exploitation of Remote Services: Wiz Research was able to gain cross-tenant access to other customers' models stored and run in Hugging Face. This demonstrates the use of 'Lateral Movement: Exploitation of Remote Services' as the attackers moved laterally within the environment by exploiting the shared infrastructure.
- T1195: Supply Chain Compromise: The attackers used a specially crafted Pickle file to achieve remote code execution upon deserialization of untrusted data. This represents 'Initial Access: Supply Chain Compromise' as the attackers compromised the supply chain by injecting malicious code into the AI models.
- T1552.005: Unsecured Credentials: Cloud Instance Metadata API: After gaining initial access, the attackers escalated their privileges by querying the node’s IMDS and obtaining the role of a Node inside the EKS cluster. This corresponds to 'Privilege Escalation: Cloud Instance Metadata API' as they used the cloud instance metadata API to escalate privileges.
- T1526: Cloud Service Discovery: The article describes how the attackers listed all pods in the cluster with their new token, which shows 'Discovery: Cloud Service Discovery' as they enumerated cloud resources to understand the environment.
- T1552: Unsecured Credentials: The attackers were able to obtain secrets associated with their pod, enabling lateral movement within the EKS cluster. This indicates 'Credential Access: Unsecured Credentials' as they accessed sensitive credentials stored within the environment.
- T1609: Container Administration Command: The attackers used a Dockerfile with a malicious payload to gain code execution in the Hugging Face Spaces service. This is an example of 'Execution: Container Administration Command' as they used container commands to execute their payload.
- T1610: Deploy Container: The article describes how the attackers exploited a network isolation issue to write to the centralized container registry, indicating 'Persistence: Container Image' as they manipulated container images to maintain access.
Snyk security researchers have identified four critical vulnerabilities, dubbed "Leaky Vessels," in Docker and runc container infrastructure components, which could allow attackers to escape containers and gain unauthorized access to the host operating system. These vulnerabilities, CVE-2024-21626, CVE-2024-23651, CVE-2024-23653, and CVE-2024-23652, affect widely used container engines and build tools, prompting Snyk to recommend immediate updates from relevant vendors. To aid in detecting exploit attempts, Snyk has released two open source tools: a runtime detection tool and a static analysis program. These tools serve as reference implementations and are intended to help identify potential exploits in container environments. Users are advised to monitor and update their systems promptly to mitigate these risks.
The "Leaky Vessels" vulnerabilities in Docker and runc allow attackers to escape from containers and gain unauthorized access to the host operating system. This is achieved through a container breakout technique, exploiting vulnerabilities in the container runtime. BlueRock's Container Capability Control effectively mitigates this threat by controlling the capabilities assigned to containers, thereby reducing the risk of unauthorized access to the host. Additionally, the exploitation of the runc vulnerability involves using a malicious image or Dockerfile to achieve privilege escalation. BlueRock's Container Runtime Drift Protection (Available 2024 Dec) provides protection against unauthorized changes to the container runtime environment, ensuring that the runtime state remains consistent with the expected configuration, thus preventing privilege escalation attempts. These mechanisms collectively help secure container environments against such vulnerabilities.
- T1611: Escape to Host: The article describes how the vulnerabilities, dubbed 'Leaky Vessels', allow an attacker to escape from a Docker container to the underlying host operating system. This indicates the use of a container breakout technique, specifically exploiting a vulnerability in the container runtime.
- T1068: Exploitation for Privilege Escalation: The exploitation of the runc vulnerability (CVE-2024-21626) involves the use of a malicious image or Dockerfile to achieve the container escape. This demonstrates the use of 'Exploitation for Privilege Escalation' as the attacker exploits the vulnerability to gain elevated privileges on the host.
- T1195: Supply Chain Compromise: The article mentions that the vulnerabilities can be exploited by running a malicious image or by building a container image using a malicious Dockerfile. This indicates the use of 'Supply Chain Compromise' to introduce the malicious Dockerfile or image into the build process.
- T1584.002: Compromise Infrastructure: DNS Server: The exploitation process involves building a container image using a malicious Dockerfile or upstream image, which suggests the use of 'Build Misconfiguration' to exploit the vulnerabilities during the container build process.
- T1005: Data from Local System: Once the attacker has gained access to the underlying host operating system, they could potentially access sensitive data such as credentials and customer information. This indicates the use of 'Data from Local System' to gather sensitive information from the compromised host.
- T1592: Gather Victim Host Information: The article describes how the vulnerabilities were discovered and disclosed responsibly to the relevant parties, indicating a 'Vulnerability Disclosure' process.
The Sysdig Threat Research Team has uncovered a novel cloud-native cryptojacking operation named AMBERSQUID, which exploits AWS services like AWS Amplify, AWS Fargate, and Amazon SageMaker. These services are often overlooked from a security perspective, allowing attackers to operate undetected and potentially cost victims over $10,000 per day. AMBERSQUID uses Docker Hub to distribute malicious container images that evade static scanning. The operation involves creating multiple AWS roles with extensive permissions, setting up repositories in AWS CodeCommit, deploying cryptomining scripts via AWS Amplify, and using ECS and Fargate for cryptojacking. The attackers also utilize AWS CodeBuild, CloudFormation, EC2 Auto Scaling, and SageMaker to further their cryptojacking activities. This operation is attributed to Indonesian attackers based on the language used in scripts and usernames. The article emphasizes the need for comprehensive monitoring and quick response to detect and mitigate such threats.
The AMBERSQUID cryptojacking operation began with attackers uploading a container image containing cryptomining software to Docker Hub, which evaded static scanning. This step was effectively mitigated by BlueRock's Container Drift Protection (Binaries & Scripts), which prevents unauthorized executables and scripts from running, ensuring that only binaries present in the original container image are executed. The attackers then used compromised AWS credentials to configure their environment and gain access to various AWS services, creating new IAM roles with full access policies. BlueRock's Cloud IMDS Firewall (AWS) could have been instrumental in preventing unauthorized access to AWS metadata services, thereby protecting against the misuse of valid accounts. The operation further involved creating repositories in AWS CodeCommit to store and distribute malicious code, and leveraging AWS Amplify to create web applications that executed cryptomining software. BlueRock's mechanisms ensure that unauthorized code execution is blocked, thus thwarting the attackers' attempts to exploit cloud services for cryptojacking. Finally, the attackers used AWS Elastic Container Service (ECS) and AWS Fargate to run containers executing cryptomining tasks, a step that could be mitigated by BlueRock's comprehensive monitoring and protection of container orchestration services.
- T1202: Indirect Command Execution: The attack begins with the attackers uploading a container image containing cryptomining software to Docker Hub. This image didn't raise alarms during static scanning, indicating the use of techniques to evade detection. The malicious payload only became apparent when the container was run, suggesting the use of Dynamic Analysis Evasion.
- T1078: Valid Accounts: The attackers used compromised AWS credentials to configure their environment and gain access to various AWS services. This is indicative of Valid Accounts, where legitimate credentials are used to access systems and services.
- T1098.003: Account Manipulation: Additional Cloud Roles: The attackers created new IAM roles with full access policies for multiple AWS services like AWSCodeCommit-Role and sugo-role. This shows the use of Create or Modify Cloud Accounts and Permissions to facilitate further malicious activities.
- T1213: Data from Information Repositories: They then created repositories in AWS CodeCommit and used these repositories to store and distribute their malicious code. This aligns with the use of Code Repositories for hosting malicious code.
- T1613: Container and Resource Discovery: They used AWS Elastic Container Service (ECS) and AWS Fargate to run containers that execute cryptomining tasks. This involves the abuse of Container Orchestration Services.
- T1611: Escape to Host: AWS CodeBuild was used to compile and test source code, embedding cryptomining commands within the build specification. This represents the abuse of Continuous Integration/Continuous Delivery (CI/CD) pipelines.
- T1608.001: Stage Capabilities: Upload Malware: The attackers created CloudFormation stacks to automate the deployment of EC2 instances that run cryptomining software. This technique involves the abuse of Infrastructure as Code (IaC) for malicious purposes.
- T1537: Transfer Data to Cloud Account: They utilized EC2 Auto Scaling to dynamically adjust the number of instances running their cryptomining software, ensuring maximum resource usage. This shows the exploitation of Cloud Compute Resources.
SCARLETEEL, a cyber operation reported by the Sysdig Threat Research Team, has continued to evolve and target cloud environments, particularly AWS Fargate and Kubernetes, to steal proprietary data and engage in cryptomining. The attackers have adapted their tools and techniques to bypass new security measures, demonstrating resilience and stealth in their command and control architecture. Recent activities included compromising AWS accounts by exploiting vulnerable compute services, gaining persistence, and using cryptominers, potentially costing over $4,000 per day. The attackers also escalated privileges by exploiting a customer mistake in an AWS policy, allowing them to gain AdministratorAccess and control over the account. They used various scripts to steal AWS credentials, targeting instance metadata, the filesystem, and Docker containers. These credentials were exfiltrated stealthily using shell built-ins instead of common tools like curl and wget. Additionally, the attackers employed tools such as AWS CLI, Pacu, and peirates to exploit AWS and Kubernetes environments further. They also engaged in DDoS-as-a-Service by executing Pandora malware, part of the Mirai Botnet. Despite multiple layers of defense, including runtime threat detection, vulnerability management, CSPM, and CIEM, the attackers managed to create 42 instances running cryptominers, though they were eventually caught due to the excessive noise generated.
In the SCARLETEEL 2.0 attack, the adversaries began by exploiting vulnerable compute services in AWS accounts to gain initial access. BlueRock's Cluster Drift Protection mechanism effectively mitigates this by preventing unauthorized changes to cluster configurations, ensuring that any attempts to exploit public-facing applications are detected and blocked. Once inside, the attackers escalated privileges by exploiting a misconfiguration in an AWS policy, allowing them to gain AdministratorAccess. BlueRock's Cloud IMDS Firewall (AWS) mechanism is crucial here, as it restricts access to the instance metadata service, preventing unauthorized retrieval of sensitive credentials that could be used for privilege escalation. The attackers then created new users and access keys to maintain persistence. BlueRock's Cluster Drift Protection again plays a role by monitoring and alerting on unauthorized account creations, ensuring that any suspicious activity is quickly identified and addressed. Throughout the attack, the adversaries used scripts to steal AWS credentials and exfiltrate them to a command and control server. BlueRock's Cloud IMDS Firewall (AWS) mechanism helps prevent such credential theft by blocking unauthorized access to metadata services, thereby safeguarding sensitive information from being exfiltrated.
- T1190: Exploit Public-Facing Application: The attack begins with the exploitation of vulnerable compute services in AWS accounts, allowing the attackers to gain initial access to the cloud environment. The article mentions 'compromise AWS accounts through exploiting vulnerable compute services.'
- T1068: Exploitation for Privilege Escalation: After gaining access, the attackers escalate their privileges by exploiting a misconfiguration in an AWS policy, allowing them to gain AdministratorAccess. The article states, 'the actor discovered and exploited a customer mistake in an AWS policy which allowed them to escalate privileges to AdministratorAccess.'
- T1078: Valid Accounts: The attackers gain persistence by creating new users and access keys, ensuring continued access even if initial access vectors are closed. The article mentions, 'Using the new admin privileges, the adversary created new users and a new set of access keys for all the users in the account, including admins.'
- T1552.001: Unsecured Credentials: Credentials In Files: The attackers use scripts to steal AWS credentials by querying the instance metadata service (IMDSv1 and IMDSv2) and searching the filesystem and Docker containers for credentials. The article describes, 'Those scripts search for AWS credentials in different places: by contacting the instance metadata (both IMDSv1 and IMDSv2), in the filesystem, and in the Docker containers created in the target machine (even if they are not running).'
- T1041: Exfiltration Over C2 Channel: The attackers exfiltrate the stolen AWS credentials by sending them to a command and control (C2) server using various endpoints. The article details, 'the exfiltration function sends the Base64 encoded stolen credentials to the C2 IP Address.'
- T1059.004: Command and Scripting Interpreter: Unix Shell: The attackers use the AWS CLI and Pacu to further exploit the AWS environment and facilitate privilege escalation. The article mentions, 'They installed AWS CLI binary and Pacu on the exploited containers and configured them with the retrieved keys.'
- T1611: Escape to Host: The attackers leverage the tool peirates to further exploit Kubernetes environments. The article states, 'they also leveraged peirates, a tool to further exploit Kubernetes.'
- T1586.001: Compromise Accounts: Social Media Accounts: The attackers use the compromised AWS environment to run cryptominers, creating multiple EC2 instances to mine cryptocurrency. The article mentions, 'With the admin access, the attacker created 42 instances of c5.metal/r5a.4xlarge in the compromised account.'
- T1498: Network Denial of Service: The attackers utilize a botnet malware (Pandora) to perform DDoS attacks, indicating their involvement in DDoS-as-a-Service campaigns. The article notes, 'they also downloaded and executed Pandora, a malware belonging to the Mirai Botnet.'
- T1071.001: Application Layer Protocol: Web Protocols: The attackers use multiple command and control (C2) domains, including public services, to send and retrieve data, enhancing their defense evasion. The article mentions, 'Changes in C2 domains multiple times, including utilizing public services used to send and retrieve data.'
Aqua Nautilus researchers have uncovered a potentially massive cloud-native campaign, attributed to the cybercriminal group TeamTNT, which is in its early stages of testing and deployment. The attack infrastructure comprises a cloud worm targeting exposed JupyterLab and Docker APIs to deploy Tsunami malware, hijack cloud credentials, and perform resource hijacking. Four distinct malicious container images were identified and reported to Docker Hub, leading to their removal. The campaign's tools include the ZGrab application for banner grabbing, the masscan tool for scanning IP addresses, and various shell scripts to execute cryptominers and backdoors. The attack leverages misconfigured Docker APIs and JupyterLab instances, utilizing NGROK to conceal the infrastructure and anondns.net to mask the C2 server. Recommendations to mitigate such attacks include securing configurations, applying the principle of least privilege, continuous monitoring, and using vulnerability scanners like Trivy. The investigation suggests that the attack is still in the optimization phase and may escalate into a full-blown campaign.
In the Silentbob's Cloud Attack, the attacker begins by exploiting exposed JupyterLab and Docker APIs to gain initial access. BlueRock's Container Capability Control effectively mitigates this by restricting the capabilities that can be granted to containers, thereby limiting unauthorized command execution. The attacker ensures persistence by setting containers to restart always, which is countered by BlueRock's Container Capability Control, limiting the potential for unauthorized command execution and maintaining system integrity.
- T1190: Exploit Public-Facing Application: The attack begins with the attacker exploiting exposed JupyterLab and Docker APIs. This initial access is facilitated by scanning for these exposed services, which is indicative of the technique 'Exploit Public-Facing Application' (T1190). The article states, 'This infrastructure is in early stages of testing and deployment, and is mainly consistent of an aggressive cloud worm, designed to deploy on exposed JupyterLab and Docker APIs.'
- T1046: Network Service Discovery: Once access is gained, the attacker uses the ZGrab application for banner grabbing to identify further vulnerable instances. This falls under 'Network Service Scanning' (T1046). The article details, 'ZGrab is an application layer scanner, developed with Go language, that enables the attacker to perform banner grabbing.'
- T1046: Network Service Discovery: The attacker uses masscan to scan IP ranges for exposed services, which is a continuation of 'Network Service Scanning' (T1046). The article mentions, 'Subsequently, the masscan tool scans and pipes the IP to be utilized by ZGrab for assessing whether there is an exposed Jupyter Lab instance.'
- T1041: Exfiltration Over C2 Channel: The gathered information is sent back to the attacker's Command and Control (C2) server, indicative of 'Exfiltration Over C2 Channel' (T1041). The article notes, 'The resulting information is organized and stored in the JupyterLab.txt file, which is then transmitted to the attacker’s C2 server.'
- T1105: Ingress Tool Transfer: The attacker's infrastructure is concealed using NGROK, aligning with 'Ingress Tool Transfer' (T1105) for transferring tools and 'Proxy' (T1090) for hiding communication. The article states, 'Through the use of NGROK, the attacker is able to conceal the infrastructure, thereby minimizing the risk of it being shut down.'
- T1059.004: Command and Scripting Interpreter: Unix Shell: The attack progresses with the execution of a script to scan for misconfigured Docker daemons and deploy a privileged container, demonstrating 'Command and Scripting Interpreter: Unix Shell' (T1059.004). The article describes, 'One layer incorporates the ELF system... Another layer houses ZGrab, while yet another contains the run.sh shell script, which is programmed to initiate as soon as the container starts.'
- T1496: Resource Hijacking: The attacker uses Docker to deploy a container with a cryptominer and Tsunami malware, indicative of 'Resource Hijacking' (T1496) and 'Deploy Container' (T1610). The article notes, 'It releases a cryptominer and includes the Tsunami malware, which acts as a backdoor.'
- T1090.002: Proxy: External Proxy: The attacker utilizes the TOR service to obscure network communication, indicative of 'Proxy: External Proxy' (T1090.002). The article mentions, 'Following this, the attacker launches the TOR service to obscure network communication.'
- T1568.002: Dynamic Resolution: Domain Generation Algorithms: The attacker uses anondns.net to mask their C2 server, aligning with 'Domain Generation Algorithms' (T1568.002). The article states, 'The attacker employs anondns.net to mask his C2 server.'
- T1552.001: Unsecured Credentials: Credentials In Files: The attacker scans for AWS keys and secrets, which aligns with 'Cloud Credential Dumping' (T1552.001). The article speculates, 'We strongly suspect that this script is designed to systematically scan the environment for AWS keys and secrets, thereby enabling the attacker to steal them.'
- T1609: Container Administration Command: The attacker sets the container to restart always, ensuring persistence, which aligns with 'Container Administration Command' (T1609). The article summarizes, 'The container is running with the flag --restart=always, which creates a persistence in case the container fails it will try to restart.'
CVE-2022-0847, known as "Dirty Pipe," is a Linux kernel vulnerability that allows users to overwrite files they can read but should not be able to write to. This vulnerability is particularly concerning for containerized environments using Docker, as it enables the modification of files within container images from inside a container. This can lead to potential attacks where shared images are poisoned, affecting all containers running against that image. The exploit can also override read-only mounted volumes. Systems running Linux kernel 5.8 or above should be patched immediately to mitigate this issue. The vulnerability highlights the importance of regular updates and reboots to ensure patches are effective.
The "Dirty Pipe" vulnerability (CVE-2022-0847) allows attackers to overwrite files within container images from inside a container, posing a significant threat to containerized environments. The attack begins with the adversary gaining access to a container, potentially through valid cloud accounts. Once inside, the attacker exploits the Dirty Pipe vulnerability to escalate privileges and modify files that should be read-only, such as configuration files shared across multiple containers. This is where BlueRock's Read-Only File Protection mechanism comes into play. By enforcing strict read-only policies on critical files and directories, BlueRock effectively prevents unauthorized modifications, ensuring that even if an attacker gains access to a container, they cannot alter the underlying image files. This protection is crucial in maintaining the integrity of containerized applications and preventing the spread of malicious changes across multiple containers.
- T1078.004: Valid Accounts: Cloud Accounts: The article describes how attackers can use the Dirty Pipe vulnerability (CVE-2022-0847) to overwrite files in container images from within a container. This implies that attackers can gain control of a container to execute this exploit. The first step in this attack scenario is the adversary gaining initial access to the container.
- T1068: Exploitation for Privilege Escalation: Once the attacker has access to the container, they utilize the Dirty Pipe vulnerability to modify files that should be read-only. This action is directly manipulating and altering the system's files to achieve their goal, which falls under the category of exploiting a privilege escalation vulnerability.
- T1105: Ingress Tool Transfer: The article mentions that the attacker can modify files from the underlying image, affecting all containers using that shared image. This action of modifying files in a way that affects multiple containers aligns with the technique of Ingress Tool Transfer, where the attacker transfers tools or files into the container to facilitate the attack.
- T1592.003: Gather Victim Host Information: Firmware: The attack's ability to modify configuration files such as nginx.conf to affect multiple running containers demonstrates the attacker’s ability to modify system configurations to maintain persistence or further their goals. This aligns with the concept of modifying system configurations.
- T1070.006: Indicator Removal: Timestomp: Finally, the article advises patching the Linux kernel to mitigate the vulnerability. This suggests that the persistence of the vulnerability can be mitigated by updating the system, highlighting the importance of applying security patches.