Will 2009 bring newer and more comprehensive versions of regulations such as PCI or FDCC? Is your organization already positioned to leverage the benefits of configuration management and transparent audit of IT resources?

With a focus on configuration and vulnerability management for enterprise networks, Tenable CTO Ron Gula, will discuss the latest trends in compliance standards, strategies for a positive audit experience and how this process can lower your organization's operational costs and maximize availability.

Title: "Winning at the Compliance Game"
Date: Tuesday, February 3, 2009
Time: 1:00 PM - 2:15 PM EST

Register now by clicking on the link below:
https://www1.gotomeeting.com/register/706770928

If you are unable to attend the live webinar, it will be recorded and made available online at the above URL shortly after it occurs.

Have you ever been in the situation where you have found a server or desktop Windows system that was infected with a virus, Trojan, rootkit or malware and you wanted to scan your network to see if other systems had similar issues?  Nessus ProfessionalFeed and Security Center users can leverage the compliance auditing features of Nessus to look for evidence of hostile software on their network.

Background

Even though anti-virus technology is available, many organizations routinely deal with daily infections. In some organizations, anti-virus agents are prevalent due to the plethora of mutations in the threat as new types of hostile code can make its way into your network. Even more worrisome is the fact that many organizations with large networks have made the decision to not use any anti-virus solution and instead, rely only on network security and system hardening. Gone are the days when Internet-wide worms made front page news. Instead, IT security organizations wage daily battles to keep their network clean.

Existing Anti-Virus Audit and Hostile Code Discovery Capabilities

Before we talk about some new strategies for discovering viruses with Nessus, we should review the existing methods to audit systems for potential viruses and to make sure they are running a correctly configured anti-virus solution.

Previous blog entries have described how Nessus and the Security Center can be used to audit small and large enterprise networks to make sure there is adequate anti-virus capabilities.

• If Nessus finds one of many commonly running commercial anti-virus solutions, it checks to make sure its virus signatures are up to date. If not, it lists this as an important vulnerability. (Read more)
• As part of your corporate configuration audit policy, you can also use Nessus audit policies to ensure that each system is running the correct and official anti-virus solution and verify that it is set to run, to auto-start, to auto-update and so on. (Read more)

Nessus also has the ability to find suspicious system services and issues that may indicate the presence of malware:

• If a worm or Trojan adds a daemon to a compromised host that serves executables, Nessus will recognize this and generate an alert accordingly.
• If your Windows HOSTS file has been modified by a virus, Nessus check 23910 will likely detect it.
• If you have a Trojan or worm that has added a service in general, Nessus can audit all system processes which have an open network socket.
• Nessus checks for several dozen popular virus daemons and infected files. If you visit Tenable’s plugin search page and enter in terms such as “worm”, “virus” or “Trojan”, you can get an idea for the types of hostile code Nessus can search for.

Finding Systems Compromised with Hostile Code

Now that we’ve reviewed how Nessus can monitor your anti-virus solutions and potentially identify broad types of virus infections, how can it help when you know exactly what type of hostile code you are dealing with?

The basic idea is to use Nessus’ ability to audit registry settings or file content to look for viruses. As part of your analysis of any system infected with hostile code, there is very good chance that the virus has some sort of fingerprint that aids in detection. Some of the most common fingerprints to look for are specific registry entries or files that have been created or modified by the virus.

For example, F-Secure has written an analysis about the Banbra.RM virus, which provides a list of files, processes, network connections and registry entries the virus attempts to make or create. In particular, it sets the value “C:\WINDOWS\msnmsgsr.exe” into the following registry:

HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\run\msn

The following audit policy could be used by Nessus or the Security Center to audit your network for this virus:

<if>
 <condition type: "and">
  <custom_item>
   type        : REGISTRY_SETTING
   description    : "Banbra.RM trojan check"
   value_type    : POLICY_TEXT
   reg_key    : "HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\run"
   reg_item    : "msn"
   value_data    : "C:\WINDOWS\msnmsgsr.exe"
   reg_option    : CAN_BE_NULL
  </custom_item>
 </condition>

 <then>
  <report type: "FAILED">
   description    : "Banbra.RM trojan check."
   info        : "A key found in the registry indicates the Banbra.RM trojan is infecting the host."
   info        : "Key: HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\run , msn, C:\WINDOWS\msnmsgsr.exe"
   info        : "(This audit tests for the Banbra.RM trojan, as defined at:"
   info        : "http://www.f-secure.com/v-descs/trojan-spy_w32_banbra_rm.shtml"
   info        : "The contents of this audit should be edited to reflect any other desired target.)"
  </report>
 </then>
 <else>
  <report type : "PASSED">
   description : "Banbra.RM trojan check."
   info        : "The absence of a known key in the registry indicates the Banbra.RM trojan is likely not infecting this machine."
   info        : "(This audit tests for the Banbra.RM trojan, as defined at:"
   info        : "http://www.f-secure.com/v-descs/trojan-spy_w32_banbra_rm.shtml"
   info        : "The contents of this audit should be edited to reflect any other desired target.)"
  </report>
 </else>
</if>

This is not to suggest that you should load up all of your favorite virus rules and use this technique proactively. The idea is that when you discover some sort of infection, you can quickly audit your Windows computers to see if they contain evidence of a compromise.

Types of Technical Audits

If you have discovered a virus infection or some other type of hostile code and want to audit your systems to see if others have been infected, Tenable recommends that you consider the following types of audits.

• Static registry key, item and value
• A user registry key, item and value
• A static file
• A specific process name

If you are familiar with user registry settings, you will know that different Windows system users can have different registry settings. These settings are located under the “HKU” if you are browsing a system registry. The Nessus configuration auditing checks will automatically test any HKU registry key across all users.

Below are two screen shots of auditing live systems for the presence of a specific virus.

The is an audit for the Banbra virus.The audit is looking for specific registry data which indicates a system has likely been infected by the Banbra virus.

In this screen shot, we've audited a system's list of processes to look for a file named "sodata.exe" and have not found it. This process is associated with the W32/Hupigon.OGA backdoor.

A Word to the Wise

Many viruses will invoke cmd.exe to run a variety of programs. You may be tempted to search all of your Windows computers to see if any have cmd.exe processes running. many legitimate applications will also run cmd.exe and leave those processes running. Finding a cmd.exe process does not directly correlate with a virus infection, but it could be a valid audit for your organization.

Please keep in mind that if you are working with live viruses, they may interact with your testing and auditing. If a virus has countermeasures, it may attempt to resist being removed and could re-create itself from copies running in memory. If a virus has a rootkit component, it may also have the ability to hide various registry settings, processes and files from your audits. This could give you a false sense of security. In a crisis though, being able to rapidly audit many different systems could yield very interesting and useful results.

For More Information

Tenable’s Customer Support Portal includes example audit policies for Nessus and Security Center users that can be modified to find evidence of local systems that have evidence of virus infections. Users who wish to share their audit policies for specific variants of Trojans and viruses may wish to post them to the Discussions Forum so that other Nessus users can benefit.

Previous blog entries have described how blacklist analysis for logs and network traffic can lead to interesting evidence of compromises and network probes. In this blog entry, we will examine a situation where the continuous blacklist activity led to multiple compromises.  This particular network has the Security Center, Passive Vulnerability Scanner and two Log Correlation Engines (LCEs). One LCE is receiving netflow data and logs from Snort while the other LCE is gathering network session data and syslog messages from routers, servers and access control devices on the network.

Initial Detection

Tenable products are deployed at several different live research and testing sites. For blacklist analysis, we typically see occasional hits during the course of a day such as shown in the following screen shot:

At one of the university locations we monitor, we saw the following sequence of events:

Notice that the “Blacklist-Emerging Threats Compromised Host” event is almost continuous. The default query is for 24 hours. Since the event seems continuous, we zoomed out for a five day summary of events: 

Clearly, we can see that the bulk of the Blacklist events occurred over the past 2 days, but there were no events in large numbers prior to that time.

Who is causing us problems?

The next step is to determine the IP address or addresses involved. Clicking on the “78909” events instruct the Security Center to summarize IP addresses, as shown in the following screen capture (actual addresses have been sanitized):

All of the IP addresses involved were from our network except one in the 123.151.0.0/16 class B network. To trace the owner of the address, we first searched for it in the ARIN “whois” database, which can be found at this link: http://www.arin.net/index.shtml. Entering the IP address in the search box labeled “Whois” showed that the address was registered with the Asia Pacific Network Information Center (APNET).  Querying the “Whois” search on the the APNET site showed that the address was registered from a location in China. Tracing one IP address is much easier than tracing multiple simultaneous attackers.

Analyzing the Attacker

An important point with blacklists is that an IP address could be scanning you today, yesterday or even a few weeks ago and it might never be placed on a public blacklist. Even when it is, you should always attempt to go back in time and see if there was any detected activity from the IP before it was placed on the blacklist.

In this case, we took the IP address and had the Security Center summarize all events from it for the past 48 hours:

This single display tells a very interesting story and is the primary focus for this blog post.

There is no activity prior to the blacklist events. We should always be suspicious that there may have been activity that was not logged or sniffed, but in this case, we are pulling netflow data from inside the network and are performing direct network sniffing on the university perimeter.

On January 15 around 9:00 AM (the first vertical blue line is 12:00 noon on the 15th) are two “Never Before Seen Correlated” events.  This means that two hosts on the network have had a correlated event occur from the LCE, which has never happened before. The correlated event that has never been seen before is the “Long Term Intrusion Activity” as indicated by this sanitized log entry:

Never_Before_Seen-correlated event, destination IP address 128.xxx.xxx.xxx has never seen event Long_Term_Intrusion_Activity in the past. This event originated from 123.151.xxx.xxx. If this event is unusual for this IP address, please investigate this event further.

Other machines on our network may have indeed had correlated events and need to be investigated, but the IP addresses involved in this attack could be our first priority.

The bulk of the network traffic is short network sessions, consistent with probing. These are indicated by both the TNM-TCP_Session_Short and the TFM-TCP_Session_Partial. The TNM events indicate network sessions that were sniffed with the Tenable Network Monitor agent and the TFM events indicate netflow events logged with the Tenable NetFlow Monitor.  A majority of the events are short events that last less than 5 minutes. However, in both the netflow data and sniffed network session logs, there are several sessions that have lasted 15, 30, 60 minutes or longer. Towards the end of this graph can be seen some network sessions that have transferred hundreds of megabytes of data and several that have transferred more than a gigabyte.

Performing a port summary of just the network events provides this distribution:

Clearly, this is on port 22 and is likely a Secure Shell probe of some sort. With this in mind, the long network sessions and sessions that had large bandwidth in them seem more ominous.

Many SSH worms that have been active in January of 2009 perform brute force password guessing. These sessions are relatively long, but utilize low bandwidth.  Picking a TNM-Long_TCP_Session_60_Minutes event at random, we can analyze its sanitized log:

Fri Jan 16 13:49:15 - TNM-Long_TCP_Session_60_Minutes[2102]:123.151.xxx.xxx:13861 -> 128.xxx.xxx.xxx:22 [u:521 d:1581]|1232128074|1232131755|3681

The “u:521 d:1581” entries indicate that the client uploaded 521 bytes and also downloaded 1581 bytes of data. Moving slightly more than 2000 bytes in an hour is not a large file transfer. It is very likely that the network connection was used to attempt several login and password guesses.

Perhaps more concerning is that later on in the graph, there are several TNM-TCP_Session_Whole events that had 100MB to 1GB of data transferred. This could indicate that a server was compromised and was being used for a more specific purpose. Each of these sessions also involved port 22. Large file transfers on this port are very alarming. Keep in mind that the filter on this graph only showed events that involved our suspicious entry from China. If that IP had connected to a host on a target network and then connected out to other targets across the Internet, it would not be shown on this graph. Finding all of the IP addresses that these target hosts had connected to would be a very good next step.

Lastly, there are two “Suspicious Proxy” events. These events are the result of an LCE correlation that examines terminating TCP sessions that are longer then five minutes and attempts to find “leap frog” connections. The behavior we are trying to find is when one computer connects to a second computer and then uses that second computer to make a connection to a third computer. Every time the LCE sees a terminating network session, it checks lists of other previously terminated network sessions to see if there could be a link. If so, it logs a Suspicious Proxy event with a log entry that looks like this:

Suspicious_Proxy - host: 192.168.20.91 just completed a network session lasting from client 208.73.181.192 to port 1361 and during that time completed the following TCP sessions (destination IP:destination port:duration): 208.73.181.192:5223:

Although simple and elegant, an issue with this technique is that since we are purely watching the network traffic, we have no way to correlate system activity that could be generating normal outbound connections. There could be other processes or even other users on the system that are making legitimate connections outbound.  Even in the case of our blacklisted IP address, the fact that the IP address has connected with us over SSH  is no reason to conclude a different user on the system was not performing some sort of network activity.

Having said all this about the two Suspicious Proxy events, knowing that the blacklisted IP address in this case had made numerous connections to the network, and eventually was seen using large amounts of bandwidth from the network, these events should be analyzed much further. With the Security Center and Passive Vulnerability Scanner, we could learn the IP addresses involved in these Suspicious Proxy events and then obtain vulnerability and profile information about the targets.

What are we not seeing?

One of the interesting perspectives about running Tenable’s products at different test locations is that in almost every case, we get to deal with a different level of vulnerability and event information. In some places, we get to scan with credentials and in others, we can only sniff. Some test sites provide us full logs from their network servers and even user desktops while others only provide us netflow data and sniffed TCP sessions. With that in mind, what types of logs and access would be of most useful to us in this case?

• System logs for these targeted Linux servers would be most useful. It would be very interesting to see if an account was guessed and which account it was. Was there any software installed via RPMs? Were any network devices placed into promiscuous mode?  Were any user accounts added? This sort of information is readily processed by the LCE and can quickly build a full picture of what an attacker is capable of.
• Full system audit access would allow Nessus to perform more detailed patch analysis, and also determine which ports had which processes listening on them. If an unsophisticated backdoor were added to the server, it is possible a new Nessus process scan could identify the listening process.

This sort of analysis is local to our network. It is also very interesting to see if the remote attackers are active on other lists or monitored sites. In this case, the IP address was added to an Emerging Threats Snort rule. After gathering the information for this blog, we went and queried several of our other test sites and saw logs like this:

Fri Jan 16 03:53:04 – TNM-ICMP_Activity:123.151.xxx.xxx:11 -> 149.xxx.xxx.xxx:0

This is a log from the Tenable Network Monitor that captured some ICMP probes also from the remote blacklisted IP address.

Previous Event Analysis Training Blogs

This blog entry is the fifth is a series of entries that offers in-depth example analysis of detecting a wide variety of scanning, probing and compromise issues. To view all of them, click on this link. The specific blog entries in this series are as follows:

• Run NT and Pay The Price – shows how a Windows NT 4.0 system is compromised and participating in a command and control network.
• Advanced Blacklist Analysis – shows examples of how IP blacklists can be used.
• Working with “Blacklists” – introduction to working with publicly available sources for IP address reputations.
• Working with Emerging Threats Events – introduction to work with IDS alerts generated from Snort running the Emerging Threats signature rules

Although we focus on using Tenable products to view and analyze a variety of security events, readers can expect to learn a wide variety of monitoring strategy from reading these blog entries. If you would like more information about Tenable products, please contact as at sales@tenablesecurity.com or consider viewing the following product videos.

The videos from the January DojoSec meeting are now online. Marcus Carey's introduction, Dale Beauchamp's talk on memory forensics and my talk on all things related to compliance and IT are available on Vimeo. To watch the talks, click below. My talk is 45 minutes and it should make you think hard about how to articulate compliance, configuration management, and mono-cultures to your management or your team.

With the release of Security Center 3.4.3 as well as Log Correlation Engine 3.0.1, we've updated the main Unified Security Monitoring videos at nessus.org. These videos are free to use and do not require registration. The following new videos are now available:

Unified Security Monitoring

This is a five minute introduction to the concept of performing vulnerability and configuration analysis on the same vendor solution that can perform log correlation and anomaly detection. Unifying this information into one spot allows you to spot security risks and compliance issues early and often.

PCI Enterprise Auditing

This twelve minute video discusses how unifying system and event analysis into one platform can address all 12 requirements of PCI. Demo includes enterprise PCI DSS scanning, auditing anti-virus configurations, scanning for documents which contain credit cards, finding wireless access points, tracking user access to systems with card holder data and much more.

Configuration And Vulnerabiltiy Scanning

This five minute video provides a more in-depth look at how to analyze vulnerabilties and configuration issues that have been obtained from the Nessus vulnerability scanner and Passive Vulnerability Scanner. Many aspects of the Security Center's ability to filter and sort on the security data collected are demonstrated.

Log Normalization And Search

This video shows how syslog, windows events, firewall logs, network session data and much more is aggregated and normalized by the Log Correlation Engine. Multiple examples of event analysis are performed, including searching logs of a firewall for specific patterns.

Correlation And Anomalies

The Log Correlation Engine will perform a variety of event correlation types. This video demonstrates detection of some simple behaviors such as brute force password guessing, continuous scanning detection and statistical changes in network traffic and login events.

Change Detection

Change occurs on your network all the time. With this video, you can see how Nessus, the Security Center, Passive Vulnerability Scanner and the Log Correlation Engine can detect changes from scan to scan, through log analysis and through direct network monitoring. More importantly, this video shows how vulnerability data can be filtered by time so you can easily see when a vulnerability was first discovered. 

Insider Threat

A new feature of version 3.0 of the Log Correlation Engine is to dynamically associate usernames with IP addresses and tag every event with a user name. This makes sorting on firewall logs, netflow and any other type of event by user very easy. This video demonstrates how to use user login events from a popular NAC to then correlate other types of network and system activity.

I was recently asked by Carpathia Hosting to contribute to an eBook being written by their CTO, Jon Greaves. The book is titled 'The Datacenter of the Future'. 

The initial chapter describes the evolution of security and privacy as we've progressed from issues such as the Morris worm of 1988 to today's "it's in the cloud" attitude. There are some very good insights in the chapter which explain how the past evolution of technology will influence the types of offerings ISPs and hosting companies will provide in the next decade.

My contribution was to answer specific questions on how cloud computing can impact your security posture, what sort of functions should/could be outsourced and how organizations can minimize their operating costs with virtual systems.

If you are struggling in your organization to raise security awareness in a mass rush to outsource key applications, you, your peers or your managers will benefit from reading the chapter.There is no charge and no sales pitch.

Chapter 1 was recently released in PDF format and at the DataCenter Journal. I've uploaded a PDF copy  (454KB) below for readers of this blog: 

Immunity Inc, (the makers of the CANVAS penetration testing tool), have partnered with Tenable Network Security and DSquare Security to offer a product bundle which is ideal for consultants who perform penetration testing, vulnerability analysis and compliance auditing services. The bundle includes:

• Immunity CANVAS
• Tenable Nessus ProfessionalFeed
• DSquare Exploit Pack

This bundle saves customers 20% off of the list purchase price for each of these products.

One of the things I am very excited about with this bundle is the integration between Nessus and CANVAS provided by the DSquare Exploit Pack. As you can see in this video here, you can perform your vulnerability scans with Nessus and then feed them directly into CANVAS for exploitation.This can minimize the amount of work a consultant needs to do when attempting to find an exploitable target. The DSquare technology makes great use of the Nessus 3 report format as well. This also means if you are a Security Center organization, you can extract all of your vulnerability data and feed it into CANVAS to rapidly provision a penetration test. 

CANVAS also has the ability to retrieve password LM/NTLM hashes. This information can be fed into Nessus 3 to perform a patch or configuration audit of a system that has been compromised. As a consultant, this allows you to identify systems which can be compromised with CANVAS and then further test them with Nessus by performing patch audits, CIS/PCI/FDCC and other patch audits and to even scan them for sensitive data.

The next DOJOSEC is this week. I've been invited to speak about the latest compliance trends in PCI and FDCC. Also presenting will be Shaf Ramsey of TechGaurd Security and Dale Beauchamp of the Transportation Security Administration. Mr. Ramsey will discuss the future of virtual worlds such as HIPIHI and the implications they will have for information security. Mr. Beauchamp is a digital forensics expert and will discuss practical memory analysis. 

The time and location of the event are:

January 8th - Thursday - 6:00 PM to 9:30 PM
Charles I. Ecker Business Training Center
6751 Columbia Gateway Drive
Columbia, MD 21046

DOJOSEC is a series of presentations organized by Sun Tzu Data.  Past speakers have included Johnny Long and Bruce Potter. They have many more seminars planned and I recommend signing up to their newsletter to learn more.