Security researchers have disclosed technical details and proof-of-concept (PoC) exploit code for CVE-2024-26581, a critical vulnerability in the Linux kernel with a CVSS score of 7.8. This flaw, located in the nft_set_rbtree function of nftables, allows local authenticated attackers to obtain sensitive information from affected systems. The vulnerability, which affects Linux kernel versions 6.1.9 and later, 5.15.91 and later, and 5.10.166 and later, arises from a lack of a crucial check in the nft_rbtree_gc_elem function, leading to a use-after-free condition during transaction rollbacks. Attackers can exploit this by inserting set elements with specific flags before triggering an error condition, potentially escalating privileges to root level. Administrators are advised to update their systems, monitor nftables activity, and implement additional security measures such as SELinux to mitigate risks.

The attacker begins by exploiting the vulnerability in the nft_set_rbtree function of the Linux kernel, sending a specially crafted request to trigger a use-after-free condition. Following this, the attacker leverages the use-after-free condition to escalate privileges by modifying process credentials. BlueRock's Process Credential Protection is crucial here, as it prevents unauthorized privilege escalation by blocking attempts to overwrite process credentials with high-privileged values. Without BlueRock, the attacker attempts to gain full control over the system by chaining the initial exploit with subsequent attacks.

• T1190: Exploit Public-Facing Application: The attacker begins by exploiting a vulnerability within the Linux kernel, specifically targeting the nft_set_rbtree function. This function is responsible for managing sets in nftables. The vulnerability allows local authenticated attackers to obtain sensitive information by sending a specially crafted request. This corresponds to the technique of Exploiting Public-Facing Application.
• T1068: Exploitation for Privilege Escalation: Once the attacker has successfully triggered the vulnerability, they exploit the use-after-free condition in the nft_rbtree_gc_elem function. This condition occurs because the function lacks a crucial check, leading to memory that has been deallocated being inadvertently accessed. This can be classified under Exploitation for Privilege Escalation.
• T1005: Data from Local System: The attacker leverages the leaked information from the initial exploit to craft further attacks. By inserting a set element with specific flags and triggering an error condition, they cause a double deletion of a set element. This is a classic example of leveraging information disclosure to further exploit a system, aligning with Data from Local System.
• T1078: Valid Accounts: The attacker then escalates their privileges to root level by chaining the initial exploit with subsequent attacks. This allows them to gain full control over the affected system, fitting the technique of Privilege Escalation.

‍

Stroz Friedberg has identified a sophisticated Linux malware, named "sedexp," that exploits udev rules to maintain persistence and evade detection. Active since at least 2022, sedexp remains undetected in many online sandboxes. It uses udev rules to execute malicious scripts whenever specific device events occur, particularly targeting the /dev/random device. This malware provides attackers with reverse shell capabilities and uses memory manipulation to conceal its presence, including hiding files and altering process names. The malware is financially motivated, evidenced by its use in credit card scraping operations. Organizations are advised to enhance their detection capabilities and engage in comprehensive forensic analysis to mitigate such threats.

The sedexp malware begins its attack by exploiting udev rules to maintain persistence on a Linux system. This allows the malware to execute malicious scripts whenever specific device events occur, such as when the /dev/random device is loaded. BlueRock's Container Drift Protection (Binaries & Scripts) can mitigate this by preventing unauthorized executables and scripts from running, ensuring that only binaries present in the original container image are executed. The malware also provides reverse shell capabilities, allowing attackers to maintain control over the compromised system. BlueRock's Reverse Shell Protection effectively counters this by blocking unauthorized attempts to bind shell input and output streams to network sockets, thus preventing reverse shell attacks. Additionally, the malware's potential to escape from a containerized environment is mitigated by BlueRock's Container Capability Control, which restricts container capabilities to prevent actions that could lead to container escapes, such as mounting the host filesystem or executing privileged commands. These mechanisms collectively enhance the security posture against the sophisticated tactics employed by sedexp.

• T1547.010: Boot or Logon Autostart Execution: Port Monitors: The initial compromise of the system is not explicitly described, but the article implies that the malware was able to get onto the system. This could have been through various means, but since it's not detailed, we start with the first clear technique: the malware achieving persistence through udev rules. 'Sedexp utilizes udev rules to maintain persistence.'
• T1053.005: Scheduled Task/Job: Scheduled Task: The udev rule ensures that the malware is run whenever /dev/random is loaded, which happens on every system reboot. 'This rule ensures that the malware is run whenever /dev/random is loaded. /dev/random is a special file that serves as a random number generator, used by various system processes and applications to obtain entropy for cryptographic operations, secure communications, and other functions requiring randomness.'
• T1219: Remote Access Software: The malware includes a reverse shell capability, allowing the attacker to maintain control over the compromised system. 'Reverse Shell Capability: It includes a reverse shell, allowing the threat actor to maintain control over the compromised system.'
• T1564.001: Hide Artifacts: Hidden Files and Directories: The malware modifies memory to hide any file containing the string 'sedexp' from commands like ls or find. 'Memory Modification for Stealth: The malware modifies memory to hide any file containing the string "sedexp" from commands like ls or find.'
• T1036.004: Masquerading: Masquerade Task or Service: The malware manipulates arguments to obfuscate its presence and changes the process name to blend in with legitimate system processes. 'Memory Allocation and Argument Handling: The malware manipulates arguments to obfuscate its presence. It changes the process name to kdevtmpfs using prctl to blend in with legitimate system processes.'
• T1547.010: Boot or Logon Autostart Execution: Port Monitors: The malware sets up persistence by copying itself to a specific location and creating a udev rule. 'Persistence Setup: The malware sets up persistence by copying itself to a specific location and creating a udev rule.'
• T1110.001: Brute Force: Password Guessing: The malware was used to hide credit card scraping code on a webserver, indicating a focus on financial gain. 'Credit Card Scraping: The malware was used to hide credit card scraping code on a webserver, indicating a focus on financial gain.'
• T1611: Escape to Host: The malware could theoretically be used to escape outside of a containerized workload.

‍

A new variant of the Gafgyt botnet has been discovered by Aqua Nautilus researchers, targeting machines with weak SSH passwords to expand the botnet and mine cryptocurrency using GPU power. Initially known for targeting IoT devices like routers and cameras, Gafgyt has evolved to attack more robust servers in cloud-native environments. The attack flow involves brute-forcing SSH passwords, executing binaries in memory, and conducting system checks to eliminate competing malware. The malware includes components masquerading as legitimate system files, and uses GPU capabilities for cryptomining. The campaign leverages exposed SSH services, highlighting the need for strong authentication practices. Aqua Security's platform detected the attack in real-time, illustrating the effectiveness of runtime protection in mitigating such threats.

The Gafgyt malware variant begins its attack by brute-forcing weak SSH passwords to gain initial access to target machines. BlueRock's SSH Deep Auth & SSH Least Privilege mechanism effectively mitigates this step by enforcing strong authentication practices and limiting SSH access to only necessary users, thereby reducing the attack surface. Once access is gained, the attacker executes shell commands to prepare the server for further exploitation. Here, BlueRock's Container Drift Protection (Binaries & Scripts) comes into play by preventing unauthorized executables and scripts from running, thus blocking the execution of malicious binaries that are not part of the original container image. This mechanism ensures that any attempt to execute unauthorized code is thwarted, protecting the system from further compromise.

• T1110.001: Brute Force: Password Guessing: The attacker initially gained access to the target machine by brute forcing SSH credentials, which were weak. This is evident from the statement: 'In this attack we see a successful brute force attempt on our SSH honeypot which is configured with a very weak password.'
• T1059.004: Command and Scripting Interpreter: Unix Shell: Once access was gained, the attacker executed shell commands to inspect and prepare the server. This is shown in the article: 'Once access is gained a few commands to inspect and prepare the server are executed.'
• T1082: System Information Discovery: The attacker conducted system discovery to check if the machine was already infected and to identify any competing malware. This is highlighted by: 'A few checks are conducted mainly to determine if the machine has already been infected by this variant of Gafgyt and to check if another malware is running and if so to kill it.'
• T1055.001: Process Injection: Dynamic-link Library Injection: The attacker used two binaries that were executed in memory to avoid detection, as indicated by: 'Next the two binaries are executed in memory.'
• T1496: Resource Hijacking: The attacker executed a cryptomining operation using the XMRIG cryptominer, as described: 'Executing the cryptominer: Figure 4: Executing the XMRIG cryptominer.'
• T1490: Inhibit System Recovery: The attacker modified system configurations to optimize performance and security, such as altering the /etc/sysctl.conf file. This is noted in: 'Configuration alteration: Figure 6: Modifying configurations /etc/sysctl.conf.'
• T1070.003: Indicator Removal: Clear Command History: The attacker deleted history and log files to evade detection, as indicated by: 'Lastly history and logs files are deleted to evade detection.'
• T1036.005: Masquerading: Match Legitimate Name or Location: The attacker used masquerading techniques to make their binaries appear as legitimate system components, as noted: 'The names of these binaries indicate that the threat actors are putting emphasis on defense evasion as these names are masquerading as legitimate components related to the Linux operating system environment.'
• T1105: Ingress Tool Transfer: The attacker downloaded a brute force configuration file from a command and control (C2) server, as shown: 'The function backgroundlogic in the malware is set to download from the threat actor’s server (at 107.189.5.210) the file 1.txt, which is a brute force configuration file containing 179 sets of users and passwords.'

‍

A critical vulnerability, CVE-2024-31989, has been discovered in the Argo CD Kubernetes controller, which has a severity score of 9.1. This vulnerability affects Kubernetes clusters using Argo CD, a GitOps continuous delivery tool. The flaw allows attackers to exploit the Argo CD server's elevated permissions, enabling them to escalate privileges and potentially take control of the entire Kubernetes cluster. The attack manipulates the data in Argo CD’s Redis caching server, which, by default, lacks password protection and can be accessed by any pod within the cluster. Attackers can alter application state manifests stored in the Redis server, recalculating the verification hash without a secret key, thereby tricking Argo CD into accepting malicious updates. To mitigate this vulnerability, users should update Argo CD to the latest versions (2.11.1, 2.10.10, 2.9.15, and 2.8.19), ensure the network policy "argocd-redis-network-policy" is enabled, and use controller-based secrets management tools. The vulnerability was responsibly disclosed, and patches have been released to address the issue.

The attack on the Argo CD Kubernetes controller begins with the exploitation of elevated permissions, allowing the attacker to manipulate the Redis caching server, which lacks password protection. This manipulation enables the attacker to alter application state manifests and trick Argo CD into accepting malicious updates. As the attacker deploys malicious pods with high privileges, BlueRock's Container Capability Control mechanism ensures that only containers with specified capabilities are allowed to run, effectively preventing the deployment of these potentially harmful containers. Furthermore, the attacker attempts to execute code on the host node by deploying a privileged pod. Here, BlueRock's Reverse Shell Protection mechanism comes into play by preventing unauthorized attempts to bind shell input and output streams to network sockets, thereby mitigating the risk of reverse shell attacks. These mechanisms collectively safeguard the Kubernetes environment from unauthorized container deployments and malicious script executions, maintaining the integrity and security of the cluster.

• T1068: Exploitation for Privilege Escalation: The article mentions that the attacker exploits the elevated permissions of the Argo CD server to escalate their privileges and potentially take control of the Kubernetes cluster. This indicates the use of privilege escalation techniques.
• T1600.001: Weaken Encryption: Reduce Key Space: The attacker manipulates the data stored in Argo CD’s Redis caching server, which lacks password protection. This involves altering application state manifests stored in the Redis server to exploit the system. This describes a manipulation of application state and configuration data.
• T1059: Command and Scripting Interpreter: The attacker uses the Argo CD server’s elevated permissions to deploy malicious pods with high privileges, which can execute code on the host node and access sensitive information. This demonstrates the use of deploying malicious code or scripts.
• T1114.002: Email Collection: Remote Email Collection: The attacker recalculates the hash for the manipulated manifest without a secret key, allowing them to modify the manifest data and present it as legitimate. This is indicative of the use of hashing algorithms to bypass integrity checks.
• T1610: Deploy Container: The attacker creates a low-privilege pod in another namespace to simulate a compromised pod within the cluster. This is a form of creating and using a container for malicious purposes.
• T1560.002: Archive Collected Data: Archive via Library: The attacker uses a Go program to decompress gzipped contents in the Redis server to uncover cached information about the applications managed by Argo CD, including their manifests and details about the Kubernetes cluster. This involves extracting and analyzing compressed data.
• T1057: Process Discovery: The attacker uses Redis profiler to observe interactions between pods and the Redis server to understand how application behavior is affected. This is a form of gathering information through monitoring and profiling.
• T1535: Unused/Unsupported Cloud Regions: The attacker modifies the application manifest in Redis and successfully deploys a privileged pod, which allows them to escalate privileges and execute code on the host node. This involves the manipulation of cloud infrastructure.
• T1021.004: Remote Services: SSH: The attacker adds their public SSH key to the node’s authorized keys, allowing them to connect to the node with an SSH shell. This is indicative of the use of SSH for remote access.

‍

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.

‍