Priveon Labs Security Blog

Priveon Training Services is in the process of working towards certification as an IronPort Training Partner. Last week, I attended the S-Series training for the IronPort Web Security Appliance and both the standard and advanced courses for the C-Series Email Security Appliances.

The S-Series Web Security Appliance is a new appliance from IronPort based on the highly successful AsyncOS platform that IronPort developed for the C-Series. It offers fast inspection ofweb traffic from two different perspectives: a Layer 4 wire-speed packet filtering device and an advanced Web Application Proxy. The datasheet can be found at http://www.ironport.com/products/web_security_appliances.html

The C-Series Email security Appliances are well know in the industry and offer extremely feature rich options to protect email services ranging from small to ISP-class infrastructures. The C-Series Appliance offers innovative technology from IronPort called SenderBase – a reputation based analysis technology that draws information from customers and participants all over the world to assess the credibility of a sender, much like a credit score attempts to score the creditworthiness of consumers by analyzing their past history and other various scoring factors. More details can be found here: http://www.ironport.com/products/email_security_appliances.html

In this, the third part of my series I will review additional methods of discovering malware on a system using basic built-in tools. As I mentioned in the previous post, we are going to cover processes, listeners, and locations.

Processes

Many folks are probably aware of Task Manager in windows. Task Manager provides information about processes running on your computer. Task Manager can be accessed by pressing the “Ctrl, Alt, and Del” keys at the same time and then clicking on the Task Manger button. There is a lot of malware out there written to evade Task Manager. Malware will create a process that terminates the Task Manager process upon execution, effectively preventing you from accessing the information that Task Manager provides. Some malware will hide processes from being viewed in task manager. There are other utilities available that can provide the same information or more about processes. Do you remember the WMIC command from Part 2 of this series?

Click Start. Then Run and type “cmd.exe”

At the dos prompt, type “wmic process list brief” and hit enter.

As you can see, we get the same type of information that Task Manager provides. Oh My Gosh What The heck is that omgwt32.exe?

Listeners and Locations

This time we are going to look at the TCP communications of the computer. In order to determine this information, we are going to use “netstat”. Microsoft states that this program “Displays active TCP connections, ports on which the computer is listening, Ethernet statistics, the IP routing table, IPv4 statistics (for the IP, ICMP, TCP, and UDP protocols), and IPv6 statistics (for the IPv6, ICMPv6, TCP over IPv6, and UDP over IPv6 protocols). Used without parameters, netstat displays active TCP connections.”

Click Start. Then Run and type “cmd.exe”

At the dos prompt, type “netstat -nao” and hit enter.

In the screenshot image, you might notice that something is listening on port 2222. We can also see that the PID (Process ID) is 640. I intentionally left the results from the previous “wmic process list brief” command displayed, so that you could see that the PID matches omgwt32.exe. We know from Part 1 of the series that we were able to see omgwt32.exe is located in the c:\windows directory using “Sigverif”, but what if we did not see that information? Lets use wmic to display more information, but lets pipe that information through the windows “findstr” utility to narrow the search and display just the information we need for omgwt32. Findstr is a utility used to search for regular expressions (somewhat).

Click Start. Then Run and type “cmd.exe”

At the dos prompt, type “wmic process list | findstr omgwt32” and hit enter.

You should now see the path to the omgwt32.exe file.

Lets use the findstr utility to see if omgwt32.exe is in the startup list.

Click Start. Then Run and type “cmd.exe”

At the dos prompt, type “wmic startup list brief | findstr omgwt32” and hit enter.

We can now see the command line that started this executable up in the first place. Omgwt32 is actually netcat. I used it for demonstration purposes.

In Part 4 and the final post of this series, I will use these same methods to discover real malware on an infected system. More importantly, I will also demonstrate that some of these methods will not always provide results. As I previously stated, these tools simply provide a means to check the system for signs that malware may exist.

When installing or configuring a Cisco MARS environment/hierarchy you should always ensure that the Local Controllers (LCs) are set to the same timezone as the reporting devices that they are monitoring. In addition, all of the LCs and the Global Controller (GC) should be configured for the same timezone and be configured to sync their clocks off of the same NTP source that is used by the reporting devices themselves.

But what if the environment you are installing the MARS in is configured to use GMT? If you look at the MARS timezone settings, GMT is NOT an option.

Lets take a look... To set the timezone on the MARS you use the command line interface (CLI) command of: timezone set

This displays a menu system that allows you to select the appropriate timezone based on continent/country/region. So going back to our requirement of setting the timezone to GMT we need to determine how this maps into the menu options. To do this we need to understand where and when GMT is observed:

GMT is used all year in these European countries:

• Iceland

GMT is used during winter only in these European countries:

• Ireland
• United Kingdom - main islands (England, Wales, Scotland, Northern Ireland)

Based on this information, the only viable setting to use on the MARS is Iceland:

For additional information, Cisco does have a Bug ID on this for tracking purposes: CSCsi06290. The bug is marked resolved and the fix should be incorporated in upcoming MARS release 4.2.7.

As a final note, make sure you are aware that time changes on the MARS are immediate, which can affect active incident correlation. If you change the time by greater than 30 minutes, you should restart your appliance to ensure that all processes synchronize using the new time.

In my last post, I showed how to use sigverif to identify questionable files. In this post, I will go over identifying potential threats by examining startup items, scheduled tasks, user accounts, and the windows hosts file. The goal so far, has been to provide you with the ability to monitor various areas on you system where malware tends to "hide". These tools and methods should help you get familiar with what’s normal on your computer and what’s suspicious. Let’s first take a look at the windows Hosts file.

Hosts File

The windows XP hosts file is used to store information on where to find a node on a computer network. The information contained in the file, resolves hostnames to IP addresses. This file is used much like DNS (Domain Name System), but has the ability to be edited locally, unlike DNS. Malware will often write to the hosts file in order to prevent you from resolving some addresses or to have you resolve specific addresses to point to a malicious site. In the first case, the malware author may want your antivirus software to stop getting updates, so the author creates an entry in your hosts file that prevents your antivirus software from going to the correct location for updates. Another way a malware author may use the hosts file is to have the malware add an entry that resolves your bank's address to a fake server elsewhere on the internet. While its important to know that the hosts file can be used for good, there are many ways a bad guy can use the hosts file.

Viewing the hosts file:

Click Start, then Run, and type:

Notepad.exe %SystemRoot%\system32\drivers\etc\hosts

Click OK.

The image illustrates what a normal hosts file in windows XP should look like. Everything with “#” in front of it is commented out – meaning that they are just comments and are not used by windows XP for resolution. The loopback address of 127.0.0.1 is set for localhost, which is a reserved name meaning this computer.

Now that we have an idea of what a normal hosts file look like, let’s take a look at a hosts file that has been edited or replaced by malware.

Read more »

Here's another tip on how to customize the Agent User Interface of the Cisco Security Agent. By default the CSA Agent UI will display a "balloon" popup message near its system tray icon whenever a deny rule is triggered. It may be desirable for some administrators to leave the agent UI enabled but at the same time not display alert messages to the end user. This tip can be combined with my previous post on changing how the system tray icon behaves to prevent unnecessary notification to the end user.

The balloon popups can be disabled through a per user registry value. In the "HKEY_USERS\(USER SID NUMBER)\Software\Cisco\CSAgent" key of the registry, add a DWORD value with a value name of BalloonPopupsDisabled and a value of 1 to disable popups. If you choose to re-enable popups then you would set the value at 0.

Per user registry values can be tricky and unpleasant to deal with. I'll go over the basic options you have now and then in a later post I'll show how to do this automatically without any manual changes needed on each workstation. There are three registry paths that can be used to implement this change, each having a somewhat different affect. To make the change for the user currently logged in then you would choose the path "HKEY_CURRENT_USER\Software\Cisco\CSAgent." To make the change for a specific user (you must specify the user's SID in the path to target them) you would use the path "HKEY_USERS\(USER SID NUMBER)\Software\Cisco\CSAgent." Another option is to make the change in the default user key. This will only apply to new users that login to that particular computer but it will make sure that all new users get the setting. To make the change for the default user key you would use the path "HKEY_USERS\.DEFAULT\Software\Cisco\CSAgent."

This setting can be applied to CSA versions 5.0 and above. It should also be noted that the agent will prevent modifications to its registry key while it is active.

In future posts I'll be sharing more tips as well as ways to make these changes via an automated deployment to multiple clients through systems management technologies. Stay tuned!