Wednesday, December 17, 2014

Wiper Malware - A Detection Deep Dive

This post was authored by Christopher Marczewski with contributions from Craig WIlliams

A new piece of wiper malware has received quite a bit of media attention. Despite all the recent press, Cisco's Talos team has historic examples of this type of malware going back to the 1990s. Data is the new target, this should not surprise anyone. Recent examples of malware effectively "destroying" data - putting it out of victims' reach – also include Cryptowall, and Cryptolocker, common ransomware variants delivered by exploit kits and other means.

Wiping systems is also an effective way to cover up malicious activity and make incident response more difficult, such as in the case of the DarkSeoul malware in 2013.

Any company that introduced proper back-up plans in response to recent ransomware like Cryptolocker or Cryptowall should already be protected to a degree against these threats. Mitigation strategies like defense in depth will also help minimize the chance of this malware reaching end systems.

The Deep Dive

Initially we started investigating a sample reported to be associated with the incident to improve detection efficacy. Based off our analysis of e2ecec43da974db02f624ecadc94baf1d21fd1a5c4990c15863bb9929f781a0a we were able to link 0753f8a7ae38fdb830484d0d737f975884499b9335e70b7d22b7d4ab149c01b5 as a nearly identical sample. By the time we reached the network-related functions during our analysis, the relevant IP addresses belonging to the C2 servers were no longer responding back as expected. In order to capture the necessary traffic we had to modify both of the aforementioned disk wiper components. One modification replaced one of the hard-coded C2 server IP addresses with a local address belonging to a decoy VM while changing references to the other hard-coded addresses to point to this local address instead. The other modification simply changed the parameter being passed to an instance of the Sleep() function so debugging efforts wouldn’t be put on hold for 45 minutes (the original sample used a 10 minutes sleep).

When we initially examined a rule that was being distributed in the public we were looking for areas where we could improve coverage to better protect our customers. The new Wiper variant is poorly written code and luckily includes very little obfuscation.The author(s) made the mistake of allocating a buffer for the send() function that surpasses the data they wished to include in the payload: a null-terminated opening parentheses byte, the infected host's local IP address, and the first 15 bytes of the host name. This incorrect buffer allocation results in the desired data, in addition to some miscellaneous data already present on the stack (including the 0xFFFFFFFF bytes we alerted on in the first revision of our rule).

Simply running the disk wiper component on different versions of Windows proves the miscellaneous data from the stack that we onced alerted on only applies to beacons being sent from Win XP hosts:

Monday, December 15, 2014

Ancient Mac Site Harbors Botnet that Exploits IE Vulnerability

This post was authored by Alex Chiu and Shaun Hurley.

Last month, Microsoft released a security bulletin to patch CVE-2014-6332, a vulnerability within Windows Object Linking and Embedding (OLE) that could result in remote code execution if a user views a maliciously crafted web page with Microsoft Internet Explorer. Since then, there have been several documented examples of attackers leveraging this vulnerability and attempting to compromise users. On November 26th, Talos began observing and blocking an attack disguised as a hidden iframe on a compromised domain to leverage this vulnerability and compromise Internet Explorer users.

Tuesday, December 9, 2014

Dridex Is Back, then it's gone again

This post was authored by Armin Pelkmann and Earl Carter.

Talos Security Intelligence and Research Group noticed a reappearance of several Dridex email campaigns, starting last week and continuing into this week as well. Dridex is in a nutshell, malware designed to steal your financial account information. The attack attempts to get the user to install the malicious software on their system through an until lately, rarely exploited attack vector: Microsoft Office Macros. Recently, we noticed a resurgence of macro abuse. If macros are not enabled, social engineering techniques are utilized to try to get the user to enable them. Once the malware is installed on the system, it is designed to steal your online banking credentials when you access your banking site from an infected system.

Talos analyzed three separate campaigns in the last days, all distinguishable from their subject lines.

Microsoft Patch Tuesday for December 2014: Light Month, Some Changes

This post was authored by Yves Younan.

Today, Microsoft is releasing their final Update Tuesday of 2014. Last year, the end of year update was relatively large. This time, it’s relatively light with a total of seven bulletins, covering 24 CVEs. Three of those bulletins are rated critical and four are considered to be important. Microsoft has made a few changes to the way they report their bulletins. Microsoft has dropped the deployment priority (DP) rating, which was very much environment-specific and might not be all that useful for non-default installations. Instead, they are now providing an exploitability index (XI), which ranges from zero to three. With zero denoting active exploitation and three denoting that it’s unlikely that the vulnerability would be exploited. Another change is to more clearly report on how the vulnerability was disclosed: was Microsoft notified via coordinated vulnerability disclosure or was the vulnerability publicly known before being released?

Sunday, November 30, 2014

MS14-063 A Potential XP Exploit

This post was written by Marcin Noga with contributions by Earl Carter and Martin Lee.

New vulnerabilities for old operating systems may not seem particularly interesting, until you consider the large number of legacy machines running outdated versions of Windows. Windows XP has reached its end of life, meaning that new vulnerabilities will not be patched. In this post we will show that a recent vulnerability can be used as a platform for exploiting Windows XP.

In October, Microsoft released a bulletin for a privilege escalation vulnerability in the FASTFAT driver that was released as:

MS14-063 -- Vulnerability in FAT32 Disk Partition Driver Could Allow Elevation of Privilege (2998579)CVE-2014-4115.

Let me present some of the most interesting parts of the advisory and add some details from my own research.

When the bug kicks in…

In the advisory, Microsoft indicates that the following OS’s are vulnerable:

  • Microsoft Windows Server 2003 SP2
  • Vista SP2
  • Server 2008 SP2

The Microsoft bulletin does not mention Windows XP, since Windows XP is no longer supported. According to my research, however, this vulnerability is also present in the Windows XP FASTFAT driver.

See the following video.

This vulnerability can be exploited on Windows XP SP3 using a malicious usb stick with a malformed FAT32 partition. Let’s examine the reaction when the USB is inserted into the system.

Monday, November 24, 2014

Cisco Coverage for 'Regin' Campaign

This post was authored by Alex Chiu with contributions from Joel Esler.
Advanced persistent threats are a problem that many companies and organizations of all sizes face. In the past two days, information regarding a highly targeted campaign known as ‘Regin’ has been publicly disclosed.  The threat actors behind ‘Regin’ appear to be targeting organizations in the Financial, Government, and Telecommunications verticals as well as targeting research institutions in the Education vertical.  Talos is aware of these reports and has responded to the issue in order to ensure our customers are protected.

Tuesday, November 18, 2014

Reversing Multilayer .NET Malware

This post was authored by Dave McDaniel with contributions from Jaeson Schultz.
Recently, we came across a malware sample that has been traversing the Internet disguised as an image of a woman. The malware sample uses several layers of obfuscation to hide its payload, including the use of steganography. Steganography is the practice of concealing a message, image, or file within another message, image, or file. Steganography can be used in situations where encryption might bring unwanted attention. Encrypted traffic from an unusual source is going to draw unwanted attention. Steganography allows malicious payloads to hide in plain sight. It also allows the attacker to bypass security devices. In our sample malware, steganography is used to decrypt and execute a second dropper, which in turn installs a user-land rootkit to further hide its intentions. The rootkit adds another layer of obfuscation by installing a DarkComet backdoor, using RC4 encryption to encrypt its configuration settings and send data to its command and control server.

Tuesday, November 11, 2014

Microsoft Update Tuesday November 2014: Fixes for 3 0-day Vulnerabilities

This month Microsoft is releasing 14 security bulletins. Originally they had planned to release 16, but due to issues that emerged in late testing, two bulletins that were announced in the Advance Security Notification, MS14-068 and MS14-075, have been postponed. Of the 14 bulletins, four are considered critical, eight are important, while two are moderate. They cover a total of 33 CVEs.

Friday, November 7, 2014

Talos Discovered Three More Vulnerabilities in Pidgin

This post was authored by Yves Younan and edited by Armin Pelkmann.

Table of contents

CVE-2014-3697, VRT-2014-0205
CVE-2014-3696, VRT-2014-0204
CVE-2014-3695, VRT-2014-0203

Cisco Talos is announcing the discovery and patching of another three 3 CVE vulnerabilities in Pidgin (An open-source multi-platform instant messaging client - see wikipedia page). These vulnerabilities were discovered by our team and reported to the Pidgin team. They were found during our initial look at Pidgin which resulted in the first 4 vulnerabilities released in January, but were reported to Pidgin a little later and took longer to get patched. Now that these vulnerabilities were patched in the latest version of Pidgin, 2.10.10, we want to publicly disclose our findings.

The first vulnerability (CVE-2014-3697, VRT-2014-0205) is in the routines Pidgin uses to handle smiley and theme packages in Windows. These packages can be downloaded from websites and installed by dragging and dropping them to Pidgin. The packages are TAR files and Pidgin handles them by un-tarring the files to a specific directory.

Tuesday, October 28, 2014

Threat Spotlight: Group 72, Opening the ZxShell

This post was authored by Andrea Allievi, Douglas Goddard, Shaun Hurley, and Alain Zidouemba.

Recently, there was a blog post on the takedown of a botnet used by threat actor group known as Group 72 and their involvement in Operation SMN.  This group is sophisticated, well funded, and exclusively targets high profile organizations with high value intellectual property in the manufacturing, industrial, aerospace, defense, and media sector. The primary attack vectors are watering-hole, spear phishing, and other web-based attacks.

Frequently, a remote administration tool (RAT) is used to maintain persistence within a victim’s organization. These tools are used to further compromise the organization by attacking other hosts inside the targets network.

ZxShell (aka Sensocode) is a Remote Administration Tool (RAT) used by Group 72 to conduct cyber-espionage operations. Once the RAT is installed on the host it will be used to administer the client, exfiltrate data, or leverage the client as a pivot to attack an organization’s internal infrastructure.  Here is a short list of the types of tools included with ZxShell:

  • Keylogger (used to capture passwords and other interesting data)
  • Command line shell for remote administration
  • Remote desktop
  • Various network attack tools used to fingerprint and compromise other hosts on the network
  • Local user account creation tools

For a complete list of tools please see the MainConnectionIo section.

The following paper is a technical analysis on the functionality of ZxShell. The analysts involved were able to identify command and control (C2) servers, dropper and installation methods, means of persistence, and identify the attack tools that are core to the RAT’s purpose. In addition, the researchers used their analysis to provide detection coverage for Snort, Fireamp, and ClamAV.

Thursday, October 16, 2014

Weaponized Powerpoint in the Wild

This post was written by Jaeson Schultz.
On October 14th information related to a new Windows vulnerability, CVE-2014-4114, was published. This new vulnerability affects all supported versions of Microsoft Windows. Windows XP, however, is not affected by this vulnerability. The problem lies in Windows’ OLE package manager. When triggered it allows for remote code execution.

Wednesday, October 15, 2014

POODLE and The Curse of Backwards Compatibility

This post was written by Martin Lee
Old protocol versions are a fact of life. When a new improved protocol is released, products still need to support the old version for backwards compatibility. If previous versions contain weaknesses in security, yet their continued support is mandated, then security can become a major issue when a potential weakness is discovered to be a genuine vulnerability and an exploit is released.

The Transport Layer Security (TLS) protocol defines how systems can exchange data securely. The current version 1.2 dates from August 2008, however the protocol’s origins lie in the Secure Sockets Layer (SSL) standard first published in February 1995. As weaknesses in the cryptography and flaws in the protocol design were discovered, new versions of the protocol were released.

In order to maintain interoperability the most recent TLS standard requires that systems support previous versions down to SSL 3.0. The discovery of a cryptographic weakness in SSL 3.0 and the publication of an attack that can exploit this provide attackers with a means to attack TLS implementations by intercepting communications using the old SSL 3.0 protocol.

The vulnerability, assigned the Common Vulnerability and Exposure ID CVE-2014-3566, and referred to as POODLE, allows an attacker to modify the padding bytes that are inserted into SSL packets to ensure that they are of the correct length and replay modified packets to a system in order to identify the bytes within a message,  one by one. This allows an attacker to discover the values of cookies used to authenticate https secured web sessions. Nevertheless, the vulnerability potentially affects any application that secures traffic using TLS, not only https traffic.

Tuesday, October 14, 2014

Microsoft Update Tuesday October 2014: Fixes for 4 0-day Vulnerabilities

This post was authored by Yves Younan

Microsoft Tuesday is here once again and this month they are releasing a total of eight bulletins. Three of which are rated as critical, while the remaining five are rated as important. There’s a total of 24 CVEs this month, 20 of which were privately disclosed to Microsoft and four which are either publicly known or under active attack, making them 0-day vulnerabilities. Of those four, two are being actively attacked, while two have been publicly disclosed but do not seem to be under attack for supported software. Of the 24 CVEs, 15 are categorized as allowing remote code execution, four as elevation of privilege and three as security feature bypasses.

Threat Spotlight: Group 72

This post is co-authored by Joel Esler, Martin Lee and Craig Williams.

Everyone has certain characteristics that can be recognised. This may be a way of walking, an accent, a turn of phrase or a style of dressing. If you know what to look for you can easily spot a friend or acquaintance in a crowd by knowing what characteristics to look for. Exactly the same is true for threat actors.

Each threat actor group may have certain characteristics that they display during their attack campaigns. These may be the types of malware that they use, a pattern in the naming conventions of their command and control servers, their choice of victims etc. Collecting attack data allows an observer to spot the characteristics that define each group and identify specific threat actors from the crowd of malicious activity on the internet.

Talos security and intelligence research group collects attack data from our various telemetry systems to analyse, identify and monitor threat actors through their different tactics, techniques, and procedures. Rather than give names to the different identified groups, we assign numbers to the threat actors. We frequently blog about significant attack campaigns that we discover, behind the scenes we integrate our intelligence data directly into our products. As part of our research we keep track of certain threat actor groups and their activities. In conjunction with a number of other security companies, we are taking action to highlight and disrupt the activities of the threat actors identified by us as Group 72.

Thursday, October 9, 2014

Evolution of the Nuclear Exploit Kit

This post is co-authored by Alex Chiu, Martin Lee, Emmanuel Tacheau, and Angel Villegas.

Exploit kits remain an efficient mechanism for cyber criminals to distribute malware. Such kits include exploits for multiple vulnerabilities within a single malicious webpage. Criminals can check operating systems, web browsers and browser plugins for anything that is not fully patched and launch an exploit specific to the out of date software. Using this technique criminals can maximise their chances of infecting visitors but reduce their exposure to only infect those who are vulnerable; presumably in order to remain inconspicuous.

Tuesday, September 30, 2014

Shellshock Exploits in the Wild

This post was authored by Joel Esler & Martin Lee.

The recently discovered Bash vulnerability (CVE-2014-6271) potentially allows attackers to execute code on vulnerable systems. We have already blogged about the issue and provided more technical detail in a further blog. The rapid release of IPS signatures for our platforms allowed us to follow very quickly, the attempts at exploitation of the vulnerability in the wild.

For further details of our response to the issue, please see the Event Response Page.

Friday, September 26, 2014

Shellshock - Update Bash Immediately!

Shellshock is a serious vulnerability. Bash, arguably the most widely distributed shell on Linux systems, fails to correctly parse environment variables with function declarations. Why the fuss over environment variables? Because these variables are often set by programs that handle network data. Examples include dhcpcd which, through this vulnerability, more or less gives you a remote shell through DHCP option 114 (and potentially others) and Apache using mod_cgi or mod_cgid when CGI scripts are either written in Bash, or otherwise spawn subshells with exported data acquired from untrusted sources -- to name a few.

The problem is located in variables.c

initialize_shell_variables (env, privmode)
     char **env;
     int privmode;

If an environment variable starts with the string "() {" then initialize_shell_variables() interprets it as a function definition:

if (privmode == 0 && read_but_dont_execute == 0 &&
    STREQN ("() {", string, 4))
 string_length = strlen (string);
 temp_string = (char *)xmalloc (3 + string_length + char_index);
 strcpy (temp_string, name);
 temp_string[char_index] = ' ';
 strcpy (temp_string + char_index + 1, string);

To define the bash function, the rest of the string is passed to the parse_and_execute() function.

 if (posixly_correct == 0 || legal_identifier (name))
 parse_and_execute (temp_string, name, SEVAL_NONINT|SEVAL_NOHIST);

The problem here is the rest of the string is assumed to hold only a function definition, and is passed without sanitation to parse_and_execute().


/* Parse and execute the commands in STRING.  Returns whatever
   execute_command () returns.  This frees STRING. 
parse_and_execute (string, from_file, flags)
     char *string;

However, parse_and_execute() does not stop processing when it reaches the end of the function definition. Bash ends up executing all the commands in the string, even after the function definition. In essence, if an attacker can control an environment variable in a program that will spawn a shell with an environment containing that variable, command injection is possible. Since the original discovery of the vulnerability (CVE-2014-6271), the first fix has been found to be incomplete (CVE-2014-7169). Detection for the vulnerability condition (including CVE-2014-6271 & CVE-2014-7169) can be found in SIDs 31975-31978 & SID 31985.

We have observed attacks attempting to load ELF binaries onto possibly vulnerable targets via wget. ClamAV offers protection from this threat under the name "Linux.Flooder.Agent".

The following ELF binaries have been observed in the wild so far:


We'll be writing more on this subject early next week as we collect more information about the attacks we are seeing in the wild.

Thursday, September 25, 2014

Another Major Vulnerability Bashes Systems

Vulnerabilities that permit remote network attacks against ubiquitous software components are the nightmares of security professionals. On 24 September the presence of a new vulnerability, CVE-2014-6271 in Bash shell allowing remote code execution was disclosed.

Monday, September 22, 2014

Threat Spotlight: “Kyle and Stan” Malvertising Network 9x Larger Than Expected

This post was authored by Armin Pelkmann.

On September 8th, Cisco's Talos Security Intelligence & Research Group unveiled the existence of the "Kyle and Stan" Malvertisement Network. The network was responsible for placing malicious advertisements on big websites like,,, and 70 other domains. As it turns out, this was just the tip of the iceberg. Ongoing research now reveals the real size of the attackers' network is 9 times larger than reported in our first blog. For more details, read the Kyle and Stan Blog.

The infographic below illustrates how much more of the malvertisement network was uncovered in comparison to our first assessment. We have now isolated 6491 domains sharing the same infrastructure. This is over 9 times the previously mentioned 703 domains.  We have observed and analyzed 31151 connections made to these domains. This equals over 3 times the amount of connections previously observed. The increase in connections is most likely not proportional to the domains due to the fact that a long time that has passed since the initial attacks.

The discovery difference from the previous blog to this one in raw numbers. With more than 3-times the now observed connections and over 9-times the revealed malicious domains, this malvertising network is of unusually massive proportions.

Wednesday, September 17, 2014

Help! My IP Address Has Been Hijacked!

This post is authored by Jaeson Schultz.

SpamCop is a free, community-based spam email reporting service provided by Cisco. SpamCop analyzes reported spam, and extracts details about the sending IP, the URLs contained in the spam, and the networks over which the spam message has transited. This information is used to create the SpamCop Block List (SCBL). The SCBL a list of IP addresses believed to be sending Unsolicited Bulk Email.

As part of its service, each week SpamCop sends millions of email messages to notify network administrators about malicious activity that is observed occurring on their networks. SpamCop receives all types of replies in response to our notification emails. Many times recipients of SpamCop’s notifications will reply to SpamCop and claim, “we did not send the spam”. The SpamCop Deputies responsible for following up on these replies have heard every excuse under the sun. For them, “we did not send the spam” is the spam block list equivalent of “the dog ate my homework.”

Thursday, September 11, 2014

Looking Glasses with Bacon

This is my first post on the VRT blog and I would like to introduce myself. I am Mariano Graziano, an Italian third-year Ph.D. student at the Software and Systems Security Group at Institut Eurecom in Sophia-Antipolis (France) under the supervision of professor Davide Balzarotti. My research interests are memory forensics and automated malware analysis and currently I am an intern at Cisco in the Talos Security Intelligence and Research Group under the guidance of Alain Zidouemba for the next three months. This post is not about my current project at Cisco but is about my DEF CON talk.

At DEF CON 22 last month, I presented with my former colleague Luca Bruno an offensive research about Looking Glass software security. At the time we contacted all the Autonomous Systems (ASes) involved, as well as all the maintainers of the affected open-source Looking Glass software, but unfortunately, responsible disclosure is not the panacea and as result either some issues have not been addressed by the software maintainers or the AS local sysadmins did not update their Looking Glass instances.

In this post I give a brief overview about the research, then I introduce the vulnerabilities and web misconfigurations we uncovered, and finally I show how the Talos Security Intelligence and Research Group covered  all the CVEs with Snort rules, so that users can protect their backbone infrastructure.


Let's start by defining what a looking-glass is. A looking-glass is a web-application that provides a restricted set of operations on AS routers and is commonly written in Perl or PHP. This web application is directly connected to the routers (via telnet or SSH), the commands go from the web form to the router console and the answer is printed back. The attack vector is obviously from the web, in this threat model we have two kind of problems: web misconfigurations and common web vulnerabilities in the web interface. Web misconfigurations might lead an attacker to the backbone router credentials with a simple Google Dork while a severe vulnerability might lead to a command injection from the web form to the router console. During our research we have found both issues and six CVE numbers have been assigned by the MITRE affecting 45 ASes all over the world.

For a detailed analysis please have a look at either the WOOT 2014 paper or our DEF CON 22 slides.


We have found six vulnerabilities on four open-source Looking Glass software (MRLG4PHP, Cougar LG, Cistron LG and MRLG). Two CVEs (CVE-2014-3927 and CVE-2014-3926) are common web vulnerabilities, three are simply web misconfigurations (CVE-2014-3928, CVE-2014-3929 and CVE-2014-3930) and the last one is a memory corruption in a third-party binary shipped in a Looking Glass installation package. Below you can find the list of these issues:

  • CVE-2014-3927: Remote command injection in router's console via "argument" parameter
  • CVE-2014-3926: XSS in <title> via "addr" parameter
  • CVE-2014-3928: Unsafe configuration file path/ACL
  • CVE-2014-3929: Unsafe SSH keypairs path in default config
  • CVE-2014-3930: Unsafe configuration file path/ACL
  • CVE-2014-3931: Remote memory corruption in fastping (SUID binary)

The Snort way

Talos wrote six Snort rules to address all the above issues. The rules for the web misconfigurations prevent the attacker to retrieve the configuration file or list the configuration directories (have a look at sid:31709, sid:31708 and sid:31727 for all the details). The memory corruption bug referenced by CVE-2014-3931 should be avoided by sid:31767, only the default ICMP Echo Reply payloads are allowed. The web vulnerabilities are addressed by sid:31741 and sid:31766, these rules provide the missing input sanitization and should avoid basic exploitation attempts.

We recommend that all Snort users running the affected Looking Glass software deploy the mentioned rules.

Tuesday, September 9, 2014

Microsoft Update Tuesday September 2014: another generally light month but with a significant IE bulletin

This month’s Microsoft Update Tuesday is pretty light save for the Internet Explorer bulletin. While there’s only a total of 4 bulletins, they cover a total of 42 CVEs. The IE bulletin, as is usual, has the most updates for bugs and is rated critical. It covers a total of 37 CVEs. The other three bulletins are rated as important and provide updates for the remaining five vulnerabilities.

MS14-052 is the IE bulletin and is rated critical. It covers a total of 37 CVEs. Of these 37 CVEs, 36 are remote code execution vulnerabilities, the other one is an information disclosure vulnerability (CVE-2013-7331). This last vulnerability is publicly known and under active exploitation. This vulnerability allows attackers to use Microsoft’s XMLDOM ActiveX object to gain information on local drive and network settings. The attack can be used to detect if files or folders are present on the machine due to different error messages being returned depending on if the files or folder exist or not. An attacker can similarly figure out internal IP addresses using this vulnerability. The remaining 36 vulnerabilities are mostly the result of use-after-free vulnerabilities.

The three remaining bulletins are all rated as important:

Bulletin MS14-053 deals with a single CVE (CVE-2014-4072) in .NET. The vulnerability results in a Denial of Service. This is due to a hash collision that can be exploited by an attacker, which will result in resource exhaustion.

CVE-2014-4074 is fixed by bulletin MS14-054, it deals with a vulnerability in the Windows Task Scheduler that could allow a logged on user to schedule a task that would run code at the system level.

The final bulletin is MS14-055 and fixes three vulnerabilities in Lync. Two of the vulnerabilities, CVE-2014-4068 and CVE-2014-4071, could result in Denial of Services. An attacker could create a legitimate meeting and then modify the SIP information, which would result in a DoS on the Lync server. The third vulnerability that is covered by this bulletin is CVE-2014-4070 and can result in information disclosure due to a Cross Site Scripting (XSS) vulnerability on the server.

To address these issues, Talos has the following SIDs:  29821-29822, 30110-30113, 31782-31797, 31799-31802, 31811-31812

Monday, September 8, 2014

Threat Spotlight: "Kyle and Stan" Malvertising Network Threatens Windows and Mac Users With Mutating Malware

This post was authored by Shaun Hurley, David McDaniel and Armin Pelkmann. Malware was discovered by Richard Harman.

Update 2014-09-22: Updates on this threat can be found here

Have you visited,,,, or any of the 74 domains listed below lately? If the answer is yes, then you may have been a victim to the "Kyle and Stan" Malvertising Network that distributes sophisticated, mutating malware for Windows and even Macs.

Table of contents

Attack in a Nutshell
Technical Breakdown
Reversing of the Mac Malware
Reversing of the Windows Malware
Protecting Users Against These Threats

Malvertising is a short form for "malicious advertising." The idea is very simple: use online advertising to spread malware.

Friday, September 5, 2014

Danger at the Retail Point of Sale

This blog post was authored by Martin Lee and Jaeson Schultz.

With the announcement that yet another major retailer has allegedly been breached, it is important to review how attackers compromise retail systems and how such intrusions can be prevented. In this latest case, retailers are working to determine if a large cache of credit card information offered for sale on an underground trading forum originated as a result of a systems breach.

The presence of large amounts of financial and personal information within retail systems means that these companies are likely to remain attractive targets to attackers. Illicit markets exist for such information so that attackers are able to easily monetize stolen data. Although we don’t know the details of this specific attack, it may follow the same pattern as other major breaches in the retail sector. Incidents involving Point of Sale (POS) malware have been on the rise, affecting many large organizations.

In addition to the risk of fraud to the individuals affected, the consequences for the breached organizations are severe. News of customer data theft not only damages the brand, but recovering from the breach can also cost into the millions of dollars as systems are investigated, cleaned, repaired, and new processes are implemented to prevent future similar attacks.

POS Attack

Thursday, September 4, 2014

Malware Using the Registry to Store a Zeus Configuration File

This blog was co-authored by Andrea Allievi. 

A few weeks ago I came across a sample that was reading from and writing a significant amount of data to the registry. Initially, it was thought that the file may be a binary, but after some analysis it was determined that the file is a configuration file for Zeus. Within this blog post we take a look at our analysis of the data I/O in the registry.

Initial Stages of Infection

The scope of this paper is the analysis of the registry write. This section is a brief overview of what happens when the malware is executed.
  1. Unpacks
  2. Creates a copy of itself in the tmp directory
  3. Injects itself into explorer.exe
  4. Starts a thread that executes the injected code

The code injected into Explorer.exe becomes the focus of our analysis. To get started, an infinite loop was added to the entry point of the injected code and Ollydebug was used to attached to Explorer.exe. Debugging injected code in this manner was previously covered here.


Registry Key Names
After attaching the debugger and prior to continuing execution, a breakpoint is set on Advapi32.RegSetValueExW() before the large data write is made. This breakpoint is tripped multiple times by multiple threads within Explorer.exe. Most of the time the threads are related to the injected ZBot code.

It turns out that the same thread is used consistently for writing to this registry key.  Several sub-keys are created to store data that the application uses at a later time.The names of the sub-keys are created using an index value that is combined with other data to appear random. For instance, the key “2f0e9h99” was created by combining a hash of the User SID with the index value 0x9A. Throughout this paper, the registry key will be referenced by either name or index.

A Series of Registry Writes

This section establishes a pattern to the registry activity that can be used to help figure out what the malware is accomplishing with the registry I/O. The registry activity centers around writing to the following key:
  • HKUSERS\<sid>\Software\Microsoft\Ujquuvs.

The “ujquuvs” is dynamically generated by the application and will change between executions.

zbot-regdata-prior to initial large data write.png
Ujquuvs Registry Key Prior to 

Prior to the first registry write of interest the Ujquuvs sub-key contains the values shown in the above graphic. Throughout this section we’ll see that new value names are generated and data is cycled between the keys.

One of the first chunks written to the registry value 2f0e9h99 is a binary string that is 475 bytes in length. The following graphic shows the call to the Windows Advapi32.RegSetValueExW() procedure made by the malware.

RegSetValueExW() Stack

First Registry Write to 2f0e9h99

The above graphic displays the binary string data that was written to the registry. Although 475 bytes is a significant chunk of data written to the registry it is not what caused an alarm. The registry write I am looking for is greater than 3000 bytes. 

Second Registry Write to 2f0e9h99
Another 475 byte write occurs, but the data is different than the first write. It is worth noting that although the data is different the first four bytes appear to be the same “5D BB 95 50” pattern. This may be a header used to distinguish the data.

The next call to RegSetDataExW will write 3800 bytes to the registry.  The binary data was replaced with alphanumeric data (possibly base64). Another assumption can be made. The original binary data is encoded and then stored back to the registry.

Alphanumeric Data Written to 2f0e9h99

This is one of the large data writes that was flagged by the sandbox. Continuing on we see several more data writes all of which are variations of the above. The data cycles between binary strings and alphanumeric strings, and the string lengths vary. One of the largest data writes was an 7200 byte alphanumeric string.

Registry Reads

Along with the registry writes there are usually corresponding registry reads. The data located in 2f0e9h99 is pulled into a buffer and manipulated by the application.

Once the data is read, decoded from alphanumeric encoding to a long list of 475 byte chunks of binary data. These chunks of data contain a hash to identify specific chunks within the list. Whenever a new chunk of data is received the data contained in 2f0e9h99 is decoded and the hash value of the received chunk of data is compared against each chunk that exists already within the registry. If these hash values match, then the that registry data chunk is replaced with the incoming data. Otherwise the data is appended to the bottom of the list.

Once the  input queue is empty the calls to read or write to the registry stop. The thread has not been killed, but it is (most likely) suspended until some event occurs.

The next section combines these findings with further analysis to track down the source of the registry writes.

ZBotThread_1 Procedure

Walking through the executable with a debugger led us to the source of the registry writes. A thread is created and starts executing the code at address 0x41F579. From here on out this code is going to be referred to as ZBotThread_1(). This procedure is the backbone for all activity related to this registry key.

Network Socket Loop

After  several instructions for initializing various data structures, ZBotThread_1() initializes a network socket to communicate with a remote server.  Once traffic is received the IP address is verified against an IP blacklist of network address ranges that exists within a data structure used throughout the application. These IP Address ranges appear to be owned by various AV vendors (indicated here). Here is the list of blacklisted address ranges with the corresponding netmasks:
Once the IP address is verified the payload is decrypted and the data is initialized into the following data structure (sub_41F9C6):


Throughout this post we will refer to this as ZBOT_SOCKET_DATA. Each datagram payload contains this data structure. The lpDataBuff points to a buffer that contains the data that will eventually be written to the registry.

In addition, the dataBuffHeader[0x2C]  contains the first 44 bytes of the decrypted received data. These bytes contain critical information about the entire data chunk.

After a few checks to verify the integrity of the data, ZBotThread_1 calls AnalyseSockDataAndUpdateZBot (sub_43D305). This function will take the 20 byte hash of the data contained within the data chunk header (first 44 bytes) and compares it against a list of other hashes. This list of hashes is built out of previously received datagrams.  If the hash is part of the list then the data is dropped. Otherwise, the hash is appended to the end of the list.

 Next, AnalyseAndFinalizeSockData (sub_41D006) is called to begin the process of adding the data to the registry. Once inside the function, the data type (dataBuffHeader+0x3) is checked. There are several different data types, but the one that is relevant for the purposes of this blog post is type 0x6. This signifies the end of the data stream and the malware can proceed to save the data to registry key 2f0e9h99

The type 0x6 code branch calls VerifyFinalSckDataAndWriteToReg (sub_436889). This function strips the 0x2C length header from the socket data before verifying the integrity using RSA1.

Finally, if the data integrity is good, the WriteSckDataToReg function is called.

Writing Socket Data to the Registry

The previously received socket data has already been written to registry key 2f0e9h99. At this point, the socket data needs to be merged with the data contained within the registry key. Before this can occur, the data is currently alphanumerically encoded (see the registry write section above). The decoded data is a series of 0x1D0 hex byte chunks. Each chunk is a ZBOT_SOCKET_DATA structure.

encoded data structure.png
Alphanumeric Encoded Data in Memory

The hash of the socket data is compared against the hash of each chunk contained within the list of chunks. If the hashes match, then that registry data chunk is replaced with the network socket data. Otherwise the network socket data is appended to the end of the list.

Once the update is completed the registry data is (once again) alphanumerically encoded and written back to the 2f0e9h99 registry key.
It’s worth noting that our sample dropper can encode the original data in several different ways: Base64, and 3 customized XOR algorithms (see function at VA 0x4339DE for all the details).


Using the registry as a way to store and update a configuration is a clever idea. The multiple writes and reads that come with constructing the file with a registry key will raise alarms. It’s what originally grabbed our interest.

This blog post covers a small percentage of the functionality of this malware sample. Some of the functionality that we uncovered denote a high level of sophistication by the author. We strongly encourage others to download a copy and crack open their debuggers.

Sample MD5 Hashes:
     Dropper: 15136D615297C16D1FED67F2A8C11C37
     Injected Code: B4A00F4C6F025C0BC12DE890A2C1742E

Wednesday, August 20, 2014

Discovering Dynamically Loaded API in Visual Basic Binaries

Performing analysis on a Visual Basic (VB) script, or when Visual Basic is paired with the .NET Framework, becomes an exercise of source code analysis. Unfortunately when Visual Basic is compiled to a Windows Portable Executable (PE) file it can become a nightmare for many malware analysts and reverse engineers.

Why is it used by malware?

Visual Basic binaries have a reputation for making an analysts job difficult due to the many aspects of its compilation that differ from standard C/C++ binaries. To analyze a VB PE binary it helps to be familiar with the VB scripting syntax and semantics since their constructs will appear throughout the binary's disassembly. VB binaries have their own API interpreted by Microsoft's VB virtual machine (VB 6.0 uses msvbvm60.dll). Many of the APIs are wrappers for more commonly used Win32 APIs leveraged from other system DLLs.

Reverse engineering VB binaries will often involve reverse engineering VB internals for various VB APIs, a task dreaded by many. The entry point of a VB program diverts from the typical C/C++ or even Borland Delphi binary. There is no mainCRTStartup or WinMainCRTStartup function that initializes the C runtime and calls the developer defined main or WinMain function. Instead the Entry Point (EP) looks like this:

     004014A4 start:
     004014A4                 push    offset dword_40159C
     004014A9                 call    ThunRTMain
     004014A9 ; -----------------------------------------------------------------
     004014AE                 dw 0
     004014B0                 dd 0
     004014B4                 dd 30h, 40h, 0
     004014C0                 dd 0E8235672h, 403451C6h, 0AAF1D6B9h, 88BB31A6h, 0

The call to ThunRTMain is just wrapper to call VB API (msvbvm60!ThunRTMain). The only argument to ThunRTMain is the address of an object. This structure is documented in several places online and Reginald Wong developed an IDA Pro IDC script ( to parse the structure and label its members within the IDB. This will aid in understanding the objects used within the binary and their corresponding methods.

At this point it becomes an exercise of understanding the VB program based on the VB APIs used (there are some caveats, e.g. calls to Zombie_AddRef). Generally, VB programmers will have access to all the functionality they need through msvbvm60.dll, however, it is is possible to dynamically load API not available within the VB API through the DllFunctionCall function. The name implies the function will call the supplied function within a DLL, but this is not true.

How does it work?

DllFunctionCall takes in a structure that defines the wanted library and exported function, loads the library specified into memory, locates the address of the function provided, and returns the address. To know this we have to dive into the VB engine. Opening msvbvm60.dll in IDA Pro and navigating to the disassembly for DllFunctionCall we are met with a fairly small function (See figure DllFunctionCall graph). Within the first code block we see a call to sub_7342A127 with arg_0 as its first argument. At this point, all we know is DllFunctionCall has one argument that should provide (at a minimum) the library and export name. Based on what we currently know we can define our structure:

    typedef struct _DllFunctionCallStruct {
        void * lpLibraryOrExportName;
        void * lpExportOrLibraryName;
    } DllFunctionCallStruct;

IDA Pro Graph View of msvbvm60!DllFunctionCall

Going to the Structures window I created the structure, changed DllFunctionCall and sub_7342A127 function headers to reflect that arg_0 is typed as a DllFunctionCallStruct * and rename arg_0 in both functions to "struct". By examining sub_7342A127 we see this is where all the work happens (See sub_7342A127 function graph).

IDA Pro Graph View of msvbvm60!sub_7342A127

Analyzing the disassembly within sub_7342A127 we see our DllFunctionCallStruct structure assigned to ESI (first red box in figure sub_7342A127 part 1 below) and our assumptions of its composition is incorrect. The second red box highlights a new, unknown, member within our DllFunctionCallStruct structure. A new structure member is accessed at offset 0x0C (12) and saved into EDI (or &DllFunctionCallStruct + 0x0C).

IDA Pro Text View of msvbvm60!sub_7342A127 Part 1
msvbvm60!sub_7342A127 part 1

The new member is accessed at 0x7342A14A (first red box in figure sub_7342A127 part 2 below), however, it is accessed via an offset and a dereference. This tells us the new member at offset 0x0C is a pointer to a value, most likely a structure, with its own members (e.g. a member at offset 4). The call to LoadLibraryA (second red box in figure sub_7342A127 part 2 below) helps to fill in some of the assumptions we have made so far concerning DllFunctionCallStruct.

IDA Pro Text View of msvbvm60!sub_7342A127 Part 1
msvbvm60!sub_7342A127 part 2

The first member of DllFunctionCallStruct (&DllFunctionCallStruct + 0) must be a pointer to a character array containing the library name to be loaded (e.g. "kernel32.dll), thus the second member is a pointer to the string representing the exported function (e.g. “CreateFileA”). Finally, EDI is used to save the return value of LoadLibraryA (third red box in figure sub_7342A127 part 2 above), corroborating our suspicion that EDI is a structure. Below we create a new structure DynamicaHandles and rewrite DllFunctionCallStruct:
            typedef struct _DynamicHandles {
    0x04    HANDLE hModule;
            } DynamicHandles;

            typedef struct _DllFunctionCallStruct {
    0x00        LPCSTR lpDllName;
    0x04        LPTSTR lpExportName;
    0x0C        DynamicHandles sHandleData_unk;
            } DllFunctionCallStruct;

Continuing our analysis we confirm DllFunctionCallStruct + 4 is a pointer to the exported function name. However, we also see that DllFunctionCallStruct contains a byte at offset 0x0A (10) that is used for the comparison at 7342A16C. Examining both possible branches it becomes clear that this byte is significant for the function to determine if GetProcAddress is being called with the exported function's string representation or the export function's ordinal. After GetProcAddress is called arg_8 is used to save the value (arg_8 will be renamed to fnAddress) and its value is saved into the DynamicHandles structure at offset 8.

IDA Pro Text View of msvbvm60!sub_7342A127 Part 3
msvbvm60!sub_7342A127 part 3

Piecing this together DllFunctionCall argument is the structure defined below:
            typedef struct _DynamicHandles {
    0x00        DWORD dwUnknown;
    0x04        HANDLE hModule;
    0x08        VOID * fnAddress
            } DynamicHandles;

            typedef struct _DllFunctionCallStruct {
    0x00        LPCSTR lpDllName;
    0x04        LPTSTR lpExportName;
                // 4 bytes means it is a LPTSTR *
                // 2 bytes means it is a WORD (the export's Ordinal) 
    0x0A        char sizeOfExportName;    
    0x0C        DynamicHandles sHandleData;
            } DllFunctionCallStruct;

Putting it all Together

Great, we understand enough of the structure passed into DllFunctionCall, but how does this benefit us? It will aid us in locating dynamically loaded API functions in a VB binary. Most VB binaries making use of DllFunctionCall will have wrapper functions that follow this format:
          mov     eax, dword_ZZZZZZZZ
          or      eax, eax
          jz      short loc_XXXXXXXX
          jmp     eax
          push    YYYYYYYYh
          mov     eax, offset DllFunctionCall
          call    eax ; DllFunctionCall
          jmp     eax
The memory address 0xYYYYYYYY represents the address of the DllFunctionCallStruct. This structure is usually saved as a global variable. The sHandleData field within the DllFunctionCallStruct points to another global variable in memory. The fnAddress field within the DynamicHandles structure is accessed directly via the offset dword_ZZZZZZZZ. If the exported function has not been loaded into memory yet then DllFunctionCall will be invoked, thereby populating the value stored at dword_ZZZZZZZZ, and any sequential calls will directly call the exported function.

In malware, dozens or even hundreds of these wrapper functions can be found. Going through each reference to DllFunctionCall, applying the DllFunctionCallStruct and DynamicHandles structures, labelling the structure and direct address to the fnAddress field, and defining/renaming the function is a lot of work. To get around this cumbersome task I've created a IDA Python script that will perform these monotonous tasks and print out a listing of all the dynamically loaded API used by the binary.

As an example, a VB compiled binary may contain the below undefined section of code (see figure Undefined Code below). Note that IDA Pro was unable to make a function out of this set of instructions, didn’t interpret “push 4038D8h” as an offset within the binary, and didn’t recognize the ASCII string or offset to it starting at virtual address 0x004038CC.

IDA Pro Text View of undefined DllFunctionCall wrapper
Undefined Code

After the IDA Python script runs, the disassembly is cleaned up, a function is defined, the structures are applied, offsets are labeled, strings are defined, and appropriate names are given to the function and global variables. This will be applied to all DllFunctionCall wrapper functions generated by the compiler.

IDA Pro Text View of Defined DllFunctionCall wrapper and structures after running IDA Python Script
Defined Code

The script is freely available and comes "as is," depending on your situation it may need to be altered. For example if the VB binary you are analyzing obfuscates the strings associated with library name or export name then the strings will need to be de-obfuscated first.

The script can be downloaded on our Github.