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:
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:
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:
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.
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 !
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.
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:
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:
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:
All those methods are passive and the goal is only to know more about who is originating that suspicious traffic against your edge device.
The second part of this article will explain how to capture live data and how to connect the dots to formulate your final conclusion.