This document is being published jointly by the CERT Coordination
Center and AusCERT (Australian Computer Emergency Response Team). It
describes suggested steps for responding to a UNIX or NT system
compromise. Your response should be carried out in several stages:
Note that all actions taken during your recovery from a system
compromise should be in accordance with your organization's policies
and procedures.
Depending on how your organization is structured, it may be
important to notify management in order to facilitate
internal coordination of your recovery effort. Also be
aware that intrusions may get the attention of the media.
Before you get started in your recovery, your organization
needs to decide if pursuing a legal investigation is an
option.
Note that the CERT Coordination Center and AusCERT
(Australian Computer Emergency Response Team) are involved
in providing technical assistance and facilitating
communications in response to computer security incidents
involving hosts on the Internet. We do not have legal
expertise and cannot offer legal advice or opinions. For
legal advice, we recommend that you consult with your legal
counsel. Your legal counsel can provide you with legal
options (both civil and criminal) and courses of action
based on you or your organization's needs.
It is up to you how you wish to pursue this incident. You
may wish to secure your systems or to contact law
enforcement to investigate the case.
If you are interested in determining the identity of or
pursuing action against the intruder, we suggest that you
consult your management and legal counsel to see if any
local, state, or federal laws have been violated. Based on
that, you could then choose to contact a law enforcement
agency and see if they wish to pursue an investigation.
We encourage you to discuss the root compromise activity
with your management and legal counsel to answer the
following questions:
In general, if you are interested in pursuing any type of
investigation or legal prosecution, we'd encourage you to
first discuss the activity with your organization's
management and legal counsel and to notify any appropriate
law enforcement agencies (in accordance with any policies
or guidelines at your site).
Keep in mind that unless one of the parties involved
contacts law enforcement, any efforts to trap or trace the
intruder may be to no avail. We suggest you contact law
enforcement before attempting to set a trap or tracing an
intruder.
U.S. sites interested in an investigation can contact their
local Federal Bureau of Investigation (FBI) field office. To
find contact information for your local FBI field office, please
consult your local telephone directory or see the FBI's field
offices web page available at:
For more information, please see the web page of the FBI
Washington Field Office Infrastructure Protection and
Computer Intrusion Squad (WFO IPCIS):
You may wish to contact the U.S. Secret Service for incidents
involving the following:
To contact the Secret Service:
Non-U.S. sites may want to discuss the activity with their
local law enforcement agency to determine the appropriate steps
that should be taken with regard to pursuing an investigation.
To contact the Australian Federal Police:
In addition to notifying management and legal counsel at
your site, you may also need to notify others within
your organization who may be directly affected by your
recovery process (e.g., other administrators or users).
Therefore, you may wish to work through steps in section C.5. Look for signs of a network sniffer to
determine if the compromised system is currently running a
network sniffer.
Operating in single user mode on UNIX systems will prevent
users, intruders, and intruder processes from accessing or
changing state on the compromised machine while you are
going through the recovery process.
If you do not disconnect the compromised machine from the
network, you run the risk that the intruder may be
connected to your machine and may be undoing your steps as
you try to recover the machine.
If you have an available disk which is the same size and
model as the disk in the compromised system, you can use
the dd command in UNIX to make an exact copy
of the compromised system.
For example, on a Linux system with two SCSI disks, the
following command would make an exact replica of the
compromised system (/dev/sda) to the disk of the same size
and model (/dev/sdb).
Please read the dd man page for more information.
There are many other ways to create a backup of your
system. On NT systems there is no built in command like
dd, but there are a number of third party
applications that will make an image copy of an entire hard
drive.
Creating a low level backup is important in case you ever
need to restore the state of the compromised machine when
it was first discovered. Also, files may be needed for a legal
investigation. Label, sign, and date the backup and keep
the backup in a secure location to maintain integrity of
the data.
When looking for modifications of system software and
configuration files, keep in mind that any tool you are
using on the compromised system to verify the integrity of
binaries and configuration files could itself be
modified. Also keep in mind that the kernel (operating
system) itself could be modified. Because of this, we
encourage you to boot from a trusted kernel and obtain a
known clean copy of any tool you intend to use in analyzing
the intrusion. On UNIX systems you can create a boot disk
and make it write protected to obtain a trustworth kernel.
We urge you to check all of your system binaries thoroughly
against distribution media. We have seen an extensive range
of Trojan horse binaries that have been installed by
intruders.
Some of the binaries which are commonly replaced by Trojan
horses on UNIX systems are: telnet, in.telnetd, login, su,
ftp, ls, ps, netstat, ifconfig, find, du, df, libc, sync,
inetd, and syslogd. Also check any binaries referenced in
/etc/inetd.conf, critical network and system programs, and
shared object libraries.
On NT systems, Trojan horses commonly introduce computer
viruses or "remote administration" programs such as Back
Orifice and NetBus. There have been cases where the system
file that handles internet connectivity was replaced with a
Trojan horse.
Because some Trojan horse programs could have the same
timestamps as the original binaries and give the correct
sum values, we recommend you use
cmp on UNIX systems to make a direct
comparison of the binaries and the original distribution
media.
Alternatively, you can check the MD5 results for either
UNIX or NT on suspect binaries against a list of MD5
checksums from known good binaries. Ask your vendor if they
make MD5 checksums available for their distribution
binaries.
Additionally, verify your configuration files against
copies that you know to be unchanged.
When inspecting your configuration files on UNIX systems,
you may want to
When inspecting NT systems, you may want to
The common classes of files left behind by intruders are
Sniffers are more common on UNIX systems, but on NT
systems check for key logging programs.
We encourage you to search thoroughly for such tools and
output files. Be sure to use a known clean copy of any tool
that you use to search for intruder tools.
When searching for intruder tools on a compromised system
Keep in mind when reviewing any log files from a
compromised machine that any of the logs could have been
modified by the intruder.
On UNIX systems, you may need to look in your
/etc/syslog.conf file to find where syslog is logging
messages. NT systems generally log everything to one of
three logs for NT events, all of which are viewed through
the Event Viewer. Other NT applications such as IIS server
may log to other locations. IIS by default writes logs to
the c:\winnt\system32\logfiles directory.
Below is a list of some of the more common UNIX log file
names, their function, and what to look for in those
files. Depending on how your system is configured, you may
or may not have the following log files.
The first step to take in determining if a sniffer is installed
on your system is to see if any process currently has any of
your network interfaces in promiscuous mode. If any interface is
in promiscuous mode, then a sniffer could be installed on your
system. Note that detecting promiscuous interfaces will not be
possible if you have rebooted your machine or are operating in
single user mode since your discovery of this intrusion.
There are a couple of tools designed for this purpose.
Another issue to consider is that sniffer log files tend to
grow quickly in size. You may want to use utilities such as
df to determine if part of the filesystem is
larger than expected. Remember that df is
often replaced by a Trojan horse program when sniffers are
installed; therefore, be sure to obtain a known clean copy
of that utility if you do use it.
If you find that a packet sniffer has been installed on
your systems, we strongly urge you to examine the output
file from the sniffer to determine what other machines are
at risk. Machines at risk are those that appear in the
destination field of a captured packet, but if passwords
across systems are common or if the source and destination
machines trust each other the source machine will also be
at further risk.
Many common sniffers will log each connection as follows:
For sniffer logs of this particular format, you can obtain a list of
affected machines by executing the following command:
You may need to adjust the command for your particular
case. Also, some sniffers encrypt their logs so they may
not be obvious. Because of this check for files that grow
quickly.
You should be aware that there may be other machines at risk in
addition to the ones that appear in the sniffer log. This may be
because the intruder has obtained previous sniffer logs from your
systems or through other attack methods.
For more information, we encourage you to review CERT
Advisory CA-94:01, available from:
The advisory describes of sniffer activity and suggests
approaches for addressing this problem.
Please send us a list of all hosts you know to be
affected. This will help us determine the scope of the
problem.
If Australian or New Zealand hosts have been involved,
please inform auscert@auscert.org.au.
In examining other systems on your network, we encourage
you to use our Intruder Detection Checklists:
We would appreciate a "cc" to cert@cert.org or
auscert@auscert.org.au as appropriate on any
correspondence. If you like, you can let the site know that
you are working with us on this incident (please include
the assigned CERT or AusCERT tracking number in the subject
line of your messages). Also let them know that we can offer
assistance on how to recover from the compromise.
Our contact information is as follows:
Australian Computer Emergency Response Team
Our contact information is as follows:
Telephone: +1-412-268-7090 24-hour hotline
CERT Coordination Center
If you are still unsure of a site or contact details, please get in
touch with us.
We encourage you to restore your system using known clean binaries.
In order to put the machine into a known state, you should re-install
the operating system using the original distribution media.
We encourage you to check with your vendor regularly for any updates
or new patches that relate to your systems.
Remember to check the advisories periodically to ensure that
you have the most current information.
Past AusCERT advisories are available from:
Remember to check the advisories periodically to ensure that
you have the most current information.
Past CERT advisories are available from:
AusCERT has published the Choosing good passwords article which contains
information to educate users to choose good passwords.
A description of some tools that can be used to help secure a
system and deter break-ins is available from:
Introduction
This document sets out suggested steps for responding to a
UNIX or NT system compromise.
Canberra +61 2 6256 7777 Ask for the Co-ordination centre
Brisbane +61 7 3222 1222 Ask for Operations
Sydney +61 2 9286 4000 Ask for the Co-ordination centre
Melbourne +61 3 9607 7777 Ask for the Co-ordination centre
Adelaide +61 8 8419 1811 Ask for the Co-ordination centre
Perth +61 8 9320 3444 Ask for the Co-ordination centre
Darwin +61 8 8981 1044 Ask for the Co-ordinator
# dd if=/dev/sda of=/dev/sdb
# find / \( -perm -004000 -o -perm -002000 \) -type f -print
A network sniffer is a utility which will monitor
and log network activity to a file. Intruders
commonly use network sniffers to capture username
and password data that is passed in cleartext over
the network. (see section C.5 below)
Trojan horse programs are programs that appear to
perform one function while actually performing a
different function. Intruders use Trojan horse
programs to hide their activity, capture username
and password data, and create backdoors for future
access to a compromised system. (see section C.1 above)
Backdoor programs are designed to hide itself
inside a target host. The backdoor allows the user
that installed it to access the system without
using normal authorization or vulnerability
exploitation.
A majority of compromises are a result of machines
running vulnerable versions of software. Intruders
often use tools to exploit known vulnerabilities
and gain unauthorized access. These tools are often
left behind on the system in "hidden"
directories.
The intruder tools listed above are not intended to
be a conclusive or comprehensive list. There may be
other tools left behind by an intruder. Some of the
other types of tools you may find are tools to
You may find log files from any number of intruder
tools. These log files may contain information
about other sites involved, vulnerabilities of your
compromised machine(s), and vulnerabilities at other
sites.
The common item to look for when reviewing log files is
anything that appears out of the ordinary.
The messages log will contain a wide variety
of information. Look for anomalies in this file.
Anything out of the ordinary should be
inspected. Also, look for events that occurred
around the known time of the intrusion.
If the compromised system has a functioning ftp
server, xferlog will contain log files for
all of the ftp transfers. This may help you
discover what intruder tools have been uploaded
to your system, as well as what information has
been downloaded from your system.
This file contains binary information for every
user currently logged in. This file is only useful
to determine who is currently logged in. One way to
access this data is the who command.
Every time a user successfully logs in, logs out, or
your machine reboots, the wtmp file is
modified. This is a binary file; thus, you need to
use a tool to obtain useful information from this
file. One such tool is last. The output from
last will contain a table which
associates user names with login times and the host
name where the connection originated. Checking this
file for suspicious connections (e.g., from
unauthorized hosts) may be
useful in determining other hosts that may have
been involved and
finding what accounts on your system may have been
compromised.
Some versions of UNIX (RedHat Linux for example)
log tcp wrapper messages to the secure log
file. Every time a connection is established with
one of the services running out of inetd that uses
tcp wrappers, a log message is appended to this log
file. When looking through this log file, look for
anomalies such as services that were accessed that
are not commonly used, or for connections from
unfamiliar hosts.
Keep in mind that some legitimate network monitors and
protocol analyzers will set a network interface in
promiscuous mode. Detecting an interface in promiscuous
mode does not necessarily mean that an intruder's sniffer is
running on a system.
available for download from:
available for download from:
-- TCP/IP LOG -- TM: Tue Nov 15 15:12:29 --
PATH: not_at_risk.domain.com(1567) => at_risk.domain.com(telnet)
% grep PATH: $sniffer_log_file | awk '{print $4}' | \
awk -F\( '{print $1}'| sort -u
Telephone: +61 7 3365 4417 monitored during
business hours (GMT+10:00)
Hotline: +61 7 3365 4417 monitored 24 hours, 7
days for emergencies (GMT+10:00)
Facsimile: +61 7 3365 7031
The University of Queensland
Brisbane
Qld 4072
AUSTRALIA
Fax: +1-412-268-6989
CERT Coordination Center personnel answer business days
(Monday-Friday) 08:30-17:00 EST/EDT (GMT-5)/(GMT-4), on call
for emergencies during other hours.
Software Engineering Institute
Carnegie Mellon University
Pittsburgh, PA USA 15213-3890
External Security Bulletins are available from:
This document is available from:
http://www.cert.org/tech_tips/win-UNIX-system_compromise.html
We strongly urge you to encrypt sensitive information sent by email. Our public PGP key is available from
subscribe cert-advisory
* "CERT" and "CERT Coordination Center" are registered in the U.S. Patent and Trademark Office.
Copyright 2000 Carnegie Mellon University.
Revision History | |
April 17, 2000 |
Initial Release |