what you don't know can hurt you


Posted Aug 17, 1999
Authored by van Hauser

Interesting text explaining how to cover your tracks when you leave the system.

tags | paper
MD5 | 4a2e105548abea403482893d5f03dd68


Change Mirror Download


<TITLE>How to cover your tracks - Practice</TITLE>


<body bgcolor="#000000" text="#ADD8E6" link="#FFFF00" onLoad="window.status='Images and Code Copyright (C) 1997 GPF'; return true">







<table border=3 cellpadding=7 cellspacing=3>

<tr><td>Author: <I><a href="mailto:mc@thc.net">van Hauser</a> / THC</I><br>

HTML-version by <a href="mailto:matic@bau2.uibk.ac.at"><I>Markus H&uuml;bner</I></a>









The first command you should enter after logging in with a hacked account

is a shell different from the one you are currently running as login shell.

The purpose is to disable history saving of the commands you'll type in

while hacking. A history check by the real user or sysadmin reveils your

presence and what you did!!

If you are running a CSH then execute a SH and vice versa.



$ <- this is a SH prompt

% <- this is a CSH prompt



If it does not look like the standard prompts above then execute SH.

If the prompt stays the same, type "<TT>exit</TT>" and execute the CSH ...

The reason for using these two shells and not bash, ksh, zsh etc. is

that these two are simple with no extra options enabled by default

(like history saving).




If you saw a text like "Last successful login from alpha.master.mil"

when you logged on with the hacked account and you can't hack root or

don't want to disrupt the system logs with deleting data then execute

the following : "<TT>rlogin <the_host_you_are_on></TT>" and provide again the

password of the hacked account if necessary. After seeing the shell

prompt type "<TT>exit</TT>" to be back again. This will change the header

"Last login from ..." etc. to the <current host> or "localhost"

which is much more unsuspicious than "site.real.user.never.saw.com"

Of course you only need to do this if your origin host might attract

attention to user and/or sysadmin.




After completing step 1 + 2 type "w" ... you'll see all currently

online users ... with the adress they logged on from. Once again

something like your origin host in the netherlands will be very

suspicious to users and/or root if the site is in the usa.

If you can't hack root or once again don't want to tamper with the

log files you can try a bug which works still for many up2date

unix distributions: just execute "<TT>login</TT>" with the same login+password.

Type "<TT>w</TT>" again and if it worked, your origin will be changed to

something like "tty05".<BR>

Of course you only need to do this if your origin host might attract

attention by other users and/or sysadmin.




Don't execute programs with suspicous names ... <TT>ISS</TT> and <TT>YPX</TT> are for

example very suspicous, and a skilled admin knows what's going on if

he sees a user running "loadmodule SandraBullok" on his Sun ... ;-)

Either you copy & rename the commands or you use those sources around

which exchanges the command name in the process list.

Btw. the process list can be checked by "<TT>ps -ef</TT>" or "<TT>ps -auxwww</TT>" and

the current command every user is executing with "<TT>w</TT>" and the most CPU

consuming processes with "<TT>top</TT>" ... so it's really easy to monitor

the programs the user(s) are running.




There are only two things which should be said about about using telnet

for hacking purpose (e.g. doing a telnet to the next target).

First <I>NEVER</I> just type "<TT>telnet target.host.com</TT>". Type "<TT>telnet</TT>" and then

"<TT>open target.host.com</TT>" which will not show up as parameter in the process

list. The seconds is that some telnet clients do export enviroment

variables. And if your hack is detected and they could trace the

connection back to your origin host they could also have got the account

you used on the origin host. So redefine (to anything you want) the

following environement variables before starting telnet, rlogin or similar:

<TT>USER</TT>, <TT>LOGNAME</TT>, <TT>UID</TT>, <TT>HOME</TT>, <TT>MAIL</TT> - maybe you should do a "<TT>cd /tmp</TT>" too

to change the <TT>PWD</TT> variable too ...

To change those variables:


SH : &#60variable>=&#60new_value>;export &#60variable>

<I>example</I> : USER=nobody;export USER

CSH: setenv &#60variable> &#60new_value>

<I>example</I> : setenv USER nobody


and don't forget to reset the variables after your telnet if you want to

do something with the account before you log out.




When you tried exploits - successful or not - delete them immedeantely

after trying them - especially if you try them in <TT>/tmp</TT> !

Nothing is more interesting than snooping in the <TT>/tmp</TT> directory to see

what other users are doing ... If you really need to work in the temp

directory (because suid is squashed in your home dir) then create a

usual directory like "<TT>.X11</TT>", and give it 711 permissions.

Remember, if someone snoops in the directories while you are hacking or

your loose connection and can't relogin or you forget about them you

are in deep trouble.



--> ! The following 2 points are only possible with root access ! <--




The important log files are <B>LASTLOG</B>, <B>WTMP</B> and <B>UTMP</B>.

If you were successful in hacking root then you should modify them.

They can usually be found in <TT>/etc</TT>, <TT>/var/adm</TT> or <TT>/var/log</TT> ... it differs,

just check the man pages.<P></P>

Which tools should you use? <TT>ZAP</TT> (or <TT>ZAP</TT>2) is nice, but it does <i>NOT</i> delete

you from the logs but overwrite the entries with zeros. CERT already

published tools which easily check the logs for those overwritten entries.

And nothing shouts more "Hey there's a hacker on the system with root

access!" into the sysadmin's face than that.

Important for <TT>ZAP</TT> : Check the paths defined in the sources for the logs!

Try <TT>CLOAK2</TT> which can change the data of the important data fields ;) But

it doesn't compile on all unix OS types.

You can also try CLEAR, included in this magazine, which <i>REALLY</i> deletes

the entries ... ;)




You should also check the syslog messages logfile if maybe entries with

your hacked account or your origin host are in it. It's usually located

in <TT>/var/adm</TT> or <TT>/var/log</TT> ... most time it's called "messages" but again

can differ - and also check other logfiles there which are generated by

<TT>auth.*</TT> and <TT>authpriv.*</TT> messages (and of course <TT>xferlog</TT> etc.).

Check the file <TT>/etc/syslog.conf</TT> to see the correct file and check out what

is logged to which file/program/mail/user.<P></P>

If you see something like "<TT>@loghost</TT>" and you find your origin host in

the messages file than you've got a problem. It's also logged at another

site which is most time not accessible from remote. But try to install

a sniffer, (see section VIII. !) and check if a root does a successful

login to the loghost - and then you've got also the password for that

host and are in to handle the problem ;)<BR>

To remove f.e. your hostname from the "messages" logfile execute :<BR>

"<TT>grep -v evil.host.com messages > /tmp/tmpfile; mv /tmp/tmpfile messages</TT>"


<TT>LASTCOMM</TT> (from accton etc.) is a tool to log all executed commands, with

a flag if the file executed had the SUID flag set and if a command was

executed by root. You can find this logfile in the same directory as the

syslog file. That's a really evil tool against hackers but - luck! -

most times it is not installed. But now you don't have to fear that

anymore :) Get Zhart's excellent ACCT Cleaner and feel the freedom ;-)




When you install a sniffer, remember that anyone can execute "<TT>ifconfig -a</TT>"

to check if the card is in promiscious mode. Get a rootkit for your unix

OS and replace it. Run <TT>fixer.c</TT> on it for the correct checksum and date/time

but check the root account first if maybe tripwire or other binary checker

are installed! Remember this for every binary you replace. If the binary

is in a directory which is NFS mounted and can't be remounted in write mode

then you must first hack the NFS host - life isn't easy sometimes ;)



<FONT SIZE=1 COLOR="000080"><H2>X. THE END</H2></FONT>

I hope you had fun and learned alot from these two textfiles, the

theory/background and the practice one.

For updates, tips, tricks etc. just email me at <a href="mailto:mc@thc.net">mc@thc.net</a>


Remember : Never get lazy. Every work must be done 100% -

or face the consequences!





Type Bits/KeyID Date User ID

pub 1024/3B188C7D 1995/10/10 van Hauser/THC of LORE BBS


Version: 2.6.3i























<a href="../hack.htm">Back to Index</a>






Login or Register to add favorites

File Archive:

May 2020

  • Su
  • Mo
  • Tu
  • We
  • Th
  • Fr
  • Sa
  • 1
    May 1st
    14 Files
  • 2
    May 2nd
    3 Files
  • 3
    May 3rd
    1 Files
  • 4
    May 4th
    18 Files
  • 5
    May 5th
    15 Files
  • 6
    May 6th
    21 Files
  • 7
    May 7th
    15 Files
  • 8
    May 8th
    19 Files
  • 9
    May 9th
    1 Files
  • 10
    May 10th
    2 Files
  • 11
    May 11th
    18 Files
  • 12
    May 12th
    39 Files
  • 13
    May 13th
    15 Files
  • 14
    May 14th
    17 Files
  • 15
    May 15th
    17 Files
  • 16
    May 16th
    2 Files
  • 17
    May 17th
    2 Files
  • 18
    May 18th
    15 Files
  • 19
    May 19th
    21 Files
  • 20
    May 20th
    15 Files
  • 21
    May 21st
    15 Files
  • 22
    May 22nd
    6 Files
  • 23
    May 23rd
    1 Files
  • 24
    May 24th
    1 Files
  • 25
    May 25th
    2 Files
  • 26
    May 26th
    23 Files
  • 27
    May 27th
    13 Files
  • 28
    May 28th
    18 Files
  • 29
    May 29th
    6 Files
  • 30
    May 30th
    0 Files
  • 31
    May 31st
    0 Files

Top Authors In Last 30 Days

File Tags


packet storm

© 2020 Packet Storm. All rights reserved.

Security Services
Hosting By