Nessus plugin 29871 has been updated to look for the presence of malicious JavaScript on a remote web site.

(See Attack on ASP site that uses a SQL server database)

Below is an example of the plugin report:

Click for larger image

Successful Attacks from Automated Malware

Recently, malware dubbed "LizaMoon" (named after the first web site found distributing it) has been popping up in the news:

Dubbed LizaMoon, unidentified perpetrators of the scareware campaign inject script into legitimate URLs, so when people try to access the website, they get redirected to a page warning them that their PCs are infected with malware that can be removed by downloading a free AV application called Windows Stability Center.

From LizaMoon SQL Injection Attack Hits Websites

LizaMoon scans web sites for easily exploitable SQL injection vulnerabilities, then uses that to put redirects on the web site that take users to a site which installs malware. This is not a new form of attack, however the "Lizamoon" malware has been surprisingly successful. Google searches for infected sites report that over 1.5 million pages have been infected. The important thing to not about the numbers of infection is "pages" does not refer to sites, as a site can have multiple infected pages. This type of attack typically works as follows:

It's 4:55 PM on a Friday and you are looking forward to an enjoyable dinner with your family. Your Blackberry starts buzzing from across your desk while your inbox starts filling up with alerts from your SecurityCenter along with frantic emails from Human Resources. It seems a disgruntled employee named Jack Black quit today and nobody remembered to tell the IT group to disable his accounts until after important files started disappearing. Suddenly, you are stuck in Incident Response mode, gathering data on the user's activities. Do you cancel your reservations?

Fortunately, you have deployed Tenable Network Security's Unified Security Monitoring products, and have a wide array of resources[1] at hand to streamline the response process. These resources include SecurityCenter, the Passive Vulnerability Scanner (PVS) and Log Correlation Engine (LCE). At a high level, what can these resources do for you?

SecurityCenter

SecurityCenter provides a unified view of both vulnerability and event data along with the alerting, ticketing and reporting required for thorough user forensics.

Passive Vulnerability Scanner

PVS not only tracks vulnerabilities, but logs user and network activities detected in real-time on the wire. These activities include:

I appeared on Risky Business episode 181 for the "sponsor interview" segment of the show. I really enjoy talking to Patrick Gray - he asks great questions and we always have a great chat. This time around I discussed some topics regarding defensive measures that actually work, including:

• Creating listening services that "trap" web spiders
• Putting intelligence inside your documents to detect attackers
• Monitoring various services and including the results in your SEIM

These topics, and more, will be the topic of my upcoming talk debuting at SOURCE Boston titled "Bringing Sexy Back: Defensive Measures That Actually Work".

When a virus infected one of my Nessus scan targets, I did what any sensible CEO of a SIEM company would do - let it run and see what types of logs and alerts it generated!

Over the 30 days that I let it run, I was able to collect a wide variety of interesting data. This included suspicious Windows application logs, internal network scans, communication anomalies, attempts to break into other lab computers and "classic" outbound connections  to various IRC channels. It even modified how logins worked, breaking my Nessus patch audits. 

Attendees of this webinar will learn about various detection methods that can be used with SIEMs to look for malicious software and computers infected with hostile code. 

Putting a Virus under the SIEM Microscope
Wednesday, January 26 2:00 PM EST
https://www1.gotomeeting.com/register/178513273

Tenable Network Security has released version 3.6 of the Log Correlation Engine. This new version includes many performance enhancements as well as its own web-based user interface. This blog entry describes the new user interface, the increased performance and the new features of LCE 3.6.

I was interviewed for episode #173 of the Risky Business information security podcast.

The previous Risky Business episode that discussed the recent release of the open source El Jefe project by Immunity Inc, focused on how process execution tracking for Windows can be a great source of security data - especially compared to raw network traces.  

During my interview with Patrick Gray, we covered how many SIEMs already have this sort of capability, but most SIEM users don't enable these features because they are complex. I also covered how Tenable's Log Correlation Engine can collect logs from both Unix and Windows computers that reflect process execution traces and how they can organized for attack detection, change detection, forensics, alerting, reporting and anomaly detection.  

Airport "Security"

Those of us who travel through any U.S. airport are used to the inconvenience of airport security - the long lines, metal detectors, having to take off your shoes, belts, earrings, and of course the ominous "liquids and gels" inspection. While most people accept these inconveniences as an unfortunate necessity, much of what has been implemented shares some of the common pitfalls found in many computer and network security programs. Using the U.S. airport security model as an example, let’s take a look at some of the security being implemented and relate it to security gone wrong in the enterprise:

The dreaded long lines at airport security are a by-product of the current security model at U.S. airports.

Passwords are just so easy to abuse...

It was interesting to see that the top scorer in the game (who went by the handle of "ftp", and coincidentally had 21 scores in the first day of game play!) did not use fancy new exploits, 0day attacks or a wide range of open-source or even commercial tools. He was able to gain access to systems because the teams left default or easily guessable passwords set on some of the Linux servers. He used SSH to login to the systems, then SCP to upload some Python code, that was used to update the scoring engine. From there he was able to maintain access, not by rootkit technology or anything sophisticated, but just hiding in plain sight. The Python script makes a TCP connection to the scoring server and sends a message. It was moved into a file called "/dev/vfat", to make it look like a system file. Next, a shell script was written to call the python script every ten minutes. This file was called "getty" and ran in the background, and was also inserted into the startup scripts to ensure it kept running. The teams never found these processes running and "ftp" won the game, no exploits required.

Hacker "ftp" at work, winning the game using built-in tools such as bash, python and SSH.

When analyzing network traffic it’s typically not as important to look at the contents of the packets; rather the information about them, where they are going and how they got there. This “network metadata” (often referred to as NetFlow data) can reveal interesting information about your network and often uncover misconfigurations, policy abuses and security incidents. I relate it to the movie "The Matrix". In the movie there is a scene where the characters are looking at computer screens displaying “the matrix”. Those who are not accustomed to looking at the matrix will not see "The Blonde" or the "Brunette", but will just see a bunch of green characters.

Setting up the Log Correlation Engine & Splunk

Tenable has recently released a new Log Correlation Engine (LCE) client that allows you to collect log data from Splunk installations to send to LCE, Tenable’s solution for log storage, normalization and correlation. If you have instances of Splunk in your environment, it’s a simple process to configure the integration. Below is an overview of the traffic flow:

Tenable has released version 3.2 of the Log Correlation Engine (LCE) which includes the ability to store, compress and search any log that is sent to it. This functionality is available to all current LCE customers as a point release upgrade. It also builds upon the existing log normalization, correlation, user tracking and anomaly detection that were already available in prior versions.

Click on the below image for a demonstration of the LCE performing full log searches from within the Security Center:

Tenable's Research group has released a new Log Correlation Engine TASL script which processes web proxy logs and alerts when specific domains are visited. The script is named blacklist_domain.tasl and can be downloaded from here. Tenable has also added several new PRM libraries to support processing logs from web proxies such as Cisco ASA, Blue Coat and Squid. This blog entry discusses how to obtain these PRM files, install the new TASL script and configure it for real time updates.

Security Monitoring with Web Proxies

Looking for internal traffic to suspicious domains can identify a wide variety of potential network abuses including:

• compromised host detection
• visiting known phishing sites
• visiting sites with adult content

An example list of suspicious domains can be obtained from the Bleeding Threat project here. The correlation used in the TASL script makes use of the list of domains tracked by the Bleeding Threats  project and can also be easily extended to include other sources.

When viewing these logs alongside data collected by netflow, sniffed sessions, IDS events, firewall logs and so on, a complete picture of what a host is doing and what sort of activity it is engaged in can be accomplished. Also, organizations that monitor employee activity closely can also attempt to discover when competitor's sites are visited and non-work activity is engaged in.

Installation

To configure this sort of monitoring with the LCE, we need to install the new PRM files, install the TASL script and also install or update the "blacklist" PERL utility which obtains updated lists of threats from SANS, Bleeding Threat and other sites.

Links to the new PRM files and TASL script is available below, and a list of shell commands to install and configure these utilities is included in the next section.

• web_squid.prm
  PRM to process logs from Squid web proxies.
• web_ncsa_common_access_log_format.prm
  PRM to process web proxy logs in the NCSA format
• web_w3c_extended_log_format.prm
  PRM to process web proxy logs saved in the W3C extended format
• prm_map.prm
  Updated list of PRM IDs
• PRM_Mappings.prm
  Updated list of PRM groupings
• lce_tasl.prm
  Updated PRM to process events from the blacklist_domain.tasl script
• blacklist_domain.tasl
  The TASL script which subscribes to web proxy events and performs lookups of suspicious domains.
• blacklist-2.4.1.pl
  PERL script which updates both a list of suspicious DNS domains as well as lists of suspicious IP addresses.

The following list of UNIX commands will allow you to update your LCE to process these new log events as well as install the blacklist_domain.tasl script. The PERL utility blacklist.pl requires a click-through license agreement to be downloaded. This should be placed on your LCE in a directory such as /usr/thunder/daemons.These shell commands below assume that the blacklist-2.4.1.tar.gz file is installed there.

su thunder
cd /usr/thunder/daemons/plugins
rm -f web_squid.prm
wget http://cgi.tenablesecurity.com/tasl/blacklist_domain.tasl
rm -f lce_tasl.prm
wget http://www.tenablesecurity.com/lce_tasl.prm
wget http://www.tenablesecurity.com/web_squid.prm
wget http://www.tenablesecurity.com/web_ncsa_common_access_log_format.prm
wget http://www.tenablesecurity.com/web_w3c_extended_log_format.prm
rm -f prm_map.prm
wget http://www.tenablesecurity.com/prm_map.prm
rm -f PRM_mapping.prm
wget http://www.tenablesecurity.com/PRM_Mappings.prm
exit                                        <-- we need to run this script as root
cd /usr/thunder/daemons
gunzip blacklist-2.4.1.tar.gz
tar xvf blacklist-2.4.1.tar
cd blacklist
./blacklist-2.4.1.pl                  <-- the tool will automatically run in the background

Before restarting the thunder daemon, give the script a chance to reach out and obtain new data. Inside the /usr/thunder/daemons/blacklist directory, the script will update the blacklist.domain file. Once these files have been populated, the thunderd service can be restarted with the following command:

/etc/rc.d/init.d/thunder restart

Managing Static Lists of "Bad" Domains

If you do not want to synchronize your list of potential blacklisted domains automatically, you can also manually edit the file /usr/thunder/daemons/blacklist/blacklist-custom.domain. This file won't exist unless you create it. The format of the contents are the same as those for the blacklist.domain file in that it is a domain suffix, a corresponding web site and a description about the item. For example, if you wanted to alert when web users attempted to receive new information from CNN or FOX, an entry could look like this:

cnn.com,www.cnn.com,CNN
foxnews.com,www.foxnews.com,FOX

If changes to the blacklist-custom.domain file occur, either the thunderd process must be restarted or a SYSLOG message containing the word "Blacklist_File_Update" be received. If the blacklist.pl script is running, it will send such a SYSLOG message to the thunderd process periodically.

For More Information

If this sort of alerting is interesting to your organization, you should also consider running the BlackList IP TASL script. This script uses multiple lists of "bad guy" IP address such as SANS and the Bleeding Threats project to alert when you have network activity to or from these sites. A blog entry detailing how it can be set up and configured is located here.

Tenable's research group has released a TASL correlation script for the Log Correlation Engine (LCE) that automatically associates learned user accounts with IP addresses. This enables historical tracking of users in organizations that do not have centralized authentication and access control such as university environments or campus-wide networks.

The script is named "New Network User" (new_nw_usr.tasl). It accepts normalized logs from several dozen different authentication log sources, extracts the user name and originating IP address and then creates a log if the user identity is new, or if an existing "user to IP address" relationship has changed.

Current supported log sources include:

• Windows system and active directory logins
• UNIX SSH logins
• RADIUS Authentications
• Application logs for authenticated email (POP, IMAP, .etc)
• Application logs for a variety of FTP servers
• Passively sniffed gmail, MySpace and other web applications
• Passively sniffed chat and IM login processes

Logs from the Passive Vulnerability Scanner (PVS) which generate user name or identity information are unique in that this information is passively determined. Unlike the other applications supported by this script which send logs of authentication users accessing a domain or checking email, the PVS obtains this information through protocol analysis. We've  previously blogged about this capability in the PVS.

Tracking "New User" Identities

From this TASL script's point of view, a new user is any recognized account that hasn't been previously tracked. For example, the first time a network user connects to their Gmail account, the PVS will recognize this and send a syslog message to the LCE. This TASL scipt will extract the user name from the PVS syslog message and then will generate a new log such as this one shown below:

New Network User - user mrrongula957@gmail.com has logged on from IP address 192.168.56.254

The script looks at many different types of "identities" that can be passively obtained or extracted from log files. A given user might likely have different names and identities for their public email, domain and chat accounts. An identity might be a full email address (such as mrrongula957@gmail.com) or if the log or traffic came from an authenticated email it might be just an account name like 'bsmith'.

Tracking When Users Move Around

As these logs occur, the script builds a table of user accounts and the IP address they have originated from. If this pairing ever changes, a new log is generated which looks like this:

Network user IP address change, user mrrongula957@gmail.com IP address has changed from 192.168.56.254 to 192.168.159.71

Users can get new IP addresses for many different reasons including DHCP lease expirations, moving around a campus network or even obtaining a new computer.

In environments where centralized authentication (like RADIUS or LDAP) or network access control (NAC) isn't implemented, the ability to passively associate user names with the PVS to an IP address can be very useful for incident response and compliance monitoring.

Once these logs are stored in the LCE, trying to find out which users had access to certain IP addresses or networks at any given time is something that can be queried for.

If one wanted to find out which network users originated from IP address 192.168.20.67 on April 10, 2007, they would perform a query for the "New_Network_User" and "Network_User_IP_change" events on such a day.

Below is an obscured screen shot of these logs from a university environment. The main source of the user identities has come from the PVS's ability to track unique Gmail accounts.

This information can also be saved as a spread sheet.

Installing the new Script

Log Correlation Engine customers should download the new_nw_usr.tasl script from the TASL homepage to their /usr/thunder/daemons/plugins directory. They should also download an updated lce_tasl.prm and tenable_pvs.prm libraries to the same directory and then restart the thunderd process.

These following UNIX command lines can be used to obtain and restart the LCE and should be run as user 'thunder'.

cd /usr/thunder/daemons/plugins
rm ./lce_tasl.prm
wget http://www.tenablesecurity.com/lce_tasl.prm
rm ./tenable_pvs.prm
wget http://www.tenablesecurity.com/tenable_pvs.prm
wget http://cgi.tenablesecurity.com/tasl/new_nw_usr.tasl
/etc/rc.d/init.d/thunder restart

Other Types of User Tracking with the LCE

If this sort of user tracking is of interest to you, several other LCE TASL scripts should be considered:

• invalid_user_logon.tasl -- Automatically learns a list of invalid or deleted logins and then alerts if those accounts are used again in the future.
• new_user.tasl -- Automatically tracks all SSH, Windows and other application logins to build up a list of unique valid user accounts for each logged server and alerts when a new user account is used.
• user_to_mac.tasl -- Tracks authentication logs along with DHCP logs to build automatic match es between user names to Ethernet addresses. Generates an alert when a user has a new Ethernet address. Previously blogged about here.

For More Information

To learn more about TASL scripting, please consider the TASL documentation as well as the example TASL scripts. Tenable also offers a free webinar about Network Based Anomaly Detection which uses TASL scripting to process netflow and sniffed network sessions to look for leapfrog attacks, network backdoors and other types of host and crowd behaviors.

Tenable Log Correlation Engine customers who have Stonegate firewalls within their environment can now make use of a new normalization library. The new PRM parses logs obtained from the Stonesoft product. The new PRM is available here.

If you have Stonegate firewalls within your network, download this new library and place it in the /usr/thunder/daemons/plugins directory and then restart the thunderd process. Also, if you are using the Never Before Seen TASL script, you should also update your PRM_mappings.prm file, which contains the event IDs for the new Stonegate logs. 

The current list of supported network and host based firewall logs includes:

• Checkpoint
• Cisco ASA
• Cisco PIX
• CyberGuard (Secure Computing)
• Gauntlet
• Juniper
• Astaro
• Arkoon
• Fortinet
• ipchains
• Iptables
• Ipfilter
• Kerio
• NetGear
• OpenBSD's pf
• SideWinder (Secure Computing)
• SonicWall
• Stonegate
• PortSentry
• Sygate
• Symantec
• Windows XP
• ZoneAlarm

This entry concerns more information and analysis of output from the "Never Before Seen" TASL script for the Log Correlation Engine (LCE). We've had the script running at several customer locations and have had interesting data to discuss which helps show the script's usefulness. This blog entry discusses analyzing the results from IntruShield IPS events as well as overall "never before seen" event trending.

Reviewof the "Never Before Seen" Concept

As we've previously blogged, the nbs.tasl script alerts when any event type from any source occurs for the first time towards or away from a given "local" IP address. This can be a IDS event, firewall deny log, Active Directory login failure -- it doesn't matter. The basic principal is that stuff that happens all the time doesn't get alerted on and only new stuff does.

Event with this sort of filtering, on real "large" or "busy" enterprise networks, there can still be a large number of "never before seen" events. Analyzing them can lead you to a rich set of unique event data that may normally get overlooked.

IntruShield IPS Event Analysis

In the screen shot below, a large network being monitored by the IntruShield IPS, a PVS and the Log Correlation Enginer's Network Monitor has all of their events normalized:

There were 2062 unique events we've not seen before. Conducting a sort for top IP addresses yields this view (with our IP addresses concealed):

The IP at 204.16.209.59 was out top source of "new events" that haven't been seen before. Keep in mind, the same IP could have also been doing many evil things that have been seen before, but those events would have been buried in all of the other normalized events.

Looking at the actual SYSLOG messages for this these events reveals that the source IP has been detected by the IntruShield IPS for violating some sort of protocol:

Looking at the logs, it can be seen that the remote IP address is trying several IP addresses in a row in the same local subnets.

Knowing that we might have a "bad guy" IP address on our hands, doing a quick summary of all events for 204.16.209.59 yields the following results:

So not only have there been a good deal of protocol violation events logged by the IntruShield IPS, this IP address was tagged by the SANS Internet Storm Center and matched with the blacklist.tasl script. The algorithm of highlighting "never before seen" events helped point us in the right direction for an attacker scanning our network.

Large Scale Trending

Here is a graph of "never before seen" events occurring at a large network:

The amount of "never before seen" events may appear random, but (from left to right) it is steadily decreasing over time. As the nbs.tasl script learns more and more about what happens on which hosts, as new events occur, they can be easily highlighted. These new event types might identify compromised systems, new types of scans, configuration changes and so on.

Tenable has seen similar patterns of decay for the nbs.tasl script alerts on lab networks, home networks and multiple large networks. As time goes on, the alerts become more and more unique and this becomes very valuable to understand what has changed on a given network.

For More Information

The previous blog entry on "never before seen" events is located here. Tenable also has a webinar on network based anomaly detection located here.

Tenable's research group has recently expanded support for "Black Lists" within the Log Correlation Engine. These new features include enhanced log parsing to identify specific black-list sources as well as leveraging these lists into the "Crowd Surge" detection TASL script.

Why Correlate With Black Lists?

There are many free sources of lists of "bad guys" available.Tenable currently supports the following sources:

• D-Shield's ISC Block list and Top 10 scanning IPs
• Bleedingthreat Botnet, Bot-Block and Spyware (through Blackhole DNS)
• Spamhaus public list of well known spammers

Each of these groups keeps track of abusive activity and publishes lists of IP addresses and networks performing "bad" things. Tenable has written a utility to monitor these lists and feed updated information to the Log Correlation Engine.

The blacklist.tasl script reads in a normalized list of IP addresses and then uses logs from the
Tenable Network Monitor or Tenable Netflow Monitor to look for connections from these sources.

The new lce_tasl.prm library generates unique black-list event names based on the source. Previously, black-list connections were just recorded with the name "Blacklist-Connection". Now, event names are broken apart based on the source list. For example, consider the screen shot below:

In the above image, separate connections were detected from almost all monitored black-list sources. The image was the result of a query to list all black-list connections in the past two hours. There were several thousand connections from IP addresses tracked by the Internet Storm Center (D-Shield), almost 1000 connections from known SPAM sources, a variety of bot net connections and at least 25 attempts by internal systems to reach out to known spyware destinations.

Analyzing Black List Scanning Events

In the above image, several Internet Storm Center "Top 10" connection events are occurring. This means that other organizations have reported being scanned by these sources and now these same sources are scanning your network.

If you monitor security for a network that is "addressable" on the Internet, you will likely get scanned continuously. Knowing how often you are scanned for "popular" exploits or from specific sources could give you an edge on what sort of security issues you need to worry about. For example, if you knew you were being targeted for worms that exploited VNC, specific Windows vulnerabilities or so on, you might be in a better position to recommend priorities for making firewall rule changes or recommending application and OS patches.

When analyzing broad scans, consider the following courses of action:

• Choose the most popular remote scanning IP addresses and then filter the logs at the Log Correlation Engine to see which IDS events or system logs they might be attempting. For example, worms that attempt to brute force SSH accounts or Windows logins aren't normally detected by NIDS.
• Conduct a port summary of connection attempts and then consider information available from the Internet Storm Center (ISC) about the scanned port(s). When listing ports for IDS event and log summaries, the Security Center has an automatic link to the ISC so that port activity can be tracked.
• Also for the targeted ports, use the Security Center to see which vulnerabilities your organization might have open on those ports. If you have a Passive Vulnerability Scanner deployed, it will have already likely picked up on which vulnerabilities or applications the remote scanners have targeted.   

Analyzing Black-list Botnet Events

Black-list connections from known botnets are more serious than a simple scan because they may indicate that you have one or more systems under active control by someone else. If one or more of your systems is connecting to a known botnet network or host, this may indicate that the server or servers have been compromised.

For a potential infected IP address or network, it is very good idea to look at last few days of logs collected. There may have been logs, IDS events and anomalies which could present a clearer picture of how the device got compromised. It may also show changes in behavior or when connections to the botnet started. For example, the image below clearly shows an increase in events during the last few days of a 25 day query.

This doesn't necessarily mean an infection has occurred, but if multiple systems are connecting to the same destination this may indicate a broader infection.

When analyzing these alerts keep in mind that some mediums, such as IRC, can be shared. A botnet may make use of a very popular IRC server, but this does not mean that everyone else that connects to the same IRC server is also part of the same botnet.

As with other types of analysis, consider the target ports, the frequency of connections, the time of day, .etc If the behavior seems out of sorts, it could be something looking into further.

Analyzing Black List Spam Events

Since there is so much SPAM, you might be asking why to even bother tracking these IP addresses. The short answer is to make sure that the systems the SPAM folks are sending mail to are indeed your mail servers. If they are unauthorized mail servers, mis-configured mail servers (such as those allowing relaying from the Internet) or mail servers from a different organization, matching their traffic against known SPAM lists can give some indication of abuse or potential risk. This technique might also identify your own email servers that are indeed receiving SPAM but do not have their anti-SPAM technology enabled.

Adding this to Crowd Surge detection

The crowd_surge.tasl script was also recently modified to correlate "crowd surge" destinations with the black-list.

For those not familiar with crowd surges, this event occurs when a certain percentage of a given population all visit obscure places at the same time. An example scenario could be when all of your infected Windows systems reach out to an IRC channel at 2:00 AM. The idea is to not alert on the places we all go to (Google, MySpace, CNN, .etc) and to alert when enough of the population starts to go to places such as ddoskiddies.com.

The algorithm in the crowd_surge.tasl script is effective at finding botnets and spyware that use IRC, tor, the web, SSH and proprietary protocols for command and control. More detailed information about "crowd surge" detection can be found in a previous BLOG entry.

By adding the black-list lookup to the crowd_surge.tasl script, more detailed alerts can be generated. If a certain percentage of a given network is reaching out to a known "bad guy", those events will show themselves with a typical "Blacklist" event as we've discussed already. However, if enough hosts visit a known black-list site in a short amount of time, you might be dealing with a real botnet. The crowd_surge.tasl script can alert you to this fact and save you from needing to discover this sort of behavior with manual analysis.

Below is a screen shot of what the events look like for a correlation between a known black-list and a crowd surge:

Installing

Obtaining these files and installing them is very simple:

The blacklist-2.2.tar.gz file can be downloaded from here. It should be installed into the /usr/thunder/daemons/blacklist directory. The file blacklist.cfg should be edited with the IP address of your thunder server (a.k.a. the Log Correlation Engine) as well as how often the web sites with various public black-lists should be polled. If a previous version of this script is running (such as version 2.1), the running program should be killed and the installed directory be completely removed.

The files blacklist.tasl, crowd_surge.tasl and lce_tasl.prm should all be downloaded with the wget tool into the /usr/thunder/daemons/plugins directory. Keep in mind that when wget downloads a file, by default, if a file with the same name exists, it won't be overwritten. Once these files are in place, restart the thunderd process.

A useful event to know about on any network is when something new happens on a given server for the first time. This is a very simple concept and extremely useful.

Regardless if your event logs are from UNIX systems, router access control violations, wireless access DHCP logs, intrusion detection systems or so on, after a certain period of time, the same events tend to repeat themselves. This is because most of our networks run controlled and automated processes.

With this in mind, finding out when something "new" occurs could indicate a security or administration problem.

The nbs.tasl Script

Tenable's research team has written a TASL script which implements this concept for the Log Correlation Engine. The script, nbs.tasl, stands for "never before seen". By default, the script subscribes to all possible event IDs except for network connection events from the Tenable Network Monitor (TNM) and the Tenable Netflow Monitor (TFM).

The script checks to make sure each event has either a source IP or destination IP in the "Customer Ranges.asset" file which the LCE obtains automatically from the Security Center. If an organization had a different asset list they would like watched, one could be substituted easily by modifying the script.

Detecting Intrusions

Tagging "new" events originating on, from or too a specific IP is very useful, especially for intrusion detection events.

For example, the nbs.tasl can differentiate between when a Snort event is generated for the first time from a server as compared to just alert when a system is attacked for the first time.

Consider a network that is being attacked very often. The Log Correlation Engine will likely record normalized IDS events inbound to monitored hosts. Very seldom (if at all) will an IDS event be sent from a target because we hope that our systems aren't attacking anyone. The first time these events occur though, the nbs.tasl script will alert on this "new" type of event.

Example Logs

Below is a screen shot of a set of logs generated by the nbs.tasl script:

Issues and Complimentary Technology

The first time you run the nbs.tasl script, all events will be new. By default, it will wait one day to learn which events are "normal". After that, any event that hasn't  occurred in the past day will be recognized as something "new" for the first time. This will create a spike of events that get generated.

Tenable considered placing a longer "learning mode" into the script, but being able to graph how often a "new" event occurs initially, where they come from and how long it takes for these events to "quiet down", can actually generate useful information.

For dealing with intrusions, keep in mind that the nbs.tasl also won't alert on the same event twice, even if it is a very critical alert. This is on purpose. If a server is compromised one day for the first time, and then compromised the second day with the same exact technique, the nbs.tasl will stay silent.

We've also designed the nbs.tasl script to not consider network events from the TNM and TFM. Those logs are verbose and copious and don't add a lot of value. Similar logs for monitoring and detecting network change (as in detecting new hosts, new ports, .etc) are already generated by the Passive Vulnerability Scanner.

And lastly, the LCE's stats daemon is designed to look for changes in the frequency of events and connections. If the data from the nbs.tasl script seems interesting to detect events that have not occurred before, then alerts from the statistics daemon identify changes that also have not occurred in the past.

Setting it UP

Please download all of these files to your /usr/thunder/daemons/plugins directory using wget or some other web client:

• http://cgi.tenablesecurity.com/tasl/nbs.tasl
• http://www.tenablesecurity.com/PRM_Mappings.prm
• http://www.tenablesecurity.com/prm_map.prm
• http://www.tenablesecurity.com/lce_tasl.prm

Keep in ming that if you have an existing file (such as the PRM_Mappings.prm library) wget by default won't overwrite the existing file but will save it with a numerical extension such as PRM_Mappings.prm.1.

By default, the nbs.tasl considers events to or from the Security Center "Customer Ranges" asset group. If a different asset group is available or desirable, it should be entered into the script.

By default, the script also has a variable named LEARNING_PERIOD. This variable is set to the number of seconds in one day. When the script first runs, it will consider all events "new" but won't alert on them until the period of time specified in LEARNING_PERIOD has occurred. If you want to start alerting right away, set this variable to zero.

Once these files are installed, restart your thunderd daemon.

For More Information

If event analysis seems interesting to you, all Tenable TASL scripts are available online. They are easily extended and work with the Log Correlation Engine. Tenable also has two free webinars available and several white papers which consider log analysis and event correlation located here:

• (webinar) Network Based Anomaly Detection
• (webinar) Vulnerability and IDS Event Correlation
• (white papers) Security Event Management

Please contact Tenable's sales or support groups for more information on these scripts.

I recently encountered logs from a Buffalo Wireless Access Point. DHCP leases and MAC address associations generate logs like this:

AP00160114430C : WIRELESS: wl0: 11g : Associated User - 00:04:23:76:34:20
AP00160114430C udhcpd: sending ACK to 192.168.11.2

The log identifying the remote MAC address is in one line and the log identifying the remote IP address is in a second line. Most of the TASL correlation scripts for the Log Correlation Engine expect to derive MAC/IP pairs from single logs lines like those of the DHCP daemon shown below:

Mar 24 11:07:46 util04 dhcpd: DHCPREQUEST for 10.9.102.183 from 00:c0:4f:0c:27:14 via eth0

Scripts like the user_to_mac.tasl expect to parse DHCP logs that contain both the MAC address and the IP address on the same line. So how can we take the logs from the Buffalo WAP and generate something that looks like a log from a typical DHCP daemon?

The buffalo_dhcp_one_line.tasl script is a very simple TASL that subscribes to events from the accesspoint_buffalo.prm library. It "keeps state" on the last MAC address in the "Associated User" logs encountered. Those are normalized to event ID 400. When an ACK (event ID 402) or OFFER DHCP (event ID 403) log is encountered, a new log is generated that looks like this:

DHCPREQUEST for 192.168.11.2 from 00:04:23:76:34:20 via buffalo_one_line.tasl script

The MAC address is added from the MAC address seen in the last "Associated user" event. The format of this log is very similar to that of the logs generated by the regular DHCP daemon. This is readily processed by the dhcp.prm plugin library.

Below is a Security Center screen shot of the events from Buffalo WAP being processed by the accesspoint_buffalo.prm library and the buffalo_dhcp_one_line.tasl script.

The two DHCP-Request events were generated by the TASL script while processing the BuffaloWAP-Associated_MAC and BuffaloWAP-DHCP_Address_ACK events.

Tenable has released several new PRM libraries and TASL scripts. This blog entry details the changes and how Tenable customers can obtain them.

PRM Updates

dns_bind.prm

New rules to parse zone transfer updates.

Added rule for generic "IP deny" events.

firewall_cisco_pix.prm

Added rule for generic "IP deny" events.

firewall_netscreen.prm

Added rules to detect authorized SNMP polling and running policy configuration changes.

mail_postfix.prm

Added rule to process rejected logs due to Spamhaus filtering.

nbad_arbor.prm

This new library has rules to parse events from the Arbor network behavioral anomaly detection products. Incidentally, the nids_stealthwatch.prm was renamed to nbad_stealthwatch.prm.

os_win2k_sys.prm

New rules were added to identify unexpected Windows service crashes, as well as application faults due to failed memory write attempts. These may be generated by failed buffer overflow or worm attacks. These events are also consumed by the new windows_crashes_and_restarts.tasl script that looks for these events occurring across multiple hosts.

PRM_mappings.prm

This PRM library does not contain any rules, but does include a list of all PRM IDs used by all libraries. This is useful to have for TASL writers and for choosing new IDs for new PRM rules.

router_cisco.prm

New rules for "RSH" connection attempts as well as link "up" and "down" messages.

ssh_openssh.prm

New rule added for processing of user login attempts which don't have executable shells.

virus_clamav.prm

A new PRM library to analyze logs generated by the Clam Anti Virus application. Multiple PRM rules are used to normalize detected viruses as Trojans, Worms, Phishing attempts and so on.

vpn_cisco_concentrator.prm

The regular expressions were modified to handle logs from systems specified by an IP address or a DNS name. Also, administrator login success events and failures now generate specific events.

TASL Updates

detect_change.tasl

Now processes change detection events for NetScreen firewalls.

ids_event_followed_by_change.tasl

This TASL has been updated to include alerts from Arbor devices. In addition, it now also considers normalized Snort IDS events for detected executable code in motion.

standard_deviation_long_term.tasl

This TASL has also been updated to include alerts from Arbor devices.

windows_crashes_and_restarts.tasl

This TASL looks for many different types of Windows events, including new events added to the os_win2k_sys.prm library. These rules identify unexpected Windows service crashes, Windows restarts due to crashes as well as application faults due to failed memory write attempts. These may be generated by failed buffer overflow or worm attacks. The script looks for these events occurring across multiple hosts.

Obtaining These Rules

To obtain a particular PRM library, a user can use the UNIX wget program to load the file directly from the www.tenablesecurity.com web site. below is an example of a user obtaining the os_linux.prm file:

wget http://www.tenablesecurity.com/os_linux.prm .

The period is needed and means to place the file in the local directory. If this command were executed from the /usr/thunder/daemons/plugins directory, a user would just need to make sure the file is owned by user 'thunder' and then restart the thunderd service. To restart the Log Correlation Engine, please run:

/etc/rc.d/init.d/thunder restart

The TASL scripts are available for web download from:

http://cgi.tenablesecurity.com/tasl.html

Individual scripts can also be obtained with the wget tool in a similar manner. Here is an example download of the Windows Event Correlator script:

wget http://www.tenablesecurity.com/os_linux.prm . http://cgi.tenablesecurity.com/tasl/windows_event_correlator.tasl

As with PRM libraries, if this command were executed from the /usr/thunder/daemons/plugins directory, a user would just need to make sure the file is owned by user 'thunder' and then restart the thunderd service.

All Log Correlation Engine licenses include the stats daemon. This daemon reads any log source, including netflow or sniffed TCP sessions, builds a baseline of normal activity and then creates alerts when there is activity which is statistically significant. This blog entry will explain in greater detail how the stats daemon accomplishes this, and discusses several example "anomaly" detections.

Tenable's Correlation Model in General

The stats engine for log and event analysis is part of our overall strategy for detecting significant events on your network. The correlation technology includes:

• Real time vulnerability to intrusion events with most leading NIDS solutions
• More than 50 TASL scripts for sophisticated real time discovery of worms, specific types of anomalies, compliance issues and compromises
• The stats engine to find statistically significant events on your network

Each of these events is viewed under the Security Center. This means any event can be viewed for specific asset groups by asset owners as a means of filtering and reporting.

The Statistical Model

The stats daemon keeps track of the following statistics for each IP address on your network:

• number of client and server connections
• number of internal, external and inbound connections
• number of unique events or normalized logs which occur

These statistics are maintained for each hour of each day. The statistics consider both the rolling averages of any particular occurrence, as well as the grouping of the values which build the rolling averages. For more information on how the mathematics works, please read the "Statistics Daemon Guide".

Each of the items tracked by the stats daemon are not "critical" in nature. For example, a Windows IIS server may normally have "server" connections and not act like a client. It may do outbound connections for logging, to obtain patch updates and perhaps synchronize with other servers.

In the classic example of "NBAD", if the machine were compromised and used for a botnet it may begin to connect to IRC or some other form of proprietary command and control. It may even start to scan other devices. In those cases, perhaps the client/server statistics as well as the balance of internal/external and inbound connection rates would generate an alert.

We'll consider a few examples of statistical events with screen shots from live networks. These screen shots came from live systems, and have had their IP addresses obscured.

First Example Analysis - Spike of Web traffic on an email server

Below is a summary of all stats anomalies for the last 24 hours at a major university. There are a lot because the stats daemon is very sensitive to small types of change. These particular events have been selected for systems which accept SMTP traffic. There are a variety of events, including changes in connections and a single "Large_Anomaly" event. Since mail operates 24x7, detecting slight changes in the balance of email coming in from the outside world as compared to being delivered internally isn't that interesting. However, the Statistics-Large_Anomaly event is certainly worth investigating.

Below is the SYSLOG content for the Statistics-Large_Anomaly event. It tells us a few things. First it is a "network spike" event. The TNM-TCP_Session_Completed event is generated by the Tenable Network Monitor which creates logs for when specific TCP sessions start and stop. Normally for this IP address between 4:00 AM and 5:00 AM, we get 207 hits of this event with a standard deviation of 403 hits. However, today we got 45178 hits.

Investigating further, using the IP address in question, for the last 24 hours, we can look at a summary of all events as well as a time-based summary. Although interesting, the specific events (specifically the Snort events) are fairly normal for this host. If they weren't we'd get statistical events for the new events as well. The time based summary is more interesting. Clearly between 4:00 AM and 5:00 AM there was a spike.

Investigating even further, we consider two more queries involving both a port summary and a list of involved IP addresses. The conclusion is that a majority of the traffic occurred on port 80 and to a single IP address. The second IP address (the one ending with .129.242) carried the bulk of the events.

So what was this? This turned out to be a proxy device which incorrectly went out to the Internet to keep an updated cache of a certain web site. The proxy was accidently placed on the list of SMTP servers because it acted like an SMTP when being scanned. We've actually been able to detect these sorts of things with the Passive Vulnerability Scanner, but in this case, only active scanning was used to identity SMTP devices.

You may be reading this entry and ask yourself, why lead off with a "false positive" for an example? The reason is that Tenable feels that statistically profiling a network's behaviors is very enlightening, but when an anomaly occurs it is not necessarily an evil hacker. More likely it is a change in a server or an issue with assumptions made before monitoring started. Let's look at a second example.

Second Example Analysis - Firewall Traffic Spikes

Below is a screen shot of raw NetScreen firewall logs event spikes and TNM activity of UDP and ICMP traffic. They have all occurred between 11:00 PM and midnight (23:00 for us ex-military types). These particular firewall events are all "accept" events, which means the firewall has passed this traffic.

In the case of the network which was being monitored here, the TNM agent was sniffing "inside" the firewall, so we were getting "double" hits. The purpose of this example is to show that NBAD shouldn't necessarily apply to netflow or direct network monitoring. Many types of anomalies can be discovered with logs from firewalls, proxies and even applications.

In the particular example shown, during the time period, event rates of around 10 were the norm, but in some cases, more than 20,000 had occurred during that time period.

Third Example Analysis - Multiple Hours of Misbehaving and Follow-on Activity after IDS events

The last example combines the LCE's TASL time-based correlation with events from the stats daemon. The events generated by the stats daemon also follow a "bell curve" of results. If you refer to the very first image of this blog, you can see that besides the one Statistics-Large_Anomaly event, there were several dozen events of lesser statistical significance.

Given that the stats daemon keeps a separate "model' of normalcy for each host and for each hour of the day, the LCE's TASL scripting can be used to see if a host is behaving oddly for more than one hour at a time. The standard_deviation_long_term.tasl script looks for stats events occurring more than two hours in a row.

Similarly, the ids_event_followed_by_change.tasl script looks for critical IDS events inbound to your network followed by some sort of statistical activity. The idea is to correlate an attack detected by a NIDS with a "behavior" change.

For more information

Tenable has several white papers on correlation that are free for download in our Security Event Management section. These papers are:

• "Security Event Management" - summarizes Tenable correlation technology, as well as log storage and acting on the events.
• "Correlating IDS Alerts with Vulnerability Information" - shows how NIDS alerts can be correlated with vulnerabilities found though scanning, passive analysis and host analysis
• "Advanced Event Correlation Scripting" - several case studies of TASL scripts

Tenable also has a video of the Log Correlation Engine's log analysis and correlation functions being viewed through the Security Center.

The Log Correlation Engine can be used to track DHCP leases and Active Directory authentication logs to automatically learn each user's Ethernet address and then alert when this relationship changes. Tenable has released a TASL script named user_to_mac.tasl which can perform this function with a variety of DHCP sources and Active Directory "successful login" events. This script is useful for several reasons:

• It continuously updates a text file named user_mac.txt with a list of all users, their last IP address and their MAC address.
• If a user account logs in from a different laptop, an alert will be logged.
• New user to MAC address detection events are also detected by the detect_change.tasl script.

Below are some screen shots of what these alerts look like under the Security Center.

Summary of Events	Raw Syslog Capture

To make use of this new script, download it to your plugins directory and also update your lce_tasl.prm file to parse the new event names.

Tenable's Log Correlation Engine (LCE) can accept events from the Reconnex iGuard. If you are not familiar with products like the iGuard, it is a sophisticated network traffic analyzer that can look for social security numbers, credit card numbers, and important corporate data as it flows across instant messaging, email attachments, web surfing and most other forms of network traffic.

Having the LCE be able to parse logs from the iGuard allows users of the Security Center to analyze traffic on their separate network segments. This means Joe from accounting can see the iGuard events for his network and Sue from HR can get alerted for their events. Tenable has also written some advanced TASL correlation rules that look for systems being attacked and then having their sensitive data transferred by the attacker. Using intrusion detection logs and iGuard logs, the LCE can recognize when a system has been under attack and then sensitive data has been obtained from the target.

Security Enhanced Linux (commonly known as SE Linux) offers several methods to secure what the kernel and the applications can and can't do. This can help prevent successful buffer overflow attacks from both local and remote sources. When exceptions occur, the operating system will generate logs that are processed by Tenable's Log Correlation Engine. Currently, the logs are processed and can be manually analyzed by users. Shortly though, Tenable will release a TASL script that correlates attacks detected by intrusion detection systems with system events from SE Linux servers. This will allow Tenable customers to detect more serious Linux network attack attempts.