HackDig : Dig high-quality web security articles for hacker

Analysis of the Procedure of Penetration on a Hacked Host

2016-04-02 17:30

Author: HRay
From: http://drops.wooyun.org/tips/13647

0x00 Conclusion


On the morning of 14th, a colleague of mine reported that the CPU usage of a host reached up to 100%. Then Security Department embarked on investigation and concluded the followings:

  1. Port access was not restricted on this host and SSH was exposed to the Internet.
  2. A large amounts of external IP (100+) brute force attacked this host and a sum of 6 external IPs successfully passed SSH authentication starting from 21:12 14th.
  3. Passing the authentication, an automation program deployed a backdoor and was added to Scheduled Task. The first malicious scheduled task was executed at 22:21:01. Comparing the several backdoors that were found, there were actually two executable files (based on parts of behavior), while others just used different file names.
  4. Because of the malicious process, CPU usage of a machine increased to 100% on the morning of 14th, resulting the backdoor to be discovered.

0x01 Procedure


Here is the analysis procedure:

On logging the host, the suspicious process PID is identified

Enter into process directory proc/. The absolute path for the corresponding file is /usr/bin. Here’s the stat information:

[root@xxx.com 13146]# stat /usr/bin/faksiubbri
  file: `/usr/bin/faksiubbri'
  Size: 610224          Blocks: 1200       IO Block: 4096   regular file
Device: 802h/2050d      Inode: 312739      Links: 1
Access: (0755/-rwxr-xr-x)  Uid: (    0/    root)   Gid: (    0/    root)
Access: 2015-01-14 10:33:13.000000000 +0800
Modify: 2015-01-14 10:29:06.000000000 +0800
Change: 2015-01-14 10:29:06.000000000 +0800
 
[root@xxx.com 13862]# stat /usr/bin/ohzxttdhqk
file: `/usr/bin/ohzxttdhqk
Size: 625622          Blocks: 1232       IO Block: 4096   regular file
Device: 802h/2050d      Inode: 312741      Links: 1
Access: (0755/-rwxr-xr-x)  Uid: (    0/    root)   Gid: (    0/    root)
Access: 2015-01-14 10:32:59.000000000 +0800
Modify: 2015-01-14 10:29:26.000000000 +0800
Change: 2015-01-14 10:29:26.000000000 +0800

In a preliminary estimate, the attack occurred at around 10:29 on the morning of 14th and obtained root permission.

Remote IP and other information can be found by using strings to check file contents.

The IP is from a host in Hong Kong and the following contents are found in Weibo.

Combined with strings and other information, the file is conformed as a malware. Currently the first priority is to determine which ways attackers used to penetrate the host. A few detours are made here because:

  1. Web and FTP service are running on the server but without root permission.
  2. The last login is perfectly normal and no suspicious operation history is found. Besides default ssh port is not opened. Therefore, attacks on SSH are underestimated.
  3. The server has bash vulnerability, so the attacks may utilize the bash vulnerability and privilege escalation. However, no suspicious access log is found.
  4. The previous time judgment based on stat file is not correct. Later we found the administrator has killed s process and when a process ends, it deletes itself and generates a new file. Therefore, the time information in stat actually shows the time that the administrator killed a process.

Then a colleague searched that this ddos backdoor is distributed through brute force attack on SSH, so we shit our focus back to SSH. Confirmed by professionals, this server opens its 22 port for special reasons and uses weak password. In view of these information, this server may be suffered by SSH brute force attack, so security log needs to be checked.

6 hosts from external network shows successful authentication records ranging between 21:12 and 23:59 of 13th. In the secure log, ip118.193.199.132 and ip104.149.220.27 have no record that shows wrong password, so it’s estimated that attackers used another host to perform brute force attack and then they used other hosts to login with the returned password.

It shows in the cron log that two malicious scripts get executed every three minutes.

/etc/cron.hourly/cron.sh
/etc/cron.hourly/udev.sh

Here are the contents of the cron.sh file

Based on file size and the contents of strings, /lib/libgcc.so is almost the same as the malware ohzxttdhqk under /usr/bin.

Here are the contents of udev.sh

Based on file size and the contents of strings, /lib/libgcc4.so is almost the same as the malware faksiubbri under /usr/bin.

The two files are executed respectively at:

According to the fact that its time line complies with the time of brute force, this backdoor is implanted by attacking SSH.

Viewing the secure log, the time difference between IP passed SSH authentication and connection disconnected is as follows:

221.235.189.229

62.210.180.180

103.41.124.48

118.193.199.132

175.126.82.235

Jan 13 23:22:23 After passing authentication, no disconnection information shows.

104.149.220.27

Based on the time difference between IP passed SSH authentication and connection disconnected, the time difference between 221.235.189.229, 62.210.180.180 and 103.41.124.48 is 0, so attackers made no other move after successfully performing brute force attack. Combined with the scheduled task running time and time difference, the two IPs that used to implant the backdoor are 118.193.199.132 and 175.126.82.235.

But its time difference between 118.193.199.132 is 5 seconds, for human it’s hard to implant a backdoor in such a short time, therefore, it may be done by automated program.

0x02 Reasonable Doubts


At the moment, it’s not sure how the backdoor is deployed?

We verified that whenever you remotely copy a file to the host through scp and login through SSH, a log of Received disconnect is created. If automation is deployed through SSH, why there’s no record in the last login? If relevant records are deleted independently? If it’s remote copy through scp, then how is it deployed? Right now we don’t know if there’s any method that could be used to put a file into a machine and let it to automatically execute, is there any other deployment methods?

0x03 Improvements


  1. Check if there are other hosts that open its ports to the outside

  2. Check if there is malware in other hosts and pay attention to

    1. if there is a filename with 10 random characters under directory /etc/init.d/
    2. if there is a filename with 10 random characters under directory /etc/rc%d.d/S90
    3. if there is /etc/cron.hourly/udev.sh
    4. if there is /etc/ cron.hourly/cron.sh
    5. if there is any suspicious scheduled tasked task in /etc/crontab
    6. if there is any filename with 10 random characters under directory /usr/bin
  3. fix the bash vulnerability on host

  4. improve the complexity of the host password (including not to open the important ports)

  5. For hosts with abnormalities, security researchers should try not to perform any operation before investigation. If you have to operate on files, save stat information first and back up file contents. Execute stat /etc/passwd and stat /etc/shadow and save execution results before changing password/creating new account/delete an account.

0x04 Digression


The above post is a response report for enterprises. The analysis procedure can be a reference, which can be improved is that we wasted some time because we subjective thought it cannot be SSH penetration. When you hit the bottleneck during analysis, focus more on the log instead of assumption. Next part is some popular thoughts and commands often used in incident response under Linux, wishing it could be of help.

Web intrusion

For Web intrusion, troubleshoot based on the following points:

1.Log stat information of the backdoor and determine when the intrusion happens; other than that, compare with accesslog to determine if it’s the first backdoor.

2.Based on the known mtime and file contents as searching features to locate other backdoors, or compare with svn or previous file backup; or use some webshell AV software to pack files under web directory.

3.Search for file command being modified in a day

find /home/work –mtime -1 –type f

4.Search for files with specified characters (use known shell password or certain character as keyword)

find /|xargs grep -ri "Bot1234" -l 2>/dev/null (on execution, it changes the atime of all files, please finish operation 5 first)

5.On viewing larger log files, screen specified characters through fgrep, for instance, when knowing the shell file is conf.php, use command to scree, the visit log of conf.php; for some highly dangerous vulnerabilities, use the keyword of exploitation as keyword to screen, through the first step, you’ll find information about intruder’s IP in the results, based on the information you find, you may further conduct your investigation on all visit logs.

6.Determine its effects, when webshell is manifested as post without traffic mirror, if some sensitive files can be accessed are determined by atime information, such as source code package or files with password information. Besides, the number of request to webshell and the number of returned characters are both the basis for loss assessment.

Non-WEB intrusion

It’s mainly achieved through other risky services. Most of the current cases are that SSH is exposed to external network or uses weak password, for such cases, you may determined by syslog.

Here are a few things to check:

  1. Determine if the server supports access to external network, using netstat –an to check if the server connects to any suspicious external servers, if it is, disconnect it.
  2. Log the stat information of backdoor file and locate other backdoor files based on its mtime, meanwhile determine intrusion method based on file group and the corresponding service.
  3. If it has permission root, check if it’s rootkit by using: http://rkhunter.sourceforge.net/
  4. Many tend to place malicious files of non-web backdoor under /tmp. Check on suspicious process name and cpu usage. Some backdoors will disguise as normal process name, but the top command can find out backdoor process through cpu usage. On getting PID, you’ll be able to cd /proc/ to the corresponding pid directory. ls –al is to get the file path by checking the exe value. Besides, you can check scheduled tasks, because backdoor often add new scheduled tasks to guarantee Autorun.


Source: lmth.84/92/30/6102/oi.nuyoow.ne

Read:2513 | Comments:0 | Tags:No Tag

“Analysis of the Procedure of Penetration on a Hacked Host”0 Comments

Submit A Comment

Name:

Email:

Blog :

Verification Code:

Announce

Share high-quality web security related articles with you:)

Tools

Tag Cloud