Take the 2-minute tour ×
Information Security Stack Exchange is a question and answer site for Information security professionals. It's 100% free, no registration required.

I'm a linux noob and have an assignment I'm a bit stumped on... We're given VirtualBox (vdi) images and raw files for the state of a linux server at 3 different dates.

We're supposed to answer:

  • what order did people hack in and give themselves accounts?
  • did a certain user mess up ssh functionality for everyone?
  • what other shenanigans have people been up to?
  • tips: check out /var/log/ and the programs extcarve and Bulk Extractor

And we're not taught how to do any of this :(

My thoughts / questions:

  • I'm looking at the /etc/shadow file now for user accounts. This should work right? I'm not missing anything if I do it this way?
  • Googling yielded the existence of a /etc/ssh/ssh_config file, but I have no idea what to look for in here... Any tips? Is it possible to tell who modified a file? Or do I need to go through every user's /.bash_history to check? x_x
  • I looked at the /var/logs directory and didn't see anything immediately useful. Any ideas what he may want us to look for in here?
  • I'm not sure what other shenanigans he wants us to look for. extcarve and Bulk extractor sound useful if you're trying to put together statistic on the entire drive, or maybe a file was deleted and you want to check on what's left of it? Do you think that's what he has in mind?

Sorry for the noob questions, but thanks for any help!

share|improve this question
add comment

2 Answers

up vote 5 down vote accepted

Welcome to the Wild and Wonderful World of Forensics! So you have your images. Before you do anything else make sure you get a checksum of the disk images and also make a copy of them. The copy means you can work on it instead of the original, allowing you to roll back to the original state if you accidentally change anything on the system. The hash will allow you to validate your working copy against the original. For this purpose, just about any hashing algorithm should be sufficient.

In order to really understand what's going on, or went on, in a system you must first figure out what it was. It is obvious that you're looking at some form of UNIX derivative, probably a Linux, but you should attempt to determine which family it belongs to. Is it a RedHat, a Debian, a BSD, Solaris, or even something completely off kilter like AIX or HP-UX?

The type of system you're inspecting will determine exactly what log files you need to browse and how you determine where configs are stored. The advice to start in /var/log is pretty good, that is the default log location for Linux systems. Depending on the specific flavor you may also find useful information in /var/log/audit from the auditing subsystems (if installed) or the RBAC/MAC systems like SELinux or AppArmor.

Answering your specific config questions, account information is stored in a number of files: /etc/passwd, /etc/shadow, /etc/group, /etc/gshadow. The construction of each is well understood and easily researched. For other services the specific config files, and their construction, will require both research as well as experience based understanding on your part.

Performing a proper post-incident investigation requires that one have a deep understanding of the system you are analyzing. You will not only have to understand what files to look at, but also what files imply what, how different configurations can interact with each other, and (when carving) how a filesystem is actually constructed. Having been thrown into the deep end, as it were, will be tricksome, but can be gratifying. It's not without merit that the mantra of the Offensive Security team is Try Harder™. While this isn't exactly offensive work the principles definitely apply here.

share|improve this answer
add comment

The master file for user accounts is /etc/passwd. If the hackers have tried to hide their tracks, they might not have created an entry in /etc/shadow. They might not even have created an entry in /etc/passwd, but to some other database instead. This would have required them to add an entry to the passwd line in /etc/nsswitch.conf.

Entries in /etc/passwd and /etc/shadow appear in the order they were added, if the hackers used the usual tools to add accounts. They may of course have edited the files manually.

/etc/ssh/ssh_config (which may be located directly in /etc, this depends on the distribution) is the system-wide configuration file for the SSH client. There is a corresponding file sshd_config for the SSH server. Compare these files with the distribution's default.

If you don't know already, you should figure out what distribution this is. Since you have a VM you can run (make sure to isolate it from the network, and to keep copies of the original image!), it probably displays a message at boot time. With a disk image, look for files like /etc/redhat_release, /etc/debian_version, etc. Note that these files might indicate a derivative (e.g. /etc/debian_version is also present on Ubuntu). If there's an lsb_release command or a file /etc/lsb-release, it has the precise information. All of this is assuming no one has tried to muddle things up.

/var/log probably contains useful information, but finding it may be difficult. Most actions taken by the hackers have been logged, but they may have tried to hide their tracks. They may not have been thorough, though. It's difficult to delete all incriminating logs while retaining enough legitimate ones not to make the logs suspicious — if there are no logs for a long time, missing logs from cron jobs, etc., this tends to indicate someone bulk-erased a time period.

If the hackers edited the log files, traces of the old content may remain in unused sectors. Carving tools may help you find these sectors.

“Other shenanigans” may include things like inserting a rootkit into the kernel (in which case nothing the live system reports can be trusted, but the disk image won't lie, at least not directly), hiding a setuid root shell somewhere, changing the password to the root account (or adding an account with uid 0 and another name), ...

share|improve this answer
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.