Part Two in a multi-part series on holistic, multi-disciplinary analysis and reversing.

The last post, “Mutex Analysis: The Canary in the Coal Mine,” started off showing to use mutexes to discover malware that is difficult to locate using more traditional methods and tools. We used a live compromised system for the example and the post came to a relatively abrupt end when it seemed that we stumbled onto a new/unknown type of malware – or at least one that does not seem to have any public exposure or analysis. This post is “part 2″ of our analysis.
 
Update 6/21/2011:
 
This post has been moved to the “Forensics and Reversing” section of the website. I apologize for the inconvenience. Read the full article here.
 

Part One in a multi-part series on holistic, multi-disciplinary analysis and reversing.

This post is based on a presentation I gave at the last Thotcon, but was really prompted by a case from a couple days ago. It’s an interesting example of how the same disciplined methodologies for finding malicious traffic on the network also applies to sophisticated situations on the host as well. We’ll examine those methodologies and logic on the host by examining a little app I wrote called LockPick, pictured  here and detailed later in this article. As we’ll see, mutex analysis is a VERY powerful way of analyzing systems during Incident Response. They can lead the direction of your analysis when other automated methods fail to do so.
 
Update 6/21/2011:
 
This post has been moved to the “Forensics and Reversing” section of the website. I apologize for the inconvenience. Read the full article here.
 

Within the past few days,  We’ve seen the emergence of a new zero-day attack that involves flash files embedded into word documents.   These have purportedly been used in an attempt to compromise machines belonging to government-affiliated persons, as detailed here:

http://krebsonsecurity.com/2011/04/new-adobe-flash-zero-day-being-exploited/

http://contagiodump.blogspot.com/2011/04/apr-8-cve-2011-0611-flash-player-zero.html

As detailed in previous posts,  NetWitness tries to stay away from “signature” based detection of these types of attacks, and instead look for indicators that point to something that is not the norm.

In this particular case, we took a sample of the zero-day attack, and ran it through a NextGen system that is configured with some of the malware detection parser technology that is part of our Spectrum Malware Analysis product.

Even with no prior knowledge of this attack, we are immediately alerted to the presence of an XOR encoded executable in the session:

Because the use of XOR to obfuscate executable content is common in the malware world, we’ve chosen to have this alert into our highest Risk Category.

Additionally,  our forensic fingerprinting parsers identify the content in this session as containing executable content, as well as flash content, which appears to be a Flash version 10 swf file, despite the “.doc” filename.

So in this case, even if we weren’t aware of the *specific* attacks, a NextGen user would have been notified of the attack because of the collection of “abnormal” network activities.

Since we’ve determined that this is an incident that warrants further investigation.  We can use the data-extract function to extract the word document for further analysis:

Which allows us access to the fully reconstructed doc for further analysis:

Who needs signatures, when you have NetWitness!   More to follow involving malware analysis of the extracted samples.

- Alex Cox, Principal Research Analyst

Introduction

In our first post in the forensics and reversing series, we examined why HTTP gzip content encoding is a larger and more serious problem than most people realize. We’ll use the end of the first post as a starting point for analysis in this post. It also serves as an example of something far more important. That is, the very heart of forensics – and something I’d propose is the very definition of forensics. I teach a network forensics and reversing class together with Mike Sconzo about once a month. This is a point I raise at least a dozen times a day in class. That is:

World class forensics engineers are the ones who quickly and intelligently reduce millions of sessions to about a dozen worthy of deeper analysis.

What constitutes quickly? I suppose it depends on the tool being used to perform the analysis, but I’d generalize by saying no more than a couple minutes and/or the same number of clicks. We’ll see this in a moment.

What constitutes intelligently? We can answer this question by looking at a host-based forensics analogy. Suppose you were given a hard disk of a compromised machine and you needed to find the malware. There could be millions of files on the computer, so where do you start? Most of the time, especially for most standard compromises, the following steps will work (this is an over-generalization, but one that works nonetheless):

1. Show only PE files (exe, dll, etc..). At this point you’ve probably gone from nearly a million to about 100,000.
2. Show only PE files outside the Program Files directory. Here you may go from about a hundred thousand files to tens of thousands.
3. Depending on the assumed time of compromise, show only those PE files modified or created in a specific range of days. At this point you should go from tens of thousands to less than 100.
4. Since malware tends to be smaller in size, show only those PE files less than 500k. At this point you should be looking at only a handful of files, and most of the time, the malware you’re looking for will be one of them.

In the above steps, you found malware NOT by looking for known traits of malware. You did it by examining general characteristics about file traits. In other words, by examining characteristics external to the file, not by searching for signatures or other characteristics internal to the file. Typically, each of those traits by themselves are completely uninteresting until they are combined with other “uninteresting” traits, making them very interesting when layered together.

As you’ll see next, the same applies to network traffic. We can intelligently go from millions of sessions to only a few by wisely layering traits of network sessions with little attention paid to what is inside those sessions.

Read the full and detailed post here:
http://www.networkforensics.com/forensics-and-reverse-engineering-series/

Gary Golomb

Brian Krebs posted an article on his blog this morning that documents a recent spam attack on U.S. government employees that occurred around christmas time.

http://krebsonsecurity.com/2011/01/white-house-ecard-dupes-dot-gov-geeks/

which has in-depth technical coverage at:

http://contagiodump.blogspot.com/2011/01/general-file-information-file-card.html

Using a very simple ruse of “Merry Christmas from the White House”, this message used the common “ecard” social engineering hook to push a ZeuS trojan variant to the unlucky recipient.

From a configuration standpoint, this ZeuS bot used the following command and control points, all of which are down as of this writing:

Configuration Files:

http://patmarclean.us/flash/resny.bin

http://rogersvillechamber.us/components/tmpny.bin

http://ingunnanvik.no/templates/system/sysny.bin

http://argentum.lv/modules/rssny.bin

Binary Updates:

http://ingunnanvik.no/templates/system/botny.exe

Information Drops:

http://209.172.60.242/~newdowni/stat/gate_in.php

http://someonesome.mobi/imgs_ctn/icon_sml/gate_in.php

http://shock-world.mobi/zs/tmp/gate.php

It was poised to collect credentials from most major banks, but also includes site such as ebay, myspace, and microsoft, as well as online-payment processors, paypal and e-gold.

While these facts alone show similarities to infrastructure aspects of the “kneber” compromise that we documented back in February 2010, a very specific tie-in makes us believe that this attack was driven by operators that were also a part of the initial “kneber” compromise.

One domain in the original kneber data, “updatekernel.com” was tied specifically to a phishing email that used a spoofed address to push ZeuS to targeted government-employees, which Brian details here:

http://krebsonsecurity.com/2010/02/zeus–attack–spoofs–nsa–targets–gov–and–mil/

An interesting sidenote to this particular aspect of the kneber data was that the ZeuS bot that was involved with this phish had a second stage download of an executable called “stat.exe”. This malware was revealed to be a perl script converted to a stand-alone executable with the perl2exe tool.

This malware searched the local harddrive of the victim PC for xls,doc and pdf files, and uploaded them via FTP to:

packupdate.com

Which at the time, resided on a server in Belarus.

This current spam run, also downloaded a second-stage executable, called “pack.exe”, which was also:

- A perl2exe exectuable
- Searched the victim PC for all xls, doc and pdf files
- Uploaded stolen information to a server in Belarus, which resolved to “uploadpack.org”

So in this case, we have two executables, and three domain names, that have three converging elements, (pack, belarus and perl2exe)

When compared, these two files, separated by almost a year, are nearly identical in size:

Furthermore when analyzed with HBGary’s “fingerprint” tool, which looks for code similarities and “toolmarks”, a 95.8% match is indicated, with the only differing factors being the CPUID of the machine on which the malware was compiled:

This, because it is such a small and fairly unknown aspect of the kneber compromise, makes us think that this is indeed the same operator, who is again after documents pertaining to U.S. Government activities.

This evidence shows the continuing convergence of cyber-crime and cyber-espionage activites, and how they occassionally mirror or play off one another.

The question again, which we posed in our initial Kneber document, is:

Who is the end consumer of this information?

Alex Cox, Principal Research Analyst

Motivation

A large number of security researchers use Virtual Machines when analyzing malware and/or setting up both active and passive honeynets. There a numerous reasons for this, including: scalability, manageability, configuration and state snapshots, ability to run diverse operating systems, etc..

Malware that attempts to detect if it’s running in a Virtual Machine (then change its behavior accordingly to prevent analysis by security people) is not a subject of academic fancy. A recent search of VirusTotal showed they receive at least 1,000 unique samples a week with VM detection capabilities. (This search was performed by searching for known function import names from non-standard DLLs.) Personally, my first encounter with malware that behaved completely differently inside a Virtual Machine (from a real host) was approximately eight years ago.

VM detection does not apply just to the realm of APT-level malware. Agobot/Gaobot/PhatBot  is a family of massively deployed malware first released in 2004 with the ability to detect if running in either VMware or VirtualPC and changes its behavior accordingly. Considering just this example of how old and low-entry malware (with such a massive deployment) performs these actions, our attention to this subject should be especially keen.

Notes

1 – This post contains a number of techniques for VM detection used by malware, along with code demonstrating how simple these techniques are to implement. Except where noted, all techniques are currently used in the wild.

2 – Most of this post (but not all) is a summary of other people’s work, not mine – except where noted. References are given and should be accurate. If not, email me and I’ll correct.

3 – Examples where simple code samples could not be produced will not be considered here.

Only techniques that are difficult to mitigate are examined here. I’m sure there are hundreds of other ways to detect VM’s. Of the methods I’m familiar with, these were the ones that stood out in my mind as being difficult to fight.

Types of Virtual Machines

Generally speaking, there are three types of Virtual Machines. They are:

1 – Hardware Assisted – aka: Hypervisors – These VM’s use processor-specific instructions to cause the Host OS to [in effect] “fork,” where the original copy of the OS stays in a suspended state while the newly spawned “Guest copy” continues to run as if nothing happened. The important thing to keep in mind relative to this topic is that when the Guest executes machine level instructions, the actual hardware CPU is used to execute those instructions.

2 – Reduced Privilege – These are the VM’s most people are familiar with and use regularly. Here, the Host takes more of an active “proxy” role for the Guest by virtualizing important data structures and registers, then performing some level of translation services for some machine level instructions. Relative to this topic, the important thing to note here is that the guest – in effect – runs at a lower privilege than if it was truly controlling the CPU.

3 – Pure Software – Software VM’s act as full proxies to the CPU by implementing a truly virtual CPU the Guest interacts with.

Hypervisors (Hardware Assisted VMs)

Xen > 3.x and Virtual Server 2005 are a couple examples of Hardware assisted virtual machines.

Low-level detection of being virtualized in one of these environments is extremely difficult. Many people still call it impossible. While several people have talked publically about proof of concept code developed to detect these environments for years, none has been released or found in wild (that I’m aware of). Because of this, I will not talk about hypervisors any further than describing why detection is so difficult. (Since we have no code to examine how simple it is – the point of this post.)

A Hypervisor “guest” can be launched at any point after the OS has loaded. In preparation for launching a guest copy of the OS, the “host” sets up some basic CPU-specific control structures, then uses a single instruction (opcode) to cause the CPU to place the Host OS in a virtualized state while the Guest is basically a “forked copy” of the originally running OS. Once a Hypervisor has started running, the Guest OS basically has zero knowledge of this fact since all access to hardware is direct access. While the access to hardware is direct, the Hypervisor VM itself still has the ability to intercept interesting events – even before the Host OS has seen them. In this effect, a hypervisor VM is more powerful than both the Host and Guest OS’s because it sees everything before either of them.  Also, once a hypervisor is running, no others can become active. The first hypervisor VM has absolute control.

All methods for detecting the presence of Hypervisors depend on timing functions, however they are only useful techniques in theory because of the infeasibility of creating a good baseline to compare timing results to in order to make a pass/fail decision. Another technique uses context switching to cause Translation Lookaside Buffers filled with a predetermined pattern of data to get flushed when a hypervisor is running. Describing the technique is far beyond the scope of this paper since there is no exploit code to examine, but… Based on my understanding of the following article, I’m not sure the technique is so relevant anymore anyways. http://download.intel.com/technology/itj/2006/v10i3/v10-i3-art01.pdf

VMware

The non-ESX versions of VMware are reduced privilege VMs, and because of that are trivial to detect. Because critical data structures setup by the Operating System in critical regions of memory during OS start-up are already in use by the Host OS, VMware must relocate virtual copies of them for use by the Guest OS. This fact alone presents several powerful opportunities to detect when running inside a VMware image.

The first example simply checks the base address of the Interrupt Descriptor Table, as shown below. If then IDT is at a location much higher than its normal location, the process is likely inside a VM. This technique is generally attributed to Joanna Rutkowska , and is described here.

Code:

  In the above example, line #6 is the single line of assembly it takes to get the base address of the IDT, which is then tested a couple lines below that. SIDT is an instruction that stores the contents of the interrupt descriptor table register (IDTR) in the destination operand. It’s important to note this instruction is an unprivileged instruction that can be executed at any privilege level. However, according to the paper, “Detecting the Presence of Virtual Machines Using the Local Data Table,” verifying the IDT on multi-processor systems will fail when there is an IDT for each microprocessor. If that detection technique wasn’t simple enough, the next one is. VMware builds the Local Descriptor Table in memory, however Windows does not. Therefore, simply checking for a non-zero address for the LDT when running in Windows is enough to identify VMware.

On line #6, SLDT is the assembly instruction to store the segment selector from the local descriptor table register (LDTR) in the destination operand. It’s important to note this instruction is also an unprivileged instruction that can be executed at any privilege level!

Another interesting feature of VMware is seen when executing the IN instruction from user-land of common OSs like Linux, Windows, etc (and more accurately, when executing this instruction in ring3). IN is the “Input from Port” instruction. It copies the value from the I/O port specified with the source operand to the destination operand.  The IN instruction is a privileged instruction which cannot be run from ring3 (user-land), therefore when executed, an exception should be thrown. However, when VMware is running, no exception is generated if a special input port is specified. That port is “0×5658,” aka: “VX.” This technique is described in much more detail in the original posting here.

Example code is below, with comments added to explain each step.

Some people writing for SANS have said that disabling certain configuration option in VMware will defeat this type of detection mechanism. Unfortunately, the real IN instruction would never change any register other than EAX in the first place, so all the other register changes that take place when executing the instruction in VMware are still detectable. Other counter-measures have been proposed, however they are too unstable and unusable in the real world for us to consider here.

VirtualPC

  VirtualPC is also a reduced privilege VM, like non-ESX versions of VMware, and is just as trivial to detect. The IDT and LDT table structures tests described in the VMware section apply to VirtualPC as-is. In fact, those tests apply to all the big-name VMs that people are most familiar with in the Reduced Privilege category of VMs. VirtualPC has functionality similar to VMware’s use of the IN instruction, however it uses illegal instructions to trigger exceptions the kernel will catch. For example, issuing the following machine code would normally cause an exception because it’s an undefined opcode: 0F 3F 0A 00 But, with VirtualPC running, no exception is generated because this is part of VirtualPC’s guest to host communication protocol. Therefore, the code in the VMware example can simply be modified to issue this opcode, then test for a lack of exception. A more interesting feature of VirtualPC is its use of “buffered code emulation.” Buffered code emulation is the practice of copying an instruction from a Guest into a host-controlled buffer and executing it there, then returning the results to the Guest. As VirtualPC is intercepting every instruction and deciding what to return back to the caller, it will sometimes alter or craft its own results – as it does with the CPUID instruction. Normal values retuned are “GenuineIntel” and “AuthenticAMD.” With VirtualPC, the result is “ConnectixCPU.” But, I like this example of VirtualPC detection best since it uses the high-level and easy to use language, C#. Consider the following:

The above example pulls the manufacturer name of the motherboard and tests if it’s “Microsoft Corporation.” If it is, then VirtualPC has just been detected.

Software VMs

Examples software VMs include Bochs, Hydra, QEMU, Atlantis, and Norman Sandbox, among many others. Because software VMs try to fully emulate hardware, there are too many techniques to detect them to list here. Because it would be nearly impossible to implement every instruction and match the quirks each instruction has on different families of processors, most of the tests for Software VM’s revolve around testing some of the more arcane instructions.

Sandboxes

I personally love sandboxes because of the sheer volume of work they automate and standardization of data they return. I can’t even imagine life before they existed anymore! However, we need to be realistic about the fact that most (but not all!) are trivial to detect, regardless of hardware platform. This doesn’t mean we should avoid them – it just means we need to ensure we’re compensating for that fact.

A technique I have not seen elsewhere and have used in my own “research” malware in the past is to check the DLLs that have been loaded into my program’s space. To use this technique, you must first create a “fingerprint” of the DLLs your program loads. This is easily accomplished with a couple lines of debug code after you have finished your program. The technique is easy and can be used even in high-level languages like C#. Consider the following:

bool checkName(string nameOfLoadedDLL) is a method that returns true if the dll mapped in the program’s process space is known to belong to the “fingerprint” of this program. If the dll mapped in is unknown to the program, then it returns false and the logic below is executed.

This simple function is enough to catch many sandboxes (again, not all of them), even if you’ve followed their best practices and rename their monitoring dll (typically injected into all new processes).  Other examples of sandbox detection include using the hook detection employed by numerous security programs to find malware (except in this case – used by malware to detect sandboxes), counting hooks, etc..

Unfortunately, in the case of sandboxes, malware doesn’t even need to go through all that trouble to defeat them. The only thing malware needs to do is ensure its persistence through a reboot, then wait for a reboot to take place. That alone is enough to defeat the analysis steps of most analysis!

Summary

In short, you have seen that while many people quibble over VM detection being as simple as looking for registry keys and mac addresses (all easily mitigated from a security perspective), VM detection is actually:

1. Much easier than programmatically dealing with the registry
2. Much harder [nearly impossible] to mitigate when behavior of hardware is the target of testing
3. Happens on a massive scale in malware in the wild

While the use of Virtual Machines has many advantages for research purposes, their selection and limitations should be carefully weighed against your actual objectives.

Gary Golomb

Update 11/29/10: Added a short discussion about non-malware executables also.

Have you ever wondered how people writing reports about malware can say where the malware was likely developed?

Sometimes you get totally lucky and log files created by the malware will help answer the question. Given the following line from a log:

11/16/2009 6:41:48 PM –>  Hook instalate lsass.exe

We can use Google Translate’s “language detect” feature to help up determine the language used (click to enlarge):

Of course, it’s not often we get THAT lucky!

A more interesting method is the examination of certain structures known as the Resource Directory within the executable file itself. For the purpose of this post, I will not be describing the Resource Directory structure. It’s a complicated beast, making it a topic I will save for later posts that actually warrant and/or require a low-level understanding of it. Suffice it to say, the Resource Directory is where embedded resources like bitmaps (used in GUI graphics), file icons, etc. are stored. The structure is frequently compared to the layout of files on a file system, although I think it’s insulting to file systems to say such a thing. For those more graphically inclined, I took the following image from http://www.devsource.com/images/stories/PEFigure2.jpg. (Click to enlarge.)

For the sake of example, here’s some images showing you just a few of the resources embedded inside of notepad.exe: (using CFF Explorer from: http://www.ntcore.com/exsuite.php)

Now it’s important to note that an executable may have only a few or even zero resources – especially in the case of malware. Consider the following example showing a recent piece of malware with only a single resource called “BINARY.” (Click to enlarge.)

Moving on, let’s look at another piece of malware… Below, we see this piece of malware has five resource directories.

We could pick any of the five for this analysis, but I’ll pick RCData – mostly because it’s typically an interesting directory to examine when reverse engineering malware. (This is because RCData defines a raw data resource for an application. Raw data resources permit the inclusion of any binary data directly in the executable file.) Under RCData, we see three separate entries:

The first one to catch my eye is the one called IE_PLUGIN. I’ll show a screenshot of it below, but am saving the subject of executables embedded within executables for a MUCH more technical post in the near future (when it’s not 1:30 am and I actually feel like writing more!). (Click to enlarge.)

Going back to the entry structure itself, the IE_PLUGIN entry will have at least one Directory Entry underneath it to describe the size(s) and offset(s) to the data contained within that resource. I have expanded it as shown next:

And that’s where things get interesting – as it relates to answering the question at the start of this post anyways. Notice the ID: 1055. That’s our money shot for helping to determine what country this binary was compiled in. Or, more specifically, the default locale codepage of the computer used to compile this binary. Those ID’s have very legitimate uses, for example, you can have the same dialog in English, French and German localized forms. The system will choose the dialog to load based on the thread’s locale. However, when resources are added to the binary without explicitly setting them to different locale IDs, those resources will be assigned the default locale ID of the compiler’s computer.

So in the example above, what does 1055 mean?

It means this piece of malware likely was developed (or at least compiled in) Turkey.

How do we know that one resource wasn’t added with a custom ID? Because we see the same ID when looking at almost all the other resources in the file (anything with an ID of zero just means “use the default locale”):

In this case, we are also lucky enough to have other strings in the binary (once unpacked) to help solidify the assertion this binary is from Turkey. One such string is “Aktif Pencere,” which Google’s Translation detection engine shows as: (Click to enlarge.)

However, as you can see, this technique is very useful even when no strings are present – in logs or the binary itself.

So is this how the default binary locale identification works normally (eg: non-malware executable files)?

Not exactly. The above techniques are generally used with malware (if the malware even has exposed resources), but not generally with normal/legitimate binaries. Consider the following legitimate binary. What is the source locale for the following example?

As you see in the green box, we have some cursor resources with the ID for the United States. (I’m including a lookup table at the bottom of this post.) In the orange box, there are additional cursor resources with the ID for Germany. In the red box is RCData, like we examined before, but all of these resources have the ID specifying the default language of the computer executing the application.

As it turns out, the normal value to examine is the ID for the Version Information Table resource (in the blue box). In the case above, it’s the Czech Republic. The Version Information Table contains the “metadata” you normally see depicted in locations like this:

In the above screenshot, Windows is identifying the source/target local as English, and specifically, United States English (as opposed to UK English, Australian English, etc…). That information is not stored within the Version Information table, but rather is determined by the ID of the Version Information Table.

However, in malware, the Version Information table is almost always stripped or mangled, as is the case with our original example from earlier:

Because of that, the earlier techniques are more applicable to malware.

Below, I’m including a table to help you translate Resource Entry IDs to locales (sorted by decimal ID number).

-Gary Golomb

Gary Golomb

.

Recent reports from various sources in the security industry show that a large takedown of servers associated with the “Bredolab” trojan occurred within the past few weeks. While most of the reports have focused around the idea that this infrastructure was solely related to the command and control of Bredolab, our research shows that these servers were used as an all-purpose hosting infrastructure for criminal activity.

This criminal system came to our attention in July 2010, when NetWitness analysts were asked to investigate a hacked wordpress blog.

We found that the following obfuscated script had been injected into all .html and php pages on the site:

When decoded, this script created a redirect to the following location:

hxxp://bakedonlion.ru:8080/google.com/pcpop.com/torrentdownloads.net.php

Further investigation revealed an injection of the script into victim webpages via FTP:

These IPs all connected to the victim website within a 20-minute period on May 8^th, and when plotted on a map, it becomes obvious that this is likely a botnet.

Read the rest…

Early this year, we were challenged by our CEO Amit Yoran to take this perpetual battle against Malware to the next level.  Easily, one of the most common use cases today of NetWitness Nextgen, is the combating of various forms of commercial and custom malicious code.  The goal of helping our customers optimize their efforts in this regard seemed like a natural progression.  It seemed like every day customers or NetWitness analysts were finding yet another zero day, or yet another piece of custom code, or yet another group of professional thieves.  We are very fortunate to have so many experts on staff, as well as customers, who regularly use our solution to sift through terabytes of network data to identify threats from malware.

The first step was to interview these experts, and ask them how we could ease this effort.  We also asked them to quantify and explain their magic sauce.  Surprisingly, explaining how they go about their day-to-day efforts was very easy for most of them. However, when we asked what our system should do to help – nearly every one of them found it hard to come up with any specific requirements.  Inevitably, they would defer and simply say, “Well – do some of that stuff I just told you.  That’s a start.”

Tell us the same thing enough times, and we will eventually listen.  What if we automated all their steps during investigations? What if we could ask all the questions they ask?  What if all the information needed to highlight what was bad, was analyzed for them?  It slowly dawned on us, that their “secret sauce” was the answer.  We did not need to invent a new paradigm.  We needed to make their paradigms work and scale. They were telling us what they wanted done for them, by describing all the laborious steps they took to get there manually.  They were telling us what tools, services, and intelligence they liked to use.  They were telling us the combinations of indicators that really peaked their interest.  And we had a very distinct advantage.  They were telling us all this, by showing us in NetWitness what they look for.  We already had collected the majority of the information we needed.  We just needed to ask the right questions.

Today at the 2nd annual NetWitness user conference, we introduced NetWitness Spectrum.  We are in the process of taking requests for early access any NetWitness customer. Spectrum is an expert automated analytics engine that provides extraction and prioritization of executable content within an enterprise.  Spectrum is your virtual Malware expert, sifting through thousands of executables and doing the laborious legwork to prioritize malicious content, all on a continual, real-time, port and protocol independent basis.

Over the next few weeks, we will be discussing more and more features and capabilities of Spectrum. We have a history here at NetWitness of thinking a little differently than the industry tells us to think. We prefer to innovate rather than copy, lead rather than follow.  This time however, our innovation is purely you, our user community.  We are following your lead.

For more information regarding Spectrum and the early access program, visit www.netwitness.com.

Tim Belcher, CTO

Knowledge of what’s really happening on your network is critical if you are responsible for the protection of your organization’s information assets.  Depending upon where you work and what you believe about both the capabilities of your security team and those of the adversary, you live somewhere on the spectrum of “really concerned about advanced threats” to feeling that “things are just about A-OK. ‘

NetWitness recently sponsored a study by the Ponemon Institute regarding the prevalence and awareness of advanced threats by security practitioners.  There have been many studies and reports over the last two years claiming that most successful data breaches result from “advanced threats” or “sophisticated attacks,” so we wanted to understand exactly what security people believed was happening in their organizations today and how they were coping with it.

A security blogger tweeted people to stay away from the study because it did not “hit the mark.”  Reason?  In a moment or two of weakness, the study used the revered term “advanced persistent threat (APT)” versus “advanced threat.”  Unfortunately, many security practitioners today cannot precisely define the difference.  Use of terminology within the study should not reduce the utility of the paper, however, especially if the end result of either advanced threat vector contains tangible risk to the corporation or government agency that might be mitigated through a better understanding of the network traffic.  Security people and vendors will get the terminology right at some point.

The other issue raised regarding the study concerned the number of respondents who would include terms such as “SQL Injection” in their definition of an advanced threat (“What other terms are used to describe an advanced threat?”).  Actually, the blogger missed the point of this question – the point was not to claim each response actually was an advanced threat, but to illustrate the relationship between common problems that security practitioners believe to be advanced in nature, and those that are simply evading their detection or mitigation capabilities.  Other questions in the study go down this path of lack of awareness.

Compared to other risk-based industries, the security industry is bereft of adequate pan-industry historical data, meaningful metrics, and comparative information.  Although imperfect as a first survey instrument, rather than ignore professional surveys such as the Ponemon Institute study, it should be used by security practitioners in an appropriate context:

1.  Prepare a non-FUD-based discussion for senior management regarding the characteristics of the current state of the threat environment.

2.  Bring forward studies from reputable national/international-level firms that illustrate the costs of data breaches, the sources and methods of these threat vectors, and now with Ponemon data, the opinions of 600 fellow security practitioners regarding the technical and administrative readiness of peer organizations to cope with the threats they are facing.

3.  Develop real evidence of what’s really happening in your world using your own corporate data.  For example, conduct a proof of concept of NetWitness and get definitive answers to some of the nagging questions you may have about advanced threat prevalence or insider threat concerns within your own I/T environment.

4.  Present a people, process and technology plan for reducing the uncertainty around advanced threats (and even APTs depending upon where you work).