2. Explain the impact that your actions had on the running system.
In presence of a compromised machine we need to be very
careful in examining it: any action could possibly lead to loss
of important evidence.
To this purpose, I did not save any file locally, but mounted
a floppy, and redirected the output of every command to a new
file on the floppy, for analisys to be performed on another machine.
It is definitely a bad idea to write whatever information
on the disk, as the new files could overwrite the blocks used
by previously deleted files.
In this particular case, it was soon very obvious that the logfiles
and other files had been deleted.
With a bit of hope we tried to recover them.
Most of them were little, and we recovered them first, outputting
to a floppy.
Two of them were big enough not to fit on a floppy, so I have
been forced to recover them locally, which might have led to overwriting
of some other information.
Indeed the operation worked well, as described in Answer
N.1.
It would have been better to be able to save them on a separate
disk or partition, but in this case it was not possible since
the one disk was entirely used already, with no space to crate
other
partitions, nor it was possible to add ('hot-swap'?) a new disk
in VMWare. AT least, not with the machine running.
It would have been possible to shutdown the machine, "connect"
another disk, start the machine from a bootable CD or floppy,
maybe mount the "compromised" disk in read-only, and
continue the analisys that way.
In this particular case though, it was clear that the rootkit
of the hacker was not installed or configured correctly, since
we were able to see some processes that "should" (in
the hacker's intentions, most likely) have been hidden.
All of the forensics research has been performed with trusted,
statically-compiled executables, loaded from a mounted cdrom.
Already this revealed us so much information that I found correct
to continue analysing the "live" machine for as long
as possible, and as throughly as I considered necessary.
Moreover, starting the machine for "dead" analysis
would have been a problem with the Forensics CD I was using, as
I later tried and it did not load the necessary SCSI drivers to
"see" the disk.
So we should have resorted to build another CLEAN RedHat Machine,
and mount the disk from it.
Other than recovering files, also other files were collected as evidence, always copying them to a floppy disk.
Another BAD idea in performing forensics is to launch not
known or not trusted executables, because they might behave in
destructive ways.
So I did export some executables on another disponsable system
for analisys.
For what concerns the network, the machine - as resumed
- was already disconnected from any network (due to the configuration
of VMWare that I choose, but even physically keeping the "host"
machine with the network cable unplugged).
This might be considered 'cheating' in the way of using VMWare...
but it is an effective protection.
Having the network cable unplugged when resuming, means that a connection was still visible with netstat, but of course that was disappeared shortly after.
Doesn't matter, we saw that as one of the first things, anyway and collected that evidence.
It is important to keep the evidence, but if the hacker
finds out that we discovered him, he might react in destructive
ways, furtherly destroying evidence that he's ever been there.
Moreover, disconnecting the machine, we avoid further damages/attacks
target at innocent third parties.
The aim of honeynets is to study the hackers in action, and share the lessons learned, not to provide them with extra attack launchpads ! :)
Previous | To answer N.3 --> List the PID(s) of the process(es) that had a suspect port(s) open (i.e. non Red Hat 7.2 default ports). | Home |