Common Indicators of Security Incidents

Several types of events are common indicators of security incidents. You should pay particular attention to these types of events. Although after investigation, most of these events will prove harmless, some will warrant closer investigation and possibly trigger your organization s incident response plan.

Internet Port Scans

The most common indicator of a security incident is the scanning of Transmission Control Protocol (TCP) and User Datagram Protocol (UDP) ports from the Internet. Because port scanning can be a prelude to more serious penetration attempts, you should keep track of the amount and type of port scans your network receives. Variations in the number of scans or the sophistication of the scans used against your network can be an early indicator of a possible attack.

Given the frequency of port scans, you should closely monitor log files, either manually or through a log collection and correlation system. You can use a variety of tools to monitor event log files, including products such as Microsoft Operations Manager or tools that come at no cost, such as Event Comb and Dumpel.exe. (EventcombMT.exe is located in the Tools\EventComb folder on the CD that accompanies this book. Dumpel.exe is located in the Tools folder on the CD that accompanies this book.)

See Chapter 12, Auditing Microsoft Windows Security Events, in this book for detailed information on configuring auditing in Microsoft Windows 2000 and Microsoft Windows XP.

If an attacker succeeds in penetrating your defenses, one common approach she might take is to attempt to cover her tracks by erasing or modifying the event logs. Because of this, you must stay current with your logs either by exporting them to a well-secured network location (or to write-once media) or by analyzing them in real time.

The act of clearing the security event log creates an event 517. The presence of that event and the lack of events in a log that should be populated can indicate that a successful attack has occurred and evidence has been manipulated. Because attack tools that allow for the manipulation of the event log now exist, your optimal goal will be to remove logs from a given system in real time and store them in a protected data store. These principles also apply to logs other than the event logs.

You should also monitor the logs files listed in Table 27-1, as well as any other log files that seem applicable based on the details of the specific incident. Consider implementing a process to collect these log files on a daily basis and placing them in a secure, central location.

Table 27-1. Log Files of Interest to an Incident Response Team (continued)
Log File	Default Location	Description
URLScan log	%windir%\system32\ inetsrv\urlscan	The URLScan log file details why rejected requests were rejected (which specific rule in the URLScan.ini triggered the rejection) as well as the time and date, the URL in question, and the IP address of the requestor. The logging functionality for URLScan allows you to toggle logging on or off (the default is on) and allows for separate logs on a per-process or per-day basis.
Domain Name System (DNS) log	%windir%\system32\ DNS\Dns Event.Evt	The DNS event log file can be used to identify any inappropriate DNS activity, such as unauthorized zone transfers, which can be a precursor to an attack on the network.
Microsoft Internet Information Services (IIS) log	By default, when you install IIS 4.0, 5.0, or 5.1, the IIS logs are created in C:\%windir%\ system32\ LogFiles\W3SVC# (where # is the Web site number). To find the log file location, examine the properties of the Web site in the Internet Services Manager (ISM).	IIS extends beyond the scope of the event-logging or performance-monitoring features of Windows. The logs can include information such as who has visited your Web site, what the visitor viewed, and when the information was viewed last. You can monitor attempts, either successful or unsuccessful, to access your Web sites, virtual folders, or files. This includes events such as reading the file or writing to the file. You can choose which events you want to audit for any site, virtual folder, or file. By regularly reviewing these files, you can detect areas of your server or your sites that might be subject to attacks or other security problems. You can enable logging for individual Web sites and choose the log format. When logging is enabled, it is enabled for all the site s folders, but you can disable it for specific directories. Inspect the IIS logs for suspicious Web server activities, including (but not limited to) the following: Multiple unsuccessful commands trying to run executable files or scripts. (Closely monitor the Scripts folder.) Excessive unsuccessful attempts from a single IP address, with the possible intention of increasing network traffic and denying access to other users. Unsuccessful attempts to access and modify .bat or .cmd files. Unauthorized attempts to upload files and executable files to a folder that contains execute permissions by using HTTP PUT or POST methods.
Internet Authentication Service (IAS) log	%windir%\system32\LogFiles\Iaslog.log	The IAS log contains listings of both successful and rejected authentication requests. This can help you determine baseline patterns for Remote Access Service (RAS) users, as well as identify anomalous activity and rejected authentication attempts, which might indicate an attack in progress.
Internet Connection Firewall (ICF) log	Windows XP or later: %windir%\ pfirewall.log	On network connections protected by ICF, the ICF logs can be configured to show successful and unsuccessful connections to that network interface, including the date and time, IP address, and ports utilized.
Dr. Watson log	%AllUsersProfile%\ Documents\ DrWatson\ Drwtsn32.log	The Dr. Watson log records process information for the processes that are running when an application crashes. If an application crashes, it might be possible to see information about the processes running at the time of the crash to help determine whether the cause was related to an attack.
IDS log	Varies based on the IDS use	IDS systems create log files that can provide a great deal of information about what is happening at the network layer of the computer. Some IDS systems incorporate a GUI and search capability to correlate large volumes of detailed information quickly.

Inability to Access Network Resources

Another indication that an incident has occurred is the sudden inability to access a network resource or a degraded response from that resource under otherwise normal conditions. If a system suddenly reboots, an application hangs unexpectedly, a system undergoes a routing change, or a modification to DNS occurs, clients might not be able to access network resources. Some or all of these events might occur in the event of an intrusion, depending on the attacker s approach. Investigate such outages to determine whether they were caused by an intruder.

Excessive CPU Utilization

Similarly, higher than normal CPU or network utilization can indicate rogue processes that might be indicators of an attack. It is normal for a system s processor to jump to 100 percent utilization periodically, or for high network traffic to be seen during a large file transfer to or from a file server. However, when a system that normally averages 40 percent CPU utilization operates at an average of 70 percent CPU utilization, or when large quantities of data travel to or from a server that normally does not generate such traffic, some form of attack might be in progress.

Although most processes being executed on a computer running Windows 2000 or Windows XP will be displayed in the Task Manager, if an attacker has compromised the computer, it will be possible to execute processes that are hidden from the Task Manager. You should be careful about how you use computers that might have been compromised. For example, an attacker might have installed keystroke logging software that is responsible for the excess CPU utilization. Thus, when you log on to the computer to investigate this issue, the attacker could intercept your account logon name and password.

Irregular Service Operations

Other variances from baseline behavior that might require investigation relate to system services. Services that should be running but are paused or stopped, services that are new to the system, and services that should be running but are missing can all indicate that an attacker has made modifications to your system to suit his needs. Tools such as SvcMon.exe which first shipped with Microsoft Windows 2000 Server Resource Kit (Microsoft Press, 2000) can monitor local or remote systems to detect changes in state of the various services on a system that you select by using the SMConfig.exe tool. Should a service stop or start, the tool will notify the administrator by e-mail and log the event.

Irregular File System Activity

Indicators of an attack at the file system level can include missing files or folders or a noticeable decrease in the available space on a system. Missing files can result from the attacker modifying your system because she wants more space or the attacker covering her tracks. A decrease in disk space can occur because the attacker is using your system for Internet Relay Chat (IRC) or file storage, or because she has copied tools to that system to extend her attack to other systems in your environment. Other file system changes, such as changes to the datestamp on system files or to the MD5 hash of system files, can be an indicator of an intrusion. Attackers will often replace executables with Trojan horse versions of the same program that can either help hide their presence or provide them with additional levels of access.

You can use the file integrity verification tool Fciv.exe, which is located in the Tools\Fciv folder that accompanies this book, to create and verify hash signatures of files.

The presence of new drivers also can point to an attack. You can monitor the drivers on a system by using the Drivers.exe tool, which is included in the Tools folder on the CD that ships with this book. This tool displays all installed device drivers on the computer on which the tool is executed. The output of the tool includes the driver s file name, the size of the driver on disk, and the date that the driver was linked. The link date can be used to identify any newly installed drivers. If an updated driver was not recently installed, this can indicate a replaced driver on the part of an attacker.

Permissions Changes

Changes to user permissions, group membership, or other security policy are also common attack indicators. If a user is granted permissions outside your change control process or if an account is added to a more privileged group, an attacker might be trying to access resources he currently cannot access. An example of this is the Nimda worm, which adds the Guest account to the Administrators group. Other changes along this vein include changes to Group Policy objects (GPOs) and auditing changes. If any of these events occur outside planned operations, we recommend you conduct an investigation. Event IDs 608 612 and 624 643 can denote such improper changes.