Category Archives: McAfee

  • 0

Go with the flow! Automating and streamlining workflows with OpenDXL

Category : McAfee

Date: Wednesday, October 11, 2017
Time: 3:00PM BST | 4:00PM CEST

We all need some time hacks to help us get more done in our days. We need technologies that work together for faster detection and remediation. Programmatic workflows can help by automating repetitive and time sensitive tasks, as well as sharing intelligence from disparate sources.

Automating IOC ingestion using OpenDXL can tell more than just where those IOCs live in your environment. Integrating with McAfee Threat Intelligence Exchange (TIE) enables faster action across your environment. And integration with McAfee Active Response (MAR) enables automated searches that result in faster remediation.

Join McAfee OpenDXL Developer Advocate Parker Crook to learn more about how OpenDXL can help you make the most of your time and secure better outcomes for your enterprise.


  • 0

The Hack Back, A Double-Edged Sword

Category : McAfee

Global cyberattacks like Mirai, WannaCry and Petya have left victims feeling helpless and eager to gain back the data they’ve lost at the hands of cybercriminals. This modern threat landscape has everyone looking towards new solutions and strategies—any way they can help protect others while staying secure themselves. So, it’s no surprise that the idea of the “hack back” is gaining some traction. The hack back, a notion that came to light in various congressional proposals that are intended to put tools in the hands of victims to identify alleged attackers, halt an alleged attack, and potentially recover or delete stolen information.

This legislation, first proposed back in May, features policies intended to empower victims of a cyberattack, while still trying to ensure accountability. It states a mandatory reporting requirement for entities that use active-defense techniques, which is intended to help federal law enforcement ensure defenders use these tools responsibly. It also includes an exemption allowing the recovery or destruction of one’s own data if it’s located using the active-defense techniques permitted by this bill and does not result in the destruction of data belonging to another person.

While the objective of the legislation is laudable, helping companies improve their ability to defend themselves, we have to consider some of its risks that could include actions that may well cause damage to parties that either innocently were part of an attack, or through false flag operations that have no direct involvement. For instance, we’ve recently seen that the emerging intent from many attackers is to point the source of attacks to another party, such as was witnessed during the Operation Troy attacks. The use of hacking back in this scenario would have caused damage to a third party.

Our approach, and one we would recommend to others, is to take direct action against malicious actors by utilizing the expertise of law enforcement. A strong partnership between the public and private sector to hold cybercriminals accountable is essential in maintaining a safer society. So, if you do undergo a cyberattack, your first action should be contacting the authorities immediately. From there, experts will handle the situation in a way that ensures safety for all innocent parties involved.

There is a lesson to be learned from the notion of hacking back, however. Instead of hacking back, rather learn how to think like a hacker in order to identify cyberattacks and flag them before the damage is done. By thinking proactively, the need to take reactive measures lessens and the power shifts back to where it belongs: with you.


Author: Raj Samani

  • 0

McAfee Demos Ease of Exploiting Recent Apache Struts Vulnerability

Category : McAfee

A series of exploitable conditions have been uncovered in Apache Struts. One of these, CVE-2017-9805, allows unauthenticated execution of attacker code (aka remote code execution). This issue has already been weaponized into attack kits such as Metasploit and exploitation has been seen “in the wild”; that is, attackers are attempting to take advantage of the flaw.

Apache Struts is a popular open-source component that is used in numerous websites across the Internet, which makes a remote code execution vulnerability very concerning. Speculation is widespread about this issue’s exploitation.

CVE-2017-9805 describes a vulnerability in Apache Struts 2.5.12 that could be subject to a malware attack or other vector of attack designed to take advantage of the vulnerability. To our knowledge, Apache Struts 2.5.12 is not used in McAfee enterprise products as delivered by McAfee.

To demonstrate how easy it is to exploit the vulnerability, we created a little demo in which we take ownership of a vulnerable system. You can watch the video here.

To have an indication of the volume of attacks, the Advanced Threat Research (ATR) team set up a “honeypot” system to attract attack attempts. After less than two hours online, the ATR honeypot system recorded two attacks. One of the attackers attempted to run the Windows command line (cmd.exe) on our Linux box; the other attacker attempted to create a reverse shell toward his machine. If that had been successful, he could have gained full control of our system. Of course, our honeypot setup does not allow a compromise.

McAfee handles reported vulnerabilities in accordance with our product security practices. McAfee adheres to international product incident practices, including CVSS Version 3.0 calculation and CVE assignment.

McAfee actively encourages customer engagement and welcomes specific requests for clarification about our software security process.  There are some things we do not disclose, such as lists of vulnerabilities found through internal investigations or automated testing tools.

For external communications, we publish a security bulletin to all customers of an affected McAfee product as soon as McAfee’s security vulnerability team has confirmed that the vulnerability is critical, and after McAfee has determined appropriate mitigation for the vulnerability. (“Critical” means greater than or equal to CVSS 8.5.) The bulletin may address mitigations, workarounds, and updates. Please see McAfee’s Product Security Bulletins for more information.


This post was written by Brook Schoenfield and the Advanced Threat Research Team.

  • 0

One year later, McAfee ESM

Category : McAfee

We have two SIEMs in the Labs and we use them slightly differently. The McAfee ESM is our workhorse. We use the version 10 and we really like the new html5 user interface. This SIEM started life as the NitroView and it was, at that time, unquestionably the best analyst’s SIEM available. Today, Nitro having been acquired by McAfee, sold to Intel, and returned to McAfee, the product has undergone many changes, all of them very positive from our perspective. Perhaps the most important change is its personality. It still is a great analyst’s tool but it has become far more user-friendly over the years. Today it is a fine SOC engineer’s tool without losing any of its analytical chops.

This is a highly configurable tool and we stretch it constantly. It is so feature-rich that we would be hard-pressed to address everything that it can do in a single review. The easy way to introduce yourself to the ESM, once you have it installed and configured in your environment, is just to turn it on and look the default dashboard over. Without any fancy manipulation, you are presented with lots of important and useful information. From that point, you can select any of dozens of views concentrating on just about anything from malware to user activity to compliance. It comes pre-configured with special dashboards for just about any compliance task you can think of.

The power doesn’t stop there, though. The dashboards consist of collections of views that select elements that go together and place those collections in windows that you can edit and move around, adding your own elements and creating entire new collections for truly custom dashboards. For any given task, you start by selecting the dashboard you want and then performing drill-downs. This gives you a custom-designed threat hunting environment. This lets the SIEM do double duty: as a correlator of sensors with the job of alerting on suspicious behavior, and as a first-rate threat hunting tool.
Here in the Labs we are engaged mostly in research and testing. We let our SIEMs watch the Internet directly with no firewall. So, this is like drinking, not from a firehose, but from Niagara Falls. Add to that, we have a honeynet, deception network and a TOR exit node. We don’t have the SIEM configured precisely the same as you might in a production environment in your enterprise. That speaks volumes about the versatility of the device.

In a typical enterprise environment, you would be feeding it from every log source you could find – and it will accept them all, most out of the box, but you may need to do a bit of fiddling for odd or unusual log and flow sources. The tool looks at all events and flows, correlates them and plays them against standards you configure to get to risk. So, at the end of the day, with the addition of vulnerability and weighting data, ESM becomes a risk measuring machine.
McAfee has provided, automatically, a collection of threat intelligence feeds but you can add your own easily as well. Some are as easy as adding a simple command for execution with a single click. For example, we use several web sites to analyze intelligence on an IP address. We added those feeds to the ESM and now when we select an IP address we can select a threat feed we want to send it to as well. This returns intelligence on that IP – perhaps it is on a block list or has a bad reputation. We get all of this with a click of the mouse. Setting it up took about two minutes per threat intelligence site.

We have used the ESM in enterprise situations where we have been able to analyze logs such as domain controller and active directory server logs and correlate those data with others we may have found. This adds significantly to the threat hunt.
We have found support to be exceptional. The product is available as a virtual appliance or a physical one. There are specific support programs for each one. Support packages at the gold level include all updates for rules, signatures and content packs. Since you can build out your own content packs that is pretty powerful. Support at that level is 24X7. Documentation is everything it should be and pricing is very reasonable for the power the SIEM delivers.
IT should go without saying that this will be SC Lab Approved for another year, but just to avoid confusion, it has a home in the Labs for the next 12 months.


  • 0

Analysis of Chrysaor Keylogging Mechanism Shows Power of Simple Malicious Code

Category : McAfee

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.


The basic keylogging process.

The sample has two main binaries related to keylogging: and When the sample executes, the former is copied to /data/local/tmp/inulmn and the latter to /data/local/tmp/ The file injects shellcode into the memory space of the keyboard process (Step 1 in the preceding graphic). When the shellcode runs, it loads 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/ 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/ ;

chmod 0777 /data/local/tmp/inulmn ;

chmod 0777 /data/local/tmp/ ;

/data/local/tmp/inulmn <pid of keyboard process> /data/local/tmp/ 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/, 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 allows the injecting of code into the keyboard process and executing certain functions using the ptrace API. 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 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. calls the init() function, which installs a hook for keylogging. 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(“”) 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.


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.


Author: Jaewon Min

  • 0

Android Click-Fraud Apps Briefly Return to Google Play

Category : McAfee

Click-fraud apps frequently appear on Google Play and third-party markets. They are sometimes hard to identify because the malicious behavior that simulates clicks is similar to the behavior of many legitimate applications (using common API calls and permissions). Further, part of the malicious code does not reside in the original malware and comes from a control server. Using special methods to perform the clicking allows the attackers to decide when and how pursue their fraud.

The McAfee Mobile Malware Research Team recently found on Google Play a group of Android/Clickers published by the developer “TubeMate 2.2.9 SnapTube YouTube Downloader J.” Five apps were updated on Google Play on August 4 and were removed a few days later, along with the developer profile.


By checking “” on GooglePlay we saw something suspicious in this application: a nonsense name, no description, and poorly reviewed. Of course, those traits do not guarantee an app is malicious, but this lineup should serve as a warning for Android users looking for new apps.


Analyzing and reverse engineering this sample shows us a DeviceAdminReceiver class that connects to a hardcoded URL to obtain parameters that indicate how and where to perform click-fraud activities:

This function is part of a service initiated by a receiver related to DeviceAdmin.

Once the URL is requested, the control server returns an HTML page with the parameters in an uncommon way—inside the title tag, as we see in the following:

All the parameters are in one line, but the malware interprets them using the string “eindoejy” to separate them, obtaining the target URL, JavaScript functions to perform clicks, HTTP headers used in the fraudulent HTTP request, and another Google Play package to monetize the clicks in the abused ad network. We thought that string “eindoejy” could be an anagram of “I enjoyed” or “die enjoy,” but we found other variants in which the word used to split the parameters is different.

Once installed, Android/Clicker.BN adds an icon to the main menu that is not related to the downloaded app from Google Play. The new icon appears to be a system utility. Some examples of the icons loaded by the malware:

When Android/Clicker.BN executes, it requests device administration privileges:

Some of the apps can access YouTube inside a WebView and list trending channels, others lock and blacken the screen, and others crash the UI while in the background running click fraud—which not only harms advertisers and publishers, but also generates malicious traffic on infected devices, impacts battery and overall usage performance, and opens the door to new malicious payloads.

McAfee Mobile Security detects this threat as Android/Clicker.BN!Gen and prevents its execution. To further protect yourself against malicious apps, use only legitimate app stores, and pay attention to suspicious traits such as nonsense names, missing descriptions, and poor reviews. Also verify that the app’s request for permissions are related to its functionality. Be wary when apps request device administration API access, which is usually requested only by security apps, antimalware, mobile device management, or corporate email clients. Most apps and games will never ask for device admin rights.


Author: Fernando Ruiz

  • 0

Why Human-Machine Teaming Will Lead to Better Security Outcomes

Category : McAfee

Artificial intelligence and machine learning have never been more prominent in the public forum. CBS’s 60 Minutes recently featured a segment promising myriad benefits to humanity in fields ranging from medicine to manufacturing. World chess champion Garry Kasparov recently debuted a book on his historic chess game with IBM’s Deep Blue. Industry luminaries continue to opine about the potential threat by AI to human jobs and even humanity itself. Much of the conversation focuses on machines replacing humans. But the fact is the future doesn’t have to see humans eclipsed by machines.

In my field of cybersecurity, as long as we have a shortage of human talent, and, as a 451 Research report released this week illustrates, we must rely technologies such as these to amplify the capabilities of the humans we have. Furthermore, as long as there are human adversaries behind cybercrime and cyber warfare, there will always be a critical need for human intellect teamed with technology.

We recently commissioned 451 Research to delve into this area in one of its Pathfinder Advisories. Released this week, the report nicely frames the concept of “human-machine teaming” in cybersecurity. It identifies ways in which we can use machine learning to overcome the challenges of protecting organizations and do so with an insufficient number of cybersecurity professionals.

To quote the report:

“Machine learning makes security teams better, and vice versa. Human-machine teams deliver the best of both worlds:

  • Machine learning means security teams are better informed so they can, therefore, make better decisions.Security executives realize that the intelligence and creativity of their security operations experts are critical business resources. Machine learning is a technology that allows chief security officers (CSOs) to get the most out of human and security product assets.
  • Adversaries are human, continuously introducing new techniques. Creative new tactics and strategies dealt by adversaries force security teams to employ machine learning to automate the discovery of new attack methods. Creative problem solving and the unique intellect of the security team strengthen the response.
  • Machine learning becomes more accurate as more data is available to feed its algorithms. Enhancements in handling big data using high-performance and massive-capacity storage architectures have enabled the growth of artificial intelligence.
  • IT teams need help analyzing faults. In those rare instances when endpoint security cannot prevent damage from an attack, machine learning accumulates relevant data elements into one place, placing it at the fingertips of security analysts when needed.
  • Human-machine teaming makes for sustainable endpoint security. As new threats are introduced, security teams alone cannot sustain the volume, and machines alone cannot issue creative responses. Human-machine teams make endpoint security more effective without draining performance or inhibiting the user experience.”

Machine learning has enabled us to improve the accuracy of hurricane forecasting from within 350 miles to within 100 miles. Nate Silver’s best seller The Signal and the Noise notes that although our weather forecasting models have improved, combining this technology with human knowledge of how weather systems work has improved forecast accuracy by 25%. Such human-machine teaming has literally saved thousands of lives.

As we implement machine learning deeper into our cyber defenses, we must recognize that humans are good at doing certain things and machines are good at doing certain things. The best outcomes will come from combining them. Machines are good at processing massive quantities of data and performing operations that inherently require large scales. Humans have strategic intellect, so they can understand the theory about how an attack might play out even if it has never been seen before.

Of course, thunderstorms are not trying to evade the latest in machine learning technologies applied by human beings. Cybercriminals are.

Cybersecurity is very different from other fields that employ big data, analytics, and machine learning because there is an adversary trying to reverse engineer your models and evade your capabilities. Security technologies such as spam filters, virus scans, and sandboxing are still part of protection platforms, but their industry buzz has cooled since criminals began working to evade their technology.

Based on the information they receive, IT security staff on the front lines of an attack can anticipate new evasion techniques, exploits, and other tactics in ways detection models based on the past cannot. A major area in which we see this playing out is attack reconstruction, where technology assesses what has happened inside your environment, and then engages a human to work on the scenario.

Efforts to orchestrate security incident responses can benefit tremendously when a complex set of actions is required to remediate a cyber incident. Some of those actions might have very severe consequences to networks. Having a human in the loop not only helps guide the orchestration steps, but also assesses whether the required actions are appropriate for the level of risk involved.

The 451 report asserts that machine learning will manifest itself by optimizing the cyber professional’s user experience, automatically flagging suspicious behavior, and by automatically making high-value investigation and response data available. In this way, says the report, IT security teams will have “the ability to rapidly dismiss alerts and accelerate solutions that thwart new threats.”

In threat intelligence analysis, attack reconstruction, and incident response orchestration, human-machine teaming takes the machine assessment of new information and layers upon it the intellect that only a human can bring.

Doing so can lead us to better outcomes in all aspects of cybersecurity. Now more than ever, better outcomes are everything in cybersecurity.


Author: Steve Grobman

  • 0

Mastering the Endpoint, A Forrester Report

Category : McAfee

Organizations now monitor 10 different security agents on average, and swivel between at least five different interfaces to investigate and remediate incidents. Learn how to master endpoint security with these recommendations from Forrester.

Please  download the Forrester report.

  • 0

Network Security in the Amazon Web Services Cloud – It’s Your Responsibility!

Category : McAfee

There is a presiding notion that because established cloud providers such as Amazon deliver enterprise-class infrastructure, security is “taken care of.” When you set up your workloads in AWS, you hopefully configure available settings like access control and firewall port restrictions. That’s all good, and necessary! But outside of the cloud, would that ever be enough?

Hopefully your answer is no. And Amazon agrees. As a customer or prospective user of AWS, you should familiarize yourself with what is known as the “Shared Responsibility Model”, essentially stating where Amazon’s security ends, and your responsibility begins. Here’s their graphical representation:

Fig. 1 The AWS Shared Responsibility Model. For more visit

If you’re familiar with data center security, server security, or security for virtualized infrastructure, you’re probably not surprised with this breakdown. Encrypting data, running host-based anti-malware, and configuring access control are staples of your practice.

Let’s not forget – the cloud has a network too. And its susceptible to threats just like your own datacenter network, and more specific to the cloud. Advanced malware can reach your AWS workloads through network traffic, along with cross site scripting, botnet, and SQL injection attacks. Cloud infrastructure also has its own vulnerabilities – if one virtual server in AWS is compromised, the malware can potentially roam to other vulnerable servers in the same environment. This lateral path is known as “east-west” network traffic, and is much more prominent in virtualized environments. Additionally, there are unique management challenges in the cloud, like orchestrating security controls across a dynamically changing environment, and automating the process. Not to mention, simply gaining visibility into what workloads are being spun up by your organization!

Moving workloads to the cloud confidently means solving these security challenges as you plan your deployment, not after. If you’re responsible for data center and cloud infrastructure, bring your security team in early. Security professionals – don’t assume security in the cloud will hold back the agility your organization needs.

Stay tuned for part 2 of this short series on protecting cloud networks in AWS for our technology recommendations, and a new way to kick the tires with no investment required.



  • 0

New Surveillance Malware “FruitFly” Is a Nearly Undetectable Mac Backdoor

Category : McAfee

Mac malware outbreaks used to be viewed as a rarity. However, the last few years have seen Mac-focused threats steadily on the rise. In fact, our McAfee Labs Quarterly Threats Report showed instances of Mac malware growing by a huge 744% in 2016. Fast forward to the summer of 2017, and a new and powerful strain of Mac malware has hit the scene. Named FruitFly, the threat has only recently been detected by researchers, despite being around for years. The malware is highly-invasive and capable of taking complete control of an infected Mac.

FruitFly malware works as a traditional RAT (remote access trojan). Once it infects a Mac, this RAT creates a backdoor and helps the attacker control the infected device through the Command and Control server (C&C or C2) by sending its system commands. These commands include taking screenshots of the display, remotely switching on the webcam, and modifying files. What’s more — later versions of FruitFly seem to have the ability to control mouse movements and interactions with the infected machine.

Though powerful, FruitFly is primarily old fashioned. It partially utilizes the Perl programming language, which is not commonly used anymore. Additionally, the open source libjpeg code, which enables programmers to handle the JPEG image format, can also be found in FruitFly malware samples dating back to at least 1998. This all suggests the programmers have been around for some time.

Who has been impacted by FruitFly so far? Fortunately, only a small number of users are known to have been targeted by both old and new variants. Biomedical personnel were the main target of the first variant and users at home were the target of the later variant. However, smaller, tailored FruitFly campaigns may continue to persist for a while, which means all Mac users need to be vigilant. Additionally, much of the code written for FruitFly is cross platform, meaning that it can also run on Linux. While the current version does not run fully on Linux, there are only a few necessary changes to make it viable. This suggests a Linux variant may exist or is planned.

The good news is there are a few things users can do to stay protected from FruitFly. First off, users can protect against older variants just by updating a Mac to include the latest patch. Newer variants still require detection and prevention, which means users need to run up-to-date security products.

For McAfee customers – our solutions detect both the dropper and the sample itself from the both old and new variants. The latter is detected using our cloud technology Artemis.


Author: Charles McFarland