- Misses the purpose of some RPM installs.
- Misses the missing shutdown account.
- Recovers /var/log/messages.
- Recovers /root/.bash_history.
- Lastlog analysis.
- Cron child PID analysis in cron.txt!
- Unrms files with debugfs.
- Recovers logging from swap in files/messages.
- Recovers /proc/net/tcp from swap file.
- Identification of intrusion method is OK (statd, clock skew,
shellcode in deleted /var/log/messages).
- Assumes the attacker runs Linux, hopcount 22 distance.
- Misses that some RPMs were installed to fix old bugs. [The
reasons that lead the attacker to installing these packages are
unclear to me. All the packages were originated from Red Hat, Inc.,
so there is almost no chance that they were not clear (=trojaned).
- Finds backdoor in unused inetd.
- Finds backdoor in unused in.ftpd.
- Finds backdoor in unused in.identd.
- When explaining what is known about the source of programs
found on the system, mentions RedHat 6.2 plus patch RPMs. But also
mentions origin of rootkit stuff in the rootkit analysis.
- Timeline.txt is a condensed time line. The rootkit analysis has
- The report suitable for management is missing, but has suggestions
on what would go in.
- Advisory is limited to statd exploit - no discussion of
what happened with the compromised machine.
The prevention section is inaccurate: statd cannot be packet
filtered since it runs on a random port.
The "how to detect" is marginal (active port 4545, 5002,...)
unusual files (/dev/ptyp and /usr/man/.Ci) No detection for
the trojaned installed software.
- Did not produce all documents as suggested, but did manage
to get most of the information in what was produced.
- Lack of organization, but the content is technically OK.
- Misses some things (why some RPMs were installed);
for some reason he uses atime analysis, not the power of
mactime that combines all time-related info.
- There's some good stuff in the non-described files
where he recovers logging and /proc/net/tcp from swap.
- Lack of use of forensic analysis tools is made up for by
- Uses a very interesting technique of analysing cron
logs to determine the amount of system activity by variation in
cron PID values. This source of data, as he points out, is not
addressed with by most rootkit "clean" scripts. It proves quite
accurate in this case in obtaining corroborating information about
login time activity. This technique has some limitations, though, on
systems that have continual high process turnover (e.g., major web
servers running CGI programs, systems that have frequent inetd managed
daemon activity, lots of interactive remote login sessions, etc.)
There may still be "quiet" periods during which an attacker is more
likely to be active.
- The rootkit analysis (all intruder files, actually) does a very
good job of both summarizing the files installed on the system
and identifying their source and configuration file associations.
This would aid in then tying some of these tools to their signatures
(as seen by IDS and firewalls) and advisories or exploit databases
- Supports timeline using references to the data sources
that produced his time/activity conclusions. (See also comments on Addam's entry.) I would only suggest
a little better use of whitespace to make this more readable.
- One problem with Peter's submission (and this is really not an
important issue in this case) is that he did not actually produce a
signed timestamp. He signed the MD5 hashes of files (which can prove
that he created the file), but there is no time associated with this
activity, and no independant third party who can attest to the time
at which it was created.
- Outstanding technical analysis (especially the cron
- Excellent rootkit analysis, best I have seen yet.
- Difficult reading the time line, syntax was a little
confusing. Maybe more use of whitespace.