Skip navigation
All Places > Products > RSA NetWitness Platform > Blog > 2012 > August

RSA NetWitness Platform

August 2012 Previous month Next month

If you stay up to date on the latest trends in the security industry, you may have already known for a number of years that Antivirus technology hasn't fared well against cutting edge threats.  This is because of the necessity for a signature to be created in order for anyone to detect anything, whereas technologies like RSA NetWitness thrive on not needing a specific signature to exist in order to find abnormal or malicious activity.


F-Secure's Chief Research Officer, Mikko Hypponen recently wrote in a Wired article how the Antivrius industry failed with Flame, Stuxnet, and Duqu malware.  It took over 2 years for Flame to be properly discovered and identified, and it took over a year for both Stuxnet and Duqu.  With the speed at which modern attacks can be formulated and delivered, response times are expected to be closer to minutes or hours, not days, weeks, or years.


Traditional Antivirus methodology has been, in my opinion, rendered obsolete as a way to identify cutting edge edge threats until long after the detection would provide any meaningful value.  Risk based technologies however, provide a much better chance at detecting new threats by identifying activity that doesn't fall under baselines and does not require specific signatures that can only be obtained once a sample is analyzed.


I've often heard colleagues say that in the best way to find the needle in the haystack is to remove the hay.  Antivirus attempts to identify the needle with no context as to what kind of hay it might be living in.  Remove the hay and all the needles immediately become apparent.  This is an important evolution in an ever more complex networked world with a need for faster and faster response times as the so called "arms race" between malicious attackers and us defenders becomes larger.


This isn't to say that antivirus technology is completely useless.  It just should no longer be viewed as a primary defense system.  Used in conjunction with other technologies there are effective ways to manage current deployments without having to re-architect an entire company's IT solution.  Technologies come and go, evolve and are replaced, and this is a perfect time to put a plan in place to do just that instead of ignoring the changing landscape.

RSA Security Analytics is a game changer - why?  RSA Security Analytics at a high level defines a new security product category. It's the new name of our platform that's powered by NetWitness and combines network security monitoring, SIEM, and Big Data Management & Analytics. 


But first, we're excited to introduce the new Security Analytics interface.  It's awesome with a fresh look and feel.  The new GUI unifies all your analytics within a single interface.  Your investigative and analytical workflows will all be integrated by this platform independent, browser-based GUI. 


This new GUI will first launch as a beta with three analytic modules:  Investigation, Live and Administration.


Check out this sneak peek below:


1. The Unified Dashboard - has customizable dashlets that allow for quick investigative actions.  The Quick Tasks provide immediate access to popular features with a single click.  HTML 5 provides quick response to user input.  It's clean and simple.



2.  The Investigation module - we've put proven analytics functionality (Investigator) into an O/S independent browser.  So now, you have seamless integration between analysis views and Live context.  In addition, we introduce a new feature called Meta Groups where you can easily separate and organize investigative focus by use case.


3.  The Live module - centralizes threat intelligence and content acquisition so you can continue to centrally manage your distribution of content. 



4.  The Administration module - manage your environment by grouping devices for administration or data access.  Upgrade multiple devices at the same time.  New drag and drop capability for adding metrics and timeline charts into historical statistical information.


This is just a summary and we look forward to you navigating Security Analytics yourself and providing feedback!  

RSA Admin

Welcome Back, Rustock.

Posted by RSA Admin Employee Aug 22, 2012



It seems that our holiday from rustock-generated spam is over.


We monitor a number of botnets at NetWitness and check them occasionally for new information.  Since Rustock is in the news, we’ve paid close attention to it recently.   Sometime this morning, Rustock begain spamming again,  pushing viagra from shady .ru sites.


Looking at the traffic in Investigator,  I see a quick overview of subject lines:


And reconstructed, we see a very in-depth message of “CLICK HERE!”


Which of course takes us to Canadian Pharmacy!


Welcome back Rustock…We can’t say we’ve missed you.   There is no telling if this will be continued activity, but appears to be business as usual for the Rustock operators.



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.


which has in-depth technical coverage at:


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:








Binary Updates:






Information Drops:







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, “” was tied specifically to a phishing email that used a spoofed address to push ZeuS to targeted government-employees, which Brian details here:–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:


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 “”


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





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.




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.




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.




  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 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.




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!




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



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:


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 44697

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:




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.” 44693

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!). 44690

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: 44687

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).


Arabic – Saudi Arabiaarar-sa10251256
Chinese – Taiwanzhzh-tw1028
German – Germanydede-de10311252
English – United Statesenen-us10331252
Spanish – Spain (Traditional)eses-es10341252
French – Francefrfr-fr10361252
Italian – Italyitit-it10401252
Dutch – Netherlandsnlnl-nl10431252
Norwegian – Bokmlnbno-no10441252
Portuguese – Brazilptpt-br10461252
Romanian – Romaniaroro10481250
Swedish – Swedensvsv-se10531252
Farsi – Persianfafa10651256
Azeri – Latinazaz-az10681254
FYRO Macedoniamkmk10711251
Sesotho (Sutu)1072
Sami Lappish1083
Gaelic – Scotlandgdgd1084
Malay – Malaysiamsms-my10861252
Kyrgyz – Cyrillic10881251
Uzbek – Latinuzuz-uz10911254
Bengali – Indiabnbn1093
Sinhala; Sinhalesesisi1115
Frisian – Netherlands1122
Divehi; Dhivehi; Maldiviandvdv1125
Igbo – Nigeria1136
Guarani – Paraguaygngn1140
HID (Human Interface Device)1279
Arabic – Iraqarar-iq20491256
Chinese – Chinazhzh-cn2052
German – Switzerlanddede-ch20551252
English – Great Britainenen-gb20571252
Spanish – Mexicoeses-mx20581252
French – Belgiumfrfr-be20601252
Italian – Switzerlanditit-ch20641252
Dutch – Belgiumnlnl-be20671252
Norwegian – Nynorsknnno-no20681252
Portuguese – Portugalptpt-pt20701252
Romanian – Moldovaroro-mo2072
Russian – Moldovaruru-mo2073
Serbian – Latinsrsr-sp20741250
Swedish – Finlandsvsv-fi20771252
Azeri – Cyrillicazaz-az20921251
Gaelic – Irelandgdgd-ie2108
Malay – Bruneimsms-bn21101252
Uzbek – Cyrillicuzuz-uz21151251
Bengali – Bangladeshbnbn2117
Arabic – Egyptarar-eg30731256
Chinese – Hong Kong SARzhzh-hk3076
German – Austriadede-at30791252
English – Australiaenen-au30811252
French – Canadafrfr-ca30841252
Serbian – Cyrillicsrsr-sp30981251
Arabic – Libyaarar-ly40971256
Chinese – Singaporezhzh-sg4100
German – Luxembourgdede-lu41031252
English – Canadaenen-ca41051252
Spanish – Guatemalaeses-gt41061252
French – Switzerlandfrfr-ch41081252
Arabic – Algeriaarar-dz51211256
Chinese – Macau SARzhzh-mo5124
German – Liechtensteindede-li51271252
English – New Zealandenen-nz51291252
Spanish – Costa Ricaeses-cr51301252
French – Luxembourgfrfr-lu51321252
Arabic – Moroccoarar-ma61451256
English – Irelandenen-ie61531252
Spanish – Panamaeses-pa61541252
French – Monacofr61561252
Arabic – Tunisiaarar-tn71691256
English – Southern Africaenen-za71771252
Spanish – Dominican Republiceses-do71781252
French – West Indiesfr7180
Arabic – Omanarar-om81931256
English – Jamaicaenen-jm82011252
Spanish – Venezuelaeses-ve82021252
Arabic – Yemenarar-ye92171256
English – Caribbeanenen-cb92251252
Spanish – Colombiaeses-co92261252
French – Congofr9228
Arabic – Syriaarar-sy102411256
English – Belizeenen-bz102491252
Spanish – Perueses-pe102501252
French – Senegalfr10252
Arabic – Jordanarar-jo112651256
English – Trinidadenen-tt112731252
Spanish – Argentinaeses-ar112741252
French – Cameroonfr11276
Arabic – Lebanonarar-lb122891256
English – Zimbabween122971252
Spanish – Ecuadoreses-ec122981252
French – Cote d’Ivoirefr12300
Arabic – Kuwaitarar-kw133131256
English – Phillippinesenen-ph133211252
Spanish – Chileeses-cl133221252
French – Malifr13324
Arabic – United Arab Emiratesarar-ae143371256
Spanish – Uruguayeses-uy143461252
French – Moroccofr14348
Arabic – Bahrainarar-bh153611256
Spanish – Paraguayeses-py153701252
Arabic – Qatararar-qa163851256
English – Indiaenen-in16393
Spanish – Boliviaeses-bo163941252
Spanish – El Salvadoreses-sv174181252
Spanish – Honduraseses-hn184421252
Spanish – Nicaraguaeses-ni194661252
Spanish – Puerto Ricoeses-pr204901252


Gary Golomb



Something I’ve found unsettling for some time now is the drastically increased usage of gzip as a Content-Encoding transfer type from web servers. By default now, Yahoo, Google, Facebook, Twitter, Wikipedia, and many other organizations compress the content they send to your users. From that list alone, you can infer that most of the HTTP traffic on any given network is not transferred in plaintext, but rather as compressed bytes.


That means web content you’d expect to look like this on the wire (making it easily searchable for policy violations and security threats):


In reality, looks like this:


As it turns out, the two screenshot above are for the exact same network session, the later screenshot being from wireshark and showing the data sent by the webserver really is compressed and not discernable.


By extension, you can likely say that most real-time network forensics/monitoring tools are [realistically] “blind” to [plausibly] a majority of the web the traffic flowing into your organization.


Combined with the fact that a vast majority of compromises are delivered to clients via HTTP (at this time, typically through the use of javascript), my use of the word “unsettling” should be an understatement. This includes everything from “APT” types of threats (or whatever soapbox you stand on to describe the same thing), down to drive-by’s and mass exploitations.


The good news: Current trends in exploitation have given us very powerful methods for generic detection (eg: without needing “signatures,” or more precisely – preexisting knowledge about the details of particular vulnerabilities or exploits) by examining traits of javascript, iframes, html, pdf’s, etc.


The bad news: Webservers are reducing the chance of network technologies from detecting those conditions by compression based transfer (obfuscation).


I find no fault with organizations choosing to use gzip as their transfer type. HTTP is a horribly repetitive and redundant language (read: bloated). Every opening <tag> has an identical closing </tag>. XML is even worse. For massive sites with massive traffic, the redundancy and bloat of protocols like HTTP and XML translate directly to lost revenue via extremely large amounts of wasted bandwidth.


Nonetheless, as forensic engineers, our challenge is to discover and compensate for all the things proactive security technologies like AV, firewalls, IPS, etc. continually fail to identify and stop. Recently, I added the following rule on a customer’s network in NetWitness:


If you’re not familiar with the NetWitness rule syntax, the rule above does the following:


If the server application/version (as extracted by the protocol parsing engine) contains the string: “nginx,”




If the Content-Encoding used by the server is gzip




Create a tag labeled “http_gzip_from_nginx” in a key called “monitors.”


In the Investigator GUI, you would see something like this in the “monitors” key:


Why nginx? As it turns out, a lot of hackers tend to use nginx webservers, so this seemed like a good place to start experimenting. The question I was trying to answer is:


If the content body of a web response is gzip’ed (so we can’t examine traits of “suspiciousness” inside the body), then what can we see outside the body to indicate this gzip’ed traffic is worth examining further?


We’ll revisit this question in later blog posts, but for now, nginx as a webserver is an amazingly powerful place to start! We’ll examine one such example in this post, with an additional post using the gzip + nginx combination. As the small screenshot above shows, there were 33 sessions meeting the criteria of gzip + nginx (out of about 50,000 sessions). With only 33 sessions, it’s possible to examine them by drilling into the packets of all 33, examining them each one-by-one (eg: brute-force forensic examination), but that would be poor forensic technique and defeat the entire point of a technical and educational network forensics blog! The examples in these series of blog posts will employ good forensic practices using “correlative techniques,” allowing us to have a good idea of what is inside the packet contents before we ever drill that deeply into the network data (an indication you are using good network forensics practices).


The first pivot point we’ll examine are countries. Keep in mind, this is after we used the rule above to include only network sessions where the server returned gzip compressed content, and where the webserver was some type of nginx. We could have manually done the same by first pivoting on the content type of gzip:


Doing the first pivot reduces the number of sessions we’re examining from about 50,000 down to 2,878. Then we can do a custom filter to only include servers with the string “nginx” within those 2,878 session. Doing so gives us the same 33 sessions mentioned above.


In those 33 sessions, the countries communicated with are:


Not only do we tend to see a higher degree of malicious traffic from countries like Latvia, it immediately looks suspicious simply because it’s an outlier in the list. (Don’t worry Latvia, we’ll pick on our own country in the next post!) Additionally, there’s only a single session to examine here, meaning drilling into the packet-level detail is an ok decision at this point.


In the request, we see the client requested the file “/th/inyrktgsxtfwylf.php” from the host “,” as shown next:


As expected, based on the meta information NetWitness already extracted, we see the gzip’ed reply from a nginx server:


Fortunately, Investigator makes it easy for us to examine gzip’ed content by right-clicking in the session display and selecting decode as compressed data:


Doing so shows us a MUCH different story!


The traffic appears to be obfuscated javascript. We can extract it from NetWitness (a few different ways) to clean it up and examine. I’ll skip those steps and just show the cleaned-up and nicely formatted content the webserver returned.


There are a few things to notice in here. At the very bottom of the image above, we clearly see encoded javascript, a trait extremely common to client-side exploit delivery and malicious webpages. We’ll save full javascript reverse engineering for another blog post.


But the worst (or most interesting) part is the decoding and evaluation for this encoded data, while implemented in javascript, is stored inside a TextArea HTML object! This technique makes the real logic invisible and indiscernible to most automated javascript reverse engineering tools.


Indeed, if we upload this webpage to one of my favorite js reversing sites (jsunpack, located at:, we see the following results when the site attempts to automatically reverse engineer the javascript:


Without going further into the process of reverse engineering the javascript (for now – we have an endless supply of blog posts coming!), we can be quite sure we’re looking at something suspicious. At the very least, we know for a fact we’re looking at something that does not make it easy to discern what it’s doing!


The telltale signs of “badness” don’t stop there. At the top of the decoded body data we saw an embedded java applet, as follows:


While we don’t know (yet) what the applet does, there’s a pretty strong indication it’s a downloader or C&C (command and control) application of some type. How can we make such a guess without knowing anything about it?


Look closely at the embedded parameter passed into the applet:


We can make a guess that the string contained in the “value” parameter is encoded data using a simple substitution cypher where “S”[parm] = “T”[actual] and “T”[parm] = “/”[actual]. If we made such a guess, then it’s possible the decoded parameter value actually starts with the string “http://”.


Of course, because we have the download of the jar file within our full packet capture and storage database, we’ll just extract it from NetWitness to validate our hunch and possibly learn more. In the below screenshot, I already performed the following steps:


  1. Switched to the session with the jar file download. (Simply clicked on the next session between that same client and server.)
  2. Extracted the jar file by saving the raw data from the server using the “Extract Payload Side 2” option in NetWitness.
  3. Opened the jar file using the following java decompiler:


The first line of code in the java applet takes the parameter passed to it (the encoded value we identified above), and hands it to a function called “b.” The result of that function is stored in a string variable called str1.


Following the decompiled java code to function “b,” we see the following:


It turns out the applet actually is using a simple substitution cypher, replacing one given character with another. When the parameter “RSS=,TT!;LBIB@STSRTYG$I=R=” is decoded, we end up with the string “”


The java malware then continues with additional string functions as shown next:


First, we see the declaration of str2 through str5, with values assigned to each.


Then, str6 through srt8 is simply the reversal of str2 through str4, resulting in the following strings:


Str6 = .exe


Str7 =


Str8 =


Combining that with the last three lines of code shown above, we see the following:


Str10 is a filename ending in “.exe” where the actual filename is a randomly generated number.


Str11 is the path to temporary files for the current user.


Str12 is the name of the Operating System the java malware is currently running on.


The last part of this java malware (that we’ll examine here anyways) is shown next:


First, it tests to see if the string “Windows” is contained anywhere in the name of the Operating System. If so, then it goes through the process of opening a connection to the URL (the one we decoded above), downloads the file, saves it to the temporary directory, then executes the file.


This file appears to be malware as a first-stage downloader for other executables that are likely far more malicious.



Even though a large amount of web traffic is coming into your organization gzip compressed, making most inline/real-time security products totally “blind” to what’s inside, we can use standard forensic principals to identify which of those sessions are worth examination. In this case, we combined to following traits to reduce 50,000 network sessions to a single one:


  1. Gzip’ed web content
  2. Suspicious country
  3. Uncommon webserver application


Once we drilled into that single session, we saw how trivial it was to use NetWitness to automatically decompress and content, extract it, then validate it as “bad.”




Does the process stop there? Of course not! If you had to repeat this process every time, not only would it make your job boring as heck, but would call into question the value you and your tools are really providing the organization in the first place! There are many ways to maximize the intelligence gained from the process just shown. I’ll highlight one method here, while saving others for later blog posts.


There are several interesting “indicators” gathered from this traffic so far. The ones I’ll focus on here are host names. In the request made by the client, we saw the following tag in the HTTP Request header:




In the java malware we decompiled, after decoding the encoded parameter value, we saw the executable to be downloaded was from the host “”


At this point, network rules should be added to firewalls, proxies, NetWitness intelligence feeds, and any other technology you have that can alert to other hosts going to either of those servers – preferably blocking all traffic to those servers.


But, can we extend our security perimeter in relation to the hackers using those servers?


Interestingly, we find both those domains are hosted on the same IP block: and


That leads to the question, “What other domains are hosted on those server?”


Normally I use to answer questions like that, but in this case, robtex does not provide a lot of information about that question. It’s possible the hackers are brining-up and tearing-down DNS records as needed for the domain names they manage.


Another source of helpful information can be found querying the “Passive DNS replication” database hosted at: Here, we can find an audit trail of all historically observed DNS replies pointing to IPs you submit queries about. In this case, we do indeed find valuable information, including about 40 unique host names that have been hosted on those two IP’s. A shortened list is included below showing some of the names that have been hosted there.


As we can see, none of them look immediately legitimate, so we can infer this is a hacking group using a set of servers for domains they have registered simply to be “thrown away” if any of those domain names are discovered and end up on a blacklist somewhere.


The Real Summary


By combining a few pivot points and looking inside compressed web traffic most products ignore, from a single network session we proactively increased the security posture of your organization by creating an intelligence feed of nearly 40 hosts names and 2 IP’s. You could now audit DNS queries made by all hosts in your organization to see if other clients are compromised and doing look-ups when trying to communicate with those hosts.


For the truly paranoid (or safe, depending on how you look at it), you could also blackhole all traffic to those apparently malicious networks:




origin: AS29557


Considering the Google Safe Browsing report for that AS, it’s probably not a bad idea!



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:




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 8th, and when plotted on a map, it becomes obvious that this is likely a botnet.



Down the Rabbit-hole


Once we established the source of the website compromise, we began back-tracking into the criminal infrastructure to help develop intelligence that would assist our customers.  What we found was the following:


The initial injected script:


redirects to obfuscated scripts:




which ultimately result in exploit code being delivered to the visiting browser.   If successful, the following GET occurs which causes the download of the bredolab malware.


Discovery of this infection sequence began a 3-month monitoring activity from June to August 2010.


More on Bredolab


Bredolab rose to prominence in the malware community around the middle of 2009.   Trend Micro has a very good report on the malware’s specifics.


In this particular instance, this Bredolab variant downloaded both Fake AV and ZeuS, which are two well-known malware threats.


1) Fake AV – Installs a fake antivirus program that reports non-existent infections on the host workstation.  The option to “clean” the host is given if the user agrees to pay a fee for the “pro” or “advanced” version of the software.  This particular combination of social engineering and malware has been very popular in the past few years as it has a three-part punch:


  1. The miscreant establishes a foothold on the compromised PC.
  2. The miscreant makes money from those users that pay the “upgrade” fee.
  3. The miscreant has access to the payment method of the user after he or she makes payment (credit card, paypal,etc), which can be used for further fraud.


2) ZeuS – An all-purpose information stealer that has historically been focused on financial fraud.   Because online hosts often have the ability to use a web-based client to remotely manage files and folder on a host, this may likely be one of the sources for the stolen FTP credentials used in script injection. 


Although not part of the campaign detailed here, Bredolab has been observed downloading other malware families, which provided evidence that the operator used the system in pay-per-install affiliate programs or provided install services to other miscreants.


Further into the infrastructure


Shortly after our initial investigation began, open source research in the security community into common paths on the miscreant servers revealed active Apache Server Status pages, a feature in the Apache webserver that allows you to monitor performance of your installation.  This finding allowed us to log and further develop intelligence based on the page visits that we observed on the miscreant servers.


With this bit of information, we were able to take the previously known infection sequence, and expand it:


1) The initial directory sequence observed in the original injected script:




was only one of many variations, some of which are as follows:


  • GET / HTTP/1.0
  • GET / HTTP/1.0
  • GET /dangdang-com/ HTTP/1.0
  • GET /elpais-com/ HTTP/1.0
  • GET /focus-cn/ HTTP/1.0
  • GET /verizonwireless-com/ HTTP/1.0
  • GET /vmn-net/ HTTP/1.0


We surmised that this seemingly random combination of high-traffic sites served two purposes: 


  • Establish “legitimacy” during casual inspection.
  • Make the creation of intrusion detection signatures on this particular phase difficult.


2) Specific paths to exploit artifacts, which included: 


  • GET /Notes1.pdf HTTP/1.0
  • GET /Notes2.pdf HTTP/1.0
  • GET /Notes3.pdf HTTP/1.0
  • GET /Notes4.pdf HTTP/1.0
  • GET /Notes5.pdf HTTP/1.0
  • GET /Notes6.pdf HTTP/1.0
  • GET /Notes7.pdf HTTP/1.0
  • GET /Notes8.pdf HTTP/1.0
  • GET /Notes9.pdf HTTP/1.0
  • GET /Notes10.pdf HTTP/1.0
  • GET /NewGames.jar HTTP/1.0
  • GET /Games.jar HTTP/1.0
  • GET /Applet1.html HTTP/1.0
  • GET /Applet4.html HTTP/1.0
  • GET /Applet10.html HTTP/1.0


3)   Additional Malware Downloads: 


  • GET /images/gr_old_cr.exe HTTP/1.0


Examining Exploits


By taking a closer look at one of the exploits used in this particular campaign during the observed time period, we saw a common theme that is being used by most criminal elements in the current threat environment.


  • Client-side vulnerabilities in third-party software


Criminal elements have learned that organizations typically have OS-level patching under control, but the patching of third-party applications is often outside of the capabilities of most organizations.  This is usually due to both the complication of centralizing third-party patching, but more so because of the linking of commodity technologies, such as PDF readers, into mission-critical business processes that may be interrupted by upgraded versions and require lengthy testing prior to extensive deployment. 


In this case, we see the following exploits being used in the exploit PDFs:



Which, when successful, calls out to the previously observed urls:


While we did see multiple versions of this pdf file (1-10), they were all structurally identical, with slight changes to change the file enough to bypass antivirus detection.


A change of tactics


On or around June 11th, we observed a tactics change by the miscreants, based on the previously observed exploit-cycle. The previously seen requests, such as:


  • GET / HTTP/1.0


Stopped occurring, and we began seeing requests formatted as follows:


  • GET /E-mail.js HTTP/1.0
  • GET /Filename.js HTTP/1.0
  • GET /Gnutella.js HTTP/1.0


These requests were made to the same servers, but on port 80 (rather than the previously observed 8080).    While it wasn’t immediately apparent at the time, this change signified a significant shift from a single domain based compromise structure to a multi-domain system that assigned specific roles to domains according to their desired use. 


An Intelligence Breakthrough


At this point in the investigation, we began linking like servers together based on community reports and our own field work with indicators such as malware and exploit filenames.   Since they all had available server status pages, this again expanded our ability to collect intelligence on this system. A breakthrough occurred when we observed one of the exploit servers transferring a tgz archive from one of the other servers in the system via HTTP. With the proper path, we were then able to retrieve this file directly from the exploit server and further explore it. This archive contained a series of DNS zone configuration files that detailed the infrastructure with labels and allowed us completely map the system as it was updated.  We surmised that the configuration files were used by the criminal miscreants to update their exploit system in an automated fashion.  This would allow quick updates when security researcher activity caused a takedown of a suspect domain.  With this discovery, we began logging changes to the infrastructure on a daily basis.



Mapping the Infrastructure


With the zone information and other monitoring, we observed 114 IP addresses resolving to known malicious domains in this system.


1231262.27.51.163ECOTEL ecotel communication ag
1232288.191.47.83PROXAD Free SAS
1232288.191.79.158PROXAD Free SAS
1232288.191.79.223PROXAD Free SAS
1321383.170.113.88UK2NET-AS UK-2 Ltd Autonomous System
13727216.8.179.23ND-CA-ASN – NEXT DIMENSION INC
1541877.68.52.52FASTHOSTS-INTERNET Fasthosts Internet Ltd. Gloucester
15685217.11.254.41CASABLANCA-AS Casablanca INT Autonomous system
1626585.17.137.40LEASEWEB LEASEWEB AS
1626585.17.19.26LEASEWEB LEASEWEB AS
1626594.75.243.6LEASEWEB LEASEWEB AS
16276178.32.1.70OVH OVH
16276188.165.124.185OVH OVH
16276188.165.159.139OVH OVH
16276188.165.192.22OVH OVH
16276188.165.196.19OVH OVH
16276188.165.204.115OVH OVH
16276188.165.61.44OVH OVH
16276188.165.95.132OVH OVH
16276188.165.95.133OVH OVH
16276213.186.47.177OVH OVH
16276213.251.164.84OVH OVH
1627687.98.149.171OVH OVH
1627691.121.108.38OVH OVH
1627691.121.11.69OVH OVH
1627691.121.15.168OVH OVH
1627691.121.162.65OVH OVH
1627691.121.163.43OVH OVH
1627691.121.167.167OVH OVH
1627691.121.174.152OVH OVH
1627691.121.182.209OVH OVH
1627691.121.226.19OVH OVH
1627691.121.27.197OVH OVH
1627691.121.3.80OVH OVH
1627691.121.74.88OVH OVH
1627694.23.110.107OVH OVH
1627694.23.12.62OVH OVH
1627694.23.158.31OVH OVH
1627694.23.198.9OVH OVH
1627694.23.220.163OVH OVH
1627694.23.220.194OVH OVH
1627694.23.224.132OVH OVH
1627694.23.228.40OVH OVH
1627694.23.229.220OVH OVH
1627694.23.24.66OVH OVH
1627694.23.28.143OVH OVH
1627694.23.34.93OVH OVH
1627694.23.35.107OVH OVH
1627694.23.92.35OVH OVH
17482.138.98.27COGENT Cogent/PSI
2077387.230.53.82HOSTEUROPE-AS AS of Hosteurope Germany / Cologne
2077387.230.55.58HOSTEUROPE-AS AS of Hosteurope Germany / Cologne
2077387.230.73.52HOSTEUROPE-AS AS of Hosteurope Germany / Cologne
2087787.237.106.195DATEK DATEK Telecom SRL
20912212.66.100.194ASN-PANSERVICE Panservice
2313674.213.179.183ONX – OnX Enterprise Solutions Inc.
24940188.40.81.119HETZNER-AS Hetzner Online AG RZ
2494088.198.14.169HETZNER-AS Hetzner Online AG RZ
2494088.198.35.214HETZNER-AS Hetzner Online AG RZ
2494088.198.49.197HETZNER-AS Hetzner Online AG RZ
2494088.198.55.175HETZNER-AS Hetzner Online AG RZ
2498988.84.145.36IXEUROPE-DE-FRANKFURT-ASN IX Europe Germany AS
2860194.79.88.121NOVIS Novis Telecom
2867762.193.208.175AMEN AMEN Network
28753188.72.211.253NETDIRECT AS NETDIRECT Frankfurt
28753188.72.212.104NETDIRECT AS NETDIRECT Frankfurt
2907394.102.54.11ECATEL-AS AS29073
29131109.169.29.144RAPIDSWITCH-AS RapidSwitch
2914198.64.133.214NTT-COMMUNICATIONS-2914 – NTT America
29321217.195.160.74CENTRONETAS Centronet
2955092.48.119.94SIMPLYTRANSIT Simply Transit Ltd
2955094.76.254.248SIMPLYTRANSIT Simply Transit Ltd
2987367.223.233.101BIZLAND-SD – The Endurance International Group
3133383.151.21.150VOLLMAR-AS AS31333
3136585.153.38.2SGSTELEKOM SGS Telekom Autonomous System
3224467.225.181.217LIQUID-WEB-INC – Liquid Web
3301213.180.79.146TELIANET-SWEDEN TeliaNet Sweden
335662.67.246.113LEVEL3 Level 3 Communications
34265213.108.72.158SILVERTELECOM-AS SilverTelecom Ltd
3476277.241.80.228COMBELL-AS Combell group NV
3477993.103.5.146T-2-AS AS set propagated by T-2
3477993.103.5.156T-2-AS AS set propagated by T-2
3522887.194.123.116BEUNLIMITED Avatar Broadband Limited
3583080.248.221.213SIVIT-AS SIVIT Network –
36057174.137.179.244WEBAIR-AMS Webair Internet Development Inc
3932693.89.80.117GOSCOMB-AS Goscomb Technologies Limited
3958289.106.8.40GRID Grid Bilisim Teknolojileri A.S.
41044194.24.228.81THYA-AS Thya AS Number
413461.177.120.254CHINANET-BACKBONE No.31
42926213.128.83.18RADORE Radore Hosting Telekomunikasyon Hizmetleri San. ve Tic. Ltd. Sti.
4335077.247.180.40NFORCE NForce Entertainment B.V.
4341378.41.22.130ASNEW NEW TELEKOM
4354193.185.105.74VSHOSTING VSHosting s.r.o.
4411277.222.43.78SWEB-AS SpaceWeb JSC
4497691.204.116.114IONOD-AS AZNet Autonomous System
4766218.145.56.55KIXS-AS-KR Korea Telecom
4766222.122.81.54KIXS-AS-KR Korea Telecom
4853991.198.106.6OXILION-AS Oxilion B.V.
49981217.23.7.112WORLDSTREAM WorldStream
5577212.117.161.3ROOT root SA
672485.214.22.200STRATO STRATO AG
690878.41.156.236DATAHOP Datahop Ltd
799272.38.223.96COGECOWAVE – Cogeco Cable
800169.164.212.94NET-ACCESS-CORP – Net Access Corporation
856087.106.99.134ONEANDONE-AS 1&1 Internet AG
8935212.19.216.11INTOUCH-CS-AS Amsterdam
897262.75.161.249PLUSSERVER-AS PlusServer AG
897262.75.162.196PLUSSERVER-AS PlusServer AG
897285.25.152.176PLUSSERVER-AS PlusServer AG


Which, when plotted on a map, looks like:


This map example shows the high concentration of compromised servers in the OVH autonomous system, a large hosting company located in France.  While this shouldn’t specifically illustrate that OVH is overtly malicious, it does show that their hosting strategies are permissive to cybercrime (or at least, they are not staffed or equipped to handle abuse requests in a timely manner.).  This data also doesn’t take into account sink-holing activity, in which a security researcher will register a known malicious domain and redirect its traffic to a friendly server for intelligence or defensive purposes.


Historically, however, OVH has been highly ranked in most “malicious organization lists” which include the following:



With our new found intelligence in hand, we began mapping the infrastructure according to labels and descriptions that were part of the zone files.   What we found was a tiered infrastructure that spread domains across specific functions. 


A Tiered-Criminal Infrastructure


After analyzing the DNS configuration over the observed time-period, we classified the servers into four distinct “functions”


These were:


  • Command and Control – Domains used for command and control functions
  • Traffic – Domains used in script injection tasks
  • Exploit – Domains used to exploit visiting browsers
  • Supporting – Domains used to support other cybercrime ventures


Command and Control Domains 


During our observation, we tracked 23 domains specifically devoted to C2 activity, which were then sub-divided into other categories:


afterspan.ruBredolab Command and Control
alesolo.ruBredolab Command and Control
armyerror.ruBredolab Command and Control
bayjail.ruBredolab Command and Control
coolblender.ruBredolab Command and Control
discountprowatch.comBredolab Command and Control
evilpal.ruBredolab Command and Control
exitguide.ruBredolab Command and Control
eyesong.ruBredolab Command and Control
feeplain.ruBredolab Command and Control
forhomessale.ruBredolab Command and Control
galoh.ruBredolab Command and Control
hostindianet.comBredolab C2/ DNS configuration
hotgas.ruBredolab Command and Control
imoviemax.ruBredolab Command and Control
localegg.ruBredolab Command and Control
tunemug.ruBredolab Command and Control
yourarray.ruBredolab Command and Control
getyourdns.comDNS Configuration
dnsofthost.comDNS Configuration
instantdnsserver.comDNS Configuration
netdnshosting.comDNS Configuration
netwebinternet.ruUnknown (labeled “Win Proxy”)


Most of these domains all used the same registrar:


registrar:  NAUNET-REG-RIPN


Naunet , a Russian registrar located in Moscow, has been highly visible in many “known bad organization” lists.  Accord to data at URIBL (, nearly 100% of the domains recently registered at this registrar are listed for spam, malware or exploits:


Listed Domains registered at NAUNET-REG-RIPN


97.68% – 970 of 993 domains registered at are listed by URIBL in the 5 day period prior to the 48hr publication delay.


Additionally, the ShadowServer organization has tracked additional malicious  behavior (to which NetWitness was a contributor) from this registrar:


According to the NAUNET website, multiple avenues of “support” contact information are given for contact, but in our experience, abuse notifications are never answered.   This, combined with observed behavior, makes it highly likely that NAUNET-REG-RIPN is complicit in cybercrime activity, if not directly involved.


Traffic Domains


The next group of domains were what we classified as “traffic domains”.


These domains were used specifically in injection and spam tasks, and either via injected script or direct hyperlink to direct visiting browsers to exploit domains for exploitation and malware downloads:


In the case of this group of domains,  all were registered at NAUNET-REG-RIPN:


Again showing ongoing abuse occurring with this registrar.


Exploit Domains


The third group of domains, which were the most numerous (380) of the classifications, where used exclusively for host exploitation and typically listened on port 8080 for connections:


The majority of these domains were again registered at NAUNET, but we also see an additional familiar face in the “bad registrar” space:


  • Registrar: BIZCN.COM, INC.  (number 12 on
  • Registrar: ONLINENIC, INC.


Supporting Domains 


The fourth and final classification of domains in this infrastructure were devoted to a number of “supporting activities”, most notably elements that are typically the subject matter of mass-spam campaigns.


This includes:


  • Pharmacy Sites
  • Gambling
  • Pornography
  • Counterfeit Merchandise
  • Pirated Video
  • Online Dating



The domains in this group were as follows:


bestviagraa.comPharmacy Spam
bestviagracenter.comPharmacy Spam
bestviagrapharmacies.comPharmacy Spam
bestviagrapills.comPharmacy Spam
buynowviagra.comPharmacy Spam
buyviagraworld.comPharmacy Spam
cheapdrug-shop.comPharmacy Spam
cheapviagrarx.comPharmacy Spam
co-pharmacy.comPharmacy Spam
drugbestprice.comPharmacy Spam
drugs-shop4u.comPharmacy Spam
drugshops24.comPharmacy Spam
eropharmacy.comPharmacy Spam
esuperviagra.comPharmacy Spam
expressviagraonline.comPharmacy Spam
greatviagrabest.comPharmacy Spam
greatviagraprice.comPharmacy Spam
i-drugshop.comPharmacy Spam
live-pharmacy.comPharmacy Spam
mybestviagra.comPharmacy Spam
naturalviagraonline.comPharmacy Spam
onlineviagraorder.comPharmacy Spam
pharmacy-4you.comPharmacy Spam
pharmacy-magazine.comPharmacy Spam
superviagraonline.comPharmacy Spam
thecheapviagra.comPharmacy Spam
thenaturalviagra.comPharmacy Spam
thesuperviagra.comPharmacy Spam
theviagrapills.comPharmacy Spam
theviagrasite.comPharmacy Spam
viagra-international.comPharmacy Spam
viagrabestprices.comPharmacy Spam
viagrapriceline.comPharmacy Spam
web-drugshop.comPharmacy Spam
world-drugshop.comPharmacy Spam
discount-bestwatch.comCounterfeit Merchandise
discount-bestwatches.comCounterfeit Merchandise
discount-smartwatch.comCounterfeit Merchandise
watch-atbestprice.comCounterfeit Merchandise
watchatlowprice.comCounterfeit Merchandise
gr8kino.ruPirated Video
100bestfilms.ruPirated Video
kino-welcome.ruPirated Video
skachivai-kino.ruPirated Video
seebestkino.ruPirated Video
hochutebia.ruOnline Dating
hotsex-meets.ruOnline Dating
dating-4you.ruOnline Dating
dating-group.ruOnline Dating
dating-spot.ruOnline Dating
love-pair.ruOnline Dating
xochu-dating.ruOnline Dating


An added bit of intelligence that came through the server status pages on these servers was the proxying of “” through all of the exploit domains.  This was evident by the following request:


GET /scan4u/ HTTP/1.0,2010-06-10 10:00:01


GETs of the following URL from any exploit domain on port 8080 resulted in a connection to _http://scan4u.net_


http://domain:8080/scan4u is essentially a “criminal virustotal plus”.  That is, it is a service where a miscreant can submit a newly created malware binary to gauge the detection rate of various antivirus vendors.  While similar to virustotal in this regard, the key is that scanned binaries aren’t submitted to the antivirus vendors in question, as is done with virustotal.  A general overview of the service (translated from Russian) shows the following key points:


  • The service doesn’t submit to anti-virus vendors.
  • Antivirus clients are updated hourly to maintain a current definition set.
  • Submitted binaries are rechecked on a schedule and customers are emailed about new detections.


As well as antivirus checks, the miscreants running the service appear to have extended their checks into the online blacklist area: 


“Domain check on presence in black list: ZeuS domain blocklist, ZeuS IP blocklist, ZeuS Tracker, MalwareDomainList (MDL), Google Safe Browsing (FireFox), PhishTank (Opera, WOT, Yahoo! Mail), hpHosts, SPAMHAUS SBL, SPAMHAUS PBL, SPAMHAUS XBL, MalwareUrl,SmartScreen (IE7/IE8 malware & phishing Web site),Norton Safe Web, Panda Antivirus 2010, (Firefox Phishing and Malware Protection), and RFC-Ignorant.Org.”


This update indicates ongoing blacklist checks across a variety of services, including:


  • Security researcher and community published blacklists (zeustracker, malwaredomainlist, malwareurl, phishtank, spamhaus)
  • Browser-based anti-phishing technology (google safe browsing, smartscreen)
  • Vendor blacklists (Norton, Panda, etc.)



Miscreants using this service have a one-stop shop for both the detection of malicious binaries as well as the existence of their delivery systems in disparate blacklists across the Internet.


Tying it together


When the numbers are looked at as a whole, the infrastructure shows knowledge of defender techniques, as well as insight into the various money-making schemes involved.



Exploit domains are, by far, the largest slice of the total number of involved domains.  Because exploit activity is often the “noisiest” of the infection cycle in a malware campaign and usually the mostly likely target for takedown,  it makes sense that this operator would have a large quantity of such domains to rotate into campaigns as needed. Details showed this was a proxy network as well, so the use of compromised servers as a front-line helps to prevent takedown of the back-end servers feeding the system.


Based on the gathered intelligence as a whole, the operator was likely making money off of this scheme in a number of ways:


  • Multiple Bredolab C2 domains indicate a segregated botnet which suggests that the operator rented portions of the botnet out to end-users.
  • Executable delivery as part of second-stage after Bredolab installation.
  • Executable delivery outside the observed infection chain (directly from a domain subdirectory) suggests hosting services for other malware campaigns.
  • Proxying of third-party sites indicates spam-related hosting services for items that are of high risk for takedown. (pharmacy, gambling, pornography, etc.).
  • Proxying of the “” service.





The intelligence gathered on this system show the continuing advancement of criminal exploit systems and detail the following points:


  1. The continued abuse of online hosting and registration services, and the associated lack of action by ICANN and Regional Registries in suspending organizations associated with criminal activity, despite overwhelming evidence of abusive, permissive or neglectful activity.
  2. The use of automation to stymie researcher takedown efforts and creatively weighting points in the malware-infection cycle to predict takedown activity (high number of exploit domains compared to others).
  3. The use of compromised credentials to inject scripts into benign sites and direct visiting browser systems.
  4. The use of compromised servers to host spam-related content and further monetize fraud activity outside of malware infection.
  5. The use of proxy networks to obfuscate primary hosts in the infrastructure.


Special thanks to the following researchers, who played a key role in helping us understand this system:


Vitaly Kamluk – Kaspersky Lab, Japan
Steven Burn – Ur I.T. Mate Group


Happy Hunting!


Alex Cox, Principal Research Analyst

RSA Admin

Its Malware!

Posted by RSA Admin Employee Aug 22, 2012



Zeus is evolving. In regards to a new release, one Anti-Virus vendor recently noted:

“[the new exe] uses techniques designed to avoid automatic heuristics-based detection.”


The discussion then proceeds to examine how the exe is different from previous versions of the malware.


Should we be alarmed that Zeus is getting so sophisticated that it evades heuristics-based detection mechanisms?


I suppose if it actually evaded heuristics-based detection mechanisms, that would be alarming. I’m sure the version of Zeus in question evades the mechanisms of certain AV vendors. However, when looking at the exact sample in question (verified by MD5) using the techniques we use for malware identification here, we see the sample stands out like a sore thumb.


Using our own internally-developed heuristic malware identification methods (also used by components of NextGen), we see the exe has traits such as the following (not a complete list!):


  1. The binary contains packed sections, indicative of packed, obfuscated, and/or encrypted malware.
  2. The size of the binary is abnormally small considering the conditions and context in which it was found.
  3. The PE checksum fails to validate, something malware packers are notoriously bad about.
  4. The binary does not have any information normally found within the version info table in the resource section of the PE.


But… Why get overly wrapped around the minutia related to the abnormal facets of this particular sample of Zeus? There’s a more important note to be made here. That is, Zeus is malware, so it does the things that malware does! You can’t get more “heuristically obvious” than that!

From the same vendor as above:

“…common ZeuS 2.0 variants contain relatively few imported external APIs… By contrast, [this version] imports many external APIs. To a heuristic scanner, this changes the appearance of the file and lowers the possibility of detection.”


Finding a binary that has very few external imports is generally a sign that something is suspicious. Specifically, it’s generally a sign the file is packed, obfuscated, and/or encrypted and the real imports are likely hidden inside. Such is the case when finding binaries that only import between two and five specific API’s from kernel32.dll (in the more obvious cases).


However, when finding a binary with a lot of imports, that’s even better since you get to see the full range of imports needed by the binary/malware! Without even running the sample or doing deep low-level reverse engineering, you can start to make assumptions about the functionality of the binary based on the API’s it uses. Further, it’s a simple matter to separate malware from legitimate binaries by comparing the API’s it uses to the ones it doesn’t need/use.


As is the case with this sample of Zeus, we see it (like the thousands of different types of malware not related to Zeus) imports APIs related to hooking the Windows API, creating mutexes, and managing services – without importing the functions used by legitimate binaries that also use the same functions.


So, should we be alarmed some people say Zeus is getting so sophisticated that it evades heuristics-based detection mechanisms?


If your security vendor is looking for Zeus, then yes, you should be alarmed. However, if your security vendor is looking for general signs of malware, infection, and so on, then no… Fortunately Zeus is still malware, just like all the rest of it…


Gary Golomb



In the “malware of the minute” news,  information surrounding the “Murofet” trojan has hit some malware research blogs.

Details around this trojan, which shares code similarities with ZeuS, can be found here:



What’s interesting about Murofet is that it borrows a page from the Conficker playbook and uses an algorithm to generate command and control domain names on the fly based on the date and time on the infected host. This makes it very difficult to take down from a defender standpoint because coordinated effort is required to control all of the possible domain names as they are detected.


In this case, reverse engineering has revealed a way to generate the domain names used by the malware in advance, which allows us to build a list of all possible domains that will be used by the malware in its current state.


But that brings us to our challenge. Murofet can generate 1,020 usable domain names a day… which if we say, push that out for a few months in advance, quickly reaches into the tens of thousands of possible domain names. If I’m an incident responder at a large enterprise, I may need to parse through multiple gigabytes a day of proxy logs to attempt to locate these tens of thousands of possibly malicious domains. As you can imagine, this can quickly become a very tedious and unwieldy problem.


One of the many strengths of the NextGen framework is that it is built around addressing this sort of “needle in a haystack” problem. The NetWitness Live system is built around the concept of using external intelligence and applying it to *your* network in real-time, with alerting and in some cases we have feeds with *millions* of entries.


In this case, and given a big list of Murofet domains, it is a trivial exercise to create a custom feed that identifies when they are seen on the network. Add an Informer Alert, and you have real-time notification if any one of these 74,000 domains are accessed by any of your monitored hosts. This strategy was also successfully used to track Conficker infections at some of our clients.


If you’d like more information on creating your own custom feeds, please see this link in the community:



The press has been a buzz over the past few weeks with news of law enforcement busts of some prominent ZeuS miscreants.


This has renewed interest at NetWitness around the data and publication of our “Kneber” paper, which documented the data stolen by a large ZeuS botnet.


Today I took a second look at the domains reported to (since in the release of our research in February) that were registered by our nemesis,


Here’s what I found:


Since February, seven-one new “kneber” domains have been identified as malicious and whois records indicate the vast majority of them were created after the publication of our research:


  • Created On:09-Feb-2010 20:20:43 UTC
  • Created On:13-Apr-2010 14:58:46 UTC
  • Created On:20-Jan-2010 13:02:23 UTC
  • Created On:20-Jan-2010 13:02:23 UTC
  • Created: 2009-12-22
  • Created: 2010-01-14
  • Created: 2010-02-09
  • Created: 2010-02-11
  • Created: 2010-02-12
  • Created: 2010-02-17
  • Created: 2010-02-18
  • Created: 2010-02-23
  • Created: 2010-02-23
  • Created: 2010-03-11
  • Created: 2010-03-11
  • Created: 2010-03-11
  • Created: 2010-03-15
  • Created: 2010-03-15
  • Created: 2010-03-15
  • Created: 2010-03-16
  • Created: 2010-04-13
  • Created: 2010-04-27
  • Created: 2010-05-06
  • Created: 2010-05-26
  • Created: 2010-06-10
  • Created: 2010-06-14
  • Created: 2010-06-14
  • Created: 2010-06-25
  • Created: 2010-06-29
  • Created: 2010-07-05
  • Created: 2010-07-08
  • Created: 2010-07-16
  • Created: 2010-07-26
  • Created: 2010-07-29
  • Created: 2010-08-01
  • Created: 2010-08-02
  • Created: 2010-08-06
  • Created: 2010-08-06
  • Created: 2010-08-06
  • Created: 2010-08-13
  • Created: 2010-08-14
  • Created: 2010-08-14
  • Created: 2010-08-17
  • Created: 2010-08-26
  • Created: 2010-08-28
  • Created: 2010-08-28
  • Created: 2010-08-28
  • Created: 2010-08-28
  • Created: 2010-09-05
  • Created: 2010-09-09
  • Created: 2010-09-21
  • Created: 2010-09-21
  • Created: 2010-10-05


Of these domains, 56 had registrar information in the whois records, and 53 of those were a single registrar: 


Registrar: BIZCN.COM, INC.


These domains are being reported for a number of different malicious elements, but there are 100 instances of ZeuS components from this group of domains, including:


  • zeus v1 config file
  • zeus v1 drop zone
  • zeus v1 trojan
  • zeus v2 config file
  • zeus v2 drop zone
  • zeus v2 trojan


So what does this tell us about the state of the internet? 


  • Domain registration and monitoring of activities is still a weak point in the security of the internet.
  • Top-level .com and .net dns providers are in a key place to act against this sort of activity but don’t.
  • Despite massive press coverage and industry acknowledgement of and associated maliciousness,  registrars (and BIZCN in particular) are still allowing ongoing registration by this email address, and not suspending existing “kneber” domains.
  • Not surprisingly, ZeuS is still very active.


NetWitness customers that subscribe to NetWitness Live automatically detect these domains due to our partnership with


Happy Hunting!


Alex Cox, Principal Research Analyst



If you’ve kept a view on security news in the past 24 hours, you may have noticed some press around a new email worm spreading on corporate networks.   Dubbed the “Here You Have” worm, it is a good case study on how to manage emerging threats with your NetWitness technology.  You can find additional info on the worm here:


As a general overview, the worm works in a similar manner as other recent malware observed in the wild.


  • It tempts the user to click on an attachment or link with a social engineering hook.
  • When clicked, the malware establishes itself on the targeted machine to run automatically and propogates itself.
  • The malware downloads additional executables intended to steal saved credentials and establishes a beacon mechanism to receive updates or transmit stolen data.


Like most emerging threats, research teams at NetWitness analyzed this variant as soon as we found out about it, and I’ll use a few basic incident response questions to demonstrate detection mechanisms using our technology.   One thing to note is that none of this worm’s activity requires any content generation other than simple application rules since the metadata extraction process in our engine  extracts all of the relevant meta by default.


1)  Who in my environment was targeted?


Targeted email addresses related to this worm’s activity can be detected by simply using a custom-drill in Investigator:


subject contains ‘here you have’,'just for you’ && email = ‘’


This drill will focus the collection on the email sessions related to this activity, and relevant email addresses, ip addresses, hostnames, etc. can be extracted for additional analysis.


2) Who in my environment actually clicked on the link or attachment?


In this case, there are a few ways to detect this activity.   Once executed, the malware downloads a number of files with the extension “iq”.   Since this is an unusual extension, an initial quick pivot to locate infected hosts is:


extension = ‘iq’


Or, you could specifically target some of the filenames themselves:


filename = ‘’,'’,'’,'’,'’,'’,'’,'’,'’,'’


Or, you could look for hits to the where the files reside: = && directory contains ‘yahoophoto’


Or, if your sniffing equipment is monitoring a backbone, you could look for the malware being copied to mapped network drives:


filename = ‘pdf_document21_025542010_pdf.scr’


3) Who in my organization is infected and beaconing?


In this case, one of the downloaded files in Step 2 attempts to contact “”, so you can use an pivot to locate machines that may have transmitted credentials to a third-party: = ‘’


One thing to keep in mind is that both “” and “” have been taken down by the security industry at this point, so with this variant, you are looking at a cleanup effort.   Also keep in mind that infected machines will continue to spam messages until they are cleaned.


Happy Hunting!



If you’ve ever seen me, or any of the NetWitness crew, speak on malware, advanced threats or the current threat environment, you’ll generally hear more than one recurring theme, one of which is:


Your anti-virus solution isn’t working like you think it is.


This is occurring for a variety of reasons and is ultimately the result of a business-based exploitation cycle in the criminal underground.   This cycle includes software support, licensing, and ongoing quality assurance.  One of the best examples I’ve ever seen to illustrate this concept is in the case of “”.


Brian Krebs posted about this particular cybercrime endeavor in his blog here a few months ago:


However, recent intelligence gathering efforts have revealed that this particular business venture has been extended and improved using the same resilience concepts used in most large legitimate corporate infrastructures.


A brief overview of “” is essentially  a “criminal virustotal plus”.  That is, it is a service where a miscreant can submit a newly created malware binary to gauge the detection rate of various antivirus vendors.  While similar to virustotal in this regard, the key is that scanned binaries aren’t submitted to the antivirus vendors in question, as is done with virustotal.


Let’s surf the service for examples:


What we see here is a general overview of the service (translated from russian) with the following key points:


  • The service doesn’t submit to anti-virus vendors.
  • Antivirus clients are updated hourly to maintain a current definition set
  • Submitted binaries are rechecked on a schedule and customers are emailed about new detections


Digging deeper we see an example of the current signature state of included antivirus engines, which includes the vendor name, signature update version number and last update time: 


And it’s even affordable and easy to pay for…$25 a month or 15 cents per scan, and a discount for referrals.  As well as flexible payment options and multiple contact points (I’ve blocked the specifics out):




How long has this service been running?


“News” updates indicate that this service has been running since at least October of 2009 and is being consistently upgrade and maintained:



2010-05-01 – 2010-05-10 – Our support will be online, less often

2010-04-23 – Add Domain/IP/Url check in NOD32 antivirus

2010-04-21 – Add Domain/IP/Url check in Kasperky Anti-Phishing database

2010-04-19 – Today we will do hardware upgrade, posible some down time.

2010-04-15 – The check of sheaves is finished, now we pull out all that is possible. The check goes only from one IP(our web IP). So do not forget to null stats before the check or to switch off blocking on IP.

2010-04-12 – We upgrade Dr Web to 6.0 version.

2010-03-31 – Today/Tomorow we will do hardware upgrade, posible some down time.

2010-03-22 – Add Trend Micro Internet Security Pro Antivirus.

2010-03-21 – Add eTrust-Vet Internet Security Antivirus.

2010-03-19 – Add VirusBuster Internet Security Antivirus.

2010-03-19 – Update API, now you can turn some AV off for check, add support for Exploits Pack check. Add ability to get execution result of find/pdfid/pefile/trid utility (“Save file on server” option must be on)

2010-03-18 – We upgrade Avast and NOD32 antiviruses to new version. Avast now have Avast5 version and NOD32 now 4.0437 version.

2010-03-11 – We second day under DOSS attack, we apologize for any interference. Our technical team is working on this.

2010-03-03 – Add New type of check, “Exploit Pack”.

2010-02-25 – Add Domain/IP/Url check in and RFC-Ignorant.Org.

2010-02-23 – Today we make our 500K check.

2010-01-28 – Add new features: now reports can be send to Jabber and GTalk accounts.

2010-01-20 – Upgrade Notrton Antivirus to Norton Internet Security.

2010-01-19 – Update Internet Explorer 8, now found more “Unsafe Website”.

2009-12-08 – Add Webroot Internet Security Essentials Antivirus.

2009-12-08 – Add F-Secure Internet Security 2010 Antivirus.

2009-12-02 – Add COMODO Internet Security Antivirus.

2009-11-25 – Add Domain/IP/Url check in Firefox Phishing and Malware Protection

2009-11-17 – Add Domain/IP/Url check in Panda Antivirus 2010

2009-11-11 – Add Domain/IP/Url check in Norton Safe Web

2009-11-10 – new support ICQ 588-391-779. Old number temporarily not work.

2009-11-10 – Add Polish Antivirus ArcaVir.

2009-11-09 – Today we add chinese Antivirus Rising to our system.

2009-11-05 – Add Sophos Antivirus.

2009-11-02 – Add AntiVir (Avira) Antivirus.

2009-10-27 – Add Utility that help you makes checks on your own system (see Links page).

2009-10-23 – Add Norman Antivirus.

2009-10-21 – Add Domain/IP/Url check in SmartScreen (IE7/IE8 malware & phishing Web site defense).

2009-10-19 – Add ability to check Domain/IP/Url in blacklist and Filter databases. At now we support following checks: ZeuS domain block-list, ZeuS IP block-list, ZeuS Tracker, MalwareDomainList (MDL), Google Safe Browsing (FireFox), PhishTank (Opera, WOT, Yahoo! Mail), hpHosts, SPAMHAUS SBL, SPAMHAUS PBL, SPAMHAUS XBL, MalwareUrl.

2009-10-15 – Add Microsoft Security Essentials Antivirus.

2009-10-06 – Add IKARUS Antivirus.

2009-10-02 – Add 2 new antivirus Quick Heal and A-Squared.

2009-10-01 – At present at us 16 antivirus Solo, McAfee, BitDefender, Panda, F-Prot, Avast!, VirusBlokAda, ClamAV, Kaspersky, Vexira, Norton, DrWeb, AVG, A-Squared, ESET NOD32, G DATA.

2009-10-01 – Today we have started our service on check of files on presence of viruses and malware.

How do we kill it?


So to take this down, we’d just get the domain name suspended right? appears that that has already been done as is evident with a quick dig:


Not found:



>>>> Whois database was last updated on: Sun May 30 14:07:49 GMT 2010 <<<<

So how is it still accessible?


At this moment, this service is being hosted or proxied through a criminal infrastructure, known in the industry as Gumblar.  Gumblar was recently referenced in a large scale compromise of blogs at most major hosting companies and has been an ongoing presence in the malware world for the past few  years.   At last check, the infrastructure has at least 376 verified domains, mostly in the .ru tld, across at least 43 different IPs in geographically disperse locations.


This hosting model is, in effect, a content distribution network, as used by most major online presences.  In this case, it’s being used to both hide the miscreants actual operating location, as well as provide fault tolerance from ongoing takedown efforts by the security community.


Extending beyond antivirus checks


As well as antivirus checks, the miscreants running the service appear to have extended their checks into the online blacklist area:


“Domain check on presence in black list: ZeuS domain blocklist, ZeuS IP blocklist, ZeuS Tracker, MalwareDomainList (MDL), Google Safe Browsing (FireFox), PhishTank (Opera, WOT, Yahoo! Mail), hpHosts, SPAMHAUS SBL, SPAMHAUS PBL, SPAMHAUS XBL, MalwareUrl,SmartScreen (IE7/IE8 malware & phishing Web site),Norton Safe Web, Panda Antivirus 2010, (Firefox Phishing and Malware Protection), and RFC-Ignorant.Org.”


This update indicates ongoing blacklist checks across a variety of services, including:


  • Security researcher and community published blacklists (zeustracker, malwaredomainlist,malwareurl,phishtank,spamhaus)
  • Browser-based anti-phishing technology (google safe browsing,smartscreen)
  • Vendor blacklists (Norton, Panda, etc)


So in essence, miscreants using this service have a one-stop shop for both the detection of malicious binaries as well as the existence of their delivery systems in disparate blacklists across the internet. 


They also understand researcher and malware analysis activity:


Add ability to get execution result of find/pdfid/pefile/trid utility (“Save file on server” option must be on)”


  • PDFID is Didier Steven’s excellent PDF analysis tool.
  • PEFILE  is a python module used to assist in reverse engineering binaries to detect packing and other indicators of maliciousness.
  • TRID is a tool used to identify files from their binary signatures.


What all of this should tell you is that criminal miscreants continue to upgrade and enhance their services to assist in perpetuating their business model, penetrate your networks, and make money!


Watch your network, because they certainly are!


Alex Cox, Principal Research Analyst





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:


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.





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 0x8F


0xE8 0×00 0×00 0×00 0×00 0x0F 0x1A


0xE8 0×00 0×00 0×00 0×00 0x0F 0xA9


Noir’s no JMP/CALL


This next technique was first described by  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.


Gary Golomb

RSA Admin

Kneber Update

Posted by RSA Admin Employee Aug 22, 2012



There was a significant amount of coverage yesterday on research performed by NetWitness into a large set of stolen information recovered from a ZeuS botnet.  Some of the information, analysis, and commentary was very beneficial to the broader discussion of threats such as these.  There is, however, some information that we feel we should address.


  • Kneber is a pseudonym for ZeuS:

Kneber is not a pseudonym for ZeuS. Kneber refers to one group of organized criminals, one group of Command and Control Systems, and 74,000+ infected victim systems for this particular ZeuS (primarily) botnet.   ZeuS is a tool, used by many groups to create command and control systems, and steal information.  There are hundreds of active ZeuS botnets, many of which are larger than this one. It is but one of many tools used in this particular botnet.  We have seen INTENTIONAL cross pollination of various trojans, including waledec, grum, and even tools such as packet sniffers.  When we discuss threat, we are referring to more than the tool used, but the organization behind them.


  • Kneber is “nothing new”:

We have been very clear that this is a medium sized infestation when compared with all the tracked ZeuS botnets on the Internet.   What does make this very valuable is the opportunity to analyze such a large sample of stolen information, and quantitatively add to the discussion of threats to corporate security.  The number of infected and active systems behind some of the largest, most technology savvy companies needs to be considered, and our approach to security needs to change given the broad failure to identify or remediate these infestations.   In addition, trivializing the damage done is simply disingenuous by anyone who has seen the types of data stolen from threats such as these.


  • Current protections and solutions can detect this type of activity:

This quote from Symantec, via the Guardian, KrebsOnSecurity, and others:


“Kneber, in reality, is not a new threat at all, but is simply a pseudonym for the infamous and well-known Zeus Trojan,” said the company. “The name Kneber simply refers to a particular group, or herd, of zombie computers, a.k.a. bots, being controlled by one owner. The actual Trojan itself is the same Trojan.Zbot, which also goes by the name Zeus, which has been being observed, analyzed and protected against for some time now.”


This quote is particularly troubling, as it seems to minimize the threat and is almost dismissive.   Moreover, when this particular variant was analyzed in late January (various services used), Symantec did NOT detect this as malicious.   To be fair, McAfee, Trend Micro, AVG, and most other mainstream anti-virus solutions also failed to recognize this as malicious.  In the past 3 weeks, Symantec has added signatures to detect this particular variant as a generic “Trojan Horse”.  However, if you were infected by this particular strain, your system has already processed an update that prevents you from contacting Symantec and others for updates.   In most cases, this will prevent future detection.   Worse, as part of normal operation of ZeuS, it attaches to running processes on victim systems in order to monitor them.   This data is logged along with other stolen information.   This set of data shows that ZeuS has actually attached to running versions of Symantec software on over a thousand victim systems.  Many other AV vendors are also present.




This example shows ZeuS monitoring a Symantec Live Update, and includes the ftp username and password used by the Symantec software during the update process.


  • Are the facts overstated?:

The facts are fairly succinct in the whitepaper that we released.   We do not believe the threat is over-stated, and we were very conservative on the analysis released.   There are likely thousands of additional corporate networks affected, and analysis of this much information takes time.   And this is simply one of many similar operations in existence.  The group behind this effort can be described as sophisticated, yet also shows signs of lax effort to hide their trails.   The botnet is very actively managed, and continues in operation today.   The fact that they have been in successful operation for over 18 months also has to be considered.   We have also received several additional data points from federal contacts with additional insight into related government focused attacks.


More to come.


Tim Belcher and Alex Cox

RSA Admin

Finding Aurora googlehack

Posted by RSA Admin Employee Aug 22, 2012




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!”

Filter Blog

By date: By tag: