NetFort Advertising

Server log files do not always have the answer

In today’s world, security information and event management (SIEM) systems are hot technology. Some people deploy them because of compliance needs, others because they need access to data to troubleshoot problems. SIEM systems themselves are useless without sources of data and most of them connect to server log files and other network devices. The problem is that there are limitations with server log files when it comes to usability analysis.


A good example of this is Ransomware. It is a big issue at the moment and most IT managers want to detect and get rid of it as soon as possible. This can be challenging when you have hundreds if not thousands of users on your network.

Once Ransomware gets into a network it starts to encrypt files and every time it moves from a directory to another, it leaves an instruction note within a text file that leads to a website or TOR network site. If an event can be triggered when these files are created then it would be an excellent start. However, as you can see in this sample event, no IP address is shown for the problematic device that is spreading the malware. This makes it difficult to block the device from accessing the network.

Event Type:         Success Audit
 Event Source:      Security
 Event Category:    Object Access
 Event ID:          560
 Date:              2/24/2015
 Time:              12:40:46 PM
 User:              WIN2003DATABASE\Administrator
 Computer:          WIN2003DATABASE
 Object Open:
 Object Server:     Security
 Object Type:       File
 Object Name:       C:\Downloads\test.txt
 Handle ID:         5128
 Operation ID:      {0,2612512}
 Process ID:        4
 Image File Name:
 Primary User Name: WIN2003DATABASE$
 Primary Domain:    WORKGROUP
 Primary Logon ID:  (0x0,0x3E7)
 Client User Name:  Administrator
 Client Domain:     WIN2003DATABASE
 Client Logon ID:   (0x0,0x2708B4)
 Accesses:          SYNCHRONIZE
 Privileges:            -
 Restricted Sid Count:       0
 Access Mask:       0x100080

Some people suggest setting up SPAN or mirror ports which are excellent data sources. The problem is that you may need to work through millions of packets to find useful information. Make no mistake about it, packet analysis can reveal crucial detail like IP addresses as you can see in the image below.

Server Log Files

You could now use log data and information from your Windows log to build a complete picture. While this might be an option for a small network with a few clients, it does not scale well. The next option to consider is a system like LANGuardian which does the packet analysis for you. It analyses the packets as they come in from a SPAN or mirror port and it extracts the important metadata. Metadata would include things like IP addresses, filenames and actions.

File Activity Monitoring
File Share Activity

Systems like the LANGuardian can then export this information via SYSLOG or other formats to other network management systems which can then take an action.

Server log files do not always have the answer but there are other sources of data on your network.

Alternatives for log file monitoring