Introduction

In the first part of this post I explained the scenario and the initial approach for data gathering, in this second part I’m going to discuss the approach to collect data while the incident is happening.

Understanding Data Gathering Process

To better understand the information gathering flow that we are about to configure, review the diagram below:

The expected flow in this scenario is:

1. The attacker starts the procedure against the company’s resource.
2. Once the amount of attempts reaches a certain number an alert is triggered.
3. Event Viewer will log the event 21284 and since it is configured to trigger an action once this event happens, it will execute the script.
4. The script will open netmon and start collect data.

Although this is the basic flow for this scenario, we also have an option to follow a different approach, for example: leave netmon running until the network traffic from the attacker’s IP is received and once event viewer shows the event you can trigger a different action. For this example we will use the following flow:

1. We will leave Netmon running (following the steps from NetWiz to create the nmcap command line)
2. The attacker starts the procedure against the company’s resource.
3. Nmcap is configure to capture all traffic coming from this source IP (which is the one that you already determine from previous 21284)
4. Once the amount of attempts reaches a certain number an alert is triggered and event 21284 will be logged.
5. Task Scheduler is configured to run a task (a BAT file for example) that will send a traffic pattern to force netmon to stop capturing.

Preparing the Environment

In order to use Netwiz you should have Network Monitor installed first in your system, once you finish installing Netmon, download NetWiz from Codeplex and follow the steps below on your Edge device:

1. Double click NetWiz1.1.exe
2. Click Yes on the initial pop up window.
3. In the Welcome page, click Next.
4. In the Protocols page select All protocols coming from this host (IP address). For the purpose of this example I’m going to use the IP 192.168.0.1.
5. On the Schedule Start page leave it as default (Now) and click Next.
6. On the File Size page leave it as default (100 MB) and click Next.
7. On the Schedule Stop page choose When the following traffic comes in and click Select Traffic button. Type the IP address of one internal resource that you want to establish a connection when this event happens. For this example we will use the IP address of one internal web server. Choose Destination, TCP as protocol and port 80. Click OK and click Next.
8. On the Interface page, select the adapter that face Internet connection and click Next.
9. On the Options page, leave the default option and click Next.
10. Click Finish.

Second part is to configure Event Viewer to trigger an action when this event happens, in order to do that follow the guidelines from this post. The BAT (or script) that will be used during this process must have the command that will initiate a connection on port 80 of the internal web server (telnet webserver_IP 80). This is an important step in order to comply with the parameters that were configured in NetWiz. This BAT (or script) can also contain a lot more commands (including other tools that can gather more data about a target system); it all depends on what you want to collect in additional to netmon traces.

It is also important to emphasize that sometimes this type of attack comes from random IP addresses, if this is the case, you will not need to create filters to only collect data coming from one specific address.

Now What?

Once you have the traffic pattern and also identified the IP address that is starting the attack against your resource you can start by contacting your service provider to report the abuse of resources coming from this IP. Check if it is possible for your ISP to track this IP and take actions against this type of attack.

The presentation that I delivered last week during the TechPEDay and MS Sec Day V2 is now available in the link below (in Portuguese):

This presentation was based on the article that I co-wrote with Deb Shinder to the ISSA Jounal (May issue). In this presentation I showed a video (in English) from Chris Capossela, Senior Vice President of Microsoft's Business Division, where he responds to CIO concerns around data security in the cloud (see below).

Enjoy it !

Introduction

Most of the good firewalls out there have the capability to identify suspicious activity and lof this information for you. However, there are some scenarios where you want more than just knowing what happened, you want to build a better footprint of the potential attack that the edge device is passing through. This post will explain how to combine the power of Event Viewer with the flexibility of Network Monitor Wizard to build trigger an action when an incident happen. To achieve that we will divide the post in two parts, this part one will explain the scenario, identify the issue and work on the data gathering process. For this post we will use Forefront TMG 2010 as our edge device; however the same approach can be used in any device that logs its major alerts to Windows Event Log.

Symptom

The true value of having logging enabled on your system is the capability to review it and identify suspicious activities that took place during that time. In this particular case the Firewall Administrator identified the following entry in the Event Viewer:

When reviewing such event, pay attention to the following fields:

• Logged: this field provide the time and day that such event took place. Notice here that it took place 3:31AM, which in this particular case is a non production hour (first flag).
• Event ID: this field is important because you will use it to filter all events with the same ID. The goal is identify if there are more than one event like that on your system.
• General: the text on this field means a lot; read it carefully and observe the IP address that it is available there. Once you filter the events by the Event ID, you should check if the IP appears is the same on all events. In this case it did (second flag).

The reason why I added the flags is because usually when you raise two flags while analyzing potential suspicious activity you have enough reason to move forward in the investigation process. Is important to also mention that in this particular scenario, as I’m using Forefront TMG as example of Edge device, the same event that you see on Event Viewer will be also available at Monitoring/Alerts within TMG’s console as shown below:

Footprint

Now that you identified the suspicious activity on your edge device and you know which IP address you should hunting for, you can move forward. The information gathering will vary according to your internal process to respond to incidents; however there are usually some commons steps that can be used during this process, such as:

• WhoIs: type http://who.is/whois-ip/ip-address/W.X.Y.Z/ (where W.X.Y.Z is the IP address that you are trying to lookup).
• Bing: Bing has the capability to look for all domains that are using a particular IP. To know more about this feature, download the presentation “Lord of the Bing” from Black Hat 2010.
• DNS Query: once you have the domains and the IP that belongs to this host, you can use nslookup to know more information about the records that are part of this domain.

All those methods are passive and the goal is only to know more about who is originating that suspicious traffic against your edge device.

Moving Forward

The second part of this article will explain how to capture live data and how to connect the dots to formulate your final conclusion.