How Malicious Code Can Run in Microsoft Office Documents

One of the most effective methods of compromising computer security, especially as part of a targeted attack, involves emailing the victim a malicious Microsoft Office document. Even though the notion of a document originally involved non-executable data, attackers found ways to cause Microsoft Office to execute code embedded within the document. Below are 4 of the most popular techniques used to accomplish this.

VBA Macros

Support for executing code that’s embedded as a VBA macro is built into Microsoft Office. Once the victim opens the document and allows macros to run, this code can run arbitrary commands on the user’s system, including those that launch programs and interact over the network. The penetration testing tool Metasploit makes it relatively straightforward to generate payload that attackers could embed in an Office file as a VBA macro. (See one example by Chris Patten.)

Such macros can be included in “legacy” binary formats (.doc, .xls., .ppt) and in modern XML-formatted documents supported by Microsoft Office 2007 and higher. In either case, Office will present the user with a security warning, stating that macros have been disabled and offering to “enable content.” Social engineering techniques can persuade the victim to click the button that will allow the embedded macro to run and infect the system.

Payload of a Microsoft Office Exploit

Another way to execute malicious code as part of an Office document involves exploiting vulnerabilities in a Microsoft Office application. The exploit is designed to trick the targeted application into executing the attacker’s payload, which is usually concealed within the Office document as shellcode.

In this case, Microsoft Office has to be exploited to execute the attacker’s code. This is in contrast to the previous scenario, where the attacker takes advantage of macros, supported by Microsoft Office as a feature. For instance, vulnerability CVE-2012-0141, announced in May 2012, could allow the attacker to craft a malicious Excel file to include an exploit that would “take complete control of an affected system.”

Embedded Flash Program

Embedding a Flash program inside an Office document provides attackers yet another way to run malicious code on the victim’s system. In this case, the code within the Flash object run as soon as the victim opens the document without any warnings and without relying on exploits. This code is till subject to security restrictions imposed by Flash Player, so to perform escalated actions the code would need to exploit a vulnerability in Flash Player.

One example of this attack has been described by Mila on the Contagio blog. The malicious Word document “DOC Iran’s Oil and Nuclear Situation.doc” was sent to a victim as part of a targeted attack. The document contained a Flash object, as seen below. (See steps to manually embed a Flash object in an Office document.)

Attackers can embed Flash objects in Office documents using automated tools. manual steps to do this the Flash object instructed Flash Player to download and play an MP4 file that was designed to exploit the CVE-2012-0754 vulnerability in Flash Player, announced in February 2012. This allowed the attacker to infect the victim’s system with a malicious Windows executable (trojan).

Embedded JavaScript

Another way to automatically execute code then the victim opens a Microsoft Office document involves embedding the ScriptBridge ActiveX control in the file. This control allows the attacker to embed and execute JavaScript, as was the case with the malicious “World Uyghur Congress Invitation.doc” file I obtained from the Contagio blog. This file used the “Microsoft Scriptlet Component”, implemented as the ScriptBridge ActiveX control to execute the embedded JavaScript code.

This Word file used ScriptBridge to execute embedded JavaScript code, which downloaded a malicious Flash file by from the specified URL. Microsoft Office automatically invokes embedded ActiveX controls that are marked Safe-For-Initialization, which is the case with ScriptBridge. (I’d love to better understand how ScriptBridge is being used to run JavaScript, so if you have more details, please let me know.)

In the case of this Word document, the downloaded Flash file was crafted to exploit the CVE-2012-0779 vulnerability in Flash player, announced in May 2012.

These are some of the techniques that intruders have used to execute code in Microsoft Office documents to compromise the system. The attacker could directly take advantage of a vulnerability in the targeted Office application. In other cases, the attacker uses functionality provided by Microsoft Office to either trick the user into allowing the malicious code to run (VBA macros) or to use a weakness in Office settings to run code that exploits vulnerabilities in other applications (Flash Player).

— Lenny Zeltser

An Example of SMS Text Phishing

Phishing—a technique grounded in social engineering—remains an effective way for attackers to trick people into giving up sensitive information. Potential victims can be contacted by email, fax, phone calls and SMS text messages. Below is an example of such a scam sent through SMS—a practice sometimes called smishing.

In this case, the recipient is requested to visit update.vtext02.net to update account information, supposedly so that he or she can continue using Verizon services.

The phone number of the SMS message’s sender was most likely spoofed.

The malicious domain vtext02.net appears to have been shut down by its registrar several hours after the phishing text message was received. When it was still active, the victim visiting the link on the SMS message would have seen the following page that mimicked the Verizon Wireless website:

All elements of this page were unclickable images with the exception of the form that prompted the victim for his or her Verizon account credentials. The “Sign In” button would submit the data to the phisher’s server-side confirm.php script. Here’s an excerpt from the page’s HTML code:

A similar incident was publicly described by another person about a month earlier. In that case, the sender was being directed to another malicious URL. The phishing SMS message stated “V.erizon.wireless.update. Please click on http:// verizon.vtext-1.com and proceed.” (Don’t go there.)

Mobile phone users are especially vulnerable to social engineering scams. One of the reasons for this, as pointed out by ESET’s Randy Abrams, is that “virtually none of the visual indicators that help even a moderately savvy novice computer user make informed decision are present on mobile devices.”

Russ Klanke documented the steps for reporting a suspicious SMS message to the GSMA Spam Reporting Service by sending a text to short code 7726 (SPAM).

Hand-picked related articles:

• The Use of Social Engineering by Mobile Device Malware
• The Changing Landscape of Malware for Mobile Devices

— Lenny Zeltser

8 Reasons for Denial-of-Service (DoS) Attacks

Denial of Service attacks (DoS) affect numerous organizations connected to the Internet. They distrupt normal business operations, are practically impossible to prevent and are costly and time-consuming to handle. It pays to spend some time understanding the way a DoS inicident might affect your organization and how you might handle the situation.

One way to start thinking about your ability to withstand and respond to DoS attacks is to consider why such incidents occur. The common reasons include the following:

• Extortion via a threat of a DoS attack: The attacker might aim to directly profit from his perceived ability to disrupt the victim’s services by demanding payment to avoid the DoS attack.

• Turf wars and fights between online gangs: Groups and individuals in engaged on Internet-based malicious activities might use DoS as weapons against each others’ infrastructure and operations, catching legitimate businesses in the cross-fire.

• Anti-competition business practices: Cyber-criminals sometimes offer DoS services to take out competitor’s websites or otherwise disrupt their operations.

• Punishment for undesired actions: A DoS attack might aim to punish the victim for refusing an extortion demand or for causing disruption to the attacker’s business model (e.g., spam-sending operations)

• Expression of anger and criticism: Attackers might use the DoS attack as a way of criticizing the affected company for exhibiting undesirable political, economic or monetary behaviors.

• Training ground for other attacks: Attackers sometimes might target when fine-tuning DoS tools and capabilities for future attacks, which will be directed at other victims.

• Self-induced: Some downtime and service disruptions are the result of the non-malicious actions that the organization’s employees took by mistake.

• No apparent reason at all: Many victims never learn why they experienced a DoS attack.

Handling a DoS incident involves operating under stressful circumstances, often with limited resources and time. To learn how to prepare for dealing with a DoS attack and what to do if you’re caught unprepared, see my Network DDoS Incident Response Cheat Sheet.

— Lenny Zeltser

5 Events in 2011 That Challenged Online Security and Trust Assumptions

2011 is only three-quarters through. Yet, so much has already happened in the world of infosec this year that I’d like to start thinking about the events that have challenged our online security and trust assumptions.

• Data breach at RSA allowed attackers to compromise aspects of the SecurID product and led to compromises of defense contractors and possibly other firms. Until this incident, the effectiveness of SecurID specifically and token-based authentication in general as a security control was rarely, if ever, questioned.

• Data breach at the CA company DigiNotar allowed the attacker to issue illicit digital certificates for popular sites such as Google, Microsoft, AOL and many others. The certs, when used in a man-in-the-middle scenario, allowed attackers to stealthily snoop and modify the traffic that victims exchanged with these sites. The incident highlighted some of the limitations in the CA-based SSL trust model of the web.

• A surge in MacDefender malware for OS X, and the ease with which this rogue antivirus program spread demonstrated that OS X was also vulnerable to infections. While Apple issued software updates in attempts to curtail the spread of MacDefender, the company’s arguably slow response hinted on the company’s relative inexperience at dealing with such incidents.

• The appearance of ZeuS malware modules for mobile devices allowed attackers to intercept SMS authentication codes. By infecting both the victim’s PC and mobile phone, the attackers obtains victims’ banking logon credentials from the infected computer and could collect one-time authentication codes transmitted to their phones. This development highlighted the limitation of relying on the phone as the foolproof authentication token.

• The re-emergence of malicious hacking groups that compromised data for political and other causes or just for fun highlighted the diversity and vulnerability of potential targets. (Anonymous and LulzSec are the most prominent examples of such groups.) Their attack campaigns have caused many organizations that were complacent in their perspective on information security to reexamine their infosec posture.

These events are acting as catalysts for changing the threat models we use to secure data, networks and applications. If there were other critical events that I failed to list, please leave a comment. What will the remainder of 2011 bring? We’ll know soon enough.

Hand-picked related items:

• Similarities Between Riots and Modern Internet Hacktivism
• Evolving Threats: The Long Tail of Potential Data Breach Victims
• Could a Data Breach Actually Help the Affected Brand?

— Lenny Zeltser

Malvertising: Dealing With Malicious Ads - Who and How?

My earlier posts presented malvertising examples and explored how malicious ads work and how they get deployed and protected. This note consider what might be done to handle the threats of malicious ads. Who can and should deal with this issue?

Spotting Malicious Ad Campaigns

Recommendations for ad networks for spotting potential malvertising campaigns include:

• Validate the integrity and authenticity of the entity wishing to place the ad by reviewing their credentials and documentation and by conducting a background search with financial review companies. Unfortunately, the documents are easily faked and review companies provide very limited coverage.
• Research advertisers with domain registry lookup tools looking for red flags, such as concealed contact details, recently-created or modified records or the use of webmail email addresses for domain contacts. This seems quite practical to me.
• Examine Flash ads with analysis tools, such as automated analyzers or web proxies. Unfortunately, the authors of malicious Flash ads are very good at concealing malicious logic, making it very hard to examine these programs to identify malware characteristics. (Perhaps ad networks could refuse accepting Flash ads with scripts that seem obscure or obfuscated.)
• Watch out for social engineering tricks, such as willingness to pay for the full campaign in cash, placing orders at the last moment or maintaining contact at odd hours. This is hard to do, considering how persuasive social engineers can be. Moreover, ad networks’ sales people might prefer to get paid and deal with the potential malvertisement later, rather than saying “no” to a new customer.

These practices are either not being followed or are ineffective, given the apparent popularity and effectiveness of malicious ads.

Who Can Deal With Malvertisements?

In an article that explored who should kill off malvertisements, Trend Micro’s Rik Ferguson pointed out that “website owners and ad networks alike suffer embarrassing brand damage when their customers are infected.” However, I am not sure brand tarnishing provides sufficient incentives to motivate companies to address the problem:

1. A website might suffer embarrassment when displaying a malicious advertisement;
2. The site apologizes and points a finger at the ad network that served the ad;
3. The network apologizes and disables the offending advertisement;
4. The world moves on and forgets about the incident after a few days.

Moreover, ad networks probably keep the money they were paid for the campaign that turned out to be malicious. This creates an incentive to look the other way even when the ad network’s sales staff notices red flags when processing the campaign.

The Role that Enterprises and Individuals Can Play by Blocking Ads

When describing his experience supporting LAN operations for about 4 years, Michael Robinson observed that the majority of malware infections in that environment occurred through malvertisements. In response, the company’s firewall engineers:

“Created rules to block traffic from 20 specific advertisers. By blocking only these sites, the number of malware infections on the LAN dropped by over 80%.”

If blocking ads is as effective as what Michael experienced, then by adopting this practice on a larger scale—at the level network level as well as on individual workstations—organizations might create powerful incentives for ad networks to work more rigorously as investigating, identifying and responding to malvertising campaigns.

For now, individuals and organizations can minimize their exposure to malvertisements by minimizing their exposure to banner ads. Also, the standard practices for combating social engineering scams, client-side exploits and malware apply when dealing with the threat of malicious ads.

This note is part of a series of malvertising-related posts. You can also learn:

• Examples of Malicious Ad Campaigns
• The Mechanics of Malicious Ads
• How Malicious Ad Campaigns Are Protected
• How Malicious Ads Are Deployed

— Lenny Zeltser

Malvertising: How Malicious Ads Are Deployed

My earlier posts looked at examples of malvertising campaigns, explored how malicious ads function and how they are protected. This note examines how scammers deploy malvertisements into the world, making them appear on numerous desktops, laptops and mobile devices across the web.

Sometimes, attackers compromise the ad network’s IT infrastructure to distribute malvertisements. This allows the attacker to directly control what banner ads are displayed, offering the ability of serving malvertisements or modifying legitimate ads to include malicious code or destinations. This seems to have been the case in the Unanimis incident that affected websites such as the London Stock Exchange. According to SC Magazine, Unanimis confirmed that the malvertisements were the result of unauthorized access to their systems.

Another, perhaps more common approach to injecting malvertisements into the web ecosystem involves impersonating agencies that supposedly represent legitimate clients wishing to advertise. This approach involves attackers spending money to pay for the malicious ad campaign. (But it takes money to make money, right? In any case, they are probably paying with stolen funds.)

For example, a scammer contacted Gawker Media pretending to be a popular ad agency:

“I work with Automotive and Entertainment clients in Spark. First and foremost, we want to run a performance campaign for Suzuki across your network. Our budget to start is $25k+.”

In their phone and email interactions the scammer sounded professional and knowledgeable and was able to fool Gawker’s ad sales representatives into placing the accepting and displaying the ads that turned out to be malicious.

Sometimes attackers pretend to be associated with legitimate and well-known ad agencies. In other cases, attackers represent fake ad agencies pretending to represent legitimate clients who wish to launch an advertising campaign. They might even present the ad network with a falsified Letter of Mandate, claiming that the company being advertised authorized the ad agency to act on its behalf. For instance, SkyAuction.com reported the following incident according to the Spyware Sucks blog:

“We were contacted by another company today that were duped into hosting one of the fraudulent ads for a couple of days (which have since been taken down). It seems that the source of the ads is a company called NetMediaGroup (http://www.netmediagroup.net). They are claiming to represent us and even provided a fake letter of mandate.”

Attackers can deploy malicious advertisements by compromising the ad networks systems or by purchasing campaigns that distribute the malicious ads. These tactics allow attackers to run malicious code in browsers and applications of numerous users across the web, providing an effective initial attack vector.

This note is part of a series of malvertising-related posts. You can also learn:

• Examples of Malicious Ad Campaigns
• The Mechanics of Malicious Ads
• How Malicious Ad Campaigns Are Protected
• Dealing With Malicious Ads - Who and How?

— Lenny Zeltser

Malvertising: How Malicious Ad Campaigns Are Protected

My earlier posts looked at examples of malvertising campaigns and explored how malicious ads function. In this note I look at the efforts that scammers put into protecting their ad-based attack campaigns.

Attackers do their best to make it harder for the advertisement networks to distinguish between benign and malicious ads. Obfuscating the logic implemented as part of the ad’s code—both HTML/JavaScript and Flash/ActionScript—is one way to do this. For instance, here’s an excerpt from a malicious web page using obfuscated JavaScript to evade detection and complicate analysis:

The script executes in the victim’s browser, recreating the original script on the file and executing it to implement the client-side attack.

ActionScript included in malicious Flash ads can be obfuscated as well using a variety of techniques. One of these methods is implemented using a commercial (and non-malicious in itself) tool SWF Encrypt, rendering the code within a Flash program virtually unreadable.

Another approach to protecting a malvertising campaign is to time it to take place over the weekend. The ad is often scheduled to begin displaying on Friday evening, but the malicious logic isn’t activated until early Saturday morning. This timing is designed to make it less likely that the advertisement network’s employees will be able to detect and quickly react to the malicious nature of the ad, since the staff probably isn’t at work during the weekend.

Unfortunately, it often takes a long time for the malicious ad to be disabled. Dasient’s Q4 2010 Malware Update reported the average lifetime of a malvertising campaign being about 10 days. Interestingly, according to Dasient’s data, Thursday appears to be the least popular day for malicious ads.

Attackers protect malvertising campaigns by carefully timing when the advertisements begin exhibiting malicious characteristics and also by obfuscating the code that implements the ad’s logic. These actions make it difficult for ad networks and end-users’ tools to distinguish between legitimate and malicious advertisements.

This note is part of a series of malvertising-related posts. You can also learn:

• Examples of Malicious Ad Campaigns
• The Mechanics of Malicious Ads
• How Malicious Ads Are Deployed
• Dealing With Malicious Ads - Who and How?

— Lenny Zeltser

Malvertising: The Mechanics of Malicious Ads

My earlier post discussed examples of high-profile malvertising campaigns as a starting point for exploring the malicious practice of deploying ads to infect computers. This note digs into the mechanics of malicious ads to better understand how they function and what they do.

One approach to conducting a malvertising campaign involves an image ad that people click on to visit the advertised website. In this context, the advertised website turns out to be malicious in itself or redirects to a malicious site. For example, Kimberly from StopMalvertising described one malvertisement that took the person viewing or clicking on the ad to popadscdn.net, which redirected to pop.biyoetanol.net, which redirected to ad.amiadrugaddict.info, which eventually redirected to the Blackhole Exploit Kit hosted at 0d1.cz.cc.

If redirected to a site hosting an exploit kit, the victim’s system is subjected to one or more attacks on the browser or the software that the browser can invoke, such as Acrobat Reader or Java Runtime. The exploit kit’s code probes the victim’s browser environment to determine which vulnerability to attempt exploiting. Some of the malicious sites implement another approach, relying on social engineering to trick the visitor into installing malicious software.

Malicious ads might also take the form of Flash programs. Flash provides the attacker with the ability to use ActionScript to embed “business logic” directly into the ad. This allows attackers to incorporate more elaborate instructions that would execute in the victim’s browser as soon as the advertisement is displayed.

For instance, the Flash-based ad can incorporate logic that decides when to attack the user and whom to attack. The ad might trigger a malicious action on a particular date; this is typically done to delay the attack until after the advertising network examined and approved the ad. For instance, the ad can begin redirecting victims to a malicious site only during a weekend, and may decide to only go after people in a particular location.

The Flash advertisement’s logic may also evade detection by only attacking the user once—such ads typically use a cookie-like Local Shared Object (LSO) to avoid attacking the user if he has already been targeted. These and other techniques are described in the paper Analyzing and Detecting Malicious Flash Advertisements by Ford, Cova, Kruegel and Vigna.

Since Flash executes in the victim’s browser as soon as the ad is displayed, Flash/ActionScript-based malvertisements provide attackers with more flexibility than those based on HTML/JavaScript. Perhaps the future will bring malvertising campaigns where Flash-based ads usurp the victim’s CPU cycles to run computations, such as distributed password cracking. Another potential is to use the browser for Bitcoin mining; such operations are already possible using pure JavaScript, so an ActionScript version isn’t that far off.

Attackers take advantage of the ad’s nature to direct people to the advertised website by advertising websites that turn out to be malicious. They do this by modifying the ad’s destination after submitting it to the advertising network. Using Flash programs to implement the banner ad provides the attacker with additional control over the attack logic, because Flash can incorporate ActionScript that tends to be harder to examine than JavaScript.

This note is part of a series of malvertising-related posts. You can also learn:

• Examples of Malicious Ad Campaigns
• How Malicious Ad Campaigns Are Protected
• How Malicious Ads Are Deployed
• Dealing With Malicious Ads - Who and How?

— Lenny Zeltser

Malvertising: Some Examples of Malicious Ad Campaigns

Internet advertisement networks provide attackers with an effective venue for targeting numerous computers through malicious banner ads. Such malvertisements may take the form of Flash programs that look like regular ads, but contain code that attacks the visitor’s system directly or redirects the browser to a malicious website. Malicious ads can also be implemented without Flash by simply redirecting the destination of the ad after the launch of the campaign.

How are such campaigns conducted? What, if anything, can we do about them? We can begin making sense of malicious ad practices by examining some examples of high-profile malvertising incidents.

Rik Ferguson from Trend Micro described an incident when the New York Times was hosting a banner ad that attempted to social-engineer people into installing a rogue antivirus tool. According to Rik, “the problem may have been ongoing for upwards of 24 hours” before the New York Times noticed the malicious nature of the ad and disabled it.

In another example, the London Stock Exchange website was also observed inadvertently serving malicious ads to its users, as described by Paul Mutton. This incident was traced to a possible breach at Unanimis—the company serving the ads the London Stock Exchange and many other companies.

Elad Sharf from Websense analyzed the Unanimis malvertising incident that affected a number of high profile web properties. He noted that such malvertising campaigns are attractive to attackers because they “can be easily spread across a large number of legitimate Websites without directly compromising those Websites.”

Mary Landesman from ScanSafe/Cisco pointed out that the list of popular websites serving malicious ads in the recent years included Hoovers.com, USNews.com, Tucows.com, TheOnion.com, SpeedTest.net and many others. She also explained that malvertisements aren’t limited to a particular ad network; they’ve been “delivered via DoubleClick (Google), YieldManager (Yahoo!), and rad.msn.com (Microsoft),” and also through webmail services, such as Windows Live (Hotmail) and Yahoo! Mail.

Jiri Sejtko from Avast! also reported that large scale ad-networks are often responsible for delivering malvertisements. For one malvertising campaign tracked by Avast!, the most compromised services were YieldManager.com (Yahoo!) and Fimserve.com (FOX Audience Network), which delivered more than half of the malicious ads in that incident.

While most of the malvertising campaigns have affected users of web browsers, an incident involving Spotify showed that applications can be used as a similar attack vector. Patrik Runald at Websense described how Spotify, a music streaming service, was displaying a malicious ad to the users of its media-playing application. The app rendered the ad and its malicious code as if it were a browser without requiring user interaction. “If you had Spotify open but running in the background, listening to your favorite tunes, you could still get infected.”

The wide reach that attackers can have by delivering client-side attacks through advertisement networks—and the difficulty with which we’ve hard curtailing malvertising practices—suggests that this attack vector isn’t likely to disappear soon. We need to find a better way of dealing with it.

This is the first post a series of malvertising-related posts. You can also learn:

• The Mechanics of Malicious Ads
• How Malicious Ad Campaigns Are Protected
• How Malicious Ads Are Deployed
• Dealing With Malicious Ads - Who and How?

— Lenny Zeltser