Carding Forum
Professional
- Messages
- 2,788
- Reaction score
- 1,176
- Points
- 113
How do vulnerable servers turn into invisible mining machines?
A recent study by Trend Micro revealed that attackers can use the Jenkins script console to run malicious scripts aimed at mining cryptocurrencies. This is possible if authentication is configured incorrectly, which opens access to the console and allows remote code execution (RCE).
As an open source Continuous Integration and Delivery (CI/CD) solution, Jenkins provides extensive capabilities for automating software development. However, incorrect server settings and outdated versions of Jenkins can become a target for hackers seeking to launch cryptominers and other malicious programs.
The Jenkins Scripting Console allows administrators and authorized users to execute Groovy scripts with system privileges. If authentication is configured incorrectly, attackers can gain access to this console and use it to run malicious scripts.
Attackers often use tools such as Shodan to find vulnerable Jenkins servers available on the Internet. Research has shown that many of these servers are not properly protected and can be used in real attacks. While not all publicly available Jenkins servers are vulnerable, they may well be entry points for hackers.
In their attacks, attackers inject a Base64-encoded script into the system, which is run through the Jenkins script console. This script checks whether it is running in the BusyBox environment and, if so, exits. The script then searches for directories with write permissions to download and run the cryptominer.
The script includes the function of checking available system resources for efficient mining. It identifies and terminates processes that consume more than 90% of CPU resources, which allows you to free up resources for the miner to work. If there are no suitable directories, the script uses the /tmp directory and creates a subdirectory with the maximum permissions for performing operations.
To keep the miner running, attackers use cron jobs and the systemd-run utility. Cron jobs ensure that the miner starts up regularly, and systemd-run makes sure that the miner starts up every hour. These methods guarantee that the miner will run continuously, despite possible system restarts.
Cron jobs use the flock utility to lock the file to ensure that only one copy of the miner is running at any given time. The script also deletes all duplicate cron entries to prevent the miner from running multiple times.
To protect your Jenkins instances from such attacks, we recommend following the following best practices:
Jenkins provides powerful capabilities for automating software development, but these same capabilities can be used by attackers if the system is configured incorrectly. Organizations should carefully monitor their security settings, regularly update their software, and conduct audits to protect their Jenkins servers.
Source
A recent study by Trend Micro revealed that attackers can use the Jenkins script console to run malicious scripts aimed at mining cryptocurrencies. This is possible if authentication is configured incorrectly, which opens access to the console and allows remote code execution (RCE).
As an open source Continuous Integration and Delivery (CI/CD) solution, Jenkins provides extensive capabilities for automating software development. However, incorrect server settings and outdated versions of Jenkins can become a target for hackers seeking to launch cryptominers and other malicious programs.
The Jenkins Scripting Console allows administrators and authorized users to execute Groovy scripts with system privileges. If authentication is configured incorrectly, attackers can gain access to this console and use it to run malicious scripts.
Attackers often use tools such as Shodan to find vulnerable Jenkins servers available on the Internet. Research has shown that many of these servers are not properly protected and can be used in real attacks. While not all publicly available Jenkins servers are vulnerable, they may well be entry points for hackers.
In their attacks, attackers inject a Base64-encoded script into the system, which is run through the Jenkins script console. This script checks whether it is running in the BusyBox environment and, if so, exits. The script then searches for directories with write permissions to download and run the cryptominer.
The script includes the function of checking available system resources for efficient mining. It identifies and terminates processes that consume more than 90% of CPU resources, which allows you to free up resources for the miner to work. If there are no suitable directories, the script uses the /tmp directory and creates a subdirectory with the maximum permissions for performing operations.
To keep the miner running, attackers use cron jobs and the systemd-run utility. Cron jobs ensure that the miner starts up regularly, and systemd-run makes sure that the miner starts up every hour. These methods guarantee that the miner will run continuously, despite possible system restarts.
Cron jobs use the flock utility to lock the file to ensure that only one copy of the miner is running at any given time. The script also deletes all duplicate cron entries to prevent the miner from running multiple times.
To protect your Jenkins instances from such attacks, we recommend following the following best practices:
- Use the script approval feature provided by Jenkins. This will limit the execution of unknown or potentially malicious scripts.
- Configure the correct authentication and authorization policies for accessing the web console. You should use the Jenkins access control guidelines.
- Enable the log audit function to track actions on the server and detect suspicious activity.
- Restrict access to Jenkins servers from the Internet to prevent unauthorized access.
Jenkins provides powerful capabilities for automating software development, but these same capabilities can be used by attackers if the system is configured incorrectly. Organizations should carefully monitor their security settings, regularly update their software, and conduct audits to protect their Jenkins servers.
Source
