Chris Sanders

There are a lot of things that the industry does well when it comes to network security monitoring (NSM). For instance, I tend to think that we have data collection figured out reasonably well. I also think that signature-based intrusion detection is a really well developed science. However, with NSM having only existed for a short period of time there are several facets of it that aren’t too well defined. One such aspect is the actual diagnostic method that people use to analyze NSM events. That is, the process an analyst uses to connect the dots between the initial alert and the final diagnosis. In this article I’m going to discuss the use of a common medical diagnostic method called differential diagnosis and how it can be applied to NSM.

 

Understanding Normal

The first thing that was ever taught to me when I started my career as an NSM analyst was that if you know what normal looks like, then you can determine what is bad. I trusted in this concept for many years and even taught it to others. As true as this statement may be, I believe it is relied on entirely too much. This is primarily due to a failure in separating the collection, detection, and analysis processes.

 

Collection centers on the hardware and software used to collect NSM related data. Consider the collection of full content packet capture (PCAP) data. The use a network tap and DaemonLogger allow you to store this data on disk so that it may be used for the identification and analysis of network security related events. Collection occurs with a combination of hardware and software.

Detection is the process by which collected data is examined and anomalies are identified, typically through some form of signature, anomaly, or statistically based detection. Snort is software that is an example of signature-based intrusion detection that compares collected network traffic to signatures of known malicious activity in an effort to perform pattern matching to determine if something bad has occurred. Detection is typically software focused.

Analysis is what occurs when a human interprets the results of the output of an identification tool. Although Snort may detect a pattern match in a communication sequence and generate an alert, it is a human who is ultimately responsible for reviewing the alert and investigating it to an end determination on its validity. The key concept here is that analysis is human focused.

 

With those three terms more clearly defined and distinctions drawn, it would stand to reason that the concept of knowing what normal looks like in order to determine what is bad is actually more relevant to detection than analysis. Realistically speaking, it’s not feasible in the modern state of network computing to be well versed in every aspect of normal communications. Although some traffic patterns may remain fairly static, the open nature and loose standards that govern network communication protocols result in a constant evolution of traffic patterns. Don’t be mistaken, this is still an important concept that must be incorporated into the analytic approach, it’s just not strong enough to stand on its own as the singular concept new analysts should be taught. Knowing what normal looks like is best used when analyzing specific facets of a potential breach rather than as a holistic method to classify all network traffic you may be capturing.

 

A Differential Approach

The general goal of an NSM analyst is to digest the alerts generated by various detection tools and investigate multiple data sources and perform relevant tests and research to see if their findings represent a network security breach. This is very similar to that of a physician, whose goal is to digest the symptoms a human presents and investigate multiple data sources and perform relevant tests and research to see if their findings represent a breach in the person’s immune system.  Both practitioners share a similar of goal of connecting the dots to find out if something bad has happened and/or is still happening.

Although NSM has only been around a short while, medicine has been around for centuries. This means that they’ve got a head start on us when it comes to developing their diagnostic method. One of the most common diagnostic methods used in clinical medicine is one called differential diagnosis. If you’ve ever seen an episode of “House” then chances are you’ve seen this process in action. The group of doctors will be presented with a set of symptoms and they will create a list of potential diagnosis on a whiteboard. The remainder of the show is spent doing research and performing various tests to eliminate each of these potential conclusions until only one is left. Although the methods used in the show are often a bit unconventional they still fit the bill as a part of the differential diagnosis process.

The differential method is one based upon a process of elimination. It consists of five distinct steps, although in some cases only two will be necessary. The differential process exists as follows:

1. Identify and list the symptoms
   
   In medicine, symptoms are typically initially conveyed verbally by the individual experiencing them. In NSM, a symptom is most commonly in the form of an alert generated by some form of intrusion detection system or other detection software. Although this step focuses primarily on the initial symptoms, more symptoms may be added to this list as additional tests or investigations are conducted.

 

2. Consider and evaluate the most common diagnosis first
   
   A statement every medical student is taught in their first year is “If you hear hoof beats, look for horses…not zebras.” This is to state to that the most common diagnosis is likely the correct one. As a result, this diagnosis should be evaluated first. The analyst should focus his investigation on doing what is necessary to quickly confirm this diagnosis. If this common diagnosis cannot be determined to be true during this initial step then the analyst should proceed to the next step.

 

3. List all possible diagnosis for the given symptoms
   
   The next step in the differential process is to list every possible diagnosis based upon the information currently available with the initially assessed symptoms. This step requires some creative thinking is often most successful when multiple analysts participate in generating ideas. Although you may not have been able to completely confirm the most common diagnosis in the previous step, if you weren’t able to rule it out completely then it should be carried over into the list generated in this step. Each potential diagnosis on this list is referred to as a candidate condition.

 

4. Prioritize the list of candidate conditions by their severity
   
   Once a list of candidate conditions is created a physician will prioritize these listing the condition that is the largest threat to human life at the top. In the case of an NSM analyst you should also prioritize this list, but the prioritization should focus on which condition is the biggest threat to your organizations network security. This will be highly dependent upon the nature of your organization. For instance, if “MySQL Database Root Compromise” is a candidate condition then a company whose databases contains social security numbers would prioritize this condition much higher than a company who uses a simple database to store a list of its sales staffs on-call schedule.

 

5. Eliminate the candidate condition, starting with the most severe
   
   The final step is where the majority of the action occurs. Based upon the prioritized list created in the previous step the analyst should begin doing what is necessary to eliminate candidate conditions, starting with the condition that poses the greatest threat to network security. This process of elimination requires considering each candidate condition and performing tests, conducting research, and investigating other data sources in an effort to rule them out as a possibility. In some cases investigation on one candidate condition may effectively rule out multiple candidate condition, speeding up this process. Alternatively, investigation of other candidate conditions may prove inconclusive leaving one or two conditions that are unable to be definitively eliminated as possibilities. This is acceptable however as sometimes in network security monitoring (as in medicine) there are anomalies that can’t be explained that require more observation before determining a diagnosis. Ultimately, the goal of this final step is to be left with one diagnosis so that either the incident handling process may begin or the alert can be dismissed as a false positive. It’s very important to remember that “Normal Communication” is a perfectly acceptable diagnosis, and will be the most common diagnosis an NSM analyst arrives at. I also find that remembering that all packets are good unless you can prove they are bad is an important concept to remember during this step.

 

 

Let’s consider this process with a couple of broad case scenarios.

 

Scenario 1

Step 1: Identify and List the Symptoms

Symptoms:

• Internal host appears to be sending outbound traffic to a Russian IP address
• The traffic is occurring at regular intervals, every 10 minutes
• The traffic is HTTPS over port 443, and as such is encrypted and unreadable

Step 2: Consider and Evaluate the Most Common Diagnosis First

It’s been my experience that most entry level analysts will see these symptoms and automatically think that this machine is infected with some form of malware and is phoning home for further instructions. Those analysts tend to key in on that fact that the traffic is going to a Russian IP address and that it is occurring at regular 10 minute intervals. Although those things are worth noting (I wouldn’t have listed them if they weren’t), I don’t buy into the malware theory so easily. I believe entirely too much emphasis is placed on the geographic location of IP addresses, so the fact that the remote IP address is Russian means little to me. Additionally, there are a whole variety of normal communication mechanisms that talk on regular periodic intervals. This includes things like web-based chat, RSS feeds, web-based e-mail, stock tickers, software update processes, and more. Operating on the principal that all packets are good unless you can prove they are bad, I think the most common diagnosis here is that this is normal traffic.

That said, how we can confirm this potential diagnosis? Confirming something is normal can be hard. In this particular instance we could start with some open source research on the Russian IP. Although it’s located in Russia it still may be owned by a legitimate company. If we were to look up the host and find that it was registered to a popular AV vendor we might be able to use that information to conclude that this was an AV application checking for updates. I didn’t mention the URL that the HTTPS traffic is going to, but quickly Googling it may yield some useful information that will help you determine if it is a legitimate site or something that might be hosting malware or some type of botnet C2. Another technique would be to examine the host physically if you have ready access to it in an effort to see if any processes are launched on the machine at the same intervals the traffic is occurring at.

Let’s assume that we weren’t able to make a final determination on whether or not this was normal communication.

Step 3: List all Possible Diagnosis for the Given Symptoms

*There are obviously more candidate conditions in the realm of possibility, but for this and the other scenario I’ve kept it to some of the more common ones for the sake of brevity.

Candidate Conditions:

• Normal Communication
  We weren’t able to rule this out completely in the previous step so we carry it over to this step.

 

• Malware Infection / Installed Malicious Logic
  This is used as a broad category. We typically don’t care about the specific strain until we determine that malware may actually exist. If you are concerned about a specific strain then it can be listed separately. Think of this category as a doctor listing “bacterial infection” as a candidate condition knowing that they can further narrow it down later.

 

• Data Exfiltration from Compromised Host
  Potential that the host could be sending proprietary or confidential information out. This sort of thing would likely be part of a coordinated or targeted attack.

 

• Misconfiguration
  It’s well within the realm of possibilities that a system administrator fat-fingered an IP address and a piece of software that should be trying to communicate periodically with an internal IP is now trying to do so with a Russian IP. This is really quite common.

 

Step 4: Prioritize the List of Candidate Conditions by their Severity

These priorities are fairly generalized since they are dependent upon your organization.

Priority 1: Data Exfiltration from Compromised Host

Priority 2: Malware Infection / Installed Malicious Logic

Priority 3: Misconfiguration

Priority 4: Normal Communication

Step 5: Eliminate the Candidate Conditions, Starting with the Most Severe

Priority 1: Data Exfiltration from Compromised Host

This one can be a bit tricky to eliminate as a possibility. Full packet capture won’t be of the most assistance here since the traffic is encrypted, but if you can create some statistics from this traffic, or better yet, if you have netflow available, you should be able to determine the amount of data going out. If only a few bytes are going out every then minutes than it’s likely that this is not data exfiltration. The host based research you did earlier on the Russian IP address may also provide some value here in determining the reputation of this host. It would also be of value to determine if any other hosts on your network are talking to this IP address or any other IPs in the same address space. Finally, baselining normal communication for your internal host and comparing it with the potentially malicious traffic may provide some useful insight.

Priority 2: Malware Infection / Installed Malicious Logic

At this point the research you’ve already done should give you a really good idea on whether or not this condition is true. It will be likely that by examining the potential for data exfiltration you will rule this condition out as a result, or will have already been able to confirm it to be true.

Priority 3: Misconfiguration

This condition can best be approached by comparing the traffic of this host against the traffic of one or more hosts with a similar role on the network. If every other workstation on that same subnet has the same traffic pattern, but to a different IP address, then it’s likely that the wrong IP address was entered into a piece of software somewhere proving that a misconfiguration exists. Having access to host-based logs can also be useful in figuring out if a misconfiguration exists since they might exist in Windows or Unix system logs.

Priority 4: Normal Communication

If you’ve gotten this far, then the diagnosis of normal communication should be all that remains on your list of candidate conditions.

Concluding a Diagnosis

At this point you have to use your experience as an analyst and your intuition to decide if you think something malicious is really occurring. If you were able to complete the previous analysis thoroughly, then operating on the assumption that all packets are good unless you can prove they are bad would mean your final diagnosis here should be that this is normal communication. If you still have a hunch something quirky is happening though, there is no shame in monitoring the host further and reassessing once more data has been collected.

 

Scenario 2

Step 1: Identify and List the Symptoms

Symptoms:

• A web server in our DMZ is receiving massive amounts of inbound traffic
• The inbound traffic is unreadable and potentially encrypted or obfuscated
• The inbound traffic is coming to multiple destination ports on the internal host
• The inbound traffic is UDP based

Step 2: Consider and Evaluate the Most Common Diagnosis First

With the amount of traffic being received by the internal host being very large and the packets using the UDP protocol with random destination ports, my inclination would be that this is some form of denial of service attack.

The quickest way to determine whether something is a denial of service is to assess the amount of traffic being received compared with the normal amount of traffic received on that host. This is something that is really easy to do with netflow data if you have it available. If the host is only receiving 20% more traffic than it normally would then I would consider other alternatives to a DoS. However, if the host is receiving ten or one hundred times its normal amount of traffic then DoS is very likely and almost a certainty.  It’s important to remember that a DoS is still a DoS even if it is unintentional.

Once again, for the sake of this scenario we will continue as though we weren’t able to make a clear determination on whether or not a DoS condition exists.

Step 3: List all Possible Diagnosis for the Given Symptoms

Candidate Conditions:

• Denial of Service
  We weren’t able to rule this out completely in the previous step so we carry it over to this step.

 

• Normal Communication
  It doesn’t seem incredibly likely, but there is potential for this to be normal.

 

• Misdirected Attacks
  When a third party chooses to attack another they will often spoof their source address for the sake of anonymity and to prevent getting DoS’d themselves. This will result in the owner of the spoofed IP they are using seeing that traffic. This web server could be seeing the effects of this.

 

• Misconfigured External Host
  A misconfiguration can happen on somebody else’s network just as easily as it could on yours. This misconfiguration could result in an external host generating any number of types of traffic and sending them to the web server.

 

• SPAM Mail Relay
  The server could be misconfigured or compromised in a manner that allows it to be used for relaying SPAM across the Internet.

 

Step 4: Prioritize the List of Candidate Conditions by their Severity

Priority 1: Denial of Service

Priority 2: SPAM Mail Relay

Priority 3: Misconfigured External Host

Priority 4: Misdirected Attacks

Priority 5: Normal Communication

Step 5: Eliminate the Candidate Conditions, Starting with the Most Severe

Priority 1: Denial of Service

We’ve already gone through the paces on this one without being able to identify that it is the definitive diagnosis. Even though this is the most severe we would have to proceed to attempt to eliminate other candidate conditions to help in figuring out if a DoS is occurring. Of course, depending on the effect of the attack it may make the most sense to contain the issue by blocking the traffic before spending more time investigating the root cause.

Priority 2: SPAM Mail Relay

This one is relatively easy to eliminate. If the server was being used as a mail relay then you would have a proportionate amount of traffic going out as you do going in. If that’s not the case and you don’t see any abnormal traffic leaving the server then it is likely that it is not relaying SPAM. If the web server is also running mail services then you can examine the appropriate logs here as well. If it is not supposed to be running mail services you can examine the host to see if it is doing so in an unauthorized manner.

Priority 3: Misconfigured External Host

This one is typically pretty tricky. Unless you can identify the owner of the IP address and communicate with them directly then the most you can hope to do is block the traffic locally and/or report abuse at their ISP level.

Priority 4: Misdirected Attacks

This is another tricky one along the same lines as the previous candidate condition. If it’s an attacker somewhere else whose antics are causing traffic redirection to your server then the most you can do is to report the issue to the ISP responsible for the IP address and block the traffic locally.

Priority 5: Normal Communication

This doesn’t seem likely, but you can’t say this for sure without baselining the normal traffic for the host. Compare its traffic at similar times on previous days to see if you can draw any conclusions. Is the pattern normal and it’s just the amount of traffic that anomalous? Is it both the pattern and the amount that’s anomalous? Does the server ever talk to the offending IP prior to this?

 

Concluding a Diagnosis

In this scenario, it’s very possible that you are left with as many as three candidate conditions that you cannot rule out. The good thing here is that even though you can’t rule these out, the containment and remediation methods would be the same for all of them so you still have gotten to a state of diagnosis that allows the network to recover from whatever is occurring. If the amount of traffic isn’t too great then you may not need to block the activity and you may be able to monitor it further in order to attempt to collect more symptoms that may be useful in providing a more accurate diagnosis.

 

Conclusion

I’ve spent quite a bit of time doing analysis with this differential approach and also reviewing previous investigations post-mortem while applying these concepts and I’ve been really pleased with my findings. I think that if you are struggling with being able to grasp a firm analytical method then this may be a great one to start with. I’m not entirely sure that the differential method is appropriate for all organizations, but just as with medicine, there are competing approaches and I hope to examine more of those in the future so that I can draw more comparisons between the medical field and NSM. If you have any scenarios in which you’ve used this differential approach (for better or for worse), I’d love to hear about them.

In the realm of network security monitoring and intrusion analysis we are all slaves to our data. Typically speaking, we rely on two different types of data at the network layer; full content data (PCAP) and session data (Netflow). Both are pretty easy to generate given the right sensor placement, and there are a lot of great resources out there for learning how to get good value out of the data. That said, they do each have their own shortcomings as well.

 

Session Data (Netflow)

Netflow is a standard form of session data that details the ‘who, what, when, and where’ of network traffic. I tend to equate this to the call records you’ll see on your monthly cell phone bill.

 

 

 

 

Figure 1: Partial Netflow Records Exported from SiLK

 

The best thing about netflow is that it provides a lot of value with minimal disk storage overhead. It’s really a lot of bang for your buck. Most commercial grade routers and firewalls will generate netflow, and there are a lot of free and open source tools, such as SiLK, that can be used to generate and analyze netflow as well. There is even a yearly conference called FloCon where people get together and talk about cool things you can do with netflow. The only real downside to netflow data is that it doesn’t paint a complete picture, so it’s often best used as a complement to full content data.

 

Full Content Data (PCAP)

If netflow session data is equivalent to a call log, then full content data in the form of PCAP is just like having a full recording of all of your calls.

 

 

 

Figure 2: PCAP Data Investigation with Wireshark

 

 

The PCAP format has become very universal and can be collected and analyzed with a variety of free and open source applications like Dumpcap, Tcpdump, Wireshark, and more. A lot of the more popular intrusion detection systems, such as Snort, use the PCAP format as well. As an analyst, having PCAP data available tends to make the analytical process a dream come true as it provides the highest level of context when investigating an anomaly. The primary downside to full content data is that it has an incredibly high disk storage overhead, which prevents most organizations from collecting and storing any reasonable amount of it. In my experience, the organizations that are capable of collecting and storing PCAP can only measure the amount stored in hours, rather than days. In addition to this, unless you have an idea of what you are looking for within a reasonable time range, it can be a bit difficult to locate things as well, somewhat impeding flexibility in analysis.

 

Application Layer Metadata

The concept of application layer metadata originally presented itself to me in a discussion regarding additional data types that are useful within the network security monitoring function that were sort of a happy medium in between session data and full content data. It didn’t take a lot of number crunching to find that on most of the networks we monitored, the vast majority of the traffic was the application layer data of a few common protocols. The largest of these was HTTP, followed by the other usual suspects; SSL, DNS, and SMTP.

Starting with a couple of these protocols as a baseline, we quickly realized that we could save ourselves a lot of disk storage overhead by actually eliminating the stuff we didn’t need. There are an unlimited number of ways to do this, but we wanted to go with the keep it simple philosophy, so we started by using tcpdump to read in our PCAP data, outputting the ASCII formatted data to a file. Then, we ran the Unix strings command on that file to get read of any binary data that we couldn’t read anyways. We weeded out a few more things that we didn’t want through a magical combination of SED and AWK, added in the appropriate timestamps, formatted the data a bit prettier, and we had achieved our goal.

The end result of a reasonably small bash script was the ability generate application layer metadata in the form of something we call a Packet String, or PSTR file (pronounced pee-stur).  The script is ideally designed to run as a cron job where it parses continually generated PCAP files in order to generate accompanying PSTR files.

 

 

 

 

 

 

 

 

Figure 3: Sample PSTR Data

 

You can download the bash script that generates this data from PCAP files here. This is provided as a simple proof of concept and takes an input PCAP file and generates an output PSTR file. Now that we’ve got application layer metadata being generated in the form of PSTR files, let’s take a look at a few use cases.

 

Using PSTR as a Data Source

The original goal of generating PSTR files was to provide a data format with a low disk storage overhead that provided value to analysts as a secondary NSM data source. In a typical workflow, analysts would take an input from a detection capability, such as an IDS, and then PSTR would be another data source available to the analyst in order to provide supporting evidence in the analysis of a potential event or incident. I’ve written a few use cases here. Some of these are theoretical, but others are examples of actual things that have happened since implementing the PSTR data type.

 

Malware Infection Use Case

Let’s look at an example in which we’ve just received an alert from our IDS stating that an internal system has been detected as exhibiting symptoms of infection. The signature that fired did so because it saw a malicious GET request associated with a known botnet C2 server. The host was examined, and it appeared as though the GET request matches what is expected as a result of the signature that fired, so were able to determine with a pretty reasonable certainty that this box was infected.

Upon closer examination, we also notice that the infected host was also sending an HTTP POST with a very unique string. This looked like it might be an indicator of malicious activity, but it wasn’t something that any of your existing signatures fired on. In this case, an analyst was very quickly able to use GREP to quickly find other instances of this same string within the HTTP header data of all traffic on our monitored networks. PSTR data proved to be incredibly useful in finding other infected boxes across multiple networks.

 

Targeted Phishing Use Case

As a theoretical example, consider another example where several users have contacted your security team because they’ve received a very suspicious e-mail that seems to be targeted specifically at your company. This e-mail mentions a payroll adjustment and asks the client to access the provided link and log in with their employee ID number and password.

After examining the e-mail, you’ve determined that it has been sent from a spoofed e-mail address and that it uses a slightly modified subject line that is unique to each recipient. You’ve also noticed that based upon the reports you’ve received from users, these e-mails have come in over the past several weeks. One of the things you would want to do in this case would be to find who within your organizations received this e-mail. The purpose of this is to be able to warn the users not to click the link in the e-mail and also in hopes that you might be able to find a pattern as to why the selected recipients were chosen (access to certain systems, high profile employees, etc).

Typically, you might search through Exchange or Postfix logs to see if you can find who the recipients were. This of course relies on your organization having adequate logging and retention of those logs. The unique nature of the string however, makes it difficult to query these data sources. Using PSTR data, you can write a quick regular expression to match the semi unique subject lines and run a very quick query that will give you these results.

 

Using PSTR as a Detection Capability

The one thing we didn’t really anticipate when we created the PSTR file type was its use as a second level detection capability. When I refer to second level analysis and detection, I’m referring to moving past near real-time detection to the point in which analysts start reviewing traffic retrospectively to find things that signatures don’t catch. This often involves statistical and anomaly based detection with large data sets. This is something PSTR is perfect for.

 

User Agent Use Case

The user agent field within an HTTP header is always a good source for catching the low hanging fruit when it comes to malware infections on a network. Lots of malware will use a custom value in this field that deviates from standard browser identifying strings. The detection technique I’ve seen most commonly deployed to catch these types of malware infections at the network level rely on IDS/IPS signatures. As a matter of fact, if you subscribe to the common popular Snort rule sets then probably are using their user agent rules to detect known bad user agents.
The only problem with that detection scenario is that malware is now being generated at a rate much faster than the AV and ISD companies can keep up with. As a result, there are a LOT of malicious user agents out there that aren’t accounted for. In addition to this, some malware uses randomly generated user agent strings, meaning it’s much more difficult to write adequate signatures for detection.

One day, one of our analysts started playing around with PSTR data and wrote a quick script to parse all of the PSTR data for a given site, grab all of the user agent strings, and sort those by uniqueness. As expected, there were thousands of occurrences of the typical Firefox and Internet Explorer user agents, but what was really interesting was that there were several user agent strings only seen a handful of times that didn’t correlate to any particular known browsers. After a bit more analysis, we ended up finding quite a few machines that were infected with malware variants using these custom user agent strings. This one was a home run.

 

E-Mail Subject Use Case

The previous use case got us to thinking about other common fields with application layer metadata that we could do the same types of analysis on. One such field was the e-mail subject line field.  We modified our user agent parsing code to look at all PSTR data related to e-mail subject lines, and again had some very cool results.

Instead of most of the distribution being focused on one or two unique strings like we saw with user-agents, we saw that the distribution was spread very widely across thousands of different subject lines. This was expected, since most e-mails have a unique subject line. What interested us here however, was that we had a few subject lines that were used in excess. The first item of interest we found was that some sites had misconfigured applications that were mailing things to places they shouldn’t go, which was worth pursuing and getting fixed. We also found a user who was e-mailing all of his work documents to himself as a scheduled task every night, which was a policy violation.

This was all found with a very basic level of analysis, and it had some very real and useful results.

 

Additional Analytic Capabilities

The thing I love about this data format is that we can store a lot of it and it’s really quick to search through. With those things being true, there are a ton of things that can be done with it from a detection standpoint. A few immediate ideas include:

• Searching for unique values with HTTP, SMTP, DNS, and SSL headers

This is what we did in most of these examples. You can really quickly sort through the unique values within certain fields and find the outliers that warrant additional investigation.

• Byte entropy of certain fields to locate encrypted data where it shouldn’t be

It’s a common tactic to exfiltrate encrypted data through commonly used channels in an effort to hide in plain sight. Performing entropy calculations on GET and POST requests in an effort to find encrypted data would be a good way to detect where this might be occurring.

• Checking the length of certain fields for anomalies

You can do some statistical analysis and determine that certain fields will often have values that have a length falling in a particular range. Using that, you can flag on outliers that are far too short or too long in order to look for anomalies. I’ve seen good success in doing this with the various HTTP header fields, e-mail subject lines, and SSL certificate exchanges.

• Enumerating Downloads of Particular File Types

There is a great deal of value to being able to list all of the executables or PDF files downloaded within a certain time span. This is pretty easily achievable really quickly with analysis of HTTP header data within PSTR files.

Of course, all of these things CAN be done on PCAP data as well, but it would take significantly more processing power and it’s likely that you can’t store enough PCAP data at a given time to make it worth useful.

 

Conclusions

The concept of collecting and storing application layer metadata isn’t anything revolutionary. As a matter of fact, the idea isn’t even completely original as I’ve encountered other organizations that do similar things. There are even some commercial products that do this as well. However, I do know that nobody is sharing their methods and code with the world, which is the purpose of this post. Analysts live and die by their data feeds, and I think application layer metadata in whatever form it takes has its place amongst the other primary network data types. You can download the proof of concept code to generate and parse PSTR files here. I’m excited to see this data format evolve as we find more and more use for it. Look for more updates on this front as the code base continues to advance.

 

 

* A special thanks to my colleague Jason Smith for doing most of the legwork on writing the POC code.

 

I’m sitting in my hotel room after just finishing my last session at US-CERT GFIRST in Nashville, TN. This was my first time at GFIRST both as an attendee and presenter, and I really had a great time. Where I’m originally from in Kentucky isn’t too far from Nashville so I am familiar with the area and the venue choice, the Gaylord Opryland Hotel, is a beautiful facility and top-notch for this kind of conference. I wanted to take a moment to address where people can find the resources for my presentation as well as my thoughts on some of the presentations I had a chance to see and the conference as a whole.

My Presentation

Along with my friend and colleague Jason Smith, we presented a talk on Real World Security Scripting. At a bare minimum, we wanted to share some quick and dirty scripts we wrote to do some pretty neat things within our security operations center (SOC) at SPAWAR. At a higher level, we really hoped that we could encourage some people to get involved with low level BASH, Python, and PERL scripting to automate tasks within their SOC environment as well as increase capabilities of the SOC and its staff. We generated quite a bit of interest, and as a result it looks like several people were turned away because the room was filled to fire code capacity. Our sincere apologies to those who missed to talk. We got some really positive feedback from folks who did make it to the presentation.

As promised, we will be releasing our slides and source code for the presentation. The slides can be downloaded here. As for the source code, we are maintaining the distribution release on https://www.forge.mil, which requires a DOD CAC or ECA certificate to access. I understand that a lot of government folks outside of DOD don’t have access to forge.mil, so we are trying to find another place to host this code where we can control access to only people in the .gov or .mil space. In the meantime, if you would like to get copies of the code, please e-mail me at my mil address (chris.sanders.ctr@nsoc.med.osd.mil) from your mil/gov address and I will get it over to you. We are hoping to get all of that bundled up by next week.

 

Presentations I Attended

Keynote Panel Discussion – “Unplug to Save”

I started the week on Tuesday by attending the opening ceremony in which there was a panel discussion between several leaders in the government cyber defense community. The panel included Winn Schwartau, Mark Bengel, Doris Gardner, John Linkous, and John Pray, Jr and was moderated by Bobbie Stempfley. If you aren’t familiar with those individuals I’ll leave the Googling to you .

 

The discussion was centered on the concept of “unplug to save”, focusing on whether it was an acceptable solution to unplug an entity from the Internet in order to prevent a catastrophic event from occurring as a result of a cyber attack. The panel was split and brought up several good points about the interdepencies between certain aspects of government and national defense, namely citing the one that were unknown. Truth be told, sometimes we just don’t know the affect removing certain networks from the Internet would have. I’m of the opinion that in some cases hitting the kill switch is the best policy, but that is only in an extreme and I’m not sure who that authority should be put on. The panel also got into a discussion of the inherently flawed nature of the Internet and the need for an architecture redesign. That was all fine and dandy and I won’t disagree…but until some form of governing body takes on the task of redesigning the fundamental protocols of the Internet and it is taken seriously then this is just a pie in the sky dream.

 

The only thing that really irked me during the discussion was when one of the panelist mentioned how we could “solve the cyber problem” by hiring the types of hackers who can’t get clearances. It would seem to be that doing such a thing would be a prime way to generate more Bradley Manning-esque cases. Granted, Manning wasn’t a computer security expert by any means, but imagine what someone with his kind of access could do with a bit of hacking knowledge. I’d just asoon we make cyber jobs within the government more attractive to young professionals so that they stay on the straight and narrow instead of the USG resorting to hiring criminals.

 

 

Internet Blockades

This talk was presented by Dr. Earl Zmijewski from Renesys and was one of the talks I enjoyed the most. He described several types of Internet censoring, blocking, and filtering techniques used across the world citing recent examples of Egypy, Libya, North Korea, and of course, the great firewall of China. All of his examples had technical data to back them up which really left me with satisfied. Random fact – N. Korea only has 768 public IP addresses.

 

 

Using Differential Network Traffic Analysis to Find Non-Signature Threats

This talk was centered on the creation of metadata of layer 7 data on the network. This isn’t entirely a new concept, but its one that most people are just now keying in on. The general idea is that you can strip out only the layer 7 data from HTTP/DNS/EMail streams, index it, and store it so that you can perform analysis on it. The benefit here is that the amount of disk space required for storage of this type of data is much less than storing full PCAP, allowing for more long term analytics. The talk was presented by David Cavuto from Narus, who did describe a few useful analytics I hadn’t though of. For example, collecting the length of HTTP request URIs and performing a standard deviation of those to look for outliers. This could potentially find incredibly long or incredibly short URIs that might be generated by malicious code.

 

Unfortuantely, being a vendor talk, Mr. Cavuto didn’t provide anything that would help people generate layer 7 metadata, but he did have a product he was selling that would do it. Fortunately, I have some code that will generate this type of metadata from PCAP. I’m going to button that up and release it here at some point…for free

 

 

Getting Ahead of Targeted and Zero-Day Malware Using Multiple Concurrent Detection Methodologies

This was, by far, my favorite presentaiton of the week. It was given by Eddie Schwartz, the new CSO at RSA. The talk was centered around investing time in the right areas of analysis. Namely, looking across the data sources that matter and not relying on the IDS to do all the work. Once Mr. Schwartz releases his slides I would recommend checking them out. He is a man who understands intrusion detection and how to make it effective. My favorite part of his talk was something he said a couple of times: Yes, doing it this way is hard. Suck it up. It gets easier.

 

 

They Are In Your Network, Now What?

This talk was presented by Joel Esler of Sourcefire. Joel is a really smart guy and a great presenter and he didn’t disappoint. My big take away from this one was his discussion of Razorback, which I really think is going to be one of the next big things in intrusion detection. I think a lot of the crowd missed the point on this. There were a lot of complaints because of the amount of legwork required to integrate the tool, but I think most of those people were overlooking the early stage the tool was in and the potential impact of the community released nuggets and detection plugins. I played with Razorback when it was first released and look forward to digging into it again once some of the setup and configuration pains are eased. I’ve already thought of quite a few nuggets that I could possibly write for it.

 

 

Analysis Pipeline: Real-time Flow Processing

I’m a huge fan of SiLK for netflow collection and analysis so I was excited to hear Daniel Ruef from CERT|SEI talk about Analysis Pipeline, a component that adds some cool flexibility to SiLK. Overall, I was really impressed with the capability and am looking forward to playing with the next version when it comes out in a couple of months. I always say that if you aren’t collecting netflow you are missing out on some great data, and SiLK is a great way to start collecting and parsing netflow for free. If you are already using SiLK, please do yourself a favor and look into the free add-on Analysis Pipeline.

 

 

Advanced Command and Control Channels

I thought this was an awesome overview of traditional and more advanced C2 channels that malware use. I don’t think anything here was really new, but the way the presentation was broken down was very intuitive and the examples that were given were rock solid. This was given by Neal Keating, a cyber intel analyst with the Department of State.

 

 

Final Thoughts

I really enjoyed the conference and honestly consider it one of the best and most relevant conferences for folks in cyber security within the gov/mil space. My only major complaint was that a few vendors managed to sneak their way into speaking and basically giving product sales pitches rather than technical talks. I’m hoping that feedback will make it back to the US-CERT folks and more effort will go into preventing that from happening in the future. I hate showing up to a talk that I hope to learn something from and being drilled with sales junk about products I don’t want. Yes, I’m looking at you General Dynamics and Netezza.

 

Overall, the staff did a great job of organizing and I’d be happy to have the opportunity to attend and speak at GFIRST 2012 in Atlanta next year.

 

 

TL;DR – Real World Security Scripting Presentation Slides – http://chrissanders.org/pub/GFIRST2011-SandersSmith.pdf – Please e-mail me for full code.

 

I recently found myself in a situation where I had a couple dozen Snort sensors deployed in a network with no commercial software for centralized management. Due to the decentralized nature of the sensor management, one of the bigger headaches was adding new custom rules to all of the sensors. New rules had to be added to each sensor manually into a custom rules file. These rules all existed in a single file, so I wrote a bash script that automates this process. Using this script an analyst only has to add the new rules to a single file and run the script to push it out to all of the other sensors. I thought I’d share that here for those that might get some use from it.

FAQ

What does the script do?

The script does a few simple tasks. It will perform the following actions for each IP in its sensor list:

• Create a backup of the existing custom rules file on the sensor.

• Replace the current rule file with the new rule file.

• Performs a ‘diff’ on the new rule file and the old rule file and places the results in a timestamped log file in /var/log/snortrules.

• Restarts snort on the sensor to ensure the new rules are applied.

What are the requirements for running the script?

In order to execute the script, the following conditions must be met:

• A custom rule file named the same as the custom rule file on the sensor must exist in the directory the script is executed from.

• You must have SSH/SCP connectivity to the servers.

• It is necessary to have permissions to perform the actions described above on the appropriate folders.

Additionally, it helps to have certificate based authentication setup for a service account that can handle actions performed by this script. Otherwise you will have to password authenticate to each sensor.

How do I add in the addresses for my sensors?

The first line of code in the script contains the list of sensor IP addresses. Replace the following with addresses for your sensors, delimited by spaces.

What other variables do I need to modify within the script to match my environment?

There are three main variables in addition to the sensor IP addresses. These are:

• rulepath – The path on the remove server where the custom rules file exists

• customrules – The name of the custom rules file

• user – The user name to use for authentication to the sensor

Can I make modifications to the script?

Absolutely. I’m not a programmer. I’m just a guy who saw a need and wrote something to address it quickly. That said, the script could probably be setup a lot better and do a lot of cool neat things (like error checking). If you find some value you in the script and want to make some modifications or additions to it then by all means do so, I just ask that you reciprocate those changes back to me so everyone can benefit.

 

With all that out of the way, you can download the script here.

I had the opportunity to take the SANS FOR610: Reverse Engineering Malware course in Orlando a couple of weeks ago and I wanted to write about my experience with the course. It’s no secret that I’m a big proponent of SANS. I’ve taken SEC 503 and SEC 504 at live events and I also mentor both courses here locally in Charleston. I wanted to take FOR610 as my next course because malware analysis is something I’ve not done a significant amount of. I’ve done a fair amount of behavioral analysis but very little code analysis at the assembly level and the course syllabus appeared to be heavy on that subject so it seemed like a natural fit to help fill in some of my knowledge gaps.

Instructor

The course in Orlando was taught by Lenny Zeltser. Lenny is the primary author of the materials, and he also runs a great blog over at http://blog.zeltser.com/ that I’ve followed for quite some time. I’ve been to a lot of different training courses and have also provided courses myself so I’ve seen plenty of bad instructors and good instructors. One of the things I find most challenging when teaching is taking highly complex subject matter and breaking it down in such a way that it is understandable. Being able to do this effectively is one of my primary criteria for defining a good instructor. That said, Lenny is perhaps one of the best teachers I’ve had. He took all of the highly complex concepts and broke them down in such a way that they were understandable at some level for every one in the class. He provided clear guidance and assistance during the lab portions of the class and I don’t remember a single question that was asked that he didn’t have an immediate answer for. His depth of knowledge on the subject was very apparent and appreciated.

Difficulty

The course really has two distinct sides to it: behavioral analysis and code analysis. Depending on your background, you may find this course very difficult at times and easier at others. I have written several programs in languages including Python, PHP, and C as a function of my primary job role, so I understand programming concepts, but I’m not a professional programmer by any stretch. That being the case, I had a harder time with the code analysis portions of the course. If I didn’t have any programming experience, I think I would have been completely lost on more than a few occasions. On the other side of the coin, I had no problems whatsoever with the behavioral analysis instruction and labs, but I could tell that several other people in the class did. From what I gathered by talking to people and looking at name badges, roughly 65-85% of the folks in my class were programmers of some sort. The course is touted as not requiring any previous programming experience, but I think to get the full benefit from the class, you should at least be familiar with core programming concepts, preferably in an object oriented language.

Course Content

The course was 5 days long and covered a variety of topics. I’ve outline some of those here along with the new skills I gained or enhanced as a result of what we learned.

Day 1

The first half of the first day was devoted to the setup of the virtual malware analysis lab used in the course. This is done in such a way so that the virtual lab can be used after you leave the class to do real world malware analysis in your organization using the virtual infrastructure. The second half of day one focused on using the lab for behavioral analysis.

New Skills I Gained: Knowledge of new malware analysis tools.

Day 2

This day built upon our knowledge of behavioral analysis and introduced new concepts related to that. We were introduced to dissecting packed executables and Javascript and Flash malware.

New Skills I Gained: Automated unpacking of packed files. Tools for dissection and extraction of malicious code in Flash objects.

Day 3

This day was devoted to code analysis. We were introduced to assembly and spent a great deal of time looking at commonly identifiable assembly patterns used in malware. This was one of the most useful parts of the class for me. We also looked a bit at anti-disassembling techniques that malware authors use.

New Skills I Gained: Enhanced understanding of assembly. A plethora of anomalies to look for in assembly level code analysis of malware. Patching code at the assembly level to get a desired outcome.

Day 4

The fourth day focused on analysis of malware that was designed to prevent itself from being analyzed. We looked at packers and learned how to manually step through malware code to unpack it for analysis. The day ended with an detailed and highly valuable look into deobfuscating malware in browser scripts.

New Skills I Gained: Detailed understanding of assembly for malware analysis. Manual extraction of unpacked code from packed executables.

Day 5

The final day of the course was another one of the most useful parts of the course for me. This first half of this day focused on analysis of malicious Microsoft Office files and malicious PDFs. After lunch, we covered shellcode analysis and memory analysis.

New Skills I Gained: Tools and procedures for extracting malicious code from MS Office files and PDFs. Better understanding of PDF file structure. Extraction of malware running in memory.

Labs

The labs were an integral part of the course. In the labs we analyzed real malware samples in our virtual analysis lab. I’m incredibly happy that we looked at REAL code from REAL attackers rather than simple malware created in a lab for the purpose of the course. Doing things this way we got to see how attackers will often take shortcuts or write bad code that we have to sort through rather than just dissecting cookie cutter malware with no imperfections. The labs served their purpose, helping reinforce new concepts in a practical manner. During the course, everyone had their laptops open and two virtual machines running at all times as we would dive into them for exercises very frequently.

Although I was very pleased with the labs in some ways, I am critical of them for a few other reasons. Prior to the class, you are provided some instructions on how to setup a single Windows based VM that is destined to be infected with malware repeatedly throughout the class. In addition, the instructions said we would be given a version of Remnux, the reverse engineering malware Linux distribution created by Lenny, to use during the class when we got there. I got this all up and running without any problems, but I was pretty upset when I got to the class to find out that there was quite a bit more setup to do. As a matter of fact, almost the entire first half of the first day of instruction was taken up by additional lab configuration. We were given a CD that contained a variety of tools that were to be installed on our Windows VM. I think all in all, we had to install about 25 different tools. Several people asked why these weren’t provided prior to the class and we were told it was so that we would take more ownership over our malware analysis labs and could ask questions. Although I can respect the comments in support of this, I think providing these tools prior to the class along with the other instructions would allow for better use of time. At lunch the first day I felt a bit cheated as my company had paid for an expensive course where I was just sitting around installing software. Providing this software prior to the course and having people come prepared would have allowed for a whole half day of additional instruction which would have been incredibly valuable.

The other primary issue I had with the labs was the format in which they were laid out. In most of the labs, Lenny would teach us a concept and then step through the process on his own system. Then he would turn us loose on our systems to work on the same example he just walked through. Although somewhat helpful, it wasn’t entirely effective since we had just seen him do the same example we were working through. I would contrast this with the lab format in the SEC 503: Intrusion Detection In-Depth course. In that course, students are given a workbook with lab exercises. The instructor there would teach a concept, go through a lab on screen, and then turn students to the workbook and give them some time to work through similar, but different examples. This format provided a great deal more value because we had to do quite a bit more thinking to get through the examples on our own, rather than just recreating what the instructor did.

Summing It Up

Overall, my experience with FOR 610 was very valuable and I’m thrilled I got the chance to take the course. I walked away with a lot of new skills and am able to provide a lot of value to my organization as a result. I now feel completely comfortable performing code analysis of malicious binaries. I also learned more assembly than I ever thought I would and feel like I could even write some simple programs in assembly should I choose to punish myself in that manner. I also gained a greater understanding of lower level operating system components which will prove useful in several cases. Make no mistake, this is a very difficult course, which is why ways numbered it so high. It is the highest level forensics course they teach, and it will challenge you. However, if you are up to it, there is a lot to be learned here, and I have no doubt that it is the best malware analysis course you will find.

You can read more about this course at http://www.sans.org/security-training/reverse-engineering-malware-malware-analysis-tools-techniques-54-mid.

One of the more important skills in intrusion detection and analysis is the ability to evaluate an IP address or domain name in order to build an intelligence profile on that host. Gathering this intelligence can help guide you to making more informed decisions regarding the remote hosts that are communicating with your network in order to determine if they are of a malicious or hostile nature. I recently wrote a two-part article on collecting threat intelligence for WindowsSecurity.com which describe some methods that can be used to collect threat intelligence on a host or network.

Collecting Threat Intelligence (Part 1)

Collecting Threat Intelligence (Part 2)

I’ve been actively involved in the training and development of intrusion detection analysts for a few years now which includes being a SANS Mentor for SEC 503: Intrusion Detection In-Depth. One thing I find myself constantly doing is trying to evolve my philosophy on effective intrusion detection. While doing this, some themes arise that tend to stay consistent no matter how that philosophy changes. Through that, I’ve written up something I call the “10 Commandments of Intrusion Analysis” which highlight some of those themes that seem to be at the core of what I try to instill in the analysts I train and in my own analysis. They don’t really command you to anything, but there are 10 of them, so the name kind of fits. These may not fit you or your organizational goals or personal style, but they work for me!

1. Analysts, Analysts, Analysts!

The most important thing an analyst can have ingrained into them in their importance. An analyst is the first line of defense. The analyst is sitting in the crows nest watching for the icebergs. It is the analyst who can keep attacks from happening and can stop attacks from getting worse. Most security incidents begin with an analyst providing a tip based upon an IDS alert and end with an analyst putting in new signatures and developing new tools based up on intelligence gained from a declared incident. The analyst is the beginning and the end in information security. The alpha and omega. Okay, maybe that’s a bit dramatic, but the importance of an intrusion analyst can’t be understated.

2. Unless you created the packet yourself, there are no absolutes.

Analysis happens in a world of assumptions and its important to remember that. Most of the decisions you will make are centered around a packet or a log entry and then honed based upon intelligence gathered through research. The fact is that the analyst isn’t the one who generated the traffic, so every decision you will make is based upon an assumption. Don’t worry though; there is nothing wrong with that. Ask your friendly neighborhood chemist or physicist. Most of their work is based upon assumptions and they have great success. The takeaway here is that there are no absolutes. Is that IP address REALLY a known legitimate host? Does that domain REALLY belong to XYZ company? Is that DNS server REALLY supposed to be talking to that database server? There are no absolutes, merely assumptions, and because of that remember that assumptions can change. Always question yourself and stay on your toes.

3. Be mindful of how far abstracted from the data you actually are.

An analyst depends on data to perform their function. This data can come in the form of a PCAP file, an IIS log file, or SYSLOG file. Since most of your time will be spent using various tools to interact with data it’s crucial to be mindful of how that tool interacts with the data. Did you know that if you run Tcpdump without specifying otherwise, it will only capture the first 68 bytes of data in a packet? How about that Wireshark displays sequence and acknowledgement numbers within TCP packets in a relative manner by default? Tools are made by people and sometimes “features” can cloud data and prevent proper analysis. I think both of the features I described earlier are great, but I’m also mindful that they exist so I can see all of the packet data available or view the real sequence and acknowledgement numbers when needed. In a job where reliance upon data is critical, you can’t afford to not understand exactly how tools interact with that data.

4. Two sets of eyes are always better than one.

There is a reason authors have editors, policemen have partners, and there are two guys sitting in every nuclear silo. No matter how much experience you have and how good you are you will always miss things. This is to be expected because different people come from different backgrounds. I work with the government so the first thing I look at when examining network traffic is the source and destination country. I’ve worked with people who have systems administration backgrounds and as a result, will look at the port number of the traffic first. I’ve even worked with people who have a number crunching background who will look at the packet size first. This demonstrates that our experiences shape our tactics a bit differently. This means that the numbers guy might see something that the sysadmin didn’t see or that the government guy might have insight that the numbers guy didn’t. Whenever possible it’s always a good idea to have a second set of eyes look at the issue you are facing.

5. Never invite an attacker to dance.

This is something I’ve believed since the first day I ever fired up a Snort sensor, but IDS guru Mike Poor phrased it best while I was attending one of his SANS classes when he said that you should never invite an attacker to dance. As an analyst its very tempting to want to investigate a hostile IP address a bit beyond conventional means. Trust me, there have been many occasions where I’ve been tempted to port scan a hostile that kept sending me painfully obviously crafted UDP packets. Even more so, any time someone attempts to DOS a network I’m responsible for defending, I wish nothing more than to be able to unleash the full fury of a /8 network on their poor unsuspecting DSL connection. The problem with this is that 99% of the time we don’t know who or what we are dealing with. Although you may just be seeing scanning activity, the host that is originating the traffic could be operated by a large group or even a military division of another country. Even something as simple as a ping could tip off an attacker that you know they exist, prompting them to change their tactics, change source hosts, or even amplify their efforts. You don’t know who you are dealing with, what their motivation is, and what there capabilities are, so you should never invite them to dance.

6. Context!

One word can drastically change the dynamic of your monitoring and detection capabilities. In order to be effective you must have context into the network you are defending. Network diagrams, listings of servers and their roles, breakdowns of IP address allocations, and more can be your best friend. Basically any and everything that can be used to document the assets within the network, how they function, and how they relate to other assets are beneficial in running down anomalous events. Depending upon your role in the organization you may not be in a position to obtain these things and if they don’t already exist you are going to have a heck of a time getting the systems folks to put in the leg work to create them. However, as difficult as this may be, its an effort that’s worth pursuing. Whether you have to present your case to the CIO or just buy your network engineers a case of their favorite adult beverage its ultimately worth the effort.

7. Packets, in a word, are good.

The ultimate argument in life is whether or not people are inherently good or inherently evil.  This same argument can be had for packets as well. You can either be the analyst that believes all packets are inherently evil or the analyst that believes all packets are inherently good. I’ve noticed that most analysts typically start their career as for the former and quickly progress the later. That’s because its simply not feasible to approach every single piece of traffic as something that could be a potential root level compromise. If you do this, you’ll eventually get fired because you spent your entire day running down a single alert or you’ll just get burnt out. There is something to be said for being thorough but the fact of the matter is that most of the traffic that occurs on a network isn’t going to be evil, and as such, packets should be treated innocent until proven guilty.

8. Analysis is no more about tcpdump than astronomy is about a telescope.

Whenever I interview someone for any analyst position that’s above entry level I always ask them to describe how they would investigate a typical IDS alert. I get frustrated when someone gives answers along the lines of “I use  Tcpdump, Wireshark, Network Miner, Netwitness, Arcsight, Xeyes, etc” with no further clarification. Although their are processes and sciences in intrusion analysis, intrusion analysis itself is not a process or a science, but rather an art. If this wasn’t the case then it wouldn’t even be necessary to have humans in the loop when it comes to intrusion detection. An effective analyst has to understand that while different tools may be the most important part of the job, those things are merely pieces of the puzzle. Just like an astronomer’s telescope is just another tool in his arsenal that allows him to figure out what makes the planets orbit the sun, Wireshark is just another tool in an analysts arsenal that allows him to figure out what makes a packet bypass a firewall rule. Start with the science, add in a few tools and processes, stay cognizant of the big picture, keep an attention to detail, and eventually the combination of all of those things and the experience you gain over time will help you develop your own analysis philosophy. It’s at that point you have taken your analysis to the level of an art, and made it so that your worthy enough to not be replaced by a machine.

9. Sometimes, we lose.

No matter how hard you try there will come a point in which the network you are defending gets successfully attacked and compromised. In the modern security landscape its inevitable and there isn’t a lot you can do about it. In these times its likely that the analyst will take the heat over the incident. Because of this, you need to be prepared when it happens. An incident won’t be remembered for how an intrusion occurred, but rather how it was responded to, the amount of downtime that occurred, the amount of information that was lost, and ultimately the amount of money it costs the organization. What recommendations can you make to management to ensure a similar incident doesn’t occur again? What can you show your superiors to explain why the attack wasn’t detected? What shortcomings do your tools have? These are questions that can’t fully be answered until an intrusion has occurred and you have the context of an attack, but you can definitely consider the questions now and have a plan for how your information will be presented to key figures. You will get caught off guard and you will be blind sided, but its important that you don’t appear as such and you keep your game face on. This can make the difference between a promotion and a pink slip.

10. Dig deeper.

At the end of the day you have to have something to rest your laurels on and that has to be the fact that you’ve done your due diligence and that you’ve given your best. My “motto” per se when it comes to intrusion analysis is “Dig Deeper”. A defender has to control 65,535 ports. An attacker has to compromise one. A defender has to protect 10,000 users. An attacker has to deceive one. A defender has to examine millions of packets. An attacker has to hide a malicious payload in one. What can you do to increase your visibility into the data? What proficiency can you develop that gives you that edge against the attacker? You have a hunch that there is more than meets the eye, so what can you do to dig deeper?

I’ve been slowly working through an article series entitled “Understanding Man-In-The-Middle Attacks” for the last few months. The last article of this series was published a couple of weeks ago so I thought I’d post a quick roundup of them all. This series covers four different types of attacks, how they work, how to execute them, and how to protect yourself from them. These articles are being hosted on WindowsSecurity.com, whom I write for on a monthly basis.

You can read each article at its corresponding link:

• Part 1 – ARP Cache Poisoning

• Part 2 – DNS Spoofing

• Part 3 – Session Hijacking

• Part 4 – SSL Hijacking

I’ve been using Snort has a host-based IDS on my laptop for quite a while now and rather than expanding my attack surface by installing a database server for logging, I am simply logging to the standard flat file format. In this format all snort alerts are logged to an alert.ids file in the C:/Snort/log directory. In previous instances I’ve just reviewed this log frequently but I’ve had the desire for quite some time to have something a bit more realtime. I’m not sure if I’ve found the best solution, but I’m currently using RainMeter to display the most recent Snort alerts on my desktop.


I did run into one problem which had a solution I think others might be interested in. Snort logs the newest alerts it recieves at the bottong of the alert.ids file, which makes gathering the most recent alerts via perl regular expressions a bit of a complicated task. I brought this problem to my analysis team at EWA and Jason Smith, who has just started learning Perl,  developed a script that alleviates this problem. The script takes the last alert in the alert.ids file and places it at the top of a new “parsed” file. The second to last alert in the alert.ids file is then placed as the second alert in the parsed file, and so on and so forth. Also, as a bit of expanded functionality the script only grabs the first four lines of every alert which gives the alert name, classification, priority, and basic packet information. This makes for a more condensed and concise output.


You can download the script here: snort_parser.zip


As for implementation, I have setup a scheduled task that runs the script every 5 minutes so that the RainMeter on my desktop is updated very frequently. One small issue I noticed was that when this task ran it would pop up a command prompt window momentarily which was quite annoying. In order to combat this I created a VBS script that runs the perl script in the background. Rather than running the perl script, the scheduled task runs the VBS script which calls the perl script as an argument so that the process is invisible to me.


You can download the VBS script here: silent_launcher.vbs


Feel free to download, use, and distribute these files as you see fit.

The fine folks over at GFI were kind enough to send me a copy of the latest release of their LANguard product which is currently at version 9.0. As a disclaimer, GFI does advertise on my site, but this is not a paid advertisement, and our business relationship is has no influence on my review of the product.

 

I’ve used various GFI products for several years and remember using LANguard many years ago while working for the Department of Education. As I have taken on a more security-focused role in my new position with EWA GSI I have found myself using LANguard again and am enjoying the newest version of the product just as much as I did the older versions.

 

The big three features LANguard boasts are vulnerability management, patch management, and network auditing. I’ll address each of those individually.

 

Vulnerability Management

 

My primary use of LANguard has always been in this category. Some of my earliest learning experiences with network security were centered on LANguard security scans and in my current security role I’m making use of it right where I left off.

 

The scanning engine boasts over 15,000 scanning signatures and does seem to be quite thorough. I compared GFI LG scans side by side with Nessus scans on the same hosts and found the reporting from the LG scans were picking up quite a few more items of interest when it came to Windows hosts. The scanning options are quite robust and the reporting and remediation interface couldn’t be much better. 

 

 

Patch Management

 

I’ve previously always used WSUS for patch management. However, if you’ve used WSUS you know that it can sometimes be unreliable and the reporting and troubleshooting features associated with it are still greatly lacking. I’m no longer directly managing a network so I evaluated the patch management features of LG on my home network and was pleasantly surprised.

 

I ran several scans against the devices on my networks and some of the virtual machines in my test networks that I had purposely halted automatic updates on. LG reported the missing updates on these machines and I was able to efficiently deploy those updates to the machines. I’ve always thought OS updates should be something that “just works” and LG fit the bill on this.

 

Network Auditing

 

There is a LOT of competition in this area but I was really impressed with what LG could offer here. I think a network auditing solutions biggest weak point is usually the reporting interface, and just as with the other areas of LG, the reporting is pristine. Not only can you perform on the spot audits, but you can also check for things such as illegal software installations by running comparisons against baseline audits.

 

 

Pricing

 

GFI has released a full-featured FREE version of LANguard to be used for up to 5 IPs. After that, pricing is done on a per-IP basis with prices starting from around $32USD per IP for a 10-24 IP block.

 

Conclusion

 

I’ve always thought GFI was a great company with some really great products and LANguard 9.0 only helps to reinforce this opinion. I will continue to use the product alongside Nessus for my security scanning needs and would fully recommend it for network management and auditing.

 

You can check out LANguard and other GFI products at http://www.gfi.com.

Derek Melber wrote a great little article about the top ten security settings to make directly after installing Active Directory. I’d recommend all of these. Our server guys here actually have a very similar procedure they follow when creating a new network.

Read the full article here.

Unfortunately, sniffing packets isn’t always as easy as plugging into an open port and firing up Wireshark. In fact, it is sometimes more difficult to place a packet sniffer on a network’s cabling system than it is to actually analyze the packets. In the grand ole days of packet analysis when everybody used hubs you could plug in and sniff all of the traffic on a network segment. As most of you know now however, the advent of switched networks prevents this. When you plug a sniffer in to a port on a switch, you can only see broadcast traffic and the traffic transmitted and received by your machine. Because of that we have had to come up with a few alternative techniques to getting the traffic we need.

The three most popular techniques for doing this are port mirroring, hubbing out, and ARP cache poisoning. The goal of this article is to give a brief overview of port mirroring and hubbing out, which are very commonly used, and then to give a detailed explanation of ARP cache poisoning, the least well known of the trio.

The Common Techniques

Port Mirroring is probably one of the easiest ways to capture the traffic you are looking for. Also called port spanning, this is a feature available on most managed network switches. This is configurable by accessing the command line or GUI management for the switch the target and sniffer systems are plugged in to and entering commands which mirror the traffic of one port to another. For instance, to capture the traffic of a device plugged in to port 3 on a switch, you could plug your sniffer into port 6 and enter a vendor specific mirroring command that mirrors port 3 to port 6.

Hubbing out is a technique in which you localize the target device and your analyzer system on the same network segment by plugging them directly in to a hub. In order to do this, all you need is an old hub and a few network cables. Simply go to the switch that the target computer resides on and unplug it from the network. Plug the targets network cable, along with the cable for your sniffer, into the hub, and then plug the hub into the network switch. This will put your sniffer and the target machine on the same broadcast domain and allow you to see all of the packets going to and from the target machine, as well as yours. Since this does involve a brief moment of connectivity loss, I do highly recommend letting the user of the target system know that you will be briefly disrupting their connectivity, especially if it is someone in management!

Poisoning the ARP Cache

The ARP protocol was designed out of necessity to facilitate to translation of addresses between the second and third layers of the OSI model.  The second layer, or data-link layer, uses MAC addresses so that hardware devices can communicate to each other directly on a small scale. The third layer, or network layer, uses IP addresses (most commonly) to create large scalable networks that can communicate across the globe. The data link layer deals directly with devices connected together where as the network layer deals with devices that are directly connected AND indirectly connected. Each layer has its own addressing scheme, and they must work together in order to make network communications happen. For this very reason, ARP was created with RFC 826, “An Ethernet Address Resolution Protocol”. I’m not going to go into detail on the whole ARP process here, but I highly recommend reading my Packet School 201 write up on it here in order to better understand this process.

ARP cache poisoning is a more advanced form of tapping into the wire on a switched network. It is commonly used by hackers to send falsely addressed packets to client systems in order to intercept certain traffic or cause denial of service (DoS) attacks on a target, but ARP cache poisoning can still serve as a legitimate way to capture the packets of a target machine on a switched network.

ARP cache poisoning, sometimes referred to as ARP spoofing, is the process of sending ARP messages to an Ethernet switch or router with fake MAC (Layer 2) addresses in order to intercept the traffic of another computer.

 

Using Cain & Abel 

When attempting to poison the ARP cache, the first step is to download the required tools and collect some necessary information. We’ll use the popular security tool Cain & Abel from Oxid.it (http://www.oxid.it). The installation is pretty straight forward so I won’t go through that here.

Once you have installed the Cain & Abel software, you need to collect some additional information including the IP addresses of your analyzer system, the remote system you wish to capture the traffic from, and the router that the remote system is downstream from.

When you first open Cain & Abel, you will notice a series of tabs near the top of the window. (ARP cache poisoning is only one of a variety of Cain & Abel’s features.) For our purposes, we’ll be working in the Sniffer tab. When you click this tab, you will see an empty table. In order to fill this table you will need to activate the program’s built-in sniffer and scan your network for hosts.

Click the second icon on the toolbar, which resembles a network card. The first time you do this you will be asked to select the interface you wish to sniff. This interface should be the one that is connected to the network you will be performing your ARP cache poisoning on. Once you’ve selected this interface, click OK to activate Cain & Abel’s built-in sniffer. To build a list of available hosts on your network, click the icon that resembles a plus (+) symbol, and click OK.

The once-empty grid should now be filled with a list of all the hosts on your attached network, along with their MAC addresses, IP addresses, and vendor identifying information. This is the list you will work from when setting up your ARP cache poisoning.

At the bottom of the program window, you will see a set of tabs that will take you to other windows under the Sniffer heading. Now that you have built your host list, you will be working from the APR tab. Switch to the APR window by clicking the tab.

Once in the APR window, you are presented with two empty tables: an upper and a lower one. Once you set them up, the upper table will show the devices involved in your ARP cache poisoning, and the lower table will show all communication between your poisoned machines.

Continue setting up your ARP poisoning by clicking the icon resembling the plus (+) symbol on the program’s standard toolbar. The window that appears has two selection columns side by side. On the left side, you will see a list of all available hosts on your network. Click the IP address of the target computer whose traffic you wish to sniff. This will result in the right window showing a list of all hosts in the network, omitting the target machine’s IP address. In the right window, click the IP address of the router that is directly upstream of the target machine, and click OK.

The IP addresses of both devices should now be listed in the upper table in the main application window. To complete the process, click the yellow-and-black radiation symbol on the standard toolbar. This will activate Cain & Abel’s ARP cache poisoning features and allow your analyzing system to be the middleman for all communications between the target system and its upstream router.

You can now fire up your packet sniffer and begin the analysis process. When you are finished capturing traffic, simply click the yellow-and-black radiation symbol again to stop ARP cache poisoning.

A Final Note

As a final note on ARP cache poisoning, you should be very aware of the roles of the systems you implement this process for. For instance, do not use this technique when the target device is something with very high network utilization, such as a fileserver with a 1Gbps link to the network (especially if your analyzer system only provides a 100Mbps link). When you perform this rerouting of traffic, all traffic transmitted and received by the target system must first go through your analyzer system, therefore making your analyzer the bottleneck in the communication process. This can create a DoS-type effect on the machine you are analyzing, which will result in degraded network performance and faulty analysis data.

That is all there really is to ARP cache poisoning. This technique has always proved significantly useful in packet analysis experience and I hope it does in yours as well.

SPAM and Phishing are both really big problems for pretty much an organization right now, and it appears to only be getting worse. One of the most common tactics used by spammers is to forge legitimate domain names in the e-mails this send. The goal here is to trick a user in to opening of these messages, or at least to get them through a SPAM filtering service to a users inbox.

The best way to prevent your e-mail domain from being spoofed is through the use of Sender Policy Framework (SPF) Records. This is basically a DNS TXT record that mail servers and spam filtering services access to verify the source of e-mail messages as they arrive.

In order to create a SPF record, start by opening the DNS MMC snap-in. From here, browse to the forward lookup zone for this DNS server, right click in the blank area, choose Other New Records, and select Text (TXT). The typical value for this record (minus the quotes) should be “v=spf1 a mx -all”. What this says is that all mail that is received from an IP address listed that’s listed in the sending domains A or MX records is legitimate. This will suffice for most companies, but in the case that you want to get a little stricter with this, you can use an entry of “v=spf1 a mx ip4:192.168.1.2 -all”. This basically specifies 192.168.1.2 as the only IP address that valid mail can be sent from.

It is considered a good proactive security principle to configure an SPF record for your domain, regardless of whether you are having SPAM/Phishing problems or not.

One of the new features in Windows Server 2008 that is getting the most attention is the introduction of the Read-Only Domain Controller (RODC).

If you manage a network that utilizes more than one domain controller then you are aware of Active Directory’s multimaster replication structure. In this architecture, any change made to active directory on any domain controller is replicated to all of the others. This has made administration a breeze in the past since administrators could make a change at any remote site and it be reflected on all of the domain controllers in the network.

The problem here arises with the threat of a security breach. Managing network and physical security at remote office location has always been a challenge. If an intruder with malicious intentions gained access to an organizations domain controller at a branch office, he/she could easily destroy the whole active directory infrastructure throughout the ENTIRE organization.

Microsoft has addressed this issue with the development of an RODC. An RODC is designed for branch offices where the network conditions require a local source of authentication but a lack of physical security monitoring and localized administration makes placing a domain controller a security risk. The RODC only allows for one way replication. That means active directory information can be replicated to it from another domain controller, but it may not replicate information to any other domain controllers.

With an RODC deployed at a branch office, an individual with malicious intentions can not make modifications to the active directory infrastructure, therefor alleviating the security risks we have mentioned.

You can deploy an RODC by simply choosing the appropriate option when running the dcpromo utility during domain controller promotion.

Getting blacklisted is pretty much the worst thing that can happen as far as users are concerned. The typical result of your IP address getting blacklisted is that you can no longer send to anybody who subscribes to a spam filtering service. These services use databases such as the CBL to check whether or not an IP address is sending illegitimate e-mail.

Here are a couple of things you can do to prevent getting blacklisted:

1. Use virus protection on your server. I’d say 95% of the time when someone gets blacklisted it is because the e-mail server or a client within the network is sending out spam messages due to a compromise.
2. Block port 25 access from all machines except your e-mail server. By making this change in a firewall or router ACL, you can ensure that nobody is communicating through SMTP except your e-mail server.
3. Subscribe to a SPAM filtering service. Obviously, the less SPAM you receive means the less SPAM your users will be subject to. Even clicking on a link from one SPAM message can get a computer infected as part of a botnet that will cause you to get blacklisted. I personally recommend Appriver.
4. Filter inbound allowed servers. If you are using a SPAM filtering service that also queues inbound e-mail, make sure that your e-mail server is set to only receive incoming mail from the remote filtering servers.
5. Make sure that your e-mail server presents itself as valid. A lot of the time remote systems will perform checks on your server to make sure it is valid. The best way to make sure these checks come back to the remote system as they would like to see them is to set a masquerade domain to your domain name (i.e. domain.com) and make sure your ISP has your reverse DNS entry set correctly. You can work with them to make sure it is set to what it is supposed to be.
6. Make sure you are not set as an open relay. If you are, then anybody can relay mail through your server and cause you to get blacklisted. You can test this here.

Doing all of these things SHOULD keep you from getting blacklisted. If you do by chance happen to still get blacklisted then you should work with the organization that blacklisted you to get to the bottom of this. I have personally worked with the CBL on blacklisting issues several times and they have some pretty dedicated people who will help you.