Apr 25 2018

Global Malware Campaign Pilfers Data from Critical Infrastructure, Entertainment, Finance, Health Care, and Other Industries

McAfee Advanced Threat Research analysts have uncovered a global data reconnaissance campaign assaulting a wide number of industries including critical infrastructure, entertainment, finance, health care, and telecommunications. This campaign, dubbed Operation GhostSecret, leverages multiple implants, tools, and malware variants associated with the state-sponsored cyber group Hidden Cobra. The infrastructure currently remains active. (For an extensive analysis by the Advanced Threat Research team, see “Analyzing Operation GhostSecret: Attack Seeks to Steal Data Worldwide.”

The campaign is extremely complicated, leveraging a number of implants to steal information from infected systems and is intricately designed to evade detection and deceive forensic investigators. The implants vary considerably and although they share some functionality and code, they are categorized as different families. As McAfee Advanced Threat Research analysts investigated this campaign, we recognized many similarities to indicators used in the 2014 Sony Pictures attack.

A portion of this campaign aimed at the Turkish financial sector using the Bankshot implant was recently discovered by McAfee Advanced Threat Research analysts. This appears to have been the initial stage of Operation GhostSecret, as within days of publication, new attacks appeared  beyond the financial sector. Between March 14 and 18, we observed the data reconnaissance implant in organizations across 17 countries.

Delving further into this campaign reveals a narrow list of organizations across the globe; the threat actors have been explicit about who can connect from which IP address. Reviewing the WHOIS information for these IP addresses shows us that there is some correlation in geography, although there are no additional clues why these addresses were used.

As we monitor this campaign, it is clear that the publicity associated with the (we assume) first phase of this campaign did nothing to slow the attacks. The threat actors not only continued but also increased the scope of the attack, both in types of targets and in the tools they used. We try to avoid using the word sophisticated because it is both subjective and overused. Nonetheless, the attackers have significant capabilities, demonstrated by their tools development and the pace at which they operate.

Fighting cybercrime is a global effort best undertaken through effective partnerships between the public and private sectors. McAfee is working with Thai government authorities to take down the control server infrastructure of Operation GhostSecret, while preserving the systems involved for further analysis by law enforcement authorities. By creating and maintaining partnerships with worldwide law enforcement, McAfee demonstrates that we are stronger together.

The post Global Malware Campaign Pilfers Data from Critical Infrastructure, Entertainment, Finance, Health Care, and Other Industries appeared first on McAfee Blogs.

Apr 25 2018

Analyzing Operation GhostSecret: Attack Seeks to Steal Data Worldwide

McAfee Advanced Threat Research analysts have uncovered a global data reconnaissance campaign assaulting a wide number of industries including critical infrastructure, entertainment, finance, health care, and telecommunications. This campaign, dubbed Operation GhostSecret, leverages multiple implants, tools, and malware variants associated with the state-sponsored cyber group Hidden Cobra. The infrastructure currently remains active. In this post, we dive deeply into this campaign. For a brief overview of this threat, see “Global Malware Campaign Pilfers Data from Critical Infrastructure, Entertainment, Finance, Health Care, and Other Industries.”

Our investigation into this campaign reveals that the actor used multiple malware implants, including an unknown implant with capabilities similar to Bankshot. From March 18 to 26 we observed the malware operating in multiple areas of the world. This new variant resembles parts of the Destover malware, which was used in the 2014 Sony Pictures attack.

Furthermore, the Advanced Threat Research team has discovered Proxysvc, which appears to be an undocumented implant. We have also uncovered additional control servers that are still active and associated with these new implants. Based on our analysis of public and private information from submissions, along with product telemetry, it appears Proxysvc was used alongside the 2017 Destover variant and has operated undetected since mid-2017.

The attackers behind Operation GhostSecret used a similar infrastructure to earlier threats, including SSL certificates used by FakeTLS in implants found in the Destover backdoor variant known as Escad, which was used in the Sony Pictures attack. Based on our technical analysis, telemetry, and data from submissions, we can assert with high confidence that this is the work of the Hidden Cobra group. The Advanced Threat Research team uncovered activity related to this campaign in March 2018, when the actors targeted Turkish banks. These initial findings appear to be the first stage of Operation GhostSecret. For more on the global aspect of this threat, see “Global Malware Campaign Pilfers Data from Critical Infrastructure of Entertainment, Finance, Health Care, and Other Industries.”

Analysis

The McAfee Advanced Threat Research team discovered a previously unknown data-gathering implant that surfaced in mid-February 2018. This implant appears to be a derivative of implants authored before by Hidden Cobra and contains functionality similar to that of Bankshot, with code overlaps from other Hidden Cobra implants. However, the variant is not based on Bankshot. Our analysis of the portable executable’s rich-header data reveals that the two implants were compiled in different development environments. (The PE rich header is an undocumented part of a Windows executable that reveals unique information to identify the Microsoft compiler and linker used to create the program. It is helpful for identifying similarities between malware variants to establish common development environments.) Our analysis of the code and PE rich header indicates that Bankshot, Proxysvc, and the Destover-like implant are distinct families, but also contain overlapping code and functionality with current tools of Hidden Cobra.

PE rich header data from the 2018 Bankshot implant.

PE rich header data from the new February 2018 implant.

PE rich header data from Proxysvc.dll.

When we compared the PE rich header data of the new February 2018 implant with a variant of Backdoor.Escad (Destover) from 2014 shortly before the Sony Pictures attack, we found the signatures to be identical. The Destover-like variant is 83% similar in code to a 2015 variant and contains the same rich PE header signature as the Backdoor.Escad variant we analyzed. Thus the new implant is likely a derivative of components of Destover. We determined that the implant is not a direct copy of well-known previous samples of Destover; rather, Hidden Cobra created a new hybrid variant using functionality present in earlier versions.

2014 Backdoor.Escad (hash: 8a7621dba2e88e32c02fe0889d2796a0c7cb5144).

2015 Destover variant (7fe373376e0357624a1d21cd803ce62aa86738b6).

The February implant fe887fcab66d7d7f79f05e0266c0649f0114ba7c was obtained from an unknown submitter in the United States on February 14, two days after it was compiled. This Korean-language file used the control server IP address 203.131.222.83. The implant is nearly identical to an unknown 2017 sample (8f2918c721511536d8c72144eabaf685ddc21a35) except that the control server addresses are different. The 2017 sample used address 14.140.116.172. Both implants specifically use FakeTLS with PolarSSL, which we saw in previous Hidden Cobra implants. PolarSSL libraries have appeared in implants since the Sony Pictures incident and were used exclusively in the implant Backdoor.Destover. This implant incorporated a custom control server protocol that sends traffic over port 443. The implementation does not format the packets in standard SSL, but rather in a custom format and transmitted over SSL—hence, FakeTLS. The control server traffic when compared to Backdoor.Escad is nearly identical.

TLS traffic in Backdoor.Destover, the 2018 Destover-like variant.

TLS traffic in Backdoor.Escad.

Further research into IP address 14.140.116.172 leads us to additional hidden components involved in the overall infrastructure. Proxysvc.dll contains a list of hardcoded IP addresses, including the preceding address, all located in India. Despite the name, this component is not an SSL proxy, but rather a unique data-gathering and implant-installation component that listens on port 443 for inbound control server connections.

Proxysvc was first collected by public and private sources on March 22 from an unknown entity in the United States. The executable dropper for the component was submitted from South Korea on March 19. McAfee telemetry analysis from March 16 to 21 reveals that Proxysvc components were active in the wild. Our research shows this listener component appeared mostly in higher education organizations. We suspect this component is involved in core control server infrastructure. These targets were chosen intentionally to run Proxysvc because the attacker would have needed to know which systems were infected to connect to them. This data also indicates this infrastructure had been operating for more than a year before its discovery. The Advanced Threat Research team found this component running on systems in 11 countries. Given the limited capabilities of Proxysvc, it appears to be part of a covert network of SSL listeners that allow the attackers to gather data and install more complex implants or additional infrastructure. The SSL listener supports multiple control server connections, rather than a list of hardcoded addresses. By removing the dependency on hardcoded IP addresses and accepting only inbound connections, the control service can remain unknown.

The number of infected systems by country in which Proxysvc.dll was operating in March. Source: McAfee Advanced Threat Research.

The 2018 Destover-like implant appeared in organizations in 17 countries between March 14 and March 18. The impacted organizations are in industries such as telecommunications, health, finance, critical infrastructure, and entertainment.

The number of infected systems by country in which the Destover variant was operating in March. Source: McAfee Advanced Threat Research.

 

Control Servers

Further investigation into the control server infrastructure reveals the SSL certificate d0cb9b2d4809575e1bc1f4657e0eb56f307c7a76, which is tied to the control server 203.131.222.83, used by the February 2018 implant. This server resides at Thammasat University in Bangkok, Thailand. The same entity hosted the control server for the Sony Pictures implants. This SSL certificate has been used in Hidden Cobra operations since the Sony Pictures attack. Analyzing this certificate reveals additional control servers using the same PolarSSL certificate. Further analysis of McAfee telemetry data reveals several IP addresses that are active, two within the same network block as the 2018 Destover-like implant.

Number of infections by Thammasat Universityhosted control servers from March 1519, 2018. Source: McAfee Advanced Threat Research.

Implant Origins

McAfee Advanced Threat Research determined that the Destover-like variant originated from code developed in 2015. The code reappeared in variants surfacing in 2017 and 2018 using nearly the same functionality and with some modifications to commands, along with an identical development environment based on the rich PE header information.

Both implants (fe887fcab66d7d7f79f05e0266c0649f0114ba7c and 8f2918c721511536d8c72144eabaf685ddc21a35) are based on the 2015 code. When comparing the implant 7fe373376e0357624a1d21cd803ce62aa86738b6, compiled on August 8, 2015, we found it 83% similar to the implant from 2018. The key similarities and differences follow.

Similarities

  • Both variants build their API imports dynamically using GetProcAddress, including wtsapi32.dll for gathering user and domain names for any active remote sessions
  • Both variants contain a variety of functionalities based on command IDs issued by the control servers
  • Common capabilities of both malware:
    • Listing files in directory
    • Creating arbitrary processes
    • Writing data received from control servers to files on disk
    • Gathering information for all drives
    • Gathering process times for all processes
    • Sending the contents of a specific file to the control server
    • Wiping and deleting files on disk
    • Setting the current working directory for the implant
    • Sending disk space information to the control server
  • Both variants use a batch file mechanism to delete their binaries from the system
  • Both variants run commands on the system, log output to a temporary file, and send the contents of the file to their control servers

Differences

The following capabilities in the 2015 implant are missing from the 2018 variant:

  • Creating a process as a specific user
  • Terminating a specific process
  • Deleting a specific file
  • Setting file times for a specific file
  • Getting current system time and sending it to the control server
  • Reading the contents of a file on disk. If the filepath specified is a directory, then listing the directory’s contents.
  • Setting attributes on files

The 2015 implant does not contain a hardcoded value of the IP address it must connect to. Instead it contains a hardcoded sockaddr_in data structure (positioned at 0x270 bytes before the end of the binary) used by the connect() API to specify port 443 and control server IP addresses:

  • 193.248.247.59
  • 196.4.67.45

Both of these control servers used the PolarSSL certificate d0cb9b2d4809575e1bc1f4657e0eb56f307c7a76.

Proxysvc

At first glance Proxysvc, the SSL listener, looks like a proxy setup tool (to carry out man-in-the-middle traffic interception). However, a closer analysis of the sample reveals it is yet another implant using HTTP over SSL to receive commands from the control server.

Proxysvc appears to be a downloader whose primary capability is to deliver additional payloads to the endpoint without divulging the control address of the attackers. This implant contains a limited set of capabilities for reconnaissance and subsequent payload installations. This implant is a service DLL that can also run as a standalone process.

The ServiceMain() sub function of Proxysvc.

The implant cannot connect to a control server IP address or URL. Instead it accepts commands from the control server. The implant binds and listens to port 443 for any incoming connections. 

 

 

Proxysvc binding itself to the specified port.

Proxysvc begins accepting incoming requests to process. 

Proxysvc makes an interesting check while accepting connections from a potential control server. It checks against a list of IP addresses to make sure the incoming connection is not from any of the following addresses. If the incoming request does come from one of these, the implant offers a zero response (ASCII “0”) and shuts down the connection.

  • 121.240.155.74
  • 121.240.155.76
  • 121.240.155.77
  • 121.240.155.78
  • 223.30.98.169
  • 223.30.98.170
  • 14.140.116.172 

SSL Listener Capabilities

The implant receives HTTP-based commands from a control server and parses the HTTP Content-Type and Content-Length from the HTTP header. If the HTTP Content-Type matches the following value, then the implant executes the command specified by the control server:

Content-Type: 8U7y3Ju387mVp49A

HTTP Content-Type comparison with a custom implant value.

The implant has the following capabilities:

  • Writing an executable received from the control server into a temp file and executing it

Proxysvc writing a binary to a temp directory and executing it. 

  • Gathering system information and sending it to the control server. The system information gathered from the endpoint includes:
    • MAC address of the endpoint
    • Computer Name
    • Product name from HKLM\Software\Microsoft\Windows NT\CurrentVersion ProductName
    • This information is concatenated into a single string in the format: “MAC_Address|ComputerName|ProductName” and is sent to the control server
  • Recording HTTP requests from the control server to the temporary file prx in the implant’s install directory with the current system timestamp

Analyzing the Main Implant

The February 2018 implant contains a wide variety of capabilities including data exfiltration and arbitrary command execution on the victim’s system. Given the extensive command structure that the implant can receive from the control server, this is an extensive framework for data reconnaissance and exfiltration, and indicates advanced use. For example, the implant can wipe and delete files, execute additional implants, read data out of files, etc.

The implant begins execution by dynamically loading APIs to perform malicious activities. Libraries used to load the APIs include:

  • Kernel32.dll
  • Apvapi32.dll
  • Oleaut32.dll
  • Iphlpapi.dll
  • Ws2_32.dll
  • Wtsapi32.dll
  • Userenv.dll
  • Ntdll.dll

The main implant dynamically loading APIs.

As part of its initialization, the implant gathers basic system information and sends it to its hardcoded control server 203.131.222.83 using SSL over port 443:

  • Country name from system’s locale
  • Operating system version
  • Processor description from

HKLM\HARDWARE\DESCRIPTION\System\CentralProcessor\0 ProcessorNameString

  • Computer name and network adapters information
  • Disk space information for disks C: through Z: including total memory in bytes, total available memory in bytes, etc.
  • Current memory status including total physical memory in bytes, total available memory, etc.
  • Domain name and usernames based on current remote sessions

Domain name and username extraction using Win32 WTS APIs.

Data Reconnaissance

The implant receives commands over SSL as encoded data. This data is decoded, and the correct command ID is derived. Valid command IDs reside between 0 and 0x1D.

Switch case handling command execution based on command IDs.

Based on the command ID, the implant can perform the following functions:

  • Gather system information and exfiltrate to the control server (same as the basic data-gathering functionality previously described)
  • Get volume information for all drives on the system (A: through Z:) and exfiltrate to the control server

Gathering volume information.

  • List files in a directory. The directory path is specified by the control server.
  • Read the contents of a file and send it to the control server

Reading file contents and sending it the control server.

  • Write data sent by the control server to a specified file path

Open handle to a file for writing with no shared permissions.

Writing data received from control server to file.

  • Create new processes based on the file path specified by the control server.

Creating a new process for a binary specified by the control server.

  • Wipe and delete files specified by the control server

Wiping and deleting files.

  • Execute a binary on the system using cmd.exe and log the results into a temp file, which is then read and the logged results are sent to the control server. The command line:

cmd.exe /c “<file_path> > %temp%\PM*.tmp 2>&1”

Executing a command and logging results to a temp file.

  • Get information for all currently running processes

Getting process times for all processes on the system.

Getting username and domain from accounts associated with a running process.

  • Delete itself from disk using a batch file.

Creating a batch file for self-deletion.

  • Store encoded data received from the control server as a registry value at:

HKLM\Software\Microsoft\Windows\CurrentVersion\TowConfigs Description

  • Set and get the current working directory for the implant

Setting and getting the current working directory for the implant’s process.

The command handler index table is organized in the implant as follows:

The command handler index table.

Conclusion

This analysis by the McAfee Advanced Threat Research team has found previously undiscovered components that we attribute to Hidden Cobra, which continues to target organizations around the world. The evolution in complexity of these data-gathering implants reveals an advanced capability by an attacker that continues its development of tools. Our investigation uncovered an unknown infrastructure connected to recent operations with servers in India using an advanced implant to establish a covert network to gather data and launch further attacks.

The McAfee Advanced Threat Research team will provide further updates as our investigation develops.

Fighting cybercrime is a global effort best undertaken through effective partnerships between the public and private sectors. McAfee is working with Thai government authorities to take down the control server infrastructure of Operation GhostSecret, while preserving the systems involved for further analysis by law enforcement authorities. By creating and maintaining partnerships with worldwide law enforcement, McAfee demonstrates that we are stronger together.  

Indicators of Compromise

McAfee detection

  • Trojan-Bankshot2

MITRE ATT&CK techniques

  • Exfiltration over control server channel: data is exfiltrated over the control server channel using a custom protocol
  • Commonly used port: the attackers used common ports such as port 443 for control server communications
  • Service execution: registers the implant as a service on the victim’s machine
  • Automated collection: the implant automatically collects data about the victim and sends it to the control server
  • Data from local system: local system is discovered and data is gathered
  • Process discovery: implants can list processes running on the system
  • System time discovery: part of the data reconnaissance method, the system time is also sent to the control server
  • File deletion: malware can wipe files indicated by the attacker

IP addresses

  • 203.131.222.83
  • 14.140.116.172
  • 203.131.222.109
  • 203.131.222.83

Hashes

  • fe887fcab66d7d7f79f05e0266c0649f0114ba7c
  • 8f2918c721511536d8c72144eabaf685ddc21a35
  • 33ffbc8d6850794fa3b7bccb7b1aa1289e6eaa45 

The post Analyzing Operation GhostSecret: Attack Seeks to Steal Data Worldwide appeared first on McAfee Blogs.

Apr 17 2018

Despite Decline in Use of Adobe Flash, Vulnerabilities Will Continue to Cause Concern

This post was researched and written with the assistance of Tim Hux, Abhishek Karnik, Asheer Malhotra, and Steve Povolny

McAfee Advanced Threat Research team analysts have studied Adobe Flash Player for years because it is a popular target for attacks. As always, we advise customers to remain current with McAfee’s latest DAT versions. In this post we want to provide some insight into the history of Flash exploitation and possible future trends.

Morphisec published an analysis of a new set of Flash flaws, CVE-2018-4878, that have been exploited in the wild. Hardik Shah of McAfee Labs posted a technical analysis of CVE-2018-4878’s mechanisms on March 2:

“The number of Flash Player exploits has recently declined, due to Adobe’s introduction of various measures to strengthen Flash’s security. Occasionally, however, an exploit still arises. On January 31, Kr-Cert reported a zero-day vulnerability, identified as CVE-2018-4878, being exploited in the field. (Adobe has released an update to fix this flaw.)”

Details about McAfee protections covering CVE-2018-4878 appear at the end of this article.

This post will examine the history of Flash’s issues since the first Common Vulnerabilities and Exposures (CVE) list for Flash was published in 2006. By examining some of the data, both users and owners of sites that employ Flash can better understand Flash flaws and why Flash will continue to interest attackers, even though Adobe will discontinue development of Flash in 2020.

We examined historical Flash data regarding vulnerabilities. We also accounted for the current distribution and uses of Flash. Through this analysis, we believe that despite Adobe announcing Flash’s end of life, a number of sites will continue to use and depend upon Flash for at least the immediate future, even as sites convert to alternative technologies. (See the list of example sites, below.) Flash continues to offer attackers an exploitable collection of flaws for the immediate future.

The following chart uses CVE data. Although not every exploitable and exploited condition receives a CVE entry, most flaws that are discovered through security research or reported against major software vendors’ products eventually gains a CVE number that is posted to the CVE database kept by Mitre. Therefore, CVE offers a convenient repository of vulnerability data to aid research.

Searching the entire database for every instance of “Flash Player” or “Adobe Flash Player” returned 1,050 CVE entries from the years 2006-2017.

There was a steady increase in reported vulnerabilities between 2006 and 2014. Then we saw a big jump in 2015 and 2016. Of the 1,050 issues, about 79% (830) gave attackers some sort of code execution capability, though not every one of those 830 flaws allowed remote code execution. Still, an attacker gains a significant advantage from running any code. The McAfee Labs analysis shows that CVE-2018-4878 was another example of remote code execution, which usually leads to full compromise. This point suggests that Flash vulnerabilities will remain a significant target.

The data source CVE Details offers the following distribution of Flash CVE vulnerabilities:

Source: CVE Details.

In 2015 through 2017, 81% of flaws resulted in code execution of one form or another.

CVE Details also assigns Flash issues with Common Vulnerability Scoring System scores. Many issues from 2015–2017 earned scores above 9, which is considered severe.

  • 2015: 294 vulnerabilities ≥ 9
  • 2016: 224 vulnerabilities ≥ 9
  • 2017: 60 vulnerabilities ≥ 9

These severe scores further highlight why attackers remain interested in exploiting Flash weaknesses; they offer significant “attacker value” for the effort required to exploit them.  Looking at the historical distribution of issues, we see a spike in 2015. Then the spike drops off. It was in the latter part of 2014 that Adobe adopted a change in their software security strategy.

“’Finding and fixing bugs isn’t the way to go, it’s … making it harder and more expensive for [attackers] to achieve an outcome,” said Adobe’s Chief Security Officer, Brad Arkin, at a conference in October 2014. He urged organizations to stop patching every vulnerability and instead increase the cost of exploitation to frustrate attackers. “The bad guys aren’t stupid,” he added. “They are going to apply their resources in the [most] cost efficient way possible, and so they seek to minimize the cost of developing an exploit.”

Adobe’s shift in software security strategy has been to make exploiting issues prohibitively expensive so that attackers will find easier, less resource-intensive, and perhaps more reliable methods. Rather than chase every flaw, Adobe’s approach focuses on building defensive techniques that protect vulnerabilities, just as standard secure development life cycle techniques attempt to prevent new vulnerabilities from being released.

Little in software development happens immediately, especially on a large scale. There is typically a lag—usually one to two years—between a strategy shift and results. In any event, the first issues to be eliminated are often the easiest to fix. As the program’s effectiveness improves, resources are available to address harder problems.

Brad Arkin spoke about a strategy shift in the fall of 2014. We expected that shift to take time, and that is what we see in the data: In 2016, the number of newly discovered issues began to decline. However, the steep increase in vulnerabilities in 2015 and 2016 requires some additional examination.

When security researchers focus on a code base, they generally start by finding the easiest-to-discover issues. As these are found and fixed, researchers probe deeper, shifting to techniques that increase in difficulty. Due to this ever-increasing difficulty, we often see a decrease in discoveries; it takes more time and effort to uncover tricky issues.

Coupling the increasing difficulty of finding problems against the increase in effectiveness of a software security program, we find a distribution like what we have seen with Flash CVE reporting from 2015 through 2017. Until 2015, attackers exploited relatively easy-to-find cross-site scripting errors, but these largely disappeared after 2014. Suddenly, in 2015, there is a huge jump in the discovery of difficult-to-uncover memory issues and code execution opportunities. The leap in the CVE numbers reflects more technically challenging issues surfacing just as Adobe’s software strategy was making its shift.

The new strategy had not had time to be fully effective by 2015. Plus, Flash, like all complex software, carries a large amount of legacy code. Just when researchers were digging deeper and harder into the code base, Adobe’s software security change required not just chasing vulnerability fixes, but also generating protective code and designs—all of which take time to implement. This typical situation explains the influx of critical new issues in 2015, and their subsequent continuous reductions.

Still, no single or collection of security techniques is perfect. In 2017, Flash marked 70 new issues. So far in 2018, three have been discovered. The most recent, CVE-2018-4878, is technically challenging and appears to be within protections that Adobe has placed within byte arrays to prevent these memory structures from being misused. “[CVE-2018-4878] bypassed the byte array mitigation feature that was introduced to prevent ‘length corruption’ attacks in Flash,” wrote McAfee’s Hardik Shah in “How Hackers Bypassed an Adobe Flash Protection Mechanism.”

It is just as possible to unwittingly add an exploitation opportunity when implementing software protections as when writing any other code. Of the 73 vulnerabilities discovered in 2017 and 2018, there is no method, without tracking code changes, to know when each of the flaws was introduced. It is likely that some of them arose in code carried forward from earlier versions, that is, from legacy code. Software implementers have a compelling argument to reuse as much code as possible in each new version. It is cheaper because it saves time.

In a product with a history as long as Flash’s (more than 10 years), some of its code was written for a different threat landscape, not for today’s attackers and their more sophisticated tools and techniques. It is reasonable to suspect that a significant portion of the last two years’ worth of newly discovered issues are in code that has been carried into the latest versions. Those flaws contrast with the most recent vulnerability, CVE-2018-4878, which bypasses and abuses protections that were likely put into place after Adobe’s shift in strategy. The code that CVE-2018-4878 abuses was intended to make exploitation of byte arrays “more expensive.”

To measure the popularity of Flash, we turned to Q-Success’ W3Techs web survey data. The following table shows the use of four client-side languages, with Flash declining steadily since 2011. JavaScript, on the other hand, today is nearly ubiquitous, at 95%. The two leading languages are graphed in the chart that follows the table.

Historical Yearly Trends in the Usage of Client-Side Programming Languages for Websites

Usage (in % of sites) of Client-Side Programming Languages for Websites

Chart data as of March 8, 2018. Source for table and chart: © 2009-2018 Q-Success DI Gelbmann GmbH

From W3Techs data, we can see that Flash use has declined steadily, to only 5% of surveyed web sites. Doesn’t that suggest that Flash exploitation would also decline or even stop? Unfortunately, it does not.

The following W3Techs chart shows that although the number of sites using Flash is fairly low, enough high-traffic sites employ it to keep Flash popular.

High-Traffic Sites That Still Use Adobe Flash

Source: PublicWWW.

If popular websites continue to use Flash, then Flash Player will remain in use on users’ machines for some time. Adobe has promised to continue supporting Flash Player until the end of 2020. Unfortunately, this means merely that software updates, features, and patches will no longer be added; it does not effectively change Flash’s overall use. Only the end of websites requiring Flash will remove its vulnerabilities from the security picture.

A highly targeted attack may need to compromise only a single computer to access an organization’s digital infrastructure and gain access to strategic targets. That single computer could be running an unpatched or dated version of Flash.

As the use of Flash has declined, client-side JavaScript has become the de facto browser programming language. Yet JavaScript’s takeover does not fully solve the problem because it can deliver a Flash payload. Although some of the Flash vulnerabilities we have analyzed can be exploited remotely, many cannot. An attacker often requires some interaction by the victim to run a Flash exploit. JavaScript has become an increasingly common delivery mechanism for this purpose.

DIY: Exploits in a Kit

Perhaps more important to attackers is the easy availability of Flash exploits ready to use in numerous exploit “kits.” Kits package all the necessary code to exercise a set of known vulnerabilities. Access to readily available exploits in a kit means far less attacker effort. Kits also “lower the technical bar.” Attackers need not understand how an exploit works; they can simply leverage the packages without knowing the technical details.

Old Flash exploits are still available, along with new ones such as CVE-2018-4878, according to Tim Hux of the McAfee Advanced Threat Research team. “The Bizarro Sundown (aka GreenFlash) and ThreadKit exploit kits added the exploit to their lists last month,” he said. “The Rig and Magnitude exploit kits added this flaw to their arsenals this month.”

Adding a new exploit does not mean the old ones are no longer available. Exploit kits are additive. The Rig kit, which appeared in 2014, contains the following Flash exploits:

CVE-2013-0634           CVE-2015-3113

CVE-2014-0497           CVE-2015-5119

CVE-2014-0515           CVE-2015-5122

CVE-2014-0569           CVE-2015-7645

CVE-2015-0311           CVE-2016-1019

CVE-2015-0359           CVE-2016-4117

CVE-2015-3090

Old exploits do not die, they just get used less often as software is upgraded to fix earlier versions. If an attacker finds a vulnerable version of Flash in use, kits will have exploits to employ.

Conclusion

It is difficult, and perhaps impossible, to prove that software is error free. (Alan Turing’s famous proof mathematically shows that automated processes cannot be proved correct through automation.) As famed computer scientist Edsger Dijkstra noted, “Testing shows the presence, not the absence of bugs.” (“Software Engineering Techniques,” NATO Science Committee, page 16.) In other words, even software that has passed a battery of security tests before release may still contain exploitable conditions.

From our analysis of the relationship between Flash CVEs and Flash’s ongoing use, especially on high-traffic sites, McAfee’s Advanced Threat Research team believes that Flash vulnerabilities will continue to offer attackers a means toward malicious ends. However, Adobe’s shift in security strategy is an excellent step in reducing the number of newly discovered issues, which should maintain their decline.

McAfee protections for CVE-2018-4878

McAfee’s malware engine can parse Flash for malicious content. Customers who have turned on automatic updates or who update regularly have been protected against seven new variants of CVE-2018-4878 since February 6.

McAfee Host Intrusion Prevention signatures 8001, 1149, 6011, and 6010 detect CVE-2018-4878 exploits.

  • 8001 and 1149: On by default, but log only, not block. Customers can select block.
    • 8001: Suspicious exploit behavior, log only, available in HIPS, not in ENS
    • 1149: CMD tool access by a Windows mail client or Internet Explorer, log only, available in HIPS, not in ENS
  • 6011 and 6010: Off by default. Enabling them may result in an increase of false positives.
    • 6011: Generic application invocation protection, not present in ENS
    • 6010: Generic application hooking protection, not present in ENS

Recent campaigns exploiting Flash Player Issues

CVE-2018-4878: Currently being exploited in a massive spam mail campaign.

CVE-2017-11292: Black Oasis Advanced Persistent Threat

CVE-2016-4117: Hidden Cobra APT/CryptXXX Ransomware/Erebus APT

CVE-2016-1019: Cerber and Locky ransomware/Hidden Cobra APT

CVE-2015-3133: CryptoWall Ransomware

CVE-2015-0311: TeslaCrypt and FessLeak Ransomware

CVE-2014-8439: Cerber Ransomware

CVE-2015-7645: Cerber and Alpha Crypt Ransomware

McAfee does not control or audit third-party benchmark data or the websites referenced in this document. You should visit the referenced website and confirm whether referenced data is accurate.
McAfee and the McAfee logo are trademarks or registered trademarks of McAfee, LLC or its subsidiaries in the US and other countries. Other marks and brands may be claimed as the property of others. Copyright © 2018 McAfee, LLC

The post Despite Decline in Use of Adobe Flash, Vulnerabilities Will Continue to Cause Concern appeared first on McAfee Blogs.

Apr 11 2018

Parasitic Coin Mining Creates Wealth, Destroys Systems

The increasing popularity of cryptocurrencies has inspired some people to pursue coin mining, essentially making money online. (Mining is the processing of transactions in the digital currency system, in which new transactions are recorded in a digital ledger called the blockchain. Miners help to update the ledger to verify and collect new transactions to be added to the blockchain. In return, miners earn Bitcoins, for example.) Mining is resource intensive and legal if it is done with the proper permissions.

McAfee Labs has recently seen a huge increase in a malware variant, commonly known as CoinMiner or CoinMiner-FOZU!, which takes control of a victim’s computer to mine new coins by infecting user executables, injecting Coinhive JavaScript into HTML files, and blocking the domains of security products to stop signature updates.

CoinMiner-FOZU!, which we analyzed, has led all major coin-miner malware in prevalence in 2018. (March figures are incomplete.) Source: McAfee Labs.

The following graphs show statistics and geographic data for recent CoinMiner-FOZU! detections:

W32/CoinMiner employs—without a user’s consent—machine resources to mine coins for virtual currencies. Its parasitic nature makes it rare as well as destructive: The malware does not put a unique marker on each file it infects. Thus subsequent infections by the same malware will reinfect the victim’s files.

Analysis

After launching, CoinMiner copies itself into two hardcoded locations:

  • %Windows%\360\360Safe\deepscan\ZhuDongFangYu.exe
  • %filesystemroot%:\RECYCLER\S-5-4-62-7581032776-5377505530-562822366-6588\ZhuDongFangYu.exe

These two files are hidden and read only:

The binary executes from the first location and starts the parasitic infection process. The malware prepends itself to user-executable files but, unlike traditional file infectors, it does not allow the original file to run. It targets files with extensions .exe, .com, .scr, and .pif. This malware does not check for multiple infections. If the threat is deleted and later reinfects the system, the same files will again be targeted.

To prevent victims from restoring clean copies of their files, the malware deletes both ISO (disk image) and GHO (Norton Ghost) files:

 

Once CoinMiner finishes infecting other executable files, it injects a Coinhive script into HTML files. The Coinhive service provides cryptocurrency mining software, which using JavaScript code can be embedded in websites and use the site visitor’s processing power to mine the cryptocurrency:

CoinMiner disables the user account control feature, which notifies the user when applications make changes to the system. Through registry updates, it also disables folder options and registry tools, and deletes safe mode.

From its second location on an infected system—the hidden autorun.inf at the file system root—the malware ensures that it starts after rebooting:

To avoid detection by security products, CoinMiner puts security software domains in the hosts file and redirects them to 127.0.0.1, the loopback address on the victim’s system. If users have not created a local website, they will see an error page in their browsers. By doing this, the malware ensures that no victim can receive an update from the security vendor.

When the victim runs the script-injected HTML files, the Coinhive script executes, downloading coinhive.min.js (hash: 4d6af0dba75bedf4d8822a776a331b2b1591477c6df18698ad5b8628e0880382) from coinhive.com. This script takes over 100% of the CPU for mining using the function setThrottle(0). The mining stops when the victim closes the infected HTML file:

The simple hosts-file injection, hiding in the recycle bin, and maximizing CPU usage suggest that this malware has been written by a novice author. McAfee advises all users to keep their antimalware products up to date.

McAfee Detections

  • W32/CoinMiner
  • CoinMiner-FOZU![Partial hash]
  • TXT/CoinMiner.m
  • HTML/CoinMiner.m
  • JS/Miner.c

Hashes (SHA-256)

  • 80568db643de5f429e9ad5e2005529bc01c4d7da06751e343c05fa51f537560d
  • bb987f37666b6e8ebf43e443fc4bacd5f0ab795194f20c01fcd10cb582da1c57
  • 4d6af0dba75bedf4d8822a776a331b2b1591477c6df18698ad5b8628e0880382

The post Parasitic Coin Mining Creates Wealth, Destroys Systems appeared first on McAfee Blogs.