Event Interpretation

Events indicate the presence of an attack; but determining who, how and why an attack is taking place can be difficult. Often, a single event is not enough to analyze an attack, but several simple events taken together can elicit more detailed information.

Certain types of well known attacks can be identified by signatures. The signature feature is described later in this manual.

This section provides advice on what to look for and how to interpret specific indications, when a signature has not detected the nature of an attack.
New attack patterns are constantly evolving and a hacker may do their best to hide the purpose of the attacks.

Event properties

  • Type

    The event type is the first thing to check. These are the three main types Connection Most events are connections and are caused by a client connecting to an open port on the sensor machine. These types of events provide the most information. Closed Port If a client tries to connect to a port with no service running on it then the host machine will immediately reject the connection attempt immediately. If there are a number of events on the same closed port number then it is worth defining a Listen definition on that port to gather more information on the purpose of that attack. Scan

    Stealth scans cover a range of techniques used by hackers and pen testers to identify hosts, fingerprint OS versions and to determine which ports are open on a host. These techniques involve sending non-standard network packets or non-standard packet sequencing gain a response from a host without establishing a full connection. These are rarely recorded in system log files and can evade detection by certain security products such as firewalls.

    nmap is the most popular stealth scanning tool.
    When a network event can be positively identified as a scan then the event is assigned the event type "Scan". Previously these would have been recorded as type "Connection". An event with the type Scan is a much clearer indicator of malicious activity than a connection.

    nmap Options decoded

    Where possible a scan is decoded to show the nmap option that matches the scan technique. The event's Description field contains the matching nmap command line option.

    The following options are individually identified:

    • nmap -sS
    • nmap -sN
    • nmap -sF
    • nmap -sX, Xmas scan
    • nmap -sM
    • nmap -sA
    n.b. Other security tools and malware may implement the same techniques. The events from these will still be identified using the nmap option as that is the standard scanning tool.
  • Port

    Different services are expected to run on certain ports. For example, if an event occurs on port 80 then it is most likely an attack directed against a web server. Use the port number and Listen name to give you an indication of what the attack is likely to be directed at.

  • Received

    The event's Received data field contains the data sent to KFSensor by the visitor. Interpreting this data is the most important way of identifying the nature of the attack. This will not be available if the listen definition is set to 'Close'.

    If the received data field is empty then this could indicate a system scan. A scanner may simply close the connection immediately after it has been opened as it may only be looking for the presence of open ports. If this is the case the Closed By field will indicate that the connection was closed by the visitor.

    The received data is likely to be either a simple and legitimate request designed to get a server to display its version information, or may be a direct attempt to exploit a vulnerability.

    The following data is an example from a Nimba attack attempting to exploit a trojan left by Code Red on port 80 of an infected IIS web server.

    GET /scripts/root.exe?/c+dir HTTP/1.0
    Host: www
    Connection: close

    Although this example is a well formed HTTP request it is very different in format to an HTTP request from a browser.

  • Visitor IP and domain

    The Visitor's IP address field gives you the IP address of the machine that generated the event.

    If the IP address is within the following range it indicates a private IP address that must be on your local area network and not from the public Internet.

    • to
    • to
    • to

    The domain name field of the visitor that generated the event. This is obtained by a reverse DNS lookup on the visitor's IP address. It may not be possible to perform a reverse look up or the DNS server may have been compromised, so if in doubt rely on the IP address and not the domain name.

    In the case of a UDP connection it is possible for a hacker to spoof the IP address, but this is not possible for a TCP connection.

    Although the IP address shows where the connection was made from the attack may not have originated from that machine. Proxy servers, firewalls and trojans can be used to relay a request, so the hacker's machine may be hidden. This is a favorite trick of experienced hackers to cover their tracks. To find the hacker's machine it is necessary to consult the logs of the machine that made the request. This can be difficult or impossible, particularly if it is coming from a trojan installed on a home user's machine.

  • Start Time and End Time
    The Start Time and End Time fields give you the duration a connection was held open for. If the duration is extremely short and the connection was closed by the visitor, then this indicates the visitor did not wait around for a response and this is likely to indicate scanning activity.

Event patterns

These are things to look for when looking at a cluster of events:
  • Speed

    If a number of events occur on the same port in quick succession, (often several a second) then it is likely that an automated vulnerability scan is being run against a particular service. For example Whisker is a web server vulnerability scanner that runs numerous HTTP requests looking for different vulnerabilities.

    A more slower and erratic request may indicate a human presence.

    A large interval between events may indicate a slow scan. Some automated scanners are deliberately run slowly to try and avoid a network based IDS.

  • Multiple Ports

    If connections are made to more than one port then this indicates a system scan. Such a scan is designed to fingerprint a server by examining all the services that are running on a particular machine.

Next: Visitor Rules

KFSensor On-Line Manual Contents