AMD has launched an investigation after the threat actor IntelBroker announced they were selling sensitive data allegedly belonging to the company.
“We are aware of a cybercriminal organization claiming to be in possession of stolen AMD data,” the chip maker told media outlets. “We are working closely with law enforcement officials and a third-party hosting partner to investigate the claim and the significance of the data.”
Earlier this week IntelBroker announced on the BreachForums cybercrime forum that they were “selling the AMD.com data breach.”
The seller states that the files were stolen in June 2024.
The allegedly stolen data includes information on future products, datasheets, employee and customer databases, property files, firmware, source code, and financial documentation.
The seller claims compromised employee data includes first and last names, job functions, business phone numbers, email addresses, and status.
It’s unclear if the data is authentic and which it the source.
IntelBroker recently made the headlines because he attempted to sell data from Europol and Zscaler.
Follow me on Twitter: @securityaffairs and Facebook and Mastodon
(SecurityAffairs – hacking, AMD)
Researchers at Datadog uncovered a new cryptojacking campaign linked to the attackers behind Spinning YARN campaign.
The threat actors target publicly exposed and unsecured Docker API endpoints for initial access.
The attack begins with the threat actor scanning the internet to find hosts with Docker’s default port 2375 open. After locating a valid host, they perform Docker reconnaissance by querying the Docker host’s version using the docker version command. Following this confirmation, the attacker starts the exploitation phase by attempting to create an Alpine Linux container and using Docker’s Binds parameter to map the host’s root directory (/) to a directory within the container (/mnt). Below is the command snippet used in the campaign:
Login"Image": "alpine",
"HostConfig": {
"Binds": ["/:/mnt"]
}If this step is successful, the attacker gains access to the Docker host’s underlying filesystem through the /mnt directory inside the container, allowing them to escalate their privileges.
In addition to defining the container image and host configuration parameters, the attacker executes a shell command within the container itself to set the root of subsequent processes.
The attackers were observed deploying multiple payloads, including chkstart) that downloads and executes additional malicious payloads and a tool to perform lateral movement (exeremo) used to propagate the malware via SSH.
The threat actors used a a shell script named “vurl” to retrieve the malicious payloads from a server under their control. The script includes another shell script called “b.sh” that, in turn, packs a Base64-encoded binary named “vurl” and is also responsible for fetching and launching a third shell script known as “ar.sh” (or “ai.sh”).
“After the attacker gains initial access and achieves execution via cron, the next stage of the campaign is to fetch and execute a new shell script—b.sh. This script contains a base64-encoded tar archive of a new binary named vurl. The script decodes and extracts this binary to /usr/bin/vurl, overwriting the existing shell script version, before fetching and executing one of two shell scripts—ar.sh or ai.sh.” reads the report published by the researchers.
The attackers use an unusual persistence mechanism by modifying existing systemd services and using the ExecStartPost configuration option to execute malicious commands.
The shell script “ar.sh” is used for multiple purposes including setting up a working directory, installing tools to scan the internet for vulnerable hosts, remove existing cron entries, weaken the system by disabling firewalls, clearing shell history, and preventing new lines from being added to the history file.
The script is ultimately used to fetch the next-stage payload “chkstart.”
Attackers used Golang binary, such as vurl, to set up a remote access and download additional tools from a remote server. The experts observed attackers downloading “m.tar,” and an XMRig miner called “top,”.
“This update to the Spinning YARN campaign shows a willingness to continue attacking misconfigured Docker hosts for initial access. The threat actor behind this campaign continues to iterate on deployed payloads by porting functionality to Go, which could indicate an attempt to hinder the analysis process, or point to experimentation with multi-architecture builds.” concludes the report.
“Although the likely objective of this campaign is to deploy an XMRig miner to compromised hosts, the attackers also ensured that they maintain access to victim machines via SSH. Maintaining remote code execution to victim hosts could mean that attackers can leverage their access for additional objectives”
Follow me on Twitter: @securityaffairs and Facebook and Mastodon
(SecurityAffairs – hacking, Docker)
VMware addressed multiple vCenter Server vulnerabilities that remote attackers can exploit to achieve remote code execution or privilege escalation.
vCenter Server is a centralized management platform developed by VMware for managing virtualized environments.
The vCenter Server contains multiple heap-overflow flaws, tracked as CVE-2024-37079, CVE-2024-37080 (maximum CVSSv3 base score 9.8), in the implementation of the DCERPC protocol.
“A malicious actor with network access to vCenter Server may trigger these vulnerabilities by sending a specially crafted network packet potentially leading to remote code execution.” reads the advisory published by the company.
Customers are recommended to install the released security patches, no workarounds are available.
The vulnerabilities were reported by Hao Zheng (@zhz) and Zibo Li (@zbleet) from TianGong Team of Legendsec at Qi’anxin Group.
VMware also addressed multiple local privilege escalation vulnerabilities, tracked as CVE-2024-37081 (maximum CVSSv3 base score of 7.8), in the vCenter Server.
“The vCenter Server contains multiple local privilege escalation vulnerabilities due to misconfiguration of sudo.” reads the advisory. “An authenticated local user with non-administrative privileges may exploit these issues to elevate privileges to root on vCenter Server Appliance.”
The issue was reported by Matei “Mal” Badanoiu from Deloitte Romania
VMware confirmed that it is not aware of attacks in the wild exploiting these issues.
The following table reports impacted products and fixed versions:
| VMware Product | Version | Running On | CVE | CVSSv3 | Severity | Fixed Version | Workarounds | Additional Documentation |
| vCenter Server | 8.0 | Any | CVE-2024-37079, CVE-2024-37080, CVE-2024-37081 | 9.8, 9.8, 7.8 | Critical | 8.0 U2d | None | FAQ |
| vCenter Server | 8.0 | Any | CVE-2024-37079, CVE-2024-37080 | 9.8, 9.8 | Critical | 8.0 U1e | None | FAQ |
| vCenter Server | 7.0 | Any | CVE-2024-37079, CVE-2024-37080, CVE-2024-37081 | 9.8, 9.8, 7.8 | Critical | 7.0 U3r | None | FAQ |
Follow me on Twitter: @securityaffairs and Facebook and Mastodon
(SecurityAffairs – hacking, VMware)
