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

• 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.

  • 10.0.0.0 to 10.255.255.255
  • 172.16.0.0 to 172.31.255.255
  • 192.168.0.0 to 192.168.255.255

  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

• 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

KF Sensor On-Line Manual Contents