('binary' encoding is not supported, stored as-is) In-Reply-To: <8282.1027970415at_private> Ingram, There are two different techniques which I have used which might help, if not in this particular case, perhaps in any future incident response scenarios you face - 1) If you are ever stuck in the situation where you have a compromise and you did NOT create an hash database of your system (Tripwire/AIDE, etc...) prior to the attack, then there is another option for quickly identifying files that have changed on your system. I have used Rsync during incident responses for this purpose. I have a statically compile version of Rsync (for each OS in my environment) burned onto my IR Toolkit CDROM. I simply mount the CDROM and can then run rsync to compare the localhost files against a secure host. Rsync has a wide range of flags to aid in identifying changed files. You could compare the files by date stamps, file sizes, ownership, etc...You can even run the checksum portion (128 bit MD4) to compare the files - this will essentially do the same thing as Tripwire - except that it is done dynamically over the network. Think of it as "Remote Tripwire". I usually run rsync first with "--size-only" and "--dry-run" flags to quickly tell me which files in /bin & /sbin, have different sizes and not to transfer them yet. This speeds up the the normally slow process of creating a new Tripwire database and then having to transport the database to another server to run it againsts a different host... 2) The second method that you could use to quickly find some places to investigate is to use a "Key Word Search" against your compromised disk. You could run a command similar to this - "# dd if=/dev/ad1s4 | strings | egrep -f hacker_words.txt | less". This is a technique that I have used many times to quickly identify places to start an investigation. The key to this method is the "hacker_words.txt" file. This file should be a large listing of common words associated with hacking, rootkits and exploits. These are words that are commonly found within rootkit files. For more information on this topic and an example of my hacker word file, you can read my GCFA practical paper where I had to analyze an unknown binary file - http://mywebpages.comcast.net/rbarnett45/ryan_barnett_gcfa/binary_analysis. html#keywords I hope this helps you with any future investigations! *********************** Ryan C. Barnett Senior Security Analyst SANS - GCUX, GCIH, GSEC *********************** >>greetings community, > >i´m trying forensics on a real breakin for the first time and, well >it´s >a really difficult task. I read some papers on forensic and TCT but i´m >stuck in finding out what exactly happend. > >1) The Situation >On Jul 2 i installed an OpenBSD 3.1 Host in our DMZ, foolish as i was >i did _not_ patched it directly. This was the time when the gobbels >ssh remote root exploit was released. The machine had only one >open port... ssh. > >2) The Break in >On Jul 4 i wanted to patch the server, doing a usual 'ps ax' bevore >showed me the following very suspect lines: > >14838 C0 Is+ 0:00.02 login -p >--\^[[20~0\^[[20~\^[[18~\^[[18~4cxs\^[[13~\^[ > 1012 C0 I+ 0:00.01 krb4-or-pwd -s >login\^[[20~0\^[[20~\^[[18~\^[[18~4cxs\^[[13~\^[ default >(login_krb4-or-pw) > >after i´ve seen that i (*maybeafailure*) stopped this to services with >'kill' and >halted the machine. > >3) My forensic... >I turned power off, and put the harddisk into my develop box, mounting >it >read-only. >laboratory# mount -o ro /dev/ad1s4 /mnt > >Next step was 'graverobber', 'unrm' and 'lazarus' from TCT: >laboratory# script >laboratory# grave-robber -v /mnt >laboratory# unrm /dev/ad1s4 >unrm_output >laboratory# lazarus -h unrm_output > >Well, now i got 1.8 gig output which could be analysed... but for what? >Looking at >every single file seems to take a whole lifetime, since i have no clue >what >the >attacker could have done i dunno what to look for. What makes this much >harder is >that there were some files recovered which seem to be from a previous >installation. > ----------------------------------------------------------------- This list is provided by the SecurityFocus ARIS analyzer service. For more information on this free incident handling, management and tracking system please see: http://aris.securityfocus.com
This archive was generated by hypermail 2b30 : Sat Aug 03 2002 - 19:29:25 PDT