Security Training
Security Certification
Cyber Security Graduate School
Internet Storm Center
Security Awareness Training
Computer Forensics
Penetration Testing
IT Audit
Software SecurityIntrusion Detection FAQ: Linux System Compromise
|
Version 1.0 January 25, 2000 Stephen Northcutt Many GIAC readers are experienced at handling compromised systems, they do it every day and do not have to think about it. However, many people have never thought about a system compromise until they face one. This is the story of a Linux box that was overtaken by hackers, and used to attack many other systems, we offer it in the hope you can learn from this. Mostly the material is presented "as is" with some additional comments. You should know that many times the files left behind are inaccurate or incomplete. NEVER assume you can repair a compromised system simply by fixing the binaries mentioned in a history file, even so we do find this educational. If you have information of this type and are willing to share with your community please send email to handler@incidents.org We will start with the note from the system administrator. +++ Hi Stephen, Thank you for your offer to help analyze the logs for my hacked Linux Box 10.33.151.244. I appended my logs and other useful info such as a script left behind by the hacker to the end of this message. As you can see I captured a lot of information. My guess is that the attacker couldn't clean up after himself because he messed up my computer too much and he could not log back in. But maybe he was just sloppy. I don't know. One thing is for sure though: He left the computer in such a state that I could not log in remotely anymore and I had to reinstall Linux. I also found out that he replaced my login and in.identd binaries. I also included two emails from other sysadmins. These are useful in that they help identify the means the attacker tried to get into other systems. Please let me know if you guys can find out more about how he got in and what he exactly did. And in particular: What I need to do to avoid such attacks in the future. Thanks for your help. -kornel +++ (The system’s log files yield some significant clues, let’s start by looking at these. First note the date, the time between December 22 and January 02 is always a very dangerous time. Many systems are unattended, but left on. From my review of the logs, I never see an entry point per se the system is already compromised.) -------------------------------------------------- (There will be two actors, or account names and they are introduced right here, danz and rmfc) Dec 23 23:58:58 turing telnetd[19278]: ttloop: peer died: Invalid or (Note this is very similar to the activity Laurie keeps reporting, I would really like to understand this better. This could be a strong hint that the telnet probes we all see are more than just reconnisannce to determine the operating system.) Dec 24 00:01:00 turing PAM_pwdb[19286]: (Wasn’t it Mae West who said they keep coming and going and coming and going and always too soon?) Dec 24 00:08:15 turing kernel: nfs: (Why attack a compromised system? Perhaps they are trying to new techniques or perhaps someone else wants a piece of the action. Secure portmap would come in handy here.) +++
|
Check Them Out!
The instructors are very knowledgeable, humorous, and give excellent resources/tools I never knew of, but can use to help enhance my security skills.
-LaTrease Coleman, Vanguard Group
